Method and process for addressing agreement of network functions in service-centric user equipment

Abstract

A method performed by a wireless transmit / receive unit (WTRU) for communicating with a network function (NF) may be provided. An example WTRU may determine a subscription persistent identifier (SUPI) and a SUPI type. The WTRU may determine a parent domain associated with the network node based on the SUPI type. The WTRU may determine a partially defined domain name (PQDN) associated with the network node. The WTRU may determine a fully defined domain name (FQDN) for the network node based on the parent domain and the PQDN. The WTRU may use the determined FQDN to transmit a message to the network node to address the network node.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 390,743 filed on July 20, 2022 and U.S. Provisional Patent Application No. 63 / 427,601 filed on November 23, 2022, the contents of which are hereby incorporated by reference into this document. Background Art

[0003] An Internet Protocol (IP) may be provided. IP may be used to provide a network address for a server on a network. IP may be used to provide a network address on a network to a wireless transmit / receive unit (WTRU). And other protocols may be used to provide a server address and / or a WTRU address. For example, a fully qualified domain name and / or a partially qualified domain name may be used. Summary of the invention

[0004] The present disclosure describes methods for wireless transmit / receive units (WTRUs) and / or network function consumers to determine the addressing identifier of a producer they are intended to reach, which may occur without going through a network resolution function. In some embodiments, when a WTRU begins to attach to a core network, a network resolution function (NRF) that may be part of the core network may not be available to the user equipment.

[0005] The identifier for the producer may be of a protocol type. For example, the identifier for the producer may be of an Internet Protocol (IP) address type or a fully qualified domain name (FQDN). In one example, the NRF may hold one or more network function (NF) registries and may be responsible (e.g., may only be responsible) for selecting which producer instance or which set of instances (e.g., a set of NFs) a consumer request may be transmitted to. In an end-to-end service based architecture, where the NAS may be replaced by the SBI and the Access and Mobility Management Function (AMF) on the WTRU, the WTRU may not have a way to contact the NRF to obtain the identifier for the producer they are intended to reach. In addition, if the WTRU is a producer, the core network consumers (other than the WTRU) may not have a way to address the WTRU.

[0006] Communication attempts by one or more consumers may involve one or more NRFs, which may be NRFs across one or more communication models (e.g., Model A, Model B, Model C, and / or Model D as described herein). This may create delays in establishing services and may create additional signaling, which may result in higher energy consumption. In one example, such as in a multi-vendor core network deployment, NFs may be provided by a vendor (e.g., a specific vendor), and the logic within the NRF for selecting an appropriate producer instance (e.g., the most appropriate producer instance) or set of NFs may be vendor dependent.

[0007] As described herein, devices, methods, and / or tools may be provided for unifying the naming convention of producer identifiers using FQDNs (e.g., only FQDNs), which may include the WTRU described herein. Devices, methods, and / or tools may be provided to address how one or more UEs may determine the FQDN (which may occur without communicating with the NRF), and devices, methods, and / or tools may be provided to provide signaling that one or more consumers (e.g., each consumer) may use to query the NRF for the identifier of the producer they want to reach. For example, a communication model (referred to herein as Model E) may be introduced to position a service communication proxy (SCP) as a transparent routing component that can be addressed indirectly. In some embodiments, the SCP may provide a programmable application programming interface (API) for configuration (e.g., constraints and affinities under which consumer instances and producer instances may be matched and / or kept together).

[0008] A method and / or WTRU for communicating with an NRF may be provided. Example A WTRU may determine a subscription permanent identifier (SUPI) and a SUPI type. The WTRU may determine a parent domain associated with the network node based on the SUPI type. The WTRU may determine a partially qualified domain name (PQDN) associated with the network node. The WTRU may determine a fully qualified domain name (FQDN) for the network node based on the parent domain and the PQDN. The WTRU may transmit a message to the network node using the determined FQDN to address the network node.

[0009] The message to the network node may include an access token request. The network node may be a network repository function (NRF). The WTRU may receive a message including an access token response message from the NRF. The network node may be an access and mobility management function (AMF). The message to the network node may include a packet data unit (PDU) session establishment request. The WTRU may determine a slice type or service type associated with the message to the network. The WTRU may modify the PQDN based on the slice type or service type.

[0010] In case the SUPI type is an International Mobile Subscriber Identity (IMSI), the WTRU may determine the parent domain associated with the network node based on the Mobile Country Code (MCC) as the top-level domain and the Mobile Network Code (MNC) as the sub-domain. In case the SUPI type is a Network Access Identifier (NAI), the WTRU may determine that the parent domain associated with the network node is the NAI. The WTRU may determine the SUPI and SUPI type by reading the SUPI and SUPI type from the Universal Subscriber Identity Module (USIM) of the WTRU.

[0011] The network node may be a network function (NF). The WTRU may determine a defined name associated with the NF. The WTRU may assign the defined name as a PQDN. The WTRU may receive a message from the network node based on the determined FQDN and a subscription hidden identifier (SUCI). The NF may be at least one of a network repository function (NRF), an access and mobility management function (AMF), a unified data management (UDM) function, a session management function (SMF), a policy control function (PCF), or a user plane function (UPF).

[0012] A first message may be transmitted to a network. The first message may indicate a request to attach to a network. The first message may indicate a subscription permanent identifier (SUPI). The first message may indicate a SUPI type. A second message may be received from the network. The second message may indicate a parent domain. A partially qualified domain name (PQDN) may be determined for the NRF. A fully qualified domain name (FQDN) may be determined for the NRF using the parent domain and the PQDN. A third message may be transmitted to the network. The third message may indicate a request for an access token. The third message may indicate the FQDN. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented;

