EP3281433A1

EP3281433A1 - Apparatus and method for requesting and providing security credentials for specific networks

Info

Publication number: EP3281433A1
Application number: EP16714419.5A
Authority: EP
Inventors: Anja Jerichow; Guenther Horn
Original assignee: Nokia Solutions and Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2015-04-10
Filing date: 2016-04-05
Publication date: 2018-02-14
Also published as: WO2016162322A1

Abstract

Systems, methods, apparatuses, and computer program products for requesting and providing security credentials for specific networks are provided. One method includes sending, by a network entity, at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode. The at least one request comprises an isolated operation mode serving network identifier (SN ID). The method also includes receiving a response, from a home subscription server, comprising authentication vectors for each of the IMSIs listed in the at least one request, and storing, by the network entity, the list of IMSIs and their authentication vectors.

Description

APPARATUS AND METHOD FOR REQUESTING AND PROVIDING SECURITY CREDENTIALS FOR SPECIFIC NETWORKS

BACKGROUND:

Field:

[0001] Embodiments of the invention generally relate to wireless or mobile communications networks, such as, but not limited to, the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E- UTRAN), LTE-Advanced (LTE-A), future 5G radio access technology, and/or High Speed Packet Access (HSPA).

Description of the Related Art:

[0002] Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) refers to a communications network including base stations, or Node Bs, and for example radio network controllers (RNC). UTRAN allows for connectivity between the user equipment (UE) and the core network. The RNC provides control functionalities for one or more Node Bs. The RNC and its corresponding Node Bs are called the Radio Network Subsystem (RNS). In case of E- UTRAN (enhanced UTRAN), no RNC exists and radio access functionality is provided in the enhanced Node B (eNodeB or eNB) or many eNBs. Multiple eNBs are involved for a single UE connection, for example, in case of Coordinated Multipoint Transmission (CoMP) and in dual connectivity.

[0003] Long Term Evolution (LTE) or E-UTRAN provides a new radio access technology and refers to the improvements of UMTS through improved efficiency and services, lower costs, and use of new spectrum opportunities. In particular, LTE is a 3GPP standard that provides for uplink peak rates of at least, for example, 75 megabits per second (Mbps) per carrier and downlink peak rates of at least, for example, 300 Mbps per carrier. LTE supports scalable carrier bandwidths from 20 MHz down to 1.4 MHz and supports both Frequency Division Duplexing (FDD) and Time Division Duplexing (TDD).

[0004] As mentioned above, LTE may also improve spectral efficiency in networks, allowing carriers to provide more data and voice services over a given bandwidth. Therefore, LTE is designed to fulfill the needs for highspeed data and media transport in addition to high-capacity voice support. Advantages of LTE include, for example, high throughput, low latency, FDD and TDD support in the same platform, an improved end-user experience, and a simple architecture resulting in low operating costs.

[0005] Certain releases of 3 GPP LTE (e.g., LTE Rel-11, LTE Rel-12, LTE Rel-13) are targeted towards international mobile telecommunications advanced (IMT-A) systems, referred to herein for convenience simply as LTE- Advanced (LTE-A).

[0006] LTE-A is directed toward extending and optimizing the 3 GPP LTE radio access technologies. A goal of LTE-A is to provide significantly enhanced services by means of higher data rates and lower latency with reduced cost. LTE-A is a more optimized radio system fulfilling the international telecommunication union-radio (ITU-R) requirements for IMT- Advanced while keeping the backward compatibility. One of the key features of LTE-A, introduced in LTE Rel-10, is carrier aggregation, which allows for increasing the data rates through aggregation of two or more LTE carriers, e.g., to the transmission bandwidth of up to 100 MHz. LTE-A in later releases may include even wider bandwidths as specified so far. Further, aggregating or interworking on the radio access level with the wireless LAN (WLAN) access network is foreseen.

BRIEF DESCRIPTION OF THE DRAWINGS: [0007] For proper understanding of the invention, reference should be made to the accompanying drawings, wherein:

[0008] Fig. 1 illustrates an example high level system architecture depicting the relation between EPC and IOPS network, according to an embodiment;

[0009] Fig. 2 illustrates an example block diagram depicting the protocol between a local MME and main HSS, according to an embodiment;

[0010] Fig. 3 illustrates an example block diagram depicting attach of IOPS- capable UE to IOPS network, according to an embodiment;

[0011] Fig. 4a illustrates the current usage of an array from 3GPP TS

33.102;

[0012] Fig. 4b illustrates an example of the improvement to the array, according to an embodiment;

[0013] Fig. 5 illustrates an example block diagram of an apparatus, according to an embodiment;

[0014] Fig. 6 illustrates an example block diagram of an apparatus, according to an embodiment;

[0015] Fig. 7 illustrates an example block diagram of an apparatus, according to an embodiment;

[0016] Fig. 8a illustrates an example flow diagram of a method, according to one embodiment;

[0017] Fig. 8b illustrates an example flow diagram of a method, according to another embodiment;

[0018] Fig. 8c illustrates an example flow diagram of a method, according to another embodiment;

