RRC Re - establishment

Abstract

In an exemplary aspect, a method is provided in a user equipment (UE) for performing an RRC re-establishment procedure, the method including receiving an instruction to perform an RRC re-establishment procedure from a network node and transmitting an RRC re-establishment request.

Description

[Technical field]

[0001] Examples of the present disclosure relate to RRC re-establishment, such as, for example, a UE performing an RRC re-establishment procedure or instructing a UE to perform an RRC re-establishment procedure. [Background technology]

[0002] Fifth generation (5G) New Radio (NR) cellular communication systems aim to support Ultra-Reliable Low Latency Communications (URLLC). Example URLLC features include PDCP duplication functionality to increase reliability, as well as make-before-break handover procedures to ensure minimal interruption time during handovers where a UE switches from one cell or beam to another.

[0003] It is expected that the general deployment of 5G NR systems will utilize cloud infrastructure to support 5G core network and upper radio access network (RAN) functions, such as 3GPP-specified gNodeB-Central Unit-Control Plane (gNB-CU-CP) functions in the future. Cloud infrastructure differs in reliability from the generic, dedicated or specialized hardware that has traditionally been used to support cellular network functions. One such difference is the availability of the underlying hardware, which can be significantly less reliable for general-purpose off-the-shelf cloud hardware compared to traditional dedicated hardware. Thus, cloud deployment of communication functions may introduce mechanisms to address failures of the cloud infrastructure. An example of such a mechanism includes using a distributed database to provide persistent storage even in the event of failure of one or more hardware nodes supporting this database.

[0004] A method for ensuring a reliable connection to a UE using URLLC may include setting up parallel user plane connections to the same UE, such that if one of the user plane connections is lost, it may be possible to continue data transmission via the other connection. Multiple user plane connections may be supported either using a single control plane connection (e.g., RRC, NAS connection) or with two independent control plane connections, which requires the device to have dual-radio capability and be able to set up two independent radio connections, which generally increases the cost of the UE. The latter solution also increases network complexity, as the network would need to both understand that two control plane connections are involved and ensure that these devices are directed to use different network resources to avoid a single point of failure.

[0005] FIG. 1 illustrates an example scenario 100 for end-to-end redundant user plane paths using dual connectivity. For example, FIG. 1 illustrates a user plane resource configuration for dual PDU sessions when redundancy is applied. One protocol data unit (PDU) session 102 spans from the UE through a master NG-RAN node to a first user plane function (UPF1) acting as a PDU session anchor, and the other PDU session 104 spans from the UE through a secondary NG-RAN node to a UPF2 acting as a PDU session anchor. As described in 3GPP Technical Specification (TS) 37.340, which is incorporated herein by reference, the NG-RAN may implement redundant user plane resources for two PDU sessions with two NG-RAN nodes (i.e., the master NG-RAN and secondary NG-RAN shown in FIG. 1) or a single NG-RAN node. In both cases, there is a single N2 interface from the master NG-RAN node towards the AMF.

[0006] Based on these two PDU sessions 102 and 104, two independent user plane paths are set up. UPF1 and UPF2 connect to the same data network (DN), but traffic over UPF1 and UPF2 may be routed through different user plane nodes within the DN.

[0007] The 5G RAN architecture 200 is described in 3GPP TS38.401, which is incorporated herein by reference, and is shown in Figure 2. The NG architecture may be further described as follows. · NG-RAN consists of a set of gNBs connected to 5GC through an NG interface. The gNB can support FDD, TDD or dual mode operation. · gNBs can be interconnected through the Xn interface. A gNB may consist of a gNB-CU (Central Unit) and one or more gNB-DUs (Distributed Units). The gNB-CU and gNB-DU are connected via the F1 logical interface. A gNB-DU is connected to only one gNB-CU.

[0008] NG, Xn and F1 are logical interfaces. In the case of NG-RAN, the NG and Xn-C interfaces for the gNB, consisting of the gNB-CU and gNB-DU, terminate at the gNB-CU. In the case of E-UTRAN New Radio Dual Connectivity (EN-DC), the S1-U and X2-C interfaces for the gNB, consisting of the gNB-CU and gNB-DU, terminate at the gNB-CU. The gNB-CU and connected gNB-DU only appear as a gNB to other gNBs and the core network (5GC).

[0009] The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e., the NG-RAN logical nodes and the interfaces between the NG-RAN logical nodes, are specified as part of the RNL. At each NG-RAN interface (NG, Xn, F1), the relevant TNL protocols and functions are specified. The TNL provides services for user plane transport and signaling transport. In an NG-Flex configuration, each gNB is connected to all Access and Mobility Functions (AMFs) within an AMF domain. The AMF domain is specified in 3GPP TS 23.501, which is incorporated herein by reference.

[0010] An open interface was specified between the control plane (CU-CP) and user plane (CU-UP) parts of the central unit (CU). The relevant specification is 3GPP TS 38.463, which is incorporated herein by reference. The open interface between the CU-CP and CU-UP is called E1. The architecture is shown in FIG. 3, which shows a split gNB architecture. Three deployment scenarios for split gNB are shown in 3GPP Technical Report (TR) 38.806, which is incorporated herein by reference. - Scenario 1: Centralized CU-CP and CU-UP, - Scenario 2: Distributed CU-CP and centralized CU-UP, - Scenario 3: Centralized CU-CP and distributed CU-UP.

[0011] The E1 Application Protocol (E1AP) is defined in TS 38.463. The E1AP defines messages exchanged between the CU-CP and the CU-UP to provide user plane services to the UE.

[0012] In LTE and NR, the Radio Resource Control (RRC) protocol is used to set up, configure and maintain the radio connection between the UE and the eNB or gNB. When the UE receives an RRC message from the eNB or gNB, the UE applies or compiles the configuration and, if this is successful, the UE generates an RRC Complete message indicating the transaction ID of the message that triggered this response.

[0013] Since LTE Release 8 (rel-8), three signaling radio bearers (SRBs), namely SRB0, SRB1 and SRB2, have been available for transport of RRC messages and Non-Access Stratum (NAS) messages between the UE and the eNB. A new SRB, known as SRB1bis, was also introduced in rel-13 to support Data over NAS (DoNAS) in Narrowband Internet of Things (NB-IoT). SRB0 is for RRC messages using the CCCH logical channel and is used to handle RRC connection setup, RRC connection resumption and RRC connection re-establishment. Once the UE is connected to the eNB (i.e. RRC connection setup or RRC connection re-establishment / resumption is successful), SRB1 is used to handle RRC messages (which may include piggybacked NAS messages), all using the DCCH logical channel, as well as for NAS messages prior to the establishment of SRB2. SRB2 is for RRC messages including logged measurement information, as well as for NAS messages, all using the DCCH logical channel. SRB2 has a lower priority than SRB1 because logged measurement information and NAS messages may be long and may cause blocking of more urgent and smaller SRB1 messages. SRB2 is always configured by E-UTRAN after security activation.

[0014] In rel-15, in case of dual connectivity (LTE as master node, while NR as secondary node or vice versa, as well as dual connectivity using two NR nodes), split SRB is introduced, where SRB1 / 2 can be transported over radio resources of master node or secondary node (protocol is terminated in the master node). Additionally, a new SRB called SRB3 is introduced (when secondary node is NR), which is used to forward RRC messages directly from secondary node to UE for messages that do not require coordination with the master node.

