EP2982069A1 - Delivery of protocol data units - Google Patents

Delivery of protocol data units

Info

Publication number
EP2982069A1
EP2982069A1 EP14715253.2A EP14715253A EP2982069A1 EP 2982069 A1 EP2982069 A1 EP 2982069A1 EP 14715253 A EP14715253 A EP 14715253A EP 2982069 A1 EP2982069 A1 EP 2982069A1
Authority
EP
European Patent Office
Prior art keywords
data unit
protocol
protocol data
data units
delivery
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP14715253.2A
Other languages
German (de)
French (fr)
Inventor
Henri Markus Koskinen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Solutions and Networks Oy
Original Assignee
Nokia Solutions and Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/856,951 external-priority patent/US20140301362A1/en
Application filed by Nokia Solutions and Networks Oy filed Critical Nokia Solutions and Networks Oy
Publication of EP2982069A1 publication Critical patent/EP2982069A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1835Buffer management
    • H04L1/1841Resequencing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1848Time-out mechanisms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/34Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/0205Traffic management, e.g. flow control or congestion control at the air interface

Definitions

  • Protocol data units or other suitable data or information units in various communication systems can be enhanced by appropriate methods and devices.
  • in-sequence delivery of protocol data units received in parallel from several lower- layer acknowledged-mode protocol entities may benefit from reordering timers and/or forwarding status reports.
  • in-sequence delivery of protocol data units (PDUs) received in parallel from several lower-layer acknowledged-mode protocol entities may benefit from a data PDU containing no service data unit (SDU) for expediting data delivery to higher layer at receiving protocol entity.
  • PDUs protocol data units
  • SDU no service data unit
  • PDCP Packet Data Convergence Protocol
  • RLC Radio Link Control
  • the listed 'Services expected from lower layers' include among others: acknowledged data transfer service, including indication of successful delivery of PDCP protocol data units and in-sequence delivery, except at re-establishment of lower layers.
  • Protocol stacks may be based on having independent RLC in each node for dual connectivity.
  • Figure 1 illustrates control/user (C/U)- plane protocol stacks. More specifically, Figure 1 illustrates multi-radio U-plane protocol stacks for offloading or inter-site carrier aggregation.
  • the work-split in in-sequence delivery between PDCP and RLC exhibits itself, for example, as follows in 3GPP TS 36.300 ⁇ 10.1 .2.3 and 10.1.2.3.1 , which is hereby incorporated herein by reference.
  • the source eNB may forward in order to the target eNB all downlink PDCP SDUs [service data units] with their SN that have not been acknowledged by the UE. ...
  • the UE receives a PDCP SDU from the target eNB, it can deliver it to higher layer together with all PDCP SDUs with lower SNs regardless of possible gaps.”
  • the PDCP at the UE may receive PDUs whose reception failed before the handover, but only if they were forwarded by the source eNB to the target eNB. In any case, the PDCP at the UE is allowed to assume that PDUs received after the handover arrive in increasing order of PDUs' sequence numbers.
  • stage-3 realization of this principle looks as follows in 3GPP TS 36.323 ⁇ 5.1 .2, 5.1 .2.1 , and 5.1 .2.1 .2: "... if the PDCP PDU received by PDCP is not due to the re- establishment of lower layers: deliver to upper layers in ascending order of the associated COUNT value: all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with the received PDCP SDU; all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU... .”
  • Another protocol-architecture option involves a distributed RLC protocol where, with reference to Figure 1 , the PDCP entity at the eNB interfaces a co-located master RLC entity: this master RLC may divide the RLC PDUs destined towards the UE into those meant for a direct radio-interface transmission via the co-located MAC/PHY layers, in the case of what is called dual-radio mode, and to those to be transmitted by a slave RLC entity operating at the LTE-Hi AP.
  • this option there is one-to-one mapping between PDCP bearers and RLC bearers with data flow in given direction.
  • each receiving unacknowledged-mode RLC entity implements the following: VR(UR) - UM receive state variable, VR(UX), UM t-Reordering state variable, VR(UH) - UM highest received state variable, and t-Reordering.
  • VR(UR) - UM receive state variable can hold the value of the SN of the earliest UMD PDU that is still considered for reordering.
  • VR(UX) - UM t-Reordering state variable can hold the value of the SN following the SN of the UMD PDU which triggered t-Reordering.
  • VR(UH) - UM highest received state variable can hold the value of the SN following the SN of the UMD PDU with the highest SN among received UMD PDUs, and it serves as the higher edge of the reordering window.
  • t-Reordering is a timer that is used by the receiving side of an AM RLC entity and receiving UM RLC entity in order to detect loss of RLC PDUs at lower layer.
  • 3GPP TS 36.322 ⁇ 5.1 .2.2.4 explains actions when t-Reordering expires. Specifically, 3GPP TS 36.322 explains that "When t-Reordering expires, the receiving UM
  • a packet data convergence protocol (PDCP) data PDU can be used to convey a PDCP SDU SN; and user plane data containing an uncompressed PDCP SDU; or user plane data containing a compressed PDCP SDU; or control plane data; and a MAC-I field for SRBs; or for RNs, a MAC-I field for DRB (if integrity protection is configured).
  • PDCP packet data convergence protocol
  • PDCP may not wait for PDUs missing among those received, except at radio link control (RLC) re-establishment.
  • RLC radio link control
  • a gap generated by PDCP discard at the eNB can be immediately seen in TCP/IP at the UE. Consequently, the UE may send a duplicate TCP ACK and the network side TCP may slow down.
  • a method includes observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer. The method also includes starting a timer upon the gap observation. The method further includes preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
  • the method includes detecting a forwarding-status report and immediately proceeding with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
  • a method includes determining which protocol data unit sequence numbers will not be forwarded to a user equipment. The method also includes explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
  • an apparatus includes at least one processor and at least one memory including computer program code.
  • the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to observe a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer.
  • the at least one memory and the computer program code are also configured to, with the at least one processor, cause the apparatus at least to start a timer upon the gap observation.
  • the at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to prevent the gap from blocking delivery of service data units to a higher layer, when the timer expires.
  • the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to detect a forwarding-status report and immediately proceed with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
  • an apparatus includes at least one processor and at least one memory including computer program code.
  • the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to determine which protocol data unit sequence numbers will not be forwarded to a user equipment.
  • the at least one memory and the computer program code are also configured to, with the at least one processor, cause the apparatus at least to explicitly identify the protocol data unit sequence numbers to the user equipment in a report.
  • an apparatus includes observing means for observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer.
  • the apparatus also includes starting means for starting a timer upon the gap observation.
  • the apparatus further includes preventing means for preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
  • the apparatus includes detecting means for detecting a forwarding- status report and delivery means for immediately proceeding with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
  • an apparatus includes determining means for determining which protocol data unit sequence numbers will not be forwarded to a user equipment.
  • the method also includes identifying means for explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
  • a method can include receiving a protocol data unit with a sequence number but without a service data unit having a non-zero size.
  • the method can also include preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
  • a method can include determining a service data unit that will not be delivered to a data-receiving entity.
  • the service data unit can be associated with a sequence number.
  • the method can also include sending a protocol data unit including the sequence number but excluding the service data unit.
  • an apparatus can include at least one processor and at least one memory including computer program code.
  • the at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive a protocol data unit with a sequence number but without a service data unit having a non-zero size.
  • the at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to prevent absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
  • an apparatus can include at least one processor and at least one memory including computer program code.
  • the at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to determine a service data unit that will not be delivered to a data- receiving entity.
  • the service data unit can be associated with a sequence number.
  • the at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to send a protocol data unit including the sequence number but excluding the service data unit.
  • an apparatus can include means for receiving a protocol data unit with a sequence number but without a service data unit having a nonzero size.
  • the apparatus can also include means for preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
  • an apparatus can include means for determining a service data unit that will not be delivered to a data-receiving entity.
  • the service data unit can be associated with a sequence number.
  • the apparatus can also include sending a protocol data unit including the sequence number but excluding the service data unit.
  • a non-transitory computer-readable medium is encoded with instructions that, when executed in hardware, perform a process.
  • the process is respectively the method of the first embodiment, the second embodiment, the seventh embodiment, and the eighth embodiment, in any of their variations.
  • a computer program comprising program instructions which, when loaded into the apparatus, cause a computer system to perform the method of the first embodiment, the second embodiment, the seventh embodiment, and the eighth embodiment, in any of their variations.
  • Figure 1 illustrates a protocol-architecture option involving independent RLC protocol bearers serving a single PDCP bearer.
  • Figure 2 illustrates a method according to certain embodiments.
  • Figure 3 illustrates timer usage according to certain embodiments.
  • Figure 4 illustrates forwarding-status report handling according to certain embodiments.
  • Figure 5 illustrates a system according to certain embodiments.
  • a sending TCP device on a network side of base station such as an evolved Node B (eNB)
  • eNB evolved Node B
  • One way may be to use Packet Data Convergence Protocol (PDCP) discard of data units at the base station.
  • PDCP Packet Data Convergence Protocol
  • the base station may seek to get a sending TCP device to slow down when the data rate of the sending TCP device exceeds that of a radio interface of the base station. For example, this discarding can be useful when the eNB's transmit buffer starts to build up.
  • PDCP Packet Data Convergence Protocol
  • the reordering protocol may not be able to distinguish packets discarded at the transmitting side from packets still being processed at lower layers.
  • the receiving PDCP at the UE may decide when to pass received data to a higher layer, even though an SDU with a certain sequence number has not been received.
  • a reordering timer may be used. This reordering timer may need to have a long expiry value.
  • the PDCP may by default prevent itself from delivering, to a higher layer, any data that follows PDUs not yet received. Whether the data follows or not may be established by sequence number.
  • Both options may benefit from an explicit indication from the sending PDCP entity to the receiving PDCP entity.
  • This indication can specify that an SDU associated with a given SN is not to be expected.
  • the PDCP bearer terminated at the user equipment and the eNB is carried over two independent RLC bearers, one over each of the two radio interfaces of the user equipment.
  • the bearer is an acknowledged-mode (AM) bearer.
  • eNB is one example of an access point.
  • the PDCP entity at the user equipment may be bound to receive PDCP protocol data units from multiple underlying RLC entities in a highly interlaced manner.
  • the assumption holds that no unreceived PDU with lower SN can be expected after the one received, become a rare exception, rather than the rule.
  • the only exception may be created by inter-eNB handover of the network-side PDCP entity, where the source eNB does not carry out forwarding of PDCP protocol data units not yet successfully delivered to the user equipment.
  • Certain embodiments provide apparatuses and methods for the PDCP entity at the user equipment to deduce when not to expect reception gaps to be filled.
  • certain embodiments utilize a timer, such as a reordering timer, as shown in Figure 3.
  • a timer such as a reordering timer
  • the timer and its handling, along with the related state variables needed, that are currently specified for RLC-UM can be repurposed for AM data transfer.
  • a timer such as a reordering timer, can be started at 320 whenever a gap in the received protocol data units is observed at 310, such as by observing a gap in a sequence of protocol data units.
  • the protocol data units may be received from a plurality of lower-layer protocol entities providing data transfer.
  • the protocol data units may be received in an alternating fashion.
  • Each of the lower-layer entities may provide acknowledged transfer of protocol data units.
  • a state variable like VR(UX) can be introduced in PDCP, whereas state variables like VR(UR) and VR(UH) may have simple relations to the currently existing PDCP state variables Last_Submitted_PDCP_RX_SN and Next_PDCP_RX_SN, respectively.
  • Preventing the block of delivery can be carried out by proceeding with the delivery of service data units to the higher layer without a delay caused by waiting for protocol data units.
  • Reception of the protocol data units from more than one lower-layer protocol entities can be at least substantially parallel in nature and the plurality of lower-layer protocol entities can be acknowledged-mode protocol entities.
  • the timer's expiry value can be configured by radio resource control (RRC) at 350, and can be set at 360 long enough so that the timer does not expire during normal delivery delay of protocol data units sent by the eNB to the user equipment via a small-cell node, for example, including all possible HARQ and ARQ retransmissions at MAC and RLC level therein, respectively. Because of this need to set the timer expiry to fairly long values, in the case of inter-eNB handover where the source does not forward PDCP Service data units and hence gaps will remain, the data delivery to higher layer by the user equipment will be considerably delayed.
  • RRC radio resource control
  • FIG. 4 illustrates forwarding-status report handling according to certain embodiments.
  • a forwarding-status report can be a new PDCP control PDU by which the network, for example the handover-target eNB, can explicitly tell the user equipment (after handover) at 410, which protocol data unit sequence numbers (PDU SNs) the user equipment should not expect to receive at all.
  • PDU SNs protocol data unit sequence numbers
  • the forwarding-status report can possibly also tell the user equipment (after handover), which protocol data unit sequence numbers the user equipment should expect to receive.
  • a control data unit such as a forwarding status report, can be sent identifying at least one protocol data unit that should not be expected to be received.
  • the method can include preventing the at least one identified protocol data unit from blocking delivery of service data units to a higher layer.
  • the user equipment can immediately proceed, at 450, with data delivery to a higher layer, containing gaps because of the lack of forwarding at handover. In cases where the handover-target eNB observes that no gap in SNs should occur in the PDCP protocol data units delivered to the user equipment, it can simply refrain from sending such a report. Thus, at 405, a determination regarding whether to send the report can be made.
  • the at least one identified protocol data unit is prevented from blocking delivery of service data units to a higher layer.
  • the timer can be used independently of the forwarding status report.
  • the timer may introduce additional, continuously running procedures for a protocol entity to execute. Those procedures may only change operation, for example when a gap among received protocol data units proves permanent, in a scenario in which a handover exists without forwarding.
  • Activation of the feature at 370, for example by radio resource control when a handover command is received, is one option. Conventionally, PDCP does not know if PDCP re-establishment is invoked because of handover.
  • deactivation of the feature can be performed by an indication from the peer PDCP entity at the handover-target eNB, that possible gaps no longer occur in protocol data units' SNs after an indicated SN. This indication may be considered one form of forwarding-status report.
  • Relying on a forwarding-status report alone may require that its reception by the user equipment be made certain, since losing such a report in transit may mean that the PDCP at the user equipment goes into deadlock waiting for reception gaps to be filled, which never will.
  • Possible options to ensure delivery may include features such as relying on an underlying acknowledged-mode delivery of RLC AM and/or requiring explicit acknowledgement of reception of the forwarding-status report at PDCP level, for which the sending node can await confirmation at 460.
  • a PDCP Control PDU may be defined for the purpose.
  • the forwarding-status report can be retransmitted at 470 if no acknowledgement is received within a predetermined amount of time.
  • Certain embodiments thus, provide apparatuses and methods for when a PDCP entity receiving protocol data units from multiple RLC-AM entities should and should not assume gap-less reception of protocol data units, and how to deliver Service data units to higher layer accordingly.
  • t-Reordering and a state variable like VR(UX) can be handled similar to what is shown in 3GPP TS 36.322 sections 5.1 .2.2.3, 5.1 .2.2.4, which are hereby incorporated herein by reference.
  • the user equipment shall update all related state variables and t-Reordering as further specified, and deliver other Service data units to higher layer, as if a PDCP Data PDU with that PDCP SN was received.
  • Figure 5 illustrates a system according to certain embodiments of the invention. It should be understood that each block of the flowchart of Figures 2, 3, or 4 and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry.
  • a system may comprise several devices, such as, for example, network element 510 and user equipment (UE) or user device 520.
  • the system may comprise more than one UE 520 and more than one network element 510, although only one of each is shown for the purposes of illustration.
  • a network element can be an access point, a base station, an eNode B (eNB), server, host or any of the other network elements discussed herein.
  • eNB eNode B
  • Each of these devices may comprise at least one processor or control unit or module, respectively indicated as 514 and 524.
  • At least one memory may be provided in each device, and indicated as 515 and 525, respectively.
  • the memory may comprise computer program instructions or computer code contained therein.
  • One or more transceiver 516 and 526 may be provided, and each device may also comprise an antenna, respectively illustrated as 517 and 527. Although only one antenna each is shown, many antennas and multiple antenna elements may be provided to each of the devices. Other configurations of these devices, for example, may be provided.
  • network element 510 and UE 520 may be additionally configured for wired communication, in addition to wireless communication, and in such a case antennas 517 and 527 may illustrate any form of communication hardware, without being limited to merely an antenna.
  • some network elements 510 may be solely configured for wired communication, and such cases antenna 517 may illustrate any form of wired communication hardware, such as a network interface card.
  • Transceivers 516 and 526 may each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception.
  • the transmitter and/or receiver (as far as radio parts are concerned) may also be implemented as a remote radio head which is not located in the device itself, but in a mast, for example.
  • the operations and functionalities may be performed in different entities, such as nodes, hosts or servers, in a flexible manner. In other words, "division of labour” may vary case by case.
  • One possible use is to make a network element to deliver local content.
  • a user device or user equipment may be a mobile station (MS) such as a mobile phone or smart phone or multimedia device, a computer, such as a tablet, provided with wireless communication capabilities, personal data or digital assistant (PDA) provided with wireless communication capabilities, portable media player, digital camera, pocket video camera, navigation unit provided with wireless communication capabilities or any combinations thereof.
  • MS mobile station
  • PDA personal data or digital assistant
  • an apparatus such as a node or user device, may comprise means for carrying out embodiments described above in relation to Figures 2, 3, or 4.
  • an apparatus such as a user device, may comprise means (524) for observing a gap in received protocol data units, starting a timer upon the gap observation and preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
  • Another exemplary apparatus such as a node, may comprise means (514) for determining which protocol data unit sequence numbers will not be forwarded to user equipment; and explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
  • Processors 514 and 524 may be embodied by any computational or data processing device, such as a central processing unit (CPU), digital signal processor (DSP), application specific integrated circuit (ASIC), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), digitally enhanced circuits, or comparable device or a combination thereof.
  • the processors may be implemented as a single controller, or a plurality of controllers or processors.
  • the implementation may comprise modules or unit of at least one chip set (e.g., procedures, functions, and so on).
  • Memories 515 and 525 may independently be any suitable storage device, such as a non-transitory computer-readable medium.
  • a hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used.
  • the memories may be combined on a single integrated circuit as the processor, or may be separate therefrom.
  • the computer program instructions may be stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language.
  • the memory or data storage entity is typically internal but may also be external or a combination thereof, such as in the case when additional memory capacity is obtained from a service provider.
  • the memory may be fixed or removable.
  • the memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus such as network element 510 and/or UE 520, to perform any of the processes described above (see, for example, Figures 2, 3, and 4). Therefore, in certain embodiments, a non-transitory computer-readable medium may be encoded with computer instructions or one or more computer program (such as added or updated software routine, applet or macro) that, when executed in hardware, may perform a process such as one of the processes described herein.
  • a non-transitory computer-readable medium may be encoded with computer instructions or one or more computer program (such as added or updated software routine, applet or macro) that, when executed in hardware, may perform a process such as one of the processes described herein.
  • Computer programs may be coded by a programming language, which may be a high-level programming language, such as objective-C, C, C++, C#, Java, etc., or a low-level programming language, such as a machine language, or assembler. Alternatively, certain embodiments of the invention may be performed entirely in hardware.
  • a programming language which may be a high-level programming language, such as objective-C, C, C++, C#, Java, etc.
  • a low-level programming language such as a machine language, or assembler.
  • certain embodiments of the invention may be performed entirely in hardware.
  • Figure 5 illustrates a system including a network element 510 and a UE 520
  • embodiments of the invention may be applicable to other configurations, and configurations involving additional elements, as illustrated and discussed herein.
  • multiple user equipment devices and multiple network elements may be present, or other nodes providing similar functionality, such as nodes that combine the functionality of a user equipment and an access point, such as a relay node.
  • Certain embodiments provide a particular case of PDCP Data PDU to be used over a standardized LTE air interface.
  • Figure 2 illustrates a method according to certain embodiments.
  • the data-transmitting PDCP entity can determine that an SDU associated with given PDCP sequence number will not be delivered to the peer protocol entity. This determination can be a decision made by the PDCP entity, for example, because of intentional discarding among already-numbered PDUs.
  • the data-transmitting PDCP entity determines that an SDU associated with given PDCP sequence number will not be delivered to the peer protocol entity
  • the data-transmitting PDCP entity can send a PDCP data PDU, with that SN but without any SDU, to the peer entity.
  • the SDU may be included but may have a zero size.
  • the portion of the method at 210 and 220 can be performed by the data-transmitting PDCP entity, whereas the remainder of the method can be performed by a receiving peer entity.
  • the receiving peer entity can receive the PDU.
  • the receiving peer entity can treat the PDU as though it included an SDU with zero length associated with that SN. This can be one example of how the receiving entity can, at 240, prevent the absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer. Therefore, the receiving peer entity can avoid waiting any longer for receiving that SN before, at 250, delivering other SDUs to a higher layer.
  • Certain embodiments may have various benefits and/or advantages. For example, in certain embodiments no additional PDCP PDU format needs to be introduced.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)

