Enhanced handover procedures in communication network environment

Abstract

Techniques are disclosed for enhanced handover operations in a communication network environment. For example, from user equipment perspective, a method includes receiving, at the user equipment, a reconfiguration message from a radio access node with which the user equipment is connected, the reconfiguration message including handover-enabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message, and utilizing, by the user equipment, the handover-enabling data to perform the two or more handover operations.

Description

[0001] ENHANCED HANDOVER PROCEDURES IN COMMUNICATION NETWORK ENVIRONMENT

[0002] Field

[0003] The field relates generally to communication networks, and more particularly, but not exclusively, to security management in such communication networks.

[0004] Background

[0005] This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0006] Fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high-capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks.

[0007] While 5G networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services providing improved wireless Internet access for mobile devices.

[0008] In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system.

[0009] For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” and TS 23.502, entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS),” the disclosures of which are incorporated by reference herein in their entireties. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and / or a data network such as a packet data network (e.g., Internet).

[0010] TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs).

[0011] Furthermore, TS 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

[0012] Security management is an important consideration in any communication network environment. However, due to continuing attempts to improve the architectures and protocols associated with a 5G network, and / or other networks, in order to increase network efficiency and / or subscriber convenience, security management issues associated with UE mobility between cells in a communication network environment (e.g., handovers) can present a significant technical challenge.

[0013] Summary

[0014] Illustrative embodiments provide techniques for enhanced handover operations in a communication network environment.

[0015] In one illustrative embodiment, from a user equipment perspective, a method includes: receiving, at the user equipment, a reconfiguration message from a radio access node with which the user equipment is connected, the reconfiguration message including handoverenabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message; and utilizing, by the user equipment, the handoverenabling data to perform the two or more handover operations.

[0016] In another illustrative embodiment, from a radio access node perspective, a method includes: sending, from a first radio access node, a first request to a network node in a communication network in response to receipt of measurement data received from user equipment subscribed to the communication network; receiving, at the first radio access node, a first response from the network node including handover-enabling data to enable the user equipment to perform two or more handover operations; sending, from the first radio access node, a second request including at least a portion of the handover-enabling data to a candidate radio access node; receiving, at the first radio access node, a second response from the candidate radio access node; identifying, by the first radio access node, the candidate radio access node as a target radio access node based on the second response; and sending, from the first radio access node, a reconfiguration message to the user equipment including identifying information corresponding to the target radio access node and at least a portion of the handoverenabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message.

[0017] In yet another illustrative embodiment, from a network node perspective, a method includes: receiving, at a network node of a communication network, a request from a radio access node to which user equipment is connected; generating, by the network node and in response to the request, handover-enabling data to enable the user equipment to perform two or more handover operations in response to a reconfiguration message received by the user equipment from the radio access node; and sending, from the network node, the handoverenabling data to the radio access node.

[0018] In some illustrative embodiments, the handover-enabling data includes two or more sets of key derivation parameters respectively corresponding to the two or more handover operations, wherein each set of key derivation parameters comprises a next hop (NH) parameter and a corresponding next hop chaining counter (NCC) parameter. The handover-enabling data may further include a hopping pattern corresponding to the user equipment.

[0019] In some embodiments, the handover-enabling data is received by the user equipment in a plurality of containers including a non-access stratum (NAS) container and a lower layer- triggered mobility (LTM) container.

[0020] Advantageously, illustrative embodiments provide enhanced LTM handover procedures that enable user equipment to perform subsequent handovers without a new reconfiguration message (e.g., radio resource control (RRC) reconfiguration message) being sent from a source radio access node to the user equipment. That is, the user equipment receives key derivation data in one RRC message to enable the user equipment to derive a fresh key for subsequent handovers.

[0021] Further illustrative embodiments are provided in the form of a non-transitory computer readable medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above and / or other steps, operations, and the like. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above and / or other steps, operations, and the like. Some illustrative embodiments comprise a system configured to perform the above and / or other steps, operations, and the like. Further, some illustrative embodiments comprise an apparatus or a system comprising means for performing the above and / or other steps, operations, and the like.

[0022] These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

[0023] Brief Description of the Drawings

[0024] FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented.

[0025] FIG. 2 illustrates user equipment and entities with which one or more illustrative embodiments may be implemented.

[0026] FIG. 3 illustrates a key chaining procedure in a communication network environment.

[0027] FIG. 4 illustrates a handover procedure in a communication network environment.

[0028] FIG. 5 illustrates an enhanced handover procedure in a communication network environment according to an illustrative embodiment.

[0029] FIG. 6 illustrates a table for a use case of an enhanced handover procedure in a communication network environment according to an illustrative embodiment.

[0030] Detailed Description

[0031] Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems.