[0019] Fig. 9a illustrates an example block diagram of an apparatus, according to an embodiment;

[0020] Fig. 9b illustrates an example block diagram of an apparatus, according to an embodiment; and [0021] Fig. 9c illustrates an example block diagram of an apparatus, according to an embodiment.

DETAILED DESCRIPTION:

[0022] It will be readily understood that the components of the invention, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of embodiments of systems, methods, apparatuses, and computer program products for requesting/providing security credentials for specific networks, as represented in the attached figures, is not intended to limit the scope of the invention, but is merely representative of some selected embodiments of the invention.

[0023] The features, structures, or characteristics of the invention described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, the usage of the phrases "certain embodiments," "some embodiments," or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment of the present invention. Thus, appearances of the phrases "in certain embodiments," "in some embodiments," "in other embodiments," or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0024] Additionally, if desired, the different functions discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions may be optional or may be combined. As such, the following description should be considered as merely illustrative of the principles, teachings and embodiments of this invention, and not in limitation thereof.

[0025] Public safety organisations consider LTE to be the next generation technology for augmenting existing communication systems and defining new critical communication systems. Keeping communication secure is of utmost importance while ensuring that public safety users, such as emergency responders, can continue communication within mission critical situations.

[0026] Embodiments of the invention relate to security for an isolated operation mode network, such as in isolated operation of E-UTRAN for public safety (IOPS) users. An isolated E-UTRAN network may comprise a single eNB or multiple eNBs. The UEs in the coverage of the Isolated E- UTRAN network should be able to continue communicating among each other and provide a restricted set of services supporting voice, data and group communications, to their public safety users. An IOPS-capable eNB refers to an eNB that has the capability of IOPS mode operation, which provides a local IP connectivity and public safety services to the UEs via Local evolved packet core (EPC) when the eNB has lost backhaul to the Macro EPC or it has no backhaul to the Macro EPC.

[0027] SA1 has specified in 3 GPP TS 22.346 a set of requirements for Isolated E-UTRAN and states that "The Isolated E-UTRAN is expected to provide for the authentication of participating entities and for the confidentiality and integrity of communications." Section 5.6.2 of TS 22.346 lists the requirements for security, authorization and privacy to be equal to that of existing LTE security.

[0028] It is noted that an Isolated E-UTRAN is characterized by having no backhaul connection or a limited backhaul connection. Limited backhaul means that either only limited bandwidth signalling backhaul or both limited bandwidth signalling and user data backhaul is available.

[0029] SA2 TR 23.797 defines an IOPS network as one or more eNBs with a co-located local EPC with no or limited backhaul. It may be operated with a fully functional "local EPC", in which case all EPC network elements, such as the local mobility management entity (MME), would be available. In an IOPS network with no backhaul, a local home subscriber server/authentication center (HSS/AuC) would need to have subscription details of all IOPS-UEs for running authentication and key agreement (AKA).

[0030] Fig. 1 illustrates an example high level system architecture depicting the relation between EPC and IOPS network. As illustrated in Fig. 1, the system may include an eNB 100, local EPC 110, and Macro EPC 120. The Local EPC 110 is an entity which provides functionality that eNBs in IOPS mode of operation use, instead of the Macro EPC 120, in order to support public safety services. Meanwhile, the Macro EPC is the EPC which serves an eNB in normal mode of operation. The local EPC 110 may include a local MME, local HSS/AuC, and other local components. The Macro EPC 120 may include a MME, HSS/AuC, and other components.

[0031] A MME may be considered the main control node for a core network. Some features handled by MME may include: bearer activation/de-activation, idle mode UE tracking, choice of serving gateway (SGW) for a UE, intra-LTE handover involving core network node location, interacting with the HSS to authenticate user on attachment, and providing temporary identities for UEs. HSS refers to a server comprising a central database that contains user-related and subscription-related information, for example. Functions of the HSS may be related to mobility management, call and session establishment support, user authentication and access authorization.

[0032] As described in the SA3 study item description: "the security mechanism(s) supported by an Isolated E-UTRAN shall be consistent with the dynamic nature of an Isolated E-UTRAN. The security of credentials shall not be compromised by solutions for Isolated E-UTRAN operation; furthermore the security provided by an Isolated E-UTRAN shall be comparable with that provided by the existing 3GPP system. Existing 3GPP security mechanisms shall be reused whenever possible and appropriate."

[0033] Thus, the local HSS/AuC may need to be pre-configured to accept IOPS users. And the local HSS/AuC may need to contain the permanent secret keys of the IOPS users. However, due to the physically exposed nature of an isolated E-UTRAN network, there is a higher risk than with a regular HSS that the permanent secret keys may be stolen or compromised. Furthermore, if a network operator does not want to limit the users of the IOPS networks according to the configuration and seeks more flexibility, other options should be explored.

[0034] Therefore, a problem that needs to be addressed is how an isolated E- UTRAN network could be operated without the need for a local HSS and how one could switch after an interruption of the backhaul link from normal operations to isolated E-UTRAN operation when there is no local HSS. In addition, there may be a need to determine which credentials can be used to fulfil the objectives as described in the SA3 study item, and how to transfer credentials to the local EPC of the IOPS network.

