Patent Description:
A current cellular network architecture <NUM>, shown in <FIG>, uses a mobility management entity (MME) <NUM> to implement procedures for controlling access to the cellular network by a user equipment (UE) <NUM>. Typically, the MME <NUM> is owned and operated by a network service provider (system operator) as a core network <NUM> element, and is located in a secure location controlled by the network service provider. The core network <NUM> has a control plane including a Home Subscriber Server (HSS) <NUM> and the MME <NUM>, and a user plane including a Packet Data Network (P-DN) Gateway (PGW) <NUM> and a Serving Gateway (S-GW) <NUM>. The MME <NUM> is connected to radio access node <NUM> (e.g., an evolved Node B (eNB)). The RAN <NUM> provides radio interfaces (e.g., radio resource control (RRC) <NUM> and packet data convergence protocol (PDCP)/radio link control (RLC) <NUM>) with the UE <NUM>.

In future cellular network architectures it is envisioned that the MMEs <NUM> or network components that perform many of the functions of the MMEs <NUM> will be pushed out towards the network edge where they are less secure either because they are physically more accessible and/or are not isolated from other network operators. As network functions are moved to, for example, the cloud (e.g., internet), it may not be assumed that they are secure because they may have a lower level of physical isolation, or no physical isolation. Further, network equipment may not be owned by a single network service provider. As an example, multiple MME instances may be hosted within a single physical hardware device. As a result, the keys sent to the MMEs may need refreshing more frequently and hence it may not be advisable to forward the authentication vectors (AVs) to the MMEs.

The article "<NPL>, concerns EAP and defines the key hierarchy and key derivations for using the EMSK hierarchy for keying in IP mobility protocols.

The Blog entry "<NPL>, provides an overview of LTE Authentication.

<CIT> represents further relevant prior art.

There is a need for improved apparatuses and methods that provide additional security for the cellular network architectures of the future where MME functions are performed close to the network edge.

One feature provides a method operational at a network device, the method comprising performing authentication and key agreement with a device, obtaining authentication information associated with the device, the authentication information including at least an authentication session key, generating a mobility session key based in part on the authentication session key, and transmitting the mobility session key to a mobility management entity (MME) serving the device. According to one aspect, the method further comprises generating different mobility session keys for different MMEs based on the authentication session key. According to another aspect, obtaining the authentication information includes determining that authentication information associated with the device is not stored at the network device, transmitting an authentication information request to a home subscriber server, and receiving the authentication information associated with the device from the home subscriber server in response to transmitting the authentication information request.

According to one aspect, obtaining the authentication information includes determining that authentication information associated with the device is stored at the network device, and retrieving the authentication information from a memory circuit at the network device. According to another aspect, the method further comprises receiving a key set identifier from the device, and determining that the authentication information associated with the device is stored at the network device based on the key set identifier received. According to yet another aspect, the method further comprises prior to performing authentication and key agreement with the device, receiving, from the MME, a non-access stratum (NAS) message originating from the device.

According to one aspect, the method further comprises generating the mobility session key based further in part on an MME identification value that identifies the MME. According to another aspect, the MME identification value is a globally unique MME identifier (GUMMEI). According to yet another aspect, the MME identification value is an MME group identifier (MMEGI).

According to one aspect, the method further comprises generating a different mobility management key for each MME serving the device, each of the different mobility management keys based in part on the authentication session key and a different MME identification value associated with each MME. According to another aspect, the method further comprises determining that, in connection to an MME relocation, a second MME is attempting to serve the device, generating a second mobility management key based in part on the authentication session key and an MME identification value associated with the second MME, and transmitting the second mobility management key to the second MME to facilitate MME relocation. According to yet another aspect, the method further comprises maintaining a counter value Key Count, and generating the mobility session key based further in part on a counter value Key Count. According to another aspect, generating the mobility session key includes deriving the mobility session key using a key derivation function having at least one of the authentication session key, an MME identification value uniquely identifying the MME, and/or a counter value Key Count as input(s).

Another feature provides a network device comprising a communication interface adapted to send and receive data, and a processing circuit communicatively coupled to the communication interface, the processing circuit adapted to perform authentication and key agreement with a device, obtain authentication information associated with the device, the authentication information including at least an authentication session key, generate a mobility session key based in part on the authentication session key, and transmit the mobility session key to a mobility management entity (MME) serving the device. According to one aspect, the processing circuit is further adapted to generate different mobility session keys for different MMEs based on the authentication session key. According to another aspect, the processing circuit adapted to obtain the authentication information includes determine that authentication information associated with the device is not stored at the network device, transmit an authentication information request to a home subscriber server, and receive the authentication information associated with the device from the home subscriber server in response to transmitting the authentication information request.

According to one aspect, the processing circuit is further adapted to generate the mobility session key based further in part on an MME identification value that identifies the MME. According to another aspect, the processing circuit is further adapted to prior to performing authentication and key agreement with the device, receiving, from the MME, a non-access stratum (NAS) message originating from the device. According to yet another aspect, the NAS message received includes a device identifier that identifies the device and an MME identification value that identifies the MME.

Another feature provides a network device comprising means for performing authentication and key agreement with a device, means for obtaining authentication information associated with the device, the authentication information including at least an authentication session key, means for generating a mobility session key based in part on the authentication session key, and means for transmitting the mobility session key to a mobility management entity (MME) serving the device. According to one aspect, the network device further comprises means for generating different mobility session keys for different MMEs based on the authentication session key.

Another feature provides a non-transitory computer-readable storage medium having instructions stored thereon that are operational at a network device, the instructions when executed by at least one processor causes the processor to perform authentication and key agreement with a device, obtain authentication information associated with the device, the authentication information including at least an authentication session key, generate a mobility session key based in part on the authentication session key, and transmit the mobility session key to a mobility management entity (MME) serving the device. According to one aspect, the instructions when executed by the processor further cause the processor to generate different mobility session keys for different MMEs based on the authentication session key.

