Location and context management in a RAN INACTIVE mode

A method at a network node of a radio access network (RAN) for managing a context of a user equipment (UE) operating in an inactive mode, the method comprising: receiving, from a second network node, a context retrieval request comprising a UE identifier and a first message, the first message being protected with a first cryptographic key; validating the first message using a stored cryptographic key associated with a UE context indicated by the UE identifier; and sending a context retrieval response message to the second network node containing a relocation indication of whether the UE context is to be relocated to the second network node.

RELATED APPLICATION

The present disclosure is related to US Provisional Patent Application No. 62/547,452 entitled “Location and Context Management in a RAN INACTIVE Mode” filed 18 Aug. 2017, the contents of which are incorporated by reference, inclusive of all filed appendices.

TECHNICAL FIELD

The present disclosure generally pertains to the field of wireless communications networks, and particular embodiments or aspects relate to location and context management in a RAN INACTIVE mode of operation.

BACKGROUND

In a conventional radio access network (RAN), a user equipment (UE) may be operating in any one of a CONNECTED mode, an IDLE mode, and an INACTIVE mode. The CONNECTED mode corresponds with bi-directional connectivity between the UE and its serving base stations, such that the UE is able to send and receive session protocol data units (PDUs). The IDLE mode corresponds with no radio resource control (RRC) connection (and therefore no radio connectivity) between the UE and the RAN, and the RAN releases any RAN resources associated with the UE. The INACTIVE mode is similar to the IDLE mode in that there is no RRC connection between the UE and the RAN and there are no radio resources allocated to the UE, but also differs from the IDLE mode in that at least one RAN node retains UE context information (such as security association, encryption keys etc.), and so is capable of initiating communication with the UE in a relatively short period of time.

The INACTIVE mode allows a UE to enter a low energy mode of operation, and thereby conserve battery power. In order to receive information transmitted by the network, the UE transitions from the INACTIVE mode into the CONNECTED mode.

However a transition from the INACTIVE mode to the CONNECTED mode results in one or more of the following:moving UE context across a backhaul network to the new serving RAN node from an anchor RAN node;creating a new security association between the UE and the new serving RAN node and deriving new cryptographic keys;control plane signalling over the radio link to configure the UE for operation within the new serving cell.

These operations result in additional latency and extended periods of time when the UE is not able to re-enter a low energy mode of operation due to the expected interaction with the serving RAN node. Therefore the anchor RAN node should be able to decide whether to retain its role of anchor for a UE or to relocate the role of anchor to the new serving RAN node.

When the UE initiates a transition from the INACTIVE to the CONNECTED mode or initiates a RAN location notification and/or a RAN notification area (RNA) update in INACTIVE mode, current procedures do not fully protect the control plane signalling between the UE and the RAN and delay validation of the UE which potentially results in significant network signalling and processing, if validation subsequently fails.

Accordingly, there may be a need for a system and method for location and context management in a RAN INACTIVE mode that is not subject to one or more limitations of the prior art.

This background information is intended to provide information that may be of possible relevance to the present disclosure. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art against the present disclosure.

SUMMARY

It is an object of the present disclosure to obviate or mitigate at least one disadvantage of the prior art.

Accordingly, a first aspect of the present disclosure provides an anchor node of a RAN, the anchor node comprising: a memory and at least one processor configured to: receive, from a second network node, a context retrieval request comprising an identifier of a UE operating in an INACTIVE mode and a first message, the first message being protected with a first cryptographic key; validate the first message using a stored cryptographic key associated with a UE context indicated by the identifier of the UE; and send a context retrieval response to the second network node, the context retrieval response containing a relocation indication of whether the UE context is to be relocated to the second network node.

In an embodiment, the relocation indication is responsive to validating the first message in accordance with the stored cryptographic key.

In an embodiment, the relocation indication is responsive to a determination of whether to relocate the UE context to the second network node.

In an embodiment, the context retrieval response can comprise a second message protected with a second cryptographic key.

In an embodiment, the second message can be a radio resource control (RRC) message.

In an embodiment, the second message can comprise at least one of: an identifier to be used by the UE for further operations in the INACTIVE mode; an indication of an RNA where the UE can receive service while operating in the INACTIVE mode; and a maximum time between location notifications initiated by the UE.

In an embodiment, the context retrieval response can comprise the UE context and a second cryptographic key.

A further aspect of the present disclosure provides a serving node of a RAN, the serving node comprising: a memory and at least one processor configured to: receive, from a UE, an identifier of a UE operating in an INACTIVE mode and a first message, the first message being protected with a first cryptographic key; send the identifier of the UE and the first message to a second network node; receive, from the second network node, a second message protected with a second cryptographic key; and send the second message to the UE.

In an embodiment, the second network node can be determined in accordance with the identifier of the UE.

In an embodiment, the second message can comprise at least one of: an identifier to be used by the UE for further operations in the INACTIVE mode; an indication of an RNA where the UE can receive service while operating in the INACTIVE mode; and a maximum time between location notifications initiated by the UE.

A further aspect of the present disclosure provides a serving node of a RAN, the serving node comprising: a memory and at least one processor configured to: receive, from a UE, an identifier of a UE operating in an INACTIVE mode and a first message, the first message being protected with a first cryptographic key; send the identifier of the UE and the first message to a second network node; receive from the second network node, a context associated with the UE; derive, based on the context, a second cryptographic key; and send a second message to the UE protected with the second cryptographic key.

In an embodiment, the second network node can be determined in accordance with the identifier of the UE.

In an embodiment, the second message can comprise any one or more of: an identifier to be used by the UE for further operations in the INACTIVE mode; an indication of an RNA where the UE can receive service while operating in the INACTIVE mode; and a maximum time between location notifications initiated by the UE.

DETAILED DESCRIPTION

In the following description, features of the present disclosure are described by way of examples. For convenience of description, these examples make use of features and terminology known from 4G and 5G networks as defined by the Third Generation Partnership Project (3GPP). However, it shall be understood that the present disclosure is not limited to such networks. Rather, methods and systems in accordance with the present disclosure may be implemented in any network in which a mobile device may connect to the network through at least one access point, and subsequently be handed-over to at least one other access point during the course of a communications session.

