Method and apparatus for enhancing rlc for flexible rlc pdu size

METHOD AND APPARATUS TO IMPROVE RLC TO FLEXIBLE RLC PDU SIZE

FIELD OF THE INVENTION

[001] This application is related to wireless communications.

HISTORIC

[002] The evolution of high-speed packet access (HSPA +) refers, here, to the evolutionary increase in radio access technology of the standards used in Universal Mobile Telecommunication Systems (UMTS), and wireless communication systems, downlink packages (HSDPA) and high-speed access to uplink packages (HSUPA) from the Third Generation Partnership Project (3GPP). Some of the enhancements for HSDPA (Standard Launch 3GPP UMTS 5) and HSUPA (Standard Launch 3GPP UMTS 6) proposed as part of HSPA + include higher data transmission rates, greater coverage and system capacity, greater support for service packages, latency reduced operating costs, and backward compatibility with previous 3GPP systems. Here, previous 3GPP systems typically refer to one or more of the pre-existing 3GPP standards prior to Launch 6. Achieving these improvements involves evolving both the interface protocol and the network architecture.

[003] The following list includes the relevant abbreviations:

• 3GPP - Third Generation Partnership Project • AM - Recognized Mode • AMD - Recognized Mode Data • ARQ - Automatic Repeat Request • CN - Internal Network • CP - Control Plan • CS - Switched Circuit • DL - Downlink • HARQ - Hybrid Auto Repeat Order • HSDPA - High Speed ​​Access to Downlink Package • HSUPA - High Speed ​​Access to Uplink Package

Petition 870190119684, of 11/18/2019, p. 14/50

2/29 • IP - Internet Protocol • LCID - Logical Channel Identifier • LTE - Long Term Evolution • MAC - Medium Access Control • PDCP - Data Packet Convergence Control • PDU - Data Packet Unit • PHY -Physical • PS - Exchanged Package • QoS - Quality of Service • RAN - Radio Access Network • RLC - Radio Link Control • RNC - Radio Network Controller • CRNC - RNC Controller • SRNC - RNC Server • RNS - Radio Network Subsystem • RoHC - Compression Robust Header • RRC - Radio Resource Control • RRM - Radio Resource Management • Rx - Reception • SAP - Service Access Point • SDU - Service Data Unit • SN - Sequence Number • TB - Block Transport • TBS - Block Transport Set • TF - Transport Format • TFC - Transport Format Combination • TFRC - Transport Format Resource Combination • TM - Transparent Mode • TM - Transparent Mode Data • Tx - Transmission

Petition 870190119684, of 11/18/2019, p. 15/50

3/29 • EU - Equipment User • UL-Uplink • UM - Unrecognized Mode • UMD - Unrecognized Mode Data • UP - User Plan • UMTS - Universal Mobile Telecommunication System • UTRAN - Universal Terrestrial Access Network via Radio • WTRU - Wireless Transmission / Reception Unit

[004] The layer 2 interface protocols include the media access control (MAC) and radio link control (RLC) protocols. Some of the functions of the MAC and RLC protocols are discussed hereinafter, however, other functions that are not discussed are considered to work as described in the 3GPP standards.

[005] Some of the main functions of the MAC protocol are:

• Channel mapping of MAC to physical data packet units (PDUs).

• Multiplication of data from the upper layers into data packet units (PDUs) • Quality of Service (QoS), which takes into account the priority of data for rate control and organization • Adaptation of the link to QoS and multiplication • Hybrid order of automatic repetition (HARQ) for error correction retransmission control.

[006] The MAC layers multiply the data from the upper layers to the MAC PDUs. MAC PDUs that are sent to the physical layer (PHY) are called transport blocks (TBs). A set of TBs, referred to as a set of transport blocks (TBS), are sent at each transport time interval (TTI) to the PHY layer with a corresponding Transport Format (TF), which describes the physical attributes of the layer for that TBS. If TBS arose from the multiplication of data from more than one logical RLC channel, then a combination of TFs, known as a transport format combination (TFC) is used. As part of the link adaptation, the layer

Petition 870190119684, of 11/18/2019, p. 16/50

4/29

MAC performs TFC selection based on RLC logical channel priority, RLC buffer occupation, physical channel conditions and multiplication of logical channels. The reference to the TFC MAC selection here is generic and may include, for example, a combination selection of transport format resources (TFRC) in the high-speed MAC protocol (MAChs) in HSDPA.

[007] The RLC protocol at layer 2 had a major impact on latency and data transfer rate. The RLC protocol in previous 3GPP systems, including Release 6 and earlier, is physically located at the radio network controller (RNC) node.

[008] Some of the main functions of the RLC transmission protocol (Tx) that occur in the Tx RLC entity are:

• Macro-diversity to allow an UE to be simultaneously connected to two or more cells to receive data (optional) • Segmentation of high radio layer carriers • Concatenation of high radio layer carriers • Detection and error recovery of received PDUs erroneously • HARQ - ARQ assisted for fast retransmission of PDUs received by error

[009] Some of the main functions of the RLC receiving protocol (Rx) that occur in the Rx RLC entity are:

• Duplicate PDU detection • Sequential PDU sending • Error detection and recovery of wrongly received PDUs • HARQ - ARQ assisted for fast retransmission of PDUs received by error • Reassembly of higher layer data from received PDUs

[0010] Three operating modes for the RLC Layers are recognized mode (AM), unrecognized mode (UM) and transparent mode (TM). In an AM operation, which includes the transmission of some higher layer data plans, the RLC protocol is bidirectional, so that control and information status are sent from the Rx RLC entity to the Tx RLC entity. In TM and UM operations, which include the transmission of a plan that controls data signaling resources via radio (RRC), the RLC protocol is

Petition 870190119684, of 11/18/2019, p. 17/50

5/29 unidirectional, so that the Tx RLC entity and the Rx RLC entity are independent, with no exchange of status or control information. In addition, some of the functions such as ARQ-assisted HARQ and error detection and recovery are typically used only in AM operations.