[0015] Most of the RRC procedures are initiated by the network to reconfigure some behavior of the UE, e.g., measurement reporting configuration, lower layer configuration, radio bearer configuration, etc. Typically, the UE acknowledges the RRC message from the network with an RRC reply message indicating that the new configuration has been adopted. Also, some RRC procedures are initiated by the UE, such as the following: - Measurement reporting (e.g. used for UE mobility) - RRC re-establishment in case of connection failure - Initial RRC connection setup (e.g. when the UE is in idle mode and needs to transition to a connection)

[0016] RRC relies on the PDCP / RLC / MAC protocol to ensure lossless, in-order, duplication-free delivery of RRC messages. In-order delivery is guaranteed by the PDCP sequence number, which means that PDCP will deliver an RRC message (e.g., deliver it later up the PDCP layer) only if the RRC message has a PDCP sequence number that is the next expected PDCP sequence number (i.e., the number is one greater than the PDCP sequence number of the last delivered message). This means that if the network loses knowledge of the next PDCP sequence number expected by the UE, the network will not be able to send any RRC messages to the UE, since if the network does not correctly guess the exact sequence number, the message will not be delivered by the PDCP layer in the UE to the upper layers (e.g., the RRC layer) in the UE.

[0017] In addition to the RRC protocol, the UE is also controlled by the NAS protocol between the UE and the core network, which is delivered embedded within the RRC messages.

[0018] FIG. 4 shows an example of a control plane (CP) protocol stack 400 in NR, and FIG. 5 shows an example of a user plane (UP) protocol stack 500 in NR, where a CU / DU split architecture is adopted (where the CU is also split into CU-UP and CU-CP). Note that the CU-CP / CU-UP split is a functional split, and thus the two functions can be present either in the same node or in different nodes, and furthermore, one of the functions, i.e., CU-UP or CU-CP, can be physically realized in several physical nodes / entities for a given gNB and can be physically distributed. For example, several instances of CU-UP / CU-CP for a given gNB can be present in an operator's cloud for redundancy purposes or load balancing purposes.

[0019] If the connection with the UE fails, for example due to radio link failure, handover failure (T304 timer expiry) or inability to match RRC messages, integrity verification failure, etc., the UE will initiate an RRC re-establishment procedure. In NR, this is captured in TS 38.331, which is incorporated herein by reference, in section 5.3.7. FIG. 6 shows an example of an RRC connection re-establishment (successful) procedure 600, and FIG. 7 shows an example of an RRC re-establishment (successful) procedure 700 with fallback to RRC establishment. The purpose of the re-establishment procedure is to re-establish the RRC connection. A UE in RRC_CONNECTED state with AS security activated with SRB2 and at least one DRB setup may initiate an RRC re-connection procedure to continue the RRC connection. If the network is able to find and verify a valid UE context for the UE, the connection re-establishment is successful, or if the UE context cannot be retrieved, the network responds with an RRC setup message, for example as shown in FIG. 7.

[0020] The network applies the procedure, for example, as follows: When AS security is activated and the network retrieves or verifies the UE context, - Reactivate AS security without changing the algorithm, - Re-establish and restart SRB1, When the UE is re-establishing an RRC connection and the network is not able to retrieve or verify the UE context; - Discard the stored AS context and release all RBs; - Fall back to establishing a new RRC connection.

[0021] If AS security was not activated, the UE shall not initiate the procedure and instead move directly to RRC_IDLE state with release cause "other". If AS security is activated but SRB2 and at least one DRB are not set up, the UE shall not initiate the procedure and instead move directly to RRC_IDLE with release cause "RRC connection failed".

[0022] The UE may re-establish to a different node than the one to which the UE was connected before detecting the problem. When the target network node receives an RRC re-establishment request message (e.g., as shown in FIG. 6 or FIG. 7), the target network node may use the ReestabUE identity information included in the request message to attempt to identify the old UE context for the UE. If the target network node can identify the context, it may send an RRC re-establishment message to the UE, and the UE will restore the old configuration. If the target network node cannot find the UE context, it must perform NAS recovery and instead send an RRC setup message to the UE, as shown in FIG. 7.

[0023] The target network node will send a UE context retrieval request (as specified in TS 38.423 / 36.423, which are incorporated herein by reference) to the source node, i.e., the node to which the UE was connected before the connection failure, and the source node can respond with a UE context retrieval response (if UE identification and verification was successful). If successful, the UE context retrieval response will include a handover preparation information message, as specified in TS 38.331, which contains the UE context. Once the UE receives the RRC re-establishment message, restores some settings (e.g. SRB1) and re-establishes the connection, the UE will send an RRC re-establishment complete message to the network. The network will then send an RRC re-configuration message to the UE, and the UE will restore and possibly re-configure the rest of the settings in the UE.

[0024] In the context of CU / DU split, the re-establishment procedure is shown in Figure 8 (from TS38.401, section 8.7), which shows an example of an RRC re-establishment procedure 800 for a CU / DU split architecture. The steps in this procedure are as follows: 1. The UE sends a preamble to the gNB-DU. 2. The gNB-DU allocates a new C-RNTI and responds with a Random Access Response (RAR) to the UE. 3. The UE sends an RRC re-establishment request message including the old C-RNTI and the old physical cell ID (PCI) to the gNB-DU. 4. The gNB-DU forwards the RRC message and the corresponding lower layer configuration for the UE in an initial UL RRC message forwarding message to the gNB-CU. The initial UL RRC message forwarding message should include the C-RNTI. 5. The gNB-CU includes the RRC re-establishment message and forwards it to the gNB-DU. If the UE requests to re-establish the RRC connection in the last serving gNB-DU, the DL RRC message forwarding message shall include the old gNB-DU UE F1AP ID. 6. The gNB-DU retrieves the UE context based on the old gNB-DU UE F1AP ID and replaces the old C-RNTI / PCI with the new C-RNTI / PCI. The gNB-DU sends an RRC re-establishment message to the UE. 7-8. The UE sends an RRC re-establishment complete message to the gNB-DU. The gNB-DU encapsulates the RRC message in a UL RRC message transfer message and sends it to the gNB-CU. 9-10. The gNB-CU triggers the UE context modification procedure by sending a UE context modification request, which may include a list of DRBs to be modified and released. The gNB-DU responds with a UE context modification response message. 9'-10'. The gNB-DU triggers the UE context modification procedure by sending a UE context modification required, which may include a list of DRBs to be modified and released. The gNB-CU responds with a UE context modification confirm message. NOTE: Here, it is assumed that the UE accesses from the original gNB-DU, for which the UE context is available for that UE, and either steps 9 to 10 or steps 9' and 10' may be present, or both may be skipped. NOTE: If the UE accesses from a gNB-DU other than the original gNB-DU, the gNB-CU should trigger the UE context setup procedure towards this new gNB-DU. 11-12. The gNB-CU includes the RRC reconfiguration message in a DL RRC message transfer message and transfers it to the gNB-DU. The gNB-DU forwards it to the UE. 13-14. The UE sends an RRC reconfiguration complete message to the gNB-DU, and the gNB-DU forwards the RRC reconfiguration complete message to the gNB-CU.

