Methods for managing data transmission within a wireless communication network

WO2026201948A1PCT designated stage Publication Date: 2026-10-01CANON KK +2
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/EP2026/058215
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2025-03-24
Filing Date
2026-03-23
Publication Date
2026-10-01

Smart Images

  • Figure EP2026058215_01102026_PF_FP_ABST
    Figure EP2026058215_01102026_PF_FP_ABST
Patent Text Reader

Abstract

A method for managing data transmission, as part of a packet data convergence protocol, PDCP, re-establishment procedure, between a user equipment and a target base station of a wireless communication network, the method at the user equipment comprising following the detection of a sequence number gap relating to data transmitted by the user equipment, transmitting to the target base station an indication of the detected sequence number gap.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] 11033960W001

[0002] METHODS FOR MANAGING DATA TRANSMISSION WITHIN A WIRELESS COMMUNICATION NETWORK

[0003] FIELD OF THE INVENTION

[0004] The present disclosure relates to methods for managing data transmission, as part of a Packet Data Convergence Protocol, re-establishment procedure, between a user equipment and a base station of a wireless communication network.

[0005] BACKGROUND

[0006] Wireless communication systems are largely deployed to address a wide range of applications, from mobile broadband, massive machine type communications to Ultra Reliable Low Latency Communications (URLLC). Such systems allow a plurality of user equipment (UE) or mobile terminals to share the wireless medium to exchange several types of data content (e.g. video, voice, messaging...) over a radio access network (RAN) through one or more base stations.

[0007] Examples of such wireless multiple-access communication systems include systems based on 3rd generation partnership project (3GPP - RTM) standards, such as fourthgeneration (4G) Long Term Evolution (LTE) or recent fifth-generation (5G) New Radio (NR) systems, or systems based on IEEE 802.11 standards, such as Wi-Fi.

[0008] Among the requirements for 5G NR, there are service requirements related to extended reality (XR).

[0009] XR (extended Reality) applications is defined in 3GPP document RP-2200285 as “various types of augmented, virtual, and mixed environments, where human-to-machine and human-to-human communications are performed with the assistance of handheld and wearable end user devices.”

[0010] Various uses cases can be found in 3GPP document TR-26.928.

[0011] Many XR applications involves interactions between a wearable device (for example a 3D helmet or augmented reality glasses) and an application server. The wearable device and the application server can be connected through a local Network (like a wireless LAN) or cellular network (like 3GPP 5G cellular network, the application server being connected to the 5G core network part).

[0012] Some XR applications like cloud gaming, involves transferring compressed video data, audio data from the server to the UE and position information from the UE to the server.

[0013] Some XR applications like virtual reality, involves transferring compressed video data, audio data, and various information from the server to the wearable device.11033960W001

[0014] Some XR applications like augmented reality, involves transferring compressed video data, audio data and various information exchanged to and from the wearable device and the server.

[0015] In the present disclosure, the information exchanged to and from the UE or wearable device and the server is referred to as application data. For example, application data may comprise one or more images, video data, audio data, position information, and various information.

[0016] The video and audio data are transferred between the wearable device (or the user equipment) and the server using media transport protocols like RTP (Real Time Protocol, RFC 3550), SRTP (Secured RTP, RFC 3711), HTTP (Hyper Text Transfer Protocol, RFC 2616-7540) or QUIC (RFC 8999, 9000, 9001 and 9002).

[0017] Video encoding and decoding can be performed according to various formats including MPEG2, H.264, H.265, HEVC, etc.

[0018] Applications generate data in the form of encoded video, audio, or position information. These data are primarily arranged in data packets by the application, an application data packet representing one unit of information is generated at the application level. 3GPP named the set of PDlls (Protocol Data Unit or Packet Data Unit) necessary to transport an application data packet a “PDU Set”. Application data comprises one or more application data packets. In downlink, 3GPP PDUs are formatted by the core network PDU Layer. In the same way, in uplink, the 3GPP PDUs are formatted by the UE (User Equipment) PDU layer. In 3GPP the delimitations of the PDU Sets (start, stop, length) are not provided by the application but generated by the core network (respectively the UE) through media transport protocol packet inspection. The detailed procedure can be found in 3GPP document TR-23.700-60.

[0019] A PDU Set is composed of one or more PDUs carrying the payload of one unit of information generated at the application level (e.g. a frame or video slice forXRM Services, as used in TR 26.926). In some implementations all PDUs in a PDU Set are needed by the application layer to use the corresponding unit of information. In other implementations, the application layer can still recover parts all or of the information unit, when some PDUs are missing. For example, one PDU Set may comprise the data of one image or frame from a video stream.

[0020] In downlink the PDU Set identification information calculated by the core network UPF (User Plane Function) are inserted in the GTP-U (GPRS Tunnelling Protocol - User Plane, TS 29.281) header. GTP-U is the protocol used by the UPF to transport data from the core network to the gNB. When GTP-U PDUs arrives atgNB SDAP (Service Data Adaptation layer, TS 37.324), the GTP-U header is removed and the PDU Set identification information is no more provided in-band. Hence the UE side (receiving side) in downlink does not have access to the PDU Set identification information.11033960W001

[0021] In uplink the PDU Set identification information calculated by the UE PDU layer are not inserted in any header, so the PDU Set identification information are not provided in-band. Hence the gNB side (receiving side) in uplink does not have access to the PDU Set identification information. To summarize, at all protocol layers (including the PDCP layer), the receiving entity does not have knowledge of the PDU Sets identification information, not in downlink nor in uplink.

[0022] On the transmit side, all layers below SDAP layer (e.g. PDCP transmitting entity) do not have access to in-band PDU Set identification information, but some internal mechanisms are easy to associate out-band PDU Set delimitation information to each PDU. For example, in the gNB, the GTP-U receiving entity can associate out-band PDU Set delimitation information to each PDU and pass them to PDCP transmitting entity. Another example is in the UE, the PDU layer can associate out-band PDU Set delimitation information to each PDU and pass them to the PDCP transmitting entity.

[0023] The network used to transport the application data can experience perturbation and congestion. It is therefore possible that some PDUs of a PDU Set are missing or are late at the receiving side (UE PDU layer in downlink, Core network UPF in uplink).

[0024] Some video decoder implementation requires the reception of a complete application data packet (complete PDU Set), received on time, to adequately decode a video. While other implementation can tolerate late arrival of data packets or partial delivery of data packets of a PDU Set. For example, these implementations rely on FEC (Forward Error Correction) technology or concealment techniques.

[0025] 3GPP, in document TR-23.700-60, defined a PDU Set QoS parameter called PSDB (PDU Set Delay Budget) that defines a time budget allocated to the transport of the PDU Set across the 5G system. This QoS parameter defined by the application is used by a 5G system to assess if a PDU Set (application data packet) is delivered on time.

[0026] In the same 3GPP document, TR-23.700-60, another QoS parameter named PSII (PDU Set Integrated Indication) is defined to characterize the decoder tolerance to loss or outdated data. If PSII parameter is set to “true”, then the decoder can only handle complete application data packet received on time. If PSII is set to “false”, then the decoder can tolerate both incomplete and delayed application data packets. In other 3GPP documents, PSII QoS parameter is also named PSIHI (PDU Set Integrated Handling Indication).

[0027] In the 5G system, at a radio network part, when a PDU Set is being sent over the air interface, some information is available regarding the reception status of the PDUs and the elapsed time of the PDU Set Delay Budget. For example, when a PDU Set is being transferred over the air, a RAN node (Radio Access Network node, either UE or gNB) can detect that one PDU transmission has failed despite all the retransmissions and error correction mechanisms. In that case, if the PSII QoS parameter is set to “true”, it means the entire PDU Set is useless11033960W001

[0028] to the application. In that case if PDlls of this “useless” PDU Set are pending transmission over the air interface, then the RAN node can consider discarding the remaining transmission of these PDlls thus achieving radio network resource saving.

[0029] In 3GPP document RP-223502, PDU Set discarding has been set as an objective for the enhancement of the Radio Access Network in order to increase the 5G system capacity to handle XR applications.

