HK1254125B - A network access identifier of cellular access network node based authentication method - Google Patents

Description

An authentication method based on a network access identifier of a cellular access network node

Background Art

Devices such as computers, handheld devices, or other types of devices can communicate over wired or wireless networks. Wireless networks can include cellular networks, which include cells and associated cellular access network nodes. Wireless devices within a cell can connect to corresponding cellular access network nodes to allow the devices to communicate with other devices.

Another type of wireless network is a wireless local area network (WLAN), which includes wireless access points that enable devices to connect wirelessly.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are described with respect to the following figures.

1A and 1B are diagrams of example network configurations that may incorporate techniques or mechanisms according to some embodiments.

2 is a message flow diagram of an example authentication process, according to some implementations.

3 is a message flow diagram of another example process according to further embodiments.

4A and 4B are block diagrams of example configurations for routing authentication messages between a user equipment (UE) and a home subscriber server (HSS) according to further embodiments.

5 is a message flow diagram of an example process between a cellular access network node and a control node according to some embodiments.

6 is a block diagram of a key derivation function according to some embodiments.

7A-7B are message flow diagrams of example cellular attach and security establishment procedures according to some embodiments.

8 is a block diagram of a sequence of key derivation functions according to some embodiments.

9 and 10 are block diagrams of example protocol layers in a cellular access network node in a wireless local area network according to some embodiments.

FIG. 11 is a block diagram of an example system according to some implementations.

DETAILED DESCRIPTION

FIG1A illustrates an example network configuration including a cellular network 102 and a wireless local area network (WLAN) 104. FIG1A also illustrates a user equipment (UE) 106 at a location within the coverage area of both the cellular network 102 and the WLAN 104. The UE 106 may be a dual-mode UE (or more generally, a multi-mode UE) capable of communicating with different types of radio access networks, which in the example of FIG1A include the cellular network 102 and the WLAN 104.

UE may refer to any of the following: computers (e.g., desktop computers, laptops, tablet computers, server computers, etc.), handheld devices (e.g., personal digital assistants, smartphones, etc.), wearable devices that can be worn on a person, computers embedded in vehicles or equipment, storage devices, communication nodes, etc.

The cellular network 102 may operate in accordance with the Long Term Evolution (LTE) standard (or other standards) provided by the Third Generation Partnership Project (3GPP). The LTE standard is also known as the Evolved Universal Terrestrial Radio Access (E-UTRA) standard. Although reference is made to LTE or E-UTRA in the subsequent discussion, it should be noted that techniques or mechanisms according to some embodiments may be applied to other wireless access technologies, such as 5G (fifth generation) technology.

The cellular network 102 includes a cellular access network node 108 that is capable of wirelessly communicating with the mobile device 106 via a cellular radio link 109. Although only one cellular access network node is depicted in FIG1A , it should be noted that the cellular network 102 may include multiple cellular access network nodes corresponding to respective cells of the cellular network 102. A cell may refer to a coverage area provided by a respective cellular access network node. A UE may move between cells and connect to a respective cellular access network node.

In an E-UTRA network, the radio access network node 108 may be implemented as an E-UTRAN Node B (eNB), which includes the functionality of a base station and a base station controller. In the subsequent discussion, the cellular access network node 108 may also be interchangeably referred to as an eNB 108. Although reference is made to an eNB in the subsequent discussion, it should be noted that the techniques or mechanisms according to the present disclosure may be applied to other types of cellular access network nodes operating according to other protocols.

The cellular network 102 also includes a core network, which includes various core network nodes. As an example, in an Evolved Packet System (EPS) cellular network, the core network nodes may include a Serving Gateway (SGW) 110 and a Packet Data Network Gateway (PDN-GW) 112. The PDN-GW 112 is an entry point and an exit point for data transmitted between a UE in an E-UTRA network and a Packet Data Network (PDN) 114 (e.g., the Internet or another network). The SGW 110 routes and forwards traffic data packets for the UE between the MeNB 108 and the PDN-GW 112. The SGW 110 may also serve as a mobility anchor point for the user plane during a handover process.

In an evolved packet system, the core network nodes may also include a control node called a mobility management entity (MME) 116. The MME 116 is a control node for performing various control tasks associated with the E-UTRA network. For example, the MME 116 may perform idle mode mobile device tracking and paging, bearer activation and deactivation, selection of a serving gateway when a mobile device initially attaches to the E-UTRA network, UE handover between eNBs, user authentication, generation and allocation of temporary identities to mobile devices, etc. In other examples, the MME 116 may perform other or alternative tasks.

The core network nodes may also include a Home Subscriber Server (HSS) 118, which is a master user database containing subscription-related information (subscriber profiles) and is used when performing authentication and authorization of users, as well as providing information about the user's location and the core network entity that is currently handling the user.

While connected to the cellular access network node 108, the UE 106 is able to communicate with other devices that may be connected to the cellular network 102 or to other networks including wired and/or wireless networks.

WLAN 104 includes a wireless access point (AP) 110. UE 106 can communicate with wireless AP 110 via a WLAN radio link 111. Although only one wireless AP is depicted in FIG1A , it is noted that WLAN 104 can include multiple wireless APs providing corresponding coverage areas. In some embodiments, WLAN 104 can operate according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. Note that a WLAN 104 operating according to the 802.11 standard can also be referred to as a Wi-Fi network. In other examples, WLAN 104 can operate according to different standards. It is worth noting that IEEE 802.11 also supports direct communication between terminal devices (e.g., between mobile devices). This direct communication (not through any AP) can be referred to as WLAN direct communication or Wi-Fi direct communication.

WLAN 104 can optionally be connected to an authentication, authorization, and accounting (AAA) server 120. AAA servers are used to perform access control, using authentication to identify users, authorization to implement policies that determine which network resources and services users can access, and accounting to track resources for billing and analytics purposes. An AAA server can refer to a node or collection of nodes that provides the services of an AAA server, or alternatively, an AAA server can refer to machine-readable instructions that provide the services of an AAA server.

Cellular network operators offering cellular networks in licensed spectrum are running out of new spectrum to purchase, and licensing available spectrum can be costly. Consequently, cellular network operators are seeking ways to expand cellular network capacity by offloading some user-plane traffic to WLAN. This allows UEs to connect to both the cellular network and WLAN simultaneously. Integrating WLAN into an LTE cellular network is known as LTE-WLAN aggregation. With LTE-WLAN aggregation, user-plane traffic can be sent by a UE to an eNB via WLAN, and user-plane traffic can be received by the UE from the eNB via WLAN.

