Apparatus and method for determining access network radio access type

By acquiring and transmitting the technology type information of the access network through the UE, the problem of the 5G core network being unable to identify untrusted access networks is solved, enabling better access control, quality of service, and billing policies, and improving the flexibility and efficiency of network management.

CN115104347BActive Publication Date: 2026-05-12LENOVO (SINGAPORE) PTE LTD
View PDF 1 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
LENOVO (SINGAPORE) PTE LTD
Filing Date
2020-02-13
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

When a user equipment (UE) connects to the 5G core network through an untrusted non-3GPP access network, the 5G core network cannot identify the specific radio access technology type, which prevents the operator from implementing effective access control, service control, and billing policies.

Method used

The UE obtains the access technology type information of the access network and sends it to the N3IWF during the registration process. The N3IWF or AMF determines the radio access technology type of the untrusted access network, and the AMF processes the registration request based on this information.

Benefits of technology

It enables operators to identify the types of untrusted access networks, allowing for better access control, quality of service control, and billing policies, thus improving the flexibility and efficiency of network management.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115104347B_ABST
    Figure CN115104347B_ABST
Patent Text Reader

Abstract

Apparatuses, methods, and systems for determining a RAT of an untrusted access network are disclosed. One apparatus (400) includes a processor (405) and a transceiver (425) that communicates with a first access network. The processor (405) obtains (605) an ANI for the first access network, the ANI including an access technology type of the first access network. The processor (405) determines (610) to register with a mobile communication network (e.g., 5GC) via the first access network using an untrusted registration procedure and sends (615) a first request (e.g., an IKE AUTH request) to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, where the obtained ANI is used by the mobile communication network to determine a RAT of the first access network. Via the transceiver (625), the processor (605) receives (620) a response to the registration request after the secure connection is established with the N3IWF, where the response depends on the RAT.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The topics disclosed in this article generally relate to wireless communication, and more specifically to identifying types of radio access technologies, such as types of untrusted access networks. Background Technology

[0002] The following abbreviations and acronyms are defined herein, and at least some of them will be referenced in the following description.