[0030] 3GPP 5G systems have two modes for delivering data to applications: in-sequence delivery and free delivery. In-sequence delivery comprises delivering the application data packets by the network to the application (the application server or the UE) in the same order as they were delivered by the application (the application server or the UE) to the network. Free delivery means that packet ordering is not guaranteed.

[0031] In 5G RAN (Radio Access Network), there are various causes that can provoke a change in packet ordering. For example, retransmission based on windowed acknowledgement techniques like the one used in certain configurations of the RLC (Radio Link Control, TS 38.322) layer or the hybrid ARQ (Hybrid Automatic Repeat reQuest) used in certain configurations of the MAC layer (TS 38.321). Carrier aggregation and dual connectivity are also known to cause change in packet ordering.

[0032] In 5G RAN, the PDCP (Packet Data Convergence Protocol, TS 38.323) layer can be configured to perform packet re-ordering. Since PDCP layer is also used to reconcile data from dual connectivity or carrier aggregation, and since the upper layers above PDCP do not implement retransmission, if PDCP layer is configured to perform re-ordering of packets on 5G RAN part of the 5G system, in-order delivery of packets is guaranteed.

[0033] PDCP layer implements in-sequence delivery by monitoring PDCP PDUs sequence numbers. PDCP PDUs include a sequence number in their headers. This sequence number is incremented by the PDCP sending entity (UE in uplink, gNB in downlink). When in-sequence delivery is configured, the PDCP receiving entity, when receiving a new PDCP PDU, shall check the PDU sequence number and, if the new sequence number follows the previously received sequence number, the PDCP receiving entity shall deliver the PDCP PDU to upper layers. If the new sequence number does not follow the previously received sequence number, then a sequence number gap is detected and the PDCP receiving entity shall not deliver the PDCP PDU to upper layers until all missing PDCP PDUs (those with sequence numbers lower than current sequence number and higher than the previously received sequence number) are received. The waiting for missing packets is time bounded, after a configured amount of time is elapsed, missing PDCP PDUs are considered definitively lost and current PDCP PDU is delivered to higher layer (upper layers). The missing PDCP PDUs will be discarded if received after the waiting time is elapsed. The waiting time is controlled by a time counter named “t-ordering” and also referred to as the re-ordering counter. The value of the waiting11033960W001

[0034] time is configured by the gNB (for both uplink and downlink) within a range from 1 millisecond to 3 seconds (see 3GPP document TS 38.331).

[0035] By combining both the PDU Set discarding and the PDU reordering at PDCP layer, sequence number gaps may be created at the receiving side and sequence number gap signalling messages may be sent by the PDCP transmitting side to the PDCP receiving side so that the PDCP receiving side will not wait for the discarded PDlls.

[0036] During uplink, the PDCP transmitting side is located at the UE and the PDCP receiving side is located at the gNB. In case of handover, the PDCP receiving side changes from source gNB to target gNB.

[0037] In a case where the UE sends a sequence number gap signalling to the source gNB prior to the handover, the target gNB operating as the new PDCP receiving side will not be aware of the sequence number gap signalled by the UE to the source gNB. Consequently, the PDCP receiving entity of target gNB may delay the delivery of PDU waiting for the reception of some missing PDUs that have been discarded by the UE prior to the handover. Since these PDUs have been discarded by UE, they will never be re-sent to the target gNB.

[0038] Thus, there is a need to improve the provision of information to the target gNB about some of the discarded PDUs, especially during a UE re-establishment procedure.

[0039] SUMMARY

[0040] According to embodiments of the present disclosure, there is provided a method of indicating to a target base station (e.g., of a wireless communication network) the existence of a sequence number gap relating to data for transmission to the target base station from a user equipment.

[0041] According to a first embodiment there is provided a method for managing data transmission, as part of a packet data convergence protocol, PDCP, re-establishment procedure, between a user equipment and a base station (e.g., a source base station and / or target base station) of a wireless communication network. The method (e.g., when implemented at the user equipment) comprises, following the detection of a sequence number gap relating to data transmitted by the user equipment, transmitting to the target base station an indication of the detected sequence number gap.

[0042] According to a second embodiment there is provided a method for managing data transmission, as part of a packet data convergence protocol, PDCP, re-establishment procedure, between a user equipment and a base station (e.g., a source base station, and / or a target base station) of a wireless communication network. The method comprises: identifying whether (e.g., whether or not) a prior sequence number gap indication (e.g., a SN gap report) transmitted by the user equipment to a source base station has been received. If the reception of the prior sequence number gap indication by the source gNB is confirmed, then the source11033960W001

[0043] base station transmits the prior sequence number gap indication to a target base station. If the reception of the prior sequence number gap indication by the source gNB is confirmed, then the user equipment transmits the prior sequence number gap indication to the target base station.

[0044] According to the first and second embodiments, the target base station is provided with timely information about PDCP data which has been discarded by the source gNB and which will never be re-sent to the target gNB. In this way, the present disclosure minimizes delays to the delivery of PDCP data for a re-establishment procedure in the event of PDU discarding.

[0045] Optional features will now be set out. These are applicable singly or in any combination with any aspect of the disclosure.

[0046] According to the present disclosure, the terms “re-establishment” and “sequence number gap” may be interpreted in a manner consistent with their usage in Third Generation Partnership Project (3GPP) standards.

[0047] In embodiments, the indication of the sequence number gap may be transmitted directly from the user equipment to the target base station.

[0048] The indication of the detected sequence number gap may comprise a sequence number gap report.

[0049] The sequence number gap is detected before, or during, the re-establishment procedure. The sequence number gap indication may comprise a mapping indication, such as a bitmap for indicating the status of the transmissible data.

[0050] The re-establishment procedure may be performed as part of, or following, a handover of the user equipment from a source base station to the target base station.

[0051] The identification as to whether a sequence number indication has been successfully received by the base station may be enabled in dependence on the user equipment being configured in an Acknowledge mode (AM).

[0052] The sequence number gap may be detected based on at least one of the following detection criteria: whether a sequence number gap indication has been transmitted to the source base station before the handover; whether a sequence number gap indication has been transmitted to the source base station, but its reception is not confirmed before the handover; and whether a sequence number gap has been confirmed at the target base station.

[0053] The sequence number gap indication may be configured based on at least one of the detection criteria.

[0054] The method may further comprise, following the detection of a sequence number gap relating to data transmitted to the source base station, transmitting to the source base station an initial indication relating to the detected sequence number gap.

[0055] In embodiments, if following the transmission of the initial sequence number gap indication the reception of the data is not confirmed, then the sequence number gap indication11033960W001

[0056] which is transmitted to the target base station may be configured to be the same as the initial sequence number gap indication.

[0057] In embodiments, if following the transmission of the initial sequence number gap indication the reception of at least part of the data is confirmed, then the sequence number gap indication which is transmitted to the target base station may be configured to be different to the initial sequence number gap indication.

[0058] The sequence number gap indication may be transmitted to the target base station if the initial indication is not received by the source base station.

[0059] In embodiments, if the initial sequence number gap indication is not received by the source base station, then the method at the user equipment may comprise transmitting the sequence number gap indication to the target base station; and / or if the initial sequence number gap indication is received by the source base station, then the method at the source base station may comprise transmitting the initial sequence number gap indication to the target base station.

[0060] In embodiments, the method may be performed as part of a PDCP data recovery procedure. Alternatively, or in addition, the method may be performed as part of a dual active protocol stack procedure. For example, the method may be performed during an uplink data switching procedure.

[0061] Optionally, the method is performed as part of a sequence number gap report triggering procedure.

[0062] The sequence number gap of the data transmitted by the user equipment may be detected in accordance with at least one of the following criteria: at least one data unit, SDU, of the transmitted data may be discarded (e.g., prior to, or during the re-establishment procedure); at least one SDU of the transmitted data may be associated with a count value which is larger than a count value which is associated to the at least one discarded SDU; and the at least one discarded SDU may not have been submitted to a lower layer of the protocol stack.

[0063] The at least one discarded SDU may be indicative that at least one protocol data unit, PDU, Set of the transmitted data has not been fully received by a base station of the wireless communication network.

[0064] According to a third embodiment there is provided an apparatus (e.g., a user equipment) comprising a transmitter configured to perform the method of the first and / or second embodiments.