[0035] In view of the above, one embodiment is directed to modifying the triggers for a protocol between local MME and main HSS. In an embodiment, the local MME may request pro-actively authentication vectors from the main HSS, i.e., before the IOPS-capable UE has started an attach request. Local MMEs have a storage for authentication vectors (AVs) that come into usage when an IOPS-capable UE attaches and no backhaul is available.

[0036] Accordingly, another embodiment addresses a problem where a universal subscriber identity module (USIM) application of any UE would reject AVs in case of sequence failure. Thus, an embodiment ensures that AVs from local MMEs are accepted.

[0037] 3 GPP TS 22.346 describes Isolated E-UTRAN operation for two situations: 1) In the event of an interruption to normal backhaul connectivity Isolated E-UTRAN operation aims to adapt to the failure and maintain an acceptable level of network operation in the Isolated E-UTRAN. The restoration of service is the eventual goal; and 2) Operation following the deployment of one or more nomadic eNBs either without backhaul or with limited backhaul. In the following, situation 1 is assumed, where normal backhaul connectivity was available at least at one point in time before being in isolated operation mode.

[0038] One embodiment includes modifying the triggers for a protocol between a local MME and main HSS. Embodiments are able to keep the new protocols unchanged from the existing protocols to the extent possible. In other words, according to certain embodiments, a local MME may behave in the same way as a normal MME would when requesting authentication vectors from the main HSS. Thus, the local MME behaves like the MME of a Visited Public Land Mobile Network (VPLMN) and requests authentication vectors from the main HSS.

[0039] According to an embodiment, a difference from normal procedures is that normally a UE would trigger such an MME request to the main HSS by sending an Attach request. Alternatively, a MME would have authentication vectors from an earlier request available and does not need to contact the HSS. Further, a local MME would usually only be activated when the E- UTRAN is in IOPS mode.

[0040] However, certain embodiments provide that the local MME becomes active for the purpose of fetching authentication vectors from the regular HSS when backhaul is available, i.e., the local MME would pro-actively ask the main HSS to provide authentication vectors (AVs) (K_ASME, RAND, AUTN, XRES) for IOPS-capable UEs and specific for the IOPS network's serving network identifier (SN-Id) (in TR 23.797 called PLMN-Id dedicated for IOPS). For this purpose, the local MME may be pre -provisioned with a list of IOPS-capable UEs. These AVs are dedicated to being used for operating in IOPS mode only. Therefore, the SN-Ids used for IOPS have a special format that needs to be standardized so that UEs can recognize them as pertaining to an E-UTRAN in IOPS mode. To avoid rejection of AUTN by the UE, a mechanism is needed to assure that no sequence failure will happen when using these AVs. This mechanism will be discussed in detail below.

[0041] In an embodiment, the local MME may request and regularly update authentication vectors for each subscriber that is tagged with IOPS in the main HSS. Thus, as a result of certain embodiments, the local MME is now pre-configured with AVs for IOPS-capable UEs.

[0042] According to an embodiment, subscribers (i.e., UEs) that are allowed to be served by IOPS networks in general, or by specific local MMEs, can be identified in the main HSS. In addition, the local MME is activated even though backhaul is available.

[0043] Fig. 2 illustrates an example block diagram depicting the protocol between the local MME and main HSS. In this example, at 1, the local MME initiates contact to HSS of macro EPC 120. At 2, the local MME requests authentication vectors from the HSS for a selected list of IMSIs authorised for IOPS. This may be done via one or several requests. The HSS, at 3, uses the IOPS serving network identifier (SN ID) that the local MME has included in the request, checks it against the IOPS tag for the subscriber, and generates one or several AV(s) for each IOPS-IMSI identified. These AV(s) may be valid for usage only for this particular local EPC 110. At 4, the HSS may provide a response, to the local MME, with the AV(s) including SN ID. The local MME, at 5, may then store a list of IOPS- IMSI(s) and AV(s). [0044] Fig. 3 illustrates an example block diagram depicting attach of IOPS- capable UE 101 to IOPS network 115. According to an embodiment, in a situation where there is no backhaul, an IOPS -capable UE 101 may attempt to attach to an eNB 100 in Isolated E-UTRAN. If this eNB 100 is part of an IOPS network 115, the request may be routed to the local MME of local EPC 110. The local MME may base the AKA run on the IMSI (note that GUTIs, i.e. temporary identities, cannot be available in isolated operation as there has been no previous contact between UE and local MME, and the local MME cannot, by definition of isolated operation, have the GUTI resolved by a previously visited MME). Since the local MME has earlier requested AVs for IOPS-capable UEs, the local MME may select one AV for the requesting IMSI and start AKA. If AKA is successful and a K_ASME has been created in the UE, local MME can continue to use this K_ASME for a long time in isolated E-UTRAN situations.

[0045] It should be noted that embodiments of the invention are not limited to public safety operation. Other use cases can be envisioned, according to some embodiments, where isolated operation mode is desired.