[0011] The RLC PDU sizes are determined by the RRC layers based on the long-term Quality of Service requirements for the application data carried by the RLC logical channels. According to previous 3GPP systems, including Launch 6 and earlier, the RLC layer is configured in a semi-static manner by the RRC layer with predetermined RLC PDU sizes. In this way, the PDU RLC size was fixed in a semi-static layer based on the upper layers and the sequence numbers (SNs) were determined for RLC PDUs. AM data from RLC PDUs are numbered by modular sequential integers (SNs), repeating from field 0 to 4095.

[0012] The RLC PDU types are DATA, CONTROL and STATUS. The DATA PDU is used to transmit user data, information loaded from STATUS and the query bit in which the RLC is operating in AM, where this stretch is used to request a status report from the receiver. The CONTROL PDU is used for the RESET RLC and RESET recognition (ACK) commands. The STATUS PDU is used to exchange status information between two RLC entities operating in AM and may include superfields (SUFIs) of different types, including, for example, the SUFI of window size or the SUFI receiver of Mobile window ( MRW).

[0013] A transmission window refers to the group of PDUs that are being processed for transmission or are currently being transmitted. Similarly, the reception window refers, in general, to the group of PDUs being received or processed at reception. The transmission or reception window typically refers to a number of PDUs transmitted or received, respectively, by the system. These transmit and receive window sizes need to be managed using flow control so as not to overload the system and receive unwanted packet fees. Generally speaking, once a PDU has been successfully received at the receiver, a new PDU must be added to the window

Petition 870190119684, of 11/18/2019, p. 18/50

6/29 transmission and / or reception.

[0014] An RLC transmission window is composed of an upper limit and a lower limit. The lower limit consists of the SN of the PDU with the lowest transmitted SN and the upper limit consists of the SN of the PDU with the highest transmitted N. The RLC is configured with a maximum transmission window, so that the maximum number of PDUs transmitted from the lower limit to the upper limit must not exceed the maximum window size. The LRC reception window is configured in a similar way. The lower limit of RLC reception is the SN following the last PDU received in sequence and the upper limit is the SN of the PDU with the highest sequence number received. The reception window also has a maximum size window, where the maximum expected PDU SN is equal to the lower SN limit plus the maximum configured window size. The transmit and receive windows are managed using transmit and receive state variables, respectively, as described here.

[0015] Among the techniques for flow control are RNC / Node B flow control, RLC flow control and RLC status report. Flow control RNC / Node B refers to procedures to minimize downlink data stored at Node B. Typically, data destined for an UE flows from a Core Network (CN) through a radio network source controller (DRNC) in a drift situation in which the UE is destined for a cell with a different radio network subsystem (RNS). Node B provides allocation of credits to the SRNE, and to the drift DRNC, allowing the SRNC to send an equivalent number of PDUs to Node B, so that the RNC cannot send more PDUS until more credits are provided. RLC flow control refers to the management of packet transfer, including the window size, between the Tx RLC entity and the Rx RLC entity. The RLC status report allows the receiver to report status information to the transmitter when queried by the transmitter.

[0016] According to 3GPP standards, several RLC protocols for flow control are signaled by the upper layers to the RLC layer, including the following parameters:

• Poll_Window [Consultation Window]

Petition 870190119684, of 11/18/2019, p. 19/50

7/29 • Configured_Tx_Window_Size [Configured Tx Window Size] • Configured_Rx_Window_Size [Configured Rx Window Size]

[0017] These parameters, described in greater detail below, are used by the RLC layer together with several RLC status variables for flow control to configure the size of the transmission and reception window. According to previous 3GPP systems, these RLC state variables depend on SNs. For example, the following RLC-transmitting state variables are affected by SNs:

• VT (S) is the issuing state variable containing the SN of the next AM data PDU to be transmitted for the first time • VT (A) is the acknowledging state variable containing the SN following the SN of the last AMD PDU recognized in sequence, and forms the lower boundary of the transmission window.

• VT (MS) is the maximum emission variable containing the SN of the first AM data PDU that can be rejected by the receiver <0} • VT (WS) is the status variable of the transmission window size

[0018] All arithmetic operations with VT (S), VT (A), VT (MS), VR (R), VR (H) and VR (MR) depend on one or more SNs. The following RLC receiver state variables are also affected by SNs:

• VR (R) is the receiver state variable containing the SN following the last AM data PDU received in the sequence • VR (H) is the highest expected state variable containing the SN following the highest SN received from any PDU AM data • VR (MR) is the maximum acceptable state variable containing the SN of the first AM data PDU that must be rejected by the receiver

[0019] In previous 3GPP systems, many functions needed to support the data transfer service, such as RNC / Node B flow control, RLC flow control and RLC status reporting are based on SNs or, in fact, in the number of PDUs when the RLC PDU size is fixed. The reason is that the transmission and reception window can be accurately characterized using the number of PDUs and the known and fixed sizes of PDU. However, in proposals for HSPA +,

Petition 870190119684, of 11/18/2019, p. 20/50

8/29 the RLC can be configured for the upper layers to allow for flexible RLC PDU sizes. If the upper layers, such as the RRC layer, configure a flexible RLC PDU size operation then the size of the RLC PDU will be variable at a semi-static maximum specified by the size of the RLC PDU load. [0020] This document recognizes that existing SN operations based on RLC may not work efficiently with flexible RLC PDU size. The reason is that using the number of PDUs to define the window size will result in a variable window size resulting in possible buffer overflows in RND and buffer underflows in Node B. Likewise, it would be beneficial to provide methods alternatives for configuring window size for flexible RLC PDU size operations.

[0021] US 2003/202501 describes a method for polling a RLC PDU. The transmission window has a size which corresponds to a predetermined maximum number of PDUs that can be transmitted and the polling period is adjusted according to the size of the window.

[0022] The document 3GPP TS 25.322 describes, for example, the parameter Polling bit and its definition in the radio link control (RLC) specification and different polling triggers, that is, the PDUs are counted and when a predetermined Poll_Value value, a poll / query is triggered.

[0023] Finally, the document 3GPP R2-070036 is a modification of 3GPP TS 25.322 which introduces a flexible size of the PDU.

RESUME

[0024] Improvements to the radio link control protocol (RLC) for high speed packet access evolution (HSPA +) and other wireless systems, as well as the long term evolution system (LTE), in which the variable RLC data unit packet size (PDU) is allowed and is declared. When RLC PDU sizes are not fixed, radio network controller (RNC) / Node B flow control, RLC flow control, status reporting and query mechanisms not only depend on the numbers of (SNs) or number of PDUs, but are configured to use methods based on byte counting. The