Abstract

Delivery of protocol data units or other suitable data or information units in various communication systems can be enhanced by appropriate methods and devices. For example, in-sequence delivery of protocol data units received in parallel from several lower- layer acknowledged-mode protocol entities may benefit from timers and/or forwarding status reports. A method can include observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer. The method can also include starting a timer upon the gap observation. The method can further include preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires. The method can additionally include detecting a forwarding-status report. The method can also include immediately proceeding with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.

Description

DESCRIPTION TITLE:
Delivery of Protocol Data Units
CROSS REFERENCE TO RELATED APPLICATION
[0001 ] This application claims the benefit and priority of U.S. Patent Application No. 14/067,509, filed October 30, 2013, which was a continuation-in-part of U.S. Patent Application No. 13/856,951 filed April 4, 2013, the benefit and priority of which is also claimed. Both of these previous applications are hereby incorporated herein by reference in their entireties.
BACKGROUND:
Field :
[0002] Delivery of protocol data units or other suitable data or information units in various communication systems can be enhanced by appropriate methods and devices. For example, in-sequence delivery of protocol data units received in parallel from several lower- layer acknowledged-mode protocol entities may benefit from reordering timers and/or forwarding status reports. Moreover, in-sequence delivery of protocol data units (PDUs) received in parallel from several lower-layer acknowledged-mode protocol entities may benefit from a data PDU containing no service data unit (SDU) for expediting data delivery to higher layer at receiving protocol entity.
Description of the Related Art:
[0003] In the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) air-interface protocol stack, the Packet Data Convergence Protocol (PDCP) currently lies above the Radio Link Control (RLC) protocol. PDCP is currently defined by third generation partnership project (3GPP) technical specification (TS) 36.323, which is hereby incorporated herein by reference. RLC is defined by 3GPP TS 36.322, which is hereby incorporated herein by reference.
[0004] For PDCP, the listed 'Services expected from lower layers' include among others: acknowledged data transfer service, including indication of successful delivery of PDCP protocol data units and in-sequence delivery, except at re-establishment of lower layers.
[0005] Correspondingly, the following PDCP 'Function' is listed: in-sequence delivery of upper layer PDUs at re-establishment of lower layers.
[0006] In studies of dual connectivity in E-UTRAN, protocol stacks may be based on having independent RLC in each node for dual connectivity. Figure 1 illustrates control/user (C/U)- plane protocol stacks. More specifically, Figure 1 illustrates multi-radio U-plane protocol stacks for offloading or inter-site carrier aggregation.
[0007] On stage-2 level, the work-split in in-sequence delivery between PDCP and RLC exhibits itself, for example, as follows in 3GPP TS 36.300 §§10.1 .2.3 and 10.1.2.3.1 , which is hereby incorporated herein by reference. "Upon handover, the source eNB may forward in order to the target eNB all downlink PDCP SDUs [service data units] with their SN that have not been acknowledged by the UE. ... After a normal handover, when the UE receives a PDCP SDU from the target eNB, it can deliver it to higher layer together with all PDCP SDUs with lower SNs regardless of possible gaps."
[0008] The possible gaps mentioned above may occur because, after handover, the PDCP at the UE may receive PDUs whose reception failed before the handover, but only if they were forwarded by the source eNB to the target eNB. In any case, the PDCP at the UE is allowed to assume that PDUs received after the handover arrive in increasing order of PDUs' sequence numbers.
[0009] The stage-3 realization of this principle looks as follows in 3GPP TS 36.323 §§5.1 .2, 5.1 .2.1 , and 5.1 .2.1 .2: "... if the PDCP PDU received by PDCP is not due to the re- establishment of lower layers: deliver to upper layers in ascending order of the associated COUNT value: all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with the received PDCP SDU; all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU... ."
[0010] Thus, unless the PDU was flushed by RLC re-establishment, performed at handover to deliver all received RLC SDUs ciphered with the source eNB's key, the system assumes that no PDU with lower SN will follow after the one received, and deliver SDUs to higher layer accordingly.
[0011] Continuing from the same 3GPP TS: "...set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers; else if received PDCP SN =
Last_Submitted_PDCP_RX_SN + 1 or received PDCP SN Last_Submitted_PDCP_RX_SN - Maximum_PDCP_SN: deliver to upper layers in ascending order of the associated COUNT value: all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU; set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers." [0012] Thus, if the PDU was flushed by RLC re-establishment, the system refrains from any SDU delivery to higher layer that would leave a hole in the SN sequence of delivered SDUs.
[0013] Accordingly, in the conventional procedure above, there are two branches, the first of which assumes that no unreceived PDU with lower SN can be expected after the one received: the only exception to this assumption - the second branch - is when PDUs are received due to RLC re-establishment.
[0014] Another protocol-architecture option involves a distributed RLC protocol where, with reference to Figure 1 , the PDCP entity at the eNB interfaces a co-located master RLC entity: this master RLC may divide the RLC PDUs destined towards the UE into those meant for a direct radio-interface transmission via the co-located MAC/PHY layers, in the case of what is called dual-radio mode, and to those to be transmitted by a slave RLC entity operating at the LTE-Hi AP. As in the previously discussed model, in this option there is one-to-one mapping between PDCP bearers and RLC bearers with data flow in given direction.
[0015] According to 3GPP TS 36.322, each receiving unacknowledged-mode RLC entity implements the following: VR(UR) - UM receive state variable, VR(UX), UM t-Reordering state variable, VR(UH) - UM highest received state variable, and t-Reordering. VR(UR) - UM receive state variable can hold the value of the SN of the earliest UMD PDU that is still considered for reordering. VR(UX) - UM t-Reordering state variable can hold the value of the SN following the SN of the UMD PDU which triggered t-Reordering. VR(UH) - UM highest received state variable can hold the value of the SN following the SN of the UMD PDU with the highest SN among received UMD PDUs, and it serves as the higher edge of the reordering window. t-Reordering is a timer that is used by the receiving side of an AM RLC entity and receiving UM RLC entity in order to detect loss of RLC PDUs at lower layer.
[0016] 3GPP TS 36.322, §5.1 .2.2.4 explains actions when t-Reordering expires. Specifically, 3GPP TS 36.322 explains that "When t-Reordering expires, the receiving UM
RLC entity shall: update VR(UR) to the SN of the first UMD PDU with SN >= VR(UX) that has not been received; reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in ascending order of the RLC SN if not delivered before; if VR(UH) > VR(UR): start t- Reordering; set VR(UX) to VR(UH)."
[0017] Conventionally, a packet data convergence protocol (PDCP) data PDU can be used to convey a PDCP SDU SN; and user plane data containing an uncompressed PDCP SDU; or user plane data containing a compressed PDCP SDU; or control plane data; and a MAC-I field for SRBs; or for RNs, a MAC-I field for DRB (if integrity protection is configured).
[0018] Conventionally, PDCP may not wait for PDUs missing among those received, except at radio link control (RLC) re-establishment. Thus, a gap generated by PDCP discard at the eNB can be immediately seen in TCP/IP at the UE. Consequently, the UE may send a duplicate TCP ACK and the network side TCP may slow down.
[0019] Higher layer small cell layer enhancements are described, for example, in 3GPP technical report (TR) 36.842 v.0.3.0, which is hereby incorporated herein by reference in its entirety. For example, option 3C in the technical report describes a U-plane protocol architecture that may be used.
SUMMARY:
[0020] According to a first embodiment, a method includes observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer. The method also includes starting a timer upon the gap observation. The method further includes preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
[0021] In a variation, the method includes detecting a forwarding-status report and immediately proceeding with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
[0022] According to a second embodiment, a method includes determining which protocol data unit sequence numbers will not be forwarded to a user equipment. The method also includes explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
[0023] According to a third embodiment, an apparatus includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to observe a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer. The at least one memory and the computer program code are also configured to, with the at least one processor, cause the apparatus at least to start a timer upon the gap observation. The at least one memory and the computer program code are further configured to, with the at least one processor, cause the apparatus at least to prevent the gap from blocking delivery of service data units to a higher layer, when the timer expires.
[0024] In a variation, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to detect a forwarding-status report and immediately proceed with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
[0025] According to a fourth embodiment, an apparatus includes at least one processor and at least one memory including computer program code. The at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to determine which protocol data unit sequence numbers will not be forwarded to a user equipment. The at least one memory and the computer program code are also configured to, with the at least one processor, cause the apparatus at least to explicitly identify the protocol data unit sequence numbers to the user equipment in a report.
[0026] According to a fifth embodiment, an apparatus includes observing means for observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer. The apparatus also includes starting means for starting a timer upon the gap observation. The apparatus further includes preventing means for preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
[0027] In a variation, the apparatus includes detecting means for detecting a forwarding- status report and delivery means for immediately proceeding with data delivery to higher layer, containing the gaps because of the lack of forwarding at handover.
[0028] According to a sixth embodiment, an apparatus includes determining means for determining which protocol data unit sequence numbers will not be forwarded to a user equipment. The method also includes identifying means for explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
[0029] According to a seventh embodiment, a method can include receiving a protocol data unit with a sequence number but without a service data unit having a non-zero size. The method can also include preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
[0030] According to an eighth embodiment, a method can include determining a service data unit that will not be delivered to a data-receiving entity. The service data unit can be associated with a sequence number. The method can also include sending a protocol data unit including the sequence number but excluding the service data unit.
[0031] According to a ninth embodiment, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to receive a protocol data unit with a sequence number but without a service data unit having a non-zero size. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to prevent absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer. [0032] According to a tenth embodiment, an apparatus can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to determine a service data unit that will not be delivered to a data- receiving entity. The service data unit can be associated with a sequence number. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the apparatus at least to send a protocol data unit including the sequence number but excluding the service data unit.
[0033] According to an eleventh embodiment, an apparatus can include means for receiving a protocol data unit with a sequence number but without a service data unit having a nonzero size. The apparatus can also include means for preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
[0034] According to a twelfth embodiment, an apparatus can include means for determining a service data unit that will not be delivered to a data-receiving entity. The service data unit can be associated with a sequence number. The apparatus can also include sending a protocol data unit including the sequence number but excluding the service data unit.
[0035] According to thirteenth through sixteenth embodiments, respectively, a non-transitory computer-readable medium is encoded with instructions that, when executed in hardware, perform a process. The process is respectively the method of the first embodiment, the second embodiment, the seventh embodiment, and the eighth embodiment, in any of their variations.
[0036] According to seventeenth through twentieth embodiments, respectively, a computer program comprising program instructions which, when loaded into the apparatus, cause a computer system to perform the method of the first embodiment, the second embodiment, the seventh embodiment, and the eighth embodiment, in any of their variations.
BRIEF DESCRIPTION OF THE DRAWINGS:
[0037] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:
[0038] Figure 1 illustrates a protocol-architecture option involving independent RLC protocol bearers serving a single PDCP bearer.
[0039] Figure 2 illustrates a method according to certain embodiments.
[0040] Figure 3 illustrates timer usage according to certain embodiments.
[0041] Figure 4 illustrates forwarding-status report handling according to certain embodiments.
[0042] Figure 5 illustrates a system according to certain embodiments.
DETAILED DESCRIPTION: [0043] There may be various ways to get a sending TCP device on a network side of base station, such as an evolved Node B (eNB), to slow down. One way may be to use Packet Data Convergence Protocol (PDCP) discard of data units at the base station. The base station may seek to get a sending TCP device to slow down when the data rate of the sending TCP device exceeds that of a radio interface of the base station. For example, this discarding can be useful when the eNB's transmit buffer starts to build up.
[0044] If the layer responsible for reordering is the same layer or higher than where such packet discarding takes place, then the reordering protocol may not be able to distinguish packets discarded at the transmitting side from packets still being processed at lower layers. There may, for example, be multiple alternative delivery branches, such as macro eNB (MeNB) and small cell eNB (SeNB), both possibly being scheduled intermittently.
[0045] There may be various options for the receiving PDCP at the UE to decide when to pass received data to a higher layer, even though an SDU with a certain sequence number has not been received. For example, a reordering timer may be used. This reordering timer may need to have a long expiry value. Alternatively, the PDCP may by default prevent itself from delivering, to a higher layer, any data that follows PDUs not yet received. Whether the data follows or not may be established by sequence number.
[0046] Both options may benefit from an explicit indication from the sending PDCP entity to the receiving PDCP entity. This indication can specify that an SDU associated with a given SN is not to be expected. This and other features are explained in the following discussion.
[0047] In certain embodiments, unlike in E-UTRAN's current bearer model, the PDCP bearer terminated at the user equipment and the eNB is carried over two independent RLC bearers, one over each of the two radio interfaces of the user equipment. Thus, in certain embodiments, the bearer is an acknowledged-mode (AM) bearer. In this discussion, eNB is one example of an access point.
[0048] When considering the renewed bearer model shown in Figure 1 , where a plurality of independent RLC-AM bearers may be harnessed to convey data of a PDCP bearer, the PDCP entity at the user equipment may be bound to receive PDCP protocol data units from multiple underlying RLC entities in a highly interlaced manner. In other words, conditions where the assumption holds, that no unreceived PDU with lower SN can be expected after the one received, become a rare exception, rather than the rule. The only exception may be created by inter-eNB handover of the network-side PDCP entity, where the source eNB does not carry out forwarding of PDCP protocol data units not yet successfully delivered to the user equipment. But this exception may need to be handled properly: if the PDCP at the user equipment always waits for reception gaps to be filled before delivery of data to higher layer, then at a handover without forwarding the bearer may go into deadlock, because the gaps created by packets that were not forwarded will never be received.
[0049] Certain embodiments provide apparatuses and methods for the PDCP entity at the user equipment to deduce when not to expect reception gaps to be filled.
[0050] For example, certain embodiments utilize a timer, such as a reordering timer, as shown in Figure 3. In order for the PDCP entity, receiving protocol data units from a plurality of RLC-AM entities running below, to conclude when a gap in received protocol data units can no longer be expected to be filled, the timer and its handling, along with the related state variables needed, that are currently specified for RLC-UM can be repurposed for AM data transfer.
[0051] As shown in Figure 3, a timer, such as a reordering timer, can be started at 320 whenever a gap in the received protocol data units is observed at 310, such as by observing a gap in a sequence of protocol data units. The protocol data units may be received from a plurality of lower-layer protocol entities providing data transfer. The protocol data units may be received in an alternating fashion. Each of the lower-layer entities may provide acknowledged transfer of protocol data units. Once the timer expires at 330, that gap is no longer allowed to block delivery of service data units to higher layer, at 340. A state variable like VR(UX) can be introduced in PDCP, whereas state variables like VR(UR) and VR(UH) may have simple relations to the currently existing PDCP state variables Last_Submitted_PDCP_RX_SN and Next_PDCP_RX_SN, respectively.
Preventing the block of delivery can be carried out by proceeding with the delivery of service data units to the higher layer without a delay caused by waiting for protocol data units. Reception of the protocol data units from more than one lower-layer protocol entities can be at least substantially parallel in nature and the plurality of lower-layer protocol entities can be acknowledged-mode protocol entities.
[0052] The timer's expiry value can be configured by radio resource control (RRC) at 350, and can be set at 360 long enough so that the timer does not expire during normal delivery delay of protocol data units sent by the eNB to the user equipment via a small-cell node, for example, including all possible HARQ and ARQ retransmissions at MAC and RLC level therein, respectively. Because of this need to set the timer expiry to fairly long values, in the case of inter-eNB handover where the source does not forward PDCP Service data units and hence gaps will remain, the data delivery to higher layer by the user equipment will be considerably delayed.
[0053] Moreover, certain embodiments utilize a forwarding-status report to shorten the delay described above. Figure 4 illustrates forwarding-status report handling according to certain embodiments. A forwarding-status report can be a new PDCP control PDU by which the network, for example the handover-target eNB, can explicitly tell the user equipment (after handover) at 410, which protocol data unit sequence numbers (PDU SNs) the user equipment should not expect to receive at all. Optionally, at 420 the forwarding-status report can possibly also tell the user equipment (after handover), which protocol data unit sequence numbers the user equipment should expect to receive. Thus, at 410, a control data unit, such as a forwarding status report, can be sent identifying at least one protocol data unit that should not be expected to be received.
[0054] The information received, at 430, in such a report by the user equipment can then override any prevailing uncertainty regarding the concerned unreceived protocol data units because of which timer may already be running as the user equipment can determine at 440 whether additional protocol data unit sequence numbers are expected. At 435, the method can include preventing the at least one identified protocol data unit from blocking delivery of service data units to a higher layer. The user equipment can immediately proceed, at 450, with data delivery to a higher layer, containing gaps because of the lack of forwarding at handover. In cases where the handover-target eNB observes that no gap in SNs should occur in the PDCP protocol data units delivered to the user equipment, it can simply refrain from sending such a report. Thus, at 405, a determination regarding whether to send the report can be made. At 435, the at least one identified protocol data unit is prevented from blocking delivery of service data units to a higher layer.
[0055] In principle, the timer can be used independently of the forwarding status report.
The timer may introduce additional, continuously running procedures for a protocol entity to execute. Those procedures may only change operation, for example when a gap among received protocol data units proves permanent, in a scenario in which a handover exists without forwarding. Activation of the feature, at 370, for example by radio resource control when a handover command is received, is one option. Conventionally, PDCP does not know if PDCP re-establishment is invoked because of handover. Moreover, at 380, deactivation of the feature can be performed by an indication from the peer PDCP entity at the handover-target eNB, that possible gaps no longer occur in protocol data units' SNs after an indicated SN. This indication may be considered one form of forwarding-status report. The possibility of having the feature either active or inactive may require separate branches in procedure descriptions. [0056] Relying on a forwarding-status report alone may require that its reception by the user equipment be made certain, since losing such a report in transit may mean that the PDCP at the user equipment goes into deadlock waiting for reception gaps to be filled, which never will. Possible options to ensure delivery may include features such as relying on an underlying acknowledged-mode delivery of RLC AM and/or requiring explicit acknowledgement of reception of the forwarding-status report at PDCP level, for which the sending node can await confirmation at 460. A PDCP Control PDU may be defined for the purpose. Moreover, the forwarding-status report can be retransmitted at 470 if no acknowledgement is received within a predetermined amount of time.
[0057] Certain embodiments, thus, provide apparatuses and methods for when a PDCP entity receiving protocol data units from multiple RLC-AM entities should and should not assume gap-less reception of protocol data units, and how to deliver Service data units to higher layer accordingly.
[0058] In the certain embodiments in which both a timer and a forwarding-status report are included, the following features may be part of a PDCP procedure. For example, it may be specified that if reception of PDCP Data protocol data units from only one DRB mapped on RLC AM has been configured and the PDCP PDU received by PDCP is not due to the re-establishment of lower layers: deliver to upper layers in ascending order of the associated COUNT value: all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with the received PDCP SDU; all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU; set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers; else if received PDCP SN = Last_Submitted_PDCP_RX_SN + 1 or received PDCP SN Last_Submitted_PDCP_RX_SN - Maximum_PDCP_SN: deliver to upper layers in ascending order of the associated COUNT value: all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value associated with the received PDCP SDU; set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers. It should be understood that this is just one example embodiment.
[0059] In addition, t-Reordering and a state variable like VR(UX) can be handled similar to what is shown in 3GPP TS 36.322 sections 5.1 .2.2.3, 5.1 .2.2.4, which are hereby incorporated herein by reference.
[0060] Furthermore, it can be specified that, regarding the reception of PDCP forwarding- status report, when a PDCP forwarding-status report is received in the downlink, for radio bearers that are mapped on RLC AM: for each PDCP SN [or COUNT value] indicated in the report as not to be expected for reception, the user equipment shall update all related state variables and t-Reordering as further specified, and deliver other Service data units to higher layer, as if a PDCP Data PDU with that PDCP SN was received.
[0061] Figure 5 illustrates a system according to certain embodiments of the invention. It should be understood that each block of the flowchart of Figures 2, 3, or 4 and any combination thereof may be implemented by various means or their combinations, such as hardware, software, firmware, one or more processors and/or circuitry. In one embodiment, a system may comprise several devices, such as, for example, network element 510 and user equipment (UE) or user device 520. The system may comprise more than one UE 520 and more than one network element 510, although only one of each is shown for the purposes of illustration. A network element can be an access point, a base station, an eNode B (eNB), server, host or any of the other network elements discussed herein. Each of these devices may comprise at least one processor or control unit or module, respectively indicated as 514 and 524. At least one memory may be provided in each device, and indicated as 515 and 525, respectively. The memory may comprise computer program instructions or computer code contained therein. One or more transceiver 516 and 526 may be provided, and each device may also comprise an antenna, respectively illustrated as 517 and 527. Although only one antenna each is shown, many antennas and multiple antenna elements may be provided to each of the devices. Other configurations of these devices, for example, may be provided. For example, network element 510 and UE 520 may be additionally configured for wired communication, in addition to wireless communication, and in such a case antennas 517 and 527 may illustrate any form of communication hardware, without being limited to merely an antenna. Likewise, some network elements 510 may be solely configured for wired communication, and such cases antenna 517 may illustrate any form of wired communication hardware, such as a network interface card.
[0062] Transceivers 516 and 526 may each, independently, be a transmitter, a receiver, or both a transmitter and a receiver, or a unit or device that may be configured both for transmission and reception. The transmitter and/or receiver (as far as radio parts are concerned) may also be implemented as a remote radio head which is not located in the device itself, but in a mast, for example. It should also be appreciated that according to the "liquid" or flexible radio concept, the operations and functionalities may be performed in different entities, such as nodes, hosts or servers, in a flexible manner. In other words, "division of labour" may vary case by case. One possible use is to make a network element to deliver local content. One or more functionalities may also be implemented as a virtual application that is as software that can run on a server. [0063] A user device or user equipment may be a mobile station (MS) such as a mobile phone or smart phone or multimedia device, a computer, such as a tablet, provided with wireless communication capabilities, personal data or digital assistant (PDA) provided with wireless communication capabilities, portable media player, digital camera, pocket video camera, navigation unit provided with wireless communication capabilities or any combinations thereof.
[0064] In an exemplary embodiment, an apparatus, such as a node or user device, may comprise means for carrying out embodiments described above in relation to Figures 2, 3, or 4. In an exemplary embodiment, an apparatus, such as a user device, may comprise means (524) for observing a gap in received protocol data units, starting a timer upon the gap observation and preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires. Another exemplary apparatus, such as a node, may comprise means (514) for determining which protocol data unit sequence numbers will not be forwarded to user equipment; and explicitly identifying the protocol data unit sequence numbers to the user equipment in a report.
[0065] Processors 514 and 524 may be embodied by any computational or data processing device, such as a central processing unit (CPU), digital signal processor (DSP), application specific integrated circuit (ASIC), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), digitally enhanced circuits, or comparable device or a combination thereof. The processors may be implemented as a single controller, or a plurality of controllers or processors.
[0066] For firmware or software, the implementation may comprise modules or unit of at least one chip set (e.g., procedures, functions, and so on). Memories 515 and 525 may independently be any suitable storage device, such as a non-transitory computer-readable medium. A hard disk drive (HDD), random access memory (RAM), flash memory, or other suitable memory may be used. The memories may be combined on a single integrated circuit as the processor, or may be separate therefrom. Furthermore, the computer program instructions may be stored in the memory and which may be processed by the processors can be any suitable form of computer program code, for example, a compiled or interpreted computer program written in any suitable programming language. The memory or data storage entity is typically internal but may also be external or a combination thereof, such as in the case when additional memory capacity is obtained from a service provider. The memory may be fixed or removable.
[0067] The memory and the computer program instructions may be configured, with the processor for the particular device, to cause a hardware apparatus such as network element 510 and/or UE 520, to perform any of the processes described above (see, for example, Figures 2, 3, and 4). Therefore, in certain embodiments, a non-transitory computer-readable medium may be encoded with computer instructions or one or more computer program (such as added or updated software routine, applet or macro) that, when executed in hardware, may perform a process such as one of the processes described herein. Computer programs may be coded by a programming language, which may be a high-level programming language, such as objective-C, C, C++, C#, Java, etc., or a low-level programming language, such as a machine language, or assembler. Alternatively, certain embodiments of the invention may be performed entirely in hardware.
[0068] Furthermore, although Figure 5 illustrates a system including a network element 510 and a UE 520, embodiments of the invention may be applicable to other configurations, and configurations involving additional elements, as illustrated and discussed herein. For example, multiple user equipment devices and multiple network elements may be present, or other nodes providing similar functionality, such as nodes that combine the functionality of a user equipment and an access point, such as a relay node.
[0069] Certain embodiments provide a particular case of PDCP Data PDU to be used over a standardized LTE air interface.
[0070] Figure 2 illustrates a method according to certain embodiments. As shown in Figure 2, at 210, the data-transmitting PDCP entity can determine that an SDU associated with given PDCP sequence number will not be delivered to the peer protocol entity. This determination can be a decision made by the PDCP entity, for example, because of intentional discarding among already-numbered PDUs.
[0071] When the data-transmitting PDCP entity determines that an SDU associated with given PDCP sequence number will not be delivered to the peer protocol entity, at 220 the data-transmitting PDCP entity can send a PDCP data PDU, with that SN but without any SDU, to the peer entity. Alternatively, the SDU may be included but may have a zero size. The portion of the method at 210 and 220 can be performed by the data-transmitting PDCP entity, whereas the remainder of the method can be performed by a receiving peer entity.
[0072] At 230, the receiving peer entity can receive the PDU. When receiving such a PDU, the receiving peer entity can treat the PDU as though it included an SDU with zero length associated with that SN. This can be one example of how the receiving entity can, at 240, prevent the absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer. Therefore, the receiving peer entity can avoid waiting any longer for receiving that SN before, at 250, delivering other SDUs to a higher layer.
[0073] Certain embodiments may have various benefits and/or advantages. For example, in certain embodiments no additional PDCP PDU format needs to be introduced.
[0074] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. For example, while a protocol data unit is used an example, certain embodiments are applicable not only to a protocol data unit but to any other suitable data or information unit. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.
[0075] Glossary
[0076] ACK Positive acknowledgement
[0077] AM Acknowledged Mode
[0078] NACK Negative acknowledgement
[0079] RLC Radio Link Control
[0080] PDCP Packet Data Convergence Protocol
[0081] PDU Protocol Data Unit
[0082] SDU Service Data Unit
[0083] SN Sequence Number
[0084] UM Unacknowledged Mode

