Method and apparatus for PEGC incapable of serving personal IoT network (PIN)

Abstract

Methods and apparatus are disclosed for a wireless transmit and receive unit (WTRU) to manage services thereof as a gateway capable individual Internet of Things network (PIN) element (PEGC) when a network connection becomes unavailable. In response to receiving a non-access stratum (NAS) signaling indicating that a connection with the 5G network is unavailable, the WTRU is triggered to respond to the NAS signaling indicating an information element (e.g., the WTRU is a PEGC and a PIN ID). The response may be a logout message, a PDU session release message, an uplink transmission message registration, or a registration for network slice selection assistance information (NSSAI) excluding a single slice (S-NSSAI) associated with the PDU session. The information elements may include a cause that the WTRU cannot act as a PEGC, a time when the WTRU is expected to be unavailable, a PIN ID, and other information.

Description

[0001] Cross-referencing related applications This application claims the benefit of U.S. Provisional Application No. 63 / 465,715, filed May 11, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] A Personal IoT Network (PIN) is a group of configured and managed PIN elements that can communicate with each other directly or via Gateway-Capable PIN Elements (PEGCs). A PIN can communicate with a 5G network via at least one PEGC and is managed by at least one Managed PIN Element (PEMC). A PIN element (PINE) is a Transmitter-Receiver Unit (WTRU), such as a User Equipment (UE) or a non-3GPP device, that can communicate within the PIN (via direct PIN connection, via PEGC, or via PEGC and 5GC) or outside the PIN via PEGC and the 5G core network (5GC). A Gateway-Capable PIN Element (PEGC) is a PIN element capable of providing connectivity to or from the 5G network for other PIN elements or relaying communication between PIN elements. A Managed PIN Element (PEMC) is a PIN element capable of managing the PIN.

[0003] With the support of the PEGC registered to the 5G network, PIN elements can access 5G network services and communicate with other PIN elements via the 5GC. PINs and PIN elements are managed by a PIN element with management capabilities (PEMC) and can also be managed by application functions (AFs). AFs for PINs can be deployed to support PIN services. AFs for PINs can communicate with the PEMC and PEGC via application layer signaling, which is transparently transmitted to the 5GS as user plane data. The purpose of the application layer signaling can be for the management of the PIN.

[0004] A PEGC is a WTRU with PIN-related subscription data associated with a 5GS and can be registered to the 5GS. In some cases, a PEGC serving a PIN may be unable to provide service to the PIN because it may not be able to provide data connectivity to an external DN. A PEGC may also be unable to provide service to the PIN due to unsuccessful registration or other non-access stratum (NAS) processes (e.g., session management (SM) processes such as PDU session establishment, or mobility management (MM) processes such as registration or service request).

[0005] These processes may be considered unsuccessful if the WTRU receives a rejection message from the network. Some possible rejection reason codes that the WTRU may receive from the network may indicate situations such as: congestion, reaching the maximum number of PDU sessions, insufficient resources for a specific network slice and / or data network name (DNN), insufficient user plane resources for a PDU session, payload not being forwarded by the mobility management layer, network slice-specific authentication and authorization failing or authorization being revoked, partial rejection / allowance of a network slice, or the rejected slice / requested slice not being part of the allowed slices provided by 5GS.

[0006] System enhancements are needed to handle PIN element traffic flows when the PEGC serving the PIN is rejected by the 5GS due to congestion or other reasons (which prevents the PEGC from providing a data path for the PIN traffic flow). Summary of the Invention

[0007] According to some aspects, methods and apparatus for WTRU operation in cases where the PEGC cannot serve the PIN are disclosed. In other aspects, methods and apparatus for handling one or more network functions where the PEGC cannot serve the PIN are disclosed. As used herein, fifth-generation mobile phones, or 5G, or 5GS, are systems defined by 3GPP since Release 15; however, embodiments are not limited to this.

[0008] According to some aspects, the Wireless Transmitter and Receiver Unit (WTRU) registers as a Personal Internet of Things Network (PIN) Element (PEGC) with gateway capabilities to a Wide Area Wireless Network (WWAN). It serves the data flow between the PIN element and the WWAN. Upon receiving an indication that the data flow with the WWAN is unavailable, the WTRU sends a Non-Access Stratum (NAS) response to the network, including information elements indicating the reason why the WTRU can no longer act as a PEGC for the PIN and the PIN identifier (ID).

[0009] In some examples, the PEGC (WTRU) can trigger a deregistration process with the 5GS upon receiving a rejection from the 5GS, providing new information elements about the PEGC's unavailability and a PIN identifier (i.e., PIN ID).

[0010] When the Application Management Function (AMF) receives a new information element from the PEGC indicating its unavailability, it can notify the Application Function (AF) for PIN that the PEGC is unavailable to serve the PIN. The AF for PIN will take into account the unavailability of the PEGC provided by 5GS and take appropriate actions, such as reconfiguring a new PEGC for the PIN, switching services and ensuring continuity via the new PEGC, or instructing the PEMC to trigger PEGC discovery and selection via the user plane.

[0011] In one example, when the AMF receives a new information element from the PEGC about its unavailability, it can notify the PEMC associated with the provided PIN ID of this situation.

[0012] When PEGC receives a rejection reason #22 (congestion, rejected due to general NAS-level mobility management congestion control), it can trigger a Public Land Mobile Network (PLMN) / Standalone Non-Public Network (SNPN) selection to find a suitable and available PLMN / SNPN that is not congested and can provide normal service.

[0013] When the PEGC becomes aware that a desired slice is no longer valid (rejected / not included in the allowed Network Slice Selection Assistance Information (NSSAI), etc.), it can trigger slice-based PLMN selection if the PEGC has slice-specific PLMN priority list information from the home network. Alternatively, the PEGC can send assistance information to the home network, providing the desired / rejected slices, and the home network can use the assistance information provided by the PEGC to generate a slice-based PLMN priority list and provide it to the PEGC via NAS signaling.

[0014] According to one example aspect, the Service Management Function (SMF) can notify the PEMC of PEGC unavailability upon rejection or upon realizing that the PEGC cannot serve the PIN by extending existing or new information elements. The PEMC will take the PEGC unavailability into account and take appropriate action, such as reconfiguring a new PEGC for the PIN, switching services and ensuring continuity via the new PEGC, and notifying the AF for the PIN of the reconfiguration via the user plane. Additional features, aspects, and embodiments are disclosed. Attached Figure Description