Another feature provides a method operational at a network device, the method comprising receiving a non-access stratum (NAS) message from a device, forwarding the NAS message along with a network device identification value identifying the network device to a session key management entity (SKME) device, receiving a mobility session key from the SKME device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network, and transmitting key derivation data to the device, the key derivation data enabling the device to derive the mobility session key. According to one aspect, the mobility session key received from the SKME device is further based in part on the network device identification value. According to another aspect, the network device identification value is a globally unique mobility management entity identifier (GUMMEI).

According to one aspect, the network device identification value is a mobility management entity group identifier (MMEGI). According to another aspect, the mobility session key received from the SKME device is further based in part on a counter value Key Count maintained at the SKME device. According to yet another aspect, the key derivation data is included in a NAS security mode command message transmitted to the device.

According to one aspect, the key derivation data includes the network device identification value. According to another aspect, the key derivation data includes a counter value Key Count maintained at the SKME device. According to yet another aspect, the method further comprises determining that a second network device needs to serve the device, determining that the second network device shares a common group identifier with the network device, and transmitting the mobility session key to the second network device. According to yet another aspect, the network device and the second network device are mobility management entities (MMEs) and the common group identifier is a common MME group identifier.

Another feature provides a network device comprising a communication interface adapted to send and receive data, and a processing circuit communicatively coupled to the communication interface, the processing circuit adapted to receive a non-access stratum (NAS) message from a device, forward the NAS message along with a network device identification value identifying the network device to a session key management entity (SKME) device, receive a mobility session key from the SKME device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network, and transmit key derivation data to the device, the key derivation data enabling the device to derive the mobility session key. According to one aspect, the processing circuit is further adapted to determine that a second network device needs to serve the device, determine that the second network device shares a common group identifier with the network device, and transmit the mobility session key to the second network device.

Another feature provides a network device comprising means for receiving a non-access stratum (NAS) message from a device, means for forwarding the NAS message along with a network device identification value identifying the network device to a session key management entity (SKME) device, means for receiving a mobility session key from the SKME device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network, and means for transmitting key derivation data to the device, the key derivation data enabling the device to derive the mobility session key. According to one aspect, the network device further comprises means for determining that a second network device needs to serve the device, means for determining that the second network device shares a common group identifier with the network device, and means for transmitting the mobility session key to the second network device.

Another feature provides a non-transitory computer-readable storage medium having instructions stored thereon that are operational at a network device, the instructions when executed by at least one processor causes the processor to receive a non-access stratum (NAS) message from a device, forward the NAS message along with a network device identification value identifying the network device to a session key management entity (SKME) device, receive a mobility session key from the SKME device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network, and transmit key derivation data to the device, the key derivation data enabling the device to derive the mobility session key. According to one aspect, the instructions when executed by the processor further cause the processor to determine that a second network device needs to serve the device, determine that the second network device shares a common group identifier with the network device, and transmit the mobility session key to the second network device.

Another feature provides a method operational at a device, the method comprising performing authentication and key agreement with a session key management entity (SKME) device, generating an authentication session key based in part on a secret key shared with a home subscriber server (HSS), the authentication session key known to the SKME device, generating a mobility session key based in part on the authentication session key, the mobility session key known to a mobility management entity (MME) serving the device, and cryptographically securing data sent from the device to a wireless communication network using the mobility session key. According to one aspect, the method further comprises generating different mobility session keys for different MMEs based on the authentication session key. According to another aspect, the method further comprises receiving key derivation data from the MME after successfully authenticated with the SKME device, the key derivation data enabling the device to derive the mobility session key.

According to one aspect, the key derivation data includes an MME identification value identifying the MME serving the device, and the method further comprises generating the mobility session key based further in part on the MME identification value. According to another aspect, the key derivation data includes a counter value Key Count maintained at the SKME device. According to yet another aspect, the key derivation data is included in a security mode command message received from the MME.

According to one aspect, generating the mobility session key includes deriving the mobility session key using a key derivation function having at least one of the authentication session key, an MME identification value uniquely identifying the MME, and/or a counter value Key Count as input(s). According to another aspect, the method further comprises receiving notification of MME relocation including an MME identifier uniquely identifying a second MME attempting to serve the device, generating a second mobility session key based in part on the authentication session key and the MME identifier uniquely identifying the second MME. According to yet another aspect, the method further comprises deriving a node B key KeNB based in part on the mobility session key, and encrypting data transmitted to a radio access node serving the device using the node B key KeNB.

Another feature provides a device comprising a wireless communication interface adapted to send and receive data to and from a wireless communication network, and a processing circuit communicatively coupled to the wireless communication interface, the processing circuit adapted to perform authentication and key agreement with a session key management entity (SKME) device, generate an authentication session key based in part on a secret key shared with a home subscriber server (HSS), the authentication session key known to the SKME device, generate a mobility session key based in part on the authentication session key, the mobility session key known to a mobility management entity (MME) serving the device, and cryptographically secure data sent from the device to the wireless communication network using the mobility session key. According to one aspect, the processing circuit is further adapted to generate different mobility session keys for different MMEs based on the authentication session key. According to another aspect, the processing circuit is further adapted to receive key derivation data from the MME after successfully authenticated with the SKME device, the key derivation data enabling the device to derive the mobility session key. According to yet another aspect, the key derivation data includes an MME identification value identifying the MME serving the device, and the processing circuit is further adapted to generate the mobility session key based further in part on the MME identification value.

According to one aspect, generating the mobility session key includes deriving the mobility session key using a key derivation function having at least one of the authentication session key, an MME identification value uniquely identifying the MME, and/or a counter value Key Count as input(s). According to another aspect, the processing circuit is further adapted to receive notification of MME relocation including an MME identifier uniquely identifying a second MME attempting to serve the device, generate a second mobility session key based in part on the authentication session key and the MME identifier uniquely identifying the second MME.

Another feature provides a device comprising means for performing authentication and key agreement with a session key management entity (SKME) device, means for generating an authentication session key based in part on a secret key shared with a home subscriber server (HSS), the authentication session key known to the SKME device, means for generating a mobility management key based in part on the authentication key, the mobility management key known to a mobility management entity (MME) serving the device, and means for cryptographically securing data sent from the device to a wireless communication network using the mobility session key. According to one aspect, the device further comprises means for generating different mobility session keys for different MMEs based on the authentication session key.