[0032] In accordance with illustrative embodiments implemented in a 5G communication system environment, one or more 3GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS 23.501, TS 23.502, and TS 33.501. Other 3GPP TS / TR documents may provide other details that one of ordinary skill in the art will realize, for example, TS 38.401 entitled, “Technical Specification Group Radio Access Network; NG-RAN; Architecture Description,” TS 38.300 entitled, “Technical Specification Group Radio Access Network; NR; NR and NG-RAN Overall Description; Stage 2,” TS 38.331 entitled, “Technical Specification Group Radio Access Network; NR; Radio Resource Control (RRC) Protocol Specification,” and RP-234036 entitled, “New WID: NR Mobility Enhancements Phase 4,” the disclosures of which are incorporated by reference herein in their entireties. Note that 3GPP TS / TR documents are nonlimiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well-suited for 5G- related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0033] It is to be understood that the term 5G network, and the like (e.g., 5G system, 5G communication system, 5G environment, 5G communication environment etc.), in some illustrative embodiments, may be understood to comprise all or part of an access network and all or part of a core network. However, the term 5G network, and the like, may also occasionally be used interchangeably herein with the term 5GC network, and the like, without any loss of generality, since one of ordinary skill in the art understands any distinctions.

[0034] Prior to describing illustrative embodiments, a general description of certain main components of a 5G network will be described below in the context of FIGS. 1 and 2.

[0035] FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent some main functions provided within the system, e.g., control plane functions, user plane functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide some of these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, at least some functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements / functions (i.e., network entities). Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface 103 with an access point 104. It is to be understood that UE 102 may use one or more other types of access points (e.g., access functions, networks, etc.) to communicate with the 5GC network other than a gNB. By way of example only, the access point 104 may be any 5G access network (gNB), an untrusted non-3GPP access network that uses an Non-3GPP Interworking Function (N3IWF), a trusted non-3GPP network that uses a Trusted Non-3GPP Gateway Function (TNGF) or wireline access that uses a Wireline Access Gateway Function (W-AGF) or may correspond to a legacy access point (e.g., eNB). Furthermore, access point 104 may be a wireless local area network (WEAN) access point as will be further explained in illustrative embodiments described herein.

[0036] The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, an loT device, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0037] In one illustrative embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a permanent subscription identifier and its related key, which are used to uniquely identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions. Alternative illustrative embodiments may not use UICC-based authentication, e.g., a Non-Public (Private) Network (NPN).

[0038] Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) unique to the UE. In one embodiment, the IMSI is a fixed 15 -digit length and consists of a 3 -digit Mobile Country Code (MCC), a 3 -digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI). Another example of a SUPI uses a Network Access Identifier (NAI). NAI is typically used for loT communication.

[0039] The access point 104 is illustratively part of a radio access network or RAN of the communication system 100. Such a radio access network may comprise, for example, a 5G System having a plurality of base stations. Components of a radio access network may, more generally, be considered “radio access entities.”

[0040] Further, the access point 104 in this illustrative embodiment is operatively coupled to an Access and Mobility Management Function (AMF) 106. In a 5G network, the AMF 106 supports, inter alia, mobility management (MM) and security anchor (SEAF) functions.

[0041] AMF 106 in this illustrative embodiment is operatively coupled to (e.g., uses the services of) other network functions 108. Other network functions 108 may include network functions that can act as service producers (NFp) and / or service consumers (NFc). Note that any network function can be a service producer for one service and a service consumer for another service. Further, when the service being provided includes data, the data-providing NFp is referred to as a data producer, while the data-requesting NFc is referred to as a data consumer. A data producer may also be an NF that generates data by modifying or otherwise processing data produced by another NF. Note that NFs may, more generally, be considered “network entities” whereby a network entity that consumes one or more of data and a service can be considered a “consumer network entity” and a network entity that produces one or more of data and a service can be considered a “producer network entity.”

[0042] Note that a UE, such as UE 102, is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN) in which some or all of the functions 106 and 108 reside. Alternatively the UE, such as UE 102, may receive services from an NPN where these functions may reside. The HPLMN is also referred to as the Home Environment (HE). If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a visited network, while the network that is currently serving the UE is also referred to as a serving network. In the roaming case, some of the functions 106 and 108 can reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a non-roaming scenario, access and mobility management functions 106 and the other network functions 108 reside in the same communication network, i.e., HPLMN. Embodiments described herein, unless otherwise specified, are not necessarily limited by which functions reside in which PLMN (i.e., HPLMN or VPLMN).

[0043] The access point 104 is also operatively coupled (via one or more of functions 106 and / or 108) to a Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. Note that the thicker solid lines in this figure denote a user plane (UP) of the communication network, as compared to the thinner solid lines that denote a control plane (CP) of the communication network. It is to be appreciated that Internet 114 in FIG. 1 may additionally or alternatively represent other network infrastructures including, but not limited to, cloud computing infrastructure and / or edge computing infrastructure. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation. Note that functions shown in 106, 108, 110 and 112 are examples of network functions (NFs).

[0044] It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the communication system 100 may comprise other elements / functions not expressly shown herein.

[0045] Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements / functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

[0046] It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) are logical networks that provide specific network capabilities and network characteristics that can support a corresponding service type, optionally using network function virtualization (NFV) on a common physical infrastructure. With NFV, network slices are instantiated as needed for a given service, e.g., eMBB service, massive loT service, and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104.

[0047] FIG. 2 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 200 is shown comprising user equipment (UE) 202 and a plurality of entities 204-1, . . . . , 204-N. For example, in illustrative embodiments and with reference back to FIG. 1, UE 202 can represent UE 102, while entities 204-1, . . . , 204-N can represent functions 106 and 108 (i.e., network entities such as, but not limited to, AMF), as well as access point 104 (i.e., radio access entity such as, but not limited to, a RAN node or gNB). It is to be appreciated that the UE 202 and entities 204-1, . . . . , 204-N are configured to interact to provide security management and other techniques described herein.

[0048] The user equipment 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the user equipment 202 includes a security management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The security management processing module 214 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the user equipment 202 includes a security management storage module 218 that stores data generated or otherwise used during security management operations.

[0049] Each of the entities (individually or collectively referred to herein as 204) comprises a processor 222 (222-1, . . . , 222-N) coupled to a memory 226 (226-1, . . . , 226-N) and interface circuitry 220 (220-1, . . . , 220-N). Each processor 222 of each entity 204 includes a security management processing module 224 (224-1, . . . , 224-N) that may be implemented at least in part in the form of software executed by the processor 222. The security management processing module 224 performs security management operations described in conjunction with subsequent figures and otherwise herein. Each memory 226 of each entity 204 includes a security management storage module 228 (228-1, . . . , 228-N) that stores data generated or otherwise used during security management operations. The processors 212 and 222 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[0050] The memories 216 and 226 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

[0051] A given one of the memories 216 and 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a computer or processor readable (non-transitory or storage) medium that has executable program code embodied therein. Other examples of computer or processor readable media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other computer or processor readable media.

[0052] Further, the memories 216 and 226 may more particularly comprise, for example, electronic random- access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phasechange RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0053] The interface circuitries 210 and 220 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

[0054] It is apparent from FIG. 2 that user equipment 202 and plurality of entities 204 are configured for communication with each other as security management participants via their respective interface circuitries 210 and 220. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request / response messages and data, request / response messages, authorization and / or authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[0055] It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function and / or access point can be configured to incorporate additional or alternative components and to support other communication protocols.

[0056] Other system elements such as access point 104, SMF 110, and UPF 112 may each be configured to include components such as a processor, memory and network interface. Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

[0057] More generally, FIG. 2 can be considered to represent processing devices configured to provide respective security management functionalities and operatively coupled to one another in a communication system. By way of example only, all or parts of each of UE 202 and the plurality of entities 204 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein.

[0058] As mentioned above, the 3GPP TS 23.501 defines the 5GC network architecture as service-based, e.g., Service-Based Architecture (SBA). It is realized herein that in deploying different NFs, there can be many situations where an NF may need to interact with an entity external to the SBA-based 5GC network (e.g., including the corresponding PLMN(s), e.g., HPLMN and VPLMN). Thus, the term “internal” as used herein illustratively refers to operations and / or communications within the SBA-based 5GC network (e.g., SBA-based interfaces) and the term “external” illustratively refers to operations and / or communications outside the SBA-based 5GC network (non-SBA interfaces). Lower layer-triggered mobility (LTM) is a new 5G handover procedure with shorter service interruption times in which a gNB receives a measurement report from a UE, and on the basis of the measurement report, the gNB changes the serving cell (e.g., from a source cell to a target cell) of the UE. In the existing LTM handover (HO), the gNB prepares one or more candidate cells and provides the candidate cell configurations to the UE through an RRC message. Then, the LTM cell switch is triggered by selecting one of the candidate configurations as the target configuration for the LTM by the gNB. The candidate cell configurations can only be added, modified, and released by the network via Radio Resource Control (RRC) signaling. As illustratively used herein, a cell refers to a geographical area covered by a frequency (or a frequency range) emitted by a base station in a cellular network.

[0059] It is realized that it would be desirable, from a security and / or signaling perspective, to enable LTM handover procedures that avoid RRC configuration between cell switches. However, such an approach would need one or more technical solutions for key handling without reconfiguration. Illustrative embodiments provide such technical solutions in the context of an enhanced LTM handover procedure as will be illustratively described below in the context of FIG. 5. Prior to illustratively describing enhanced LTM handover procedures, existing key chaining and existing LTM handover procedures will be briefly described in the context of FIGS. 3 and 4, respectively.

[0060] FIG. 3 illustrates a key chaining procedure (procedure 300) in a communication network environment. As shown in procedure 300, whenever an initial access stratum (AS) security context needs to be established between a UE and a gNB, the AMF and the UE derive a KgNB and a Next Hop parameter (NH). The K8NB and the NH are derived from the AMF key KAMF. An NH Chaining Counter (NCC) parameter is associated with each K8NB and NH parameter. Every KgNB is associated with the NCC corresponding to the NH value from which it was derived.

[0061] As further shown in procedure 300, at initial setup, the K8NB is derived directly from KAMF, and is then considered to be associated with a virtual NH parameter with an NCC value equal to zero. Further, at initial setup, the derived NH value is associated with the NCC value one. At the UE, the NH derivation associated with NCC= I could be delayed until the first handover performing vertical key derivation. The decision by the AMF to send the K8NB key or the [NH, NCC] pair to the serving gNB is described in further detail in the above-referenced TS 33.501. The AMF does not send the NH value to gNB at the initial connection setup. The gNB initializes the NCC value to zero after receiving a Next Generation Application Protocol (NGAP) Initial Context Setup Request message. Since the AMF does not send the NH value to gNB at the initial connection setup, the NH value associated with the NCC value one cannot be used in the next Xn handover or the next intra-gNB handover, for the next Xn handover or the next intra-gNB -CU handover the horizontal key derivation will apply. Note that CU refers to Centralized Unit which provides support for the higher layers of the protocol stack such as, by way of example, SDAP (Service Data Adaption Protocol), PDCP (Packet Data Convergence Protocol) and RRC (Radio Resource Control) layers, while DU refers to Distributed Unit which provides support for the lower layers of the protocol stack such as RLC (Radio Link Control), MAC (Medium Access Control), and Physical layers. Note that, in some examples, an intra- gNB handover occurs between cells of the same gNB, while inter-gNB handover occurs between cells of different gNBs.

[0062] One of the rules specified for the AMF in the above-referenced TS 33.501 states that the AMF always computes a fresh [NH, NCC] pair that is given to the target gNB. An implication of this is that the first [NH, NCC] pair will never be used to derive a K8NB. It only serves as an initial value for the NH chain. The UE and the gNB use the K8NB to secure the communication between each other. On handovers and at transitions from RRC_INACTIVE to RRC_CONNECTED states, the basis for the K8NB that will be used between the UE and the target gNB, called KNG-RAN*, is derived from either the currently active K8NB or from the NH parameter. If KNG-RAN* is derived from the currently active K8NB, this is referred to as a horizontal key derivation, and if the KNG-RAN* is derived from the NH parameter, the derivation is referred to as a vertical key derivation. As NH parameters are only computable by the UE and the AMF, it is arranged so that NH parameters are provided to gNB from the AMF in such a way that forward security can be achieved. On handovers with vertical key derivation, the NH is further bound to the target PCI (Physical Cell Identifier) and its frequency ARFCN-DL (Absolute Radio-Frequency Channel Number for Down Link) before it is taken into use as the KgNB in the target gNB. On handovers with horizontal key derivation, the currently active K8NB is further bound to the target PCI and its frequency ARFCN-DL before it is taken into use as the KgNB in the target gNB.

[0063] Accordingly, in summary, for both horizontal and vertical key derivation, PCI and DL frequency is used. Horizontal key derivation makes use of the previous key. Vertical key derivation does a refresh through use of NH. The vertical key generation is used to separate key space of each RAN node. The NH value is provided to the RAN node by the AMF. The vertical keys generated by each RAN node use a fresh NH value provided by AMF. Thus, the security domain is detached from the previous RAN node. In short, for horizontal key derivation, the inputs are the current KgNB (current active key), PCI, and DL frequency, and the output is the K8NB. In vertical key derivation, the inputs are a fresh NH value (provided by the AMF to the serving RAN node after path switch), PCI, and DL frequency, and the output is the KgNB-

[0064] Given the key chaining procedure 300, FIG. 4 illustrates a typical LTM handover procedure 400 (procedure 400) including steps 1-29 and involving a UE 402, a gNBl (source gNB) 404, a gNB2 (target gNB) 406, and an AMF 408. In this example, it is assumed that the UE 402 has NCC value as “0” and that the handover the UE 402 had was an intra-gNB handover, so the NCC value is not incremented after the handover. Assume that the key UE 402 uses is K8NB-A.

[0065] Using the received measurement report, the RAN node determines that an inter-gNB handover is appropriate (e.g., the measurement report for the target cell indicates a target cell at another gNB ). The source gNB, gNBl 404, generates the target key K8NB as K8NB-B, and sends the current NCC value “0” and the new key K8NB-B to the target gNB, gNB2 406, along with the handover request.

[0066] The target gNB, gNB2 406, receives the NCC value “0”, and embeds this in the target cell configuration. The target cell configuration is sent to the source gNB, gNBl 404, with a handover request acknowledgement message. The key K8NB-B is stored by the target gNB, gNB2 406, for later use. The source gNB, gNBl 404, then forms the handover command, encapsulating the target cell configuration and sends this to the UE 402. The UE 402 receives and decodes the handover command.

[0067] The UE 402 determines that the NCC value stayed the same at “0”. The UE 402 thus determines to perform the horizontal key generation, and uses the current key K8NB-A, the PCI, and the DL frequency of the target gNB, gNB 2406, to generate the K8NB-B. Since the algorithm at the UE side and network side are the same, a matching K8NB-B is independently generated by the UE 402 and the network.

[0068] The UE 402 encodes its message using K8NB-B and sends the message to the gNB2 406. The gNB2 406 sends the path switch request to the AMF 408. The AMF 408 increments the NCC value for the UE 402. The AMF 408 generates a fresh NH value, and sends the incremented NCC value and the new NH value to the gNB2 406. The gNB2 406 stores the NH and the NCC value but does not use them. The gNB2 406 at this point has become the serving gNB of the UE 402.

[0069] After some time period, the UE 402 may send another measurement report. This report may indicate that another target cell, this time in the same gNB, has become a strong candidate for handover. The gNB2 406 decides to trigger intra-gNB handover. The gNB2 406 determines to generate a vertical key as the stored NCC value is incremented. The gNB2 406 uses the NH value, PCI, and DL frequency to generate the KgNB-c. The gNB2 406 stores the KgNB-c- The gNB2 406 puts the incremented NCC value “1” in the target cell configuration and compiles the handover command, i.e., HO Command, and sends the HO Command to the UE 402.

[0070] The UE 402 decodes the HO command and sees that the NCC value is incremented to “1”. The UE 402 uses vertical key generation, and generates a fresh NH value using an algorithm preconfigured by the AMF 408 to the UE. The NH value generated by the UE 402 and the AMF 408 are mapped to one another as the same algorithm is used. The UE 402 then uses the NH value, PCI, and DL frequency to generate the target key, KgNB-c- The UE 402 ciphers the message with the newly generated key, then sends the ciphered message to the gNB2 406. The gNB2 406 uses the stored K8NB-C to decode the message of the UE 402.

[0071] Accordingly, as described above in procedure 400, the key to generate is indicated with the NCC value after each cell change in the handover command to the UE 402. However, it would be desirable in an LTM switching context that the candidate cell configurations are reused without a new RRC reconfiguration message. In case the same NCC value is used over and over again, only horizontal key derivation would be possible. Thus, procedure 400 is not aligned with the desired security paradigm as different gNBs need a fresh key with a new NH value.

[0072] Such a non-reconfiguration solution, for example, would provide both processing and overhead savings due to less signaling between components, as well as security enhancements in that less signaling between components would provide less opportunities for malicious actors to attempt to intercept signals or otherwise attack components in the communication network environment.

[0073] Illustrative embodiments provide the above and other technical solutions by providing an enhanced procedure for the source gNB to request the NH hopping pattern or sequence for the UE, for the subsequent LTM handover and also the new NH values, e.g., an LTM container with 2 NCC values, one NCC value for the current LTM handover and another NCC value for a subsequent handover. Both an LTM container and a Non-Access Stratum (NAS) container are passed to the UE in a preparation phase of the RRC reconfiguration message. The RRC module passes the NAS container for deciphering and integrity verification at the NAS module. After deciphering, the NH hopping pattern is passed to the RRC module. The RRC module also retrieves the two NCC values from the LTM container which are used for the current LTM handover and a subsequent one. In some illustrative embodiments, a list of NH values and associated NCC values can be provided to the UE to derive a fresh key for each subsequent handover. This can be accomplished via the source gNB obtaining a list of NH values and associated NCC values from the AMF.

[0074] In one non-limiting example, assume the AMF sends two NCC and NH values to the source gNB, e.g., one key is for the serving cell and the next NH value is for candidate cells, to perform vertical key derivation while doing an inter-gNB handover. Accordingly, from the UE perspective, there are several options: (i) after each inter-gNB handover, the UE is updated with new NCC values; (ii) the UE is aware that it should perform a vertical key update for each inter-gNB handover; and (iii) the UE does no key update during an intra-gNB handover. From the network perspective, a path switch provides two keys and the source gNB indicates to all neighbor cells the vertical keys prepared by the second NH value or indicates the NH value itself. Also, from the network perspective, no key update occurs for an intra-gNB handover.

[0075] FIG. 5 illustrates an enhanced lower layer-triggered mobility (LTM) handover procedure (e.g., procedure 500) in a communication network environment according to an illustrative embodiment. As will be evident, while procedure 400 fails to do so, procedure 500 enables the above-mentioned desired security paradigm in the LTM switching context.

[0076] Procedure 500 involves a UE 502, a source gNB 504, a target gNB 506, and an AMF 508. Source gNB 504, as shown in a disaggregated architecture, includes a source DU (s-DU), a source CU for the user plane (s-DU-UP), and a source CU for the control plane (s-DU-CP). Similarly, target gNB 506 in a disaggregated architecture includes a target DU (t-DU), a target CU for the user plane (t-DU-UP), and a target CU for the control plane (t-DU-CP).

[0077] As will be described below in further detail in the steps of procedure 500, the source gNB 504 sends a path switch request (early path switch request message) for the LTM handover to the AMF 508. The AMF 508 prepares two containers, e.g., a NAS container and an LTM container, and both containers are sent to the source gNB 504. The NAS container includes the NH hopping pattern for the UE 502 and it is used for the subsequent LTM handover(s). The LTM container contains two sets of NCC and NH values: one NCC for the current LTM handover and another NCC is for the next immediate handover. The source gNB 504 sends LTM handover request with the LTM container along with generated security key to the target gNB 506. The source gNB 504 sends the two containers to the UE 502 in a message when triggering the handover. The UE 502 fetches the NH hopping pattern from the NAS container, which is used by the UE 502 for key generation in a subsequent LTM handover(s).

[0078] More particularly, as shown in FIG. 5, procedure 500 includes a preparation phase including steps 1-19, a synchronization (sync) phase including steps 20-22, and an execution phase including steps 23-39.

[0079] The UE context for UE 502 within the source gNB 504 contains information regarding roaming and access restrictions which were provided either at connection establishment or at the last Timing Advance (TA) update. In the preparation phase of procedure 500, the source gNB 504 configures the UE measurement procedures and the UE 502 reports according to the measurement configuration. The source gNB 504 decides to handover the UE 502, based on the measurement report and RRM (Radio Resource Management) information. The source gNB 504 does the LTM preparation of candidate cells.

[0080] The source gNB 504 sends the path switch request (early path switch request message) for the LTM handover to the AMF 508. The AMF 508 prepares two containers. Alternatively, the AMF 508 can receive the initial UE message or a separate message used for LTM security key fetching.

[0081] The NAS container contains the NH hopping pattern or sequence for the UE 502 and this is used for the subsequent LTM handovers. The NH hopping pattern is ciphered using the existing UE context key NAS ciphering key KNASenc and NAS integrity protected using KNASint key. This container is intended for the source gNB 504.

[0082] The LTM container contains two sets of NCC and NH values and is sent from the AMF 508 to the source gNB 504. One NH value is used for the current LTM handover, and another is used for the next immediate handover. By way of one non-limiting example, in the LTM container, the AMF 508 sends NCC as 0 and NCC as 1 (two sets of NCC values) along with NH values to the source gNB 504. After two LTM handovers, the UE does not need any NCC or NH value as the pattern increments NCC by 3 is already communicated in the NAS container. Accordingly, the source gNB 504 will fetch this data during the third handover from the AMF 508, whereas the UE 502 knows the pattern already.

[0083] The source gNB 504 sends the LTM handover request with the LTM container with two NCC values along with the generated KNG-RAN* to the target gNB 506. The admission control may be performed by the target gNB 506. Slice-aware admission control is performed in response to the slice information being sent to the target gNB 506.

[0084] After the bearer context setup is completed, the LTM handover response is sent with the LTM container towards the source gNB 504.

[0085] The source gNB 504 triggers the handover by sending a message to the UE 502 containing the information required to access the target cell, i.e., at least the target cell ID, the new C-RNTI (Cell Radio Network Temporary Identifier), the target gNB security algorithm identifiers for the selected security algorithms, and the two containers (i.e., the LTM container and the encrypted NAS container).

[0086] The network may indicate the NCC value or a separate identifier to indicate that the UE 502 should do horizontal or vertical key generation.

[0087] The RRC module of UE 502 sends the NAS container to the NAS module of the UE 502 and the NAS keys are used to integrity check the received container content. After verification is completed, the NAS content is deciphered. The NAS module sends the NH hopping pattern to the RRC module for subsequent LTM handovers.

[0088] After each path switch update is done by a target cell, each next key (K8NB) calculated using the NH value received from the AMF 508 is indicated to all candidate gNBs.

[0089] During the execution phase, the previously fetched NH value is used for the subsequent switching procedure.

[0090] More specifically, consistent with the above illustrative description of the enhanced LTM procedure, the steps of procedure 500 of FIG. 5 are as follows.

[0091] Step 1 : A preparation phase is initiated.

[0092] Step 2: The UE 502 sends an L3 measurement report to the s-DU of the source gNB 504 according to the measurement configuration.

[0093] Step 3: The s-DU performs a UL RRC message transfer to send the L3 measurement report to the s-CU-CP of the source gNB 504.

[0094] Step 4: The source gNB 504 performs the LTM preparation of candidate cells at the s- CU-CP. Steps 5a, 5b, 5c, and 5d: A path switch request (“early” path switch request message introduced for the LTM HO use case) is sent from the s-CU-CP of the source gNB 504 to the AMF 508 for the LTM handover. The AMF 508 then prepares two containers. The NAS container contains a NH hopping pattern or sequence for the UE 502 (and for subsequent LTM handovers). The hopping pattern is ciphered using existing UE 502 context NAS keys. As a result, the AMF 508 sends a path switch response containing an LTM container and the ciphered NAS container back to the s-CU-CP of the source gNB 504. The s-CU-CP of the source gNB 504 then sends a LTM handover request to the t-CU-CP of the target gNB 506 with the LTM container and with the generated KNG-RAN*.

[0095] Step 6: Admission control is performed by the target gNB 506 (Target CU-CP of target gNB).

[0096] Steps 7 and 8: After bearer context setup request / response is completed between the t- CU-UP and the t-CU-CP of the target gNB 506, the Fl UE 502 context is set up.

[0097] Step 9: An LTM handover response is then sent from the t-CU-CP of the target gNB 506 to the s-CU-CP of the source gNB 504 with the data forwarding information and the LTM container.

[0098] Step 10: An Fl UE 502 context modification procedure is performed between the s- CU-CP and the s-DU of the source gNB 504.

[0099] Step 11 : A bearer context modification request / response procedure is completed with the data forwarding information between the s-CU-UP and the s-CU-CP in the source gNB 504.

[0100] Step 12: The RRC configuration is generated based on the measurement configuration and the prepared cell configuration at the source gNB 504.

[0101] Step 13: A DL RRC message transfer with the RRC message is sent from the s-CU-CP to the s-DU in the source gNB 504.

[0102] Steps 14a and 14b: The s-DU sends an RRC reconfiguration to the UE 502 with the LTM container and the encrypted NAS container. In response, the RRC module of UE 502 fetches the NH hopping pattern from the NAS container after decryption.

[0103] Step 15 and 16: The RRC reconfiguration is completed and an acknowledgement is sent from the UE 502 to the s-DU of the source gNB 504, which then sends a UL RRC message transfer to the s-CU-CP in the source gNB 504. Step 17: An early SN status transfer is sent from the s-CU-CP of the source gNB 504 to the t-CU-CP of the target gNB 506.

[0104] Step 18: A bearer context modification request / response is exchanged between the t- CU-UP and the t-CU-CP in the target gNB 506.

[0105] Step 19: Early data forwarding is sent from the AMF 508 to the s-CU-UP of the source gNB 504 and then sent to the t-CU-UP of the target gNB 506.

[0106] Step 20: A synchronization phase of the LTM handover begins.

[0107] Step 21: A PDCCH (Physical Downlink Control Channel) order is sent to the UE 502 from the s-DU of the source gNB 504.

[0108] Step 22: The UE 502 and the t-CU-UP of the target gNB 506 use a RACH (Random Access Channel) mechanism to acquire the target cell TA.

[0109] Step 23: An execution phase of the LTM handover begins.

[0110] Step 24: The L3 measurement report is sent from the UE 502 to the s-DU of the source gNB 504.

[0111] Steps 25, 26, and 27: The s-DU of the source gNB 504 sends a MAC control element (MAC CE) cell change trigger with the TA of the target cell to the UE 502. The s-DU also sends a notification for serving cell change to the s-CU-CP in the source gNB 504. The s-CU- CP then sends a modification request / response to the s-CU-UP in the source gNB 504.

[0112] Step 28: The RRC reconfiguration is complete and an acknowledgment is sent from the UE 502 to the t-DU of the target gNB 506.

[0113] Steps 29, 30, and 31: A UL RRC message transfer is sent from the t-DU to the t-CU- CP in the target gNB 506 along with an access notification. In response, the LTM handover is complete and an acknowledgement is sent from the t-CU-CP of the target gNB 506 to the s- CU-CP of the source gNB 504.

[0114] Step 32: A bearer context modification request / response is exchanged between the t- DU and the t-CU-CP of the target gNB 506.

[0115] Step 33: A path switch procedure is initiated between the AMF 508 and the t-CU-CP of the target gNB 506 and the NH value is used for subsequent switching.

[0116] Step 34: An end marker packet is sent from the AMF 508 to the s-CU-UP of the source gNB 504 and then forwarded to the t-CU-UP of the target gNB 506. Steps 35 and 36: A new path is sent from the AMF 508 to the t-CU-UP of the target gNB 506 and a UE 502 context release is sent from the t-CU-CP to the t-DU in the target gNB 506.

[0117] Steps 37 and 38: A bearer context release command is sent from the t-DU of the target gNB 506 to the s-CU-UP of the source gNB 504 and a Fl UE 502 context release procedure is completed between the s-DU of the source gNB 504 and the t-DU of the target gNB 506.

[0118] Step 39: The bearer context release is complete and an acknowledgement is sent from the s-CU-UP of the source gNB 504 to the t-DU of the target gNB 506.

[0119] FIG. 6 illustrates a table 600 for a non-limiting use case of procedure 500 with one source gNB (gNBl) and two candidate / target gNBs (gNB2 and gNB3).

[0120] It is to be appreciated that the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another.

[0121] It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, authorization processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

CLAIMS:

1. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a reconfiguration message from a radio access node with which the apparatus is connected, the reconfiguration message comprising handover-enabling data to enable the apparatus to perform two or more handover operations in response to the reconfiguration message.

2. The apparatus of claim 1, wherein the handover-enabling data comprises two or more sets of key derivation parameters respectively corresponding to the two or more handover operations.

3. The apparatus of claim 2, wherein each set of key derivation parameters comprises a next hop (NH) parameter and a corresponding next hop chaining counter (NCC) parameter.

4. The apparatus of claim 2, wherein the handover-enabling data further comprises a hopping pattern corresponding to the apparatus.

5. The apparatus of claim 1, wherein the handover-enabling data is received by the apparatus from the radio access node in a plurality of containers.

6. The apparatus of claim 5, wherein the plurality of containers comprises a non-access stratum (NAS) container and a lower layer-triggered mobility (LTM) container.

7. The apparatus of claim 1, wherein the two or more handover operations are lower lay er- triggered mobility (LTM) handover operations.

8. A method comprising: receiving, at user equipment, a reconfiguration message from a radio access node with which the user equipment is connected, the reconfiguration message comprising handover-enabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message; and utilizing, by the user equipment, the handover-enabling data to perform the two or more handover operations.

9. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: send a first request to a network node in a communication network in response to receipt of measurement data received from user equipment subscribed to the communication network; receive a first response from the network node including handover-enabling data to enable the user equipment to perform two or more handover operations; send a second request including at least a portion of the handover-enabling data to a candidate radio access node; receive a second response from the candidate radio access node; identify the candidate radio access node as a target radio access node based on the second response; and send a reconfiguration message to the user equipment comprising identifying information corresponding to the target radio access node and at least a portion of the handover-enabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message.

10. The apparatus of claim 9, wherein the handover-enabling data comprises two or more sets of key derivation parameters respectively corresponding to the two or more handover operations.

11. The apparatus of claim 10, wherein each set of key derivation parameters comprises a next hop (NH) parameter and a corresponding next hop chaining counter (NCC) parameter.

12. The apparatus of claim 10, wherein the handover-enabling data further comprises a hopping pattern corresponding to the user equipment.

13. The apparatus of claim 9, wherein the handover-enabling data is sent by the apparatus as a plurality of containers.

14. The apparatus of claim 13, wherein the plurality of containers comprises a non-access stratum (NAS) container and a lower layer-triggered mobility (LTM) container.

15. The apparatus of claim 9, wherein the two or more handover operations are lower lay er- triggered mobility (LTM) handover operations.

16. The apparatus of claim 9, wherein a handover operation responsive to the first request is between the user equipment and the target radio access node.

17. A method comprising: sending, from a first radio access node, a first request to a network node in a communication network in response to receipt of measurement data received from user equipment subscribed to the communication network; receiving, at the first radio access node, a first response from the network node including handover-enabling data to enable the user equipment to perform two or more handover operations; sending, from the first radio access node, a second request including at least a portion of the handover-enabling data to a candidate radio access node;receiving, at the first radio access node, a second response from the candidate radio access node; identifying, by the first radio access node, the candidate radio access node as a target radio access node based on the second response; and sending, from the first radio access node, a reconfiguration message to the user equipment comprising identifying information corresponding to the target radio access node and at least a portion of the handover-enabling data to enable the user equipment to perform two or more handover operations in response to the reconfiguration message.

18. An apparatus comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive a request from a radio access node to which user equipment is connected; generate, in response to the request, handover-enabling data to enable the user equipment to perform two or more handover operations in response to a reconfiguration message received by the user equipment from the radio access node; and send the handover-enabling data to the radio access node.

19. The apparatus of claim 18, wherein the handover-enabling data comprises two or more sets of key derivation parameters respectively corresponding to the two or more handover operations, and each set of key derivation parameters comprises a next hop (NH) parameter and a corresponding next hop chaining counter (NCC) parameter, and further wherein the handoverenabling data further comprises a hopping pattern corresponding to the user equipment.

20. A method comprising:receiving, at a network node of a communication network, a request from a radio access node to which user equipment is connected; generating, by the network node and in response to the request, handoverenabling data to enable the user equipment to perform two or more handover operations in response to a reconfiguration message received by the user equipment from the radio access node; and sending, from the network node, the handover-enabling data to the radio access node.

Images