[0015] A more detailed understanding can be obtained from the following description, exemplarily given in conjunction with the accompanying drawings, wherein the same reference numerals denote the same elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments; Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used in the communication system shown; Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A System diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used in the communication system shown; Figure 1D It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown; Figure 2 This is a diagram of an exemplary Personal Internet of Things (IoT) Network (PIN) architecture; Figure 3 This is a diagram illustrating an exemplary home automation PIN; Figure 4 This is a diagram illustrating an exemplary wearable PIN; Figure 5 This is a block diagram illustrating the architecture of a PIN application (PINAPP) with exemplary embodiments; Figure 6 This is a message sequence diagram illustrating the actions of a wireless transmit and receive unit (WTRU) when a node called a PIN element with gateway capability (PEGC) is unable to serve a PIN, according to an exemplary embodiment. Figure 7 This is a message sequence diagram illustrating the actions of network functions (such as Access and Mobility Management Function (AMF) and Service Management Function (SMF)) when the PEGC is unable to serve the PIN, according to an exemplary embodiment. Figure 8 This is a flowchart illustrating a method for handling PEGC unavailability using WTRU according to an embodiment.

[0016] Figure 9 This is a flowchart illustrating a method for handling PEGC unavailability according to an embodiment. Detailed Implementation

[0017] Figure 1A This diagram illustrates an exemplary communication system 100 that can be used to implement one or more of the disclosed embodiments. The communication system 100 can be a multiple access system that provides content (e.g., voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal Frequency Division Multiple Access (OFDMA), Single Carrier Frequency Division Multiple Access (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Spread Spectrum OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0018] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments consider any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, any one of WTRUs 102a, 102b, 102c, and 102d may be referred to as a Station (STA), configured to transmit and / or receive wireless signals, and may include User Equipment (UE), mobile station, fixed or mobile subscriber unit, subscription-based unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, netbook, personal computer, wireless sensor, hotspot or Mi-Fi device, Internet of Things (IoT) device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any one of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0019] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to connect to at least one radio interface of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (e.g., CN 106 / 115, Internet 110, and / or other networks 112). For example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs (eNBs), home NodeBs, home eNodeBs, next-generation NodeBs (such as gNodeBs (gNBs), new radio (NR) NodeBs), site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single unit, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0020] Base station 114a may be part of RAN 104, and RAN 104 / 113 may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. 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 referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide radio service coverage for a specific geographic area, which may be relatively fixed or may vary over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0021] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116. Air interface 116 can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

[0024] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use NR to establish air interface 116.

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

[0026] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Evolution Enhanced Data Rate (EDGE), GSM EDGE (GERAN), etc.

[0027] Figure 1ABase station 114b can 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 a local area, such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may access Internet 110 without needing to go through CN 106.

[0028] RAN 104 can communicate with CN 106, which can be any network type configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although Figure 1A Not shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104. For example, in addition to connecting to RAN 104, which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0029] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the 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 use the same RAT as RAN 104 or a different RAT.

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

[0031] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keyboard 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 peripheral devices 138, etc. It should be understood that WTRU 102 may include any sub-combination of the foregoing units while remaining consistent with the embodiments.

[0032] Processor 118 may be a general-purpose processor, a special-purpose 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), any other type of integrated circuit (IC), a state machine, etc. Processor 118 may perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 may be coupled to transceiver 120, and transceiver 120 may be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

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

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

[0035] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11).

[0036] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keyboard 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keyboard 126, and / or display / touchpad 128. Furthermore, the processor 118 may access and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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 user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access and store data in memory that is not physically located on WTRU 102 (e.g., a server or home computer (not shown)).

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

[0038] 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) about 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 air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0039] The processor 118 may be further coupled to other peripheral devices 138, which may include software and / or hardware modules providing one or more additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), universal serial bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may include one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors, geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, humidity sensors, etc.

[0040] WTRU 102 may include a full-duplex radio unit for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of both UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio unit may include an interference management unit to reduce and / or substantially eliminate self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio unit for which the transmission and reception of some or all signals (e.g., associated with a specific subframe of UL (e.g., for transmission) or DL ​​(e.g., for reception) are separate.

[0041] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0042] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each of eNode-Bs 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, for example, eNode-B 160a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

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

[0044] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing units are depicted as part of CN 106, it should be understood that any of these units may be owned and / or operated by an entity other than a CN operator.

[0045] The MME 162 can connect to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting specific service gateways during the initial attachment of WTRUs 102a, 102b, and 102c. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0046] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0047] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0048] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional wired communication equipment. For example, CN 106 may include or be able to communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 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.

[0049] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0051] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and from the BSS. Traffic from outside the BSS to a STA can reach and be transmitted to the STA via the AP. Traffic from a STA to a destination outside the BSS can be sent to the AP for transmission to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send a traffic flow to the AP, and the AP can transmit the traffic flow to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) via Direct Link Establishment (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode can function without access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0052] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel (e.g., the primary channel). The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish connections with the AP. In some representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) can be implemented, for example in an 802.11 system. For CSMA / CA, STAs including the AP (e.g., each STA) can listen to the primary channel. If a particular STA listens / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0053] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0054] Very High Throughput (VHT) STAs support wide channels of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels, which is referred to as an 80+80 configuration. For the 80+80 configuration, channel-coded data is delivered via a segmented parser that splits the data into two streams. Each stream can be individually processed using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the merged data can be sent to Media Access Control (MAC).

[0055] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0056] WLAN systems supporting multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The bandwidth of the primary channel can be equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STAs operating in the BSS that support the minimum bandwidth operating mode. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands may be considered busy, even if most of the available frequency bands are still idle.

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

[0058] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0059] RAN 104 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may use beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In embodiments, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0060] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using multiple or scalable length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths).

[0061] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without simultaneously accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with another RAN (e.g., eNode-B 160a, 160b, and 160c) while simultaneously communicating / connecting with gNBs 180a, 180b, and 180c. For example, WTRUs 102a, 102b, and 102c can implement the DC principle to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput to serve WTRUs 102a, 102b, and 102c.

[0062] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, and routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0063] Figure 1D The CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing units are depicted as part of CN 106, it should be understood that any of these units may be owned and / or operated by an entity other than a CN operator.