[0025] The signaling radio bearer (SRB) used for delivery of RRC messages provides lossless, duplication-free, in-order delivery of RRC messages. It is the responsibility of the PDCP layer to guarantee in-order and duplication-free delivery to the layer(s) above it. The PDCP layer does this by assigning a PDCP sequence number to every message. The sequence number is transported in the PDCP header of the PDCP message. If the PDCP sequence number of the packet containing the RRC message is the next expected PDCP sequence number (which is the last used PDCP sequence number +1), the receiving PDCP entity (e.g. in the UE) will simply deliver the RRC message in a PDCP packet to the RRC layer. If the network uses a PDCP sequence number that is smaller than the last used PDCP sequence number before the failure, the UE will consider the packet a duplicate and will discard the packet. If the network uses a PDCP sequence number that is larger than the next expected PDCP sequence number at the UE, the UE will store the message in the PDCP layer and wait for the missing packet(s) with the missing sequence number(s). For example, if the last received RRC message before a CP failure was in a PDCP packet with sequence number (SN) x, and an RRC message is received with SNx+2, the PDCP layer will wait for a PDCP packet with SNx+1 before forwarding the RRC message in a PDCP packet with SNx+2 to the RRC layer. That is, if the packet with SNx+1 is not received, the packet with SNx+2 will be stored indefinitely in the UE and its contents will not be delivered to higher layers. Because PDCP sequence numbers wrap around, the decision of whether an out-of-order packet is a duplicate or a future out-of-order packet is based on whether the packet is within or outside the PDCP receive window.

[0026] During initiation of the re-establishment procedure (according to section 5.3.7.2 of TS 38.331), the UE shall: - Reset the MAC (i.e. any pending data at the MAC level will be flushed) - Both Carrier Aggregation (CA) and Dual Connectivity (DC) will be released - All DRBs and SRBs (except SRB0, which is used to send re-establishment messages) are aborted.

[0027] The UE then starts timer T311 and performs cell reselection, which may select the same primary cell to which the UE was previously connected, or another cell. If the timer expires before a suitable cell is found, NAS recovery must be performed via idle mode. If a suitable cell is found, the UE applies default MAC and control channel configuration, starts timer T301, and sends an RRC re-establishment request message (including the UE identity, a security checksum called short MAC-I, calculated using the old RRC integrity that the UE used before the re-establishment was triggered, and a re-establishment cause, which may take one of the following values: radio link failure, re-establishment failure, handover failure, or other failure) to the selected cell. If timer T301 expires before the UE receives an RRC re-establishment message from the network, the UE must perform NAS recovery via idle mode.

[0028] Upon receiving an RRC re-establishment message containing the NCC (Next Hop Chaining Count), the UE uses the NCC value to derive new user plane and control plane ciphering and integrity protection keys to be used for the connection, including for verifying the integrity of the received re-establishment message. The network always sends an RRC re-configuration message (called "First Re-configuration after Re-establishment" in the specification) after the re-establishment message. This re-configuration message contains the complete configuration flag, thus resetting the entire radio configuration (except for the C-RNTI and the access stratum security configuration associated with the master key) and replacing it with a new radio configuration. Additionally, a reestablishPDCP field will be included for each SRB / DRB, which will re-establish the PDCP entity of each SRB / DRB. A PDCP re-establishment will result in the re-configuration of the PDCP entity to use the new ciphering and integrity protection keys calculated upon receipt of the re-establishment message, and for the sending PDCP entity, to send pending PDCP packets after protecting them with the new keys (here "pending" means those packets already sent, protected using the old security key, but for which no acknowledgement of their receipt was received). Also, in case of SRB, a PDCP re-establishment will imply a reset of sequence numbers to their initial values.

[0029] The main reason for the use of NCC and security key updates is that, from a security point of view, it should be avoided to reuse the same sequence number (Count) and security key for different data, which would otherwise occur during re-establishment since the sequence number of the SRB is reset. This is because the ciphering principle in 3GPP networks (shown in Figure D2.1.1-1 in 3GPP TS33.501, incorporated herein by reference) is based on exclusive-oring the data (plaintext blocks) with a security bitstream (keystream block) generated by a ciphering algorithm based on the key, sequence number, etc. It may be possible to remove this security bitstream by exclusive-oring two messages encrypted with the same bitstream. The remaining bits are then simply the exclusive-or (XOR) of the two original messages. Therefore, if an attacker is able to guess one of the messages, it will automatically be possible to decrypt the other messages as well. D2.1.1-1 of 3GPP TS33.501 is shown in Figure 9.

[0030] The RRC connection re-establishment procedure may be used to resynchronize the network and the UE. However, it always leads to a user plane reset, which means, for example, that the user plane data radio bearers (DRBs) are interrupted and packets in the lower layer state machines (e.g. RLC / MAC) are flushed. Studies have shown that a typical RRC connection re-establishment procedure will cause a user plane service interruption of 100 ms or more. This may be significantly longer in practice, since the re-establishment is also controlled by several timers with configurable values ​​(e.g. T310, initiated upon detecting a physical layer problem, may be up to 2 seconds long, and the UE will not initiate the re-establishment procedure until this timer expires). In general, this is not an issue for a regular Mobile Broadband (MBB) user or other users, since the overall performance of the connection is not significantly affected by such a service interruption. However, for connections requiring URLLC, this service interruption may mean that URLLC requirements, such as, for example, latency and / or reliability, are not met.

[0031] In URLLC communication, survival time is the time that an application consuming URLLC communication service can go on without an expected message. If communication service recovery (e.g., RRC re-establishment) is not completed before the survival time expires, the end user application may consider the communication service unavailable and may, for example, begin to take emergency actions to recover. Survival time also imposes a limit on the tolerable user plane interruption time (e.g., in UE mobility). Survival time is an important requirement because it imposes a limit on how fast a system needs to recover from a failure to avoid application downtime. If the recovery time after a communication failure is shorter than the survival time, the failure may be overlooked by the application. Examples of use cases with strict survival time include public safety drones, which may have a survival time of around 100 ms, and industrial automation use cases, where the traffic is cyclical, with frequent small packets, and typically uses industrial Ethernet. Survival time in these cases may tolerate the loss of a single packet or a few consecutive packets. For example, motion control has a duration of 0-2 ms, PLC-to-PLC communication 8-48 ms, and automated guided vehicles (AGVs) 40-500 ms. Summary of the Invention

[0032] One aspect of the present disclosure provides a method in a user equipment (UE) for performing an RRC re-establishment procedure, the method including receiving an instruction to perform an RRC re-establishment procedure from a network node and sending an RRC re-establishment request.

[0033] Another aspect of the present disclosure provides a method in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure, the method including determining that a first base station control plane function associated with the UE is unavailable and sending an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function.

[0034] A further aspect of the present disclosure provides an apparatus in a user equipment (UE) for performing an RRC re-establishment procedure, the apparatus comprising a processor and a memory, the memory including instructions executable by the processor such that the apparatus is operable to receive an instruction from a network node to perform an RRC re-establishment procedure and to transmit an RRC re-establishment request.

[0035] Yet a further aspect of the present disclosure provides an apparatus in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure, the apparatus comprising a processor and a memory, the memory including instructions executable by the processor such that the apparatus is operable to determine that a first base station control plane function associated with the UE is unavailable and to send an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function.

[0036] An additional aspect of the present disclosure provides an apparatus in a user equipment (UE) for performing an RRC re-establishment procedure, the apparatus being configured to receive an instruction to perform an RRC re-establishment procedure from a network node and to send an RRC re-establishment request.

