WO2017099841A1

WO2017099841A1 - Providing different radio access networks independent, standardized access to a core network

Info

Publication number: WO2017099841A1
Application number: PCT/US2016/032914
Authority: WO
Inventors: Alexandre Stojanovski; Alexander Sirotkin; Muthaiah Venkatachalam
Original assignee: Intel IP Corporation
Priority date: 2015-12-09
Filing date: 2016-05-17
Publication date: 2017-06-15
Also published as: TW201724827A; TWI751118B

Abstract

A network device may enable a non-3GPP Radio Access Network (RAN) to communicate with a 3GPP Core Network (CN) via the same type of interface that 3GPP RANs use to communicate with the CN. The network device may function as an intermediary with respect to communications between the non-3GPP RAN and the CN. The network device may convert messages, originating from a UE connected to the non-3GPP RAN and carrying information intended for the CN, from a non-3GPP RAN protocol to a 3GPP RAN protocol. The network device may convert messages, originating from the CN and carrying information intended for a UE connected to the non-3GPP RAN, from the 3GPP RAN protocol to the non-3GPP RAN protocol. The network device may provide support services to User Equipment (UE) of the non-3GPP RAN, such as user plane bearer information, Quality of Service (QoS), etc.

Description

PROVIDING DIFFERENT RADIO ACCESS NETWORKS INDEPENDENT, STANDARDIZED

ACCESS TO A CORE NETWORK

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, the contents of which is 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 telecommunications 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 Telecommunications 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 or 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 require that an LTE network operate as an umbrella network in order to arrange (via a Radio Resource Control (RRC) connection between the UE and the LTE network) for the UE to connect to the CN via the 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)) that does not require the LTE umbrella network like LWA and LWIP; however, the GAN architecture introduces a new RAN-to-CN interface (referred to as a "Wm interface") that includes a secure tunnel between the GANC and the EPC. As such, since LTE networks communicate with CNs (e.g., the EPC) via an SI interface, implementing a GANC requires the CN to use different interfaces/protocols to communicate with different

URs/RANs.

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);

Figs. 3-6 are sequence flow diagrams of an example attach procedure between a User Equipment (UE) and a CN;

Fig. 7 is a diagram of a protocol stack that may be used to implement at least some of the techniques described herein;

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

Figs. 9 and 10 are flowcharts of an example process for enabling a UE of a non-3 GPP RAN to access a CN via a standardized communication interface; and

Fig. 11 illustrates, for one embodiment, example components of an electronic 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 enable a core network (CN), of a wireless telecommunications network, to use the same type of interface to communicate with different types of Radio Access Networks (RANs). For example, a wireless telecommunication network may include a RAN that implements the 3GPP Wireless Communications Standard in order to communicate with a core network (such as an Evolved Packet Core (EPC)). An example of a RAN that implements the 3 GPP Wireless Communications Standard may include a 3 GPP RAN (e.g., a Long-Term Evolution (LTE) RAN, a Fifth Generation (5G) RAN, etc.). As per the 3GPP Wireless Communications Standard, a 3GPP RAN may communicate with the core network using an interface referred to as the S I interface.

Implementing the techniques described herein may enable the wireless

telecommunications network to use the same type of interface (e.g., the S I interface) to communicate with other types of RANs (i.e., RANs that do not implement the 3GPP

Communication Standard). A RAN that does not implement the 3GPP Communication Standard may be referred to herein as a "non-3GPP RAN", an example of which may include a Wireless Local Area Network (WLAN) that implements the Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 Communication Standard (also referred to as Wi-Fi). To enable a non-3GPP RAN to use the same interface as a 3GPP RAN to communicate with a core network, the non-3GPP RAN may include a network device (referred to herein as a "non- 3 GPP Access Spectrum device" or "N3AS device").

The N3 AS device may operate as a communications intermediary between User Equipment (UE) within the non-3GPP RAN and the core network. For instance, the N3AS device may implement a new protocol (referred to herein as a non-3 GPP Access Stratum (N3 AS) protocol) that may enable the UE and the CN to communicate with one another using the same interface that the CN uses to communicate with 3GPP RANs (e.g., the S I interface). For example, the N3 AS protocol may cause the UE to encapsulate NAS messages within a protocol implemented by the non-3GPP RAN (e.g., the 802.1 1 Communication Standard). The NAS messages may be sent to the N3AS device, and the N3 AS device may convert the message to a protocol (e.g., the 3GPP Communication Standard) implemented by the CN before sending the messages to the CN. Similarly, the N3AS device may receive messages (e.g., NAS messages) from the CN and may covert the message to a protocol (e.g., the 802.1 1 Communication Standard) being implemented by the non-3GPP RAN before sending the messages to the UE. As such, a N3 AS device may operate as an intermediary device to enable a UE within a non-3 GPP RAN to communicate with a CN using the same protocol/interface that a 3GPP RAN would use to communicate with the CN.

As described herein, "non-3GPP" may refer to a communications standard (e.g., an IEEE communications standard) that is different than the communication standard implemented by a CN. In some implementations, "non-3GPP" may include a non-cellular network based communication standard. Additionally, 3GPP may refer to a communication standard implemented by the CN (e.g., a 3rd Generation (3G) communication standard, a 4th Generation (4G) communication standard, a 5th Generation (5G) communication standard, etc.). In some implementations, "3G)) may include a cellular network based communication standard.

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 telecommunications network with different RANs.