[0064] AMF 182a and 182b can connect to one or more of gNB 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service types being utilized by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b provide control plane functionality for switching between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies, such as WiFi.

[0065] SMF 183a and 183b can connect to AMF 182a and 182b in CN 106 via the N11 interface. SMF 183a and 183b can also connect to UPF 184a and 184b in CN 106 via the N4 interface. SMF 183a and 183b can select and control UPF 184a and 184b and configure service flow routing through UPF 184a and 184b. SMF 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0066] UPF 184a and 184b can be connected via the N3 interface to one or more of gNB 180a, 180b, and 180c in RAN 104, thereby providing WTRU 102a, 102b, and 102c with access to a packet-switched network (e.g., Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-destination PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0067] CN 106 can facilitate communication with other networks. For example, CN 106 may include or be able to communicate with an IP gateway (such as an IP Multimedia Subsystem (IMS) server), which acts as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRUs 102a, 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. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to local DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and the N6 interface between UPFs 184a and 184b and DNs 185a and 185b.

[0068] Given Figures 1A to 1D And to Figures 1A to 1D As described herein, one or more of the functions described herein, relating to one or more of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other equipment described herein, may be performed by one or more emulation devices (not shown). Emulation devices may be configured to emulate one or more devices that perform one or more of the functions described herein. For example, emulation devices may be used to test other equipment and / or simulate network and / or WTRU functions.

[0069] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more functions when fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices may perform one or more functions when temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or to perform tests using over-the-air wireless communication.

[0070] One or more simulation devices may perform one or more (including all) functions when not implemented or deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used in test scenarios within a test laboratory and / or an undeployed (e.g., under test) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0071] As used in the exemplary embodiments described herein, the following terms have the relevant meanings indicated. It should be understood that the embodiments are described by way of example only, and the related terminology is not intended to limit the embodiments to any particular architecture, in which different elements, functions, and / or network architectures may be used to obtain similar advantages.

[0072] Personal IoT Network (PIN): A configured and managed group of PIN elements that can communicate directly with each other, communicate with each other via a gateway-capable PIN element (i.e., PEGC), or use PEGCs to communicate with devices or servers outside the PIN via a 5G network. A PIN includes at least one PEGC and is managed by a manageable PIN element (i.e., PEMC). If an AF (Automatic Front-End) is deployed, PIN management can be achieved through AF support.

[0073] PIN Element (PINE): A WTRU, UE, or non-3GPP device that can communicate within a PIN (via a direct PINE-to-PINE connection or an indirect PINE-to-PINE connection) or outside the PIN via a PINE with gateway capabilities (PEGC) and a network (e.g., 5GC).

[0074] PIN Element with Gateway Capability (PEGC): A PIN element that has the ability to provide data network (DN) connectivity to other PIN elements via a 5G network and / or to provide relay functionality for communication between PIN elements. Only WTRU or UE can act as a PEGC by registering with 5GS.

[0075] PIN element with management capability (PEMC): A PIN element with the ability to manage PINs.

[0076] PIN to DN communication: Connections between PINE, PEMC and DN via PEGC and User Plane Function (UPF), and connections between PEGC and DN via UPF.

[0077] PIN direct communication: A connection between two PIN elements, between a PIN element and a PEGC, between a PIN element and a PEMC, between a PEMC and a PEGC, or between two PEGCs, which does not traverse intermediate PIN elements, any intermediate 3GPP Radio Access Network (RAN) or UPF.

[0078] PIN indirect remote communication: Connections between two PIN elements, between a PIN element and a PEGC, between a PIN element and a PEMC, or between a PEMC and a PEGC via a PEGC and a UPF.

[0079] PINE to PINE routing: Service flows are routed by PEGC between two PINEs, which are directly connected to PEGC via non-3GPP access.

[0080] PINE to Network Routing: Service flows are routed between PINE and 5GS by PEGC. PINE can connect directly to PEGC via non-3GPP access.

[0081] Network-local switching for PINs: Service flows are routed by the UPF between two PINEs, which are directly connected to two PEGCs via non-3GPP access.

[0082] As described in the exemplary embodiments, the functionality described as part of PINE can be implemented in the PIN client. Additionally, the functionality described as part of PEGC can be implemented in the PIN gateway client. The functionality described as part of PEMC can be implemented in the PIN management client. The functionality described as part of the PIN client can be performed by other functions of PINE. The functionality described as part of the PIN gateway client can be performed by other functions of PEGC, and the functionality described as part of the PIN management client can be performed by other functions of PEMC.

[0083] An embodiment for WTRU action when the PEGC is unable to serve a PIN includes that, upon receiving a NAS rejection message from the AMF, the PEGC triggers a second NAS message to the AMF. The PEGC will provide new information elements (IEs) in the second NAS message, indicating that the WTRU is a PEGC, that the WTRU will be unavailable, and the corresponding PIN identifier (PIN ID). This or these new information elements will notify the AMF that the rejected WTRU is a PEGC serving a specific PIN identified by the PIN ID.

[0084] In some embodiments, the second NAS message carrying new information elements may be a deregistration message, a PDU session release message associated with a PDU session serving the PIN, a registration request that requests network slice selection assistance information (NSSAI) which may not include a single (S-NSSAI) associated with a PDU session serving the PIN, or an uplink transmission message.

[0085] In some embodiments, a message carrying new information elements may be triggered by any of the following: receiving a NAS message with a rejection reason code; local configuration (e.g., a user configuring a WTRU to indicate that it should no longer serve the PIN or act as a PEGC); leaving a geographic area associated with the PIN, or entering a geographic area not associated with the PIN.

[0086] According to various embodiments, the new information element may indicate any of the following: the reason why the WTRU can no longer serve as a PEGC for the PIN (e.g., a reason indication that triggered the message); how long the WTRU is expected to be unavailable to serve the PIN (e.g., this could be based on a fallback timer value received from the network); the identifier of the PIN for which the WTRU can no longer serve as a PEGC; an indication of whether the WTRU will continue to serve as a gateway for routing local traffic flows within the PIN; and / or the service type (e.g., mission-critical, streaming, multimedia, interactive, etc.) and its respective status (e.g., active / paused / inactive). In some embodiments, the NAS layer will send a notification to the PEGC client informing them that the PDU session has been terminated.