Claims

WE CLAIM:
1 . A method, comprising: observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer; starting a timer upon the gap observation; and preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
2. The method of claim 1 , further comprising: configuring the timer's expiry value by radio resource control.
3. The method of claim 1 , wherein the preventing is carried out by proceeding with the delivery of service data units to the higher layer without a delay caused by waiting for protocol data units.
4. The method of claim 1 , wherein reception of the protocol data units from more than one lower-layer protocol entities is at least substantially parallel in nature and the plurality of lower-layer protocol entities are acknowledged-mode protocol entities.
5. The method of claim 1 , wherein the starting the timer is further contingent upon determining whether use of the timer is activated or deactivated.
6. A method, comprising: receiving a control data unit, the control data unit identifying at least one protocol data unit that should not be expected to be received; and preventing the at least one identified protocol data unit from blocking delivery of service data units to a higher layer.
7. The method of claim 6, wherein the identifying the at least one protocol data unit is carried out by using sequence numbers.
8. The method of claim 6, wherein the preventing is carried out by proceeding with the delivery of service data units to a higher layer without a delay caused by waiting for protocol data units.
9. The method of claim 6, wherein the control data unit identifies at least one protocol data unit that should be expected to be received.
10. A method, comprising: determining at least one protocol data unit that will not be delivered to a data- receiving entity; and sending a control data unit, identifying the at least one protocol data unit.
1 1 . The method of claim 10, wherein the identifying the at least one protocol data unit is carried out by using sequence numbers.
12. The method of claim 10, wherein the control data unit identifies one or more protocol data units that should be expected to be received.
13. The method of claim 10, further comprising: awaiting confirmation of reception of the control data unit; and retransmitting the control data unit when confirmation is not received within a predetermined amount of time.
14. The method of claim 10, wherein the sending is contingent on a prior determination of whether or not to send the control data unit based on whether the delivery of protocol data units will not take place.
15. An apparatus, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to observe a gap in a sequence of protocol data units received from a plurality of lower- layer protocol entities providing data transfer; start a timer upon the gap observation; and prevent the gap from blocking delivery of service data units to a higher layer, when the timer expires.
16. The apparatus of claim 15, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to configure the timer's expiry value by radio resource control.
17. The apparatus of claim 15, wherein the preventing is carried out by proceeding with the delivery of service data units to the higher layer without a delay caused by waiting for protocol data units.
18. The apparatus of claim 15, wherein reception of the protocol data units from more than one lower-layer protocol entities is at least substantially parallel in nature and the plurality of lower-layer protocol entities are acknowledged-mode protocol entities.
19. The apparatus of claim 15, wherein the starting the timer is further contingent upon determining whether use of the timer is activated or deactivated.
20. An apparatus, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to receive a control data unit, the control data unit identifying at least one protocol data unit that should not be expected to be received; and prevent the at least one identified protocol data unit from blocking delivery of service data units to a higher layer.
21 . The apparatus of claim 20, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to identify the at least one protocol data unit by using sequence numbers.
22. The method of claim 20, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to prevent the blocking of delivery by proceeding with the delivery of service data units to a higher layer without a delay caused by waiting for protocol data units.
23. The apparatus of claim 20, wherein the control data unit is configured to identify at least one protocol data unit that should be expected to be received.
24. An apparatus, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to determine at least one protocol data unit that will not be delivered to a data-receiving entity; and send a control data unit, identifying the at least one protocol data unit.
25. The apparatus of claim 24, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to identify the at least one protocol data unit by using sequence numbers.
26. The apparatus of claim 24, wherein the control data unit is configured to identify one or more protocol data units that should be expected to be received.
27. The apparatus of claim 24, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to await confirmation of reception of the control data unit; and retransmit the control data unit when confirmation is not received within predetermined amount of time.
28. The apparatus of claim 24, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to send the control data unit contingent on a prior determination of whether or not to send the control data unit based on whether delivery of protocol data units will not take place.
29. A method, comprising: receiving a protocol data unit with a sequence number but without a service data unit having a non-zero size; and preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
30. A method, comprising: determining a service data unit that will not be delivered to a data-receiving entity, wherein the service data unit is associated with a sequence number; and sending a protocol data unit including the sequence number but excluding the service data unit.
31 . An apparatus, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to receive a protocol data unit with a sequence number but without a service data unit having a non-zero size; and prevent absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
32. An apparatus, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to determine a service data unit that will not be delivered to a data-receiving entity, wherein the service data unit is associated with a sequence number; and send a protocol data unit including the sequence number but excluding the service data unit.
33. An apparatus, comprising: means for observing a gap in a sequence of protocol data units received from a plurality of lower-layer protocol entities providing data transfer; means for starting a timer upon the gap observation; and means for preventing the gap from blocking delivery of service data units to a higher layer, when the timer expires.
34. The apparatus of claim 33, further comprising: means for configuring the timer's expiry value by radio resource control.
35. The apparatus of claim 33, wherein the preventing is carried out by proceeding with the delivery of service data units to the higher layer without a delay caused by waiting for protocol data units.
36. The apparatus of claim 33, wherein reception of the protocol data units from more than one lower-layer protocol entities is at least substantially parallel in nature and the plurality of lower-layer protocol entities are acknowledged-mode protocol entities.
37. The apparatus of claim 33, wherein the starting the timer is further contingent upon determining whether use of the timer is activated or deactivated.
38. An apparatus, comprising: means for receiving a control data unit, the control data unit identifying at least one protocol data unit that should not be expected to be received; and means for preventing the at least one identified protocol data unit from blocking delivery of service data units to a higher layer.
39. The apparatus of claim 38, wherein the identifying the at least one protocol data unit is carried out by using sequence numbers.
40. The apparatus of claim 38, wherein the preventing is carried out by proceeding with the delivery of service data units to a higher layer without a delay caused by waiting for protocol data units.
41 . The apparatus of claim 38, wherein the control data unit identifies at least one protocol data unit that should be expected to be received.
42. An apparatus, comprising: means for determining at least one protocol data unit that will not be delivered to a data-receiving entity; and means for sending a control data unit, identifying the at least one protocol data unit.
43. The apparatus of claim 42, wherein the identifying the at least one protocol data unit is carried out by using sequence numbers.
44. The apparatus of claim 42, wherein the control data unit identifies one or more protocol data units that should be expected to be received.
45. The apparatus of claim 42, further comprising: means for awaiting confirmation of reception of the control data unit; and means for retransmitting the control data unit when confirmation is not received within a predetermined amount of time.
46. The apparatus of claim 42, wherein the sending is contingent on a prior determination of whether or not to send the control data unit based on whether the delivery of protocol data units will not take place.
47. An apparatus, comprising: means for receiving a protocol data unit with a sequence number but without a service data unit having a non-zero size; and means for preventing absence of a service data unit having a non-zero size and an association with the sequence number from blocking delivery of service data units to a higher layer.
48. An apparatus, comprising: means for determining a service data unit that will not be delivered to a data-receiving entity, wherein the service data unit is associated with a sequence number; and means for sending a protocol data unit including the sequence number but excluding the service data unit.
49. A non-transitory computer-readable medium encoded with instructions that, when executed in hardware, execute a process, the process comprising the method according to any of claims 1 -14, 29, or 30.
50. A computer program product encoding instructions for performing a process, the process comprising the method according to any of claims 1 -14, 29, or 30.
EP14715253.2A 2013-04-04 2014-03-31 Delivery of protocol data units Withdrawn EP2982069A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/856,951 US20140301362A1 (en) 2013-04-04 2013-04-04 Delivery of protocol data units
US14/067,509 US20140301188A1 (en) 2013-04-04 2013-10-30 Delivery of protocol data units
PCT/EP2014/056418 WO2014161804A1 (en) 2013-04-04 2014-03-31 Delivery of protocol data units