In an LTE-WLAN aggregation architecture such as that shown in FIG1A , the eNB 108 may be referred to as a master eNB (MeNB), while the AP 110 in the WLAN 104 may be considered to provide a small cell to which the MeNB 108 may offload a portion of the user plane traffic.

1A shows an architecture in which an AP 110 is connected to a MeNB 108 via a link 122. FIG1B shows an alternative example configuration of an LTE-WLAN aggregation architecture in which multiple WLAN APs 110 (which are part of a WLAN 128) are connected via respective links 130 to a WLAN gateway 132, which in turn is connected to the MeNB 108 via a link 134.

Traditionally, WLAN and cellular networks have performed their own authentication processes to authenticate users of UEs attempting to access the WLAN or cellular networks, respectively. The authentication process used by WLAN is typically different from that used by cellular networks. If LTE-WLAN aggregation is employed, various issues associated with performing the authentication process may arise.

In the subsequent discussion, it is noted that the term "authentication process" can include only authentication tasks, or both authentication and authorization tasks. Authentication generally refers to authenticating a UE or a user of a UE attempting to access a network. In the subsequent discussion, reference is made to "authenticating the UE." It should be noted that authenticating the UE can refer to authenticating the identity of the UE or the identity of the user of the UE. Authorization can refer to implementing policies that determine which network resources and services a UE or a user of the UE can access.

In some cases, it may be necessary to use the WLAN authentication procedure in the context of LTE-WLAN aggregation. The first problem associated with using the WLAN authentication procedure in the context of LTE-WLAN aggregation (referred to as "Problem 1") is that core network signaling for performing the authentication procedure may have to be routed from the WLAN through the eNB to the cellular network of the core network. In some cases, as shown in Figures 1A and 1B, the only interface from the WLAN to the core network is through the eNB (e.g., MeNB 108). Specifying that the only interface into the core network is via the MeNB allows so-called "one network" operation, where a single core network is used to support and deliver traffic on both the licensed spectrum (of the LTE cellular network) and the unlicensed spectrum (of the WLAN).

The second issue (referred to as "Issue 2") is that in some cases, the WLAN may be connected to an AAA server (e.g., AAA server 120 in FIG. 1A ), while in other cases, the WLAN may not be connected to an AAA server. When the WLAN is connected to an AAA server, a conventional WLAN authentication process using the AAA server can be employed. However, when the WLAN is not connected to an AAA server, the authentication process can be performed by the MeNB. Therefore, depending on the specific configuration of the communication network, different operators may specify different authentication processes. Therefore, Problem 2 concerns how to inform the UE which authentication process to use.

The third problem (referred to as "Problem 3") is that it is desirable to reduce excessive signaling overhead when adding connectivity between the UE and the WLAN by avoiding additional interactions with the core network for the authentication process, when the authentication process signaling is routed through the MeNB. For Problem 3, it is desirable that the interaction with the LTE core network for the authentication process only occur when the UE is attached to the cellular network, and not when the UE is attached to the WLAN.

According to some embodiments of the present disclosure, various solutions are provided to address one or more of the aforementioned problems.

Routing authentication messages from WLAN to MeNB

According to some embodiments, the Network Access Identifier (NAI) is modified to include the identifier of a cellular access network node (e.g., an eNB), so that a WLAN node (such as a WLAN AP or WLAN gateway) sends authentication messages to a specific eNB (rather than an AAA server). The NAI refers to an identifier used to identify a user requesting access to a network. The NAI is described in Request for Comments (RFC) 7542, entitled "Network Access Identifier," dated May 2015.

Traditionally, the purpose of the NAI is to allow the WLAN to determine to which AAA server to send authentication messages. Another purpose of the NAI is to identify the user (subscriber) requesting authentication and authorization.

According to some embodiments of the present disclosure, a WLAN node may use a modified NAI (which includes an eNB identifier) to select an eNB (from among multiple eNBs) to send an authentication message. As described above, the eNB identifier may be a cell identifier for identifying a cell or an eNB identifier for identifying an eNB (or more generally, an identifier of a cellular access network node). An "identifier" may refer to any alphanumeric string, code, or any other information that can be used to identify an entity, such as a cell or cellular access network node as mentioned above.

FIG2 is a message flow diagram illustrating messages and tasks performed by various nodes, including UE 106, WLAN node 202 (e.g., AP 110 or WLAN gateway 132), and MeNB 108. According to FIG2 , to perform authentication, UE 106 may exchange messages with WLAN node 202 in accordance with the Extensible Authentication Protocol (EAP), an authentication framework that supports a variety of authentication techniques known as EAP technologies. EAP is described in RFC 3748, entitled "Extensible Authentication Protocol (EAP)," published in June 2004. While reference is made to EAP in some examples, it should be noted that in other examples, authentication messages between UE 106 and WLAN node 202 may be in accordance with other authentication protocols.

UE 106 sends (at 204) an EAP over LAN (EAPOL)-Start message to WLAN node 202. The EAPOL-Start message is a multicast message sent to a multicast group that UE 106 uses to determine whether an authenticator (more specifically, WLAN node 202 that can operate as an authenticator) exists. In response to the EAPOL-Start message, WLAN node 202 sends (at 206) an EAP-Request/Identification message to UE 106. The identification string of the EAP-Request message contains the identification of WLAN node 202.

In response to the EAP-Request/Identity message, the UE 106 sends (at 208) an EAP-Response/Identity message, where the identity string in the EAP-Response/Identity message may include a modified NAI according to some embodiments discussed above. Examples of NAIs that may be included in the identity string of the EAP-Response message are as follows:

user@MeNB1.O2.co.uk.

In the example NAI above, "user" may be an International Mobile Subscriber Identity (IMSI) used to identify the user (subscriber) of UE 106. In other examples, other user identifiers may be employed. The string "O2.co.uk" identifies the domain of the cellular operator operating the cellular network (e.g., O2), while the string "MeNB1" in the NAI identifies a specific eNB or a cell of a specific eNB, in this case, MeNB 108. In another example, the string identifying the domain of the cellular network operator may be as described in 3GPP TS 23.003 and may take the form of, for example, wlan.mnc015.mcc234.3gppnetwork.org, where the mnc015.mcc234 portion of the string provides a reference to a cellular operator subscription provider with a mobile network code of 015 and a mobile country code of 234.

