Method and apparatus for handling network functions deployed in a customer's premises network.

Abstract

Methods, apparatus, and procedures for handling network functions (NFs) deployed in a customer's private network (CPN) in wireless communications are disclosed herein. For example, a wireless transceiver unit (WTRU) is configured to send a first registration message to an access and mobility management function (AMF) indicating a request for the AMF to proxy register a network function (NF) or NF group associated with the WTRU. The WTRU is further configured to receive a second registration message from the AMF indicating proxy registration information based on the first registration message, and to send a message to the AMF indicating NF profile information for the NF or NF group associated with the WTRU.

Description

Background Art

[0001] Cross - reference to related applications This application claims the priority and benefit of U.S. Patent Provisional Application No. 63 / 449,737, filed with the United States Patent and Trademark Office on March 3, 2023, the entire content of which is incorporated herein by reference as if fully set forth below for all applicable purposes.

[0002] Mobile communications using wireless communication continue to evolve. The fifth generation is sometimes called 5G. Previous (legacy) generations of mobile communications can be, for example, the fourth generation (4G) Long - Term Evolution (LTE). The embodiments disclosed herein generally relate to communication networks.

Summary of the Invention

[0003] One or more embodiments disclosed herein relate to methods, apparatuses, and procedures for handling network functions (NFs) deployed in a customer premise network (CPN) in wireless communications.

[0004] In one embodiment, a method implemented by a wireless transmit and / or receive unit (WTRU) for wireless communication includes sending a first registration message indicating a request for an access and mobility management function (AMF) to proxy - register a network function (NF) or NF group associated with the WTRU; receiving, from the AMF, a second registration message indicating proxy - registration information based on the first registration message; and sending a message indicating NF profile information of the NF or NF group associated with the WTRU to the AMF.

[0005] In one embodiment, a wireless transmit / receive unit (WTRU) for wireless communication comprises circuitry including a processor, a transmitter, a receiver, and / or memory. The WTRU is configured to send a first registration message to an Access and Mobility Management Function (AMF) indicating a request for the AMF to proxy register a Network Function (NF) or NF group associated with the WTRU. The WTRU is further configured to receive a second registration message from the AMF indicating proxy registration information based on the first registration message, and to send a message to the AMF indicating NF profile information for the NF or NF group associated with the WTRU.

[0006] In one embodiment, a device (e.g., a wireless transceiver unit (WTRU)) may include a processor configured to perform one or more actions. The device may send registration messages to an Access and Mobility Management Function (AMF), which indicate a request for the AMF to proxy register a Network Function (NF) or NF group associated with the device. The device may receive registration accept messages from the AMF. The device may send NF profile messages to the AMF, which indicate NF profile information about an NF or NF group associated with the device. The device may establish a Protocol Data Unit (PDU) session. The device may receive Internet Protocol (IP) address assignments.

[0007] In one embodiment, a network device (e.g., an AMF) may include a processor configured to perform one or more actions. The device may receive registration messages from a WTRU, which indicate a request for the network device to proxy register a network function (NF) or NF group associated with the WTRU. The device may send registration acceptance messages to the WTRU. The device may receive network function (NF) profile messages from the WTRU, which indicate NF profile information about the NF or NF group associated with the WTRU. The device may receive Internet Protocol (IP) address assignments, which indicate IP address information associated with the WTRU. The device may update the NF profile information based on the IP address information. Based on the updated NF profile information, the device may perform proxy registration for the NF or NF group associated with the WTRU.

[0008] In one embodiment, the above request may be for an NF group. An NF group may consist of multiple NFs. An NF profile message may indicate an NF group and parameters common to multiple NFs within the NF group. The parameters may include at least one of the fully qualified domain name (FQDN) associated with a WTRU, or an IP address indicated by an IP address assignment.

[0009] In one embodiment, a WTRU can be associated with a split customer premise network (CPN). An NF profile message can indicate multiple local network exposure functions (L-NEFs) associated with the split CPN, and priority information associated with the multiple L-NEFs. The NF profile message can be sent via an uplink non-access stratum (NAS) transport message.

[0010] In one embodiment, a WTRU can be associated with an evolved residential gateway (eRG). A WTRU, NF, and / or NF group can be associated with one or more of the following: a local network registration function (L-NRF), a local network publishing function (L-NEF), or a local network data analytics function (L-NWDAF). A WTRU and an NF or NF group can be associated with a local network. The local network can be a customer premises network (CPN). [Brief explanation of the drawing]

[0011] A more detailed understanding can be obtained from the following detailed description, which is given as an example along with the drawings attached to this specification. The figures in such drawings, as well as the detailed description, are examples. Therefore, the figures and detailed description should not be considered limiting, and other equally valid examples are possible and may occur. Furthermore, similar reference numbers in the figures indicate similar elements.

[0012] [Figure 1A]This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments are implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This figure shows an exemplary radio access network (RAN) and core network (CN) used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RANs and further CNs that can be used in the communication system of Figure 1A according to one embodiment. [Figure 2] This is a system diagram showing an example of a customer premises network (CPN) architecture according to one or more embodiments. [Figure 3] This is a system diagram showing an example of an advanced residential gateway (eRG) architecture in one or more embodiments. [Figure 4] This is a message flow diagram illustrating an exemplary procedure for registering a network function (NF) group according to one or more embodiments. [Figure 5] This message flow diagram illustrates an exemplary procedure for proxy registration of a CPN-deployed NF via the Access and Mobility Management Function (AMF) in one or more embodiments. [Figure 6] This is a system diagram showing an example of a split CPN architecture according to one or more embodiments. [Modes for carrying out the invention]

[0013] The following detailed description includes numerous specific details to provide a complete understanding of the embodiments and / or examples disclosed herein. However, it will be understood that such embodiments and examples may be practiced without some or all of the specific details described herein. In other instances, well-known methods, procedures, components and circuits are not described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or essentially described, disclosed, or otherwise provided herein (collectively, “Provided”). Various embodiments are described and / or claimed herein, in which apparatus, systems, devices, etc., and / or any element thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof. However, it should be understood that any embodiment described and / or claimed herein assumes that any apparatus, systems, devices, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0014] Exemplary communication systems, networks, and devices

[0015] The methods, procedures, apparatus, and systems provided herein are suitable for communications involving both wired and wireless networks. An overview of various types of wireless devices and infrastructure is provided with respect to Figures 1A to 1D, where various elements of the network can utilize, implement, and be arranged in accordance with the methods, apparatus, and systems provided herein, as well as adapt and / or be configured for them.

[0016] Figure 1A is a system diagram showing an exemplary 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, and broadcast to multiple radio users. The communication system 100 can enable multiple radio users to access such content through the sharing of system resources, including radio 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 (ZT) unique-word (UW) discrete Fourier transform (DFT) spread OFDM (ZT UW DTS-s OFDM), unique-word OFDM (UW-OFDM), resource block filtering OFDM, and filter bank multicarrier (FBMC).

[0017] As shown in Figure 1A, the communication system 100 may include radio transceiver units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, and 102d may all be referred to as “stations” and / or “STAs” and may be configured to transmit and / or receive radio signals, and may include (or be) user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, 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 processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may interchangeably be referred to as UEs.

[0018] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or network 112. As an example, base stations 114a and 114b may be any of the following: base station transceiver station (BTS), node B (NB), e-node B (eNB), home node B (HNB), home e-node B (HeNB), g-node B (gNB), NR node B (NR NB), site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0019] 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 a base station controller (BSC), a radio network controller (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be called cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell can provide coverage for radio services to a particular geographic area that may be relatively fixed or change over time. A cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, which may utilize multiple transceivers for each sector of the cell or any sector. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0020] Base stations 114a and 114b can communicate with one or more WTRUs 102a, 102b, 102c, and 102d via an air interface 116, the air interface 116 may be any suitable radio 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).

[0021] More specifically, as described above, the communication system 100 can be a multi-connection system and can employ one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a in RAN104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using Wideband CDMA (WCDMA). WCDMA can include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High Speed Downlink Packet Access (HSDPA) and / or High Speed Uplink Packet Access (HSUPA).