[0087] An embodiment of network function (e.g., AMF / SMF) actions when the PEGC is unable to serve the PIN may include the following steps. In one embodiment, the Service Management Function (SMF) receives an indication that a PDU session of a first WTRU is associated with the PIN. The SMF determines to perform a PDU session release procedure for that PDU session. The determination to perform PDU session release may be based on receiving a PDU session release message from the first WTRU. The PDU session release message from the first WTRU may indicate the PDU session associated with the PIN and may indicate the PIN ID.

[0088] In one embodiment, the SMF receives the identifier of the second WTRU and information indicating that the second WTRU is a PIN PEMC. Upon receiving a NAS message with the reason "Unavailable" and the WTRU identified as a PEGC, the SMF can obtain the identifier of the second WTRU by querying the Unified Data Management (UDM) / Unified Data Repository (UDR) and providing the PIN ID in the query request. The SMF then sends a message to the second WTRU including an indication that the first WTRU's PDU session is unavailable. In some embodiments, this message may indicate the reason why the first WTRU's PDU session is unavailable. Examples of reasons may indicate congestion, the WTRU being out of service area, the WTRU being unreachable, and / or the need to subscribe to updates. In some embodiments, this message may be a NAS message.

[0089] According to some embodiments, certain steps may be performed by the Access and Mobility Management Function (AMF). In one example, when the AMF receives a NAS message with new information elements providing information about the unavailability of the PEGC and its association with the PIN ID, it may pass this information to the Network Open Function (NEF) and store it in the WTRU subscription information in the UDR. Upon receiving the PEGC unavailability information from the WTRU, the AMF, knowing the identifier of the WTRU acting as the PIN PEMC, will trigger downlink NAS signaling toward the PEMC (e.g., WTRU configuration update command, DL NAS transport) to notify the PEMC of the PEGC unavailability (i.e., including the new IE, PEGC unavailability, and PIN ID). The AMF may know the PEMC's identifier based on subscription information from the UDM.

[0090] In some embodiments, WTRU policies can be configured. As an example, the Policy Control Function (PCF) can provide one or more WTRU policies to the WTRU. The PCF can provide each WTRU policy using one or more WTRU policy parts, each part being identified by a User Equipment Policy Part Identifier (UPSI). The UPSI references a rule for a given service or application used for PDU sessions and network slicing, which is called a User Equipment Routing Policy (URSP). A URSP rule is a type of WTRU policy.

[0091] In some embodiments, when a service flow is initiated by a WTRU application, the WTRU uses URSP rules to determine the required characteristics of the PDU session that will carry the application service flow. Examples of PDU session characteristics are the Data Network Name (DNN), Single Network Slice Selection Auxiliary Information (S-NSSAI), and the Session and Service Continuity (SSC) mode associated with the PDU session.

[0092] URSP rules are a policy that WTRUs can use to determine how to route outgoing traffic. Traffic can be routed to an established PDU session, offloaded to a non-3GPP access point outside the PDU session, routed to a network trunk via a ProSe layer 3 WTRU outside the PDU session, or trigger the establishment of a new PDU session.

[0093] Each URSP rule consists of two parts. The first part of the URSP rule is the traffic flow descriptor, which determines when the rule applies. The URSP rule applies when each component in the traffic flow descriptor matches the corresponding information from the application. The second part of the URSP rule is a list of route descriptors (RSDs). The list of route descriptors contains one or more route descriptors. RSDs are listed in priority order and describe the characteristics of a PDU session that can be used to carry uplink application data. Characteristics of the PDU session include SSC mode, DNN, and S-NSSAI. Alternatively, the RSD may include a non-seamless offloading indication, which indicates that the traffic flow can be transmitted via non-3GPP access (e.g., WiFi) and outside any PDU session.

[0094] For each newly detected application, WTRU evaluates URSP rules in order of rule priority and determines whether the application matches any URSP rule's traffic descriptor. When it is determined that a URSP rule applies to a given application, WTRU selects a route descriptor within that URSP rule in order of route descriptor priority.

[0095] When a valid route descriptor is found, the WTRU determines whether an existing PDU session exists that matches all components in the selected route descriptor. If a matching PDU session exists, the WTRU associates the application with the existing PDU session; that is, the WTRU routes the detected application's traffic to that PDU session. If no matching RSD exists in the existing PDU sessions, the WTRU attempts to establish a new PDU session using the values ​​specified by the selected route descriptor.

[0096] If the RSD includes a non-seamless offloading indication, the WTRU will attempt to transmit data outside of any PDU session using the WLAN access network. WLANSP rules may have been used to select the WLAN access network.

[0097] Once a traffic flow from an application is associated with a PDU session, an event may cause the WTRU to re-evaluate the URSP rules and associate the traffic flow from that application with a different PDU session. Two events that may trigger URSP re-evaluation are implementation-dependent re-evaluation timers and the WTRU establishing access to a Wi-Fi network that provides internet access without using a 5G system (i.e., non-seamless offloading becomes possible).

[0098] Flow descriptors can be application descriptors, IP descriptors, domain descriptors, non-IP descriptors, DNNs, or connectivity capabilities. IP descriptors can be destination IP 3-tuples (i.e., IP address or IPv6 network prefix, port number, protocol ID of the protocol over IP).

[0099] refer to Figure 2 An exemplary personal IoT network architecture is illustrated. As briefly described above, the personal IoT network (PIN) 202 is a group of configurable and managed PIN elements 204 that can communicate with each other directly or via gateway-capable PIN elements (PEGCs) 206, and with the 5G network 210 via at least one PEGC 206. PIN 202 is managed by at least one manageable PIN element (PEMC) 208. PIN elements (PINEs) 204 are any WTRU, UE, or non-3GPP device that can communicate within PIN 202 (via direct PIN connection, via PEGC 206, or via PEGC 206 and 5GC 210), or outside PIN 202 via PEGC 206 and 5GC 210. A gateway-capable PIN element (PEGC) is a PIN element that provides connectivity to the 5G network for other PIN elements or relays communication between PIN elements. A manageable PIN element (PEMC) 206 is a PIN element capable of managing PINs.