Petition 870190119684, of 11/18/2019, p. 21/50

9/29 methods based on byte count proposed by RLC apply to both uplink and downlink communications.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025] More detailed knowledge can be obtained after the following description, given only as an example to be understood in conjunction with the drawings accompanying this document:

- figure 1 shows the structure of a superfield (SUFI) in a STATUS RLC packet data unit (PDU);

figure 2 shows a flow diagram of an RNC / Node B flow control using a byte-based credit allocation according to the instructions present;

figure 3 shows a flow diagram of an update of an RLC transmission window (Tx) according to the present instruction;

figure 4 shows a flow diagram of an update of an RLC reception window (Rx) according to the present instruction;

figure 5 shows a flow diagram for an improved octet based RLC PDU creation according to the present instruction.

DETAILED DESCRIPTION

[0026] When referred to here, the wireless transmission / reception unit (WTRU) terminology includes, but is not limited to, the user of the equipment (UE), a mobile station, a fixed or mobile subscription unit, a pager, a telephone cell phone, a personal digital assistant (PDA), a computer, or any type of user device operating in a wireless environment. When referred to here, the base station terminology includes, but is not limited to, a Node-B, a site controller, an access point (AP) or any other type of interface device capable of operating in a wireless environment.

[0027] Methods based on byte counting to improve the flow control of the radio network controller (RNC) / Node-B, the flow control of the radio link control (RLC), the RLC status report and Query mechanisms for the flexible size of RLC data packet units (PDUs) are provided here. The

Petition 870190119684, of 11/18/2019, p. 22/50

10/29 proposed improvements ensure efficient operation of the RLC functions when the size of the RLC PDU is flexible, increasing the previous RLC functions, based on the sequence numbers (SNs) that were designed for the fixed size of the RLC PDU. The proposed RLC enhancement applies to both uplink (EU for Universal Terrestrial Radio Access Network (UTRAN)) and downlink (UTRAN for EU) communications, and can be used in any wireless communication system, including, but not limited to, not being limited to, high speed packet evolution systems (HSPA +), long term evolution (LTE) and broadband code division multiple access (WCDMA). For wireless systems such as LTE, the UTRAN is equivalent to the UTRAN evolution (E-UTRAN).

[0028] The proposed RLC improvements can be used in architecture, where RLC operates both completely on Node B, partially on RNC and partially on Node-B. The proposed RLC improvements are described here mainly with respect to HSPA +. Many functions and various parameters are based on the parameters for HSDPA and HSUPA and may not be understood in conjunction with the 3GPP technical specifications (TSs), including the RLC Protocol Specifications for 3GPP for Launch 7 (see 3GPP TS 25.322 V. 7.2.0), which have been incorporated into this document. It is assumed that the RLC can be configured for the upper layers to be compatible with the flexible PDU size with a specified maximum flexible RLC PDU load size. It is also assumed that the maximum RLC PDU size can be inferred from the maximum specified load size of RCL PDU. Alternatively, the maximum RLC PDU size can be determined directly. In addition, the terms bytes and octets are used interchangeably, as well as the terms transmitter and receiver.

[0029] One or more of the following measures can be used, alone or in combination, to define and manage the window size, when the flexible RLC PDU size is configured by the RRC:

• Number of bytes • Number of blocks in which each block is a fixed number of bytes • Number of PDUS or sequence numbers (SNs)

Petition 870190119684, of 11/18/2019, p. 23/50

11/29

[0030] The measure (s) used to define the window (s) are signaled and negotiated during the RRC adjustment, the radio bearer configuration and reconfiguration procedures. The measurement (s) for the size of the window listed here can be applied to all message exchanges that update the window for flow control during a connection. For example, the window size measurement can be included in the SUFI Window Size and Move Receiving Window (MRW) SUFI on the RLC CONTROL or STATUS PDUs.

[0031] In the case of the recognized mode RLC, (AM), to be compatible with the flexible RLC PDU size in the RLC configuration and reconfiguration, with radio bearer information elements (RLC Info), any of the following information can be provided by the RRC to the RLC, to signal the use of the RLC PDU size:

• The CHOICE downlink RLC information mode, including a new indicator for the flexible RLC PDU size mode in addition to the other RLC modes. When the RLC PDU flexible size mode is indicated, the RLC entities can interpret the other RLC protocol parameters according to that mode.

[0032] Any other new element of information, as part of the RLC Information, can also be used to indicate the flexible size mode of the RLC PDU.

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

• as an octet RLC scaling parameter (after dividing the number of bits by 8), sent specifically to scale or multiply other protocol parameters specified in the number of PDUs described here, while the RLC scaling parameter has the same value as the receiving (Rx) and transmitting (Tx) RLC entity, or • as a specification of the maximum RLC PDU size in the flexible RLC PDU size mode, while the maximum RLC PDU size can , in turn, be used as the RLC scale parameter described above.

[0034] The protocol parameters signaled by the upper layers like the RRC

Petition 870190119684, of 11/18/2019, p. 24/50

12/29 for RLC, including, but not limited to, Poll_PDU, PollJSDU, Configured_Tx_Window_Size and Configured_Rx_Window_Size (see 3GPP TS 25.322 V. 7.1.0 Section 9.6), can be specified and interpreted in the following two ways:

• In a number of PDUs, or service data units (SDUs) in the case of Poll_SDU, which is an integer value from which RLC can determine the window size in octets, performing a mathematical calculation. For example, the specified number of PDUs (or SDUs in the case of PollJSDU) can be multiplied by the RLC scale parameter in octets as specified by the upper layers.

• In units of bytes, in which a new field can be defined for this option to guarantee the protocol parameter in bytes.

[0035] In a STATUS RLC PDU, a Window Size superfield (SUFI), used by the receiver to configure the transmitter's window size, is configured to provide a number of octets. This enhancement is used when the flexible RLC PDU size mode is adjusted by the RRC as described above, and can be specified in two ways:

• In the number of PDUs from which the RLC infers the equivalent amount in octets by performing a mathematical calculation. For example, the specified number of PDUs can be multiplied by the scale of RLC parameters in octets, specified by the upper layers and described above.