[0037] Another aspect of the present disclosure provides an apparatus in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure, the apparatus being configured to determine that a first base station control plane function associated with the UE is unavailable and to send an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function.

[0038] For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example only, to the following drawings: [Brief description of the drawings]

[0039] [Figure 1] FIG. 1 illustrates an example scenario for end-to-end redundant user plane paths using dual connectivity (DC). [Diagram 2] FIG. 1 illustrates an example of a 5G radio access network (RAN) architecture. [Diagram 3] A diagram showing a split g Node B architecture. [Figure 4] FIG. 2 is a diagram illustrating an example of a control plane (CP) protocol stack. [Diagram 5] FIG. 2 is a diagram illustrating an example of a user plane (UP) protocol stack. [Figure 6] A diagram showing an example of an RRC connection re-establishment (successful) procedure. [Figure 7] A diagram showing an example of an RRC re-establishment (successful) procedure with fallback to RRC establishment. [Figure 8] A diagram showing an example of an RRC re-establishment procedure for a CU / DU split architecture. [Figure 9] This is Figure D2.1.1-1 of 3GPP TS33.501. [Figure 10] 1 is a flowchart of a method in a user equipment (UE) for performing an RRC re-establishment procedure. [Figure 11] 4 is a flowchart of a method in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure. [Figure 12] FIG. 1 illustrates a particular exemplary embodiment of communication in a network. [Figure 13] FIG. 13 is a diagram illustrating another example of communication in a network. [Figure 14]14 is a schematic diagram of an example of an apparatus 1400 in a user equipment (UE) for performing an RRC re-establishment procedure. [Figure 15] 15 is a schematic diagram of an example of an apparatus 1500 in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0040] The following describes specific details, such as specific embodiments or examples, for purposes of explanation and not limitation. It will be appreciated by those skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not to obscure the description with unnecessary detail. It will be appreciated by those skilled in the art that the described functions may be implemented in one or more nodes using hardware circuits (e.g., analog and / or discrete logic gates interconnected to perform specialized functions, ASICs, PLAs, etc.) and / or using software programs and data with one or more digital microprocessors or general-purpose computers. Also, nodes that communicate using an air interface have suitable wireless communication circuitry. Moreover, where appropriate, the present technology may be considered to be fully embodied in any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk, that additionally includes a suitable set of computer instructions that will cause a processor to perform the techniques described herein.

[0041] A hardware implementation may include or encompass hardware (e.g., digital or analog) circuitry, including, but not limited to, digital signal processor (DSP) hardware, reduced instruction set processors, and, but not limited to, application specific integrated circuit (ASIC)(s) and / or field programmable gate array (FPGA)(s), and (where appropriate) state machines capable of performing such functionality.

[0042] There may be at least three possible scenarios following a control plane function failure or unavailability and a resumption or relocation of the control plane function. In some examples, the relocation of the control plane function may mean that a different control plane function takes responsibility for the control plane function / functionality for the UE(s) and DU(s) that were served by the failed or unavailable control plane function. In the first scenario, the network and UE contexts are synchronized. For example, the UE receives the last RRC message sent to the UE by the network and applies / compiles it appropriately, such that the next expected PDCP sequence number (SN) for SRB1 will be the same as the next sequence number sent by the network. In this scenario, the next RRC message sent by the network will be received in sequence at the PDCP layer and will therefore be forwarded to a layer above the PDCP layer, e.g., the RRC layer.

[0043] In the second scenario, the network has a more up-to-date context. For example, the network updated the UE context according to the latest RRC message it sent and also incremented the PDCP SN for SRB1, but that message has not arrived at the UE (e.g., the control plane function failed before the message arrived at the DU or UE). Therefore, the next RRC message sent by the network will have a larger SN than the UE expects and will be stored by the UE indefinitely, and the UE will wait for one or more packets or messages that the UE considers missing.

[0044] In a third scenario, the UE has a more up-to-date context. This can happen, for example, if the network waits until it receives an acknowledgement of an RRC message from the UE before updating the stored UE context, and the UE receives and applies the RRC message and sends an acknowledgement, but the control plane function fails before receiving the acknowledgement. In this case, the next RRC message sent by the network will have a lower SN than the UE expects, will be considered a duplicate, and will be dropped.

[0045] The embodiments of the present disclosure may, for example, ensure that context resynchronization between the UE and the network is performed upon control plane recovery (e.g., restart or relocation of control plane functions for one or more UEs). Also, the example embodiments may achieve this without service discontinuity, particularly for user plane data radio bearers (DRBs). The example embodiments provide mechanisms for having the UE perform re-establishment procedures to achieve context resynchronization between the UE and the network when a control function associated with (e.g., serving) the UE is unavailable. Furthermore, in some examples, a control plane only re-establishment procedure is provided that does not impact the operation of user plane data radio bearers.

[0046] Advantages of the exemplary embodiments may include one or more of the following: The network may cause the UE to perform a re-establishment procedure to synchronize UE context, configuration, RRC state, etc. between the network and the UE. Currently, triggering of re-establishment is only performed based on conditions in the UE, e.g., detection of radio link failure and receipt of a re-configuration that the UE was not able to compile, and is therefore UE-driven. Thus, the exemplary embodiments introduce a network-driven RRC re-establishment procedure. In some examples, a control plane re-establishment procedure is provided that does not affect user plane data radio bearers and may ensure that quality of service (QoS) requirements in the UE for bearers / services (e.g., URLLC) with stringent latency and lifetime requirements can be met even in the case of unavailability of a control plane function associated with or serving the UE. Also, in some examples, signaling optimization may be achieved, i.e., if the network sees that the UE context in the network and the UE is in sync, there will be no need to send a re-configuration message after re-establishment, which is currently always required. Even if a resynchronization is required, in some instances a partial reset may be sent instead of a full reset.

[0047] In examples of the present disclosure, the control plane functionality referred to may comprise, for example, a central unit control plane (CU-CP).

[0048] 10 is a flowchart of a method 1000 in a user equipment (UE) performing an RRC re-establishment procedure. The method includes, at step 1002, receiving an instruction from a network node (e.g., a distributed unit (DU)) to perform an RRC re-establishment procedure. The method 1000 also includes, at step 1004, sending an RRC re-establishment request. Thus, for example, the method 1000 may provide a network-driven or network-initiated RRC re-establishment procedure.

[0049] In some examples, the RRC re-establishment request includes a request to re-establish only the RRC control plane connection for the UE. This may be useful if the control plane function serving the UE has failed or is unavailable. In some examples, the control plane-only RC re-establishment procedure may thus not affect the user plane operation in the UE, and thus, for example, the user plane DRB may not be affected. In some examples, the type of message and / or an indication in the message, such as a flag or information element (IE), may indicate that the RRC re-establishment request is for control plane-only re-establishment.

[0050] Additionally or alternatively, in some examples, the instruction from the network node includes an instruction to perform a control plane only re-establishment procedure. For example, the type of message containing the instruction may indicate that the RRC re-establishment procedure is for the control plane only, and / or the message may include an indication (e.g., a flag or IE) indicating that the RRC re-establishment procedure is for the control plane only. Thus, for example, if the procedure is for the control plane only, the method 1000 may include, in some examples, maintaining a user plane UE context for the UE. This may include, for example, continuing to use one or more data radio bearers (DRBs) that were configured before receiving the instruction. In some examples, this may ensure little or no interruption to user plane operations of the UE. In some examples, the method 1000 includes performing the RRC re-establishment procedure without interrupting user plane data radio bearers (DRBs).