[0065] According to a fourth embodiment there is provided a communication network which comprises an apparatus according to the third embodiment.11033960W001

[0066] According to a fifth embodiment there is provided a computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to the first and / or second embodiments.

[0067] According to a sixth embodiment there is provided computer-readable medium carrying a computer program according to the fifth embodiment.

[0068] Any feature of the above embodiments may be applied to other embodiments of the disclosure, in any appropriate combination. In particular, method embodiments may be applied to apparatus / device / unit embodiments, and vice versa.

[0069] It will be understood that any one of the features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly. For example, in accordance with other embodiments of the disclosure, there are provided a computer program comprising instructions which, when the program is executed by one or more processing units, cause the one or more processing units to carry out the method of any embodiment or example described above and a computer readable storage medium carrying the computer program.

[0070] The preceding summary is provided for purposes of summarising some examples to provide a basic understanding of embodiments of the subject matter described herein. Accordingly, the above-described features should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Moreover, the above and / or proceeding examples may be combined in any suitable combination to provide further examples, except where such a combination is clearly impermissible or expressly avoided. Other features, embodiments, and advantages of the subject matter described herein will become apparent from the following text and the accompanying drawings.

[0071] BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Different embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which:

[0073] Figure 1 is a schematic diagram illustrating an example wireless communication system in which the present disclosure may be implemented according to one or more embodiments of the disclosure;

[0074] Figure 2 illustrates a block schematic diagram of an example configuration of a UE in which the present disclosure may be implemented according to one or more embodiments of the disclosure;

[0075] Figure 3 illustrates a block schematic diagram of an example configuration of a base station in which the present disclosure may be implemented according to one or more embodiments of the disclosure;11033960W001

[0076] Figure 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1;

[0077] Figure 5 is a block schematic diagram of an example embodiment of a PDCP protocol layer according to 3GPP document TS 38.323;

[0078] Figure 6 is a schematic and simplified diagram of an example message flow illustrating the management of PDCP sequence numbers during the handover;

[0079] Figure 7 is a schematic and simplified diagram of an example message flow illustrating the management of PDCP sequence numbers during the handover according to an embodiment of the disclosure;

[0080] Figure 8 is a schematic and simplified diagram showing an example message flow for performing an Xn handover of a UE, in accordance with one or more embodiments of the disclosure;

[0081] Figure 9 is a schematic and simplified diagram illustrating an example message flow for performing the NG handover of a UE according to embodiments of the disclosure; and Figures 10 and 11 are schematic and simplified diagrams illustrating first and second embodiments, respectively, of the disclosure.

[0082] DETAILED DESCRIPTION

[0083] Embodiments of the present disclosure will now be discussed in detail with reference to the accompanying figures. Further embodiments will be apparent to those skilled in the art.

[0084] Figure 1 illustrates an example wireless communication system 100, in particular a mobile radio communication system such as a fifth-generation (5G) New Radio (NR) system supporting an extended reality service (XR). Although in the following description, embodiments, and examples of embodiments of the present disclosure will be described with respect to a 5G NR system, it will be appreciated that it is not intended that the present disclosure is limited to 5G NR systems and may be used in any wireless communication systems supporting XR or similar service.

[0085] The system 100 comprises a User Equipment (UE) 101 (or 151), which may be for instance a virtual reality helmet or extended reality (XR) wearable like smart glasses. The UE is served by a base station 110 to communicate with a core network, such as the 5G core network 102. The UE may be any wireless device, such as a wireless communication device or apparatus or terminal, loT device, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, user device (e.g. smart phone, laptop, mobile phone, tablet, camera, game console, wearable device), capable of wireless communication with one or more core networks via one or more Radio Access Networks. The base station 110 is a network node which provides an access point to the core network for a UE and is part of the Radio Access11033960W001

[0086] Network (RAN) composed of the base stations 110, and 111. In NR, base stations are referred to as next-generation Node Bs (gNBs), the RAN is a Next Generation (NG) RAN and the core network is referred to as the 5GC. In the following, the terms RAN node, base station and gNB will be used interchangeably. The base stations 110 and 111 are interconnected by means of the Xn interface (specified in the 3GPP document TS 38.423) implemented on the wired or wireless link 130. Each base station is connected to the core network 102 by means of the NG interface (specified in the 3GPP document TS 38.413) implemented on the wired or wireless links 140 and 141.

[0087] Each of these base stations controls one or multiple cells. For instance, base station 110 controls the cell 120, and base station 111 controls the cell 121. A cell is a geographical area of a radio network defined by the frequency used in the cell to transmit data. The cell can be uniquely identified by a UE from an identification that is broadcasted over a geographical area. Each base station 110, 111 can serve several UEs like the UE 101 or UE 151. Once a UE has established a RRC connection with a base station, the base station, to which the UE is connected, is referred to as the serving base station or source base station of the UE and the cell which is controlled by the serving base station, and on which the UE camps, is referred to as the serving cell. The interface between a gNB and a UE is the Uu interface using the protocol sublayers SDAP (Service Data Adaptation Protocol), PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Medium Access Control), PHY (Physical) in the user plane, and the protocol sublayers RRC (Radio Resource Control), PDCP, RLC, MAC, PHY in the control plane.

[0088] It is assumed that UE 101 is receiving and / or sending XR data of one or more multicast XR sessions generated and / or destinated to the XR application server 103. The XR data are provided to base station 111, which controls cell 121 to which UE 101 is attached, through the core network 102 (e.g., through Data Network 160 and User Plane Function 161) and the transport bearer (also known as GTP-U tunnel) 106 over link 141. Then, XR data is transmitted by the base station 111 to the UE 101 through the Data Radio Bearer (DRB) 154. Figure 1 also shows UE 151 receiving data through DRB 153. A radio bearer is a set of PHY (layer 1) and MAC (Iayer2) parameters allowing higher layer data connection between a UE and a gNB. Multiple types of radio bearers are defined in 5G NR: the SRB (Signalling Radio Bearer) for the control plane, the DRB (Data Radio Bearer) allowing point-to-point communication with one UE in the user plane (unicast), and the MRB allowing point-to-point communication and point-to-multipoint communication with multiple UEs (multicast / broadcast), also in the user plane.

[0089] Figure 2 illustrates a block diagram of a UE device 205, like UE 101 or UE 151 in the Figure 1, in which the present disclosure may be implemented according to one or more11033960W001

[0090] embodiments of the disclosure. The UE includes components for transmitting and receiving communications, for example including at least one of a UE communication manager 220, a I / O controller 255, a transceiver 235, a set of antennas 245, memory 225, and a processor (CPU: Central Processing Unit) 215. All these elements may communicate with each other.

[0091] Memory 225 includes RAM (Random Access Memory), ROM (Read Only Memory), or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. Basic Input Output System (BIOS) Instructions may be stored within the memory 225.

[0092] The processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may be related to transmission or to interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2). The processor may run an operating system like for instance, iOS, Windows, Android, etc. The processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205. The number of processors and the allocation of processing functions to the processors is a matter of design choice for a skilled person.

[0093] The I / O controller 255 allows these interactions with external peripherals by providing the hardware required and by managing input and output signals.

[0094] The transceiver 235 is configured to provide bi-directional wireless communication with other wireless devices. For example, it provides the necessary modems and frequency shifters necessary to connect to one or more wireless networks, such as Wi-Fi, Bluetooth, LTE, 5G NR, etc. The transceiver 235 may comprise a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 215. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 215.

[0095] The radio communications use the antenna set 245 adapted to the spectrum of the frequency transposed signals, issued from the baseband modems. The antenna set 245 may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

[0096] UE communication manager 220 handles the communication establishment of the UE to a Radio Access Network, its control and its release. The UE regularly receives from the base station an indication of slots available for communication between the UE and base station. The UE then knows where in time and frequency it expects incoming data or must send its outgoing data, whether they belong to the control or data plane. In an example implementation, the UE communication manager 220 implements the Uu interface.11033960W001