For example, the wireless telecommunications 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 RAN (e.g., a Wi-Fi WLAN). The CN may include an Evolved Packet Core (EPC) that operates based on the 3 GPP Communication Standard. However, it should be appreciated that the core network may include another type of core network that is capable of providing wireless telecommunication services to UEs 110. 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 implement a particular

communication standard, such as the 3 GPP Communication Standard (as available per the date of this application and/or as subsequently developed and implemented).

The 3GPP 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 RAN may include a non-3GPP access device 130 and/or a non-3GPP Access Stratum (N3AS) device 140, via which UEs 110 may communicate with the core network. While the LTE RAN is described as a RAN that implements the 3GPP Communication Standard and the non-3GPP RAN is described as a RAN that implements a Wi-Fi communication standard (e.g., the IEEE 802.11 Communication Standards), it should be appreciated that the techniques, described herein, may be applicable to different communication standards (including a version of the 3 GPP Communication Standards and/or the Wi-Fi Communication Standard 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 telecommunications 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 RAN) of the wireless telecommunications 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 using known 3GPP request and/or response messages, UE 110 may be capable of connecting to the EPC via the non-3 GPP RAN. For instance, UE 110 may communicate with

N3AS device 140 connect to the non-3GPP RAN using typical request and response messages that are consistent with a communication protocol (e.g., IEEE 802.11 messages) of the non-3GPP RAN; however, the request and response messages may have, encapsulated therein, request and response messages that are consistent with connecting to the CN.

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.

Non-3 GPP 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 (e.g., via an air interface). Non-3GPP 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, which may provide UE 110 with access to the EPC. In one example, non- 3GPP access device 130 may include a wireless router that implements IEEE 802.11

Communication Standards.

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 RAN (e.g., UE 110 and non-3GPP access device 130) and the CN. In some implementations, N3AS device 140 may receive messages, from non-3GPP access device 130, that are consistent with a communication protocol of the non-3GPP RAN (e.g., IEEE 802.11 Communication Standards) but that include, encapsulated therein, messages that are consistent with a communication protocol of the CN (e.g., the 3GPP Communication Standard). N3 AS device 140 may convert the messages from the protocol of the non-3GPP RAN to a protocol implemented by the CN (e.g., the 3GPP Communication Standard) and may communicate the messages to the CN using the same protocol/interface as the LTE RAN.

Similarly, N3 AS device 140 may receive messages from the CN that are intended for UE 110 of the non-3GPP RAN. The messages may be consistent with the communication protocol of the CN (e.g., the 3GPP Communication Standard). N3 AS device 140 may convert the messages to the protocol implemented by the non-3 GPP RAN and send the messages to the UE. As described below, N3 AS device 140 may covert the messages from the CN by encapsulating the messages (or the content thereof) within messages that are consistent with the protocol implemented by the non- 3 GPP RAN.

The quantity of devices and/or networks, illustrated in Fig. 1, is 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 Fig. 1. Alternatively, or additionally, one or more of the devices of system 100 may perform one or more functions described as being performed by another one or more of the devices of system 100. Furthermore, while "direct" connections are shown in Fig. 1 , 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. 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 could discussed above with reference to Fig. 1. The device of Fig. 2 may operate in a manner that is consistent with a protocol implemented by the CN, such as the 3 GPP Communication Protocol.

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 an LTE RAN and a non-3 GPP RAN, 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 e Bs 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 telecommunications network. For example, MME 230 may perform operations to register UE 110 with the wireless telecommunications 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 telecommunications 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 Fig. 2, is 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 Fig. 2. Alternatively, or additionally, one or more of the devices of system 100 may perform one or more functions described as being performed by another one or more of the devices of system 100. Furthermore, while "direct" connections are shown in Fig. 2, these connections should be interpreted as logical

Figs. 3-6 are sequence flow diagrams of an example attach procedure of a UE to a CN via non-3GPP RAN. As shown, the example attach procedure of Figs. 3-6 may include UE 1 10, non-3GPP access device 130, N3AS device 140, a control plane cloud, and HSS 240. The example devices and clouds shown in Figs. 3-6 are described above with reference to Figs. 1 and 2. The example attach procedure of Figs. 3-6 includes annotations of certain operations pertaining to "Standardized RAN-to-CN Interface/Messaging," which may indicate that because of the N3AS protocol and/or the functionality of N3AS device 140 (as described herein), UE 1 10 may be capable of connecting to the CN via the same interface that would be used by a 3GPP RAN (e.g., the S I interface of the 3GPP Communication Standard).

The example provided in Figs. 3-6 also includes reference to Extensible Authentication Protocol (EAP) operations, which may include various request messages and response messages (annotated as "EAP-REQ" and "EAP-RSP," respectively). EAP operations are intended to represent operations that may be specific to a type of non-3GPP protocol implemented by a non-3GPP RAN. As mentioned above, an example of a non-3GPP protocol may include the IEEE 802.1 1 Communication Standard; however, the techniques exemplified by the EAP operations described in Figs. 3-6 may be implemented using another type of non- 3GPP Communication Standards.

As shown, UE 1 10 may establish a connection with non-3 GPP access device 130

(block 310). The operations performed by UE 1 10 and non-3GPP access device 130, in order to establish the connection may depend on the type of RAN being implemented. For instance, when non-3GPP access device 130 includes a Wi-Fi router, UE 1 10 and non-3GPP access device 130 may perform operations that are consistent with the IEEE 802.1 1 Communication Standards.

In some implementations, UE 1 10 may send a query message (e.g., a Access Network Query Protocol (ANQP) message) to non-3GPP access device 130, regarding the capabilities of non-3GPP access device 130 and/or the WLAN of non-3GPP access device 130. For instance, UE 1 10 may inquire about whether non-3GPP access device 130 is capable of enabling UE 1 10 to connect to the CN of a wireless telecommunications network. In response, non-3GPP access device 130 may inform UE 1 10 that UE 1 10 may connect to the CN of a wireless telecommunications network via non-3GPP access device 130. In some implementations, this may cause UE 1 10 to communicate with non-3GPP access device 130 using one or more of the techniques described herein. For example, as described below, UE 1 10 may begin communicating with non-3GPP access device 130 using a N3 AS protocol that enables UE 1 10 to connect to the CN via N3 AS device 140. In some implementations, UE 1 10 may inform non-3 GPP access device 130 of the intention of UE 1 10 to connect to the CN. As such, the N3 AS protocol described herein may be dynamically bootstrapped into an Attach procedure between UE 1 10 and non-3 GPP access device 130 and/or UE 1 10 and the CN.

Non-3GPP access device 130 may send an EAP-REQ message regarding the identity of UE 1 10 (block 320). In accordance with the N3AS protocol described herein, UE 1 10 may respond by sending an EAP-RES message that includes the identity information requested by the EAP-REQ message. Additionally, or alternatively, the EAP-RES message may include (e.g., encapsulates) an Attach Request message. The Attach Request message may correspond to a particular message of a protocol/standard implemented by the CN. For example, the Attach Request message may include a [NAS] Attach Request message of the 3 GPP

Communication Standard.

Non-3 GPP access device 130 may respond to the EAP-RES message from UE 1 10 by sending an AAA Diameter message to N3AS device 140. An AAA Diameter message (or "Diameter message") may include a message of the Diameter protocol, which may correspond to the Authentication, Authorization, and Accounting (AAA) protocol. As described herein, AAA Diameter messages may extend the functionalities of the EAP protocol/messages and may be part of the N3 AS protocol. As shown, the AAA Diameter message include (e.g., encapsulate) the EAP-RES message from UE 1 10.

N3 AS 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 350). As shown, the Attach Request message may be part of a standardized RAN-to-CN messaging protocol, such as the 3GPP Communication Protocol. 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 360 and 370) with HSS 240, which may include the control plane cloud receiving an Authentication Key Argument (AKA) vector from HSS 240 (line 370). In response to the AIR message from HSS 240, the control plane cloud may derive keying material 380 (block 380) for UE 1 10.

Referring to Fig. 4, the control plane loud may continue the standardized RAN-to-CN messaging by sending a downlink (DL) NAS Transport message to N3AS device 140, which may include an Authentication Request message (line 410). The Authentication Request message may be a [NAS] Authentication Request message of the 3GPP Communication

Standard. In response, N3AS device 140 may send an AAA Diameter message to non-3GPP access device 130, which may include encapsulating the Authentication Request message in an EAP-REQ message (line 420). In turn, non-3 GPP access device 130 may send the EAP- REQ Authentication Request message to UE 1 10 (line 430). UE 1 10 may respond by generating an appropriate AKA vector (block 440) followed by sending an EAP-RSP message, which may include an Authentication Response message, to non-3 GPP access device 130 (line 450). The Authentication Response message may include a [NAS] Authentication Response message of the 3GPP Communication Standard.

As shown, non-3 GPP access device 130 may send another AAA Diameter message to N3 AS device 140, which may include the EAP-RES Authentication Response message originated by UE 1 10 (line 460). This may cause N3AS device 140 to send an uplink (UL) NAS Transport message to the control plane cloud of the CN (line 470). 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 RAN-to-CN messaging protocol (e.g., the 3GPP Communication Protocol).

Referring to Fig. 5, the control plane cloud may continue with the standardized RAN- to-CN message protocol. For example, the control plan cloud may verify the response originated by UE 1 10 (i.e., the Authentication Response message) and continue with the attachment procedure (block 510). The control plane cloud may send an Initial Context Setup Request message to N3AS device 140 (line 520). The Initial Context Setup Request message may include an Attach Accept message. The Attach Accept message may include a [NAS] Attach Accept message of the 3 GPP Communication Standard. N3 AS 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 530). Examples of N3ASF information may include information for enabling UE 1 10 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) of N3AS device 140, security information, etc.).

Non-3 GPP access device 130 may send the EAP-REQ message (with the Attach Accept message and the N3ASF information) to UE 1 10 (line 540). In turn, UE 1 10 may respond by sending an EAP-RSP message (that includes (e.g., encapsulates) an Attach

Complete message) to non-3GPP access device 130 (line 550). The Attach Complete message may include a [NAS] Attach Complete message of the 3 GPP Communication Standard.

Non-3 GPP access device 130 may send an AAA Diameter message that includes the EAP-RSP message and the Attach Complete message to N3AS device 140 (line 560). In response, N3AS device 140 may continue with the attach procedure using standardized RAN- 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 570).

Referring to Fig. 6, the control plane cloud may continue with the attach procedure using standardized RAN-to-CN messaging. For instance, the control plane cloud may operate to complete the CN side of the Attach procedure (block 610). Additionally, or alternatively, N3 AS device 140 may complete the UE side of the Attach procedure by sending an AAA Diameter message to non-3GPP access device 130, which may include an EAP-RSP Success message (line 620), and non-3GPP access device 130 may respond by sending the EAP-RSP Success message to UE 1 10 (line 630).

Fig. 7 is a diagram of a protocol stack that may be used to implement at least some techniques described herein. As shown, the protocol stack may correspond to

communications between UE 1 10 and N3 AS device 140 via a SUp interface. The protocol stack may include a N3 AS protocol layer, a Data Transport Layer Security (DTLS) layer, a UDP, an IP version 4 (IPv4) and IPv6 layer, and an IEEE 802.1 1 layer. In some

implementations, the N3AS protocol layer of Fig. 7 may include two primary functions. The first primary function may include that of a transparent and secure transport of additional NAS messaging, which may be performed in lieu of at least some RRC Direct Transfer procedures. The second primary function may include communicating information about user plane bearers (e.g., transport addresses, Quality of Service (QoS) information, etc.), which may be performed in lieu of at least some RRC Connection Reconfiguration procedures.

Fig. 8 is a diagram of an example network architecture that may be used to implement at least some of the techniques described herein. The network architecture, illustrated in Fig. 8, 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. 8. Additionally, the interface names/labels provided in Fig. 7 (e.g., Yl, Y2, Y3, NG2, NG3, etc.) are provided for explanatory purposes only. In practice, the devices shown in Fig. 8 may communicate via interfaces with different labels.

As shown, UE 1 10 may communicate with non-3GPP access device 130 via a Yl interface that may be based on the type of non-3GPP RAN being implemented. For instance, the Yl interface may include an IEEE 802.1 1 interface when the non-3GPP RAN is a Wi-Fi network. The non-3GPP 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 1 10 may communicate with N3AS device 140 via a Y3 interface that may implement some or all of the N3AS protocol (also referred to as the "non-3GPP RAN protocol connection) described herein. In some implementations, the N3 AS protocol may be functionally similar to the RRC protocol implemented by UTRANs; however, it should be noted that the N3AS protocol may have different and/or additional functions. For example, the N3AS protocol may be used for transparent transport of NAS messages between UE 1 10 and the CN, as well as for exchanging information for the user-plane bearers between UE 1 10 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 RAN, 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 1 10 is connecting to the CN via a Wi-Fi network, the CN may acknowledge that UE 1 10 may not require 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 since the UE cannot seamlessly transition (e.g., experience a handover) between Wi-Fi networks as the UE moves from one location to another.

N3AS device 140 may communicate with the control pane cloud via a NG3 interface. The NG3 interface may be similar to the S l-MME interface of an EPS. N3AS device 140 may communicate with the user pane cloud via a NG4 interface, which may be an interface that is similar to the S l-U interface of an EPS. The user plane cloud and the control plane cloud may communicate via an NG5 interface that may be similar to the Sxa, Sxb, and/or Sxc interface of the 3GPP technical report TR 23.714.

As used herein, a non-3 GPP RAN protocol may include a protocol that includes EAP to communicate 3 GPP Non-Access Stratum (NAS) messages (relating to an attachment procedures) between UE 1 10 and N3AS device 140. Additionally, or alternatively, EAP messages may be used by N3 AS device 140 to provide UE 1 10 with an IP address and a UDP port number of N3AS device 140, along with appropriate security information, in order to establish a non-3GPP Access Stratum (N3-AS) protocol connection between UE 1 10 and N3AS device 140. The N3-AS protocol connection (also referred to herein as a non-3GPP RAN protocol connection) may be used to relay NAS messages (that do not relate to an attachment procedure), information about data bearers, etc., between UE 1 10 and the CN and/or between UE 1 10 and N3AS device 140.

Figs. 9 and 10 are flowcharts of an example process 900 for enabling a UE of a non-3 GPP RAN to access a CN via a standardized communication interface. The example process of Figs. 9 and 10 may be implemented by N3AS device 140.

Referring to Fig. 9, process 900 may include receiving an EAP-RES message, originating from UE 1 10, which includes an Attach Request intended for a CN (block 910). For example, non-3GPP access device 130 may encapsulate an Attach Request, corresponding to a communication protocol implemented by a CN (e.g., the 3GPP Communication

Standards), within an EAP Response message. Additionally, non-3GPP access device 130 may send the EAP Response message to N3 AS device 140. Process 900 may also include generating a 3 GPP Attach Request message based on the EAP-RES message from UE 1 10 and sending the 3 GPP Attach Request message to CN (block 920). For instance, N3AS device 140 may extract the Attach Request message encapsulated in the EAP-RES message from UE 1 10 and send the Attach Request message to the CN. The Attach Request message may be part of a standardized form communication that the CN is designed to implement, such as the 3GPP Communication Standards.

As described above, the Attach Request message may initiate an Attach procedure with the CN, whereby UE 1 10 may establish a connection with the CN. Additionally, the 3GPP Attach Request message may include a [NAS] Attach Request message. Additionally, N3 AS device 140 may send the 3GPP Attach Request message to the CN via the same type of interface (e.g., an S I interface) that an eNB (or another type of 3GPP RAN device) would use to send an Attach Request message to the CN.

Process 900 may include receiving a 3 GPP Authentication Request from the CN and sending the Authentication Request to UE 1 10 (block 930). For example, in response to sending the 3 GPP Attach Request to the CN, N3 AS device 140 may receive a 3 GPP

Authentication Request message from the CN and may notify UE 1 10 of the Authentication Request message. As described above, N3AS device 140 may do so by sending an AAA Diameter message to UE 1 10 via non-3GPP access device 130. In some implementations, the 3GPP Authentication Request message may include a [NAS] Authentication Request message. Additionally, the CN may send the 3GPP Authentication Request to N3AS device 140 via the same type of interface (e.g., an S I interface) that the CN would use to send an Authentication Request message to an eNB or another type of 3 GPP RAN device.

Process 900 may include receiving an EAP-RES message, originating from UE 1 10, which includes an Authentication Response message (block 940). For example, N3AS device 140 may receive an AAA Diameter message, from non-3GPP access device 130, which includes an EAP-RES message that has an Authentication Response message encapsulated therein.

Process 900 may include generating a 3GPP Authentication Response message, based on the EAP-RES message and sending the 3 GPP Authentication Response message to the CN (block 950). For instance, N3AS device 140 may extract the Authentication Response message encapsulated within the EAP-RES message and create a 3 GPP Authentication

Response message from the content of the EAP-RES message. In some implementations, the 3GPP Authentication Response message may include a [NAS] Authentication Response message. Additionally, N3AS device 140 may send the 3GPP Attach Response message to the CN via the same type of interface (e.g., an S I interface) that an eNB (or another type of 3GPP RAN device) would use to send an Attach Response message to the CN.

Process 900 may include receiving a 3 GPP Attach Accept from the CN and sending the

Attach Accept and N3 AWSF information to UE 1 10 (block 960). For example, in response to sending the 3 GPP Authentication Response to the CN, N3AS device 140 may receive a 3 GPP Attach Accept message from the CN and may notify UE 1 10 of the Attach Accept message. As described above, N3AS device 140 may do so by sending an AAA Diameter message to UE 1 10 via non-3GPP access device 130.

As is also described above, the N3 AWSF information may include information to enable UE 1 10 to continue communicating with N3 AWS device 140 after UE 1 10 has successfully attached to the CN (e.g., an IP address of N3AWS device 140, a UDP of N3AS device 140, security information, etc.). In some implementations, the 3GPP Attach Accept message may include a [NAS] Attach Accept message. Additionally, the CN may send the 3GPP Attach Accept message to N3AS device 140 via the same type of interface (e.g., an S I interface) that the CN would use to send an Attach Accept message to an eNB or another type of 3GPP RAN device.

Referring now to Fig. 10, process 900 may include receiving an EAP-RES message, originating from UE 1 10, which includes an Attach Complete message (block 1010). For example, N3AS device 140 may receive an AAA Diameter message, from non-3GPP access device 130, which includes an EAP-RES message that has an Attach Complete message encapsulated therein.

Process 900 may include generating a 3 GPP Attach Complete message, based on the EAP-RES message and sending the 3 GPP Attach Complete message to the CN (block 1020). For instance, N3AS device 140 may extract the Attach Complete message encapsulated within the EAP-RES message and create a 3 GPP Attach Complete message from the content of the EAP-RES message. In some implementations, the 3GPP Attach Complete message may include a [NAS] Authentication Response message. Additionally, N3AS device 140 may send the 3GPP Attach Complete message to the CN via the same type of interface (e.g., an S I interface) that an eNB (or another type of 3GPP RAN device) would use to send an Attach Complete message to the CN. Process 900 may include notify UE of Attach Success via EAP-RSP message (block 1030). For example, N3AS device 140 may create an EAP-RSP message that includes an Attach Success message. The Attach Success message may notify UE 1 10 that UE 1 10 has successfully connected to the CN.

Process 900 may include communicating with UE 1 10 via N3 AS protocol and provide UE with Radio Resource Control support (block 1040). For instance, at some point after UE 1 10 has successfully connected to the CN, N3AS device 140 and UE 1 10 may communicate with one another via the N3AS protocol, which may involve the Y3 interface discussed above with reference to Fig. 8. Additionally, N3AS device 140 may provide UE 1 10 with Radio Resource Control support, which may include N3 AS device 140 and UE 1 10 communicating with respect to user plane bearers (e.g., transport address, QoS, etc.).

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. 11 illustrates, for one embodiment, example components of an electronic device 1100. In embodiments, the electronic device 1100 may be a UE, an eNB, a WLAN AP, or some other appropriate electronic device. In some embodiments, the electronic device 1100 may include application circuitry 1102, baseband circuitry 1104, Radio Frequency (RF) circuitry 1106, front-end module (FEM) circuitry 1108 and one or more antennas 1160, coupled together at least as shown. In other embodiments, any of said circuitries can be included in different devices.

The application circuitry 1102 may include one or more application processors. For example, the application circuitry 1102 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 1103 may include a non-transitory computer-readable medium. The memory/storage may include, for example, computer-readable medium 1103, which may be a non-transitory computer- readable medium. Application circuitry 1102 may, in some embodiments, connect to or include one or more sensors, such as environmental sensors, cameras, etc.

Baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1104 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 1 106 and to generate baseband signals for a transmit signal path of the RF circuitry 1106. Baseband processing circuitry 1104 may interface with the application circuitry 1102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1106. For example, in some embodiments, the baseband circuitry 1104 may include a second generation (2G) baseband processor 1104a, third generation (3G) baseband processor 1104b, fourth generation (4G) baseband processor 1104c, and/or other baseband processor(s) 1104d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 1104 (e.g., one or more of baseband processors 1104a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1106. 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 1104 may be associated with storage medium 1103 or with another storage medium.

In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1104 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1104 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 1104 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) 1104e of the baseband circuitry 1104 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) 1104f. The audio DSP(s) 1104f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 1104 may further include memory/storage 1104g. The

