WO2015185106A1

WO2015185106A1 - Setting initial state of reordering window for protocol entity based on first received protocol data unit

Info

Publication number: WO2015185106A1
Application number: PCT/EP2014/061454
Authority: WO
Inventors: Henri Markus Koskinen
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2014-06-03
Filing date: 2014-06-03
Publication date: 2015-12-10

Abstract

An example technique may include initiating, by a user device in a wireless network, a protocol entity, determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

Description

DESCRIPTION

TITLE

SETTING INITIAL STATE OF REORDERING WINDOW FOR PROTOCOL ENTITY BASED ON FIRST RECEIVED PROTOCOL DATA UNIT

TECHNICAL FIELD

[0001 ] This description relates to communications.

BACKGROUND

[0002] A communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. Signals can be carried on wired or wireless carriers.

[0003] An example of a cellular communication system is an architecture that is being standardized by the 3^rd Generation Partnership Project (3GPP). A recent development in this field is often referred to as the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology. E- UTRA (evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's Long Term Evolution (LTE) upgrade path for mobile networks. In LTE, base stations, which are referred to as enhanced Node Bs (eNBs), provide wireless access within a coverage area or cell. In LTE, mobile devices, or mobile stations are referred to as user equipments (UE). LTE has included a number of improvements or developments.

SUMMARY

[0004] According to an example implementation, a method may include initiating, by a user device in a wireless network, a protocol entity, determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, and setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0005] According to another example implementation, an apparatus includes at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: initiate, by a user device in a wireless network, a protocol entity, determine that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, and set, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0006] According to another example implementation, a computer program product includes a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising: initiating, by a user device in a wireless network, a protocol entity, determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, and setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0007] According to an example implementation, a method may include setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received and setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[0008] According to another example implementation, an apparatus includes at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: set, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received, and set, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[0009] According to another example implementation, a computer program product includes a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received, and setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[0010] According to an example implementation, a method may include setting, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[0011 ] According to another example implementation, an apparatus includes at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: set, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received. [0012] According to another example implementation, a computer program product includes a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising: setting, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[0013] The details of one or more examples of implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] FIG. 1 is a block diagram of a wireless network 130 according to an example implementation.

[0015] FIG. 2 is a diagram illustrating an example implementation of a user device.

[0016] FIG. 3 is a flow chart illustrating operation of a user device according to an example implementation.

[0017] FIG. 4 is a flow chart illustrating operation of a user device according to another example implementation.

[0018] FIG. 5 is a flow chart illustrating operation of a user device according to another example implementation.

[0019] FIG. 6 is a block diagram of a wireless device (e.g., user device, BS or other wireless device) 600 according to an example implementation.

DETAILED DESCRIPTION

[0020] Various example implementations are provided relating to setting a state (such as an initial state) of a reordering window for a protocol entity based on a first received protocol data unit. According to an example implementation, one or more state variables and/or a state of a reordering (receiving) window may be set to an initial value based on a sequence number of a protocol data unit (PDU) that is first received by a receiving protocol entity. These techniques may be applied for unacknowledged mode (UM) and acknowledged mode (AM) protocol entities. For example, setting an initial value of a state variable or reordering window for a receiving protocol entity (e.g., radio link control entity) may be used for user devices that perform device-to-device (D2D) communication or operate in a D2D wireless network or a proximity-based services (Pro- Se) wireless network in which user devices may join or re-join the reception of protocol data units from a transmitting user device at various points in time.

[0021 ] According to an example implementation, a technique may include initiating, by a user device in a wireless network, a protocol entity (e.g., an

unacknowledged mode radio link control entity), determining that a state variable (e.g., VR(UR)) that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, and setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0022] According to another example implementation, a technique may include setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received, and setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[0023] According to another example implementation, a technique may include setting, by a protocol entity, a state of an acknowledged mode reordering window of nonzero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[0024] FIG. 1 is a block diagram of a wireless network 130 according to an example implementation. In the wireless network 130 of FIG. 1 , user devices 131 , 132, 133 and 135, which may also be referred to as user equipments (UEs), may be connected (and in communication) with a base station (BS) 134, which may also be referred to as an enhanced Node B (eNB). At least part of the functionalities of a base station or (e)Node B may be also be carried out by any node, server or host which may be operably coupled to a transceiver, such as a remote radio head. BS 134 provides wireless coverage within a cell 136. Although only four user devices are shown as being connected or attached to BS 134, any number of user devices may be provided. BS 134 is also connected to a core network 150 via a S1 interface 151 . This is merely one simple example of a wireless network, and others may be used.

[0025] A user device (user terminal, user equipment (UE)) may refer to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station, a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device using a wireless modem (alarm or measurement device, etc.), a laptop and/or touch screen computer, a tablet, a phablet, a game console, a notebook, and a multimedia device, as examples. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network.

[0026] In LTE (as an example), core network 150 may be referred to as Evolved Packet Core (EPC), which may include a mobility management entity (MME) which may handle or assist with mobility/handover of user devices between BSs, one or more gateways that may forward data and control signals between the BSs and packet data networks or the Internet, and other control functions or blocks.

[0027] According to an example implementation, user devices 131 ,132, 133 and 135 may be in proximity to each other. User device 131 and 132 may be part of user group 1 (e.g., D2D user group 1 ), while user devices 133 and 135 may be part of user group 2 (e.g., D2D user group 2), for example. Alternatively, user devices 131 , 132, 133and 135 may be part of the same user group. One of the user devices, such as user device 131 may also operate as a multi-user group cluster head. A cluster head may transmit synchronization signals, and may also transmit a channel occupation (or channel occupancy) information for one or more channels including, for each channel, identifying whether the channel is free or occupied, and identify the user group that is occupying the channel and/or the user device ID of the user device that is occupying the channel if the channel is occupied, for example, or provide/transmit other control information to other user devices.

[0028] According to an example implementation, the user devices 131 , 132, 133 and/or 135 may operate in a proximity-based services mode, such as a device-to-device (D2D) mode of operation in which user devices may directly communicate with each other. Thus, for a proximity-based services (Pro-Se) wireless network, such as a user device operating in a D2D mode, communications may occur directly between user devices, rather than passing through BS 134, for example. D2D communications may be performed, for example, in the event of a breakage of S1 interface 151 or other network failure. Alternatively, user devices may perform D2D communications even when no such network failure has occurred, such as, for example, to offload traffic from the network (BS 134 and/or core network 150) and/or to allow user devices to communicate directly in a D2D mode, even in absence of network coverage.

