بعض محتويات هذا التطبيق غير متوفرة في الوقت الحالي.
إذا استمرت هذه الحالة ، يرجى الاتصال بنا علىتعليق وإتصال
1. (WO2019061856) PRE-PROCESSING IN WIRELESS UPLINK TRANSMISSIONS
Document

Description

Title of Invention 0001   0002   0003   0004   0005   0006   0007   0008   0009   0010   0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074  

Claims

1   2   3   4   5   6   7   8   9   10  

Drawings

1   2   3   4  

Description

Title of Invention : Pre-processing in Wireless Uplink Transmissions

Technical Field

[0001]
The present disclosure relates to processes to enable pre-processing of data prior to uplink transmissions, with effective discard mechanisms.

Background

[0002]
Wireless communication systems, such as the third-generation (3G) of mobile telephone standards and technology are well known. Such 3G standards and technology have been developed by the Third Generation Partnership Project (3GPP) . The 3 rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Communication systems and networks have developed towards a broadband and mobile system. The 3rd Generation Partnership Project has developed the so-called Long Term Evolution (LTE) system, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN) , for a mobile access network where one or more macrocells are supported by a base station known as an eNodeB or eNB (evolved NodeB) . More recently, LTE is evolving further towards the so-called 5G or NR (New Radio) .
[0003]
5G or NR proposes a new radio link standard for the UE to base station link. The NR configuration and protocols utilise many LTE features as a starting point, but add a wide range of additional features and operation modes very different to LTE.
[0004]
As shown in Figure 1 the NR RAN consists of gNBs, providing the NG-RA user plane (new AS sublayer/PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the UE. The gNBs are interconnected with each other by means of the Xn interface. The gNBs are also connected by means of the NG interface to the Next Generation Core (NGC) , more specifically to the AMF (Access and Mobility Management Function) by means of the N2 interface and to the UPF (User Plane Function) by means of the N3 interface (see 3GPP TS 23.501) .
[0005]
The User plane protocol stack for NR (as defined in 3GPP TR 38.804) is shown in Figure 2. PDCP, RLC and MAC sublayers (terminated in gNB on the network side) perform similar functions as LTE. Additional functions exist in NR to fulfil those specific requirements not existing in LTE.
[0006]
In NR it is proposed to permit pre-processing of UpLink (UL) RLC PDUs from PDCP PDUs submitted by PDCP to RLC. Pre-processing is used herein to describe the formation of PDUs before a transmission opportunity is available, and may also be termed pre-generation. As used herein, “link” refers to a connection between termination points of the lower layers (RLC/MAC) , such that in dual (or multiple) connectivity a PDCP entity may be connected to several links.
[0007]
A difficulty with RLC pre-processing is that it may impede an RLC SDU discard procedure whereby the PDCP entity can request that the RLC layer discard already- submitted PDCP PDUs. Additionally, RLC pre-processing may also impact procedures such as reconfigurations in which it could be desired to e.g. avoid losing the corresponding PDCP PDUs, or avoid additional reordering delay corresponding to the transmission of these PDCP PDUs.
[0008]
There is therefore a requirement for a system to permit RLC pre-processing without impeding discard procedures, and also without impacting reconfiguration procedures performance, as far as possible.
[0009]
Summary
[0010]
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
[0011]
The invention is set out in the appended claims.
[0012]
According to an aspect of the invention, there is provided a non-transitory computer readable medium having computer readable instructions stored thereon for execution by a processor to perform the method according to the first aspect.
[0013]
The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

Brief description of the drawings

[0014]
Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. Like reference numerals have been included in the respective drawings to ease understanding.
[0015]
Figure 1 shows a schematic diagram of the principle components of a network according to the proposed NR standard;
[0016]
Figure 2 shows a proposed protocol stack;
[0017]
Figure 3 shows a PDU discard method; and
[0018]
Figure 4 shows a PDU retransmission method.
[0019]
Detailed description of the preferred embodiments
[0020]
Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.
[0021]
Permitting discard of PDCP PDUs is beneficial as it reduces the transmission of unrequired data over the air interface. However, if the PDCP PDU (RLC SDU) (or part thereof) has already been formed into an RLC PDU it is necessary to discard the whole RLC PDU. This may result in a number of RLC protocol issues due to the missing RLC PDU. Preventing discard if the PDCP PDU (or part thereof) has been formed into an RLC PDU avoids such protocol issues, but provides an inefficient discard protocol.
[0022]
In NR RLC Unacknowledged Mode (UM) , when the RLC PDU contains a complete RLC SDU the RLC header does not contain any protocol information which could lead to an RLC protocol issue if the PDU is discarded. The RLC header only contains an SI field indicating that the RLC PDU contains a completed RLC SDU, but does not contain an RLC SN.
[0023]
In UM it is therefore possible to discard the whole RLC PDU containing a complete RLC SDU (PDCP PDU) , provided it has not been submitted to the lower (MAC) layer. An efficient discard procedure can thus be defined in which PDCP PDUs are pre-processed into RLC PDUs, and discard of RLC PDUs is permitted for RLC PDUs containing complete PDCP PDUs until submission to the lower layer.
[0024]
Where an RLC PDU contains a segment of a PDCP PDU, discard of the RLC PDU may still be possible if the RLC PDU has not been submitted to a lower layer. However, this may cause reordering delay at the receiver, which may or may not be acceptable depending on the service being carried
[0025]
In RLC AM each RLC PDU containing a complete RLC SDU (PDCP PDU) includes a different RLC SN, and hence discarding such an RLC PDU causes an SN gap which may cause the RLC AM receiver to request retransmission of the missing RLC PDU, which defeats the purpose of discarding the RLC SDU. This disadvantage can be avoided by signalling to the receiver when an RLC PDU is discarded, or re-assigning RLC SNs following discard. However, the first option creates additional signalling overhead, and the second option limits pre-processing flexibility. The UE has very limited time to form MAC PDUs when a transmission opportunity arises, but re-numbering RLC PDUs may render a set of them unavailable immediately and the transmission opportunity would be lost.
[0026]
The difficulties with the above solutions can be addressed using a hybrid discard system as shown in Figure 3. An RLC PDU may be discarded by the RLC layer if the RLC PDU has not been submitted to a lower layer, and the RLC PDU is the latest in the transmission window.
[0027]
As shown in Figure 3 there are three groups of RLC PDUs. RLC PDUs 300 have been sent to the lower layer and cumulatively acknowledged by an RLC status report, and RLC PDUs 301 have been submitted to the lower layer, but not cumulatively acknowledged by a RLC status report. RLC PDUs 300 and 301 cannot be discarded.
[0028]
RLC PDUs 302 have not been submitted to the lower layer and pending submission. From the set 302, RLC PDUs 303 cannot currently be discarded as they are not the latest RLC PDUs in the transmission window and hence discarding them would lead to an SN gap.
[0029]
RLC PDU 304 is the latest in the transmission window, that is RLC SN 304 -VT (S) -1. RLC PDU 304 can thus be discarded without creating an SN gap and VT (S) can be updated to VT (S) -1 as if the RLC PDU 304 had never been generated.
[0030]
If RLC PDU 304 has been discarded, RLC PDU 305 becomes the latest RLC PDU in the transmission window (RLC SN 305 = VT (S) -1) . Discard requests received by the RLC layer for RLC PDUs that are not the latest are stored by the RLC layer as the PDUs may become the latest RLC PDUs if higher-numbered RLC PDUs are discarded. Once a PDU is submitted to the lower layer the discard request can itself be discarded.
[0031]
It is possible that when RLC SN = VT (S) -1 is discarded, all RLC PDUs with lower RLC SN will also have had discard requests due to PDCP discard timer behaviour. While this may be used to guide RLC layer behaviour, independent operation may be preferable to avoid creating a reliance between the PDCP and RLC layers.
[0032]
The current NR standards utilise the nomenclature TX_Next for VT (S) and TX_Next_ACK for VT (A) , but this does not affect the principles of operation.
[0033]
RLC SDUs (PDCP PDUs) which are not yet mapped to an RLC data PDU can be discarded without restrictions as they have no SN or any other RLC protocol field, and their discard has no effect on the RLC layer.
[0034]
In situations where RLC SDU segments are only created upon submission of a segment of the same RLC SDU to the lower layer, discard of RLC SDU segments should not be permitted at it will always create a segment gap (but not an SN gap) . The segment gap will create an ARQ retransmission request, thus disrupting the process flow.
[0035]
In situations where pre-processing of RLC PDUs permits creation of RLC PDUs with an RLC SDU segment, discard according to the above rules is permissible, provided all segments of an RLC SDU are discarded. Similarly to current NR user plane design, this case cannot happen as the segmentation of a RLC SDU coincides with the submission of the first segment to the lower layer (MAC) . This means that for AM, it is not possible to discard a RLC SDU segment, whether it was pre-processed or not into a RLC PDU, since it is associated with a first RLC SDU segment which was already submitted to the lower layer.
[0036]
An additional discard function may be provided to cause the RLC layer to discard all RLC PDUs and RLC SDUs that can be discarded according to the above rules. The function may be termed a “full discard” or flush. As above, any RLC SDUs that have not been mapped to RLC PDUs may be automatically discarded. RLC PDUs are discarded according to the above principles, using a sequential application of the rules, such that the last RLC PDU in the transmission window that has not been submitted to the lower layer may be discarded. A full discard will thus result in all unsubmitted RLC PDUs being discarded because each of those PDUs becomes the last unsubmitted PDU in turn, as the previously highest SN PDU is discarded.
[0037]
The effect of a full discard is the same as issuing individual instructions to the RLC layer for each RLC PDU. However, in that case the RLC layer must store the discard instructions and only by conducting them in the correct order will all RLC PDUs be discarded. The full discard may thus provide an efficient mechanism to discard all possible RLC PDUs. The full discard is applicable to both AM and UM cases.
[0038]
For AM, the “full discard” procedure can be seen as a partial RLC re-establishment procedure, which does not impact UL, does not impact the pre-processing flexibility agreed for NR and allows the maximum amount of data buffered in RLC for transmission to be discarded. For UM, the “full discard” procedure is applicable to the transmitting UM RLC entity.
[0039]
The “full discard” procedure can be invoked directly from RRC, or through PDCP depending on the chosen modelling. In current NR specification, “RLC re-establishment” is invoked by RRC whereas “SDU discard” is invoked by PDCP. A use case for the “full discard” procedure is described later.
[0040]
The specifications provide for configuration via RRC signalling of a split bearer. A split bearer associates one PDCP entity to two links (and could be extended to more links) . The transfer of PDCP PDUs may use either link, in DL or UL. In DL, the network has full control on whether the PDCP PDUs are transmitted on one or the other link. It may choose to send PDCP PDUs on both links, to aggregate the traffic and increase the throughput, or to a preferred link. Similarly, in UL, both links could be used to aggregate the traffic, or only a preferred link could be used. Such particular application of split bearer in UL is referred to as UL path switch. One UL link is configured at a time for transmission of PDCP PDUs in uplink (RLC control, for instance RLC STATUS in UL related to the reception of downlink RLC PDUs, still needs to be sent on the link associated to the RLC entity) , but the UE is capable of switching between them, e.g. upon signalling by the NW, or autonomously according to predefined rules. Such a configuration allows a UE to continue operation if one link becomes blocked. For example, NR enables the use of the millimetre wave band, which is susceptible to temporary blockage. A second link utilised a different band, or LTE, may be utilised as a fall-back when the first NR link fails.
[0041]
One possibility to switch between links is to reconfigure the bearer between MCG and SCG bearer types, but the reconfiguration requires RRC and CN signalling, and a re-establishment process for the lower layers. It is more convenient for the network to setup a split bearer since for downlink, it has full control of the downlink scheduling with the ability to schedule on either leg, and for uplink, it can reconfigures the UL path quickly, or configure the UE to be able to switch to either leg on the uplink according to predefined rules.
[0042]
A further case in which transmission on a single leg of a split bearer may be used is when intermodulation prevents transmission on both legs simultaneously. No capacity is gained from the split bearer, but UL path switch can be utilised to select the best leg and avoid simultaneous transmission on both legs.
[0043]
As noted above leg/link of a split bearer has its own respective RLC termination point. The LTE specification for split bearers requires that UL data is retained in the PDCP layer until it is requested by the lower layer (i.e. an UL grant is received) . The RLC termination point for each link does not therefore hold RLC SDUs prior to transmission. Switching the active link is therefore a straightforward task as PDCP PDUs can simply be directed to the other RLC termination point for transmission. However, in NR it is proposed to allow submission of PDCP PDUs to lower layers in advance, even if a split bearer is configured. A first RLC termination point may thus be storing a significant number of PDCP PDUs at the time it is desired to switch the link.
[0044]
It is possible for the first RLC termination point to seek to finish transmission of all PDCP PDUs it has received, and further PDCP PDUs to be sent to the second RLC termination point. However, transmission of the remaining PDCP PDUs on the first link may be difficult due to a blockage of that link (which led to the decision to switch links) . This means the transmission of the old PDCP PDUs over the first link can be delayed compared to the transmission of the new PDCP PDUs over the new link, which leads to reordering delay at the receiver and decrease performance.
[0045]
Difficulties with transmission of PDCP PDUs already submitted to the lower layer may be addressed by retransmitting those PDUs on the new link. For example, any PDCP PDUs for which delivery has not been confirmed may be sent to the new RLC termination point for transmission. However, this is only applicable for AM for which there is RLC ARQ feedback on whether the transmission was successful, as for UM HARQ feedback is not considered reliable enough.
[0046]
This process is similar to the PDCP data recovery mechanism (38.323v1.0.0) , associated with the RLC re-establishment of the old link, which process could be utilised at UL path switch. A benefit of this is that the process will flush the PDCP PDUs held by the first RLC termination point, thus preventing the additional delay to transmission of these PDCP PDUs in the first leg, and also preventing duplicate transmission of these PDCP PDUs. However, that process utilises an RLC re-establishment procedure, which has the major disadvantage of also interrupting DL transmissions. A modified procedure is preferable in which the original link is not re-established to avoid the disruption to DL data, which may be termed ”fast data recovery” . The data recovery procedure is specified in the L2 specifications, in which a new procedure could be specified to attend to changing the UL path. In this procedure, PDCP perform retransmission of PDCP PDUs for which delivery has not been confirmed in the old link to the new link, whereas RLC entity of the old link is not re-established.
[0047]
Following the switch to the new link, the PDCP PDUs for re-transmission should be sent first, before any new PDCP PDUs are sent to minimise re-ordering delays at the receiver in case the existing PDCP PDUs are stuck due to blockage of the original link. Eventually the PDCP PDUs sent via the first link will be transmitted and received at the network, but the duplication will be detected and eliminated by the PDCP termination point on the network side. A PDCP status report may also enable removal of the duplicate PDCP PDUs before they are transmitted.
[0048]
However, in a situation where the original link is functional, but the link switch is performed for other reasons (for example, load balancing) , it is preferable that transmission continues on the original link until all PDCP PDUs sent to the first RLC termination point have been transmitted since it is expected this will happen quickly and it avoids duplication.
[0049]
The network should be able to select an appropriate mechanism for the particular switch being performed. Signalling is preferably performed along with the UL path switch indication and may be via RRC, or other means. A new parameter may be added to the RRC Reconfiguration message to indicate that in the case of an UL link switch whether a fast data recovery procedure should be performed. Similarly, in case a fast data recovery procedure is not defined, such parameter may indicate whether a data recovery procedure (along with associated RLC re-establishment and possible drawback on the downlink data transfer) is required.
[0050]
In a modification of the fast data recovery procedure discussed above, a full discard or flush of the first RLC termination point may be performed according to the principles discussed above. This process should lead to the majority of the PDCP PDUs that are not acknowledged being discarded, thus preventing useless transmission on earlier link and duplicating transmission. Only those PDCP PDUs that have already been submitted to the lower layer will not be discarded.
[0051]
Figure 4 shows a diagram of the state of the two RLC layers at the time of the path switch. PDCP PDUs 0-6 have either been successfully delivered or have been sent to the lower layer and so cannot be discarded. However, PDCP PDUs 7-9 are pending submission and so can be discarded. Since PDCP PDUs 2-6 have not been acknowledged at the time of the switch they are sent via the new link as well and hence there is duplicate transmission. However, although PDCP PDUs 7-9 are transmitted via the new link, there is no duplication as they were discarded from the original link. Transmission of new PDCP PDUs then continues with numbers 10 and 11 and the connection is fully operational on the new link.
[0052]
The discard/flush procedure may be indicated in the same signalling as the fast switch and/or fast data recovery processes via RRC or other signalling.
[0053]
When performing the discard process during a link switch, the UE may be configured to only retransmit PDCP PDUs which were successfully discarded during the process (in the above example only 7-9) , or equivalently the PDCP PDUs in ascending COUNT order starting from the PDCP PDU with the earlier COUNT value which was successfully discarded by lower layers (the following PDCP PDUs are necessarily also successfully discarded) . The PDCP PDUs that could not be discarded are assumed to be transmitted via the original link (2-6 in the above example) , thus minimising duplication transmission. This procedure is particularly useful in case of a UM split bearer (i.e. a split bearer using RLC UM entities) . For UM, the retransmission of PDCP PDUs for which delivery has not been confirmed is not easily applicable, as there is no RLC feedback, and HARQ feedback is considered not reliable for this purpose and would introduce additional layer interaction. Generally, a UM bearer is supposed to be tolerant to packet losses. However, these packet losses are supposed to be sporadic. With the possible pre-processing for NR, a significant amount of PDCP PDUs may be pre-processed in a first NR leg. In case this leg encounters UL issues, and an UL path switch is signalled by the NW, not retransmitting these PDCP PDUs is likely to lead to a burst of packet loss. Indeed, the original PDCP PDUs on the first link will be delayed and eventually discarded at the receiver, if ever transmitted. Hence, it can be preferred to instruct the UE to perform the retransmission of the discarded PDCP PDUs.
[0054]
For UM, there are separate RLC entities for transmitting and receiving side. Hence, as an alternative to use a new “discard/flush procedure” , it can be considered to use the re-establishment of the transmitting RLC UM entity. During RLC re-establishment, all state variables of the RLC entity are reset. The re-establishment of the transmitting RLC UM entity currently only discard RLC SDUs, however with the possible pre-processing in NR it could be updated to discard also the pre-generated RLC PDUs. RLC PDUs containing complete SDUs might not cause RLC protocol issues, however, RLC PDUs containing SDU segments would cause RLC protocol issues if not discarded, since their SN would not match the SN expected by the receiver. Hence, the procedure should be updated to at least discard the RLC PDUs corresponding to PDCP PDU segments. Preferably, it should also be updated to discard the pre-generated RLC PDUs, even containing complete PDCP PDUs. Even these RLC PDUs would not cause RLC protocol issue, generally at RLC re-establishment, RLC is not supposed to still transmit PDCP PDUs submitted earlier than when the re-establishment is performed. This can lead to protocol issues for higher layers. For example, the RLC reestablishment is typically associated to a PDCP reestablishment, which can be associated with a ciphering key change. In such case, the PDCP PDUs submitted before the RLC re-establishment are not ciphered with the same key as the PDCP PDUs submitted after the RLC re-establishment. The PDCP receiver will not expect to receive PDCP PDUs ciphered with the old ciphering key on the new link used after RLC re-establishment, and these PDCP PDUs will not be correctly deciphered. It is then preferred that when performing a transmitting RLC UM entity re-establishment, not only RLC SDUs, but also pre-generated RLC PDUs (containing complete RLC SDU or RLC SDU segment) as well as any possible remaining RLC SDU segments are discarded.
[0055]
With such update, the transmitting RLC UM entity re-establishment procedure might be used instead of the “full discard/flush” procedure. In PDCP specification, it can be indicated that in case a PDCP re-establishment is requested for UM DRB, PDCP performs transmission of PDCP SDUs in ascending order of the COUNT value associated to the PDCP SDU prior to the PDCP re-establishment starting from the COUNT corresponding to the first PDCP PDU successfully discarded in the re-established transmitting RLC UM entity, if any. This enables to mitigate the burst packet loss which would otherwise occurs due to the pre-processing of RLC PDUs in the RLC UM entity.
[0056]
An additional benefit of using the transmitting RLC UM entity re-establishment procedure is that it would be applicable to more use cases than the UL path switch reconfiguration case. Indeed, some mobility/bearer type reconfigurations requires PDCP re-establishment /transmitting RLC UM entity re-establishment procedure, and the proposed retransmission mechanism will be applicable as well. In case of UL path switch for a UM bearer, the same PDCP re-establishment /transmitting RLC UM entity re-establishment procedure can be used.
[0057]
The above principles can be extended to reconfigurations which combine a bearer type change and a UL transmission path change, considering that for a non-split bearer the UL transmission path is given by the CG supporting the bearer (MCG for a MCG bearer, SCG for a SCG bearer) . For instance, a UE may be configured in EN-DC with a SCG bearer. If reconfigured to a split bearer with UL transmission path in MCG (LTE) , the same principles can apply.
[0058]
The decision to switch from a first link to a second link may be taken by the network for instance based on the monitoring of both links, and signalled to the UE, or conversely it might be taken by the UE in an autonomous way. For example, a UE may be pre-configured to perform the switch if the first link becomes congested. The precise switching and PDCP PDU handling processes may be defined in advance and executed appropriately, however generally the above-described procedures equally apply whether the UL path switch is signalled by the NW or autonomously decided by the UE.
[0059]
Upon SCG failure or SN failure, for instance in case of RLF, the specifications currently specify that the UE stops transmission towards the SCG, notifies the master node, which then reconfigures appropriately the bearer. In case of split bearer, this can be enhanced if the UE autonomously performs the retransmission operation described above on detecting the SCG failure, without waiting for the NW reconfiguration. In such case, transmission is stopped on SCG as in existing behaviour, and the UE autonomously starts the retransmission on MCG link.
[0060]
[0061]
The term base station is used in this document to describe a component that provides the function of terminating a wireless link to a UE and provides a connection to the network. For example an eNB may be considered a base station in the LTE system, and a gNB may be considered a base station in the proposed New Radio system.
[0062]
Aspects of the disclosure may be performed by a computing system, for example forming part of the UE or gNB. The computing system can include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.
[0063]
The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW) , or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.
[0064]
In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface , such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.
[0065]
The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card) , a communications port (such as for example, a universal serial bus (USB) port) , a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.
[0066]
In this document, the terms ‘computer program product’ , ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings) , when executed, enable the computing system to perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
[0067]
In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code) , when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.
[0068]
Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP) , or application-specific integrated circuit (ASIC) and/or any other sub-system element.
[0069]
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.
[0070]
Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.
[0071]
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.
[0072]
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.
[0073]
Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’ , ‘an’ , ‘first’ , ‘second’ , etc. do not preclude a plurality.
[0074]
Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ or “including” does not exclude the presence of other elements.