FIG. 1is a block diagram of an electronic device (ED)102illustrated within a computing and communications environment100that may be used for implementing the devices and methods disclosed herein. In some examples, the ED102may be an element of communications network infrastructure, such as a base station (for example a NodeB, an enhanced Node B (eNB), a next generation NodeB (sometimes referred to as ng-eNB or gNB), a home subscriber server (HSS), a gateway (GW) such as a packet gateway (PGW) or a serving gateway (SGW) or a user plane gateway (UPGW), a user plane function (UPF), or various other nodes or functions within a CN. In other examples, the ED102may be a device that couples to network infrastructure over a radio interface, such as a mobile phone, smart phone or other such wireless device that may be classified as a UE. In some examples, ED102may be a Machine Type Communications (MTC) device (also referred to as a machine-to-machine (m2m) device), or another such device that may be categorized as a UE102despite not providing a direct service to a user. In some references, an ED102may also be referred to as a mobile device (MD), a term intended to reflect devices that couple to a mobile network, regardless of whether the device itself is designed for, or capable of, mobility. Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processors, memories, transmitters, receivers, etc. The ED102typically includes a processor106, such as a Central Processing Unit (CPU), and may further include specialized processors such as a Graphics Processing Unit (GPU) or other such processor, a memory108, a network interface110and a bus112to couple the components of ED102. ED102may optionally also include components such as a mass storage device114, a video adapter116, and an I/O interface118(shown in dashed lines).

The memory108may comprise any type of non-transitory system memory, readable by the processor106, such as static random-access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or a combination thereof. In specific examples, the memory108may include more than one type of memory, such as ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. The bus112may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.

The ED102may also include one or more network interfaces110, which may include at least one of a wired network interface and a wireless network interface. As illustrated inFIG. 1, network interface110may include a wired network interface to couple to a network120, and also may include a radio access network interface122for connecting to other devices over a radio link. When ED102is network infrastructure, the radio access network interface122may be omitted for nodes or functions acting as elements of the CN other than those at the radio edge (e.g. an eNB). When ED102is infrastructure at the radio edge of a network, both wired and wireless network interfaces may be included. When ED102is a wirelessly connected device, such as a UE, radio access network interface122may be present and it may be supplemented by other wireless interfaces such as WiFi network interfaces. The network interfaces110allow the ED102to communicate with remote entities such as those coupled to network120.

The mass storage114may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus112. The mass storage114may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, or an optical disk drive. In some examples, mass storage114may be remote to the ED102and accessible through use of a network interface such as interface110. In the illustrated example, mass storage114is distinct from memory108where it is included, and may generally perform storage tasks compatible with higher latency, but may generally provide lesser or no volatility. In some examples, mass storage114may be integrated with a memory108to form an heterogeneous memory.

The optional video adapter116and the I/O interface118(shown in dashed lines) provide interfaces to couple the ED102to external input and output devices. Examples of input and output devices include a display124coupled to the video adapter116and an I/O device126such as a touch-screen coupled to the I/O interface118. Other devices may be coupled to the ED102, and additional or fewer interfaces may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device. Those skilled in the art will appreciate that in examples in which ED102is part of a data center, I/O interface118and Video Adapter116may be virtualized and provided through network interface110.

In some examples, ED102may be a standalone device, while in other examples, ED102may be resident within a data center. A data center, as will be understood in the art, is a collection of computing resources (typically in the form of servers) that can be used as a collective computing and storage resource. Within a data center, a plurality of servers can be coupled together to provide a computing resource pool upon which virtualized entities can be instantiated. Data centers can be interconnected with each other to form networks consisting of pools computing and storage resources coupled to each by connectivity resources. The connectivity resources may take the form of physical connections such as Ethernet or optical communications links, and may include wireless communication channels as well. If two different data centers are coupled by a plurality of different communication channels, the links can be combined together using any of a number of techniques including the formation of link aggregation groups (LAGs). It should be understood that any or all of the computing, storage and connectivity resources (along with other resources within the network) can be divided between different sub-networks, in some cases in the form of a resource slice. If the resources across a number of coupled data centers or other collection of nodes are sliced, different network slices can be created.

FIG. 2illustrates an architecture210for the implementation of a 5G next generation radio access network (NG-RAN)212. NG-RAN212couples a UE202to a CN214. Those skilled in the art will appreciate that CN214may be a 5G Core Network or a 4 G Evolved Packet Core (EPC) network. Nodes within NG-RAN212couple to the 5G CN214over an NG interface. This NG interface can comprise both a control plane (CP) NG-C (N2) interface to a CN CP function (CPF) and a user plane (UP) NG-U (N3) interface to a CN UP function (UPF). NG-RAN212includes a plurality of radio access nodes where each node is referred to as a gNB. In the NG-RAN212, gNB216A and gNB216B are able to communicate with each other over an Xn interface. Within a single gNB216A, the functionality of the gNB may be decomposed into a centralized unit (gNB-CU)218A and a set of distributed units (gNB-DU220A-1and gNB-DU220A-2, collectively referred to as220A). gNB-CU218A is coupled to a gNB-DU220A over an F1 interface. Similarly gNB216B has a gNB-CU218B coupling to a set of distributed units gNB-DU220B-1and gNB-DU220B. Each gNB-DU may be responsible for one or more cells providing radio coverage within the public land mobile network (PLMN).

A gNB is also coupled to UE202(such as, for example ED102) via a radio link (Uu) and to another gNB via an Xn interface that includes both a CP component (Xn-C) and a UP component (Xn-U).

A UE202may establish multiple PDU sessions with the CN214where different sessions may correspond to different instances of the NG-U UP interface; each instance of the NG-U interface may terminate on a different CN UPF.

In a 3GPP Long-Term Evolution (LTE) system, similar interfaces exist: an eNB is coupled to a CN214through an S1 interface and to another eNB through an X2 interface. Throughout this document, the term “RAN node” is used to refer to a RAN element that encompasses gNB, gNB-CU, gNB-DU, eNB, ng-eNB, ng-eNB-CU, ng-eNB-DU, NodeB, base station, and other forms of radio access controller. The term “RAN node” may also be understood in some contexts to include other wireless access nodes, such as WiFi access points, in which case suitable modifications to adapt to a different standard may be required.

It should be understood that any or all of the functions discussed above with respect to the NG-RAN212and CN214may be virtualized within a network, and the network itself may be provided as a network slice of a larger resource pool.

Referring toFIG. 3, the Uu interface between a UE202and a RAN node may comprise several entities within the protocol stack300. Example entities include physical layer (PHY)302, medium access control (MAC)304, radio link control (RLC)306, packet data convergence protocol (PDCP) layer308, service data adaptation protocol (SDAP) layer310, and radio resource control (RRC) layer312.

CP information such as RRC312and non-access stratum (NAS) signalling may be carried over a signalling radio bearer (SRB) while UP data may be carried over a data radio bearer (DRB).

In some networks, a number of small cells may be deployed within the coverage area of a macro cell to offload traffic from the macro cell and/or to provide improved signal quality to UEs.FIG. 4Ashows an example deployment in which a master RAN node402provides the NG connections to the CN214and maintains an SRB410to a UE202through a primary cell404. The UE202may use a DRB412to convey UP traffic through a secondary cell408to a secondary RAN node406. This traffic may be relayed between the master402and the secondary406RAN nodes over an Xn interface.

On the network side, the UP protocol stack in a dual connectivity deployment may be split between the master RAN node402and the secondary RAN node406, as may be seen inFIG. 4B. The master RAN node402houses the upper layer protocol stack entities (including SDAP310and PDCP308) while the secondary RAN node406houses the lower layer protocol stack entities (RLC306, MAC304and PHY302).

While the UE202is registered with the network, it may transition between multiple modes of operation, including:CONNECTED mode. In this mode, the UE202maintains radio bearers with the RAN212in order to exchange UP data with servers coupled to the Internet-at-large. In some examples, the CONNECTED mode may be referred to as RRC_CONNECTED.IDLE mode. In this mode, the UE202may remain registered with the CN214but there are no RAN212resources associated with the UE202. As a result, the UE202is not coupled to the RAN212and cannot transmit or receive information. In some examples, the IDLE mode may be referred to as RRC_IDLE.INACTIVE mode. In this mode, there are no radio resources associated with the UE202but the RAN212maintains a context for the UE202that encompasses the security keys established during authentication of the UE202and the configuration parameters associated with all sessions that have been established for the UE202. The INACTIVE mode allows a UE202to enter a low energy mode of operation, similar to IDLE mode, in order to conserve battery power but allows a quick transition to CONNECTED mode in order to transmit and receive information. In some examples, the INACTIVE mode may be referred to as RRC_INACTIVE.

Maintaining the UE202in the INACTIVE mode reduces radio link signalling overheads and may result in commensurate battery power savings in the UE202. Keeping the UE context in the RAN212also reduces latencies and network signalling overheads.

FIG. 5illustrates an example RAN model for INACTIVE mode operations. In this example RAN model:An anchor RAN node510maintains the connections to the CN214for the UE202(e.g. via NG or S1). The anchor RAN node510also maintains, or has access to, the current configuration and other context information512associated with the UE202. In some examples, the anchor RAN node510may be a node that previously acted as a serving RAN node530of the UE202, for example when the UE202entered the INACTIVE mode. In other examples, the anchor RAN node510may be a centralised server configured to act as an anchor RAN node510for multiple UEs202within the PLMN. In such an example, the anchor RAN node510may serve as a dedicated anchor RAN node510associated with a plurality of different serving RAN nodes530.a RAN notification area (RNA)520denotes one or more cells in which the UE202can receive service while moving within the PLMN; the scope of the RNA520may be as small as the coverage area provided by a single cell or as large as the entire PLMN. If the UE202moves outside the designated RNA520, it may notify the RAN212and may be assigned to a different anchor RAN node510. It should be understood that RNA520can also be described as the union of the coverage areas provided by the serving RAN node530and the other RAN Nodes535. The procedure whereby the UE202notifies the RAN212of movement outside the designated RNA520may be described, without limitation, as location notification, RAN location area update, RNA update and/or RAN area update.the anchor RAN node510may be coupled via an intra-RAN backhaul network to one or more other RAN nodes (530and535) within the RNA520; each of those RAN nodes may control one or more cells associated with the RNA520. The interface between RAN nodes, dubbed Rn560inFIG. 5, may be provided as any one or more of an X2 interface, an Xn interface, a CU-DU interface such as F1, or a new interface (which may be similar to any of the X2, Xn or CU-DU interfaces) developed for the purpose.

The example protocol stack illustrated inFIG. 5is based on the dual-connectivity model shown inFIG. 4B. Accordingly, the upper layer SDAP310and PDCP308protocol entities and state machines are located in the anchor RAN node510, while the lower layer RLC306, MAC304and PHY302protocol entities (and any state machines used for such an implementation) are located in the serving RAN node530. However, in contrast to the dual-connectivity model illustrated inFIG. 4B, the serving RAN node530does not have access to the UE-specific context512for managing transmissions over the radio link (Uu) to the UE202when the UE202is coupled to the serving RAN node530. For example, the serving RAN node530may not have any one or more of:configurations for radio bearers currently established for UE202(e.g. RLC306configuration, PDCP308configuration);radio bearer state information (e.g. received PDU sequence numbers, transmitted PDU sequence numbers);robust header compression state information (e.g. established flow contexts, flow sequence number);cryptographic keying material (e.g. keys, counters) for UE202;quality of service (QoS) information (e.g. authorised QoS profiles, SDAP QoS flow to DRB mappings);session information (e.g. identity of CN UPF, identity of CN CPF).

The lack of radio protocol information implies that the serving RAN node530retrieves the UE context512from the anchor RAN node510in order to transition a UE202from the INACTIVE to the CONNECTED mode.

RAN Cryptographic Key Derivation

3GPP Technical Specification (TS) 33.401, “3GPP System Architecture Evolution (SAE); Security architecture” defines a UE master cryptographic key dubbed KASMEthat can be derived independently by the UE and a CN CPF through an authentication and key agreement procedure. From KASME, cryptographic keys used by a RAN node for encryption and integrity protection are derived from a RAN temporal master key dubbed KeNBin LTE. A similar RAN temporal master key dubbed KgNBis defined for 5G New Radio (NR) operations that is derived from a UE master cryptographic key dubbed KAMF. A new RAN temporal master key, dubbed KeNB* for LTE and KgNB* for NR, is derived independently by the UE202and its current serving RAN node on every inter-cell and intra-cell handover—i.e. no keys need to be transmitted over the radio link between a UE202and the nodes within the RAN212. Separate temporal keys can then be derived from the master key for encryption and integrity protection of CP traffic and UP traffic.

RAN Temporal Master Key Derivation

In 3GPP TS 33.401, a new KeNBmay be derived using either a horizontal key chain or a vertical key chain such that a new generation of the key is based on a previous generation of the key:for horizontal key derivation, a new KeNB* is derived through a key derivation function (KDF) that takes as inputs: the current KeNB; the physical cell identifier (PCI) of the serving cell; and the absolute radio frequency channel number (ARFCN) used on the downlink (DL) of the serving cell. The new KeNB* then becomes the current KeNBfor subsequent operations. In 5G, a similar procedure is used for horizontal derivation of a new KgNB.for vertical key derivation, a new KeNBis derived through a KDF that takes as inputs: a next hop (NH) key; the PCI of the serving cell; and the ARFCN used on the DL of the serving cell. In 5G, a similar procedure is used for vertical derivation of a new KgNB.

The NH key used for vertical key derivation is computed independently by the UE and a CPF in the CN. A new NH key (NH*) is derived through a KDF that takes as inputs: the current NH key; and the UE master key (e.g. KASMEor KAMF). The NH* key then becomes the current NH key for subsequent operations.

When a node or function within the CN214decides to generate a new NH key (e.g. following a handover to a new serving RAN node530), it increments a next-hop chaining count (NCC) and provides the NCC and new NH key to the current serving RAN node530using a secure NG-C connection (e.g. secured using IPsec). The NCC acts as a key identifier to synchronise cryptographic operations between the UE202and the RAN212.

On a subsequent handover, the current serving RAN node530provides the value of NCC to the UE202(e.g. in a handover command). If the received NCC value is different from the value currently stored in the UE202, the UE202generates a new NH key and increments its stored value of NCC; this procedure can be repeated until the stored value of NCC matches the value received from the serving RAN node530. Once the NCC values match, the corresponding NH key is used to generate a new RAN temporal master key. Using the new RAN temporal master key (e.g. KeNBor KgNB), the UE202can generate temporal keys for cryptographic operations in the new serving cell.

RAN Temporal Keys and Cryptographic Operations

RAN temporal keys are derived from the RAN temporal master key (e.g. KeNBor KgNB) and are used for encryption and integrity protection of CP traffic and UP traffic. A different temporal key can be used for each cryptographic procedure:a CP encryption key (e.g. KRRCenc) is used for privacy protection of RRC312messages;a CP integrity protection key (e.g. KRRCint) is used for integrity protection of RRC312messages;a UP encryption key (e.g. KUPenc) is used for privacy protection of UP data;a UP integrity protection key (e.g. KUPint) is used for integrity protection of UP data.

In some situations, the UP keys are applied to all DRBs associated with a UE202. In other situations, different UP keys are used for different sessions; all DRBs associated with a given session could use the same keys but DRBs associated with a different session would use a different key.

In 3GPP TS 33.401, each of the temporal keys is generated using a KDF that takes as inputs at least one of:the RAN temporal master key (e.g. KeNBor KgNB);a pre-defined constant value that identifies the temporal key being generated; anda pre-defined constant value that may in some examples identify a cryptographic algorithm (e.g. Advanced Encryption Standard (AES)) selected by the RAN212used for encryption/integrity protection.

Each cryptographic operation (encryption or integrity protection) uses a pseudo-random function determined by the selected cryptographic algorithm that takes as inputs at least one of:the corresponding temporal key;the radio bearer number (BEARER);the direction of transmission (UL(0) or DL(1));the length of the PDCP PDU (LENGTH); anda counter associated with the PDCP instance (COUNT).

In accordance with examples of the present disclosure, before initiating a transition from INACTIVE to CONNECTED mode, validation of the CP message conveying a request from the UE202to the RAN212can be performed using a message integrity check (MIC) (also known as a message authentication code for integrity (MAC-I)) computed by the UE202using cryptographic keys derived for use with the anchor RAN node510. The RAN node530currently serving the UE202can transparently forward the request to the anchor RAN node510where the MIC can be validated using information in the UE context512stored at the anchor RAN node510. If the MIC is successfully validated, the anchor RAN node510may decide to keep the UE202in the INACTIVE mode or to initiate a transition to the CONNECTED mode.

The anchor RAN node510may also decide whether to retain its role of anchor for UE202or to allow the role of anchor to be moved to the new serving RAN node530. If the anchor RAN node510decides to retain its role as anchor for UE202, configuration parameters may be updated in the UE202through a CP RRC message that is protected using keys associated with the anchor RAN node510. If the anchor RAN node510decides to relocate the anchor role to the new serving RAN node530, the anchor RAN node510can provide the serving RAN node530with UE context512allowing the generation of a new set of cryptographic keys that are associated with the new serving RAN node530.

In all cases, provision can be made for determining the validity of the UE request before UE context512is transferred to the new serving RAN node530and for securing all CP communications with the UE202.

Generic Procedure Overview

FIGS. 6A-6Billustrate a generic procedure600, using a modified 4-step random access procedure (as described in 3GPP TS 38.321, “NR; Medium Access Control (MAC) protocol specification”). This procedure may be implemented between the UE202, serving RAN node530and anchor RAN node510described above with reference toFIG. 5, and may include the following steps.

601: The anchor RAN node510decides to transition the UE202from the CONNECTED mode to the INACTIVE mode. The anchor RAN node510, having made this determination may transmit an RRC connection release message to the UE202; this message may include:an indication of the intended mode of operation—i.e. INACTIVE mode;an identifier (e.g. ueID) assigned to the UE202and to be used by the UE202while operating in the INACTIVE mode;an indication of the RNA520(e.g. rnaConfig) where the UE202can receive service while operating in the INACTIVE mode;the maximum time between location notifications initiated by the UE202(e.g. maxUpdateTime).

CP temporal keys generated for use in the serving cell of the anchor RAN node510can be used for integrity protection (KRRCint′) and encryption (KRRCenc′) of the RRC connection release message.

602: Following receipt of the RRC connection release message from the anchor RAN node510, the UE202may initialise a periodic location notification timer. Initialization of the periodic location notification timer may be based on the maximum time between location notifications (e.g. maxUpdateTime), which may have been indicated by the anchor RAN node510(typically indicated in the RRC connection release message transmitted to the UE202).

603: While operating in the INACTIVE mode, the UE202may move into the coverage of cells controlled by a different RAN node.

604: While in the INACTIVE mode, the UE202decides to initiate an uplink (UL) transmission. This decision may, for example, be triggered by expiry of the periodic location notification timer or by the queuing of UL data that are to be transmitted.

In response to the decision to initiate an UL transmission, the UE202begins a cell selection procedure to identify a suitable cell for re-establishing a radio link connection. The RAN node controlling the selected cell is dubbed the serving RAN node530.

605: random access request (Msg1). Based on physical random access channel (PRACH) configuration broadcast as system information by the serving cell, the UE202may select a preamble (e.g. a Zadoff-Chu sequence) and transmit the selected preamble towards the serving RAN node530using the PRACH configuration. The selection of a preamble may be a random or pseudo-random selection in some examples.

606: Following receipt of the preamble from the UE202, the serving RAN node530can schedule a DL random access response (RAR) message to be sent to the UE202.

607A and607B: random access response (Msg2). The serving RAN node530may schedule (at607A) a DL transmission to the UE202(using a downlink control information (DCI) message encoded with a random access radio network temporary identifier (RA-RNTI) and including a DL grant) and then transmit (at607B) the RAR to the UE202. This RAR message may include:a random access preamble identifier (RAPID) corresponding to the detected preamble;a cell RNTI (C-RNTI) to be used by the UE202for scheduled transmissions within the serving cell;an UL grant that can be used by the UE202for the UL transmission of Msg3.

608: UE202identification and access request (Msg3). Using the UL grant provided in the RAR associated with the RAPID corresponding to the random access preamble selected by the UE202, the UE202may transmit a CP message (e.g. a RRC request) to the serving RAN node530. The RRC request message may include the INACTIVE mode identifier (ueID) assigned to the UE202by the anchor RAN node510in step601. The UE202may then start a contention resolution timer.

The RRC request may also include a MIC computed using the CP integrity protection key (KRRCint′) associated with the anchor RAN node510(i.e. the same integrity protection key used for the MIC of the RRC connection release message in step601).

Optionally, the RRC request may be encrypted using the CP encryption key (KRRCenc′) associated with the anchor RAN node510(i.e. the same encryption key used for protection of the RRC connection release command in step601). In this case, the INACTIVE mode identifier (ueID) can be included as cleartext in a lower layer element of Msg3, e.g. a MAC control element (CE) or PDCP information element. The existence of this information element can be interpreted by the serving RAN node530as initiation of an INACTIVE mode transaction.

609A and609B: contention resolution (Msg4). If the serving RAN node530successfully decodes an UL transmission608according to the grant provided in step607B, it can schedule (at609A) a transmission to the UE202(using a DCI message encoded with the C-RNTI assigned in step607and a DL grant), followed (at609B) by a contention resolution message (Msg4) that echoes the ueID received by the serving RAN node in Msg3. Msg4 may comprise a MAC CE containing the ueID.

If the ueID received by the UE202in Msg4 matches the identifier that the UE202transmitted in Msg3, the random access is deemed successful and the UE202can monitor the physical downlink control channel (PDCCH) for subsequent DCI messages encoded with the C-RNTI assigned in step607.

If the ueID received by the UE202does not match the identifier it transmitted in Msg3, or if the contention resolution timer expires, the random access is deemed unsuccessful (e.g. another UE may have selected the same preamble in step601) and the UE202restarts the random access procedure.

610: Using information extracted from the ueID received in Msg3, the serving RAN node530identifies the anchor RAN node510associated with the UE202when it entered INACTIVE mode and initiates a transaction with the anchor RAN node510to retrieve the UE context512.

As shown starting inFIG. 6B, the process continues to611: The serving RAN node530transmits a UE context retrieval request towards an identified anchor RAN node510. The UE context retrieval request includes the ueID and an information element that may transparently contain the RRC request and MIC received from the UE202in Msg3 (step608).

612: Using information extracted from the received ueID, the anchor RAN node510determines a current set of temporal keys associated with the UE202. This determination may be performed in accordance with stored UE context512that can be accessed by the anchor RAN node510. The anchor RAN node510can then use the CP integrity protection key (KRRCint′), which can be either stored in the UE context512or reconstituted based on the stored UE context512, to validate the MIC provided by the UE202, to the serving RAN node530, in the RRC request (step608).

613: If the MIC is successfully validated, the anchor RAN node510transmits a UE context retrieval response to the serving RAN node530, which may contain the UE context512associated with the UE202when it entered the INACTIVE mode.

If the MIC fails, the anchor RAN node510can abort the procedure by reporting an error to the serving RAN node530. In another example, the anchor RAN node510may abort the procedure by not transmitting any reply message to the serving RAN node530. The serving RAN node530can determine that the process has failed either through the receipt of the message reporting an error, or through a determination that the anchor RAN node510is alive and has not responded within a defined time period.

614: If the serving RAN node530successfully receives a UE context retrieval response from the anchor RAN node510, it uses the received information to construct a CP RRC response to the UE202:in some situations, the CP RRC response may be provided by the anchor RAN node510, including a MIC computed using the anchor RAN node510CP integrity protection key (KRRCint′); the prepared response is then transparently relayed to the UE202by the serving RAN node530.in other situations, the serving RAN node530uses the UE context512provided by the anchor RAN node510to generate a new set of cryptographic keys for use within the cell serving the UE202; the serving RAN node530uses the new keys to protect CP RRC messages subsequently exchanged with the UE202.

615A and615B: access request acknowledgement (Msg4bis). The serving RAN node530subsequently schedules (at615A) a DL transmission to the UE202(using a DCI encoded with the C-RNTI assigned in step607and a DL grant) and transmits (at615B) the RRC response to the RRC request sent in Msg3 (step608).if the RRC312response is protected using a new set of cryptographic keys for use within the cell serving the UE202, cryptographic parameters needed by the UE202to autonomously generate the keys are provided by the serving RAN node530as cleartext in lower layer elements of the message, e.g. in one or more MAC CEs or PDCP information elements. Additional cryptographic parameters may also be provided in Msg4bis, e.g. a cryptographic algorithm identifier.

As a result of this procedure:a) the old integrity protection key, derived for use with the anchor RAN node510, can be used for protection of Msg3 and, subsequently, for validation of the RRC request by the anchor RAN node510.b) horizontal or vertical key derivation may be used for generation of the new RAN temporal master key (e.g. KeNB* or KgNB*).c) a new cryptographic algorithm may be selected by the new serving RAN node530, different from the algorithm used by the anchor RAN node510.d) Msg3 is integrity protected and optionally encrypted (with anchor RAN node510keys).e) Msg4bis is both integrity protected and encrypted (with new serving RAN node530keys).f) cryptographic protection is provided to all RRC messages (i.e. all RRC messages are authenticated and may be encrypted).g) early validation of the UE202is provided (i.e. at step612, before transmission of Msg4bis and before UE context512is returned to the serving RAN node530).
Procedure for INACTIVE to CONNECTED Transition