• In units of bytes as a new SUFI with components of type, length and value. For example, a field of type 4 bits long, currently unused or reserved, such as bits 1000 shown in Table 1, can be used to introduce a new type of SUFI to specify the number of bytes, WINDOW_BYTES SUFI, as shown in Table 1 and figure 1, in which the SUFI length component is defined as large enough to hold the largest possible window size SUFI value, in bytes.

<td>Bit</td><td>description</td>

<td> 0000</td><td>No More Data (NO MORE)</td>

<td> 0001</td><td>Window Size (WINDOW)</td>

<td> 0010</td><td>Recognition (ACK)</td>

<td> 0011</td><td>List (LIST)</td>

<td> 0100</td><td>Bitmap (BITMAP)</td>

Petition 870190119684, of 11/18/2019, p. 25/50

13/29

<td> 0101</td><td>Relative List (Rlist)</td>

<td> 0110</td><td>Motion Reception Window (MRW)</td>

<td> 0111</td><td>Motion Reception Window Recognition (MRW ACK)</td>

<td> 1000</td><td>Window Size Bytes (WINDOW_BYTES)</td>

<td> 1001-1111</td><td>Reserved (PDUs with this encoding are invalid for this version of the orotocol)</td>

Table 1: Definition of a new type of SUFI 1000 for the WINDOW_BYTES SUFI added for fields of type SUFI that have a length of 4 bits.

Flow control RNC / Node B.

[0036] Improvements to the RNC / Node B flow control are described here for the case in which the RLC entity is retained by the RNC. However, similar improvements can be defined where the RLC entity is at RNC and Node B. In accordance with existing 3GPP standards, as described in 3GPP TS 25.425 for user plan protocols of the UTRAN lur interface for Common Transport Channel data flows between an RNC to Node B, and 3GPP TS 24.435 for plan protocols of users of the Utran lub interface for Common Transport Channels for data flow between two RCNs, a data MAC entity (MAC-d) can be retained at the RNC to receive RLC PDUs and send them to the high-speed MAC entity (MAC-hs) at Node B after applying the header information. In previous 3GPP systems, Node B sends capacity allocation frames to an RNC server (SRNC), and possibly to an RNC controller (CRNC), indicating the maximum PDU size and the number of PDUs that can be sent. In addition, parameters can be sent so that the allocation is periodic for a fixed number of periods or for an indefinite period of time.

[0037] The number of MAC PDUs sent from the RNC to Node B and the corresponding time interval is regulated by a flow control algorithm, which is based on a credit allocation scheme. Credits represent the number of MACd PDUs that can be transmitted. The RNC requests credits and Node B sends them together with a specified time interval for transmission.

[0038] When the size of the RLC PDU is variable, the size of the MAC-d PDU, consequently, is also variable. Thus, it is not enough to specify the

Petition 870190119684, of 11/18/2019, p. 26/50

14/29 number of credits in terms of the number of MAC-d PDUs. There are a number of possible approaches to perform RNC / Node B flow control with a variable size MAC-d PDU. Another possibility is to eliminate RNC / Node B flow control; however, this would require relying on user data protocols, such as the transport control protocol (TCP), to perform network flow control, and in addition to dealing with the interaction between the TCP window and the RLC window.

[0039] Alternatively, the allocation of credits can be specified in bytes instead of the number of PDUS, which can be done in two ways. A new field can be added to the existing frames to specify the number of credit bytes instead of the number of PDUs. Another alternative is that the indication can be signaled by adjusting or reconfiguring the radio receiver, or on each applicable control board using an existing control board or a new control board, which indicates that the allocation is actually an byte allocation by multiplying the credit by the maximum PDU size in bytes producing a total of bytes. Likewise, the maximum number of PDUs that can be transferred from Node B would not be equal to the credit assigned in terms of a number of PDUS, but would be limited by the total number of bytes in the PDUs. Using a byte-based approach, the RNC can optionally map the PDU's SN to its length in bytes. Since the RNC receives the allocation of credits from Node B, it can transmit as many PDUs as it can without violating the byte length limits specified by the allocation of credits based on the length of bytes.

[0040] Figure 2 presents a flow diagram of an RNC / Node B flow control using a byte-based credit allocation. A Node B marks a credit allocation in bytes (step 205). An RNC receives the credit allocation in bytes (step 210). The RNC maintains a mapping of the PDU SN to the PDU length in bytes (step 220) and transmits the PDUs without exceeding the allocation of received credits (steps 220).

RLC flow control

[0041] RLC flow control is achieved by advancing the Tx RLC window when the PDU at the lower end of the used transmission window (Tx) is recognized from

Petition 870190119684, of 11/18/2019, p. 27/50

15/29 positively, and thus it is received correctly, while still remaining within the limits imposed by the maximum window size. The PDU at the bottom end of the TX window is defined as the PDU following the last recognized PDU in the sequence. For the case where the flexible RLC PDU size is configured, the appropriate steps must be taken, so that the maximum window size limit is not violated. The size of the Tx window is specified in terms of bytes.

[0042] Figure 3 presents a flow diagram for a method of updating a transmission window (Tx) of RLC 300. Following the initialization and adjustment of the RLC, an RLC Tx operation is performed (step 305). A TX RLC operation can be, for example, receiving status and control information at the RLC receiver.

[0043] The Tx RLC entity decides whether or not to remove one or more PDUs from the used Tx window and increase the lower end of the used Tx window (step 310). One or more PDUs can be removed if:

• the PDU (s) were recognized positively by the receiver, or • the PDU (s) were recognized negatively, but the RLC transmitter decided to discard that PDU due to other reasons such as the receiver exceeding the maximum number of attempts by the transmitter, or • as the result of a disposal based on a transmitter timer.

[0044] For ease of description, the following notation is used for some quantities related to the Rx entity Tx:

• TxWMAX: length in bytes of the maximum window size • TxWUTIL: length, in bytes, of the Tx window used, or, alternatively, the length in bytes of the packets that were recognized within the window limited by state variables V (A ) and V (T) • TxL: length in bytes of one or more PDUs that are discarded due to the RLC SDU disposal procedure or due to the receipt of one or more acknowledgments.

