HK1139254A - Acknowledged mode radio link control architecture and method within evolved hspa systems - Google Patents

Description

Architecture and method for acknowledged mode radio link control within evolved HSPA systems

Technical Field

The present application relates to wireless communications.

Background

Within the 3GPP Universal Mobile Telecommunications System (UMTS), the Radio Link Control (RLC) protocol is a layer two (L2) protocol that provides segmentation, retransmission, and flow control services for control and user data. The RLC may be configured to operate in a transparent mode, an Unacknowledged Mode (UM), and an Acknowledged Mode (AM). The functions of the TM RLC include user data transfer and segmentation and reassembly functions. The functions of the UM RLC include user data transfer, segmentation and reassembly functions, and ciphering and sequencing. The AMRLC provides reliability through retransmission. The functions of the AM RLC include user data transfer, segmentation and reassembly functions, error correction, repetition detection, protocol error detection and recovery, and ciphering. The AM RLC includes an automatic repeat request (ARQ) function that provides error correction for services requiring higher transmission reliability, such as a packet-switched data service. A detailed block diagram of a typical AM RLC architecture is shown in fig. 1.

Recently, enhancements to AM RLC have been proposed as part of the 3GPP release 7 standardization work. As an enhancement to the 3GPP release 6 standard, flexible Protocol Data Unit (PDU) sizes have been introduced for AM RLC, which is configured by higher layers to operate in conjunction with individual PDU sizes. Doing so is expected to reduce the likelihood that the RLC will stay at the high data rate, in which case the RLC will present a throughput bottleneck.

The improved AM RLC is configured to operate in conjunction with a maximum PDU size rather than a fixed PDU size, whereby a segmentation process should be performed only for Service Data Units (SDUs) larger than the maximum PDU size. In the downlink, RLC PDUs are then segmented and/or concatenated at the new enhanced high speed medium access control (MAC-ehs) layer in the node-B, where the ideal transport block size is selected based on the instantaneous channel conditions.

As shown in prior art in fig. 1, the existing 3GPP release 6AM RLC architecture delivers fixed-length PDUs to lower layers for transmission over the air interface. The fixed PDU size is a semi-static parameter configured by higher layers. In order to modify the fixed PDU size, an RLC re-establishment procedure must be performed, which results in SDU loss.

In the case of a flexible AM RLC PDU size, the transmitting RLC can deliver the flexible sized PDU as long as the flexible sized PDU is configured to be within the limits imposed by the maximum AM RLC PDU size. The maximum RLC PDU size should be reconfigured without any additional impact of S such as DU loss or delay. The existing AM RLC mode does not provide sufficient support for seamless reconfiguration of the maximum RLC PDU size. In addition, other basic RLC procedures as well as lower layer interfaces should be optimized in view of the introduction of flexible PDU sizes.

Disclosure of Invention

An Acknowledged Mode (AM) Radio Link Control (RLC) architecture and method within evolved High Speed Packet Access (HSPA) is disclosed. In particular, an AM RLC architecture and method is disclosed in which RLC SDUs are segmented and/or concatenated at the time of or immediately prior to delivery of PDUs to lower layers. The architecture includes an interface with lower layers to support flexible PDU sizes for the am rlc.

Drawings

The invention will be understood in more detail from the following description of preferred embodiments, given by way of example and understood in conjunction with the accompanying drawings, in which:

fig. 1 is an exemplary block diagram of an AM RLC in the prior art;

FIG. 2 is an exemplary block diagram of an AM RLC architecture in accordance with one embodiment;

FIG. 3 is an exemplary block diagram of an AM RLC architecture in accordance with an alternative embodiment;

FIG. 4 is an exemplary block diagram of an AM RLC architecture in accordance with an alternative embodiment;

fig. 5 is a flowchart of an AM RLC method performed at a transmitting end; and

fig. 6 is a flowchart of an AM RLC method performed at a receiving end.

Detailed Description

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 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 interfacing device capable of operating in a wireless environment.

According to one particular embodiment, a new Acknowledged Mode (AM) Radio Link Control (RLC) architecture that supports creation of flexible Protocol Data Unit (PDU) sizes is disclosed. In particular, RLC Service Data Units (SDUs) are segmented and/or concatenated immediately only at the time of or before delivery of the PDUs to lower layers. Other new AM RLC procedures and new interfaces with lower layers are included to provide sufficient support for flexible PDU size generation for AM RLC. Although the following procedures relate to Downlink (DL) operation of the AM RLC, the concepts are equally applicable to Uplink (UL) operation of the AM RLC. The following description assumes that the RLC has enough data to create a full size PDU, i.e., the full size is the size requested by lower layers or the maximum size determined by the Radio Resource Control (RRC) layer. The RLC may contain only a small amount of buffered data, in which case it will create a PDU that is smaller than the requested size or smaller than the maximum size.

Fig. 2 is a block diagram of an AM RLC entity 200 according to a specific embodiment. The AM RLC entity 200 includes a transmitting end 215 and a receiving end 217. In fig. 2, one logical channel 205 (shown as a solid line) and two logical channels 210a and 210b (shown as dashed lines) are shown.

The transmitting end 215 of the AM RLC entity 200 receives the RLC SDU from the upper layer 202 through an acknowledged mode service access point (AM SAP)220, and the transmitting end 215 includes a transmission buffer 225, a retransmission and buffer management unit 230, a multiplexer 235(MUX), a field setting unit 237 for setting a field in the PDU header (for example, setting a polling bit) and a field in the piggybacked STATUS PDU, an encryption unit 238, a segmentation/concatenation unit 240, and an RLC header addition unit 245. The receiving end 217 of the AM RLC entity 200 receives AMD and control PDUs from lower layers through configured logical channels, i.e., one logical channel 205 (shown as a solid line) and two logical channels 210a and 210b (shown as dotted lines). The receiving end 217 includes a demultiplexing/routing unit 242, a decryption unit 244, a receive buffer and retransmission management unit 246, an RLC header removal and piggyback information extraction unit 248, and a reassembly unit 249. The RLC control unit 250 manages communication between the transmitting end 215 and the receiving end 217.