[0051] In some examples, the UE is associated with a first base station control plane function prior to receiving the command, and the RRC re-establishment procedure re-establishes a control plane connection to a second base station control plane function. The first and / or second control plane function may be, for example, a central unit control plane (CU-CP). Thus, the method 1000 may include, for example, receiving an RRC re-establishment message from the second base station control plane function instead of from the first control plane function in response to the RRC re-establishment request. In some examples, the command is received from the second base station control plane function, and in some examples via a network node.

[0052] The method 1000 may, in some examples, include refraining from flushing MAC and / or RLC buffers during and / or without resetting the next expected RRC message sequence number during an RRC re-establishment procedure. Such a feature may, in some examples, reduce or eliminate impact to user plane functions of the UE.

[0053] In some examples, the method 1000 includes performing an RRC re-establishment procedure (e.g., the procedure shown in FIG. 6), where the RRC re-establishment procedure includes step 1004 of transmitting an RRC re-establishment request (e.g., step 1004 is the first step shown in FIG. 6).

[0054] In some examples, receiving an instruction from the network node includes receiving an RRC message from the network node, performing an integrity verification on the RRC message using an integrity verification key, and determining that the RRC message is an instruction to perform an RRC re-establishment procedure if the integrity verification fails. Thus, for example, the network node (or other node in the network) may intentionally perform encryption or integrity protection on the RRC message using an incorrect or alternative integrity protection key, such that the message fails integrity protection at the UE. This may trigger an RRC re-establishment procedure. In some examples, a control plane only re-establishment procedure may be attempted first, followed by a "full" re-establishment procedure if the control plane only procedure is not successful. Thus, a failure of the integrity verification at the UE may be an implied instruction to perform an RRC re-establishment procedure (control plane only or otherwise) in some examples.

[0055] The command received in step 1002 may, in some examples, be received in a MAC Control Element (CE), in Downlink Control Information (DCI) transmitted on a Physical Downlink Control Channel (PDCCH), in a flag in a System Information Block (SIB), or in a broadcast message.

[0056] In some examples, the RRC re-establishment request includes an indication that the RRC re-establishment procedure is a control plane only re-establishment procedure. Additionally or alternatively, in some examples, the RRC re-establishment request includes an indication of the sequence number of the most recently received RRC message prior to receiving the command.

[0057] FIG. 11 is a flow chart of a method 1100 in a network node instructing a user equipment (UE) to perform an RRC re-establishment procedure. The network node may comprise, for example, a distributed unit (DU) or any other suitable network node or function. The method 1100 includes, in step 1102, determining that a first base station control plane function (e.g., CU-CP) associated with (e.g., serving) the UE is unavailable. For example, the first control plane function may have failed. Step 1104 of the method 1100 includes sending an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function. This may be the instruction received by the UE in step 1002 mentioned above in some examples. The instruction may be sent in a MAC control element (CE), in a downlink control information (DCI) transmitted on a physical downlink control channel (PDCCH), in a flag in a system information block (SIB), or in a broadcast message in some examples.

[0058] In some examples, the method may include receiving an RRC re-establishment request from the UE after sending the command to the UE, and forwarding the RRC re-establishment request to a second base station control plane function. Thus, the second base station control plane function (e.g., CU-CP) may be a control plane function that takes over responsibility for serving the UE, e.g., as a result of the re-establishment procedure, and is therefore associated with the UE. In some examples, the RRC establishment request includes a request to re-establish only an RRC control plane connection for the UE (e.g., as indicated in the request). Additionally or alternatively, the command sent to the UE may include an instruction to perform a control plane only re-establishment procedure, as suggested above in some examples. The RRC re-establishment request may include an indication that the RRC re-establishment procedure is a control plane only re-establishment procedure in some examples. The RRC re-establishment request may include an indication of a sequence number (SN) of a most recently received RRC message prior to receiving the command in some examples.

[0059] In some examples, the method 1100 includes maintaining a user plane UE context for the UE, which may ensure little or no user plane interruption for the UE. Maintaining the user plane UE context for the UE, in some examples, includes continuing to use one or more data radio bearers (DRBs) configured before steps 1102 and / or 1104. In some examples, the instructions include instructions to the UE to perform an RRC re-establishment procedure without interrupting the user plane data radio bearers (DRBs).

[0060] The UE may, in some examples, be associated with a first base station control plane function (e.g., CU-CP) prior to receiving the command. An RRC re-establishment procedure may then re-establish the control plane connection to a second base station control plane function (e.g., CU-CP).

[0061] In some examples, sending the command to the UE in step 1104 includes receiving the command from a second base station control plane function and forwarding the command to the UE. Thus, in these examples, the second control plane function may initiate the re-establishment procedure via a network node (e.g., a DU).

[0062] Sending the instruction to the UE may, in some examples, include encrypting the RRC message with an incorrect encryption key and forwarding the RRC message to the UE, e.g., similar to the procedure described above.

[0063] 12 illustrates a particular example embodiment of communication 1200 in a network during a method described herein. The network includes a UE 1202, a DU 1204, a first control plane function CU-CP1 1206, a second control plane function CU-CP2 1208, a UE context database 1210, a central unit user plane (CU-UP) 1212, an access and mobility management function (AMF) 1214, and a user plane function (UPF) 1216.

[0064] In this example, an RRC re-establishment procedure may be used to resynchronize the UE with the network. This example may lead to delays or user plane data transmission / reception interruptions in some cases, but this may still be faster in some examples than NAS recovery if the UE has to establish the connection from scratch (e.g., NAS recovery). However, current procedures do not allow for network-initiated re-establishment.

[0065] In step 1a) of the communication 1200 of FIG. 12, the UE 1202 has a control plane connection to the AMF 1214 via the Su 1204 and the CU-CP1 1206, and in step 1b), the UE 1202 has a user plane connection for a PDU session to the UPF 1216 via the DU 1204 and the CU-UP 1212. In step 2), the CU-CP1 writes UE information to the CU-CP2 1208 and / or the UE context database 1210. Thus, for example, the UE context(s) may be stored or updated for the UE. In step 3), the CU-CP1 1206 fails or becomes unavailable for another reason. In step 4), the DU 1204 detects the failure of the CU-CP1 1206 or the unavailability of the CU-CP1 1206. In step 5, the DU 1204 triggers RRC re-establishment in the UE 1202, for example, according to steps 1002 and 1104 described above.

[0066] In step 6a), the RLC and MAC layers are flushed in the UE 1202, and in step 6b), the RLC and MAC layers are flushed in the DU 1204. Thus, in step 7), the user plane connection is interrupted. In step 8), in the illustrated example, there is a random access procedure (RACH). For example, a random access and random access response (RAR) procedure is performed between the UE and the DU. The UE sends a special preamble on the random access channel (RACH), and the network (e.g., the DU) responds with a random access response (RAR), where the "grant" includes an uplink resource allocation for sending uplink RRC signaling. The RAR message may also include time alignment information to ensure uplink time synchronization.

[0067] In step 9), the DU 1204 selects the CU-CP2 1208. In step 10, the UE 1202 sends an RRC re-establishment request, for example according to step 1004 described above. In step 11), the CU-CP2 1208 receiving the request retrieves the UE context from the UE context database 1210. The CU-CP2 1208 then sends an RRC re-establishment message to the UE 1202 in step 12). In step 13), the UE 1202 replies with an RRC re-establishment complete message to the CU-CP2 1208.

