Description
Title of Invention: APPARATUS, SYSTEM AND METHOD FOR
SECURITY MANAGEMENT
Technical Field
[0001] The present invention relates to an apparatus, a system and a method for security
management, and particularly to a technique to manage security context for a UE (User
Equipment).
Background Art
[0002] In the current EPS (Evolved Packet System), as disclosed in e.g., NPL 1, 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).
[0003] 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.
Citation List
Non Patent Literature
[0004] NPL 1: 3GPP TS 33.401, "3GPP System Architecture Evolution (SAE); Security ar
chitecture (Release 12)", V12.13.0, 2014-12
Summary of Invention
Technical Problem
[0005] However, the inventors of this application have found that the following problems
may arise in the current architecture.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] Accordingly, an exemplary object of the present invention is to provide a solution
for alleviating overload on AKA/NAS SMC procedures.
Solution to Problem
[0010] In order to achieve the above-mentioned object, first exemplary aspect of the
present invention provides a network system including: one or more first MMEs; and a
second MME separated from the first MMEs. The first MME pushes, to the second
MME, security context for a UE that attaches to the first MME. The second MME
stores the security context.
[001 1] According to second exemplary aspect of the present invention, there is provided
an MME including: pushing means for pushing, to a second MME separated from the
MME, security context for a UE that attaches to the MME. The second MME is also
separated from one or more first MMEs to which the UE can attach and which is
different from the MME.
[0012] According to third exemplary aspect of the present invention, there is provided a
method of managing security context in an MME. This method includes: pushing, to a
second MME separated from the MME, security context for a UE that attaches to the
MME. The second MME is also separated from one or more first MMEs to which the
UE can attach and which is different from the MME.
[0013] According to fourth exemplary aspect of the present invention, there is provided a
method of managing security context in an MME separated from one or more first
MMEs. This method includes: receiving security context pushed from the first MME,
the security context for a UE that attaches to the first MME; and storing the security
context.
[0014] According to fifth exemplary aspect of the present invention, there is provided a
network system including: one or more first MMEs; and a second MME separated
from the first MMEs. The second MME generates security context for a UE that
requests to attach to the first MME, and pushes the security context to the first MME.
The first MME stores the security context.
[0015] According to sixth exemplary aspect of the present invention, there is provided an
MME including: receiving means for receiving, from a second MME separated from
the MME, security context for a UE that requests to attach to the MME; and storing
means for storing the security context. The second MME is also separated from one or
more first MMEs to which the UE can attach and which is different from the MME.
[0016] According to seventh exemplary aspect of the present invention, there is provided
an MME separated from one or more first MMEs. This MME includes: generating
means for generating security context for a UE that requests to attach to the first MME;
and pushing means for pushing the security context to the first MME.
[0017] According to eighth exemplary aspect of the present invention, there is provided a
method of managing security context in an MME. This method includes: receiving,
from a second MME separated from the MME, security context for a UE that requests
to attach to the MME; and storing the security context. The second MME is also
separated from one or more first MMEs to which the UE can attach and which is
different from the MME.
[0018] According to ninth exemplary aspect of the present invention, there is provided a
method of managing security context in an MME separated from one or more first
MMEs. This method includes: generating security context for a UE that requests to
attach to the first MME; and pushing the security context to the first MME.
[0019] According to tenth exemplary aspect of the present invention, there is provided a
network system including: one or more first MMEs; and a second MME separated
from the first MMEs. The second MME centrally manages security context for a UE
that requests to attach to a network, through a direct connection to an eNB to which the
UE wirelessly connects. The first MME supports mobility of the UE to the second
MME.
[0020] According to eleventh exemplary aspect of the present invention, there is provided
an MME separated from one or more first MMEs. This MME includes: managing
means for centrally managing security context for a UE that requests to attach to a
network, through a direct connection to an eNB to which the UE wirelessly connects.
The first MME supports mobility of the UE to the MME.
[0021] According to twelfth exemplary aspect of the present invention, there is provided a
method of managing security context in an MME separated from one or more first
MMEs. This method includes: centrally managing security context for a UE that
requests to attach to a network, through a direct connection to an eNB to which the UE
wirelessly connects. The first MME supports mobility of the UE to the MME.
Advantageous Effects of Invention
[0022] According to the present invention, it is possible to provide a solution for al
leviating overload on AKA/NAS SMC procedures, thereby solving at least a part or the
whole of the above-mentioned problems.
Brief Description of Drawings
[0023] [fig.l]Fig. 1 is a block diagram showing a configuration example of a network system
according to an exemplary embodiment of the present invention.
[fig.2]Fig. 2 is a block diagram showing a first case regarding relationships of
signaling connection between devices/nodes in the network system according to the
exemplary embodiment.
[fig.3]Fig. 3 is a sequence diagram showing a first operation example in the first case.
[fig.4]Fig. 4 is a sequence diagram showing a second operation example in the first
case.
[fig.5]Fig. 5 is a block diagram showing a second case regarding relationships of
signaling connection between devices/nodes in the network system according to the
exemplary embodiment.
[fig.6]Fig. 6 is a sequence diagram showing a first operation example in the second
case.
[fig.7]Fig. 7 is a sequence diagram showing a second operation example in the second
case.
[fig.8]Fig. 8 is a block diagram showing a third case regarding relationships of
signaling connection between devices/nodes in the network system according to the
exemplary embodiment.
[fig.9]Fig. 9 is a sequence diagram showing a first operation example in the third case
[fig. 10] Fig. 10 is a sequence diagram showing a second operation example in the third
case.
[fig. 1l]Fig. 11 is a block diagram showing a first configuration example of an MME
according to the exemplary embodiment.
[fig. 12] Fig. 12 is a block diagram showing a second configuration example of the
MME according to the exemplary embodiment.
[fig.l3]Fig. 13 is a block diagram showing a third configuration example of the MME
according to the exemplary embodiment.
[fig. 14] Fig. 14 is a block diagram showing a fourth configuration example of the MME
according to the exemplary embodiment.
[fig.l5]Fig. 15 is a block diagram showing a fifth configuration example of the MME
according to the exemplary embodiment.
[fig. 16] Fig. 16 is a block diagram showing conceptual configurations of the MME
according to the exemplary embodiment, in the first case.
[fig.l7]Fig. 17 is a block diagram showing conceptual configurations of the MME
according to the exemplary embodiment, in the second and third cases.
Description of Embodiments
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.
[0025] As shown in Fig. 1, 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 30), and a cMME (cloud MME) 40. Note that although two
MMEs 30_1 and 30_2 are shown in Fig. 1, the network system may be provided with
MMEs more than three. In such a case, the following explanation can also be similarly
applied.
[0026] Briefly, the cMME 40 serves as the offload location for e.g., storing security
context for a UE 10. Here, the UE 10 wirelessly connects to any one of eNBs 20_1 to
20_3 (hereinafter, sometimes collectively denoted by the symbol 20). Moreover, as
will be described later, the UE 10 attaches to any one of the MMEs 30_1 and 30_2 as
well as the cMME 40, through the eNB 20. Note that although one UE and three eNBs
are shown in Fig. 1, 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.
[0027] In other words, the security context is stored in cloud (cMME 40), not in the MME
30 itself. Any MME going live will have context to securely connect with the offload
location (cMME 40). 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.
[0028] Further, the MME 30 and the cMME 40 can access an HSS (Home Subscriber
Server) 50 on demand to acquire credentials necessary for authenticating the UE 10 in
the AKA procedure.
[0029] Next, there will be described operation examples of this exemplary embodiment,
as to the following cases A to C with reference to Figs. 2 to 10.
[0030]
This case "A" deals with a case where the cMME 40 serves as storage only for the
security context.
[0031] That is, as conceptually shown in Fig. 16, the cMME 40 includes security context
storage 101, a receiving unit 102 and a sending unit 103. The receiving unit 102
receives security context from the MME 30, and stores the received security context in
the storage 101. The sending unit 103 reads out the stored security context from the
storage 101 in response to a request from the MME 30, and sends the read context to
the MME 30.
[0032] On the other hand, the MME 30 includes a security function unit 201, a mobility
management unit 202, a sending unit 203 and a receiving unit 204. The security
function unit 201 creates and updates security context for the UE 10. The mobility
management unit 202 manages mobility of the UE 10. The sending unit 203 and the
receiving unit 204 send and receive various signaling messages from and to the UE 10,
the MME 30 and the HSS 50. In particular, the sending unit 203 sends the security
context and a request therefor to the cMME 40. The receiving unit 204 receives the
security context from the cMME 40. Functionalities of the MME 30 are simplified
compared with a typical MME, because the security context storage is shifted to the
cMME 40.
[0033] Briefly, in this case "A", the following operations (1) to (4) are carried out.
(1) AKA and NAS SMC procedures (carried by the MME 30) will result in keys
that should be stored in the storage (cMME 40).
(2) Current security context is stored in storage (cMME 40).
(3) Every time the MME 30 switches off or goes down, the MME 30 updates all
security context stored in the storage (cMME 40).
(4) When the UE 10 connects to the MME 30 (Attach or Mobility), the security
context can be pulled from the storage (cMME 40).
[0034] In the above operation (1), as shown by dotted lines in Fig. 2, the MME 30 can
access the HSS 50 on demand through the existing interface. In the above operations
(2) to (4), as shown by thick lines in Fig. 2, the MME 30 and the cMME 40 interact
with each other through new interface.
[0035] Specifically, as shown in Fig. 3, at the initial phase, the UE 10 sends an Attach
Request message to the MME 30 as in the existing attach procedure (step SI 1).
[0036] The MME 30 performs the existing AKA and NAS SMC procedures, as in NPL 1
(steps S12a and S12b). Successful NAS SMC procedure results in the UE 10 and the
MME 30 sharing same NAS security context which includes NAS keys (step S12c).
[0037] After that, the UE 10 and the eNB 20 interact with each other to perform AS
(Access Stratum) SMC procedure (step S12d). Successful AS SMC procedure results
in the UE 10 and the eNB 20 sharing same AS security context which includes AS
keys (step S12e). Note that the AS keys are used for protecting integrity and confi
dentiality of traffic at RRC (Radio Resource Control) protocol layer between the UE
10 and the eNB 20.
[0038] In parallel with the AS SMC procedure, the MME 30 sends a Security Context
Update message to the cMME 40 (step S13a). This message includes UE ID (identifier
of the UE 10) and NAS security context which contains KSI, Kasme and NAS keys.
[0039] The cMME 40 stores the security context received at step S13a (step S13b), and
sends a Security Context Update Ack (Acknowledgment) message to the MME 30
(step SI 3c).
[0040] The MME 30 sends an Attach response message to the UE 10 (step S14).
[0041] After that, due to power-off, overload or system down, the MME 30 starts Switchoff
procedure (step S21).
[0042] In this procedure, the MME 30 sends a Security Context Update message to the
cMME 40 (step S22a). This message includes the UE ID and the latest NAS security
context which contains KSI, Kasme and NAS keys.
[0043] The cMME 40 updates the security context stored for the given UE 10 with the
latest security context received at step S22a (step S22b), and sends a Security Context
Update Ack message to the MME 30 (step S22c).
[0044] Then, the MME 30 removes the security context which the MME 30 kept local
(step S23).
[0045] On the other hand, in mobility, the network system operates as shown in Fig. 4.
Note that the operation shown in Fig. 4 takes, as an example, a case where the UE 10
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.
[0046] Specifically, the UE 10 sends an Attach Request message, a TAU Request
message, or a Handover Request message to the New MME 30_2 (step S31).
[0047] The New MME 30_2 will not go to the Old MME 30_1 , but request for security
context from the cMME 40, by sending a Security Context Request message including
the UE ID to the cMME 40 (step S32a).
[0048] The cMME 40 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).
[0049] Then, the New MME 30_2 sends a response message to the Attach or Mobility
request back to the UE 10 (step S33). This message can be protected by the NAS keys
received from the cMME 40.
[0050] 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.
[0051]
This case "B" deals with a case where the cMME 40 has complete security func
tionalities.
[0052] That is, as conceptually shown in Fig. 17, the cMME 40 further includes a security
function unit 104 in addition to the elements shown in Fig. 16. The security function
unit 104 creates and updates security context for the UE 10, as a substitute for the
MME 30. The sending unit 103 can send the security context to the MME 30.
[0053] On the other hand, the security function unit 201 shown in Fig. 16 is removed
from the MME 30, and is shifted to the cMME 40 as the security function unit 104.
Thus, functionalities of the MME 30 are further simplified compared with those shown
in Fig. 16.
[0054] Briefly, in this case "B", the following operations (1) to (3) are carried out.
(1) AKA and NAS SMC procedures happen at the offload location (cMME 40).
(2) NAS keys are passed to the MME 30 after SMC.
(3) On handover (SI or X2), NH (Next Hop) is calculated at the offload location
(cMME 40) and passed to the eNB 20.
[0055] In the above operations (1) to (3), as shown by thick lines in Fig. 5, the cMME 40
interacts with the HSS 50 and the MME 30 through new interfaces.
[0056] Specifically, as shown in Fig. 6, at the initial phase, the UE 10 sends an Attach
Request message to the MME 30 as in the existing attach procedure (step S41).
[0057] AKA and NAS SMC procedures are carried between the UE 10 and the cMME 40
(step S42a), and the cMME 40 interacts with the HSS 50 on demand (step S42b).
Successful NAS SMC procedure results in the UE 10 and the cMME 40 sharing same
NAS security context (step S42c).
[0058] After that, the UE 10 and the eNB 20 interact with each other to perform AS SMC
procedure (step S42d). Successful AS SMC procedure results in the UE 10 and the
eNB 20 sharing same AS security context (step S42e).
[0059] In parallel with the AS SMC procedure, the c MME 40 sends a Security Context
Update message to the MME 30 (step S43a). This message includes the UE ID and the
NAS security context which contains KSI, Kasme and NAS keys.
[0060] The MME 30 stores the security context received at step S43a (step S43b), and
sends a Security Context Update Ack message to the cMME 40 (step S43c).
[0061] Then, the MME 30 sends an Attach response message to the UE 10 (step S44).
[0062] After that, due to power-off, overload or system down, the MME 30 starts Switchoff
procedure (step S51).
[0063] In this procedure, unlike the above case "A", the MME 30 merely removes the
security context which the MME 30 kept local (step S52).
[0064] On the other hand, in mobility, the network system operates as shown in Fig. 7.
Note that the operation shown in Fig. 7 takes, as an example, a case where the UE 10
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.
[0065] Specifically, the UE 10 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 10 to
the cMME 40.
[0066] The cMME 40 sends the latest UE context to the MME 30, 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).
[0067] The MME 30 stores the received security context (step S62b), and sends a Security
Context Update Ack message back to the cMME 40 (step S62c).
[0068] Then, the cMME 40 sends a Response message to the Attach or Mobility request
to the UE 10 (step S64).
[0069] Moreover, in Mobility, the cMME 40 also generates or calculates NH (step S63),
and sends the NH to the eNB 20 (step S65). Note that the NH is one of parameters
necessary for AS security.
[0070] 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. Ac
cordingly, 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.
[0071] 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.
[0072]
This case "C" deals with a case where the cMME 40 has complete security func
tionalities and direct connection to the eNB 20.
[0073] Conceptually, the cMME 40 and the MME 30 in this case "C" can be configured
as with those shown in Fig. 17. Meanwhile, unlike the above case "B", the receiving
unit 102 and the sending unit 103 can send and receive signaling messages directly
from and to the UE 10, through the eNB 20.
[0074] Briefly, in this case "C", the following operations (1) and (2) are carried out.
(1) Everything will happen similar to the above case "B" except that the MME 30
will not be in middle.
(2) Offload location (cMME 40) will send keying material to the MME 30 and the
eNB 20.
[0075] In the above operations (1) and (2), as shown by thick lines in Fig. 8, the cMME
40 interacts with the HSS 50, the MME 30 and the eNB 20 through new interfaces.
[0076] Specifically, as shown in Fig. 9, at the initial phase, the UE 10 sends an Attach
Request message to the cMME 40 (step S71).
[0077] AKA and NAS SMC procedures are carried between the UE 10 and the cMME 40
(step S72a), and the cMME 40 interacts with the HSS 50 on demand (step S72b).
Successful NAS SMC procedure results in the UE 10 and the cMME 40 sharing same
NAS security context (step S72c).
[0078] Here, the MME 30 supports initial communication/connection (communication
and/or connection) set up between the UE 10 and the cMME 40. After that, (NAS)
security related function shifts to the cMME 40, and the rest stays at the MME 30.
NAS security protection and check are carried out at the cMME 40.
[0079] Therefore, no security context needs to be handled at the MME 30. Moreover,
upon the Switch-off procedure, no action needs to be taken at the MME 30.
[0080] On the other hand, in mobility, the network system operates as shown in Fig. 10.
Note that the operation shown in Fig. 10 takes, as an example, a case where the UE 10
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.
[0081] Specifically, the UE 10 sends an Attach Request message, a TAU Request
message, or a Handover Request message directly to the cMME 40 (step S81). The
cMME 40 takes full responsibility for security.
[0082] 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.
[0083] Moreover, in Mobility, the cMME 40 calculates NH (step S83), and sends the NH
to the eNB 20 (step S84).
[0084] 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.
[0085] 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.
[0086] Next, there will be described configuration examples of the MME 30 and the
cMME 40 with reference to Figs. 11 to 15.
[0087] Firstly regarding the configuration of the MME 30 in the above case "A", as
shown in Fig. 11, the MME 30 includes at least a pushing unit 31. The pushing unit 3 1
pushes the security context to the cMME 40, at the initial phase. The pushing unit 31
may further push the latest security context to the cMME 40, during the Switch-off
procedure. Moreover, the MME 30 may include a pulling unit 32. The pulling unit 32
pulls the security context from the cMME 40, upon the Re-attach and/or Mobility.
[0088] In the above case "B", as shown in Fig. 12, the MME 30 includes a receiving unit
33 and a storing unit 34. The receiving unit 33 receives the security context from the
cMME 40, at the initial phase. The storing unit 34 stores the received security context.
The receiving unit 33 may further receive the latest security context from the cMME
40, upon the Re-attach and/or Mobility.
[0089] These units 3 1 to 34 as well as other element(s) of the MME 30 can be im
plemented by at least hardware such as a transceiver which conducts communication
with the eNB 20, the cMME 40 and the HSS 50, as well as a controller like a CPU
(Central Processing Unit) which control this transceivers to execute the processes
shown in each of Figs. 3, 4, 6 and 7, or processes equivalent thereto. The MME 30 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).
[0090] Next regarding the configuration of the cMME 40 in the above case "A", as shown
in Fig. 13, the cMME 40 includes at least a receiving unit 4 1 and a storing unit 42. The
receiving unit 4 1 receives the security context pushed from the MME 40, at the initial
phase. The storing unit 42 stores the received security context. The receiving unit 4 1
may further receive the latest security context pushed from the MME 30, during the
Switch-off procedure. The storing unit 42 updates the stored security context with the
latest security context. Moreover, the cMME 40 may include a sending unit 43. The
sending unit 43 sends the stored security context to the MME 30, in response to the
Re-attach or Mobility request from the MME 30.
[0091] In the above case "B", as shown in Fig. 14, the cMME 40 includes at least a
generating unit 44 and a pushing unit 45. The generating unit 44 generates the security
context at the initial phase. The pushing unit 45 pushes the security context to the
MME 30. The pushing unit 45 may push the latest security context, upon the Re-attach
and/or Mobility. Moreover, the cMME 40 may include a calculating unit 46. The cal
culating unit 46 calculates the NH in Mobility, and sends the NH through the MME 30
to the eNB 20.
[0092] In the above case "C", as shown in Fig. 15, the cMME 40 includes at least a
managing unit 47. The managing unit 47 centrally manages the security context,
through the direct connection to the eNB 20. Mobility of the UE 10 is supported from
the MME 30. Moreover, the cMME 40 may include a calculating unit 48. The calculating
unit 48 calculates the NH in Mobility, and sends the NH through the direct
connection to the eNB 20.
[0093] These units 4 1 to 48 as well as other element(s) of the cMME 40 can be im
plemented by at least hardware such as a transceiver which conducts communication
with the eNB 20, the MME 30 and the HSS 50, as well as a controller like a CPU
which control this transceivers to execute the processes shown in each of Figs. 3, 4, 6,
7, 9 and 10, or processes equivalent thereto. The cMME 40 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).
[0094] 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.
[0095] Also, the above-described program can be stored and provided to the computer
using any type of non-transitory computer readable medium. The non-transitory
computer readable medium includes any type of tangible storage medium. Examples of
the non-transitory computer readable medium include magnetic storage media (such as
floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media
(e.g. magneto-optical disks), CD-ROM (Read Only Memory), CD-R , CD-R/W, and
semiconductor memories (such as mask ROM, PROM (Programmable ROM),
EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory), etc.). The
program may be provided to a computer using any type of transitory computer
readable medium. Examples of the transitory computer readable medium include
electric signals, optical signals, and electromagnetic waves. The transitory computer
readable medium can provide the program to a computer via a wired communication
line such as an electric wire or optical fiber or a wireless communication line.
[0096] The whole or part of the exemplary embodiment disclosed above can be described
as, but not limited to, the following supplementary notes.
[0097] (Supplementary note 1)
New architecture - partially offload MME security function or all.
(Supplementary note 2)
MME do not need to keep the security context when UE moves away.
(Supplementary note 3)
MME does not need to know previous MME/SGSN to retrieve security context.
(Supplementary note 4)
Centralized security function and/or context management, efficiency for virtualization.
(Supplementary note 5)
New messages - security context update and Ack, security context request and
response.
(Supplementary note 6)
Storing security context on cloud MME, instead of (local) MME itself. This can
reduce signaling message when UE changes a MME, or when MME is down.
(Supplementary note 7)
cMME performs AKA and NAS SMC, and send the security context to local MME.
This can reduce MME cost; and achieve the merit in Supplementary note 6.
(Supplementary note 8)
cMME has full security function, and direct NEW interface with eNB. This can
reduce large signaling especially in mobility.
[0098] This application is based upon and claims the benefit of priority from Japanese
patent application No. 2015-026201, filed on February 13, 2015, the disclosure of
which is incorporated herein in its entirety by reference.
Reference Signs List
[0099] 10 UE
20, 20_l-20_3 eNB
30, 30_l-30_2 MME
31, 45 PUSHING UNIT
32 PULLING UNIT
33, 4 1 RECEIVING UNIT
34, 42 STORING UNIT
40 cMME
43 SENDING UNIT
44 GENERATING UNIT
46, 48 CALCULATING UNIT
47 MANAGING UNIT
50 HSS
101 SECURITY CONTEXT STORAGE
102, 204 RECEIVING UNIT
103, 203 SENDING UNIT
104, 201 SECURITY FUNCTION UNIT
202 MOBILITY MANAGEMENT UNIT