If a flexible PDU size is configured, the RLC SDUs are buffered in the transmit buffer 225. If a fixed RLC PDU size is configured, the RLC SDUs are segmented and/or concatenated into Acknowledged Mode Data (AMD) PDUs having a fixed length. If the received RLC SDU is larger than the length of the available space in the AMDPDU, segmentation is performed. The AMD PDU size may be a semi-static value configured by upper layers and may be changed by the upper layers by re-establishing an AM RLC entity.

If a flexible RLC PDU size is configured, one or more RLC SDUs are removed from the transmit buffer 225 before creating one or more PDUs requested by lower layers. If the SDU is larger than the maximum RLC PDU size configured by an upper layer, the RLC SDU is segmented. Concatenation may be performed up to the maximum rlc pdu size. The maximum RLC PDU size is a semi-static variable configured by upper layers in the transmitting end 215. The flexible RLC PDU size may be configured in uplink or downlink. Alternatively, if the SDU is larger than the maximum RLC PDU size requested by the lower layer (MAC sublayer), the RLC SDU can be segmented. The maximum RLC PDU size requested by the lower layer should be smaller than the maximum RLC PDU size configured by the upper layer.

The AMD PDU may contain segmented and/or concatenated RLC SDUs. AMD SDUs may also contain padding (padding) to ensure that they are of a valid size. If the fixed RLC PDU size is configured, the effective size will correspond to the configured fixed RLC PDU size. If a flexible RLC PDU size is configured, the effective size will correspond to an octet aligned (octet align) RLC PDU size. For example, if there are only 317 bits of data available, 3 padding bits are added to make the RLC PDU octet-aligned. The padding may also be applied in this scheme when the upper layer specifies a minimum RLC PDU payload size. If a fixed RLC PDU size is configured, a length indicator may be used to define the boundary between RLC SDUs inside an AMD PDU. The length indicator may also be used to define whether a padding or piggybacked STATUS PDU is included in the AMD PDU. When a STATUS PDU is created and there is sufficient free space available in the RLC PDU that is transmitted at the time, the piggybacked STATUS PDU will be included. If the RLC does not have enough data to fit the requested PDU size or the maximum PDU size, a STATUS PDU will be added. The length indicator size may be configured by the upper layer 202 if the flexible RLC PDU size is configured.

After fragmentation and/or concatenation is performed, the AMD PDU can be placed into a retransmission buffer 230 and a Multiplexer (MUX) 235. In addition, separate buffers (not shown) may also be reserved for new and retransmitted PDUs.

AMD PDUs buffered in the retransmission buffer 230 are either deleted or retransmitted based on STATUS reports found in STATUS PDUs or piggybacked STATUS PDUs sent by peer AM RLC entities. The status report may contain a positive or negative acknowledgement of the individual AMDPDUs received by the peer AM RLC entity.

A Multiplexer (MUX)235 multiplexes AMD PDUs from the retransmission buffer 230. The multiplexed AMD PDU may be retransmitted and the newly generated AMD dpdu delivered from the segmentation/concatenation function 240.

These PDUs are passed to the RLC header addition unit 245 to complete the AMD PDU header and preferably replace padding with piggybacked status information. The piggybacked STATUS PDU may have a variable size in order to match the amount of free space in the AMD PDU. The AMD PDU header is done based on input from the RLC control unit 50 indicating values set in different fields, such as a poll bit. The function may multiplex the control PDUs received from the RLC control unit 250, such as RESET and RESET ACK PDUs, and the control PDUs received from the reception buffer, such as piggybacked STATUS and STATUS PDUs, with AMD PDUs.

Ciphering may be applied to the AMD PDU. The AMD PDU header is unencrypted. The piggybacked STATUS PDU and padding in the AMD PDU may be encrypted. Control PDUs such as status PDUs, RESET PDUs, and RESET ACK PDUs are unencrypted.

The transmitting end of the AM RLC entity 215 submits the AMD PDU to the lower layers over one or two Dedicated Control Channels (DCCHs) or Dedicated Traffic Channels (DTCHs).

RLC SDUs should remain intact in the transmit buffer for as long as possible until the RLC can deliver the PDUs to lower layers for transmission. The existing SDU discard procedure described in the existing system can be applied to the SDU delivery buffer where RLC SDUs can be discarded when the RLC PDU (containing the SDU or SDU fragment) exceeds the maximum number of retransmissions or when the SDU discard timer expires. In particular, for the latter case, a timer _ discard is started for each SDU received from a higher layer. This controls the maximum RLC SDU delay.

Preferably, the Medium Access Control (MAC) sublayer should decide how many bytes will be transmitted through the AM RLC at each Transmission Time Interval (TTI). The interface between the AM RLC and lower layers will be discussed hereinafter.

Fig. 3 is an alternative embodiment of an AM RLC architecture 300. The AM RLC entity 300 includes a transmitting terminal 315 and a receiving terminal 317. One logical channel 305 (shown as a solid line) and two logical channels 310a and 310b (shown as dashed lines) are shown in fig. 3.

The transmitting end 315 of the AM RLC entity 300 receives the RLC SDU from the upper layer 302 through an acknowledged mode service access point (AM SAP)320, and the transmitting end 315 includes a transmission buffer 325, a retransmission and buffer management unit 330, a multiplexer 335(MUX), a field setting unit 337 for setting fields in the PDU header (e.g., setting a polling bit) and fields in the piggybacked STATUS PDU, an encryption unit 338, a segmentation/concatenation unit 340, and an RLC header addition unit 345. The receiving end 317 of the AM RLC entity 300 receives AMD and control PDUs through configured logical channels, i.e., one logical channel 305 (shown as a solid line) and two logical channels 310a and 310b (shown as dotted lines), from a lower layer. The receiving side 317 includes a demultiplexing/routing unit 342, a decryption unit 344, a reception buffer and retransmission management unit 346, an RLC header removal and piggyback information extraction unit 348, and a reassembly unit 349. In this alternative embodiment, a transmit buffer 312 may be included after the MUX 335 at the transmitting end 315, and the RLC PDUs may be temporarily stored in the transmit buffer 312 before setting the fields in the header, ciphering, and delivery to lower layers. The RLC control unit 350 manages functions between the transmitting side 315 and the receiving side 317.

