HK1140873A - Method and apparatus for enhancing rlc for flexible rlc pdu size - Google Patents

Description

Method and apparatus for implementing flexible RLC PDU size by enhancing RLC

Technical Field

The present application relates to wireless communications.

Background

Herein, high speed packet access evolution (HSPA +) refers to the evolutionary enhancements of the third generation partnership project (3GPP) radio access technology High Speed Downlink Packet Access (HSDPA) and High Speed Uplink Packet Access (HSUPA) standards used in Universal Mobile Telecommunications System (UMTS) wireless communication systems. Some of the improvements to HSPDA (3GPP UMTS standard release 5) and HSUPA (3GPP UMTS standard release 6) proposed as part of HSPA +, include higher data rates, higher system capacity and coverage, enhanced packet service support, reduced latency, reduced operator cost, and backward compatibility with 3GPP legacy systems. Herein, 3GPP legacy systems generally refers to any one or more pre-existing 3GPP standards from release 6 or earlier. And these improved implementations include evolution of the radio interface protocols and network architectures.

The following list contains the relevant abbreviations:

3 GPP-third Generation partnership project

AM-response mode

AMD-response Pattern data

ARQ-automatic repeat request

CN-core network

CP-control plane

CS-Circuit switching

DL-Downlink

HARQ-hybrid automatic repeat request

HSDPA-high speed Downlink packet Access

HSUPA-high speed uplink packet access

IP-Internet protocol

LCID-logical channel identifier

LTE-Long term evolution

MAC-medium access control

PDCP-packet data convergence protocol

PDU-packet data Unit

PHY-Physics

PS packet switching

QoS-quality of service

RAN-radio Access network

RLC-radio link control

RNC-radio network controller

CRNC-controlling RNC

SRNC-serving RNC

RNS-radio network subsystem

RoHC-robust header compression

RRC-radio resource control

RRM-radio resource management

Rx-reception/Perform reception

SAP-service Access Point

SDU-service data Unit

SN-sequence number

TB-transport Block

TBS-transport block set

TF-transport format

TFC-transport format combinations

TFRC transport format resource combination

TM-transparent mode

TMD-transparent mode data

Tx-transmission/execution transfer

UE-user Equipment

UL-Downlink

UM-non-response mode

UMD-non-answer mode data

UP-user plane

UMTS-Universal Mobile Telecommunications System

UTRAN-Universal terrestrial radio Access network

WTRU-wireless transmit/receive unit

The second layer radio interface protocols include Medium Access Control (MAC) and Radio Link Control (RLC) protocols. Some functions of the MAC and RLC protocols will be described below, and other functions not discussed are assumed to operate in the manner described in the 3GPP standard.

Some of the main functions of the MAC protocol are:

channel mapping of MAC Packet Data Units (PDUs) to physical channels

Multiplexing higher layer data into Packet Data Units (PDUs)

Quality of service (QoS) taking into account data priority for scheduling and rate control

Link adaptation for QoS and multiplexing

Hybrid automatic repeat request (HARQ) for fast retransmission control for error correction

The MAC layer multiplexes higher layer data into the MAC PDU. The mac pdu transmitted to a Physical (PHY) layer is called a Transport Block (TB). The set of TBs, which is called a Transport Block Set (TBs), is transmitted to the PHY layer at each Transmission Time Interval (TTI) by using a corresponding Transport Format (TF) describing physical layer properties for the TBs. If the TBS is obtained by combining or multiplexing data originating from more than one logical RLC channel, a TF combination named Transport Format Combination (TFC) is used. As part of link adaptation, the MAC layer performs TFC selection based on RLC logical channel priority, RLC buffer occupancy, physical channel status, and logical channel multiplexing. The reference for MAC TFC selection here is generic and may include, for example, Transport Format Resource Combination (TFRC) selection of the high speed MAC (MAC-hs) protocol in HSDPA.

The RLC protocol in the second layer has a great influence on the latency and throughput of data. The RLC protocol in 3GPP legacy systems, which is physically located at the Radio Network Controller (RNC) node, includes release 6 and earlier.

For the transmission (Tx) RLC protocol, which occurs in the Tx RLC entity, some of its main functions are:

macro diversity to enable a UE to connect to two or more cells and receive data simultaneously (optional)

Segmentation of higher layer radio bearers

Concatenation of higher layer radio bearers

Error detection and recovery of PDU with reception error

HARQ assisted ARQ for fast retransmission of PDUs received with errors

For the receive (Rx) RLC protocol to appear in Rx RLC, some of its main functions include:

duplicate PDU detection

In-order delivery of PDUs

Error detection and recovery of PDU with reception error

HARQ assisted ARQ for fast retransmission of PDUs received with errors

Reassembly of higher layer data from received PDUs

The three operation modes for the RLC layer are Acknowledged Mode (AM), Unacknowledged Mode (UM), and Transparent Mode (TM). For AM operation, which includes the transmission of certain higher layer user plane data, the RLC protocol is bi-directional, whereby status and control information is sent from the Rx RLC entity to the Tx RLC entity. For TM and UM operations, which include the transmission of certain control plane Radio Resource Control (RRC) signaling data, the RLC protocol is unidirectional, whereby the Tx RLC entity and the Rx RLC entity are independent and status and control information is not exchanged. Furthermore, certain functions are typically only used in AM operation, such as HARQ assisted ARQ and error detection and recovery.

The RLC PDU size is determined by the RRC layer according to the long-term quality of service (QoS) requirements of the application data transmitted by the RLC logical channel. In accordance with the 3GPP legacy system including release 6 and earlier, the RLC layer is configured in a semi-static manner by the RRC layer by using a predetermined RLC PDU size. Thus, the RLC PDU size is determined semi-statically by the higher layer and these RLC PDUs will be assigned Sequence Numbers (SNs). The AM data RLC PDUs are numbered modulo by a cycle of integer Sequence Numbers (SNs) of fields 0 to 4095.

RLC PDU types are DATA (DATA), CONTROL (CONTROL), and STATUS (STATUS). When the RLC operates in the AM mode, the DATA PDU is used to transmit user DATA, piggybacked STATUS information, and a polling bit for requesting a STATUS report from a receiver. The CONTROL PDU is used for RLC RESET (RLC RESET) and RESET Acknowledge (ACK) commands. The STATUS PDU is used to exchange STATUS information between two RLC entities operating in AM mode and may include different types of super fields (SUFI) including, for example, a window size SUFI and a Mobile Receive Window (MRW) SUFI.

A transmission window refers to a group of PDUs that are processed for transmission or are currently being transmitted. Likewise, a receive window generally refers to a group of PDUs being received or processed at a receiver. The transmission or reception window size generally refers to the number of PDUs transmitted or received by the system, respectively. The transmission and reception window sizes need to be managed using flow control to avoid overloading the system and incurring an unexpected packet loss rate. In general, upon successful reception of a PDU at the receiver, a new PDU can be added to the transmission and/or reception window.

The RLC transmission window consists of a lower bound and an upper bound. The lower limit consists of the SN of the PDU with the lowest SN transmitted and the upper limit consists of the SN of the PDU with the highest SN transmitted. The RLC is configured with a maximum transmission window size, whereby the maximum number of PDUs transmitted from the lower limit to the upper limit should not exceed the maximum window size. The RLC reception window is configured in a similar manner. The lower RLC reception window limit is the SN following the last in-sequence received PDU and the upper limit is the SN of the PDU with the highest received sequence number. The receive window also has a maximum window size, where the maximum expected PDU SN is equal to the sum of the lower bound SN and the maximum configuration window size. These transmit and receive windows are configured with transmit and receive state variables, respectively, as described below.

Techniques for flow control are RNC/node B flow control, RLC flow control, and RLC status reporting. RNC/node B flow control refers to a process of minimizing downlink data buffered in a node B. Generally, in case of a handover of a UE to a cell with a different Radio Network Subsystem (RNS), data destined for the UE flows from a Core Network (CN) through a Source Radio Network Controller (SRNC), a node B and a drift radio network controller (DNRC) in drift. The node B grants allocation credits to the SRNC and the DRNC in drift, which allows the SRNC to send the same number of PDUs to the node B, whereby the RNC cannot send more PDUs until granted more credits. RLC flow control refers to the management of packet transmission between the Tx RLC entity and the Rx RLC entity, including the window size. RLC status reports allow the receiver to report status information to the transmitter when polled by the transmitter.

According to the 3GPP standard, various RLC protocol parameters for flow control are reported by higher layers to the RLC layer, including the following parameters:

poll _ Window (Polling Window)

Configured _ Tx _ Window _ Size (Configured transmission Window Size)

Configured _ Rx _ Window _ Size (Configured receive Window Size)

These parameters are described in more detail below and are used by the RLC, along with various RLC state variables for flow control, to configure transmission and reception window sizes. According to 3GPP legacy systems, these RLC state variables depend on the SN. For example, the following RLC transmitter state variables are affected by SN:

VT (S) is a transmit state variable that contains the SN of the next AM data PDU to be transmitted for the first time

VT (A) is a reply state variable which contains the SN following the SN of the last AMDPDU of the in-sequence reply and forms the lower edge of the transmission window

VT (MS) is the maximum transmit state variable, which contains the SN of the first AM data PDU that may be rejected by a peer receiver

VT (WS) is a transmission window size state variable

All arithmetic calculations for VT (S), VT (A), VT (MS), VR (R), VR (H), and VR (MR) depend on one or more SNs. In addition, the following RLC receiver state variables are also affected by SN:

VR (R) is a receive state variable containing the SN following the SN of the last in-sequence received AM data PDU

VR (H) is the highest expected state variable containing the SN following any received AM data PDU

VR (MR) is the maximum acceptable reception state variable, which contains the SN of the first AM data PDU that the receiver will reject

In 3GPP legacy systems, many of the functions for supporting data transmission services such as RNC/node B flow control, RLC flow control, and RLC status reporting are based on SN, or effectively on the number of PDUs, when the RLC PDU size is fixed. The reasons for this are: the transmit and receive window sizes can be accurately characterized by the number of PDUs and the known and fixed PDU size. However, in proposals for HSPA +, RLC may be configured by upper layers to allow for flexible RLC PDU sizes. If an upper layer such as the RRC layer configures an operation of a flexible RLC PDU size, the RLC PDU size may be changed up to a semi-statically specified maximum RLC PDU payload size.

It should be considered herein that existing RLC operations based on SN may not be able to operate efficiently using flexible RLC PDU sizes. The reason for this is that: if the number of PDUs is used to define the window size, this results in a variable window size, which may lead to buffer overflow in the RNC and buffer underflow in the node B. Accordingly, it would be advantageous if an alternative method for configuring window sizes for flexible RLC PDU size operations could be provided.

Disclosure of Invention

Disclosed are enhancements to Radio Link Control (RLC) protocols for high speed packet access evolution (HSPA +) and other wireless systems such as Long Term Evolution (LTE) systems, where the enhancements allow for flexible RLC Packet Data Unit (PDU) sizes. When the RLC PDU size is not fixed, the Radio Network Controller (RNC)/node B flow control, RLC flow control, status reporting, and polling mechanisms will not depend on the Sequence Number (SN) or number of PDUs, but rather are configured to use a byte counting based approach. This byte count based approach proposed for RLC is applicable to both uplink and downlink communications.

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 shows a structure of a super field (SUFI) in an RLC STATUS Packet Data Unit (PDU);

FIG. 2 shows a flow diagram of RNC/node B flow control using byte-based credit allocation in accordance with the teachings herein;

FIG. 3 shows a flow diagram of an RLC transmission (Tx) window update process in accordance with the teachings herein;