As described in 3GPP TS 23.003, the NAI may also include an additional string (herein referred to as Auth_type) to indicate to the WLAN the type of authentication to be performed. For example, if a "0" is placed at the beginning of the NAI, this indicates that EAP-AKA authentication will be used, while a "1" indicates that EAP-SIM authentication will be used. The additional string may be added to the NAI to indicate the method by which the WLAN expects to interact with other network elements to complete the authentication process, and specifically whether authentication messages are transmitted between the WLAN and a cellular access node or between the WLAN and an AAA server. Alternatively, a new value of the existing authentication type identification string described in 3GPP TS 23.003 may be defined to indicate the type of EAP method and the type of method used to transmit authentication messages between the WLAN and other network nodes. While a specific example NAI is provided, it should be noted that in other examples, NAIs according to other formats may be employed, wherein such NAIs according to such other formats may also include an identifier of a cellular access network node (such as MeNB 108).

After receiving the identification string in the EAP response message, the WLAN node 202 parses (at 210) the identification string to identify the eNB that will be used to perform the authentication process. In the example according to FIG2 , the identified eNB is the MeNB 108.

WLAN node 202 then sends (at 212) an authentication message to the identified MeNB 108. The authentication message sent by WLAN node 202 to MeNB 108 may include an identification string, which may be the NAI received by WLAN node 202, or alternatively, a modified version of the NAI (e.g., with the substring "MeNB1" removed). In some embodiments, the authentication message sent (at 212) may perform authentication and authorization according to a protocol. In some examples, such a protocol may be the Remote Authentication Dial-In User Service (RADIUS) protocol, which is a networking protocol used to provide AAA management for users connecting to and using network services. RADIUS is described in RFC 2865, entitled "Remote Authentication Dial-In User Service (RADIUS)," published in June 2000. In other examples, the authentication message (sent at 212) may be according to the Diameter base protocol, such as described in RFC 6733, entitled "Diameter Base Protocol," published in October 2012. In further examples, other authentication protocols may be employed.

In response to receiving the authentication message sent at 212, the MeNB 108 may autonomously perform authentication in response to the authentication message, or alternatively, the MeNB 108 may act as an authentication agent and include an authentication server (such as the HSS 118 shown in FIG. 1A ) for performing the authentication process. The authentication challenge may be issued based on the NAI in the authentication message.

In response to the authentication message sent at 212, the MeNB 108 sends (at 214) an authentication challenge to the WLAN node 202. In some examples, the authentication challenge is a RADIUS Access-Challenge message according to the RADIUS protocol. In other examples, the authentication challenge can be according to a different protocol, such as the Diameter-based protocol or other protocols. More generally, an authentication challenge can refer to any message sent to elicit a response from a target node, where the response is used to authenticate the target node.

In response to the authentication challenge (sent at 214 ), the WLAN node 202 sends (at 216 ) the authentication challenge to the UE 106 , where the authentication challenge may be an EAP-Request/Challenge message.

UE 106 responds to the authentication challenge by sending (at 218) an authentication challenge response, which in some examples may be an EAP-Response/Challenge message. In response to the authentication challenge response, WLAN node 202 sends (at 220) an authentication challenge response to MeNB 108. In some examples, the authentication challenge response sent by WLAN node 202 to MeNB 108 may be a RADIUS Access-Request (Challenge Response) message, or may be a message according to a different protocol.

In response to the authentication challenge response from the WLAN node 202, the MeNB 108 sends (at 222) an Access Accept to the WLAN node 202. In some examples, the Access Accept may be a RADIUS Access-Accept message, or an Access Accept according to a different protocol.

In response to receiving the Access Accept message from MeNB 108, WLAN node 202 indicates (at 224) that UE 106 is authenticated and that access to the WLAN is granted to UE 106. At this point, WLAN opens the 802.1X controlled port of the WLAN, which effectively enables traffic (including, for example, IP traffic) other than just EAP messages to be transmitted between the UE and the cellular network. In response, WLAN node 202 sends (at 226) a success indication, such as an EAP-Success message or some other message. A further exchange of messages (at 228) may be performed between UE 106 and WLAN node 202 to generate encryption keys.

There are many ways to obtain the identifier of the eNB at the UE 106. As an example, any or some combination of the following may be performed:

• The UE derives the eNB identifier (ID) based on other network identifiers such as cell ID, Public Land Mobile Network (PLMN) ID, etc.

• The eNB derives an ID identifying the routable path between the WLAN node and the eNB, and transmits the derived ID to the UE, for example by using a dedicated Radio Resource Control (RRC) message.

• For the purpose of WLAN aggregation in the system information broadcast message, the eNB signals the routable eNB ID.

In other examples, other techniques for deriving an identifier for the eNB may be used.

Examples of modified NAIs according to the present disclosure are provided below, where the identifier of the eNB is underlined in each example NAI.

For example, two types of NAIs may be specified, as described in 3GPP TS 23.003. The first type of NAI is a root NAI, while the second type of NAI is a modified NAI.

The root NAI is the type of NAI used by a UE when attempting authentication on a network that has direct access to the AAA server of the user's home subscription provider. The root NAI can be of the form: Username@realm, where username can be derived from the IMSI and realm can be derived from the subscription provider's Mobile Network Code (MNC) and Mobile Country Code (MCC), which together provide the PLMN code.

A modified NAI is used if authentication messages (e.g., EAP messages) must be routed via another AAA server (in "otherrealm") than the AAA server of the user's home subscription provider. For example, a UE may be roaming in a visited PLMN (VPLMN) and want to use WLAN services provided by the VPLMN; as a result, authentication messages to the AAA server must first be routed to the VPLMN and then to the home PLMN (HPLMN). The modified NAI may have the following form: homerealm!username@otherrealm.

Listed below are the various options for the modified NAI.

Option 1 (Root NAI realm includes cell ID)

According to option 1, the identifier of the eNB contained in the root NAI (underlined text) is the cell ID. An example of such a root NAI is presented below:

Auth_type<Identity_desc>@wlan. cellid523768193 .mnc015.mcc234.3gppnetwork.org

In this root NAI, the underlined text is the cell ID of the cell of the MeNB to which the UE is connected. The cell ID (cellid523768193 in the example) is added to the NAI domain of the root NAI, where the NAI domain in this example is the portion of the string following the @ symbol. The cell ID is globally unique when referenced relative to a specific PLMN code. A WLAN node can, for example, perform a lookup on this domain to obtain the IP address of the MeNB. For example, the lookup can be a Domain Name System (DNS) lookup on a DNS server. Alternatively, the lookup can be a table statically configured at the WLAN node. If the eNB provides multiple cells, note that all cell IDs of these multiple cells can be expected to result in a domain that resolves to the same (eNB) IP address.

In the case where only eNBs associated with only one PLMN are attached to the WLAN, the MNC/MCC may not need to be included in the NAI. However, to cover the possibility of WLAN network sharing scenarios, it is recommended to retain the MNC/MCC in the NAI in some embodiments.

Option 2 (Root NAI field includes eNB identifier)

According to option 2, the identifier of the eNB contained in the root NAI (underlined text) is the eNB ID. An example of such a root NAI is presented below:

Auth_type<Identity_desc>@wlan. enbid83456789 .mnc015.mcc234.3gppnetwork.org

In this root NAI, the underlined text is the eNB ID (enbid83456789 in this example) that uniquely identifies the eNB and is included in the domain of the root NAI. In some examples, the eNB ID may be provided by the eNB to the UE using an RRC message (or other message). The eNB ID may be derived by the eNB; for example, the eNB identifier may be set to the cell ID of an arbitrarily selected sector within the eNB. The eNB ID may include any ID that can uniquely identify the eNB for the purpose of IP routing of AAA messages from WLAN nodes to the eNB. It is possible that the eNB ID may be derived from the IP address of the eNB on the IP network that connects the eNB to the WLAN. Note that such an eNB ID is not currently used in conventional E-UTRAN communications and may therefore be specified as an additional information element (IE) in an RRC message or other message.

Option 3 (Modify the NAI field to include the cell ID)

If the UE is cellular roaming on a VPLMN, a modified NAI may be used (e.g., for situations where the MeNB in the VPLMN must forward the EAP message to the AAA server on the HPLMN, such as in the solution where the MeNB acts as an authentication proxy, discussed further below in the "MeNB as an Authentication Proxy" section). The modified NAI includes two fields, the first field appearing in the string is the domain of the home network subscription provider, and the second field appearing in the string is the domain of the operator through which the AAA message will be routed.

An example of a modified NAI according to option 3 including the cell ID (underlined text) is provided below.

wlan.mnc015.mcc234.3gppnetwork.org! Auth_type<Identity_desc>@ wlan.cel lid523768193.mnc071.mcc610.3gppnetwork.org .

Option 4 (modify the NAI field to include eNB ID)

An example of a decorated NAI according to Option 4 containing the eNB ID (underlined text) is provided below:

wlan.mnc015.mcc234.3gppnetwork.org! Auth_type<Identity_desc>@wlan. enb id83456789 .mnc071.mcc610.3gppnetwork.org

Options for signaling UE identity

In each of the above example NAIs according to options 1-4, the "Identity_desc" string represents an identifier corresponding to the UE. Examples of identifiers may include the following:

Identifiers known to the LTE core network, such as:

o International Mobile Subscriber Identity (IMSI), which is an identifier of a user or subscriber associated with the UE, or

o Globally Unique Temporary Identifier (GUTI), which is a temporary identifier generated to identify the UE.

An identity known to the LTE eNB (called the "Radio Access Network Identity"), such as:

o Radio Network Temporary Identity (RNTI), which is a temporary identifier of the UE assigned to the UE by the radio access network in an RRC message, or

o WLAN MAC address, which identifies the UE's WLAN interface and may be exchanged between the UE and the eNB during cellular attach.

In other examples, other identifiers corresponding to the UE may be used.

Since in some of the solutions described herein, the eNB can handle the authentication process autonomously (without access to the HSS/AAA server or core network), it is possible to use a radio access network identity (e.g., RNTI or MAC address). In addition, the eNB may be able to map the RNTI or MAC address to a core network identity. For privacy reasons, a temporary identity may be used.

During the process of configuring the UE for LTE-WLAN aggregation, the MeNB may provide the UE with an "Identity_desc" string (representing the identifier corresponding to the UE) and an optional new eNB_Identifier (identifier of the eNB) using an RRC message (e.g., an RRC connection reconfiguration "RRCConnectionReconfiguration" command), as shown in FIG3 .

3 , UE 106 transmits (at 302) measurement results that include measurements of signals transmitted by various wireless access nodes, such as MeNB 108 and WLAN AP 110. The measurement results are transmitted to MeNB 108 and may indicate that LTE-WLAN aggregation may be performed (e.g., the strength or power of the signal from WLAN AP 110 measured by the UE is above a specified threshold).

In response to determining that LTE-WLAN aggregation can be performed, MeNB 108 sends (at 304) a control message to UE 106, where the control message includes the eNB_Identifier to be included in the identification string for EAP authentication, as discussed above in conjunction with FIG2. In some examples, the control message (sent at 304) can include an RRC connection reconfiguration "RRCConnectionReconfiguration" command.

3 corresponds to messages 204, 206, and 208, respectively, in FIG2. In the EAP-Response/Identity message sent at 310, the identification string includes the eNB_Identifier sent by MeNB 108 in the RRCConnectionReconfiguration command sent at 304.

In some examples, the following changes may be made to 3GPP TS 36.331 (changes are underlined).

RRC connection reconfiguration "RRCConnectionReconfiguration"

The RRC Connection Reconfiguration message is a command to modify the RRC connection. It can convey the following information: measurement configuration, mobility control, radio resource configuration (including resource blocks (RBs), MAC primary configuration and physical channel configuration), as well as any associated dedicated non-access stratum (NAS) information and security configuration.

Signaling Radio Bearer: SRB1

RLC-SAP:AM

Logical Channel DCCH

Direction: E-UTRAN to UE

RRC Connection Configuration message

Indication provided by the network to use WLAN-LTE aggregation type authentication

In some embodiments, to address issue 2 discussed further above, the network (such as MeNB 108) may provide an indication to the UE as to which of multiple authentication procedures the UE should use to gain access to WLAN resources when the UE operates in LTE-WLAN aggregation mode.

The UE may select between using a first type of authentication procedure, in which authentication messages are routed between the WLAN node and the cellular access network node (e.g., MeNB 108), and a second type of authentication procedure, in which authentication messages are routed between the WLAN node and the AAA server (e.g., 120 in FIG. 1A ).