[0068] In step 14), the CU-CP2 1208 updates the AMF 1214 (e.g., the CU-CP2 1208 updates the NG-C interface to the AMF 1214, for example by performing a path switching procedure that indicates only the movement of the NG-AP signaling association). In step 15), in this example, the same CU-UP 1212 is still used and the CU-CP2 1208 takes over the relevant UE context in the CU-UP 1212. In step 16), the CU-CP2 1208 may trigger an optional resynchronization of the UE RRC state. This step may depend on the UE context database 1210 context, for example if there is a pending RRC procedure towards the UE. In step 17b), the UE 1202 has a user plane connection for the PDU session to the UPF 1216 via the DU 1204 and the CU-UP 1212.

[0069] During normal conditions, in some examples, the CU-CP1 1206 currently serving the UE continuously or periodically stores or updates the UE context in a backup control plane function (CU-CP2 1208) or UE context database 1210. The DU 1204 can detect that the control plane function CU-CP1 1206 is unavailable in one of several ways, such as, for example: - Lack of response to SCTP keep-alive requests - Failure to receive a response to an F1-AP message, such as an F1-AP context modification, required within a given time period - Receiving explicit instructions from a failed CU-CP (upon restart) or from a new CU-CP that has taken over responsibilities for an unavailable control plane function.

[0070] If CU-CP2 already has the UE context(s) (for example, if the UE context remained updated in CU-CP2 1208 in step 2), there is no need to retrieve the UE context from the context retrieval database in step 11.

[0071] The example shown in FIG. 12 allows the network to trigger the UE to re-establish an RRC connection, thereby ensuring that UE context resynchronization is performed. However, there may be a possible interruption of user plane data. To mitigate this, in some examples, only the control plane or a part of the control plane (e.g., SRB1) needs to be re-established. For example, the command received by the UE may trigger a re-establishment procedure of only the control plane, and the UE may refrain from flushing MAC / RLC buffers and not pause reception / transmission of data radio bearers. FIG. 13 shows an example of communication 1300 in a network according to such an example. The network includes a UE 1202, a DU 1204, a first control plane function CU-CP1 1206, a second control plane function CU-CP2 1208, a UE context database 1210, a central unit user plane (CU-UP) 1212, an access and mobility management function (AMF) 1214, and a user plane function (UPF) 1216.

[0072] Steps 1a)-4) shown in Figure 13 are similar to steps 1a)-4) shown in Figure 12 and described above. However, in step 5), the DU 1204 triggers RRC re-establishment of only the control plane (CP), and in step 6), the user plane connection is not interrupted. For example, the RLC and MAC buffers may not be flushed by the UE 1302 and the DU 1304.

[0073] In step 7), the DU 1204 selects the CU-CP2 1208. In step 8), the UE 1202 sends an RRC re-establishment request, for example according to step 1004 described above. In step 9), the CU-CP2 1208 receiving the request retrieves the UE context from the UE context database 1210. The CU-CP2 1208 then sends an RRC re-establishment message to the UE 1202 in step 10). In step 11), the UE 1202 replies with an RRC re-establishment complete message to the CU-CP2 1208.

[0074] In step 12), the CU-CP2 1208 updates the AMF 1214 (e.g., the CU-CP2 1208 updates the NG-C interface to the AMF 1214, for example by performing a path switching procedure that indicates only the movement of the NG-AP signaling association). In step 13), in this example, the same CU-UP 1212 is still used and the CU-CP2 1208 takes over the relevant UE context in the CU-UP 1212. In step 14), the CU-CP2 1208 may trigger an optional resynchronization of the UE RRC state. This step may depend on the UE context database 1210 context, for example if there is a pending RRC procedure towards the UE. In step 15), the UE 1202 has a user plane connection for the PDU session to the UPF 1216 via the DU 1204 and the CU-UP 1212.

[0075] In the above, the message used to trigger the re-establishment in step 5) may be sent from the DU 1204 using lower layer signaling (e.g., MAC Control Element (CE), Downlink Control Information (DCI), System Information Block (SIB) signaling, etc.) in some examples. However, there are some alternative solutions. In one example, the DU 1204 may inform the CU-CP2 1208 about the unavailability of the CU-CP1 1206, and the CU-CP2 1208 sends a re-establishment message to the UE 1202. The DU 1204 forwards this transparently to the UE 1202. Alternatively, for example, the CU-CP2 1208 may detect that the CU-CP1 1206 is unavailable and send a control plane only re-establishment command to the UE 1202 via the DU 1204. In either case, the DU may be informed (either implicitly in the re-establishment command or explicitly) that this is a control plane only re-establishment and that there is no need to flush user plane buffers (e.g., MAC and RLC).

[0076] In some examples, the CU-CP2 1208 may generate an RRC packet, integrity protect the RRC packet with an incorrect key (e.g., a random or alternate key), and send the RRC packet to the UE 1202, as suggested above. The UE 1202 will perform integrity verification on the incoming RRC packet and detect an integrity verification failure. The legacy UE will trigger a normal re-establishment procedure, but in some examples may first attempt to perform a control plane-only re-establishment as suggested above. Since the network knows that the network has commanded the re-establishment by sending an RRC packet with incorrect integrity protection, the network may in some examples perform a control plane-only re-establishment procedure.

[0077] A new re-establishment cause value (e.g., CP-Failure) may be introduced in some examples to inform the network that the re-establishment is not triggered by a legacy re-establishment cause (such as radio link failure). This may be useful for the CU-CP2 1208, for example, when a control plane function failure is detected by the DU 1204, so that the DU 1204 is aware that it is a control plane only re-establishment.

[0078] In the re-establishment request message (e.g., as sent in step 1004 described above), the UE may, in some examples, include the PDCP sequence number (SN) of the last received RRC (e.g., SRB1) message or the next expected PDCP SN. The network may therefore verify whether the UE received the most recent RRC message sent by the network, and if so, the UE and network contexts are in sync and there is no need to send a subsequent re-configuration message to the UE. If the network finds that the UE contexts between the UE and the network are different (e.g., the last received PDCP SN indicated in the re-establishment message is smaller than the SN used for the last SRB1 message sent by the network to the UE), the network may send a subsequent re-configuration message to achieve synchronization.

[0079] In the previous re-establishment procedure, PDCP for SRB1 is re-established, which results in the sequence number (SN) for SRB1 being reset to an initial value. As a result, security keys are updated during re-establishment (using the received NCC in the re-establishment message) to ensure that the same key is not used with the same SN. A change in security keys for the control plane may also result in a change in security keys for the user plane, which may mean that RLC / MAC buffers for the DRBs must be reset (as they contain data encrypted / integrity protected using the old key) and all PDCP packets pending acknowledgment will need to be re-transmitted after being encrypted / integrity protected with the new key. This may result in increased latency for user plane traffic. However, examples of the present disclosure may mitigate these shortcomings. For example, the UE and the network may not change security keys (e.g., user plane security keys) or reset sequence numbers for a control plane-only re-establishment procedure.