[0100] Some personal IoT networks make the following architectural assumptions: (i) only 3GPP WTRUs can act as PEGCs and / or PEMCs; (ii) one or more PEGCs are in one PIN; (iii) one or more PEMCs are in one PIN, one of which can control the PIN at any given time; (iv) it is assumed that the PIN elements use non-3GPP access (e.g., WIFI, Bluetooth) for direct communication, and the PEMC can use 5G ProSe direct communication to communicate directly with the PEGC; (v) the PEGC and PEMC belong to the same PLMN or (S) NPN; (vi) a single PEGC can support multiple PINs simultaneously; and (vii) multi-hop P2P (i.e., communication between PINE chains) and P2N relay (i.e., communication from one PINE to another or to the network via an intermediate PINE).

[0101] refer to Figure 3 and Figure 4 This illustrates an example of a Personal Internet of Things (PIN) network. Internet of Things (IoT) capabilities are designed for devices that communicate using traditional cellular networks. Devices with IoT capabilities require better power performance and improved network efficiency for batch operations.

[0102] When multiple IoT devices are deployed in a private environment, IoT-capable WTRUs can be organized into a Personal IoT Network (PIN). For example, as Figure 3 As shown in the home automation PIN 300, in a home environment, devices such as security sensors 302, smart lights 304, smart plugs 306, printers 308, and mobile phones 310 are managed by a residential gateway 312 and communicate with each other. In this scenario, all devices in the home constitute a Personal IoT Network (PIN) 300. Each device is referred to as a PIN element, and different PIN elements have different capabilities. For example, the residential gateway 312 can be a PIN element with gateway capabilities (PEGC) used to provide connectivity between PIN elements and between the 5G network 314 and the PIN elements. A PIN element with management capabilities (PEMC) is a PIN element that provides a means for authorized administrators to configure and manage PINs. The residential gateway acting as a PEGC can also support PIN management functions and become a PIN element with management capabilities (PEMC).

[0103] like Figure 4As shown in the example PIN, multiple wearable devices can also constitute another PIN 402, 410, in which smartphones 402, 414 can act as PIN elements with gateway capabilities (PEGC) and PIN elements with management capabilities (PEMC), while smartwatches 404, 414, VR / AR glasses 406, 416, and headphones 408, 418 communicate with each other within the PIN (or communicate with other WTRUs via 5G network 430).

[0104] refer to Figure 5 The example PIN Application Framework (PINAPP) 500 is shown. The Personal IoT Network (PIN) 502 can also support application layer protocols and can be based on the PIN application layer functional model. Figure 5 An exemplary application architecture 500 for enabling PINAPP is shown.

[0105] It is important to note that application entities (such as PIN clients 504, 506, and 508 in PINE 510, 512, and 514, PIN gateway client 516 in PEGC 518, PIN management client 520 in PEMC 522, and / or PIN server 524 in data network 526) can be part of the PINAPP architecture 500 and implement the required functionality in PIN. The embodiments described herein can interchangeably refer to these functional entities and PIN nodes to implement PINAPP functionality.