[0022] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish an air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-A Pro.

[0023] In one embodiment, the base stations 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as NR Radio Access, which can establish an air interface 116 using New Radio (NR).

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

[0025] In one embodiment, base stations 114a and WTRUs 102a, 102b, and 102c can implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity (Wi-Fi)), 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), GSM Advanced Data Rate (EDGE), and GSM EDGE (GERAN).

[0026] In Figure 1A, base station 114b may be, for example, a wireless router, home node B, home enode B, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as offices, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones, for example), and roads. In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRU 102c, 102d can implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In one embodiment, base station 114b and WTRU 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any small cell, picocell, or femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not be required to access the internet 110 via CN 106 / 115.

[0027] RAN104 / 113 may communicate with CN106 / 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 WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security functions, such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing one of the following technologies: GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi radio technology.

[0028] CN106 / 115 can also act as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, User Datagram Protocol (UDP), and / or IP in the Transmission Control Protocol / Internet Protocol (TCP / IP) Internet Protocol Suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 114 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 can include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d can include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which can employ cellular-based radio technology and may be configured to communicate with base station 114b which can employ IEEE 802 radio technology.

[0030] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other elements / peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while remaining consistent with one embodiment.

[0031] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple 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 can perform signal coding, 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 transceiver element 122. Although Figure 1B shows the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together, for example, in an electronic package or chip.

[0032] The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmitting / receiving element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In one embodiment, the transmitting / receiving element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of radio signals.

[0033] Although the transmit / receive element 122 is shown as a single element in Figure 1B, the WTRU 102 can include any number of transmit / receive elements 122. For example, the WTRU 102 can employ MIMO technology. Thus, in one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving radio signals via the air interface 116.

[0034] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal to be received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0035] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (for example, a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input data from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. Non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 can access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data therein.

[0036] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 can be any suitable device for supplying power to the WTRU 102. For example, the power supply 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.), a solar cell, a fuel cell, etc.

[0037] The processor 118 may also be coupled to a 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 instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of when signals are received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information via any preferred location determination method while remaining consistent with one embodiment.

[0038] The processor 118 may further be coupled to other elements / peripherals 138, which may include one or more software and / or hardware modules / units that provide additional features, functionality and / or wired or wireless connectivity. For example, the elements / peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a Universal Serial Bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency-modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The element / peripheral device 138 may include one or more sensors, the sensors being one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.

[0039] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of a signal may be parallel and / or simultaneous, associated with a specific subframe for both an uplink (for transmission, for example) and a downlink (for reception, for example). The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing either through hardware (e.g., chokes) or through a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU102 may include a half-duplex radio, which is for the transmission and reception of some or all of a signal (e.g., associated with a specific subframe for either an uplink (for transmission, for example) or a downlink (for reception, for example).

[0040] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 can employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0041] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining consistent with one embodiment. Each of enodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, enodes B160a, 160b, and 160c can implement MIMO technology. Thus, enode B160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU102a.

[0042] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling on uplink (UL) and / or downlink (DL), etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c can communicate with each other via the X2 interface.

[0043] The CN106 shown in Figure 1C may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although each of the above elements is shown as part of CN106, it will be understood that any one of these elements may be owned and / or operated by an entity other than the CN operator.

[0044] The MME162 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface and can act as a control node. For example, the MME162 can be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 can provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0045] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0046] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0047] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to circuit-switched networks such as PSTN108, thereby facilitating communication between WTRU102a, 102b, and 102c and legacy landline communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0048] Although the WTRU is described as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0049] In a typical embodiment, the other network 112 may be a WLAN.

[0050] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have access points (APs) for the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with distributed systems (DSs) or other types of wired / wireless networks that carry traffic during and / or from the BSS. Traffic originating outside the BSS to the STAs may arrive through the APs and be delivered to the STAs. Traffic originating from the STAs to destinations outside the BSS may be sent to the APs to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the APs; for example, a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS is considered and / or sometimes referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between a source STA and a destination STA (for example, directly between them) via a direct link setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z tunnel DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (for example, all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to as the “ad-hoc” communication mode in this specification.

[0051] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel can be the operating channel of the BSS, which can be used by STAs to establish a connection with the AP. In some typical embodiments, Carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. In CSMA / CA, an STA, including the AP (e.g., any STA), can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that STA can backoff. One STA (e.g., only one station) can transmit at any given time within a given BSS.

[0052] A high-throughput (HT) STA can use a 40MHz wide channel for communication, for example, via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0053] Ultra-high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining consecutive 20MHz channels. 160MHz channels can be formed by combining eight consecutive 20MHz channels, or by combining two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In the 80+80 configuration, data can be passed through a segment parser that, after channel encoding, can split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of a receiving STA, the operation described above for the 80+80 configuration can be reversed, and the combined data can be sent to a media access control (MAC) layer, entities, etc.

[0054] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have limited capabilities, including support for some and / or limited bandwidths (e.g., support only for that). MTC devices may include batteries with above-threshold battery life (e.g., to maintain very long battery life).

[0055] A WLAN system that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode from among all STAs operating in the BSS. In the 802.11ah example, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) 1 MHz mode, even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier detection and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, the entire available frequency band may be considered busy, even though a large portion of the frequency band remains idle and could be available.

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

[0057] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

[0058] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while remaining consistent with one embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c can implement MIMO technology. For example, the gNB180a and 180b can utilize beamforming to transmit signals to and / or receive signals from the WTRU102a, 102b, and 102c. Thus, the gNB180a can, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from the WTRU102a. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c can implement coordinated multi-point (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0059] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may differ for different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (including, for example, a varying number of OFDM symbols and / or a varying length of absolute time that persists).

[0060] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (such as e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c, and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0062] The CN115 shown in Figure 1D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and at least one Data Network (DN) 185a, 185b. While each of the above elements is shown as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0063] AMF182a and 182b can be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b can be responsible for user authentication of WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, mobility management, etc. Network slicing can be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service being utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, and services for MTC access. AMF182a, 182b can provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as Wi-Fi.

[0064] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0065] UPF184a and 184b may be connected via the N3 interface to one or more of gNB180a, 180b, and 180c in RAN113, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network, such as the Internet 110, to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184a and 184b can 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, and providing mobility anchoring.

[0066] CN115 can facilitate communication with other networks. For example, CN115 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 can provide WTRU102a,102b,102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to DN185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b, and an N6 interface between UPF184a,184b and local data networks (DN) 185a,185b.

[0067] In view of Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein with respect to any of the WTRU 102a to d, base stations 114a to b, e-nodes B160a to c, MME 162, SGW 164, PGW 166, gNB 180a to c, AMF 182a to b, UPF 184a to b, SMF 183a to b, DN 185a to b, and / or any other (one or more) elements / devices described herein may be implemented by one or more emulation elements / devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0068] Emulation devices may be designed to implement one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices in a communication network. One or more emulation devices may perform one or more, or all, of the functions while temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for testing purposes and / or tests may be performed using over-the-air wireless communication.

[0069] One or more emulation devices can perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., including one or more antennas) may be used by an emulation device to transmit and / or receive data.

[0070] introduction

[0071] One or more features associated with localized networks (e.g., 5G residential, customer premises network (CPN), etc.) are provided herein.

[0072] Features associated with an advanced residential gateway (eRG) architecture are provided herein. Features associated with a CPN-deployed network function (NF) are also provided herein. A network function can refer to a processing function in a network (for example, having defined functional behavior and (pre-defined) interfaces). A network function can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (for example, on a cloud infrastructure).

[0073] Features associated with NF group-based registration, updates, and notifications (for example, associated with a user plane) are provided herein.

[0074] One or more features associated with proxy registration of an eRG and a co-located NF via an Access and Mobility Management Function (AMF) (for example, associated with a control plane) are provided herein.

[0075] One or more features associated with NF profile extensions for supporting split CPN are provided herein.

[0076] One or more features associated with CPN are provided herein.