The first type authentication procedure may include any of the various techniques discussed herein, including using a modified NAI (which includes an identifier of the eNB) as described above, and/or generating and using keys, as discussed further below.

The second type of authentication process is a traditional authentication procedure (such as Wi-Fi Protected Access (WPA2) from the Wi-Fi Alliance) between a WLAN node and an AAA server to gain access to WLAN resources.

In some example embodiments, an RRC message may be used by the network to inform the UE of the type of authentication procedure that the UE should apply.

The indication of the type of authentication procedure to be used may be explicit.Such an explicit indication may be included in an RRCConnectionReconfiguration command that may be used to configure the use of a WLAN-based small cell.

For example, the following information element (IE) may be added to the RRCConnectionReconfiguration command:

WLANAuthenticationType IE (enumeration value: AAA routing, eNB routing, ...)

If the WLANAuthenticationType IE is set to the value "eNB-routed", the first type authentication procedure is adopted. On the other hand, if the WLANAuthenticationType IE is set to the value "AAA-routed", the second type authentication procedure is used.

In an alternative embodiment, the indication to use the first type of authentication procedure may be an implicit indication, which may be provided using the signaling of the eNB ID (e.g., the eNB_Identifier discussed above) in the RRCConnectionReconfiguration message used for WLAN configuration (or implicitly through the presence of the eNB ID). Since such an eNB ID is provided to the UE only for the purpose of constructing the NAI including the eNB ID, the presence of the eNB ID implicitly indicates the use of the first type of authentication procedure.

The signaling indicating the type of authentication procedure to be used enables the UE to know which type of authentication procedure is used with which WLAN, wherein the WLAN type may be represented by, for example, a service set identifier (SSID) or a basic SSID (BSSID).

Processing authentication messages at the MeNB

The following describes example techniques or mechanisms for processing authentication messages (such as EAP messages) from a UE at the MeNB 108 .

In a first type of solution, the MeNB 108 acts as an authentication proxy.

In a second type of solution, the MeNB 108 acts as an autonomous authentication server.

MeNB acts as an authentication agent

This solution solves problem 1, but not problem 3.

As discussed above in conjunction with FIG2 , in response to the EAP message from the UE, the WLAN node (e.g., WLAN node 202 in FIG2 ) sends an authentication message to the MeNB 108. In response to receiving the authentication message from the WLAN node 202, the MeNB, acting as an authentication agent, involves the core network (and ultimately the HSS 118 in FIG1 ) in performing authentication of the UE, and any authentication signaling (e.g., AAA signaling) will extend between the UE and the HSS 118.

Traditionally, AAA signaling is transmitted between WLAN nodes and AAA servers. In some embodiments of the present disclosure, AAA signaling is routed via MeNB 108.

Different options for routing authentication messages between the UE 106 and the HSS 118 via the MeNB 108 are shown in FIGURES 4A and 4B, respectively.

4A, authentication messages are routed between UE 106 and HSS 118 through WLAN 104, MeNB 108 acting as AAA proxy, and 3GPP AAA server 402. In the option of FIG4A, a connection between MeNB 108 and 3GPP AAA server 402 in the core network is provided.

In FIG. 4B , authentication messages are routed between the UE 106 and the HSS 118 through the WLAN 104 , the MeNB 108 , the MME 116 , and the 3GPP AAA server 402 .

Upon receiving the EAP-Request containing the identification string from the UE 106, the MeNB 108 sends an authentication message to the 3GPP AAA server 402 ( FIG. 4A ) or to the MME 116 ( FIG. 4B ). To authenticate the UE 106, the HSS 118 uses an identifier corresponding to the UE 106. As described above, this identifier corresponding to the UE can be the IMSI provided in the “Identity_desc” string of the NAI, or alternatively, if a radio access network identifier (e.g., the RNTI or MAC address discussed above) is used in the NAI, the MeNB 108 replaces the radio access network identifier with a core network identifier such as the IMSI. One way that the MeNB 108 can determine the IP address of the correct 3GPP AAA server in the system architecture of FIG. 4A is by performing a DNS lookup using a portion of the NAI field that identifies the cellular network operator.

As described above, depending on whether UE 106 is roaming in cellular mode, either the root NAI or the modified NAI can be used. If UE 106 is not roaming in cellular mode, the root NAI is used; when UE 106 is roaming in cellular mode, the modified NAI is used. If the message must first pass through an AAA server in the VPLMN and then reach an AAA server in the HPLMN (the case where two AAA servers are not shown in Figures 4A or 4B), the modified NAI may be appropriate. The portion of the NAI that includes the eNB's identifier (e.g., cell ID or eNB ID) may be removed by MeNB 108.

If the option of FIG4B is used, the EAP message may be forwarded to the MME 116, potentially in a transparent container included in a message, such as a UE-WLAN Aggregation ID message sent (at 502) from the MeNB 108 to the MME 116, as shown in FIG5. The UE-WLAN Aggregation ID may be the IMSI of the user of the UE or any other identifier corresponding to the UE 106.