[0003] The following technologies are involved: Third Generation Partnership Project (“3GPP”), Fifth Generation Core (“5GC”), Access and Mobility Management Function (“AMF”), Access Point Name (“APN”), Access Layer (“AS”), Access Network Information (“ANT”), Application Programming Interface (“API”), Data Network Name (“DNN”), Downlink (“DL”), Enhanced Mobile Broadband (“eMBB”), Evolved Node B (“eNB”), Evolved Packet Core (“EPC”), and Evolved UMTS Terrestrial Radio Access Network (“E-UTRAN”). Home Subscriber Server (“HSS”), IP Multimedia Subsystem (“IMS”, also known as “IP Multimedia Core Network Subsystem”), Internet Protocol (“IP”), Long Term Evolution (“LTE”), LTE-Advanced (“LTE-A”), Media Access Control (“MAC”), Mobile Network Operator (“MNO”), Mobility Management Entity (“MME”), Non-Access Stratum (“NAS”), Narrowband (“NB”), Network Functions (“NF”), Network Access Identifier (“NAI”), Next Generation (e.g., 5G) NodeB ( The network includes “gNB”, Next Generation Radio Access Network (“NG-RAN”), New Radio (“NR”), Policy Control Function (“PCF”), Packet Data Network (“PDN”), Packet Data Unit (“PDU”), PDN Gateway (“PGW”), Public Land Mobile Network (“PLMN”), Quality of Service (“QoS”), Radio Access Network (“RAN”), Radio Access Technology (“RAT”), Radio Resource Control (“RRC”), Receive (“Rx”), Single Network Slice Selection Auxiliary Information (“S-NSSAI”), Serving Gateway (“SGW”), Session Management Function (“SMF”), Transmission Control Protocol (“TCP”), Transmit (“Tx”), Unified Data Management (“UDM”), User Entity / Equipment (Mobile Terminal) (“UE”), Uplink (“UL”), User Plane (“UP”), Universal Mobile Telecommunications System (“UMTS”), User Datagram Protocol (“UDP”), User Location Information (“ULI”), Wireless Local Area Network (“WLAN”), and Global Microwave Access Interoperability (“WiMAX”).

[0004] In some embodiments, the UE can connect to the 5G core in the PLMN via several types of untrusted non-3GPP access networks, all of which provide IP connectivity between the UE and the non-3GPP interoperability function (N3IWF) within the 5G core (“5GC”). However, when the UE accesses the 5GC via an N3IWF, the 5GC is unaware of which type of untrusted non-3GPP access network is being used by the UE. Summary of the Invention

[0005] Methods for determining the RAT for untrusted access networks are disclosed. Apparatus and systems also perform the functions of these methods.

[0006] One method for a UE to determine the RAT of an untrusted access network includes obtaining an Access Technology Name (ANI) for a first access network, the ANI including the access technology type of the first access network. The method includes determining registration with a mobile communication network via the first access network using an untrusted registration process, and sending a first request to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network. The method includes receiving a response to the registration request after establishing a secure connection with the N3IWF, wherein the response depends on the RAT.

[0007] A method for determining the Range Attack (RAT) of an untrusted access network using an N3IWF includes receiving a first request to establish a secure connection from a remote unit. Here, the first request includes a registration request for a mobile communication network, a first source address, and an Access Point Indicator (ANI) for the first access network. The method includes verifying the ANI using the first source address and the ANI, and sending a first message to the AMF including the registration request and the ANI, wherein the ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT.

[0008] A method for an AMF to determine the Remote Access Request (RAT) of an untrusted access network includes receiving a first message via an N3IWF, the first message including a registration request for a remote unit connected to the N3IWF via a first access network. Here, the first message also includes an Access Name Information (ANI) regarding the first access network. The method includes using the ANI to determine the RAT of the first access network. The method includes determining, based on the determined RAT, whether to accept the registration request and sending a response to the registration request to the remote unit.

[0009] Another method used by the N3IWF to determine the RAT of an untrusted access network includes receiving a first request to establish a secure connection from a remote unit. Here, the first request includes a registration request for the mobile communication network and a first source address. The method includes using the first source address to obtain an Access Technology Type (ANI) for the first access network, including the access technology type of the first access network, and sending a first message to the AMF. In such an embodiment, the first message includes the registration request and the obtained ANI, wherein the obtained ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT. Attached Figure Description

[0010] A more specific description of the embodiments briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only a few embodiments and are therefore not intended to be limiting of the scope. The embodiments will be described and explained using additional specificity and detail through the use of the drawings, in which:

[0011] Figure 1 This is a diagram illustrating one embodiment of a wireless communication system used to determine the RAT (Regulatory Access Point) of an untrusted access network;

[0012] Figure 2A This is a diagram illustrating one embodiment of a network deployment for identifying untrusted access networks using a RAT;

[0013] Figure 2B This is a diagram illustrating another embodiment of a network deployment for identifying untrusted access networks using a RAT;

[0014] Figure 2C This is a diagram illustrating a third embodiment of a network deployment for identifying untrusted access networks using a RAT;

[0015] Figure 3A This is a signal flow diagram illustrating one embodiment of the process for registering with a PLMN via a non-public mobile network;

[0016] Figure 3B yes Figure 3A The continuation of the process described in the text;

[0017] Figure 4 This is a block diagram illustrating one embodiment of a user equipment apparatus for determining an untrusted access network RAT;

[0018] Figure 5 This is a block diagram illustrating one embodiment of a network device apparatus for determining an untrusted access network's RAT;

[0019] Figure 6This is a flowchart illustrating an embodiment of a first method for determining a RAT (Registered Access Tag) for an untrusted access network;

[0020] Figure 7 This is a flowchart illustrating an embodiment of a second method for determining an untrusted access network's RAT;

[0021] Figure 8 This is a flowchart illustrating an embodiment of a third method for determining the RAT of an untrusted access network; and

[0022] Figure 9 This is a flowchart illustrating an embodiment of a fourth method for determining a RAT (Regulatory Access Point) for an untrusted access network. Detailed Implementation

[0023] As those skilled in the art will understand, aspects of the embodiments can be embodied as a system, apparatus, method, or program product. Therefore, embodiments can take the form of a completely hardware embodiment, a completely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects.

[0024] For example, the disclosed embodiments can be implemented as hardware circuits including custom-designed very large-scale integrated circuit (“VLSI”) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. The disclosed embodiments can also be implemented in programmable hardware devices such as field-programmable gate arrays, programmable array logic, programmable logic devices, etc. As another example, the disclosed embodiments may include one or more physical or logical blocks of executable code, which may, for example, be organized as objects, procedures, or functions.

[0025] Furthermore, embodiments may take the form of a program product embodied in one or more computer-readable storage devices stored in machine-readable code, computer-readable code, and / or program code, referred to below as code. The storage device may be tangible, non-transitory, and / or non-transferable. The storage device may not embody signals. In one embodiment, the storage device employs only signals for accessing the code.

[0026] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-readable storage medium. A computer-readable storage medium may be a storage device for storing code. A storage device may be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, holographic, micromechanical, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof.

[0027] More specific examples of storage devices (a non-exhaustive list) will include the following: electrical connections having one or more cables, portable computer disks, hard disks, random access memory (“RAM”), read-only memory (“ROM”), erasable programmable read-only memory (“EPROM” or flash memory), portable optical disc read-only memory (“CD-ROM”), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium can be any tangible medium capable of containing or storing programs for use by or in connection with an instruction execution system, apparatus, or device.

[0028] References to "an embodiment," "embodiment," or similar language in this specification mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment. Therefore, unless expressly specified otherwise, throughout this specification, the phrases "in an embodiment," "in an embodiment," and similar language may, but not necessarily all, refer to the same embodiment, but rather mean "one or more, but not all, embodiments." Unless expressly specified otherwise, the terms "comprising," "including," "having," and variations thereof mean "including, but not limited to,". Unless expressly specified otherwise, the list of enumerated items does not imply that any or all items are mutually exclusive. Unless expressly specified otherwise, the terms "a," "an," and "the" also mean "one or more".

[0029] As used herein, a list connected with "and / or" includes any single item in the list or a combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one or more of" includes any single item in the list or a combination of items in the list. For example, one or more of A, B, and C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. As used herein, a list using the term "one of" includes one and only one of any single item in the list. For example, "one of A, B, and C" includes only A, only B, or only C and excludes combinations of A, B, and C. As used herein, "selected from the group consisting of A, B, and C" includes one and only one of A, B, or C and excludes combinations of A, B, and C. As used in this article, “selecting members of a group consisting of A, B, and C and their combinations” includes only A, only B, only C, combinations of A and B, combinations of B and C, combinations of A and C, or combinations of A, B, and C.

[0030] Furthermore, the features, structures, or characteristics of the described embodiments can be combined in any suitable manner. In the following description, numerous specific details, such as examples of programming, software modules, user selection, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., are provided to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments can be practiced without one or more specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the embodiments.

[0031] The aspects of the embodiments are described below with reference to schematic flowcharts and / or schematic block diagrams of methods, apparatus, systems, and program products according to the embodiments. It will be understood that each block of the schematic flowcharts and / or schematic block diagrams, and combinations of blocks in the schematic flowcharts and / or schematic block diagrams, can be implemented by code. This code can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to generate machinery, such that instructions executable via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / actions specified in the schematic flowcharts and / or schematic block diagrams.

[0032] The code can also be stored in a storage device that can instruct a computer, other programmable data processing device or other device to operate in a particular manner, such that the instructions stored in the storage device produce an article of art including instructions that implement the functions / actions specified in the schematic flowchart and / or schematic block diagram.

[0033] The code may also be loaded onto a computer, other programmable data processing apparatus or other device, causing a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the code executing on the computer or other programmable apparatus provides a process for implementing the function / action specified in the schematic flowchart and / or schematic block diagram.

[0034] The schematic flowcharts and / or schematic block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, system, method, and program products according to various embodiments. In this regard, each block in the schematic flowcharts and / or schematic block diagrams may represent a module, segment, or portion of code, which includes one or more executable instructions for implementing a specified logical function.

[0035] It should also be noted that in some alternative embodiments, the functions annotated in the boxes may occur in a different order than those annotated in the figures. For example, two boxes shown successively may actually be performed substantially simultaneously, or these boxes may sometimes be performed in reverse order, depending on the functionality involved. Other steps and methods that are functionally, logically, or effectively equivalent to one or more boxes or portions thereof in the illustrated figures are conceivable.

[0036] The description of the elements in each figure can be referenced to the elements in the preceding figures. Throughout all figures, the same reference numerals refer to the same elements, including alternative embodiments of the same elements.

[0037] Methods, apparatus, and systems for determining untrusted access networks (RATs) are disclosed. As specified in current 5G specifications (see, for example, 3GPP TS23.501v16.3.0 and 3GPP TS23.502v16.3.0), a UE can connect to the 5G core in a PLMN via several types of so-called untrusted non-3GPP access networks—all of which provide IP connectivity between the UE and non-3GPP interoperability functions (“N3IWF”) in the 5G system. Note that the N3IWF can be deployed as part of the 5G core. Alternatively, the N3IWF can be deployed as part of an access network. These access networks are considered untrusted from the 5G core network's viewpoint because they do not support any secure signaling interface or any interoperability with the 5G core network. Furthermore, they are considered non-3GPP access networks because they support connectivity to the 5G core via the N3IWF, which is designed to support interoperability with untrusted non-3GPP access networks. However, some of these access networks can provide 3GPP-based radio connectivity, such as NR or E-UTRA.

[0038] The problem addressed in this disclosure is that when a UE accesses a 5GC via an N3IWF, the 5GC is unaware of what type of untrusted non-3GPP access network the UE is using. For example, the 5GC does not know whether the UE is using a Wi-Fi access network, a wired access network, or an SNPN. The 5GC only knows that the UE is using an untrusted non-3GPP access network but cannot determine the type of untrusted non-3GPP access network.

[0039] As specified in the current 5G specifications, when a UE registers with the 5GC via the N3IWF (i.e., via an untrusted non-3GPP access network), the N3IWF only sends the UE's User Location Information (ULI) to the AMF, and the AMF always applies the same access type (="non-3GPP") and the same radio access type (="Virtual"). The "Virtual" radio access type (RAT) means that the 5GC only knows that the UE is using an untrusted non-3GPP access network but does not know the exact RAT being used by the UE.

[0040] Conversely, when a UE is using a trusted non-3GPP access network and connecting to the 5GC via a trusted non-3GPP gateway function (TNGF), the 5GC knows whether the UE is using WLAN access or wired access. Note that in this case, TNGF (instead of N3IWF) is used and a signaling interface (Ta) exists between the trusted non-3GPP access network and TNGF. Through this signaling interface, TNGF receives User Location Information (ULI), which depends on the type of trusted non-3GPP access network. In the case of trusted WLAN access, ULI indicates the WLAN's SSID and BSSID; however, in the case of trusted wired access, ULI indicates the Global Line Identity (GLI) or Global Cable Identity (GCI) of the fixed line to which the UE is connected. AMF derives RAT based on the received ULI. However, because they are not trusted access networks, untrusted access networks lack this Ta signaling interface.

[0041] The advantages of enabling 5GC to identify the type of untrusted non-3GPP access network used by a UE connected to 5GC via N3IWF include the following:

[0042] Operators can implement better access control. For example, they can allow access to 5GC only from certain types of untrusted non-3GPP access, but not from other types of untrusted non-3GPP access.

[0043] Carriers have greater control over access to certain services. For example, they can allow access to IMS services from untrusted WLAN access instead of wired access.

[0044] Operators have better control over QoS over different types of untrusted non-3GPP access. For example, they can assign different QoS parameters to the serving data stream (SDF) depending on the type of untrusted non-3GPP carrying the SDF.

[0045] Operators can implement better billing controls. For example, they can choose to apply different billing policies when the UE uses untrusted WLAN access than when the UE uses SNPN access.

[0046] To overcome the above drawbacks, this disclosure describes an alternative procedure for a UE to connect to the 5G core in a PLMN after obtaining IP connectivity via an SNPN. As described in more detail below, the UE can connect to a TNGF (Trusted Non-3GPP Gateway Function) in the PLMN instead of an N3IWF. Therefore, the UE requires a new and different procedure to connect to the PLMN using the TNGF.

[0047] Figure 1 A wireless communication system 100 for determining the RAT of an untrusted access network is depicted according to embodiments of the present disclosure. In one embodiment, the wireless communication system 100 includes at least one remote unit 105, at least one base station unit 110, at least one untrusted non-3GPP access network (“untrusted AN”) 120, and a mobile core network 140 in a PLMN. The untrusted AN 120 may consist of at least one base station unit 110. The remote unit 105 may communicate with the untrusted access network 120 using 3GPP communication links and / or non-3GPP communication links 113, depending on the radio access technology deployed by the untrusted AN 120. Although Figure 1 A specific number of remote units 105, base station units 110, untrusted AN 120, and mobile core network 140 are depicted in the description, but those skilled in the art will recognize that any number of remote units 105, base station units 110, untrusted AN 120, and mobile core network 140 can be included in the wireless communication system 100.

[0048] In one implementation, the wireless communication system 100 conforms to the 5G system specified in the 3GPP specification. However, more generally, the wireless communication system 100 may implement other open or proprietary communication networks, such as LTE / EPC (referred to as 4G) or WiMAX, and other networks. This disclosure is not intended to be limited to any particular wireless communication system architecture or protocol implementation.

[0049] In one embodiment, remote unit 105 may include computing devices such as desktop computers, laptop computers, personal digital assistants (“PDAs”), tablet computers, smartphones, smart TVs (e.g., internet-connected TVs), smart appliances (e.g., internet-connected appliances), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, modems), etc. In some embodiments, remote unit 105 may include wearable devices such as smartwatches, fitness bands, optical head-mounted displays, etc. Furthermore, remote unit 105 may be referred to as a UE, subscriber unit, mobile station, mobile station, user, terminal, mobile terminal, fixed terminal, subscriber station, user terminal, wireless transmit / receive unit (“WTRU”), device, or by other terms used in the art.