[0046] As mentioned above, another embodiment of the invention is directed to how to handle the sequence number of AVs for the different local MMEs so that no sequence error will be generated by the USIM. Thus, an embodiment provides a mechanism for generating AVs that will not be rejected by the USIM because of sequence number failure in case of IOPS operation. For this, the mechanisms as described in Annex C of 3GPP TS 33.102 can be used as a basis, but they are not sufficient. In particular, if one local MME requests from the main HSS a set of AVs, it must be indicated that the following AVs are requested for the specific IOPS mode (similar to if there is a request for IMS AVs etc). In addition, to support the array mechanism as described in TS 33.102, section C 1.2, also in IOPS operation, the layout of the array which contains the sequence numbers generated by the AuC must be adapted to IOPS mode of operation.

[0047] Fig. 4a illustrates the current usage of the index values in the array scheme as described in 3GPP TS 33.102. Fig. 4b illustrates an example of the improvement to the array scheme from 3GPP TS 33.102, according to an embodiment of the invention. In particular, in this embodiment, the total range of index values in the array scheme as specified in Annex C of 3 GPP TS 33.102 is split into as many disjoint groups of index values as necessary to support the traditional domains such as CS, PS, LTE, IMS, etc. as well as one or several IOPS domains. Each IOPS domain may be comprised of one or several IOPS Serving Networks. Each IOPS Serving Network has its own IOPS SN ID. In this way, there is no risk of overlapping sequence numbers between different IOPS domains or between IOPS domains and traditional domains, since the index number (IND) is part of the sequence number (SQN). And therefore UEs moving between different IOPS domains do not risk synchronisation failures when they attach and need to run an AKA.

[0048] The sequence number management scheme affects the USIM and the HSS. IND of longer bit length could be supported by the USIM. Apart from this configuration, the procedure is transparent to the USIM. USIM does not need to know whether the AV is for IOPS usage or not. In addition to the applicable domain (one of the traditional domains or one of the IOPS domains), the HSS should know for which SN ID the AVs are generated. IOPS-AVs may be requested from HSS by several local MMEs.

[0049] If HSS evaluates a request by a local MME and finds out that this is a request for IOPS AVs, it determines a suitable index value from the IOPS SN-Id and uses this index value for preparing the AVs that are bound to the IOPS SN ID.

[0050] It should be noted that an alternative embodiment may further consider modifying the threshold L defined in 3 GPP TS 33.102, C.2.2. L may be set to a very large value as AVs in a local-MME can remain there for a long time while many AVs are consumed in normal operation.

[0051] In one example implementation, as a precondition, the HSS knows the SN ID and also knows that this SN ID is an IOPS-SN ID. The SN ID of an IOPS local evolved packet core (EPC) allows the HSS to recognise that a request for AVs (authentication data request) is for IOPS over LTE. The HSS may check the subscriber record for the IOPS tag and proceeds if the tag says "IOPS" or "IOPS for this SN-Id" (depending on the granularity of the information given by the tag). The HSS may then generate AVs for EPS as specified in 3GPP TS 33.401 and in accordance with the additional features provided by embodiments of the present invention. Thereby, the HSS applies the array mechanism as in 3GPP TS 33.102, Annex C. The HSS sets apart a subset of indices (IND) from the total set of indices such that this subset is exclusively used for IOPS purposes as explained above in reference to Fig. 4b.

[0052] The HSS may send the AVs to the requesting local-MME (and/or to OAM entity allowed to access the HSS that then transfers the retrieved AVs via OAM, e.g. manually, to the local-MME).

[0053] Fig. 5 illustrates an example of an apparatus 20 according to an embodiment. In an embodiment, apparatus 20 may be a node, host, or server in a communications network or serving such a network. In an embodiment, apparatus 20 may be a control node in a network, such as an MME. It should be noted that one of ordinary skill in the art would understand that apparatus 20 may include components or features not shown in Fig. 5.

[0054] As illustrated in Fig. 5, apparatus 20 may include a processor 32 for processing information and executing instructions or operations. Processor 32 may be any type of general or specific purpose processor. While a single processor 32 is shown in Fig. 5, multiple processors may be utilized according to other embodiments. In fact, processor 32 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[0055] Apparatus 20 may further comprise or be coupled to a memory 34 (internal or external), which may be coupled to processor 32, for storing information and instructions that may be executed by processor 32. Memory 34 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor- based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 34 may be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, or any other type of non-transitory machine or computer readable media. The instructions stored in memory 34 may include program instructions or computer program code that, when executed by processor 32, enable the apparatus 20 to perform tasks as described herein.

[0056] In some embodiments, apparatus 20 may also include or be coupled to one or more antennas (not shown) for transmitting and receiving signals and/or data to and from apparatus 20. Apparatus 20 may further include or be coupled to a transceiver 38 configured to transmit and receive information, signals and/or data. For instance, transceiver 38 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) and demodulate information received via the antenna(s) for further processing by other elements of apparatus 20. In other embodiments, transceiver 38 may be capable of transmitting and receiving signals or data directly. [0057] Processor 32 may perform functions associated with the operation of apparatus 20 including, without limitation, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 20, including processes related to management of communication resources.

