WO2017099864A1

WO2017099864A1 - Standardized access to core networks

Info

Publication number: WO2017099864A1
Application number: PCT/US2016/053564
Authority: WO
Inventors: Alexandre Stojanovski; Farid Adrangi
Original assignee: Intel IP Corporation
Priority date: 2015-12-09
Filing date: 2016-09-23
Publication date: 2017-06-15

Abstract

A network device may enable non-3rd Generation Partnership Project (3GPP) access network to communicate with a Core network (CN) via an interface that is standardized for different types of access networks. The network device may operate as an intermediary for an attach procedure between a User Equipment (UE) of the non-3GPP access network and the CN. The access network may use a Layer-2 transport option (Extensible Authentication Protocol (EAP)) or a Layer-3 transport option (Internet Key Exchange version 2 (IKEv2) or Protocol for Carrying Authentication for Network Access (PANA) to communicate Non Access Stratum (NAS) messages between the UE and the CN. Additionally, a secure connection (e.g., a Datagram Transport Layer Security (DTLS) connection) between the UE and an access device of the non-3GPP network may be bootstrapped as a result of completing the attach procedure.

Description

STANDARDIZED ACCESS TO CORE NETWORKS

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No. 62/265,306, which was filed on December 9, 2015, U.S. Provisional Patent Application No. 62/340, 193, which was filed on May 23, 2016, and of PCT/US16/32914, which was filed on May 17, 2016, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Wireless telecommunication networks often include a Core Network (CN) that is connected to multiple Radio Access Networks (RANs) that enable User Equipment (UE), such as smartphones, tablet computers, laptop computers, etc., to connect to the CN. An example of a wireless telecommunication network may include an Evolved Packet System (EPS) that operates based on 3rd Generation Partnership Project (3GPP) Communication Standards.

An EPS may include an Evolved Packet Core (EPC) network that is connected to one or more 3GPP RANs (e.g., a Long Term Evolution (LTE) RAN (also referred to as "Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Networks (E- UTRANs)", a Fifth Generation (5G) RAN, etc.). The LTE networks may each include a RAN with one or more base stations, some or all of which may take the form of enhanced Node Bs (eNBs). UEs may communicate with the EPC network via the LTE network.

Current efforts to further develop wireless telecommunication networks include enabling UEs to connect to a CN (e.g., an EPC) regardless of the type of RAN that the user device is using. For instance, efforts are being made to establish an infrastructure that enables a UE to connect to an EPC via a 3 GPP RAN or a Wi-Fi network. For example, LTE Wireless Local Area Network (WLAN) Aggregation (LWA) and LTE-WLAN Integration with Internet Protocol Security Tunnel (LWIP) have been proposed to enable a UE to connect to an EPC. However, LWA and LWIP may involve an LTE network operating as an umbrella network (via a Radio Resource Control (RRC) connection between the UE and the LTE network) in order to arrange for the UE to connect to the CN via the WLAN (e.g., a Wi-Fi network).

In another example, a Wi-Fi router may communicate with a Generic Access Network (GAN) architecture to connect to a CN. A GAN architecture may include a controller device (often referred to as a GAN Controller (GANC)) without an umbrella network; however, the

GAN architecture may introduce a new RAN-to-CN interface (often referred to as a "Wm interface") that may include a secure tunnel between the GANC and the EPC. Since LTE networks communicate with CNs (e.g., the EPC) via an SI interface, implementing a GANC may involve the CN using different interfaces/protocols to communicate with different UEs/RANs. As such, the CN may use different types of interfaces/connections depending on the technology (e.g., LWA access, LWIP access, GAN access, etc.) used to connect the UE to the CN.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a diagram illustrating an example system in which systems and/or methods described herein may be implemented;

Fig. 2 is a diagram of an example core network (CN);

Fig. 3 is a diagram of an example network with multiple CNs;

Figs. 4 and 5 are diagrams of an example attach procedure, between a User Equipment (UE) and a CN, that includes Extensible Authentication Protocol (EAP) as a Layer-2 transport option;

Fig. 6 is a diagram of an example network architecture that may be used to implement the techniques described herein;

Fig. 7 is a diagram of an example of a non-access stratum (NAS) protocol stack during an attach procedure that includes EAP as a Layer-2 transport option;

Fig. 8 is a diagram of an example of a NAS protocol stack after bootstrapping a non- 3GPP Access Stratum (N3AS) connection via an attach procedure;

Figs. 9 and 10 are diagrams of an example attach procedure that involves IKEv2 protocol as a Layer-3 transport option;

Fig. 11 is a diagram of an example of a NAS protocol stack during an attachment procedure that includes IKEv2 protocol as a Layer-3 transport option;

Figs. 12 and 13 are diagrams of an example attach procedure using Protocol for Carrying Authentication for Network Access (PANA) as a Layer-3 transport option;

Fig. 14 is a diagram of an example of a NAS protocol stack during an attachment procedure that includes PANA as a Layer-3 transport option;

Fig. 15 illustrates, for one embodiment, example components of an electronic device; and

Fig. 16 is a diagram of example components of a network device.

DETAILED DESCRIPTION OF PREFERRED EMBODFMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments are defined by the appended claims and their equivalents.

Techniques described herein may be used to help standardize the manner by which core networks (CNs) communicate with access networks, regardless of whether the access network is a Local Area Network (LAN) (e.g., an Ethernet network), a Wireless Local Area Network (WLAN) (e.g., a Wi-Fi network), or a Wireless Wide Area Network (WW AN) (e.g., a Long- Term Evolution (LTE) network). For instance, when a UE is attached to a LTE network, the UE may connect to a CN via an attach procedure as defined by the 3rd Generation Partnership

Project (3GPP) Communication Standards. When the UE is attached to an Ethernet or a Wi-Fi network, a non-3GPP Access Stratum (N3 AS) protocol may be implemented in order to enable the UE to the CN via the same procedure (e.g., the attach procedure). The standardized interface by which the access network may communicate with the CN (regardless of the type of access network involved) may be referred to herein as an "access-independent interface."

The N3 AS protocol may include performing an attach procedure between a UE and a CN, while bootstrapping a secure connection (also referred to herein as an N3 AS connection) between the UE and a N3 AS device of a non-3GPP access network (e.g., an Ethernet network, a Wi-Fi network, etc.). This may include embedding attach procedure information (e.g., non- access stratum (NAS) messages) into messages of one or more other protocols (e.g., Extensible Authentication Protocol (EAP), Diameter protocol, Internet Key Exchange version 2 (IKEv2) protocol, or Protocol for Carrying Authentication for Network Access (PANA)) for

communications between the UE and the N3 AS device, and implementing the standardized attach procedure for communications between the N3 AS device and the CN. "Bootstrapping," as used herein, may include incorporating information and/or operations for a procedure (e.g., establishing a connection, exchanging security information, etc.) into messages and/or operations corresponding to another procedure (e.g., performing an attach procedure).

Depending on the implementations, the NAS messages between the N3 AS device and the UEs may be communicated via a Layer-2 transport (e.g., EAP and the Diameter protocol) or a Layer-3 transport (e.g., Internet Key Exchange version 2 (IKEv2) or Protocol for Carrying Authentication for Network Access (PANA)). NAS messages may be communicated via a Layer-2 transport in scenarios involving an operator controlled access point (e.g., a Wi-Fi access point that is owned and operated by the same organization as the CN). By contrast, NAS messages may be communicated via a Layer-3 transport in scenarios involving a non-operator controlled access point (e.g., an Ethernet or Wi-Fi access point that is owned and operated by a school, a business, etc.). After the attach procedure is complete, a N3 AS connection between the UE and the N3 AS device may be used to transport additional NAS protocol messages, communicate information about transport addresses for user-plane bearers, relay Quality of Service (QoS) information, etc.

Fig. 1 is a diagram of an example environment 100 in which systems and/or methods described herein may be implemented. Environment 100 may include UEs 110 that are connected to a wireless telecommunication network with different types of RANs.

For example, the wireless telecommunication network may include a core network (CN) that is connected to a 3 GPP RAN (e.g., an LTE RAN, 5G RAN, etc.) or a non-3GPP access network (e.g., a Wi-Fi network, an Ethernet network, etc.). The CN may include an Evolved Packet Core (EPC) that operates based on the 3GPP Communication Standards. However, it should be appreciated that the core network may include another type of CN that is capable of providing wireless telecommunication services. The CN may include a control plane cloud and a user plane cloud. Examples of devices that may be used to implement the control plane cloud and the user plane cloud are discussed below with reference to Fig. 2. To implement the control plane cloud and/or the user plane cloud, one or more of the devices depicted in Fig. 2 may be implemented.

The 3 GPP RAN may be, or may include, one or more base stations (some or all of which may be eNBs 120), via which UEs 110 may communicate with the CN. The non-3GPP access network may include access device 130 and N3AS device 140, via which UEs 110 may communicate with the CN. While the 3GPP RAN is described as a RAN that implements the 3GPP Communication Standards and the non-3GPP access network is described as a WLAN (e.g., an IEEE 802.11 network), a wired LAN (e.g., an Ethernet network), etc., it should be appreciated that the techniques, described herein, may be applicable to different types of networks (including RANs, WLANs, and/or wired LANs that may be developed in the future).

UE 110 may include a portable computing and communication devices, such as a personal digital assistant (PDA), a smart phone, a cellular phone, a laptop computer with connectivity to the wireless telecommunication network, a tablet computer, etc. UE 110 may also include a non-portable computing device, such as a desktop computer, a consumer or business appliance, or another device that has the ability to connect to a RAN (e.g., the LTE RAN and/or the non-3GPP access network) of the wireless telecommunication network. UE 110 may also include a computing and communication device that may be worn by a user (also referred to as a wearable device) such as a watch, a fitness band, a necklace, glasses, an eyeglass, a ring, a belt, a headset, or another type of wearable device.

UE 110 may include software, firmware, or hardware that enables UE 110 to perform one or more of the operations described herein. For example, in addition to connecting to the core network via the LTE RAN, UE 110 may be capable of connecting to the EPC via the non- 3GPP access network (which may be a Wi-Fi network, an Ethernet network, etc.). For instance, UE 110 may connect to the non-3GPP access network via access device 130. In addition, UE 110 may connect to the CN (via the non-3GPP access network) by implementing the N3AS protocol. Depending on the implementation, this may include embedding NAS messages in a Layer-2 transport (such as EAP and Diameter protocol) or in a Layer-3 transport (such as IKEv2 protocol or PAN A).

eNB 120 may include one or more network devices that receives, processes, and/or transmits traffic destined for and/or received from UE 110 via an air interface. eNB 120 may be connected to a network device, such as site router, that functions as an intermediary for information communicated between eNB 120 the core network.

Access device 130 may include one or more network devices that receive, process, and/or transmit traffic destined for and/or received from UE 110. Access device 130 may include a network device, such as a gateway, a router, etc., that is capable of implementing policies and techniques for communicating information between UE 110 and N3AS device 140. Depending on the implementation, access device 130 may implement one or more non-3 GPP protocols, and may operate as a wired or wireless access point for UE 110. For instance, in some implementations, access device 130 may include a Wi-Fi access point or another device that uses an air interface to communicate with UE 110. In some implementations, access device 130 may include an Ethernet access point or another device that uses a wired interface to communicate with UE 110.

N3AS device 140 may include one or more network devices, such as a gateway, a router, etc., that is capable of operating as an intermediary between the devices of the non-3GPP access network (e.g., UE 110 and access device 130) and the CN. In some implementations, N3AS device 140 may receive messages, from access device 130, that are consistent with a

communication protocol of the non-3GPP access network (e.g., IEEE 802.11 Communication

Standards, an Ethernet network, etc.) but that include, encapsulated therein, messages (e.g., NAS messages) that are consistent with a communication protocol of the CN (e.g., the 3GPP

Communication Standards). N3AS device 140 may convert the messages from the protocol of the non-3 GPP access network to a protocol implemented by the CN and may communicate the messages to the CN using the same protocol/interface as the 3 GPP RAN.

Similarly, N3 AS device 140 may receive messages from the CN that are intended for UE 110 of the non-3GPP access network. The messages may be consistent with the communication protocol of the CN (e.g., NAS messages). N3AS device 140 may include the (e.g., NAS) messages in messages that are consistent with the protocol implemented by the non-3GPP access network (e.g., EAP, Diameter, IKEv2, PANA, etc.) and send the messages to the UE.

Fig. 2 is a diagram of an example CN. The devices depicted in Fig. 2 may be an example of the devices used to implement the control plane cloud and user plane cloud discussed above with reference to Fig. 1. The devices of Fig. 2 may operate in a manner that is consistent with one or more protocols implemented by the CN, such as the 3GPP

Communication Protocols.

As shown, the CN may include an EPC that includes Serving Gateway (SGW) 210, PDN Gateway (PGW) 220, Mobility Management Entity (MME) 230, Home Subscriber Server (HSS) 240, and/or Policy and Charging Rules Function (PCRF) 250. The CN may be connected to RANs, such as a 3 GPP RAN and a non-3 GPP access network, and an external network, such as a Public Land Mobile Networks (PLMN), a Public Switched Telephone Network (PSTN), and/or an Internet Protocol (IP) network (e.g., the Internet).

SGW 210 may aggregate traffic received from one or more eNBs 120 and may send the aggregated traffic to an external network or device via PGW 220. Additionally, SGW 210 may aggregate traffic received from one or more PGWs 220 and may send the aggregated traffic to one or more eNBs 120. SGW 210 may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks.

MME 230 may include one or more computation and communication devices that act as a control node for eNB 120 and/or other devices that provide the air interface for the wireless telecommunication network. For example, MME 230 may perform operations to register UE 110 with the wireless telecommunication network, to establish bearer channels (e.g., traffic flows) associated with a session with UE 110, to hand off UE 110 to a different eNB, MME, or another network, and/or to perform other operations. MME 230 may perform policing operations on traffic destined for and/or received from UE 110.

PGW 220 may include one or more network devices that may aggregate traffic received from one or more SGWs 210, and may send the aggregated traffic to an external network. PGW 220 may also, or alternatively, receive traffic from the external network and may send the traffic toward UE 110 (via SGW 140 and/or eNB 120). PGW 220 may be responsible for providing charging data for each communication session to PCRF 250 to help ensure that charging policies are properly applied to communication sessions with the wireless telecommunication network.

HSS 240 may include one or more devices that may manage, update, and/or store, in a memory associated with HSS 240, profile information associated with a subscriber (e.g., a subscriber associated with UE 110). The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a Mobile Directory Number (MDN) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; and/or other information. The subscriber may be associated with UE 110. Additionally, or alternatively, HSS 240 may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE 110.

PCRF 250 may receive information regarding policies and/or subscriptions from one or more sources, such as subscriber databases and/or from one or more users. PCRF 250 may provide these policies to PGW 220 or another device so that the policies can be enforced. As depicted, in some embodiments, PCRF 250 may communicate with PGW 220 to ensure that charging policies are properly applied to locally routed sessions within the telecommunication network. For instance, after a locally routed session is terminated, PGW 220 may collect charging information regarding the session and provide the charging information to PCRF 250 for enforcement.

The quantity of devices and/or networks, illustrated in Figs. 1 and 2, are provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Figs. 1 and 2. Alternatively, or additionally, one or more of the devices of Figs. 1 and 2 may perform one or more functions described as being performed by another one or more of the devices of Figs. 1 and 2. Furthermore, while "direct" connections are shown in Figs. 1 and 2, these connections should be interpreted as logical communication pathways, and in practice, one or more intervening devices (e.g., routers, gateways, modems, switches, hubs, etc.) may be present.

Fig. 3 is a diagram of an example network with multiple CNs. As shown, the wireless telecommunication network may include (among other networks and devices) an access network and multiple CNs. The access network may include a 3 GPP RAN or a non-3 GPP access network (e.g., a Wi-Fi network, an Ethernet network, etc.). Each core network may implement protocols and devices that are consistent with one or more communication standards. For example, one CN may be an EPC that operates in accordance with the 3 GPP Communication Standards, another CN may be an Internet-of-Things (IoT) network that specializes in providing services to Machine-to-Machine (M2M) devices, and another CN may specialize in providing 5G services. In another example, the CNs may each be (or include) 3GPP CNs that correspond to different PLMN networks. As described below in more detail, the techniques described herein may include an attachment procedure that enables UE 110 to indicate (e.g., via EAP messages) the particular CN (or type of CN) to which the UE is to be connected.

Figs. 4 and 5 are diagrams of an example attach procedure, between a UE and a CN, that includes EAP as a Layer-2 transport option. As shown, the example attach procedure may include UE 110, access device 130, N3AS device 140, a control plane cloud, and HSS 240. The example devices and clouds of Figs. 4 and 5 are described above with reference to Figs. 1 and 2. In the example of Figs. 4 and 5, access point 130 may be a WLAN access point (e.g., a Wi-Fi router) that implements EAP over LAN (EAPoL) to carry Layer-2 EAP messages using IEEE 802.11

Additionally, the attach procedure of Figs. 4 and 5 may include certain operations (e.g., 435-455, 485, 490, 510, 560, and 570) that correspond to an interface/protocol (referred to herein as "Standardized Access Network-to-CN Messaging") that has been standardized for messaging between access networks and CNs, regardless of the type of access network involved (e.g., LTE networks, Wi-Fi networks, Ethernet networks, etc.). In some implementations, the standardized interface/protocol may include NAS messages that are communicated over the SI interface of the 3 GPP Communications Standards.

As shown, UE 110 may establish a connection with access device 130 (block 405). The operations performed by UE 110 and access device 130 in order to establish the connection may depend on the type of access network being implemented. For instance, when access device 130 includes a Wi-Fi router, UE 110 and access device 130 may perform operations of the IEEE 802.11 Communication Standards in order to establish the connection. Access device 130 may communicate an EAP-REQ message regarding the identity of UE 110 (line 410), and UE 110 may respond by sending an EAP -RES message, with the requested identity, to access device 130 (line 415). Additionally, access device 130 may send the EAP -RES message to N3AS device 140.

As mentioned above with reference to Fig. 3, in some implementations, a single access network may provide service to multiple PLMNs and/or CNs, such as an EPC, an IoT CN, and a 5G CN. As such, at some point during the attach procedure, UE 110 may indicate to N3AS device 140 the type of CN to which UE 110 is to be connected. UE 110 may provide an identifier that corresponds to a particular CN, a particular type of CN, multiple CN identifiers arranged according to preference, etc. In some implementations, UE 110 may provide such information to N3AS device 140 via an EAP-RSP/Identity message (at, for example, line 415).

N3AS device 140 may send an EAP-REQ message with an Authentication Request to UE 110 via access device 130 (line 420). UE 110 may send an EAP-RSP message with an Attach Request to access device 130 (line 425), and access device 130 may include the EAP- RSP message (and the Attach Request) from UE 1 10 in an Authentication, Authorization, and Accounting (AAA) Diameter message that is sent to N3 AS device 140 (line 430).

N3AS device 140 may extract the Attach Request message from the AAA Diameter message and send the Attach Request message to the control plane cloud of the CN (line 435). As shown, the Attach Request message may be part of a standardized Access Network-to-CN messaging protocol, such the NAS protocol of the 3GPP Communication Standards. In other words, N3AS Device 140 may communicate with the CN (e.g., the control plane cloud) in the same or similar manner as an eNB of an LTE network might communicate with the CN. In response to the Attach Request message, the control plane cloud may exchange Authentication Information Request (AIR) messages (lines 440 and 445) with HSS 240, which may include the control plane cloud receiving an Authentication Key Argument (AKA) vector from HSS 240 (line 445). In response to the AIR message from HSS 240, the control plane cloud may derive key material (block 450) for enabling secure communications with UE 110.

The control plane cloud may send a downlink (DL) NAS Transport message to N3 AS device 140, which may include an Authentication Request message (line 455). The

Authentication Request message may be a NAS Authentication Request message of the 3 GPP Communication Standard. In response, N3 AS device 140 may send an AAA Diameter message to access device 130, which may include encapsulating the Authentication Request message in an EAP-REQ message (line 460). Access device 130 may send the EAP-REQ Authentication Request message to UE 1 10 (line 465). UE 110 may respond by executing AKA algorithms and generating an appropriate response (block 470), followed by sending an EAP-RSP message, which may include an Authentication Response message, to access device 130 (line 475). The Authentication Response message may include a NAS Authentication Response message of the 3 GPP Communication Standard.

As shown, access device 130 may send another AAA Diameter message to N3AS device 140, which may include the EAP-RES Authentication Response message originated by UE 110 (line 480). This may enable N3 AS device 140 to send an uplink (UL) NAS Transport message to the control plane cloud of the CN (line 485). As shown, the UL NAS Transport message may include the Authentication Response message. Additionally, the UL NAS Transport message may be part of the standardized Access Network-to-CN messaging protocol. The control plane cloud may perform control functions to verify the response originated by UE 110 (i.e., the Authentication Response message) and continue with the attachment procedure (block 490).

Referring now to Fig. 5, the control plane cloud may send an Initial Context Setup Request message to N3AS device 140 (line 510), which may include a NAS Attach Accept message. In response, N3AS device 140 may respond to the request from the control plane cloud by sending an AAA Diameter message that may include an EAP-REQ message with the Attach Accept message. The EAP-REQ message may also include N3 AS Function (N3 ASF) information (line 520). Examples of N3ASF information may include information for enabling UE 110 to continue communicating with N3AS device 140 after the attach procedure is complete (e.g., an Internet Protocol (IP) address of N3AS device 140, a User Datagram Protocol (UDP) information for N3AS device 140, security information, etc.).

Access device 130 may send the EAP-REQ message (with the Attach Accept message and the N3ASF information) to UE 110 (line 530). In turn, UE 110 may respond by sending an EAP-RSP message (that includes an Attach Complete message) to access device 130 (line 540). The Attach Complete message may include a NAS Attach Complete message of the 3 GPP Communication Standard. Access device 130 may send an AAA Diameter message that includes the EAP-RSP message and the Attach Complete message to N3 AS device 140 (line 550).

In response, N3AS device 140 may continue with the attach procedure using the standardized Access Network-to-CN messaging. For Instance, as shown, N3AS device 140 may send an Initial Context Setup Response message (that includes the Attach Complete message) to the control plane cloud (line 560), and the control plane cloud may perform one or more functions to complete the attach procedure (block 570). Additionally, or alternatively, N3 AS device 140 may send an AAA Diameter message to access device 130, which may include an EAP-RSP Success message (line 580), and access device 130 may respond by sending the EAP- RSP Success message to UE 110 (line 590).

The attach procedure of Figs. 4 and 5 may result in bootstrapping an N3AS connection between UE 110 and N3AS device 140. For instance, as part of the attach procedure, N3ASF information (e.g., a transport address for N3 AS device 140) may be generated by N3 AS device 140 (at line 520) and received by UE 110 (at line 530). In some implementations, the N3AS connection may include a Datagram Transport Layer Security (DTLS) connection and/or may be used to transport N3 AS protocol information, which may include additional NAS protocol messages (e.g., similar to RRC Direct Transfer procedure), information about transport addresses for user-plane bearers, QoS information, etc., (e.g., similar to RRC Connection Reconfiguration procedure). In some implementations, an IP Security (IPsec) stack may be used to communicate the N3 AS protocol information.

Additionally, the attach procedure may include generating security information (e.g., a security key, hash function, a nonce, etc.) that may be used to ensure that the N3 AS connection is secure. In some implementations, the security information may be generated in one location

(e.g., by the control plane cloud at, for example, block 450) and then communicated to the appropriate devices (e.g., UE 110, access device 130, and N3AS device 140). Alternatively, the security information may be independently generated at different locations, such as by UE 110 and the CN. For example, the attach procedure may create a security association between UE 110 and the CN, which may include determining a master key and seed information (also referred to as key material) (e.g., a combination of the master key and a known character string) for a Key Derivation Function (KDF). In some implementations, the control plane cloud may provide the key material to N3AS device 140 (at, for example, box 510) and generate a Pairwise Master Key (PMK) based on the key material and the KDF. N3 AS device 140 may send the PMK to access device 130.

Meanwhile, since UE 110 may have already acquired master key, seed information, and KDF, UE 110 may derive its own PMK instead of receiving it from the CN, N3AS device 140, or access device 130. In some implementations, UE 110 may derive the PMK in conjunctions with running the AKA algorithms during the attach procedure (block 470). UE 110 and access device 130 may use their respective PMKs to complete a 4-way security exchange (or handshake) to create a secure N3 AS connection between the two devices. Establishing a secure connection in this manner (i.e., by deriving security keys independently) may help protect access device 130 security threats, such as Denial of Service (DoS) attacks in addition to enabling non- operator control access device 130 to connect to operator-control CNs.

Fig. 6 is a diagram of an example network architecture that may be used to implement the techniques described herein. The network architecture, illustrated in Fig. 6, is provided for explanatory purposes only. In practice, there may be additional devices, networks, and/or interfaces; fewer devices, networks, and/or interfaces; different devices, networks, and/or interfaces or differently arranged devices, networks, and/or interfaces than illustrated in Fig. 6. Additionally, the interface names/labels provided in Fig. 6 (e.g., Yl, Y2, Y3, NG1, NG2, etc.) are provided for explanatory purposes only. In practice, the devices shown in Fig. 6 may communicate via interfaces with different labels.

As shown, UE 110 may communicate with the control plane cloud of the CN via an NG1 interface. NG as discussed herein may refer to a version or generation of communication standards that are currently available (such as the 3GPP Communication Standards) and/or a version or generation of communication standards that may be developed in the future (e.g., 5G Communication Standards, 6G Communication Standards, etc.). UE 110 may communicate with access device 130 via a Yl interface that may be based on the type of non-3GPP access network being implemented by the non-3GPP access network. For instance, the Yl interface may include a non-3GPP interface (e.g., an IEEE 802.11 interface, an Ethernet interface, etc.). Access device 130 may communicate with N3AS device 140 via a Y2 interface, which may include any type of suitable wireless or wired connection (e.g., an Ethernet interface).

UE 110 may communicate with N3AS device 140 via a Y3 interface, which may involve the N3 AS protocol described herein. The N3 AS protocol may be functionally similar to the RRC protocol implemented by UTRANs; however, the N3 AS protocol may have different and/or additional functions. For example, the N3 AS protocol may be used for transparent transport of NAS messages between UE 110 and the CN, as well as for exchanging information for the user-plane bearers between UE 110 and N3AS device 140, including security

information.

Transparent transport, as described herein, may include the CN acknowledging that a particular UE is connecting to the CN via a non-3GPP access network, which may include the CN acknowledging that certain services (e.g., certain RRC services) may not be applicable to the particular UE. For instance, when UE 110 is connecting to the CN via a Wi-Fi network, the CN may acknowledge that UE 110 may not use certain services/procedures, such as UE idle modes services, services relating to transitions between a UE idle mode and a UE connected mode, UE mobility services, UE paging services, Tracking Area Update (TAU) services, etc. This may be a result of the nature of the connection between the UE and the WLAN (and/or the

communication protocol implemented by the WLAN). For example, a UE may be considered in an indefinite active mode (i.e., not entering an idle mode) when connected to a Wi-Fi network. As another example, the UE may not need mobility services (connected mode mobility procedures, path switching, etc.) since the UE cannot seamlessly transition (e.g., experience a handover) between Wi-Fi networks as the UE moves from one location to another. The user plane connection between UE 110 and N3AS device 140 may include Layer-2 tunnels over modified access points (APs) or Internet Protocol Security (IPsec) tunnels over legacy APs.

N3 AS device 140 may communicate with the control pane cloud via a NG2 interface. The NG2 interface may be similar to the Sl-MME interface of an EPS. N3AS device 140 may communicate with the user pane cloud via a NG3 interface, which may be an interface that is similar to the Sl-U interface of an EPS. The user plane cloud and the control plane cloud may communicate via an NG4 interface that may be similar to the Sxa, Sxb, and/or Sxc interface of the 3GPP Communication Standards.

Fig. 7 is a diagram of an example of a non-access stratum (NAS) protocol stack during an attach procedure that includes Extensible Authentication Protocol (EAP) as a Layer-2 transport option. As shown, the protocol stack may correspond to communications between UE 110, access device 130, N3AS device 140, and a control plane cloud. The protocol stack for UE 110 and the control plane cloud may include a NAS (or NG) protocol layer, an EAP layer, an EAPoL 802.11 layer, and a WLAN Media Access Control/Physical (MAC/PHY) layer.

Access device 130 may include certain layers for the Yl interface (e.g., the interface with UE 110) and other layers for the Y2 interface (e.g., the interface with N3AS device 140. For instance, on the Yl side, access device 130 may include an EAP layer, an EAPol 802.11 layer, and a WLAN MAC/PHY layer, while on the Y2 side, access device 130 may include an EAP layer, an NG2 lower layer, and an L1/L2 layer.

N3 AS device 140 may include certain layers for the Y2 interface (e.g., the interface with access device 130) and other layers for the NG2 interface (e.g., the interface with the control plane cloud). For instance, on the Y2 side, N3AS device 140 may include an EAP layer followed by a diameter transport layer and an L1/L2 layer. On the NG2 side, N3AS device 140 may include an NG2-AP protocol layer and one or more NG2 lower layers. By contrast, the control plane cloud may include an NGl protocol layer (e.g., a NAS layer) that corresponds to the NGl protocol layer of UE 110, and an NG2-AP protocol layer and lower NG2 layers that may correspond to the layers on the NG2 interface side of N3AS device 140.

Fig. 8 is a diagram of an example of a NAS protocol stack after bootstrapping a N3 AS connection via an attach procedure. As shown, UE 110 may include an NGl protocol layer (e.g., a NAS protocol layer), an NG2-AP protocol layer, a DTLS layer, a UDP, an IP version 4 (IPv4) and IPv6 layer, and a WLAN MAC/PHY layers. With exception to the NGl protocol layer, the layers of UE 110 may correspond to those of the Y3 interface side of N3AS device 140. On the NG2 interface side, N3AS device 140 may include an NG2-AP protocol layer, and lower NG2 layers. The control plane cloud may include an NGl protocol layer (e.g., a NAS layer) that corresponds to the NGl protocol layer of UE 110, and an NG2-AP protocol layer and lower NG2 layers that correspond to the layers on the NG2 interface side of N3 AS device 140.

Figs. 9 and 10 are diagrams of an example attach procedure that involves IKEv2 protocol as a Layer-3 transport option. As shown, Figs. 9 and 10 include UE 110, access device 130, N3AS device 140, a control plane cloud, and HSS 240, examples of which are described above with reference to Figs. 1 and 2. Since messages between UE 110 and N3AS device 140, in Figs. 9 and 10, may be communicated over a Layer-3 transport (e.g., via IKEv2), access device 130 may take on a relatively passive role that may include relaying information between UE 1 10 and N3AS device 140. Additionally, since the attach procedure of Figs. 9 and 10 involves a Layer-3 transport (as opposed to, for example, a Layer-2 transport as described above in Figs. 4 and 5), access device 130 may be a wired and/or wireless network device (e.g., an Ethernet access point, a Wi-Fi access point, etc.).

The attach procedure of Figs. 9 and 10 may include certain operations that correspond to an interface/protocol (referred to herein as "Standardized Access Network-to-CN Messaging") that has been standardized for messaging between access networks and CNs, regardless of the type of access network involved (e.g., LTE networks, Wi-Fi networks, Ethernet networks, etc.). In some implementations, the standardized interface/protocol may include the NAS protocol of the 3GPP Communications Standards. In some implementations, the standardized

interface/protocol may include another type of standardized interface/protocol, including CN communication standards that may be developed in the future.

As shown, UE 110 and N3AS device 140 may perform an IKE Security Association Initial Exchange (or IKE SA INIT) procedure that involves negotiating cryptographic algorithms, communicating a nonce, Diffie-Hellman (D-H) exchanges, etc. (block 905). UE 110 may send an IKE AUTH Request message to N3 AS device 140, which may include appropriate header information an identifier (ID) for UE 110 (line 910). N3AS device 140 may respond to UE 110 with an IKE AUTH Response message that includes header information, an ID of N3 AS device 140 (and/or a function thereof) and an EAP-REQ message that includes a NAS Auth Request (line 915). In turn, UE 110 may communicate, to N3AS device 140, an

IKE AUTH Request with the appropriate header information an EAP-REQ message that includes a NAS Attach Request (line 920).

N3 AS device 140 may extract the NAS Attach Request from the EAP-REQ message and send the NAS Attach Request to the control plane cloud of the CN (line 925). As shown, the NAS Attach Request may be part of a standardized Access Network-to-CN messaging protocol, such as the NAS protocol. In other words, N3 AS Device 140 may communicate with the CN (e.g., the control plane cloud) in the same or similar manner as an eNB of an LTE network might communicate with the CN. In response to the NAS Attach Request, the control plane cloud may exchange AIR messages with HSS 240 (lines 930 and 935), which may include the control plane cloud receiving an AKA vector from HSS 240. The control plane cloud may derive key material that may later be used to enable secure communications with UE 110 (block 940).

The control plane cloud may continue with the Standardized Access Network-to-CN

Messaging by using a downlink (DL) NAS transport to send a NAS Auth Request message to N3AS device 140 (line 945). In response, N3AS device 140 may generate and send, to UE 110, an IKE AUTH Response that may include header information, an ID of N3 AS device 140 (and/or a function thereof), and an EAP-REQ message that includes a NAS Auth Request (line 950). UE 110 may run AKA algorithms and generate an appropriate response (block 955) followed by sending an IKE AUTH Request that may include header information, and an EAP- REQ message that includes a NAS Auth Response, to N3 AS device 140 (line 960).

N3 AS device 140 may extract the NAS Auth Response and, in accordance with the

Standardized Access Network-to-CN messaging protocol implemented by the CN, use an uplink (UL) NAS transport to send the NAS Auth Response to the control plane cloud (line 965). The control plane cloud may execute one or more control plane functions to, for example, verify the Auth Response and proceed with the attachment procedure (block 970). In addition, the control plane cloud may generate and send an Initial Context Setup Request, which may include a NAS Attach Accept and key material (e.g., information for generating security keys), to N3AS device 140 (line 975). N3AS device 140 may respond by sending an IKE AUTH Response, to UE 110, which may include header information, an EAP-REQ message with the NAS Attach Accept, and appropriate N3ASF information (line 980). Examples of N3ASF information may include information for enabling UE 110 to continue communicating with the CN (via N3AS device 140) after the attach procedure is complete (e.g., IP addresses, UDP information, etc.). In response, UE 110 may generate and send, to N3AS device 140, an IKE AUTH Request that may include header information and an EAP-REQ message with a NAS Attach Complete (line 985).

Referring now to Fig. 10, N3AS device 140 may continue with the attach procedure in accordance with the Standardized Access Network-to-CN Messaging. For instance, as shown, N3 AS device 140 may send an Initial Context Setup Response (that may include the NAS

Attach Complete) to the control plane cloud (line 1010). The control plane cloud may perform one or more control plane functions to complete the CN side of the attach procedure (block 1020). N3AS device 140 may complete the access network side of the attach procedure by generating and sending, to UE 110, an IKE AUTH Request, which may include header information and an EAP-Success message (line 1030).

Performing the attach procedure via the N3AS protocol described in Figs. 9 and 10 may result in a connection being established between UE 110 and N3AS device 140. The connection may be used to carry N3 AS messages that may include NAS protocol messages, information regarding transport addresses for user-plane bearers, QoS information, etc. Additionally, the connection may be a IKEv2 connection or a N3 AS connection (which may be bootstrapped as a result of N3ASF info received during the attach procedure at, for example, line 980). The IKEv2 connection may be used to carry subsequent N3 AS messages as an IKEv2 Configuration payload or an IKEv2 Notification payload. The N3 AS connection may include a DTLS connection that carries N3 AS protocol messages. Alternatively, N3 AS protocol messages may be carried over an IPsec protocol stack.

(e.g., by the control plane cloud) and then communicated to the appropriate devices (e.g., UE 110, access device 130, and N3AS device 140). Alternatively, the security information may be independently generated at different locations, such as by UE 110 and the CN.

For example, the attach procedure may create a security association between UE 110 and the CN, which may include determining a master key and seed information (e.g., a combination of the master key and a known character string) for a KDF. In some implementations, the control plane cloud may provide the key material to N3 AS device 140 (at, for example, box 975). N3AS device 140 may generate a PMK based on the key material and the KDF and send the PMK to access device 130.

Meanwhile, UE 110 may derive its own PMK (instead of receiving it from another device). In some implementations, UE 110 may derive the PMK in conjunction with running the AKA algorithms during the attach procedure (block 965). UE 110 and access device 130 may use their respective PMKs to complete a 4-way security exchange (or handshake) to create a secure N3 AS connection between the two devices. Establishing a secure connection in this manner (i.e., by deriving security keys independently) may help protect access device 130 security threats, such as DoS attacks in addition to enabling non-operator control access device 130 to connect to operator-control CNs.

In some implementations, preceding the operations depicted in the example attach procedure of Figs. 9 and 10, UE 110 may perform one or more operations to discover N3AS device 140 and whether UE 110 may connect to a CN via access device 130 (and/or N3 AS device 140). In some implementations, UE 110 may also discover whether there are multiple CNs and the types of CNs behind access device 130 (and/or N3 AS device 140). This may be enabled by, for example, providing UE 110 with IP addresses of one or more N3AS devices 140 or by providing UE 110 with fully qualified domain names (FQDNs) that can be resolved into IP addresses using dynamic host configuration protocol (DHCP). Additionally, the attach procedure of Figs. 9 and 10 include IKEv2 messages that may carry EAP messages with NAS messages. In some implementations, however, the IKEv2 messages may instead carry NAS messages as IKEv2 parameters (e.g., inside 3GPP-specific IKEv2 configuration payloads or IKEv2 notification payloads).

Fig. 11 is a diagram of an example protocol stack for an attach procedure that includes IKEv2 protocol as a Layer-3 transport option. As shown, UE 110 may include an NGl protocol layer (e.g., a NAS protocol layer) by which UE 110 may communicate with the control plane cloud of the CN. Below the NGl protocol layer, UE 110 may include an EAP layer as a Layer-2 transport option followed by an IKEv2 layer as a Layer-3 transport option. UE 110 may also include an IPv4/IPv6 layer and an L1/L2 layer.

N3AS device 140 may include similar layers (e.g., an EAP layer, an IKEv2 layer, etc.) for the Y2 interface side of N3AS device 140. For the NG2 interface side, N3AS device 140 may include an NG2-AP layer and one or more lower NG2 layers. The control plane cloud may include an NG1 protocol layer (e.g., a NAS layer) that corresponds to the NG1 protocol layer of UE 110, and an NG2-AP protocol layer and lower NG2 layers that correspond to the layers on the NG2 interface side of N3AS device 140.

Figs. 12 and 13 are diagrams of an example attach procedure using PANA as a Layer-3 transport option. As shown, Figs. 12 and 13 may include UE 110, access device 130, N3AS device 140, a control plane cloud, and HSS 240, examples of which are described above with reference to Figs. 1 and 2. Since messages between UE 110 and N3AS device 140, in Figs. 12 and 13, may be communicated over a Layer-3 transport (e.g., via PANA), access device 130 may take on a relatively passive role that may include relaying messages between UE 110 and N3AS device 140. Additionally, since the attach procedure of Figs. 12 and 13 involves a Layer- 3 transport (as opposed to, for example, a Layer-2 transport as described above in Figs. 4 and 5), access device 130 may include a wired and/or wireless network device (e.g., an Ethernet access point, a Wi-Fi access point, etc.).

Additionally, the attach procedure of Figs. 12 and 13 may include certain operations that correspond to an interface/protocol (referred to herein as "Standardized Access Network-to-CN Messaging") that has been standardized for messaging between access networks and CNs, regardless of the type of access network involved (e.g., LTE networks, Wi-Fi networks, Ethernet networks, etc.). In some implementations, the standardized interface/protocol may include the NAS protocol of the 3GPP Communications Standards. In some implementations, the standardized interface/protocol may include another type of standardized interface/protocol, including CN communication standards that may be developed in the future.

As shown, UE 110 may send a PANA Client Initiation message to N3AS device 140 (line 1205), to which N3 AS device 140 may respond with a PANA Auth Request message that may include an EAP-REQ message with a NAS Identity (line 1210). In turn, UE 110 may communicate a PANA Auth Answer message, which may include an EAP-RSP message carrying a NAS Identity (line 1215). N3AS device 140 may send a PANA Auth Request message that includes an Attach Request within an EAP-REQ message (line 1220), and UE 110 may respond with a PANA Auth Answer message with a NAS Attach Request carried by an EAP-RSP message (line 1225).

N3 AS device 140 may extract the NAS Attach Request from the EAP-REQ message and send the NAS Attach Request to the control plane cloud of the CN (line 1230). As shown, the

NAS Attach Request may be part of a messaging protocol that has been standardized for communications between access networks and CNs. As such, N3AS Device 140 may communicate with the control plane cloud of the CN via the same interface/protocol as an eNB of an LTE network might communicate with the CN. In response to the NAS Attach Request, the control plane cloud may exchange AIR messages (lines 1235 and 1240) with HSS 240, which may include the control plane cloud receiving an AKA vector from HSS 240. The control plane cloud may derive key material that may later be used to enabling secure communications with UE 110 (block 1245).

The control plane cloud may continue with the Standardized Access Network-to-CN Messaging by using a DL NAS transport to send a NAS Auth Request message to N3 AS device 140 (line 1250). In response, N3AS device 140 may generate and send, to UE 110, a PANA Auth Request that may include the NAS Auth Request within an EAP-REQ message (line 1255). UE 110 may perform AKA algorithms and generate an appropriate response (e.g., (block 1260) and sends a PANA Auth Answer message, which may include a NAS Auth Response in an EAP-RSP message, to n3AS device 140 (line 1265).

N3AS device 140 may continue with the Standardized Access Network-to-CN

Messaging by extracting the NAS Auth Response and using an UL NAS Transport to send the NAS Auth Response to the control plane cloud (line 1270). The control plane cloud may execute one or more control plane functions to, for example, verify the NAS Auth Response and proceed with the attachment procedure (block 1275). In addition, the control plane cloud may generate and send an Initial Context Setup Request, which may include a NAS Attach Accept and key material (e.g., information for generating security keys), to N3AS device 140 (line 1280). N3AS device 140 may respond by sending a PANA Auth Request, to UE 110, which may include an EAP-REQ message with the NAS Attach Accept, and N3 ASF information (line 1285). Examples of N3ASF information may include information for enabling UE 110 to continue communicating with the CN (via N3 AS device 140) after the attach procedure is complete (e.g., IP addresses, UDP information, etc.). In response, UE 110 may generate and send, to N3 AS device 140, sending a PANA Auth Answer message that may include an EAP- REQ message with a NAS Attach Complete (line 1290).

Referring now to Fig. 13, N3AS device 140 may continue with the attach procedure in accordance with the Standardized Access Network-to-CN Messaging. For instance, N3 AS device 140 may send an Initial Context Setup Response (that may include the NAS Attach Complete) to the control plane cloud (line 1310). The control plane cloud may perform one or more control plane functions to complete the CN side of the attach procedure (block 1320), and N3AS device 140 may complete the access network side of the attach procedure by generating and sending, to UE 110, a PANA Auth Request that may include a PANA AUTH KEY, a key ID, and an EAP-Success message (line 1330). UE 110 may respond by sending a PANA Auth Answer that includes a corresponding PANA AUTH KEY and a key ID (line 1340).

Performing the attach procedure via the N3AS protocol described in Figs. 12 and 13 may result in a connection being established between UE 110 and N3AS device 140. The connection may be used to carry N3 AS messages that may include NAS protocol messages, information regarding transport addresses for user-plane bearers, QoS information, etc. In some

implementations, the N3 AS message may include a DTLS connection that is bootstrapped as a result of N3ASF information received during the attach procedure at, for example, line 1285).

The attach procedure of Figs. 12 and 13 may include bootstrapping an N3AS connection between UE 110 and N3AS device 140. For instance, as part of the attach procedure, N3ASF info (e.g., a transport address for N3 AS device 140) may be generated by N3 AS device 140 and received by UE 110 (at line 1285). In some implementations, the N3AS connection may include a DTLS connection and/or may be used to transport N3 AS protocol information, which may include additional NAS protocol messages, information about transport addresses for user-plane bearers, QoS information, etc. In some implementations, an IPsec stack may be used to communicate the N3 AS protocol information.

Additionally, the attach procedure may include generating security information that may be used to ensure that the N3 AS connection is secure. In some implementations, the security information may be generated in one location (e.g., the CN) and then communicated to the appropriate devices (e.g., UE 110, access device 130, and N3AS device 140). Alternatively, the security information may be generated at different locations independently, such as by UE 110 and the control plane cloud. For example, the attach procedure may create a security association between UE 110 and the CN, which may include determining a master key and seed information (also referred to as key material) for a KDF. The control plane cloud may provide the seed information to N3AS device 140 (at, for example, box 1280). N3AS device 140 may generate a PMK based on the key material and the KDF and send the PMK to access device 130.

Meanwhile, since UE 110 may already have the seed information and the KDF, UE 110 may derive its own PMK instead of receiving it from another device. In some implementations, UE 110 may derive the PMK in conjunctions with the AKA algorithms of the attach procedure (block 1260). UE 110 and access device 130 may use their respective PMKs to complete a 4- way security handshake to create a secure N3 AS connection between the two devices. Deriving security keys independently may help protect access device 130 from security threats, such as

DoS attacks, in addition to enabling non-operator control access device 130 to connect to operator-control CNs.

In some implementations, preceding the operations depicted in the example attach procedure of Figs. 12 and 13, UE 110 may perform one or more operations to discover N3AS device 140 and whether UE 110 may connect to a CN via access device 130 (and/or N3 AS device 140). In some implementations, UE 110 may also discover whether there are multiple CNs and the types of CNs behind access device 130 (and/or N3 AS device 140). This may be enabled by, for example, providing UE 110 with the IP addresses of one or more N3AS devices 140 or by providing UE 110 with FQDNs that UE 110 may be resolved into IP addresses using DHCP. Additionally, while EAP containers may be optional (due to the use of IKEv2) in the example attach procedure of Figs. 9 and 10, EAP containers may be used in the example attach procedure of Figs. 12 and 13 due to the use of P ANA.

Fig. 14 is a diagram of an example protocol stack for an attach procedure that includes PANA as a Layer-3 transport option. As shown, UE 110 may include an NG1 protocol layer (e.g., a NAS protocol layer) by which UE 110 may communicate with the control plane cloud of the CN. Below the NG1 protocol layer, UE 110 may include an EAP layer as a Layer-2 transport option followed by a PANA layer as a Layer-3 transport option. UE 110 may also include UDP/IP layer and an L1/L2 layer.

N3AS device 140 may include similar layers (e.g., an EAP layer, a PANA layer, etc.) for the Y2 interface side of N3AS device 140. For the NG2 interface side, N3AS device 140 may include an NG2-AP layer and one or more lower NG2 layers. The control plane cloud may include an NG1 protocol layer (e.g., a NAS layer) that corresponds to the NG1 protocol layer of UE 110, and an NG2-AP protocol layer and lower NG2 layers that correspond to the layers on the NG2 interface side of N3AS device 140.

As used herein, the term "circuitry" or "processing circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 15 illustrates, for one embodiment, example components of an electronic device 1500. In embodiments, the electronic device 1500 may be a

UE, an eNB, a WLAN AP, or some other appropriate electronic device. In some embodiments, the electronic device 1500 may include application circuitry 1502, baseband circuitry 1504,

Radio Frequency (RF) circuitry 1506, front-end module (FEM) circuitry 1508 and one or more antennas 1560, coupled together at least as shown. In other embodiments, any of said circuitries can be included in different devices.

The application circuitry 1502 may include one or more application processors. For example, the application circuitry 1502 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage, and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system. In some implementations, storage medium 1503 may include a non-transitory computer-readable medium. The memory/storage may include, for example, computer-readable medium 1503, which may be a non-transitory computer-readable medium. Application circuitry 1502 may, in some embodiments, connect to or include one or more sensors, such as environmental sensors, cameras, etc.

Baseband circuitry 1504 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1504 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 1506 and to generate baseband signals for a transmit signal path of the RF circuitry 1506. Baseband processing circuitry 1504 may interface with the application circuitry 1502 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1506. For example, in some embodiments, the baseband circuitry 1504 may include a second generation (2G) baseband processor 1504a, third generation (3G) baseband processor 1504b, fourth generation (4G) baseband processor 1504c, and/or other baseband processor(s) 1504d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 1504 (e.g., one or more of baseband processors 1504a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1506. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some implementations, baseband circuitry 1504 may be associated with storage medium 1503 or with another storage medium.

In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1504 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry

1504 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity

Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments. In some embodiments, the baseband circuitry 1504 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (E-UTRAN) protocol including, for example, physical (PHY), MAC, radio link control (RLC), PDCP, and/or radio resource control (RRC) elements. A central processing unit (CPU) 1504e of the baseband circuitry 1504 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 1504f. The audio DSP(s) 1504f may be include elements for

compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 1504 may further include memory/storage 1504g. The memory/storage 1504g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 1504. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 1504g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache, buffers, etc. The memory/storage 1504g may be shared among the various processors or dedicated to particular processors.

Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some

embodiments, some or all of the constituent components of the baseband circuitry 1504 and the application circuitry 1502 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1504 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1504 may support communication with an E-UTRAN and/or other wireless metropolitan area networks (WMAN), a WLAN, a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1504 is configured to support radio

communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 1506 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1506 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1506 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1508 and provide baseband signals to the baseband circuitry 1504. RF circuitry 1506 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1504 and provide RF output signals to the FEM circuitry 1508 for transmission.

In some embodiments, the RF circuitry 1506 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 1506 may include mixer circuitry 1506a, amplifier circuitry 1506b and filter circuitry 1506c. The transmit signal path of the RF circuitry 1506 may include filter circuitry 1506c and mixer circuitry 1506a. RF circuitry 1506 may also include synthesizer circuitry 1506d for synthesizing a frequency for use by the mixer circuitry 1506a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1506a of the receive signal path may be configured to down- convert RF signals received from the FEM circuitry 1508 based on the synthesized frequency provided by synthesizer circuitry 1506d. The amplifier circuitry 1506b may be configured to amplify the down-converted signals and the filter circuitry 1506c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals.

Output baseband signals may be provided to the baseband circuitry 1504 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this may not necessarily the case. In some embodiments, mixer circuitry 1506a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1506a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1506d to generate RF output signals for the FEM circuitry 1508. The baseband signals may be provided by the baseband circuitry 1504 and may be filtered by filter circuitry 1506c. The filter circuitry 1506c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1506a of the receive signal path and the mixer circuitry 1506a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 1506a of the receive signal path and the mixer circuitry 1506a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g.,

Hartley image rejection). In some embodiments, the mixer circuitry 1506a of the receive signal path and the mixer circuitry 1506a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 1506a of the receive signal path and the mixer circuitry 1506a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1506 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1504 may include a digital baseband interface to communicate with the RF circuitry 1506.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 1506d may be a fractional-N synthesizer or a fractional N/N+6 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1506d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 1506d may be configured to synthesize an output frequency for use by the mixer circuitry 1506a of the RF circuitry 1506 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1506d may be a fractional N/N+6 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although this may not necessarily the case. Divider control input may be provided by either the baseband circuitry 1504 or the applications processor 1502 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 1502.

Synthesizer circuitry 1506d of the RF circuitry 1506 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+6 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 1506d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1506 may include an IQ/polar converter.

FEM circuitry 1508 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1560, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1506 for further processing. FEM circuitry 1508 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1506 for transmission by one or more of the one or more antennas 1560.

In some embodiments, the FEM circuitry 1508 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1506). The transmit signal path of the FEM circuitry 1508 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1506), and one or more filters to generate RF signals for subsequent

transmission (e.g., by one or more of the one or more antennas 1560.

In some embodiments, the electronic device 1500 may include additional elements such as, for example, memory/storage, display, camera, sensors, and/or input/output (I/O) interface. In some embodiments, the electronic device of Fig. 15 may be configured to perform one or more methods, processes, and/or techniques such as those described herein.

Fig. 16 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 16 shows a diagrammatic representation of hardware resources 1600 including one or more processors (or processor cores) 1610, one or more memory/storage devices 1620, and one or more communication resources 1630, each of which are communicatively coupled via a bus 1640.

The processors 1610 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1612 and a processor 1614. The memory/storage devices 1620 may include main memory, disk storage, or any suitable combination thereof.

The communication resources 1630 may include interconnection and/or network interface components or other suitable devices to communicate with one or more peripheral devices 1604 and/or one or more databases 1606 via a network 1608. For example, the communication resources 1630 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

Instructions 1650 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1610 to perform any one or more of the methodologies discussed herein. The instructions 1650 may reside, completely or partially, within at least one of the processors 1610 (e.g., within the processor's cache memory), the memory/storage devices 1620, or any suitable combination thereof. Furthermore, any portion of the instructions 1650 may be transferred to the hardware resources 1600 from any combination of the peripheral devices 1604 and/or the databases 1606. Accordingly, the memory of processors 1610, the memory/storage devices 1620, the peripheral devices 1604, and the databases 1606 are examples of computer-readable and machine-readable media.

A number of examples, relating to embodiments of the techniques described above, will next be given.

In a first example, an apparatus for an application processor of a network device, may comprise circuitry to: implement a non-3rd Generation Partnership Project (3GPP) Access Stratum (N3AS) protocol to enable a non-3rd Generation Partnership Project (3GPP) access network to connect to a core network (CN), of a wireless telecommunications network, via an access-independent interface, wherein, to implement the N3 AS protocol, the circuitry is to: enable an attach procedure between a UE, of the non-3GPP access network, and the CN by: exchanging, with the UE, messages, corresponding to the attach procedure, encapsulated in messages corresponding to a protocol of the non-3 GPP access network, and exchanging, with the CN and via the access-independent interface, the messages corresponding to the attach procedure, and cause a secure connection, for communicating information between the UE and the non-3 GPP access network, to be bootstrapped via the attach procedure.

In example 2, the subject matter of example 1, or any of the examples herein, the access- independent interface is terminated at the network device.

In example 3, the subject matter of example 1, or any of the examples herein, the messages corresponding to the attach procedure include Non Access Stratum (NAS) messages.

In example 4, the subject matter of example 1, or any of the examples herein, the N3AS protocol includes exchanging information for data bearers between the UE and the network device.

In example 5, the subject matter of example 1, or any of the examples herein, implementing the N3 AS protocol includes receiving key material from the core network and causing the key material to be used to establish the secure connection.

In example 6, the subject matter of example 1, or any of the examples herein, the secure connection includes a Datagram Transport Layer Security (DTLS) connection.

In example 7, the subject matter of example 1, or any of the examples herein, the non- 3GPP access network may include a Wireless Local Area Network (WLAN) that is operated by an organization that is different than that of the CN, and the UE connects to the CN via the WLAN.

In example 8, the subject matter of example 1, or any of the examples herein, to implement the N3 AS protocol, the circuitry is to inform the UE that the apparatus supports the CN.

In example 9, the subject matter of example 1, or any of the examples herein, to implement the N3 AS protocol, the circuitry is to: inform the UE that the apparatus supports the multiple CNs, and receive, from the UE, an indication of a particular CN, of the plurality of CNs, to which the UE is to be connected.

In a tenth example, a computer-readable medium may contain program instructions for causing one or more processors to enable a non-3rd Generation Partnership Project (3GPP) access network to connect to a core network (CN), of a plurality of CNs, of a wireless telecommunications network, via an access-independent interface that different types of access networks use to connect to any of the plurality of CNs, by: receiving, from the UE, an indication that the UE is to connect to a particular CN, of the plurality of CNs, communicating, with the UE, as part of an attach procedure between the UE and the particular CN, Non Access Stratum

(NAS) messages corresponding to the attach procedure and encapsulated in messages corresponding to a non-3 GPP protocol of the non-3 GPP access network, and communicating, with the particular CN, as part of the attach procedure and via the access-independent interface, the NAS messages corresponding to the attach procedure, causing a secure connection, for communicating information between the UE and the non-3 GPP access network, after the attach procedure is complete, to be bootstrapped via the attach procedure between the UE and the access point of the non-3 GPP access network.

In example 11, the subject matter of example 10, or any of the examples herein, a non- 3GPP Access Stratum (N3AS) protocol that enables an exchange information for data bearers between the UE and the non-3GPP access network, is bootstrapped via the attach procedure.

In example 12, the subject matter of example 10, or any of the examples herein, causing a secure connection to be established may include: receiving key material from the particular CN, and causing the key material to be used to establish the secure connection.

In example 13, the subject matter of example 10, or any of the examples herein, the secure connection includes a Datagram Transport Layer Security (DTLS) connection.

In a fourteenth example, a device of example 1 or a computer-readable medium of example 10, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

In a fifteenth example, a device of example 1 or a computer-readable medium of example 10, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

In a sixteenth example, a device of example 15 or a computer-readable medium of example 15, or any of the examples herein, the Internet Key Exchange version 2 (TKEv2) message include Extensible Authentication Protocol (EAP) messages with the message corresponding to the attach procedure.

In a seventeenth example, a device of example 15 or a computer-readable medium of example 15, or any of the examples herein, the messages corresponding to the attach procedure are carried directly as IKEv2 parameters.

In an eighteenth example, a device of example 1 or a computer-readable medium of example 10, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

In a nineteenth example, means for implementing a non-3rd Generation Partnership

Project (3GPP) Access Stratum (N3AS) protocol to enable a non-3rd Generation Partnership

Project (3 GPP) access network to connect to a core network (CN), of a wireless

telecommunications network, via an access-independent interface, wherein, to implement the

N3 AS protocol, the means for implementing includes: means for enabling an attach procedure between a UE, of the non-3GPP access network, and the CN by: exchanging, with the UE, messages, corresponding to the attach procedure, encapsulated in messages corresponding to a protocol of the non-3 GPP access network, and exchanging, with the CN and via the access- independent interface, the messages corresponding to the attach procedure, and means for causing a secure connection, for communicating information between the UE and the non-3 GPP access network, to be bootstrapped via the attach procedure.

In example 20, the subject matter of example 19, or any of the examples herein, the access-independent interface is terminated at the network device.

In example 21, the subject matter of example 19, or any of the examples herein, the messages corresponding to the attach procedure include Non Access Stratum (NAS) messages.

In example 22, the subject matter of example 19, or any of the examples herein, the

N3 AS protocol includes exchanging information for data bearers between the UE and the network device.

In example 23, the subject matter of example 19, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

In example 24, the subject matter of example 19, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

In example 25, the subject matter of example 24, or any of the examples herein, the messages corresponding to the attach procedure are carried directly as IKEv2 parameters.

In example 26, the subject matter of example 24, or any of the examples herein, the IKEv2 message include Extensible Authentication Protocol (EAP) messages with the message corresponding to the attach procedure.

In example 27, the subject matter of example 19, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Protocol for Carrying

Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

In example 28, the subject matter of example 19, or any of the examples herein, implementing the N3 AS protocol includes receiving key material from the core network and causing the key material to be used to establish the secure connection.

In example 29, the subject matter of example 19, or any of the examples herein, the secure connection includes a Datagram Transport Layer Security (DTLS) connection.

In example 30, the subject matter of example 19, or any of the examples herein, the non-

3GPP access network may include a Wireless Local Area Network (WLAN) that is operated by an organization that is different than that of the CN, and a UE may connect to the CN via the WLAN.

In example 31, the subject matter of example 19, or any of the examples herein, the means for implementing the N3 AS protocol may include means for informing the UE that the network device supports the CN.

In example 32, the subject matter of example 19, or any of the examples herein, the means for implementing the N3 AS protocol may include: means for informing the UE that the network device supports the multiple CNs, and means for receiving, from the UE, an indication of a particular CN, of the plurality of CNs, to which the UE is to be connected.

In a thirty-third example, A method, comprising: implementing, by a network device, a non-3rd Generation Partnership Project (3GPP) Access Stratum (N3AS) protocol to enable a non-3rd Generation Partnership Project (3GPP) access network to connect to a core network (CN), of a wireless telecommunications network, via an access-independent interface, wherein implementing the N3 AS protocol include: enabling an attach procedure between a UE, of the non-3 GPP access network, and the CN by: exchanging, with the UE, messages, corresponding to the attach procedure, encapsulated in messages corresponding to a protocol of the non-3 GPP access network, and exchanging, with the CN and via the access-independent interface, the messages corresponding to the attach procedure, and causing a secure connection, for communicating information between the UE and the non-3 GPP access network, to be bootstrapped via the attach procedure.

In example 34, the subject matter of example 33, or any of the examples herein, the access-independent interface is terminated at the network device.

In example 35, the subject matter of example 33, or any of the examples herein, the messages corresponding to the attach procedure include Non Access Stratum (NAS) messages.

In example 36, the subject matter of example 33, or any of the examples herein, the N3 AS protocol includes exchanging information for data bearers between the UE and the network device.

In example 37, the subject matter of example 33, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

In example 38, the subject matter of example 33, or any of the examples herein, messages of the protocol of the non-3GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

In example 39, the subject matter of example 38, or any of the examples herein, the messages corresponding to the attach procedure are carried directly as IKEv2 parameters.

In example 40, the subject matter of example 38, or any of the examples herein, the IKEv2 message include Extensible Authentication Protocol (EAP) messages with the message corresponding to the attach procedure.

In example 41, the subject matter of example 33, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

In example 42, the subject matter of example 33, or any of the examples herein, implementing the N3 AS protocol includes receiving key material from the core network and causing the key material to be used to establish the secure connection.

In example 43, the subject matter of example 33, or any of the examples herein, the secure connection includes a Datagram Transport Layer Security (DTLS) connection.

In example 44, the subject matter of example 33, or any of the examples herein, the non-

In example 45, the subject matter of example 33, or any of the examples herein, implementing the N3 AS protocol includes informing the UE that the network device supports the CN.

In example 46, the subject matter of example 33, or any of the examples herein, implementing the N3 AS protocol includes: informing the UE that the network device supports the multiple CNs, and receiving, from the UE, an indication of a particular CN, of the plurality of CNs, to which the UE is to be connected.

In a forty-seventh example, an apparatus for an application processor of a User

Equipment (UE), comprising circuitry to: communicate, to an access device of a non-3GPP access network, a request to connect to a particular core network (CN) of a plurality of CNs, of a wireless telecommunications network; communicate, with the access device, as part of an attach procedure between the UE and the particular CN, Non Access Stratum (NAS) messages corresponding to the attach procedure and encapsulated in messages corresponding to a non- 3GPP protocol of the non-3GPP access network; and enable a secure connection, for communicating information between the UE and the non-3 GPP access network, after the attach procedure is complete, to be bootstrapped via the attach procedure between the UE and the access point of the non-3 GPP access network.

In example 48, the subject matter of example 47, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Extensible Authentication

Protocol (EAP) messages communicated over a Layer-2 transport.

In example 49, the subject matter of example 47, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

In example 49, the subject matter of example 47, or any of the examples herein, messages of the protocol of the non-3 GPP access network include Protocol for Carrying

In example 50, the subject matter of example 47, or any of the examples herein, to enable the secure connection, the circuitry is to: derive security key information locally, and use the security information to complete a security exchange with the access device.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

For example, while series of signals may have been described with regard to one or more of Figs. 4-5, 9-10, and 12-13, the order of the signals may be modified in other embodiments. Further, non-dependent signals may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the embodiments illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code—it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Further, certain portions may be implemented as "logic" that performs one or more functions. This logic may include hardware, such as an application-specific integrated circuit ("ASIC") or a field programmable gate array ("FPGA"), or a combination of hardware and software.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.

Claims

WHAT IS CLAIMED IS:

1. An apparatus for an application processor of a network device, comprising circuitry to:

implement a non-3rd Generation Partnership Project (3GPP) Access Stratum

(N3AS) protocol to enable a non-3 rd Generation Partnership Project (3 GPP) access network to connect to a core network (CN), of a wireless telecommunications network, via an access-independent interface,

wherein, to implement the N3 AS protocol, the circuitry is to:

enable an attach procedure between a UE, of the non-3 GPP access network, and the CN by: exchanging, with the UE, messages, corresponding to the attach procedure, encapsulated in messages corresponding to a protocol of the non-3GPP access network, and exchanging, with the CN and via the access-independent interface, the messages corresponding to the attach procedure, and

cause a secure connection, for communicating information between the UE and the non-3 GPP access network, to be bootstrapped via the attach procedure.

2. The apparatus of claim 1 , wherein messages of the protocol of the non-3GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

3. The apparatus of claim 1 , wherein messages of the protocol of the non-3 GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

4. The apparatus of claim 3, wherein the Internet Key Exchange version 2 (IKEv2) message include Extensible Authentication Protocol (EAP) messages with the message corresponding to the attach procedure.

5. The apparatus of claim 3, wherein the messages corresponding to the attach procedure are carried directly as IKEv2 parameters.

6. The apparatus of claim 1 , wherein messages of the protocol of the non-3GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

7. The apparatus of any of claims 1, 2, or 6, wherein the access-independent interface is terminated at the network device.

8. The apparatus of any of claims 1, 2, or 6, wherein the messages corresponding to the attach procedure include Non Access Stratum (NAS) messages.

9. The apparatus of any of claims 1, 2, or 6, wherein the N3AS protocol includes exchanging information for data bearers between the UE and the network device.

10. The apparatus of any of claims 1, 2, or 6, wherein implementing the N3AS protocol includes receiving key material from the core network and causing the key material to be used to establish the secure connection.

1 1. The apparatus of any of claims 1, 2, or 6, wherein the secure connection includes a Datagram Transport Layer Security (DTLS) connection.

12. The apparatus of any of claims 1, 2, or 6, wherein:

the non-3 GPP access network may include a Wireless Local Area Network

(WLAN) that is operated by an organization that is different than that of the CN, and

the UE connects to the CN via the WLAN.

13. The apparatus of any of claims 1, 2, or 6, wherein, to implement the N3AS protocol, the circuitry is to:

inform the UE that the apparatus supports the multiple CNs, and

receive, from the UE, an indication of a particular CN, of the plurality of CNs, to which the UE is to be connected.

14. A computer-readable medium containing program instructions for causing one or more processors to:

enable a non-3rd Generation Partnership Proj ect (3GPP) access network to connect to a core network (CN), of a plurality of CNs, of a wireless telecommunications network, via an access-independent interface that different types of access networks use to connect to any of the plurality of CNs, by:

receiving, from the UE, an indication that the UE is to connect to a particular CN, of the plurality of CNs, communicating, with the UE, as part of an attach procedure between the UE and the particular CN, Non Access Stratum (NAS) messages corresponding to the attach procedure and encapsulated in messages corresponding to a non-3 GPP protocol of the non-3 GPP access network, and

communicating, with the particular CN, as part of the attach procedure and via the access-independent interface, the NAS messages corresponding to the attach procedure,

causing a secure connection, for communicating information between the UE and the non-3 GPP access network, after the attach procedure is complete, to be bootstrapped via the attach procedure between the UE and the access point of the non-3 GPP access network.

15. The computer-readable medium of claim 14, wherein messages of the protocol of the non-3 GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

16. The computer-readable medium of claim 14, wherein messages of the protocol of the non-3GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

17. The computer-readable medium of claim 14, wherein messages of the protocol of the non-3 GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

18. A network device, comprising:

means for implementing a non-3rd Generation Partnership Project (3GPP) Access

Stratum (N3AS) protocol to enable a non-3rd Generation Partnership Proj ect (3GPP) access network to connect to a core network (CN), of a wireless telecommunications network, via an access-independent interface,

wherein, to implement the N3 AS protocol, the means for implementing includes: means for enabling an attach procedure between a UE, of the non-3GPP access network, and the CN by:

exchanging, with the UE, messages, corresponding to the attach procedure, encapsulated in messages corresponding to a protocol of the non- 3 GPP access network, and exchanging, with the CN and via the access-independent interface, the messages corresponding to the attach procedure, and

means for causing a secure connection, for communicating information between the UE and the non-3GPP access network, to be bootstrapped via the attach procedure.

19. The network device of claim 18, wherein messages of the protocol of the non-3GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

20. The network device of claim 18, wherein messages of the protocol of the non-3GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

21. The network device of claim 18, wherein messages of the protocol of the non-3GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.

22. An apparatus for an application processor of a User Equipment (UE), comprising circuitry to:

communicate, to an access device of a non-3GPP access network, a request to connect to a particular core network (CN) of a plurality of CNs, of a wireless

telecommunications network,

communicate, with the access device, as part of an attach procedure between the UE and the particular CN, Non Access Stratum (NAS) messages corresponding to the attach procedure and encapsulated in messages corresponding to a non-3 GPP protocol of the non- 3 GPP access network; and

enable a secure connection, for communicating information between the UE and the non-3 GPP access network, after the attach procedure is complete, to be bootstrapped via the attach procedure between the UE and the access point of the non-3 GPP access network.

23. The apparatus of claim 22, wherein messages of the protocol of the non-3GPP access network include Extensible Authentication Protocol (EAP) messages communicated over a Layer-2 transport.

24. The apparatus of claim 22, wherein messages of the protocol of the non-3GPP access network include Internet Key Exchange version 2 (IKEv2) messages communicated over a Layer-3 transport.

25. The apparatus of claim 22, wherein messages of the protocol of the non-3GPP access network include Protocol for Carrying Authentication for Network Access (PANA) messages communicated over a Layer-3 transport.