[0029] Therefore, the various techniques and example implementations described herein may be applicable to a user device that communicates via a BS (such as BS 134), and/or for user devices that communicate directly with one or more other user devices, such as for a proximity-based services (Pro-Se) wireless network or a D2D mode of operation for the user device. In addition, the various techniques and example implementations described herein may be applied, for example, to devices that may implement at least a portion of the LTE standard (and improvements to LTE, such as LTE-Advanced, etc.), and also to non-LTE devices, e.g., which may implement other standards or protocols in some cases.

[0030] FIG. 2 is a diagram illustrating an example implementation of a user device. Each user device may include at least one radio protocol stack that may be implemented in hardware and/or software. According to an example implementation, a protocol stack may include logic, and/or computer instructions executed by a processor to perform the functions or operations for each entity of the protocol stack. An example protocol stack for a user device 210 may include several protocol entities, such as, for example, a Packet Data Convergence Protocol (PDCP) entity 240, a Radio Link Control (RLC) entity 242, a Media Access Control (MAC) entity 244, a Physical layer (PHY) entity 246, and a Radio Resource Control (RRC) entity 248. [0031 ] The PDCP entity 240 may, for example, perform ciphering (encryption and decryption of data) and header compression-decompression. The RLC entity 242 may, for example, perform segmentation/concatenation, error detection and correction, data retransmission, duplicate detection and in-sequence data delivery to higher layers. According to an example implementation, there may be one RLC corresponding to one logical channel. MAC entity 244 performs multiplexing of logical channels (where there may be one or more logical channels), hybrid ARQ retransmissions, inserting of MAC control elements (MAC CEs) used for in-band control signaling, and other MAC-related functions. The PHY entity 246 handles or performs coding/decoding,

modulation/demodulation, multi-antenna mapping, and other physical layer functions. Multiple RLC entities within a user device may share one MAC entity 244 and one PHY entity 246.

[0032] RRC entity 248 may be responsible for handling a number of functions or procedures related to the Radio Access Network (RAN).

[0033] According to an example implementation, one or more user devices may operate in a 1 :M D2D mode in which the user devices may communicate directly with each other. In an example 1 :M D2D mode of operation, a transmitting user device may broadcast data via a shared wireless channel to a plurality (M) of other user devices that are also operating in a D2D mode. A user device may have multiple applications that may be transmitting data in a D2D mode of operation. According to an example implementation, at a transmitting user device, a user plane (UP) protocol configuration may be initiated or configured (e.g., by the RRC entity 248) for each application that is transmitting data. User plane entities may, for example, include one or more entities at a user device that are involved in transmitting data to and/or receiving data from other user devices. For example, a user device may include multiple transmitting applications including, for example, a voice application (e.g., voice over LTE or VoLTE) to transmit voice data, and a texting or messaging application to transmit text data. These are merely two examples, and other applications may be used or provided.

[0034] According to an example implementation, a UP protocol configuration may be configured or initiated for each application that is transmitting data on a user device operating in a D2D mode of operation to other user devices. According to an example implementation, a UP protocol configuration may include one or more UP protocol entities, such as a RLC entity 242 and/or a PDCP entity 240, and a logical channel 250 provided to the RLC entity 242 by the MAC entity 244. A logical channel may be provided by the MAC entity 244 to an RLC entity 242, for communication with a peer RLC entity. For example, at a transmitting user device in D2D mode, a first RLC entity and a first logical channel may be initiated or configured for a voice application to transmit voice data, while a second RLC entity and a second logical channel may be initiated or configured for a messaging application to transmit messaging-related data. In various example implementations, a PDCP entity may be provided for each RLC entity, or a PDCP entity may not necessarily be used for D2D communications, in the above- described example involving a voice application and a messaging application.

[0035] According to an example implementation, a user device operating in a D2D mode that is receiving data from one or more applications (which may be referred to as a receiving user device) of one or more other D2D user devices may include a UP protocol entity (e.g., including entities such as a RLC entity 242 and/or a PDCP entity 240, and a logical channel 250) to receive data from each transmitting application. A receiving user device also includes a MAC entity 244 and a PHY entity, which may be shared among multiple RLC entities. At a receiving user device, a RLC entity may be initiated or provided to receive data from each transmitting user device (or from each application transmitting from the user device). In one example implementation, a UP protocol configuration does not necessarily need to be created or initiated in advance by a receiving user device, but may be initiated or configured based upon receipt of data (e.g., a protocol data unit or PDU) from another D2D user device.

[0036] For example, a first application of a first user device (operating in D2D mode) may be transmitting data to a plurality of D2D user devices, including to a second user device. The MAC entity of the (receiving) second user device may receive a MAC protocol data unit (PDU) from the first user device, and decodes the MAC PDU. The MAC PDU may include, for example, a source ID that includes a user device identifier (user device ID), a destination ID (which may be set to a user group ID, of which the second user device is a member), and a logical channel ID to identify a logical channel for the data (e.g., where a different logical channel may be used for each application that is transmitting data from a user device). Based on the source ID (identifying the transmitting user device) and the logical channel ID (e.g., LCID) in the MAC PDU, the MAC entity 244 of the receiving user device may determine if a UP protocol

configuration has already been initiated or configured for this source ID/LCID combination. If this is a first MAC PDU for the source ID/LCID (e.g., no UP protocol configuration has yet been initiated or configured for such source ID/LCID), then the MAC entity 244 on the receiving user device sends an indication to the RRC entity 248 on the receiving user device. In response to receiving this indication, the RRC entity 248 of the receiving user device may initiate or configure a UP protocol configuration for this source ID/LCID, e.g., including a PDCP entity 240, a RLC entity 242 and a logical channel 250, for example. The existing MAC entity 244 and PHY entity 246 may be used/shared by this new UP protocol configuration at the receiving user device. In another example implementation, the RRC entity 248 of the receiving user device may configure or initiate a UP protocol configuration that includes only a RLC entity 242 and a logical channel 250. Thus, for example, a receiving user device may create or include a separate RLC entity and logical channel for each user device that is transmitting data (e.g., a user device may include a separate RLC entity and logical channel to receive data from an application of a transmitting D2D user device).

[0037] In general, an RLC entity may perform (e.g., one or more of) the following: segmentation, concatenation and reassembly of RLC service data units (SDUs); in-sequence delivery and duplicate detection for the corresponding logical channel; and, RLC retransmission (only for AM). Retransmissions of missing or erroneous data units (or PDUs) are also handled by the hybrid-ARQ mechanism in the MAC entity, complemented by the retransmission functionality of the RLC entity (RLC AM only).

[0038] To keep track of PDUs in transit, the transmitting RLC entity includes an RLC header for each RLC PDU, including, among other fields, a sequence number (SN) for the PDU. An RLC entity 242 may operate in either an acknowledged mode (AM), unacknowledged mode (UM), or transparent mode (TM). In TM, the RLC entity is transparent and is essentially bypassed, with no retransmissions, no