[0058] In an embodiment, memory 34 stores software modules that provide functionality when executed by processor 32. The modules may include, for example, an operating system that provides operating system functionality for apparatus 20. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 20. The components of apparatus 20 may be implemented in hardware, or as any suitable combination of hardware and software.

[0059] As mentioned above, according to one embodiment, apparatus 20 may be a server, node or host in a communications network or serving such a network, such as a control node or MME. In an embodiment, apparatus 20 may be a local MME as illustrated in Figs. 1-3 discussed above. In this embodiment, apparatus 20 may be controlled by memory 34 and processor 32 to send at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. In an embodiment, the at least one request comprises an isolated operation mode serving network identifier (SN ID). Apparatus 20 may also be controlled by memory 34 and processor 32 to receive a response, from a HSS, comprising authentication vectors for each of the IMSIs listed in the at least one request, and to store the list of IMSIs and their authentication vectors, for example in memory 34.

[0060] According to one embodiment, the authentication vectors are valid to use only for a local evolved packet core (EPC) comprising the apparatus 20. In one example embodiment, the isolated operation mode may be IOPS. [0061] In certain embodiments, apparatus 20 may be controlled by memory 34 and processor 32 to receive a request to attach from a UE, select one of the authentication vectors for the requesting UE's IMSI, and start AKA. According to an embodiment, the SN ID is allocated a set of indices, such that each of the set of indices is specific to one SN ID and does not overlap with any other set.

[0062] Fig. 6 illustrates an example of an apparatus 40 according to an embodiment. In an embodiment, apparatus 40 may be a node, host, or server in a communications network or serving such a network. For example, according to one embodiment, apparatus 40 may be a server in a network, such as an HSS. It should be noted that one of ordinary skill in the art would understand that apparatus 40 may include components or features not shown in Fig. 6.

[0063] As illustrated in Fig. 6, apparatus 40 may include a processor 42 for processing information and executing instructions or operations. Processor 42 may be any type of general or specific purpose processor. While a single processor 42 is shown in Fig. 6, multiple processors may be utilized according to other embodiments. In fact, processor 42 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[0064] Apparatus 40 may further comprise or be coupled to a memory 44 (internal or external), which may be coupled to processor 42, for storing information and instructions that may be executed by processor 42. Memory 44 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor- based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 44 may be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, or any other type of non-transitory machine or computer readable media. The instructions stored in memory 44 may include program instructions or computer program code that, when executed by processor 42, enable the apparatus 40 to perform tasks as described herein.

[0065] In some embodiments, apparatus 40 may also include or be coupled to one or more antennas (not shown) for transmitting and receiving signals and/or data to and from apparatus 40. Apparatus 40 may further include or be coupled to a transceiver 48 configured to transmit and receive information, signals and/or data. For instance, transceiver 48 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) and demodulate information received via the antenna(s) for further processing by other elements of apparatus 40. In other embodiments, transceiver 48 may be capable of transmitting and receiving signals or data directly.

[0066] Processor 42 may perform functions associated with the operation of apparatus 40 including, without limitation, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 40, including processes related to management of communication resources.

[0067] In an embodiment, memory 44 stores software modules that provide functionality when executed by processor 42. The modules may include, for example, an operating system that provides operating system functionality for apparatus 40. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 40. The components of apparatus 40 may be implemented in hardware, or as any suitable combination of hardware and software.

[0068] As mentioned above, according to one embodiment, apparatus 40 may be a server, node or host in a communications network or serving such a network, such as an HSS. According to an embodiment, apparatus 40 may be an HSS/AuC as illustrated in Figs. 1-2 discussed above. In this embodiment, apparatus 40 may be controlled by memory 34 and processor 32 to receive at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. The at least one request may comprise an isolated operation mode SN ID. Apparatus 40 may also be controlled by memory 34 and processor 32 to check the SN ID against an isolated operation mode tag for the subscriber, generate at least one authentication vector for each of the IMSIs, and send a response comprising the generated at least one authentication vector, to a local MME.

[0069] According to one embodiment, apparatus 40 may be controlled by memory 34 and processor 32 to generate the at least one authentication vector by selecting sequence numbers with index values in the array scheme that are selected as explained above in reference to Fig. 4b.

[0070] Fig. 7 illustrates an example of an apparatus 50 according to an embodiment. In an embodiment, apparatus 50 may be a node, host, or server in a communications network or serving such a network. According to one embodiment, apparatus 50 may be a mobile device or UE, for example. It should be noted that one of ordinary skill in the art would understand that apparatus 50 may include components or features not shown in Fig. 7.

[0071] As illustrated in Fig. 7, apparatus 50 may include a processor 52 for processing information and executing instructions or operations. Processor 52 may be any type of general or specific purpose processor. While a single processor 52 is shown in Fig. 7, multiple processors may be utilized according to other embodiments. In fact, processor 52 may include one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on a multi-core processor architecture, as examples.