This section describes the INACTIVE to CONNECTED (i2c) mode procedure that is initiated by a UE202and follows the generic procedure described above. In this procedure:a CP request to resume a connection that is received from the UE202(e.g. in Msg3) is integrity protected using the integrity protection key associated with the anchor RAN node510(KRRCint′);the anchor role is moved from the current anchor RAN node510to the new serving RAN node530following validation of the MIC;a CP command to resume the connection transmitted from the serving RAN node530(e.g. in Msg4bis) is both integrity protected and encrypted using a cryptographic algorithm selected by the serving RAN node530and a new set of temporal keys derived for use in the new serving cell.

The steps in this procedure (700), illustrated inFIGS. 7A-7C, include:

701-705: With the UE202operating in the INACTIVE mode, the UE202decides to initiate a transition to the CONNECTED mode. This decision may, for example, be triggered by the queuing of data that will be transmitted on the UL to the RAN. In response to any of these factors, or any other determination that the UE202should transition to the CONNECTED mode, the UE202can initiate a random access procedure (705) with the serving RAN node530.

The connection release, cell selection and random access procedures are similar to steps601-607ofFIG. 6.

706: The UE202transmits a RRC resume request message to the serving RAN node530(e.g. in Msg3 of the random access procedure). The RRC resume request message may include the INACTIVE mode identifier (ueID) assigned to the UE202by the anchor RAN node510(e.g. in step701).