Claims

[Claim 1]
A method of transmitting PDCP PDUs from a first termination point to a second termination point via a wireless link, the method comprising the steps of operatingthe link in unacknowledged mode; submitting PDCP PDUs to the RLC layer; receiving an instruction to discard at least one PDCP PDU; and discarding RLC PDUs containing complete PDCP PDUs to be discarded, provided those RLC PDUs have not been submitted to a lower layer.
[Claim 2]
A method according to claim 1, further comprising the step of discarding RLC PDUs containing segments of PDCP PDUs indicated to be discarded.
[Claim 3]
A method of transmitting PDCP PDUs from a first termination point to a second termination point via a wireless link, the method comprising the steps of operatingthe link in acknowledged mode; submitting PDCP PDUs to the RLC layer; pre-processing RLC SDUs to form RLC PDUs, wherein each RLC PDU has a sequence number; receiving an instruction to discard at least one PDCP PDU; and discarding RLC PDUs containing complete PDCP PDUs to be discarded, provided the RLC PDU has not been submitted to a lower layer and is the latest PDCP PDU in the transmission window.
[Claim 4]
A method according to claim 3, further comprising repeating the step of discarding RLC PDUs after a first RLC PDU has been discarded, wherein the step is repeated until no more RLC PDUs can be discarded.
[Claim 5]
A method according to claim 3 or claim 4, further comprising the step of discarding RLC PDUs containing segments of PDCP PDUs tobe discarded, provided the RLC PDU has not been submitted to a lower layer and is the latest PDCP PDU in the transmission window.
[Claim 6]
A method of operating a wireless uplink connection comprising a plurality of links, wherein each link comprises a discrete RLC connection, the method comprising transmitting data via a first of the plurality of links from a UE to a network; switching the transmitting of data to a second link of the plurality of links; and performing the method of any of claims 1 to 5 on the first link during the switching process.
[Claim 7]
A method according to claim 6, wherein the switch is performed without re-establishment of RLC connections.
[Claim 8]
A method according to claim 6, wherein PDCP PDUs not yet acknowledged on the first link are transmitted on the second link.
[Claim 9]
A method according to claim 8, wherein the PDCP PDUs not yet acknowledged are transmitted on the second link before any new PDCP PDUs are transmitted.
[Claim 10]
A method according to claim 7, wherein any discarded PDCP PDUs are transmitted via the second link.

Drawings

[ Fig. 1]  
[ Fig. 2]  
[ Fig. 3]  
[ Fig. 4]