Another feature provides a non-transitory computer-readable storage medium having instructions stored thereon that are operational at a device, the instructions when executed by at least one processor causes the processor to perform authentication and key agreement with a session key management entity (SKME) device, generate an authentication session key based in part on a secret key shared with a home subscriber server (HSS), the authentication session key known to the SKME device, generate a mobility session key based in part on the authentication session key, the mobility session key known to a mobility management entity (MME) serving the device, and cryptographically securing data sent from the device to a wireless communication network using the mobility session key. According to one aspect, the instructions when executed by the processor further causes the processor to generate different mobility session keys for different MMEs based on the authentication session key.

<FIG> illustrates a wireless communication network <NUM> according to one aspect of the disclosure. The wireless communication network <NUM> includes a core network <NUM>, a radio access node (e.g., eNB) <NUM>, and a wireless communication device (e.g., UE) <NUM>. The core network includes, among other things, a session key management entity (SKME) device <NUM> (may herein be referred to as "authentication session key anchor function device"), an MME <NUM>, an HSS <NUM>, a P-GW <NUM>, and an S-GW <NUM>. The SKME device <NUM>, the MME <NUM>, and the HSS <NUM> comprise the control plane, while the P-GW <NUM> and the S-GW <NUM> comprise the user plane. This architecture of the wireless communication network <NUM> may be used in a fifth generation (<NUM>) cellular network.

The radio access node <NUM> may be, for example, an evolved node B (eNB) and may communicate with the MME <NUM> and the UE <NUM>. The RAN <NUM> provides radio interfaces (e.g., radio resource control (RRC) <NUM> and packet data convergence protocol (PDCP)/radio link control (RLC) <NUM>) with the UE <NUM>.

The SKME <NUM> may be a trust anchor or key anchor located deep inside the wireless communication network <NUM>. The SKME <NUM> derives mobility session keys (e.g., key KASME) for each MME <NUM> it serves. (Although <FIG> illustrates only one (<NUM>) MME <NUM>, the SKME <NUM> may be in communication with and/or serve a plurality of MMEs. ) Thus, as MMEs <NUM> and/or network devices that perform the MMEs' functions are pushed to the network's edge (i.e., close to RAN or collocated with the RAN), the SKME <NUM> stays deep inside the network <NUM> where physical access from external entities is prohibited. In this fashion the SKME <NUM> acts as an intermediary between the MME <NUM> and the HSS <NUM>.

The HSS <NUM> generates an authentication session key (e.g., key KSKME) based on one or more secret keys (SK) shared between the UE <NUM> and the wireless communication network's authentication center (AuC) (not shown in <FIG>). The one or more secret keys shared may be, for example, a root key and/or a cipher key (CK) and an integrity key (IK) derived from root key. The authentication session key KSKME is sent to the SKME <NUM>, which in turn generates a mobility session key KASME based on, in part, the authentication session key KSKME. The SKME <NUM> then sends the mobility session key KASME to the MME <NUM> for which it was generated. Other keys, such as an eNB key KeNB may be derived from the mobility session key KASME and used to secure communications between the RAN <NUM> and the UE <NUM>.

<FIG> and <FIG> illustrate a process flow diagram <NUM> of the wireless communication network <NUM> according to one aspect of the disclosure. Some components (e.g., RAN <NUM>, P-GW <NUM>, S-GW <NUM>) of the network <NUM> have been omitted from <FIG> for clarity.

Referring to <FIG>, the process may begin with a UE <NUM> transmitting <NUM> a non-access stratum (NAS) message to an MME <NUM> (e.g., via a RAN <NUM> not shown in <FIG>). Among other things, the NAS message may be, for example, an attach request, a subsequent service request, or a tracking area update request. In some cases the NAS message may include a key set identifier (KSI) associated with the UE <NUM> and/or a device identifier (e.g., international mobile subscriber identity (IMSI)) that identifies the UE <NUM>. The MME <NUM> may then forward <NUM> the NAS message and the KSI (if included) to the SKME <NUM>. The SKME <NUM> may next determine <NUM> whether authentication information for the UE <NUM> is already stored at the SKME <NUM>. If it is, then the SKME <NUM> uses the stored authentication information (e.g., authentication vector) for the UE <NUM> to perform <NUM> authentication and key agreement (AKA) with the UE <NUM>. If it is not, the SKME <NUM> may transmit <NUM> an authentication information request to an HSS <NUM> requesting authentication information associated with the UE <NUM>. In response, the HSS <NUM> may provide <NUM> one or more authentication vectors (e.g., authentication information) to the SKME <NUM>. At least one of the authentication vectors provided is associated with the UE <NUM> and can be used to perform <NUM> AKA with the UE <NUM>. An authentication vector may include an expected response (XRES), an authentication value (AUTN), a random number (RAND), and an authentication session key KSKME may be referred to herein as "first authentication session key KSKME", "second authentication session key KSKME", etc.). The AUTN may be based on a sequence number and a secret key which the UE <NUM> shares with the HSS <NUM>.

The authentication session key KSKME may be generated at the HSS based in part on one or more secret keys shared between the UE and the AuC of the network. These secret keys may include the root key and/or a cipher key (CK) and an integrity key (IK) derived from root key. To further perform AKA, the SKME <NUM> may transmit an authentication request message (e.g., includes AUTN and RAND) to the UE <NUM> requesting an authentication response (RES). The SKME <NUM> may then compare RES to XRES for a match to determine whether authentication with the UE <NUM> was successful.