The resume request message can include a MIC such as an integrity checksum or check value computed using the CP integrity protection key (KRRCint′) associated with the anchor RAN node510(i.e. the same integrity protection key used for the MIC of the connection release message in step701).

Optionally, the resume request message may be encrypted using the CP encryption key (KRRCenc′) associated with the anchor RAN node510. In this case, the INACTIVE mode identifier (ueID) is included as cleartext in a lower layer element of step706(Msg3), e.g. a MAC CE or PDCP information element; the existence of this information element is interpreted by the serving RAN node530as initiation of an i2c transition.

707-709: Similar to steps610-611ofFIGS. 6A-6B, the serving RAN node530identifies the anchor RAN node510and sends a UE context512retrieval request (708) to the anchor RAN node510. The UE context512retrieval request may include any or all of the ueID, the resume request and MIC received from the UE202. Using UE context512associated with the received ueID, the anchor RAN node510can validate the MIC provided by the UE202in the resume request and, if the validation is successful, the anchor RAN node510can retrieve the requested UE context information (709).

710: If the MIC is successfully validated, the anchor RAN node510can return a UE context retrieval response to the serving RAN node530that includes any or all of:RRC configuration information provided to the UE202by the anchor RAN node510(e.g. rrcConfig1);UE capabilities (e.g. ueCapabilities) previously determined by the anchor RAN node510(e.g. supported cryptographic algorithms); andUE security association information (e.g. current NCC and KeNB* or KgNB*).