[0080] An example of a modification of 3GPP specification 38.331, v16.0.0 to enable a control plane only re-establishment procedure as described herein is provided below. ******************************************************************************** 5.3.7.2 Start-up The UE initiates the procedure when one of the following conditions is met: 1> When detecting radio link failure of MCG according to 5.3.10 and T316 is not set, or 1> Upon re-configuration with sync failure of the MCG according to subclause 5.3.5.8.3, or 1> Upon mobility from NR failure according to subclause 5.4.3.5, or 1> Upon an integrity check failure indication from the lower layer related to SRB1 or SRB2, except when the integrity check failure is detected on a RRCR re-establishment message, or 1> Upon failure of RRC connection re-establishment according to subclause 5.3.5.8.2, or 1> upon detection of a radio link failure for the SCG during which the MCG transmission is interrupted according to subclause 5.3.10.3 in the NR-DC or according to TS 36.331

[10] subclause 5.3.11.3 in the NE-DC, or 1> Upon failure of reconfiguration involving synchronization of the SCG during which MCG transmission is interrupted according to subclause 5.3.5.8.3, or 1> Upon failure of SCG change during MCG transmission in the NE-DC according to TS 36.331

[10] subclause 5.3.5.7a, or 1> Upon failure of SCG configuration during interruption of MCG transmission according to subclause 5.3.5.8.2 in the NR-DC or according to TS 36.331

[10] subclause 5.3.5.5 in the NE-DC, or 1> Upon an integrity check failure indication from the SCG lower layers related to SRB3 while the MCG is suspended, or 1> Upon expiration of T316 pursuant to subclause 5.7.3b.5, or 1> When the network receives an indication from the lower layer (MAC CE) that it requires re-establishment At the start of the procedure the UE shall: 1> Stop timer T310 if it is running. 1> Stop timer T312 if it is running. 1> Stop timer T304 if it is running. 1> Start timer T311. 1> Stop timer T316 if it is running. 1> If an instruction from a lower layer triggers a re-establishment, which instructs the re-establishment of the control plane only, 2> Initiate sending an RRC CP re-establishment request message according to 5.3.7.4. 1> If not, 2> Reset your MAC, 2> If set, release the MCG SCell(s). 2> If conditionalReconfiguration is not configured in the UE, 3> If set, release spCellConfig. 3> Suspend all RBs except SRB0. 2> If MR-DC is set, 3> Perform MR-DC release as specified in clause 5.3.5.10. 2> Release delayBudgetReportingConfig if set and stop timer T342 if running. 2> Release overheatingAssistanceConfig, if set, and stop timer T345, if running. 2> If set, release idc-AssistanceConfig. 2> Release drx-PreferenceConfig if set and stop timer T346a if running. 2> Release maxBW-PreferenceConfig if set and stop timer T346b if running. 2> Release maxCC-PreferenceConfig if set and stop timer T346c if running. 2> Release maxMIMO-LayerPreferenceConfig, if set, and stop timer T346d, if running. 2> Release minSchedulingOffsetPreferenceConfig if set and stop timer T346e if running. 2> If set, releasePreferenceConfig and stop timer T346f, if running. 2> Perform cell selection in accordance with the cell selection process as specified in TS 38.304

[20] , clause 5.2.6. 5.3.7.3 Actions Following Cell Selection While T311 is Running <<skipped text>> 5.3.7.4 Actions involved in sending an RRC re-establishment request message The UE shall set the content of the RRC re-establishment request message as follows: 1> If the procedure is initiated due to a radio link failure as specified in 5.3.10.3 or due to a handover failure as specified in 5.3.5.8.3, 2> Set the reestablishmentCellId in the VarRLF-Report to the global cell identity of the selected cell. 1> Set ue-Identity as follows: 2> Set c-RNTI to the C-RNTI used in the source PCell (reconfiguration with synchronization or mobility failure from NR) or to the C-RNTI used in the PCell where the trigger for re-establishment occurred (other cases). 2> Set physCellId to the physical cell identity of the source PCell (reconfiguration with synchronization or mobility failure from NR) or to the physical cell identity of the PCell where the trigger for re-establishment occurred (other cases). 2> shortMAC-I, 3> Close 8 (i.e., a multiple of 8 bits) over the ASN.1 encoded according to VarShortMAC-Input, 3> K used in the source PCell RRCint K of the PCell where a trigger for re-establishment occurred (reconfiguration with synchronization or mobility failure from NR) or using the key and integrity protection algorithm RRCint with a key and an integrity protection algorithm (in other cases), and 3> With all input bits for COUNT, BEARER and DIRECTION set to binary 1 Set it to the 16 least significant bits of the calculated MAC-I. 1> Set reestablishmentCause as follows: 2> If the re-establishment procedure is initiated due to a re-establishment failure as specified in 5.3.5.8.2, 3> Set reestablishmentCause to the value reconfigurationFailure. 2> Otherwise, if the re-establishment procedure was triggered by a reconfiguration failure with synchronization as specified in 5.3.5.8.3 (intra-NR handover failure) or 5.4.3.5 (inter-RAT mobility failure from NR), 3> Set reestablishmentCause to the value handoverFailure. 2> Otherwise, if the re-establishment procedure was initiated by receiving an instruction to trigger the re-establishment of the CP only, 3> Set reestablishmentCause to the value CP-Failure. 2> If not, 3> Set reestablishmentCause to the value otherFailurer. 1> Re-establish PDCP for SRB1. 1> Re-establish PLC for SRB1. 1> Apply the specified settings specified in 9.2.1 for SRB1. 1> Configure lower layers to suspend integrity protection and ciphering for SRB1. NOTE: Ciphering is not applied for subsequent RRC re-establishment messages used to resume the connection. Integrity checking is performed by lower layers, but only upon request from RRC. 1> Restart SRB1. 1> Submit an RRC Connection Re-establishment Request message to lower layers for transmission. 5.3.7.5 UE Reception of RRC Re-establishment The UE shall: 1> Stop timer T301. 1> Consider the current cell to be a PCell. 1> When reestablishCP is instructed, 2> Submit an RRC re-establishment complete message to lower layers for transmission. 2 The procedure ends. 1> Remember the nextHopChainingCount value indicated in the RRC re-establishment message. 1> As specified in TS33.501

[11] , use the stored nextHopChainingCount value to calculate the current K gNB Based on the key or NH, K gNB Update the key. 1> The K associated with the previously configured cipheringAlgorithm, as specified in TS33.501

[11] . RRCenc Key and K UPenc Derive the key. 1> The K associated with the previously configured integrityProtAlgorithm as specified in TS33.501

[11] . RRCint Key and K UPint Derive the key. 1> The previously set algorithm and K RRCint The RRC re-establishment message integrity protection request is sent to the lower layers using the key and . 1> If the integrity protection check of the RRC re-establishment message fails, 2> Perform actions upon entering RRC_IDLE as specified in 5.3.11 with release cause "RRC connection failure", then the procedure ends. 1> The previously set algorithm and K RRCint The lower layers shall be configured to immediately resume integrity protection for SRB1 using the keys and , i.e. integrity protection shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate successful completion of the procedure. 1> The previously set algorithm and K RRCenc The lower layers shall immediately be configured to resume ciphering for SRB1 using the key and, i.e., ciphering shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate successful completion of the procedure. 1> If set, releases the measurement gap configuration indicated by measGapConfig; 1> Set the content of the RRC re-establishment complete message as follows: 2> If the UE has logged measurements available for NR and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport, 3> Include logMeasAvailable in the RRC re-establishment complete message. 2> If the UE has Bluetooth logged measurements available and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport, 3> Include logMeasAvailableBT in the RRC re-establishment complete message. 2> If the UE has logged measurements of an available WLAN and if the RPLMN is included in the plmn-IdentityList stored in the VarLogMeasReport, 3> Include logMeasAvailableWLAN in the RRC re-establishment complete message. 2> If the UE has connection establishment failure information available in VarConnEstFailReport, and if the RPLMN is equal to the plmn-Identity stored in the VarConnEstFailReport, 3> Include connEstFailInfoAvailable in the RRC re-establishment complete message. 2> If the UE has radio link failure or handover failure information available in the VarRLF-Report and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report, 3> Include rlf-InfoAvailable in the RRC re-establishment complete message. 2> If the UE has radio link failure or handover failure information available in the VarRLF-Report of TS 36.331