After successful completion of AKA <NUM>, the SKME <NUM> may identify <NUM> the appropriate authentication session key KSKME for the UE <NUM> based on the KSI (if any) provided by the UE <NUM>. This may be done if the SKME <NUM> receives a plurality of authentication vectors having a plurality authentication session keys KSKME from the HSS <NUM>. The SKME <NUM> may then derive/generate <NUM> a mobility management key KASME (e.g., "first mobility management key KASME", "second mobility management key KASME", "third mobility management key KASME", etc.). The mobility management key KASME may be based on the authentication session key KSKME, an MME identification value (e.g., globally unique MME identifier (GUMMEI), MME identifier (MMEI), MME group identifier (MMEGI), public land mobile network identifier (PLMN ID), MME code (MMEC), etc.), and/or a counter value (e.g., Key Count). Thus, KASME may be derived as KASME = KDF(KSKME, MME identification value | Key Count) where KDF is a key derivation function. The counter value Key Count is a counter value that may be incremented by the SKME <NUM> to enable the SKME <NUM> to derive a fresh KASME key for the same MME <NUM> whenever relocation back to the MME <NUM> occurs. According to one aspect, a number used once (nonce) may be used instead of the counter value Key Count. According to another aspect, the MME identification value (e.g., GUMMEI, MMEGI, MMEI, MMEC, PLMN ID, etc.) may be omitted if it's not used to authorize a particular MME identity. For example, if SKME <NUM> is always in the same network as the MMEs <NUM> it provides KASME to, then including the MME identification value in the key derivation may be unnecessary. Thus, according to another example, KASME may be derived as KASME = KDF(KSKME, nonce) or KASME = KDF(KSKME, Key Count). The MME identification value may be one example of a network device identification value.

Next, the SKME <NUM> may send <NUM> the mobility session key KASME to the MME <NUM> that it was generated for. The MME <NUM> may send <NUM> key derivation data (KDD) to the UE <NUM> to help the UE <NUM> generate the mobility session key KASME. According to one example, the key derivation data may be included in a non-access stratum (NAS) security mode command (SMC). The key derivation data may include the MME identification value (e.g., GUMMEI, MMEGI, MMEI, MMEC, PLMN ID, etc.), the counter value Key Count, and/or a nonce that were used to generate the key KASME. With this data, the UE <NUM> can then generate/derive <NUM> the key KASME and use it to secure communication, such as data traffic, between itself and the wireless communication network/serving network (e.g., MME <NUM>, SKME <NUM>, etc.). The MME <NUM> and the UE <NUM> may also generate/derive <NUM> subsequent keys (e.g., KeNB, KNASenc, KNASint, NK, etc.) based on the mobility management key KASME and use them to secure communications between the UE <NUM>, MME <NUM>, and/or the RAN (e.g., eNB) <NUM> serving the UE <NUM>.

According to one aspect, the authentication session key KSKME may be derived using a first key derivation function having a secret key (e.g., CK, IK, etc.) and a serving network identity (SN_id) as inputs. The mobility session key KASME may be derived using a second key derivation function. The first and second key derivation functions may be based on, for example, key-hashed message authentication code (HMAC) HMAC-<NUM>, HMAC-SHA-<NUM>, HMAC-SHA-<NUM>, etc. The authentication and key agreement may be performed using an extensible authentication protocol (EAP), or specific NAS signaling. The mobility session key KASME may be derived during the AKA procedure (for the currently attached MME with the UE), or during a handover involving an MME relocation. The session may be defined for the currently attached MME by the SKME <NUM>. MME relocation may be performed within a group of MMEs sharing an MMEGI. Alternatively, MME relocation may be performed with another MME having a different MMEGI. According to one aspect, the GUMMEI may be based on a combination of an MMEGI and an MME code.

According to one aspect of the disclosure, the MME may receive the mobility session key KASME from the SKME <NUM> over a communication channel that is security protected. According to another aspect, a target MME during an MME relocation may receive the key KASME used by another MME if the two MMEs belong to the same MME group (e.g., both have the same MME group identifier (MMEGI)).

<FIG> and <FIG> illustrate scenarios where the UE <NUM> shown in <FIG> is roaming and is thus in a visited network <NUM> outside of the home network <NUM>. In such a case, the SKME <NUM> of the visited network becomes the local key anchor and also performs mutual authentication (e.g., AKA) with the UE <NUM>, and generally follows the process described above with respect to <FIG>. Similarly, during an MME relocation (e.g., handover or tracking area update) within the visited network, the local SKME <NUM> of the visited network <NUM> derives a new KASME and provides it to the target/new MME. The key KeNB may be derived from the new KASME. In <FIG>, <FIG>, and <FIG>, the key KNAS is used to secure control messages between the UE <NUM> and the MME <NUM>.

<FIG> illustrates a schematic diagram of the key hierarchy for the wireless communication network <NUM> described above. The UE's universal subscriber identity module (USIM) and the network's authentication center (AuC) may store a root key. From the root key, an integrity key (IK) and a cipher key (CK) may be derived and provided to the HSS. The root key, CK, and IK may be considered shared secret keys shared between the UE and the network.

The HSS may in turn generate the authentication session key KSKME and provide it to the SKME. The session key KSKME is valid during the entire authentication session. The SKME may utilize the KSKME to generate the mobility session key KASME and provide that key to the MME serving the UE. In one aspect, the mobility session key KASME may be valid for only a specific MME. In other aspects, the mobility session key KASME may be shared between MMEs of the same group (e.g., having the same MMEGI). The MME serving the UE may in turn generate other keys (KNASenc, KNASint, KeNB/NH, etc.) based on the KASME.

During an initial attach to a network, a UE performs an authentication and key agreement (AKA) procedure with a session key management entity (SKME) device. Once authentication is successful, SKME derives a key (e.g., KASME) for the MME to which the UE is attached and provides the key to the MME.

When a tracking area update (TAU) involving MME relocation is requested by a UE, the new MME that receives the TAU request receives a new key KASME from the SKME and establishes a security association with the UE by performing a NAS SMC procedure. Similarly, when a handover involving MME relocation happens, the target MME also gets a new key KASME from the SKME and establishes a security association with the UE.

An MME that supports two tracking areas may initiate a change of mobility session key KASME when the UE moves between tracking areas. This hides the network configuration from the UE. For example, the UEs may only see tracking areas and not MMEs. This may happen both in response to a TAU or a handover that changes tracking areas.

<FIG> illustrates a flow diagram of an attach procedure and initial data transfer for a UE connecting to a wireless communication network (e.g., wireless cellular network) according to one aspect of the disclosure. First, the UE <NUM> transmits an attach request <NUM> to a RAN <NUM>, which in turn forwards the request to the MME <NUM>, which in turn forwards the request (along with possibly KSI information) to the SKME <NUM>. The SKME <NUM> may then transmit an authentication information request <NUM> to the HSS <NUM> and in response it receives one or more authentication vectors <NUM> from the HSS <NUM> that may include an expected response (XRES), an authentication value (AUTN), a random number (RAND), and an authentication session key KSKME. The AUTN may be based on a sequence number and a secret key which the UE <NUM> shares with the HSS <NUM>.

