Patent Description:
In the current EPS (Evolved Packet System), as disclosed in e.g., NPL <NUM>, AKA (Authentication and Key Agreement) procedure and NAS (Non Access Stratum) SMC (Security Mode Command) procedure are performed, so that NAS security context for a UE (hereinafter, sometimes referred to as "UE context" or simply "security context") is shared between the UE and an MME (Mobility Management Entity).

The NAS security context includes Kasme with the associated KSI (Key Set Identifier), and the like. The Kasme and the KSI are used for deriving the same NAS keys at both the UE and the MME. The NAS keys are used for protecting integrity and confidentiality of traffic between the UE and the MME.

<NPL>) discloses the LTE security architecture, including AKA between UE and MME.

However, the inventors of this application have found that the following problems may arise in the current architecture.

Specifically, in mobility, new MME has to retrieve the UE context from an old MME or SGSN (Serving GPRS (General Packet Radio Service) Support Node). It requires that the UE indicate the old MME/SGSN (MME or SGSN) in GUTI (Globally Unique Temporary Identity) or P-TMSI (Packet-TMSI (Temporary Mobile Subscriber Identity)). Note that the new MME is the one to which the UE newly attaches, and the old MME/SGSN is the one to which the UE previously attached.

Meanwhile, the old MME/SGSN may have already removed the UE context. In this case, AKA/NAS SMC (AKA and NAS SMC) procedures are performed again under the initiative of the new MME. Such redundant performance causes signaling overload to devices/nodes (devices and nodes), in particular the MME, involved in the AKA/NAS SMC procedures and all interfaces therebetween. As the number of UEs increases, such overload will become much more pronounced.

Moreover, it is predicted that virtualization will need to create and/or remove the MME on demand. In this case, the UE context will be retrieved and/or removed frequently. Therefore, the overload will be caused as in the mobility case.

Accordingly, an exemplary object of the present invention is to provide a solution for alleviating overload on AKA/NAS SMC procedures.

The present invention provides a first node, and an associated method as disclosed in the appended independent claims. Optional, but advantageous features are disclosed in the appended dependent claims.

According to the present invention, it is possible to provide a solution for alleviating overload on AKA/NAS SMC procedures, thereby solving at least a part or the whole of the above-mentioned problems.

Hereinafter, an exemplary embodiment of an apparatus, a system and a method according to the present invention will be described with reference to the accompanying drawings.

As shown in <FIG>, a network system according to this exemplary embodiment includes one or more MMEs 30_1 and 30_2 (hereinafter, sometimes collectively denoted by the symbol <NUM>), and a cMME (cloud MME) <NUM>. Note that although two MMEs 30_1 and 30_2 are shown in <FIG>, the network system may be provided with MMEs more than three. In such a case, the following explanation can also be similarly applied.

Briefly, the cMME <NUM> serves as the offload location for e.g., storing security context for a UE <NUM>. Here, the UE <NUM> wirelessly connects to any one of eNBs 20_1 to 20_3 (hereinafter, sometimes collectively denoted by the symbol <NUM>). Moreover, as will be described later, the UE <NUM> attaches to any one of the MMEs 30_1 and 30_2 as well as the cMME <NUM>, through the eNB <NUM>. Note that although one UE and three eNBs are shown in <FIG>, the network system may be provided with UEs more than two, and eNBs less or more than three. In such cases, the following explanation can also be similarly applied.

In other words, the security context is stored in cloud (cMME <NUM>), not in the MME <NUM> itself. Any MME going live will have context to securely connect with the offload location (cMME <NUM>). The offload location can be distributed or centralized. Virtual image of the offload location could be brought up or down at a given location based on pattern - user, usage etc. Moreover, the offload location may be configured not only by the cloud but also by a tangible MME which represents the pool of MMEs, for example.

Further, the MME <NUM> and the cMME <NUM> can access an HSS (Home Subscriber Server) <NUM> on demand to acquire credentials necessary for authenticating the UE <NUM> in the AKA procedure.

Next, there will be described operation examples of this exemplary embodiment, as to the following cases A to C with reference to <FIG>.