[10] , and if the UE is capable of cross-RAT RLF reporting, and if the RPLMN is included in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] , 3> Include rlf-InfoAvailable in the RRC re-establishment complete message. 1> Submit an RRC re-establishment complete message to lower layers for transmission. 1> The procedure ends. ********************************************************************************

[0081] 14 is a schematic diagram of an example of an apparatus 1400 in a user equipment (UE) for performing an RRC re-establishment procedure. The apparatus 1400 comprises a processing circuit 1402 (e.g., one or more processors) and a memory 1404 in communication with the processing circuit 1402. The memory 1404 includes instructions executable by the processing circuit 1402. The apparatus 1400 also comprises an interface 1406 in communication with the processing circuit 1402. Although the interface 1406, the processing circuit 1402, and the memory 1404 are shown connected in series, they may alternatively be interconnected in any other manner, for example, via a bus.

[0082] In some embodiments, the memory 1404 includes instructions executable by the processing circuit 1402 such that the apparatus 1400 is operable to receive instructions from a network node to perform an RRC re-establishment procedure and to send an RRC re-establishment request. In some examples, the apparatus 1400 is operable to perform the method 1000 described above with reference to FIG.

[0083] 15 is a schematic diagram of an example of an apparatus 1500 in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure. The apparatus 1500 comprises a processing circuit 1502 (e.g., one or more processors) and a memory 1504 in communication with the processing circuit 1502. The memory 1504 includes instructions executable by the processing circuit 1502. The apparatus 1500 also comprises an interface 1506 in communication with the processing circuit 1502. Although the interface 1506, the processing circuit 1502, and the memory 1504 are shown connected in series, they may alternatively be interconnected in any other manner, for example, via a bus.

[0084] In one embodiment, the memory 1504 includes instructions executable by the processing circuit 1502 such that the apparatus 1500 is operable to determine that a first base station control plane function associated with the UE is unavailable and to send an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function. In some examples, the apparatus 1500 is operable to perform the method 1100 described above with reference to FIG.

[0085] It should be noted that the above examples are illustrative rather than limiting of the present invention, and that those skilled in the art will be able to design many alternatives without departing from the scope of the appended description. The word "comprising" does not exclude the presence of elements or steps other than those recited in the claims, and "a" or "an" does not exclude a plurality, and a single processor or other unit may perform the functions of several units recited in the following description. When terms such as "first", "second", etc. are used, they should be understood as merely convenient identification labels of certain features. In particular, they should not be interpreted as describing a first or second feature of a plurality of such features (i.e., the first or second of such features to occur in time or space) unless expressly stated otherwise. Steps in methods disclosed herein may be performed in any order, unless expressly stated otherwise. Any reference signs in the description should not be interpreted as limiting their scope.

Claims

1. 1. A method in a user equipment (UE) for performing an RRC re-establishment procedure, the method comprising: receiving an instruction from a network node to perform an RRC re-establishment procedure; in response to receiving the command, transmitting an RRC re-establishment request; Including, The method, wherein the instructions from the network node include instructions to perform a control plane only re-establishment procedure.

2. 2. The method of claim 1, wherein the RRC re-establishment request comprises a request to re-establish only an RRC control plane connection for the UE.

3. The method of claim 2 , comprising maintaining a user plane UE context for the UE.

4. 4. The method of claim 3, wherein maintaining the user plane UE context for the UE includes continuing to use one or more Data Radio Bearers (DRBs) that were established before receiving the command.

5. 5. The method of claim 1, comprising performing the RRC re-establishment procedure without interrupting user plane Data Radio Bearers (DRBs).

6. 6. The method according to claim 1, wherein the UE is associated with a first base station control plane function before receiving the command, and the RRC re-establishment procedure re-establishes a control plane connection to a second base station control plane function.

7. The method of claim 6 , comprising receiving an RRC re-establishment message from the second base station control plane function in response to the RRC re-establishment request.

8. 8. The method of claim 1, comprising refraining from flushing MAC and / or RLC buffers during and / or without resetting a next expected RRC message sequence number during the RRC re-establishment procedure.

9. Receiving the instruction from the network node receiving an RRC message from the network node; performing integrity verification on the RRC message using an integrity verification key; if the integrity verification fails, determining that the RRC message is an instruction to perform an RRC re-establishment procedure; The method of any one of claims 1 to 8, comprising:

10. 10. The method of claim 1, wherein the instruction is received in a MAC Control Element (CE), in Downlink Control Information (DCI) transmitted on a Physical Downlink Control Channel (PDCCH), in a flag in a System Information Block (SIB), or in a broadcast message.

11. The method of claim 1 , wherein the RRC re-establishment request includes an indication that the RRC re-establishment procedure is a control plane only re-establishment procedure.

12. 12. The method of claim 1, wherein the RRC re-establishment request includes an indication of a sequence number of a most recently received RRC message prior to receiving the command.

13. 1. A method in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure, the method comprising: determining that a first base station control plane function associated with the UE is unavailable; if it is determined that the first base station control plane function associated with the UE is unavailable, sending an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function; receiving an RRC re-establishment request from the UE after sending the command to the UE; and forwarding the RRC re-establishment request to the second base station control plane function. A method comprising:

14. 14. The method of claim 13, wherein sending the instruction to the UE includes encrypting an RRC message with an incorrect encryption key and forwarding the RRC message to the UE.

15. A computer program comprising instructions which, when executed on at least one processor, cause said at least one processor to perform a method according to any one of claims 1 to 12.

16. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to perform a method as claimed in claim 13 or 14.

17. An apparatus in a user equipment (UE) for performing an RRC re-establishment procedure, the apparatus comprising: receiving an instruction from a network node to perform an RRC re-establishment procedure; in response to receiving the command, transmitting an RRC re-establishment request; It is set to do The apparatus, wherein the instructions from the network node include instructions to perform a control plane only re-establishment procedure.

18. 18. Apparatus according to claim 17, wherein the apparatus is configured to carry out the method according to any one of claims 2 to 12.

19. 1. An apparatus in a network node for instructing a user equipment (UE) to perform an RRC re-establishment procedure, the apparatus comprising: determining that a first base station control plane function associated with the UE is unavailable; if it is determined that the first base station control plane function associated with the UE is unavailable, sending an instruction to the UE to perform an RRC re-establishment procedure to cause the UE to re-establish a control plane connection with at least a second base station control plane function; receiving an RRC re-establishment request from the UE after sending the command to the UE; and forwarding the RRC re-establishment request to the second base station control plane function. The device is configured to:

20. 20. Apparatus according to claim 19, wherein the apparatus is configured to carry out the method according to claim 13 or 14.

Images