711: Based on the UE context512received from the anchor RAN node510, the serving RAN node530can:select a cryptographic algorithm supported by both the UE202and the serving RAN node530;generate a corresponding set of temporal encryption and integrity check keys (described above) based on the received RAN temporal master key (e.g. KeNB* or KgNB*).

712: The serving RAN node530transmits a message to the UE202(e.g. in Msg4bis) that includes a resume command, the cryptographic algorithm selected by the serving RAN node530and the NCC value received from the anchor RAN node510. The cryptographic algorithm and the NCC value can be provided in cleartext in a lower layer element of Msg4bis, e.g. a MAC control element (CE) or PDCP information element. The resume command can be integrity protected using the new CP integrity protection key (KRRCint) derived by the serving RAN node530. The resume command may also be encrypted using the new CP encryption key (KRRCenc) derived by the serving RAN node530. If the resume command is encrypted, the serving RAN node530may include modified RRC configuration information in this message rather than using a separate connection reconfiguration message at a later time.

713: Using the specified cryptographic algorithm, the UE202can:verify that the received value of NCC matches its stored value of NCC and, if there is a mismatch, compute NH* to match the received value of NCC;generate a new RAN temporal master key (e.g. KeNB* or KgNB*) based on the current KeNB/KgNB(or NH*) and the cell currently serving the UE202; andgenerate a corresponding set of temporal encryption and integrity check keys.

