Patent Grant
11818566
Recently, Mobile Network Operators (MNOs) have shown much interest in deploying Integrated Small Cell and Wi-Fi (ISW) networks to accommodate the widespread increase in wireless data usage. More specifically, the ISW networks leverage the deployment of long term evolution (LTE) small cells in the licensed spectrum along with Wireless Local Area Network (WLAN) Access Points (APs) in the unlicensed spectrum. The ISW topic has been addressed by standardization, academic, and industrial bodies such as 3rd Generation Partnership Project (3GPP), Small Cell Forum (SCF), and Wireless Broadband Alliance (WBA). Such huge interest will drive development of a variety of network architectures, subscriber service options, and policy management mechanisms to the ISW networks.
In 3GPP TS 23.402 a 3GPP technical specification for core-network (CN)-based interworking between the Evolved Packet Core (EPC) and non-3GPP networks (e.g., WLAN) has been introduced. The 3GPP TS 23.402 document provides the complete architecture, interfaces, access, and handover procedures for the interworking between Trusted Wide Area Network (TWAN) and 3GPP Evolved Packet Core (EPC).
Since a fundamental architecture principle of the EPC is to handle the data plane and control plane separately (i.e. MME/S-GW), Mobility Management Entity (MME) extensions along with TWAN extensions can provide a logical choice for inter-system mobility management signaling while corresponding S-GW extensions can support inter-system user plane functionality. The Mobility Management Entity (MME) can be extended into a common control plane entity for both LTE and Wi-Fi access, while enabling the S-GW to function as a common user plane gateway for both LTE and Wi-Fi access. The reference points S1a-MME and S1a-U shown in
These extensions can improve performance by enabling execution of inter-system mobility procedures closer to the edge of the network. Latency can be reduced by minimizing the need for signaling procedures deep in the core network, i.e., toward the PDN Gateway (P-GW) 208. This can be especially beneficial when an Mobile Network Operator (MNO) deploys both small cell and Wi-Fi access in a common geographic area. Scalability is also improved by reducing the P-GW 208 processing burden, e.g., by distributing some inter-system mobility functions to the MME 202 and S-GW 206.
A general background on the AKA algorithm is given below including the mutual authentication between the User Equipment (UE) 214 and network along with key generation hierarchies. Then, such generic Authentication and Key Agreement (AKA) algorithm is described with respect to 3GPP (EPS AKA) and WLAN (EAP-AKA′) networks.
The process of generating AVs is explained in
Back to
Upon receipt of RAND and AUTN the USIM/UE applies the user authentication procedure shown in
Finally and back to
For the LTE, the “User Authentication Request” is implemented in the “NAS: Authentication Request”. Similarly, the “User Authentication Response” is implemented in the “NAS: Authentication Response”. For the WLAN case, the “User Authentication Request” is implemented via the “Diameter-EAP-Answer” and “EAP-Request/AKA′-Challenge” messages. The “User Authentication Response”, is implemented using the “EAP-Response/AKA′-Challenge” and “Diameter-EAP-Request”.
The security procedures between the UE 214 and EPC network 216 is explained in details in Clause 6 of 3GPP TS 33.401. The security procedure is a fundamental step of the initial attachment procedure (Clause 5.3.2 of 3GPP TS 23.401). This section focuses on the exact authentication-related messages in 3GPP EPC. In particular, this section focuses on Diameter-based messages, exchanged between the MME 202 and HSS 210 over the S6a reference point. The presented messages correspond to the generic “Authentication data request” and “Authentication data response”, shown in
In order for the MME to request authentication vectors for the HSS, it sends the Diameter-based “Authentication-Information-Request (AIR)” command over the S6a reference point, as indicated in Clause 5.2.3 of 3GPP TS 29.272. Some of the relevant Attribute-Value Pairs (AVPs) of the AIR command are shown in Table 1. The UE 302 will be identified using its ‘International Mobile Subscriber Identity (IMSI)’. The ‘Requested-EUTRAN-Authentication-Info’ AVP (Clause 7.3.11 of 3GPP TS 29.272) shall contain the information related to the authentication requests for E-UTRAN, namely, ‘Number-Of-Requested-Vectors’, ‘Immediate-Response-Preferred’, and ‘Re-synchronization-Info’ AVPs. The ‘Visited-PLMN-Id’ AVP (Clause 7.3.9 of 3GPP TS 29.272), also referred to as Serving Network Identity (SN ID), shall contain the concatenation of Mobile Country Code (MCC) and Mobile Network Code (MNC).
In response to the AIR command, the HSS provides the authentication vectors to the MME in the “Authentication-Information-Answer (AIA)” command over the S6a reference point, as indicated in Clause 5.2.3 of 3GPP TS 29.272. Table 2 provides some of the relevant AVPs of the AIA command. The ‘Authentication-Info’ AVP (Clause 7.3.17 of 3GPP TS 29.272) contains the required authentication vectors for multiple 3GPP RATs, namely, ‘E-UTRAN-Vector’, ‘UTRAN-Vector’, and ‘GERAN-Vector’. Of special interest is the ‘E-UTRAN-Vector’ AVP (Clause 7.3.18 of 3GPP TS 29.272), which is an E-UTRAN vector that includes the following authentication information ‘Item-Number’, ‘RAND’, ‘XRES’, ‘AUTN’, and ‘KASME’. The KASME is the Access Security Management Entity key (ASME).
Non-3GPP access authentication signaling is executed between the UE 214 and HSS 210 through the 3GPP AAA 212 server 212 across the STa reference point (TWAN-AAA Server) and SWx (AAA Server-HSS). First, the UE initiates the Extensible Authentication Protocol (EAP) authentication process towards the TWAN 218, which forwards the EAP messages to the 3GPP AAA Server 212. The 3GPP AAA Server 212 and HSS 210 interact according to the standard AKA procedure shown previously in
In order for the 3GPP AAA Server 212 to authenticate a TWAN-connected UE 214, it sends Diameter-based “Authentication Request” message to the HSS 210 over the SWx reference point. Table 3 shows a few AVPs of the “Authentication Request” message, which are of our interest. As shown, the 3GPP AAA Server 212 includes the ‘IMSI’, ‘Number of Authentication Items’, ‘Access Network Identity (=WLAN)’, and ‘Access Type (=WLAN)’ AVPs.
Access Network Identity (=WLAN)’, and ‘Access Type (=WLAN)’ AVPs.
As a response to the “Authentication Request” message from the 3GPP AAA Server 212, the HSS 210 responds by sending “Authentication Answer” message to the AAA Server 212. The “Authentication Answer” command is sent over the SWx reference point. The most relevant AVPs of the Diameter-based “Authentication Answer” command are shown in Table 4. As shown, it includes ‘Authentication Data’ AVP, whose contents are shown in Table 5. As indicated, the ‘Authentication Data’ AVP contains all the needed authentication/authorization parameters (RAND, AUTN, XRES) and keys (CK, IK).
The key hierarchy for EPS/E-UTRAN access is shown in
Then the UE 214 and MME 202 derive the NAS keys, namely, KNASenc (NAS encryption key) and KNASint (NAS integrity protection key), using the key derivation functions (KDF) described in Annex A.7 of 3GPP TS 33.401. Furthermore, the MME 202 and UE 214 derive the eNB security key (KeNB) using the KASME and the uplink NAS COUNT, as defined in Annex A.3 of 3GPP TS 33.401. Afterwards, the eNB receives the KeNB from the MME 202, contained in the “Initial Context Setup Request” message. Finally, the UE 214 and eNB derive the needed keys for user plane (KUPint, KUPenc) and RRC (KRRCint, KRRCenc) transmissions using the KDFs described in Annex A.7 of 3GPP TS 33.401.
The MME 202 uses the “Initial Context Setup Request” message to send the (KeNB) to the eNB. In general, the “Initial Context Setup Request” message is sent to request the setup of a UE context (Clause 9.1.4 of TS 36.413). The ‘Security Key’ Information Element (IE) (KeNB) is used to apply security in the eNB (Clause 9.2.1.41 of TS 36.413).
In this section, the AKA′ key hierarchy for TWAN, which is shown in
where PRF′ is a pseudo-random function, K_encr is a 128-bit encryption key (for data encryption), K_aut is a 256-bit authentication key (for MAC), K_re is a 256-bit re-authentication key (for fast re-authentication), MSK is a 512-bit Master Session Key, and EMSK is a 512-bit Extended Master Session Key.
The MSK is exported by the EAP method IETF RFC 3748 to the TWAN. More specifically, the 3GPP AAA server transports the MSK to the TWAN by sending the Diameter-based “Diameter-EAP-Answer” (EAP-Payload, EAP-Master-Session-Key) message, as discussed in IETF RFC 4072. The ‘EAP-Master-Session-Key’ AVP represents the MSK to be used over the WLAN link.
In Intra-LTE handover, in which a UE 214 experiences handover from one eNB to another, the UE 214 does not need to be authenticated again to the network. Instead only a new KeNB is generated at the UE and target eNB. The procedure to update the KeNB is shown in
Fast re-authentication can be done for TWAN 218 access to EPC 216. In this case, the HSS 210 will not be involved as it was in the full authentication case. The fast re-authentication procedure aims to generate new MSK to be used between the UE and TWAN. Clause 6.3 of 3GPP TS 33.402 describes it in details.
The “EAP-Request/AKA′-Reauthentication” Message (Clause 9.7 of IETF RFC 4187) message is sent from the 3GPP AAA Server to the UE, once the 3GPP AAA Server receives the re-authentication ID. It includes the following attributes: COUNTER, NONCE, MAC, and new re-authentication ID. First, the COUNTER is a 16-bit unsigned integer counter value (Clause 10.16 of IETF RFC 4187). The COUNTER is initialized to one in the full authentication procedure. Second, the NONCE is random number (16 bytes) that is freshly generated by the AAA server for this EAP-AKA′ fast re-authentication (Clause 10.18 of IETF RFC 4187. The random number is used as a challenge for the UE and also as a seed value for the new keying material. Third, the MAC attribute contains a message authentication code (MAC) covering the EAP packet in general. The MAC is calculated over the whole EAP packet (NONCE in this case) and concatenated with optional message-specific data (Clause 10.15 of IETF RFC 4187). Finally, the new re-authentication ID will be used in the next fast re-authentication.
In fast re-authentication, the following keys are calculated (IETF RFC 5448):
where MK is Master Key and PRF is a Pseudo-Random number Function. On fast re-authentication, the same pseudo-random number generator can be used to generate a new MSK (IETF RFC4187). K_re is the re-authentication key from the preceding full authentication and stays unchanged over any fast re-authentication(s) that may happen based on it. Finally, COUNTER and NONCE are generated at the server.
In the current 3GPP Inter-Working Architecture, a multi-RAT (LTE/WLAN) UE that decides to make an Inter-RAT handover will need to run the full authentication procedure before making the handover, TS 23.402. When the Small Cell is collocated with the Wi-Fi network, it is inefficient to require that the UE Detailed Description run a complete re-authentication at each handover between LTE and WLAN.
Multi-RAT UEs currently have two independent paths to authenticate with HSS (either via the MME or the 3GPP AAA Server causing repeated authentication messages to HSS. Embodiments described below use one unified authentication path between the UE and HSS for Small Cell and Wi-Fi authentication.
First, a new 3GPP EPC-TWAN interworking architecture has the MME manage the authentication requests from multi-RAT UEs. In other words, the 3GPP AAA Server will not handle any authentication procedures from ISWN-based UEs. To do so, a new reference point, namely, STb is added, between the TWAN and MME.
Second, new unified authentication procedures are added, which allow the ISWN-based multi-RAT UE to be authenticated directly with the HSS, irrespective of its current access network (TWAN or HeNB). The unified authentication procedures enable mutual authentication between the UE and MME and provide keys for both WLAN and LTE access networks. Both TWAN-initiated and HeNB-initiated authentication can be done by a UE via either the TWAN or HeNB respectively.
Third, new fast re-authentication procedures for Inter-RAT handover scenarios are done. The re-authentication procedures simplify the mutual authentication step by focusing only on generating the required keys. In other words, the fast re-authentication procedures do not involve the HSS in the re-authentication process, which reduces the burden on the core network. Both Intra-ISWN (TWAN-to-HeNB and HeNB-TWAN) and TWAN-to-eNB handover scenarios are described.
Finally, the extensions to the various standard protocol messages to execute the authentication procedures are described. The extended messages span the following layer, protocols, and reference points: RRC, S1-AP, NAS, EAP, and Diameter over the S6a reference point (MME-HSS).
These changes need not replace the existing 3GPP interworking architecture. Rather, they can provide a more efficient alternative that can be used when the Small Cell and Wi-Fi network are tightly integrated.
While the examples in this document deal with handover between a radio access technology that operates in licensed spectrum such as LTE and a radio access technology that operates in unlicensed such as Wi-Fi, it should be appreciated that the concepts can apply to handover between any two radio access technologies.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to limitations that solve any or all disadvantages noted in any part of this disclosure.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
In an Integrated Small Cell/Wi-Fi Network, it is inefficient to re-run the full authentication procedure at each handover event with similar functionality provided by both MME 202 and AAA Server 212.
It is understood that the functionality illustrated in
The HSS sends the authentication vectors and keys to the MME in step 4 of
After a while, the UE 214 discovers a WLAN and wants to make a handover to the TWAN 218 in step 9 of
The HSS 210 sends the authentication vectors and keys to the AAA Server in step 15 of
From
In observing this issue, if a UE 214, which is attached to the HeNB side of an ISWN, wants to handover to the TWAN side of the ISWN then there is no need to perform full authentication procedure again with the HSS 210 via the AAA server 212. Based on the previously explained use case, the problems considered in this disclosure can be formulated as follows:
In this case, there will no need to run the full authentication procedure at Intra-ISWN Inter-RAT handover. Instead, we will have a fast re-authentication procedure.
For example, the HSS 210 may not be needed to get involved in the re-authentication process.
It is understood that the entities performing the steps illustrated in
In this example, the 3GPP AAA Server 212 will not be utilized. Instead for the authentication procedures, the TWAP 224 will be connected to the MME 202 via a new STb reference point. As for the Session Management (SM) procedure and similar to
The unified authentication procedure can bypass the 3GPP AAA server 212 and only use HSS 210 and MME 202 for authentication of ISWN 230. However, the 3GPP AAA Server 212 can still co-exist in the same network for authentication of other networks not allowed for unified authentication, or used when unified authentication is not supported. Finally, we point out that such interworking architecture can be generalized to other non-3GPP systems, which utilize the 3GPP AAA Server 212, such as CDMA2000.
As was shown in
It is understood that the functionality illustrated in
Unified Authentication Procedures
In this section, we introduce the unified authentication procedure which allows the UE 214 and the network to perform the full AKA algorithm, for both RATs of the ISWN 230. The authentication step is the first important step in the initial attachment procedure. Hence, we will explain the authentication procedure, as a part of the initial attachment process. We will cover two cases, depending on whether the UE 214 initiates attachment towards the TWAN 218 or HeNB 220 of the ISWN 230.
HeNB-Based Unified Authentication/Attachment Procedure
In this section, we assume that the UE 214 will initiate the attachment to the ISWN 230 via the HeNB 220. Accordingly, we aim to have the UE 214 to be mutually authenticated with the HSS 210 via the MME 202. Furthermore, key materials for both E-UTRAN and WLAN 218 are to be derived. The unified procedure depends on running the AKA algorithm one time only taking into consideration the ISWN configuration parameters in Table 6.
In step 1 of
In step 2 of
A new ‘Unified Authentication’ information element to the “RRC Connection Setup Complete” message. This new information element is used by the UE 14 to indicate its desire to the HeNB 220 to perform the unified authentication including the TWAN side of the ISWN too. We point out that by adding such IE, the UE 214 will be backward-compatible as it may perform the typical authentication procedure. Similarly, new information element, namely “Unified Authentication” is added in the “RRC Connection Setup” message from the HeNB 220 to the UE 214 in step 1 of
In step 3 of
We assume that the HeNB 220 sends some information about its integrated TWAN 218. Such information can be configured in both the HeNB 220 and TWAN 218 once the ISWN is established. More specifically, the HeNB 220 will send the “Initial UE message” message conveying the ‘Access Type=ISWN’ and ‘Access Network identity=WLAN’ to the MME 202. The ‘Access Network identity=WLAN’ represents the TWAN side (Table 8.1.1.2 of 3GPP TS 24.302). Furthermore, we define a new ‘Access type’ of ISWN to inform the MME 202 that the UE 214 is connected to an ISWN 230 (TWAN 218 and HeNB 220).
In step 4 of
The “Authentication-Information-Request” message is extended to include ‘Access Type=ISWN’ and ‘Access Network identity=WLAN’ of the TWAN 218 side.
In step 5 of
In step 6 of
In step 7 of
In step 8 of
Three information elements are added to the “Authentication-Information-Answer” message, which are CK′ and IK′.
In step 9 of
In step 10 of
The MME 202 can generates all the WLAN keys (K_encr, K_aut, K_re, MSK, and EMSK). Such a key generation function is moved from the 3GPP AAA Server 212 to the MME 202.
In step 11 of
Two new information elements are added, which are the ‘Access Network Identity’ and ‘re-authentication ID’ in the “Authentication Request” message. The ‘Access Network Identity’ information element conveys the WLAN access network identity to the UE (via HeNB). Such information element is needed at the UE to be used for WLAN key generation, in a similar fashion to 7 of
In step 12 of
In step 13 of
In step 14 of
In step 15 of
In step 16 of
In step 17 of
In step 18 of
In step 19 of
In step 20 of
In step 21 of
In step 22 of
In step 23 of
In step 24 of
In step 25 of
TWAN-Based Unified Authentication/Attachment Procedure
In this section, we assume that the UE 214 attempts to connect to the ISWN 230 via its TWAN 218 side. Similar to the unified authentication idea, presented in
The standard AKA algorithm will be applied involving the HSS 210, MME 202, TWAN 218, and UE 214. Both the UE 214 and MME 202 will generate the needed keys to be used in the TWAN transmission. We notice that the 3GPP AAA Server 212 is not needed any more.
The call flow in
In step 1 of
In step 2 of
In step 3 of
The EAP “EAP-Response/Identity” message can be extended by adding a ‘Unified Authentication’ information element. The ‘Unified Authentication’ information element is an indicator from the UE 214 that it needs to perform the ISWN-based unified authentication including both the TWAN 218 and HeNB 220 sides of the ISWN 220. We point out that the EAP messages can be extended as was done previously to include ‘handover indicator’ for example (Clause 16.1.4A.2 in 3GPP TS 23.402).
In step 4 of
A new message over the STb reference point is added, namely, “Diameter-EAP-Request” message, which is similar to the one defined over STa (between AAA Server and TWAP) in IETF RFC 4072. Furthermore, the ‘Access Type=ISWN’ and ‘Access Network Identity=WLAN’ can be added to the “Diameter-EAP-Request” message.
Steps 5-11 of
In step 12 of
A new message is added over the STb reference point, namely, “Diameter-EAP-Answer” message, which is similar to the one defined over STa (between AAA Server 212 and TWAP 224) in the IETF RFC 4072. No new AVPs are added to the “Diameter-EAP-Answer” message.
In step 13 of
In steps 14-16 of
In step 17 of
In step 18 of
In step 19 of
In step 20 of
In step 21 of
In step 22 of
In step 23 of
In step 24 of
Fast Re-Authentication in Inter-RAT Handover Procedures
Fast Re-Authentication in Intra-ISWN HeNB-to-TWAN Handover Procedure
In this section, we consider a scenario in which a UE 214 has initially performed unified authentication by attaching to HeNB 220. Then, the UE 214 decides to switch to WLAN 218. As the UE 214 has been already authenticated with the HSS 210, there is no need to run the full authentication procedure again. Instead, the UE 214 and MME 202 need to run fast re-authentication only, in which only new keys for the WLAN access networks (e.g. MSK) are generated.
The MME 202, not the TWAN 218, will be the responsible network entity for generating the new WLAN keys (e.g. MSK). This is in agreement with the 3GPP guidelines, which typically allow the AAA Server (not TWAN 218) to perform fast re-authentication (Clause 6.3 of 3GPP TS 33.402) or MME 202 (not HeNB 220) to generate intra-LTE E-UTRAN handover keys (Section 212).
The call flow in
In step 0 of
In step 1 of
In step 2 of
In step 3 of
In step 4 of
In step 5 of
In step 6 of
In step 7 of
In step 8 of
In step 9 of
In step 10 of
In step 11 of
In step 12 of
In step 13 of
In step 14 of
In step 15 of
An alternative mechanism is described below, which describes an optimized re-authentication mechanism based on EAP-Re-authentication Protocol (EAP-RP) (RFC 6696). The EAP-RP protocol may be carried out after a full EAP authentication or an AKA authentication protocol or for that matter any full authentication protocol. EAP-RP achieves re-authentication using a single round-trip. Similar mechanisms may be used to perform the re-authentication such as One-Round-Trip Authentication (ORTA) may be employed. EAP-FAST mechanisms may also be employed.
Mechanisms such as ORTA may be employed in order further reduce the latency involved in Authentication/IP address assignment. ORTA makes use of an ORTA ID, so that a full authentication procedure is avoided and the UE may be able to optionally request for an IP address assignment using the ORTA messages without having to explicitly start a DHCP message after the EAP authentication has been carried out in a serial manner. Using ORTA, the DHCP process is either carried out implicitly or explicitly using ORTA messaging in a parallel manner.
The call flow in
In step 0 of
In step 1 of
In step 2 of
In step 3 of
In step 4 of
In step 5 of
In step 6 of
In step 7 of
In step 8 of
In step 9 of
In step 10 of
In steps 11-12 of
Fast Re-Authentication in Intra-ISWN TWAN-to-HeNB Handover Procedure
In this section, we consider the handover scenario from TWAN 218 to HeNB 220 in an ISWN 230. Initially, we assume that a unified authentication procedure has been performed to authenticate the UE 214 with TWAN 218 of an ISWN 230. Then, the UE 214 decides to make handover towards the HeNB 220 side of the ISWN. In this case, there is no need to run the full authentication procedure. Instead, a fast re-authentication procedure between the UE 214 and MME 202, which focuses on the key-regeneration only, can be performed. The HSS 210 will not be involved in the fast re-authentication procedure.
The call flow in
In step 0 of
In step 1 of
In step 2 of
In step 3 of
In step 4 of
In step 5 of
In step 6 of
In step 7 of
In step 8 of
In step 9 of
In step 10 of
In steps 11-14 of
In steps 15 of
Fast Re-Authentication in TWAN-to-eNB Handover Procedure
In this section, we consider a scenario in which a UE 214 goes from a TWAN 218, which is part of an ISWN 230, to a macro eNB 1702. This scenario resembles the case when a subscriber is getting out of his home or office (ISWN/TWAN) and going on the road (Macro eNB 1702).
Messages Extensions
In this section, we introduce the needed message and protocol extension to enable the procedures presented above.
RRC: “RRC Connection Setup Complete” Message
In Step 12 of
Unified Authentication
0 or 1:
1: denotes unified authentication is
needed
S1-AP: “Initial UE Message” Message
In Step 12 of
Access Type
O
ISWN
ISWN access
type, needed for
unified
authentication
procedure
Access Network
O
WLAN
The WLAN
Identity
access network
identity of the
TWAN side of
the ISWN
NAS: “Authentication Request” Message
In Steps 11 and 12 of
Re-authentication
UE's re-authenti-
ID
cation
identity,
which will be
used by the UE in
an
upcoming fast
re-authentication
procedure.
Access Network
‘WLAN’: Used to
Identity
generate WLAN
keys
CK′ and IK′
EAP: “EAP-Response/Identity” Message
Clause 9.2 of IETF FRC 4187 describes the “EAP-Response/Identity”, which is sent by the UE to indicate its identity (Network Access Identifier). In step 3 of
Diameter-Based Messages Over the S6a Reference Point
“Authentication-Information-Request” Message
In multiple instances (e.g. step 4 of
Access
ANID
C
‘WLAN’: Used to generate
Network
WLAN keys CK′ and IK′
Identity
This IE shall contain the
access network identifier used
for
key derivation at the HSS.
(See 3GPP TS 24. 302 [10] for
all possible values).
This IE shall be present if the
Authentication Method is
EAP-AKA′.
“Authentication-Information-Answer” Message
In multiple instances (e.g. step 8 of
Confidential-
Confidential-
M
This information element shall
ity
Key AKA
ity-Key
contain the confidentiality
key
CK′. It shall be binary
encoded.
Integrity
Integrity-
M
This information element shall
Key AKA
Key
contain the integrity key
IK′.
Re-
It shall be binary encoded.
authentication
UE's re-authentication identity,
ID
which will be used by the
UE
in an upcoming fast re-
authentication procedure.
Diameter-Based Messages Over the New STb Reference Point
“Diameter-EAP-Request” Message
In Step 4 of
[Access-Type = ISWN]
[Access-Network-Identity=WLAN]
“Diameter-EAP-Answer” Message
In multiple instances (e.g., Step 12 of
It is understood that the entities performing the steps illustrated in
The standard mutual authentication procedure between the UE 214 and HSS 210 in the untrusted WLAN case, described in 3GPP TS 33.402, consists of the following protocols:
The main authentication-related difference between the untrusted and trusted WLAN cases is the usage of IKEv2 protocol (UE-ePDG) to carry the EAP messages for the untrusted case. Equally important, we note the similarity of roles between step 2 above (ePDG-3GPP AAA Server 212 for the untrusted WLAN case) and the (TWAP-3GPP AAA Server 212) communication over STa for the trusted WLAN case, which was explained in details in
Therefore, the interworking architecture for the untrusted WLAN case can be enhanced by adding a new reference point (namely STm in
It is understood that the functionality illustrated in
It is understood that the functionality illustrated in
User Interfaces
Interfaces, such as Graphical User Interfaces (GUIs), can be used to assist user to control and/or configure functionalities related to the unified authentication. A Graphical User Interface (GUI) can allow the UE 214 to decide which access network (LTE or Wi-Fi) to utilize (during initial attachment and handover), and whether to use the unified authentication procedure or not.
Example M2M/IoT/WoT Communication System
The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effect the methods described herein. As used herein, the terms “apparatus,” “network apparatus,” “node,” “device,” and “network node” may be used interchangeably.
The term “service layer” refers to a functional layer within a network service architecture. Service layers are typically situated above the application protocol layer such as HTTP, CoAP or MQTT and provide value added services to client applications. The service layer also provides an interface to core networks at a lower resource layer, such as for example, a control layer and transport/access layer. The service layer supports multiple categories of (service) capabilities or functionalities including a-service definition, service runtime enablement, policy management, access control, and service clustering. Recently, several industry standards bodies, e.g., oneM2M, have been developing M2M service layers to address the challenges associated with the integration of M2M types of devices and applications into deployments such as the Internet/Web, cellular, enterprise, and home networks. A M2M service layer can provide applications and/or various devices with access to a collection of or a set of the above mentioned capabilities or functionalities, supported by the service layer, which can be referred to as a CSE or SCL. A few examples include but are not limited to security, charging, data management, device management, discovery, provisioning, and connectivity management which can be commonly used by various applications. These capabilities or functionalities are made available to such various applications via APIs which make use of message formats, resource structures and resource representations defined by the M2M service layer. The CSE or SCL is a functional entity that may be implemented by hardware and/or software and that provides (service) capabilities or functionalities exposed to various applications and/or devices (i.e., functional interfaces between such functional entities) in order for them to use such capabilities or functionalities.
As shown in
As shown in
Exemplary M2M terminal devices 18 include, but are not limited to, tablets, smart phones, medical devices, temperature and weather monitors, connected cars, smart meters, game consoles, personal digital assistants, health and fitness monitors, lights, thermostats, appliances, garage doors and other actuator-based devices, security devices, and smart outlets.
Referring to
The M2M service layer 22 may be implemented by one or more servers, computers, devices, virtual machines (e.g. cloud/storage farms, etc.) or the like, including for example the devices illustrated in
Similar to the illustrated M2M service layer 22, there is the M2M service layer 22′ in the Infrastructure Domain. M2M service layer 22′ provides services for the M2M application 20′ and the underlying communication network 12 in the infrastructure domain. M2M service layer 22′ also provides services for the M2M gateways 14 and M2M terminal devices 18 in the field domain. It will be understood that the M2M service layer 22′ may communicate with any number of M2M applications, M2M gateways and M2M devices. The M2M service layer 22′ may interact with a service layer by a different service provider. The M2M service layer 22′ by one or more nodes of the network, which may comprises servers, computers, devices, virtual machines (e.g., cloud computing/storage farms, etc.) or the like.
Referring also to
The methods of the present application may be implemented as part of a service layer 22 and 22′. The service layer 22 and 22′ is a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both ETSI M2M and oneM2M use a service layer that may contain the connection methods of the present application. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e. service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). Further, connection methods of the present application can implemented as part of an M2M network that uses a Service Oriented Architecture (SOA) and/or a resource-oriented architecture (ROA) to access services such as the connection methods of the present application.
In some embodiments, M2M applications 20 and 20′ may be used in conjunction with the disclosed systems and methods. The M2M applications 20 and 20′ may include the applications that interact with the UE or gateway and may also be used in conjunction with other disclosed systems and methods.
In one embodiment, the logical entities such as MME 202, WLAN AN 204, S-GW 206, P-GW 208, HSS 210, 3GPP AAA server 212, UE 214, EPC 216, TWAN 218, HeNB 220, TWAP 224, ISWN 230, TWAG 232, S-GwIP-GW 1002, Macro eNB 1702, untrusted WLAN 1802, and ePDG 1804 and logical entities to produce user interface 2000 shown in
The M2M applications 20 and 20′ may include applications in various industries such as, without limitation, transportation, health and wellness, connected home, energy management, asset tracking, and security and surveillance. As mentioned above, the M2M service layer, running across the devices, gateways, servers and other nodes of the system, supports functions such as, for example, data collection, device management, security, billing, location tracking/geofencing, device/service discovery, and legacy systems integration, and provides these functions as services to the M2M applications 20 and 20′.
Generally, the service layers 22 and 22′ define a software middleware layer that supports value-added service capabilities through a set of Application Programming Interfaces (APIs) and underlying networking interfaces. Both the ETSI M2M and oneM2M architectures define a service layer. ETSI M2M's service layer is referred to as the Service Capability Layer (SCL). The SCL may be implemented in a variety of different nodes of the ETSI M2M architecture. For example, an instance of the service layer may be implemented within an M2M device (where it is referred to as a device SCL (DSCL)), a gateway (where it is referred to as a gateway SCL (GSCL)) and/or a network node (where it is referred to as a network SCL (NSCL)). The oneM2M service layer supports a set of Common Service Functions (CSFs) (i.e., service capabilities). An instantiation of a set of one or more particular types of CSFs is referred to as a Common Services Entity (CSE) which can be hosted on different types of network nodes (e.g. infrastructure node, middle node, application-specific node). The Third Generation Partnership Project (3GPP) has also defined an architecture for machine-type communications (MTC). In that architecture, the service layer, and the service capabilities it provides, are implemented as part of a Service Capability Server (SCS). Whether embodied in a DSCL, GSCL, or NSCL of the ETSI M2M architecture, in a Service Capability Server (SCS) of the 3GPP MTC architecture, in a CSF or CSE of the oneM2M architecture, or in some other node of a network, an instance of the service layer may be implemented as a logical entity (e.g., software, computer-executable instructions, and the like) executing either on one or more standalone nodes in the network, including servers, computers, and other computing devices or nodes, or as part of one or more existing nodes. As an example, an instance of a service layer or component thereof may be implemented in the form of software running on a network node (e.g., server, computer, gateway, device or the like) having the general architecture illustrated in
Further, logical entities such as MME 202, WLAN AN 204, S-GW 206, P-GW 208, HSS 210, 3GPP AAA server 212, UE 214, EPC 216, TWAN 218, HeNB 220, TWAP 224, ISWN 230, TWAG 232, S-GwIP-GW 1002, Macro eNB 1702, untrusted WLAN 1802, and ePDG 1804 and logical entities to produce user interface 2000 shown in
The device 30 can be part of an M2M network as shown in
The processor 32 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. In general, the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the node in order to perform the various required functions of the node. For example, the processor 32 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the M2M node 30 to operate in a wireless or wired environment. The processor 32 may run application-layer programs (e.g., browsers) and/or radio access-layer (RAN) programs and/or other communications programs. The processor 32 may also perform security operations such as authentication, security key agreement, and/or cryptographic operations, such as at the access-layer and/or application layer for example.
As shown in
The transmit/receive element 36 may be configured to transmit signals to, or receive signals from, other M2M nodes, including M2M servers, gateways, device, and the like. For example, in an embodiment, the transmit/receive element 36 may be an antenna configured to transmit and/or receive RF signals. The transmit/receive element 36 may support various networks and air interfaces, such as WLAN, WPAN, cellular, and the like. In an embodiment, the transmit/receive element 36 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 36 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 36 may be configured to transmit and/or receive any combination of wireless or wired signals.
In addition, although the transmit/receive element 36 is depicted in
The transceiver 34 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 36 and to demodulate the signals that are received by the transmit/receive element 36. As noted above, the M2M node 30 may have multi-mode capabilities. Thus, the transceiver 34 may include multiple transceivers for enabling the M2M node 30 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 32 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 44 and/or the removable memory 46. For example, the processor 32 may store session context in its memory, as described above. The non-removable memory 44 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 46 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 32 may access information from, and store data in, memory that is not physically located on the M2M node 30, such as on a server or a home computer. The processor 32 may be configured to control lighting patterns, images, or colors on the display or indicators 42 to reflect the status of an M2M service layer session migration or sharing or to obtain input from a user or display information to a user about the node's session migration or sharing capabilities or settings. In another example, the display may show information with regard to a session state. The current disclosure defines a RESTful user/application API in the oneM2M embodiment. A graphical user interface, which may be shown on the display, may be layered on top of the API to allow a user to interactively establish and manage an E2E session, or the migration or sharing thereof, via the underlying service layer session functionality described herein.
The processor 32 may receive power from the power source 48, and may be configured to distribute and/or control the power to the other components in the M2M node 30. The power source 48 may be any suitable device for powering the M2M node 30. For example, the power source 48 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
The processor 32 may also be coupled to the GPS chipset 50, which is configured to provide location information (e.g., longitude and latitude) regarding the current location of the M2M node 30. It will be appreciated that the M2M node 30 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 32 may further be coupled to other peripherals 52, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 52 may include various sensors such as an accelerometer, biometrics (e.g., figure print) sensors, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
The node 30 may be embodied in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The node 30 may connect to other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 52. Alternately, the node 30 may comprise apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane.
Computing system 90 can be an M2M device, user equipment, gateway, UE/GW or any other nodes including nodes of the mobile care network, service layer network application provider, terminal device 18 or an M2M gateway device 14 for example. Such computer readable instructions may be executed within a processor, such as central processing unit (CPU) 91, to cause computing system 90 to do work. In many known workstations, servers, and personal computers, central processing unit 91 is implemented by a single-chip CPU called a microprocessor. In other machines, the central processing unit 91 may comprise multiple processors. Coprocessor 81 is an optional processor, distinct from main CPU 91, that performs additional functions or assists CPU 91. CPU 91 and/or coprocessor 81 may receive, generate, and process data related to the disclosed systems and methods for E2E M2M service layer sessions, such as receiving session credentials or authenticating based on session credentials.
In operation, CPU 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computer's main data-transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally contain stored data that cannot easily be modified. Data stored in RAM 82 can be read or changed by CPU 91 or other hardware devices. Access to RAM 82 and/or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode can access only memory mapped by its own process virtual address space; it cannot access memory within another process's virtual address space unless memory sharing between the processes has been set up.
In addition, computing system 90 may contain peripherals controller 83 responsible for communicating instructions from CPU 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
Display 86, which is controlled by display controller 96, is used to display visual output generated by computing system 90. Such visual output may include text, graphics, animated graphics, and video. Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touch-panel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
Further, computing system 90 may contain communication circuitry, such as for example a network adaptor 97, that may be used to connect computing system 90 to an external communications network, such as network 12 of
User equipment (UE) can be any device used by an end-user to communicate. It can be a hand-held telephone, a laptop computer equipped with a mobile broadband adapter, or any other device. For example, the UE can be implemented as the M2M terminal device 18 of
It is understood that any or all of the systems, methods, and processes described herein may be embodied in the form of computer executable instructions (i.e., program code) stored on a computer-readable storage medium which instructions, when executed by a machine, such as a node of an M2M network, including for example an M2M server, gateway, device or the like, perform and/or implement the systems, methods and processes described herein. Specifically, any of the steps, operations or functions described above, including the operations of the gateway, UE, UE/GW, or any of the nodes of the mobile core network, service layer or network application provider, may be implemented in the form of such computer executable instructions. Logical entities such as MME 202, WLAN AN 204, S-GW 206, P-GW 208, HSS 210, 3GPP AAA server 212, UE 214, EPC 216, TWAN 218, HeNB 220, TWAP 224, ISWN 230, TWAG 232, S-GwIP-GW 1002, Macro eNB 1702, untrusted WLAN 1802, and ePDG 1804 and logical entities to produce user interface 2000 shown in
In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the Figures, specific terminology is employed for the sake of clarity. The claimed subject matter, however, is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.
This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have elements that do not differ from the literal language of the claims, or if they include equivalent elements with insubstantial differences from the literal language of the claims.
This Application is a continuation of U.S. patent application Ser. No. 15/579,703 filed Dec. 5, 2017 which is a National Stage Application filed under 35 U.S.C. § 371 of International Application No. PCT/US2016/035757 filed Jun. 3, 2016, which claims benefit of U.S. Provisional Patent Application No. 62/171,497, filed Jun. 5, 2015, the disclosures of which are hereby incorporated by reference as if set forth in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 8332912 | Naeslund et al. | Dec 2012 | B2 |
| 9392502 | Suh et al. | Jul 2016 | B2 |
| 20030154446 | Constant et al. | Aug 2003 | A1 |
| 20040203346 | Myhre et al. | Oct 2004 | A1 |
| 20060128362 | Bae et al. | Jun 2006 | A1 |
| 20070101406 | Zavalkovsky | May 2007 | A1 |
| 20070249352 | Song et al. | Oct 2007 | A1 |
| 20080101400 | Auterinen | May 2008 | A1 |
| 20080192925 | Sachs et al. | Aug 2008 | A1 |
| 20080205345 | Sachs et al. | Aug 2008 | A1 |
| 20100323700 | Bachmann et al. | Dec 2010 | A1 |
| 20110223885 | Salkintzis et al. | Sep 2011 | A1 |
| 20120005731 | Lei et al. | Jan 2012 | A1 |
| 20130064221 | Pampu et al. | Mar 2013 | A1 |
| 20130077482 | Krishna | Mar 2013 | A1 |
| 20130083661 | Gupta et al. | Apr 2013 | A1 |
| 20130095789 | Keevill | Apr 2013 | A1 |
| 20130198817 | Haddad et al. | Aug 2013 | A1 |
| 20130298209 | Targali et al. | Nov 2013 | A1 |
| 20130324170 | Watfa | Dec 2013 | A1 |
| 20140029513 | Takahashi et al. | Jan 2014 | A1 |
| 20140051393 | Mildh et al. | Feb 2014 | A1 |
| 20140093071 | Qiang | Apr 2014 | A1 |
| 20140204832 | Van et al. | Jul 2014 | A1 |
| 20150099488 | Mildh et al. | Apr 2015 | A1 |
| 20150103780 | Kaippallimalil et al. | Apr 2015 | A1 |
| 20150173000 | Basilier | Jun 2015 | A1 |
| 20150208309 | Taneja et al. | Jul 2015 | A1 |
| 20150271668 | Sun et al. | Sep 2015 | A1 |
| 20160156748 | Yang | Jun 2016 | A1 |
| 20160174123 | Hedberg et al. | Jun 2016 | A1 |
| 20160262020 | Zalzalah et al. | Sep 2016 | A1 |
| 20170223538 | Hahn et al. | Aug 2017 | A1 |
| 20170230826 | Mestanov | Aug 2017 | A1 |
| 20170289883 | Kiss et al. | Oct 2017 | A1 |
| 20180184297 | Mohamed et al. | Jun 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 101610507 | Dec 2009 | CN |
| 102075938 | May 2011 | CN |
| 102238544 | Nov 2011 | CN |
| 103402201 | Nov 2013 | CN |
| 103828299 | May 2014 | CN |
| 2495550 | Oct 2011 | GB |
| 10-0755394 | Sep 2007 | KR |
| 10-2009-0004896 | Jan 2009 | KR |
| 2007102702 | Sep 2007 | WO |
| 2015200326 | Dec 2015 | WO |
| Entry |
|---|
| Tomici (Tomici et al., “Integrated small cell and Wi-Fi networks”, 2015 IEEE Wireless Communications and Networking Conference (WCNC), Mar. 2015) (Year: 2015). |
| Orlandi et al., “Improving the Customer Experience for Heterogeneous Wireless Access”, Bell Labs Technical Journal 15(4), 23-44 (2011) © 2011 Alcatel-Lucent. ⋅ DOI: 10.1002/bltj.20470, (Year: 2011). |
| Dhawan et al., “Macro and Small Cell/Wi-Fi Networks: An Analysis of Deployment Options as the Solution for the Mobile Data Explosion,” Bell Labs Technical Journal 18(1), 59-79 (2013) © 2013 Alcatel-Lucent. ⋅ DOI: 10.1002/bltj.21593. (Year: 2013). |
| 3GPP TSG-RAN WG2#90 R2-152775, “WLAN Authentication and Security Aspects of LTE/WLAN Aggregation”, May 2015, 7 pages. |
| 3rd Generation Partnership Project; 3GPP TS 23.003, V12.4.1, Technical Specification Group Core Network and Terminals; Numbering, Addressing and Identification (release 12), Oct. 2014, 90 pages. |
| 3rd Generation Partnership Project; 3GPP TS 23.401, V12.4.0, Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access (Release 12), Mar. 2014, 302 pages. |
| 3rd Generation Partnership Project; 3GPP TS 23.402, V12.4.0, Technical Specification Group Services and System Aspects; Architecture Enhancements for non-3GPP Accesses (release 12), Mar. 2014, 288 pages. |
| 3rd Generation Partnership Project; 3GPP TS 24.301, V12.0.0, Technical Specification Group Core Network and Terminals; Non-Access-Stratum (NAS) Protocol for Evolved Packet System (EPS); Stage 3 (release 12), Mar. 2013, 345 pages. |
| 3rd Generation Partnership Project; 3GPP TS 29.272, V12.6.0, Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) Related Interfaces Based on Diameter Protocol (release 12), Sep. 2014, 134 pages. |
| 3rd Generation Partnership Project; 3GPP TS 33.102, V12.1.0, Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (release 12), Jun. 2014, 76 pages. |
| 3rd Generation Partnership Project; 3GPP TS 33.401, V12.12.0, Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security Architecture (release 12), Sep. 2014, 129 pages. |
| Chris Johnson, “RRC Connection Establishment”, http://lte-bullets.com/LTE%20in%20Bullets%20%20RRC%20Establishment.pdf, retrieved from the Internet on Sep. 12, 2018, 4 pages. |
| IEEE Standards 802.11—2012, “IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan area Networks—Specific requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, Mar. 29, 2012, 2793 pages. |
| IETF RFC 3748, “Extensible Authentication Protocol (EAP)”, Jun. 2004, 68 pages. |
| IETF RFC 4072, “Diameter Extensible Authentication Protocol (EAP) Application”, Aug. 2005, 33 pages. |
| IETF RFC 4187, Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), Jan. 2006, 80 pages. |
| IETF RFC 4282, “The Network Access Identifier”, Dec. 2005, 17 pages. |
| IETF RFC 5448, Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA), May 2009, 29 pages. |
| IETF RFC 5996, “Internet Key Exchange Protocol Version 2 (IKEv2)”, Sep. 2010, 139 pages. |
| IETF RFC 6696, “EAP Extensions for the EAP Re-authentication Protocol (ERP)”, Jul. 2012, 48 pages. |
| Kazem Sohraby and Mehmet Ulema, “Integrated Services and Integration Issues in Wireless Networks”, IEEE Communications Magazine, DOI: 10.1109/MCOM. 1996.536555 (Year: 1996). |
| Kwon et al., Consideration of UMTS-WLAN Seamless Handover, Seventh IEEE International Symposium on Multimedia (ISM'05), IEEE, © 2005, 6pgs. |
| RFC7458, Valmikam and Koodli, “Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core”, IPCQM000240768D (Year: 2015). |
| Shi et al., “IEEE802.11 Roaming and Authentication in Wireless LAN/Cellular Mobile Networks”, IEEE Wireless Communications, 1536-1284/04, 2004. |
| Targali et al., “ORTA—Seamless Authentication and Mobility Across Heterogeneous Networks using Federated Identity Systems”, IEEE ICC Workshops, Jun. 2013, 6 pages. |
| Third Generation Partnership Project (3GPP), 3GPP 36.331, V12.1.0, Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol Specification (Release 12), Mar. 2014, 356 pages. |
| Third Generation Partnership Project (3GPP), 3GPP TS 24.302, V12.6.0, Technical Specification Group Core Network and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3 (Release 12), Sep. 2014, 98 pages. |
| Third Generation Partnership Project (3GPP), 3GPP TS 29.212, V12.4.0, Technical Specification Group Core Network and Terminals; Policy and Charging Control (PCC); Reference points (Release 12), Mar. 2014, 220 pages. |
| Third Generation Partnership Project (3GPP), 3GPP TS 29.273, V13.5.0, Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); 3GPP EPS AAA interfaces (Release 13), Sep. 2016, 172 pages. |
| Third Generation Partnership Project (3GPP), 3GPP TS 33.203, V12.7.0, Technical Specification Group Services and System Aspects; 3G Security; Access Security for IP-based services (Release 12), Sep. 2014. |
| Third Generation Partnership Project (3GPP), 3GPP TS 36.413, V12.1.0, Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1Application Protocol (S1AP) (Release 12), Mar. 2014, 285 pages. |
| Third Generation Partnership Project (3GPP); 3GPP TS 33.402, V12.4.0, Technical Specification Group Services and System Aspects; 3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses (Release 12), Sep. 2014, 56 pages. |
| Wikiepedia, “EnodeB”, found aten.wikipedia.org/wiki/ENodeB; author unknown, Apr. 2015. |
| Number | Date | Country | |
|---|---|---|---|
| 20210321257 A1 | Oct 2021 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62171497 | Jun 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15579703 | US | |
| Child | 17321913 | US |