[0072] Apparatus 50 may further comprise or be coupled to a memory 54 (internal or external), which may be coupled to processor 52, for storing information and instructions that may be executed by processor 52. Memory 54 may be one or more memories and of any type suitable to the local application environment, and may be implemented using any suitable volatile or nonvolatile data storage technology such as a semiconductor- based memory device, a magnetic memory device and system, an optical memory device and system, fixed memory, and removable memory. For example, memory 54 may be comprised of any combination of random access memory (RAM), read only memory (ROM), static storage such as a magnetic or optical disk, or any other type of non-transitory machine or computer readable media. The instructions stored in memory 54 may include program instructions or computer program code that, when executed by processor 52, enable the apparatus 50 to perform tasks as described herein.

[0073] In some embodiments, apparatus 50 may also include or be coupled to one or more antennas (not shown) for transmitting and receiving signals and/or data to and from apparatus 50. Apparatus 50 may further include or be coupled to a transceiver 58 configured to transmit and receive information, signals and/or data. For instance, transceiver 58 may be configured to modulate information on to a carrier waveform for transmission by the antenna(s) and demodulate information received via the antenna(s) for further processing by other elements of apparatus 50. In other embodiments, transceiver 58 may be capable of transmitting and receiving signals or data directly.

[0074] Processor 52 may perform functions associated with the operation of apparatus 50 including, without limitation, precoding of antenna gain/phase parameters, encoding and decoding of individual bits forming a communication message, formatting of information, and overall control of the apparatus 50, including processes related to management of communication resources.

[0075] In an embodiment, memory 54 stores software modules that provide functionality when executed by processor 52. The modules may include, for example, an operating system that provides operating system functionality for apparatus 50. The memory may also store one or more functional modules, such as an application or program, to provide additional functionality for apparatus 50. The components of apparatus 50 may be implemented in hardware, or as any suitable combination of hardware and software.

[0076] As mentioned above, according to one embodiment, apparatus 50 may be a server, node or host in a communications network or serving such a network, such as a UE as illustrated in Fig. 3 discussed above. In an embodiment, apparatus 50 may be controlled by memory 54 and processor 52 to send a request to attach to a local MME. The request to attach may include at least one IMSI authorised for isolated operation mode. In certain embodiments, apparatus 50 may also be controlled by memory 54 and processor 52 to receive AUTN and RAND in an authentication request from the local MME, to verify AUTN and compute RES, to compute KASME, and to send RES in an authentication response to the local MME.

[0077] Fig. 8a illustrates an example flow diagram of a method, according to one embodiment of the invention. In certain embodiments, the method of Fig. 8a may be performed by a network entity, such as a MME. The method of Fig. 8a may include, at 800, sending at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. The at least one request may comprise an isolated operation mode SN ID. The method may also include, at 805, receiving a response, from a home subscription server, comprising authentication vectors for each of the IMSIs listed in the at least one request. The method may then include, at 810, storing, by the local mobility management entity, the list of IMSIs and their authentication vectors. In an embodiment, the authentication vectors may be valid to use only for a local EPC comprising the local mobility management entity.

[0078] According to one embodiment, the method may also include, at 815, receiving a request to attach from a user equipment, selecting, at 820, one of the authentication vectors for the requesting user equipment's IMSI, and, starting, at 825, authentication and key agreement.

[0079] In certain embodiments, the SN ID may be allocated an index specific to this SN ID.

[0080] Fig. 8b illustrates an example flow diagram of a method, according to one embodiment of the invention. In certain embodiments, the method of Fig. 8b may be performed by a network entity, such as a HSS. The method of Fig. 8b may include, at 830, receiving at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. The at least one request may comprise an isolated operation mode SN ID. The method may also include, at 835, checking the SN ID against an isolated operation mode tag for the subscriber. In an embodiment, the method may further include, at 840, generating at least one authentication vector for each of the IMSIs, and, at 845, sending a response comprising the generated at least one authentication vector, to a local mobility management entity.

[0081] In certain embodiments, the generating may further include selecting sequence numbers with index values in the array scheme necessary to support each isolated operation mode SN ID.

[0082] Fig. 8c illustrates an example flow diagram of a method, according to one embodiment of the invention. In certain embodiments, the method of Fig. 8c may be performed by a node in a network, such as a mobile device or UE. The method of Fig. 8c may include, at 850, sending a request to attach to a local MME. The request to attach may include at least one IMSI authorised for isolated operation mode. In certain embodiments, the method may also include, at 855, receiving AUTN and RAND in an authentication request from the local MME, verifying, at 860, AUTN and computing RES, computing KASME at 865, and, sending, at 870, RES in an authentication response to the local MME.

[0083] Fig. 9a illustrates an example block diagram of an apparatus 900, according to another embodiment. In one example, apparatus 900 may be a MME. The apparatus 900 may include, for example, a sending unit 905, receiving unit 910, storing unit 915, selecting unit 917, and authenticating unit 919. In an embodiment, the sending unit 905 may send at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. The at least one request may comprise an isolated operation mode SN ID. The receiving unit 910 may then receive a response, from a HSS, which includes authentication vectors for each of the IMSIs listed in the at least one request. The storing unit 915 may store the list of IMSIs and their authentication vectors. In an embodiment, the authentication vectors may be valid to use only for a local EPC comprising the apparatus 900.