The MME 116 may then unpack the EAP message and forward the unpacked EAP message to the appropriate AAA server (e.g., 402 in FIG. 4B ). The NAI within the EAP message may contain sufficient information for the MME 116 to determine to which AAA server the unpacked EAP message (e.g., the traditional form of the NAI without the eNB's identifier as described above) should be forwarded.

In response to the UE-WLAN Aggregation ID message, the MME 116 sends (at 504) a UE-WLAN Aggregation Challenge to the MeNB 108, where the UE-WLAN Aggregation Challenge may have been issued by the HSS 118 or the AAA server 402. The UE-WLAN Aggregation Challenge message contains a challenge vector.

In a radio access network (RAN) sharing scenario, there may be multiple MMEs (in different PLMNs) connected to the MeNB 108. To support this scenario, the MeNB 108 may have to read the NAI to determine which MME to forward the EAP message (assuming that the IMSI is used as the Identity_desc). On the other hand, if the radio access network identity is used as the Identity_desc in the NAI (the example discussed above), or if the EAP message arrives in an X2-AP message associated with a specific user, the MeNB 108 may perform a table lookup to determine which specific MME (i.e., which S1-C link) should be used to forward the transparent container.

The following describes exemplary changes to 3GPP TS 36.413, as shown in FIG. 5 , to enable signaling between the MeNB 108 and the MME 116 .

UE WLAN-aggregation authentication message

UE-WLAN aggregation ID

The UE-WLAN Aggregation ID message (as shown in the table below) is sent by the MeNB to request the MME to send the corresponding challenge vector of the EAP challenge response to be sent to the UE. The direction is eNB → MME.

UE-WLAN aggregation query

The UE-WLAN Aggregation Challenge message (as shown in the table below) is sent by the MME to send IEs for challenging the UE for WLAN authentication during the EAP exchange. The direction is MME→eNB.

MeNB autonomously processes EAP messages

The first type of solution in which the MeNB 108 functions as an authentication proxy is discussed above. The second type of solution in which the MeNB 108 functions as an autonomous authentication server is discussed below.

The second type of solution addresses both problems 1 and 2.

For the second type of solution, it is assumed that the MeNB 108 obtains the key Kwlan (discussed below). Hierarchically, this key can be at the same security level as the KeNB generated at the MME 116. The MME 116 generates KeNB using the NAS uplink count as a counter of the NAS message.

The key Kwlan may be made known to the MeNB 108. The key Kwlan may be used by both the MeNB 108 and the UE 106 to perform WLAN EAP authentication/authorization challenges and to calculate WLAN-specific keys for encryption and integrity protection.

The MeNB 108 generates Kwlan or is provided with Kwlan from the MME 116. The UE 106 can generate Kwlan from a master key K stored on the UE's 106 Universal Subscriber Identity Module (USIM).

As shown in Figure 6, the key Kwlan can be generated in a similar manner to the generation of KeNB by using a key derivation function (KDF) 602. KDF 602 receives two inputs: (1) an input key (Kasme in Figure 6), which is typically a secret value that does not leave the security domain from which the key is known or derived; and (2) an input string (INPUT_STRING1 in Figure 6), which may or may not be secret and can be constructed using a predetermined set of parameters or values.

INPUT_STRING1 used in generating Kwlan may be stored and forwarded to UE 106 to enable UE 106 to also generate Kwlan (note that another input Kasme may be generated by UE 106).

In some implementations, the serving network identity (SN ID) may be used to determine Kasme (Kasme is the EPS session master key).

As an example, INPUT_STRING1 can be a random number generated by MME 116 and subsequently sent to UE 106 during its attach procedure (e.g., by including the random number in an authentication request message sent from MME 116 to UE 106). The authentication request message is described in 3GPP TS 24.301. Alternatively, INPUT_STRING1 can be a value that is known to both UE 106 and MeNB 116 and can change. Such a value does not need to be signaled to the UE. An example of such a value is an RRC message counter.

The underlined text below may be added to 3GPP TS 33.401 to support the above, where FC is an identifier of a specific variant of the key derivation function.

Annex A (Specifications):

Key derivation function

A.1 KDF interface and input parameter construction

…

A.16 Exporting Kwlan at the MME

This input string is used by the MME and UE when deriving Kwlan from Kasme for WLAN aggregation. The following should be used Enter the parameters to form the input string to the key derivation function:

-FC=0x1D

- P0 = random non-negative integer value generated at the MME

- L0 = the length of the non-negative integer generated in the above step (ie 0x00 0x02) The input key is Kasme.

7A-7B illustrate a modified LTE attach and security setup procedure according to 3GPP TS 23.401. The modifications to the LTE attach and security setup procedure according to 3GPP TS 23.401 shown in FIG7A-7B are discussed below. The remaining messages according to 3GPP TS 23.401 are not discussed further.

As shown in Figures 7A-7B, message 11 is an initial context setup request message sent by MME 116 to MeNB 108. In some embodiments, the initial context setup request message can be modified to include the key Kwlan as described above. In other embodiments, the key Kwlan is not included in the initial context setup request message.

Message 14 in Figures 7A-7B is an RRCConnectionReconfiguration message sent from MeNB 108 to UE 106. As described above, the RRCConnectionReconfiguration message may include an indication of which of the different types of authentication procedures (such as the first type authentication procedure and the second type authentication procedure discussed above) to use. The RRCConnectionReconfiguration message may also include an identifier (WLAN ID) of the WLAN to which the particular authentication type applies.

7A-7B also illustrate task 702 , which corresponds to adding a WLAN (for LTE-WLAN aggregation mode) triggered at UE 106 in response to an RRC reconfiguration procedure not shown in FIGs. 7A-7B .

Messages and/or tasks 18, 19, 20, 20a, 21, 22, 23, 24, 25, 26, 26a, 27 and 27a in Figures 7A-7B correspond to messages and/or tasks 204, 206, 208, 210, 212, 214, 216, 218, 220, 222, 224, 226 and 228 in Figure 2, respectively.

7A-7B also illustrate task 704 at MeNB 108, which includes performing an EAP Authentication and Key Agreement (AKA) (EAP-AKA or EAP-AKA′) algorithm using Kwlan as input and outputting AK, RAND, AUTN, XRES, MSK (Master Session Key), and EMSK (Extended Master Session Key), as shown in FIG8 .

EAP is an authentication framework that supports multiple authentication methods, referred to as EAP methods. AKA and AKA' are procedures based on 3GPP that use certificates stored on the USIM and HSS. EAP-AKA and EAP-AKA' are applicable authentication procedures. EAP-AKA' is similar to EAP-AKA, except that it provides for binding derived keys to access network identifiers. EAP-AKA' is described in RFC 5448, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')," published in May 2009.

Performing the EAP-AKA or EAP-AKA' process in task 704 may include requesting an AKA vector and returning an AKA vector containing various contents, such as the output of the key derivation function shown in FIG8 (discussed further below). In some embodiments, the request for the AKA vector may be sent from the MeNB 108 to the HSS 118 via the MME 116 and/or the 3GPP AAA server 402, after which the HSS 118 responds with the AKA vector. In other embodiments where the MeNB 108 performs authentication tasks autonomously, the MeNB 108 may generate the AKA vector. Further details regarding EAP-AKA' are provided in 3GPP TS 33.402 and RFC 5448.

7A-7B also illustrate task 706 at UE 106, which includes running AKA using Kwlan, verifying AUTN, and generating RES and MSK.

In Figures 7A-7B , before configuring the UE in LTE-WLAN aggregated mode, MeNB 108 generates a RADIUS Access-Challenge message (Message 22). To achieve this, all contents of the RADIUS Access-Challenge message are generated at MeNB 108. As shown in Figure 8 , the contents of the RADIUS Access-Challenge message are generated by MeNB 108 using Kwlan as a secret key.

Figure 8 illustrates an example of how the MeNB can derive this set of parameters to enable mutual authentication between the UE and the network. Key Derivation Functions (KDFs) 802, 804, and 806 are used to generate keys in response to various inputs. The output of KDF 802 is provided as input to KDF 804, which in turn provides input to KDF 806. The output of KDF 806 includes the MSK and EMSK, which are keys that can be used, for example, to encrypt WLAN traffic. Several other functions are also provided to derive other parameters used as part of the mutual authentication process between the UE and the network. Function F1 810 provides a message authentication code, which the UE checks to verify the authenticity of authentication messages from the network. Function F3 generates an authentication token, which the UE can also derive and use in comparison checks to authenticate the network. Function F2 812 generates an XRES (Expected Result), which the UE also expects to derive and then provide to the network in the RES parameter, enabling the network to authenticate the UE. The network provides the UE with parameters including string 1, string 2, string 3 (so-called KDF-INPUT parameters) and the identity of the KDF (Key Derivation Function), unless the UE can reliably determine them autonomously.

The following table compares the parameters used in the key generation algorithm shown in Figure 8 with the parameters used in key generation used in the legacy EAP-AKA’ algorithm.

Referring to Figure 6, it can be noted that the key Kasme is used as the secret key input for the algorithm used to derive Kwlan. Alternatively, any other key such as KeNB can be used as input. In other words, the above algorithm can be run by replacing Kasme with KeNB in Figure 6.

If KeNB is used, since a new KeNB is generated when the MeNB changes, the algorithm can be re-executed using the new KeNB (i.e., the KeNB after the handover) after the handover. The rest of the algorithm remains unchanged. The assumption here is that during the handover (i.e., MeNB change), the WLAN is removed and added again (by the new MeNB).

Another alternative technique is to derive Kwlan at the HSS 116 and USIM (i.e., at the same security level as deriving Kwlan) by using the same key derivation function and input as used in deriving Kwlan, but using a different serving network identifier (SN ID string). The SN ID string can be a fixed string that is used whenever the device uses WLAN in LTE-WLAN aggregation mode when the cell is attached to a given PLMN.

Options for transmitting authentication messages between WLAN and MeNB

This solution can be used to solve problem 1.

There are many ways to transmit information for completing authentication on the WLAN between the WLAN and the MeNB 108. The following are examples of ways to transmit authentication messages:

EAP messages are transmitted between the WLAN and the MeNB using Stream Control Transmission Protocol/Internet Protocol (SCTP/IP) in DIAMETER or RADIUS messages. DIAMETER messages are based on the Diameter protocol, while RADIUS messages are based on the RADIUS protocol.

Use X2-AP transparent containers to transmit DIAMETER or RADIUS messages between the WLAN and the MeNB.

Use X2-AP transparent container to directly transmit EAP messages between WLAN and MeNB.

Extract the content of the EAP message and place the extracted content in the X2-AP message between the WLAN and the MeNB.

Further details regarding the above-described manner of transmitting authentication messages are provided below.

Using Diameter or Radius to transmit EAP messages over SCTP/IP

DIAMETER and RADIUS are protocols that support the transmission of EAP messages. RADIUS is more common in WLAN, while DIAMETER is used by 3GPP.

FIG9 is a block diagram of the protocol layers in MeNB 108 and WLAN 104 (a WLAN AP or a combination of a WLAN AP and a WLAN gateway). The protocol layers in each of MeNB 108 and WLAN 104 include Layer 1 (physical layer), Layer 2 (data link layer), the IP layer above Layer 1, and the SCTP layer above the IP layer. Furthermore, each of MeNB 108 and WLAN 104 includes a DIAMETER layer and an optional X2-AP layer. Using the configuration of FIG9 , DIAMETER messages transmitted between the DIAMETER layers of MeNB 108 and WLAN 104 can encapsulate EAP messages.

In other embodiments of the present disclosure, a RADIUS layer may be provided in the MeNB 108 and the WLAN 104 to carry RADIUS messages that may encapsulate EAP messages.

Using Diameter or Radius to Transmit EAP in an X2-AP Transparent Container

In an alternative embodiment, as shown in FIG. 10 , the EAP message is first encapsulated into a DIAMETER or RADIUS message, and the DIAMETER or RADIUS message is then carried in an X2-AP message between the WLAN node 202 and the MeNB 108 .

The protocol layers of each of MeNB 108 and WLAN 104 include Layer 1, Layer 2, IP layer, SCTP layer, and an X2-AP layer above the SCTP layer. X2-AP messages carrying DIAMETER or RADIUS messages support what is known in 3GPP as transparent containers, meaning that the X2-AP layer itself does not interpret the contents of the transparent container, but rather the contents (in this case, the DIAMETER or RADIUS message) are made available to MeNB 108 for further processing.

Although FIG10 shows an example in which a DIAMETER message is carried by an X2-AP transparent container, in other examples, a RADIUS message may be carried by an X2-AP transparent container instead.

Transmit EAP messages directly in the X2-AP transparent container

In this solution, EAP messages are directly carried in an X2-AP transparent container, rather than being first encapsulated in a DIAMETER or RADIUS message and then carried by the X2-AP transparent container.

The content of the EAP message is transmitted in the X2-AP message

In this solution, the content of the EAP-AKA' message is directly carried as a new information element in the new X2-AP message. The content of the EAP-AKA' message supported in the EAP message includes information elements such as NAI, RAND, AUTN, and MAC.

System Architecture

11 is a block diagram of an example system (or network node) 1100 that may represent any of the following: a UE, a cellular access network node, or a WLAN node. System 1100 may be implemented as a computing device or a configuration of multiple computing devices.

System 1100 includes a processor (or multiple processors) 1102 that can be coupled to a network interface (or multiple network interfaces) 1104 to communicate with another entity wirelessly or through a wired link. The processor may include a microprocessor, a microcontroller, a physical processor module or subsystem, a programmable integrated circuit, a programmable gate array, or another physical control or computing circuit.

The processor 1102 may also be coupled to a non-transitory machine-readable or machine-readable storage medium (or storage media) 1106 that may store machine-readable instructions 1108 executable on the processor 1102 to perform the various tasks described above.

A storage medium (or multiple storage media) 1106 may include one or more computer-readable or machine-readable storage media. The one or more storage media may include one or more different forms of memory, including semiconductor memory devices such as dynamic or static random access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed, flexible, and removable disks; other magnetic media (including magnetic tape); optical media such as compact disks (CDs) or digital video disks (DVDs); or other types of storage devices. Note that the instructions described above may be provided on a computer-readable or machine-readable storage medium or, alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system, potentially with multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any manufactured single component or multiple components. The one or more storage media may be located in the machine that runs the machine-readable instructions, or at a remote location from which the machine-readable instructions may be downloaded over a network for execution.

In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, these implementations may be practiced without some of these details. Other implementations may include modifications and variations of the above details. It is intended that the appended claims cover such modifications and variations.

Claims (20)

1. A communication method, comprising: The User Equipment (UE) sends a Network Access Identifier (NAI) to a Radio Access Node (RAN) in a Wireless Local Area Network (WLAN). The NAI includes an identifier for a cellular access network node. Sending the NAI to the RAN in the WLAN causes the RAN to send an authentication message to the cellular access network node based on the identifier of the cellular access network node in the NAI. The UE receives an authentication challenge based on information in the NAI from the radio access node in the WLAN, wherein the authentication challenge is sent by the cellular access network node in response to the authentication message; The UE sends a response to the authentication challenge to the radio access node in the WLAN, so that the radio access node in the WLAN sends the response to the cellular access network node; and The UE receives an indication of successful authentication from the wireless access node in the WLAN, the indication being sent by the wireless access node in the WLAN. 2. The method according to claim 1, wherein the identifier of the cellular access network node includes a cell identifier or a cellular access network node identifier. 3. The method according to any one of claims 1 to 2, wherein the NAI of the identifier of the cellular access network node includes a root NAI. 4. The method according to any one of claims 1 to 2, wherein the NAI of the identifier of the cellular access network node includes a modified NAI. 5. The method according to any one of claims 1 to 2, wherein the NAI further includes an identifier corresponding to the UE. 6. The method of claim 5, wherein the identifier is selected from the International Mobile Subscriber Identity (IMSI), the Globally Unique Temporary Identifier (GUTI), the Radio Network Temporary Identifier (RNTI), and the Media Access Control (MAC) address. 7. The method according to any one of claims 1 to 2, wherein sending the NAI includes sending the NAI in an Extensible Authentication Protocol (EAP) message. 8. The method according to any one of claims 1 to 2, further comprising: receiving an instruction from the network regarding whether to use a first type of authentication process or a second type of authentication process, wherein the first type of authentication process routes authentication messages between the WLAN node and the cellular access network node, and the second type of authentication process routes authentication messages between the WLAN node and an authentication, authorization, and accounting (AAA) server. 9. A cellular access network node, comprising: A network interface for communicating with wireless access nodes in a wireless local area network (WLAN); and At least one processor is configured as follows: Receive a first authentication message from the radio access node to authenticate the user equipment (UE), the first authentication message being sent in response to the radio access node receiving a network access identifier (NAI), the network access identifier including an identifier of the cellular access network node, wherein the cellular access network node is part of a cellular access network, the cellular access network being a radio access network of a different type than the WLAN; and In response to the first authentication message, authentication of the UE is performed; the authentication includes: The cellular access network node sends an authentication challenge in response to the first authentication message to the wireless access node in the WLAN, so that the wireless access node in the WLAN sends the authentication challenge to the UE; The cellular access network node receives the authentication challenge message from the radio access node in the WLAN, and the response is received by the radio access node in the WLAN from the UE; and The cellular access network node sends a message to the wireless access node in the WLAN, the message being a response to the authentication challenge. 10. The cellular access network node according to claim 9, wherein the at least one processor is configured to: A second authentication message is sent to the core network node to perform authentication of the UE, wherein the second authentication message is based on the first authentication message. 11. The cellular access network node according to claim 10, wherein the core network node to which the authentication message is forwarded includes an authentication, authorization, and accounting (AAA) server. 12. The cellular access network node of claim 11, wherein the at least one processor is configured to select the AAA server from a plurality of AAA servers based on an identifier in the NAI corresponding to the UE. 13. The cellular access network node according to claim 10, wherein the core network node to which the authentication message is forwarded includes a Long Term Evolution (LTE) Mobility Management Entity (MME). 14. The cellular access network node according to claim 9, wherein the at least one processor is configured to: The authentication of the UE is performed in response to the authentication message. 15. The cellular access network node of claim 14, wherein the authentication includes using a key to perform an authentication challenge on the UE. 16. The cellular access network node of claim 15, wherein the at least one processor is configured to receive the key from a core network node or generate the key. 17. The cellular access network node according to any one of claims 9 to 16, wherein the at least one processor is configured to send an indication to the UE regarding which type of authentication among multiple types to apply to the UE, wherein the multiple types of authentication include a first type of authentication and a second type of authentication, the first type of authentication routing authentication messages between the WLAN node and the cellular access network node, and the second type of authentication routing authentication messages between the WLAN node and an authentication, authorization, and accounting (AAA) server. 18. The cellular access network node according to any one of claims 9 to 16, wherein the cellular access network node is configured to use any one of the following to transmit Extensible Authentication Protocol (EAP) messages: Use Stream Control Transport Protocol/Internet Protocol (SCTP/IP) to transmit EAP messages encapsulated in DIAMETER or RADIUS messages. Transmit DIAMETER or RADIUS messages encapsulating EAP messages within the X2-AP transparent container. The EAP message is transmitted directly within the X2-AP transparent container, and The content extracted from the EAP message is transmitted in the X2-AP message. 19. A user equipment (UE), comprising: At least one wireless interface for communicating with a wireless access node in a wireless local area network (WLAN) and with a cellular access network node; and At least one processor is configured as follows: Sending an authentication request including a Network Access Identifier (NAI) to a wireless access node in the WLAN, wherein the NAI contains an identifier of the cellular access network node, wherein sending the NAI to the wireless access node in the WLAN causes the wireless access node to send an authentication message to the cellular access network node based on the identifier of the cellular access network node in the NAI; and Receive an authentication challenge based on information in the NAI from the cellular access network node, wherein the authentication challenge is sent by the cellular access network node in response to the authentication message; Sending a response to the authentication challenge to the wireless access node in the WLAN, so that the wireless access node in the WLAN sends the response to the cellular access network node; and The UE receives an indication of successful authentication from the wireless access node in the WLAN, the indication being sent by the wireless access node in the WLAN. 20. A computer-readable storage medium storing machine-readable instructions that can be executed by a processor to perform the method according to any one of claims 1 to 8.