Fig. 4 is an alternative embodiment of an AM RLC architecture 400. The AM RLC entity 400 includes a transmitting end 415 and a receiving end 417. In fig. 4, a logical channel 405 (shown as a solid line) and two logical channels 410a and 410b (shown as dashed lines) are shown.

The transmitting end 415 of the AM RLC entity 400 receives RLC SDUs from the upper layer 402 through an Acknowledged Mode Service Access Point (AMSAP)420, and the transmitting end 415 includes a transmission buffer 425, a retransmission and buffer management unit 430, a multiplexer 335(MUX), a field setting unit 437 for setting fields in a PDU header (e.g., setting a polling bit) and fields in a piggybacked STATUS PDU, an encryption unit 438, a segmentation/concatenation unit 440, and an RLC header addition unit 445. The receiving end 417 of the AM RLC entity 400 receives AMD and control PDUs through configured logical channels, i.e., one logical channel 405 (shown as a solid line) and two logical channels 410a and 410b (shown as dotted lines), from a lower layer. The receiving end 417 includes a demultiplexing/routing unit 442, a decryption unit 444, a receiving buffer and retransmission management unit 446, an RLC header removal and piggyback information extraction unit 448, and a reassembly unit 449. In this alternative embodiment, a segmentation buffer 443 is included in the segmentation/concatenation unit 440. The RLC control unit 450 manages functions between the transmitting end 415 and the receiving end 417.

Fig. 5 is a flow diagram of an AM RLC process 500 executed on the transmitting end 215 of the AM RLC entity of fig. 2. At 510, the transmitting end 215 of the AM RLC entity 200 receives RLC SDUs from an upper layer through an AM service access point 220 (SAP). If a flexible PDU size is configured, 520, the RLC SDU is buffered in the transmission buffer 225, 530. Subsequently, at 540, N PDUs of size X are requested. Alternatively, the maximum RLC PDU size may be requested by lower layers, or the maximum number of bits may be requested by lower layers. Next, at 550, the RLC SDUs are removed from the transmit buffer 225. Finally, at 560, a PDU is created.

If a fixed RLC SDU size is configured 520, the RLC SDU is segmented and/or concatenated by the segmentation/concatenation unit 240 into acknowledged mode data AMD PDUs having a fixed length and stored in the transmit buffer 225 570. Segmentation is performed if the received RLC SDU is larger than the available space length in the AMD PDU.

Fig. 6 is a flow chart of an AM RLC method 600 performed at the receiving end. When receiving an RLC PDU, if a "fixed RLC PDU size" is configured, the receiving end of the AM RLC can only discard or ignore PDUs having a size different from the configured "downlink AMD PDU size". Further, if the 'flexible RLC PDU size' is configured, all PDUs with valid headers are processed by the reception end 217.

At 610, the receiving end 217 of the AM RLC entity 200 of fig. 2 receives AMD and control PDUs from the lower layer through the configured logical channel. At 620, if a variable PDU size is configured, at 660, the received AMD PDU is processed.

At 620, if a fixed RLC PDU size is configured, at 630, a determination is made as to whether the fixed PDU size is configured by higher layers. If the fixed PDU size is configured by higher layers, at 640, it is determined whether the PDUs have different sizes. If the PDUs have different sizes at 640, the PDUs having different sizes are discarded at 650. At 640, if the PDUs have the same size, then at 660, the received AMD PDU is processed.

At 630, if the fixed PDU size is not configured by higher layers, at 670, the AMD PDU size is determined based on the first PDU received. Next, at 680, a determination is made to check whether the PDUs have different sizes. If, at 680, the PDUs are determined to have different sizes, then, at 690, the PDUs having different sizes are discarded.

The maximum AM RLC PDU size is configured by higher layers. The maximum AM RLC PDU size should be dynamically reconfigured without any data corruption or loss.

When the RLC instructs the higher layer to change the maximum RLC PDU size, for all retransmitted RLC PDUs, the RLC ignores the new maximum PDU size and retransmits the PDU containing the same payload unit as the first transmission. Further, for all other RLC PDUs for the information delivery service that have not yet been delivered or delivered to lower layers, the RLC may extract the SDUs and/or SDU segments contained in the PDU and recreate a new RLC PDU according to the new maximum RLC PDU size. Alternatively, the AM RLC may ignore the new maximum PDU payload size and keep the existing RLC PDUs already constructed.

For unprocessed RLC SDUs stored in the transmit buffer 225, the RLC will use the new maximum RLC PDU size to segment and/or concatenate the SDUs prior to the segmentation/concatenation function 240.

The existing interface between the RLC and MAC sublayers is defined in existing systems. The existing MAC primitive for AM RLC indicates to the RLC entity the number of PDUs that the MAC requests to be transmitted at a specified time. Since only one fixed size is available, the MAC only requests a plurality of PDUs having a configured size. Preferably, the primitive is modified. The MAC-DATA-Indication primitive used by the receiving MAC to indicate RLC PDU reception should include the PDU size measured in bits or octets of each RLC PDU received. Alternatively, the overall size or sum of sizes of the received individual RLC PDUs may be indicated and measured in bits or octets. In another alternative, the size of the received transport block may be indicated.