segmentation/reassembly, and no in-sequence delivery being performed by RLC entity, e.g., and may be used for broadcast control channels, for example. UM supports segmentation/reassembly, and in-sequence delivery of data, but not retransmissions by the RLC entity (although HARQ retransmissions are provided by MAC entity). UM mode is typically used when error-free delivery is not required, such, as, for example, Voice over IP (VoIP), Voice over LTE (VoLTE), etc. AM provides segmentation/reassembly, in- sequence delivery, and retransmissions (at the RLC entity, in addition to HARQ retransmissions by the MAC entity) of erroneous data.

[0039] For a receiving RLC entity, in-sequence delivery may include storing (by the receiving RLC entity or by the receiving user device) the received PDUs in a data buffer until all PDUs with a lower sequence number have been delivered or timed out (skipping a data unit due to expiration of a reorder (or reordering) timer may be performed by RLC entity for UM). For example, at a receiving RLC entity, if PDU n has been received (along with all earlier PDUs), a reordering window or receiving/reception window (these terms reordering window, receiving window and reception window may be used interchangeably herein) may be advanced and the payload of the PDU n is passed up to higher layers/PDCP entity. Next, a PDU n+2 may be received although PDU n+1 has not yet been received. The payload (e.g., data portion) of PDU n+2 cannot yet be delivered to the upper layer (PDCP) since the receiving RLC entity is waiting to receive PDU n+1 . A reordering timer may be started for PDU n+1 (missing PDU). When the reordering timer expires (without receiving the missing PDU n+1 ), then the payload of PDU n+2 may be delivered by a UM receiving RLC entity to the PDCP entity (for UM), or the AM receiving RLC entity may request retransmission from the peer RLC entity (AM).

[0040] As noted, when a receiving RLC entity determines a gap in SNs or the SNs of received PDUs indicate a missing PDU (e.g., due to a skipped SN for received PDUs), the receiving RLC entity starts a reordering timer for the missing PDU. The expiry time of the reordering timer may be set, for example, to a value that may be sufficient for the underlying MAC layer to perform a maximum number of retransmission attempts for the missing PDU. If the reordering timer expires before the missing PDU has been received by the UM receiving RLC entity, then the UM receiving RLC entity may simply skip the missing RLC PDU and may pass up to the receiving PDCP entity payload from subsequently received PDUs (or PDUs with a higher sequence number(s) than the missing PDU). In other words, UM tolerates missing RLC PDUs, e.g., in the case of dropped PDUs or packets for VolP/VoLTE, for example.

[0041 ] For an AM receiving RLC entity, expiration of the reordering timer may cause the AM receiving RLC entity to send a control PDU to the transmitting entity containing a status report (e.g., indicating that the missing PDU has not been received by receiving RLC entity), which may trigger a retransmission of the missing RLC PDU.

[0042] In AM (acknowledged mode) operation, the RLC entity is bidirectional, that is, data flows in both directions between two peer AM RLC entities. In AM, both peer (bidirectional) RLC entities maintain two windows, including a transmission (or transmit) window, and a receiving (or reception or reordering) window. For example, for AM, PDUs with a SN below the transmit window have already been acknowledged by the receiving RLC entity. Similarly, for AM, the receiving RLC entity only accepts PDUs with sequence numbers within the receiving (or reordering) window, for example. The receiving RLC entity may discard any duplicate PDUs as the payload of each PDU should be assembled into SDUs (service data units) only once for passing up to higher layers (e.g., PDCP entity).

[0043] For in-sequence delivery, data blocks are delivered by the receiver (or receiving RLC entity) to the PDCP entity in the same order that the data blocks were transmitted. Received PDUs may be stored in a data buffer until the payload of all PDUs behind the (or having a lower SN than the) received PDU has been delivered up to the receiving PDCP entity. When all PDUs behind (or lower sequence number than) the current PDU have been used for assembling SDUs to pass up to receiving PDCP entity, then the payload of the current PDU is passed up to the receiving PDCP. RLC retransmission is provided only for AM, and not for UM. The receiving RLC entity also performs duplicate detection. If a RLC PDU is received again by a receiving RLC entity, and is within the receiving/reordering window (despite the PDU having already been received), the PDU is discarded by the receiving RLC entity.

[0044] The UM (unacknowledged mode) operation of an RLC entity is similar to that described above for AM, except in UM, no retransmissions are performed, and each RLC entity is unidirectional. Also, a UM receiving RLC entity maintains a receiving (or reception window or reordering window) to track received PDUs.

[0045] Example Implementations For Unacknowledged Mode (UM) Operation

[0046] The operation of UM (unacknowledged mode) receiving RLC entity will be described in more detail. Several unacknowledged mode state variables may be used and updated to keep track of the state of the UM RLC entity, including one or more state variables that may define the state (e.g., identify a sequence number for an upper edge and/or lower edge) of the reordering window (which may also be referred to as the reception/receiving window). Some of the UM state variables may include the following, as examples:

[0047] VR(UR) - this UM state variable holds the value of the sequence number (SN) of the earliest UMD PDU that is still considered for reordering. For example, PDUs with sequence numbers that are below VR(UR) have already been received and passed up to a receiving PDCP entity, or omitted based on timeout of the reordering window for the PDU.

[0048] VR(UH) - this UM state variable holds the value of the sequence number following the sequence number of the UMD PDU with the highest sequence number among received UMD PDUs. VR(UH) defines a higher(or upper) edge of the reordering window. In UM, the reordering window may extend, for example, from VR(UH) down to (VR(UH)-UM Window Size), where UM Window Size is the size (in number of sequence numbers) of the UM reordering (or receiving) window.

[0049] The processing of PDUs by a receiving UM RLC entity is briefly described below, and includes Sections A and B.

[0050] Section A: The following actions may be performed by UM RLC entity when an UM PDU is received by the UM receiving RLC entity from a lower layer (e.g., received by MAC entity and passed up to RLC entity):

[0051 ] 1 ) When a UM PDU with SN = x is received from lower layer, the receiving UM RLC entity may perform the following:

[0052] 2) if VR(UH) has already been set to any value:

[0053] 3) if VR(UR) < x < VR(UH) and the UM PDU with SN = x has been received before; or

[0054] 4) if (VR(UH) - UM_Window_Size) <= x < VR(UR):

[0055] 5) discard the received UM PDU;

6) else (if neither of statements 3 and 4 is true):

7) place the received UM PDU in the reception buffer

[0056] 8) else: (if VR(UH) is not already set to a value):

[0057] 9) place the received UM PDU in the reception buffer.

[0058] Section B: The following actions are performed by UM RLC entity when an UMD PDU is placed in the reception buffer: When an UM PDU with SN = x is placed in the reception buffer, the receiving UM RLC entity may perform the following:

[0059] 10) if x falls outside of the reordering window or VR(UH) has not yet been set to any value:

[0060] 11 ) update VR(UH) to x + 1 ; [0061 ] 12) reassemble RLC SDUs (service data units) from any UMD

RLC PDUs with SNs that fall outside of the reordering window, remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer (e.g., PDCP entity) in ascending order of the RLC SN if not delivered before;

[0062] 13) if VR(UR) falls outside of the reordering window or has not yet been set to any value:

[0063] 14) set VR(UR) to (VR(UH) - UM_Window_Size);

[0064] According to an illustrative example implementation, a transmitting user device may be transmitting data units to one or more other user devices. In an example implementation, the user devices may be operating in a device-to-device (D2D) mode or operating as part of a proximity-based services network in which a transmitting user device may transmit or broadcast directly to one or more other user devices. An issue that may arise in such D2D wireless networks is that a receiving user device may start receiving data units in the middle of a transmission session, or may stop and later resume (or re-join) receiving data units from such transmitting user device. In some cases, a transmitting and receiving user device or RLC entity may agree to begin PDU SNs at 0 for a transmission session. However, this approach (starting sequence numbers at 0) may not necessarily work in the case of a D2D network where a receiving RLC entity may join or re-join a data reception from a transmitting peer RLC

entity/transmitting user device at any point in time. Therefore, according to an example implementation, techniques are provided herein to allow determining or setting state variables including setting a state of a reordering (or receiving) window at a receiving protocol entity (such as at a receiving RLC entity or a receiving PDCP entity) of a receiving user device, e.g., in the case of D2D or Pro-Se (proximity-based services) wireless operation/network, for example

[0065] In section A, at 1 ) a UMD PDU with SN = x is received by the receiving user device. Although not required, according to an example implementation, the MAC PDU received by the receiving user device may include data, a source ID that identifies the transmitting user device, a destination ID that may identify a receiving user device or a (D2D or proximity-based services) user group of which the receiving user device is a member, and a logical channel ID (LCID) that identifies the logical channel. According to an example implementation, a MAC PDU (transmitted from a transmitting user device) may be received by a MAC entity (at a receiving user device), which may cause the receiving MAC entity to notify a RRC entity 248 of a received PDU for a new logical channel or transmission session, e.g., for which no RLC entity exists at the receiving user device to receive the data units for this logical channel, for example. Therefore, in response to this notification from the MAC entity, the RRC entity at the receiving user node may initiate (or create an instance of) a RLC entity at the receiving user device to receive data units from this transmitting user device, e.g., for this logical channel.

[0066] At operation 2) of section A, the RLC entity (or other entity) at the receiving user device may determine if VR(UH) has already been set to any value. For example, VR(UH) would typically not be set to any value until after a first (e.g., first in time) PDU from the peer (transmitting) RLC entity has been received, e.g., for the logical channel. Alternatively, the RLC entity may determine whether another state variable (e.g., VR(UR)) or the state of the reordering (or receiving) window has been set to any value. In some cases, initially, none of the state variables (including VR(UH) or state of reordering window) for this receiving RLC entity have been set to any values. Thus, in such case wherein VR(UH) (or, alternatively, other state variable, and/or the state of the reordering window) has not been set to any value yet, the flow of section A may skip down to operations 8) and 9) where the received PDU is not discarded, and the received UM PDU is placed or stored in the reception buffer.

[0067] If VR(UH) has already been set to a value, then flow proceeds to operations 3) and 4) to determine if either operations 3) or 4) are true.

[0068] At operation 3), the receiving RLC entity determines if the SN (x) of the received PDU is a valid SN, e.g., whether VR(UR) < x (which indicates that the SN of the received PDU is greater than the earliest UM PDU that is still considered for reordering), and that x < VR(UH) (which indicates that the SN of the received PDU is within the reordering window, for example). If the SN = x of the received PDU is valid and the PDU has been received before, then the flow proceeds to operation 5) where the received PDU is discarded as a duplicate.

[0069] At operation 4), the receiving RLC entity determines if (VR(UH) - UM Window Size) <= x < VR(UR). If this is true, then x is less than the earliest UM PDU that is still considered for reordering, and flow proceeds to operation 5) where the received PDU is discarded as invalid (e.g., this PDU SN has already been passed up to PDCP or this PDU has been omitted based on a timeout of the reordering timer, for example). [0070] At operation 6), if neither of statements 3 and 4 is true, then operation proceeds to operation 7), wherein the received UM PDU is not discarded. Rather, the received PDU is placed or stored in the reception buffer.

[0071 ] At operation 8), if VR(UH) is not already set to a value, then operation proceeds to operation 9), wherein the received UM PDU is not discarded. Rather, the received PDU is placed or stored in the reception buffer.

[0072] Section B (above) describes the operation of the receiving UM RLC entity when a UM RLC PDU is placed in the buffer. At operation 10), the receiving RLC entity determines if x (the SN of the received PDU) falls outside of the reordering window or VR(UH) has not yet been set to any value. For example, if VR(UH) (for a receiving RLC entity or for a logical channel) has not been set to any value yet, then this indicates that this received PDU is a first PDU or a PDU that is received first by the receiving RLC entity from the transmitting RLC entity. If x is outside of the reordering window for this RLC entity or this logical channel, or if VR(UH) has not been set to any value (regardless of the value of the SN of the PDU that is first received, e.g., x may be inside or outside a reordering window), then operations 11 ) - 13) are performed.

[0073] At operation 11 ), VR(UH) is updated (or set) to x + 1 , which is the SN following the SN of the received PDU. Thus, for example, in the case where VR(UH) for a receiving RLC entity or logical channel has not been set to any value, VR(UH) may then be set to an initial value based on the sequence number of the PDU that is first received by the receiving protocol entity (e.g., receiving RLC entity or PDCP entity). For example, in the case where VR(UH) for a receiving RLC entity or logical channel has not been set to any value, VR(UH) may then be set to a sequence number (x+1 ) following the sequence number (x) of the PDU that is first received by the receiving protocol (e.g., RLC) entity. By setting VR(UH) to a value, this also sets a state of the UM reordering window for the UM RLC entity, since VR(UH) defines an upper edge of the reordering window. Also, as VR(UH) is incremented, this also moves or pulls forward the UM reordering window for this receiving RLC entity. Thus, according to an example implementation, the UM reordering window is a pull reordering window because the reordering window is pulled forward in response to increasing/incrementing of the state variable VR(UH), which identifies an upper edge of the reordering window.

[0074] At operation 12), the receiving RLC entity may deliver data for the received RLC PDUs to the upper layer (e.g., PDCP entity) in ascending order if not delivered before. For example, the receiving RLC entity reassembles RLC SDUs (service data units) from any UM RLC PDUs with SNs that fall outside of the reordering window, remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer (e.g., PDCP entity) in ascending order of the RLC SN if not delivered before.