This case "A" deals with a case where the cMME <NUM> serves as storage only for the security context.

That is, as conceptually shown in <FIG>, the cMME <NUM> includes security context storage <NUM>, a receiving unit <NUM> and a sending unit <NUM>. The receiving unit <NUM> receives security context from the MME <NUM>, and stores the received security context in the storage <NUM>. The sending unit <NUM> reads out the stored security context from the storage <NUM> in response to a request from the MME <NUM>, and sends the read context to the MME <NUM>.

On the other hand, the MME <NUM> includes a security function unit <NUM>, a mobility management unit <NUM>, a sending unit <NUM> and a receiving unit <NUM>. The security function unit <NUM> creates and updates security context for the UE <NUM>. The mobility management unit <NUM> manages mobility of the UE <NUM>. The sending unit <NUM> and the receiving unit <NUM> send and receive various signaling messages from and to the UE <NUM>, the MME <NUM> and the HSS <NUM>. In particular, the sending unit <NUM> sends the security context and a request therefor to the cMME <NUM>. The receiving unit <NUM> receives the security context from the cMME <NUM>. Functionalities of the MME <NUM> are simplified compared with a typical MME, because the security context storage is shifted to the cMME <NUM>.

Briefly, in this case "A", the following operations (<NUM>) to (<NUM>) are carried out.

In the above operation (<NUM>), as shown by dotted lines in <FIG>, the MME <NUM> can access the HSS <NUM> on demand through the existing interface. In the above operations (<NUM>) to (<NUM>), as shown by thick lines in <FIG>, the MME <NUM> and the cMME <NUM> interact with each other through new interface.

Specifically, as shown in <FIG>, at the initial phase, the UE <NUM> sends an Attach Request message to the MME <NUM> as in the existing attach procedure (step S11).

The MME <NUM> performs the existing AKA and NAS SMC procedures, as in NPL <NUM> (steps S12a and S12b). Successful NAS SMC procedure results in the UE <NUM> and the MME <NUM> sharing same NAS security context which includes NAS keys (step S12c).

After that, the UE <NUM> and the eNB <NUM> interact with each other to perform AS (Access Stratum) SMC procedure (step S12d). Successful AS SMC procedure results in the UE <NUM> and the eNB <NUM> sharing same AS security context which includes AS keys (step S12e). Note that the AS keys are used for protecting integrity and confidentiality of traffic at RRC (Radio Resource Control) protocol layer between the UE <NUM> and the eNB <NUM>.

In parallel with the AS SMC procedure, the MME <NUM> sends a Security Context Update message to the cMME <NUM> (step S13a). This message includes UE ID (identifier of the UE <NUM>) and NAS security context which contains KSI, Kasme and NAS keys.

The cMME <NUM> stores the security context received at step S13a (step S13b), and sends a Security Context Update Ack (Acknowledgment) message to the MME <NUM> (step S13c).

The MME <NUM> sends an Attach response message to the UE <NUM> (step S14).

After that, due to power-off, overload or system down, the MME <NUM> starts Switch-off procedure (step S21).

In this procedure, the MME <NUM> sends a Security Context Update message to the cMME <NUM> (step S22a). This message includes the UE ID and the latest NAS security context which contains KSI, Kasme and NAS keys.

The cMME <NUM> updates the security context stored for the given UE <NUM> with the latest security context received at step S22a (step S22b), and sends a Security Context Update Ack message to the MME <NUM> (step S22c).

Then, the MME <NUM> removes the security context which the MME <NUM> kept local (step S23).

On the other hand, in mobility, the network system operates as shown in <FIG>. Note that the operation shown in <FIG> takes, as an example, a case where the UE <NUM> has been previously attached to the MME 30_1 and newly attaches to the MME 30_2, i.e., a case where the MME 30_1 is "Old MME" and the MME 30_2 is "New MME". Meanwhile, the mobility also includes Idle mobility, i.e., TAU (Tracking Area Update), and Handover procedure.

Specifically, the UE <NUM> sends an Attach Request message, a TAU Request message, or a Handover Request message to the New MME 30_2 (step S31).