[0014] Figure 1B is an example of an embodiment in which Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system;

[0015] Figure 1C is an example of an embodiment in which Figure 1A A system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system;

[0016] Figure 1D is an example of an embodiment in which Figure 1A A system diagram of another example RAN and another example CN used within the illustrated communication system;

[0017] Figure 2 is a system diagram illustrating an example system architecture, such as a 5G system, according to an embodiment;

[0018] Figure 3 is a system diagram illustrating an example system architecture, such as a 5G system, according to an embodiment;

[0019] Figure 4 is a message protocol diagram illustrating an example indirect communication model according to an embodiment;

[0020] Figure 5 is a message protocol diagram illustrating an example indirect communication model according to an embodiment;

[0021] Figure 6 An example structure of an identifier such as a Subscription Concealment Identifier (SUCI) is shown.

[0022] Figure 7 is a message protocol diagram illustrating a process for a consumer to retrieve consumer information from an SCP according to an embodiment; and

[0023] Figure 8 is a message protocol diagram illustrating a communication model for WTRU initiated control plane communication according to an implementation scheme.

[0024] Fig. 9 is a sample message sequence chart. DETAILED DESCRIPTION

[0025] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0026] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the UE 102a, 102b, 102c, 102d (any of which WTRU may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include a user equipment (WTRU), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0027] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device that is configured to interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NR Node B, a site controller, an access point (AP), a wireless router, and the like. Although the base stations 114a, 114b are each depicted as a single element, it should be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0028] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0029] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0030] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA, among others. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

[0031] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA) that may establish the air interface 116 using Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro).

[0032] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR radio access, which may establish the air interface 116 using New Radio (NR).

[0033] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 114a and the WTRUs 102a, 102b, 102c may together implement LTE radio access and NR radio access, for example using the dual connectivity (DC) principle. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and / or transmissions transmitted to / from multiple types of base stations (e.g., eNBs and gNBs).

[0034] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0035] Figure 1AThe base station 114b in may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial venues, homes, vehicles, campuses, industrial facilities, sky corridors (e.g., for use by drones), and roads. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. As Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0036] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not described in detail in the text and video, the CN 106 / 115 may be configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0037] The CN 106 / 115 may also act as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired communication networks and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.

[0038] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The illustrated WTRU 102c may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0039] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0040] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal decoding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0041] The send / receive element 122 may be configured to send a signal to a base station (e.g., base station 114a) or receive a signal from a base station via an air interface 116. For example, in one embodiment, the send / receive element 122 may be an antenna configured to send and / or receive an RF signal. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, an IR, UV, or visible light signal. In another embodiment, the send / receive element 122 may be configured to send and / or receive both an RF signal and an optical signal. It should be understood that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0042] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in the figure, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.

[0043] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. For example, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0044] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, and a secure digital memory card, among others. In other embodiments, the processor 118 may access information from and store data in a memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0045] The processor 118 may receive power from the power source 134, and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel cadmium (NiCd), nickel zinc (NiZn), nickel metal hydride (NiMH), lithium ion (Li-ion), etc.), solar cells, fuel cells, etc.

[0046] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0047] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, FM radio unit, digital music player, media player, video game player module, Internet browser, virtual reality and / or augmented reality (VR / AR) device and activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor; altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor and / or humidity sensor.

[0048] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0049] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0050] The RAN 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.

[0051] Each of the evolved Node Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, and scheduling of users in the UL and / or DL, among other things. Figure 1C As shown, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0052] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] The MME 162 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, and selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

[0054] The SGW 164 may be connected to each of the evolved Node-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring the user plane during an inter-evolved Node-B handover, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, and managing and storing the context of the WTRUs 102a, 102b, 102c.

[0055] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0056] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0057] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

[0058] In a representative embodiment, the other network 112 may be a WLAN.

[0059] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for a BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic away from the BSS. Traffic originating from outside the BSS and destined for the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and destined for a target outside the BSS may be transmitted to the AP to be delivered to the corresponding target. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the target STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be transmitted between the source STA and the target STA (e.g., directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

[0060] When using the 802.11ac infrastructure operation mode or a similar operation mode, the AP may send beacons on a fixed channel (such as a primary channel). The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel may be an operating channel of the BSS and may be used by the STA to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) may be implemented, for example, in an 802.11 system. For CSMA / CA, a STA (e.g., each STA) (including the AP) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0061] High throughput (HT) STAs may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

[0062] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and the data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

[0063] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument type control / machine type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

[0064] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only the 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

[0065] In the United States, the available frequency band for 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0066] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

[0067] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, the gNBs 180a, 180b may utilize beamforming to send signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a may, for example, use multiple antennas to send wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In an embodiment, gNBs 180a, 180b, 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0068] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or Transmission Time Intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths over time).

[0069] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNodeB 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNodeBs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNodeB 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0070] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0071] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possible data networks (DNs) 185a, 185b. Although each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0072] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling and mobility management, etc. The AMF 182a, 182b may use network slicing to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0073] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0074] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0075] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108 or may communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. In addition, the CN 115 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPF 184a, 184b via an N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0076] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more simulation devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0077] The simulation device may be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more simulation devices may perform one or more functions or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more simulation devices may perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The simulation device may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communications to perform testing.