[0097] Figure 3 illustrates a block diagram of a base station device 305, similar to base stations (gNBs) 110 and 111 in the Figure 1, in which one or more embodiments of the present disclosure may be implemented. The base station device 305 includes components for transmitting and receiving communications, for example including at least one of a Base Station communication manager 320, a Core Network communication manager 355, a transceiver 335, a set of antennas 345, memory 325, a processor (CPU) 315, and an InterStation communication manager 365. All these elements may communicate with each other.

[0098] The Base Station communication manager 320 handles the communications with a plurality of UEs. It is responsible for the establishment, the control, and the release of these communications. In an example implementation, the Base Station communication manager 320 implements the Uu interface. The Base Station communication manager 320 includes a scheduler that allocates time frequency slots to the different UE communications. Information regarding the schedule of these slots is regularly sent to the involved UEs.

[0099] The Core Network communication manager 355 manages communications of the base station with the core network. It may provide a standardized NG interface, as defined by the 3GPP standard, to support these communications.

[0100] The transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices may be UEs, or even other base stations. The transceiver 335 provides the necessary modems and frequency shifters in order to connect to a large number of UEs simultaneously, using different frequency carriers, in Time Division Duplex (TDD) or in Frequency Division Duplex (FDD). The transceiver 335 may include a PDCP transmitter and a PDCP receiver. The PDCP transmitter and the PDCP receiver may be implemented by the processor 315. The PDCP transmitter and the PDCP receiver may be a software only function implemented by the processor 315. The transceiver 335 is connected to the antenna set 345, that may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.

[0101] Memory 325 includes RAM, ROM, or combination of both or as a non-limiting example a mass storage device such as a disk or a Solid-State Drive. BIOS Instructions may be stored within the memory 325 to support an operating system.

[0102] The inter-station communication manager 365 manages communications with other base stations. The Inter-Station communication manager 365 may provide a standardized Xn interface, as defined by the 3GPP standard, to support these communications.

[0103] Figure 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1. This data plane protocol stack is described in detail in 3GPP document TS 23.501. In the downlink direction, an application server 103 connects to the UPF (User Plane Function) 161 through a data network 160 at PDU layer 40211033960W001

[0104] level. PDU layer corresponds to the PDlls carried between the UE (user Equipment) and the DN (Data Network) over the PDU Session. When the PDU Session Type is IPv4 or IPv6 or IPv4v6, it corresponds to IPv4 packets or IPv6 packets or both of them; When the PDU Session Type is Ethernet, it corresponds to Ethernet frames; etc. At PDU session establishment time, the core network provides session QoS parameters to UPF, gNB and UE. The PDU session QoS parameters includes at least one of the following XR PDU Set QoS parameters (S2-2302696):

[0105] A. PDU Set Delay Budget;

[0106] B. PDU Set Error Rate; and

[0107] C. PDU Set Integrated Handling Indication. Formerly called PDU Set Integrated Indication

[0108] When the PDUs (in the description of Figure 4, unless stated otherwise, a PDU refers to the packets handled by the PDU layer 402, all other layers handle other types of PDUs and their PDUs will be prefixed by the layer name, e.g. PDCP PDU) arrive at the UPF PDU layer 402, the UPF performs application packets inspection to determine the PDU Set boundaries. Document S2-2302696 provides examples on how to identify PDU Sets when inspecting RTP / SRTP header, RTP header extension, H.264 RTP payload, H.265 RTP payload and H.266 RTP payload.

[0109] PDU Set identification information as described in S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header. The PDU Set identification Information comprises at least one of:

[0110] A. PDU Set Sequence Number;

[0111] B. Indication of End PDU of the PDU Set;

[0112] C. PDU Sequence Number within a PDU Set;

[0113] D. PDU Set Size in bytes; and

[0114] E. PDU Set Importance, which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS Flow.

[0115] In uplink the application is located on the UE. As explained earlier, the UE obtains the PDU session QoS parameter from the core network when the PDU session is established (PDU session establishment procedure is defined in TS 23.502 clause 4.3.2.). When the PDUs generated by the application 403 arrive at the UE PDU layer 402, the UE performs application packets inspection to determine the PDU Set boundaries in the same way as described earlier for UPF.

[0116] In both downlink and uplink, the application 103 sends and receives data to / from the NG-RAN through a General Packet Radio Service (GPRS) tunnel (e.g., GTP-U layer 404 as described in TS 29.281).11033960W001

[0117] In downlink, the UPF detects the PDU Set identification information and obtains from the core network a set of mapping rules (e.g., filtering rules). The filtering rules define how each PDU Set is mapped to QoS flows. QoS Flows are identified by an identifier, and GTP-U PDUs are marked according to the determined QoS flow identifier. At the gNB, the relay layer 406 extracts PDU Set identification information and QoS flow identifier from GTP-U PDUs and maps them into SDAP QoS flows. In one XR session, multiple PDU Sets can be mapped to the same QoS flow and also in one XR session, some PDU Sets may be mapped to different QoS flows. Then according to 3GPP document TR-38.835, in one alternative, each SDAP QoS flow can be mapped to a different PDCP DRB (Data Radio Bearer), and in a second alternative, all SDAP QoS flows from the same XR session are mapped to a single PDCP DRB.

[0118] In uplink, the UE detects the PDU Set identification information at PDU layer 402 and obtains from the core network a set of mapping rules (filtering rules). The filtering rules define how each PDU Set is mapped to QoS flows. The UE maps the XR PDUs to associated SDAP QoS flows according to the filtering rules. In the same way as for downlink, in uplink, in one XR session, multiple PDU Sets can be mapped to the same QoS flow and, in one XR session, some PDU Sets may be mapped to different QoS flows.

[0119] Figure 5 is a block schematic diagram of an example embodiment of a PDCP protocol layer according to 3GPP document TS 38.323. A PDCP layer 401 is composed of a PDCP transmitting entity 502 and a PDCP receiving entity 503. In Figure 5, the two PDCP entities do not belong to the same NG-RAN node. The two PDCP entities are connected by radio communication 504 which represents a simplified view on all lower layers from RLC to PHY. For example, PDCP transmitting entity 502 is located on UE 101 and PDCP receiving entity 503 is located on gNB 111. However, the present disclosure is not limited to this particular example, the PDCP transmitting entity (e.g., PDCP transmitter) 502 may be located on the gNB 111 and the PDCP receiving entity (e.g., PDCP receiver) 503 may be located on the UE 101. Each NG-RAN node implements both PDCP transmitting and receiving entities, they are not all represented in this figure for simplicity.

[0120] Each functional block of the PDCP entities is described in detail in 3GPP document TS 38.323. Each PDCP entity is carrying the data of one radio bearer. A PDCP entity is associated either to the control plane or the user plane depending on which radio bearer it is carrying data for. A PDCP entity associated with DRB / MRB can be configured by the RRC layer (TS 38.331 describes a control plane which is not shown in Figure 4) to use header compression or uplink data compression (UDC) 505. Robust header compression protocol (ROHC), the Ethernet header compression protocol (EHC) and UDC are supported. Each header compression protocol is independently configured for a DRB / MRB. The compression 505 is performed by11033960W001

[0121] the transmitting entity 502, and the decompression 509 is performed by the receiving entity 503.

[0122] The integrity protection function includes both integrity protection 506 and integrity verification 512 and is performed in PDCP, if configured by RRC. The data unit that is integrity protected is the PDCP PDU header and the data part of the PDCP PDU before ciphering. The integrity protection is always applied to PDCP Data PDlls of SRBs (Signalling Radio Bearer). The integrity protection is not applicable to PDCP Control PDlls.

[0123] The ciphering function includes both ciphering 507 and deciphering 508 and is performed in PDCP, if configured. The data unit that is ciphered is the MAC-I (1203, 1213, 1223) and the data part of the PDCP Data PDU except the SDAP header and the SDAP Control PDU if included in the PDCP SDU (Service Data Unit). The ciphering is not applicable to PDCP Control PDUs.

[0124] If configured, the PDCP transmitting entity 502 performs buffer sequence numbering 510 which is further detailed in Figure 9, while PDCP receiving entity 503 performs re-ordering and duplication discarding 511 which is further detailed in Figure 11.

[0125] Examples of sequence numbering and re-ordering are described below with reference to Figure 6.