The New MME 30_2 will not go to the Old MME 30_1, but request for security context from the cMME <NUM>, by sending a Security Context Request message including the UE ID to the cMME <NUM> (step S32a).

The cMME <NUM> retrieves the UE's context corresponding to the received UE ID, and sends back to the New MME 30_2 a Security Context Response message including the UE ID and the retrieved NAS security context which contains KSI, Kasme and NAS keys (step S32b).

Then, the New MME 30_2 sends a response message to the Attach or Mobility request back to the UE <NUM> (step S33). This message can be protected by the NAS keys received from the cMME <NUM>.

According to this case "A", the security context is stored on the cloud MME, instead of the (local) MME itself. Thus, it is possible to reduce signaling messages when the UE changes an MME or when the MME is down, because of avoiding redundant AKA/NAS SMC procedures to be performed. Accordingly, it is possible to alleviate overload on the AKA/NAS SMC procedures, such as signaling overload to devices/nodes, in particular the MME, involved in the AKA/NAS SMC procedures and all interfaces therebetween.

This case "B" deals with a case where the cMME <NUM> has complete security functionalities.

That is, as conceptually shown in <FIG>, the cMME <NUM> further includes a security function unit <NUM> in addition to the elements shown in <FIG>. The security function unit <NUM> creates and updates security context for the UE <NUM>, as a substitute for the MME <NUM>. The sending unit <NUM> can send the security context to the MME <NUM>.

On the other hand, the security function unit <NUM> shown in <FIG> is removed from the MME <NUM>, and is shifted to the cMME <NUM> as the security function unit <NUM>. Thus, functionalities of the MME <NUM> are further simplified compared with those shown in <FIG>.

Briefly, in this case "B", the following operations (<NUM>) to (<NUM>) are carried out.

In the above operations (<NUM>) to (<NUM>), as shown by thick lines in <FIG>, the cMME <NUM> interacts with the HSS <NUM> and the MME <NUM> through new interfaces.

Specifically, as shown in <FIG>, at the initial phase, the UE <NUM> sends an Attach Request message to the MME <NUM> as in the existing attach procedure (step S41).

AKA and NAS SMC procedures are carried between the UE <NUM> and the cMME <NUM> (step S42a), and the cMME <NUM> interacts with the HSS <NUM> on demand (step S42b). Successful NAS SMC procedure results in the UE <NUM> and the cMME <NUM> sharing same NAS security context (step S42c).

After that, the UE <NUM> and the eNB <NUM> interact with each other to perform AS SMC procedure (step S42d). Successful AS SMC procedure results in the UE <NUM> and the eNB <NUM> sharing same AS security context (step S42e).

In parallel with the AS SMC procedure, the c MME <NUM> sends a Security Context Update message to the MME <NUM> (step S43a). This message includes the UE ID and the NAS security context which contains KSI, Kasme and NAS keys.

The MME <NUM> stores the security context received at step S43a (step S43b), and sends a Security Context Update Ack message to the cMME <NUM> (step S43c).

Then, the MME <NUM> sends an Attach response message to the UE <NUM> (step S44).

After that, due to power-off, overload or system down, the MME <NUM> starts Switch-off procedure (step S51).

In this procedure, unlike the above case "A", the MME <NUM> merely removes the security context which the MME <NUM> kept local (step S52).

On the other hand, in mobility, the network system operates as shown in <FIG>. Note that the operation shown in <FIG> takes, as an example, a case where the UE <NUM> has been previously attached to the Old MME 30_1 and newly attaches to the New MME 30_2. Meanwhile, the mobility also includes Idle mobility (i.e., TAU), and Handover procedure.

Specifically, the UE <NUM> sends an Attach Request message, a TAU Request message, or a Handover Request message to the New MME 30_2 (step S61). The New MME 30_2 will not go to the Old MME 30_1, forward the message from the UE <NUM> to the cMME <NUM>.

The cMME <NUM> sends the latest UE context to the MME <NUM>, by sending a Security Context Update message including the UE ID and the NAS security context which contains KSI, Kasme and NAS keys (step S62a).