Once the SKME <NUM> has the authentication vector associated with the UE <NUM>, the UE <NUM> and the SKME <NUM> may perform <NUM> AKA. Once AKA is successful, the SKME <NUM> may derive a mobility session key KASME based on the authentication session key KSKME , an MME identification value (e.g., GUMMEI, MMEI, MMEGI, etc.), and/or a counter value (e.g., Key Count). Thus, KASME may be derived as KASME = KDF(KSKME, MME identification value | Key Count) where KDF is a key derivation function. The counter value Key Count is a counter value that may be incremented by the SKME <NUM> to enable the SKME <NUM> to derive a fresh KASME key for the same MME <NUM> whenever handover back to the MME <NUM> occurs. According to one aspect, a number used once (nonce) may be used instead of the counter value. According to another aspect, the GUMMEI may be omitted if it's not used to authorize a particular MME identity. For example, if the SKME <NUM> is always in the same network as the MMEs it provides KASME for, then including GUMMEI in the key derivation may be unnecessary. Thus, according to another example, KASME may be derived as KASME = KDF(KSKME, nonce). The mobility session key KASME is then sent <NUM> to the MME <NUM>. The MME <NUM> may then use the mobility session key KASME to perform <NUM> a NAS SMC procedure with the UE <NUM>. During the NAS SMC procedure, the MME <NUM> may provide its GUMMEI and/or the Key Count to the UE <NUM> so the UE <NUM> can also derive KASME. The remaining steps <NUM> - <NUM> shown in <FIG> may be similar to those found in <NUM> LTE cellular communication protocols.

<FIG> illustrates a flow diagram of an S1-handover procedure according to one aspect of the disclosure. First, the source eNB 260a (i.e., the current eNB) transmits a handover (HO) required message <NUM> to the source MME 210a (i.e., the current MME). Next, the source MME 210a transmits/forwards a relocation request <NUM> based on the HO required message to the target MME 210b (i.e., the new MME). The target MME 210b may create and transmit a session request <NUM> to a target serving gateway (S-GW) 250b and receive a session response <NUM> from the target S-GW 250b. The target MME 210b may also transmit a key request <NUM> for a mobility session key KASME to the SKME <NUM>. In so doing, the target MME 210b may provide the SKME <NUM> with its MME identification value (e.g., GUMMEI). The SKME <NUM> may in turn generate the mobility session key KASME using the MME's GUMMEI, the authentication session key KSKME it previously received from the HSS <NUM> (described above), and the Key Count. According to one aspect, a number used once (nonce) may be used instead of the Key Count. According to another aspect, the GUMMEI may be omitted if it is not desired to authorize a particular MME identity. The SKME <NUM> transmits the KASME <NUM> to the target MME 210b. According to one aspect, the target MME 210b may transmit the session request <NUM> to the target S-GW 250b and transmit the key request <NUM> at about the same time. Thus, steps <NUM> and <NUM> may be carried out concurrently with steps <NUM> and <NUM>.

The target MME 210b may then transmit a handover request <NUM> to the target eNB 260b (i.e., the potential new eNB) and in response the target eNB 260b sends back a handover response <NUM>. The handover request <NUM> may include the key KeNB derived by the target MME 210b using KASME. The handover response <NUM> indicates whether the target eNB 260b agrees to accept the handover. If the target eNB 260b does agree to accept the handover then the target MME 210b sends a key (i.e., KASME) acknowledgement message <NUM> to the SKME <NUM>. Upon receiving the key acknowledgement message, the SKME <NUM> may then increment the Key Count counter value. The step of sending the key acknowledgement message <NUM> is delayed until the handover request acknowledgement <NUM> is received because the handover request may be rejected by the target eNB 260b. In such case, a new KASME doesn't need to be derived by the UE <NUM>, and in the case SKME <NUM> may not need to increase the Key Count. After the target MME 210b sends the source MME 210a the relocation response <NUM>, the source MME 210a sends a handover command <NUM> to the source eNB 260a which is forwarded <NUM> to the UE <NUM>. The handover command <NUM>, <NUM> may include the GUMMEI of the target MME 210b and the Key Count so that the UE <NUM> can derive the new KASME and the new KeNB for the target eNB 260b. The UE <NUM> responds with a handover confirmation message <NUM> to the target eNB 260b. The handover confirmation message <NUM> may be integrity protected and ciphered.

<FIG> and <FIG> illustrate a flow diagram of a tracking area update procedure after a UE <NUM> moves to a new location requiring an MME relocation according to one aspect of the disclosure. Referring to <FIG>, first, the UE <NUM> generates and transmits <NUM> a tracking area update request to the RAN <NUM> (e.g., eNB). The eNB <NUM> in turn forwards <NUM> the tracking area update request to a target MME 210b (e.g., "new MME") that will be associated with and/or serve the UE <NUM>. The eNB <NUM> determines which new MME 210b to send the tracking area update request to based on various criteria including the location of the UE <NUM>. The tracking area update request may include a globally unique temporary identifier (GUTI) that includes the GUMMEI of the source MME 210a (e.g., "old MME"), which is the MME currently associated with the UE <NUM>. The target MME 210b may then use the GUMMEI in the tracking area update request it receives to transmit <NUM> a UE context request message to the source MME 210a. The source MME 210a then responds <NUM> with the UE context information in a UE context response message. An acknowledgment may be sent <NUM> from the target MME 210b to the source MME 210a once this response is received.