[0075] At operation 13), the receiving RLC entity determines if VR(UR) falls outside of the reordering window or has not yet been set to any value. If VR(UR) falls outside of the reordering window or has not yet been set to any value, then VR(UR) may be set to a value based on operation 14). For example, at operation 14), the receiving RLC entity sets VR(UR) to (VR(UH) - UM_Window_Size). However, in this example implementation, the state variable, VR(UH), has now been set to a value of x+1 .

Therefore, operation 14) may set VR(UR) based on the following, for example:

[0076] VR(UR) = (x+1 ) - UM_Window_Size, where UM_Window_Size is the size of the unacknowledged mode reordering window for the receiving RLC entity. Finally, after being set to initial values (e.g., based on a sequence number of a RLC PDU that is first received by the receiving RLC entity), the reordering window and one or more state variables may be used by the receiving RLC entity to receive RLC PDUs from the transmitting RLC entity.

[0077] According to an example implementation, a protocol entity may be initiated. For example, a radio link control (RLC) entity may be initiated at a user device, e.g., in response to receiving a data unit from a transmitting user device for a new RLC entity or new logical channel. The protocol entity (e.g., RLC entity) may determine that a first state variable (e.g., the UM state variable, VR(UR)) that identifies an earliest PDU that is still considered for reordering has not been set to any value. The protocol entity (e.g., RLC entity) at the receiving user device may set the first state variable (e.g., VR(UR)) to an initial value based on a sequence number of a PDU that is first received by the protocol entity (e.g., RLC entity). In an example implementation, the RLC entity may set the first state variable (e.g., VR(UR)) to an initial value according to the following: VR(UR) = (x+1 ) - UM Window Size, where x is the sequence number of the PDU that is first received by the receiving protocol entity (e.g., RLC entity) or for the logical channel, and where UM Window Size is the size of the unacknowledged mode (UM) reordering window for the receiving RLC entity. A transmitting RLC entity may be provided on a transmitting user device, and a receiving RLC entity may be provided on a receiving user device. For example, the transmitting user device and the receiving user device may be part of a device-to-device (D2D) wireless network or a proximity-based services (Pro-Se) wireless network, or the transmitting user device and the receiving user device may be operating in a D2D mode of operation in which user devices directly transmit to other user devices.

[0078] In addition, the protocol entity, such as the receiving UM RLC entity, may determine that a second unacknowledged mode (UM) state variable (e.g., VR(UH)), which identifies a sequence number following a sequence number of an UMD PDU having a highest sequence number among received UMD PDUs (for the receiving RLC entity or for the logical channel), has not been set to any value. This may occur, for example, when the received UM PDU is a PDU that is first received by this receiving RLC entity or for this logical channel.

[0079] According to another example implementation, a protocol entity (e.g., RLC entity) of a receiving user device may set a state of a reordering window of nonzero size if the state of the reordering window has not been set to any value. For example, the state of the reordering window may be set according to (or based upon) a sequence number of a PDU that is first received by the protocol entity (e.g., RLC entity) before any other PDU, without any restriction on the sequence number of the PDU (e.g., SN of PDU may be inside or outside of a reordering window). For example, a reordering window of non-zero size may typically be a reordering window that is greater than zero. For example, a 10-bit sequence number may result in a sequence number space of 1024 (0-1023), and a reordering (or receiving) window of half the size (e.g., 512) of the sequence number space, as an example. Also, the state of the reordering window may not be set to any value, for example, before a first PDU has been received by the receiving protocol entity/RLC entity. For example, a state of a reordering window may be identified by an identification of (or defining) an upper edge or lower edge of the reordering window, since the reordering window may be of fixed size, such as half the sequence number space, according to an example implementation. For example, the state of a UM reordering window may be set according to (e.g., based on the value of) an UM state variable (e.g., VR(UH)) that defines an upper edge of the UM reordering window. Thus, for example, by setting the value of the state variable, VR(UH), this also sets or defines a state of the UM reordering window, according to an example implementation.

[0080] Example Implementations For Acknowledged Mode (AM) Operation [0081 ] The above-described techniques, which allow one or more state variables and a state of a reordering window to be set to an initial value based on a sequence number of a PDU that is first received by a receiving protocol entity, may also be applied to an acknowledged mode (AM) RLC entity. Several AM state variables may be used to keep track of the state of the AM RLC entity, including one or more state variables that may define the state (e.g., identify a sequence number for an upper edge and/or lower edge) of the reordering window (which may also be referred to as the reception/receiving window). Some of the AM state variables may include the following, as examples:

[0082] VR(R) - this AM state variable holds the value of the sequence number following the last in-sequence completely received AMD PDU, and it serves as the lower edge of the reordering/receiving window. It may be initially set to 0, unless otherwise set to an initial value (e.g., for D2D communication) based on sequence number of a first received AM PDU, and is updated whenever the AM RLC entity receives an AM PDU with SN=VR(R). According to an example implementation, the AM RLC entity may set the AM state variable VR(R) to an initial value based on a sequence number of the PDU that is first received by the RLC entity before any other PDU, if the variable VR(R) has not been set to any value.

[0083] VR(MS) - Maximum STATUS transmit state variable. This state variable holds the highest possible value of the SN which can be indicated by "ACK SN" when a STATUS PDU needs to be constructed. This state variable may be initially set to 0 unless otherwise configured, e.g. for the purpose of D2D communication (e.g., set to x+1 , based on SN (x) of first received PDU).

[0084] At reception of the first PDU with SN=x, VR(MS) should be set to x+1 , where x is the SN of the AMD PDU that is first received by the receiving AM RLC entity, regardless of the sequence number (SN) of the PDU that is first received (e.g., without any precondition or restriction on the SN of the first received PDU). ACK SN defines the first SN which cannot yet be confidently NACKed by the protocol (i.e. MAC-layer retransmissions may still be in progress).

[0085] Thus, for example, a AM RLC entity may set a state of an AM

reordering/receiving window of non-zero size if the state of the AM reordering/receiving window has not been set to any value. For example, the state of the AM reordering or receiving window may be set according to or based upon a sequence number of a PDU that is first received by the receiving AM RLC entity, without any restriction on the sequence number of the PDU that is first received (e.g., the SN of the first PDU may be any number, and may be, for example, inside or outside a reordering/receiving window). For example, a state of a AM reordering or receiving window may be set by the AM receiving RLC entity setting the AM sate variable VR(R) to an initial value, if the state variable VR(R) has not been set to any value, based on the following: VR(R) = x+1 , where x is the sequence number of the PDU that is first received by the AM RLC entity. Setting VR(R) sets or defines a state of the AM reordering/receiving window because, for example, the variable VR(R) defines a lower edge of the AM reordering/receiving window, and the receiving window may be a fixed size, e.g., half of the SN space. Thus, AM reordering or receiving window may be a push window where the reordering or receiving window is pushed forward as VR(R) is increased, for example.