[0050] Remote unit 105 can communicate directly with one or more base station units 110 in untrusted AN 120 via uplink (“UL”) and downlink (“DL”) communication signals. Additionally, the UL and DL communication signals can be carried on communication link 113. Note that untrusted AN 120 is an intermediate network, for example, via IP network 150, providing remote unit 105 with access to mobile core network 140.

[0051] In some embodiments, remote unit 105 communicates with an application server (or other communication peer) via a network connection to mobile core network 140. For example, an application in remote unit 105 (e.g., a web browser, media client, telephone / VoIP application) can trigger remote unit 105 to establish a PDU session (or other data connection) with mobile core network 140 using an untrusted AN 120. Mobile core network 140 then uses the PDU session to relay services between remote unit 105 and, for example, an application server in IP network 150. Note that remote unit 105 may establish one or more PDU sessions (or other data connections) with mobile core network 140. Thus, remote unit 105 may have at least one PDU session for communicating with IP 150. Remote unit 105 may establish additional PDU sessions for communicating with other data networks and / or other communication peers.

[0052] Base station unit 110 may be distributed across a geographical area. In some embodiments, base station unit 110 may also be referred to as an access terminal, access point, base station, Node B, eNB, gNB, home Node B, relay node, device, or by any other terminology used in the art. Base station unit 110 is typically part of a radio access network (“RAN”) such as untrusted AN 120, which may include one or more controllers communicatively coupled to one or more corresponding base station units 110. These and other elements of the radio access network are not illustrated but are generally well known to those skilled in the art. Base station unit 110 is connected to mobile core network 140 via untrusted AN 120.

[0053] Base station unit 110 can serve multiple remote units 105 within a service area, such as a cell or cell sector, via communication link 113. Base station unit 110 can communicate directly with one or more remote units 105 via communication signals. Typically, base station unit 110 transmits DL communication signals to serve remote units 105 in the time, frequency, and / or spatial domains. Furthermore, DL communication signals can be carried on communication link 113. Communication link 113 can be any suitable carrier in the licensed or unlicensed radio spectrum. Communication link 113 facilitates communication between one or more remote units 105 and / or one or more base station units 110.

[0054] In one embodiment, the mobile core network 140 is a 5G core (“5GC”) or an evolved packet core (“EPC”), which may be coupled to a data network (e.g., IP network 150, such as the Internet and private data networks, as well as other data networks). The remote unit 105 may have a subscription or other account through the mobile core network 140. This disclosure is not intended to limit implementations to any particular wireless communication system architecture or protocol.

[0055] Mobile core network 140 includes several network functions (“NFs”). As depicted, mobile core network 140 includes multiple user plane functions (“UPFs”). Here, mobile core network 140 includes at least one UPF 141 that serves the untrusted AN 120. Mobile core network 140 also includes multiple control plane functions, including but not limited to Access and Mobility Management Function (“AMF”) 143, Session Management Function (“SMF”) 145, and Policy Control Function (“PCF”) 147. In some embodiments, mobile core network 140 may also include a Unified Data Management Function (“UDM”), an Authentication Server Function (“AUSF”), a Network Repository Function (“NRF”) (used by various NFs for discovery and communication with each other via APIs), or other NFs defined for the 5G core.

[0056] The N3IWF 153 is a network function that supports access to a 5GC network via an untrusted non-3GPP access network. In some embodiments, the N3IWF 153 supports connectivity to one or more 5GC networks for a UE supporting the NAS protocol via non-3GPP access and applicable NAS procedures.

[0057] In various embodiments, the mobile core network 140 supports different types of mobile data connections and different types of network slices, wherein each mobile data connection utilizes a specific network slice. Each network slice includes a set of CP and UP network functions, wherein each network slice is optimized for a specific type of service or service category. For ease of illustration, in Figure 1 Different network slices are not shown, but their support is assumed. In one example, each network slice includes SMF and UPF, but the individual network slices share AMF 143, PCF 147, and UDM. In another example, each network slice includes AMF, SMF, and UPF. Although in Figure 1 A specific number and type of network functions are described, but those skilled in the art will recognize that any number and type of network functions may be included in the mobile core network 140.

[0058] In order for the mobile core network 140 (e.g., 5GC) to identify the type of untrusted non-3GPP access network used by a remote unit 105 connected to the mobile core network 140 via N3IWF 153, the remote unit 105 acquires access network information sent to the AMF 143 via N3IWF 153. Using the access network information, the AMF 143 determines the radio access type (“RAT”) of the untrusted AN 120.

[0059] Figure 2A-2C A network deployment variant including UE 205 is depicted, which registers with a 5G system 225 in a PLMN via an untrusted non-3GPP access network 210 and an IP network 220. In various embodiments, the untrusted non-3GPP access network 210 includes a DCHP server 215.

[0060] As depicted, the 5G system 225 in the PLMN includes at least N3IWF 230, AMF 235, PCF 240, and SMF 245. The 5G system 225 in the PLMN can be an embodiment of the mobile core network 140. In various embodiments, N3IWF 230, AMF 235, PCF 240, and SMF 245 are embodiments of N3IWF 153, AMF 143, PCF 147, and SMF 145, respectively. Note that there is no direct connection (e.g., Ta interface) between the untrusted non-3GPP access network 210 and the 5G core. For this reason, UE 205 and / or N3IWF 230 provide access network information to AMF 235, enabling AMF 235 to determine the RAT of the untrusted non-3GPP access network 210.

[0061] Figure 2A A first network deployment 200 is depicted, in which an untrusted non-3GPP access network 210 includes a Wi-Fi access network 211, such as a public hotspot or a residential Wi-Fi network. As depicted, UE 205 uses the IEEE 802.11 standard for radio communication to communicate with the Wi-Fi access point (“AP”).

[0062] UE 205 connects to Wi-Fi access network 211 and obtains information about this access network, including Access Technology Type (ATT) and Access Network Identity (ANI). In one embodiment, this information is obtained from DHCP server 215. In another embodiment, this information is obtained from data broadcast by Wi-Fi access network 211. As an example, when UE 205 connects to Wi-Fi access network 211, the ATT indicates "WLAN" or "IEEE 802.11" and the ANI indicates the WLAN's SSID.

[0063] UE 205 establishes an NWu connection with N3IWF 230 and sends the obtained ATT to N3IWF 230, which forwards the ATT to AMF 235 within the initial UE message. Note that the initial UE message is associated with the IP address IP@1 (ULI). Additionally, UE 205 can also forward ANI to N3IWF 230. AMF 235 determines the specific radio access type (“RAT”) of the untrusted non-3GPP access network used by UE 205. Instead of the general RAT=Virtual currently used for all types of untrusted non-3GPP access, AMF 235 can determine RAT=Untrusted-WLAN.

[0064] Figure 2BA second network deployment 250 is depicted, in which an untrusted non-3GPP access network 210 includes a wired access network 213, such as a wired or ADSL access network. As depicted, the UE 205 uses IEEE 802.11, NR, E-UTRA, or Ethernet standards to communicate with the residential gateway (“RG”).

[0065] UE 205 connects to wired access network 213 and obtains information about this access network, including Access Technology Type (ATT) and Access Network Identity (ANI). In one embodiment, this information is obtained from DHCP server 215. In another embodiment, this information is obtained from data broadcast by wired access network 213. As an example, when UE 205 connects to wired access network 213, ATT indicates "Wired Line" and ANI indicates the Global Line Identity (GLI) or Global Cable Television Identity (GCI) of the fixed line to which UE 205 is connected.

[0066] UE 205 establishes an NWu connection with N3IWF 230 and sends the obtained ATT to N3IWF 230, which forwards the ATT to AMF 235 within the initial UE message. Note that the initial UE message is associated with the IP address IP@2 (ULI). Additionally, UE 205 can also forward ANI to N3IWF 230. AMF 235 determines the specific radio access type (“RAT”) for the untrusted non-3GPP access network used by UE 205. Instead of the general RAT=Virtual currently used for all types of untrusted non-3GPP access, AMF 235 can determine RAT=Untrusted-Wireline.

[0067] Figure 2C A third network deployment 260 is depicted, in which the untrusted non-3GPP access network 210 includes a standalone non-public network (SNPN) 217, such as a private 5G network that provides mobile services to a specific organization and is deployed at the organization's premises, such as a campus, enterprise, or factory. As depicted, the UE 205 uses NR and / or E-UTRA standards for radio communication to communicate with the private gNB.

[0068] UE 205 connects to SNPN 217 and obtains information about this access network, including the Access Technology Type (ATT) and Access Network Identity (ANI). In one embodiment, this information is obtained from DHCP server 215. In another embodiment, this information is obtained from data broadcast by SNPN 217. As an example, when UE 205 connects to SNPN 217, the ATT indicates "SNPN".

[0069] UE 205 establishes an NWu connection with N3IWF 230 and sends the obtained ATT to N3IWF 230, which forwards the ATT to AMF 235 within the initial UE message. Note that the initial UE message is associated with the IP address IP@3 (ULI). Additionally, UE 205 can also forward ANI to N3IWF 230. AMF 235 determines the specific radio access type (“RAT”) for the untrusted non-3GPP access network used by UE 205. Instead of the general RAT=Virtual currently used for all types of untrusted non-3GPP access, AMF 235 can determine RAT=Untrusted-SNPN.

[0070] As discussed above, after determining the RAT of the untrusted non-3GPP access network 210, the AMF 235 sends the RAT, which is then sent to other network functions in the 5G core, such as the PCF 240 and SMF 245. These network functions take into account the operations they are used to perform, such as creating charging or QoS policies for the UE, or determining whether access to a data network (DN) is permitted.

[0071] Note that the ULI contains the IP address of UE 205 as known to N3IWF 230. This address can be the same as the IP address assigned to UE 205 by the untrusted non-3GPP access network 210, or it can be a different address when there is a Source Network Address Translation (SNAT) device between UE 205 and N3IWF 230, which is a common occurrence. For this reason, the addresses IP@1*, IP@2*, and IP@3* sent by N3IWF 230 to AMF 235 can be the same as or different from the IP@1, IP@2, and IP@3 assigned to UE 205 (respectively). Generally, the ULI cannot be used by AMF 235 to determine the type of untrusted non-3GPP access being used by UE 205.

[0072] It should be noted further that the solution in this disclosure can also be applied to scenarios where a UE accesses the evolved packet core (EPC) via an untrusted non-3GPP access network and enables the ePDG to determine the access technology type (or RAT) used by the UE to access the EPC via the untrusted non-3GPP access network.

[0073] Figures 3A-3B A process 300 for determining a RAT (Registered Access Point) for an untrusted access network according to embodiments of this disclosure is described. Process 300 involves a UE 205 (e.g., an embodiment of remote unit 105) in a 5G system 225 within a PLMN, an untrusted non-3GPP access network 210, and N3IWF 230, AMF 235, and PCF 240. Process 300 details the signaling flow of a scenario where the UE attempts to register with the 5G system 225 in the PLMN via the untrusted non-3GPP access network. Similar steps occur in other scenarios, such as when the UE attempts to perform a service request instead of a registration request. In some embodiments, N3IWF 230 is part of the 5G core. In other embodiments, N3IWF is part of an access network.

[0074] refer to Figure 3A Process 300 begins at step 1a, where UE 205 connects to an access network—such as Wi-Fi access network 211, wired access network 213, or SNPN 217—and obtains Access Network Information (ANI) about this access network (see box 305). The Access Network Information includes Access Technology Type (ATT) parameters and may include additional parameters such as Access Network Identifier (ANId) and Access Carrier Identifier (AOI).

[0075] In some embodiments, the parameters in the ANI are determined using the DHCP protocol: In a DHCP request (DHCPv4 or DHCPv6), UE 205 requests to receive an access network identifier (as specified in RFC 7839), which contains information related to the identity of the access network to which UE 205 is attached. This information may include the access technology type, network identifier, and access network operator identifier. UE 205 determines the ANI parameters using the access network identifier information received in the DHCP response. Specifically, the ATT parameter is determined based on the access technology type in the received access network identifier information, the ANId parameter is determined based on the access identifier in the received access network identifier information, and the AOI parameter is determined based on the network operator identifier in the received access network identifier information.

[0076] In some embodiments, parameters in the ANI are determined using the ANQP protocol: when UE 205 uses IEEE 802.11 radio technology on the access link, UE 205 can use the Access Network Query Protocol (ANQP) specified in the IEEE 802.11 specification to request information about the access network. Parameters announced using the ANQP protocol are specified in the IEEE 802.11 specification and in the Wi-Fi Alliance Hotspot 2.0 specification. These parameters (called ANQP elements) include a domain name that UE 205 can use to determine the ANId and an operator-friendly name that UE 205 can use to determine the AOI. Although ANQP parameters are not currently specified to indicate the access technology type of the access network, this parameter can be defined as a new vendor-specific ANQP parameter. UE 205 can use this new ANQP parameter to determine the ATT.

[0077] In some embodiments, the parameters in the ANI are determined by receiving broadcast data: when UE 205 connects to the SNPN, UE 205 knows the SNPN's access technology type (i.e., "SNPN"), the SNPN's network identity (i.e., the PLMN ID + network access identity broadcast by the SNPN), and the operator associated with the SNPN (e.g., determined from the MCC and MNC values ​​of the PLMN ID). UE 205 can use this information to determine the ATT parameters as well as the ANId and AOI parameters. When UE 205 connects to the access network using IEEE 802.11 radio technology, UE 205 can determine the SSID broadcast by the access network, and this SSID can be used to determine the ANId parameter.

[0078] At step 1b, after connecting to access network 210 and obtaining the ANI, UE 205 decides to register with the 5G core 225 in the PLMN via access network 210 using, for example, the “untrusted non-3GPP access” registration procedure specified in clause 4.12.2 of TS23.502. In some embodiments, Figure 3A The procedure shown extends the procedure in Clause 4.12.2 of TS23.502. Before initiating the “Untrusted Non-3GPP Access” registration procedure, UE 205 selects N3IWF 230 using the procedure specified in TS23.501 and discovers the IP address of this N3IWF 230 using the DNS procedure (see Box 310).

[0079] At step 2, UE 205 proceeds to establish an IPsec security association (SA) with the selected N3IWF by initiating an IKE initial exchange in accordance with RFC 7296 (see Message Transmission 315). After step 2, all subsequent IKE messages are encrypted and protected for integrity using the IKE SA established in this step.

[0080] At step 3, UE 205 initiates an IKE_AUTH exchange by sending an IKE_AUTH request message (see message transmission 320). The AUTH payload is not included in the IKE_AUTH request message, which indicates that the IKE_AUTH exchange should use EAP signaling.

[0081] At step 4, N3IWF 230 responds with an IKE_AUTH response message, which includes an EAP-Request / 5G-Start packet (see message transmission 325). The EAP-Request / 5G-Start packet notifies UE 205 to initiate an EAP-5G session, i.e., to begin sending NAS messages encapsulated within the EAP-5G packet.

[0082] At step 5, UE 205 sends an IKE_AUTH request, which includes an EAP-Response / 5G-NAS packet containing access network parameters (AN-params) and a registration request message. The AN-params contain information used by N3IWF 230 to select AMF 235 in the 5G core network, including, for example, GUAMI, the selected PLMN ID, the requested NSSAI, and the establishment reason. The establishment reason provides the reason for requesting a signaling connection with 5GC.

[0083] In message 330, UE 205 also includes an ANI, which contains ATT parameters and optionally includes the ANId and AOI parameters determined by UE 205 in step 1. The ANI can be included in the EAP-Res / 5G-NAS message, for example, as an additional parameter in AN-Params, or it can be included in the IKE_AUTH request message as a new vendor-specific IKE attribute.

[0084] At step 6, the N3IWF 230 may optionally attempt to perform a coarse verification of the ANI information provided by the UE 205, for example, to confirm that the AOI provided by the UE 205 is correct. For this purpose, the N3IWF 230 may be configured with tables containing IP addresses assigned to several access network operators, such as “IP address space = 16.3.0.0 / 16 ==> AOI = 'WLAN-Operator-A'”, “IP address space = 191.23.4.0 / 8 ==> AOI = 'Car-Vendor-B'”, and “IP address space = 2001:db8:3c4d:15:: / 64 ==> AOI = 'Cable-Operator-C'”.

[0085] When the N3IWF 230 receives a request to establish an IPsec Security Association (SA) from the IPv4 address 16.3.1.1 and the AOI in step 5 is different from "WLAN-Operator-A", the N3IWF 230 considers the ANI invalid. Similarly, when the N3IWF 230 receives a request to establish an IPsec SA from the IPv6 address 2001:db8:3c4d:15:a23d:45:l:l and the AOI in step 5 is different from "Cable-Operator-C", the N3IWF 230 considers the ANI invalid.

[0086] continue Figure 3B At step 7, N3IWF 230 selects AMF 235 based on the received AN-Params and local policy, as specified in Clause 6.3.5 of TS23.501, and forwards the registration request received from UE 205 to the selected AMF 235 within the initial UE message (see Message Transmission 335). This message is expanded (e.g., with new information elements) to also include the ANI received from UE 205.

[0087] From the received ANI, AMF 235 determines the Radio Access Type (RAT) of the untrusted non-3GPP access used by UE 205 (see box 340). Specifically: if the ATT parameter in the ANI indicates "WLAN", AMF 235 sets RAT = "Untrusted-WLAN"; if the ATT parameter in the ANI indicates "Wireline", AMF 235 sets RAT = "Untrusted-Wireline"; if the ATT parameter in the ANI indicates "SNPN", AMF 235 sets RAT = "Untrusted-SNPN".

[0088] The additional parameter called "ANI-Validate" can be included in message 7 (in Figure 3B (Not shown in the image) Message 7 indicates whether the N3IWF attempted to verify the ANI provided by UE 205. AMF 235 can be configured to set RAT="Virtual" when the ANI is not verified by the N3IWF—for example, because AMF 235 does not trust the parameters provided by UE 205 and wants to avoid misuse of these parameters. Alternatively, AMF 235 can be configured to trust all or some of the ANI parameters provided by UE 205 even if the ANI is not verified by N3IWF 230, and set the RAT value as defined above.

[0089] At step 8, additional steps of the normal registration process as specified in Clause 4.12.2 of TS23.502 are performed (see box 345).

[0090] At step 9, AMF 235 sends an AM policy control request to PCF to receive the Access Management (AM) policy for UE 205 (see message transmission 350). Note that the RAT type provided to PCF 240 is set according to the RAT type derived by AMF 235 in step 7. This allows PCF 240 to derive the AM policy based on the specific type of untrusted non-3GPP access 210 used by UE 205.

[0091] When UE 205 requests a PDU session (in) Figure 3B When (not shown in the diagram), AMF 235 also provides the RAT type to SMF 245, and SMF 245 forwards the RAT type to PCF 240 when requesting a session management (SM) policy. This allows PCF 240 to derive the SM policy based on the specific type of the untrusted non-3GPP access 210 used by UE 205. Note that SMF 245 derives the session management context for the PDU session, which includes the session management policy received from PCF 240.

[0092] At step 10, the registration process for the 5G core is completed, for example, using the additional steps specified in Clause 4.12.2 of TS23.502 (see box 355).

[0093] The above process focuses on the ATT parameter and illustrates how this parameter is used by the AMF to determine the RAT type of untrusted non-3GPP access. Note that, as discussed in step 6, the AOI can be used to verify the ANI provided by UE 205. Generally, ANId and AOI can also be provided from AMF 235 to PCF 240 and SMF 245 and can be used to derive policies based on the identity of the access network and / or based on the operator of the access network. For example, the 5G core can be configured to deny UE 205 attempting to register from a wireline access point of operator-A, but allow UE 205 attempting to register from a wireline access point of operator-B.

[0094] In an alternative embodiment, UE 205 does not need to obtain the ANI as specified in step 1 of procedure 300, nor does it need to provide the ANI to N3IWF 230. However, N3IWF 230 is configured with an ANI mapping table that can be used to derive the ANI based on the source IP address with which it established the IPsec SA.

[0095] This source IP address can be the UE's IP address if the UE 205 is assigned a public IP address, or it can be a different IP address if the UE 205 is assigned a private IP address. Figure 2A-2C In the image, the source IP address is shown as IP@1*, IP@2*, and IP@3*.

[0096] Table 1 is an example of an ANI mapping table with 3 rows:

[0097] Table 1

[0098] IP address space ATT ANId AOI 16.3.0.0 / 16 WLAN Airport Hotspots WLAN-Operator-A 191.23.4.0 / 8 SNPN MCC+MNC+NID Car-Vendor-B 2001:db8:3c4d:15:: / 64 Wireline none Cable-Operator-C

[0099] Based on the ANI mapping table above, when the N3IWF 230 receives a request to establish an IPsec SA from the source IPv4 address 16.3.1.1, it determines the ANI from the first row of the table. Similarly, when the N3IWF 230 receives a request to establish an IPsec SA from the source IPv6 address 2001:db8:3c4d:15:a23d:45:1:1, it determines the ANI from the third row of the table.

[0100] In an alternative embodiment, N3IWF 230 in Figure 3B In message transmission 340, the determined ANI is provided to AMF235 (i.e., step 7), and AMF235 derives the RAT type as discussed above.

[0101] Figure 4An embodiment of a user equipment device 400, which can be used to determine an untrusted access network (RAT) according to embodiments of the present disclosure, is depicted. The user equipment device 400 may be an embodiment of a remote unit 105 and / or a UE 205. Furthermore, the user equipment device 400 may include a processor 405, a memory 410, an input device 415, an output device 420, and a transceiver 425. In some embodiments, the input device 415 and the output device 420 are combined into a single device, such as a touchscreen. In some embodiments, the user equipment device 400 does not include any input device 415 and / or output device 420.

[0102] As depicted, transceiver 425 includes at least one transmitter 430 and at least one receiver 435. Here, transceiver 425 communicates with a mobile core network (e.g., 5GC) via an access network. Additionally, transceiver 425 may support at least one network interface 440. Here, at least one network interface 440 facilitates communication with an eNB or gNB (e.g., using a "Uu" interface). Furthermore, at least one network interface 440 may include an interface for communication with an AMF, SMF, and / or UPF.

[0103] In one embodiment, processor 405 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 405 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 405 executes instructions stored in memory 410 to perform the methods and routines described herein. Processor 405 is communicatively coupled to memory 410, input device 415, output device 420, and transceiver 425.

[0104] In various embodiments, processor 405 obtains an Access Technology Name (ANI) for a first access network, which includes the access technology type of the first access network. Processor 405 determines to register with a mobile communication network (e.g., 5GC) via the first access network using an untrusted registration process and sends a first request (e.g., an IKE_AUTH request) to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network. In other embodiments, the first request includes a service request instead of a registration request. In such embodiments, the first request also includes the obtained ANI.

[0105] After establishing a secure connection with the N3IWF, the processor 405 receives a response to the registration request (or service request) via transceiver 425, where the response depends on the RAT. For example, based on the RAT, the network can accept or reject the registration request (or service request). As another example, a policy can be derived based on the RAT.

[0106] In some embodiments, the processor 405 establishes a data connection (e.g., a PDU session) with a mobile communication network via a first access network. In such embodiments, the data connection can be configured to operate based on a RAT. For example, based on the RAT, the data connection may be denied or accepted. As another example, the data connection can operate under QoS and charging policies that depend on the RAT.

[0107] In some embodiments, obtaining the ANI includes querying a server in a first access network, which includes one of the following: a DHCP server and an ANQP server. In a further embodiment, obtaining the ANI includes sending a DHCP request and receiving a DHCP Ack containing an access network identifier option (e.g., as defined in RFC 5839). In such embodiments, the ANI is derived based on parameters included in the access network identifier option. In some embodiments, the parameters in the access network identifier option include access technology type, access network identifier, and carrier identifier.

[0108] In some embodiments, obtaining the ANI includes receiving broadcast data from the first access network and deriving the ANI based on parameters in the broadcast data. In some embodiments, the ANI obtained in the first request is verified by the N3IWF, wherein the mobile communication network uses the obtained ANI to determine the RAT of the first access network only when the obtained ANI is successfully verified.

[0109] In one embodiment, memory 410 is a computer-readable storage medium. In some embodiments, memory 410 includes volatile computer storage media. For example, memory 410 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 410 includes non-volatile computer storage media. For example, memory 410 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 410 includes both volatile and non-volatile computer storage media. In some embodiments, memory 410 stores data related to determining the RAT of an untrusted access network, such as storing ANI, IP address, etc. In some embodiments, memory 410 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on user equipment device 400, and one or more software applications.

[0110] In one embodiment, input device 415 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 415 may be integrated with output device 420, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 415 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 415 includes two or more different devices, such as a keyboard and a touch panel.

[0111] In one embodiment, output device 420 may include any known electronically controllable display or display device. Output device 420 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 420 includes an electronic display capable of outputting visual data to a user. For example, output device 420 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 420 may include wearable displays, such as smartwatches, smart glasses, heads-up displays, etc. Furthermore, output device 420 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0112] In some embodiments, output device 420 includes one or more speakers for generating sound. For example, output device 420 may generate an auditory alarm or notification (e.g., a buzzer or beep). In some embodiments, output device 420 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 420 may be integrated with input device 415. For example, input device 415 and output device 420 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of output device 420 may be located near input device 415.

[0113] As discussed above, transceiver 425 communicates with one or more network functions of a mobile communication network via one or more access networks. Transceiver 425 operates under the control of processor 405 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 405 may selectively activate the transceiver (or a portion thereof) at specific times to facilitate sending and receiving messages.

[0114] Transceiver 425 may include one or more transmitters 430 and one or more receivers 435. Although only one transmitter 430 and one receiver 435 are illustrated, user equipment device 400 may have any suitable number of transmitters 430 and receivers 435. Furthermore, transmitters 430 and receivers 435 may be of any suitable type. In one embodiment, transceiver 425 includes a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum.

[0115] In some embodiments, a first transmitter / receiver pair for communicating with a mobile communication network on licensed radio spectrum and a second transmitter / receiver pair for communicating with a mobile communication network on unlicensed radio spectrum may be combined into a single transceiver unit, such as a single chip performing functions applicable to both licensed and unlicensed radio spectrum. In some embodiments, the first transmitter / receiver pair and the second transmitter / receiver pair may share one or more hardware components. For example, certain transceivers 425, transmitters 430, and receivers 435 may be implemented as physically separate components that access shared hardware and / or software resources, such as, for example, a network interface 440.

[0116] In various embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a single hardware component, such as a multi-transceiver chip, system-on-a-chip, ASIC, or other type of hardware component. In some embodiments, one or more transmitters 430 and / or one or more receivers 435 may be implemented and / or integrated into a multi-chip module. In some embodiments, other components such as network interface 440 or other hardware components / circuitets may be integrated with any number of transmitters 430 and / or receivers 435 into a single chip. In such embodiments, transmitters 430 and receivers 435 may be logically configured as a transceiver 425 using a more common control signal, or implemented as modular transmitters 430 and receivers 435 implemented in the same hardware chip or multi-chip module.

[0117] Figure 5 An embodiment of a network device apparatus 500, according to embodiments of the present disclosure, is depicted for use in determining a RAT (Reliable Access Tag) of an untrusted access network. In some embodiments, the network device apparatus 500 may be an embodiment of 5G-RG. Furthermore, the network device apparatus 500 may include a processor 505, a memory 510, an input device 515, an output device 520, and a transceiver 525. In some embodiments, the input device 515 and the output device 520 are combined into a single device, such as a touchscreen. In some embodiments, the network device apparatus 500 does not include any input device 515 and / or output device 520.

[0118] As depicted, transceiver 525 includes at least one transmitter 530 and at least one receiver 535. Here, transceiver 525 communicates with one or more remote units 105. Additionally, transceiver 525 may support at least one network interface 540, such as... Figure 1 The NWu interface is depicted in the diagram. In some embodiments, transceiver 525 supports a first interface for communicating with RAN nodes, a second interface for communicating with one or more network functions in the mobile core network (e.g., 5GC), and a third interface for communicating with remote units (e.g., UEs).

[0119] In one embodiment, processor 505 may include any known controller capable of executing computer-readable instructions and / or performing logical operations. For example, processor 505 may be a microcontroller, microprocessor, central processing unit (“CPU”), graphics processing unit (“GPU”), auxiliary processing unit, field-programmable gate array (“FPGA”), or similar programmable controller. In some embodiments, processor 505 executes instructions stored in memory 510 to perform the methods and routines described herein. Processor 505 is communicatively coupled to memory 510, input device 515, output device 520, and transceiver 525.

[0120] In various embodiments, network device 500 operates as an N3IWF. In such embodiments, transceiver 525 supports a first network interface for communicating with remote units via a first access network and a second network interface for communicating with the AMF in the mobile core network.

[0121] In some embodiments, processor 505 receives a first request (e.g., an IKE_AUTH request) from a remote unit to establish a secure connection. Here, the first request includes a registration request for the mobile communication network, a first source address, and an Access Point Name (ANI) for the first access network. Processor 505 uses the first source address and ANI to verify the ANI and sends a first message including the registration request and the ANI to the AMF, wherein the ANI is used by the AMF to determine the Range Attempt (RAT) of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT. In some embodiments, the first request includes a service request instead of a registration request.

[0122] In some embodiments, the ANI includes an operator identifier. In such embodiments, verifying the ANI includes comparing a first source address with a pre-configured address space selected using the operator identifier, wherein the ANI is successfully verified in response to a first source address belonging to the pre-configured address space. In some embodiments, a first message given to the AMF includes an indication of whether the ANI has been successfully verified, wherein the AMF further determines the RAT based on whether the ANI has been successfully verified. In some embodiments, the first source address is the source IP address of the packet containing the first request (e.g., an IKE_AUTH request). Note that if a network address translator is present in the data path, the first source address will not be the IP address of the UE.

[0123] In some embodiments, processor 505 receives a first request (e.g., an IKE_AUTH request) from a remote unit to establish a secure connection. Here, the first request includes a registration request for the mobile communication network and a first source address. Processor 505 uses the first source address to obtain an Access Technology Name (ANI) for the first access network, including the access technology type of the first access network, and sends a first message to the AMF including the registration request and the obtained ANI, wherein the obtained ANI is used by the AMF to determine the Resource Acquisition Type (RAT) of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT. In some embodiments, the first request includes a service request instead of a registration request, and the network processes the service request based on the determined RAT.

[0124] In some embodiments, obtaining an ANI includes using a pre-configuration table containing ANIs for a first address space, wherein the first source address belongs to the first address space.

[0125] In various embodiments, network device 500 operates as an AMF (Advanced Mobile Functions). In such an embodiment, transceiver 525 supports a first network interface for communication with an N3IWF (Internet Protocol Version 1) in a mobile communication network and a processor 505 for receiving a first message via the N3IWF, the first message including a registration request for a remote unit connected to the N3IWF via a first access network. Here, the first message also includes an ANI (Access Provider Interface) for the first access network. Processor 505 uses the ANI to determine the RAT (Registered Access Point) of the first access network and determines whether to accept the registration request based on the determined RAT. Processor 505 sends a response to the registration request to the remote unit via the first network interface.

[0126] In some embodiments, receiving the first message includes receiving an indication from the N3IWF regarding whether the ANI has been successfully authenticated. In such embodiments, the RAT is further determined based on whether the ANI has been successfully authenticated. In some embodiments, the processor 505 further sends a policy request, including the RAT, to a policy control function via a second network interface, wherein the policy control function derives an access management policy for the remote unit based on the RAT.

[0127] In some embodiments, the processor 505 further receives a request via the N3IWF to establish a data connection (e.g., a PDU session) for the remote unit, and sends a session context creation request to the session management function via a second network interface. In such embodiments, the session context creation request includes a RAT, wherein the session management function derives a session context creation based on the RAT, including a session management policy for the remote unit. The session management policy for the session context is retrieved from the policy control function by the session management policy.

[0128] In one embodiment, memory 510 is a computer-readable storage medium. In some embodiments, memory 510 includes volatile computer storage media. For example, memory 510 may include RAM, including dynamic RAM (“DRAM”), synchronous dynamic RAM (“SDRAM”), and / or static RAM (“SRAM”). In some embodiments, memory 510 includes non-volatile computer storage media. For example, memory 510 may include a hard disk drive, flash memory, or any other suitable non-volatile computer storage device. In some embodiments, memory 510 includes both volatile and non-volatile computer storage media. In some embodiments, memory 510 stores data related to determining the RAT of an untrusted access network, such as storing ANI, IP address, UE context, etc. In some embodiments, memory 510 also stores program code and related data, such as an operating system (“OS”) or other controller algorithms operating on network device apparatus 500, and one or more software applications.

[0129] In one embodiment, input device 515 may include any known computer input device, including a touch panel, buttons, keyboard, stylus, microphone, etc. In some embodiments, input device 515 may be integrated with output device 520, for example, as a touchscreen or similar touch-sensitive display. In some embodiments, input device 515 includes a touchscreen, allowing text to be entered using a virtual keyboard displayed on the touchscreen and / or by handwriting on the touchscreen. In some embodiments, input device 515 includes two or more different devices, such as a keyboard and a touch panel.

[0130] In one embodiment, output device 520 may include any known electronically controllable display or display device. Output device 520 may be designed to output visual, auditory, and / or tactile signals. In some embodiments, output device 520 includes an electronic display capable of outputting visual data to a user. For example, output device 520 may include, but is not limited to, LCD displays, LED displays, OLED displays, projectors, or similar display devices capable of outputting images, text, etc., to a user. As another non-limiting example, output device 520 may include wearable displays, such as smartwatches, smart glasses, heads-up displays, etc. Furthermore, output device 520 may be a component of a smartphone, personal digital assistant, television, desktop computer, laptop computer, personal computer, vehicle dashboard, etc.

[0131] In some embodiments, output device 520 includes one or more speakers for generating sound. For example, output device 520 may generate an auditory alarm or notification (e.g., a buzzer or beep). In some embodiments, output device 520 includes one or more haptic devices for generating vibration, motion, or other haptic feedback. In some embodiments, all or part of output device 520 may be integrated with input device 515. For example, input device 515 and output device 520 may form a touchscreen or similar touch-sensitive display. In other embodiments, all or part of output device 520 may be located near input device 515.

[0132] As discussed above, transceiver 525 can communicate with one or more remote units and / or with one or more interoperability functions that provide access to one or more PLMNs. Transceiver 525 can also communicate with one or more network functions (e.g., in mobile core network 140). Transceiver 525 operates under the control of processor 505 to transmit messages, data, and other signals, and also to receive messages, data, and other signals. For example, processor 505 can selectively activate the transceiver (or a portion thereof) at specific times to facilitate sending and receiving messages.

[0133] Transceiver 525 may include one or more transmitters 530 and one or more receivers 535. In some embodiments, one or more transmitters 530 and / or one or more receivers 535 may share transceiver hardware and / or circuitry. For example, one or more transmitters 530 and / or one or more receivers 535 may share antennas, antenna tuners, amplifiers, filters, oscillators, mixers, modulators / demodulators, power supplies, etc. In one embodiment, transceiver 525 implements multiple logical transceivers using different communication protocols or protocol stacks while using common physical hardware.

[0134] Figure 6 A method 600 for determining an untrusted access network (RAT) according to embodiments of the present disclosure is described. In some embodiments, method 600 is performed by a UE such as remote unit 105, UE 205, and / or user equipment device 400. In some embodiments, method 600 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0135] Method 600 begins and obtains 605 an Access Technology Name (ANI) for the first access network, which includes the access technology type used for the first access network. Method 600 includes determining 610 to register with the mobile communication network (e.g., 5GC) via the first access network using an untrusted registration process. Method 600 includes sending 615 a first request (e.g., an IKE_AUTH request) to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network. Method 600 includes receiving 620 a response to the registration request after establishing a secure connection with the N3IWF, wherein the response depends on the RAT. For example, the registration request can be accepted or rejected based on the RAT. As another example, the network can derive a strategy for UE registration based on the RAT. Method 600 ends.

[0136] Figure 7 A method 700 for determining a RAT (Reliable Access Tag) of an untrusted access network according to embodiments of the present disclosure is described. In some embodiments, method 700 is performed by an interconnecting device such as N3IWF 153, N3IWF 230, and / or network device 500. In some embodiments, method 700 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0137] Method 700 begins and receives a first request (e.g., an IKE_AUTH request) from a remote unit at 705 to establish a secure connection. Here, the first request includes a registration request for the mobile communication network, a first source address, and an ANI (Access Entity Name) for the first access network. Method 700 includes verifying the ANI using the first source address and ANI at 710. Method 700 includes sending a first message (715) to the AMF (Access Provider Function) including the registration request and the ANI, wherein the ANI is used by the AMF to determine the RAT (Registered Access Point) for the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT. Method 700 ends.

[0138] Figure 8 A method 800 for determining a RAT (Registered Access Tag) of an untrusted access network according to embodiments of the present disclosure is described. In some embodiments, method 800 is performed by access and mobility management functions such as AMF 143, AMF 235, and / or network device 500. In some embodiments, method 800 may be executed by a processor such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0139] Method 800 begins and receives a first message 805 via N3IWF, the first message including a registration request for a remote unit connected to N3IWF via a first access network. Here, the first message also includes an ANI (Access NI) for the first access network. Method 800 includes using the ANI to determine 810 the RAT (Registered Access Point) of the first access network. Method 800 includes determining 815 whether to accept the registration request based on the determined RAT. Method 800 includes sending 820 a response to the registration request to the remote unit. Method 800 ends.

[0140] Figure 9 A method 900 for determining a RAT (Reliable Access Tag) of an untrusted access network according to embodiments of the present disclosure is described. In some embodiments, method 900 is performed by an interconnecting device such as N3IWF 153, N3IWF 230, and / or network device 500. In some embodiments, method 900 may be performed by a processor that executes program code, such as a microcontroller, microprocessor, CPU, GPU, auxiliary processing unit, FPGA, etc.

[0141] Method 900 begins by receiving, from a remote unit, a first request (e.g., an IKE_AUTH request) to establish a secure connection (905). Here, the first request includes a registration request for the mobile communication network and a first source address. Method 900 includes obtaining, using the first source address, an Access Technology Name (ANI) for the first access network (910), which includes the access technology type of the first access network. Method 900 includes sending a first message (915) to the AMF. In such an embodiment, the first message includes the registration request and the obtained ANI, wherein the obtained ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT. Method 900 ends.

[0142] This document discloses a first apparatus for determining the Reference Technology Acquisition (RAT) of an untrusted access network according to embodiments of this disclosure. The first apparatus may be implemented by a remote unit 105, a UE 205, and / or a user equipment apparatus 400. The first apparatus includes a processor and a transceiver communicating with a first access network. The processor obtains an Access Technology Type Information (ANI) for the first access network, including the access technology type of the first access network. The processor determines to register with a mobile communication network (e.g., 5GC) via the first access network using an untrusted registration process and sends a first request (e.g., an IKE_AUTH request) to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network. The processor receives a response to the registration request via the transceiver after establishing a secure connection with the N3IWF, wherein the response depends on the RAT. For example, the network may accept or reject the registration request based on the RAT. As another example, a strategy may be derived based on the RAT.

[0143] In some embodiments, the processor establishes a data connection (e.g., a PDU session) with a mobile communication network via a first access network. In this embodiment, the data connection can be configured to operate based on a RAT. For example, a RAT-based data connection can be rejected or accepted. As another example, the data connection can operate according to QoS and charging policies dependent on the RAT.

[0144] In some embodiments, obtaining the ANI includes querying a server in a first access network, which includes one of the following: a DHCP server and an ANQP server. In a further embodiment, obtaining the ANI includes issuing a DHCP request and receiving a DHCP Ack (e.g., as defined in RFC 5839) containing an access network identifier option. In this embodiment, the ANI is derived based on parameters included in the access network identifier option. In some embodiments, the parameters in the access network identifier option include access technology type, access network identifier, and carrier identifier.

[0145] In some embodiments, obtaining the ANI includes receiving broadcast data from the first access network and deriving the ANI based on parameters in the broadcast data. In some embodiments, the ANI obtained in the first request is verified by the N3IWF, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network only when the obtained ANI is successfully verified.

[0146] This document discloses a first method for determining the Registered Access Technology (RAT) of an untrusted access network. The first method can be performed by a remote unit 105, a UE 205, and / or a user equipment device 400. The first method includes obtaining an Access Technology Type (ANI) for the first access network, including the access technology type of the access network. The first method includes determining whether to register with a mobile communication network (e.g., 5GC) via the first access network using an untrusted registration process and sending a first request (e.g., an IKE_AUTH request) to establish a secure connection with an N3IWF in the mobile communication network. Here, the first request includes a registration request to the mobile communication network and the obtained ANI, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network. The first method includes receiving a response to the registration request after establishing a secure connection with the N3IWF, wherein the response depends on the RAT. For example, the registration request can be accepted or rejected based on the RAT. As another example, the network can derive a strategy for UE registration based on the RAT.

[0147] In some embodiments, the first method includes establishing a data connection (e.g., a PDU session) with a mobile communication network via a first access network. In this embodiment, the data connection can be configured to operate based on a RAT. For example, a RAT-based data connection can be rejected or accepted. As another example, the data connection can operate according to QoS and charging policies dependent on the RAT.

[0148] In some embodiments, obtaining an ANI may include querying a server in a first access network, which includes one of the following: a DHCP server and an ANQP server. In a further embodiment, obtaining an ANI includes issuing a DHCP request and receiving a DHCP Ack (e.g., as defined in RFC 5839) containing an access network identifier option, wherein the ANI is derived based on parameters included in the access network identifier option. In some embodiments, the parameters in the access network identifier option include access technology type, access network identifier, and carrier identifier.

[0149] In some embodiments, obtaining the ANI includes receiving broadcast data from the first access network and deriving the ANI based on parameters in the broadcast data. In some embodiments, the ANI obtained in the first request is verified by the N3IWF, wherein the obtained ANI is used by the mobile communication network to determine the RAT of the first access network only when the obtained ANI is successfully verified.

[0150] This document discloses a second apparatus for determining the Range Attack (RAT) of an untrusted access network according to embodiments of this disclosure. The second apparatus may be implemented by N3IWF 153, N3IWF 230, and / or network device 500. The second apparatus includes a first network interface for communicating with a remote unit via a first access network and a second network interface for communicating with an AMF in a mobile core network. The second apparatus also includes a processor that receives a first request (e.g., an IKE_AUTH request) from the remote unit to establish a secure connection. Here, the first request includes a registration request for the mobile communication network, a first source address, and an Access Point Indicator (ANI) for the first access network. The processor uses the first source address and the ANI to verify the ANI and sends a first message to the AMF including the registration request and the ANI, wherein the ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT.

[0151] In some embodiments, the ANI includes an operator identifier. In this embodiment, verifying the ANI includes comparing a first source address with a pre-configured address space selected using the operator identifier, wherein the ANI is successfully verified in response to the first source address belonging to the pre-configured address space. In some embodiments, a first message given to the AMF includes an indication of whether the ANI has been successfully verified, wherein the AMF further determines the RAT based on whether the ANI has been successfully verified. In some embodiments, the first source address is the source IP address of the packet containing the first request (e.g., an IKE_AUTH request). Note that if a network address translator is present in the data path, the first source address will not be the IP address of the UE.

[0152] This document discloses a second method for determining the Range Attack (RAT) of an untrusted access network according to embodiments of this disclosure. The second method can be performed by N3IWF 153, N3IWF 230, and / or network device 500. The second method includes receiving a first request (e.g., an IKE_AUTH request) from a remote unit to establish a secure connection. Here, the first request includes a registration request for the mobile communication network, a first source address, and an Access Point Indicator (ANI) for the first access network. The second method includes verifying the ANI using the first source address and ANI of the remote unit and sending a first message including the registration request and the ANI to the AMF, wherein the ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT.

[0153] In some embodiments, the ANI includes an operator identifier, wherein verifying the ANI includes comparing a first source address with a pre-configured address space selected using the operator identifier, wherein the ANI is successfully verified in response to the first source address belonging to the pre-configured address space. In some embodiments, a first message given to the AMF includes an indication of whether the ANI has been successfully verified, wherein the AMF further determines the RAT based on whether the ANI has been successfully verified.

[0154] This document discloses a third apparatus for determining the Range Attack (RAT) of an untrusted access network according to embodiments of this disclosure. The third apparatus may be implemented by AMF 143, AMF 235, and / or network device 500. The third apparatus includes: a first network interface that communicates with an N3IWF in a mobile communication network; and a processor that receives, via the N3IWF, a first message including a registration request for a remote unit connected to the N3IWF via the first access network. Here, the first message also includes an Access Name Information (ANI) regarding the first access network. The processor uses the ANI to determine the RAT of the first access network and determines whether to accept the registration request based on the determined RAT. The processor sends a response to the registration request to the remote unit via the first network interface.

[0155] In some embodiments, receiving the first message includes receiving an indication from the N3IWF whether the ANI has been successfully authenticated. In this embodiment, the RAT is further determined based on whether the ANI has been successfully authenticated. In some embodiments, the processor further sends a policy request, including the RAT, to a policy control function via a second network interface, wherein the policy control function derives an access management policy for the remote unit based on the RAT.

[0156] In some embodiments, the processor further receives a request via N3IWF to establish a data connection (e.g., a PDU session) for a remote unit and sends a session context creation request to the session management function via a second network interface. In such embodiments, the session context creation request includes a RAT, wherein the session management function derives a session context including a session management policy for the data connection based on the RAT.

[0157] This document discloses a third method for determining the Registered Access Point (RAT) of an untrusted access network according to embodiments of this disclosure. The third method can be performed by AMF 143, AMF 235, and / or network device 500. The third method includes receiving, via N3IWF, a first message including a registration request for a remote unit connected to N3IWF via a first access network. Here, the first message also includes an Access Name Information (ANI) regarding the first access network. The third method includes using the ANI to determine the RAT of the first access network. The third method includes determining, based on the determined RAT, whether to accept the registration request and sending a response to the registration request to the remote unit.

[0158] In some embodiments, receiving the first message includes receiving an indication from the N3IWF whether the ANI has been successfully authenticated. In this embodiment, the RAT is further determined based on whether the ANI has been successfully authenticated. In some embodiments, the third method includes sending a policy request, which includes the RAT, to a policy control function via a second network interface, wherein the policy control function derives an access management policy for the remote unit based on the RAT.

[0159] In some embodiments, the third method includes receiving a request via N3IWF to establish a data connection (e.g., a PDU session) for a remote unit. In this embodiment, the third method includes sending a session context creation request via a second network interface to a session management function, the session context creation request including a RAT, wherein the session management function derives a session context including a session management policy for the data connection based on the RAT.

[0160] This document discloses a fourth apparatus for determining the Range Attack (RAT) of an untrusted access network according to embodiments of this disclosure. The fourth apparatus may be implemented by N3IWF 153, N3IWF 230, and / or network device 500. The fourth apparatus includes a first network interface for communicating with a remote unit via a first access network and a second network interface for communicating with an AMF in a mobile core network. The fourth apparatus includes a processor that receives a first request (e.g., an IKE_AUTH request) from the remote unit to establish a secure connection. Here, the first request includes a registration request for the mobile communication network and a first source address. The processor uses the first source address to obtain an Access Technology Type Indicator (ANI) for the first access network, including the access technology type of the access network, and sends a first message to the AMF including the registration request and the obtained ANI, wherein the obtained ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT.

[0161] In some embodiments, obtaining an ANI includes using a pre-configuration table containing ANIs for a first address space, wherein the first source address belongs to the first address space.

[0162] This document discloses a fourth method for determining the Range Attack (RAT) of an untrusted access network according to embodiments of this disclosure. The fourth method can be performed by N3IWF 153, N3IWF 230, and / or network device 500. The fourth method includes receiving a first request (e.g., an IKE_AUTH request) from a remote unit to establish a secure connection. Here, the first request includes a registration request for a mobile communication network and a first source address. The fourth method includes using the first source address to obtain an Access Technology Type (ANI) for the first access network, including the access technology type of the access network, and sending a first message to the AMF. In this embodiment, the first message includes the registration request and the obtained ANI, wherein the obtained ANI is used by the AMF to determine the RAT of the first access network, and wherein the mobile communication network processes the registration request based on the determined RAT.

[0163] In some embodiments, obtaining an ANI includes using a pre-configuration table containing ANIs for a first address space, wherein the first source address belongs to the first address space.

[0164] The embodiments may be practiced in other specific forms. The described embodiments are to be considered illustrative in all respects only and not restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the meaning and scope of the claims should be covered within their scope.

Claims

1. A user equipment ("UE") apparatus, comprising: A transceiver that communicates with a first access network; as well as Processor, the processor: Obtain access network information ("ANI") about the first access network, wherein the ANI includes the access technology type of the first access network; It is determined that an untrusted registration process was used to register with the mobile communication network via the first access network; Send a first request to establish a secure connection with a non-3GPP interoperability function ("N3IWF") in the mobile communication network, the first request including a registration request for the mobile communication network and an obtained Access NI, wherein the obtained ANI is verified by the N3IWF, and the radio access type ("RAT") of the first access network is determined based on whether the ANI is successfully verified; and After establishing the secure connection with the N3IWF, a response to the registration request is received, wherein the response depends on the RAT.

2. The UE device according to claim 1, wherein, The processor establishes data with the mobile communication network via the first access network, wherein the data connection is configured to operate based on the RAT.

3. The UE device according to claim 1, wherein, Obtaining the ANI includes querying a server in the first access network, the server including one of the following: a Dynamic Host Configuration Protocol ("DHCP") server and an Access Network Query Protocol ("ANQP") server.

4. The UE device according to claim 3, wherein, Obtaining the ANI includes sending a DHCP request and receiving a DHCP Ack containing the Access Network Identifier option, wherein the ANI is derived based on parameters included in the Access Network Identifier option.

5. The UE device according to claim 4, wherein, The parameters in the access network identifier option include access technology type, access network identifier, and operator identifier.

6. The UE device according to claim 1, wherein, Obtaining the ANI includes receiving broadcast data from the first access network and deriving the ANI based on parameters in the broadcast data.

7. A method performed by a user equipment ("UE") device, comprising: Obtain access network information ("ANI") about a first access network, wherein the ANI includes the access technology type of the first access network; It is determined that an untrusted registration process was used to register with the mobile communication network via the first access network; Send a first request to establish a secure connection with a non-3GPP interoperability function ("N3IWF") in the mobile communication network, the first request including a registration request for the mobile communication network and an obtained ANI, wherein the obtained ANI is verified by the N3IWF, and the radio access type ("RAT") of the first access network is determined based on whether the ANI is successfully verified; and After establishing a secure connection with the N3IWF, a response to the registration request is received, wherein the response depends on the RAT.

8. A network device ("NE") apparatus, comprising: A first network interface that communicates with a non-3GPP interoperability function ("N3IWF") in a mobile communication network; and Processor, the processor: The first message is received via the N3IWF, the first message including a registration request for a remote unit connected to the N3IWF via a first access network and access network information ("ANI") about the first access network; The ANI is used to determine the radio access type ("RAT") of the first access network; The decision to accept the registration request is based on the determined RAT. as well as Send a response to the registration request to the remote unit. Receiving the first message includes receiving an indication from the N3IWF as to whether the ANI has been successfully verified, wherein the RAT is further determined based on whether the ANI has been successfully verified.

9. The NE device according to claim 8, wherein, The processor further sends a policy request to the policy control function via a second network interface. The policy request includes the RAT, wherein the policy control function derives an access management policy for the remote unit based on the RAT.

10. The NE device according to claim 8, wherein, The processor further receives a request to establish a data connection for the remote unit via the N3IWF, and sends a session context creation request to the session management function via the second network interface. The session context creation request includes the RAT, wherein the session management function derives a session context including a session management policy for the data connection based on the RAT.

11. A method performed by a network device ("NE"), comprising: A first message is received via a non-3GPP interoperability function ("N3IWF"), the first message including a registration request for a remote unit connected to the N3IWF via a first access network and access network information ("ANI") about the first access network; The ANI is used to determine the radio access type ("RAT") of the first access network; The decision on whether to accept the registration request is based on the determined RAT. as well as Send a response to the registration request to the remote unit. Receiving the first message includes receiving an indication from the N3IWF as to whether the ANI has been successfully verified, wherein the RAT is further determined based on whether the ANI has been successfully verified.