The long term evolution (LTE) of the Third Generation Partnership Protocol (3GPP) has defined a user-plane protocol stack architecture as shown in
The services and functions of the RLC sublayer include:
transfer of upper layer protocol data units (PDUs) supporting acknowledged mode (AM) or unacknowledged mode (UM), transparent mode (TM) data transfer, concatenation, segmentation, reassembly, in sequence delivery (reordering), duplicate detection, and error correction through automatic repeat request (ARQ) (cyclic redundancy check (CRC) provided by the physical layer).
The RLC sublayer may also provide segmentation according to the size of the transport block (TB). For example, the RLC service data unit (SDU) is segmented into variable sized RLC PDUs (which do not include any padding), when an RLC SDU does not fit entirely into the TB. Hence, the RLC will segment and/or concatenate the RLC SDUs so that the resulting PDUs fit within the total size of RLC PDU(s) indicated by a lower layer at the particular transmission opportunity notified by the MAC sublayer.
The RLC sublayer may also perform re-segmentation of RLC PDUs prior to retransmission if a PDU that needs to be retransmitted does not fit entirely into the new TB used for such retransmission. The number of re-segmentations is not limited.
Additional RLC capabilities include: concatenation of SDUs for the same radio bearer, in-sequence delivery of upper layer PDUs except at handover (HO) in the uplink, duplicate detection, protocol error detection and recovery, flow control between evolved NodeB (eNB) and user equipment (UE), SDU discard and reset.
In evolved universal mobile telecommunication system (UMTS) radio access network (E-UTRAN) (or LTE), a new re-segmentation functionality is supported, along with traditional segmentation. Thus, re-segmentation and reassembly of RLC PDUs will be supported (at least for AM data transfer) in addition to segmentation and reassembly of RLC SDUs.
In segmentation, the RLC SDU is segmented into RLC PDUs. The RLC PDUs are identified via a Sequence Number (SN) that is assigned on a per-PDU basis, i.e. a PDU SN. The PDU SN is included in the RLC header (not shown in
In such re-segmentation, the RLC PDU is segmented into PDU segments (i.e. sub-segments). The term ‘sub-segments’ refers to PDU segments (i.e. to the result of PDU re-segmentation). A sub-segment will be identified via two parameters, as illustrated in
Segment Offset (SO): which indicates the (starting) position of the segment within the original PDU (e.g. in bytes)
Segment Length (SL): which indicates the length (size) of the segment (e.g. in bytes)
The Segment Offset (SO) field in the RLC header may directly indicate the SO in the RLC (or MAC) headers. Similarly, a Length Indicator (LI) field in the RLC header may directly indicate the SL. Alternatively, the Length Indications from the MAC layer (e.g. within the MAC header) may provide such information. A Re-segmentation flag in the RLC header may indicate the existence of a PDU segment.
SO and SL information in the various headers are used as inputs to the mechanisms described herein.
PDU re-segmentation can be applied multiple times (an unlimited number of times according to Release 8 of 3GPP).
In UTRAN (e.g. Release 6 or earlier), the detection of duplicate PDU segments is supported for AM RLC, and for UM RLC. In E-UTRAN (LTE), duplicate detection functionality is supported for AM RLC, and may also be supported for UM RLC.
The duplicate detection mechanisms employed in the earlier UTRAN releases, and specified in the current version of the E-UTRAN (LTE) RLC specification are based purely on performing a sequence number (SN) comparison between the received RLC PDU SN and the SN of packets stored in the reordering buffer. This approach worked because there was no re-segmentation.
Such duplicate detection techniques are not appropriate for E-UTRAN (LTE), since in E-UTRAN new functions such as re-segmentation will be employed. Therefore enhanced duplicate detection functionality is required for E-UTRAN, and for systems that support re-segmentation of RLC PDUs. Such an enhanced mechanism needs to be able to handle the impact of re-segmentation, and the possibility of receiving PDUs that have been re-segmented multiple times.
An RLC entity selectively stores part or parts of a received RLC PDU (or re-segmented PDU) in the RLC buffer and selectively discards other part(s) of the received PDU, rather than simply depending on the received RLC PDU SN for either discarding the entire received PDU or storing the entire received PDU in the RLC buffer.
A receiving RLC entity performs the following upon receiving an RLC PDU:
Alternatively, the receiving RLC entity performs the following upon receiving an RLC PDU:
The above embodiment can be performed in any function of the RLC entity in general, such as in the RLC duplicate detection function, or the RLC reassembly function, or the RLC reordering function, or any other function.
A more detailed understanding may be had from the following description of embodiments, given by way of example and to be understood in conjunction with the accompanying drawings wherein:
When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment.
When referred to hereafter, the terminology “duplicate detection” means the detection of duplicate data segments (for example, PDU segments) and may also be referred to as “duplicate avoidance” or “duplicate elimination”. The proposed duplicate detection functionality (e.g. its logic, or its steps) may be combined or performed in conjunction with other RLC functionalities such as the reordering functionality, or the reassembly functionality or the receive window functionality, or with any other functionality. A ‘Re-segmented PDU’, a ‘sub-segment’, or a ‘PDU Segment’ is the outcome of a PDU re-segmentation. When referred to hereafter, the terminology ‘buffer’ may be used interchangeably to mean a simple buffer, a ‘reassembly’ buffer or a ‘reordering’ buffer. When referred to hereafter, the terminology “new data” means data that does not “already exist” in the receiver's buffer. When referred to hereafter, the acronym “AMD” means “acknowledged mode data.” When referred to hereafter, the term packet refers to a PDU or a ‘PDU segment’. When referred to hereafter, the term “AMD PDU” refers to a (non re-segmented) PDU or to a ‘PDU Segment’. When referred to hereafter, the term “entire packet” refers to all data in the packet.
Unlike previous mechanisms that only utilized the PDU SN information, an enhanced RLC duplicate detection functionality may utilize any or all of the following information: Sequence Number (SN), Segment Offset (SO), and Segment Length (SL).
Determining whether some or all the data contained in the AMD PDU is already stored or exists (has been previously received) in the RLC buffer is done by utilizing SN, SO and SL information to determine (or compare or calculate) the relationship between the data received in the packet and the data stored in the RLC buffer (previously received data). Determining whether or not a received packet is a ‘Re-segmented PDU’ may be accomplished by checking a re-segmentation flag in the RLC header.
The receiving RLC entity will find the relationship by comparing the data ranges (boundaries) of the PDU parts that are stored in the buffer with the data range (e.g. SO and SL) communicated in the packet's header information (e.g. RLC or MAC headers).
Referring to
Compares the data range specified by SN, SO, and SL (if available) of the packet with the data ranges of a packet (or packets) already stored in the RLC buffer 535, which is a virtual entity contained in memory 530 to determine if the data contained in the packet exists in the RLC buffer (was previously received).
If all of the data contained in the packet already exists (i.e., it has been previously successfully received) in the RLC buffer 535, then the RLC entity 525 discards the received packet;
Depending on the (determined) relationship, the RLC entity performs one of the following:
Referring to
Case 2 (2-A or 2-B), illustrates the condition where all of the data contained in the received packet 440 has been previously received and stored in RLC buffer 430, the receiving RLC entity can either:
Case 3 (3-A, 3-B or 3-C) illustrates the situation where some (but not all) of the data contained in the received packet 470 has been previously received and stored in RLC buffer 460, the receiving RLC entity can either:
In Case 3-A (similarly in 3-B, 3-C), the receiving RLC entity's reassembly function (selectively) combines the received PDU Segment 470 with existing PDU Segments (462 and 464) that are already stored in the RLC buffer 460.
However, storing all of the received packet's data (i.e. overwriting existing segments 462 and 464) in the RLC buffer 460 is also a viable option, since this will achieve the same result.
In contrast to the current state of the art whereby the receiving RLC entity simply either discards the received PDU in entirety or stores the received PDU in entirety depending on the received RLC PDU SN, the RLC entity utilizing enhanced duplicate detection may selectively store a part or parts of a received PDU and selectively discard (i.e. does not store) other part or parts of the received PDU. In each embodiment described below, the receiving RLC entity (e.g. in the UE or in the eNB) will determine if any of the data in the received packet has been previously received (already exists in the RLC buffer) by determining, as described above, the relationship between the data received in the packet and the data stored in the RLC buffer (previously received data).
In one embodiment, a receiving RLC entity performs the following upon receiving an RLC PDU:
In another embodiment, a receiving RLC entity performs the following upon receiving an RLC PDU or an RLC PDU Segment:
In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity shall:
In other words, if all the data contained in the newly received AMD PDU already exists in the RLC buffer, the receiving side of the AM RLC entity will discard the AMD PDU.
In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
In this embodiment, the RLC receiver's operation is simplified by having it overwrite the data in the RLC buffer in all cases. Thus, the duplicate detection functionality may be eliminated from the RLC. In other words, the RLC will always store the received AMD PDU (i.e. overwrite the buffer with the data of the received AMD PDU) without performing duplicate detection.
In another embodiment, the AMD PDU is only stored in the RLC buffer (i.e. duplicate detection is not performed) if it is a re-segmented PDU. But when an AMD PDU is not a re-segmented PDU, duplicate detection is performed. This embodiment is described as follows:
When receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
Any of the above embodiments may be combined with the following:
One skilled in the art will recognize that the embodiments may be combined (integrated) with other functionalities, operations, or with other logic. For example, the embodiments may be performed in any function of the RLC entity in general, such as in the RLC duplicate detection function, or the RLC reassembly function, or the RLC reordering function, or any other function.
In order to limit the impact of re-segmentation on duplicate detection and reassembly operations, another embodiment relates to a restriction whereby a PDU or ‘PDU Segment’ can be re-segmented an additional time (i.e. for an additional level), but only if the resulting ‘PDU Segment’ is smaller or equal in size. A variant condition is that a RLC entity (e.g. in a device) will create and/or transmit a second PDU Segment (using data from an underlying PDU) only if all data to be included in the second PDU Segment is a subset (was fully included) within a first PDU Segment created and/or transmitted earlier. Another variant condition is that a RLC entity (e.g. in a device) will create and/or transmit a second PDU Segment (using data from an underlying PDU) only if the second PDU Segment is created using data from a first PDU Segment created and/or transmitted in the most recent round of PDU re-segmentation. Yet another variant condition is that a RLC entity (e.g. in a device) will create and/or transmit a second PDU Segment only if the second PDU Segment's SO is equal to or greater than a first PDU Segment's SO and the second PDU Segment's SL is equal to or less than the first PDU Segment's SL, wherein the first PDU Segment is any PDU Segment created and/or transmitted earlier. This restriction can prevent situations such as Case 3 in
Hence, the transmitting RLC entity performs an additional re-segmentation of a first ‘PDU Segment’ when the resulting subsequent ‘PDU Segment’ is (or can be) shorter (i.e. a sub-set) than the first ‘PDU Segment’.
Another possible restriction is that once a re-segmentation is applied on a given PDU, the ‘full’ PDU or ‘original’ PDU cannot be retransmitted again at a subsequent time.
As described above, removing the duplicate detection functionality from the RLC can simplify overall RLC operations. In another embodiment, simplification may be achieved, by integrating one or more of the aforementioned embodiments for duplicate detection, within other RLC functions. For example, the reassembly function may perform any of the duplicate detection embodiments.
Those skilled in the art will recognize that the previous embodiments are applicable to other data units capable of re-segmentation similar to a ‘PDU Segment’, where the term ‘PDU’ is defined to encompass any RLC output packet, including a ‘PDU Segment’. In this case, it may be necessary to determine if a received RLC PDU is or is not a sub-segment.
Those skilled in the art will recognize that the above embodiments are also applicable when duplicate detection is performed in conjunction with other functions, such as, for example, reassembly, reordering, or window operations.
Those skilled in the art will recognize that the above embodiments are applicable when there are changes or modifications to the RLC sub-layer's functionality, for example, if SDU re-segmentation is employed instead of PDU re-segmentation. The same concepts illustrated for PDU re-segmentation can be reused in the case of SDU re-segmentation (e.g. the SO will indicate the (starting) position of the segment within the original SDU (e.g. in bytes), and the SL will indicate the length of the segment (e.g. in bytes). Also, the embodiments may apply if a different mechanism is used for re-segmentation (other than the segment offset/length approach), for example, when it is possible to find/calculate SO and SL from the indicated segmentation information.
The above embodiments are applicable even if additional functionalities are added to the RLC sub-layer or if they are used in another RLC mode, such as UM (unacknowledged mode), in addition to the AM RLC mode. While the above embodiments are described in terms of RLC PDUs (or RLC packets) and specifically AMD PDUs (or AMD packets) they are equally applicable to other types of RLC PDUs such as UM PDUs (or UM packets).
Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. The methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.
A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) module.
This application claims the benefit of U.S. Provisional Application Ser. No. 60/976,632 filed on Oct. 1, 2007, which is incorporated by reference as if fully set forth.
Number | Date | Country | |
---|---|---|---|
60976632 | Oct 2007 | US |