[0086] Other AM state variables may also be defined or set based on a sequence number of a AMD PDU that is first received by the AM RLC entity for a transmitting user device or RLC entity (or for a logical channel). For example, a AM state variable, VR(H), which identifies a SN following a SN of an AM PDU with a highest SN among received AM PDUs, may be set to an initial value based on a SN of a PDU that is first received by the AM RLC entity, without restriction on the SN of the PDU that is first received, if the VR(H) state variable has not been set to any value. For example, VR(H) may be set to an initial value according to: VR(H) = x+1 , where x is the sequence number of the PDU that is first received by the receiving AM RLC entity.

[0087] FIG. 3 is a flow chart illustrating operation of a user device according to an example implementation. Operation 310 may include initiating, by a user device in a wireless network, a protocol entity. Operation 320 may include determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value. Operation 330 may include setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0088] In an example implementation of the method of FIG. 3, the state variable may include an unacknowledged mode state variable; wherein the determining comprises determining that an unacknowledged mode state variable that identifies an earliest unacknowledged mode protocol data unit that is still considered for reordering has not been set to any value; and wherein the setting comprises setting, by the protocol entity, the unacknowledged mode state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0089] In an example implementation of the method of FIG. 3, the

unacknowledged mode state variable may include a VR(UR) state variable for Long Term Evolution or Long Term Evolution Advanced standard.

[0090] In an example implementation of the method of FIG. 3, the initiating may include initiating, by a user device in a wireless network, a radio link control protocol entity.

[0091 ] In an example implementation of the method of FIG. 3, the setting may include setting, by the protocol entity, the state variable to an initial value equal to the following: VR(UR) = (x + 1 ) - UM_Window_Size, where VR(UR) is the state variable for unacknowledged mode, x is the sequence number of the protocol data unit that is first received by the protocol entity, and UM Window Size is a size of a reordering window of the protocol entity for receiving protocol data units.

[0092] In an example implementation of the method of FIG. 3, the protocol entity may include a first protocol entity at a first user device that is configured to receive protocol data units from a second protocol entity at a second user device, the first device and the second device being part of a proximity-based services (Pro-Se) wireless network or a device-to-device (D2D) wireless network.

[0093] In an example implementation of the method of FIG. 3, the

unacknowledged mode state variable may include a first unacknowledged mode state variable, the method further including: determining that a second unacknowledged mode state variable, which identifies a sequence number following a sequence number of an unacknowledged mode protocol data unit having a highest sequence number among received unacknowledged mode protocol data units, has not been set to any value; and setting, by the protocol entity, the second unacknowledged mode state variable to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0094] In an example implementation of the method of FIG. 3, the second unacknowledged mode state variable includes a VR(UH) state variable for Long Term Evolution or Long Term Evolution Advanced standard.

[0095] In an example implementation of the method of FIG. 3, the setting the second unacknowledged mode state variable comprises setting, by the protocol entity, the second unacknowledged mode state variable to an initial value equal to the following: VR(UH) = x+1 , where VR(UH) is the second unacknowledged mode state variable, and x is the sequence number of the protocol data unit that is first received by the protocol entity.

[0096] According to another example implementation, an apparatus may include means for carrying out any of the method elements described herein. According to another example implementation, a computer program product for a computer, may include software code portions for performing any of the steps or method elements described herein when said product is run on the computer.

[0097] An apparatus may include at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: initiate, by a user device in a wireless network, a protocol entity; determine that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value; and set, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0098] A computer program product, the computer program product including a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method including: initiating, by a user device in a wireless network, a protocol entity; determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value; and setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[0099] FIG. 4 is a flow chart illustrating operation of a user device according to another example implementation. Operation 410 may include setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received. Operation 420 may include setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[00100] Also, according to an example implementation, the protocol entity (e.g., RLC entity), which may be provided on a receiving user device, may receive (or control receiving) RLC PDUs from a peer protocol entity (e.g., a peer RLC entity) of a transmitting user device based on one or more state variables and/or the state of the reordering window.

[00101 ] In an example implementation of the method of FIG. 4, the setting a state variable may include setting, by the protocol entity, a first unacknowledged mode state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received, and the setting a state of a reordering window comprises setting, by the protocol entity, a second unacknowledged mode state variable that defines an upper edge of the reordering window to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[00102] In an example implementation of the method of FIG. 4, the setting the second unacknowledged mode state variable may include setting, by the protocol entity, the second unacknowledged mode state variable to an initial value equal to the following: VR(UH) = x+1 , where VR(UH) is the second unacknowledged mode state variable, and x is the sequence number of the protocol data unit that is first received by the protocol entity.

[00103] In an example implementation of the method of FIG. 4, the setting the first unacknowledged mode state variable may include setting, by the protocol entity, the first unacknowledged mode state variable to an initial value equal to the following: VR(UR) = (x + 1 ) - UM Window Size, where VR(UR) is the second unacknowledged mode state variable, x is the sequence number of the protocol data unit that is first received by the protocol entity, and UM Window Size is a size of a reordering window of the protocol entity for receiving protocol data units.

[00104] In an example implementation of the method of FIG. 4, the protocol entity may include a radio link control (RLC) protocol entity.

[00105] An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: set, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received; and set, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[00106] A computer program product, the computer program product including a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method including: setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received; and setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

[00107] FIG. 5 is a flow chart illustrating operation of a user device according to yet another example implementation. Operation 510 may include setting, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[00108] In an example implementation of the method of FIG. 5, the setting the state of the acknowledged mode reordering window may include setting, by the protocol entity, an acknowledged mode state variable VR(R) to an initial value based on the sequence number of the protocol data unit that is first received by the protocol entity before any other protocol data unit, the setting being performed if the acknowledged state variable VR (R) has not been set to any value, where VR(R) holds a value of a sequence number following a last in-sequence completely received acknowledged mode protocol data unit and defines a lower edge of the acknowledged mode reordering window.

[00109] In an example implementation of the method of FIG. 5, the setting may include setting the state of the acknowledged mode reordering window comprises setting, by the protocol entity, an acknowledged mode state variable VR(R) to an initial value based on the following, if the acknowledged state variable VR (R) has not been set to any value: VR(R) = x+1 , where x is the sequence number of the protocol data unit that is first received by the protocol entity.

[00110] In an example implementation of the method of FIG. 5, the protocol entity is provided at a user device that receives protocol data units from one or more other user devices within a proximity-based services (Pro-Se) wireless network or a device - to-device (D2D) wireless network.