714: Using the new CP keys (KRRCencand KRRCint), the UE202can decrypt the resume command and validate the MIC received from the serving RAN node530. In some examples, the decryption and validation may be performed separately with intervening steps.

715: If the resume command is successfully validated, the UE202sends a resume complete message (e.g. Msg5) to the serving RAN node530that can be integrity protected using the new CP integrity protection key (KRRCint) and encrypted using the new CP encryption key (KRRCenc).

716: The serving RAN node530can decrypt the received message using the CP encryption key (KRRCenc) which may have been previously derived by the serving RAN node530. The serving RAN node530can validate the MIC included in the received message using the CP integrity protection key (KRRCint).

717: If the resume complete message is successfully validated, the serving RAN node530sends a UE context retrieval complete message to the old (or previous) anchor RAN node510, confirming that the serving RAN node530has successfully assumed the role of anchor RAN node510for UE202.

718: When it receives the UE context retrieval complete message, the old anchor RAN node510may delete the stored UE context512for UE202.

The old anchor RAN node510should not delete the stored UE context512before receiving the UE context retrieval complete message because the serving RAN node530may not succeed in becoming the new anchor RAN node510for UE202, and it may be advantageous to ensure that the UE context512is not deleted until another node can assume anchor RAN node510responsibilities. For example:the UE202may move to a different serving cell, associated with a different RAN node, before completing the resume procedure;validation of the UE202by the serving RAN node530may fail (e.g. due to a replay attack by a bogus UE202);the retrieval response from the anchor RAN node510to the serving RAN node530in step710may be lost.
Procedures for Location Notification

This section describes several procedures for applying the generic procedure described above to RRC messages passing between a UE202and the RAN212in order for a UE202to notify the RAN212of its current location. Location notification may be initiated by a UE202due to expiration of a periodic timer or due to mobility outside of a designated RNA520.