• TxN: length in bytes of the next or the next PDUs to be transmitted for the first time.

[0045] The RLC entity Tx computes the following amount of length of

Petition 870190119684, of 11/18/2019, p. 28/50

16/29 window (WL) (step 315):

WL = TxWUTIL - TxL + TxN. Equation (1)

[0046] The RLC entity Tx determines whether the amount WL is less than the maximum size of the TxWMAX window (step 320). If the WL is less than the TxWMAX, the next or the next PDUs are not transmitted and the upper end of the window is not increased (step 325). If the WL is less than the TxWMAX, the next or the next PDUs are transmitted and the bottom edge of the window is increased (step 330).

[0047] An RLC flow control method is applied to the Rx RLC entity when the flexible RLC PDU size is configured, to ensure that the maximum window size limit is not violated. The size of the Rx window is specified in terms of bytes. Figure 4 presents a flow diagram of a method for updating the reception window (Rx) of RLC 400 according to the instructions in this document. After RLC initialization and adjustment, an RLC Rx operation will be performed (step 405). An Rx RLC operation can be, for example, the receipt of a new PDU. The RLC Rx entity decides whether or not to enlarge the lower end of the Rx window (step 410). The RLC entity Rx can increase the bottom edge of its RX window and therefore decrease the RxWUTIL if:

• he receives the PDU with the SN after the last PDU received in sequence, or • he receives a Movement Receiving Window (MRW) from the RLC entity Tx.

[0048] For ease of description, the following notation is used for certain quantities related to the RLC entity of RLC:

• RxWMAX: length in bytes of the maximum window size • RxWUTIL: length in bytes of the used Rx window • RxD: length in bytes of one or more PDU (s) that were received by the reception window for reception in order • RxN: length in bytes of the next or the next PDU (s) to be received for the first time

[0049] RLC entity Rx computes the following window length (WL)

Petition 870190119684, of 11/18/2019, p. 29/50

17/29

[0050] quantity (step 415):

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

[0051] The RLC entity Rx determines whether the amount of WL is less than the maximum window size RxWMAX (step 420). If the WL is not less than the RxWMAX, the next PDU (s) will not be received and the bottom edge of the Rx window is not increased (step 425). If the WL is less than the RxWMAX, the next PDU (s) are received, without discarding the PDU with an SN next to the largest received SN, and the larger end of the RX window has been increased (430) .

[0052] Setting the RLC transmitter and receiver status variables using octet based methods is described here. When the flexible RLC PDU size mode is set by the RRC layer and the RLC operates in AM, AM data RLC PDUs are numbered by sequence numbers (SN) of entire modules, alternating through a field.

[0053] Generally, this field varies between 0 and 4095, although a different maximum value can be configured for the RRC or other higher layers. It is good to remember that arithmetic operations with VT (S), VT (A), VT (MS), VR (R), VR (H) and VR (MR) are affected by the SN module.

[0054] A parameter or state variable Maximum_Tx_Window_Size in octets can be maintained by the RLC transmitter. This parameter is initially set to the protocol parameter Configured_Tx_Window_Size in octets in the upper layers, and can be updated later to a number of octets indicated by the SUFI Window Size in a RLC STATUS PDU. The state variable VT (WS) can be derived from the Maximum_Tx_Window_Size in octets, and can be set to a value equal to the largest non-negative integer not greater than 4095 (or a maximum value configured for RRC / upper layers), so that the window octet length limited by VT (A) and VT (A) + VT (WS) does not exceed the Maximum_Tx_Window_Size in octets. The state variable VT (WS) is updated when the Maximum_Tx_Window_Size in the octets is updated. Alternatively, the state variable VT (WS) can be derived from the largest non-negative integer not greater than 4095 (or a maximum value set for RRC / upper layers), so that the

Petition 870190119684, of 11/18/2019, p. 30/50

18/29 window octet length limited by VT (A) and VT (A) + VT (WS) does not exceed:

• the protocol parameter Configured_Tx_Window_Size in octets, and • the SUFI Window Size referring to an amount of octet in a RLC STATUS PDU defined above.

[0055] The state variable VT (MS) is an SN calculated as VT (MS) = VT (A) + VT (WS) in which the VT (WS) is derived as described above. The VR (MR) state variable is an SN derived from Configured_Rx_Window_Size in octets sent by the upper layers, so that the length in octets of the window limited by VR (R) and (MR) is as wide as possible without exceeding the Configured_Rx_Window_Size in octets.

Improved RLC PDU creation

[0056] Figure 5 presents a flow diagram for a method for creating an improved RLC PDU based on octets, 500 for both uplink and downlink, based on the following parameters:

• Current_Credit: In the uplink, this is the amount of data that can be transmitted based on a MAC link adaptation and is sent by the MAC to RLC in the EU, or at Node B in simple architectural systems like long-term evolution ( LTE) and Launch 8 of the broadband code division multiple access systems (WCDMA). In the downlink, this is the result of the remaining credit allocation plus any new credit allocation from the Node-B to the RNC. This amount is represented in octets.

• Available_Data: These are the data available to be transmitted at the RLC entity. This amount is represented in octets.

• Leftover_Window: This is the window length limited by the VT (S) and the VT (MS) on the RLC transmitter. This amount is represented in octets.

• Maximum_RLC_ PDU_size: This is the maximum RLC PDU size configured by the upper layers, for example, the RCC layer.

• Minimum_RLC_PDU_size: This is a parameter configured by the upper layers, for example, the RRC layer, which specifies the RLC PDU size. Alternatively, the upper layers can specify the minimum load size

Petition 870190119684, of 11/18/2019, p. 31/50

19/29 of RLC PDU from which the Minimum_RLC_PDU_size can be inferred.

[0057] After the RLC PDU generation started, at each transmission time interval (ΤΠ), the following quantities were calculated (step 505):

X = Min {Current_Credit, Available_Data, Leftover_Window} Equation (3)

N = Floor {X / Maximum_RLC_PDU_size) Equation (4)