[00111 ] In an example implementation of the method of FIG. 5, the method may further include setting, by a receiving acknowledged mode protocol entity, an initial value of an acknowledged mode state variable, VR(MS), which is a maximum status transmit state variable, the state variable being set to the initial value based on a sequence number of a protocol data unit that is first received by the RLC entity if the acknowledged mode state variable has not been set to any value. For example, the protocol entity may include a radio link control (RLC) protocol entity.

[00112] The flow chart of FIG. 5 may also include an operation 520. Operation 520 may include setting, by a protocol entity, a state of an acknowledged mode state variable, which identifies a sequence number following a sequence number of an acknowledged mode protocol data unit with a highest sequence number among received acknowledged mode protocol data units, to an initial value based on the sequence number of the protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received. Also, the acknowledged mode state variable may include the acknowledged mode state variable VR(H), and wherein the setting the

acknowledged mode state variable VR(H) comprises setting VR(H) to an initial value based on the following: VR(H) = x+1 , where x is the sequence number of the protocol data unit that is first received by the protocol entity.

[00113] According to another example implementation, an apparatus may include at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to: set, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[00114] According to another example implementation, a computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method including: setting, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

[00115] FIG. 6 is a block diagram of a wireless station (e.g., BS or user device) 600 according to an example implementation. The wireless station 600 may include, for example, two RF (radio frequency) or wireless transceivers 602A, 602B, where each wireless transceiver includes a transmitter to transmit signals and a receiver to receive signals. The wireless station also includes a processor or control unit/entity (controller) 604 to execute instructions or software and control transmission and receptions of signals, and a memory 606 to store data and/or instructions.

[00116] Processor 604 may also make decisions or determinations, generate frames, packets or messages for transmission, decode received frames or messages for further processing, and other tasks or functions described herein. Processor 604, which may be a baseband processor, for example, may generate messages, packets, frames or other signals for transmission via wireless transceiver 602 (602A or 602B). Processor 604 may control transmission of signals or messages over a wireless network, and may control the reception of signals or messages, etc., via a wireless network (e.g., after being down-converted by wireless transceiver 602, for example). Processor 604 may be programmable and capable of executing software or other instructions stored in memory or on other computer media to perform the various tasks and functions described above, such as one or more of the tasks or methods described above. Processor 604 may be (or may include), for example, hardware, programmable logic, a programmable processor that executes software or firmware, and/or any combination of these. Using other terminology, processor 604 and transceiver 602 together may be considered as a wireless transmitter/receiver system, for example.

[00117] In addition, referring to FIG. 6, a controller (or processor) 608 may execute software and instructions, and may provide overall control for the station 600, and may provide control for other systems not shown in FIG. 6, such as controlling input/output devices (e.g., display, keypad), and/or may execute software for one or more applications that may be provided on wireless station 600, such as, for example, an email program, audio/video applications, a word processor, a Voice over IP application, or other application or software.

[00118] In addition, a storage medium may be provided that includes stored instructions, which when executed by a controller or processor may result in the processor 604, or other controller or processor, performing one or more of the functions or tasks described above.

[00119] According to another example implementation, RF or wireless

transceiver(s) 602A/602B may receive signals or data and/or transmit or send signals or data. Processor 604 (and possibly transceivers 602A/602B) may control the RF or wireless transceiver 602A or 602B to receive, send, broadcast or transmit signals or data.

[00120] An example of an apparatus may include means (604, 602A, 602B) for sending and/or receiving data, and means (604, 602A, 602B) for controlling sending and/or for controlling receiving data.

[00121 ] Another example of an apparatus may include means for initiating (604, 244, 248), by a user device in a wireless network, a protocol entity (e.g., 242), means (604, 242) for determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value, and means (604, 242) for setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

[00122] Another example of an apparatus may include means (604, 242) for setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received, and means (604, 242) for setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received. Also, the apparatus may include means (604, 602A, 602B, 242) for receiving (or means for controlling receiving) RLC PDUs from a peer protocol entity (e.g., a peer RLC entity) of a transmitting user device based on one or more state variables and/or the state of the reordering window.

[00123] Another example of an apparatus may include means (604, 242) for setting, by a protocol entity, a state of an acknowledged mode reordering window of nonzero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received, and means (604, 242) for setting, by a protocol entity, a state of an acknowledged mode state variable, which identifies a sequence number following a sequence number of an acknowledged mode protocol data unit with a highest sequence number among received acknowledged mode protocol data units, to an initial value based on the sequence number of the protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received. [00124] Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. Implementations may implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. Implementations may also be provided on a computer readable medium or computer readable storage medium, which may be a non-transitory medium. Implementations of the various techniques may also include implementations provided via transitory signals or media, and/or programs and/or software

implementations that are downloadable via the Internet or other network(s), either wired networks and/or wireless networks. In addition, implementations may be provided via machine type communications (MTC), and also via an Internet of Things (IOT).

[00125] The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, readonly memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers.

[00126] Furthermore, implementations of the various techniques described herein may use a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the implementation and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers, ...) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals. The rise in popularity of smartphones has increased interest in the area of mobile cyber- physical systems. Therefore, various implementations of techniques described herein may be provided via one or more of these technologies.

[00127] A computer program, such as the computer program(s) described above, can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit or part of it suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[00128] Method steps may be performed by one or more programmable processors executing a computer program or computer program portions to perform functions by operating on input data and generating output. Method steps also may be performed by, and an apparatus may be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[00129] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer, chip or chipset. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data.

Generally, a computer also may include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[00130] To provide for interaction with a user, implementations may be

implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a user interface, such as a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[00131 ] Implementations may be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation, or any combination of such back-end, middleware, or front-end components. Components may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of

communication networks include a local area network (LAN) and a wide area network (WAN), e.g., the Internet.

[00132] While certain features of the described implementations have been illustrated as described herein, many modifications, substitutions, changes and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the various embodiments.

Claims

WHAT IS CLAIMED IS:

1 . A method comprising:

initiating, by a user device in a wireless network, a protocol entity;

determining that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value; and

setting, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

2. The method of claim 1 wherein the state variable comprises an

unacknowledged mode state variable;

wherein the determining comprises determining that an unacknowledged mode state variable that identifies an earliest unacknowledged mode protocol data unit that is still considered for reordering has not been set to any value;

wherein the setting comprises setting, by the protocol entity, the unacknowledged mode state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

3. The method of claim 2 wherein the unacknowledged mode state variable comprises a VR(UR) state variable for Long Term Evolution or Long Term Evolution Advanced standard.

4. The method of claim 1 wherein the initiating comprises initiating, by a user device in a wireless network, a radio link control protocol entity.