In both cases, location notification may or may not result in a change of anchor RAN node510and/or an update to the configuration parameters used by the UE202while operating in the INACTIVE mode. The updated configuration parameters may include:RNA520may be changed to encompass a different set of cells based, for example, on the RAN nodes that are neighbours to the current serving RAN node530. A rolling update to the configured RNA520may be used, for example, as a trade-off between paging overhead for DL traffic and overhead for UL location reporting.periodic timer may be changed, for example, based on cell deployment at the current location (e.g. during a transition between urban small cell and suburban/rural macro cell deployment) or the proximity of the UE202to a geographical point of interest (e.g. to a RNA or tracking area boundary, to a PLMN boundary, to a tunnel).UE INACTIVE mode identifier (ueID) may be changed, for example, to reflect a change in the anchor RAN node510or as a security measure by a particular anchor RAN node510to limit the use and/or lifetime of a particular identifier.

Relocation of the anchor role (also referred to as responsibilities of an anchor RAN node510) to the serving RAN node530is a decision made by the current anchor RAN node510. Because a change in the anchor role may involve additional processing (and consumption of battery power) in the UE202(e.g. for the generation of new cryptographic keys), the current anchor RAN node510may retain its role for UE202when the UE202moves outside the designated RNA520; retaining its role as anchor is predicated on the ability of the RAN node to communicate to the set of potential serving RAN nodes530within a new RNA520.

Similarly, the current anchor RAN node510may decide to relocate the role of anchor to the serving RAN node530following a periodic location update from the UE202even though the UE202is still within its designated RNA520. The current anchor RAN node510may make this decision based, for example, on its current load, on a projected trajectory for a mobile UE202, or on network latencies associated with the backhaul network between RAN nodes or between the RAN212and CN214nodes associated with the UE202.

Location Notification, without Change in Anchor Role

In this procedure, validation of the location notification is performed by the anchor RAN node510and the updated INACTIVE mode configuration is returned by the anchor RAN node510to the serving RAN node530. UE context512is not provided to the serving RAN node530, therefore a new set of cryptographic keys is not generated at the serving RAN node530; as a consequence, the updated configuration is protected by the anchor RAN node510using the CP keys associated with the anchor RAN node510. In this procedure, the serving RAN node simply acts as a transparent relay for signalling between the UE202and the anchor RAN node510.

The steps in this procedure (800), illustrated inFIGS. 8A-8B, include:

801-809: With the UE202operating in the INACTIVE mode, the periodic location notification timer expires and the UE202transmits a location notification message that is received by the serving RAN node530. The serving RAN node530can act as a relay to forward or otherwise transmit this message to the anchor RAN node510indicated by the ueID received from the UE202.

This procedure is similar to steps601-612described above with reference toFIGS. 6A-6B.

810: If the MIC provided by the UE202is successfully validated, the anchor RAN node510may decide to not relocate the anchor role to the current serving RAN node530(e.g. the anchor RAN node510may decide to keep the anchor role instead of relocating the responsibilities to the serving RAN node530). In this case, the anchor RAN node510returns a UE context retrieval response to the serving RAN node530that may include:an indication that the anchor role is not changing and that UE context512is not being provided to the serving RAN node530;an information element that contains a location notification response, possibly transparently, from the anchor RAN node510to the UE202; the location notification response may include:a MIC computed by the anchor RAN node510using a CP integrity protection key (KRRCint′) associated with the anchor RAN node510(e.g. the same integrity protection key used for the MIC of the connection release command in step801);optionally, a new set of configuration parameters to be used by the UE202while operating in INACTIVE mode—e.g. updated RNA520, maximum periodic update time, and/or INACTIVE mode identifier (ueID).

The location update response may also be encrypted using a CP encryption key (KRRCenc′) associated with the anchor RAN node510.

811: Based on the received response from the anchor RAN node510, the serving RAN node530transmits a message to the UE202(e.g. Msg4bis) that includes the location notification response provided by the anchor RAN node510.

812: Using the CP keys derived for use with the anchor RAN node510(KRRCenc′and KRRCint′), the UE202decrypts the location notification response and validates the MIC.

If the location update response is successfully validated, the UE202may optionally send a location notification complete message (e.g. Msg5) to the serving RAN node530as confirmation that it is resuming INACTIVE mode operation.

Location Notification, with Change in Anchor Role

In this procedure, following validation of the location notification by the current anchor RAN node510, the anchor RAN node510decides to relocate the anchor role to the serving RAN node530. As a result, the anchor RAN node510returns the UE context512to the serving RAN node530where, following procedure800, the serving RAN node530generates a new set of cryptographic keys and instructs the UE202to return to CONNECTED mode for reconfiguration by the serving—now new anchor—RAN node.

The steps in this procedure (900), illustrated inFIGS. 9A-9C, include:

901-909: With the UE202operating in the INACTIVE mode, a periodic location notification timer expires and the UE202transmits a location notification message to the serving RAN node530. The serving RAN node530then relays this message to the anchor RAN node510indicated by the ueID received from the UE202.

This procedure is similar to steps601-612described above with reference toFIGS. 6A-6B.

910: If the MIC is successfully validated, the anchor RAN node510may decide to relocate the anchor role to the current serving RAN node530.

911: The anchor RAN node510returns a UE context512retrieval response to the serving RAN node530that may include any or all of:RRC configuration information provided to the UE202by the anchor RAN node510(e.g. rrcConfig1);UE202capabilities (e.g. ueCapabilities) previously determined by the anchor RAN node510(e.g. supported cryptographic algorithms);UE202security association information (e.g. current NCC and KeNB*/KgNB*).

912-919: The UE context512returned by the anchor RAN node510is an indication to the serving RAN node530that it should assume the role of anchor RAN node for UE202. Similar to steps711-718ofFIGS. 7A-7C, the serving RAN node530establishes a new set of temporal cryptographic keys and configures the UE202for operation with the serving—now new anchor—RAN node.

Reception of a resume command at step913rather than a location notification response is an indication to the UE202that it is being returned to the CONNECTED mode for possible reconfiguration in a new anchor RAN node.

If necessary, the new anchor RAN node530can return the UE202to the INACTIVE mode at a later time.

Method Actions

Turning now toFIG. 10, there is shown a flow chart, shown generally at1000, showing example actions taken by a network node of a RAN for managing a context of a UE operating in an inactive mode.

One example action1010is to receive, from a second network node, a context retrieval request comprising a UE identifier and a first message, the first message being protected with a first cryptographic key.

One example action1020is to validate the first message using a stored cryptographic key associated with a UE context indicated by the UE identifier.

The result of the validation action1020may be considered in decision1030. If the message is not valid1031, then processing proceeds to action1040. If the message is valid1032, then processing proceeds to decision1050.