The MME <NUM> stores the received security context (step S62b), and sends a Security Context Update Ack message back to the cMME <NUM> (step S62c).

Then, the cMME <NUM> sends a Response message to the Attach or Mobility request to the UE <NUM> (step S64).

Moreover, in Mobility, the cMME <NUM> also generates or calculates NH (step S63), and sends the NH to the eNB <NUM> (step S65). Note that the NH is one of parameters necessary for AS security.

According to this case "B", as with the above case "A", it is possible to reduce signaling messages when the UE changes an MME or when the MME is down, because of avoiding redundant AKA/NAS SMC procedures to be performed. Accordingly, it is possible to alleviate overload on the AKA/NAS SMC procedures, such as signaling overload to devices/nodes, in particular the MME, involved in the AKA/ NAS SMC procedures and all interfaces therebetween.

In addition, according to this case "B", the cMME performs AKA and NAS SMC procedures as a substitute for the MME, and sends the security context to the local MME. Therefore, it is also possible to reduce cost for the MME and the like.

This case "C" deals with a case where the cMME <NUM> has complete security functionalities and direct connection to the eNB <NUM>.

Conceptually, the cMME <NUM> and the MME <NUM> in this case "C" can be configured as with those shown in <FIG>. Meanwhile, unlike the above case "B", the receiving unit <NUM> and the sending unit <NUM> can send and receive signaling messages directly from and to the UE <NUM>, through the eNB <NUM>.

Briefly, in this case "C", the following operations (<NUM>) and (<NUM>) are carried out.

In the above operations (<NUM>) and (<NUM>), as shown by thick lines in <FIG>, the cMME <NUM> interacts with the HSS <NUM>, the MME <NUM> and the eNB <NUM> through new interfaces.

Specifically, as shown in <FIG>, at the initial phase, the UE <NUM> sends an Attach Request message to the cMME <NUM> (step S71).

AKA and NAS SMC procedures are carried between the UE <NUM> and the cMME <NUM> (step S72a), and the cMME <NUM> interacts with the HSS <NUM> on demand (step S72b). Successful NAS SMC procedure results in the UE <NUM> and the cMME <NUM> sharing same NAS security context (step S72c).

Here, the MME <NUM> supports initial communication/connection (communication and/or connection) set up between the UE <NUM> and the cMME <NUM>. After that, (NAS) security related function shifts to the cMME <NUM>, and the rest stays at the MME <NUM>. NAS security protection and check are carried out at the cMME <NUM>.

Therefore, no security context needs to be handled at the MME <NUM>. Moreover, upon the Switch-off procedure, no action needs to be taken at the MME <NUM>.

Specifically, the UE <NUM> sends an Attach Request message, a TAU Request message, or a Handover Request message directly to the cMME <NUM> (step S81). The cMME <NUM> takes full responsibility for security.

Path Switch procedure can be forwarded by the New MME 30_2 (step S82). The New MME 30_2 only forwards messages but has no security function, does not perform key generation, message protection and check.

Moreover, in Mobility, the cMME <NUM> calculates NH (step S83), and sends the NH to the eNB <NUM> (step S84).

According to this case "C", as with the above cases "A" and "B", it is possible to reduce signaling messages when the UE changes an MME or when the MME is down, because security function and context management are centralized into the cMME to avoid redundant AKA/NAS SMC procedures to be performed. Accordingly, it is possible to alleviate overload on the AKA/NAS SMC procedures, such as signaling overload to devices/nodes, in particular the MME, involved in the AKA/NAS SMC procedures and all interfaces therebetween. Moreover, such centralization will be also efficient for virtualization.

In addition, according to this case "C", the cMME has full security function and direct interface with the eNB. Therefore, it is also possible to reduce large amount of signaling especially in mobility.

Next, there will be described configuration examples of the MME <NUM> and the cMME <NUM> with reference to <FIG>.