[0077] A CPN is a type of local network. A CPN can extend network management capabilities (e.g., 3GPP network management capabilities) to customer premises (e.g., homes, offices, stores, etc.). A CPN can provide users with improved service quality.

[0078] CPN can be described as an evolution of the fifth-generation (5G) residential gateway concept. A 5G residential gateway may involve a residential base station (e.g., a premise radio access station (PRAS)) and an advanced residential gateway (eRG) deployed together (e.g., with non-3GPP devices).

[0079] A “locally deployed NF” can be an NF deployed on a local network (e.g., a CPN) and using an eRG to communicate with functions deployed outside the local network (e.g., in 5GS). A “locally deployed application function (AF)” can be an AF deployed on a local network (e.g., a CPN) and using an eRG to communicate with functions deployed outside the local network (e.g., in 5GS). As used herein, the terms “CPN” and “local network” may be interchangeable. A locally deployed NF, or a locally deployed AF, may be hosted (or colocated) within an eRG, or may be hosted on a device (e.g., within the local network) that is separate from the eRG and has a path to the eRG. In such a case, the locally deployed NF may still communicate with functions outside the local network via the eRG.

[0080] Figure 2 shows an exemplary architecture for CPN.

[0081] An eRG can be a gateway (e.g., an anchor) element that connects different devices in a CPN (e.g., all different devices, e.g., 3GPP devices and non-3GPP devices) to the 5G core (5GC). An eRG can connect to the 5GC through different mechanisms. For example, an eRG can connect to the 5GC through 5G mobile access (e.g., 5G-RAN) or through fixed access (e.g., using both mobile and fixed access together).

[0082] An eRG can be considered a UE from the perspective of a 5GC (for example, whether the eRG is connected via 5G-RAN or fixed access). For example, an eRG can exchange N1 signaling with a 5GC (for example, communicate via an N1 interface). An eRG can include a WTRU (for example, communicate via wireless messaging). An eRG can communicate via a wired connection. One or more features described herein relating to an eRG communicating wirelessly with a 5GC (for example, via a WTRU) can similarly apply to an eRG communicating with a 5GC via a wired connection (for example, via fixed wired access), and vice versa.

[0083] One or more features associated with CPN ownership and administration are provided herein. An end user or another third-party entity (e.g., a company, building owner, landowner, or other third-party provider) may be authorized as an authorized administrator to configure and manage (e.g., at least partially) network nodes in a CPN (e.g., PRAS, eRG, and CPN-connected devices). A CPN may be owned, installed, and / or (e.g., at least partially) configured by a customer of a public network operator (MNO) (e.g., an end user or other third party).

[0084] Exemplary use cases for CPN are provided herein.

[0085] One or more features associated with the quality of service (QoS) of small indoor base station connectivity are provided herein. The QoS flow can be provided to a WTRU behind the eRG (e.g., connected to a PRAS or non-3GPP access).

[0086] One or more features associated with visitor access to a small indoor base station are provided herein. Access can be provided to visiting WTRUs, which enable them to connect to PRAS or non-3GPP access and 5GC via eRG. Traffic isolation, different billing sessions, etc., may be considered.

[0087] One or more features associated with maintaining QoS from outdoors to indoors are provided herein. A WTRU can perform handovers between gNB access and PRAS or non-3GPP access (for example, a CPN can maintain QoS for flows).

[0088] One or more features associated with efficient routing for communication between WTRUs via a residential gateway (e.g., eRG) are provided herein. One or more (e.g., two) WTRUs connected to different or the same PRAS or non-3GPP access can be routed (e.g., efficiently) within the CPN.

[0089] One or more features associated with end-to-end (E2E) QoS monitoring are provided herein. E2E QoS can be monitored when some of the segments that traffic traverses are within a CPN.

[0090] One or more features associated with provisioning the eRG and PRAS are provided herein. The operator-managed portion of the CPN can be provisioned automatically.

[0091] One or more features associated with 5G LAN scalability are provided herein. The widespread use of 5G-LAN connectivity can test the limitations of current VLAN scalability support within 3GPP networks.

[0092] One or more features associated with an indoor LAN for 5G LAN connectivity are provided herein. WTRUs and non-3GPP devices belonging to the same network can interact. eRGs can support this interoperability.

[0093] One or more features associated with seamless route switching from direct inter-WTRU communication to indirect communication via eRG are provided herein. Routes can be set up between one or more (e.g., two) WTRUs attached to a PRAS of the same CPN. The eRG can create routes (e.g., more efficient routes) between them.

[0094] One or more features associated with seamless switching from a service hosting environment to an application server via an eRG are provided herein. The eRG and local application services can interact. Computation can be offloaded to the local AS.

[0095] One or more features associated with local control of WTRU connectivity in a CPN are provided herein. This use case addresses how an authorized administrator can explicitly configure QoS guarantees for flows between specific WTRUs.

[0096] One or more features associated with IP traffic offloading are provided herein. The eRG can offload several flows locally and directly to an external IP network.

[0097] One or more features associated with PRAS sharing are provided herein. This use case considers the sharing of different PRAS in a CPN by visiting WTRUs from different operators.

[0098] One or more features associated with multicast service access control for one or more legacy devices behind an eRG are provided herein. One or more features associated with multicast traffic access behind an eRG are provided herein. The granularity of multicast service access control can be at the eRG level (for example, so that all devices behind the eRG share the same access rights). This access control granularity can be extended.

[0099] One or more features associated with connecting to a 5G LAN via a fixed IP VPN are provided herein. Users on the 5G-LAN can be supplemented by an external IP VPN (for example, a VPN used for teleworking).

[0100] One or more features associated with the loss of connectivity between the eRG or PRAS and the 5GC are provided herein. The CPN may take one or more actions if the eRG loses connectivity to the 5GC.

[0101] One or more features associated with the control of the CPN by an authorized administrator are provided herein, and the configuration of the CPN (e.g., different configurations, including eRGs) can be controlled by an external authorized administrator (e.g., either remotely or locally).

[0102] One or more features associated with an eRG that support multiple connectivity are provided herein. There may be routing scenarios in which the eRG has multiple connections to 5GC (for example, similar to hybrid access for the eRG).

[0103] One or more features associated with providing 5G multicast broadcast services (5MBS) to devices through an eRG are provided herein. 5MBS services can be provisioned to devices behind the eRG.

[0104] One or more features associated with identification, authentication, and authorization for PRAS are provided herein. The link between PRAS and eRG can be made secure.

[0105] One or more features associated with supporting backward external services of eRG in CPN are provided herein. 5GC can be used as an identity information provider for services to nodes in CPN.

[0106] A CPN may have one or more requirements (for example, from a service perspective).

[0107] 5G systems can support applications on ASs connected to a CPN.

[0108] 5G systems can enable network operators associated with eRGs to control the security policies of eRGs.

[0109] 5G systems can support real-time E2E QoS monitoring and control for in-CPN data traffic (e.g., any in-CPN data traffic) to and from WTRUs (e.g., via eRG, or via PRAS and eRG).

[0110] 5G systems can support real-time E2E QoS monitoring and control for data traffic (e.g., any data traffic) between WTRUs within the CPN and the 5G network (i.e., via eRG or via PRAS).

[0111] 5G systems can allow authorized administrators to provision WTRU access considerations in PRAS (e.g., allowing all WTRUs or only specific WTRUs) (e.g., according to operational policies).

[0112] A 5G system can enable network operators to provide 5G services (e.g., any 5G service) to WTRUs (e.g., any WTRU) via PRAS connected through eRG.

[0113] 5G systems can support mechanisms that allow authorized third parties to authorize and / or deauthorize WTRUs to access 5G LAN VNs.

[0114] One or more features associated with enabling the control and configuration of the CPN by an authorized administrator are provided herein.

[0115] One or more features associated with network-exposure functions (NEFs) and local NEFs (L-NEFs) are provided herein.

[0116] NEF can enable access to network information and / or capabilities for external use (for example, by untrusted application functions (AF) and / or application services (AS)).