[0084] According to one embodiment, the receiving unit 910 may receive a request to attach from a UE. The selecting unit 917 may select one of the authentication vectors for the requesting UE's IMSI, and the authenticating unit 919 may start authentication and key agreement. In certain embodiments, the SN ID may be allocated an index specific to this SN ID.

[0085] Fig. 9b illustrates an example block diagram of an apparatus 901, according to another embodiment. In one example, apparatus 901 may be a HSS. The apparatus 901 may include, for example, a receiving unit 920, checking unit 925, sending unit 930, and generating unit 935. The receiving unit 920 may receive at least one request for authentication vectors for a selected list of IMSIs authorized for isolated operation mode. The at least one request may comprise an isolated operation mode SN ID. The checking unit 925 may then check the SN ID against an isolated operation mode tag for the subscriber. In an embodiment, the generating unit 935 may generate at least one authentication vector for each of the IMSIs. The sending unit 930 may send a response comprising the generated at least one authentication vector, to a local MME.

[0086] In certain embodiments, the generating unit 935 may be further configured to select sequence numbers with index values in the array scheme as necessary to support each isolated operation mode SN ID

[0087] Fig. 9c illustrates an example block diagram of an apparatus 902, according to another embodiment. In one example, apparatus 902 may be a mobile device or UE. The apparatus 902 may include, for example, a sending unit 940, receiving unit 945, verifying unit 950, and computing unit 955. The sending unit 940 may send a request to attach to a local MME. The request to attach may include at least one IMSI authorised for isolated operation mode. The receiving unit 945 may receive AUTN and RAND in an authentication request from the local MME. The verifying unit 950 may verify AUTN, and the computing unit 955 may compute RES and compute KASME. The sending unit 940 may then send RES in an authentication response to the local MME.

[0088] Embodiments of the invention provide several advantages and/or technical improvements. For example, according to certain embodiments, even if a UE has never been attached to the local MME of an eNB participating in an IOPS network, the local MME can operate autonomously with the pre -provisioned AVs using the above-described embodiments. Also, a local-HSS is not needed according to certain embodiments. Furthermore, UEs can verify that the local network is authorized to serve IOPS users because the key K_ASME is bound to the SN-Id, which the UE can recognize as being associated with IOPS.

[0089] In other embodiments, even if an IOPS-capable UE has never been attached to the IOPS network for a long time, successful verification of sequence number freshness is guaranteed. Also, even if UEs would not be allowed to do a hand-over from one local EPC to another, they still can hop between local IOPS domains without risking synch failure. Thus, embodiments of the present invention introduces flexibility in the management of IOPS networks in terms of possible aggregation of otherwise separated IOPS networks, or split of a larger IOPS network into isolated, smaller ones.

[0090] Programs, also called program products or computer programs, including software routines, applets and macros, may be stored in any apparatus-readable data storage medium and they include program instructions to perform particular tasks. A computer program product may comprise one or more computer-executable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it. Modifications and configurations required for implementing functionality of an embodiment may be performed as routine(s), which may be implemented as added or updated software routine(s). Software routine(s) may be downloaded into the apparatus.

[0091] Software or a computer program code or portions of it may be in a source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers include a record medium, computer memory, readonly memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and software distribution package, for example. Depending on the processing power needed, the computer program may be executed in a single electronic digital computer or it may be distributed amongst a number of computers. The computer readable medium or computer readable storage medium may be a non-transitory medium.

[0092] In other embodiments, the functionality of any method or apparatus described herein may be performed by hardware, for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another embodiment, the functionality may be implemented as a signal, a non-tangible means that may be carried by an electromagnetic signal downloaded from the Internet or other network.

[0093] According to an embodiment, an apparatus, such as a node, device, or a corresponding component, may be configured as a computer or a microprocessor, such as single-chip computer element, or as a chipset, including at least a memory for providing storage capacity used for arithmetic operation and an operation processor for executing the arithmetic operation.

[0094] One having ordinary skill in the art will readily understand that the invention as discussed above may be practiced with steps in a different order, and/or with hardware elements in configurations which are different than those which are disclosed. Therefore, although the invention has been described based upon these preferred embodiments, it would be apparent to those of skill in the art that certain modifications, variations, and alternative constructions would be apparent, while remaining within the spirit and scope of the invention. In order to determine the metes and bounds of the invention, therefore, reference should be made to the appended claims.

Claims

WE CLAIM:

1. A method, comprising:

sending, by a local mobility management entity, at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

wherein the at least one request comprises an isolated operation mode serving network identifier (SN ID);

receiving a response, from a home subscription server, comprising authentication vectors for each of the IMSIs listed in the at least one request; and

storing, by the local mobility management entity, the list of IMSIs and their authentication vectors.

2. The method according to claim 1, wherein the authentication vectors are valid to use only for a local evolved packet core (EPC) comprising the local mobility management entity.

3. The method according to claim 1, further comprising:

receiving a request to attach from a user equipment;