L = X mod Maximum_RLC_PDU_size Equation (5) where the Min {} function provides the minimum value of the set, the Floor function provides the closest smaller interior value, and mod b is the division of module b of a. RLC N PSUs of size Maximum_RLC_PDU_size are generated (step 505). Optionally, if L is non-zero, an additional RLC PDU can be created for the TTI. It was determined that X is equal to the parameters Leftover_Window or Current_Credit (step 510). If so, it was determined that L is greater than the Minimum_RLC_PDU_size parameter or if X is equal to Available_Data (515). If the L is greater than the Minimum_RLC_PDU_size, or if X is equal to the Available_Data, then the RLC PDU of length L will be generated (520). In addition, if X is not equal to Leftover_Window or Current_Credit, then an RLC PDU of length L is generated (520). Another option, if the L is less than the Minimum_RLC_PDU_size, a Minimum_RLC_PDU_size RLC PDU can be created. The generated RLC PDU (s) will be stored in a transmission buffer (525). Method 500 can be repeated at each TTI, or alternatively, when data is available or requested by lower layers (530).

[0058] As a result of the 500 method described here earlier, the number of PDUs of length equal to the maximum RLC PDU size generated in this time period, which is typically a TTI or some other system-specified time period , 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 can also be generated in the same period with a size equal 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

Petition 870190119684, of 11/18/2019, p. 32/50

20/29

RLC PDU can also be generated in the same period with a size equal to Min {Current_Credit, Leftover_Window, Available_Data} mod Maximum_RLC_PDU_size. If Min {Current_Credit, Available_Data, Leftover_Window) = Leftover_Window, then another RLC PDU can also be generated in the same period with a size equal to Min {Current_Credit, Leftover_Window, Available_Data} mod Maximum_RLC_ PDU_size, if and only if this PDU length is greater than Minimum_RLC_PDU_size.

[0059] The creation of RLC PDU of variable size can also be applied without the Minimum_RLC_PDU_size and / or the limitations of Minimum_RLC_ PDU_size. Alternatively, it is also possible to define the RLC PDU size limitations and allow the transmitter to choose a size with these limitations without a TTI-based relationship with the MAC layer link adaptation.

[0060] Alternatively, a RLC PDU of size X can be created with a system in which the parameters minimum_RLC_PDU_size and maximum_RLC_PDU_size have not been defined.

[0061] An alternative method of realization, the realization of window management, the current state variables used for the RLC PDU size are maintained and can be used simultaneously with a set of new variables that deal with the counting RLC PDUs flexible bytes. More specifically, some of the values ​​maintained in terms of the number of PDUs and processed in unimproved RLCs may include • The state variables of RLC transmitters: VT (S), VT (A), VT (MS), VT ( WS) • The RLC receiver state variables: VR (R), VR (H), VR (MR)

[0062] VT (WS) is maintained in terms of maximum number of PDUs and was originally configured for outer layers based on the size parameter Configured_Tx_Window_size provided in the number of PDUs. This value can correspond to the maximum number of PDUs allowed for the window, and / or the maximum number of PDUs limited by the number of bits used for the sequence number. For example, if 12 bits are used, then up to 212, or 4096 PDUs, can be supported. Optionally, for the flexible RLC PDU size, the VT (WS) can be prohibited from being updated using WINDOW SUFI. The calculation of VT (MS) remains, preferably, the same,

Petition 870190119684, of 11/18/2019, p. 33/50

21/29 in which VT (MS) = VT (A) + VT (WS). The other reception state variables can also be maintained and processed according to previous 3GPP standards.

[0063] In addition to these variables, the variables dealing with the byte count for the transmitter and receiver are also maintained and processed. Some variables that can be used are listed below, and are assumed to be maintained in terms of bytes. The names of these variables are used for descriptive purposes but they can be given any name. The variables include:

• Configure_Tx_Window_size_bytes - This protocol parameter indicates the maximum allowed transmission window size in octets and the value for the VT (WS) _bytes state variable. This variable can be configured, for example, in one of the following ways: by the upper layers, by the network, pre-configured in the EU, or determined in the EU, based on memory requirements or EU category.

• VT (WS) _bytes - size of transmission window data in octets. This status variable contains the size in octets that must be used for the transmission window. One option is that the VT (WS) _bytes should be the same as the WSN field when the transmitter receives a STATUS PDU including a WINDOW_BYTE SUFI. The initial value and the maximum value for this state variable are given by Configure_Tx_Window_size_bytes.

• Window_utilization: length in bytes of the TX window used. For each transmission the byte count is increased by the size of the RLC PDU to be transmitted for the first time. For each PDU discarded, the byte count is decreased for the RCL PDU size to be discarded.

• RxWMAX: length in bytes of the maximum size of the Rx window given in octets for the upper layers.

• RxWUTIL: length in bytes of the Rx window used. The variable will be increased by the size of the RLC PDU upon receipt of a new RLC PDU, and it will be decreased by the size of an RLC PDU when an RLC PDU is removed from the buffer.

• RxN: length in bytes of the PDU received at the same time

[0064] The combination of old and new state variables will allow RLC

Petition 870190119684, of 11/18/2019, p. 34/50

22/29 control the Tx and Rx windows in terms of the maximum number of bytes allowed and also in terms of the maximum number of PDUs allowed (limited by the number of sequence numbers available for transmission).

RLC procedure affected by the introduction of flexible RLC PDU

[0065] Some of the procedures in 3GPP TS 25.322 V7.1.0 can be updated as described in the explanations of this document to be compatible with and manage the Tx and Rx windows for RLC PDU, including the following procedures: • Transmission of PDU from AMD • Submission of AMD PDUs to lower layers • Reception of AMD PDU by the receiver • Reception of AMD PDU by the receiver • Reception of AMD PDU outside the reception window

[0066] The procedures associated with reconfiguring and resetting the state variables Tx and Rx can be updated.

Recognition Mode Date PDU (AMD) Transmission

[0067] For a fixed RLC PDU, when AMD PDUs are retransmitted, the transmitter must ensure that the AMD PDU SN is less than the maximum variable sent VT (MS). The SN of the retransmitted AMD PDU can be greater than the VT (MS) if the window size is updated by the receiver using WINDOW SUFI.