[0117] NEF can support the following functions (e.g., standalone functions): NEF can support the exposure of capabilities and events. For example, NF capabilities and events can be securely exposed by NEF to, for example, third parties, AF, or edge computing (e.g., EAS, EES, ECS, etc.). NEF can store and / or retrieve information as structured data using a standardized interface to a unified data repository (UDR) (e.g., Native Unified Data Repository (Nudr)).

[0118] NEF can support the secure provisioning of information to the 3GPP network (for example, from external applications). For example, NEF can provide a means for AF to securely provide information to the 3GPP network (for example, expected WTRU behavior, 5G virtual network (5G-VN) group information, time synchronization service information, and / or service-specific information).

[0119] NEF can support internal-to-external information translation. For example, NEF can translate information exchanged with AF and information exchanged with internal NF. For example, NEF can handle the masking of network and user sensitive information to external AF according to network policies.

[0120] NEFs can support redirecting AFs to a more suitable NEF / L-NEF (for example, if an NEF is servicing AF requests for local information disclosure, the NEF can detect that there is a more suitable NEF instance to serve the AF requests).

[0121] An NEF can receive information from other NFs (for example, based on the publicly available capabilities of other NFs). An NEF can store the received information as structured data (for example, using a standardized interface to a UDR). The stored information can be accessed by the NEF, "republished" to other NFs and / or AFs, and / or used for other purposes (for example, analysis).

[0122] NEF can support 5G-VN group management functionality. For example, the 5G-VN group management function in NEF can store 5G-VN group information in the UDR via unified data management (UDM).

[0123] NEF can support the publication of analyses. For example, an NWDAF analysis can be securely published by NEF (e.g., by AF) for use by external parties.

[0124] NEF can support data retrieval from external parties (e.g., AF) via NWDAF. For example, data provided by an external party can be collected by NWDAF via NEF for analytical and generation purposes.

[0125] The NEF can be an entry point (e.g., a common entry point) or a service access point for external communication and information gathering to the 5GC.

[0126] Local NEF (L-NEF) is similar to NEF but is local to an area or CPN. For example, L-NEF can be used in local deployments of edge services to provide network information exposure with reduced latency.

[0127] One or more features associated with Network Data Analysis Function (NWDAF) are provided herein.

[0128] NWDAF within 5GC can be used to enable data analysis and database applications. NWDAF may include one or more of the following functions: support for data collection from NF and AF, support for data collection from OAM, NWDAF service registration and metadata publication to NF and AF, support for provisioning analytical information to NF and AF, and support for machine learning (ML) model training and provisioning to NWDAF (including, for example, analytical logic functions).

[0129] One or more features associated with the Network Repository (NRF) function are provided herein.

[0130] An NRF can support one or more (for example, two) functions. For example, an NRF can perform one or more service discovery functions (for example, by acting as a receiver of NF discovery requests from NF instances and providing information about discovered NF instances), maintain an NF profile of available NF instances and their supported services, and so on.

[0131] Typical procedures for handling network functions (NFs) deployed in a customer's private network (CPN)

[0132] A CPN can provide 3GPP-based control and management to customer networks within a premises (e.g., residences, offices, stores / shops, etc.). A CPN can include a (e.g., single) connection point to 5GC (e.g., an enhanced Residential Gateway (eRG)) that can connect to and provide access to 5GS functionality. A CPN can relay over an eRG when performing 5G-related operations (e.g., all of them). An eRG may include a WTRU to provide connectivity and one or more (e.g., several) NFs that provide services within the CPN. An eRG can be a set of functions (e.g., NFs) that relate to and reside within a single location.

[0133] eRG can operate as a collection of several NFs (e.g., operating jointly). NFs can be CPN-specific, operate under the same attachment point to 5GC (e.g., the same attachment point), and be optimized simultaneously. While one or more features described herein can be implemented in a CPN scenario, such features can be applied to any situation where a set of NFs share the same network connectivity (e.g., connected to 5GS through a single WTRU) and share some common relationship. The features described herein can be applied to one or more processes for NF registration and discovery (e.g., different 3GPP standardization processes).

[0134] In one embodiment, one or more features associated with a CPN are provided herein.

[0135] A CPN can include an eRG. An eRG can behave as a WTRU directed towards 5GC.

[0136] Within a CPN, one or more (e.g., multiple) NFs may depend on an eRG to maintain connectivity with the 5GC. One or more of these NFs may be colocated within the eRG. NFs may be related (for example, because they all share a common connection to the 5GC).

[0137] A CPN can be managed by an AF. The AF may not need to understand the CPN topology (e.g., single PRAS, multiple PRAS, AS deployment, etc.) (or may have authorization). A CPN-managing AF can be located within or outside the CPN.

[0138] One or more features associated with optimizing different aspects of CPN operation are provided herein. These features may be general enough to be applied in other (e.g., future) scenarios.

[0139] Features associated with AF and / or AS that interact with the internal NF of the eRG are provided herein. Features associated with AF and / or AS that constitute the functionality of the CPN are provided herein.

[0140] NFs in a CPN can have relationships (for example, relationships between NFs). For example, NFs can share IP addresses (for example, to optimize the interface and / or interaction between an NF and a 5GS).

[0141] A CPN can be managed by an authorized AF (for example, to place a device with a certain MAC address into a private group for communication within the CPN). The AF can understand (for example, may need to understand) the CPN topology to determine where a particular MAC address can be valid within the CPN. Due to security and complexity, the CPN topology may be hidden from the authorized AF. Management interactions between the authorized AF and the CPN can be transparent to the CPN topology (for example, the AF may be unaware of the CPN topology).

[0142] An exemplary eRG architecture is provided herein. One or more features associated with a CPN-deployed NF are provided herein.

[0143] The eRG can provide a means of accessing information about 5GC services (e.g., 5G-LAN configuration). The eRG can permit (e.g., enable) an AF belonging to an authorized administrator to configure and control parameters relating to the operation of the CPN or the eRG. An authorized administrator AF can reside within the CPN (e.g., including within the eRG) or outside the CPN (e.g., in the core network or data network).

[0144] In one embodiment, referring to Figure 3, an exemplary eRG architecture is provided (for example, including a CPN-deployed local NF). The eRG can be associated with a WTRU. For example, the eRG may include a WTRU (sometimes referred to herein as an eRG WTRU). The eRG WTRU may include a local NF (for example, including a local network registration function (L-NRF), a local network exposure function (L-NEF), a local network data analysis function (L-NWDAF), etc.) and provide a common connection to the 55GC for the CPN.

[0145] L-NRF can function as a local rendezvous place for local NFs.

[0146] L-NEF can be the network exposure function of the eRG. L-NEF can enable AF to control, configure, and / or retrieve exposed information from the eRG and PRAS. Although AF is shown as being external to the eRG in Figure 3, those skilled in the art will understand that AF can be collocated with the eRG.

[0147] L-NWDAF can collect information from eRG (e.g., regarding its operation), CPN devices (e.g., PRAS, e.g., including radio information), and / or from local NF and AF deployed in the CPN (e.g., with eRG or connected CPN devices).

[0148] The L-NWDAF can collect information through the L-NEF (as shown in Figure 3, for example) or by direct connection. The information collected by the L-NWDAF can be made publicly available (for example, by the L-NEF) to (one or more) CPN NFs and (one or more) AFs.

[0149] For example, as shown in Figure 3, L-NEF, L-NWDAF, and L-NRF can be collated in eRG. These NFs and (one or more) other NFs and / or (one or more) AFs can be deployed on other devices connected in CPN.

[0150] In this architecture, NFs (including, for example, L-NEF, L-NWDAF, and L-NRF, or any other NF) may depend on eRG WTRUs for connectivity to 5GC (for example, they may depend on eRG WTRUs to act as gateways to the network, as described herein).

[0151] An NF within a CPN (including an NF co-located with an eRG) may not be able to register with the 5GC or global NRF until the eRG acquires connectivity. If the eRG implements IP connectivity to the CPN through a NAT, the NF co-located with the eRG may be reachable by different IP addresses from nodes inside or outside the CPN (e.g., a private address for nodes inside the CPN, a public address for nodes behind the eRG). L-NRFs, global NRFs, L-NEFs, and global NEFs (e.g., located in the core network) may contain different information about the NF's contact point. L-NEFs / L-NRFs may provide local IP addresses (e.g., which may be from the private IP space) to local CPN NFs, while core-located NFs will have global IP addresses used by the NAT (e.g., located in the eRG) that is giving them access to the CPN.