selecting one of the authentication vectors for the requesting user equipment's IMSI; and

starting authentication and key agreement.

4. The method according to claim 1, wherein the SN ID is allocated a set of indices from an array scheme, wherein a total range of index values in the array scheme is split into as many disjoint groups of index values as necessary to support the traditional domains and one or several isolated operation mode domains, and wherein each isolated operation mode domain comprises one or several IOPS Serving Networks.

5. The method according to claim 1, wherein the isolated operation mode comprises isolated operation of E-UTRAN for public safety (IOPS).

6. An apparatus, comprising:

sending means for sending at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

receiving means for receiving a response, from a home subscription server, comprising authentication vectors for each of the IMSIs listed in the at least one request; and

storing means for storing the list of IMSIs and their authentication vectors.

7. The apparatus according to claim 6, wherein the authentication vectors are valid to use only for a local evolved packet core (EPC) comprising the apparatus.

8. The apparatus according to claim 6, further comprising:

receiving means for receiving a request to attach from a user equipment;

selecting means for selecting one of the authentication vectors for the requesting user equipment's IMSI; and

authenticating means for starting authentication and key agreement.

9. The apparatus according to claim 6, wherein the SN ID is allocated a set of indices from an array scheme, wherein a total range of index values in the array scheme is split into as many disjoint groups of index values as necessary to support the traditional domains as well as one or several isolated operation mode domains and each isolated operation mode domain comprises one or several IOPS Serving Networks.

10. The apparatus according to claim 6, wherein the isolated operation mode comprises isolated operation of E-UTRAN for public safety (IOPS).

11. The apparatus according to claim 6, wherein the apparatus comprises a mobility management entity.

12. An apparatus, comprising:

at least one processor; and

at least one memory comprising computer program code,

the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to send at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

receive a response, from a home subscription server, comprising authentication vectors for each of the IMSIs listed in the at least one request; and

store the list of IMSIs and their authentication vectors.

13. The apparatus according to claim 12, wherein the authentication vectors are valid to use only for a local evolved packet core (EPC) comprising the apparatus.

14. The apparatus according to claim 12, where the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to:

receive a request to attach from a user equipment;

select one of the authentication vectors for the requesting user equipment's IMSI; and

start authentication and key agreement.

15. The apparatus according to claim 12, wherein the SN ID is allocated a set of indices from an array scheme, and wherein a total range of index values in the array scheme is split into as many disjoint groups of index values as necessary to support the traditional domains as well as one or several isolated operation mode domains and each isolated operation mode domain comprises one or several IOPS Serving Networks.

16. The apparatus according to claim 12, wherein the isolated operation mode comprises isolated operation of E-UTRAN for public safety (IOPS).

17. The apparatus according to claim 12, wherein the apparatus comprises a mobility management entity.

18. A method, comprising:

receiving, by a home subscription server, at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

wherein the at least one request comprises an isolated operation mode serving network identifier (SN ID); checking the SN ID against an isolated operation mode tag for the subscriber;

generating at least one authentication vector for each of the IMSIs; and

sending a response comprising the generated at least one authentication vector, to a local mobility management entity.

19. The method according to claim 18, wherein the generating further comprises splitting a total range of index values in the array scheme into as many disjoint groups of index values as necessary to support the traditional domains as well as one or several isolated operation mode domains such that each isolated operation mode domain comprises one or several IOPS Serving Networks.

20. An apparatus, comprising:

receiving means for receiving at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

checking means for checking the SN ID against an isolated operation mode tag for the subscriber;

generating means for generating at least one authentication vector for each of the IMSIs; and

sending means for sending a response comprising the generated at least one authentication vector, to a local mobility management entity.

21. The apparatus according to claim 20, wherein the generating means further comprises means for selecting sequence numbers with index values in an array scheme such that the total range of index values in the array scheme is split into as many disjoint groups of index values as necessary to support the traditional domains as well as one or several isolated operation mode domains and each isolated operation mode domain comprises one or several IOPS Serving Networks.

22. The apparatus according to claim 20, wherein the apparatus comprises a home subscription server.

23. An apparatus, comprising:

at least one processor; and

at least one memory comprising computer program code,

the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus at least to receive at least one request for authentication vectors for a selected list of international mobile subscriber identities (IMSIs) authorized for isolated operation mode,

check the SN ID against an isolated operation mode tag for the subscriber;

generate at least one authentication vector for each of the IMSIs; and send a response comprising the generated at least one authentication vector, to a local mobility management entity.

24. The apparatus according to claim 23, wherein the at least one memory and the computer program code are further configured, with the at least one processor, to cause the apparatus at least to generate the at least one authentication vector by selecting sequence numbers with index values in an array scheme such that the total range of index values in the array scheme is split into as many disjoint groups of index values as necessary to support the traditional domains as well as one or several isolated operation mode domains and each isolated operation mode domain comprises one or several IOPS Serving Networks.

25. The apparatus according to claim 23, wherein the apparatus comprises a home subscription server.

26. A computer program, embodied on a non-transitory computer readable medium, the computer program configured to control a processor to perform a method according to any one of claims 1-5 or 18-19.