[0068] For a flexible RLC PDU size, the transmitter can also check the use of the Tx window until the retransmitted AMD PDU does not exceed the maximum window size in bytes using the VT (WS) _bytes state variable. The Window_utilization state variable is the total size of the RLC PDUs transmitted in the relay buffer. Therefore, when this condition is verified, the utilization up to the retransmitted SN can be calculated independently. If the Window_utilization is less than VT (WS) _bytes, the condition is reached automatically; however, if the window_utilization is greater than VT (WS) _bytes, the buffer utilization up to the AMD PDU must be calculated to ensure that it does not exceed VT (WS) _bytes. Thus, another option is to calculate buffer usage if window_utilization exceeds the VT (WS) _bytes state variable.

Petition 870190119684, of 11/18/2019, p. 35/50

23/29

[0069] For example, the AMD PDU transmission procedure can be modified as follows to take into account the fixed and flexible RLC PDU sizes, as noted by the upper layers:

• If the fixed size of the RLC PDU is configured, then:

• for each AMD PDU that has been negatively recognized:

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

• program the AMD PDU for retransmission;

• If the flexible RLC PDU size is configured, then:

• for each AMD PDU that has been negatively recognized:

• if (1) the usage window until the AMD PDU SN is less than

VT (WS) _bytes, where this condition is always true if window_utilization &lt;VT (WS) _bytes, or is calculated as the window used up to SN and (2), optionally, if the AMD PDU SN is less than that VT (M) then:

• program the AMD PDU for retransmission.

[0070] Sending AMD PDUs to lower layers

[0071] One of the conditions to allow the transmission of an AMD PDU is that the SN of the AMD PDU is less than the state variable VT (MS). When a flexible RLC PDU size is configured, an additional condition is to verify that the use of the window for the transmitted or retransmitted PDU does not exceed the maximum window size in bytes. The lower layers include the MAC layer and the physical layer.

[0072] According to one approach, if one or more AMD PDUs have been programmed for transmission or retransmission (see, for example 3GPP TS 25.322 V7.1.0 sub-clause 11.3.2), then the issuer can:

• do not send any AMD PDUs that do not allow transmission to lower layers. When the fixed size of the RLC PDU is configured, an AMD PDU can be transmitted if the AMD PDU has an SN &lt;VT (MS) or if the AMD PDU has an SN equal to VT (S) -1. If the flexible RLC PDU size is configured, the AMD PDU can be transmitted if (1) it has an SN &lt;VT (MS) or if the AMD PDU has an SN equal to VT (S) -1, and (2) if the AMD PDU transmitted does not make the

Petition 870190119684, of 11/18/2019, p. 36/50

24/29 use of windows, determined by AMD's window_utilization + PDU size, exceeds VT (WS) _bytes. In addition, an AMD PDU may be transmitted if the AMD PDU is not restricted to being transmitted by a local suspend function (see, for example, 3GPP TS 25.322 V7.1.0 and sub-clause).

• inform the lower layers of both the number of AMD PDUs scheduled for transmission or retransmission and that allow transmission or retransmission. Another option, if the flexible size of the RLC PDU is configured, is for the sender to inform the lower layers about the number of bytes to be programmed.

• adjust AMD PDU contents in accordance with, for example, 3GPP TS 25.322 V7.1.0 sub-clause 11.3.2.1.

• submit the requested number of AMD PDUs to the lower layers. Another option, if the flexible RLC PDU size is configured, is that the sender can also submit to the lower layers the number of bytes required by the lower layers.

• treat retransmissions with higher priority than AMD PDUs transmitted for the first time.

• update the state variables for each AMD PDU submitted to the lower layer (see, for example, 3GPP TS 25.322 V7.1.0 sub-clause 9.4 for the state variables) except VT (DAT), which counts the number of times an AMD PDU has been programmed and transmitted and has already been updated when the AMD PDU contents have been adjusted (see, for example, 3GPP TS 25.322 V7.1.0 sub-clause 11.3.2).

• if the flexible RLC PDU size is configured, update the window_utilization variable, thus updating the variables associated with byte count tracking.

• if (1) the query bit, used by the transmitter to request a status report from the receiver, is set to 1 on any of the AMD PDUs, and (2) Timer_Poll, a timer to monitor an AMD PDU containing a query indicated by the lower layers, is configured, then start the Timer_Poll timer (see, for example, 3GPP TS 25.322 V7.1.0, sub-clause 9.5).

Petition 870190119684, of 11/18/2019, p. 37/50

25/29 • buffer AMD PDUs that have not been submitted to the lower layers according to a disposal configuration (see, for example, 3GPP TS 25.322 V7.1.0, sub-clause 9.7.3).

Receipt of AMD PDU by the Receiver

[0073] The procedure associated with receiving an AMD PDU by the receiver is updated to include and update the receiver state variables associated with the byte count for the flexible RLC PDU size. The improved procedure is defined as follows. Upon receipt of an AMD PDU, the receiver must: • in the UE:

• If the downlink size of the AMD PDU has not been adjusted yet, then • adjust the downlink size of the AMD PDU to the size of the received PDU.

• update the VR (R), VR (H) and VR (MR) status variables for each AMD PDU received (see, for example, 3GPP TS 25.322 V7.1.0 clause 9.4);

• if the flexible size of the RLC PDU is configured, then • update the state variable RxWUTIL by setting RxWUTIL to be equal to RxWUTIL plus the size of the new RLC PDUs received minus the size of the RLC PDUs removed from the buffer due to a reception in order.

AMD PDU reception outside the reception window

[0074] If the fixed size of the RLC PDU is configured, then, when receiving an AMD PDU with an SN outside the VR (R) &lt;SN &lt;VR (MR) range, the receiver must:

• discard the AMD PDU;

• if the query bit on the discarded AMD PDU is set to 1 then • start the STATUS PDU transfer procedure.

[0075] If the size of the RLC PDU is configured, on receipt of a new AMD PDU whose size added to RxWUTIL exceeds RxWMAX (in which RxWMAX &lt;RxWUTIL + the size of the new AMD PDU received, or RxN) or, on receipt of an AMD PDU with the SN outside the VR (R) &lt;SN &lt;VR (MR) range, the receiver must:

• discard the AMD PDU;

• if the query bit in the discarded AMD PDU is set to 1 then

Petition 870190119684, of 11/18/2019, p. 38/50

26/29 • start the STATUS PDU transfer procedure.

RLC Status Report