Firstly regarding the configuration of the MME <NUM> in the above case "A", as shown in <FIG>, the MME <NUM> includes at least a pushing unit <NUM>. The pushing unit <NUM> pushes the security context to the cMME <NUM>, at the initial phase. The pushing unit <NUM> may further push the latest security context to the cMME <NUM>, during the Switch-off procedure. Moreover, the MME <NUM> may include a pulling unit <NUM>. The pulling unit <NUM> pulls the security context from the cMME <NUM>, upon the Re-attach and/or Mobility.

In the above case "B", as shown in <FIG>, the MME <NUM> includes a receiving unit <NUM> and a storing unit <NUM>. The receiving unit <NUM> receives the security context from the cMME <NUM>, at the initial phase. The storing unit <NUM> stores the received security context. The receiving unit <NUM> may further receive the latest security context from the cMME <NUM>, upon the Re-attach and/or Mobility.

These units <NUM> to <NUM> as well as other element(s) of the MME <NUM> can be implemented by at least hardware such as a transceiver which conducts communication with the eNB <NUM>, the cMME <NUM> and the HSS <NUM>, as well as a controller like a CPU (Central Processing Unit) which control this transceivers to execute the processes shown in each of <FIG>, <FIG>, <FIG> and <FIG>, or processes equivalent thereto. The MME <NUM> can also be implemented by the combination of such hardware, and software (e.g., a program as stored in a memory and executed by the CPU).

Next regarding the configuration of the cMME <NUM> in the above case "A", as shown in <FIG>, the cMME <NUM> includes at least a receiving unit <NUM> and a storing unit <NUM>. The receiving unit <NUM> receives the security context pushed from the MME <NUM>, at the initial phase. The storing unit <NUM> stores the received security context. The receiving unit <NUM> may further receive the latest security context pushed from the MME <NUM>, during the Switch-off procedure. The storing unit <NUM> updates the stored security context with the latest security context. Moreover, the cMME <NUM> may include a sending unit <NUM>. The sending unit <NUM> sends the stored security context to the MME <NUM>, in response to the Re-attach or Mobility request from the MME <NUM>.

In the above case "B", as shown in <FIG>, the cMME <NUM> includes at least a generating unit <NUM> and a pushing unit <NUM>. The generating unit <NUM> generates the security context at the initial phase. The pushing unit <NUM> pushes the security context to the MME <NUM>. The pushing unit <NUM> may push the latest security context, upon the Re-attach and/or Mobility. Moreover, the cMME <NUM> may include a calculating unit <NUM>. The calculating unit <NUM> calculates the NH in Mobility, and sends the NH through the MME <NUM> to the eNB <NUM>.

In the above case "C", as shown in <FIG>, the cMME <NUM> includes at least a managing unit <NUM>. The managing unit <NUM> centrally manages the security context, through the direct connection to the eNB <NUM>. Mobility of the UE <NUM> is supported from the MME <NUM>. Moreover, the cMME <NUM> may include a calculating unit <NUM>. The calculating unit <NUM> calculates the NH in Mobility, and sends the NH through the direct connection to the eNB <NUM>.

These units <NUM> to <NUM> as well as other element(s) of the cMME <NUM> can be implemented by at least hardware such as a transceiver which conducts communication with the eNB <NUM>, the MME <NUM> and the HSS <NUM>, as well as a controller like a CPU which control this transceivers to execute the processes shown in each of <FIG>, <FIG>, <FIG>, <FIG>, <FIG> and <FIG>, or processes equivalent thereto. The cMME <NUM> can also be implemented by the combination of such hardware, and software (e.g., a program as stored in a memory and executed by the CPU).

Note that the present invention is not limited to the above-mentioned exemplary embodiment, and it is obvious that various modifications can be made by those of ordinary skill in the art based on the recitation of the claims.

Claim 1:
A first node (<NUM>) for a system using authentication and key agreement, AKA, authentication procedure, the first node (<NUM>) configured to connect to a second node (<NUM>) that performs mobility management of a user equipment, UE, and receives a request message from the UE, the first node (<NUM>) comprising:
means for accessing a third node (<NUM>) that serves AKA authentication information on the UE,
means for getting the AKA authentication information from the third node (<NUM>) upon requesting from the second node (<NUM>); and
means for performing authentication of the UE using the AKA authentication information.