[0126] Figure 6 is a schematic and simplified diagram of an example message flow illustrating the management of PSCP sequence numbers during the handover. Figure 6 shows a sequence of PDUs (e.g., PDCP PDUs) exchanged between a PDCP transmitting entity 502 (e.g., UE 101) and a PDCP receiving entity 503 (e.g., gNB 111).

[0127] The sequence commences when PDU 6010 is sent by the transmitting entity and received by the receiving entity. This PDU is delivered to higher layers (SDAP layer) of the protocol stack. A second PDU 6020 is sent by the transmitting entity but not received by the receiving entity. This can be due to bad radio link conditions. Lower layers like RLC and MAC perform, if configured, multiple retransmissions of PDU 6020. While lower layers handle the retransmission of PDU 6020, the transmitting entity sends a third PDU 6030. The receiving entity receives PDU 6030 and detects that PDU 6020 is missing because there is a sequence “gap” between PDUs 6010 and PDU 6030. The receiving entity stores PDU 6030 and starts t_ordering timer. PDU 6030 will not be delivered to the upper layer (SDAP) until either PDU 6020 is received or the t_ordering timer elapses. PDUs 6040 and 6050 are sent by the transmitting entity but not received by the receiving entity. The transmitting entity sends PDU 6060, which is received by the receiving entity. The receiving entity then detects missing PDUs 6040 and 6050 because there is a sequence gap between PDU 6030 and PDU 6060. The receiving entity stores PDU 6060 while the t_ordering timer is already running. PDU 6060 will not be delivered to upper layer (SDAP) until PDU 6030 is delivered and PDUs 6040 and 605011033960W001

[0128] are received, or until t_ordering timer elapses after being re-initialised when PDU 6030 is delivered.

[0129] In this example, PDlls 6010, 6020, 6030, 6050 are part of a first PDU Set (e.g., PDU Set 1) and PDUs 6040, 6060 are part of a second PDU Set (e.g., PDU Set 2). The PDU Set identification information is known at the transmitting side SDAP layer and it is not known at the receiving side.

[0130] In this example the discard timer associated with PDU 6020 elapses (as shown by the star at 6070), and the UE is configured with pdu-SetDiscard, so the UE discards PDUs 6020 and 6050 because they are part of PDU Set 1. Consequently, the UE sends a SN gap discard notification 6080, indicating the two discarded PDUs 6020 and 6050.

[0131] Upon reception of the SN gap report 6080, gNB 111 will deliver PDU 6030 to the higher layer and waits for PDU 6040 (e.g., as the next PDU) before delivering PDU 6060 to the higher layer.

[0132] In this example, a handover 6090 is decided by the source gNB 111 at some time after having received the SN gap report 6080. The handover decision arranges the UE 101 to be handed over to target gNB 110. As part of the handover procedure, the source gNB 111 may send a SN status transfer message (e.g., which conforms to specification TS 38.423). The SN status transfer 6100 indicates the first missing PDU (e.g., PDU 6040) at the source gNB 111. PDU 6020 is not considered as missing since PDU 6030 has been delivered to the higher layer upon the reception of SN gap report 6080. Optionally, a bitmap is provided indicating the status of those PDUs which follow PDU 6040 (e.g., the notifier “01” indicates that PDU 6050 is missing and PDU 6060 has been received).

[0133] In this example, PDU 6040 is missing, PDU 6060 is not delivered to the higher layer by source gNB 111 before the handover. Optionally, the source gNB may forward PDU 6060 in an uplink forward message 6110. In this example, the receiving entity of the target gNB 110 will delay the delivery of PDU 6060 until PDUs 6040 and 6050 are received, or t_ordering timer has elapsed. However, PDU 6050 has been discarded by UE 101 (e.g., following the timer elapse at 6070), so PDU 6050 will never be sent to the target gNB 110. After handover, the target gNB 110 is configured to wait for a t_ordering delay factor before starting to deliver PDUs to the higher layers. Hence, there is a need to provide timely information to the target gNB about at least some of the PDUs which have been discarded, and / or will never be re-sent to the target gNB.

[0134] Figure 7 is a schematic and simplified diagram of an example message flow illustrating the management of PDCP sequence numbers during the handover according to an embodiment of the disclosure. Figure 7 shows a sequence of PDUs (e.g., PDCP PDUs)11033960W001

[0135] exchanged between a PDCP transmitting entity 502 (e.g., UE 101) and a PDCP receiving entity 503 (e.g., gNB 111).

[0136] The sequence commences when PDU 7010 is sent by the transmitting entity and received by the PDCP receiving entity. This received PDU is delivered to higher layers (e.g., the SDAP layer) of the protocol stack. A second PDU 7020 is sent by the transmitting entity but not received by the receiving entity. This can be due to bad radio link conditions. Lower layers of the protocol stack (e.g., the RLC and MAC layers) perform, if configured, multiple retransmissions of the PDU 7020. While the lower layers handle the retransmission of PDU 7020, the transmitting entity sends a third PDU 7030. The receiving entity receives the PDU 7030 and detects that PDU 7020 is missing because there is a sequence “gap” between PDU 7010 and PDU 7030. The receiving entity stores PDU 7030 and starts a timer (e.g., t_ordering timer). The PDU 7030 will not be delivered to the upper layer (e.g., SDAP layer) until either the PDU 7020 is received or the timer elapses. A subsequent set of PDUs (e.g., PDU 7040 and 7050) are sent by the transmitting entity but not received by the receiving entity. The transmitting entity sends PDU 7060, which is received by the receiving entity. The receiving entity detects the missing PDUs 7040 and 7050 because there is a sequence gap between PDU 7030 and PDU 7060. The receiving entity stores the PDU 7060 while the timer (e.g., t_ordering timer) is already running. The PDU 7060 will not be delivered to the upper layer until the PDUs 7030 is delivered successfully and PDUs 7040 and 7050 are received, or the timer elapses after having been re-initialised when PDU 7030 is delivered.

[0137] In this example, PDUs 7010, 7020, 7030, 7050 are part of a first PDU Set (e.g., PDU Set 1) and PDUs 7040, 7060 are part of a second PDU Set (e.g., PDU Set 2). The PDU Set identification information is known at transmitting side SDAP layer but it is not known at the receiving side.

[0138] According to the above example, the discard timer associated with PDU 7020 is configured to elapse at point 7070 (i.e., shown by the star in Fig. 7). As the timer elapses the UE is configured with pdu-SetDiscard, so the UE discards PDUs 7020 and 7050 because they are part of PDU Set 1. Consequently, the UE sends a SN gap discard notification 7080, indicating two discarded PDUs 7020 and 7050.

[0139] Upon reception of the SN gap report 7080, the receiving entity (e.g., gNB 111) is configured to deliver PDU 7030 to the higher layer of the protocol stack. Further, the receiving entity waits to receive PDU 7040 (i.e., because PDU 7020 has been discarded) before delivering PDU 7060 to the high layer.

[0140] In this example, a handover 7090 is decided by the receiving entity (e.g., source gNB 111) at some point in time after having received the SN gap report 7080. The handover decision will lead to the transmitting entity (e.g., UE 101) being handed over to a (new) receiving entity (e.g., target gNB 110).11033960W001

[0141] In example embodiments, as part of the handover procedure, the source gNB 111 may send a SN status transfer message (see optional method step 7100 in Fig. 7). The SN status transfer message may be configured to conform to specification TS 38.423. The SN status transfer indicates the first missing PDU (e.g., PDU 7040) at the source gNB 111. PDU 7020 is not considered as missing since PDU 7030 has been delivered to the higher layer upon the reception of SN gap report 7080. Optionally, a bitmap is provided indicating the status of the PDUs following PDU 7040. For example, the identifier “01” may be included in the SN status transfer to indicate that PDU 7050 is missing and PDU 7060 has been received.

[0142] According to the present example PDU 7040 is missing, and PDU 7060 is not delivered to the higher layer by the source gNB 111 before the handover. In examples where the PDU 7060 is received by the source gNB 111 (e.g., after handover), then the source gNB may be configured to forward PDU 7060 to the target gNB 110 in an uplink forward message 7110.