The MAC-STATUS-Indication primitive indicates to the RLC on the transmitting end 215 the rate at which data is to be transmitted to the MAC on each logical channel, and should include the maximum number of bits or octets that can be passed to the MAC for the information transfer service. The maximum size parameter measured in bits or octets corresponds to the sum of all RLC PDUs delivered to the MAC, preferably over each transmission time interval. Alternatively, the maximum size parameter may be interpreted as the maximum amount of data that the RLC can deliver to the MAC during any other fixed period of time. In another alternative, the maximum size parameter may be interpreted as the amount of data that the RLC can deliver before the next time the maximum size is indicated using the MAC-STATUS-Indication primitive. Alternatively, the MAC layer may also request N PDUs of size X from the RLC, in which case the parameters N and X would be included in the MAC-STATUS-Indication primitive. The MAC layer may determine the amount of data requested from the RLC based on the amount of data that may be transmitted or expected to be transmitted in the next TTI or a subsequent TTI. The amount of data that may be transmitted over the air interface in a Transmission Time Interval (TTI) depends on the radio channel conditions and the scheduling process between different WTRUs.

Once setting, adding or reconfiguring an RLC instance is initiated, the MAC-hs should configure accordingly. The MAC-hs is configured by higher layers, especially the Radio Resource Controller (RRC). RRC procedures involving the configuration or reconfiguration of MAC-hs queues and MAC-d flows are described in existing systems. However, the process needs to be modified.

The modification depends on the mapping of the MAC-d flows and logical channels. An alternative is a one-to-one mapping between logical channels and MAC-d flows. Another alternative is the multiplexing of logical channels in one MAC-d flow, where the LCH-ID is provided by the Iub frame protocol.

The procedure may also rely on optimization of the MAC header to support both flexible and fixed RLC PDUs. MAC header optimization provides the ability for MAC to handle both fixed and flexible RLC PDUs. This means that the MAC header information is changed based on the logical channel. If the PDU size is variable, a length indicator "LI" is provided for SDUs belonging to the logical channel. Alternatively, if the PDU size is fixed, size indicators "SID" and "N" may be provided, where N is the number of PDUs contained in the MAC of the specified size indicated by the SID field.

In an alternative embodiment, all logical channels are mapped one-to-one with the MAC-d flows. Furthermore, MAC header optimization is not supported. This means that all MAC SDUs will be processed in the same way, whether the RLC configuration is fixed or variable.

Currently, up to eight (8) MAC-d flows are allowed for downlink. Up to 16 logical channels are available. Thus, the number of DL MAC-d flows needs to be increased to 16.

Furthermore, conventional MAC-hs allows mapping MAC-d flows to more than one queue. However, a MAC-hs queue can only have one MAC-d mapped to it. The MAC-hs queue preferably allows mapping of more than one MAC-d flow by increasing the number of MAC-d flows to 16.

The Radio Resource Control (RRC) procedure corresponding to the radio bearer and used to configure the MAC-d flow to the MAC-ehs should also be modified. An Information Element (IE) for supporting up to 16 identified MAC-d flow identifications is included. The IE "RB mapping information" should also be modified to support mapping of logical channels to one of the 16 MAC-d flows. The IE "added or reconfigured MAC-d flows", including operations associated therewith, should be modified to support mapping of different MAC-d flows to a priority queue.

A new MAC-d flow identification information element is included. The MAC-d flow identification is a DL enhanced MAC-d flow identification. The definition of this IE is shown in table 1 below.

TABLE 1

Information element/group name	Need to make sure that	A plurality of	Type and reference	Semantic description
					DL MAC-d flow identification	MP		Integer (0 to 15)

When configuring or reconfiguring a radio bearer, the logical channel associated with the radio bearer is mapped to the correct MAC-d flow identification. In systems that do not support flexible RLC PDUs and enhanced MAC-ehs, the logical channel may be mapped to one of 8 MAC-d flows, however, for systems that support flexible RLC PDUs and enhanced MAC-ehs, the logical channel is preferably mapped to one of the new 16 MAC-d flows. This should be reflected in the IE "RB mapping information".

Preferably, the mapping selection is based on MAC-hs configuration (normal or enhanced) or DL RLC configuration (normal or enhanced). The definition of the RB mapping information IE is shown in table 2 below.

TABLE 2

This IE is extended to support both normal and enhanced MAC-hs configurations. The MAC-hs sets the MAC-hs queue accordingly, based on normal or enhanced configuration.

For enhanced MAC-hs, more than one MAC-d may be mapped to a MAC-ehs queue. Thus, to support more than one MAC-d flow, the IE should be extended to provide a list of MAC-d flows to be added or reconfigured to the queue. In this IE, MAC-d identifies that up to 16 MAC-d flows should be supported. The SID and N field configuration (i.e., MAC-d PDU size information, MAC-d PDU size, and index) is provided only for conventional MAC-hs. Since the field is optional, the RRC can ensure that this information is not provided when the MAC-hs configuration is set to normal. The fields may be placed in the IE as a sub-part of the regular MAC-hs configuration choice. The RRC procedure corresponding to the operation when the "added or reconfigured MAC-d flow" is received may be modified so that only the field is checked if the MAC-hs configuration is set to normal. The definition of the IE "added or reconfigured MAC-d flow" is shown in table 3 below.

TABLE 3

Information element/group name	Need to make sure that	A plurality of	Type and reference	Semantic description
					MAC-hs queue addition or reconfiguration list	OP	<1 to maxQueueID>
>MAC-hs queue Id	MP		Integer (0 to 7)	The MAC-hs queue ID is unique across all MAC-d flows.
					>Selecting DLMAC-hs configuration
>>Enhanced type
					>>>MAC-d flow addition or reconfiguration list		<1 to maxMAC-d flows>
>>>>MAC-d flow identification	MP		DL enhanced MAC-d flow identification 10.3.5.7f
					>General of
>>MAC-d flow identification	MP		MAC-d flow identification 10.3.5.7c
					>T1	MP		Integers (10, 20, 30, 40, 50, 60, 70, 80, 90, b, g, b,	Timer when PDU is released to higher layer even in case of outstanding (outstanding) PDU with lower TSN value

			100、120、140、160、200、300、400)))	(in milliseconds)
					>MAC-hs window size	MP		Integer (4, 6, 8, 12, 16, 24, 32)