In some non-limiting examples, one example action1040may be to indicate, by the context retrieval response, that a determination has been made that the first message is not valid.

In some non-limiting examples, one example action1045may be to indicate, by the relocation indication, that a determination has been made not to relocate the UE context.

In some non-limiting examples, a determination whether or not to relocate the UE context may be made at decision1050. If the determination is not to relocate the UE context1051, then processing proceeds to action1060. If the determination is to relocate the UE context1052, then processing proceeds to action1070.

In some non-limiting examples, one example action1060may be to indicate, by the relocation indication, that a determination has been made not to relocate the UE context.

In some non-limiting examples, one example action1065may be to include a RRC response in the context retrieval response.

In some non-limiting examples, one example action1070may be to indicate, by the relocation indication, that a determination has been made to relocate the UE context.

In some non-limiting examples, one example action1075may be to include the UE context and a second cryptographic key in the context retrieval response.

One example action1080may be to send a context retrieval response to the second network node, the context retrieval response containing the relocation indication of whether the UE context is to be relocated to the second network node.

Turning now toFIG. 11, there is shown a flow chart, shown generally at1100, showing example actions taken by a network node of a RAN for managing a context of a UE operating in an inactive mode.

One example action1110is to receive, from the UE, a UE identifier and a first message, the first message being protected with a first cryptographic key.

One example action1120is to send the UE identifier and the first message to a second network node.

One example action1130is to receive, from the second network node, a second message protected with a second cryptographic key.

One example action1140is to send the second message to the UE.

Turning now toFIG. 12, there is shown a flow chart, shown generally at1200, showing example actions taken by a network node of a RAN for managing a context of a UE operating in an inactive mode

One example action1210is to receive, from the UE, a UE identifier and a first message, the first message being protected with a first cryptographic key.

One example action1220is to send the UE identifier and the first message to a second network node.

One example action1230is to receive, from the second network node, a context associated with the UE.

One example action1240is to derive, based on the context, a second cryptographic key.

One example action1250is to send a second message to the UE protected with the second cryptographic key.

Accordingly, a first aspect of the present disclosure provides a method at a network node of a RAN for managing a context of a UE operating in an INACTIVE mode, the method comprising: receiving, from a second network node, a context retrieval request comprising a UE identifier and a first message, the first message being protected with a first cryptographic key; validating the first message using a stored cryptographic key associated with a UE context indicated by the UE identifier; and sending a context retrieval response message to the second network node, the context retrieval response message containing a relocation indication of whether the UE context is to be relocated to the second network node.

A further aspect of the present disclosure provides a method at a network node of a RAN for managing a context of a UE operating in an INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; sending the UE identifier and the first message to a second network node; receiving, from the second network node, a second message protected with a second cryptographic key; and sending the second message to the UE.

A further aspect of the present disclosure provides a method at a network node of a RAN for managing a context of a UE operating in an INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; sending the UE identifier and the first message to a second network node; receiving, from the second network node, a context associated with the UE; deriving, based on the context, a second cryptographic key; and sending a second message to the UE protected with the second cryptographic key.

Accordingly, an aspect of the present disclosure provides a method at a network node of a radio access network (RAN) for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from a second network node, a context retrieval request comprising a user equipment identifier and a first message protected with a first cryptographic key; and sending a context retrieval response message to the second network node, the context retrieval response message containing an indication of whether the UE context is to be relocated to the second network node.

In an embodiment, the sending the context retrieval response if performed can be responsive to validating the first message in accordance with the first cryptographic key. In an embodiment, the sending of the context retrieval response can be performed responsive to a determination of whether to relocate the UE context to the second network node. In an embodiment, the network node can be an anchor node associated with the user equipment.

A further aspect of the present disclosure provides an anchor node of a radio access network (RAN), the anchor node comprising: at least one processor; and non-transitory computer readable software instructions configured to control the at least one processor to implement a method for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from a second network node, a context retrieval request comprising a user equipment identifier and a first message protected with a first cryptographic key; and sending a context retrieval response message to the second network node, the context retrieval response message containing an indication of whether the UE context is to be relocated to the second network node.

A further aspect of the present disclosure provides a method at a network node of a radio access network (RAN) for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; identifying, based on the UE identifier, a second network node; sending the UE identifier and the first message to the second network node; receiving, from the second network node, a second message protected with a second cryptographic key; and sending the second message to the UE.

In an embodiment, the second network node can be determined in accordance with the UE identifier. In an embodiment, the second message can comprise at least one of: an identifier to be used by the UE for further operations in the inactive mode; an indication of the RAN notification area where the UE can receive service while operating in the inactive mode; and a maximum time between location notifications initiated by the UE. In an embodiment, the network node can be a serving node associated with the user equipment.

A further aspect of the present disclosure provides a serving node of a radio access network (RAN), the anchor node comprising: at least one processor; and non-transitory computer readable software instructions configured to control the at least one processor to implement a method for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; identifying, based on the UE identifier, a second network node; sending the UE identifier and the first message to the second network node; receiving, from the second network node, a second message protected with a second cryptographic key; and sending the second message to the UE.

A further aspect of the present disclosure provides a method at a network node of a radio access network (RAN) for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; identifying, based on the UE identifier, a second network node; sending the UE identifier and the first message to the second network node; receiving, from the second network node, a context associated with the UE; deriving, based on the context, a second cryptographic key; and sending a second message to the UE protected with the second cryptographic key.

In an embodiment, the second network node can be determined in accordance with the UE identifier. In an embodiment, the second cryptographic key can be determined in accordance with the context associated with the UE. In an embodiment, the network node can be a serving node associated with the UE. In an embodiment, the second message can comprise any one or more of: an identifier to be used by the UE for further operations in the inactive mode; an indication of the RAN notification area where the UE can receive service while operating in the inactive mode; and a maximum time between location notifications initiated by the UE.

A further aspect of the present disclosure provides a serving node of a radio access network (RAN), the anchor node comprising: at least one processor; and non-transitory computer readable software instructions configured to control the at least one processor to implement a method for managing a UE context of a user equipment (UE) operating in the INACTIVE mode, the method comprising: receiving, from the UE, a UE identifier and a first message protected with a first cryptographic key; identifying, based on the UE identifier, a second network node; sending the UE identifier and the first message to the second network node; receiving, from the second network node, a context associated with the UE; deriving, based on the context, a second cryptographic key; and sending a second message to the UE protected with the second cryptographic key.