The target MME 210b may then send <NUM> a location update and a key request (i.e., KASME key request) to the SKME <NUM>. The location update is forwarded to the HSS <NUM> which then sends <NUM> a location cancelation message to the source MME 210a. In response, the source MME 210a may transmit <NUM> a location cancelation acknowledgement message back to the HSS <NUM>. The SKME <NUM> may generate a new KASME for the target MME 210b based on the GUMMEI of the target MME 210b and/or the Key Count counter value as previously described. According to one aspect, a number used once (nonce) may be used instead of the Key Count. According to another aspect, the GUMMEI may be omitted if it is not desired to authorize a particular MME identity. The new KASME is transmitted <NUM> to the target MME 210b. Upon receiving KASME from the SKME <NUM>, the target MME 210b may reply <NUM> with a key acknowledgement message to the SKME <NUM>. According to one aspect, the target MME 210b may transmit <NUM> the UE context request message to the source MME 210a at about the same time it transmits <NUM> the location update and key request to the SKME <NUM>. Thus, steps <NUM>, <NUM>, and <NUM> may be performed concurrently with steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM>.

Referring to <FIG>, once the target MME 210b has received the KASME from the SKME <NUM>, the target MME 210b may then perform <NUM>, <NUM> a non-access stratum security mode command procedure with the UE <NUM>. During the security mode command procedure, the UE <NUM> derives the key KASME used by the target MME 210b since the target MME 210b provides the UE <NUM> with its GUMMEI. Once the UE <NUM> also has the same KASME as the target MME 210b, the UE <NUM> and the target MME 210b may engage in secure communications based on the KASME key. For example, the target MME 210b may engage <NUM>, <NUM> in a tracking area update exchange with the UE <NUM> whose communications are encrypted by KASME or other keys (e.g., NAS encryption and integrity protection keys) derived from KASME. This exchange may include a message sent from the target MME 210b to the UE <NUM> that includes the new GUTI based on the target MME's GUMMEI. Such a message is again encrypted by KASME or another key derived from KASME.

As shown in <FIG> and described above, the NAS SMC <NUM>, <NUM> is followed by the tracking area update process <NUM>, <NUM>. In some aspects of the disclosure, the NAS SMC <NUM>, <NUM> and the tracking area update process <NUM>, <NUM> may be combined. For example, the NAS SMC message <NUM> sent from the target MME 210b to the UE <NUM> may be combined with the tracking area update message <NUM>. In so doing, only part of the combined message (e.g., the part associated with the tracking area update) may be encrypted, while the portion of the message that helps the UE derive KASME is left unencrypted. A new temporary mobile subscriber identity (TMSI), which is part of GUTI, allocated by the MME may be encrypted.

As discussed above, AKA is run between the UE and the SKME. The key KSKME is derived by the HSS and sent to the SKME. From the HSS' perspective, authentication vectors are constructed in the same manner as <NUM> LTE and sent to the SKME instead of the MME. Thus, HSS may be connected to SKME without any modification.

SKME derives a mobility session key KASME for a given MME and thus the MME's GUMMEI may be used in the KASME key derivation process. A NAS Count value may be initialized to zero (<NUM>) for a new KASME. In one example, the old NAS Count values are not discarded if tracking area update(s) doesn't complete. For the freshness of the key KASME the UE and the SKME may maintain a Key Count counter value and use it for KASME derivation. This may be done to avoid deriving the same KASME in cases where the UE moves back to an old MME. The Key Count counter value may be initialized to zero (<NUM>) or some other pre-determined value when the initial AKA is performed successfully. In some aspects, a nonce may be used instead of the Key Count counter value. In another aspect, the GUMMEI may be omitted from the key derivation.

The key derivation function (KDF) used to generate the keys KSKME, KASME, K6NB, next hop (NH), etc. may utilize HMAC-SHA-<NUM>, HMAC-SHA-<NUM>, etc. The input string S may be constructed from n + <NUM> input parameters. For example, S = [FC ∥ P<NUM> ∥ L<NUM> ∥ P<NUM> ∥ L<NUM> ∥ P<NUM> ∥ L<NUM> ∥. ∥ PN ∥ LN]. The field code FC may be a single octet used to distinguish between different instances of the algorithm and may use a value in the range 0x50 - 0x5F. The input parameters P<NUM> through PN are the n + <NUM> input parameter encodings. P<NUM> may be a static ASCII-encoded string. The values L<NUM> through LN are two octet representations of the length of the corresponding input parameters P<NUM> through PN.

