Patent Description:
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions.

Fourth generation (<NUM>) 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 (<NUM>) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (IoT) networks.

While <NUM> networks are intended to enable massive IoT services (e.g., very large numbers of limited capacity devices) and mission-critical IoT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services intended to provide improved wireless Internet access for mobile devices.

Security during mobility of user equipment or UE (such as, for example, a mobile terminal or subscriber) between two networks (i.e., intersystem mobility) is an important consideration. For example, initial Non-Access Stratum (NAS) messages, e.g., registration messages, between the UE and a network are integrity protected by the UE if there is a current NAS security context in the UE that is valid and accepted by the network.

Today, in the scenario where the UE is moving between networks, e.g., interworking between a <NUM> network and <NUM> network, adequate integrity verification is not yet defined.

<CIT> discloses systems and methodologies which facilitate fetching a native security context between network nodes in a core network after an inter-system handover of a mobile device. For instance, a mobility message that is integrity protected by a security context (e.g., the native security context, a mapped security context,. ) can be obtained at a network node from the mobile device. Further, the network node can send a request to a disparate network node within a core network. The request can include information that can be used by the disparate network node to establish that the mobile device is authenticated. Moreover, the native security context can be received from the disparate network node in response to the request. Accordingly, the native security context need not be recreated between the network node and the mobile device.

<NPL> discloses a solution for interworking between NextGen Core and EPC, including proposed principles for interworking between EPC and 5GC.

<NPL> discloses content for NAS security clause <NUM>, based on key issue agreements <NUM> and <NUM>. NAS security keys are derived from KAMF whenever a new KAMF is established. It is possible to have more than one NAS bearers, one each over different access such as 3GPP access or non 3GPP access.

The present invention is as set out in the independent claims. Any examples/embodiments and features described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.

Illustrative embodiments provide improved techniques for secure intersystem mobility of user equipment in a communication system environment.

In one or more methods according to illustrative embodiments, in accordance with the occurrence of a mobility event whereby user equipment moves from accessing a source network to accessing a target network in a communication system environment, the user equipment sends a control plane message to the target network comprising an integrity verification parameter associated with the source network and an integrity verification parameter associated with the target network.

In another illustrative embodiment, in accordance with the occurrence of a mobility event whereby user equipment moves from accessing a source network to accessing a target network in a communication system environment, a mobility management element of the target network receives a control plane message from the user equipment comprising an integrity verification parameter associated with the source network and an integrity verification parameter associated with the target network.

In a further embodiment, in accordance with the occurrence of a mobility event whereby user equipment moves from accessing a source network to accessing a target network in a communication system environment, a mobility management element of the source network receives a context request message from a mobility management element of the target network when the mobility management element of the target network is unable to verify the user equipment based on a control plane message received from the user equipment comprising an integrity verification parameter associated with the source network and an integrity verification parameter associated with the target network.

Advantageously, by providing integrity verification parameters for both the source network and the target network in a control plane message sent by the user equipment to the mobility management element of the target network (e.g., a Registration Request message in <NUM> and a Tracking Area Update message in <NUM>), the mobility management element of the target network does not have to initiate a new Authentication and Key Agreement (AKA) run and thus, among other benefits, avoids performance degradation. Rather, the target network can verify the user equipment on its own or seek the assistance of the source network.

Further embodiments are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

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

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing security for user equipment during intersystem mobility that, among other benefits, avoids performance degradation of the core network. 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 3GPP system elements such as an LTE Evolved Packet Core (<NUM>) and a 3GPP next generation system (<NUM>), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems including, but not limited to, WiMAX systems and Wi-Fi systems.

In existing systems, a single Message Authentication Code (MAC) parameter is used to integrity protect the NAS message sent to a network. In the case of a mobility event (active mode mobility, i.e., handover, or idle mode mobility) from a source network to a target network, an initial NAS message is sent to the target network to trigger the mobility event. If the UE still has a valid security context for the target network, it will integrity-protect the NAS message using this security context and use the MAC parameter to send the generated MAC code to the target network. In existing approaches, the NAS-MAC parameter is a common parameter that either contains the authentication code to be verified by the source network or by the target network. This is no problem as long as source and target networks are both of the same type, say they are both LTE networks. It becomes a problem, however, when the source and target networks are of different types, say the source network is an LTE network and the target network is a <NUM> network; the problem is that the MACs used in LTE are (very likely) different from those that will be used in <NUM>. However, there exists no mechanism today for the UE to send two independent MACs for both the source and the target networks to verify integrity of the message, if required.

Thus, a problem with the current mechanism is that the UE does not know before-hand whether the initial integrity-protected message it sent to the target network can be successfully verified by the target network. It is possible that the target network has deleted the corresponding "native" security context for the UE. In such a scenario, there is no way for the target network to verify the message. In addition, the target network cannot rely on the source network to verify the message because there is no other field to carry the second MAC to be verified by the source network.

The only logical action for the target network would be to re-authenticate the UE again by executing a fresh Authentication and Key Agreement (AKA) run and then generate NAS and AS (Access Stratum) security keys through relevant procedures. Re-authentication has, however, a significant negative performance impact, so solutions that can avoid this would be preferred.

As illustratively used herein, Non-Access Stratum (NAS) is a functional layer of a communication network that provides non-radio signaling for certain control plane functionalities between the UE and a Core Network (CN), transparent to the Radio Access Network (RAN). Such functionalities include, but are not limited to, mobility management, authentication, etc. Compare the NAS functional layer to the Access Stratum (AS), which is the functional layer below NAS that provides functionalities between the UE and the RAN including, but not limited to, data transport over a wireless connection and radio resource management.

Illustrative embodiments provide improved techniques for intersystem mobility scenarios. More specifically, in one embodiment, a parameter is provided in the initial NAS message in <NUM> to carry an additional <NUM>-MAC for verification by the source network, if required. In another embodiment, similarly, both <NUM> and <NUM> verification parameters are provided when the UE is moving from the <NUM> network to the <NUM> network.

Before describing interworking scenarios with mobility from <NUM> to <NUM>, and from <NUM> to <NUM>, an exemplary communication system environment in which such illustrative embodiments are implemented is described in the context of <FIG> and <FIG>.

<NUM> security aspects are addressed in <NPL>,", and in <NPL>". Of particular interest are scenarios where the UE is moving from accessing a <NUM> network to accessing a <NUM> network, and in the converse, moving from accessing a <NUM> network to accessing a <NUM> network. Such movement between different generation communication networks is generally referred to herein as "intersystem mobility. " In addition to security concerns, of course, performance degradation is also a concern for such networks, i.e., in the context of avoiding additional processing overhead when possible.

<FIG> shows a communication system environment <NUM> within which illustrative embodiments are implemented. More particularly, communication system environment <NUM> shows part of (P/O) a <NUM> network and part of a <NUM> network. It is assumed that a UE <NUM> is involved in a mobility event (active mode mobility, i.e., handover, or idle mode mobility) from a source network (i.e., from one of the <NUM> network and the <NUM> network) to a target network (i.e., to the other of the <NUM> network and <NUM> network). It is to be understood that the elements shown in communication system environment <NUM> are intended to represent main functions provided within the system, e.g., UE access functions and mobility management functions. As such, the blocks shown in <FIG> reference specific elements in LTE and <NUM> networks that provide the 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 an LTE or <NUM> network are depicted in <FIG>. Rather, functions that facilitate an explanation of illustrative embodiments are represented.

Accordingly, as shown in <FIG>, communication system environment <NUM> comprises user equipment (UE) <NUM> that communicates via an air interface <NUM> with an access point (e.g., evolved Node B or eNB in a <NUM> network) <NUM> in the part of the <NUM> network shown in <FIG>. The UE <NUM> may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, 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 communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE <NUM> is comprised of a Universal Integrated Circuit Card (UICC) and a Mobile Equipment (ME). 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 the International Mobile Subscriber Identity (IMSI) number and its related key which are used to 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.

The access point <NUM> is illustratively part of an access network of the <NUM> network. Such an access network may comprise a plurality of base stations. The base stations may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or femto cellular access point. In an LTE (<NUM>) network, the access network is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). In general, the access point provides access for the UE to a Core Network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

The access point <NUM> in this illustrative embodiment is operatively coupled to a mobility management function <NUM>. In a <NUM> network, the function is typically implemented by a Mobility Management Entity (MME). A mobility management function, as used herein, is the element or function in the CN part of the communication system that manages, among other network operations, access and authentication operations with the UE (through the access point <NUM>).

Similarly, in the <NUM> network as shown in <FIG>, the UE <NUM> may alternatively communicate via an air interface <NUM> with an access point (e.g., gNB in a <NUM> network) <NUM>. For example, the <NUM> System is described in <NUM> Technical Specification (TS) <NUM>, V0. <NUM>, entitled "Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System".

The access point <NUM> in this illustrative embodiment is operatively coupled to a mobility management function <NUM>. In a <NUM> network, the function is implemented by an Access and Mobility Management Function (AMF). Although not expressly shown, a Security Anchor Function (SEAF) can be implemented with the AMF connecting a UE with the mobility management. Thus, KSEAF in <NUM> would take over the role of the Access Security Management Entity Key (KASME) in LTE.

It is to be appreciated that this particular arrangement of system elements in <FIG> 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 system environment <NUM> may comprise authentication elements, gateway elements, as well as other elements not expressly shown herein.

Accordingly, the <FIG> arrangement is just one example configuration of a wireless cellular system environment, and numerous alternative configurations of system elements may be used. For example, although only single UE, eNB/gNB, and MME/AMF elements are shown in the <FIG> 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.

It is also to be noted that while <FIG> illustrates system elements as singular functional blocks, the various subnetworks that make up the <NUM> network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of function sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service, and mission-critical IoT 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 <NUM> is configured to access one or more of these services via gNB <NUM>.

<FIG> shows a more detailed view of MME <NUM> and AMF <NUM> in an illustrative embodiment. The MME <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the MME <NUM> includes a secure intersystem mobility processing module <NUM> that may be implemented at least in part in the form of software executed by the processor. The processing module <NUM> performs operations of the processes described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the MME <NUM> includes a secure intersystem mobility storage module <NUM> that stores data generated or otherwise used during secure intersystem mobility operations.

The AMF <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the AMF <NUM> includes a secure intersystem mobility processing module <NUM> that may be implemented at least in part in the form of software executed by the processor. The processing module <NUM> performs operations described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the AMF <NUM> includes a secure intersystem mobility storage module <NUM> that stores data generated or otherwise used during secure intersystem mobility operations.

The processors <NUM> and <NUM> of the respective MME <NUM> and AMF <NUM> may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

The memories <NUM> and <NUM> of the respective MME <NUM> and AMF <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> to implement at least a portion of the functionality described herein. For example, 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 <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> 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 processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage 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 processor-readable storage media.

The memory <NUM> or <NUM> may more particularly comprise, for example, an 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), phase-change 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.

The interface circuitries <NUM> and <NUM> of the respective MME <NUM> and AMF <NUM> 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.

It is apparent from <FIG> that MME <NUM> is configured for communication with AMF <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves the MME <NUM> sending data to the AMF <NUM>, and the AMF <NUM> sending data to the MME <NUM>. However, in alternative embodiments, other network elements may be operatively coupled between MME <NUM> and AMF <NUM>. That is, the mobility management elements/functions of the two networks can communicate with each other directly, indirectly through one or more intermediate network elements/functions, or some combination of both. 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 user equipment and a core network via a base station element including, but not limited to, NAS messages, MAC codes, other verification parameters, etc..

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations may be used in other embodiments. For example, the mobility management elements/functions can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements, such as UE <NUM>, eNB <NUM>, and gNB <NUM>, may each also be configured to include components such as a processor, memory and network interface. These elements 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. Such a processing platform may additionally comprise at least portions of an eNB/gNB and an associated radio network control function.

Before describing message flows associated with embodiments of the secure intersystem mobility procedures, interworking scenarios with mobility from a <NUM> network to a <NUM> network are described, followed by interworking scenarios with mobility from a <NUM> network to a <NUM> network.

In a first scenario (<NUM> to <NUM>), assume that the <NUM> network is the source network and the <NUM> network is the target network. The UE has a valid <NUM> NAS security context (as the UE has been registered in the <NUM> network up to the mobility event), and the UE may have a <NUM> NAS security context still stored from a previous visit to the <NUM> network.

According to illustrative embodiments, when the UE moves from a <NUM> network to a <NUM> network, and the UE still has a <NUM> NAS security context, then the UE includes two different MAC parameters in the initial NAS message:.

If the <NUM> target network does not possess the corresponding <NUM> NAS security context for the UE and therefore cannot verify the message, the target network forwards the complete <NUM> initial NAS message, including the <NUM>-MAC parameter, but excluding the <NUM>-MAC parameter, to the <NUM> source network for further action.

In an alternative approach, the UE and the <NUM> target network map the <NUM> initial NAS message to a message that has the structure of a <NUM> Tracking Area Update (TAU) or <NUM> Attach message. The UE then computes the <NUM>-MAC over the mapped message while the UE computes the <NUM>-MAC over the entire <NUM> initial NAS message. This mapping could be achieved, e.g., by selecting an appropriate subset of the <NUM> initial NAS message, or by other means. The alternative approach is required for interworking with so-called legacy MMEs in <NUM> that have not been upgraded to support interworking with <NUM>. Such legacy MMEs can only handle messages that have the structure of a <NUM> message. But the alternative approach could also be applied to interworking with MMEs that are not legacy.

The <NUM> source network verifies the integrity of the message based on the received <NUM>-MAC parameter. If the verification is successful, the <NUM> network generates a key to be used in the target network and sends it to the <NUM> target network. This key could either be a mapped key when the MME has been upgraded to support interworking with <NUM>, or a KASME key (as defined in the LTE security specification TS <NUM>) when the MME is a legacy MME.

The <NUM> target network implies from the response that the message has been verified by the <NUM> source network and subsequently uses the received key to generate a new set of <NUM>-NAS keys. An existing NAS security mode command procedure is used to complete the key setup in the UE.

In a second scenario (<NUM> to <NUM>), assume that the MME in the target <NUM> network has been upgraded to support interworking with <NUM> networks. Recall from above, that according to illustrative embodiments, two different MAC parameters, a <NUM>-MAC and a <NUM>-MAC, are sent in the initial NAS message by the UE. It is further assumed the MME in the <NUM> network has been upgraded to support interworking with <NUM> networks and understands the purpose of the two different MAC parameters.

<FIG> and <FIG> illustrate message flows and network configurations within which one or more of the above-described secure intersystem mobility techniques can be implemented. These message flows and network configurations are understood to be illustrative embodiments.

<FIG> illustrates a UE mobility event from a <NUM> source network to a <NUM> target network. More particularly, the example in <FIG> shows an idle mode mobility event from <NUM> to <NUM>. The procedure depicts how two MACs are sent in the initial NAS message (Registration Request) and used during the mobility event to verify the UE either in the source network (<NUM>) or in the target network (<NUM>). <FIG> shows, in procedure <NUM>, UE <NUM>, gNB <NUM>, <NUM> Target System (AMF) <NUM>, and <NUM> Source System (MME) <NUM>. The numbered steps referred to below correspond to the numbers <NUM> through <NUM> in <FIG>. It is to be understood that in an idle mode mobility procedure, radio functions such as an eNB and a gNB do not necessarily take an active role.

In step <NUM>, UE <NUM> initiates a mobility registration update with a Registration Request (RR) message sent to AMF <NUM> through gNB <NUM>.

As shown, UE <NUM> includes the mapped <NUM>-GUTI derived from the <NUM>-GUTI, and KSI equal to the value of the eKSI associated with the current Evolved Packet System (EPS) security context, and a <NUM>-bit NONCEUE, in the Registration Request message. As is known, GUTI refers to a Globally Unique Temporary Identity, and KSI is Key Set Identifier.

The mapped <NUM>-GUTI has enough information to identity the <NUM>-GUTI and MME <NUM>.

If the UE <NUM> has a current <NUM> NAS security context, then UE <NUM> integrity-protects the message using this context and includes the <NUM>-KSI, native <NUM>-GUTI and <NUM>-MAC in the Registration Request message. The UE <NUM> uses the current <NUM> NAS security context algorithms to generate the <NUM>-MAC for the Registration Request message.

The UE <NUM> additionally integrity-protects the message by generating a <NUM>-MAC using the current <NUM> NAS integrity identified by the <NUM>-GUTI used to derive a mapped <NUM>-GUTI. The <NUM>-MAC field is used to store the generated <NUM>-MAC. As indicated for an alternative embodiment above, the UE may alternatively compute the <NUM>-MAC over a message mapped from the entire <NUM> initial NAS message.

In step <NUM>, if the <NUM>-GUTI was included in the message along with <NUM>-KSI, the AMF <NUM> searches for the already existing UE context stored and, if available, uses it to verify the Registration Request using the <NUM>-MAC parameter.

In step <NUM>, the AMF <NUM> uses the mapped <NUM>-GUTI received from the UE to derive the MME address and sends a Context Request message to the MME <NUM> to retrieve user information.

The AMF <NUM> forwards the complete Registration Request message, or alternatively only the message mapped from the complete Registration Request message, except for the <NUM>-MAC, but including the "UE validated" field and the <NUM> GUTI to the MME <NUM> with the Context Request message. It includes the <NUM>-MAC and eKSI if and only if the UE <NUM> could not be validated in step <NUM> by checking the <NUM>-MAC. The "UE validated" field is used to indicate whether the AMF <NUM> has validated the integrity protection of the Registration Request based on the native <NUM> context.

In step <NUM>, if the Registration Request message, or the mapped message, as received by the MME <NUM>, was protected with a <NUM> MAC, the MME <NUM> verifies the integrity protection of the Registration Request message, or the mapped message, based on the current <NUM> security context identified by the eKSI value it received from the AMF <NUM>. If the verification was successful, the MME <NUM> proceeds to step <NUM>.

In step <NUM>, MME <NUM> responds to the AMF <NUM> with a Context Response with the UE's security context. This message includes KASME, or a key mapped from KASME, if Context Request indicated that UE was not validated and <NUM>-MAC verification was successful. If the Context Response does not include KASME, or a key mapped from KASME, proceed to step <NUM>.

In step <NUM>, AMF <NUM> generates a new mapped KAMF using the KASME key, or the key mapped from KASME, it obtained from the MME <NUM>, NONCEUE, and NONCEAMF and a <NUM> NAS security context is derived from the mapped KAMF key including NAS security keys. The AMF allocates KSI<NUM> to identify the mapped KAMF key.

In step 7a. , AMF <NUM> initiates a NAS Security mode command procedure as described in 3GPP Technical Specification TS <NUM>, including the KSI<NUM>, replayed UE Security capabilities, NONCEAMF, NONCEMME and NAS algorithms.

In step 7b. , UE <NUM> derives a mapped KAMF from its copy of KASME , or a key mapped from KASME, in the same way as the AMF did in step 7a. UE <NUM> further generates a new mapped <NUM> NAS Security context including NAS security keys from the mapped KAMF.

In step 7c. , UE <NUM> responds to the AMF <NUM> with the NAS Security Mode Complete message.

In step <NUM>, if the AMF <NUM> shares a current <NUM> NAS security context with the UE <NUM> and has successfully validated the UE (from step <NUM>), the AMF <NUM> proceeds to check if it needs to establish radio bearers. If the AMF <NUM> wants to change the NAS algorithms, the AMF <NUM> uses a NAS security mode procedure to inform the UE <NUM>. If the "active flag" is set in the Registration Request message or the AMF <NUM> choses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, a KgNB derivation is performed from the KAMF key.

The newly derived KgNB key is delivered to the target gNB on the S1 interface. The AS Security context is established between the gNB and the UE.

In step <NUM>, AMF <NUM> sends a Registration Accept message to the UE <NUM>.

In step <NUM>, UE <NUM> responds with a Registration Complete message to the AMF <NUM>.

As illustrated in the above procedure, an integrity check happens only once, either in the target AMF <NUM> in step <NUM> or in step <NUM> in the source MME <NUM>. Accordingly, a decision is made in the AMF <NUM> to either reuse the existing verified UE context or rely on the mapped key derived from the information sent by the source MME <NUM> to generate a new mapped UE context. NAS security mode command procedure is optional if the AMF <NUM> successfully verified the UE <NUM> with its own store of the UE security context.

<FIG> illustrates a UE mobility event from a <NUM> source network to a <NUM> target network. More particularly, the example in <FIG> shows call flow for the mobility scenario from a <NUM> source system to an upgraded <NUM> target system using the dual <NUM>-MAC and <NUM>-MAC in a tracking area update request. <FIG> shows, in procedure <NUM>, UE <NUM>, eNB <NUM>, <NUM> Upgraded Target System (MME) <NUM>, and <NUM> Source System (AMF) <NUM>. The numbered steps referred to below correspond to the numbers <NUM> through <NUM> in <FIG>.

In step <NUM>, UE <NUM> initiates a TAU (Tracking Area Update) Request message sent to MME <NUM> through eNB <NUM>.

As shown, UE <NUM> includes the mapped <NUM>-GUTI derived from the <NUM>-GUTI, and eKSI equal to the value of the NG-KSI associated with the current 5GS security context, and a <NUM>-bit NONCEUE, in the TAU Request message.

The mapped <NUM>-GUTI has enough information to identity the <NUM>-GUTI and AMF <NUM>.

If the UE <NUM> has a current <NUM> NAS security context, then UE <NUM> integrity-protects the message using this context and includes the eKSI, native <NUM>-GUTI and <NUM>-MAC in the TAU Request message. The UE <NUM> uses the current <NUM> NAS security context algorithms to generate the <NUM>-MAC for the TAU Request message.

The UE <NUM> additionally integrity-protects the message by generating a <NUM>-MAC using the current <NUM> NAS integrity identified by the <NUM>-GUTI used to derive a mapped <NUM>-GUTI. The <NUM>-MAC field is used to store the generated <NUM>-MAC.

In step <NUM>, if the <NUM>-GUTI was included in the message along with <NUM>-KSI, the MME <NUM> searches for the already existing UE context stored and, if available, uses it to verify the TAU Request using the <NUM>-MAC parameter.

In step <NUM>, the MME <NUM> uses the mapped <NUM>-GUTI received from the UE to derive the AMF address and sends a Context Request message to the AMF <NUM> to retrieve user information.

The MME <NUM> forwards the complete TAU Request message, except for the <NUM>-MAC, but including the "UE validated" field and the <NUM> GUTI to the AMF <NUM> with the Context Request message. It includes the <NUM>-MAC and NG-KSI if and only if the UE <NUM> could not be validated in step <NUM> by checking the <NUM>-MAC. The "UE validated" field is used to indicate whether the MME <NUM> has validated the integrity protection of the TAU Request based on the native <NUM> context.

In step <NUM>, if the Registration Request message parameters contained in the TAU Request message, as received by the AMF <NUM>, were protected with a <NUM> MAC, the AMF <NUM> verifies the integrity protection of the Registration Request message based on the current <NUM> security context identified by the NG-KSI value it received from the MME <NUM>. If the verification was successful, the AMF <NUM> proceeds to step <NUM>.

In step <NUM>, AMF <NUM> responds to the MME <NUM> with a Context Response with the UE's security context. This message includes KAMF if Context Request indicated that UE was not validated and <NUM>-MAC verification was successful. If the Context Response does not include KAMF, proceed to step <NUM>.

In step <NUM>, MME <NUM> generates a new mapped KASME using the KAMF key it obtained from the AMF <NUM>, NONCEUE, and NONCEAMF and a <NUM> NAS security context is derived from the mapped KASME key including NAS security keys. The AMF allocates eKSI<NUM> to identify the mapped KASME key.

In step 7a. , MME <NUM> initiates a NAS Security mode command procedure as described in 3GPP Technical Specification TS <NUM>, including the KSI<NUM>, replayed UE Security capabilities, NONCEAMF, NONCEMME and NAS algorithms.

In step 7b. , UE <NUM> derives a mapped KASME from its copy of KAMF in the same way as the MME did in step 7a. UE <NUM> further generates a new mapped <NUM> NAS Security context including NAS security keys from the mapped KASME.

In step 7c. , UE <NUM> responds to the MME <NUM> with the NAS Security Mode Complete message.

In step <NUM>, if the MME <NUM> shares a current <NUM> NAS security context with the UE <NUM> and has successfully validated the UE (from step <NUM>), the MME <NUM> proceeds to check if it needs to establish radio bearers. If the MME <NUM> wants to change the NAS algorithms, the MME <NUM> uses a NAS security mode procedure to inform the UE <NUM>. If the "active flag" is set in the TAU Request message or the MME <NUM> choses to establish radio bearers when there is pending downlink UP data or pending downlink signalling, a KeNB derivation is performed from the KASME key using the KDF as specified in TS <NUM>.

The newly derived KeNB key is delivered to the target gNB on the S1 interface. The AS Security context is established between the eNB and the UE.

In step <NUM>, MME <NUM> sends a TAU Accept message to the UE <NUM>.

In step <NUM>, UE <NUM> responds with a TAU Complete message to the MME <NUM>.

As illustrated in the above procedure, an integrity check happens only once, either in the target MME <NUM> in step <NUM> or in step <NUM> in the source AMF <NUM>. Accordingly, a decision is made in the MME <NUM> to either reuse the existing verified UE context or rely on the mapped key derived from the information sent by the source AMF <NUM> to generate a new mapped UE context. NAS security mode command procedure is optional if the MME <NUM> successfully verified the UE <NUM> with its own store of the UE security context.

In yet another embodiment, the source mobility management entity may be an unmodified <NUM> mobility management entity with no awareness of a <NUM> interworking. Such <NUM> unaware mobility management entities would be able to support interworking and context transfer to a target <NUM> network AMF, if the <NUM> target AMF canonically maps the received registration request message from the UE to the <NUM> equivalent Context request message containing TAU parameters along with the <NUM>-MAC from the UE. The <NUM> AMF performs this intelligent mapping to the Context Request and the Context response based on its awareness that the source <NUM> mobility management entity is <NUM> unaware. With this functionality, a <NUM> AMF will interwork with a <NUM> aware MME as well as non-aware MME.

It is to be appreciated that the naming of identifiers and parameters mentioned herein are for illustrative purposes only. That is, an identifier or parameter may have different names or acronyms in different protocols and standards for different communication network technologies. As such, none of the specific names or acronyms given to these identifiers herein are intended to limit embodiments in any manner.

As indicated previously, the embodiments are not limited to the LTE or <NUM> context and the disclosed techniques can be adapted in a straightforward manner to a wide variety of other communication system contexts including, but not limited to, other 3GPP systems and non-3GPP systems.

The processor, memory, controller and other components of a user equipment or base station element of a communication system as disclosed herein may include well-known circuitry suitably modified to implement at least a portion of the identity request functionality described above.

As mentioned above, embodiments may be implemented in the form of articles of manufacture each comprising one or more software programs that are executed by processing circuitry of user equipment, base stations or other elements of a communication system. Conventional aspects of such circuitry are well known to those skilled in the art and therefore will not be described in detail herein. Also, embodiments may be implemented in one or more ASICS, FPGAs or other types of integrated circuit devices, in any combination. Such integrated circuit devices, as well as portions or combinations thereof, are examples of "circuitry" as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

Claim 1:
A method comprising:
in accordance with the occurrence of a mobility event wherein a user equipment (<NUM>) moves from accessing a source network to accessing a target network in a communication system environment (<NUM>), the user equipment sending a control plane message to the target network comprising an integrity verification parameter associated with the source network and an integrity verification parameter associated with the target network;
wherein the user equipment (<NUM>) integrity protects the control plane message using a security context previously established with the target network,
wherein the integrity verification parameter associated with the target network is a message authentication code generated using the security context previously established with the target network.