Publications (1)

Publication Number Publication Date
EP2982069A1 true EP2982069A1 (en) 2016-02-10

Family

ID=50439356

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14715253.2A Withdrawn EP2982069A1 (en) 2013-04-04 2014-03-31 Delivery of protocol data units

Country Status (8)

Country Link
US (2) US20140301188A1 (en)
EP (1) EP2982069A1 (en)
JP (1) JP6336039B2 (en)
KR (2) KR101811749B1 (en)
CN (1) CN105229961A (en)
BR (1) BR112015025308B1 (en)
HK (1) HK1218677A1 (en)
WO (1) WO2014161804A1 (en)

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6231837B2 (en) * 2013-09-24 2017-11-15 株式会社Nttドコモ Mobile communication method and radio base station
JP6230859B2 (en) * 2013-09-26 2017-11-15 株式会社Nttドコモ Mobile communication system and radio base station
CN104581824A (en) * 2013-10-17 2015-04-29 中兴通讯股份有限公司 Method and system for data packet shunting transmission
WO2015113497A1 (en) * 2014-01-28 2015-08-06 Mediatek Singapore Pte. Ltd. Methods for re-order pdcp packets
US10237911B2 (en) * 2014-01-30 2019-03-19 Intel IP Corporation Packet data convergence protocol (PDCP) enhancements in dual-connectivity networks
CN105578522B (en) * 2014-10-11 2019-01-01 中国移动通信集团公司 The sending method and device of transmission control protocol confirmation message section
CN105704641B (en) * 2014-11-06 2019-11-26 中兴通讯股份有限公司 Device-to-device D2D data transmission method, device and D2D UE
KR102237511B1 (en) * 2015-04-29 2021-04-07 삼성전자주식회사 Method and appratus for controlling communication of a portable terminal in an wireless communication system
WO2017012668A1 (en) * 2015-07-23 2017-01-26 Nokia Solutions And Networks Oy Improved data unit reordering in dual connectivity scenarios
US9999049B2 (en) * 2015-08-31 2018-06-12 Qualcomm Incorporated Avoiding unnecessary protocol data unit (PDU) transmissions
CN106559184A (en) * 2015-09-25 2017-04-05 中兴通讯股份有限公司 The method of data transfer, apparatus and system
CN108024295B (en) * 2016-11-03 2022-04-19 中兴通讯股份有限公司 Relay transfer method and device, terminal and base station
US11088941B2 (en) * 2017-03-23 2021-08-10 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Method for transmitting data, terminal device, and network device
CN110622543A (en) * 2017-04-28 2019-12-27 瑞典爱立信有限公司 Network node for Packet Data Convergence Protocol (PDCP) reordering and method therein
US11101940B2 (en) * 2017-05-04 2021-08-24 Lg Electronics Inc. Method and device for transmitting data unit
WO2018227501A1 (en) 2017-06-15 2018-12-20 Oppo广东移动通信有限公司 Data transmission method and device
CN109150767A (en) * 2017-06-16 2019-01-04 华为技术有限公司 A kind of data packet sending method, device and equipment
CN109451788B (en) 2017-07-20 2021-11-30 北京小米移动软件有限公司 Data transmission method and device
WO2019028826A1 (en) * 2017-08-11 2019-02-14 Qualcomm Incorporated Radio link control reassembling techniques in wireless systems
CA3075835C (en) * 2017-09-28 2023-08-15 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Wireless communication method and terminal device
CN110049519B (en) * 2018-01-15 2021-08-13 华为技术有限公司 Session establishing method, session transferring method, device and storage medium
CN111756485B (en) * 2019-03-27 2022-09-02 华为技术有限公司 Control timer, data packet processing method and equipment
CN116114206A (en) * 2020-07-20 2023-05-12 诺基亚技术有限公司 Apparatus, method and computer program
CN112469080B (en) * 2020-11-27 2022-08-02 紫光展锐(重庆)科技有限公司 Data packet processing method and related device
CN115914126A (en) * 2021-09-08 2023-04-04 联发科技(新加坡)私人有限公司 Method for managing out-of-order data packets and user equipment thereof

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100747464B1 (en) * 2002-01-05 2007-08-09 엘지전자 주식회사 Timer based Stall Avoidance method in HSDPA system
KR100896484B1 (en) * 2002-04-08 2009-05-08 엘지전자 주식회사 Data transmission mobile communication method and apparatus in mobile communication system
TW200746864A (en) * 2006-05-01 2007-12-16 Interdigital Tech Corp Method and apparatus for facilitating lossless handover in 3GPP long term evolution systems
US8116250B2 (en) * 2006-07-07 2012-02-14 Telefonaktiebolaget L M Ericsson (Publ) Medium access control discard notification
US8290428B2 (en) * 2006-12-06 2012-10-16 Qualcomm Incorporated Methods and apparatus for RLC re-transmission schemes
KR100907978B1 (en) 2007-09-11 2009-07-15 엘지전자 주식회사 A status reporting transmission method and receiving apparatus of a PDCP layer in a mobile communication system
US8477719B2 (en) * 2007-10-01 2013-07-02 Qualcomm Incorporated Systems and methods for in-order delivery in downlink during handover
US8989004B2 (en) * 2010-11-08 2015-03-24 Qualcomm Incorporated System and method for multi-point HSDPA communication utilizing a multi-link PDCP sublayer
US20120294281A1 (en) * 2011-05-16 2012-11-22 Electronics And Telecommunications Research Institute Data delivery method performed in receiving apparatus of mobile communication system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2014161804A1 *