5. The method of claim 1 wherein the setting comprises setting, by the protocol entity, the state variable to an initial value equal to the following: VR(UR) = (x + 1 ) - UM Window Size, where VR(UR) is the state variable for unacknowledged mode, x is the sequence number of the protocol data unit that is first received by the protocol entity, and UM Window Size is a size of a reordering window of the protocol entity for receiving protocol data units.

6. The method of claim 1 wherein the protocol entity comprises a first protocol entity at a first user device that is configured to receive protocol data units from a second protocol entity at a second user device, the first device and the second device being part of a proximity-based services (Pro-Se) wireless network or a device-to-device (D2D) wireless network.

7. The method of claim 2 wherein the unacknowledged mode state variable comprises a first unacknowledged mode state variable, the method further comprising:

determining that a second unacknowledged mode state variable, which identifies a sequence number following a sequence number of an unacknowledged mode protocol data unit having a highest sequence number among received unacknowledged mode protocol data units, has not been set to any value; and setting, by the protocol entity, the second unacknowledged mode state variable to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

8. The method of claim 7 wherein the second unacknowledged mode state variable comprises a VR(UH) state variable for Long Term Evolution or Long Term Evolution Advanced standard.

9. The method of claim 7 wherein the setting the second unacknowledged mode state variable comprises setting, by the protocol entity, the second

unacknowledged mode state variable to an initial value equal to the following: VR(UH) = x+1 , where VR(UH) is the second unacknowledged mode state variable, and x is the sequence number of the protocol data unit that is first received by the protocol entity.

10. An apparatus comprising means for carrying out the method according to any one of claims 1 to 9.

1 1 . A computer program product for a computer, comprising software code portions for performing the steps of any of claims 1 to 9 when said product is run on the computer.

12. An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to:

initiate, by a user device in a wireless network, a protocol entity;

determine that a state variable that identifies an earliest protocol data unit that is still considered for reordering has not been set to any value; and

set, by the protocol entity, the state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

13. A computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising:

initiating, by a user device in a wireless network, a protocol entity;

14. A method comprising:

setting, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received; and

setting, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

15. The method of claim 14 wherein the setting a state variable comprises setting, by the protocol entity, a first unacknowledged mode state variable to an initial value based on a sequence number of a protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received; and

wherein the setting a state of a reordering window comprises setting, by the protocol entity, a second unacknowledged mode state variable that defines an upper edge of the reordering window to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity, regardless of the sequence number of the protocol data unit that is first received.

16. The method of claim 15 wherein the setting the second unacknowledged mode state variable comprises setting, by the protocol entity, the second unacknowledged mode state variable to an initial value equal to the following: VR(UH) = x+1 , where VR(UH) is the second unacknowledged mode state variable, and x is the sequence number of the protocol data unit that is first received by the protocol entity.

17. The method of claim 15 wherein the setting the first unacknowledged mode state variable comprises setting, by the protocol entity, the first unacknowledged mode state variable to an initial value equal to the following: VR(UR) = (x + 1 ) - UM Window Size, where VR(UR) is the second unacknowledged mode state variable, x is the sequence number of the protocol data unit that is first received by the protocol entity, and UM Window Size is a size of a reordering window of the protocol entity for receiving protocol data units.

18. The method of claim 14 wherein the protocol entity comprises a radio link control (RLC) protocol entity.

19. An apparatus comprising means for carrying out the method according to any one of claims 14 to 18.

20. A computer program product for a computer, comprising software code portions for performing the steps of any of claims 14 to 18 when said product is run on the computer.

21 . An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to:

set, by a protocol entity, a state of a reordering window of non-zero size if the state of the reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received; and

set, by the protocol entity, a state variable that identifies an earliest protocol data unit that is still considered for reordering to an initial value based on a sequence number of the protocol data unit that is first received by the protocol entity if the state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

22. A computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising:

23. A method comprising:

setting, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

24. The method of claim 23 wherein the setting the state of the acknowledged mode reordering window comprises setting, by the protocol entity, an

acknowledged mode state variable VR(R) to an initial value based on the sequence number of the protocol data unit that is first received by the protocol entity before any other protocol data unit, the setting being performed if the acknowledged state variable VR (R) has not been set to any value, where VR(R) holds a value of a sequence number following a last in-sequence completely received acknowledged mode protocol data unit and defines a lower edge of the acknowledged mode reordering window.

25. The method of claim 23 wherein the setting comprises setting the state of the acknowledged mode reordering window comprises setting, by the protocol entity, an acknowledged mode state variable VR(R) to an initial value based on the following, if the acknowledged state variable VR (R) has not been set to any value:

VR(R) = x+1 , where x is the sequence number of the protocol data unit that is first received by the protocol entity.

26. The method of claim 23 and further comprising setting, by a protocol entity, a state of an acknowledged mode state variable, which identifies a sequence number following a sequence number of an acknowledged mode protocol data unit with a highest sequence number among received acknowledged mode protocol data units, to an initial value based on the sequence number of the protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

27. The method of claim 26 wherein the acknowledged mode state variable comprises the acknowledged mode state variable VR(H), and wherein the setting the acknowledged mode state variable VR(H) comprises setting VR(H) to an initial value based on the following:

VR(H) = x+1 , where x is the sequence number of the protocol data unit that is first received by the protocol entity.

28. The method of claim 23 wherein the protocol entity is provided at a user device that receives protocol data units from one or more other user devices within a proximity-based services (Pro-Se) wireless network or a device -to- device (D2D) wireless network.

29. The method of claim 23 and further comprising setting, by a receiving acknowledged mode protocol entity, an initial value of an acknowledged mode state variable, VR(MS), which is a maximum status transmit state variable, the state variable being set to the initial value based on a sequence number of a protocol data unit that is first received by the receiving acknowledged mode protocol entity if the acknowledged mode state variable has not been set to any value, without any restriction on the sequence number of the protocol data unit that is first received.

30. The method of claim 23 wherein the protocol entity comprises a radio link control (RLC) protocol entity.

31 . An apparatus comprising means for carrying out the method according to any one of claims 23 to 30.

32. A computer program product for a computer, comprising software code portions for performing the steps of any of claims 23 to 30 when said product is run on the computer.

33. An apparatus comprising at least one processor and at least one memory including computer instructions, when executed by the at least one processor, cause the apparatus to:

set, by a protocol entity, a state of an acknowledged mode reordering window of non-zero size if the state of the acknowledged mode reordering window has not been set to any value, according to a sequence number of a protocol data unit that is first received by the protocol entity before any other protocol data unit, without any restriction on the sequence number of the protocol data unit that is first received.

34. A computer program product, the computer program product comprising a computer-readable storage medium and storing executable code that, when executed by at least one data processing apparatus, is configured to cause the at least one data processing apparatus to perform a method comprising: