TWI751118B - Providing different radio access networks independent, standardized access to a core network - Google Patents

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

Technology for providing independent, standardized access from different radio access networks to the core network

The present invention relates to techniques for providing independent, standardized access of different radio access networks to the core network.

Wireless telecommunications networks typically include a core network (CN) linked to multiple radio access networks (RANs) that enable user equipment (UE) such as smartphones, tablets, laptops, etc. to link to EN. An example of a wireless telecommunication network may include an Evolved Packet System (EPS) operating based on the 3rd Generation Partnership Project (3GPP) communication standard.

An EPS may include an Evolved Packet Core (EPC) network connected to one or more 3GPP RANs (eg, Long Term Evolution (LTE) RAN (also known as the Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E - UTRAN)", fifth generation (5G) RAN, etc.). LTE networks may each include a RAN with one or more base stations, some or all of which may be in the form of enhanced Node Bs (eNBs). LTE network and communicate with EPC network.

Current efforts to further develop wireless telecommunication networks include enabling UEs to connect to CNs (eg, EPCs) independently of the type of RAN used by the user equipment. For example, efforts are being made to build an infrastructure that enables UEs to connect to the EPC via 3GPP RAN or Wi-Fi networks. For example, LTE Wireless Local Area Network (WLAN) Aggregation (or LWA) and LTE-WLAN Integration Internet Protocol Secure Tunneling (LWIP) have been proposed to enable UEs to connect to the EPC. However, LWA and LWIP require the LTE network to operate as an umbrella network in order to arrange (through a Radio Resource Control (RRC) connection between the UE and the LTE network) the UE to connect to the CN through the Wi-Fi network.

In another example, a Wi-Fi router can communicate with a Generic Access Network (GAN) architecture to connect to the CN. The GAN architecture may include a controller device (commonly known as the GAN Controller (GANC)), which does not require an LTE umbrella network like LWA and LWIP; however, the GAN architecture introduces a new RAN-to-CN including a secure tunnel between the GANC and the EPC interface (referred to as the "Wm interface"). As such, since the LTE network communicates with the CN (eg, EPC) through the S1 interface, implementing GANC requires the CN to use a different interface/protocol to communicate with a different UR/RAN.

According to an embodiment of the present invention, an apparatus for an application processor of a network device is specifically proposed, which includes circuitry for implementing a non-3rd Generation Partnership Project (3GPP) radio access network ( RAN) protocol for communicating with a user equipment (UE) connected to a non-3GPP RAN; implementing a 3GPP RAN protocol for communicating with a 3GPP core network (CN); and through an access independent RAN-to-CN interface, relaying information between the UE and the 3GPP CN: converting messages originating from the UE and carrying information intended for the 3GPP CN from the non-3GPP RAN protocol to the 3GPP RAN protocol; and A message originating from the 3GPP CN and carrying information intended for the UE is converted from the 3GPP RAN protocol to the non-3GPP RAN protocol.

The following detailed description refers to the accompanying drawings. The same reference numbers in different figures 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 this disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the embodiments is defined by the appended claims and their equivalents.

The techniques described herein can be used to enable core networks (CNs) of wireless telecommunications networks to communicate with different types of radio access networks (RANs) using the same type of interface. For example, a wireless telecommunications network may include a RAN implementing the 3GPP wireless communication standard to communicate with a core network, such as Evolved Packet Core (EPC). Examples of RANs implementing 3GPP wireless communication standards may include 3GPP RANs (eg, Long Term Evolution (LTE) RANs, Fifth Generation (5G) RANs, etc.). According to the 3GPP wireless communication standard, the 3GPP RAN can communicate with the core network using an interface called the S1 interface.

Implementation of the techniques described herein may enable wireless telecommunications networks to communicate with other types of RANs (ie, RANs that do not implement 3GPP communication standards) using the same type of interface (eg, the S1 interface). RANs that do not implement 3GPP communication standards may be referred to herein as "non-3GPP RANs," examples of which may include wireless local area networks ( WLAN). To enable the non-3GPP RAN to communicate with the core network using the same interface as the 3GPP RAN, the non-3GPP RAN may include network devices (referred to herein as "non-3GPP access spectrum devices" or "N3AS devices").

The N3AS device may operate as a communication intermediary between user equipment (UE) and the core network that is not within the 3GPP RAN. For example, an N3AS device may implement a new protocol (referred to herein as a Non-3GPP Access Stratum (N3AS) protocol) that enables the UE and CN to use the same interface (eg, the S1 interface) that the CN uses to communicate with the 3GPP RAN communicate with each other. For example, the N3AS protocol may cause the UE to encapsulate NAS messages within a protocol (eg, the 802.11 communication standard) implemented by a non-3GPP RAN. NAS messages can be sent to the N3AS device, and the N3AS device can convert the messages to protocols implemented by the CN (eg, 3GPP communication standards) before sending the messages to the CN. Likewise, the N3AS device may receive messages (eg, NAS messages) from the CN and convert the messages to protocols implemented by non-3GPP RANs (eg, the 802.11 communication standard) before sending the messages to the UE. As such, the N3AS device may operate as an intermediary device to enable UEs inside a non-3GPP RAN to communicate with the CN using the same protocols/interfaces that the 3GPP RAN will use to communicate with the CN.

As described herein, "non-3GPP" may refer to a different communication standard (eg, an IEEE communication standard) than that implemented by the CN. In some embodiments, "non-3GPP" may include non-cellular network-based communication standards. In addition, 3GPP may refer to communication standards (eg, third generation (3G) communication standards, fourth generation (4G) communication standards, fifth generation (5G) communication standards, etc.) implemented by the CN. In some embodiments, "3G)) may include cellular network-based communication standards.

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

For example, a wireless telecommunications network may include a core network (CN) that is connected to a 3GPP RAN (eg, LTE RAN, 5G RAN, etc.) or a non-3GPP RAN (eg, Wi-Fi WLAN). The core network (CN) may include an Evolved Packet Core (EPC) operating based on the 3GPP communication standard. However, it should be understood that the core network may include another type of core network that can provide wireless telecommunication services to UE 110 . The CN may include a control plane cloud and a user plane cloud. Examples of devices that may be used to implement the plane cloud and user plane cloud are discussed below with reference to FIG. 2 . To implement a plane cloud and/or a user plane cloud, one or more of the devices depicted in Figure 2 may implement a specific communication standard, such as the 3GPP communication standard (as available on the filing date of this application and/or subsequently developed and implemented By).

The 3GPP RAN may be or may include one or more base stations (some or all of which may be eNBs 120) through which UEs 110 can communicate with the CN. The non-3GPP RAN may include non-3GPP access devices 130 and/or non-3GPP access stratum (N3AS) devices 140 through which UEs 110 may communicate with the core network. While the LTE RAN is described as a RAN implementing a 3GPP communication standard and a non-3GPP RAN is described as a RAN implementing a Wi-Fi communication standard (eg, the IEEE 802.11 communication standard), it should be understood that the techniques described herein can be applied to different communication standards ( Including future versions of 3GPP communication standards and/or Wi-Fi communication standards).

UE 110 may include portable computing and communication devices, such as personal digital assistants (PDAs), smart phones, cellular phones, laptops with connections to wireless telecommunication networks, tablet computers, and the like. UE 110 may also include non-portable computing devices, such as desktop computers, consumer or business appliances, or other devices capable of connecting to a RAN of a wireless telecommunications network (eg, LTE RAN and/or non-3GPP RAN) . UE 110 may also include computing and communication devices (also known as wearable devices) that may be worn by a user, such as watches, fitness bands, necklaces, eyeglasses, monocles, rings, belts, headsets, or other types of wearable devices .

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 through the LTE RAN using known 3GPP request and/or response messages, the UE 110 may be able to connect to the EPC through a non-3GPP RAN. For example, UE 110 may communicate with N3AS device 140 that connects to the non-3GPP RAN using typical request and response messages consistent with the communication protocol of the non-3GPP RAN (eg, IEEE 802.11 messages); however, the request and response messages may have Request and response messages consistent with linking to the CN are encapsulated therein.

The eNB 120 may include one or more network devices that receive, process, and/or transmit traffic destined to and/or received from the UE 110 over the air interface. The eNB 120 may be connected to a network device, such as a web router, which mediates the information communicated between the eNB 120 and the core network.

Non-3GPP 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 (eg, through an air interface). Non-3GPP access devices 130 may include network devices, such as gateways, routers, etc., capable of implementing policies and techniques for communicating information between UE 110 and N3AS device 140, which may provide UE 110 with an access EPC. In one example, the non-3GPP access device 130 may include a wireless router implementing the IEEE 802.11 communication standard.

N3AS device 140 may include one or more network devices, such as gateways, routers, etc., operable to communicate between non-3GPP RAN devices (eg, UE 110 and non-3GPP access device 130 ) and the core network mediation of information. In some embodiments, the N3AS device 140 may receive messages from the non-3GPP access device 130 that are consistent with the non-3GPP RAN protocol (eg, the IEEE 802.11 communication standard), but which include the communication protocol with the CN (eg, 3GPP communication standard) is encapsulated in it. The N3AS device 140 can convert the messages from non-3GPP RAN protocols to protocols implemented by the CN (eg, 3GPP communication standards), and can communicate the messages to the CN using the same protocols/interfaces as the LTE RAN.

Likewise, the N3AS device 140 may receive messages from the CN intended for the UE 110 of the non-3GPP RAN. These messages may conform to the CN's communication protocol (eg, the 3GPP communication standard). The N3AS device 140 can convert these messages to protocols implemented by the non-3GPP RAN and send the messages to the UE. As described in more detail below, the N3AS device 140 translates the messages from the CN by encapsulating the messages (or their contents) within messages consistent with protocols implemented by the non-3GPP RAN.

The numbers of devices and/or networks illustrated in FIG. 1 are for illustrative purposes only. In practice, there may be additional devices and/or networks than those illustrated in FIG. 1; fewer devices and/or networks; different devices and/or networks; or different arrangements of devices and/or networks. Additionally, or in addition, one or more of the devices of system 100 may perform one or more functions as performed by another or more of the devices of system 100 . Again, although "direct" links are shown in Figure 1, these links must be interpreted as logical communication paths, and in reality, there may be one or more intervening devices (eg, routers, gateways, modems) , switches, hubs, etc.).

FIG. 2 is a schematic diagram of an example of CN. The device depicted in FIG. 2 may be an example of a device used to implement the control plane cloud and user plane cloud discussed above with reference to FIG. 1 . The apparatus of Figure 2 may operate in a manner consistent with protocols implemented by the CN, such as the 3GPP communication protocol.

As shown, the CN may include an EPC including a Service Gateway (SGW) 210, a PDN Gateway (PGW) 220, a Mobility Management Entity (MME) 230, a Home Subscriber Server (HSS) 240, and/or Policy and Charging Rules Function (PCRF) 250. CNs can be connected to RANs, such as LTE RANs and non-3GPP RANs, and external networks, such as Public Land Mobile Network (PLMN), Public Switched Telephone Network (PSTN), and/or Internet Protocol (IP) networks (eg, the Internet).

The SGW 210 may aggregate traffic received from one or more eNBs 120 and may send the aggregated traffic through the PGW 220 to external networks or devices. 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 . The SGW 210 is operable as an anchor for the user plane during handover between eNBs and as an anchor for mobility between different telecommunication networks.

The MME 230 may include one or more computing and communication devices that act as a control node for the eNB 120 and/or other devices that provide an air interface to the wireless telecommunications network. For example, MME 230 may operate to register UE 110 with a wireless telecommunication network to establish bearer channels (eg, traffic flows) associated with UE 110's connection phase to hand off UE 110 to a different eNB , MME, or other networks, and/or perform other traffic policing operations. MME 230 may perform regulatory operations on traffic to and/or received from UE 110 .

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

HSS 240 may include one or more devices that may manage, update, and/or store profile information associated with users (eg, users associated with UE 110 ) in memory associated with HSS 240 . Profile information to identify approved and/or accessible applications and/or services by the user; mobile phone number (MDN) associated with the user; bandwidth or data rate thresholds associated with the application and/or service value; and/or other information. A user may be associated with UE 110 . Alternatively or additionally, the HSS 240 may perform authentication, authorization, and/or accounting operations associated with the user and/or the communication connection phase with the UE 110 .

PCRF 250 may receive information about policies and/or subscriptions from one or more sources, such as user databases and/or from one or more users. PCRF 250 may provide these policies to PGW 220 or other devices so that the policies can be enforced. As depicted, in several embodiments, PCRF 250 may communicate with PGW 220 to ensure that charging policies are properly applied to the local routing phase within the telecommunications network. For example, after the local routing connection phase ends, PGW 220 may collect charging information about the connection phase and provide the charging information to PCRF 250 for execution.

The numbers of devices and/or networks illustrated in FIG. 2 are for illustration purposes only. In practice, there may be additional devices and/or networks than those illustrated in FIG. 2; fewer devices and/or networks; different devices and/or networks; or different arrangements of devices and/or networks. Additionally, or in addition, one or more of the devices of system 100 may perform one or more functions as performed by another or more of the devices of system 100 . Again, although "direct" links are shown in Figure 2, these links must be interpreted as logical communication paths, and in reality, there may be one or more intervening devices (eg, routers, gateways, modems) , switches, hubs, etc.).

3-6 are sequence flow diagrams of example procedures for UE attaching to CN via non-3GPP RAN. As shown, the attach procedure examples of FIGS. 3-6 may include UE 110 , non-3GPP access device 130 , N3AS device 140 , control plane cloud, and HSS 240 . The device and cloud examples shown in FIGS. 3-6 are as previously described above with reference to FIGS. 1 and 2 . The attach procedure example of Figures 3-6 includes certain operational notes related to "Standardized RAN to CN Interface/Signaling", which may indicate that due to the N3AS protocol and/or the functionality of the N3AS device 140 (as described herein), the UE 110 may be able to connect to the CN through the same interface used by the 3GPP LTE standard (eg, the S1 interface of the 3GPP communication standard).

The examples provided in Figures 3-6 also include reference to Extensible Authentication Protocol (EAP) operations, which may include various request and response messages (labeled "EAP-REQ" and "EAP-RSP", respectively). EAP operations are intended to represent operations specific to the type of non-3GPP protocol implemented by the non-3GPP RAN. As previously mentioned, one example of a non-3GPP protocol may include the IEEE 802.11 communication standard; however, the techniques exemplified by the EAP operations described in Figures 3-6 may be implemented using other types of non-3GPP communication standards.

As shown, UE 110 may establish a connection with non-3GPP access device 130 (block 310). The operations performed by the UE 110 and the non-3GPP access device 130 to establish the connection may depend on the type of RAN implemented. For example, when the non-3GPP access device 130 includes a Wi-Fi router, the UE 110 and the non-3GPP access device 130 may perform operations consistent with the IEEE 802.11 communication standard.

In some embodiments, the UE 110 may send a query message (eg, an Access Network Query Protocol (ANQP) message) to the non-3GPP about the capabilities of the non-3GPP access device 130 and/or the WLAN of the non-3GPP access device 130 Access device 130 . For example, the UE 110 may inquire about whether the non-3GPP access device 130 is capable of enabling the UE 110 to connect to the CN of the wireless telecommunication network. In response, the non-3GPP access device 130 may notify the UE 110 of the CN that the UE 110 can connect to the wireless telecommunication network through the non-3GPP access device 130 . In several embodiments, this may enable UE 110 to communicate with non-3GPP access device 130 using one or more of the techniques described herein. For example, as described in more detail later, UE 110 may begin to communicate with non-3GPP access device 130 using the N3AS protocol, which enables UE 110 to connect to the CN through N3AS device 140 . In some embodiments, UE 110 may notify non-3GPP access device 130 that UE 110 intends to connect to the CN. As such, the N3AS protocol described herein can dynamically lead into the attach procedure between UE 110 and non-3GPP access device 130 and/or UE 110 and CN.

The non-3GPP access device 130 may send an EAP-REQ message regarding the identity of the UE 110 (block 320). According to the N3AS protocol described herein, UE 110 may respond by sending an EAP-RES message that includes the identity information requested by the EAP-REQ message. Alternatively or additionally, the EAP-RES message may include (eg, encapsulate) an attach request message. The attach request message may correspond to a specific message of the protocol/standard implemented by the CN. For example, the attach request message may include the 3GPP communication standard [NAS] attach request message.

The non-3GPP access device 130 may respond to the EAP-RES message from the UE 110 by sending an AAA Diameter message to the N3AS device 140 . The AAA Diameter message (or "Diameter message") may include a Diameter protocol message, which may correspond to an Authentication, Authorization, and Accounting (AAA) protocol. As described herein, the AAA Diameter message may extend the functionality of the EAP protocol/message and may be part of the N3AS protocol. As shown, the AAA Diameter message includes (eg, encapsulates) the EAP-RES message from UE 110 .

The N3AS device 140 may extract the Attach Request message from the AAA Diameter message, and send the Attach Request message to the CN's control plane cloud (line 350). As shown, the attach request message may be part of a standardized RAN-to-CN signaling protocol, such as the 3GPP communication standard. In other words, the N3AS device 140 may communicate with the CN (eg, the control plane cloud) in the same or similar manner that the eNB of the LTE network may communicate with the CN. In response to the Attach Request message, the control plane cloud may exchange Authentication Information Request (AIR) messages with the HSS 240 (lines 360 and 370 ), which may include the control plane cloud receiving an Authentication Key Argument (AKA) vector from the HSS 240 (line 370 ). ). In response to the AIR message from HSS 240, the control plane cloud may derive keying material 380 for UE 110 (block 380).

Referring to Figure 4, the control plane cloud may proceed to standardize RAN to CN signaling by sending a downlink (DL) NAS transfer 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 the packet authentication request message within an EAP-REQ message (line 420). The non-3GPP access device 130 may in turn send an EAP-REQ authentication request message to the UE 110 (line 430). UE 110 may then send an EAP-RSP message, which may include an authentication response message, to non-3GPP access device 130 (line 450) by generating an appropriate AKA vector response (block 440). The authentication response message may include the [NAS] authentication response message of the 3GPP communication standard.

As shown, the non-3GPP access device 130 may send another AAA Diameter message to the N3AS device 140, which may include an EAP-RES Authentication Response message originated by the UE 110 (line 460). This may cause the N3AS device 140 to send an uplink (UL) NAS transfer message to the CN's control plane cloud (line 470). As shown in the figure, the UL NAS transmission message may include an authentication response message. Additionally, the UL NAS transport messages may be part of a standardized RAN-to-CN signaling protocol (eg, 3GPP communication protocol).

Referring to Figure 5, the control plane cloud may continue to standardize the RAN to CN signaling protocol. For example, the control plane cloud may verify the response originated by the UE 110 (ie, the authentication response message) and continue the attach procedure (block 510). The control plane cloud may send an initial context setting request message to the N3AS device 140 (line 520). The initial context setting request message may include an attach accept message. The Attach Accept message may include a [NAS] Attach Accept message of the 3GPP communication standard.

The N3AS device 140 may respond to the request from the control plane cloud by sending an AAA Diameter message including an EAP-REQ message with an Attach Accept message. The EAP-REQ message may also include N3AS function (N3ASF) information (line 530). Examples of N3ASF information may include information used to enable the UE 110 to continue communicating with the N3AS device 140 after the attach procedure is complete (eg, the Internet Protocol (IP) address of the N3AS device 140 , the user data package protocol of the N3AS device 140 ) (UDP), security information, etc.).

The non-3GPP access device 130 may send an EAP-REQ message (with an attach accept message and N3ASF information) to the UE 110 (line 540). In turn, UE 110 may send an EAP-RSP message, which includes (eg, 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 3GPP communication standard.

The non-3GPP access device 130 may send an AAA Diameter message including the EAP-RSP message and the Attach Complete message to the N3AS device 140 (line 560). In response, the N3AS device 140 may continue the attach procedure using standardized RAN signaling to the CN. For example, as shown, N3AS device 140 may send an initial context setup response message (which includes an attach complete message) to the control plane cloud (line 570).

Referring to Figure 6, the control plane cloud may continue the attach procedure using standardized RAN signaling to the CN. For example, the control plane cloud is operable to complete the CN side of the attach procedure (block 610). Alternatively or additionally, the N3AS device 140 may complete the CN side of the attach procedure by sending an AAA Diameter message to the non-3GPP access device 130, which may include an EAP-RSP success message (line 620), and the non-3GPP access device 130 This may be responded by sending an EAP-RSP success message to UE 110 (line 630).

7 is a schematic diagram of a protocol stack that may be used to implement at least some of the techniques described herein. As shown in the figure, the protocol stack can correspond to the communication between the UE 110 and the N3AS device 140 through the SUp interface. The protocol stack may include the N3AS protocol layer, the Data Transport Layer Security (DTLS) layer, the UDP, IP version 4 (IPv4) and IPv6 layers, and the IEEE 802.11 layer. In some embodiments, the N3AS protocol layer of Figure 7 may include two main functions. The first major function may include additional transparent and secure transport functions for NAS signaling, which may be performed in place of at least part of the RRC direct transfer procedure. The second primary function may include communicating information about the user plane bearer (eg, transport address, quality of service (QoS) information, etc.), which may be performed in lieu of at least part of the RRC link reconfiguration procedure.

8 is a schematic diagram of an example of a network architecture that may be used to implement at least some of the techniques described herein. The network architecture illustrated in Figure 8 is for illustrative purposes only. In practice, there may be additional devices, networks, and/or interfaces; fewer devices, networks, and/or interfaces than those illustrated in FIG. 8; different devices, networks, and/or interfaces; or different Arranged devices, networks, and/or interfaces. Additionally, the interface names/designations (eg, Y1, Y2, Y3, NG2, NG3, etc.) provided in FIG. 7 are for illustrative purposes only. In practice, the devices shown in FIG. 8 can communicate through interfaces with different labels.

As shown, the UE 110 can communicate with the non-3GPP access device 130 through a Y1 interface based on the non-3GPP RAN type implemented. For example, when the non-3GPP RAN is a Wi-Fi network, the Y1 interface may include an IEEE 802.11 interface. The non-3GPP access device 130 can communicate with the N3AS device 140 through the Y2 interface, which can include any type of suitable wireless or wired connection (eg, an Ethernet interface).

UE 110 may communicate with N3AS device 140 through a Y3 interface that can implement some or all of the N3AS protocols described herein (also known as "non-3GPP RAN protocol links"). In some embodiments, the N3AS protocol may be similar in function to the RRC protocol implemented by the UTRAN; however, it should be noted that the N3AS protocol may have different and/or additional functions. For example, the N3AS protocol can be used for the transparent transfer of NAS messages between UE 110 and the CN, and for the exchange of user plane bearer information, including security information, between UE 110 and N3AS device 140 .

As described herein, transparent transmission may include the CN confirming that a particular UE is connected to the CN through a non-3GPP RAN, which may include the CN confirming that certain services (eg, certain RRC services) may not be available for the particular UE. For example, when the UE 110 is connected to the CN via a Wi-Fi network, the CN can confirm that the UE 110 may not need certain services/procedures, such as UE idle mode services, services related to transition between UE idle mode and UE connected mode , UE mobility service, UE messaging service, Tracking Area Update (TAU) service, 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, when connected to a Wi-Fi network, the UE may be considered in an infinite active mode (ie, not entering an idle mode). As another example, the UE may not need mobility services because the UE cannot seamlessly transition between Wi-Fi networks (eg, experience handover) when the UE moves from one location to another.

The N3AS device 140 can communicate with the control plane cloud through the NG3 interface. The NG3 interface may be an EPS-like S1-MME interface. The N3AS device 140 can communicate with the user plane cloud through the NG4 interface, which can be an EPS-like S1-U interface. The user plane cloud and the control plane cloud can communicate through the NG5 interface, which can be an Sxa, Sxb, and/or Sxc interface similar to 3GPP Technical Report TR 23.714.

As used herein, a non-3GPP RAN protocol may include a protocol that includes EAP for communicating 3GPP non-access stratum (NAS) messages between the UE 110 and the N3AS device 140 (related to attach procedures). Alternatively or additionally, the EAP message may be used by the N3AS device 140 to provide the UE 110 with the IP address and UDP port number of the N3AS device 140, along with appropriate security information, to establish a non-3GPP access layer between the UE 110 and the N3AS device 140 (N3-AS) protocol link. N3-AS protocol links (also referred to herein as non-3GPP RAN protocol links) may be used to relay NAS messages between UE 110 and CN and/or between UE 110 and N3AS device 140 (not related to the attach procedure), Information about the data carrier, etc.

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

Referring to FIG. 9, method 900 may include receiving an EAP-RES message from UE 110 that includes an attach request expected to be sent to the CN (block 910). For example, the non-3GPP access device 130 may encapsulate an attach request corresponding to a communication protocol (eg, 3GPP communication standard) implemented by the CN within an EAP response message. Additionally, the non-3GPP access device 130 may send an EAP response message to the N3AS device 140 .

The method 900 may also include generating a 3GPP Attach Request message based on the EAP-RES message from the UE 110, and sending the 3GPP Attach Request message to the CN (block 920). For example, the N3AS device 140 may extract the Attach Request message encapsulated in the EAP-RES message from the UE 110 and send the Attach Request message to the CN. The attach request message may be part of a standardized form of communication that the CN is designed to implement, such as the 3GPP communication standard.

As previously described, the attach request message may trigger an attach procedure with the CN, whereby the UE 110 may establish a connection with the CN. In addition, the 3GPP Attach Request message may include a [NAS] Attach Request message. Additionally, the N3AS device 140 may send the 3GPP Attach Request message to the CN through the same type of interface (eg, the S1 interface) that the eNB (or other type of 3GPP RAN device) will use to send an Attach Request message to the CN.

The method 900 may include receiving a 3GPP authentication request from the CN and sending the authentication request to the UE 110 (block 930). For example, in response to sending a 3GPP attach request to the CN, the N3AS device 140 may receive a 3GPP authentication request message from the CN and may notify the UE 110 of the authentication request message. As previously described, the N3AS device 140 may accomplish this by sending an AAA Diameter message to the UE 110 through the non-3GPP access device 130. In some embodiments, the 3GPP Authentication Request message may include a [NAS] Authentication Request message. Furthermore, the CN can send the 3GPP authentication request to the N3AS device 140 through the same type of interface (eg, S1 interface) that the CN will use to send an authentication request message to the eNB or other types of 3GPP RAN devices.

Method 900 may include receiving an EAP-RES message from UE 110 that includes an authentication response message (block 940). For example, the N3AS device 140 may receive a AAA Diameter message from the non-3GPP access device 130 that includes an EAP-RES message with an Authentication Response message encapsulated therein.

The method 900 may include generating a 3GPP authentication response message based on the EAP-RES message and sending the 3GPP authentication response message to the CN (block 950). For example, the N3AS device 140 may extract the authentication response message inside the encapsulated EAP-RES message and generate a 3GPP authentication response message from the content of the EAP-RES message. In some embodiments, the 3GPP Authentication Response message may include a [NAS] Authentication Response message. Additionally, through the same type of interface (eg, S1 interface) that the eNB (or other type of 3GPP RAN device) will use to send an Attach Response message to the CN, the N3AS device 140 may send the 3GPP Attach Response message to EN.

The method 900 may include receiving a 3GPP Attach Accept from the CN and sending the Attach Accept and N3AWSF information to the UE 110 (block 960). For example, in response to sending the 3GPP Authentication Response to the CN, the N3AS device 140 may receive a 3GPP Attach Accept message from the CN and may notify the UE 110 of the Attach Accept message. As previously described, the N3AS device 140 may accomplish this by sending an AAA Diameter message to the UE 110 through the non-3GPP access device 130 .

Also as before, the N3AWSF information may include information to enable the UE 110 to continue communicating with the N3AWS device 140 after the UE 110 has successfully attached to the CN (eg, IP address of the N3AWS device 140, UDP of the N3AS device 140, security information Wait). In some embodiments, the 3GPP Attach Accept message may include a [NAS] Attach Accept message. In addition, the CN may send the 3GPP Attach Accept message to the N3AS device 140 through the same type of interface (eg, the S1 interface) that the CN will use to send an Attach Accept message to the eNB or other types of 3GPP RAN devices.

Referring now to FIG. 10, method 900 may include receiving an EAP-RES message from UE 110 that includes an attach complete message (block 1010). For example, N3AS device 140 may receive an AAA Diameter message from non-3GPP access device 130 that includes an EAP-RES message with an Attach Complete message encapsulated therein.

The method 900 may include generating a 3GPP Attach Complete message based on the EAP-RES message and sending the 3GPP Attach Complete message to the CN (block 1020). For example, the N3AS device 140 may extract the Attach Complete message inside the encapsulated EAP-RES message and generate a 3GPP Attach Complete message from the content of the EAP-RES message. In some embodiments, the 3GPP Attach Complete message may include a [NAS] Authentication Response message. Additionally, through the same type of interface (eg, S1 interface) that the eNB (or other type of 3GPP RAN device) will use to send an attach complete message to the CN, the N3AS device 140 may send the 3GPP attach complete message to EN.

The method 900 may include notifying the UE of the successful attach via an EAP-RSP message (block 1030). For example, N3AS device 140 may generate an EAP-RSP message that includes an attach success message. The attach success message may inform the UE 110 that the UE 110 has successfully attached to the CN.

The method 900 may include communicating with the UE 110 via the N3AS protocol and providing radio resource control support to the UE (block 1040). For example, at some point after UE 110 has successfully connected to the CN, N3AS device 140 and UE 110 may communicate with each other via the N3AS protocol, which may involve the Y3 interface discussed above with reference to FIG. 8 . Additionally, N3AS device 140 may provide UE 110 with radio resource control support, which may include N3AS device 140 and UE 110 communicating with respect to user plane bearers (eg, transport address, QoS, etc.).

As used herein, the term "circuit" or "processing circuit" may refer to, be part of, or include application-specific integrated circuits (ASICs), electronic circuits, processors (shared, dedicated, or group), and/or or memory (shared, dedicated, or group) that executes one or more software or firmware programs, combinational logic circuits, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuit may be implemented in one or more software or firmware modules, or the related functions of the circuit may be implemented by such modules. In some embodiments, the circuit may include logic operable, at least in part, in hardware.

The embodiments described herein may be implemented as a system using any suitably configured hardware and/or software. FIG. 11 illustrates an example of components of an electronic device 1100 for one embodiment. In an embodiment, the electronic device 1100 may be a UE, an eNB, a WLAN AP, or some other suitable electronic device. In some embodiments, electronic device 1100 may include application circuit 1102, baseband circuit 1104, radio frequency (RF) circuit 1106, front-end module (FEM) circuit 1108, and one or more antennas 1160, coupled together at least as shown . In other embodiments, any of these circuits may be included in a different device.

The application circuit 1102 may include one or more application processors. For example, 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 special purpose processors (eg, graphics processors, application processors, etc.). A processor may be coupled to and/or may include a memory/storage device, and may be configured to execute instructions stored in the memory/storage device to enable applications and/or operating systems to run on the system. In some embodiments, storage medium 1103 may comprise a non-transitory computer-readable medium. The memory/storage device may include, for example, a computer-readable medium 1103, which may be a non-transitory computer-readable storage medium. In several embodiments, the application circuit 1102 may be coupled to or include one or more sensors, such as environmental sensors, cameras, and the like.

Baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuit 1104 may include one or more baseband processors and/or control logic for processing baseband signals received from the receive signal path of RF circuit 1106 and generating baseband signals for the transmit signal path of RF circuit 1106 . The baseband processing circuit 1104 can interface with the application circuit 1102 for generation and processing of baseband signals, and for control operations of the RF circuit 1106 . For example, in some embodiments, the baseband circuit 1104 may include a second generation (2G) baseband processor 1104a, a third generation (3G) baseband processor 1104b, a fourth generation (4G) baseband processor 1104c, and/or other baseband processors 1104d for other existing generations, developing generations, or future generations (eg, fifth generation (5G), 6G, etc.). Baseband circuitry 1104 (eg, one or more of baseband processors 1104a-d) may handle various radio control functions that enable it to communicate with one or more radio networks through RF circuitry 1106. Radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, baseband circuit 1104 may be associated with storage medium 1103 or with other storage mediums.

In some embodiments, the modulation/demodulation circuitry of the baseband circuit 1104 may include Fast Fourier Transform (FFT), precoding, and/or cluster mapping/de-mapping functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 1104 may include convolution, tail-biting convolution, turbo boost, Viterbi, and/or low density parity check (LDPC) encoder/decoder Features. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments. In several embodiments, baseband circuitry 1104 may include elements of a protocol stack such as elements of the 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. The central processing unit (CPU) 1104e of the baseband circuit 1104 may be configured to run a protocol stack of components for signaling at the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuit may include one or more audio digital signal processors (DSPs) 1104f. Audio DSP 1104f may include elements for compression/decompression and echo cancellation, and in other embodiments may include other suitable processing elements.

The baseband circuit 1104 may further include a memory/storage device 1104g. The memory/storage device 1104g may be used to load and store data and/or instructions for operations performed by the processor of the baseband circuit 1104 . For one embodiment, the memory/storage device may include any combination of desirable voltage-dependent memory and/or non-electronic memory. The memory/storage 1104g may include any combination of various levels of memory/storage including, but not limited to, read only memory (ROM) with embedded software instructions (eg, firmware), random access memory ( For example, dynamic random access memory (DRAM), cache memory, buffers, etc. Memory/storage 1104g may be shared among various processors or may be dedicated to a particular processor.

In some embodiments, the components of the baseband circuit can be conveniently combined on a single chip, a single chip set, or disposed on the same circuit board. In some embodiments, some or all of the constituent components of baseband circuit 1104 and application circuit 1102 may be implemented together, such as on a system-on-a-chip (SOC).

In some embodiments, baseband circuitry 1104 may provide for communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 1104 may support communication with E-UTRAN and/or other wireless metropolitan area networks (WMANs), WLANs, wireless personal area networks (WPANs). Embodiments in which the baseband circuit 1104 is configured to support radio communications of more than one wireless protocol may be referred to as a multimode baseband circuit.

RF circuitry 1106 may enable communication with wireless networks using modulated electromagnetic radiation via non-solid media. In various embodiments, RF circuitry 1106 may include switches, filters, amplifiers, etc. to facilitate communication with wireless networks. RF circuit 1106 may include a receive signal path, which may include circuitry to downconvert the RF signal received from FEM circuit 1108 and provide a baseband signal to baseband circuit 1104 . RF circuit 1106 may also include a transmit signal path, which may include circuitry to upconvert the baseband signal provided by baseband circuit 1104 and provide an RF output signal to FEM circuit 1108 for transmission.

In some embodiments, the RF circuit 1106 may include a receive signal path and a transmit signal path. The receive signal path of RF circuit 1106 may include mixer circuit 1106a, amplifier circuit 1106b, and filter circuit 1106c. The transmit signal path of RF circuit 1106 may include filter circuit 1106c and mixer circuit 1106a. The RF circuit 1106 may also include a synthesizer circuit 1106d for synthesizing a frequency for use by the mixer circuit 1106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 1106a of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 1108 based on the synthesized frequency provided by the synthesizer circuit 1106d. Amplifier circuit 1106b may be configured to amplify the down-converted signal, and filter circuit 1106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to convert the down-converted signal from The output fundamental frequency signal is generated by removing the undesired signal.

The output baseband signal may be provided to baseband circuit 1104 for further processing. In some embodiments, the output fundamental frequency signal may be a null frequency fundamental frequency signal, but it is not necessary. In some embodiments, the mixer circuit 1106a of the receive signal path may comprise a passive mixer, although the scope of embodiments is not limited in this respect.

In several embodiments, the mixer circuit 1106a of the transmit signal path may be configured to upconvert the incoming fundamental frequency signal based on the synthesis frequency provided by the synthesizer circuit 1106d to generate the RF output signal for the FEM circuit 1108. The baseband signal may be provided by baseband circuit 1104 and may be filtered by filter circuit 1106c. The filter circuit 1106c may include a low pass filter (LPF), although the scope of embodiments is not limited in this respect.

In some embodiments, the mixer circuit 1106a of the receive signal path and the mixer circuit 1106a of the transmit signal path may include two or more mixers and may be configured for quadrature down-conversion and/or up-conversion, respectively. In some embodiments, the mixer circuit 1106a of the receive signal path and the mixer circuit 1106a of the transmit signal path may include two or more mixers and may be configured for image carrier suppression (eg, Hartley) image carrier suppression). In some embodiments, mixer circuit 1106a and mixer circuit 1106a of the receive signal path may be configured for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, the mixer circuit 1106a of the receive signal path and the mixer circuit 1106a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, but the scope of the embodiments is not limited in this aspect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuit 1106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits, and baseband circuit 1104 may include a digital baseband interface in communication with RF circuit 1106 .

In several dual-mode embodiments, separate radio IC circuits may be provided for processing signals of each spectrum, but the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuit 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, the synthesizer circuit 1106d may be a sigma-delta synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

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

In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), but is not required. The divider control input may be provided by base frequency circuit 1104 or application circuit 1102 depending on the desired output frequency. In some embodiments, the divider control input (eg, N) may be determined from a look-up table based on the channel indicated by the application circuit 1102 .

The synthesizer circuit 1106d of the RF circuit 1106 may include a divider, a delay locked loop (DLL), a multiplier, and a phase accumulator. In some embodiments, the divider may be a dual modulo divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+6 (eg, based on a carry-out) to provide a fractional divide ratio. In some embodiments, the DLL may include a set of cascaded tunable delay elements, phase detectors, charge pumps, and D-type flip-flops. In these embodiments, delay elements can be configured to break a VCO cycle into Nd equal phase packets, 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, the synthesizer circuit 1106d may be configured to generate the carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (eg, twice the carrier frequency, four times the carrier frequency, etc.). multiples) and joint quadrature generator and divider circuits are used to generate multiple signals at the carrier frequency that have multiple different phases relative to each other. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 1106 may include an IQ/polarity converter.

FEM circuit 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 signal, and provide an amplified version of the received signal to RF circuitry 1106 for further processing. The FEM circuit 1108 may also include a transmit signal path, which may include circuitry configured to amplify the transmit signal provided by the RF circuit 1106 for transmission by one or more of the one or more antennas 1160 .

In some embodiments, the FEM circuit 1108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include a low noise amplifier (LNA) to amplify the received RF signal and provide the amplified received RF signal as an output (eg, to RF circuit 1106). The transmit signal path of FEM circuit 1108 may include a power amplifier (PA) to amplify the incoming RF signal (eg, provided by RF circuit 1106 ), and one or more filters to generate the RF signal for subsequent transmission (eg, by One or more of the one or more antennas 1160.

In some embodiments, the electronic device 1100 may include additional elements such as memory/storage devices, displays, cameras, sensors, and/or input/output (I/O) interfaces. 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.

12 is a block diagram illustrating the ability to read instructions from a machine-readable or computer-readable medium (eg, a machine-readable storage medium) and perform one or more of the methods discussed herein in accordance with several embodiments s component. In particular, FIG. 12 shows a representative diagram of a hardware resource 1200, which includes one or more processors (or processor cores) 1210, one or more memory/storage devices 1220, and one or more communication resources 1230, wherein Each of these are communicatively coupled through bus bar 1240 .

Processor 1210 (eg, central processing unit (CPU), reduced instruction set computer (RISC) processor, complex instruction set computer (CISC) processor, graphics processing unit (GPU), digital signal processor (DSP) such as baseband Processors, application specific integrated circuits (ASICs), radio frequency integrated circuits (RFICs), other processors, or any suitable combination thereof) may include, for example, processor 1212 and processor 1214 . Memory/storage 1220 may include main memory, disk storage, or any suitable combination thereof.

Communication resources 1230 may include interconnect and/or network interface components or other suitable means for communicating with one or more peripheral devices 1204 and/or one or more databases 1206 over network 1208 . For example, communication resources 1230 may include wired communication components (eg, for coupling via Universal Serial Bus (USB)), cellular communication components, near field communication (NFC) components, Bluetooth® components (eg, Bluetooth® low energy), Wi-Fi® components, and other communication components.

Instructions 1250 may comprise software, programs, applications, mini-applications, mobile phone applications, or other executables to cause at least any of processors 1210 to perform any one or more of the methods discussed herein code. Instructions 1250 may reside wholly or partially in any of processors 1210 (eg, within the processor's cache), memory/storage 1220, or any suitable combination thereof. Again, any portion of instructions 1250 may be transferred to hardware resource 1200 from any combination of peripherals 1204 and/or database 1206. Thus, the memory of processor 1210, memory/storage 1220, peripherals 1204, and database 1206 are examples of computer-readable and machine-readable media.

Next, various examples of technical embodiments described above will be described.

In a first example, an apparatus for an application processor of a network device may include circuitry for implementing a non-3rd Generation Partnership Project (3GPP) Radio Access Network (RAN) protocol for communicating with communicating with a user equipment (UE) connected to a non-3GPP RAN; implementing a 3GPP RAN protocol for communicating with a 3GPP core network (CN); and by accessing an independent RAN-to-CN interface in Relay information between the UE and the 3GPP CN: convert messages originating from the UE and carrying information intended for the 3GPP CN from the non-3GPP RAN protocol to the 3GPP RAN protocol; The CN and the message carrying the information intended for the UE are converted from the 3GPP RAN protocol to the non-3GPP RAN protocol.

In Example 2, the subject matter of Example 1 or any of the examples herein, wherein, according to the non-3GPP RAN protocol, the circuit is used to communicate a 3GPP non- 3GPP connection procedure related to an attach procedure between the UE and the 3GPP CN Access Layer (NAS) information.

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

In Example 4, the subject matter of Example 3 or any of the examples herein, wherein the circuitry is used to use the non-3GPP RAN protocol link to carry information for a data carrier in the non-3GPP RAN.

In Example 5, the subject matter of Example 1 or any of the examples herein, wherein the non-3GPP RAN agreement is implemented as part of an attach procedure between the UE and the 3GPP CN.

In Example 6, the subject matter of Example 1 or any of the examples herein, wherein according to the non-3GPP RAN protocol, the circuitry is to: receive from the UE in a first Extensible Authentication Protocol (EAP) response (EAP-RSP) a 3GPP Attach Request, and a 3GPP Attach Complete in a second EAP-RSP received from the UE.

In Example 7, the subject matter of Example 1 or any of the examples herein, wherein, according to the non-3GPP RAN protocol, the circuitry is to: via an Extensible Authentication Protocol (EAP) request (EAP-REQ) , communication originating from a 3GPP attachment of the 3GPP CN is received to the UE.

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

In Example 9, the subject matter of Example 1 or any of the examples herein, wherein the circuitry is to: receive a query message about the capabilities of the non-3GPP RAN; and, in response to the query message, notify the UE The UE can communicate with the 3GPP CN through the non-3GPP RAN.

In a tenth example, a non-transitory computer-readable medium containing program instructions for causing one or more processors to: cause linking to a non-3rd Generation Partnership Project (3GPP) radio interface by the following steps: A user equipment (UE) of a network (RAN) can connect to the wireless telecommunication network through a standardized RAN-to-core network (CN) interface that can be applied to both the 3GPP RAN and the non-3GPP RAN of a wireless telecommunication network A CN of the telecommunications network: converts messages originating from the UE and carrying information intended for the 3GPP CN from the non-3GPP RAN protocol to the 3GPP RAN protocol; and converting messages originating from the 3GPP CN and carrying A message with information expected to be sent to the UE is converted from the 3GPP RAN protocol to the non-3GPP RAN protocol.

In Example 11, the subject matter of Example 10, or any of the examples herein, wherein, according to the non-3GPP RAN agreement, the program instructions cause the one or more processors to: between the UE and the 3GPP CN 3GPP non-access stratum (NAS) information for communicating an attach procedure between them.

In Example 12, the subject matter of Example 10 or any of the examples herein, wherein, in accordance with the non-3GPP RAN protocol, the program instructions cause the one or more processors to: use an extensible authentication protocol ( EAP) is used, in addition to security information, to provide the UE with an Internet Protocol (IP) address and User Data Packet Protocol (UDP) port number of the network device to enable the network device to communicate with the UE. There can be a non-3GPP RAN protocol link between them.

In Example 13, the subject matter of Example 12 or any of the examples herein, wherein, according to the non-3GPP RAN protocol, the program instructions cause the one or more processors to: use the non-3GPP RAN protocol link to Information is carried for the data carrier in the non-3GPP RAN.

In Example 14, the subject matter of Example 10 or any of the examples herein, wherein the non-3GPP RAN agreement is implemented as part of an attach procedure between the UE and the CN.

In Example 15, the subject matter of Example 10 or any of the examples herein, wherein, according to the non-3GPP RAN agreement, the program instructions cause the one or more processors to: receive from the UE in a first A 3GPP Attach Request in an Extensible Authentication Protocol (EAP) response (EAP-RSP), and a 3GPP Attach Complete in a second EAP-RSP received from the UE.

In Example 16, the subject matter of Example 10 or any of the examples herein, wherein, according to the non-3GPP RAN protocol, the program instructions cause the one or more processors to: through an extensible authentication protocol (EAP) request (EAP-REQ), the communication originating from one of the CNs 3GPP attach is accepted to the UE.

In Example 17, the subject matter of Example 16 or any of the examples herein, wherein the EAP-REQ also includes, in addition to security information, an Internet Protocol (IP) of the UE the network device address and User Data Packet Protocol (UDP) port number to enable a non-3GPP RAN protocol connection between the network device and the UE.

In Example 18, the subject matter of Examples 1 or 10 or any of the examples herein, wherein the non-3GPP RAN protocol link is implemented on top of a Data Packet Transport Layer Security (DTLS) protocol.

In a 19th example, a network device may include implementing a non-3rd Generation Partnership Project (3GPP) radio access network (RAN) protocol for communicating with a user equipment (UE) connected to a non-3GPP RAN. ) communication means; means for implementing a 3GPP RAN protocol for communicating with a 3GPP core network (CN); and means for communicating between the UE and the Means of relaying information between 3GPP CNs: converting messages originating from the UE and carrying information intended for the 3GPP CN from the non-3GPP RAN protocol to the 3GPP RAN protocol; and converting the messages originating from the 3GPP CN and A message carrying information intended for the UE is converted from the 3GPP RAN protocol to the non-3GPP RAN protocol.

In Example 20, the subject matter of Example 19 or any of the examples herein, wherein the messages derived from the UE and the non-3GPP RAN agreement include with, an attachment between the UE and the 3GPP CN. Access-related, Extensible Authentication Protocol (EAP) messages in which 3GPP Non-Access Stratum (NAS) information is encapsulated.

In Example 21, the subject matter of Example 19 or any of the examples herein, wherein the means for relaying information comprises: for encapsulating in Extensible Authentication Protocol (EAP) by extracting from the UE 3GPP non-access stratum (NAS) information within the message related to an attach procedure between the UE and the 3GPP CN to convert the message from the non-3GPP RAN protocol to the component of the 3GPP RAN protocol.

In Example 22, the subject matter of Example 21 or any of the examples herein, wherein NAS messages not related to the attach procedure are communicated over the non-3GPP RAN protocol link.

In Example 23, the subject matter of Example 19 or any of the examples herein, further comprising: for receiving from the UE in a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) means for a 3GPP attach request; and means for receiving a 3GPP 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, is used to communicate via an Extensible Authentication Protocol (EAP) request (EAP-REQ) according to the non-3GPP RAN protocol from the A 3GPP attachment of the 3GPP CN accepts the components to the UE.

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

In the foregoing specification, various embodiments have been described with reference to the accompanying drawings. However, it will be evident that various modifications and changes may be made thereto, and additional embodiments may be practiced, without departing from the broader scope set forth in the following claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

For example, although the series of signals have been described with respect to one or more figures, the ordering of the signals may be modified in other embodiments. Also, non-dependent signals can be performed in parallel.

It will be apparent that the examples as described above are oriented towards implementation in many different forms of software, firmware, and hardware that may be embodied in the embodiments illustrated in the figures. However, the actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. As such, the operation and performance of these aspects are described without reference to specific software code - it being understood that software and control hardware may be designed to implement these aspects based on the descriptions herein.

Also, certain portions may be implemented as "logic" that performs one or more functions. Such 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 specific combinations of features are cited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. Indeed, many of these features may be combined in ways not specifically recited in the claims and/or not specifically disclosed in the specification.

No element, act, or instruction used in the present case should be construed as limiting or essential unless expressly described otherwise. As used herein, the use of the term "and" does not necessarily preclude the interpretation that the phrase "and/or" is intended to be used in that case. Likewise, as used herein, use of the term "or" does not necessarily preclude the interpretation that the phrase "and/or" is intended to be used in that instance. Also, as used herein, the article "a" is intended to encompass one or more items, and is used interchangeably with the phrase "one or more." When only one item is expected, the terms "a", "single", "only", or similar words are used.

100...Environment, System 110...User Equipment (UE) 120...Evolved Node B (eNB) 130...Non-3GPP Access Device 140...Non-3GPP Access Layer (N3AS) Device 210...Serving Gateway (SGW) 220...PDN Gateway (PGW) 230... Mobility Management Entity (MME) 240... Home Subscriber Server (HSS) 250... Policy and Charging Rules Function (PCRF) 310, 380, 440, 510, 610, 910-960, 1010 -1040...Blocks 320-370, 410-430, 450-470, 520-570, 620, 630...Lines 900...Methods 1100...Electronics 1102...Application Circuits 1103...Computer Readable Media 1104...Base Frequency Circuits 1104a... Second generation (2G) baseband processor 1104b...third generation (3G) baseband processor 1104b...fourth generation (4G) baseband processor 1104d...other baseband processor 1104e...central processing unit (CPU) 1104f ...audio digital signal processors (DSPs) 1104g, 1220...memory/storage devices 1106...radio frequency (RF) circuits 1106a...mixer circuits 1106b...amplifier circuits 1106c...filter circuits 1106d...synthesizer circuits 1108...front-end modules ( FEM) circuit 1160...antenna 1200...hardware resource 1204...peripheral device 1206...database 1208...network 1210, 1212, 1214...processor 1230...communication resource 1240...busbar 1250...command NG2-5, Y1-3... interface

Examples of this embodiment will be readily understood from the following detailed description in conjunction with the accompanying drawings. To aid in the description herein, similar reference numerals may designate similar structural elements. Embodiments will be illustrated by way of example and not by way of limitation in the figures of the accompanying drawings. Figure 1 is a schematic diagram illustrating an example of a system in which the systems and/or methods described herein may be implemented; Figure 2 is a schematic diagram of an example of a core network (CN); Figures 3-6 are between a user equipment (UE) and the CN Figure 7 is a schematic diagram of a protocol stack that can be used to implement at least part of the techniques described herein; Figure 8 is a schematic diagram of a protocol stack that can be used to implement at least part of the techniques described herein Schematic diagram of network architecture; Figures 9 and 10 are flowcharts of an example of a method for enabling UEs in non-3GPP RANs to access CN through standardized communication interfaces; and Figure 11 illustrates an example of electronic device components for one embodiment. 12 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium.

110‧‧‧User Equipment (UE)

120‧‧‧Evolved Node B (eNB)

130‧‧‧Non-3GPP Access Device

140‧‧‧N3AS device

Claims (19)

An apparatus for an application processor of an interworking network device, comprising circuitry for implementing a first protocol to connect to a non-third generation during an attach procedure Communicate with a User Equipment (UE) of a Partnership Project (3GPP) Radio Access Network (RAN); implement a 3GPP RAN protocol to communicate with a 3GPP Core Network (CN); and communicate via the UE to the CN After attaching, relaying information between the UE and the 3GPP CN through non-access stratum (NAS) signaling, wherein the attaching includes receiving an Extensible Authentication Protocol (EAP) response message ( EAP-RSP), the Extensible Authentication Protocol Response message carries a NAS message including an attach request; and transmits a first message to the control plane of the CN, the first message includes the attach request; and after an authentication exchange between the CN and the UE, receiving a second message from the CN, the second message carrying one of an attach accept a NAS message; and transmitting a third message to the UE, the third message including the attach acceptance to the UE. The apparatus of claim 1, wherein the circuit is used to: using Extensible Authentication Protocol (EAP) to, in addition to security information, provide the UE with an Internet Protocol (IP) address and User Datagram Protocol (UDP) port number of the interworking network device, to enable a non-3GPP RAN protocol connection between the interworking network device and the UE. The apparatus of claim 2, wherein the circuitry is used to: use the non-3GPP RAN protocol link to carry information for data bearers in the non-3GPP RAN. The apparatus of claim 1, wherein, according to the non-3GPP RAN protocol, the circuitry is to: attach a 3GPP originating from the 3GPP CN via an Extensible Authentication Protocol (EAP) request (EAP-REQ) Accept communication to the UE. The apparatus of claim 4, wherein the EAP-REQ also includes, in addition to security information, an Internet Protocol (IP) address and User Data Packet Protocol (UDP) port number of the interworking network device, to enable a non-3GPP RAN protocol connection between the interworking network device and the UE. The apparatus of claim 1, wherein the circuit is further configured to: receive a query message about capabilities of the non-3GPP RAN; and in response to the query message, notify the UE that the UE can communicate with the 3GPP CN through the non-3GPP RAN . A network device configured to implement a first protocol during an attach procedure with connection to a non- Communicate with a User Equipment (UE) of a 3rd Generation Partnership Project (3GPP) Radio Access Network (RAN); implement a 3GPP RAN protocol to communicate with a 3GPP Core Network (CN); and Following attachment of the CN, relaying information between the UE and the 3GPP CN through non-access stratum (NAS) signaling, wherein the attachment includes receiving an Extensible Authentication Protocol (EAP) response message ( EAP-RSP), the Extensible Authentication Protocol Response message carries a NAS message including an attach request; and transmits a first message to the control plane of the CN, the first message including the attach request; and in After an authentication exchange between the CN and the UE, receiving a second message from the CN, the second message carrying a NAS message including an attach acceptance; and transmitting a third message to the UE, the first message Three messages include the Attach Accept to the UE. The network device of claim 7, wherein the network device is for: using Extensible Authentication Protocol (EAP) to, in addition to security information, provide the UE with an internet protocol of the network device (IP) address and User Data Packet Protocol (UDP) port number to enable a non-3GPP RAN protocol connection between the network device and the UE. The network device of claim 8, wherein the network device Used to: use the non-3GPP RAN protocol link to carry information for the data carrier in the non-3GPP RAN. The network device of claim 7, wherein according to the non-3GPP RAN protocol, the network device is configured to: receive one of a first Extensible Authentication Protocol (EAP) Response (EAP-RSP) from the UE 3GPP Attach Request, and a 3GPP Attach Complete in a second EAP-RSP received from the UE. The network device of claim 7, wherein, according to the non-3GPP RAN protocol, the network device is to: via an Extensible Authentication Protocol (EAP) request (EAP-REQ), A 3GPP attachment accepts communication to the UE. The network device of claim 11, wherein the EAP-REQ also includes, in addition to the security information, an Internet Protocol (IP) address and User Data Packet Protocol (UDP) port number of the network device, to enable a non-3GPP RAN protocol connection between the network device and the UE. The network device of claim 7, wherein the network device is further configured to: receive a query message about capabilities of the non-3GPP RAN; and in response to the query message, notify the UE that the UE can communicate with the non-3GPP RAN through the non-3GPP RAN. The 3GPP CN communication. A method executed by an interworking network device method comprising: implementing a first protocol to communicate with a user equipment (UE) connected to a non-3rd Generation Partnership Project (3GPP) radio access network (RAN) during an attach procedure; implementing a 3GPP RAN agreement to communicate with a 3GPP core network (CN); and after attachment by the UE to the CN, signaling through the non-access stratum (NAS) to communicate between the UE and the 3GPP CN The following information, wherein the attaching includes: receiving an Extensible Authentication Protocol (EAP) Response message (EAP-RSP), the Extensible Authentication Protocol Response message carrying a NAS message including an attach request; and transmitting a a first message to the control plane of the CN, the first message including the attach request; and after an authentication exchange between the CN and the UE; receiving a second message from the CN, the second message carrying including a NAS message of an Attach Accept; and transmitting a third message to the UE, the third message including the Attach Accept to the UE. The method of claim 14, further comprising: using Extensible Authentication Protocol (EAP) to, in addition to security information, provide the UE with an Internet Protocol (IP) address of the interworking network device and User Data Packet Protocol (UDP) port number to enable a non-3GPP RAN protocol connection between the interworking network device and the UE. The method of claim 15, further comprising: using the non-3GPP RAN protocol link to carry information for the data carrier in the non-3GPP RAN. The method of claim 14, further comprising: communicating a 3GPP Attach Accept originating from the 3GPP CN to the non-3GPP RAN protocol via an Extensible Authentication Protocol (EAP) request (EAP-REQ) UE. The method of claim 17, wherein the EAP-REQ also includes, in addition to the security information, an Internet Protocol (IP) address and User Data Packet Protocol (UDP) port number of the interworking network device, to enable a non-3GPP RAN protocol connection between the interworking network device and the UE. The method of claim 14, further comprising: receiving a query message about the capabilities of the non-3GPP RAN; and in response to the query message, notifying the UE that the UE can communicate with the 3GPP CN through the non-3GPP RAN.

Images