>MAC-d PDU size information	OP	<1 to maxmaddpdus>		Different MAC-d PDU sizes configured for the HS-DSCH are mapped to MAC-d PDU size indices in the MAC-HS header.
					>>MAC-dPDU size	MP		Integer (1 to 5000)
>>MAC-dPDU size index	MP		Integer (0 to 7)
					MAC-hs queue deletion list	OP	<1 to maxQueueID>
>MAC-hs queue Id	MP		Integer (0 to 7)	The MThe AC-hs queue ID is unique across all MAC-d flows.

Alternatively, the MAC-d PDU size information and associated MAC-d PDU size index may be placed as a sub-part of the "regular" DM MAC-hs configuration choice.

Operations related to the presence of this IE may be modified as well, in addition to the information element definition. In this embodiment, optimization of the MAC-ehs header is included. The modification of the MAC-d flow identification and Radio Bearer (RB) mapping information IE remains the same as described above.

To support optimization of different processes performed on fixed and flexible RLC PDU sizes on a logical channel basis, the IE "added or reconfigured MAC-d flows" should be modified. A field indicating whether the corresponding MAC-d flow supports flexible or fixed RLC PDU sizes may be added to the "enhanced" DL MAC-hs configuration selection. Alternatively, the DL RLC configuration field from the RB mapping information IE may be used to check whether the RLC supports flexible or fixed RLC PDU sizes. Further, if a fixed RLC configuration is supported, the RLC performs an operation associated with mapping between a MAC-d PDU size index and a MAC-d PDU size allowed by a MAC-d flow. A possible definition of IE is shown in table 4 below.

TABLE 4

Information element/group name	Need to make sure that	A plurality of	Type and reference	Semantic description
					MAC-hs queue addition or reconfiguration list	OP	<1 to maxQueueID>
>MAC-hs queue Id	MP		Integer (0 to 7)	The MAC-hs queue ID is unique across all MAC-d flows.
					>Selecting DL MAC-hs configuration
>>Enhanced type
					>>>MAC-d flow addition or reconfiguration list		<1 to maxMAC-d flow>
>>>>MAC-d flow identification	MP		DL enhanced MAC-d flow identification 10.3.5.7f
					>>>>DL RLC configuration			Enumeration (conventional, enhanced)
>>>>MAC-d PDU size information	OP	<1 to maxmaddpdus>		Different MAC-d PDU sizes configured for the HS-DSCH are mapped to MAC-d PDU size indices in the MAC-HS header.
					>>>>>MAC-d PDU size	MP		Integer number of

Small			(1 to 5000)
					>>>>>MAC-d PDU size index	MP		Integer (0 to 7)
>General of

The MAC-d PDU size information may be specific to a logical channel or a logical channel group corresponding to a designated priority queue. In the latter case, as indicated above, the MAC-d pdu size information is not required for each logical channel in the queue, but for each priority queue. In this case, the MAC-d flow identification will be consistent with other parameters in the queue such as T1 and the MAC-hs window size.

When the logical channel is not mapped one-to-one with the MAC-d flow, the logical channel identification is specified in the Iub frame protocol. In this case, the MAC-d flow identification and RB mapping information for release 6 remain unchanged.

The mapping of logical channels and MAC-hs queues is modified as follows. In particular, the IE "added or reconfigured MAC-d flow" operation is adjusted by selecting the MAC-hs configuration, i.e., normal or enhanced. The selection is not limited to DL MAC-hs configuration. Any other valid IE indicating the MAC-hs version may be used.

If the enhanced MAC-hs configuration is used, the MAC-hs should map the logical channel list provided for the reordering queue. More than one logical channel may be mapped to a queue and a field containing a list of logical channels for addition or reconfiguration is provided for enhanced MAC-hs configuration options.

The new field named "logical channel add or reconfigure list" ranges from 1 to maxLCH-ID, where maxLCH-ID is the maximum number of logical channels that can be mapped to a queue or the maximum number of valid logical channels. A logical channel identification is provided for each logical channel.

The modified IE "added or reconfigured MAC-d flow" is shown in table 5 below. To support MAC-ehs header optimization, where MAC-ehs handles fixed and flexible RLC PDU sizes, a similar modification as described above should be performed. This includes adding a field indicating the RLC configuration supported for a given logical channel and/or MAC-d or logical size information per logical channel or per queue.

TABLE 5

Information element/group name	Need to make sure that	A plurality of	Type and reference	Semantic description
					MAC-hs queue addition or reconfiguration list	OP	<1 to maxQueueID>
>MAC-hs queue Id	MP		Integer (0 to 7)	The MAC-hs queue ID is unique across all MAC-d flows.
					>Selecting DLMAC-hs configuration
>>Enhanced type
					>>>Logical channel addition or reconfiguration list		<1 to maxLCH-ID>
>>>>Logical channel identification	MP		Integer (1 to 15)	This parameter is used to distinguish the logical channels multiplexed by the MAC on the transport channel.
					>General of
>>MAC-d flow identification	MP		MAC-d flow identification 10.3.5.7c
					>T1	MP		Integers (10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 120, 140, 160, 200, 300, C,	Even in case of outstanding (outstanding) PDUs with lower TSN values when the PDU is released to higher layers

			400)	Time-meter (with millisecond as unit)
					>MAC-hs window size	MP		Integer (4, 6, 8, 12, 16, 24, 32)
>MAC-dPDU size information	OP	<1 to maxmaddpdus>		Different MAC-d PDU sizes configured for the HS-DSCH are mapped to MAC-d PDU size indices in the MAC-HS header.
					>>MAC-dPDU size	MP		Integer (1 to 5000)
>>MAC-dPDU size index	MP		Integer (0 to 7)
					MAC-hs queue deletion list	OP	<1 to maxQueueID>