memory/storage 1104g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 1104. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 1104g 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 1104g 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 1104 and the application circuitry 1102 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1104 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1104 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 1104 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 1106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1106 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1106 may include a receive signal path which may include circuitry to down- convert RF signals received from the FEM circuitry 1108 and provide baseband signals to the baseband circuitry 1104. RF circuitry 1106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1104 and provide RF output signals to the FEM circuitry 1108 for transmission. In some embodiments, the RF circuitry 1106 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 1106 may include mixer circuitry 1106a, amplifier circuitry 1106b and filter circuitry 1106c. The transmit signal path of the RF circuitry 1106 may include filter circuitry 1106c and mixer circuitry 1106a. RF circuitry 1106 may also include synthesizer circuitry 1106d for synthesizing a frequency for use by the mixer circuitry 1106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1106a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1108 based on the synthesized frequency provided by synthesizer circuitry 1106d. The amplifier circuitry 1106b may be configured to amplify the down-converted signals and the filter circuitry 1106c 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 1104 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1106a 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 1106a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1106d to generate RF output signals for the FEM circuitry 1108. The baseband signals may be provided by the baseband circuitry 1104 and may be filtered by filter circuitry 1106c. The filter circuitry 1106c 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 1106a of the receive signal path and the mixer circuitry 1106a 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 1106a of the receive signal path and the mixer circuitry 1106a 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 1106a of the receive signal path and the mixer circuitry 1106a may be arranged for direct downconversion and/or direct upconversion,

respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a 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 1106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1104 may include a digital baseband interface to communicate with the RF circuitry 1106.

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 1106d 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 1106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase- locked loop with a frequency divider.

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

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1104 or the applications processor 1102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the applications processor 1102.

Synthesizer circuitry 1106d of the RF circuitry 1106 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 1106d 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 1106 may include an IQ/polar converter.

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

In some embodiments, the FEM circuitry 1108 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 1106). The transmit signal path of the FEM circuitry 1108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1160.

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

Fig. 12 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. 12 shows a diagrammatic representation of hardware resources 1200 including one or more processors (or processor cores) 1210, one or more memory/storage devices 1220, and one or more communication resources 1230, each of which are communicatively coupled via a bus 1240.

The processors 1210 (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 1212 and a processor 1214. The memory/storage devices 1220 may include main memory, disk storage, or any suitable combination thereof.

The communication resources 1230 may include interconnection and/or network interface components or other suitable devices to communicate with one or more peripheral devices 1204 and/or one or more databases 1206 via a network 1208. For example, the communication resources 1230 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 1250 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1210 to perform any one or more of the methodologies discussed herein. The instructions 1250 may reside, completely or partially, within at least one of the processors 1210 (e.g., within the processor's cache memory), the memory/storage devices 1220, or any suitable combination thereof. Furthermore, any portion of the instructions 1250 may be transferred to the hardware resources 1200 from any combination of the peripheral devices 1204 and/or the databases 1206. Accordingly, the memory of processors 1210, the memory/storage devices 1220, the peripheral devices 1204, and the databases 1206 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) Radio Access Network (RAN) protocol to communicate with a User Equipment (UE) connected to a non-3 GPP RAN; implement a 3 GPP RAN protocol to communicate with a 3 GPP core network (CN); and relay information between the UE and the 3GPP CN, via an access-independent RAN-to-CN interface, by: converting messages, originating from the UE and carrying information intended for the 3 GPP CN, from the non-3 GPP RAN protocol to the 3 GPP RAN protocol; and converting messages, originating from the 3 GPP CN and carrying information intended for the UE, from the 3 GPP RAN protocol to the non-3 GPP RAN protocol.

In example 2, the subj ect matter of example 1, or any of the examples herein, wherein the circuitry, in accordance with the non-3GPP RAN protocol, is to communicate 3GPP Non- Access Stratum (NAS) information related to an attachment procedure between the UE and the 3 GPP CN.

In example 3, the subj ect matter of example 1, or any of the examples herein, wherein the circuitry is to use Extensible Authentication Protocol (EAP) to provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3GPP RAN protocol connection between the network device and the UE.

In example 4, the subj ect matter of example 3, or any of the examples herein, wherein the circuitry is to use the non-3 GPP RAN protocol connection to carry information for data bearers in the non-3 GPP RAN.

In example 5, the subj ect matter of example 1, or any of the examples herein, wherein the non-3 GPP RAN protocol is implemented as part of an Attach procedure between the UE and the 3 GPP CN.

In example 6, the subj ect matter of example 1, or any of the examples herein, wherein the circuitry, in accordance with the non-3GPP RAN protocol, is to: receive a 3GPP Attach Request in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE, and receive a 3 GPP Attach Complete in a second EAP-RSP from the UE.

In example 7, the subj ect matter of example 1, or any of the examples herein, wherein the circuitry, in accordance with the non-3GPP RAN protocol, is to communicate a 3GPP Attach Accept, originating from the 3 GPP CN, to the UE, via an EAP Request (EAP-REQ).

In example 8, the subj ect matter of example 7, or any of the examples herein, wherein the EAP-REQ also includes an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3GPP RAN protocol connection between the network device and the UE.

In example 9, the subj ect matter of example 1, or any of the examples herein, wherein the circuitry is to: receive an inquiry message regarding the capabilities of the non-3GPP RAN; and notify the UE, in response to the inquiry message, that the UE may communicate with the 3 GPP CN via the non-3 GPP RAN.

In a tenth example, a computer readable medium containing program instructions for causing one or more processors to: enable a User Equipment (UE), connected to a non-3rd Generation Partnership Proj ect (3GPP) Radio Access Network (RAN), to connect to a core network (CN) of a wireless telecommunications network, via a standardized RAN-to-CN interface applicable to both 3 GPP RAN and non-3 GPP RANs of the wireless telecommunications network, by: converting messages, originating from the UE and carrying information intended for the CN, from the non-3 GPP RAN protocol to a 3 GPP protocol of the CN; and converting messages, originating from the CN and carrying information intended for the UE, from the 3 GPP protocol of the CN to the non-3 GPP RAN protocol.

In example 1 1, the subj ect matter of example 10, or any of the examples herein, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to: communicate 3GPP Non-Access Stratum (NAS) information, related to an attachment procedure, between the UE and the 3 GPP CN.

In example 12, the subj ect matter of example 10, or any of the examples herein, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to: use Extensible Authentication Protocol (EAP) to provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3 GPP RAN protocol connection between the network device and the UE.

In example 13, the subj ect matter of example 12, or any of the examples herein, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to: use the non-3 GPP RAN protocol connection to carry information for data bearers in the non-3 GPP RAN.

In example 14, the subj ect matter of example 10, or any of the examples herein, wherein the non-3GPP RAN protocol is implemented as part of an Attach procedure between the UE and the CN.

In example 15, the subj ect matter of example 10, or any of the examples herein, wherein the program instructions, in accordance with the non-3GPP RAN protocol, cause the one or more processors to: receive a 3 GPP Attach Request in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE, and receive a 3GPP Attach Complete in a second EAP-RSP from the UE.

In example 16, the subj ect matter of example 10, or any of the examples herein, wherein the program instructions, in accordance with the non-3GPP RAN protocol, cause the one or more processors to: communicate a 3 GPP Attach Accept, originating from the CN, to the UE, via an EAP Request (EAP-REQ).

In example 17, the subj ect matter of example 16, or any of the examples herein, wherein the EAP-REQ also includes and an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number associated with a device corresponding to the one or more processors, in addition to security information, to enable a non-3 GPP RAN protocol connection between the device corresponding to the one or more processors and the UE.

In example 18, the subj ect matter of example 1 or 10, or any of the examples herein, wherein the non-3 GPP RAN protocol connection is implemented on top of Datagram Transport Layer Security (DTLS) protocol.

In a nineteenth example, a network device may comprise means for implementing a non- 3rd Generation Partnership Project (3 GPP) Radio Access Network (RAN) protocol to communicate with a User Equipment (UE) of a non-3 GPP RAN; means for implementing a 3 GPP RAN protocol to communicate with a 3 GPP core network (CN); and means for relaying information between the UE and the 3 GPP CN, via an access-independent RAN-to-CN interface, by: converting messages, originating from the UE and carrying information intended for the 3 GPP CN, from the non-3GPP RAN protocol to the 3 GPP RAN protocol; and converting messages, originating from the 3 GPP CN and carrying information intended for the UE, from the 3 GPP RAN protocol to the non-3 GPP RAN protocol.

In example 20, the subj ect matter of example 19, or any of the examples herein, wherein the messages, originating from the UE and of the non-3GPP RAN protocol, include Extensible Authentication Protocol (EAP) messages with 3GPP Non-Access Stratum (NAS) information, related to an attachment procedure between the UE and the 3GPP CN, encapsulated therein.

In example 21, the subj ect matter of example 19, or any of the examples herein, wherein the means for relaying information includes: means for converting the message from the non-3 GPP RAN protocol to the 3 GPP RAN protocol by extracting Non-Access Stratum (NAS) information, related to an attachment procedure between the UE and the 3 GPP CN, encapsulated within Extensible Authentication Protocol (EAP) messages from the UE, and means for converting the message from the 3 GPP RAN to the non-3 GPP RAN by encapsulating NAS information, related to the attachment procedure and from the 3 GPP CN, within Extensible Authentication Protocol (EAP) messages.

In example 22, the subj ect matter of example 21 , or any of the examples herein, wherein NAS messages not related to the attachment procedure are communicated via the non-3GPP RAN protocol connection.

In example 23, the subject matter of example 19, or any of the examples herein, further comprising: means for receiving a 3 GPP Attach Request in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE; and a means for receiving a 3 GPP Attach Complete in a second EAP-RSP from the UE.

In example 24, the subject matter of example 19, or any of the examples herein, means for communicating, in accordance with the non-3 GPP RAN protocol, a 3 GPP Attach Accept, originating from the 3 GPP CN, to the UE, via an Extensible Authentication Protocol (EAP) Request (EAP-REQ).

In example 25, the subj ect matter of example 24, or any of the examples herein, wherein the EAP-REQ also includes an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3GPP RAN protocol connection between the network device and the UE.

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 Figs., 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 (3 GPP) Radio Access Network

(RAN) protocol to communicate with a User Equipment (UE) connected to a non-3 GPP RAN; implement a 3GPP RAN protocol to communicate with a 3GPP core network (CN); and

relay information between the UE and the 3 GPP CN, via an access-independent RAN- to-CN interface, by:

converting messages, originating from the UE and carrying information intended for the 3 GPP CN, from the non-3 GPP RAN protocol to the 3 GPP RAN protocol; and

converting messages, originating from the 3 GPP CN and carrying information intended for the UE, from the 3 GPP RAN protocol to the non-3 GPP RAN protocol.

2. The apparatus of claim 1, wherein the circuitry, in accordance with the non-3 GPP RAN protocol, is to communicate 3GPP Non-Access Stratum (NAS) information related to an attachment procedure between the UE and the 3 GPP CN.

3. The apparatus of claim 1, wherein the circuitry is to:

use Extensible Authentication Protocol (EAP) to provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3 GPP RAN protocol connection between the network device and the UE.

4. The apparatus of claim 3, wherein the circuitry is to:

use the non-3 GPP RAN protocol connection to carry information for data bearers in the non-3 GPP RAN.

5. The apparatus of claim 1, wherein the circuitry, in accordance with the non-3 GPP RAN protocol, is to:

receive a 3GPP Attach Request in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE, and receive a 3GPP Attach Complete in a second EAP-RSP from the UE.

6. The apparatus of claim 1, wherein the circuitry, in accordance with the non-3 GPP RAN protocol, is to: communicate a 3 GPP Attach Accept, originating from the 3 GPP CN, to the UE, via an Extensible Authentication Protocol (EAP) Request (EAP-REQ).

7. The apparatus of claim 6, wherein the EAP-REQ also includes an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3 GPP RAN protocol connection between the network device and the UE.

8. The apparatus of claim 1, wherein the circuitry is further to:

receive an inquiry message regarding the capabilities of the non-3GPP RAN; and notify the UE, in response to the inquiry message, that the UE may communicate with the 3 GPP CN via the non-3 GPP RAN.

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

enable a User Equipment (UE), connected to a non-3rd Generation Partnership Proj ect (3GPP) Radio Access Network (RAN), to connect to a core network (CN) of a wireless telecommunications network, via a standardized RAN-to-CN interface applicable to both 3GPP RAN and non-3GPP RANs of the wireless telecommunications network, by:

converting messages, originating from the UE and carrying information intended for the CN, from the non-3 GPP RAN protocol to a 3 GPP protocol of the CN; and

converting messages, originating from the CN and carrying information intended for the UE, from the 3 GPP protocol of the CN to the non-3 GPP RAN protocol.

10. The computer readable medium of claim 9, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to:

communicate 3GPP Non-Access Stratum (NAS) information, related to an attachment procedure, between the UE and the 3 GPP CN.

1 1. The computer readable medium of claim 9, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to:

use Extensible Authentication Protocol (EAP) to provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3 GPP RAN protocol connection between a network device, of the one or more processors, and the UE.

12. The computer readable medium of claim 9, wherein the program instructions cause the one or more processors to:

13. The computer readable medium of claim 9, wherein the program instructions, in accordance with the non-3 GPP RAN protocol, cause the one or more processors to:

communicate a 3GPP Attach Accept, originating from the 3GPP CN, to the UE, via an Extensible Authentication Protocol (EAP) Request (EAP-REQ).

14. The computer readable medium of claim 13, wherein the EAP-REQ also includes an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3GPP RAN protocol connection between the network device and the UE.

15. A network device as in claims 1 or 9, wherein the non-3GPP RAN protocol is implemented as part of an Attach procedure between the UE and the CN.

16. A network device as in claims 1 or 9, wherein the non-3GPP RAN protocol connection is implemented on top of Datagram Transport Layer Security (DTLS) protocol.

17. A network device, comprising:

means for implementing a non-3rd Generation Partnership Project (3GPP) Radio Access Network (RAN) protocol to communicate with a User Equipment (UE) connected to a non-3 GPP RAN;

means for implementing a 3 GPP RAN protocol to communicate with a 3 GPP core network (CN); and

means for relaying information between the UE and the 3 GPP CN, via an access- independent RAN-to-CN interface, by:

18. The network device of claim 17, further comprising:

means for communicating, in accordance with the non-3GPP RAN protocol, 3GPP Non-Access Stratum (NAS) information related to an attachment procedure between the UE and the 3 GPP CN.

19. The network device of claim 17, further comprising:

means for usING Extensible Authentication Protocol (EAP) to provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3GPP RAN protocol connection between the network device and the UE.

20. The network device of claim 17, wherein the messages, originating from the UE and of the non-3 GPP RAN protocol, include Extensible Authentication Protocol (EAP) messages with 3GPP Non-Access Stratum (NAS) information, related to an attachment procedure between the UE and the 3GPP CN, encapsulated therein.

21. The network device of claim 17, wherein the means for relaying information includes: means for converting the message from the non-3 GPP RAN protocol to the 3 GPP RAN protocol by extracting Non-Access Stratum (NAS) information, related to an attachment procedure between the UE and the 3GPP CN, encapsulated within Extensible Authentication Protocol (EAP) messages from the UE, and

means for converting the message from the 3 GPP RAN to the non-3 GPP RAN by encapsulating NAS information, related to the attachment procedure and from the 3 GPP CN, within Extensible Authentication Protocol (EAP) messages.

22. The network device of claim 21 , wherein NAS messages not related to the attachment procedure are communicated via the non-3 GPP RAN protocol connection.

23. The network device of claim 17, further comprises:

means for receiving a 3GPP Attach Request in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE; and

means for receiving a 3 GPP Attach Complete in a second EAP-RSP from the UE.

24. The network device of claim 17, wherein the means for relaying information includes: means for communicating, in accordance with the non-3GPP RAN protocol, a 3GPP

Attach Accept, originating from the 3 GPP CN, to the UE, via an Extensible Authentication Protocol (EAP) Request (EAP-REQ).

25. The network device of claim 24, wherein the EAP-REQ also includes an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the network device, in addition to security information, to enable a non-3 GPP RAN protocol connection between the network device and the UE.