[0106] A Registered Area (RA) is a set of Tracking Areas (i.e., a list of Tracking Area IDs (TAIs)). This set of Tracking Areas includes the Tracking Areas of any NG-RAN nodes used by the WTRU within the Registered Area. When constructing the RA, the AMF can consider various pieces of information (e.g., the WTRU's movement pattern and permitted / unpermitted areas).

[0107] Mobility patterns are a concept that the AMF (Active Network Data Analysis) can use to characterize and optimize WTRU mobility. The AMF determines and updates WTRU mobility patterns based on WTRU subscriptions, WTRU mobility statistics, network-local policies, and WTRU ancillary information, or any combination of these. WTRU mobility statistics can be historical or projected WTRU mobility trajectories. If Network Data Analysis Function (NWDAF) is deployed, WTRU mobility statistics can also be analyses (i.e., statistics or predictions) provided by NWDAF. Mobility patterns can be used by the AMF to optimize mobility support provided to WTRUs, such as registration area allocation.

[0108] The requested NSSAI is the NSSAI provided by the WTRU to the service PLMN during registration. The permitted NSSAI is a list of S-NSSAI values ​​that indicate the WTRU can use in the service PLMN within the currently registered area.

[0109] A rejected S-NSSAI can also be called a "rejected slice". WTRUs receive rejected NSSAIs from the AMF via NAS messages. A rejected NSSAI is a list of rejected S-NSSAIs. In other words, a rejected NSSAI is a list of rejected slices. The list of rejected slices can be sent to the WTRU in NAS messages (e.g., registration accept, deregistration request, WTRU configuration update command, or registration reject message). Each rejected S-NSSAI in the rejected NSSAI is associated with a reason value that indicates why the AMF rejected the slice. This reason value is also used by the WTRU to determine when the WTRU will be allowed to register to a rejected slice again.

[0110] In certain circumstances, the network may send a rejected NSSAI to the WTRU for the current PLMN or SNPN. This NSSAI is a set of S-NSSAIs included in the requested NSSAI by the WTRU and rejected by the AMF with the reason "S-NSSAI is not available in the current PLMN or SNPN". If the network accepts the WTRU's registration request and the WTRU receives the rejected NSSAI for the current PLMN or SNPN, the WTRU will not attempt to use this S-NSSAI in the current PLMN or SNPN until the WTRU is powered off, the UICC containing the USIM is removed, the Subscriber Data List entry with the SNPN identifier of the current SNPN is updated, or the network sends a message to the WTRU indicating that the S-NSSAI is no longer considered a rejection.

[0111] In certain circumstances, the network may send a rejected NSSAI to the WTRU for the current registration area. This NSSAI is a set of S-NSSAIs included in the WTRU's requested NSSAI and rejected by the AMF with the reason "S-NSSAI is not available in the current registration area". If the network accepts the WTRU's registration request and the WTRU receives a rejected NSSAI for the current registration area, the WTRU will not attempt to use this S-NSSAI in the current registration area until the WTRU is powered off, the WTRU is removed from the current registration area, the UICC containing the USIM is removed, the "Subscriber Data List" entry with the SNPN identifier of the current SNPN is updated, or the rejected S-NSSAI is removed, or the network sends a message to the WTRU indicating that the S-NSSAI is no longer considered rejected.

[0112] In other cases, the network may send a rejected NSSAI to the WTRU for a failed or revoked Network Slice-Specific Authentication and Authorization (NSSAA), which is a set of S-NSSAIs. The AMF may send a rejection with the reason "S-NSSAI unavailable due to failed or revoked Network Slice-Specific Authentication and Authorization." If the network accepts the WTRU's registration request and the WTRU receives a rejected NSSAI for a failed or revoked NSSA, the WTRU will not attempt to use this S-NSSAI in the current PLMN or SNPN through any access until the WTRU is powered off, the UICC containing the USIM is removed, the "Subscriber Data List" entry with the SNPN identifier of the current SNPN is updated, or the network sends a message to the WTRU indicating that the S-NSSAI is no longer considered a rejection.

[0113] In a further scenario, the network can send a rejection NSSAI to the WTRU for reaching the maximum number of WTRUs. This NSSAI is the set of S-NSSAIs included in the WTRU's requested NSSAI. The AMF can send the rejection with the reason "S-NSSAI unavailable due to reaching the maximum number of WTRUs." The network can also provide a fallback time value, called T3526, for each rejected slice. If the network accepts the WTRU's registration request and the WTRU receives a rejection NSSAI for reaching the maximum number of WTRUs, the WTRU will not attempt to use this S-NSSAI in the current PLMN or SNPN through the current access until the WTRU is powered off, the UICC containing the USIM is removed, the "Subscriber Data List" entry with the SNPN identifier of the current SNPN is updated, the fallback timer expires, or the network sends a message to the WTRU indicating that the S-NSSAI is no longer considered deleted.

[0114] In the example above, when the WTRU receives a rejected slice, it is prevented from attempting to register with that slice again until an event occurs. This event could be the WTRU leaving the PLMN, leaving the RA, or when the fallback timer expires. This can be advantageous because it prevents the WTRU from repeatedly attempting to register with the rejected slice. Therefore, it prevents the WTRU from generating unnecessary signaling (i.e., attempting to register with a slice repeatedly rejected by the network).

[0115] As mentioned earlier, the PEGC is a WTRU that has subscription data related to the PIN associated with the 5GS and can register with the 5GS. A PEGC serving the PIN may fail to provide service to the PIN because it may not be able to provide data connectivity to the external DN, the reasons for which are discussed in this paper. The PEGC may fail to provide service to the PIN because registration may fail or other NAS processes may fail, such as session management (SM) processes (e.g., PDU session establishment) or mobility management (MM) processes (e.g., registration or service request).

[0116] These processes can be considered unsuccessful because the WTRU receives a rejection message from the network. Embodiments are described to handle PIN element traffic flows when the PEGC serving the PIN is rejected by the 5GS due to congestion or other reasons (preventing the PEGC from providing a data path for the PIN traffic flow).

[0117] Mechanisms and enhancements are described to address scenarios where PEGCs providing data connectivity to a PIN are rejected by 5GS for congestion or other rejection reasons, as well as methods to mitigate this situation.

[0118] In some embodiments, the PEGC can trigger a deregistration process to the 5GS and provide new information elements (IEs) indicating that the PEGC is unavailable and a PIN ID used to identify the PIN. The AMF can then pass this information to the appropriate AF for the PIN, which, upon receiving the PEGC unavailability, will trigger appropriate actions such as PEGC relocation, reconfiguring a different PEGC for the PIN for service handover and continuity.

[0119] In another embodiment, the AMF serving the PIN learns about the association between the PEGC and the PIN through subscription information (or the SMF provides subscription information about the WTRU associated with the PIN and / or the PIN element with gateway capabilities). When the AMF detects that the PEGC is unavailable for various reasons (congestion / denial, etc.), it can notify the PEMC associated with the PIN of the PEGC unavailability.

[0120] In another embodiment, when the SMF refuses or becomes aware that the PEGC cannot serve the PIN, it will notify the PEMC of the PEGC unavailability via NAS SM signaling, where the information is provided by an updated or new information element.

[0121] PEMC will take into account the unavailability of PEGC and trigger appropriate actions, such as reconfiguring a new PEGC for the PIN, service switching and continuity via the new PEGC, and reconfiguring via the user plane to the AF for the PIN.

[0122] refer to Figure 6This document illustrates and describes an embodiment of WTRU / AMF action when the PEGC is unable to serve the PIN. As previously stated, the PEGC is a PIN element that has the capability to provide connectivity to 5G networks for other PIN elements or to relay communication between PIN elements. The PIN element uses the PDU session established by the PEGC for UL data service flows to external data networks.

[0123] In one embodiment, such as Figure 6 As shown, a method for operating a WTRU in a network may include, in step 1, successfully establishing a PIN 600 with multiple PINE 602s, one PEMC 604, and one or more PEGC 606s. In step 2, a trigger at PEGC 606 causes PEGC 606 to send a NAS signaling request to the AMF in 5GC 608. Exemplary triggers may include initial / mobile / periodic registration requests, establishing a PDU session for a PINE traffic flow, or a service request process to move PEGC 606 from a CM-IDLE state to a CM-CONNECTED state, etc.

[0124] In step 3, the AMF may reject the NAS signaling request for reasons such as congestion, reaching the maximum number of PDU sessions, insufficient resources for a specific slice and DNN, insufficient resources for a specific slice, insufficient user plane resources for a PDU session, payload not being forwarded by the mobility management layer, failure of network slice-specific authentication and authorization or revocation of authorization, partial rejection / allowance of network slices, or the rejected slice / requested slice not being part of the allowed slices provided by 5GS 608.

[0125] In certain scenarios (e.g., congestion), the AMF can provide a fallback timer for the PEGC 606, where the PEGC 606 is not allowed to initiate UL NAS signaling for normal service, with exceptions including high-priority services, emergency services, or deregistration procedures. In another use case, the AMF can update the allowed NSSAI information to the PEGC, which will cause certain slices used / expected by the PEGC to become invalid, i.e., not belonging to the allowed NSSAI list.

[0126] In an alternative embodiment, upon receiving a rejection reason from 5GS 608 in step 3, PEGC 606 may alternatively act. Examples include the typical behavior upon receiving a rejection reason indicating congestion, whereby the WTRU is backed up by the network with a back-off timer value, and during the back-off timer's execution, the WTRU is not allowed to access the network for normal service and can continue with normal cell reselection. Alternatively, this restriction may be specifically removed for the WTRU (PEGC), and upon receiving a congestion reason, it triggers PLMN / SNPN selection to find other available and suitable non-congested PLMN / SNPNs.

[0127] In scenarios where a specific slice is rejected or no longer valid, PEGC can use slice-priority-ordered PLMNs to trigger slice-specific PLMN selection and attempt to find available and suitable PLMNs that support the rejected / desired slice.

[0128] In scenarios where a specific slice is rejected or removed from the allowed NSSAI and the PEGC does not have a PLMN with slice-based priority ranking provided by its home network, new WTRU auxiliary information (providing desired / rejected slice information) can be created and sent to the home network to request a slice-based PLMN priority list. The home network can use the WTRU auxiliary information provided by the PEGC to generate a slice-based PLMN priority list and provide it to the PEGC via NAS signaling (e.g., SoR / DL NAS transmission). The PEGC can then use the newly received information to find available and suitable PLMNs supporting the rejected / desired slice.

[0129] In step 4, upon receiving a rejection message from the AMF, the PEGC 606 triggers a deregistration process with the AMF. The PEGC 606 can provide new information elements (IEs) indicating that the WTRU is a PEGC, the WTRU will be unavailable, and the corresponding PIN identifier (PIN ID). One or more newly defined information elements will notify the AMF that the rejected WTRU is a PEGC serving a specific PIN identified by the PIN ID.

[0130] Alternatively, the NAS message carrying new information elements can be a deregistration message. In another embodiment, the NAS message carrying new information elements can be a PDU session release message associated with a PDU session serving the PIN. In another example, the NAS message carrying new information elements can be a registration message, and the requested NSSAI of the registration message may not include the S-NSSAI associated with the PDU session serving the PIN. Alternatively, the NAS message carrying new information elements can be a UL transport message.

[0131] In various embodiments, a message carrying new information elements may be triggered by: (i) receiving a NAS message with a rejection reason code; (ii) local configuration (e.g., a user configuring the WTRU to indicate that it should no longer serve the PIN or act as a PEGC); (iii) leaving the geographic area associated with the PIN; or (iv) entering a geographic area not associated with the PIN.

[0132] In various embodiments, the newly defined information elements may indicate one or more of the following: the reason why the WTRU can no longer act as a PEGC for the PIN (e.g., a reason for triggering the message); how long the WTRU is expected to be unavailable to serve the PIN (e.g., this may be based on a fallback timer value received from the network); the identifier of the PIN for which the WTRU can no longer act as a PEGC; whether the WTRU will continue to act as a gateway for routing local traffic flows in the PIN; if the WTRU indicates that it will continue to act as a PEGC, the duration for which the WTRU will continue to act as a gateway; and / or the type of service (e.g., mission-critical, streaming, multimedia, interactive, etc.) and its respective status (e.g., active / paused / inactive).

[0133] In step 5, when the AMF receives a deregistration message with new information elements providing information about the unavailability of the PEGC and the PIN ID, it will either pass this information to the NEF 610 or store it in the WTRU subscription information in the UDR. The AMF can relay this information to the SMF, and the SMF can release the associated PDU session and invoke service operations to request the removal of the Session Management (SM) policy associated with the Policy Control Function (PCF). The SMF can know that the PDU session is being used to serve the PIN, and it can also know that the PDU session is serving the PIN based on the WTRU subscription information received by the SMF from the UDM / UDR. For example, service-specific information in the WTRU subscription information may include an indication that the DNN / S-NSSAI combination is serving the PIN. Based on the fact that the PDU session is serving the PIN and based on the fact that the PDU session is being released or rolled back, the SMF can send a notification to the NEF or to the UDM / UDR informing them that the PEGC is unavailable.

[0134] In step 6, NEF 610 may relay the information received from 5GS 608 to AF 612 for PIN service. Note that a notification sent to NEF 610 to inform NEF that WTRU is unavailable for PIN service may alternatively originate from UDM / UDR.

[0135] In step 7, AF 612 for the PIN will consider the unavailability of PEGC 606 provided by 5GS 608 and take appropriate action. Such actions may include reconfiguring a new PEGC for the PIN, service switching and continuity via the new PEGC, and instructing the PEMC via the user plane to trigger PEGC discovery and selection.

[0136] In step 8, or, upon receiving information from the WTRU that PEGC 606 is unavailable, the AMF that knows PEMC 604 based on the subscription information from the UDM will trigger downlink NAS signaling to the PEMC (e.g., WTRU configuration update command, DL NAS transmission) to notify of the unavailability of PEGC (i.e., including new IE, PEGC unavailable, PIN ID).

[0137] In step 9, PEMC 604 will consider the unavailability of PEGC 606 and take appropriate action. Such actions may include: discovering an alternative PEGC, notifying PINE of the PEGC unavailability, reconfiguring a new PEGC for the PIN, service switching and continuity via the new (e.g., alternative) PEGC, and / or notifying AF 612 for the PIN of the reconfiguration via the user plane.

[0138] refer to Figure 7 This section describes an embodiment where the Service Management Function (SMF) 710 cannot process PEGC 706 for PIN 700. As previously described, PEGC 706 is a PIN element that has the capability to provide connectivity to a 5G network for other PIN elements 702 or to provide relay functionality for communication between PIN elements 702. The PIN element uses the PDU session established by PEGC 706 for UL data service flows with an external data network.

[0139] In step 1, a PIN 700 with multiple PINE 702s, one PEMC 704, and one PEGC 706 is successfully established. In step 2, a trigger at PEGC 706 causes PEGC 706 to send a NAS signaling request to AMF 708. Exemplary triggers may include initial / mobile / periodic registration requests, establishing PDU sessions for PINE service flows, service request procedures to move PEGC from CM-IDLE state to CM-CONNECTED state, etc.

[0140] In step 3, the AMF 708 has rejected the NAS signaling process. Possible reasons for rejection include congestion, reaching the maximum number of PDU sessions, insufficient resources for a specific slice and DNN, insufficient resources for a specific slice, insufficient user plane resources for a PDU session, payload not being forwarded by the mobility management layer, network slice-specific authentication and authorization failure or authorization revocation, partial rejection / allowance of network slices, and the rejected / requested slice not being part of the allowed slices provided by 5GS. In some scenarios (e.g., congestion), the AMF 708 will provide a fallback timer to the PEGC 706, where the PEGC 706 is not allowed to initiate uplink NAS signaling for normal service, with exceptions including high-priority service, emergency service, or deregistration procedures. In another use case, the AMF 708 may update the allowed slice information to the PEGC 706, which will cause some slices used / expected by the PEGC 706 to become invalid.

[0141] In step 4, after rejecting PEGC 706, AMF 708 can call the Nsmf_PDUSession_ReleaseSMContext service operation to request the release of the PDU session and the deletion of the SM context used for PEGC (WTRU) in SMF 708.

[0142] In an alternative embodiment, assuming that AMF 708 is aware that the WTRU to be rejected is a PEGC, for example, through AMF / SMF coordination, or through subscription information from the UDM, or through the WTRU providing this information to AMF during the registration process, AMF may first notify SMF 710 of the request to release the PDU session associated with the PIN. This gives SMF 710 the opportunity to successfully provide PEGC unavailability information across PINs (i.e., to other PEMCs / PEGCs), after which AMF 708 will send a control plane (CP) rejection to PEGC 706.

[0143] In step 5, when SMF 710 receives a PDU session release request for the PIN from AMF 708 (the SMF is aware of the association between the PDU session and the PIN), it will trigger downlink SM signaling (e.g., 5GSM STATUS) towards the PEMC via AMF (e.g., DL NAS transmission) to notify the PEGC of its unavailability (i.e., including the new IE, PEGC unavailability, and PIN ID). If there is no active PDU session established with PEMC 706, SMF 710 will first establish a PDU session and transmit downlink SM messages to the PIN. If the PIN is served by multiple PEGCs, SMF 710 can also notify other PEGCs of the unavailability of the PEGC provided by AMF 708. SMF 710 can know about PEMC 706 based on the PIN subscription information from UDM and the PIN ID provided by AMF 708 via a new information element.

[0144] In step 6, PEMC 704 will take into account the unavailability of PEGC 706 and take appropriate actions, such as discovering an alternative PEGC, notifying PINE 702 of the PEGC unavailability, reconfiguring a new PEGC 700 for the PIN, switching services and maintaining continuity via the new (e.g., alternative) PEGC, and notifying the AF for the PIN of the reconfiguration via the user plane.

[0145] Figure 8 This is a flowchart illustrating a method 800 for a WTRU to manage a PEGC that is unavailable for service to a Personal Internet of Things (PIN) network, according to an exemplary embodiment. In step 802, the WTRU associated with the PIN registers with the 5G network and establishes a PDU session for the PIN's elements. In step 804, the WTRU acts as a PEGC for the data flow between the PIN and the 5G network. Due to any of the various reasons discussed earlier, the network may determine that the connection / service from the WTRU / PEGC to the network is unavailable, and in step 806, the WTRU receives a NAS signaling process rejection, referred to as "triggering". In response, in step 808, the WTRU / PEGC may send a New Information Element (IE) discussed earlier, including PEGC unavailability information and the PIN ID. Depending on the reason for the rejection, the WTRU may be deselected as the PEGC for the PIN, or the session may be re-established if, for example, a less congested PLMN / network slice can be configured. As described above, in one embodiment, a deregistration process to the network AMF may be triggered, where the IE indicates that the WTRU is a PEGC, the WTRU will be unavailable, and the corresponding PIN ID is used for network processing.

[0146] Figure 9This is a flowchart illustrating a method 900 for processing PEGC unavailability according to an embodiment. Figure 9 The steps performed on the network in relation to method 800 described above are described. In step 902, the 5G network registers a PEGC for the PIN. In step 904, the PEGC serves the network data flow with the PIN. Due to any of the reasons discussed earlier, in step 906, the network may determine that the connection / service from the WTRU / PEGC to the network is unavailable, and in step 908, a NAS signaling is sent to the rejected PEGC (WTRU). In step 910, the previously discussed New Information Element (IE), including PEGC unavailability information and the PIN ID, can be received from the WTRU / PEGC. Depending on the reason for rejection, the WTRU may be deselected as the PEGC for the PIN, or the session may be re-established if, for example, a less congested PLMN / network slice can be configured. In step 912, the IE is sent to the PEMC in a DL NAS signaling.

[0147] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via wired or wireless connections) and 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 (e.g., internal hard disks and removable disks), magneto-optical media, and optical media (e.g., CD-ROMs and Digital Universal Optical Discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for a wireless transmit and receive unit (WTRU), comprising: Register as a Personal Internet of Things Network (PIN) Component (PEGC) with gateway capabilities to a Wide Area Wireless Network (WWAN); Provide services for the data flow between the PIN element and the WWAN; Receive an indication that the data stream to the WWAN is unavailable; as well as Send a Non-Access Stratum (NAS) message to the network, the information element indicating the reason why the WTRU can no longer act as the PEGC for the PIN and the PIN identifier (ID).

2. The method of claim 1, wherein the indication of unavailability is based on one of the following: network congestion, reaching the maximum number of Packet Data Unit (PDU) sessions, insufficient resources for a specific network slice, insufficient user plane resources, failure of the mobility management layer to forward payloads, and failure of network slice authentication and authorization.

3. The method of claim 1, wherein the message includes one of the following: a deregistration process message with an Application Management Function (AMF), a PDU session release message, an uplink transmission message, and a registration message for Network Slice Selection Assistance Information (NSSAI), wherein the NSSAI lacks a slice associated with the PDU session serving the PIN.

4. The method of claim 1, wherein the unavailability indication includes one of the following: receiving a NAS message with a rejection reason code and a local configuration change made by a PIN element (PEMC) with management capabilities.

5. The method of claim 1, wherein the message of the information element is triggered by leaving or entering a geographic area associated with the PIN.

6. The method of claim 1, wherein the information element further includes a time value indicating how long the WTRU may no longer serve as the PEGC for the PIN, a time value indicating how long the WTRU is expected to be unavailable for serving the PIN, a duration indicating how long the WTRU will continue to serve as the PEGC, and a service type associated with serving the data stream.

7. The method of claim 1, wherein the PEGC provides connectivity to or from the WWAN for one or more other PIN elements.

8. The method of claim 6, wherein the one or more other PIN elements use the PEGC to communicate with a device or server outside the PIN via the WWAN.

9. The method of claim 1, wherein the PEGC provides relay functionality for communication between other PIN elements.

10. The method of claim 1, wherein the PEGC subscription includes data related to the PIN associated with the WWAN.

11. The method of claim 1, wherein the WWAN includes a fifth-generation (5G) network.

12. A wireless transmitting and receiving unit, comprising: A transceiver and a processor communicating with the transceiver, the transceiver and the processor being configured to perform any of the methods described in claims 1 to 11.

Images