Abstract:
A radio link control (RLC) entity selectively stores part or parts of a received protocol data unit (PDU) or re-segmented PDU and selectively discards other parts of the received PDU, rather than simply either discarding the whole received PDU or storing the whole received PDU. The receiving RLC entity performs duplicate detection of received data as compared to data in an RLC buffer, selects the parts of the received PDU that will be discarded (if data is duplicated), discards the selected parts of the PDU, and stores the remaining parts of the PDU. Alternatively, data can be stored regardless of duplicate detection, and the buffer data is overwritten by the stored data.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    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. 
     
    
     BACKGROUND 
       [0002]    The long term evolution (LTE) of the Third Generation Partnership Protocol (3GPP) has defined a user-plane protocol stack architecture as shown in  FIG. 1 , which includes the Layer 2 (L2) sub layers: packet data convergence protocol (PDCP), radio link control (RLC) and medium access control (MAC). 
         [0003]    The services and functions of the RLC sublayer include: 
         [0000]    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). 
         [0004]    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. 
         [0005]    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. 
         [0006]    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. 
         [0007]    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. 
         [0008]      FIG. 2  illustrates the processes of segmentation and re-segmentation in E-UTRAN (LTE). 
         [0009]    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  FIG. 2 ). Segmentation of an SDU into PDUs may be done once (an SDU cannot be re-segmented again). Re-segmentation can be performed on RLC PDUs. 
         [0010]    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  FIG. 2 : 
         [0011]    Segment Offset (SO): which indicates the (starting) position of the segment within the original PDU (e.g. in bytes) 
         [0012]    Segment Length (SL): which indicates the length (size) of the segment (e.g. in bytes) 
         [0013]    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. 
         [0014]    SO and SL information in the various headers are used as inputs to the mechanisms described herein. 
         [0015]    PDU re-segmentation can be applied multiple times (an unlimited number of times according to Release 8 of 3GPP).  FIG. 3  illustrates an example of re-segmentation that is applied two times (or two levels). The left side of  FIG. 3  illustrates that the 2nd sub-segment is larger than the 1st sub-segment; this might occur when the transport block (TB) size selected by lower layer is larger than the size of the PDU segment (i.e. the 1st sub-segment) that needs to be retransmitted. The right side of  FIG. 3  illustrates that the 2nd sub-segment is smaller than the 1st sub-segment; this might occur for example when the transport block (TB) size selected by lower layer is smaller than the size of the PDU segment (i.e. the 1st sub-segment) that needs to be retransmitted. 
         [0016]    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. 
         [0017]    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. 
         [0018]    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. 
       SUMMARY 
       [0019]    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. 
         [0020]    A receiving RLC entity performs the following upon receiving an RLC PDU:
       Selects the parts of the received PDU that will be discarded; Discards the selected parts of the PDU, and stores the remaining (other) parts of the PDU in the RLC buffer;       
 
         [0022]    Alternatively, the receiving RLC entity performs the following upon receiving an RLC PDU:
       Selects the parts of the received PDU that will be stored in the RLC buffer);   Stores the selected parts of the PDU in the RLC buffer, and discards the remaining (other) parts of the PDU       
 
         [0025]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0026]    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: 
           [0027]      FIG. 1  shows an LTE user-plane protocol stack; 
           [0028]      FIG. 2  is an illustration of segmentation and re-segmentation in LTE; 
           [0029]      FIG. 3  is an illustration of applying re-segmentation more than one time on a particular PDU; and 
           [0030]      FIG. 4  is an illustration of various cases that can arise due to re-segmentation. 
           [0031]      FIG. 5  shows an embodiment of a WTRU and its relevant components. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0032]    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. 
         [0033]    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&#39;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. 
         [0034]    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). 
         [0035]    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. 
         [0036]    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&#39;s header information (e.g. RLC or MAC headers). 
         [0037]    Referring to  FIG. 5 , upon reception of a packet (e.g. PDU or PDU segment) by the receiver  510 , the receiving RLC entity  525 , which is a virtual entity logically contained in and executed by the processor  520  (shown in a WTRU, but is also present in an eNB) performs the following: 
         [0038]    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). 
         [0039]    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;
       Else if some data contained in the packet does not exist (i.e., it is new data because it was not previously successfully received) in the RLC buffer  535 ;
           then the RLC entity  525  only discards the data part that already exists in the RLC buffer  535  (i.e. RLC entity  525  stores new data in the RLC buffer  535 ).   
               
 
         [0042]      FIG. 4  illustrates various situations/cases that can arise along with the relationships between the received packet (e.g. RLC PDU or PDU segment) and the data stored in the RLC buffer (previously received data). The receiving RLC entity (e.g. in the WTRU or in the eNB) will determine if any of the data in the received packet has been previously received 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). 
         [0043]    Depending on the (determined) relationship, the RLC entity performs one of the following:
       Stores all the data in the received packet in the RLC buffer;   Discards all the data in the received packet;   Stores some of the data in the received packet in the RLC buffer, and discards the rest of the data (or vice versa, i.e. discards some, and stores the rest).       
 
         [0047]    Referring to  FIG. 4 , Case  1  exemplifies the condition where the RLC buffer  410  has not previously received (and stored) any of the data contained in the received packet  420 , the receiving RLC entity will store (i.e. will not discard) the data contained in the new packet  420  in the RLC buffer  410 . 
         [0048]    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:
       Discard the received packet  440 , or   Store (overwrite) all of the received packet&#39;s data into the RLC buffer  430 .       
 
         [0051]    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:
       Store the received packet&#39;s data that is not already stored in the RLC buffer  460  and discard the rest of the received packet&#39;s data, or   Store (overwrite) all of the received packet&#39;s data in the RLC buffer  460 .       
 
         [0054]    In Case  3 -A (similarly in  3 -B,  3 -C), the receiving RLC entity&#39;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 . 
         [0055]    However, storing all of the received packet&#39;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. 
         [0056]    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). 
         [0057]    In one embodiment, a receiving RLC entity performs the following upon receiving an RLC PDU:
       Selects 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) the parts of the received PDU that will be discarded; and
           Discards the selected parts of the PDU, and stores the remaining (other) parts of the PDU in the RLC buffer.   
               
 
         [0060]    In another embodiment, a receiving RLC entity performs the following upon receiving an RLC PDU or an RLC PDU Segment:
       Selects 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) the parts of the received PDU that will be stored in the RLC buffer (those parts that have not been previously received); and   Stores the selected parts of the PDU in the RLC buffer, and discards the remaining (other) parts of the PDU (those parts that were previously received).       
 
         [0063]    In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
       If an AMD PDU with the same SN already exists in the RLC buffer (some or all of the data has been previously received and stored):
           Then if all the data contained in the received AMD PDU already exists in the RLC buffer:
               Discard the received AMD PDU;   
               Else (i.e. if some data contained in the received AMD PDU does not exist in the RLC buffer):
               Discard only the received AMD PDU data that already exists in the RLC buffer (i.e. store the new data in the RLC buffer).   
               
               
 
         [0069]    In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity shall:
       If an AMD PDU with the same SN already has data in the RLC buffer:
           If all the data contained in the received AMD PDU already exists in the RLC buffer:
               Discard the received AMD PDU;   
               Else (i.e. if some data contained in the received AMD PDU does not exist in the RLC buffer):
               Store the received AMD PDU (i.e. over-write the RLC buffer with the data of the received AMD PDU).   
               
               
 
         [0075]    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. 
         [0076]    In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
       If an AMD PDU with the same SN already exists in the RLC buffer:
           Store the received AMD PDU (i.e. overwrite the buffer with the data of the received AMD PDU).   
               
 
         [0079]    In this embodiment, the RLC receiver&#39;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. 
         [0080]    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: 
         [0081]    When receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
       If an AMD PDU with the same SN already has data in the RLC buffer:
           If the received AMD PDU is not a re-segmented PDU:
               If the entire AMD PDU already exists in the buffer;
                   Discard the received AMD PDU;   
                   
               Else (i.e. if the received AMD PDU is a re-segmented PDU):
               Store the received AMD PDU (i.e. over-write the RLC buffer with the data of the received AMD PDU).   
               
               
 
         [0088]    In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
       If an AMD PDU with the same SN already has data in the RLC buffer:
           If the received AMD PDU is not a re-segmented PDU:
               If all of the AMD PDU&#39;s data is already stored in the RLC buffer);
                   Discard the received AMD PDU   
                   
               Else if the received AMD PDU is a re-segmented PDU:
               If all the data contained in the re-segmented PDU is already stored in the RLC buffer:
                   Discard the received AMD PDU;   
                   Else if some data contained in the re-segmented PDU does not exist in the RLC buffer:
                   Discard only the AMD PDU data that already exists in the RLC buffer (i.e. store the new data).   
                   
               
               
 
         [0098]    In another embodiment, when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs as follows:
       If an AMD PDU with the same SN already has data in the RLC buffer:
           Discard only the received AMD PDU data that is already stored in the RLC buffer (i.e. store the new data).   
               
 
         [0101]    Any of the above embodiments may be combined with the following:
       when receiving an AMD PDU from a lower layer, the receiving side of an AM RLC entity performs the following:
           If an AMD PDU with the same SN has not been received before:
               Store the received AMD PDU.   
               
               
 
         [0105]    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. 
         [0106]    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&#39;s SO is equal to or greater than a first PDU Segment&#39;s SO and the second PDU Segment&#39;s SL is equal to or less than the first PDU Segment&#39;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  FIG. 4  from arising, and can simplify aspects such as receive buffer operations, duplicate detection, reassembly, and reordering. 
         [0107]    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’. 
         [0108]    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. 
         [0109]    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. 
         [0110]    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. 
         [0111]    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. 
         [0112]    Those skilled in the art will recognize that the above embodiments are applicable when there are changes or modifications to the RLC sub-layer&#39;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. 
         [0113]    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). 
         [0114]    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). 
         [0115]    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. 
         [0116]    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.