[0143] As part of handover procedure, or following the handover procedure, the UE 101 shall assess SN gap condition at the target gNB 110. If a / the SN gap condition at the target gNB 110 is detected then the UE shall send a SN gap report 7120 which is similar to 7080 to the target gNB 110 (e.g., the UE may be configured to re-send 7080). Depending on the assessment method, the UE may instead send SN gap report 7130 which is different from the SN gap report 7080.

[0144] The assessment of SN gap report may include at least one of the following criteria: A. a SN gap report has been sent to the source gNB prior to the handover;

[0145] B. a SN gap report has been sent to the source gNB, but its reception by source gNB is not confirmed prior to the handover; and

[0146] C. a SN gap situation is confirmed at target gNB. For example, if there is no further confirmation before the handover of successful delivery to the source gNB of PDUs sent before the SN gap report, then the same SN gap report may be sent to the target gNB (e.g., 7080). If the reception of all non-discarded PDUs by the source gNB is confirmed before the handover, then the SN gap report may not be sent to the target gNB. If there is confirmation of successful delivery to the source gNB of some PDUs sent before the SN gap report is received before the handover, then a different SN gap report may be sent to the target gNB (e.g., 7130).

[0147] Considering the above-described example, according to the third criteria (i.e. , criteria C), the UE sends SN gap report 7120, reporting discarded PDUs 7020 and 7050, if no confirmation of successful delivery to the source gNB of PDUs 7060, 7040, 7030, 7010 is received before handover 7090. In addition, the UE sends SN gap report 7130, reporting discarded PDU 7050, if confirmation of the successful delivery to the source gNB of PDUs 7010, 7030 is received before handover 7090. Further, the UE does not send any SN gap11033960W001

[0148] report if confirmation of successful delivery to the source gNB of PDlls 7010, 7030, 7050 and 7060 is received before handover 7090.

[0149] Figure 8 is a schematic and simplified diagram illustrating an example message flow for performing Xn handover of a UE according to embodiments of the disclosure. Figure 8 shows a source gNB 8020 (e.g., gNB 111 as shown of Figure 1), a target base station 8030 (e.g., gNB 110), a UE 8100, and the AMF 8040.

[0150] At the beginning of the message flow, the UE 8100 is served by gNB 8020 through a cell (i.e. the serving or source cell) controlled by gNB 8020. Hence, the gNB 8020 may be characterised as a source gNB. The user data in downlink is provided by the 5GC to the source gNB 8020 through a UPF (not represented in Figure 8), then the user data is transmitted to the UE 8100 through a radio bearer. The user data in uplink is similarly transmitted in the opposite direction from the UE to the UPF in the 5GC.

[0151] The source gNB 8020 may have some information related to or associated with the UE 810 (e.g., UE “context information”). For instance, the source gNB 8020 may have been informed, by the UE 8100, at the RRC connection of the UE 8100 to the gNB 8020, with the message RRC setup complete (e.g., as specified in TS 38.331).

[0152] When served by the source gNB 8020, the UE 8100 regularly performs measurement on signals received from the serving cell and one or more target cells (e.g. candidate cells), such as the Signal Synchronization Block (SSB) transmitted in the serving cell and in the target cells. The target cells may be neighbouring cells to the serving or source cell (i.e. the current serving cell).

[0153] Once UE 8100 discovers at least one SSB that meets predefined criteria (for instance a received power that exceeds a predefined threshold), then UE 8100 may send a measurement report 8210 to the source gNB 8020 through a RRC message. The measurements provide radio link quality information for different cells in the vicinity of UE 8100. The identity of each cell is included in the measurement report to allow the source gNB 8020 to identify the gNB(s) controlling the reported cell(s).

[0154] Based on the received measurement report, the source gNB 8020 may detect that UE 8100 receives radio signals in a cell controlled by the target gNB 8030 with a better quality than in the current serving cell controlled by the source gNB 8020. The source gNB 8020 may then decide at step 8200 the handover of UE 8100 to the target gNB 8030.

[0155] The source gNB 8020 may execute a Xn handover when there is a Xn interface between the source gNB 8020 and the target gNB 8030. To trigger the handover, the source gNB 8020, sends a handover request message 8220 to the selected target gNB 8030 including the information related to or associated with the UE 8100 to be handed over. The handover11033960W001

[0156] request message may be the Handover Request message specified in the 3GPP document TS 38.423 section 9.1.1.1, which may in addition include information associated with UE 8100.

[0157] The target gNB 8030 receiving the handover request with the information related to UE 8010 performs the admission control step 8400 to decide whether the request is accepted or not.

[0158] If the target gNB 8030 has rejected the handover request, it sends a Handover Request Failure message (not shown in Figure 8) as defined in TS 38.423 section 8.2.1.3. Upon reception of this message, the source gNB 8020 may consider another cell to hand over the UE 8100.

[0159] If the target gNB 8030 has decided to accept the handover request, the handover procedure can be completed as defined in TS 38.300 section 9.2.3. Briefly, the target gNB 8030 sends a handover request acknowledge message 8230 to the source gNB 8020.

[0160] Then, the source gNB 8020 sends a RRC Reconfiguration message 8240 containing the necessary information for UE 8100 to connect to the target cell, such as radio bearer(s), measurement configuration, (e.g., information previously received by the source gNB 8020 from the target gNB 8030 in the acknowledgment message 8230). In case of conditional handover (CHO), UE 8100 is configured with a triggering condition to fulfil before switching to the target cell. RRC reconfiguration message includes instructions to the UE to perform either a DRB re-establishment or data recovery.

[0161] If UE 8100 is configured with DAPS (Dual Active Protocol Stack), the source gNB 8020 sends the EARLY STATUS TRANSFER message 8245.

[0162] If UE 8100 is not configured with DAPS, the source gNB 8020 sends the SN STATUS TRANSFER message 8245 to the target gNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a PDCP SN yet.

[0163] After switching to the target cell as the new serving cell, UE 8100 performs a randomaccess channel (RACH) procedure 8250 towards the target cell to acquire uplink synchronization.

[0164] Once synchronization is established, if UE 8100 is not configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) DRB, if the RRC reconfiguration message 8240 includes instruction to perform DRB re-establishment, then UE 8100 is configured, as part of the PDCP re-establishment procedure (TS 38.323 clause 5.1.2), to11033960W001

[0165] assess SN gap condition at target gNB 8030. If a SN gap condition at the target gNB is detected then the UE shall send a SN gap report 8255.

[0166] Alternatively, once synchronization is established, if UE 8100 is not configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) DRB, if the RRC reconfiguration message 8240 includes instruction to perform data recovery, then the UE 8100 shall, as part of the PDCP data recovery procedure (TS 38.323 clause 5.5), assess SN gap condition at target gNB 8030. If a / the SN gap condition at target gNB is detected then the UE shall send a SN gap report 8255.

[0167] Alternatively, once synchronization is established, if UE 8100 is configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) or UM (Un-acknowledge mode) DRB, the UE 8100 shall, as part of the uplink data switching procedure (TS 38.323 clause 5.13), assess SN gap condition at target gNB 8030. If a / the SN gap condition at target gNB is detected then the UE shall send a SN gap report 8255.

[0168] Alternatively, once synchronization is established, if the UE PDCP entity is configured as AM (Acknowledge mode) or UM (Un-acknowledge mode) DRB, the UE 8100 shall, as part of the PDCP SN gap report triggering procedure (TS 38.323 clause 5.16), assess SN gap condition at target gNB 8030. If a / the SN gap condition at target gNB is detected then the UE shall send a SN gap report 8255.

[0169] The assessment of SN gap report include at least one of the following criteria:

[0170] A. a SN gap report has been sent to the source gNB prior to the handover;

[0171] B. a SN gap report has been sent to the source gNB, but its reception by source gNB is not confirmed prior to the handover; and

[0172] C. a SN gap situation is confirmed at target gNB. For example, if there are no further confirmation before the handover of successful delivery to the source gNB of PDUs sent before the SN gap report, then the same SN gap report may be sent to the target gNB. If the reception of all non-discarded PDUs by the source gNB is confirmed before the handover, then the SN gap report may not be sent to the target gNB. If there is confirmation of successful delivery to the source gNB of some PDUs sent before the SN gap report received before the handover, then a different SN gap report may be sent to the target gNB.