KSKME = KDF(KCK/IK, S). The input S may be equal to [FC ∥ P<NUM> ∥ L<NUM> ∥ P<NUM> ∥ L<NUM>] where FC = 0x50, P<NUM> = SN id, L<NUM> = length of SN id (i.e., L<NUM> = 0x00 0x03), P<NUM> = SQN XOR AK, and L<NUM> = length of P<NUM> (i.e., L<NUM> = 0x00 0x06). SQN is the sequence number and AK is anonymity key, and XOR is the exclusive OR operation. The value SQN XOR AK is sent to the UE as part of the authentication token (AUTN). If AK is not used then AK may be treated in accordance with TS <NUM> (i.e., <NUM>. The input key KCK/IK is the concatenation of the cipher key (CK) and the integrity key (IK), i.e., KCK/IK = CK ∥ IK.

KASME = KDF(KSKME, S). The input S may be equal to [FC ∥ P<NUM> ∥ L<NUM> ∥ P<NUM> ∥ L<NUM>] where FC = 0x51, P<NUM> = GUMMEI, L<NUM> = length of <NUM> bit GUMMEI (i.e., L<NUM> = 0x00 0x06), P<NUM> = Key Count, and L<NUM> may equal the length of P<NUM> (e.g., L<NUM> = 0x00 0x08). This is merely one example of how KASME may be derived. In another aspects, the GUMMEI may be omitted and rand number used once (e.g., nonce) may be used instead of the Key Count counter value.

NH = KDF(KASME, S). The input S may be equal to [FC ∥ P<NUM> ∥ L<NUM>] where FC = 0x52, P<NUM> = Sync-Input, L<NUM> = length of Sync-Input (i.e., L<NUM> = 0x00 0x20). The Sync-Input parameter may be newly derived KeNB for the initial NH derivation, and the previous NH for all subsequent derivations. This results in an NH chain, where the next NH is always fresh and derived from the previous NH.

K'eNB = KDF(Kx, S). When deriving K'eNB from the current KeNB or from a fresh NH and the target physical cell identifier in the UE and the eNB as specified in clause <NUM>. <NUM> for handover purposes, the input S may be equal to [FC ∥ P<NUM> ∥ L<NUM> ∥ P<NUM> ∥ L<NUM>] where FC = 0x53, P<NUM> = target physical cell identifier (PCI), L<NUM> = length of PCI (e.g., L<NUM> = 0x00 0x02), P<NUM> = EARFCN-DL (target physical cell downlink frequency), and L<NUM> = length of P<NUM> (e.g., L<NUM> = 0x00 0x02). The input key Kx may be the <NUM> bit next hop (NH) key when the index in the handover increases otherwise the current <NUM> bit KeNB is used.

<FIG> shown and described above assume that the MMEs change from source to target MME. However, the same process flow diagrams may be used when a single MME assumes the role of two MMEs (source MME and target MME) and there is no actual interface between the two MMEs.

<FIG> illustrates a schematic block diagram of a device <NUM> (e.g., "user device", "user equipment", "wireless communication device") according to one aspect of the disclosure. The device <NUM> may be an integrated circuit, a plurality of integrated circuits, or an electronic device that incorporates one or more integrated circuits. The device <NUM> may also be any wireless communication device such as, but not limited to, a mobile phone, a smartphone, a laptop, a personal digital assistant (PDA), a tablet, a computer, a smartwatch, and a head-mounted wearable computer (e.g., Google Glass®). The device <NUM> may include at least one or more wireless communication interfaces <NUM>, one or more memory circuits <NUM>, one or more input and/or output (I/O) devices/circuits <NUM>, and/or one or more processing circuits <NUM> that may be communicatively coupled to one another. For example, the interface <NUM>, the memory circuit <NUM>, the I/O devices <NUM>, and the processing circuit <NUM> may be communicatively coupled to each other through a bus <NUM>. The wireless communication interface <NUM> allows the device <NUM> to communicate wirelessly with the wireless communication network <NUM>. Thus, the interface <NUM> allows the device <NUM> to communicate wirelessly with wireless wide area networks (WWAN), such as mobile telecommunication cellular networks, as well as short range, wireless local area networks (e.g., WiFi®, Zigbee®, Bluetooth®, etc.).

The memory circuit <NUM> may include one or more volatile memory circuits and/or nonvolatile memory circuits. Thus, the memory circuit <NUM> may include dynamic random access memory (DRAM), static random access memory (SRAM), magnetoresistive random access memory (MRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, etc. The memory circuit <NUM> may store one or more cryptographic keys. The memory circuit <NUM> may also store instructions that may be executed by the processing circuit <NUM>. The I/O devices/circuits <NUM> may include one or more keyboards, mice, displays, touchscreen displays, printers, fingerprint scanners, and any other input and/or output devices.

The processing circuit <NUM> (e.g., processor, central processing unit (CPU), application processing unit (APU), etc.) may execute instructions stored at the memory circuit <NUM> and/or instructions stored at another computer-readable storage medium (e.g., hard disk drive, optical disk drive, solid-state drive, etc.) communicatively coupled to the user device <NUM>. The processing circuit <NUM> may perform any one of the steps and/or processes of the device <NUM> described herein including those discussed with reference to <FIG>, <FIG>, <FIG> <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM>. According to one aspect, the processing circuit <NUM> may be a general purpose processor. According to another aspect, the processing circuit may be hard-wired (e.g., it may be an application-specific integrated circuit (ASIC)) to perform the steps and/or processes of the UE <NUM> described herein including those discussed with reference to <FIG>, <FIG>, <FIG> <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM>.

<FIG> illustrates a schematic block diagram of a device processing circuit <NUM> according to one aspect. The processing circuit <NUM> may include an authorization and key agreement (AKA) performing circuit <NUM>, an authentication session key generation circuit <NUM>, a mobility session key generation circuit <NUM>, and/or a data securing circuit <NUM>. According to one aspect, these circuits <NUM>, <NUM>, <NUM>, <NUM> may be ASICs and are hard-wired to perform their respective processes.

The AKA performing circuit <NUM> may be one non-limiting example of a means for performing authentication and key agreement with an SKME device. The authentication session key generation circuit <NUM> may be one non-limiting example of a means for generating an authentication session key based in part on a secret key shared with a home subscriber server. The mobility session key generation circuit <NUM> may be one non-limiting example of a means for generating a mobility session key based in part on the authentication session key. The data securing circuit <NUM> may be one non-limiting example of a means for cryptographically securing data sent from the device to a wireless communication network using the mobility session key.

<FIG> illustrates a method <NUM> operational at the device <NUM>. First, authentication and key agreement with a session key management entity (SKME) device is performed <NUM>. Next, an authentication session key is generated <NUM> based in part on a secret key shared with a home subscriber server (HSS), the authentication session key known to the SKME device. Then, a mobility session key is generated <NUM> based in part on the authentication session key, the mobility session key known to a mobility management entity (MME) serving the device. Next, data sent from the device to a wireless communication network is cryptographically secured <NUM> using the mobility session key.

<FIG> illustrates a schematic block diagram of a network device <NUM> according to one aspect of the disclosure. The network device <NUM> may be, among other network components, an SKME, MME, a RAN, S-GW, and/or P-GW. The network device <NUM> may include at least one or more wireless communication interfaces <NUM>, one or more memory circuits <NUM>, one or more input and/or output (I/O) devices/circuits <NUM>, and/or one or more processing circuits <NUM> that may be communicatively coupled to one another. For example, the interface <NUM>, the memory circuit <NUM>, the I/O devices <NUM>, and the processing circuit <NUM> may be communicatively coupled to each other through a bus <NUM>. The wireless communication interface <NUM> allows the network device <NUM> to communicate wirelessly with the user device <NUM>. Thus, the interface <NUM> allows the network device <NUM> to communicate wirelessly through wireless wide area networks (WWAN), such as mobile telecommunication cellular networks, and/or short range, wireless local area networks (e.g., WiFi®, Zigbee®, Bluetooth®, etc.).

The memory circuit <NUM> may include one or more volatile memory circuits and/or nonvolatile memory circuits. Thus, the memory circuit <NUM> may include DRAM, SRAM, MRAM, EEPROM, flash memory, etc. The memory circuit <NUM> may store one or more cryptographic keys. The memory circuit <NUM> may also store instructions that may be executed by the processing circuit <NUM>. The I/O devices/circuits <NUM> may include one or more keyboards, mice, displays, touchscreen displays, printers, fingerprint scanners, and any other input and/or output devices.

The processing circuit <NUM> (e.g., processor, central processing unit (CPU), application processing unit (APU), etc.) may execute instructions stored at the memory circuit <NUM> and/or instructions stored at another computer-readable storage medium (e.g., hard disk drive, optical disk drive, solid-state drive, etc.) communicatively coupled to the network device <NUM>. The processing circuit <NUM> may perform any one of the steps and/or processes of a network devices described herein including those discussed with reference to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM>. According to one aspect, the processing circuit <NUM> may be a general purpose processor. According to another aspect, the processing circuit <NUM> may be hard-wired (e.g., it may be an application-specific integrated circuit (ASIC)) to perform the steps and/or processes of the SKME <NUM> and/or MME <NUM>, 210a, 210b described herein including those discussed with reference to <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM>.

<FIG> illustrates a schematic block diagram of a network device processing circuit <NUM> according to one aspect. The processing circuit <NUM> may include an authorization and key agreement (AKA) performing circuit <NUM>, an authentication information obtaining circuit <NUM>, a mobility session key generation circuit <NUM>, and/or a mobility session key transmission circuit <NUM>. According to one aspect, these circuits <NUM>, <NUM>, <NUM>, <NUM> may be ASICs and are hard-wired to perform their respective processes.

The AKA performing circuit <NUM> may be one non-limiting example of a means for performing authentication and key agreement with a device. The authentication information obtaining circuit <NUM> may be one non-limiting example of a means for obtaining authentication information associated with the device, the authentication information including at least an authentication session key. The mobility session key generation circuit <NUM> may be one non-limiting example of a means for generating a mobility session key based in part on the authentication session key. The mobility session key transmission circuit <NUM> may be one non-limiting example of a means for transmitting the mobility session key to a mobility management entity (MME) serving the device.

<FIG> illustrates a schematic block diagram of a network device processing circuit <NUM> according to another aspect. The processing circuit <NUM> may include a NAS message receiving circuit <NUM>, a NAS message forwarding circuit <NUM>, a mobility session key receiving circuit <NUM>, and/or a key derivation data transmission circuit <NUM>. According to one aspect, these circuits <NUM>, <NUM>, <NUM>, <NUM> may be ASICs and are hard-wired to perform their respective processes.

The NAS message receiving circuit <NUM> may be one non-limiting example of a means for receiving a non-access stratum (NAS) message from a device. The NAS message forwarding circuit <NUM> may be one non-limiting example of a means for forwarding the NAS message along with a network device identification value identifying the network device to a session key management entity (SKME) device. The mobility session key receiving circuit <NUM> may be one non-limiting example of a means for receiving a mobility session key from the SKME device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network. The key derivation data transmission circuit <NUM> may be one non-limiting example of a means for transmitting key derivation data to the device, the key derivation data enabling the device to derive the mobility session key.

<FIG> illustrates a method <NUM> operational at the network device <NUM>. First, authentication and key agreement with a device is performed <NUM>. Next, authentication information associated with the device is obtained <NUM>, the authentication information including at least an authentication session key. Then, a mobility session key based in part on the authentication session key is generated <NUM>. Next, the mobility session key is transmitted <NUM> to a mobility management entity (MME) serving the device.

<FIG> illustrates a method <NUM> operational at the network device <NUM>. First, a non-access stratum (NAS) message is received <NUM> from a device. Next, the NAS message along with a network device identification value identifying the network device is forwarded <NUM> to a session key management entity (SKME) device. Then, a mobility session key from the SKME device is received <NUM>, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network. Next, key derivation data is transmitted <NUM> to the device, the key derivation data enabling the device to derive the mobility session key.

One or more of the components, steps, features, and/or functions illustrated in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM> may be rearranged and/or combined into a single component, step, feature or function or embodied in several components, steps, or functions. Additional elements, components, steps, and/or functions may also be added without departing from the invention. The apparatus, devices, and/or components illustrated in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM> may be configured to perform one or more of the methods, features, or steps described in <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and/or <NUM>. The algorithms described herein may also be efficiently implemented in software and/or embedded in hardware.

Also, it is noted that the aspects of the present disclosure may be described as a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. A process is terminated when its operations are completed. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.

Moreover, a storage medium may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine-readable mediums and, processor-readable mediums, and/or computer-readable mediums for storing information. The terms "machine-readable medium", "computer-readable medium", and/or "processor-readable medium" may include, but are not limited to non-transitory mediums such as portable or fixed storage devices, optical storage devices, and various other mediums capable of storing or containing instruction(s) and/or data. Thus, the various methods described herein may be fully or partially implemented by instructions and/or data that may be stored in a "machine-readable medium", "computer-readable medium", and/or "processor-readable medium" and executed by one or more processors, machines and/or devices.

Furthermore, aspects of the disclosure may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage(s). A processor may perform the necessary tasks. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc..

The various illustrative logical blocks, modules, circuits, elements, and/or components described in connection with the examples disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic component, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may also be implemented as a combination of computing components, e.g., a combination of a DSP and a microprocessor, a number of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The methods or algorithms described in connection with the examples disclosed herein may be embodied directly in hardware, in a software module executable by a processor, or in a combination of both, in the form of processing unit, programming instructions, or other directions, and may be contained in a single device or distributed across multiple devices. A storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium.

Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both.

Claim 1:
A method operational at a network device, the method comprising:
receiving (<NUM>) a non-access stratum, NAS, message from a device;
forwarding (<NUM>) the NAS message along with a network device identification value identifying the network device to an authentication session key anchor function device;
receiving (<NUM>) a mobility session key from the authentication session key anchor function device, the mobility session key based in part on an authentication session key that was derived from a key shared between the device and a wireless communication network; and
transmitting (<NUM>) key derivation data to the device, the key derivation data enabling the device to derive the mobility session key.