Claims
A network system comprising:
one or more first MMEs (Mobility Management Entities); and
a second MME separated from the first MMEs,
wherein the first MME pushes, to the second MME, security context
for a UE (User Equipment) that attaches to the first MME, and
wherein the second MME stores the security context.
The network system according to Claim 1,
wherein the first MME further pushes the latest security context to
the second MME, during a switch-off procedure for the first MME, and
wherein the second MME updates the stored security context with
the latest security context.
The network system according to Claim 1 or 2,
wherein the first MME pulls the security context from the second
MME, when the UE re-attaches to the first MME or is handovered from
different one of the first MMEs.
An MME (Mobility Management Entity) comprising:
pushing means for pushing, to a second MME separated from the
MME, security context for a UE (User Equipment) that attaches to the
MME,
wherein the second MME is also separated from one or more first
MMEs to which the UE can attach and which is different from the
MME.
The MME according to Claim 4,
wherein the pushing means is configured to further push the latest
security context to the second MME, during a switch-off procedure for
the MME.
The MME according to Claim 4 or 5, further comprising:
pulling means for pulling the security context from the second MME,
when the UE re-attaches to the MME or is handovered from one of the
first MMEs.
An MME (Mobility Management Entity) separated from one or more
first MMEs, the MME comprising:
receiving means for receiving security context pushed from the first
MME, the security context for a UE (User Equipment) that attaches to
the first MME; and
storing means for storing the security context.
PCT/JP2016/000512
The MME according to Claim 7,
wherein the receiving means is configured to further receive the
latest security context pushed from the first MME, during a switch-off
procedure for the first MME, and
wherein the storing means is configured to update the stored security
context with the latest security context.
The MME according to Claim 7 or 8, further comprising:
sending means for sending the stored security context to the first
MME,
wherein the sending means is configured to send the stored security
context in response to a request from the first MME, the request being
issued when the UE re-attaches to the first MME or is handovered from
different one of the first MMEs.
A method of managing security context in an MME (Mobility
Management Entity), the method comprising:
pushing, to a second MME separated from the MME, security
context for a UE (User Equipment) that attaches to the MME,
wherein the second MME is also separated from one or more first
MMEs to which the UE can attach and which is different from the
MME.
A method of managing security context in an MME (Mobility
Management Entity) separated from one or more first MMEs, the
method comprising:
receiving security context pushed from the first MME, the security
context for a UE (User Equipment) that attaches to the first MME; and
storing the security context.
A network system comprising:
one or more first MMEs (Mobility Management Entities); and
a second MME separated from the first MMEs,
wherein the second MME generates security context for a UE (User
Equipment) that requests to attach to the first MME, and pushes the
security context to the first MME, and
wherein the first MME stores the security context.
The network system according to Claim 12,
wherein the second MME pushes the latest security context, when
the UE re-attaches to the first MME or is handovered from different
one of the first MMEs.
The network system according to Claim 13,
WO 2016/129238 PCT/JP2016/000512
wherein when the UE performs handover, the second MME
calculates NH (Next Hop) for the handover, and sends the NH through
the first MME to an eNB (evolved Node B) to which the UE wirelessly
connects.
[Claim 15] An MME (Mobility Management Entity) comprising:
receiving means for receiving, from a second MME separated from
the MME, security context for a UE (User Equipment) that requests to
attach to the MME; and
storing means for storing the security context,
wherein the second MME is also separated from one or more first
MMEs to which the UE can attach and which is different from the
MME.
[Claim 16] The MME according to Claim 15,
wherein the receiving means is configured to further receive the
latest security context from the second MME, when the UE re-attaches
to the MME or is handovered from one of the first MMEs.
[Claim 17] An MME (Mobility Management Entity) separated from one or more
first MMEs, the MME comprising:
generating means for generating security context for a UE (User
Equipment) that requests to attach to the first MME; and
pushing means for pushing the security context to the first MME.
[Claim 18] The MME according to Claim 17,
wherein the pushing means is configured to push the latest security
context, when the UE re-attaches to the first MME or is handovered
from different one of the first MMEs.
[Claim 19] The MME according to Claim 18, further comprising:
calculating means for calculating, when the UE performs handover,
NH (Next Hop) for the handover, and for sending the NH through the
first MME to an eNB (evolved Node B) to which the UE wirelessly
connects.
[Claim 20] A method of managing security context in an MME (Mobility
Management Entity), the method comprising:
receiving, from a second MME separated from the MME, security
context for a UE (User Equipment) that requests to attach to the MME;
and
storing the security context,
wherein the second MME is also separated from one or more first
MMEs to which the UE can attach and which is different from the
WO 2016/129238 PCT/JP2016/000512
MME.
[Claim 21] A method of managing security context in an MME (Mobility
Management Entity) separated from one or more first MMEs, the
method comprising:
generating security context for a UE (User Equipment) that requests
to attach to the first MME; and
pushing the security context to the first MME.
[Claim 22] A network system comprising:
one or more first MMEs (Mobility Management Entities); and
a second MME separated from the first MMEs,
wherein the second MME centrally manages security context for a
UE (User Equipment) that requests to attach to a network, through a
direct connection to an eNB (evolved Node B) to which the UE
wirelessly connects,
wherein the first MME supports mobility of the UE to the second
MME.
[Claim 23] The network system according to Claim 22,
wherein when the UE is handovered from one of the first MMEs to
another, the second MME calculates NH (Next Hop) for the handover,
and sends the NH through the direct connection to the eNB.
[Claim 24] An MME (Mobility Management Entity) separated from one or more
first MMEs, the MME comprising:
managing means for centrally managing security context for a UE
(User Equipment) that requests to attach to a network, through a direct
connection to an eNB (evolved Node B) to which the UE wirelessly
connects,
wherein the first MME supports mobility of the UE to the MME.
[Claim 25] The MME according to Claim 24, further comprising:
calculating means for calculating, when the UE is handovered from
one of the first MMEs to another, NH (Next Hop) for the handover, and
for sending the NH through the direct connection to the eNB.
[Claim 26] A method of managing security context in an MME (Mobility
Management Entity) separated from one or more first MMEs, the
method comprising:
centrally managing security context for a UE (User Equipment) that
requests to attach to a network, through a direct connection to an eNB
(evolved Node B) to which the UE wirelessly connects,
wherein the first MME supports mobility of the UE to the MME.