[0173] The UE 8100 sends a RRC Reconfiguration Complete message 8260 to the target gNB 8030, which is now the new source or serving gNB for UE 8100.

[0174] In case of DAPS handover, the source gNB 8020 sends the SN STATUS TRANSFER message 8265 for DRBs configured with DAPS for which the description in step 8245 applies, and the normal data forwarding follows as defined in TS 38.300 clause 9.2.3.2.3.

[0175] In the meantime, the target gNB 8030 may perform the path switch handshake procedure toward UE AMF 8040, with the exchange of Path Switch Request message 8270 and Path Switch Request Acknowledge 8280. It can be noted that the target gNB 8030 knows11033960W001

[0176] the AMF of the UE 8100 as the ID of this AMF is included in the Handover Request message 8220. Then, the control and user data associated with the UE 8100 will transit through the target gNB 8030 and no more through the source gNB 8020.

[0177] During HO preparation (e.g., between handover request and handover acknowledge), U-plane tunnels can be established between the source gNB and the target gNB;

[0178] During HO execution (up to Path switch request), user data can be forwarded from the source gNB to the target gNB through U-plane tunnels (e.g., as indicated by the PDU forward messages 6110 and 7110 as shown in Figures 6 and 7, respectively).

[0179] Finally, the target gNB 8030 sends a UE Context Release message 8290 to the source gNB 8020, to indicate that the handover procedure is completed, and that the source gNB 8020 can delete the stored context information related to the UE 8100.

[0180] In Figure 8, the messages 8220, 8230, 8290 may correspond to the messages with the same name described in TS 38.423, the messages 8210, 8240, 8280 may correspond to the messages with the same name described in TS 38.331, the messages 8270, 8280 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 8250 may correspond to the RACH procedure described in TS 38.321.

[0181] Figure 9 is a schematic and simplified diagram illustrating an example message flow for performing the NG handover of a UE according to embodiments of the disclosure. Figure 9 shows a source gNB 9020 (e.g., gNB 111 as shown of Figure 1), a target base station 9030 (e.g., gNB 110), a UE 9100, and an AMF 9040.

[0182] The beginning of the message flow is similar to the message flow described above with reference to Figure 8. UE 9100 is served by the source gNB 9020 through a cell (e.g., a serving or source cell) controlled by source gNB 9020. UE 9100 regularly performs measurement on signals received at UE 9100 from the serving cell and one or more target cells (e.g. neighbouring candidate cells).

[0183] Based on the received measurement reports, the source gNB 9020 may detect that UE 9100 receives radio signals in a cell controlled by the target gNB 9030 with a better quality than in the current serving cell controlled by the source gNB 9020. The source gNB 9020 may then decide at step 9200 the handover of the UE 9100.

[0184] The source gNB 9020 may execute a NG handover, for instance when there is no Xn interface between the source gNB 9020 and the target gNB 9030. To trigger the handover, the source gNB 9020, sends a handover required message 9220 to AMF 9040 indicating the target cell for the handover (and thus indicating the selected target gNB 9030). Then the AMF 9040 sends a Handover Request message 9230 to the target gNB 9030 including the information related to or associated with UE 9100 to be handed over.11033960W001

[0185] The target gNB 9030 receiving the handover request with the information related to the UE 9100 performs the admission control step 9400 (e.g., similar to method step 8400 of Figure 8), to decide whether the request is accepted or not.

[0186] If the target gNB 9030 has rejected the handover request, it sends a Handover Failure message (not shown in Figure 9) as defined in TS 38.413 section 9.2.3.6. A Cause IE indicates the reason of rejection. Upon reception of this message, the AMF 9040 sends to the source gNB 9020 a Handover Preparation Failure (not shown in Figure 9) as defined in TS 38.413 section 9.2.3.3, and the source gNB 9020 may consider another cell to hand over UE 9100. The Cause IE in the Handover Preparation Failure message corresponds to the Cause IE in the Handover Failure message. The value of the Cause IE may be set to a value as discussed above with respect to the Handover Request Failure message.

[0187] If the target gNB 9030 has decided to accept the handover request, the handover procedure can be completed. Briefly, the target gNB 9030 sends a handover request acknowledge message 9240 to AMF 9040. Then, AMF 9040 sends a Handover Command message 9250 to the source gNB 9020. Then, the source gNB 9020 sends a RRC Reconfiguration message 9260 containing the necessary information for UE 9100 to connect to the target cell, such as radio bearer(s), measurement configuration, (information previously received by the source gNB 9020 from the target gNB 9030 via the acknowledgment message 9240 and the Handover Command message 9250). In case of conditional handover (CHO), UE 9100 is configured with a triggering condition to fulfil before switching to the target cell. The RRC reconfiguration message includes instructions to the UE to perform either a DRB reestablishment or data recovery.

[0188] If UE 9100 is configured with DAPS (Dual Active Protocol Stack), the source gNB 9020 sends the UPLINK RAN EARLY STATUS TRANSFER message 9265. The AMF 9040 sends back the content to the target gNB in the DOWNLINK RAN EARLY STATUS TRANSFER message 9267.

[0189] If UE 9100 is not configured with DAPS, the source gNB 9020 sends the UPLINK RAN STATUS TRANSFER message 9265 to the AMF 9040 to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs for which PDCP status preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL PDCP SDU and may include a bit map of the receive status of the out of sequence UL PDCP SDUs that the UE needs to retransmit in the target cell, if any. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target gNB shall assign to new PDCP SDUs, not having a PDCP SN yet. The AMF 9040 sends back the content to the target gNB in the DOWNLINK RAN STATUS TRANSFER message 9267.11033960W001

[0190] After switching to the target cell as the new serving cell, the UE 9100 performs a randomaccess channel (RACH) procedure 9270 towards the target cell to acquire uplink synchronization.

[0191] Once synchronization is established, if UE 9100 is not configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) DRB, if the RRC reconfiguration message 9260 includes instruction to perform DRB re-establishment, the UE 9100 shall, as part of the PDCP re-establishment procedure (TS 38.323 clause 5.1.2), assess SN gap condition at target gNB 9030. If a SN gap condition at the target gNB is detected then the UE shall send a SN gap report 9275.

[0192] Alternatively, once synchronization is established, if UE 9100 is not configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) DRB, if the RRC reconfiguration message 9260 includes instruction to perform data recovery, the UE 9100 shall, as part of the PDCP data recovery procedure (TS 38.323 clause 5.5), assess SN gap condition at target gNB 9030. If a SN gap condition at the target gNB is detected then the UE shall send a SN gap report 9275.

[0193] Alternatively, once synchronization is established, if UE 9100 is configured with DAPS, if the UE PDCP entity is configured as AM (Acknowledge mode) or UM (Un-acknowledge mode) DRB, the UE 9100 shall, as part of the PDCP uplink data switching procedure (TS 38.323 clause 5.13), assess SN gap condition at target gNB 9030. If a SN gap condition at the target gNB is detected then the UE shall send a SN gap report 9275.

[0194] Alternatively, once synchronization is established, if the UE PDCP entity is configured as AM (Acknowledge mode) or UM (Un-acknowledge mode) DRB, the UE 9100 shall, as part of the PDCP SN gap report triggering procedure (TS 38.323 clause 5.16) assess SN gap condition at the target gNB 9030. If a SN gap condition at the target gNB is detected then the UE shall send a SN gap report 9275.

[0195] The assessment of SN gap report may comprise at least one of the following criteria: A. a SN gap report has been sent to the source gNB prior to the handover;

[0196] B. a SN gap report has been sent to the source gNB, but its reception by the source gNB is not confirmed prior to the handover; and

[0197] C. a SN gap situation is confirmed at the target gNB. For example, if there are no further confirmation before the handover of successful delivery to the source gNB of PDUs sent before the SN gap report, then the same SN gap report may be sent to the target gNB. If the reception of all non-discarded PDUs by the source gNB is confirmed before the handover, then the SN gap report may not be sent to the target gNB. If there is confirmation of successful delivery to the source gNB of some PDUs sent before the SN gap report received before the handover, then a different SN gap report may be sent to the target gNB.11033960W001

[0198] The UE 9100 sends a RRC Reconfiguration Complete message 9280 to the target gNB 9030, which is now the new source or serving gNB for the UE 9100.