[0076] RLC status reports that contain recognition information to support the ARQ can be triggered in various scenarios by the RLC Tx and RLC Rx entities. To link with the flexible RLC PDU size, the RLC Tx and RLC Rx entities can maintain a mapping of the RLC PDU SN to the corresponding length in bytes. This allows the calculation and maintenance of the flow control window length used in bytes or any other measure based on bytes as described here.

[0077] A parameter equivalent to Every Poll_PDU PDU, the upper limit for the VT state variable (PDU) to maintain a query monitoring, can be configured in terms of bytes. In this case, the transmitter may have a PDU counting query mechanism and / or a byte counting query mechanism, so that the transmitter receives the information from the recipient of each Poll_Bytes byte. For purposes of description, it is assumed that the query parameter provided by the upper layers is called Poll_Bytes. If configured for query, the RLC transmitter can trigger a status report by setting the query bit on some PDUs as follows:

• The RLC transmitter maintains a counter for the total number of bytes transmitted in PDUs since the transmission of the last PDU containing a query bit, in which the last PDU containing a query bit can be due to any type of query trigger, including, for example, Poll_PDU, PollJSDU or Poll_bytes, or, alternatively, it may be restricted to the last PDU containing a query bit triggered due to the byte query mechanism.

• When the counter reaches or exceeds the Poll_Bytes value, the RLC transmitter sets the query bit in the PDU (or, otherwise, the next PDU) that caused the counter to be greater than or equal to the Poll_Bytes value and restart the counter.

[0078] In this document, setting a query bit refers to a query request, so that a query request can consist of a SUFI POLL PDU, or it can consist of a query bit setting in a PDU of AMD RLC. O

Petition 870190119684, of 11/18/2019, p. 39/50

27/29 total number of bytes transmitted in PDUs must refer to the size of PDUs transmitted for the first time. On the other hand, it can refer to the size of all transmitted PUSH, including retransmissions. The total number of bytes transmitted can only count for the first PDU (AMD) transmission of RLC recognized data mode, the RLC AMD PDU segment or a portion of the RLC SDU, in which the retransmissions of those data portions cannot be counted.

[0079] The protocol parameters Poll_PDU and PollJSDU are assigned by upper layers, such as RRC, to the RLC layer to indicate a PDU count interval. In addition, the protocol parameter Poll_Bytes in octets can be checked and configured for upper layers. Consultation procedures on an RLC transmitter may include the following:

[0080] The RLC transmitter maintains a PollJDctets variable counter to monitor the total number of bytes transmitted in PDUs since the transmission of the last PDU containing a query bit, which may have been triggered due, for example, to the reception of the parameters Poll_PDU, PollJSDU or Poll_Bytes from the top layers. PollJDctets can, on the other hand, monitor the total number of bytes transmitted since the last PDU containing a query bit triggered due only to the byte query mechanism.

[0081] The Poll_Octets counter can, in another way, count a total number of bytes of a first transmission from each PDU (AMD) in recognized RLC data mode. The PollJDctets counter can, on the other hand, count only RLC data PDUs, so that RLC control PDUs are not counted. When the Poll_Octets counter reaches the Poll_Bytes interval value, the RLC transmitter sets the query bit in the PDU (or, otherwise, the next PDU) that causes the Poll_Octets counter to exceed the Poll_Bytes limit, and reset the poll_Bytes counter. Poll_Octets. The PollJDctets counter can also be reset if the query bit is set due to other query conditions such as receiving a Poll_PDU.

[0082] When the flexible RLC PDU sizes are compatible with AM RLC, the flexible RLC PDU size mode has been adjusted for the RRC layer, and the window-based query has been configured in the upper layers, the parameters of

Petition 870190119684, of 11/18/2019, p. 40/50

28/29 Poll_Window protocol was signaled by layers higher than RLC to inform the transmitter to consult the receiver. Poll_Window can be given in terms of a percentage window or in terms of the number of bytes. A query is triggered by the transmitter for each AMD PDU when the K value is greater than or equal to the Poll_Window parameter, where K is the percentage of transmission window defined as:

K = utilized_window / Maximum_Tx_Window_Size (in octets).

[0083] Equation (6), in which utilized_window is the length in octets of the window limited by the state variables VT (A) and VT (S). The window used represents the buffer used for the remaining data in the transmission buffer. If Poll_Window is given in terms of the number of bytes, K is equivalent to utilized_window. Therefore, the transmitter will trigger a query request if the utilized_window exceeds the number of Poll_window bytes signaled by the network.

[0084] The RLC transmitter can trigger a status report by setting the query bit when the size of the Tx window used is greater than a determined limit set by the system in terms of the number of bytes or in terms of percentage of maximum size window. The RLC receiver can trigger a status report when the size of the Rx window used is greater than a certain limit configured in terms of the number of bytes or a percentage of maximum window size.

[0085] Poll_Window indicates when the transmitter should consult the receiver, in cases in which window-based consultation is configured for the upper layers. A query will be triggered for each AMD PDU when: the J value is greater than the Poll_Window parameter, where J is the percentage of transmission window defined as:

J = (4096 + VT (S) + l-VT (A)) mod4096 x x100 Equation (7)

VT (WS) in which the constant 4096 is the AM module described in 3GPP TS 25.322 V7.1.0 subclause 9.4 and VT (S) is the initial value of Poll_Window before the AMD PDU is submitted to the lower layers.

Petition 870190119684, of 11/18/2019, p. 41/50

29/29

[0086] If the flexible RLC PDU size is configured, a query will also be triggered for each AMD PDU when the K value is greater than the Poll_Window parameter, where K is defined as:

K = A Sum of RLC PDU sizes from VT (A) to VT (S) x 100 Equation (8) Maximum Transmission Window Size

[0087] Although the explanations present are described in the context of RLC transmitting (Tx) and receiving (Rx) entities, they are applicable for both uplink communications (UE for UTRAN / E-UTRAN) and downlink (UTRAN / E-UTRAN for EU). For example, in the direction of uplink the configuration / reconfiguration of the Configured_Tx_Window_Size parameter causes:

• The UE derives the variable VT (WS) from the Configured_Tx_Window_Size, as described above.

• The UE updates the state variable VT (MS) as described above.

Petition 870190119684, of 11/18/2019, p. 42/50

1/4