[0152] One or more features associated with the network function repository service are provided herein. One or more features associated with NF group-based registration, update, and notification are provided herein.

[0153] The eRG may contain one or more (e.g., more) NFs that are colocate or accessible within the local network (for example, a CPN is used as an example herein). One or more of the NFs (e.g., each) may be accessible through the same IP address (however, for example, the NFs may use different ports or be accessible through different IP addresses belonging to the same IPv6 prefix (a prefix delegated to the eRG by 5GC)).

[0154] CPN NFs can share one or more common parameters. Groups or relationships can be formed between a set of CPN NFs and their common parameters (e.g., the FQDN of an eRG). Such parameter sharing can establish relationships or groupings between CPN NFs and their common parameters (e.g., all NFs are accessible through the same IP or the same eRG). Parameter sharing and / or relationships / groupings can be signaled to the network.

[0155] Relationships / grouping can be used to optimize CPN NF registration, updates, and event notifications. For example, if an NRF knows an eRG and its collated NFs, and the eRG changes its IP address, the NRF can automatically propagate those changes across all NFs collated with the eRG.

[0156] Defining relationships / groupings between different NFs can be applicable to any NF in a 5GC system, including use outside or beyond the CPN.

[0157] The relationships between NFs within a CPN can be represented in an NFGroupProfile data structure, which can be used within the Nnrf_NFManagement service through an endpoint (for example, a newly defined endpoint called nfgroup-instances). Table 1 shows an example of the NFGroupProfile data structure.

[0158] In one embodiment, with reference to Figure 4, an exemplary procedure for NF group registration is provided.

[0159] In a CPN context, NF group registration can be applied to user-plane communication between the eRG and 5GC in the CPN. NF group registration can be used if the eRG is registered with the 5GC and has a PDU session established for communication.

[0160] An NF group registration may include one or more of the following elements:

[0161] An NF (for example, one of several NFs) belonging to a group of NFs (for example, statically configured to belong to a group) can send a PUT request to a resource URI representing the NF group instance. The URI can be determined based on the NF group instance. The variable {nfGroupID} can represent an identifier (for example, provided by an NF service consumer). The variable {nfGroupID} can be globally unique within the PLMN of the NRF to which the NF group is registered.

[0162] The format of an NF group ID can be a universally unique identifier (UUID) or any other unique identifier.

[0163] The payload body of a PUT request may include a representation of the NF group to be registered.

[0164] An NF can determine which NF should send the initial PUT request. A mechanism for arbitration may be applied (for example, the NF with the highest ID (in numerical format) can send the initial PUT request), or the determination may be made based on configuration.

[0165] If a service consumer is not a trusted NF, the service consumer can communicate with an NEF (for example, instead of an NRF).

[0166] If NF group registration is successful, a message (for example, "201 Created") may be returned. The payload body of the PUT response may include a representation of the created resource. The "Location" header may include the URI of the created resource.

[0167] If NF group registration fails or is redirected, one or more of the following actions may be taken: If NF group registration fails in NRF due to an encoding error in the NFGroupProfile JSON object, NRF may return a message containing a status code with a ProblemDetails information element (IE) that provides details of the error (for example, "400 Bad Request").

[0168] If registration of an NF group fails in the NRF due to an internal NRF error, the NRF may return a message containing a status code with ProblemDetails IE that provides details of the error (for example, "500 Internal Server Error").

[0169] If an NF group registration is redirected, the NRF may return a "3xx" status code that includes a location header with a URI pointing to an endpoint of another NRF service instance.

[0170] Referring again to Figure 3, the system diagram shows an exemplary eRG architecture implemented within a CPN. In this example, the CPN (or eRG) includes an L-NRF. Local CPN NFs can register with the L-NRF. The L-NRF can be an NF responsible for registering groups of NFs in a global NRF located in the core of the network.

[0171] Based on the completion of group registration, the NRF can proceed to register one or more of the NFs identified in the group (for example, each of them).