>MAC-hs queue Id	MP		Integer (0 to 7)	The MAC-hs queue ID is unique across all MAC-d flows.

If a fixed RLC PDU size for a logical channel is supported, the system performs operations corresponding to the MAC-d index and MAC-d PDU size mapping. In this case, the MAC-d index and size correspond to a specific logical channel and an allowed RLC PDU size for the logical channel.

The operation associated with the IE is similar to that set forth above and with the following variations. For each logical channel contained in the IE "logical channel addition or reconfiguration list", if the "DL MAC-hs configuration" is set to the value "enhanced", and if the WTRU previously stored a mapping between the MAC-hs queue and the logical channel, the old mapping is deleted and the logical channel indicated in the current message is mapped to the MAC-hs queue.

Alternatively, a new IE element may be added. This new information element will serve the same purpose as the "added or reconfigured MAC-d flow" IE. The fields contained in this IE may include a list of queue IDs and queue identifications and a list of logical channels and logical channel identifications for each queue. Alternatively, if MAC-hs header optimization is included, there may be fields to indicate RLC configuration and SID and N information for each logical channel with a fixed RLC PDU size. In addition, a T1 timer, MAC-hs window size, and queue to be deleted may also be included.

Although the features and elements described above are described 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, examples of which include Read Only Memory (ROM), Random Access Memory (RAM), registers, buffer 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), for execution by a general purpose computer or a processor.

For example, suitable processors include: 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, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any 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, terminal, base station, radio network controller, 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 video circuit, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, bluetoothA module, a Frequency Modulation (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 of a Wireless Local Area Network (WLAN) or Ultra Wideband (UWB) module.

Examples

1. A method for handling variable Acknowledged Mode (AM) Protocol Data Unit (PDU) sizes, the method comprising:

receiving a Radio Link Control (RLC) Service Data Unit (SDU);

determining whether RLC is configured for flexible PDU sizes; and

and processing the RLC SDU.

2. The method of embodiment 1 wherein processing the RLC SDU comprises segmenting and/or concatenating the RLC SDU into Acknowledged Mode Data (AMD) PDUs of fixed length if the RLC is not configured for flexible PDU sizes and storing the AMD PDUs of fixed length in a transmit buffer.

3. A method as in any of embodiments 1 or 2 wherein processing the RLC SDUs when configured for flexible PDU sizes comprises storing the RLC SDUs in a transmit buffer, receiving a request from a lower layer, removing the RLC SDUs from the transmit buffer, and creating a flexible PDU.

4. The method of embodiment 3 wherein the received request is a request for N PDUs of size X.

5. The method as in any one of embodiments 3 or 4 wherein the received request is a request for a maximum amount of data.

6. A method as in any of embodiments 3-5 wherein the received request is a request for a maximum RLC PDU size.

7. The method of any of embodiments 3-6 wherein the lower layer comprises a Medium Access Control (MAC).

8. A method as in any of embodiments 3-7 wherein the PDU size requested by a lower layer is below a maximum value configured by a higher layer.

9. A method as in any of embodiments 3-8 wherein the PDU size requested by a lower layer is above a minimum value configured by a higher layer.

10. The method as in any of embodiments 3-9 wherein the status PDU is piggybacked when the sum of the sizes of buffered rlc PDUs is less than the maximum PDU size to be delivered to lower layers.

11. A method as in any of embodiments 3-10 wherein the STATUS PDU is piggybacked when the size of the next RLC SDU to be transmitted is less than the maximum PDU size to be delivered to lower layers.

12. A method as in any of embodiments 3-11 wherein a STATUS PDU is piggybacked when concatenation of all buffered RLC SDUs with the STATUS PDU is less than a maximum PDU size to be delivered to lower layers.

13. A method as in any of embodiments 3-12 wherein a STATUS PDU is piggybacked when the concatenation of the next RLC PDU with the STATUS PDU is less than the maximum PDU size determined by lower layers.

14. A method as in any of the embodiments 3-13 wherein a length indicator is used to define whether a padding or piggybacked STATUS PDU is included in the AMD PDU.

15. A method as in any of embodiments 3-14 wherein a length indicator is used to define a boundary between RLC SDUs inside an AMD PDU.

16. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

a Radio Link Controller (RLC) configured to operate in an Acknowledged Mode (AM) and process variable size Protocol Data Units (PDUs).

17. The WTRU of embodiment 16, further comprising:

a transmitting end;

a receiving end; and

an RLC control unit configured to manage a function between the transmitting end and the receiving end.

18. The WTRU of embodiment 17, wherein the transmitting side further comprises:

a transmission buffer;

a segmentation/concatenation unit;

an RLC header addition unit;

a retransmission buffer and management unit;

a Multiplexer (MUX);

a field setting unit configured to set fields in a PDU header and a piggybacked STATUS PDU; and

and an encryption unit.

19. The WTRU of embodiment 18 further comprising a second transmit buffer.

20. The WTRU as in any one of embodiments 19 or 20 wherein the segmentation/concatenation unit includes a segmentation buffer.

21. The WTRU as in any one of embodiments 17-20 wherein the receiving end further comprises:

a demultiplexing/routing unit;

a decryption unit;

a receive buffer and a retransmission management unit;

an RLC header removal and piggyback information extraction unit; and

and (5) a recombination unit.

22. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

an interface between a receiving Medium Access Control (MAC) sub-layer and a receiving Radio Link Control (RLC) sub-layer, the interface configured to receive a MAC Protocol Data Unit (PDU), extract an RLC PDU, transmit the RLC PDU, and indicate a PDU size to the RLC.

23. The WTRU of embodiment 22 wherein the size of the RLC PDU is indicated using a MAC-DATA-Indication primitive.

24. The WTRU of embodiment 23 wherein the MAC-DATA-Indication primitive is used to indicate a PDU size measured in bits.

25. The WTRU as in any one of embodiments 23 or 24, wherein the MAC-DATA-Indication primitive is used to indicate a PDU size measured in octets.

26. The WTRU of embodiment 23 wherein the MAC-DATA-Indication primitive is used to indicate an overall size of a received single Radio Link Control (RLC) Protocol DATA Unit (PDU).

27. The WTRU of embodiment 26 wherein the total size of the RLC PDU is measured in bits.

28. The WTRU as in any one of embodiments 26 or 27 wherein an overall size of the rlc pdu is measured in octets.

29. A WTRU according to any of embodiments 26-28, wherein an overall size of the RLC PDUs comprises a sum of sizes of individual RLC PDUs.

30. The WTRU as in any one of embodiments 26-29 wherein the MAC-DATA-Indication primitive is used to indicate a size of a received transport block.

31. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

an interface between a transmit MAC sublayer and a transmit RLC sublayer, the interface configured to determine, at the MAC layer, a maximum Radio Link Control (RLC) Protocol Data Unit (PDU) size parameter corresponding to a sum of all PDUs communicated to a Medium Access Control (MAC) and to indicate the maximum size parameter to the RLC layer.

32. The WTRU of embodiment 31 wherein the maximum size parameter is sent using a MAC-STATUS-Indication primitive.

33. The WTRU as in any one of embodiments 31 or 32 wherein the maximum size parameter is measured in bits.

34. The WTRU as in any one of embodiments 31-33 wherein the maximum size parameter is measured in octets.

35. The WTRU as in any one of embodiments 31-34 wherein the maximum size parameter is measured every Transmission Time Interval (TTI).

36. The WTRU as in any one of embodiments 31-35 wherein the maximum size parameter is measured at any fixed time period.

37. The WTRU as in any one of embodiments 31-36 wherein the maximum size parameter is an amount of data that the RLC can deliver before a next time a maximum size is indicated using the MAC-STATUS-Indication primitive.

38. The WTRU as in any one of embodiments 32-38 wherein the interface further comprises:

n parameter and X parameter when the MAC layer requests N PDUs of size X.

39. The WTRU as in any one of embodiments 32-39 further comprising:

circuitry configured to determine the maximum size parameter based on a data capacity of an air interface.

40. A WTRU according to any of embodiments 37-39, wherein the interface further comprises:

circuitry configured to determine a data capacity of the air interface based on radio conditions and user data scheduling.

41. A wireless transmit/receive unit (WTRU), comprising:

a processor configured to receive a Radio Link Control (RLC) Service Data Unit (SDU);

a processor configured to determine whether the RLC is configured for variable PDU sizes; and

a processor configured to process the RLC SDU.

42. The WTRU of embodiment 41 wherein processing the RLC SDU comprises segmenting and/or concatenating RLC SDUs into Acknowledged Mode Data (AMD) Protocol Data Units (PDUs) having a fixed length and storing the AMD PDUs having a fixed length in a transmit buffer if the RLC is not configured for flexible PDU sizes.

43. The WTRU as in any of embodiments 41 or 42 wherein processing the RLC SDUs when the RLC is configured for flexible PDU sizes comprises storing the RLC SDUs in a transmission buffer, receiving a request from a lower layer, removing the RLC SDUs from the transmission buffer, and creating a flexible PDU.

44. A wireless transmit/receive unit (WTRU) configured to handle variable Acknowledged Mode (AM) Protocol Data Unit (PDU) sizes, the process comprising:

receiving an Acknowledged Mode Data (AMD) and a control Protocol Data Unit (PDU);

performing a first determination of whether the RLC is configured for a flexible PDU size;

processing the received AMD PDU if the first determination is positive;

performing a second determination of whether a fixed PDU size has been configured by a higher layer if the first determination is negative;

if the second determination is positive, performing a third determination of whether the PDU has a different size;

discarding PDUs of different sizes if the third determination is positive;

processing the received AMD PDU if the third determination is negative;

if the second determination is negative, basing the received first PDU as a basis for AMD PDU size and performing a fourth determination of whether the PDUs have different sizes;

discarding PDUs of different sizes if the fourth determination is positive; and

processing the received AMD PDU if the fourth determination is negative.

Claims (44)

1. A method for handling variable Acknowledged Mode (AM) Protocol Data Unit (PDU) sizes, the method comprising:

receiving a Radio Link Control (RLC) Service Data Unit (SDU);

determining whether RLC is configured for flexible PDU sizes; and

and processing the RLC SDU.

2. The method of claim 1 wherein processing the RLC SDU comprises segmenting and/or concatenating the RLC SDU into Acknowledged Mode Data (AMD) PDUs of fixed length if the RLC is not configured for flexible PDU sizes, and storing the AMD PDUs of fixed length in a transmit buffer.

3. The method of claim 1 wherein processing the RLC SDUs when the RLC is configured for flexible PDU sizes comprises storing the RLC SDUs in a transmission buffer, receiving a request from a lower layer, removing the RLC SDUs from the transmission buffer, and creating a flexible PDU.

4. The method of claim 3, wherein the received request is a request for N PDUs of size X.

5. The method of claim 3, wherein the received request is a request for a maximum amount of data.

6. The method of claim 3 wherein the received request is a request for a maximum RLC PDU size.

7. The method of claim 3, wherein the lower layer comprises a Medium Access Control (MAC).

8. The method of claim 3, wherein a PDU size requested by a lower layer is below a maximum value configured by a higher layer.

9. The method of claim 3, wherein a PDU size requested by a lower layer is above a minimum value configured by a higher layer.

10. The method of claim 3, wherein a STATUS PDU is piggybacked when the sum of the sizes of buffered RLC SDUs is less than the maximum PDU size to be delivered to lower layers.

11. The method of claim 3, wherein the STATUS PDU is piggybacked when the size of the next RLC SDU to be transmitted is smaller than the maximum PDU size to be delivered to lower layers.

12. The method of claim 3, wherein a STATUS PDU is piggybacked when concatenation of all buffered RLC SDUs with the STATUS PDU is less than a maximum PDU size to be delivered to lower layers.

13. The method of claim 3, wherein a STATUS PDU is piggybacked when the concatenation of the next RLC SDU with the STATUS PDU is less than the maximum PDU size determined by lower layers.

14. The method of claim 3, wherein a length indicator is used to define whether a padding or piggybacked STATUS PDU is included in the AMD PDU.

15. The method of claim 3 wherein a length indicator is used to define the boundary between RLC SDUs inside an AMD PDU.

16. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

a Radio Link Controller (RLC) configured to operate in an Acknowledged Mode (AM) and process variable size Protocol Data Units (PDUs).

17. The WTRU of claim 16, further comprising:

a transmitting end;

a receiving end; and

an RLC control unit configured to manage a function between the transmitting end and the receiving end.

18. The WTRU of claim 17, wherein the transmitting end further comprises:

a transmission buffer;

a segmentation/concatenation unit;

an RLC header addition unit;

a retransmission buffer and management unit;

a Multiplexer (MUX);

a field setting unit configured to set fields in a PDU header and a piggybacked STATUS PDU; and

and an encryption unit.

19. The WTRU of claim 18, further comprising a second transmit buffer.

20. The WTRU of claim 18 wherein the segmentation/concatenation unit includes a segmentation buffer.

21. The WTRU of claim 17, wherein the receiving end further comprises:

a demultiplexing/routing unit;

a decryption unit;

a receive buffer and a retransmission management unit;

an RLC header removal and piggyback information extraction unit; and

and (5) a recombination unit.

22. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

an interface between a receiving Medium Access Control (MAC) sub-layer and a receiving Radio Link Control (RLC) sub-layer, the interface configured to receive a MAC Protocol Data Unit (PDU), extract an RLC PDU, transmit the RLC PDU, and indicate a PDU size to the RLC.

23. The WTRU of claim 22 wherein the size of the RLC PDU is indicated using a MAC-DATA-Indication primitive.

24. The WTRU of claim 23, wherein the MAC-DATA-Indication primitive indicates a PDU size measured in bits.

25. The WTRU of claim 23, wherein the MAC-DATA-Indication primitive indicates a PDU size measured in octets.

26. The WTRU of claim 23, wherein the MAC-DATA-Indication primitive indicates an overall size of a received single Radio Link Control (RLC) Protocol DATA Unit (PDU).

27. The WTRU of claim 26 wherein the overall size of the RLC PDU is measured in bits.

28. The WTRU of claim 26 wherein the overall size of the RLC PDU is measured in octets.

29. The WTRU of claim 26 wherein the total size of the RLC PDUs comprises the sum of the sizes of the individual RLC PDUs.

30. The WTRU of claim 26, wherein the MAC-DATA-Indication primitive indicates a size of a received transport block.

31. A wireless transmit/receive unit (WTRU), comprising:

a transmitter;

a receiver; and

an interface between a transmit MAC sublayer and a transmit RLC sublayer, the interface configured to determine, at the MAC layer, a maximum Radio Link Control (RLC) Protocol Data Unit (PDU) size parameter corresponding to a sum of all PDUs communicated to a Medium Access Control (MAC) and to indicate the maximum size parameter to the RLC layer.

32. The WTRU of claim 31, wherein the maximum size parameter is sent using a MAC-STATUS-Indication primitive.

33. The WTRU of claim 31, wherein the maximum size parameter is measured in bits.

34. The WTRU of claim 31, wherein the maximum size parameter is measured in octets.

35. The WTRU of claim 31 wherein the maximum size parameter is measured every Transmission Time Interval (TTI).

36. The WTRU of claim 31, wherein the maximum size parameter is measured at any fixed time period.

37. The WTRU of claim 31, wherein the maximum size parameter is an amount of data that the RLC can deliver before a next time a maximum size is indicated using the MAC-STATUS-Indication primitive.

38. The WTRU of claim 31, wherein the interface further comprises:

n parameter and X parameter when the MAC layer requests N PDUs of size X.

39. The WTRU of claim 31, wherein the interface further comprises:

circuitry configured to determine the maximum size parameter based on a data capacity of an air interface.

40. The WTRU of claim 37, wherein the interface further comprises:

circuitry configured to determine a data capacity of the air interface based on radio conditions and user data scheduling.

41. A wireless transmit/receive unit (WTRU), comprising:

a processor configured to receive a Radio Link Control (RLC) Service Data Unit (SDU);

a processor configured to determine whether the RLC is configured for variable PDU sizes; and

a processor configured to process the RLC SDU.

42. The WTRU of claim 41 wherein processing the RLC SDU comprises segmenting and/or concatenating an RLC SDU into Acknowledged Mode Data (AMD) Protocol Data Units (PDUs) of fixed length and storing the AMD PDUs of fixed length in a transmit buffer if the RLC is not configured for flexible PDU sizes.

43. The WTRU of claim 41 wherein processing the RLC SDUs when the RLC is configured for flexible PDU sizes includes storing the RLC SDUs in a transmit buffer, receiving a request from a lower layer, removing the RLC SDUs from the transmit buffer, and creating a flexible PDU.

44. A wireless transmit/receive unit (WTRU) configured to handle variable Acknowledged Mode (AM) Protocol Data Unit (PDU) sizes, the processing comprising:

receiving an Acknowledged Mode Data (AMD) and a control Protocol Data Unit (PDU);

performing a first determination of whether the RLC is configured for a flexible PDU size;

processing the received AMD PDU if the first determination is positive;

performing a second determination of whether a fixed PDU size has been configured by a higher layer if the first determination is negative;

if the second determination is positive, performing a third determination of whether the PDU has a different size;

discarding PDUs of different sizes if the third determination is positive;

processing the received AMD PDU if the third determination is negative;

if the second determination is negative, basing the received first PDU as a basis for an AMD PDU size and performing a fourth determination of whether the PDU has a different size;

discarding PDUs of different sizes if the fourth determination is positive; and

processing the received AMD PDU if the fourth determination is negative.