Abstract:
A method for determining an unacknowledged mode radio link control protocol data unit (PDU) size in a wireless transmit receive unit (WTRU) includes the WTRU setting a maximum PDU size, and the WTRU setting a maximum total data transferred size. The PDU size is flexible up to the maximum PDU size.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. provisional application Nos. 60/894,937 filed Mar. 15, 2007 which is incorporated by reference as if fully set forth 
     
    
     FIELD OF INVENTION 
       [0002]    The present invention is related to wireless communications. 
       BACKGROUND 
       [0003]    A goal of the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) program is to develop new technology, new architecture and new methods for settings and configurations in wireless communication systems in order to improve spectral efficiency, reduce latency and better utilize the radio resource to bring faster user experiences and richer applications and services to users with lower costs. 
         [0004]    The Radio Link Control Protocol (RLC) is a Level 2 (L2) protocol within 3GPP Universal Mobile Telephone Service (UMTS) systems that provides segmentation, retransmission, and flow control services for control and user data. The RLC can be configured to operate in Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). When configured in UM, there is no retransmission mechanism. Delivery of data is not guaranteed. UM does offer the following services and functions: segmentation and reassembly, concatenation, padding, transfer of user data, ciphering, sequence number check, service data unit (SDU) discard, out of sequence SDU delivery, and duplicate avoidance and reordering. The UM RLC is typically used for the transfer of time sensitive services such as Voice over Internet Protocol (VoIP) and multiple broadcast/multicast services (MBMS). 
         [0005]    An AM RLC supports flexible protocol data unit (PDU) sizes. The AM RLC is configured by higher layers to operate with a maximum, rather than a single, PDU size. Flexible PDU sizes may reduce the possibility of the RLC stalling at high data rates, where the RLC has been shown to be a throughput bottleneck. 
         [0006]    The AM RLC is configured to operate with a maximum PDU size rather than a fixed PDU size, and therefore should only segment SDUs that are larger than the maximum PDU size. RLC PDUs are segmented and/or concatenated at a medium access control (MAC) layer in a Node B where an ideal transport block size is selected based on instantaneous channel conditions. 
         [0007]    In existing UM operation, the RLC is configured by higher layers to create and deliver PDUs according to a set of fixed sizes. For each transmission time interval (TTI), the MAC layer decides which UM RLC PDU size shall be used and how many UM RLC PDUs shall be transmitted. The MAC layer selects the UM RLC PDU size from a finite list of PDU sizes, configured by higher layers. 
         [0008]    In order to deliver PDUs of a fixed size, the UM RLC concatenates the last segment of an RLC SDU with the first segment of the next RLC SDU in order to fill the data field completely. Alternatively, the RLC adds padding bits in order to fill the data field. 
         [0009]    The transfer of variable size RLC PDUs in UM is not supported. Flexible or variable PDU sizes for UM RLC would be beneficial for VoIP applications since VoIP packets are compressed at the packet data protocol control (PDPC) layer using the Robust Header Compressions (ROHC) algorithm, which generates different packet sizes from one TTI to another, depending on the compressor state. Flexible UM RLC PDUs would eliminate the overhead caused by padding. 
       SUMMARY 
       [0010]    A method and apparatus is disclosed to operate a UM RLC protocol with variable PDU sizes. This may include mechanisms to support flexible or variable PDU sizes. The PDUs may be measured in bits or octets. Parameters and primitives may be used by the RLC to communicate with other layers. The parameters and primitives may include information regarding PDU sizes, and may include PDU measurements in bytes or octets. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWING 
         [0011]    A more detailed understanding may be had from the following description, given by way of example and to be understood in conjunction with the accompanying drawing wherein: 
           [0012]      FIG. 1  shows an example of a wireless communication system in accordance with one embodiment; 
           [0013]      FIG. 2  shows a functional block diagram of a WTRU and a Node B of  FIG. 1 ; 
           [0014]      FIG. 3  is a functional block diagram of UM signal transmission in accordance with one embodiment; 
           [0015]      FIG. 4  shows a flow diagram for a transmission process of an RLC message in accordance with one embodiment; and 
           [0016]      FIG. 5  shows a flow diagram for a reception process of a RLC message in accordance with one embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0017]    When referred to hereafter, the term “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 term “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. 
         [0018]      FIG. 1  shows a wireless communication system  100  including a plurality of WTRUs  110  a Node B  120  and a Radio Network Controller (RNC)  130 . As shown in  FIG. 1 , the WTRUs  110  and the RNC  130  are in communication with the Node B  120 . Although three WTRUs  110  and one Node B  120  are shown in  FIG. 1 , it should be noted that any combination of wireless and wired devices may be included in the wireless communication system  100 . The WTRUs  110  each include a MAC  140  and an RLC  150 . The Node B  120  also includes a MAC  160  and the RNC  130  includes an RLC  170 . 
         [0019]      FIG. 2  is a functional block diagram  200  of the WTRU  110  and the Node B  120  of the wireless communication system  100  of  FIG. 1 . The WTRU  110  is in communication with the Node B  120  which includes a MAC  160 . The Node B  120  is in communication with an RNC  130  which includes a RLC  170 . The WTRU  110 , Node B  120  and RNC  130  are configured to function in AM, UM or TM. 
         [0020]    In addition to the components that may be found in a typical WTRU, the WTRU  110  includes a processor  215 , a receiver  216 , a transmitter  217 , and an antenna  218 . The processor  215 , receiver  216  and transmitter  217  are configured to operate in UM, AM and TM. The receiver  216  and the transmitter  217  are in communication with the processor  215 . The antenna  218  is in communication with both the receiver  216  and the transmitter  217  to facilitate the transmission and reception of wireless data. 
         [0021]    In addition to the components that may be found in a typical Node B, the Node B  120  includes a processor  225 , a receiver  226 , a transmitter  227 , and an antenna  228 . The processor  225 , the receiver  226  and the transmitter  227  are configured to function in AM, UM and TM. The receiver  226  and the transmitter  227  are in communication with the processor  225 . The antenna  228  is in communication with both the receiver  226  and the transmitter  227  to facilitate the transmission and reception of wireless data. 
         [0022]    A UM data transfer procedure may be used for transferring data between two RLC peer entities that are operating in UM. For each TTI, the MAC layer may determine a maximum amount of data that the UM RLC can deliver to lower layers for information transfer service. At least one of the following two parameters can be determined: 1) a maximum UM RLC PDU size that can be delivered; and 2) a maximum total of data transferred, measured in bits or in octets. The sum of all UM RLC PDU should be less than a maximum total of data transferred. Alternatively, a maximum UM RLC PDU size and a maximum number of PDUs to deliver may be defined. Alternatively, the parameters can be configured by higher layers (i.e., the RRC layer) upon establishment or reconfiguration of the radio bearer. The parameters can represent the amount of data that can be delivered during a predetermined time interval, such as a TTI or another indication, for example. 
         [0023]      FIG. 3  is a functional block diagram of UM signal transmission  300  in accordance with one embodiment. A transmit entity  302  can be a WTRU ( 110  of  FIG. 1 ) or a Node B ( 112  of  FIG. 2 ). The SDUs for transmission are passed through the UM-service access point (SAP) to a transmission buffer  306 . Each SDU is then sent to a segmentation and concatenation unit  308  where the SDUs are processed into RLC PDUs. If fixed size PDUs are used, the SDUs are reconfigured to match the fixed PDU size, which may require segmentation, concatenation, and the addition of padding bits. 
         [0024]    However, if flexible PDU sizes are supported, under certain circumstances, the SDU is segmented if it is larger than a maximum RLC PDU size. The maximum size may be configured by upper layers, such as the radio resource control (RRC), for example. Concatenation may be performed up to the maximum RLC PDU size. 
         [0025]    Alternatively, an upper layer such as the RRC, for example, sets an absolute maximum PDU size. For each TTI, the MAC layer sets a maximum PDU size that does not exceed the upper layer absolute maximum. The MAC may determine PDU size based on radio conditions that affect the amount of data that may be sent over the air interface and scheduling of data from various users, for example. Primitives passed between the RLC and MAC may be used to communicate the limits. 
         [0026]    An RLC header unit  310  adds an RLC header to each PDU. If fixed PDU sizes are used, the header may include a length indicator. However, if flexible PDU sizes are allowed, the length indicator may be configured by an upper layer. Once the RLC header is added, the PDU may be ciphered by a ciphering unit  312  prior to transmission. 
         [0027]    The receiver  301  may be a WTRU ( 110  of  FIG. 1 ) or a Node B ( 112  of  FIG. 2 ) or any other compatible wireless device. At the receiver  301  the ciphered PDU is deciphered in a deciphering unit  303 . The PDUs are then placed in a reception buffer  305  until a complete RLC SDU is received. The RLC header is removed at a header removal unit  307 , and the reassembly unit  309  reassembles the SDUs that are then sent to the upper layers through the RLC-SAP  311 . 
         [0028]      FIG. 4  shows a flow diagram for a transmission process for an RLC message. At step  402  an upper layer requests an UM transfer. The transmitter, at step  404 , checks if the SDU discard configuration is set. If yes, SDU discard will be based on a timer. If not, SDUs will be discarded if the buffer is full. At step  406  the SDUs are stored in a transmission buffer. At step  408 , the MAC schedules transmission and, at step  410 , the SDUs are segmented and concatenated to a PDU size indicated by the lower layer, if the PDU size is fixed. If the PDU size is flexible, the SDUs are processed such that each PDU does not exceed a maximum size. At step  412  the PDUs are sent to the MAC layer and, at step  414 , the state variable VT(US) is updated. Any remaining SDUs are buffered at step  416 . 
         [0029]      FIG. 5  shows a flow diagram for a reception process  500  for a RLC message. The receiving entity, at step  502 , receives a PDU. At step  504 , out-of-sequence processing is performed if out-of sequence processing is configured. If out of sequence processing is not configured, at step  506 , the receiving entity checks the sequence number of the received PDU against the VR(UM) state variable. If the sequence number is larger than the state variable, at step  508 , the PDU is discarded and the next PDU is received at step  502 . Otherwise, at step  510  the VR(UM) state variable is updated. The length indicator is checked at step  512 . Based on the value of the length indicator, at step  514  the PDUs are reassembled into SDUs. At step  516 , the SDUs are forwarded to the upper layers. 
         [0030]    When using flexible PDU sizes, sequence numbering may be performed on a per byte basis. The sequence number that is included in the RLC header may correspond to the sequence number of the first byte that is included in the payload. For fixed PDU sizes, sequence numbering is typically performed on a per PDU basis. The RLC protocol includes a number of parameters that are passed between RLC entities. These parameters include, but are not limited to: Configured_Rx_Window_Size, Configured_Tx_Window_Size, OSD_Window_Size, and DAR_Window_Size. These parameters can be configured by higher layers (i.e., the RRC layer) upon establishment or reconfiguration of the radio bearer and may represent the amount of data that can be delivered during a TTI, the amount of data that can be delivered during any other pre-determined time interval, or the amount of data that can be delivered until the next indication. 
         [0031]    Configured_Rx_Window_Size indicates the reception window size. This is a maximum amount of data that can be received in any single TTI, and is variable from TTI to TTI. Similarly, the Configured_Tx_Window_size parameter indicates a transmission window size, OSD_Window_Size indicates a size of the out-of-sequence SDU delivery storage window and the DAR_Window_Size indicates a size of the duplicate avoidance and reordering receive window. For fixed PDU sizes, these parameters are indicated in terms of number of PDUs. However, if flexible PDU sizes are used, these parameters may be indicated in number of bytes. 
         [0032]    Primitives are used as a basic or fundamental unit of instruction between a MAC entity and an RLC entity. MAC_DATA_XXX and MAC_STATUS_XXX are two primitives used in the RLC protocol, wherein XXX may be a Request, an Indication or a Response. 
         [0033]    The MAC-DATA-Indication primitive is used by the receiving MAC to indicate the reception of a UM RLC PDU. The primitive should include the PDU size, either measured in bits or in octets, of each UM RLC PDU that has been received. Alternatively, the total size or the sum of the sizes of individual UM RLC PDUs received can be indicated, measured in bits or octets. Alternatively, the size of the received transport block can be indicated. 
         [0034]    The MAC-STATUS-Indication primitive, which indicates to the UM RLC on the transmitting side for each logical channel the rate at which it may transfer data to MAC, should include the maximum number of bits or octets that can be delivered to the MAC for information transfer service. The maximum size (measured in bits or octets) parameter corresponds to the sum of all UM RLC PDUs that are delivered to the MAC, preferably per TTI. Alternatively, the maximum size parameter could be interpreted as the maximum amount of data that the UM RLC can deliver to the MAC over any other fixed period of time. Alternatively, the maximum size parameter can be interpreted as the amount of data that the UM RLC can deliver until the next time a maximum size is indicated using the MAC-STATUS-Indication primitive. 
         [0035]    The MAC-DATA-Request primitive, which is used to request that an upper layer PDU be sent using the procedures for the information transfer service, may include the size, either measured in bits or in octets, of each RLC PDU that is delivered to the MAC layer. 
         [0036]    Although the features and are described in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided 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). 
         [0037]    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. 
         [0038]    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.