[0172] To gather information about the registration of NFs (for example, each NF), an NF responsible for registering a group in a global NRF (for example, L-NRF) can subscribe to registration events for NFs in the group (for example, using the NRF's NFStatusSubscribe service). NFs can subscribe by including the group identifier in the NfGroupListCond attribute of the SubscrCond data type, using the subscrCond attribute of the SubscriptionData object type.

[0173] If an NF successfully subscribes to the NF group registration event, L-NRF can receive notifications of the registration of one or more NFs in the group (e.g., each NF). NFs in the group can receive updates on their status by subscribing to such notifications in L-NRF.

[0174] An example of the NFGroupProfile data structure is shown in Table 1.

[0175] [Table 1]

[0176] Table 2 shows an exemplary PortMap structure.

[0177] [Table 2]

[0178] The NFGroupProfile data structure can be modified (for example, through different functions of the Nnrf_NFManagement service). Based on the grouping of NFs, one or more (for example, all) NFs can be modified as a group. For example, if an eRG changes its IP address, the co-located NFs (for example, all co-located NFs) can have their IP addresses modified through a swap (for example, a single swap).

[0179] The PortMap structure can indicate the mapping of port numbers to an NRF (for example, when NAT traversal is required). IpEndPoints included in the NFService structure within an NFProfile and / or NFGroupProfile can be mapped to URLs accessible from outside the local network.

[0180] One or more features associated with proxy registration (e.g., by AMF) of a CPN NF connected via eRG are provided herein.

[0181] NFs located within a CPN (e.g., all NFs) may rely on eRG connectivity to register with the NRF and 5GC. The NF registration process may (or may need to) wait until the eRG (e.g., eRG WTRU) registers with 5GS and obtains an IP address (e.g., via PDU session establishment).

[0182] An eRG WTRU can be an entity in the eRG that provides connectivity to the core network (e.g., 5GC). Communication by the eRG with the network described herein can be carried out by the eRG WTRU. The WTRU may be different from the NF and may not be intended to operate or implement the APIs used by the NF to register and connect to the core. However, in a CPN, a local NF can (and may need to) register with and communicate with 5GC via the eRG WTRU.

[0183] An eRG (e.g., an eRG WTRU) can indicate to the AMF a NF located within a CPN (e.g., including itself (eRG)). The eRG can request the AMF to proxy register the CPN local NF with the NRF (e.g., via the eRG WTRU control plane). CPN NF proxy registration can occur before or after the eRG WTRU establishes a PDU session and receives an IP address from the SMF / UPF. If CPN NF proxy registration is initiated before the eRG obtains an IP address, the AMF may not complete the proxy registration of the CPN NF with the NRF until the eRG WTRU PDU session is established.

[0184] IEs (for example, those shown in Table 3) can be added to the registration request message.

[0185] [Table 3]

[0186] IE can be a 5GS Mobility Management (5GMM) information element (for example, eRG capability IE).

[0187] The eRG Capability IE can provide the network with information related to the NF, concerning aspects of the eRG, in relation to the eRG and collated with or in the CPN. The eRG Capability IE can indicate aspects of the eRG's operation (for example, the presence of a NAT connecting the CPN to the eRG). The content of the eRG Capability IE may influence how the network handles the operation of the eRG.

[0188] The eRG capability IE can be encoded as shown in Table 4.

[0189] [Table 4]

[0190] The eRG capability IE can have a minimum length of 4 octets and a maximum length of 15 octets.

[0191] The "Configurable CPN Name" bit can indicate whether the eRG is capable of supporting configurable CPN names (for example, to 5GC). One or more CPN_Name bits can be used to enable different services and service levels for each CPN_Name (for example, each CPN_Name).

[0192] The "Offloading to CPN" bit can indicate whether the eRG is capable of offloading incoming traffic to the local UPF.

[0193] The "Local DNN" bit can indicate whether the eRG can connect to a local or external IP network via the eRG.

[0194] The "CPN with UPF" bit can indicate whether the eRG is capable of performing CPN communication, which allows the eRG to switch traffic originating from WTRUs behind the eRG to local UPF.

[0195] The "CPN with relay" bit can indicate whether the eRG is capable of performing CPN communication, allowing the eRG to relay traffic originating from the WTRU behind the eRG to the 5GC.

[0196] The "Use of Unauthorized Spectra" bit can indicate whether the eRG is capable of using unauthorized spectra within one or more PRAS connected to the eRG.

[0197] The "Visitor Access Support" bit can indicate whether eRG / PRAS supports access for all visitors, no visitors, or specific visitors (e.g., only specific visitors). Visitor access support capability can be pre-configured by an authorized administrator (e.g., according to the operator's policy).

[0198] The "Implements NAT" bit can indicate whether the CPN is behind NAT.

[0199] The "Local NEF" bit can indicate whether the eRG implements a colocated local NEF.

[0200] The "Local NWDAF" bit can indicate whether the eRG implements co-located local NWDAF.

[0201] The "Local N3IWF" bit can indicate whether the eRG is capable of allowing untrusted non-3GPP access users to connect to 5GC via the eRG.

[0202] The "Supports N5CW" bit can indicate whether the eRG implements local TWIF.

[0203] The "Supports N5GC" bit indicates whether the eRG implements W-AGF functionality and registers N5GC nodes in the CPN.

[0204] The "Split DNN" bit can indicate whether the CPN is split across multiple locations connected through different eRGs.

[0205] The "Dynamic DNS" bit can indicate to (for example, to AMF) whether the eRG and collated NF will automatically update their DNS entries based on IP information (for example, received IP information).

[0206] The "NFProfile sent in transport" IE can indicate whether the eRG will provide (for example, later) NFProfile / NFGroupProfiles for different NFs that should be proxy-registered with the NRF by the AMF.

[0207] The “eRG Functionality” IE and “Proxy NF Registration” IE can be included in the registration request (for example, if the 5GMM capability IE indicates eRG support). Table 5 shows an example of a modified 5GMM capability IE (including, for example, the eRG Functionality IE and Proxy NF Registration IE highlighted below).

[0208] [Table 5]

[0209] The 5GMM capability IE may include an eRG capability IE (for example, including one or more bits indicating that) which can indicate (for example, to the AMF) that the WTRU to be registered is an eRG. The eRG capability IE may indicate that the eRG capability IE is included in (for example, the same) registration request.

[0210] The 5GMM capability IE may include a proxy NF registration IE that indicates the eRG / WTRU is requesting the AMF to proxy register the collated NF with the NRF.

[0211] In one embodiment, referring to Figure 5, an exemplary procedure for proxy registration of a CPN-deployed NF via AMF is provided.

[0212] An eRG can behave like a WTRU for a 5GC or 5G system. An eRG can perform registration toward the AMF, for example, an eRG WTRU can perform registration toward the AMF (which may include proxy registration of an NF, for example) as shown in Figure 5. An eRG can indicate that it is providing access to a CPN by setting the eRG Functionality IE (for example, a bit) in the 5GMM Capability IE (for example, setting the eRG Functionality IE to 1). An eRG can send an eRG Capability IE with information associated with the eRG and the CPN. In the eRG Capability IE, the eRG can indicate a different NF that is collated with the eRG. In the eRG Capability IE, the eRG can indicate its capability by sending the NFProfile / NFGroupProfile of the collated NF through a NAS transport message. An eRG can request that the AMF perform proxy registration of the eRG and the collated NF. The profiles of the eRG and the collated NF (one or more) can be sent in the NAS transport (for example, through the use of the proxy NF registration IE(bit) included in the 5GMM capability IE).

[0213] AMF can accept registrations for eRGs. AMF can provide information such as the eRG ID and the policies to be used by the eRG.

[0214] The eRG WTRU can provide an NFProfile or NFGroupProfile data structure that should be used by the AMF to register the NF with the NRF. The eRG can provide this information at any time after the eRG has registered. For example, Figure 5 shows an eRG that provides information before the PDU session is established. If the eRG provides information before the PDU session is established (for example, as shown in Figure 5), the AMF may not complete the proxy NF registration with the NRF until the eRG is assigned an IP address. If the PDU session is already established when the eRG provides the information (for example, the eRG is assigned an IP address), the AMF can register the CPN NF with the NRF (for example, without performing the actions described in 4a, 4b, and 5).

[0215] A WTRU can send uplink NAS transport messages. These uplink NAS transport messages may include additional information IEs (or other IEs) that have different (one or more) NFGroupProfiles or (one or more) NFProfiles, for example, to proxy register with the NRF (or other IEs may transport this information). One or more features associated with transporting an NFGroupProfile or NFProfile in an uplink NAS transport message are provided herein.

[0216] The eRG WTRU can know that CPN NF proxy registration can be triggered by an eRG configuration indicating trigger conditions (e.g., CPN NF registration at eRG registration time), a policy provided by AMF (e.g., as described in 2 in Figure 5) that indicates whether proxy registration is requested, allowed, or prohibited, the conditions that trigger registration, the detection of a new NF instance being available in the CPN (e.g., NF registration to the L-NRF in the CPN), and / or the detection of an NF instance being removed from the CPN.

[0217] If the eRG has established a PDU session, the eRG can communicate CPN NF proxy registration to the 5GC NRF via the user plane (for example, instead of via the eRG control plane).

[0218] The eRG can obtain one or more IP addresses to use for registering the NF collated with the eRG. For example, as shown in 4a, the eRG can establish a PDU session with the SMF, be assigned a UPF, and receive an IP address (for example, as part of establishing the PDU session). As shown in 4b, the SMF can send an IP address to the eRG through the AMF.

[0219] If the uplink NAS transport message is sent before the SMF assigns an IP address to the eRG, the AMF can use the eRG IP address information (for example, after receiving the eRG IP address information) to update the NFProfile or NFGroupProfile provided by the eRG. If the uplink NAS transport message is not sent before the SMF assigns an IP address to the eRG, the NFProfile or NFGroupProfile can contain (for example, already contain) an IP address.

[0220] The AMF can perform proxy registration of NFs collated with the eRG to the NRF (for example, by using the Nnrf_NFManagement service or by using the NF group registration described herein). Once proxy registration is complete, the NFs (for example, those that can be deployed locally in the CPN) will be registered with the NRF in the 5GC (for example, outside the CPN). NFs registered with an external NRF can be discoverable by other NFs. For example, an NF or AF not in the CPN can communicate with the 5GC NRF to discover information about one or more NFs deployed locally in the CPN (including those collated with the eRG). The discovered information may include any of the information from Table 1. For example, the discovered information may include one or more addresses (e.g., IP addresses, port numbers, and / or URIs) of NFs deployed locally in the CPN. An NF not in the CPN can use the discovered information to send a message to a local CPN NF. The message can be received by the eRG and forwarded to an NF deployed locally in the CPN.

[0221] One or more NFGroupProfiles or NFProfiles can be transported between the WTRU and AMF via uplink NAS transport messages. One or more NFGroupProfiles or NFProfiles can be transported using additional information IEs. In this case, the NFGroupProfile or NFProfile can be sent within an IE (for example, an already defined IE). The IE can indicate that it contains NFGroupProfile or NFProfile parameters through bits included in the 5GMM capability IE.

[0222] (One or more) NFGroupProfiles or (one or more) NFProfiles can be transported using a container (e.g., a new container) within the uplink NAS transport message. In this case, the uplink NAS transport message can be modified as follows:

[0223] [Table 6]

[0224] The NFGroupProfile container IE can be defined as follows:

[0225] [Table 7]

[0226] The NFGroupProfile container information element can be a type 6 IE with a minimum length of 4 octets and a maximum length of 65538 octets.

[0227] The NFGroupProfile container content field can contain an NFGroupProfile structure (for example, as shown in Table 1).

[0228] An NFProfile container IE can have the following structure:

[0229] [Table 8]

[0230] The NFProfile content field can have the following structure:

[0231] [Table 9]

[0232] The NFProfile container information element can be a type 6 IE with a minimum length of 4 octets and a maximum length of 65538 octets. The NFProfile container IE can contain a list of NFProfiles to be registered.

[0233] One or more NFGroupProfiles or NFProfiles can be transported using a payload container in an uplink NAS transport message. The payload container may contain an NFGroupProfile IE or NFProfile IE (for example, as an optional IE) within the payload container entry.

[0234] One or more features associated with extensions to NFProfile for supporting split CPN are provided herein.

[0235] A CPN can be a simple residential network encompassing an eRG (e.g., a single eRG) that connects the CPN (e.g., the entire CPN) to a 5GC (e.g., a single eRG). (For example, it can be indicated as such.) A CPN can be more complex (e.g., it can span multiple location and data networks (DNs)). A CPN can be configured and managed by a local AF that may need to interact with the eRG and 5GC.

[0236] NEFs or L-NEFs can be discovered using DNS queries that utilize the external identifier of a WTRU (e.g., individual WTRUs). AFs / ASs may need to know that the CPN is split. AFs / ASs may need to know the identifier of each WTRU connecting to the AF / AS (e.g., eRG WTRUs). If the AF is located inside the CPN, the IP bundled with the external identifier may not be reachable from the internal CPN network (e.g., the eRG may provide NAT functionality, mapping the external ID to an external IP).

[0237] The configuration of a CPN can be performed by an external AF through a local NEF (which will expose the APIs and information necessary to configure, for example, the local segment and its interaction with 5GC). A CPN can span multiple locations and contain multiple eRGs. In this case, it may not be possible for the AF to understand which L-NEF to access to configure a particular segment of the CPN.

[0238] NFProfile can be extended to take into account the relationships between NFs, eRGs, DNNs, and locations. AF can be enabled to discover the most appropriate L-NEF to communicate with (including, for example, any possible hierarchy or priority between local NFs).

[0239] The following information can be added to the NFProfile data type.

[0240] [Table 10]

[0241] CPN information may include one or more of the following components:

[0242] [Table 11]

[0243] The NRF can use this information to select an NF (e.g., L-NEF) for the AF to use to control and / or configure the CPN.

[0244] Referring to Figure 6, an example of a split CPN architecture is provided. The CPN can be a CPN connecting two separate locations, for example, a small business / company. A first AF (AF1) can attempt to configure the CPN (for example, AF1 may belong to the remote administrator of a small business / company). The CPN can be configured such that the company's (e.g., the entire enterprise / company) AAA server is located in eRG2. To configure the AAA parameters, AF1 can (for example, may need to) interact with the local NF (e.g., L-NEF2) in eRG2.

[0245] When the NRF determines which L-NEF to provide to the AF, or when the AF receives information on both L-NEFs, the NRF or AF may consider parameters added to the CPN information data type (as described herein with respect to Table 10, for example), such as priority, location, and eRG ID. For example, the NRF or AF may determine that there are two L-NEFs serving the CPN and that the L-NEF with the higher priority is the L-NEF in eRG2 (e.g., L-NEF2).

[0246] A first WTRU (e.g., WTRU1) can be associated with (or may include) a first eRG (e.g., eRG1) of the split CPN. A second WTRU (e.g., WTRU2) can be associated with (or may include) a second eRG (e.g., eRG2) of the split CPN.

[0247] A second AF (AF2) can attempt to access the L-NWDAF located within eRG1. Based on the information associated with eRG1 provided in the CPN information data type, NRF or AF2 can select the correct L-NWDAF.

[0248] Typical procedure for proxy registration of CPN NF connected via eRG using AMF

[0249] In one embodiment, a wireless transceiver unit (WTRU) for wireless communication is provided, comprising a circuit including a processor, a transmitter, a receiver, and memory. The WTRU sends a first registration message (to the AMF) indicating a request for the AMF to proxy register a network function (NF) or NF group associated with the WTRU. The WTRU receives a second registration message (from the AMF) indicating proxy registration information based on the first registration message. The WTRU sends a message (to the AMF) indicating NF profile information for the NF or NF group associated with the WTRU. In one example, the WTRU is associated with a customer premises network (CPN), which includes an advanced residential gateway (eRG) and a premises radio access station (PRAS). The first registration message may include a 5G mobility management (5GMM) IE. The WTRU can be associated with an advanced residential gateway (eRG) or a customer premises network (CPN). In one example, the message indicating NF profile information is an uplink non-access layer (NAS) transport message.

[0250] conclusion

[0251] Although the features and elements described above are described in specific combinations, each feature or element can be used alone or in various combinations with or without other features and elements in the preferred embodiment.

[0252] While the implementations described herein may take into account 3GPP-specific protocols, it is understood that the implementations described herein are not limited to this scenario and may be applicable to other radio systems. For example, while the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it is understood that the solutions described herein are not limited to this scenario and may be applicable to other radio systems. For example, while the systems are described with respect to 3GPP, 5G, and / or NR network layers, the assumed embodiments extend beyond implementations using specific network layer technologies. Similarly, potential implementations extend to all types of service layer architectures, systems, and embodiments. The techniques described herein can be applied independently and / or used in combination with other resource configuration techniques.

[0253] The processes described herein can be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and / or optical media such as compact disc (CD)-ROM discs and / or digital multipurpose discs (DVDs). Software-related processors can be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

[0254] It is understood that entities that perform the processes described herein may be logical entities that can be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device, network node, or computer system and executed on its processor. That is, a process may be implemented in the form of software (e.g., computer executable instructions) stored in the memory of a mobile device and / or network node, such as a node or computer system, and this computer executable instruction performs the described process when executed by the node's processor. It is also understood that any transmit and receive processes shown in the diagram may be performed by the node's communication circuitry under the control of the node's processor and the computer executable instructions (e.g., software) it executes.

[0255] Furthermore, it should be understood that the terms used herein are intended solely to describe specific embodiments and are not intended to limit them. As used herein, the terms “video” or “imagery” may mean any snapshot, a single image, and / or multiple images displayed over a time basis. As another example, when referred to herein, the terms “user device” and its abbreviation “UE,” the term “remote,” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmit and / or receive unit (WTRU), (ii) any of several embodiments of a WTRU, (iii) a wireless-enabled and / or wired (e.g., tetherable) device configured using some or all of the structure and functionality of a WTRU, (iii) a wireless-enabled and / or wired device configured using less structure and functionality than all of a WTRU, or (iv) similar. Details of exemplary WTRUs that can represent any WTRU enumerated herein are provided herein with respect to Figures 1A to 1D. As another example, the various embodiments disclosed above and below in this specification are described as utilizing a head-mounted display. Those skilled in the art will recognize that devices other than head-mounted displays may be used, and that some or all of the present disclosure and the various embodiments disclosed may be modified as appropriate without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information for providing an adapted reality experience.

[0256] The various techniques described herein can be implemented in relation to hardware or software, or, where appropriate, in relation to a combination of both. Thus, implementations and apparatus of the subject matter described herein, or particular aspects or parts thereof, can take the form of program code (e.g., instructions) embodied on a tangible medium including any other machine-readable storage medium, and when the program code is loaded into and executed by a machine such as a computer, the machine becomes an apparatus for practicing the subject matter described herein. Where the program code is stored on a medium, the program code may be stored on one or more media that collectively perform the actions, i.e., one or more media contain the code collectively for performing the actions, but if there are two or more single media, any particular part of the code does not need to be stored on any particular medium. In the case of program code execution on a programmable device, the computing device generally includes a processor, a processor-readable storage medium (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize processes described herein in relation to the subject matter described herein, for example, through the use of APIs, reusable controls, etc. Such programs are preferably implemented in a high-level procedural or object-oriented programming language for communicating with a computer system. However, (one or more) programs may be implemented in assembly language or machine language, if necessary. In either case, the language may be a compiled or interpreted language and may be combined with a hardware implementation.

[0257] Exemplary embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more standalone computing systems, but the subject matter described herein is not limited thereto and can rather be implemented in relation to any computing environment, such as a network or distributed computing environment. Furthermore, aspects of the subject matter described herein can be implemented in or across multiple processing chips or devices, and memory devices may similarly affect multiple devices. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems such as automobiles and airplanes.

[0258] In describing preferred embodiments of the subject matter of this disclosure, as shown in the figures, specific terminology is employed for clarity. However, it should be understood that the claimed subject matter is not intended to be limited to the specific terminology thus chosen, and that each specific element includes all technical equivalents that operate in a similar manner to achieve a similar purpose.

[0259] In general, it will be understood by those skilled in the art that the terms used herein, in particular in the appended claims (e.g., the text of the appended claims), are generally intended to be “open” terms (for example, the term “including” should be interpreted as “including, but not limited to,” the term “having” should be interpreted as “having at least,” and the term “including” should be interpreted as “including, but not limited to,” etc.). It will further be understood by those skilled in the art that if a certain number of claim descriptions are intended to be introduced, such intention will be explicitly stated in that claim, and if such statement is not present, such intention does not exist. For example, if only one item is intended, the term “single” or similar word may be used. For the sake of understanding, the following appended claims and / or description herein may include the use of the introductory phrases “at least one” and “one or more” to introduce claim descriptions. However, the use of such a phrase should not be interpreted as implying that the introduction of a claim description by the indefinite article "a" or "an" limits any particular claim containing such introduced claim description to embodiments containing only one such description, even if the same claim contains the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (for example, "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"). The same applies to the use of the definite article used to introduce a claim description. Furthermore, even if a specific number of introduced claim descriptions are explicitly stated, it will be recognized that such a statement should be interpreted as meaning at least the number stated (for example, the mere statement "two descriptions" without other modifiers means at least two descriptions, or two or more descriptions).Furthermore, in cases where a convention similar to "at least one of A, B, and C" is used, such configurations are generally intended to be understood by those skilled in the art (for example, "a system having at least one of A, B, and C" is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or systems having A, B and C together). It will be further understood by those skilled in the art that any substantially disjunctive word and / or phrase presenting two or more alternative terms should be understood, whether in the specification, claims, or drawings, as intended to include the possibility of including one of those terms, either one of those terms, or both of those terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B.” Furthermore, the term “any of” as used herein, followed by an enumeration of multiple items and / or multiple categories of items, is intended to include, individually or in combination with other items and / or other categories of items, “any of,” “any combination of,” “any multiple of,” and / or “any combination of multiples of.” Moreover, the term “set” as used herein is intended to include any number of items, including zero. In addition, the term “number” as used herein is intended to include any number, including zero. Furthermore, the term “multiple” as used herein is intended to be synonymous with “a plurality.”

Claims

1. A method implemented by a wireless transceiver unit (WTRU), The steps include sending a first registration message to the Access and Mobility Management Function (AMF) indicating a request for the AMF to proxy register a Network Function (NF) or NF group associated with the WTRU, The steps include receiving a second registration message from the AMF indicating proxy registration information based on the first registration message, The steps include sending a message to the AMF indicating the NF profile information of the NF or NF group associated with the WTRU, and A method that includes [a certain feature].

2. A wireless transceiver unit (WTRU) for wireless communication, comprising a circuit including a processor, a transmitter, a receiver, and memory, wherein the WTRU is A first registration message is sent to the Access and Mobility Management Function (AMF) indicating a request for the AMF to proxy register the Network Function (NF) or NF group associated with the WTRU. The AMF receives a second registration message from the AMF indicating proxy registration information based on the first registration message. Send a message to the AMF indicating the NF profile information of the NF or NF group associated with the WTRU. A wireless transceiver unit (WTRU) configured in this manner.

3. The method according to claim 1 or the WTRU according to claim 2, wherein the WTRU is associated with a customer's private network (CPN), and the CPN comprises an advanced residential gateway (eRG) and a private radio access station (PRAS).

4. The first registration message is the method according to claim 1 or the WTRU according to claim 2, which includes a 5G Mobility Management (5GMM) IE.

5. The WTRU is associated with an advanced residential gateway (eRG) or a customer premises network (CPN) according to the method of claim 1 or the WTRU according to claim 2.

6. The method according to claim 1 or the WTRU according to claim 2, wherein the message indicating the NF profile information is an uplink non-access layer (NAS) transport message.

7. A device equipped with a processor, The aforementioned processor, A registration message is sent to the Access and Mobility Management Function (AMF), and the registration message indicates a request for the AMF to proxy register the Network Function (NF) or NF group associated with the device. Upon receiving a registration confirmation message from the aforementioned AMF, An NF profile message is sent to the AMF, and the NF profile message indicates NF profile information for the NF or NF group associated with the device. Establish a Protocol Data Unit (PDU) session, Receive Internet Protocol (IP) address assignment A device configured in a certain way.

8. The device according to claim 7, wherein the request is for the NF group, the NF group is a plurality of NFs, the NF profile message indicates the NF group, and the NF profile message further indicates parameters common to the plurality of NFs in the NF group.

9. The device according to claim 8, wherein the parameter includes at least one of a fully qualified domain name (FQDN) associated with the device, or an IP address indicated by the IP address assignment.

10. The device according to claim 7, wherein the device is associated with a split customer premises network (CPN), and the NF profile message further indicates a plurality of NFs or local network exposure functions (L-NEFs) associated with the split CPN, and priority information associated with the plurality of NFs or L-NEFs.

11. The device according to claim 7, wherein the NF profile message is sent via an uplink non-access layer (NAS) transport message.

12. The device is the device according to claim 7, which is associated with an advanced residential gateway (eRG).

13. The device according to claim 12, wherein the device is associated with one or more of the following: a local network registration function (L-NRF), a local network publishing function (L-NEF), or a local network data analysis function (L-NWDAF).

14. The device according to claim 7, wherein the device and the NF or NF group are associated with a local network.

15. The device according to claim 14, wherein the local network is a customer's private network (CPN).

16. The aforementioned processor, A message is received from an NF outside the CPN for the NF or NF group, and the NF or NF group is located within the CPN. Send the message to the aforementioned NF or NF group. The device according to claim 15, further configured as follows.

17. The device according to claim 7, wherein the device includes a wireless transceiver unit (WTRU).

18. A network device equipped with a processor, The aforementioned processor, A registration message is received from the Wireless Transceiver Unit (WTRU), and the registration message indicates a request for the network device to proxy register a network function (NF) or NF group associated with the WTRU. Send a registration confirmation message to the aforementioned WTRU, The WTRU receives a network function (NF) profile message, and the NF profile message indicates NF profile information for the NF or NF group associated with the WTRU. An Internet Protocol (IP) address assignment is received, and the said IP address assignment indicates the IP address information associated with the WTRU. The NF profile information is updated based on the IP address information. Based on the updated NF profile information, perform proxy registration for the NF or NF group associated with the WTRU. A network device configured in a certain way.

19. The network device according to claim 18, wherein the request is for the NF group, the NF group is a plurality of NFs, the NF profile message indicates the NF group, and the NF profile message further indicates parameters common to the plurality of NFs in the NF group.

20. The network device according to claim 19, wherein the parameter includes at least one of a fully qualified domain name (FQDN) associated with the WTRU, or an IP address indicated by the IP address assignment.

21. The network device according to claim 18, wherein the WTRU is associated with a split customer premises network (CPN), and the NF profile message further indicates a plurality of local network exposure functions (L-NEFs) associated with the split CPN, and priority information associated with the plurality of L-NEFs.

22. The network device according to claim 18, wherein the NF profile message is received via an uplink non-access layer (NAS) transport message.

23. The WTRU is a network device according to claim 18, associated with an advanced residential gateway (eRG).

24. The network device according to claim 23, wherein the NF or NF group includes one or more of the following: local network registration function (L-NRF), local network publishing function (L-NEF), or local network data analysis function (L-NWDAF).

25. The network device according to claim 18, wherein the WTRU and the NF or NF group are associated with a local network.

26. The network device according to claim 25, wherein the local network is a customer's private network (CPN).

Images