[0199] The target gNB 9030 can then send a Handover Notify message 9290 to the AMF 9040 to indicate that the handover procedure is completed.

[0200] If UE 9100 is configured with DAPS (Dual Active Protocol Stack), the source gNB 9020 sends the UPLINK RAN STATUS TRANSFER message 9310. The AMF 9040 sends back the content to the target gNB in the DOWNLINK RAN STATUS TRANSFER message 9315.

[0201] During HO preparation (between handover request and handover acknowledge), U-plane tunnels can be established between the source gNB and the target gNB;

[0202] During HO execution (i.e. , up to UE context release), user data can be forwarded from the source gNB to the target gNB through U-plane tunnels (e.g., PDU forward 6110 and 7110 of Figures 6 and 7);

[0203] Finally, the UE 9100 sends a UE Context Release Command message 9330 to the source gNB 9020, to indicate that the handover procedure is completed, and that the source gNB 9020 can delete the stored context information related to the UE 9100. The source gNB 9020 may send a UE Context Release Complete message 9320 to the AMF 9040 to acknowledge this operation.

[0204] In embodiments, the target gNB 9030 does not need to execute the path switch handshake procedure toward the AMF 9040, as the AMF 9040 already knows the target gNB 9030 as the new serving gNB for the UE 9100.

[0205] In Figure 9, the messages 9210, 9260, 9280 may correspond to the messages with the same name described in TS 38.331, the messages 9220, 9230, 9240, 9250, 9290, 9330, 9320 may correspond to the messages with the same name described in TS 38.413, and the RACH procedure 9270 may correspond to the RACH procedure described in TS 38.321.

[0206] Figure 10 is a schematic and simplified diagram illustrating a control method according to a first embodiment of the disclosure. The control method is performed as part of a PDCP, re-establishment procedure (e.g., between UE 101 and the target gNB 110, as shown in Figure 1). For example, the re-establishment procedure may include (as shown by optional method step 1010) the source gNB 111 sending a RRC reconfigure message to the UE 101. At method step 1020 the user equipment is configured, following the detection of a SN gap relating to data transmitted by the UE 101, to transmit to the target gNB 110 an indication (e.g., a SN gap report) of the detected SN gap.

[0207] Figure 11 is a schematic and simplified diagram illustrating a control method according to a second embodiment of the disclosure. The control method is performed as part of a PDCP, re-establishment procedure. For example, the re-establishment procedure may include (as11033960W001

[0208] shown by the optional method step 1110) the source gNB 111 sending a RRC reconfigure message to the UE 101. The method proceeds with step 1120, the UE checks whether a prior SN gap indication (e.g., a SN gap report) sent by the UE to the source gNB has been received by the source gNB. The check is possible if the UE PDCP transmitting side is configured in AM mode (Acknowledge mode). If the reception of the prior SN gap report by the source gNB is confirmed (yes at 1120), then at method step 1130 the source gNB 111 sends the prior SN gap report to the target gNB 110. If the reception of the prior SN gap report by the source gNB is not confirmed (no at 1120), then at method step 1140 the UE sends the prior SN gap report to the target gNB 110.

[0209] According to each of the control methods described in Figures 10 and 11, the optional RRC reconfigure message may result from a handover procedure (e.g., Xn or NG, DAPS, or non-DAPS).

[0210] While the present disclosure has been described with reference to examples and embodiments, it is to be understood that the disclosure is not limited to the disclosed examples and embodiments. It will be appreciated by those skilled in the art that various changes and modification might be made without departing from the scope of the disclosure, as defined in the appended claims. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent, or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0211] In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

[0212] In the preceding embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.

[0213] Computer-readable media may include computer-readable storage media, which corresponds to a tangible medium such as data storage media, or communication media including any medium that facilitates transfer of a computer program from one place to another, e.g., according to a communication protocol. In this manner, computer-readable media11033960W001

[0214] generally may correspond to (1) tangible computer-readable storage media which is non-transitory or (2) a communication medium such as a signal or carrier wave. Data storage media may be any available media that can be accessed by one or more computers or one or more processors to retrieve instructions, code, and / or data structures for implementation of the techniques described in this disclosure. A computer program product may include a computer-readable medium.

[0215] By way of example, and not limitation, such computer-readable storage media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection is properly termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a coaxial cable, fibre optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fibre optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave may be included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Claims

11033960W001CLAIMS1. A method for managing data transmission, as part of a packet data convergence protocol, PDCP, re-establishment procedure, between a user equipment and a target base station of a wireless communication network, the method at the user equipment comprising:following the detection of a sequence number gap relating to data transmitted by the user equipment, transmitting to the target base station an indication of the detected sequence number gap.

2. The method of claim 1, wherein the indication of the sequence number gap is transmitted directly from the user equipment to the target base station.

3. The method of claim 1 or claim 2, wherein the indication of the detected sequence number gap comprises a sequence number gap report.

4. The method of any one of claims 1 to 3, wherein the sequence number gap is detected before, or during, the re-establishment procedure.

5. The method of any one of the preceding claims, wherein the sequence number gap indication comprises a mapping indication.

6. The method of claim 5, wherein the sequence number gap indication comprises a bitmap for indicating the status of the transmissible data.

7. The method of any one of the preceding claims, wherein the re-establishment procedure is performed as part of, or following, a handover of the user equipment from a source base station to the target base station, wherein the sequence number gap is detected based on at least one of the following detection criteria:whether a sequence number gap indication has been transmitted to the source base station before the handover;whether a sequence number gap indication has been transmitted to the source base station, but its reception is not confirmed before the handover; andwhether a sequence number gap has been confirmed at the target base station.

8. The method of claim 7, wherein the sequence number gap indication is configured based on at least one of the detection criteria.2811033960W0019. The method of claim 7 or claim 8, wherein the method further comprises:following the detection of a sequence number gap relating to data transmitted to the source base station, transmitting to the source base station an initial indication relating to the detected sequence number gap.

10. The method of claim 9, wherein, if following the transmission of the initial sequence number gap indication the reception of the data is not confirmed, then the sequence number gap indication transmitted to the target base station is configured to be the same as the initial sequence number gap indication.

11. The method of claim 9, wherein, if following the transmission of the initial sequence number gap indication the reception of at least part of the data is confirmed, then the sequence number gap indication transmitted to the target base station is configured to be different to the initial sequence number gap indication.

12. The method of any one of claims 9 to 11 , wherein the sequence number gap indication is transmitted to the target base station if the initial indication is not received by the source base station.

13. The method of any one of claims 9 to 12, wherein:if the initial sequence number gap indication is not received by the source base station, then the method at the user equipment comprises transmitting the sequence number gap indication to the target base station; andif the initial sequence number gap indication is received by the source base station, then the method at the source base station comprises transmitting the initial sequence number gap indication to the target base station.

14. The method of any one of the preceding claims, wherein the method is performed as part of a PDCP data recovery procedure.

15. The method of any one of claims 1 to 14, wherein the method is performed as part of a dual active protocol stack procedure.

16. The method of claim 15, wherein the method is performed during an uplink data switching procedure.11033960W00117. The method of any one of the claims 1 to 14, wherein the method is performed as part of a sequence number GAP report triggering procedure.

18. The method of any one of the preceding claims, wherein the sequence number gap of the data transmitted by the user equipment is detected in accordance with at least one of the following criteria:at least one data unit, SDU, of the transmitted data is discarded;at least one SDU of the transmitted data is associated with a count value larger than a count value associated to the at least one discarded SDU; andthe at least one discarded SDU has not been submitted to a lower layer of the protocol stack.

19. The method of claim 18, wherein the at least one discarded SDU is indicative that at least one protocol data unit, PDU, Set of the transmitted data has not been fully received by a base station of the wireless communication network.

20. A user equipment apparatus comprising a transmitter configured to perform the method of any one of claims 1 to 19.

21. A communication network which comprises the apparatus of claim 20.

22. A computer program comprising instructions which, when the program is executed by a transmitter, causes the transmitter to carry out the method according to any one of claims 1 to 19.

23. A computer-readable medium carrying a computer program according to claim 22.