FIG. 4 shows a flow diagram of an RLC reception (Rx) window update process in accordance with the teachings herein; and

fig. 5 is a flow chart illustrating a process for enhanced octet-based rlc pdu creation in accordance with the teachings herein.

Detailed Description

The term "wireless transmit/receive unit (WTRU)" as referred to below 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 equipment 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.

Methods based on byte counting are provided to enhance Radio Network Controller (RNC)/node B flow control, Radio Link Control (RLC) flow control, RLC status reporting, and polling mechanisms for flexible RLC Packet Data Unit (PDU) sizes. The proposed enhancements enable efficient RLC functionality operation to be implemented when RLC PDU sizes are variable, in order to improve the conventional Sequence Number (SN) -based RLC functionality designed for fixed RLC PDU sizes. The proposed RLC enhancements are applicable to both uplink (UE to Universal Terrestrial Radio Access Network (UTRAN)) and downlink (UTRAN to UE) communications and can be used in any wireless communication system including, but not limited to, high speed packet access evolution (HSPA +), Long Term Evolution (LTE), and Wideband Code Division Multiple Access (WCDMA) systems. For wireless systems such as LTE, UTRAN is equivalent to evolved UTRAN (E-UTRAN).

The proposed RLC enhancements can be used in architectures where the RLC is fully operational in the node B, or where the RLC is partially operational in the RNC and partially operational in the node B. For the proposed RLC enhancements, it is described herein in principle with reference to HSPA +. Numerous functions and parameters are based on functions and parameters for HSDPA and HSUPA and can be understood in conjunction with the 3GPP RLC protocol specification (TS), which contains release 7 of the 3GPP RLC protocol specification incorporated herein (see 3GPP ts25.322v.7.2.0). It is assumed that the RLC can be configured by higher layers to support flexible PDU sizes with a specified maximum RLC PDU payload size. Further, it is assumed that the maximum RLC PDU size can be inferred from the specified maximum RLC PDU payload size. Alternatively, the maximum RLC PDU size may be directly specified. Furthermore, the terms byte and octet, and the terms transmitter and sender, are used interchangeably.

One or more of the following metrics may be used, alone or in combination, to define and manage window size when RRC configures flexible RLC PDU sizes:

number of bytes

Number of blocks, where each block has a fixed number of bytes

Number of PDUs or Sequence Number (SN)

The one or more metrics for window definition are signaled and negotiated in RRC establishment, configuration, and reconfiguration procedures for radio bearers. For the one or more metrics listed above for window size, these metrics may apply to all messaging that updates the window for flow control during the connection process. For example, these window size metrics may be included in the window size super field (SUFI) and the Mobile Receive Window (MRW) SUFI of the rlc control or STATUS PDU.

For Acknowledged Mode (AM) RLC, to support flexible RLC PDU sizes by using radio bearer information elements (RLC information) in RRC configuration and RLC reconfiguration, RRC may provide RLC with any one or more of the following information to signal the use of flexible RLC PDU sizes:

selecting downlink RLC mode information, wherein the information includes a new indicator for flexible RLC PDU size mode in addition to other RLC modes. When the flexible RLC pdu size mode is indicated, the RLC entity may interpret other RLC protocol parameters according to the mode.

Any other new information element that is part of the RLC information may also be used to indicate the flexible RLC PDU size mode.

In the context of the flexible RLC PDU size mode, Downlink (DL) RLC PDU size information in bits can be reused and can be interpreted as follows:

as an RLC scaling parameter in octets (after dividing the number of bits by 8), which is sent specifically for scaling or multiplexing other protocol parameters specified in the number of PDUs as described below, where the RLC scaling parameter has the same value on the receiving (Rx) RLC entity and on the transmitting (Tx) RLC entity, or

Specifying the maximum RLC PDU size in a flexible RLC PDU size mode, where the maximum RLC PDU size may also be used instead as the above-described RLC scaling parameter.

Protocol parameters signaled by an upper layer like RRC to RLC, including but not limited to Poll _ PDU, Poll _ SDU, Configured _ Tx _ Window _ Size, and Configured _ Rx _ Window _ Size (see 3GPP TS25.322 v.7.1.0, section 9.6), which can be specified and interpreted in two ways:

in PDU number, for Poll _ SDU, in number of Service Data Units (SDU), which is an integer value, and from which the RLC can derive the window size in octets by performing a mathematical calculation. For example, a specified number of PDUs (SDUs for Poll _ SDU) may be multiplexed with the RLC scaling parameters in octets specified by the upper layer.

Byte-wise, where a new field can be defined for the option to hold protocol parameters in bytes.

In an RLC STATUS PDU, for a window size super field (SUFI) used by the receiver to configure the transmitter window size, the super field is configured to provide octet parameters. This enhancement can be used when the RRC sets the flexible RLC PDU size in the manner described above, and can be specified in two ways:

in number of PDUs and from which the RLC can derive the equivalent parameter in octets by performing a mathematical calculation. For example, a specified number of PDUs may be multiplied by the RLC scaling parameter in the octet specified by the upper layer as described above.

New SUFI, in bytes, with type, length and value components. For example, for a type field currently unused or reserved that is 4 bits in length, such as bit 1000 shown in Table 1, this field may be used for a new SUFI type to specify the number of BYTES WINDOW _ BYTES SUFI shown in Table 1 and FIG. 1, where the SUFI length component is defined long enough to hold the maximum possible WINDOW size SUFI value in BYTES.

Table 1: definition of a New SUFI type 1000 for WINDOW _ BYTESSUI added to a 4-bit-long existing SUFI type field

Bits	Description of the invention
		0000	No MORE data (NO _ MORE)
0001	Window size (WINDOW)
		0010	Response (ACK)
0011	Listing (LIST)
		0100	BITMAP (BITMP)
0101	Correlation list (Rlist)
		0110	Mobile Receiving Window (MRW)
0111	Mobile receive window acknowledgement (MRW _ ACK)
		1000	Window size byte (WINDOW _ BYTES)
1001-1111	Retention (for this protocol version, PDU with this code is invalid)

RNC/node B flow control

Enhancements to RNC/node B flow control will be described herein with respect to an example of reserving an RLC entity in an RNC. However, similar enhancements may be defined in the case where the RLC entity is in the RNC and node B. For 3GPP TS 25.425 for the UTRAN Iur interface user plane protocol with common transport channel data flow between an RNC and a node B, and for 3GPP TS 24.435 for the UTRAN Iub interface user plane protocol for common transport channel data flow between two RNCs, a data MAC entity (MAC-d) may be retained in the RNC for receiving RLC PDUs and forwarding them to a high speed MAC (MAC-hs) entity in the node B after applying appropriate header information, according to the existing 3GPP standards described in these documents. In 3GPP legacy systems, the node B sends the capacity allocation information to the serving rnc (srnc) and possibly to the controlling rnc (crnc) in order to indicate the maximum PDU size that can be sent and the number of PDUs. Furthermore, by transmitting these parameters, the allocation in a fixed number of periods or indeterminate periods can be made periodic.

The number of MAC PDUs sent from the RNC to the node B and the corresponding time interval for transmission is adjusted by a flow control algorithm based on a credit allocation scheme. The credit represents the number of MAC-d PDUs that can be transmitted. The RNC requests credits and the node B grants them along with a specified time interval for transmission.

When the RLC PDU size is variable, the MAC-d PDU size may thus also be variable. Thus, the process of specifying the number of credits in terms of the number of MAC-d PDUs would not suffice. There are currently many possible methods for performing RNC/node B flow control with variable size MAC-d PDUs. One of the possibilities is to eliminate RNC/node B flow control, but to do so requires relying on user data protocols such as Transmission Control Protocol (TCP) to implement flow control for the network and additionally handling the interaction between TCP windows and RLC windows.

Alternatively, credit allocations may be specified in bytes rather than PDU quantities, and such specification may be accomplished in two ways. A new field may be added in the existing frame to specify the number of bytes of credit rather than the number of PDUs. Alternatively, an existing control frame or a new control frame may be used in radio bearer establishment or reconfiguration or in each appropriate control frame to signal an indication that the allocation is actually a byte allocation by multiplying the credit by the maximum PDU size in bytes to yield the total number of bytes. Accordingly, the maximum number of PDUs that can be transmitted from the RNC to the node B is not equal to the credit measured in terms of the number of PDUs and signaled. By using a byte-based approach, the RNC may optionally maintain a mapping of PDU SNs to their byte lengths. Once the RNC receives a credit allocation from the node B, it is allowed to transmit as many PDUs as it can without violating the length limit in bytes specified by this new credit allocation based on length in bytes.

Figure 2 shows a flow diagram of RNC/node B flow control using byte based credit allocation. The node B signals the credit allocation in bytes (step 205). The RNC receives a credit allocation in bytes (step 210). The RNC maintains a mapping of PDU SNs to PDU lengths in bytes (step 220) and transmits PDUs without exceeding the received credit allocation (step 220).

RLC flow control

RLC flow control is achieved by advancing the RLC Tx window and at the same time keeping it within the limits imposed by the maximum window size when the PDUs at the lower end of the used transmission (Tx) window get acknowledged and thus received correctly. The PDU at the lower end of the Tx window is defined as the PDU that follows the last in-sequence acknowledged PDU. If a flexible RLC PDU size is configured, violation of the maximum window size limit should be avoided by taking appropriate steps. The Tx window size is specified in bytes.

Fig. 3 shows a flow diagram of a method for updating an RLC window Transmission (TX) window 300. After the initialization and setup process of the RLC, an RLC Tx operation is performed (step 305). The RLC Tx operation may be, for example, receiving status and control information from an RLC receiver. The RLC Tx entity determines whether to remove one or more PDUs from the used Tx window and raises the lower end of the used Tx window (step 310). One or more PDUs may be removed if the following occurs:

the receiver acknowledges PDU(s), or

The receiver negatively acknowledges the PDU(s), but the RLC transmitter decides to discard the PDU for other reasons, such as the receiver exceeding the transmitter's maximum number of retries, or

As a result of timer-based dropping in the transmitter.

For convenience of description, the following comments will be used for certain parameters related to the RLC Tx entity:

TxWMAX: length in bytes of maximum window size

TxWUTIL: the length in bytes of the window that has been used, or of the packet that has been acknowledged inside the window defined by the state variables V (A) and V (T)

TxL: length in bytes of one or more PDUs discarded due to RLC SDU discard procedure or due to receipt of one or more acknowledgements

TxN: length in bytes of the next PDU or PDUs to be transmitted first

The RLC entity calculates the Window Length (WL) parameter (step 315) as follows:

WL ═ TxWTIL-TxL + TxN. Equation (1)

The RLC Tx entity determines whether the WL parameter is less than the maximum window size TxWMAX (step 320). If WL is not less than TxWMAX, then the next PDU or PDUs are not transmitted and the upper end of the window is not raised (step 325). If WL is less than TxWMAX, the next PDU or PDUs are transmitted and the upper end of the window is raised (step 330).

A similar RLC flow control method would be applied at the RLC Rx entity when configuring a flexible RLC PDU size in order to ensure that the maximum window size limit is not violated. The Rx window size is specified in bytes. Fig. 4 shows a flow diagram of a method of updating an RLC receive (Rx) window 400 in accordance with the teachings herein. After the initialization and setup process of the RLC, an RLC Rx operation is performed (step 405). The RLC Rx operation may be, for example, receiving a new PDU. The RLC Rx entity determines whether to raise the lower end of the Rx window (step 410). An RLC Rx entity may raise the lower end of its Rx window and thereby lower RxWUTIL if the RLC Rx entity:

reception of a PDU whose SN follows the SN of the last PDU received in sequence, or

Receive a Moving Receive Window (MRW) from the RLC Tx entity.

For ease of description, the following comments will be used for the parameters related to the RLC Rx entity:

RxWMAX: length in bytes of maximum window size

RxWUTIL: length in bytes of used Rx window

RxD: length in bytes of one or more PDUs removed from a receive window due to in-order reception

RxN: length in bytes of the next PDU or PDUs to be received first

The RLC Rx entity calculates the Window Length (WL) parameter as follows:

WL ═ RxWUTIL + RxN-RxD. Equation (2)

The RLC Rx entity determines whether the WL parameter is less than the maximum window size RxWMAX (step 420). If WL is not less than RxWMAX, then the next PDU(s) are not received and the upper end of the Rx window is not raised (step 425). If the WL is less than RxWMAX, then the next PDU or PDUs are received without discarding PDUs having SNs following the highest received SN, and the upper end of the Rx window is raised (430).

The setting of RLC transmitter and receiver state variables using the octet-based method will be described hereinafter. When the RRC layer sets a flexible RLC PDU size mode and the RLC operates in AM, AM data RLC PDUs will be numbered modulo an integer sequence number that is cycled through in a certain area. Typically, this area ranges from 0 to 4095, although RRC or other upper layers may be configured with different maximum values. Recall that the arithmetic operations for vt(s), (vt (a), (vt (ms), (vr) (r), (vr) (h), and vr (mr) are affected by the SN modulus.

A parameter or state variable Maximum Tx Window Size in octets may be maintained by the RLC transmitter. This parameter is initially set equal to the protocol parameter Configured _ Tx _ Window _ Size (Configured transmission Window Size) sent by the upper layer in octets and can be updated later as an octet parameter indicated by the Window Size SUFI in the RLC STATUS PDU. The state variable vt (ws) may be derived from Maximum Tx Window Size in octets and may be set to the largest non-negative integer no greater than 4095 (or the Maximum of RRC/high layer configuration), whereby the octet length of the Window defined by vt (a) and vt (a) + vt (ws) does not exceed Maximum Tx Window Size in octets. When Maximum _ Tx _ Window _ Size in octet is updated, the state variable vt (ws) is also updated. Alternatively, the state variable vt (ws) may be obtained as a non-negative integer no greater than 4095 (or the maximum configured by RRC/upper layers), whereby the octet length of the window defined by vt (a) and vt (a) + vt (ws) does not exceed:

the protocol parameter Configured _ Tx _ Window _ Size in octets, and

window size SUFI mentioned for the octet parameter in the RLC STATUS PDU as defined above.

The state variable vt (ms) is an SN calculated as vt (ms) ═ vt (a) + vt (ws), where vt (ws) is obtained as described above. The state variable vr (mr) is the SN derived from the Configured _ Rx _ Window _ Size in octets sent from the upper layer, whereby the octet length of the Window defined by vr (r) and vr (mr) will be as large as possible, but not exceed the Configured _ Rx _ Window _ Size in octets.

Enhancement of RLC PDU creation processing

Fig. 5 shows a flow chart of a method of an octet based enhanced RLC PDU creation process 500 for uplink and downlink, where the process is based on the following parameters:

current _ Credit: in the uplink, it is the amount of data that can be transmitted according to MAC link adaptation, and the amount of data is transmitted by MAC to RLC in a UE or in a node B in a planar architecture system such as Long Term Evolution (LTE) and Wideband Code Division Multiple Access (WCDMA) system eighth edition. In the downlink it is the result of the remaining credit allocation added to any new credit allocation sent from the node B to the RNC. The parameter is represented by octets.

Available _ Data: this parameter is the data that can be transmitted in the RLC. The parameter is represented by octets.

Leftover _ Window: this parameter is the window length defined by vt(s) and vt (ms) in the RLC transmitter. This parameter is represented by octets.

Maximum _ RLC _ PDU _ size: this parameter is the maximum RLC PDU size configured by an upper layer such as the RRC layer.

Minimum _ RLC _ PDU _ size: this parameter is a parameter configured by an upper layer such as an RRC layer, and it specifies a minimum RLC PDU size. Alternatively, the upper layer may specify a Minimum RLC PDU payload size, and Minimum _ RLC _ PDU _ size may be derived therefrom.

Once the RLC PDU generation process is initiated, the following parameters are calculated in each Transmission Time Interval (TTI) (step 505):

x Min { Current _ Credit, Available _ Data, Leftover _ Window } equation (3)

Floor { X/Maximum _ RLC _ PDU _ size } equation (4)

X mod Maximum _ RLC _ PDU _ size equation (5)

Where the function Min {. cndot. } returns the minimum value in the set, the function Floor {. cndot. } returns the nearest rounded-down integer value, and a mod b is a division of a modulo b. N RLC PDUs of size Maximum _ RLC _ PDU _ size are generated (step 505). Alternatively, if L is not zero, one additional RLC PDU may be created for the TTI. X will be determined to be equal to the Leftover _ Window or Current _ Credit parameter (step 510). If so, it is determined whether L is greater than the Minimum _ RLC _ PDU _ size parameter or X is equal to Available _ Data (515). If L is greater than Minimum _ RLC _ PDU _ size, or if X is equal to Available _ Data, an RLC PDU of length L is generated (520). Also, if X is not equal to Leftover _ Window or Current _ Credit, an RLC PDU of length L is also generated (520). Alternatively, if L is smaller than Minimum _ RLC _ PDU _ size, an RLC PDU of size Minimum _ RLC _ PDU _ size may be created. The generated one or more RLC PDUs are stored in a buffer for transmission (525). The method 500 may be repeated every TTI or alternatively when data is available or requested by lower layers (530).

The result of the above method 500 is: the number of PDUs generated in this period, which is typically a TTI or some other system specified period, equal to the Maximum RLC PDU size, is equal to the largest non-negative integer less than Min { Current _ Credit, Available _ Data, Leftover _ Window }/Maximum _ RLC _ PDU _ size. If Min { Current _ Credit, Available _ Data, Leftover _ Window } ═ Current _ Credit, then another RLC PDU may also be generated in the same time period equal in size to Min { Current _ Credit, Leftover _ Window, Available _ Data } mod Maximum RLC _ PDU _ size. If Min { Current _ Credit, Available _ Data, Leftover _ Window } - [ Available _ Data ], then another RLC PDU may also be generated in the same period of time equal in size to Min { Current _ Credit, Leftover _ Window, Available _ Data } modMaximum _ RLC _ PDU _ size. If Min { Current _ create, Available _ Data, Leftover _ Window }, is Leftover _ Window, then another RLC PDU may also be generated in the same time period of size equal to Min { Current _ create, Leftover _ Window, Available _ Data } modMaximum _ RLC _ PDU _ size, if and only if the length of this PDU is greater than Minimum _ RLC _ PDU _ size.

The creation process of flexible size RLC PDUs may also be applied without Minimum _ RLC _ PDU _ size and/or Maximum _ RLC _ PDU _ size limits. Alternatively, maximum and minimum RLC PDU size limits may be defined and the transmitter may be allowed to select a size in conjunction with these limits without the need for TTI-based association with MAC layer link adaptation.

As an alternative to the enhanced PDU creation process, the current state variable for fixed RLC PDU sizes will be maintained and can be used simultaneously with a set of entirely new variables for handling byte counts of flexible RLC PDUs. In particular, some values maintained according to the number of PDUs and handled as non-enhanced RLC may include:

RLC transmitter state variables: VT (S), VT (A), VT (MS), VT (WS)

RLC receiver state variables: VR (R), VR (H), VR (MR)

Vt (ws) is kept according to the maximum number of PDUs and it is initially Configured by higher layers based on the Configured _ Tx _ Window _ size parameter provided in the form of the number of PDUs. This value may correspond to the maximum number of PDUs allowed to be provided to the window and/or to the maximum number of PDUs limited by the number of bits used for the sequence number. For example, if 12 bits are used, then the PDU that can be supported is 2¹²Or 4096. Alternatively, for a variable RLC PDU size, vt (ws) may be prohibited from being updated by the receiver by using WINDOW SUFI (WINDOW size super field). Preferably, the calculations regarding vt (ms) are kept the same, wherein vt (ms) ═ vt (a) + vt (ws). In addition, other receiver state variables may also be maintained and processed in accordance with 3GPP legacy standards.

In addition to these variables, those variables used to process the byte count for the transmitter and receiver are maintained and processed. Some variables that can be used are listed below and are assumed to be held in terms of bytes. The names of these variables are for descriptive purposes and any name may be provided. The variables include:

configuration _ Tx _ Window _ size _ bytes-this protocol parameter indicates the maximum allowable transmission Window in octets and the value for the state variable vt (ws) _ bytes. For example, the variable may be configured in any of the following ways: by higher layers, by the network, pre-configured in the UE, or determined by the UE based on memory requirements or UE classification.

Vt (ws) _ bytes-the transmission window size given in octets. The state variable contains the size in octets that should be used for the transmission window. Alternatively, when the transmitter receives a STATUS PDU containing WINDOW _ BYTE SUFI, VT (WS) BYTEs should be equal to the WSN field. The initial and maximum values of the state variables are given by Configure _ Tx _ Window _ size _ bytes.

Window _ utilization: TX in bytes uses the window length. For each new transmission, the byte count is incremented by the size of the RLC PDU to be first transmitted. For each discarded PDU, the byte count is decremented by the size of the RLC PDU to be discarded.

RxWMAX: the maximum Rx window size provided by the higher layers in octets has a length in bytes.

RxWUTIL: rx in bytes has used the length of the window. The variable is incremented by the size of the received RLC PDU when a new RLC PDU is received, and decremented by the size of the RLC PDU when the RLC PDU is removed from the buffer.

RxN: length in bytes of the simultaneously received PDU.

By combining the old and new state variables, the RLC may be allowed to control the Tx and Rx windows according to the maximum number of bytes allowable and according to the maximum number of PDUs allowable (limited by the number of sequence numbers available for transmission).

RLC procedures affected by introduction of flexible RLC PDU sizes

In 3GPP TS25.322, certain procedures may be updated as described in the teachings herein to support and manage Tx and Rx windows for flexible RLC PDUs, including the following procedures:

AMD PDU transmission

Submit AMD PDUs to lower layers

Reception of AMD PDU by receiver

Reception of AMD PDU by receiver

Receiving AMD PDUs outside the receive Window

The procedures associated with the reconfiguration and re-initialization of Tx and Rx state variables may be updated.

Transmission of Acknowledged Mode Data (AMD) PDUs

For fixed RLC PDUs, the transmitter must ensure that the SN of the AMDPDU is less than the maximum transmission variable vt (ms) when retransmitting the AMD PDU. For retransmitted AMD PDUs, if the receiver uses WINDOW SUFI to update the WINDOW size, the SN of the retransmitted AMD PDU may be larger than vt (ms).

For variable RLC PDU sizes, the transmitter may also use the state variable vt (ws) bytes to check that the Tx window usage up to the AMD PDU to be retransmitted does not exceed the maximum window size in bytes. The state variable Window _ utilizing is the total size of the transmitted RLC PDUs in the retransmission buffer. Thus, when checking this condition, it is necessary to independently calculate the usage up to the retransmission SN. This condition is automatically satisfied if Window _ animation is less than VT (WS) _ bytes. However, if window _ animation is larger than VT (WS) -bytes, then the buffer usage up to AMD PDU must be calculated to ensure it does not exceed VT (WS) -bytes. Thus, alternatively, if window _ animation exceeds the state variable VT (WS) _ bytes, then cache usage is calculated.

For example, the AMD PDU transmission procedure can be modified to account for the fixed and variable RLC PDU sizes signaled by the upper layer as follows:

if a fixed RLC PDU size is configured, then:

for each AMD PDU with a negative acknowledgement:

if the AMD PDU SN is less than VT (MS):

scheduling AMD PDUs for retransmission;

if a flexible RLC PDU size is configured, then:

for each AMD PDU with a negative acknowledgement:

if (1) the window usage up to the AMD PDU SN is less than VT (WS) bytes, where the condition is always true if window _ optimization < VT (WS) bytes, or the condition is calculated as a used window up to the SN, and (2) optionally, if the AMD PDU SN is less than VT (M):

scheduling AMD PDUs for retransmission.

Submitting AMD PDUs to lower layers

In the conditions that allow transmission of AMD PDUs, one of the conditions is that the AMD PDU is less than the state variable VT (MS). When configuring a flexible RLC PDU size, it is checked whether an additional condition is met that the window usage for transmitted or retransmitted PDUs does not exceed the maximum window size in bytes. The lower layers include the MAC layer and the physical layer.

According to one approach, if one or more AMD PDUs are scheduled for transmission or retransmission (see 3GPP TS25.322 v7.1.0 sub-clause 11.3.2 for a related example), the sender may:

not submitting any AMD PDU that is not allowed to be transmitted to lower layers. When a fixed RLC PDU size is configured, if an AMD PDU has a SN less than vt (ms), or if an AMD PDU has a SN equal to vt(s) -1, then this AMD PDU will be allowed to be transmitted. If a flexible RLC PDU is configured, then if (1) it has a SN less than VT (MS), or alternatively, an AMD PDU has a SN equal to VT (S) -1, and (2) if the transmitted AMD PDU does not cause window usage determined by window _ arbitration + AMD PDU size to exceed VT (WS) -bytes, then this AMD PDU is allowed to be transmitted. Furthermore, if the AMDPDU is not restricted to be transmitted by the partial suspension function (see 3GPP TS25.322 v7.1.0 subclause for related examples), the AMD PDU is allowed to be transmitted.

Simultaneously advertising to the lower layer the number of AMD PDUs scheduled for transmission and retransmission and the number of AMD PDUs allowed for transmission or retransmission. Alternatively, if a flexible RLC PDU size is configured, the sender may inform the lower layers of the number of bytes to be scheduled.

Set AMD PDU, for example, according to 3GPP TS25.322 V7.1.0 sub-clause 11.3.2.1.

The number of AMD PDUs requested is submitted to the lower layers. Alternatively, if a flexible RLC PDU size is configured, the sender may also submit the number of bytes requested by the lower layer to the lower layer.

Handling retransmissions of AMD PDUs with higher priority than the first transmission.

Update the status variable for each AMD PDU submitted to the lower layers except vt (dat) (see 3GPP TS25.322 v7.1.0 sub-clause 9.4 for relevant examples regarding status variables), where the vt (dat) counts the number of times AMD PDUs are scheduled for transmission and has been updated at the time the AMD PDU content is set (see 3GPP TS25.322 v7.1.0 sub-clause 11.3.2 for relevant examples).

If a flexible RLC PDU size is configured, the window _ negotiation variable is updated, thereby updating the variables associated with the process of keeping track of the byte count.

If (1) the Poll bit in any AMD PDU that the transmitter requests status reports from the receiver is set to "1" and (2) a Timer _ Poll is configured to track AMD PDUs that contain polls indicated by the lower layers, a Timer _ Poll is started (see 3GPP TS25.322 v7.1.0 subclause 9.5 for a related example).

Buffering those AMD PDUs that are not submitted to the lower layers according to the discard configuration (see 3GPP TS25.322 v7.1.0 subclause 9.7.3 for a relevant example).

Receiver receiving AMD PDU

The procedures associated with the receiver's process of receiving AMD PDUs will be updated to include and update those receiver state variables associated with the byte count for the flexible RLC PDU size. The enhanced procedure is defined below. Upon receiving an AMD PDU, the receiver should:

in the UE:

if the downlink AMD PDU size has not been set, then

Set the downlink AMD PDU size to be the size of the received PDU.

Update receiver state variables vr (r), vr (h) and vr (mr) for each AMD PDU received (see 3GPP TS25.322 v7.1.0 clause 9.4 for relevant examples);

if a flexible RLC PDU size is configured, then

Update the RxWUTIL state variable by setting RxWUTIL equal to the result of the RxWUTIL being added to the newly received RLC PDU size and subtracting the size of the RLC PDU removed from the buffer because of in-order reception.

Receiving AMD PDUs outside of a receive window

If a fixed RLC PDU size is configured, then upon receiving an AMD PDU with an SN outside of interval VR (R). ltoreq.SN < VR (MR), the receiver should:

discard this AMD PDU;

if the poll bit in the discarded AMD PDU is set to "1", then:

start the STATUS PDU conversion procedure.

If a variable RLC PDU size is configured, the receiver should either, when receiving a new AMD PDU added to RxWTIL whose size exceeds RxWMAX (where RxWMAX < RxWTIL + size of the newly received AMD PDU or RxN), or when receiving an AMD PDU with an SN outside of the interval VR (R) ≦ SN < VR (MR):

discard this AMD PDU;

if the poll bit in the discarded AMD PDU is set to "1", then:

start the STATUS PDU conversion procedure.

RLC status reporting

In different scenarios, the RLC Tx and RLC Rx entities may trigger an RLC status report containing acknowledgement information to support ARQ. To handle variable RLC PDU sizes, the RLC Tx and RLC Rx entities may maintain a mapping of RLC PDU SNs to corresponding PDU lengths in bytes. This allows the length of the used flow control window in bytes or other byte-based metrics as described above to be calculated and maintained.

The RLC transmitter may trigger a status report by setting a poll bit when the used Tx window size exceeds some threshold percentage of the maximum window size configured by the system. The RLC receiver may trigger a status report when the used Rx window exceeds some threshold percentage of the maximum window size configured by the system.

The equivalent parameter to each Poll _ PDU is the upper limit of the state variable vt (PDU) used for trace polling and can be configured in terms of bytes. In this case, the transmitter may have a PDU count polling mechanism and a byte count polling mechanism, whereby the transmitter will Poll the receiver for each Poll _ Bytes byte. For the purposes of description, it is assumed herein that the polling parameters provided by the higher layers are referred to as Poll _ Bytes. If configured for polling, the RLC transmitter may trigger a status report by setting the poll bit in certain PDUs as follows:

the RLC transmitter maintains a counter of the total number of bytes transmitted in the PDU since the transmission of the last PDU containing polling bits, which can be generated by any type of polling trigger, including for example Poll PDU, Poll SDU or Poll bytes, or alternatively the last PDU can be limited to contain polling bits triggered by the byte polling mechanism.

When the counter reaches or exceeds the value Poll _ Bytes, the RLC transmitter sets the polling bit in the PDU (or alternatively the next PDU) that caused the counter to exceed the value Poll _ Bytes and resets the counter.

Here, setting the polling bit refers to a polling request, whereby the polling request may comprise a poll PDU, or it may also comprise a polling bit setting in an AMD RLC PDU. The total number of bytes transmitted in the PDU may refer to the size of the PDU transmitted first. Alternatively, it may refer to the total number of all transmitted bytes, including retransmissions. The total number of all transmitted PDUs counted may count only the first transmission of an RLC Acknowledged Mode Data (AMD) PDU, an RLC AMD PDU segment, or a portion of an RLC SDU, where retransmissions of these data portions may not count.

The protocol parameters Poll _ PDU and Poll _ SDU are signaled by an upper layer, such as RRC, to the RLC layer to indicate the PDU count interval. In addition, the protocol parameter Poll _ Bytes in octets may be signaled and configured by higher layers. In the RLC transmitter, the polling procedure includes the following processes:

the RLC transmitter maintains a variable Poll _ Octets counter to track the total number of bytes transmitted in a PDU since the last PDU containing the Poll bit was transmitted, e.g., because the parameter Poll _ PDU from the upper layer was received,

Poll _ SDU or Poll _ Bytes. Alternatively, Poll _ Octets may track the total number of bytes transmitted from the last PDU containing the Poll bit triggered only by the byte polling mechanism.

When the Poll _ Octets counter reaches the Poll _ Bytes interval value, the RLC transmitter sets a polling bit in the PDU (or the next PDU as an option) that caused the Poll _ Octets counter to exceed the Poll _ Bytes threshold value and resets the Poll _ Octets counter. Also, the Poll _ Octets counter may be reset as well if the Poll bit is set because of other polling conditions such as receipt of Poll _ PDU.

When a flexible RLC PDU size for AM RLC is supported, the RRC layer sets a flexible RLC PDU size mode and the upper layer configures a Window-based polling process, and signals a protocol parameter Poll _ Window to the RLC to inform the transmitter of polling the receiver. The transmitter will trigger a Poll for each AMDPDU when the value K is greater than or equal to the parameter Poll _ Window, where K is the transmission Window percentage defined as follows:

k is utilized _ Window/Maximum _ Tx _ Window _ Size (in octets)

Equation (6)

Wherein utilized _ window is a window length in octets defined by state variables VT (A) and VT (S). The utilized _ window represents a buffer for the data remaining in the transmission buffer.

Poll _ Window indicates when the transmitter should Poll the receiver in case "Window based polling" is configured in the upper layer. When the value J is greater than the parameter Poll _ Window, polling will be triggered for each AMD PDU, where J is the transmission Window percentage defined as:

equation (7)

Where the constant 4096 is the modulus for AM described in 3GPP TS25.322 v7.1.0 sub-clause 9.4, vt(s) is the initial value of Poll _ Window before submission of AMD PDUs to lower layers.

If a flexible RLC PDU size is configured, then a Poll is also triggered for each AMD PDU when the value K is greater than the parameter Poll _ Window, where K is defined as:

although the teachings herein are described in terms of RLC transmission (Tx) and reception (Rx) entities, it is equally applicable to uplink (UE to UTRAN/E-UTRAN) and downlink (UTRAN/E-UTRAN to UE) communications. For example, in the uplink direction, the configuration/reconfiguration of the parameter Configured _ Tx _ Window _ Size will result in:

UE derives the State variable VT (WS) from Configured _ Tx _ Window _ Size in the manner described above

The UE updates the state variable vt (ms) in the manner described above.

Examples

1. A method for enhancing Packet Data Unit (PDU) operation in a Radio Link Control (RLC) entity configured to support variable RLC sizes.

2. The method of embodiment 1, comprising: the window size is defined and managed according to a byte count based window size metric.

3. The method of any preceding embodiment, wherein the defining and managing of the window size is based on a window size metric comprising a number of bytes.

4. The method of any preceding embodiment, wherein the defining and managing of the window size is based on a window size metric comprising a number of blocks, wherein each block is a fixed number of bytes.

5. A method as in any preceding embodiment wherein the defining and managing of the window size is further based on a Packet Data Unit (PDU) sequence number.

6. The method of any preceding embodiment, further comprising: the window size metric is included in the RLC control PDU.

7. The method of any preceding embodiment, further comprising: the window size metric is included in the RLC status PDU.

8. The method of any preceding embodiment, further comprising: the maximum RLC PDU payload size is received from the higher layer.

9. The method of embodiment 8, further comprising: the maximum RLC PDU size is inferred from the maximum RLC PDU payload size.

10. The method of any preceding embodiment, further comprising: the maximum RLC PDU size is received from the higher layer.

11. The method of any preceding embodiment, further comprising: a byte count based window size metric is received and negotiated in establishing a radio bearer.

12. The method of any preceding embodiment, further comprising: a byte count based window size metric is received and negotiated in configuring a radio bearer.

13. The method of any preceding embodiment, further comprising: a byte count based window size metric is received and negotiated in reconfiguring a radio bearer.

14. The method of any preceding embodiment, further comprising: the byte-based window size metric is applied in all messaging that updates the window for flow control during the connection.

15. The method of embodiment 14 wherein applying the window size metric across all messaging causes the messaging to include a window size super field (SUFI) in an RLC control and status PDU.

16. The method as in any embodiments 14-15 wherein the act of applying the window size metric across all messaging is to cause the messaging to include a Moving Receive Window (MRW) SUFI in the RLC control and status PDU.

17. A method as in any preceding embodiment wherein an RLC entity operates in Acknowledged Mode (AM).

18. The method of embodiment 17, further comprising: receiving, from a Radio Resource Control (RRC) entity, a radio bearer information element including selection downlink RLC mode information including a new indicator for a flexible RLC PDU size mode in addition to other RLC modes.

19. The method as in any embodiments 17-18, further comprising: receiving a radio bearer information element from a Radio Resource Control (RRC) entity, wherein the information element comprises an information element for indicating a flexible RLC PDU size mode.

20. The method as in any embodiments 17-19, further comprising: receiving a radio bearer information element from a Radio Resource Control (RRC) entity, wherein the information element includes downlink RLC PDU size information indicating one of an RLC scaling parameter in octets or a maximum RLC PDU size in a flexible RLC PDU size mode.

21. The method as in any embodiments 17-20, further comprising: receiving a radio bearer information element from a Radio Resource Control (RRC) entity, wherein the information element comprises RRC signaled protocol parameters including Poll _ PDU, Poll _ SDU, Configured _ Tx _ Window _ Size, and Configured _ Rx _ Window _ Size.

22. The method of embodiment 21 wherein the protocol parameters are specified and interpreted in at least one of number of PDUs and byte units.

23. The method as in any embodiments 17-22, further comprising: receiving RLC PDUs for transmission, and retaining the received RLC PDUs and not submitting the RLC PDUs to a lower layer when the window usage exceeds the maximum window size in bytes or when the received RLC PDU sequence number exceeds the maximum window size in PDU number.

24. The method as in any embodiments 17-22, further comprising: a window size super field (SUFI) referring to an octet parameter is received from the RRC entity in the RLC STATUS PDU.

25. The method of embodiment 24 wherein the window size SUFI is specified in units of number of PDUs.

26. The method of embodiment 25 further comprising deriving the window size in octets by multiplying the number of PDUs by an RLC scaling parameter in octets.

27. The method of embodiment 24 wherein the WINDOW size SUFI is specified in BYTES as a new SUFI WINDOW _ BYTES having a type, length, and value component.

28. A method in a Radio Link Control (RLC) entity for enhancing RLC operation, wherein the RLC entity is configured to support a variable Packet Data Unit (PDU) size with a maximum RLC PDU size, the method comprising: RLC flow control is performed using a byte count based metric.

29. The method of embodiment 28, further comprising: RLC status reporting is performed using a byte count based metric.

30. The method as in any embodiments 28-29, wherein the RLC entity is configured as an RLC transmission entity in the transmitter, and the method further comprises: if the receiver acknowledges one or more PDUs, the RLC transmission window is updated when the RLC transmission operation is performed.

31. The method as in any embodiments 28-29, wherein the RLC entity is configured as an RLC transmission entity in the transmitter, and the method further comprises: if the receiver negatively acknowledges one or more PDUs because the maximum number of retries is exceeded, the RLC transmission window is updated when the RLC transmission operation is performed.

32. The method as in any embodiments 28-29, wherein the RLC entity is configured as an RLC transmission entity in the transmitter, and the method further comprises: the RLC transmission window is updated when an RLC transmission operation is performed as a result of a timer-based discard process in the transmitter.

33. The method as in any embodiments 30-32, wherein updating the RLC transmission window comprises: removing one or more PDUs from the used transmission window and raising the lower end of the used transmission window.

34. The method of embodiment 33, further comprising: the following parameters were determined: TxWMAX equal in length in bytes to the maximum window size; TxWUTIL equal to the length in bytes of the transmission window that has been used, or equal to one of the lengths in bytes of the packets that get acknowledgements inside the window defined by the transmission state variables v (a) and v (t); TxL equal to one of a length in bytes of one or more PDUs discarded due to the RLC SDU discard procedure or a length in bytes of one or more acknowledgements received; and TxN equal to a length in bytes of the next PDU or PDUs to be transmitted first.

35. The method of embodiment 34, further comprising: the Window Length (WL) parameter WL ═ TxWUTIL-TxL + TxN is calculated.

36. The method of embodiment 35, further comprising: if WL is smaller than TxWMAX, the next PDU or PDUs are transmitted and the upper end of the used transmission window is raised.

37. The method as in any embodiments 28-29, wherein the RLC entity is configured as an RLC receiving entity, and the method further comprises: if one or more PDUs are received by the RLC receiving entity and the sequence number of these PDUs follows the sequence number of the last in-sequence received PDU, the RLC reception window is updated when the RLC reception operation is performed.

38. The method as in any embodiments 28-29, wherein the RLC entity is configured as an RLC receiving entity, and the method further comprises: if the RLC receiving entity receives a Move Receive Window (MRW) instruction from the RLC transmitting entity, the RLC receive window is updated when the RLC receive operation is performed.

39. The method as in any embodiments 37-38, wherein the sequence numbering comprises raising a lower end of a used receive window.

40. The method of embodiment 39, further comprising: the following parameters were determined: a parameter RxWMAX equal to the length in bytes of the maximum window size; RxWUTIL equal in length in bytes to the used receive window; RxD equal to the length in bytes of one or more PDUs removed from the RLC receive window due to in-order reception; and RxN equal to a length in bytes of the next PDU or PDUs to be first received.

41. The method of embodiment 40, further comprising: the Window Length (WL) parameter WL ═ RxWUTIL + RxN-RxD is calculated.

42. The method of embodiment 40, further comprising: if WL is less than RxWMAX, the next PDU or PDUs are received and the upper end of the used receive window is raised.

43. The method as in any embodiments 28-41, further comprising: RLC PDUs are created at each time interval by defining the following parameters: current _ Credit equal to the amount of data that can be transmitted based on MAC link adaptation in the uplink and the result in octets of the remaining Credit allocation added to the new Credit allocation received in the downlink; available _ Data equal to Data in octets Available for transmission in RLC PDU format; leftover _ Window equal to the Window length in octets defined by the state variables vt(s) and vt (ms) in the RLC transmitter; maximum _ RLC _ PDU _ size equal to the Maximum RLC PDU size configured by the upper layer; and Minimum _ RLC _ PDU _ size equal to a parameter configured by an upper layer to specify one of a Minimum RLC PDU size or a Minimum RLC PDU payload size.

44. The method of embodiment 43, further comprising: the parameter X {. Min { Current _ Credit, Available _ Data, Leftover _ Window } is calculated, where Min {. returns the minimum value in the set.

45. The method as in any embodiments 43-44, further comprising: the parameter N is calculated as Floor { X/Maximum _ RLC _ PDU _ size }, where Floor {. returns the nearest rounded-down integer value and a mod b.

46. The method as in any embodiments 43-45, further comprising: calculate L ═ Xmod Maximum _ RLC _ PDU _ size, where the division of a modulo b is returned.

47. The method as in any embodiments 45-46, further comprising: n PDUs equal in length to Maximum _ RLC _ PDU _ size are generated.

48. The method of embodiment 47, further comprising: if X is not equal to Leftover _ Window or Current _ Credit, another RLC PDU of length L is generated.

49. The method as in any embodiments 47-48, further comprising: if X is equal to Leftover _ Window or Current _ Credit, and L is greater than Minimum _ RLC _ PDU _ size or X is equal to Available _ Data, another RLC PDU of length L is generated.

50. The method as in any embodiments 47-49, further comprising: if X is equal to Leftover _ Window or Current _ Credit, and L is not greater than Minimum _ RLC _ PDU _ size, another RLC PDU of length size Minimum _ RLC _ PDU is generated.

51. The method as in any embodiments 47-50, further comprising: the generated RLC PDUs are stored in a buffer for transmission.

52. The method as in any embodiments 43-51, wherein the time interval is defined by a multiple of 1 or more Transmission Time Intervals (TTIs).

53. A method as in any of embodiments 43-51 wherein the time interval is defined by a time instance when data is available for transmission or requested from a lower layer.

54. The method as in any embodiments 43-53, wherein Maximum _ RLC _ PDU _ size and Minimum _ RLC _ PDU _ size are not configured by an upper layer.

55. The method as in any embodiments 28-54, further comprising: a state variable is maintained, wherein the state variable is specified and interpreted in terms of the number of PDUs and byte units.

56. The method of embodiment 55 wherein the RLC entity is configured as an RLC transmission entity and the method further comprises: a state variable Maximum Tx Window Size is maintained, where the state variable represents the Maximum transmission Window Size in octets.

57. The method of embodiment 56, further comprising: the state variable Maximum _ Tx _ Window _ Size is updated to the octet parameter specified by the Window Size super field (SUFI) in the received RLC status PDU.

58. The method as in any embodiments 56-57, further comprising: the following state variables were maintained: a send state variable vt(s), an acknowledge state variable vt (a), a maximum send state variable vt (ms), and a transmission window size state variable vt (ws).

59. The method of embodiment 58, further comprising: the state variables vt(s), vt (a), vt (ms) and vt (ws) are updated according to the state variables Maximum _ Tx _ Window _ Size in octet units.

60. The method of embodiment 55 wherein the RLC entity is configured as the RLC receiving entity and the method further comprises: a state variable Maximum Rx Window Size is maintained, where the state variable represents the Maximum receive Window Size in octets.

61. The method of embodiment 60, further comprising: the state variable Maximum _ Rx _ Window _ Size is received from an upper layer.

62. The method of embodiment 61, further comprising: the following state variables were maintained: a received state variable vr (r), a highest expected state variable vr (h), and a maximum acceptable received state variable vr (mr).

63. The method of embodiment 62, further comprising: the state variables VR (R, VR (H) and VR (mr) are updated according to the state variable Maximum _ Rx _ Window _ Size in octet units.

64. The method as in any embodiments 28-63, further comprising: RLC polling mechanisms are defined and managed using byte count based metrics.

65. The method of embodiment 64, further comprising: the following parameters are defined: current _ Credit equal to the amount of data that can be transmitted based on the result of MAC link adaptation in the uplink and the addition of the remaining Credit allocation in the downlink and the new Credit allocation received in octets; available _ Data with Data in octets Available for transmission in RLC PDU format; leftover _ Window equal to the Window length in octets defined by the state variables vt(s) and vt (ms) in the RLC transmitter.

66. The method of embodiment 65, further comprising: the calculation parameter X ═ Min { Current _ Credit, Available _ Data, Leftover _ Window }.

67. The method of embodiment 66, further comprising: when the used window size in octets is greater than X, a poll is triggered in an Acknowledged Mode Data (AMD) PDU.

68. The method as in any embodiments 28-67, further comprising: polling is triggered in an AMD PDU each time when the total amount of data transmitted exceeds a predetermined amount known as octets or data blocks.

69. The method of embodiment 68, further comprising: when the Window-based polling is configured by upper layers, the receiver is polled using the protocol parameter Poll _ Window.

70. The method of embodiment 68, further comprising: triggering polling for each Acknowledged Mode Data (AMD) PDU when a transmission Window percentage, K, is greater than or equal to Poll _ Window, where K is defined as in octets as follows: k ═ utilized _ Window/Maximum _ Tx _ Window _ Size, and where utilized _ Window is the Window length in octets defined by the state variables vt (a) and vt(s).

71. The method as in any embodiments 28-70, wherein protocol parameters Poll _ PDU and Poll _ SDU are received at an RLC transmission entity from an upper layer to indicate a PDU count interval.

72. The method as in any embodiments 28-71, wherein the octet-by-octet protocol parameter Poll _ Bytes is configured to indicate a byte count interval between polls.

73. The method of embodiment 72, further comprising: the RLC transmission entity maintains a variable Poll _ Octets counter that counts the total number of bytes transmitted in the PDU since the transmission of the last PDU that triggered the polling request.

74. The method of embodiment 72, further comprising: when the Poll _ Octets counter is greater than or equal to the value of Poll _ Bytes, the RLC transmitting entity triggers a polling request in the PDU causing the Poll _ Octets counter to exceed the Poll _ Bytes and resets the Poll _ Octets counter.

75. The method as in any embodiments 73-74, wherein a Poll _ Octets counter counts a total number of bytes of a first transmitted PDU.

76. The method as in any embodiments 73-74, wherein a Poll _ Octets counter counts a total number of bytes of all transmitted PDUs including retransmissions.

77. The method as in any embodiments 73-76, wherein the triggering of the polling request comprises: a polling bit is set in the PDU causing the Poll _ Octets counter to exceed the Poll _ Bytes.

78. The method as in any embodiments 73-76, wherein the triggering of the polling request comprises: the POLL PDU is sent to the receiver.

79. The method of embodiment 78 wherein the last PDU that triggered the Poll request is due to the Poll Bytes mechanism.

80. The method of embodiment 78 wherein the last PDU that triggered the polling request is attributed to a Poll PDU or a Poll SDU.

81. The method as in any embodiments 67-68, wherein a protocol parameter Poll _ Window is received at an RLC transmitting entity from an upper layer.

82. The method of embodiment 81, further comprising: when the Window-based polling process is configured by the upper layer, Poll _ Window is used to Poll the receiver.

83. The method of embodiment 82, further comprising: the transmitter triggers a Poll for each Acknowledged Mode Data (AMD) PDU when the value J, where J is defined asAnd wherein 4096 is a modulus for an Answer Mode (AM) and vt(s), vt (a) and vt (ws) are state variables.

84. The method of embodiment 83, further comprising: triggering polling for each AMD PDU when a value K is greater than or equal to Poll _ Window, where K is defined as

85. A method as in any preceding embodiment wherein the method is performed by an RLC entity.

86. A wireless transmit/receive unit (WTRU) comprising the RLC entity of embodiment 85.

87. A node B comprising the RLC entity of embodiment 85.

88. A Radio Network Controller (RNC) comprising the RLC entity of embodiment 85.

89. A method of Radio Network Controller (RNC)/node B flow control for downlink data when a variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported, the method comprising: credit allocations in bytes are signaled.

90. The method of embodiment 89, wherein signaling credit allocations in bytes comprises: information specifying the number of bytes of credit is added to the frame.

91. The method as in any embodiments 89-90, further comprising: the information specifying the number of PDUs for that credit is removed from the frame.

92. The method as in any embodiments 89-91, wherein the method is performed by an RLC entity.

93. A node B comprising the RLC entity of embodiment 92.

94. A method for RNC/node B flow control of downlink data when variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported, the method comprising: a credit allocation in bytes is received.

95. The method of embodiment 94, wherein receiving a credit allocation in bytes comprises: receiving a frame, wherein the frame includes information specifying a number of credit bytes.

96. The method as in any embodiments 94-95, further comprising: the maximum size of the PDU in bytes is stored.

97. The method of embodiment 96, wherein receiving a credit allocation in bytes comprises: receiving a frame, wherein the frame includes information specifying a number of PDUs to credit.

98. The method of embodiment 97, further comprising: the number of PDUs credited is multiplied by the maximum size of the PDU in bytes.

99. The method as in any embodiments 94-98, further comprising: a mapping of PDU SN to the associated length in bytes is stored.

100. The method of embodiment 99, further comprising: the PDUs are transmitted without exceeding the received credit allocation.

101. The method as in any embodiments 94-100, wherein the method is performed by an RLC entity.

102. A Radio Network Controller (RNC) comprising the RLC entity of embodiment 101.

103. The RNC of embodiment 102 wherein the RNC is configured as a serving RNC (srnc).

104. The RNC of embodiment 102 wherein the RNC is configured as a drift RNC (drnc).

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 the computer-readable storage medium 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 discs and Digital Versatile Discs (DVDs).

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) module or an Ultra Wideband (UWB) module.

Claims (132)

1. A method, in a Radio Link Control (RLC) entity configured to support variable Packet Data Unit (PDU) sizes, for enhancing RLC operation, the method comprising: the window size is defined and managed according to a byte count based window size metric.

2. The method of claim 1, wherein the defining and managing of window sizes is based on a window size metric including at least one of a number of bytes and a number of blocks, and wherein each block is a fixed number of bytes.

3. The method of claim 2, wherein the defining and managing of the window size is further based on a Packet Data Unit (PDU) sequence number.

4. The method of claim 1, further comprising: including the window size metric in an RLC control and status PDU.

5. The method of claim 1, further comprising:

receiving a maximum RLC PDU payload size from a higher layer; and

inferring a maximum RLC PDU size from the maximum RLC PDU payload size.

6. The method of claim 1, further comprising: the maximum rlc pdu size is received from a higher layer.

7. The method of claim 1, further comprising: receiving and negotiating the byte count based window size metric during at least one of an establishment, a configuration, and a reconfiguration of a radio bearer.

8. The method of claim 1, further comprising: the byte-based window size metric is applied in all messaging that updates the window for flow control during the connection.

9. The method of claim 8, wherein applying the window size metric across all messaging causes the messaging to include at least one of a window size hyper field (SUFI) and a Mobile Receive Window (MRW) SUFI in an RLC control and status PDU.

10. The method of claim 1 wherein the RLC entity is operating in Acknowledged Mode (AM).

11. The method of claim 1, further comprising: receiving, from a Radio Resource Control (RRC) entity, a radio bearer information element comprising at least one of:

selecting downlink RLC mode information including a new indicator for a flexible RLC PDU size mode in addition to other RLC modes;

an information element for indicating a flexible RLC PDU size mode;

downlink RLC PDU size information indicating one of an RLC scaling parameter in octets or a maximum RLC PDU size in a flexible RLC PDU size mode; and

protocol parameters signaled by the RRC including Poll _ PDU, Poll _ SDU, Configured _ Tx _ Window _ Size, and Configured _ Rx _ Window _ Size, wherein the protocol parameters are specified and interpreted in at least one of PDU number and byte units.

12. The method of claim 11, further comprising:

receiving an RLC PDU for transmission; and

when the window usage exceeds the maximum window size in bytes or when the received RLC PDU sequence number exceeds the maximum window size in PDU number, the received RLC PDU is retained and not submitted to lower layers.

13. The method of claim 11, further comprising: receiving a window size super field (SUFI) involving an octet parameter in an RLC STATUS PDU from the RRC entity.

14. The method of claim 13, wherein the window size SUFI is specified in units of a number of PDUs, and the method further comprises: deriving a window size in octets by multiplying the number of PDUs by an RLC scaling parameter in octets.

15. The method of claim 13, wherein the WINDOW size SUFI is specified in BYTES as a new SUFI WINDOW BYTES having type, length, and value components.

16. The method of claim 1, further comprising performing RLC flow control using a byte count based metric.

17. The method of claim 1, wherein the RLC entity is configured as an RLC transmission entity in a transmitter, and further comprising: the RLC transmission window is updated when the RLC transmission operation is performed if the receiver acknowledges the one or more PDUs positively or if the receiver acknowledges the one or more PDUs negatively due to the receiver exceeding a maximum number of retries or due to timer-based discard in the transmitter.

18. The method of claim 17, wherein the updating of the RLC transmission window comprises:

removing one or more PDUs from a used transmission window and raising a lower end of the used transmission window;

the following parameters were determined:

TxWMAX, equal to the length of the maximum window size in bytes;

a TxWTIL equal to one of the length in bytes of the used transmission window, or the length in bytes of the packet acknowledged within a window defined by transmission state variables V (A) and V (T);

TxL equal to one of a length in bytes of the one or more PDUs discarded as a result of the RLC SDU discard procedure, or a length in bytes of the one or more PDUs discarded as a result of receipt of the one or more acknowledgements; and

TxN equal to a length in bytes of a next one or more PDUs to be transmitted first;

calculating a Window Length (WL) parameter: WL ═ TxWUTIL-TxL + TxN; and

transmitting the next one or more PDUs and raising the upper end of the used transmission window if WL is less than TxWMAX.

19. The method of claim 1, wherein the RLC entity is configured as an RLC receiving entity, and further comprising: if the RLC receiving entity receives one or more PDUs and the sequence number of these PDUs follows the sequence number of the last in-sequence received PDU or if the RLC receiving entity receives a moving receive window from the RLC transmitting entity

(MRW) instruction, the RLC receive window is updated when the RLC receive operation is performed.

20. The method of claim 19, wherein the updating of the RLC reception window comprises:

raising the lower end of the used receive window;

the following parameters were determined:

RxWMAX, length in bytes equal to the maximum window size;

RxWUTIL equal to the length of the used receive window in bytes;

RxD equal to the length in bytes of one or more PDUs removed from the RLC receive window due to in-order reception; and

RxN, equal to a length in bytes of a next one or more PDUs to be first received;

calculating a Window Length (WL) parameter: WL ═ RxWUTIL + RxN-RxD; and

if WL is less than RxWMAX, the next one or more PDUs are received and the upper end of the used receive window is raised.

21. The method of claim 1, further comprising: an RLC PDU is created at each time interval by:

the following parameters are defined:

current _ Credit equal to the amount of data that can be transmitted based on the MAC link adaptation in the uplink and the result in octets of the remaining Credit allocation added to the new Credit allocation received in the downlink;

available _ Data, equal to the Data in octets Available for transmission in the RLC PDU format;

leftover _ Window, equal to the Window length in octets defined by the state variables vt(s) and vt (ms) in the RLC transmitter;

the following parameters were calculated:

X＝Min{Current_Credit，Available_Data，Leftover_Window}；

where Min {. is returned is the minimum in the set; and

generating a PDU of length X.

22. The method of claim 21, further comprising:

the following parameters are defined:

maximum _ RLC _ PDU _ size, equal to the Maximum RLC PDU size configured by the upper layer;

and

minimum _ RLC _ PDU _ size, equal to a parameter configured by the upper layer to specify one of a Minimum RLC PDU size or a Minimum RLC PDU payload size; and

the PDUs with a size between Minimum _ RLC _ PDU _ size and Maximum _ RLC _ PDU _ size are generated.

23. The method of claim 22, further comprising:

calculating parameters:

floor { X/Maximum _ RLC _ PDU _ size }; and

x mod Maximum _ RLC _ PDU _ size; where Floor {. returns the nearest rounded-down integer value, and a mod b returns the division of a modulo b; and

n PDUs of length equal to Maximum RLC PDU size are generated.

24. The method of claim 23, further comprising:

if X is not equal to Leftover _ Window or Current _ Credit, another RLC PDU with length L is generated;

if X is equal to Leftover _ Window or Current _ Credit, and L is greater than Minimum _ RLC _ PDU _ size or if X is equal to Available _ Data, generating another RLC PDU of length L; and

if X is equal to Leftover _ Window or Current _ Credit, and L is not greater than Minimum _ RLC _ PDU _ size, another RLC PDU of length Minimu _ RLC _ PDU size is generated.

25. The method of claim 24, further comprising: the generated RLC PDUs are stored in a buffer for transmission.

26. The method of claim 21, wherein the time interval is defined by a multiple of 1 or more Transmission Time Intervals (TTIs).

27. The method of claim 21, wherein the time interval is defined by a time instance when data is available for transmission or requested from a lower layer.

28. The method of claim 21, wherein Maximum RLC PDU size and Minimum RLC PDU size are not configured by upper layers.

29. The method of claim 1, further comprising: a state variable is maintained, wherein the state variable is specified and interpreted in terms of the number of PDUs and byte units.

30. The method of claim 29, wherein the RLC entity is configured as an RLC transmission entity, and further comprising:

holding a state variable Maximum _ Tx _ Window _ Size, wherein the state variable represents a Maximum transmission Window Size in octets;

updating a state variable Maximum _ Tx _ Window _ Size to an octet parameter specified by a Window Size hyper field (SUFI) in the received RLC status PDU;

the following state variables were maintained: a transmission state variable VT (S), a response state variable VT (A), a maximum transmission state variable VT (MS) and a transmission window size state variable VT (WS); and

the state variables vt(s), vt (a), vt (ms) and vt (ws) are updated according to the state variables Maximum _ Tx _ Window _ Size in octet units.

31. The method of claim 29, wherein the RLC entity is configured as an RLC receiving entity, and further comprising:

holding a state variable Maximum _ Rx _ Window _ Size, wherein the state variable represents a Maximum receive Window Size in octets;

receiving a state variable Maximum _ Rx _ Window _ Size from an upper layer;

the following state variables were maintained: a reception state variable vr (r), a highest expected state variable vr (h), and a maximum acceptable reception state variable vr (mr); and

the state variables vr (r), vr (h) and vr (mr) are updated according to the state variable Maximum _ Rx _ Window _ Size in units of octets.

32. A method, in a Radio Link Control (RLC) entity configured to support variable Packet Data Unit (PDU) sizes, for enhancing RLC operation, the method comprising: RLC polling mechanisms are defined and managed using byte count based metrics.

33. The method of claim 32, further comprising triggering polling in an Acknowledged Mode Data (AMD) PDU when a used window size in octets is greater than a system configuration threshold in bytes.

34. The method of claim 32, further comprising: polling is triggered in an AMD PDU each time when the total amount of data transferred exceeds a known predetermined number of octets or data blocks.

35. The method of claim 32, further comprising:

polling the receiver using a protocol parameter Poll _ Window when the Window-based polling is configured by an upper layer; and

triggering polling for each Acknowledged Mode Data (AMD) PDU when a transmission Window percentage, K, is greater than or equal to Poll _ Window, where K is defined as in octets as follows:

K＝utilized_window/Maximum_Tx_Window_Size，

wherein utilized _ window is the length in octets of the window defined by the state variables VT (A) and VT (S).

36. The method of claim 32 wherein protocol parameters Poll PDU and Poll SDU are received at the RLC transmission entity from the upper layer to indicate a PDU count interval.

37. The method of claim 32, wherein a protocol parameter Poll Bytes in octets is configured to indicate a byte count interval between polls, and the method further comprises:

maintaining, by said RLC transmission entity, a variable Poll _ Octets counter, wherein said counter counts the total number of bytes transmitted in a PDU since the transmission of the last PDU that triggered the polling request; and

when the Poll _ Octets counter is greater than or equal to the value of Poll _ Bytes, the RLC transmission entity triggers a polling request in the PDU causing the Poll _ Octets counter to exceed Poll _ Bytes and resets the Poll _ Octets counter.

38. The method of claim 37, wherein the Poll _ Octets counter counts a total number of bytes for a first transmission of each Acknowledged Mode Data (AMD) PDU.

39. The method of claim 37, wherein the Poll _ Octets counter counts the total number of bytes of all transmitted PDUs, including retransmissions.

40. The method of claim 37, wherein the triggering of the polling request comprises: setting a Poll bit in the PDU causing the Poll _ Octets counter to exceed the Poll _ Bytes.

41. The method of claim 37, wherein the triggering of the polling request comprises: the POLL PDU is sent to the receiver.

42. The method of claim 37, wherein the last PDU that triggered the Poll request is due to a Poll Bytes mechanism.

43. The method of claim 37, wherein the last PDU that triggered the polling request is attributed to a Poll PDU or a Poll SDU.

44. The method of claim 32, further comprising triggering a poll in an Acknowledged Mode Data (AMD) PDU when a used window size in octets is greater than a threshold percentage of a system configured maximum window size.

45. The method of claim 32, further comprising triggering a status report when a used receive window size is greater than a threshold percentage of a particular system configured maximum window size.

46. The method of claim 32, further comprising triggering a status report when a used receive window size in octets is greater than a system configured threshold in bytes.

47. The method of claim 32, wherein a protocol parameter Poll _ Window is received at the RLC transmission entity from an upper layer, and the method further comprises:

polling the receiver using Poll _ Window when the Window-based polling is configured by the upper layer; and

the transmitter triggers a Poll for each Acknowledged Mode Data (AMD) PDU when a value J is greater than or equal to Poll _ Window, where J is defined as:

where 4096 is a modulus for the Answer Mode (AM), and vt(s), vt (a), and vt (ws) are state variables.

48. The method of claim 47, further comprising:

triggering polling for each AMD PDU when the value K is greater than or equal to the protocol parameter Poll _ Window, where K is defined as:

49. the method of claim 47, wherein the protocol parameter Poll _ Window is measured in number of bytes, the method further comprising:

triggering polling for each AMD PDU when the value K is greater than or equal to the protocol parameter Poll _ Window, where K is defined as:

k is the sum of RLC PDU sizes from vt (a) to vt(s).

50. A wireless transmit/receive unit (WTRU) comprising an RLC entity configured to perform the method of claim 1.

51. A node B comprising an RLC entity configured to perform the method of claim 1.

52. A Radio Network Controller (RNC) comprising an RLC entity configured to perform the method of claim 1.

53. A wireless transmit/receive unit (WTRU) comprising an RLC entity configured to perform the method of claim 32.

54. A node B comprising an RLC entity configured to perform the method of claim 32.

55. A Radio Network Controller (RNC) comprising an RLC entity configured to perform the method of claim 32.

56. A method of Radio Network Controller (RNC)/node B flow control for downlink data when a variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported, the method comprising: credit allocations in bytes are signaled.

57. The method of claim 56, wherein signaling credit allocations in bytes comprises: information specifying the number of bytes of credit is added to the frame.

58. The method of claim 57, further comprising: information specifying the number of PDUs credited is removed from the frame.

59. The method of claim 56, wherein the method is performed in a node B.

60. A method for RNC/node B flow control of downlink data when variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported, the method comprising: a credit allocation in bytes is received.

61. The method of claim 60, wherein receiving a credit allocation in bytes comprises: a frame containing information specifying a number of bytes for a credit is received.

62. The method of claim 60, further comprising: storing a maximum size of the PDU in bytes, wherein receiving the credit allocation in bytes comprises:

receiving a frame including information specifying a number of PDUs to be credited; and

the number of PDUs credited is multiplied by the maximum size of the PDU in bytes.

63. The method of claim 60, further comprising:

storing a mapping of PDU SNs to associated lengths in bytes; and

the PDUs are transmitted without exceeding the received credit allocation.

64. The method of claim 60, wherein the method is performed in an RNC.

65. The method of claim 64, wherein the RNC is a Serving RNC (SRNC).

66. The method of claim 64, wherein the RNC is a Drift RNC (DRNC).

67. A Radio Link Control (RLC) entity, the RLC entity configured to:

enhancing RLC operation to support a flexible Packet Data Unit (PDU) size with a maximum RLC PDU size; and

the window size is defined and managed according to a byte count based window size metric.

68. The RLC entity of claim 67, configured to define and manage a window size based on a window size metric, wherein the metric includes at least one of a number of bytes and a number of blocks, and wherein each block is a fixed number of bytes.

69. The RLC entity of claim 68, configured to define and manage a window size according to a Packet Data Unit (PDU) sequence number.

70. The RLC entity of claim 67, further configured to include the window size metric in an RLC control and status PDU.

71. The RLC entity of claim 67, further configured to:

receiving a maximum RLC PDU payload size from a higher layer; and

inferring a maximum RLC PDU size from the maximum RLC PDU payload size.

72. The RLC entity of claim 67, further configured to receive a maximum RLC PDU size from a higher layer.

73. The RLC entity of claim 67, further configured to receive and negotiate the byte count based window size metric during at least one of an establishment, a configuration, and a reconfiguration of a radio bearer.

74. The RLC entity of claim 67, further configured to apply a byte-based window size metric in all messaging that updates a window for flow control during a connection.

75. The RLC entity of claim 74, configured to apply the window size metric across all messaging such that the messaging includes at least one of a window size hyper field (SUFI) and a Mobile Receive Window (MRW) SUFI in an RLC control and status PDU.

76. The RLC entity of claim 67, further configured to operate in Acknowledged Mode (AM).

77. The RLC entity of claim 67, further configured to receive a radio bearer information element from a Radio Resource Control (RRC) entity comprising at least one of:

selecting downlink RLC mode information including a new indicator for a flexible RLC PDU size mode in addition to other RLC modes;

an information element for indicating a flexible RLC PDU size mode;

downlink RLC PDU size information indicating one of an RLC scaling parameter in octets or a maximum RLC PDU size in a flexible RLC PDU size mode; and

protocol parameters signaled by the RRC including Poll _ PDU, Poll _ SDU, Configured _ Tx _ Window _ Size, and Configured _ Rx _ Window _ Size, wherein the protocol parameters are specified and interpreted in at least one of PDU number and byte units.

78. The RLC entity of claim 77, further configured to:

receiving an RLC PDU for transmission; and

when the window usage exceeds the maximum window size in bytes or when the received RLC PDU sequence number exceeds the maximum window size in PDU number, the received RLC PDU is retained and not submitted to lower layers.

79. The RLC entity of claim 77, further configured to receive a window size super field (SUFI) from the RRC entity that relates to octet parameters in the RLC STATUS PDU.

80. The RLC entity of claim 79, wherein the window size SUFI is specified in units of a number of PDUs, and the RLC entity is further configured to: deriving a window size in octets by multiplying the number of PDUs by an RLC scaling parameter in octets.

81. The RLC entity of claim 79, wherein the window size SUFI is specified in BYTES as a new SUFIWINDOW _ BYTES having type, length, and value components.

82. The RLC entity of claim 67, further configured to:

RLC flow control is performed using a byte count based metric.

83. The RLC entity of claim 67, the RLC entity configured as an RLC transmission entity in a transmitter, and the RLC entity further configured to: the RLC transmission window is updated when the RLC transmission operation is performed if the receiver acknowledges the one or more PDUs positively or if the receiver acknowledges the one or more PDUs negatively due to the receiver exceeding a maximum number of retries or due to timer-based discard in the transmitter.

84. The RLC entity of claim 83, configured to update an RLC transmission window by:

removing one or more PDUs from a used transmission window and raising a lower end of the used transmission window;

the following parameters were determined:

TxWMAX, equal to the length of the maximum window size in bytes;

a TxWTIL equal to one of the length in bytes of the used transmission window, or the length in bytes of the packet acknowledged within a window defined by transmission state variables V (A) and V (T);

TxL equal to one of a length in bytes of the one or more PDUs discarded as a result of the RLC SDU discard procedure, or a length in bytes of the one or more PDUs discarded as a result of receipt of the one or more acknowledgements; and

TxN equal to a length in bytes of a next one or more PDUs to be transmitted first;

calculating a Window Length (WL) parameter: WL ═ TxWUTIL-TxL + TxN; and

transmitting the next one or more PDUs and raising the upper end of the used transmission window if WL is less than TxWMAX.

85. The RLC entity of claim 67, the RLC entity configured as an RLC receiving entity, and the RLC entity further configured to: if one or more PDUs are received and the sequence number of these PDUs follows the sequence number of the last in-sequence received PDU, or if a Move Receive Window (MRW) instruction is received from the RLC transmission entity, the RLC receive window is updated when the RLC receive operation is performed.

86. The RLC entity of claim 85, wherein the RLC entity is configured to update the RLC reception window by:

raising the lower end of the used receive window;

the following parameters were determined:

RxWMAX, length in bytes equal to the maximum window size;

RxWUTIL equal to the length of the used receive window in bytes;

RxD equal to the length in bytes of one or more PDUs removed from the RLC receive window due to in-order reception; and

RxN, equal to a length in bytes of a next one or more PDUs to be first received;

calculating a Window Length (WL) parameter: WL ═ RxWUTIL + RxN-RxD; and

if WL is less than RxWMAX, the next one or more PDUs are received and the upper end of the used receive window is raised.

87. The RLC entity of claim 67, further configured to create an RLC PDU at each time interval by:

the following parameters are defined:

current _ Credit equal to the amount of data that can be transmitted based on the MAC link adaptation in the uplink and the result in octets of the remaining Credit allocation added to the new Credit allocation received in the downlink;

available _ Data, equal to the Data in octets Available for transmission in the RLC PDU format;

leftover _ Window, equal to the Window length in octets defined by the state variables vt(s) and vt (ms) in the RLC transmitter;

the following parameters were calculated:

x Min { Current _ Credit, Available _ Data, Leftover _ Window }, where

Min {. returns the minimum in the set; and

generating a PDU of length X.

88. The RLC entity of claim 87, further configured to:

the following parameters are defined:

maximum _ RLC _ PDU _ size, equal to the Maximum RLC PDU size configured by the upper layer;

and

minimum _ RLC _ PDU _ size, equal to a parameter configured by the upper layer to specify one of a Minimum RLC PDU size or a Minimum RLC PDU payload size; and

PDUs are generated with a size between Minimum _ RLC _ PDU _ size and Maximum _ RLC _ PDU _ size.

89. The RLC entity of claim 88, the RLC entity further configured to:

the following parameters were calculated:

floor { X/Maximum _ RLC _ PDU _ size }; and

x mod Maximum _ RLC _ PDU _ size; where Floor {. returns the nearest rounded-down integer value, and a mod b returns the division of a modulo b;

and

n PDUs of length equal to Maximum RLC PDU size are generated.

90. The RLC entity of claim 89, further configured to:

if X is not equal to Leftover _ Window or Current _ Credit, another RLC PDU with length L is generated;

if X is equal to Leftover _ Window or Current _ Credit, and L is greater than Minimum _ RLC _ PDU _ size or if X is equal to Available _ Data, generating another RLC PDU of length L; and

if X is equal to Leftover _ Window or Current _ Credit, and L is not greater than Minimum _ RLC _ PDU _ size, another RLC PDU of length Minimu _ RLC _ PDU size is generated.

91. The RLC entity of claim 90, further configured to store the generated RLC PDUs in a buffer for transmission.

92. The RLC entity of claim 89, wherein the time interval is defined by a multiple of 1 or more Transmission Time Intervals (TTIs).

93. The RLC entity of claim 89, wherein the time interval is defined by a time instance when data is available for transmission or requested from lower layers.

94. The RLC entity of claim 89, wherein Maximum RLC PDU size and Minimum RLC PDU size are not configured by upper layers.

95. The RLC entity of claim 67, further configured to maintain a state variable, wherein the state variable is specified and interpreted in terms of number of PDUs and byte units.

96. The RLC entity of claim 95, the RLC entity configured as an RLC transmission entity, the RLC entity further configured to:

holding a state variable Maximum _ Tx _ Window _ Size, wherein the state variable represents a Maximum transmission Window Size in octets;

updating a state variable Maximum _ Tx _ Window _ Size to an octet parameter specified by a Window Size hyper field (SUFI) in the received RLC status PDU;

the following state variables were maintained: a transmission state variable VT (S), a response state variable VT (A), a maximum transmission state variable VT (MS) and a transmission window size state variable VT (WS); and

the state variables vt(s), vt (a), vt (ms) and vt (ws) are updated according to the state variables Maximum _ Tx _ Window _ Size in octet units.

97. The RLC entity of claim 95, the RLC entity configured as an RLC receiving entity, and the RLC entity further configured to:

holding a state variable Maximum _ Rx _ Window _ Size, wherein the state variable represents a Maximum receive Window Size in octets;

receiving a state variable Maximum _ Rx _ Window _ Size from an upper layer;

the following state variables were maintained: a reception state variable vr (r), a highest expected state variable vr (h), and a maximum acceptable reception state variable vr (mr); and

the state variables vr (r), vr (h) and vr (mr) are updated according to the state variable Maximum _ Rx _ Window _ Size in units of octets.

98. A Radio Link Control (RLC) entity, the RLC entity configured to:

enhancing RLC operation to support flexible Packet Data Unit (PDU) sizes with a maximum RLC PDU size; and

RLC polling mechanisms are defined and managed using byte count based metrics.

99. The RLC entity of claim 98, further configured to:

polling is triggered in an Acknowledged Mode Data (AMD) PDU when the used window size in octets is greater than a system configured threshold in bytes.

100. The RLC entity of claim 98, further configured to trigger polling in the AMDPDU each time when a total amount of data transmitted exceeds a known predetermined number of octets or data blocks.

101. The RLC entity of claim 98, configured as an RLC transmission entity, and further configured to:

polling the receiver using a protocol parameter Poll _ Window when the Window-based polling is configured by an upper layer; and

triggering polling for each Acknowledged Mode Data (AMD) PDU when a transmission Window percentage, K, is greater than or equal to Poll _ Window, where K is defined as in octets:

K＝utilized_window/Maximum_Tx_Window_Size，

wherein utilized _ window is the length in octets of the window defined by the state variables VT (A) and VT (S).

102. The RLC entity of claim 98, further configured to receive protocol parameters Poll PDU and Poll SDU from the upper layer for indicating a PDU count interval.

103. The RLC entity of claim 98, configured to receive a protocol parameter Poll Bytes in octets, wherein the protocol parameter indicates a byte count interval between polls, and further configured to:

maintaining a variable Poll _ Octets counter, wherein the counter counts the total number of bytes transmitted in a PDU since the transmission of the last PDU that triggered the polling request; and

triggering a polling request in a PDU that causes the Poll _ Octets counter to exceed the Poll _ Bytes when the Poll _ Octets counter is greater than or equal to the value of Poll _ Bytes, and resetting the Poll _ Octets counter.

104. The RLC entity of claim 103, wherein the Poll _ Octets counter counts a total number of bytes for a first transmission of each RLC Acknowledged Mode Data (AMD) PDU.

105. The RLC entity of claim 103, wherein the Poll _ Octets counter counts the total number of bytes of all transmitted PDUs, including retransmissions.

106. The RLC entity of claim 103, configured to trigger a polling request by setting a polling bit in a PDU causing the Poll _ Octets counter to exceed Poll _ Bytes.

107. The RLC entity of claim 103, configured to trigger a POLL request by sending a POLL PDU to a receiver.

108. The RLC entity of claim 103, wherein the last PDU that triggered the polling request is attributed to a Poll Bytes mechanism.

109. The RLC entity of claim 103, wherein the last PDU that triggered the polling request is attributed to a Poll PDU or a Poll SDU.

110. The RLC entity of claim 98, further configured to trigger polling in an Acknowledged Mode Data (AMD) PDU when a used window size in octets is greater than a threshold percentage of a system-configured maximum window size.

111. The RLC entity of claim 98, further configured to trigger a status report when a used receive window size is greater than a threshold percentage of a particular system configured maximum window size.

112. The RLC entity of claim 98, further configured to trigger a status report when a used receive window in octets is greater than a system-configured threshold in bytes.

113. The RLC entity of claim 98, configured to receive a protocol parameter Poll _ Window from an upper layer, the RLC entity further configured to:

polling the receiver using Poll _ Window when the Window-based polling is configured by the upper layer; and

triggering polling for each Acknowledged Mode Data (AMD) PDU when a value J is greater than or equal to Poll _ Window, where J is defined as:

where 4096 is a modulus for the Answer Mode (AM), and vt(s), vt (a), and vt (ws) are state variables.

114. The RLC entity of claim 113, further configured to:

triggering polling for each AMD PDU when a value K is greater than or equal to Poll _ Window, where K is defined as:

115. the RLC entity of claim 113, wherein the protocol parameter Poll _ Window is measured by a number of bytes, the RLC entity further configured to:

triggering polling for each AMD PDU when a value K is greater than or equal to the protocol parameter Poll _ Window, where K is defined as:

k is the sum of RLC PDU sizes from vt (a) to vt(s).

116. A wireless transmit/receive unit (WTRU) comprising the RLC entity of claim 67.

117. A node B comprising the RLC entity of claim 67.

118. A Radio Network Controller (RNC) comprising the RLC entity of claim 67.

119. A wireless transmit/receive unit (WTRU) comprising the RLC entity of claim 98.

120. A node B comprising the RLC entity of claim 98.

121. A Radio Network Controller (RNC) comprising the RLC entity of claim 98.

122. A Radio Link Control (RLC) entity, the RLC entity configured to:

performing Radio Network Controller (RNC)/node B flow control of downlink data when a variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported; and

credit allocations in bytes are signaled.

123. The RLC entity of claim 122, configured to signal credit allocation in bytes by adding information specifying the number of bytes of credit to a frame.

124. The RLC entity of claim 123, further configured to remove information from a frame that specifies a number of PDUs credited.

125. A node B comprising the RLC entity of claim 122.

126. A Radio Link Control (RLC) entity, the RLC entity configured to:

performing RNC/node B flow control of downlink data when a variable Radio Link Control (RLC) Packet Data Unit (PDU) size is supported; and

a credit allocation in bytes is received.

127. The RLC entity of claim 126, configured to receive credit allocations in bytes by receiving a frame containing information specifying a number of bytes for credit.

128. The RLC entity of claim 126, further configured to:

storing the maximum size of the PDU in bytes;

receiving a frame including information specifying a number of PDUs to be credited; and

the number of PDUs credited is multiplied by the maximum size of the PDU in bytes.

129. The RLC entity of claim 126, further configured to:

storing a mapping of PDU SNs to associated lengths in bytes; and

the PDUs are transmitted without exceeding the received credit allocation.

130. A Radio Network Controller (RNC) comprising the RLC entity of claim 126.

131. The RNC of claim 130, wherein the RNC is configured as a serving RNC (srnc).

132. The RNC of claim 130, wherein the RNC is configured as a drift RNC (drnc).