[0078] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuits (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data. DETAILED DESCRIPTION

[0080] The present disclosure describes methods for wireless transmit / receive units (WTRUs) and / or network function consumers to determine the addressing identifier of a producer they are intended to reach, which may occur without going through a network resolution function (NRF). In some embodiments, when the WTRU begins to communicate with a core network (e.g., when the WTRU attempts to attach to the core network), the NRF may not be available. For example, when the WTRU requests an access token, the NRF may not be available.

[0081] The identifier for the producer may be of a protocol type. For example, the identifier for the producer may be of an Internet Protocol (IP) address type or a fully qualified domain name (FQDN). In one example, the NRF may hold one or more network function (NF) registries and may be responsible for selecting to which producer instance or which set of instances (e.g., a set of NFs) the consumer request will be transmitted to. In an end-to-end service based architecture (e.g., where the non-access network layer (NAS) protocol stack is replaced by SBI utilizing HTTP and the access and mobility management function (AMF) on the WTRU), the WTRU may not have a way to contact the NRF to obtain the identifier for the producer that the WTRU is intended to reach. In addition, if the WTRU is a producer, the core network consumers (e.g., other than the WTRU) may not have a way to address the WTRU.

[0082] Communication attempts by one or more consumers may involve one or more NRFs, which may be NRFs across one or more communication models (e.g., Model A, Model B, Model C, and / or Model D as described herein). This may delay establishment of service and may create additional signaling, which may result in higher energy consumption. In one example, such as in a multi-vendor core network deployment, the NF may be provided by a vendor (e.g., a specific vendor). The logic within the NRF to select an appropriate producer instance (e.g., the most appropriate producer instance) or set of NFs may rely on another (e.g., a specific) vendor.

[0083] As described herein, devices, methods and / or tools are provided for unifying the naming convention of producer identifiers using FQDNs (e.g., only FQDNs), which devices, methods and / or tools may include WTRUs. Devices, methods and / or tools are provided to address how one or more WTRUs can determine the FQDN. The WTRU can determine the FQDN without communicating with the NRF. The devices, methods and / or tools provided herein describe signaling that one or more consumers can use to query the NRF for the identifier of the producer that the consumer wants to reach. For example, a communication model (which may be referred to as model E in this article) may be introduced to position a service communication agent (SCP) as a transparent routing component that may not be explicitly addressed by an identifier (e.g., as defined in models C and D). For example, data and / or packets may be received and / or transmitted without using one or more addressing conventions. In some examples, the SCP may provide a programmable application programming interface (API) to configure constraints and / or affinities under which consumer instances and producer instances are matched and / or kept together.

[0084] A method and / or wireless / transmit-receive unit (WTRU) for communicating with a network node (e.g., NF) is provided herein. The WTRU may determine a subscription permanent identifier (SUPI) and a SUPI type (e.g., by reading the SUPI and / or SUPI type from a universal subscriber identity module (USIM) of the WTRU, such as Figure 8 shown).

[0085] A first message may be transmitted to a network. The first message may indicate a request to attach to the network. The first message may indicate a SUPI. The first message may indicate a SUPI type. The WTRU may determine a parent domain associated with a network node. For example, the WTRU may determine the parent domain based on information from a SIM in the WTRU. For example, the WTRU may read a public land mobile network identifier (PLMN ID) from the SIM and use the PLMN ID to form a parent domain, as described herein. A partially qualified domain name (PQDN) may be determined for a network node (e.g., NF) with which the WTRU may communicate (e.g., the PQDN may be associated with the network node and / or the NF). A fully qualified domain name (FQDN) may be determined for a network node (e.g., NF) based on (e.g., using) the parent domain and the PQDN. The first message may indicate a request for an access token. The first message may indicate the FQDN. The first message may be transmitted to the network, for example, by transmitting the message to a device (e.g., WTRU, server, etc.) using the FQDN. The device may connect to the network.

[0086] In one example, a second message may be received from the network. The second message may indicate an access token associated with the service and / or FQDN. The second message may indicate that the request for the access token has been denied. The second message may further indicate a reason why the request for the access token was denied.

[0087] This document uses the following abbreviations: API (Application Programming Interface), DNS (Domain Name System), FQDN (Fully Qualified Domain Name), IMSI (International Mobile Subscriber Identity), JSON (JavaScript Object Notation), NAI (Network Access Identifier), NAS (Non-Network Access Stratum), NSSAI (Network Slice Selection Assistance Information), NF (Network Function), MCC (Mobile Country Code), MNC (Mobile Network Code), PDQN (Partially Qualified Domain Name), PLMN (Public Land Mobile Network), SBA (Service Based Architecture), SBI (Service Based Interface), Slice / Service Type (SST), SUCI (Subscription Hidden Identifier), SUPI (Subscription Persistent Identifier).

[0088] Features associated with SBA are provided herein. For example, SBA may include features for a system architecture such as a 5G system architecture. Such features may include, for example, a service-based interface (SBI) for most interfaces of core network functions. SBI may implement, for example, HTTP / 2 as an application layer protocol with a payload encoded in JavaScript Object Notation (JSON). Such features may include, for example, a consumer capable of transmitting a request via a protocol (e.g., HTTP) and a producer capable of responding to a request via a protocol (e.g., HTTP). A consumer may be able to call a producer. An SBI-enabled interface may not use numbers for interface names, but may use acronyms for producers.

[0089] Figure 2 is a system diagram illustrating an example system architecture, such as a 5G system, according to an embodiment. For example, Figure 2 A service communication proxy (SCP) may be introduced into a system architecture such as a 5G system architecture. The SCP may be part of the core network but may not provide SBI. Figure 2 The example UE shown may be a WTRU capable of communicating with the AMF via N1 via N2. In one example, the N4 interface may not be SBI enabled.

[0090] An end-to-end service based architecture may be provided. For example, a revised end-to-end service based architecture may be provided. In an embodiment, the NAS protocol may be used over an interface, such as over N1, to take advantage of the SBA principle. For example, some embodiments may take advantage of an application protocol (e.g., HTTP) with an encoded payload (e.g., a JSON encoded payload) and / or remove the strict endpoint relationship of a particular interface (such as N1).

[0091] Figure 3 is a system diagram illustrating an example system architecture of a 5G system according to an implementation scheme. Figure 3 An example system architecture without N1 is depicted. In such a system architecture, the WTRU may utilize SCP to communicate (e.g., directly) with one or more core network functions. In an embodiment, a service-based interface (e.g., Nue interface) may be used in situations where the WTRU is a producer and the network is a consumer.

[0092] Features associated with direct communication models and indirect communication models are provided herein. For example, four communication models may be provided for SBI-enabled network function (NF) to NF communication. The four models may be classified as direct and indirect communication, wherein the direct model does not include SCP, and the indirect model includes SCP. For example, a first direct communication model (e.g., Model A) may not include NRF or SCP. In Model A, the consumer instance and the producer instance communicate directly with each other. A second direct communication model (e.g., Model B) may enable discovery of the producer instance to which the consumer should transmit its request via the NRF. After the NRF decides, the consumer may communicate directly with the producer.

[0093] Model C is an example of an indirect communication model. In Model C, the consumer may utilize NRF to discover which producer instance to select. NRF may inform the consumer about the addressing identifier of the SCP (e.g., the IP address or fully qualified domain name (FQDN) of the SCP). SCP may route requests and responses. Model D is another example of an indirect communication model. In Model D, the consumer may know (e.g., implicitly know) the addressing identifier (e.g., IP address or FQDN) of the SCP. The consumer may issue a request to (e.g., directly to) the SCP. The consumer may add discovery and selection parameters, thereby allowing the SCP to discover the appropriate producer instance via the NRF. SCP may route request and response packets.

[0094] Table 1 provides an overview of the example communication model described in this paper for NF-to-NF interaction:

[0095] Table 1

[0096]

[0097]

[0098] Figure 4 is a message protocol diagram illustrating an example indirect communication model according to an embodiment. For example, Figure 4 An indirect communication model according to Model C described herein is illustrated. Figure 4 Indirect communication without delegated discovery is illustrated. At 401, NF1 may be a consumer and request a producer identifier and an SCP identifier from the NRF. At 402, the NRF may respond with an identifier for NF2 (e.g., producer) and an SCP identifier. For example, Figure 4 In , NF2 can be registered under the host nf2.foo.com, and the SCP serving the NF is registered under scp.foo.com. At 403, NF1 can use the resource (e.g., Figure 4At 404, SCP may rewrite the HTTP header to the hostname of NF2 and route the request to the NF2 instance. At 405, NF2 may transmit back a response for the resource. At 406, SCP may route such response to consumer NF1.

[0099] Figure 5 is a message protocol diagram illustrating an example indirect communication model according to an embodiment. In an embodiment, an indirect communication model, such as Model D, may be provided. In Model D, a consumer may implicitly know the addressing identifier (e.g., IP address or FQDN) of an SCP and may issue a request directly to the SCP. A consumer request may also include, for example, discovery and / or selection parameters. The SCP may use such selection parameters to discover an appropriate producer instance via the NRF. The SCP may route request and response packets.

[0100] Figure 5 An example indirect communication model according to Model D as described herein may be illustrated. In an embodiment, a consumer may not perform producer discovery, but an SCP may perform producer discovery. The model may be represented as "delegated discovery". At 501, a consumer (e.g., NF1) may issue a request for a producer (e.g., NF2) hosted by an SCP. An identifier for the SCP may be implicitly known to NF1. At 502, the SCP may request an identifier for an instance of NF2 via the NRF. At message 503, the NRF may respond to the SCP with an identifier (e.g., nf2.foo.com). At 504, the SCP may replace the Host value with the Host value provided by the NRF, and the request may be routed to NF2. At 505, NF2 may respond to the request from the SCP. At 506, the SCP routes the response message from NF2 to NF1.

[0101] This article provides a sample Subscription Hidden Identifier (SUCI). Figure 6 An example structure of an identifier such as a SUCI is shown. The SUCI may include at least two fields (e.g., a SUPI type and a home network identifier). The SUPI type may define the type of SUPI hidden in the SUCI. For example, a value of 0 may correspond to an International Mobile Subscriber Identity (IMSI), a value of 1 may correspond to a Network Access Identifier (NAI), and values ​​2-7 may be reserved for other uses (e.g., future use). The home network identifier may be set by a home public land mobile network (HPLMN), and for a value of 0 SUPI type may include a mobile country code (MCC) and a mobile network code (MNC) of the IMSI. The home network identifier may include a variable length string representing a domain name for a value of 1 SUPI type.

[0102] Features associated with control and user plane separation achieved through network slicing are provided herein. The network slicing concept may support different QoS configurations (e.g., requirements) on the user plane. The network slicing concept may enable separation (e.g., entire separation) of core network instances specific to a network slice (e.g., identified via a predefined slice / service type (SST)). An optional slice differentiator (SD) may be used to distinguish network slices of the same type.

[0103] It may be beneficial to separate the UPFs (e.g., and related core network functions that control the respective UPFs, such as SMF, PCF, and / or AMF). For example, if one UPF implements a first type of communication for a first packet data unit (PDU) session type (e.g., standard best effort user plane communication for PDU session type IP) and another UPF implements a second type of communication for a second PDU session type (e.g., time sensitive networking for PDU session type Ethernet), the UPFs may be separated.

[0104] Support for Network Slice Selection Assistance Information (NSSAI) by the gNB and the AMF may be (pre-)configured (e.g., by the operator). If the provided NSID matches, the two endpoints may establish a connection via N2. When the WTRU requests a PDU Session, the WTRU may provide the NSID in the request to the AMF (e.g., among other information). The AMF may request (e.g., from the NSSF) the use of an NRF service or service endpoint. When asking the NRF for the FQDN or IP address of the SMF, the AMF may use the NSID and / or other information to determine which SMF service or service endpoint to use. The AMF may address the request for a new PDU Session (or any other PDU Session action, such as modification or release) to an SMF that is capable of configuring a UPF that provides support for the requested network slice (QoS).

[0105] The identifier for the producer may be of type IP address or FQDN. The NRF may hold one or more NF registrations. The NRF may be responsible for selecting to which producer instance or set of instances (e.g., set of NFs) the consumer request may be transmitted to. In an end-to-end service based architecture, where the SBI may replace the NAS on the WTRU and / or AMF, the WTRU may not have a way to contact the NRF to obtain the identifier for the producer that the WTRU is intended to reach. If the WTRU is a producer, the core network consumer (e.g., other than the WTRU) may not have a way to address the WTRU.

[0106] Communication attempts by one or more consumers may involve one or more NRFs across one or more communication models (e.g., communication models A, B, C, and D as described herein). This may delay establishing services and may create additional signaling, which may result in higher energy consumption. In a multi-vendor core network deployment, NFs may be provided by a specific vendor. The logic within the NRF for selecting an appropriate producer instance (or set of NFs) may depend on the specific vendor.

[0107] When network slicing is used to request a user plane with QoS specifications, the design of the system architecture may use various NFs to request information about which FQDN or IP address to use for the next producer (e.g., which may involve using yet another producer). These requests may introduce additional signaling, which may result in higher latency and power consumption (e.g., of the 5G core network).

[0108] Methods and / or devices for unifying the naming convention of producer identifiers using FQDN are provided herein. The WTRU may also use a naming convention. The methods and / or devices described herein provide techniques for one or more WTRUs to determine the FQDN without communicating with the NRF. Features associated with local support for network slices that are part of a unified naming convention for producers are provided herein. The methods and / or devices described herein provide additional signaling that one or more consumers can use to query the NRF for the identifier of the producer that the consumer wants to reach. Example service communication proxy models are provided herein. As described herein, Model C and Model D may allow the use of SCP for routing purposes. Model C may implement indirect communication without delegated discovery, while Model D may implement indirect communication with delegated discovery. Model C may enable consumers to discover appropriate producers via the NRF, while Model D may enable consumers to make requests directly to the SCP (e.g., with discovery and selection parameters included in the request). In indirect communication, the SCP may be addressed (e.g., directly addressed) using an IP address or FQDN, thereby adding logic regarding addressing of the SCP to the consumer.

[0109] This article provides an example communication model E. Model E can position the SCP as a transparent routing component that may not be directly addressed. The SCP can provide a programmable API that can be used to configure the constraints and affinities under which consumer instances and producer instances can be matched and kept together.

[0110] A naming convention for one or more producers is provided herein. In an embodiment, a producer may be identified by an IP address or an FQDN. For example, when an indirect communication model (e.g., Model C and / or Model D) is used, a producer may be identified by an FQDN, thereby allowing cloud local processes to occur. One or more consumers may communicate with the producer using an FQDN. This may, for example, enable a consumer specific implementation to avoid deployment specification implementations (e.g., such as the use of IP addresses). Avoidance of IP addresses may allow core network deployments to scale with any number of instances across a range of locations, independent of the specific implementation.

[0111] When the core network is deployed, one or more instances of the core network may collectively provide control plane services, thereby forming a common control plane service provided to the WTRU. This service provision is reflected in the FQDN through the definition of a parent domain (e.g., foo.com) to identify the service. For example, in the case of 5GC, the domain may be the name of the operator followed by the country in which it is deployed (e.g., foo.co.uk, foo.it, or foo.es for operator Foo in the United Kingdom (.co.uk), Italy (.it), or Spain (.es), respectively). Further differentiation of the core network deployment of the same operator to the same country may form part of the parent domain (e.g., dedicated network deployments or regional differentiation).

[0112] If a consumer requests to communicate with a NF, the consumer may know which NF to target because one or more SBIs may be provided. For example, if the AUSF requests to authenticate a user as part of a registration process, the AUSF may know that it can communicate with the UDM. The AUSF may construct an FQDN for the UDM so that the AUSF may address the UDM. The UDM (e.g., a defined name of the UDM, which may be implicitly known) may become a subdomain under a parent domain (e.g., udm.foo.com, where udm may be a subdomain of the parent domain foo.com). A subdomain may also be referred to as a PQDN. The same applies to other NFs. For example, the PQDN (e.g., subdomain) for an NRF may be nrf, the PQDN (e.g., subdomain) for an AMF may be amf, and so on.

[0113] In an embodiment, the WTRU may use HTTP-based communications when transmitting requests to the core network (e.g., attach, PDU session establishment, or mobility communications). In an embodiment, the WTRU may use HTTP-based communications to reach any NF in the core network and vice versa. The WTRU may be associated with a child domain (e.g., a unique child domain) under a parent domain. In an embodiment, the WTRU may behave as a producer.

[0114] Features associated with producer registration are provided herein. In an embodiment, a dedicated FQDN registration and / or deregistration API may be exposed by one or more SCPs. Such an API may include a routing layer that is able to obtain registration information about a particular producer, thereby allowing requests from consumers to be routed to the producer. Such registration information may include, for example, an identifier of the FQDN of the producer service (e.g., udm.foo.com), the producer's IP address, the transport layer port, and which transport layer protocol the producer uses. In an embodiment, the registration information may be provided to the SCP by, for example, the producer or an orchestration framework during core network deployment.

[0115] An example method for obtaining a parent domain of a deployed core network is provided herein. An example description is provided on how a consumer may obtain a parent domain to form an FQDN for requesting message construction from a producer deployed in the core network.

[0116] Features associated with core network functionality are provided herein. For example, if a consumer instance is started, the consumer may request information about the parent domain of the core network (e.g., to which the consumer belongs) in order to form an FQDN to communicate with other producers. In an embodiment, to avoid deploying specific parent domain values, the SCP may provide a dedicated API that allows the consumer to retrieve information about the consumer's parent domain and / or other consumer-specific information. In an embodiment, the FQDN under which the SCP may provide the API may be known to one or more consumers.

[0117] Figure 7 is a message protocol diagram illustrating an example process for a consumer to retrieve consumer information from an SCP. For example, Figure 7 A process for a consumer to utilize an example Nscp_Whoami request / response primitive is illustrated. At 701, a consumer may issue an Nscp_Whoami request to whoami.scp (e.g., using HTTP method POST) with the consumer's own MAC address as an identifier. In an embodiment, the process may be used by the WTRU and / or the consumer. At 702, the SCP may use the provided MAC address to find one or more details related to the consumer, such as those described herein (e.g., during deployment and registration). At 703, the SCP may respond to the consumer with an Nscp_Whoami response message that includes the PQDN of the consumer and / or parent domain.

[0118] In an embodiment, the WTRU may not be deployed in a similar manner to the core network, and therefore the SCP may need another way to obtain the parent domain to form the FQDN. The home network identifier of the SUCI may be used by the SCP to determine the parent domain value. In an example, if the consumer request SUPI type is IMSI, the home network identifier is a confirmed PLMN ID consisting of MCC and MNC. Following the convention that the FQDN has a country type or an organization type as the TDL (e.g., .uk for the United Kingdom), the MCC may be used as the TDL and the MNC as the subdomain. The parent domain (e.g., associated with a network node) may be determined based on the SUPI type. For example, under the condition that the SUPI type is IMSI, the parent domain is determined based on the mobile country code (MCC) as the top-level domain and the mobile network code (MNC) as the subdomain (e.g., if the SUPI type is IMSI, the MCC is 001, and the MNC is 01, the resulting parent domain may be 01.001). In an example, if the SUPI type is NAI, the home network identifier may include a variable length string representing a domain name. This string (eg, value) can be used directly as the parent domain (eg, if the SUPI type is a Network Access Identifier (NAI), the parent domain is the NAI). For example, if the NAI is foo.com, the parent domain can also be foo.com.

[0119] An example naming convention for producers supporting network slicing is provided.

[0120] The NSSAI may be added as a PQDN to the FQDN so that communication (e.g., direct communication) may be created between the consumer and the producer (e.g., without having to ask another producer for an FQDN or IP address that may be used to reach the producer). If the WTRU requests a PDU session, the WTRU may communicate a pre-configured NSSAI towards the AMF as part of the request, or the NSSAI may be provided by the UDM (e.g., in the SUCI) as part of the authentication response (e.g., an authentication response transmitted back to the WTRU). If authentication is complete, the WTRU may know the NSSAI and may use the NSSAI as a partial subdomain of the FQDN for the producer. The NSSAI may include an SST or an SST value. The NSSAI may form the FQDN (e.g., <nssai> . <producer>.<PARENT_DOMAIN> ) of the subdomain (e.g., the least significant subdomain).

[0121] PQDN (for example, <producer>) may be a defined name (eg, an acronym, such as an official acronym) of a NF implemented by a producer. The parent domain may be a PLMN ID or a NAI, as described herein.

[0122] Example WTRU initiated control plane communications are provided herein. For example, an SBI enabled WTRU may request an access token from an NRF (e.g., with or without NSSAI). In an embodiment, the core network consumer and the WTRU consumer may derive the parent domain by different methods, but in conjunction with the producer's PQDN (e.g., <producer>)The use of the parent domain can be similar.

[0123] Features associated with non-NSSAI based communications are provided.

[0124] An example is provided of how a WTRU forms a FQDN (eg, for use by an NRF to obtain an access token). Figure 8 is a message protocol diagram illustrating a communication model for WTRU-initiated control plane communications. As shown at 801, one or more producers may be registered. For example, a core network producer instance may be registered with the SCP. At 801.a, as part of the WTRU's attempt to attach to the network, the WTRU may read a home network identifier. In an embodiment, the SUPI type may be an IMSI including an MCC and an MNC. The home network identifier may be composed of an MCC and an MNC, and the resulting parent domain may follow the order mnc.mcc (e.g., 01.001, where 001 is a top-level domain and 01 is a subdomain). In an embodiment, the SUPI type may be a NAI. In such an embodiment, the home network identifier is a string representing a domain name (e.g., foo.com). At 801.b, the SCP may add information about a new producer instance to an information store. In an embodiment, if the SCP receives a request to determine an appropriate instance for a consumer, the SCP may look up an NRF instance.

[0125] An example WTRU communication with an NRF producer instance is illustrated at 802. The WTRU may obtain a parent domain (e.g., a home network identifier) ​​at 802.a and may form an FQDN by combining a PDQN (e.g., nrf) and the parent domain at 802.b. For example, if the SUPI type is IMSI, the FQDN may be nrf.01.001. If the SUPI type is NAI, the FQDN may be nrf.foo.com (e.g., using nrf as the PQDN and using foo.com as the parent domain). The WTRU may use the determined FQDN to transmit a message (e.g., NRF) to a network node to address the network node (e.g., the WTRU may issue a Nnrf_AccessToken_Get request to the FQDN determined in 802.b). In response to the Nnrf_AccessToken_Get request, the SCP may route the Nnrf_AccessToken_Get request to an appropriate instance from a stored list of registered producers (e.g., established at 801). The NRF may respond to the Nnrf_AccessToken_Get request with a Nnrf_AccessToken_Get response including the access token or a specific rejection. The SCP may route the response to the WTRU.

[0126] At 801.a, the WTRU may attempt to attach to the network and may read the home network identifier. If the SUPI type is IMSI, the home network identifier may be composed of the MCC and MNC, and the resulting parent domain may follow the order mnc.mcc (e.g., 01.001, where 001 may be the top-level domain and 01 is the subdomain). If the SUPI type is NAI, the home network identifier is a string representing a domain name (e.g., foo.com).

[0127] At 801.b, the SCP may add information about the producer instance to an internal list. This may allow the SCP to find available NRF instances (e.g., all available NRF instances) when a request (e.g., a new request) arrives and determine an appropriate instance that can serve the consumer.

[0128] At 802.a, the WTRU may attempt to communicate with the NRF to retrieve an access token. The WTRU may use the parent domain that has been previously obtained to form the FQDN for the NRF and may add the PQDN nrf to the parent domain (e.g., nrf.01.001 if the SUPI type is IMSI or nrf.foo.com if the SUPI type is a network access identifier).

[0129] At 802.b, the WTRU may form a FQDN for the NRF using nrf as the PQDN and foo.com as the parent domain, for example, if the SUCI type is a network access identifier.

[0130] At 802.c, the WTRU may issue a Nnrf_AccessToken_Get request to the FQDN determined at 802.b. The SCP may route the Nnrf_AccessToken_Get request to the appropriate instance from the list of registered producers.

[0131] At 802.d, the NRF may respond to the request with a Nnrf_AccessToken_Get response, which may include the access token (or a specific rejection). The Nnrf_AccessToken_Get response may be routed to the WTRU via the SCP.

[0132] Features associated with NSSAI based communications are provided.

[0133] An example addressing convention (including NSSAI) may involve the establishment of a PDU session. If the WTRU requests a PDU session, the AMF may use the NSSF to obtain the FQDN or IP address of the NRF configured to serve discovery requests (e.g., subsequent discovery requests) for the SMF and PCF.

[0134] Fig. 9 is a sample message sequence chart. Fig. 9 An example of an NSSAI-based addressing convention is illustrated.

[0135] At 901, the WTRU may read / obtain the NSSAI for the eMBB (eg, through pre-configuration or during an authentication process as described herein).

[0136] At 902, the WTRU may form a FQDN towards the AMF (e.g., as described herein). The WTRU may determine a slice type or service type associated with the message being transmitted to the AMF. The WTRU may modify the PQDN based on the slice type or service type. For example, the WTRU may add a slice type or service type (e.g., embb) or an SST value (e.g., 1) as a subdomain to the PQDN and the parent domain amf.foo.com (e.g., resulting in embb.amf.foo.com).

[0137] At 903, a PDU session establishment request may be transmitted to the AMF using the FQDN determined at 902 (eg, the host may be embb.amf.foo.com).

[0138] At 904, the AMF processing the request may know (e.g., implicitly know) that the AMF is serving the eMBB slice. The AMF may communicate with an appropriate NRF (e.g., an NRF reachable via embb.nrf.foo.com) to obtain the FQDN or IP address of the SMF.

[0139] At 905, the NRF may provide the FQDN of the SMF to the AMF (e.g., the SMF FQDN may be embb.smf.foo.com).

[0140] If an optional SD is used to differentiate slices of the same SST, one or more options may be considered. In a first example option, the SD may be used by the WTRU as a parent domain. <nssai>.<PRODUCER_ID> .<PLMN_ID> If SD is a 24-bit integer (e.g., a pure integer with a length of 24 bits), the resulting FQDN may start with an integer in the range 1 to 16,777,215, followed by the parent domain (e.g., <nssai>.<PRODUCER_ID> .<PLMN_ID> ).

[0141] In a second example option, the SD may not be used to form the FQDN. The NSSAI (eg, only the NSAAI) may be used to form the FQDN.

[0142] The UDM may convey addressing convention information (e.g., in the SUCI as part of authentication, where the NSSAI to be selected is communicated to the WTRU) so that the WTRU knows which addressing convention is implemented (e.g., in the core network to which the WTRU wants to attach). The WTRU may aim to resolve the FQDN formed with the SD as a subdomain. If the DNS server responds with a NXDOMAIN response (e.g., "FQDN cannot be resolved"), the WTRU may use the FQDN formed without the SD as a subdomain (e.g., formed using only the NSAAI).< / nssai> < / nssai> < / producer> < / producer> < / producer> < / nssai>

Claims

1. A wireless transmit / receive unit (WTRU) for communicating with a network node, the WTRU comprising: A processor, wherein the processor is configured to: Determine the Subscription Permanent Identifier (SUPI) and SUPI type; determining a parent domain associated with the network node based on the SUPI type; determining a partially qualified domain name (PQDN) associated with the network node; determining a fully qualified domain name (FQDN) for the network node based on the parent domain and the PQDN; as well as A message is transmitted to the network node using the determined FQDN to address the network node.

2. The WTRU of claim 1 , wherein the processor is configured to determine the parent domain associated with the network node based on the SUPI type comprises the processor being configured to: In case the SUPI type is an International Mobile Subscriber Identity (IMSI), the parent domain associated with the network node is determined based on a Mobile Country Code (MCC) as a top-level domain and a Mobile Network Code (MNC) as a sub-domain.

3. The WTRU of claim 1 , wherein the processor is configured to determine the parent domain associated with the network node based on the SUPI type comprises the processor being configured to: In case the SUPI type is a Network Access Identifier (NAI), determining that the parent domain associated with the network node is the NAI.

4. The WTRU of claim 1 , wherein the processor being configured to determine the SUPI and the SUPI type comprises the processor being configured to read the SUPI and the SUPI type from a Universal Subscriber Identity Module (USIM) of the WTRU.

5. The WTRU of claim 1 , wherein the network node comprises a network function (NF), and wherein the processor is configured to determine the PQDN associated with the network node comprises the processor being configured to: determining a name of a definition associated with the NF; and The defined name is assigned as the PQDN.

6. The WTRU of claim 1 , wherein the message to the network node is a first message, and wherein the processor is further configured to receive a second message from the network node based on the determined FQDN and a subscription concealment identifier (SUCI).

7. The WTRU of claim 1 , wherein: said message to said network node being a first message comprising a request for an access token; The network node comprises a network repository function (NRF); and The processor is further configured to receive a second message including an access token response message from the NRF.

8. The WTRU of claim 1 , wherein the network node comprises an access and mobility management function (AMF), and wherein the message to the network node comprises a packet data unit (PDU) session establishment request.

9. The WTRU of claim 1 , wherein the processor is configured to determine the FQDN for the network node based on the parent domain and the PQDN comprises the processor being configured to: determining a slice type or service type associated with the message; and The PQDN is modified based on the slice type or the service type.

10. The WTRU of claim 1, wherein the network node comprises a network function, and wherein the network function is at least one of a network repository function (NRF), an access and mobility management function (AMF), a unified data management (UDM) function, a session management function (SMF), a policy control function (PCF), or a user plane function (UPF).

11. A method for a wireless transmit / receive unit (WTRU) to communicate with a network node, the method comprising: Determine the Subscription Permanent Identifier (SUPI) and SUPI type; determining a parent domain associated with the network node based on the SUPI type; determining a partially qualified domain name (PQDN) associated with the network node; determining a fully qualified domain name (FQDN) for the network node based on the parent domain and the PQDN; as well as A message is transmitted to the network node using the determined FQDN to address the network node.

12. The method of claim 11, wherein determining the parent domain associated with the network node based on the SUPI type comprises: In case the SUPI type is an International Mobile Subscriber Identity (IMSI), the parent domain associated with the network node is determined based on a Mobile Country Code (MCC) as a top-level domain and a Mobile Network Code (MNC) as a sub-domain.

13. The method of claim 11, wherein determining the parent domain associated with the network node based on the SUPI type comprises: In case the SUPI type is a Network Access Identifier (NAI), determining that the parent domain associated with the network node is the NAI.

14. The method of claim 11, wherein determining the SUPI and the SUPI type comprises reading the SUPI and the SUPI type from a Universal Subscriber Identity Module (USIM) of the WTRU.

15. The method of claim 11, wherein the network node comprises a network function (NF), and wherein determining the PQDN associated with the network node comprises: determining a name of a definition associated with the NF; as well as The defined name is assigned as the PQDN.

16. The method of claim 11, wherein the message to the network node is a first message, and wherein the method further comprises receiving a second message from the network node based on the determined FQDN and a subscription concealment identifier (SUCI).

17. The method of claim 11, wherein: said message to said network node being a first message comprising a request for an access token; The network node comprises a network repository function (NRF); and The method also includes receiving a second message including an access token response message from the NRF.

18. The method of claim 11, wherein the network node comprises an access and mobility management function (AMF), and wherein the message to the network node comprises a packet data unit (PDU) session establishment request.

19. The method of claim 11, wherein determining the FQDN for the network node based on the parent domain and the PQDN comprises: determining a slice type or service type associated with the message; as well as The PQDN is modified based on the slice type or the service type.

20. The method of claim 11, wherein the network node comprises a network function, and wherein the network function is at least one of a network repository function (NRF), an access and mobility management function (AMF), a unified data management (UDM) function, a session management function (SMF), a policy control function (PCF), or a user plane function (UPF).

Images