Also Published As

Publication number Publication date
JP2016521038A (en) 2016-07-14
CN105229961A (en) 2016-01-06
BR112015025308B1 (en) 2023-04-04
US20160043955A1 (en) 2016-02-11
BR112015025308A8 (en) 2022-04-26
KR101811749B1 (en) 2017-12-22
HK1218677A1 (en) 2017-03-03
US20140301188A1 (en) 2014-10-09
BR112015025308A2 (en) 2017-07-18
JP6336039B2 (en) 2018-06-06
KR20150138351A (en) 2015-12-09
WO2014161804A1 (en) 2014-10-09
KR20170021383A (en) 2017-02-27

Similar Documents

Publication Publication Date Title
US20160043955A1 (en) Delivery of protocol data units
US20140301362A1 (en) Delivery of protocol data units
EP3332604B1 (en) Method, apparatus and computer readable medium for packet data convergence protocol (pdcp) reordering with enhanced component carriers
US10440614B2 (en) Interruptions in wireless communications
EP3020155B1 (en) Method and system for protocol layer enhancements in data offload over small cells
US20200267793A1 (en) Method and system for handling packet duplication and resumption of rbs in wireless communication system
KR101577451B1 (en) Method of detecting and handling an endless rlc retransmission
EP3603138B1 (en) Packet data convergence protocol windows with split bearers
JP6142920B2 (en) Wireless communication system, mobile station, base station, and wireless communication method
US8917728B2 (en) Retransmission request transmitting method and receiving-side apparatus
EP2670077A1 (en) Method and apparatus for data packet retransmission
EP3455969B1 (en) Packet retransmission in a wireless communication system
JPWO2015141012A1 (en) Wireless communication apparatus and wireless communication method
US20140029564A1 (en) Communication system, communication apparatus and radio resource allocating method
US10396966B2 (en) Per-protocol data unit delivery-path indication
JP6481711B2 (en) Wireless communication system, mobile station, base station, and wireless communication method

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20151104

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20190401

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SOLUTIONS AND NETWORKS OY

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190813