Method and apparatus for individual Internet of Things network (PIN) management

Abstract

Methods and apparatus for individual Internet of Things network (PIN) management are described herein. A first wireless transmit / receive unit (WTRU) may transmit a first non-access stratum (NAS) request to a network node in a cellular network, the first non-access stratum (NAS) request indicating a capability of the first WTRU as a management enabled PIN element (PE) (PEMC) in a PIN. The WTRU may receive a first NAS response from the network node, the first NAS response including authorization information, an authorized PIN type, and a validity duration of the PIN. The WTRU may receive a connection request from a second WTRU, the connection request including PE information associated with the second WTRU. The PE information may include a PE type and PE capabilities. Based on the PE type and the PE capability being compatible with the authorized PIN type, the WTRU may send a connection response to the second WTRU, the connection response indicating that the second WTRU is authorized as a PE of the PIN.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 324,517, filed on March 28, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] When multiple Internet of Things (IoT) devices are deployed in a private environment, IoT-capable devices can be organized into a personal IoT network (PIN). A PIN may include PIN elements (PE) such as security sensors, smart lights, smart plugs, printers, and cellular phones. Different PEs may have different capabilities. For example, a PE with gateway capabilities (PEGC) may provide connections between PEs and between PEs and cellular networks. A PE with management capabilities (PEMC) may configure and / or manage PINs. However, methods and devices for creating, updating, authorizing / deauthorizing, activating / deactivating, and managing PINs have not yet been defined. Summary of the invention

[0004] Methods and apparatus for personal internet of things network (PIN) management are described herein. A first wireless transmit / receive unit (WTRU) may send a first non-access stratum (NAS) request message to a network node in a cellular network, the first non-access stratum (NAS) request message indicating the ability of the first WTRU to act as a PIN element (PE) with management capabilities (PEMC) in a PIN. The WTRU may receive a first NAS response message from the network node in the cellular network, the first NAS response message including authorization information for the first WTRU to act as the PEMC to initiate the PIN, the authorized PIN type, and the validity period of the PIN. The WTRU may receive a connection request message from a second WTRU, the connection request message including PE information associated with the second WTRU. The PE information may include the PE type of the second WTRU and the PE capabilities of the second WTRU. Based on the compatibility of the PE type and the PE capabilities with the authorized PIN type, the WTRU may send a connection response message to the second WTRU, the connection response message indicating that the second WTRU is authorized to act as a PE for the PIN. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which like reference numerals indicate like elements, and in which:

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

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

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

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

[0010] Figure 2 is a diagram illustrating an example home automation personal Internet of Things network (PIN);

[0011] Figure 3 is a diagram illustrating an example wearable device PIN;

[0012] Figure 4 is a diagram illustrating an example network architecture of a PIN;

[0013] Figure 5 is a diagram illustrating an example reference model of a 5G / next generation network;

[0014] Figure 6 is a diagram illustrating example PIN management;

[0015] Fig. 7A is a diagram illustrating an example of WTRU initiated PIN creation;

[0016] Figure 7B catch Fig. 7A ;

[0017] Figure 8 is a diagram illustrating an example PIN management procedure;

[0018] Fig. 9 is a diagram illustrating an example of a WTRU initiated PIN update;

[0019] Fig.10 is a diagram illustrating an example of a WTRU initiated PIN reestablishment;

[0020] Fig.11 is a diagram illustrating an example of PIN activation / deactivation with a validity timer;

[0021] Fig.12 is a diagram illustrating an example of network-initiated PIN creation; and

[0022] Fig.13 is a diagram illustrating an example of a network-initiated PIN update. DETAILED DESCRIPTION

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

[0024] 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, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a personal IoT network (PIN) element (PE) with management capabilities (PEMC), a PE with gateway capabilities (PEGC), a PIN element (PE), a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0026] The base station 114a may be part of the RAN 104, 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), a relay node, etc. The base station 114a and / or the base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of licensed and unlicensed spectrums. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, a cell associated with the base station 114a may be divided into three sectors. Therefore, in one embodiment, the base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

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

[0028] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology, such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), that may 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0045] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (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, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0061] 802.11af and 802.11ah support operating modes below 1GHz. Channel operating bandwidths and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support meter 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 support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain very long battery life).

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

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

[0064] Figure 1D1 is a system diagram illustrating the RAN 104 and the CN 106 according to one embodiment. As noted above, the RAN 104 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

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

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

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

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

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

[0070] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of non-access stratum (NAS) signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, etc. The AMF 182a, 182b may provide a control plane function for switching between the 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.

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

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

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

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

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

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

[0077] The terms used throughout this disclosure are as follows.

[0078]

[0079]

[0080] Internet of Things (IoT) features have been designed for devices that use traditional cellular networks for communication. IoT-capable devices require better power performance and higher network efficiency for bulk operations.

[0081] Figure 2 2 is a diagram illustrating an example home automation personal IoT network (PIN) 200, which may be used in conjunction with any of the other embodiments described herein. When multiple IoT devices are deployed in a private environment, WTRUs with IoT capabilities may be organized into a personal IoT network (PIN). For example, Figure 2As illustrated, in a home environment, a guest device (or guest PE) 202, a security sensor 204, a motion sensor 206, a smart lock 208, a smart key 210, a smart plug 212A, a smart light 212B, a smart plug 212C, 212D, a smart phone 214, a printer 218, etc. may be managed by a residential gateway 216 and communicate with each other. Smart plug 212A, smart light 212B, smart plug 212C, 212D may be used as a relay node for guest device (or guest PE) 202, security sensor 204, motion sensor 206, smart lock 208, and smart key 210. In this example, all devices 202-216 in the home may constitute a personal IoT network (PIN). Each of these devices may be referred to as a PIN element (PE), and different PIN elements (PE) may have different capabilities. For example, the residential gateway 216 may be a PIN element (PE) (PEGC) with gateway capabilities for providing connections between the PIN elements (PE) 202-214, 218 and between the 5G network 220 and the PIN elements 202-214, 218. A PIN element (PE) (PEMC) with management capabilities may be a PIN element (PE) that provides a means for an authorized administrator to configure and manage PINs. In one example, the residential gateway 216 acting as a PEGC may also support PIN management functions and may be a PIN element (PE) (PEMC) with management capabilities. In another example, the smart phone 214 may act as a PEMC that manages the PIN elements (PE) 202-212, 218 in the home automation PIN 200. The smart phone 214 (i.e., PEMC) may communicate directly with the PE 202-212, 218, or may communicate with the PE 202-212, 218 through the residential gateway 216 (i.e., PEGC). In one embodiment, the PEMC and PEGC may be logical functions located in a single entity / device / WTRU. In another embodiment, the PEMC and PEGC may be logical functions located in different, independent entities / devices / WTRUs. The PEMC and PEGC may include non-3GPP communication capabilities (e.g., Bluetooth, WiFi, Zigbee, Z-Wave, Bluetooth Low Energy, etc.) and 3GPP communication capabilities (e.g., LTE, 5G NR, etc.) for communicating with the PEs 202-218 and the 5G core network 220 (including the smartphone 222 in the 5G core network 220). The PEs 202-212 may include non-3GPP communication capabilities (e.g., Bluetooth, WiFi, Zigbee, Z-Wave, Bluetooth Low Energy, etc.) for communicating with the smartphone 214 (e.g., PEMC) and / or the residential gateway 216 (e.g., PEGC).The terms "PIN element (PE) with management capabilities", "PE with management capabilities", "PE management capabilities", "PIN management", "WTRU with management capabilities" and / or any combination thereof may be used interchangeably throughout the present disclosure. The terms "PIN element (PE) with gateway capabilities", "PE with gateway capabilities", "PE gateway capabilities", "PIN gateway", "WTRU with gateway capabilities" and / or any combination thereof may be used interchangeably throughout the present disclosure.

[0082] Figure 3 is a diagram illustrating an example wearable device PIN 300, which may be used in conjunction with any of the other embodiments described herein. Figure 3 As illustrated, wearable devices such as earphones 302, 312, smart glasses 304, 314, smart watches 306, 316, etc. may constitute another PIN, wherein smart phones 308, 318 may act as PIN elements (PE) with gateway capabilities (PEGC) and PIN elements (PE) with management capabilities (PEMC). For example, wearable device PIN 330 may include earphones 302, smart glasses 304, smart watch 306, and smart phone 308. Smart phone 308 may act as PEMC and PEGC for earphones 302, smart glasses 304, and smart watch 306, while earphones, smart glasses, and smart watches act as PEs in wearable device PIN 330. Wearable device PIN 330 may be connected to 5GS 310 via smart phone 308. Similarly, another wearable device PIN 335 may coexist with wearable device PIN 330. The wearable device PIN 335 may also include the headset 312, smart glasses 314, smart watch 316, and smart phone 318. The smart phone 318 may act as a PEMC and PEGC for the headset 312, smart glasses 314, and smart watch 316, while the headset, smart glasses, and smart watch act as PEs in the wearable device PIN 335. The wearable device PIN 335 may be connected to the 5GS 310 via the smart phone 318. In another example, the smart watches 306, 316, virtual reality (VR) / augmented reality (AR) glasses 304, 314, headsets 302, 312, etc. may communicate with each other in the PIN 330, 335 (or communicate with other WTRUs via the 5G network).

[0083] Figure 4 4 is a diagram illustrating an example architecture 400 of a personal Internet of Things network (PIN), which can be used in conjunction with any of the other embodiments described herein. Figure 4As illustrated, the PIN 420 may include, but is not limited to, PIN elements (PE) 402, 404, PIN management (PEMC) 406, and PIN gateway (PEGC) 408. The PIN elements (PE) 402, 404 may be WTRUs or non-3GPP devices that may communicate within the PIN 420. The PIN management device (i.e., PEMC) 406 may be a WTRU or PIN element (PE) that has the ability to manage the PIN 420. The PEGC 408 may be a WTRU or PIN element (PE) that is capable of providing connectivity to and from a 3GPP network (such as a 5G core network 422) for other PIN elements (PE) 402, 404. The 5G core network 422 may include a RAN 410, an AMF 412, an SMF 414, and a UDF 416. The UDF 416 may provide connectivity between the 5G network 422 and a data network 418.

[0084] like Figure 4 As illustrated, PIN elements (PE) 402, 404 may communicate with each other via PEGC 408 or directly. Alternatively or additionally, PIN elements (PE) 402, 404 may communicate with a 5G system to obtain 5G services, or communicate with a data network 418 via a 5G core network 422. The 5G core network 422 is an example of a wireless network. Wireless networks with which PEMC 406 and / or PEGC 408 may communicate may include, but are not limited to, GSM, CDMA, UMTS, LTE, and 5G.

[0085] As described above, the PIN element (PE) with management capability (PEMC) 406 and the PIN element (PE) with gateway capability (PEGC) 408 can be WTRU or UE equipped with 3GPP RAT and non-3GPP RAT, and all other communications within the PIN 420 can be performed by the PEMC 406 and PEGC 408 via non-3gpp communications (e.g., WiFi, Bluetooth, etc.).

[0086] Figure 5 is a diagram illustrating an example reference model 500 for a 5G or next generation network, which may be used in conjunction with any other of the other embodiments described herein. Figure 5 As illustrated, the 5G network may include a WTRU 502, a radio access network (RAN) 504, a user plane function (UPF) 506, a data network (DN) 508, an access control and mobility management function (AMF) 510, a session management function (SMF) 512, a policy control function (PCF) 514, an application function (AF) 516, an authentication server function (AUSF) 518 and a unified data management (UDM) 520.

[0087] The radio access network (RAN) 504 may refer to a 5G RAT or Evolved-E-UTRA based radio access network that is connected to a next generation core network.

[0088] Access control and mobility management function (AMF) 510 may include, but is not limited to, the following functionalities: registration management, connection management, reachability management, mobility management, etc.

[0089] The session management function (SMF) 512 may include, but is not limited to, the following functionalities: session management (including session establishment, modification and release), WTRU IP address allocation, UP function selection and control, etc.

[0090] A WTRU or PE with management capabilities (PEMC) may be responsible for creating and managing PINs, while a WTRU or PE with gateway capabilities (PEGC) may facilitate connectivity between PE and PEMC and the CN.

[0091] A PIN may include different PIN elements (PEs) with different characteristics, such as wearable devices, home automation devices, devices installed in vehicles, devices in offices, or smart industrial automation devices, which have different requirements and roles in terms of size, weight, power consumption, mission criticality, high bandwidth, etc. Based on the needs, the user can create a network (PIN) consisting of all or a subset of these devices (i.e., PEs), which can be static or dynamic in nature.

[0092] It is not clear how to create a PIN, authorize / deauthorize a PE, authorize / deauthorize a PEMC, authorize / deauthorize a PEGC, and activate / deactivate a PIN (regardless of whether the network or the WTRU initiates the PIN creation). Therefore, mechanisms need to be established, such as how a PIN is created, how a PE is authorized or deauthorized to communicate within a PIN, how a PEMC obtains authorization and deauthorization for PIN creation, how a PEGC obtains authorization and deauthorization for PIN creation, how a PIN is updated or rebuilt, how a PIN is activated or deactivated, and how the time validity of a PIN and its elements is established.

[0093] Embodiments of PIN creation, PIN reconstruction, PIN authorization and deauthorization, PIN activation and deactivation, and PIN validity duration are described herein. Figure 6 is a diagram illustrating an example PIN management 600, which may be used in conjunction with any of the other embodiments described herein.

[0094] This article describes an implementation scheme for PIN creation. Figure 6As illustrated, PIN creation may include authorization 605 of the PEMC, authorization 610 of the PEGC, and / or authorization (or activation) 615 of the PIN. WTRU-initiated PIN creation may mean that the PIN creation is initiated by the PEMC. At 605, the PEMC may first request and obtain authorization to act as a PEMC. At 610, the PEGC may independently request and obtain authorization, but it may also be selected by the PEMC and added to the PIN. The PEMC and PEGC may establish a direct connection to each other via PC5 or an indirect connection via Uu. At 615, the PE may establish a connection with the PEMC and request authorization to be part of the PIN, where the request for PIN creation is forwarded by the PEMC to the CN, which may be authorized by the CN or a third-party PIN server. It should be noted that the PEMC and PEGC may be logical entities in the WTRU or device equipped with 3GPP communication capabilities and non-3GPP RAT capabilities, or independent entities equipped with 3GPP communication capabilities and non-3GPP RAT capabilities.

[0095] Network-initiated PIN creation may mean that PIN creation is initiated by a PIN server. The PIN server may request the CN to provide information on all available PEMCs, PEGCs, and PEs that meet certain criteria. The PIN server may then create PINs for available PEs, PEMCs, and PEGCs based on specific services or applications.

[0096] An implementation scheme for PIN duration is described herein. At 620, the CN may provide one or more timers for the validity duration of the PEMC, PEGC, and / or PIN. One or more timers for the PIN, PEMC, and / or PEGC may start immediately after the CN authorizes it. Alternatively or additionally, the PIN validity timer value may start after the PIN activation indication is transmitted from the PEMC to the CN. The PIN is active as long as the PIN timer, PEMC timer, and / or PEGC timer are valid. Once the time period of one of the timers expires, the PIN may be deactivated. Alternatively or additionally, the PIN may be deactivated by the WTRU (e.g., PEMC) or the CN based on an event or trigger. The term "timer" may be referred to throughout the present disclosure as a clock, a counter, a duration, a time unit, or any other device / value configured to measure a time period.

[0097] Embodiments of PIN updates are described herein. Once a PIN is created and communications are established, the PIN may be updated at 625 if one or more PEs are added, modified, or removed from the PIN. Changes to PEs may not change the PIN type or require reauthorization, but may result in different QoS requirements (e.g., requiring modification of an existing PDU session or updating of a QoS flow).

[0098] Similar to the above, an existing PIN may be updated by a service provider (e.g., a PIN server). This may be due to changes in services and operations that require the addition, modification, or removal of any PEs. Therefore, a PIN update may be initiated based on service requirements.

[0099] Embodiments of PIN reconstruction are described herein. Similar to PIN updates (where new PIN elements (PEs) may join or leave a PIN), if the PE that is joining or leaving belongs to a PE category that changes PIN types or may belong to a secure PIN type, the PE may not be authorized to join the PIN, but may need to reconstruct the PIN, where the PE is authorized by the PEMC at 630. PIN reconstruction may mean that the PEMC and PEGC remain connected and do not need to be reauthorized by the network. However, as a result of the PE joining or leaving, the old PIN may be discarded, and authorization for a new PIN may be initiated by the PEMC.

[0100] Embodiments of WTRU-initiated PIN creation are described herein. Fig. 7A and Figure 7B is a diagram illustrating an example WTRU-initiated PIN creation 700, which may be used in conjunction with any of the other embodiments described herein. WTRU-initiated PIN creation may include four phases: 1) capability negotiation and policy provisioning between PEMC and AMF / UDM / PCF; 2) authorization and parameter exchange by PEMC, which also requests PIN creation, during which the PIN ID and context are generated; 3) authorization of the PIN element to join the PIN; and 4) PIN creation and activation indication.

[0101] like Fig. 7A As illustrated, at step 714, for PIN authorization and creation, the CN including AMF 707 / PCF 708 / UDM709 and PIN-NEF 710 may require certain parameters, which are received as policy parameters from a third-party PIN server 712 via PIN-NEF 710. These parameters may include, but are not limited to, pre-authorized PIN types and PE types for which the CN does not need to obtain authorization from the PIN server. Alternatively or additionally, these parameters may include, but are not limited to, PIN types and PE types for which authorization can only be performed by the PIN server.

[0102] At step 716, the WTRU (e.g., PEMC 704) may transmit a NAS message (e.g., a registration request) to the AMF 707. The NAS message may include, but is not limited to, multiple PEMC capabilities (a PEMC capability), multiple PEGC capabilities (a PEGC capability), PEMC supported applications or services, PIN server address, PIN type, and / or PIN size. The PEMC capabilities may indicate that the WTRU (i.e., PEMC 704) is capable of providing management functionality and / or that the WTRU (i.e., PEMC 704) may have PE functionality. The PEGC capabilities may indicate that the WTRU (i.e., PEGC 706) is capable of providing gateway functionality and / or that the WTRU (i.e., PEGC 706) may have PE functionality. The PEMC supported applications or services may indicate the types of applications and services that the PEMC 704 is capable of providing to the PE 702 in the PIN. For example, the applications or services supported by the PEMC 704 may include IoT, streaming, healthcare, VR, and / or AR applications / services. The PIN type may indicate the type of PIN network that the PEMC 704 is capable of providing. PIN types may include, but are not limited to, IoT, streaming, healthcare, etc.

[0103] At step 718, the AMF 707 may receive the PEMC capabilities and check with the UDM 709 and / or PCF 708 whether the WTRU (ie, PEMC 704) is allowed to act as a PEMC. The UDM 709 may include subscription information of the WTRU in the network. The AMF 707 may also receive the PEGC capabilities.

[0104] At step 720, before responding to a NAS message (e.g., a registration request) from the WTRU (i.e., PEMC 704), the AMF 707 may request authorization of the PEMC 704 / PEGC 706 from the PIN server 712. This action may be based on several round-trip messaging between the AMF 707 and the PIN server 712 via the PIN-NEF 710. Specifically, the AMF 707 may transmit the WTRU user ID, PEMC capabilities, applications or services supported by the PEMC 704, PIN type, PIN size, etc. to the PIN server 712. The PIN server 712 may respond with the authorized PIN type, PIN size, number of PEs of each type, PIN ID set, PIN server list, validity period of the authorization of the PEMC / PEGC, etc. It should be noted that step 720 is optional based on the pre-authorization information about the PEMC / PEGC capabilities obtained by the AMF 707 / PCF 708 / UDM 709 from the PIN server 712.

[0105] At step 722, the AMF 707 may transmit a NAS message (e.g., a registration response) to the WTRU (i.e., the PEMC 704). The NAS message may include, but is not limited to, a PEMC authorization, a pre-authorization to initiate PIN creation using specific characteristics (e.g., PIN type, PIN size, number of PEs of each type), which pre-authorization may indicate or specify which PEs are sufficiently authorized locally by the PEMC or which PEs require network authorization (e.g., authorization by the PIN server 712). For example, if the AMF 707 already has pre-authorization information for the PEMC 704, the AMF 707 may transmit a PEMC authorization to the WTRU (i.e., the PEMC 704), indicating that the PEMC 704 is authorized to act as the PEMC 704 in the PIN. If the AMF 707 does not have pre-authorization information for the PEMC 704, the AMF 707 may transmit a request to the PIN server 712 as disclosed in step 720. The PIN type included in the NAS message may indicate the type of PIN that the PEMC 704 is allowed to create. A NAS message (e.g., a registration response) may include multiple PIN types for multiple PINs. A PIN ID set may include one or more PIN IDs that the PEMC 704 is allowed to create or use. The PIN size may indicate the total number of PEs allowed in the PIN. The maximum number of PEs of each type may indicate the maximum number of PEs allowed for each PIN type. For example, the maximum number of PEs of each type may indicate that the IoT PIN type allows 20 IoT devices, but the streaming PIN type only allows one streaming device. A NAS message (e.g., a registration response) may also include a PIN with a timer value, a PEMC and / or PEGC validity duration, a PIN ID set, and authorized applications / services. The PIN, PEMC, and / or PEGC validity duration may be milliseconds, seconds, minutes, hours, days, months, etc.

[0106] At step 724, the WTRU (i.e., PEMC 704) may receive one or more connection requests from PE 702, for example, via WiFi or Bluetooth, which is beyond the capabilities of 3GPP. PEMC 704 may have received a device ID and PE ID that can be used for PIN creation. The connection request received from PE 702 may include, but is not limited to, a device ID, a PE ID, a PE type, and / or PE capabilities. The PE type may indicate the device type of the PE, such as a sensor, a light, a plug, a printer, a cellular phone, a wearable device, an augmented reality (AR) device, an in-vehicle device, and a virtual reality (VR) device. The PE capabilities may indicate the radio access technologies that PE 702 is capable of supporting, such as Bluetooth, Wi-Fi, Bluetooth Low Energy (BLE), Zigbee, and Z-Wave.

[0107] At step 726, once the WTRU (i.e., PEMC 704) connects with an available PE, the WTRU (i.e., PEMC 704) may first determine whether the particular PE belongs to a pre-authorized PE type that can be locally authorized by the PEMC 704. If the PE type can be locally authorized, the WTRU (i.e., PEMC 704) may authorize the connection request from the PE 702. In one example, the PEMC 704 may authorize the connection request based on a PE type that is compatible with the pre-authorized PE type and / or the pre-authorized PIN type. The pre-authorized PE type or the pre-authorized PIN type may be received from the AMF 707 (e.g., the NAS response message at step 722). In another example, the PEMC 704 may authorize the connection request based on a PE type that is compatible with the pre-authorized PIN type and / or PE capabilities. For example, if the PE type is an IoT device and the pre-authorized PIN type is temperature sensing, the WTRU (i.e., PEMC 704) may authorize the connection request from the PE 702. If the PE type is IoT device but the pre-authorized PIN type is streaming media, the WTRU (ie, PEMC 704 ) may not authorize the connection request from PE 702 .

[0108] The WTRU (i.e., PEMC 704) may connect to all available PEs 702 that are required and discoverable for a particular service. The PEMC 704 may have pre-authorized some PEs locally, but for the remaining PEs, the PEMC 704 may have to request authorization from the CN or from a third-party PIN server 712. When a PE 702 requires network authorization, at step 728, the WTRU (i.e., PEMC 704) may transmit a mobility registration request to the AMF 707, which includes the pre-authorized PIN type, PE information (e.g., PE ID, PE capabilities and / or PE type), application / service, and PIN server address (e.g., a PIN server address selected from the list received in step 720).

[0109] Step 730 may be the same as steps 718 and 720, but the parameters may be slightly different. Authorization may additionally or alternatively be accomplished according to the following example procedure:

[0110] In one example, AMF 707 may authorize PE 702 on its own, as described in step 718. However, the CN may additionally or alternatively provide a PIN validity duration with a timer value.

[0111] In another example, if the PIN server 712 needs to be authorized, the AMF 707 may transmit a request, as described in step 720. Specifically, the AMF 707 may transmit the pre-authorized PIN type, PE information (e.g., PE ID, PE capability and / or PE type), application / service to the PIN server address selected by the PEMC. The PIN server 712 may respond with an authorized PE list with PE ID, and a PIN validity duration with a timer value.

[0112] At step 732, AMF 707 may transmit a mobility registration response to PEMC 704 and include the authorized PIN type, PIN ID, PIN policy parameters (if new), CN connectivity parameters, and PIN validity duration with timer value. The mobility registration response may also include S-NSSAI NSI ID or DNN. CN connectivity parameters may include one or more allowed quality of service (QoS) requirements associated with the PE type of PE 702.

[0113] At step 734, the WTRU (i.e., PEMC 704) may establish a connection with PEGC 706 to achieve PIN connectivity. At this step, PEMC 704 may perform PEGC selection and request to establish a PDU session with PEGC 706. In one example, assuming that both PEMC 704 and PEGC 706 are capable of direct communication via PC5, a direct unicast communication link may be established between PEMC 704 and PEGC 706.

[0114] At step 736, a PIN is created and a PIN activation indication may be transmitted to the CN and / or to the PIN server 712. The CN and / or the PIN server 712 may start a PIN validity timer.

[0115] In one embodiment, after steps 716-722 in WTRU-initiated PIN creation 700, once the WTRU (i.e., PEMC 704) is authorized by the network, the PEMC 704 may have established a PDU session with the CN. The remaining procedures for PE authorization and PIN creation may then alternatively or additionally be performed on the user plane using a PDU session. The procedure may be as follows:

[0116] First, the PEMC 704 and the PEGC 706 may be authorized (eg, independently). The PEMC 704 and the PEGC 706 may both discover each other, and a PDU connection may be established between the PEMC 704 and the PIN server 712.

[0117] Second, PEMC 704 may receive a connection request from PE 702, for example, via WiFi or Bluetooth, which is beyond the capabilities of 3GPP. However, PEMC 704 may have received a device ID and PE ID that may be further used for PIN creation.

[0118] Third, PEMC 704 may trigger secondary authorization, wherein an application in PEMC 704 transmits PE information including, for example, PIN type, PE information (eg, PE ID, PE type, and PE quantity), application / service, etc. to an application in a PIN server.

[0119] Finally, the application in PEMC 704 can obtain PIN authorization from PIN server 712.

[0120] In another embodiment, the WTRU may perform authorization to act as a PEGC 706 in the same manner as performed for the PEMC 704 in steps 716-722 of the WTRU-initiated PIN creation 700. The pre-authorized PEMC 704 may discover and establish a connection with a suitable / available PEGC 706 and establish connectivity with the network via the PEGC 706.

[0121] Figure 8 is a diagram illustrating an example PIN management procedure 800, which may be used in conjunction with any of the other embodiments described herein. At step 805, a first WTRU may send a first non-access stratum (NAS) request message to a network node in a cellular network. The first NAS request message may indicate that the first WTRU is capable of acting as a PEMC in a PIN. The network node in the cellular network may be a base station (BS), AMF, PCF, UDM, NEF, or any other device / entity / function in a core network (CN) or RAN that is capable of communicating with the WTRU for PIN creation / management. The cellular network may include, but is not limited to, a global system for mobile communications (GSM), a universal mobile telecommunications system (UMTS), long term evolution (LTE), 5G new radio (NR), and 6G. In response to the first NAS request message, at step 810, the WTRU may receive a first NAS response message from a network node in the cellular network. The first NAS response message may include, but is not limited to, authorization information of the request of the first WTRU, an authorized PIN type, and one or more validity durations of the PIN / PEMC / PEGC. The authorization information may indicate that the WTRU is allowed to act as a PEMC in the PIN to be created. Authorized PIN types may include, but are not limited to, home security, industrial security, home automation, industrial automation, healthcare monitoring, temperature sensing, motion detection, augmented reality (AR), virtual reality (VR), connected transportation, and autonomous transportation.

[0122] At step 815, the first WTRU may receive a connection request message from a second WTRU, the connection request message including PE information associated with the second WTRU. The PE information associated with the second WTRU may include, but is not limited to, the PE type of the second WTRU and the PE capabilities of the second WTRU. The PE type may include, but is not limited to, sensors, lights, plugs, printers, cellular phones, wearable devices, augmented reality (AR) devices, in-vehicle devices, and virtual reality (VR) devices. The PE capabilities may indicate the non-3GPP RATs that the PE can support. Such non-3GPP RATs may include, but are not limited to, Bluetooth, Wi-Fi, Bluetooth Low Energy (BLE), Zigbee, and Z-Wave. At step 820, if the PE type and PE capabilities are compatible with the authorized PIN type, then at step 825, the WTRU may send a connection response message to the second WTRU, indicating that the second WTRU is authorized to act as a PIN element (PE) of the PIN or to join the PIN. For example, if the PE type is a plug, the PE capability is Zigbee, and the pre-authorized PIN type is home automation, the first WTRU may authorize the connection request from the second WTRU. If the PE type is plug, the PE capability is Zigbee, but the pre-authorized PIN type is streaming, the first WTRU (i.e., PEMC 704) may not authorize the connection request from the second WTRU. In one embodiment, the first WTRU may use only the PE type and the authorized PIN type to determine compatibility. In another embodiment, the first WTRU may use only the PE type and the authorized PE type to determine compatibility. Once the second WTRU is authorized by the first WTRU or after the first WTRU transmits a connection response message to the second WTRU, the first WTRU may send a PIN activation indication to the CN or PIN server.

[0123] At step 820, if the first WTRU determines that the PE type and PE capabilities are not compatible with the authorized PIN type, then at step 830, the first WTRU may send a second NAS request message to a network node in the cellular network, the second NAS request message requesting the core network (CN) or PIN server to authorize the second WTRU to act as a PE for the PIN. The second NAS request message may include PE information associated with the second WTRU as described above. At step 835, the first WTRU may receive a second NAS response message from the network node in the cellular network, the second NAS response message indicating that the second WTRU is authorized by the CN or PIN server to act as a PE for the PIN. The second NAS response message may include, but is not limited to, the authorized PIN type, the PIN ID, one or more CN connectivity parameters, and the validity duration of the PIN. Once the second WTRU is authorized as a PE by the CN or PIN server, at step 840, the first WTRU may send another connection response message to the second WTRU, the other connection response message indicating that the second WTRU is authorized to act as a PE for the PIN. The one or more CN connectivity parameters may include, but are not limited to, one or more allowed quality of service (QoS) requirements associated with the second WTRU or the PE type of the second WTRU. Once the second WTRU is authorized by the CN or PIN server or after the first WTRU transmits another connection response message to the second WTRU, the first WTRU may send a PIN activation indication to the CN or PIN server.

[0124] In one embodiment, if the received PEMC / PEGC / PIN validity duration expires, the first WTRU may send a third NAS request message to a network node in the cellular network to reauthorize the second PE. The third NAS request message may request the core network (CN) or PIN server to reauthorize the second WTRU to act as a PE for the PIN. The third NAS request message may include PE information associated with the second WTRU as described above.

[0125] After creating the PIN, at step 845, the first WTRU may receive another connection request message from the third WTRU. The another connection request message may include PE information associated with the third WTRU. The PE information associated with the third WTRU may include, but is not limited to, the PE type of the third WTRU and the PE capabilities of the third WTRU. If one or more QoS requirements associated with the third WTRU or the PE type of the third WTRU are different from one or more allowed QoS requirements associated with the second WTRU or the PE type of the second WTRU, then at step 850, the first WTRU may send a third NAS request message to a network node in the cellular network, the third NAS request message requesting the CN or PIN server to authorize the third WTRU to act as a PE for the PIN. The third NAS request message may include PE information associated with the third WTRU as described above.

[0126] Note that the first WTRU is capable of supporting both 3GPP RATs and non-3GPP RATs, and the second WTRU is capable of supporting non-3GPP RATs. 3GPP RATs may include, but are not limited to, Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), 5G New Radio (NR), and 6G. Non-3GPP RATs may include, but are not limited to, Bluetooth, Wi-Fi, Bluetooth Low Energy (BLE), Zigbee, and Z-Wave. The PE capabilities of the second WTRU or the third WTRU may indicate that the second WTRU or the third WTRU is capable of supporting non-3GPP RATs.

[0127] Embodiments of PIN updating and reconstruction are described herein. In these embodiments, it is assumed that a PIN is created and a connection is established between the PIN, CN, and PIN server. If one or more PEs join or leave the PIN, they may or may not significantly affect the PIN. If the change is significant in terms of a change in QoS requirements or resulting in a change in PIN type, the PIN may be updated or reconstructed based on the embodiments described herein. Specifically, once a PIN is created and is in operation, the following situations may occur: (1) PEs in the PIN may become unavailable; (2) new PEs may join the PIN; (3) the expected or allowed QOS may change due to the joining / leaving or unavailability of PEs; and (4) the PIN type and characteristics may change, for example, particularly for PINs related to security or emergency.

[0128] Embodiments of WTRU initiated PIN updates are described herein. In this embodiment, the scenario describes a PIN update that may be initiated by a WTRU (eg, PEMC or PEGC). Fig. 9is a diagram illustrating an example WTRU-initiated PIN update 900, which may be used in conjunction with any of the other embodiments described herein.

[0129] As described above, at step 914, it is assumed that the PIN is established. At step 916, the PIN element 902 may become available or unavailable. The PEMC 904 may be aware of this. A new PE 902 may connect to the PEMC 904 to notify the availability. An existing PE may be out of service and detected by the PEMC 904. An existing PE 902 may provide additional services and the QOS requirements may change (e.g., from PEGC 906 to 5GS aggregated QOS). One or more new PEs 902 that want to join the PIN or one or more existing PEs 902 that want to leave the PIN may trigger an update to the PIN and / or a reconstruction / reauthorization of the PIN.

[0130] At step 918, the PEMC 904 may determine whether the PIN update in step 916 has any impact on the type or QoS requirements. At step 920, if the PEMC 904 determines that there is any change in the PIN type or QoS, the PEMC 904 may transmit a NAS message (e.g., a mobility registration request to the AMF in the CN 908) and include some parameters such as the old PIN ID, S-NSSAI, DNN, an indication of the PIN type / QoS change, and the newly added / removed PE information (e.g., PE ID and PE type). At step 922, the AMF may check with the CN 908 and / or the PIN server 912 whether re-authorization is required. If re-authorization is not required, the QoS parameters may be updated. At step 924, the AMF may transmit new CN connectivity parameters to the PEMC 904 via NAS signaling (e.g., using a mobility registration response) for modifying the PDU session or updating the QoS flow.

[0131] Steps 926-930 and step 932 describe two alternative or additional methods. In the first scenario, at step 926, NAS signaling may occur between CN 908 and PEMC 904 without PEGC 906 being aware of it. Therefore, PEMC 904 may transmit an indication to PEGC 906 to notify the change in QoS requirements and provide new CN connectivity parameters and PIN ID for PDU session modification. At step 928a, PEGC 906 may initiate session modification and transmit a PDU session modification request including the new CN connectivity parameters and PIN ID to the SMF. At step 928b, the SMF may transmit a session modification acceptance, which may include the PIN ID. At step 930, PEGC 906 may transmit a PEGC indication to PEMC 904 indicating that a connection has been successfully established for the updated PIN. The PEGC indication may include the PIN ID.

[0132] In the second scenario, at step 932, a network initiated PDU session modification may be established, wherein the AMF notifies the SMF of the change in the PIN QoS requirement after step 924. The SMF may notify the PEGC 906 that the PDU session is modified. The PEGC 906 may notify the PEMC 904 of the modified PDU session, including connectivity parameters for the PIN ID. At step 934, PIN connectivity may be established with the new PIN.

[0133] Embodiments of WTRU initiated PIN re-establishment are described herein. This embodiment describes that a PIN re-establishment may be initiated by a WTRU (e.g., PEMC or PEGC). Re-establishment may mean that the PEMC / PEGC is authorized and connected to the CN, but the PIN type changes due to a PE joining, leaving, or becoming unavailable (causing the PIN to be unauthorized). Such actions may first require the PIN to be unregistered and a new authorization to be requested in order to re-establish the PIN using the updated PE information.

[0134] Fig.10 is a diagram illustrating an example WTRU-initiated PIN reestablishment 1000, which may be used in conjunction with any of the other embodiments described herein. At step 1014, it is assumed that the PIN is established. Steps 1016-1022 are similar to Fig. 9 The steps are the same as those described in and are not explained here for the sake of brevity.

[0135] At step 1024, if re-authorization is required because new PEs 1002 joining the PIN or those leaving the PIN may have significantly different attributes (e.g., PE 1002 is critical to security or safety), the AMF may transmit a PIN deregistration notification to the PEMC 1004 via NAS signaling (e.g., mobility registration response) and request re-authorization for PIN reconstruction. At step 1026, the PDU session may be released. This may be initiated by the PEMC 1004 requesting the PEGC 1006 to initiate a PDU session release procedure. Alternatively or additionally, the PDU session release may be initiated by the CN 1008 (e.g., SMF), or by an application server (or PIN server 1012) of an application in the requesting PEMC 1004. At step 1028, a new PIN may be created in the same manner as illustrated in Figure 7 (e.g., steps 724-738). This PIN creation may be referred to as PIN reconstruction because PEMC 1004 and PEGC 1006 may remain unchanged but a PIN is created for the updated PE.

[0136] Embodiments of PIN activation and deactivation are described herein. For PIN management, it may be necessary to handle PIN activation and deactivation. For example, embodiments of PIN activation and deactivation may include three scenarios: (1) based on a timer (i.e., when the WTRU or network determines to activate and deactivate the PIN based on the timer value when the timer expires); (2) also based on a timer, but the CN or PIN server extends the timer value; and (3) when the PIN is deactivated by the network operator or an authorized third-party PIN server, which may be instantaneous and event-triggered.

[0137] Fig.11 1 is a diagram illustrating an example PIN activation / deactivation with validity timer 1100, which can be used in conjunction with any of the other embodiments described herein. At step 1114, as described above, once a PIN is created, it may or may not be activated immediately. However, once the PIN is activated, an indication may be transmitted to the CN 1108 and / or to the PIN server 1112 specifying the activation of the PIN and specifying a reference time value.

[0138] In the first scenario (i.e., Option 1 1116), the PIN validity period may have expired, and the PEMC 1104 may transmit a PIN deactivation indication to the CN 1108 and / or to the PIN server 1112. It may also trigger a PDU session release and PIN deregistration. The PIN timer may have expired and the PIN may have been dissolved, but the PEMC 1104 and PEGC 1106 may still be authorized and connected to the CN 1108 for PIN reestablishment. They may not need to perform reauthorization.

[0139] In the second scenario (ie, option 2 1118), before the PIN validity time expires, if there is no major change in the PIN with respect to type, size, etc., the CN 1108 only needs to extend the time or reset the time. The updated parameters may be communicated to the WTRU (e.g., PEMC 1104) via a UE Configuration Update (UCU) command.

[0140] The WTRU (e.g., PEMC 1104) may respond with a UCU completion message or indication. The UCU completion message may include, but is not limited to, a PIN activity indication that will synchronize the clocks on the WTRU (e.g., PEMC 1104) and CN 1108 for a timer duration.

[0141] In the third scenario (ie, option 3 1122), a PIN deactivation indication may be initiated by the CN 1108 and / or the PIN server 1112 due to certain conditions, which revokes the PIN connection and automatically releases the PDU session.

[0142] This article describes an embodiment of network-initiated PIN creation. For example, network-initiated PIN creation can be implemented in two steps. The first step is the same as the step illustrated in Figure 7. By this step, the network may have information about available PEMCs, PEGCs, and PEs. Assuming this information is known, Fig.11 A network-initiated PIN creation example 1200 is illustrated, which can be used in conjunction with any of the other embodiments described herein. Network-initiated PIN creation 1200 can be initiated by a managed service provider. The service provider can select the required PE 1202, PEMC 1206, and PEGC 1204 to provide the service. Note that the network can refer to any 3GPP network, such as a 5G system (5GS) including CN and RAN. The network can include AMF / SMF 1208 and PIN-NEF 1210.

[0143] At step 1214, the service provider may query available PEs 1202 by providing an application / service name, location, and / or service area. The application / service name may be a service / application that the service provider wants to provide. It may be a string that identifies the service, such as "GAMING", "AR / VR", "SURVILLENCE", "HEALTH", etc. It may be assumed that the network (e.g., 5GS) is aware of the service name as part of the service agreement. The location may be a tracking area identifier (TAI), an EUTRA cell global identifier (ECGI), etc. The service area may be a city area code, a geographic location, etc. At step 1216, the network (e.g., 5GS) may find out if there are any PINs based on the "application name", "location", and "service area". If not, based on this information, the network may try to find available PEs 1202, PEMCs 1206, and PEGCs 1204 that can support the application. At step 1218, the network (e.g., 5GS) may provide available PEs and PEMCs 1206, PEGCs 1204 that can be used to support the application at the expected location. It can provide a list of information elements: List[{Location,Application Level PE ID},{Location,Application Level PE ID},…], assuming that Application Level PE ID is the PE ID known to the service producer.

[0144] At step 1219, the service provider may select a subset of PE 1202, PEMC 1206, and PEGC 1204 to provide the intended service. At step 1220, the service provider may initiate PIN creation by transmitting a Create PIN message to the network (e.g., 5GS), which may include, but is not limited to: application name (string); service location (TAI, CGI); and selected application-level PE Ids (PE ID List (1..n)). At step 1221, the selected PE IDs may include PE 1202, PEMC 1206, and / or PEGC 1204. If PE 1202, PEMC 1206, and / or PEGC 1204 are not available, the network (e.g., 5GS) may select other PE IDs. At step 1222, the network (e.g., 5GS) may determine the device (e.g., PE 1202, PEMC 1206, and PEGC 1204) based on the application-level ID and initiate PIN creation. The application level PE ID may be converted to a network level PE ID. A PIN ID and a PE ID associated with the PIN ID may be created. The allowed QoS may be determined based on subscription and service agreements.

[0145] At step 1224, the network (e.g., 5GS) may transmit a PIN creation request to the PEMC 1206 using a WTRU configuration update message. The WTRU configuration update message may include, but is not limited to: PIN ID, PIN size, allowed QoS requirements, and element list. PIN ID: integer or string; identifies the PIN to be created. PIN size may be an integer indicating the maximum number of PEs allowed. The allowed QoS requirement may be the allowed or expected QoS for the entire PIN. It may be an aggregation of the QoS allowed for each PE. The element list or PE element list may be a list of 1...N elements. Specifically, list_of_Pin_elements[] may include but is not limited to: (1) PIN type: whether it is AR / VR, temperature sensor; (2) allowed QoS, optional: QoS allowed by the PIN type; (3) maximum number of allowed PIN types: integer indicating the maximum number of allowed PE types; (4) {PE_IDs, Timer value} list (1…n), the timer value of each PE_ID indicates the validity time of the identified PIN element; and / or (5) the network (e.g., 5GS) may include other available PEMC1206 and PEGC 1204 in the list List_of_Pin_elements[].

[0146] At steps 1226A, 1226B, PEGC 1204 may be configured as follows:

[0147] In the first scenario (ie, option 1 1226A), 1206PEMC may transmit configuration information to PEGC 1204 by transmitting a configuration update message. The message may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN to be created; (2) aggregate QOS: the expected QOS requirement of PE GW for 5GS; (3) List_of_Pin_elements[]: a list of 1...N PIN elements. The list of 1...N PIN elements may include, but is not limited to: (1) PIN type: whether it is AR / VR, temperature sensor; (2) allowed QoS, optional: QoS allowed by PIN type; and / or (3) {PE_IDs, Timer value} list (1...n), the timer value of each PE_ID indicates the validity time of the identified PE.

[0148] In the second scenario (ie, option 2 1226B), the network (e.g., 5GS) may configure the PEGC 1204 by transmitting a configuration update message. The message may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN to be created; (2) aggregate QOS: the expected QOS requirement of the PE GW for the 5GS; and / or (3) List_of_Pin_elements[]. The list of 1...N PIN elements may include: (1) PIN type: whether it is AR / VR, temperature sensor; (2) allowed QoS, optional: QoS allowed by the PIN type; and (3) {PE_IDs, Timer value} list (1...n), the timer value of each PE_ID indicates the validity time of the identified PE.

[0149] At step 1228, the PEMC 1206 may trigger the PE 1202 to join the PIN. At step 1230, the PE 1202 may connect to the PEGC 1204, and connectivity between the PEs 1202 and / or the PE 1202 to the network (e.g., 5GS) may be established by the PEGC 1204.

[0150] Assuming that the PIN is successfully established in step 1230, the PEMC 1206 may notify the network (e.g., 5GS) by transmitting a WTRU configuration update response at step 1232. The configuration update response may include, but is not limited to: (1) PIN ID: integer or string; identifies the created PIN; (2) PIN element list [PE_ID...]: PIN element, a part of the created PIN; and / or (3) result: success or failure. At step 1234, the network (e.g., 5GS) may transmit a create PIN response to the service provider. The create PIN response may include, but is not limited to: (1) PIN ID: integer or string; identifies the created PIN; (2) PIN element list [Application Level PIN ID,...]: PIN element, a part of the created PIN; and / or (3) result: success or failure.

[0151] Embodiments of network-initiated PIN updates are described herein. Fig.12 1 is a diagram illustrating an example of a network-initiated PIN update, which can be used in conjunction with any of the other embodiments described herein. In this embodiment, the scenario describes an update of a PIN managed by a service provider.

[0152] At step 1314, PE 1302 may become available or unavailable. PEMC 1306 may be aware of this. New PE 1302 may connect to PEMC 1306 to notify its availability. Existing PE may be out of service and detected by PEMC 1306. Existing PE may provide additional services and QoS requirements may change (e.g., aggregated QoS from PEGC 1304 to the network (e.g., 5GS)). For example, an existing PE may support multiple different PINs or services. Once an existing PE leaves one of the multiple PINs, the event may trigger the existing PE to provide different services associated with a different PE (with which the existing PE is still associated). Note that the network may refer to any 3GPP network, such as a 5G system (5GS) including CN and RAN. The network may include AMF / SMF 1308 and PIN-NEF 1310.

[0153] At step 1316, PEMC 1306 may notify the network (e.g., 5GS) of the change by transmitting a mobility registration request. The mobility registration request may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN; (2) change indication: enumeration (newPE, peUnav, qosChange); (3) PE-ID: string, identifies an available or unavailable PIN; (4) qosReq: string, describes the new aggregated QOS requirement; (5) S-NSSAI: identifies the slice that includes the PIN; and (6) DNN: for the updated PIN.

[0154] At step 1318, the network (e.g., 5GS) may notify the PIN service provider (e.g., PIN server 1312) of the availability of the PE or the QoS change of the PIN. The network (e.g., 5GS) may first authorize the change to the service provider (e.g., PIN server 1312). At step 1320, the network (e.g., 5GS) may notify the PEMC 1306 that these changes are authorized by transmitting a mobility registration response. The mobility registration response may include, but is not limited to, an allow / disallow indication that may add a new PE or update the QoS.

[0155] At step 1322, the service provider (e.g., PIN server 1312) may decide to update the PIN, which may be one or more of the following actions: (1) remove the PE ID from the PIN identified by the PIN ID; (2) add the PE-ID to the current PIN identified by the PIN ID; and (3) update the QOS of the PIN. The service provider (e.g., PIN server 1312) may transmit an update PIN message to the network (e.g., 5GS). The update PIN message may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN; (2) new application-level PE Id: list of PE IDs (1...n); the list includes the PEs of the PIN and takes into account the added or deleted PEs; and (3) approved QOS: yes or no. At step 1324, the network (e.g., 5GS) may identify the corresponding PEMC 1306 based on the PIN ID.

[0156] At step 1326, the network (e.g., 5GS) may transmit a WTRU configuration update message to the PEMC 1306. The WTRU configuration update message may include, but is not limited to: (1) PIN ID; and (2) list Update_action{1...n}. The list Update_action{1...n} may include, but is not limited to: (1) Action: enumeration ADD, DELETE, UPDATE_QOS; (2) PIN type: identification whether it is AR / VR, temperature sensor; (3) {List of PE-ID(1...n): PE identifiers; PIN_Duration(1...n): Timer value}; and (4) Updated QOS: new QoS from PEGC 1304 to the network (e.g., 5GS).

[0157] In steps 1328A, 1328B, PEGC 1304 may be configured as follows:

[0158] In the first scenario (i.e., Option 1 1328A), PEMC 1306 may transmit configuration information to PEGC 1304 by transmitting a configuration update message. The configuration update message may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN to be updated; and (2) Update_Action list {1...n}. Update_Action list {1...n} may include, but is not limited to: (1) Action: enumeration ADD, DELETE, UPDATE_QOS; (2) List_of_Pin_elements[]: list of 1...N PIN elements; and (3) Aggregate QoS: updated QoS requirements of PEGC 1304 for the network (e.g., 5GS). The list of 1...N PIN elements may include, but is not limited to: (1) PIN type: whether it is AR / VR, temperature sensor; (2) Allowed QoS, optional: QoS allowed by PIN type; and (3) {PE_IDs, Timer value} list (1...n), the timer value of each PE_ID indicates the validity time of the identified PIN element.

[0159] In the second scenario (i.e., Option 2 1328B), the network (e.g., 5GS) may configure PEGC 1304 by transmitting a configuration update message. The configuration update message may include, but is not limited to: (1) PIN ID: integer or string; identifies the PIN to be updated; and (2) Update_Action list {1...n}. The Update_Action list {1...n} may include, but is not limited to: (1) Action: enumeration ADD, DELETE, UPDATE_QOS; (2) List_of_Pin_elements[]: a list of 1...N PIN elements; and (3) Aggregate QoS: the updated QoS requirements of PEGC 1304 for the network (e.g., 5GS). The list of 1...N PIN elements may include, but is not limited to: (1) PIN type: whether it is AR / VR, temperature sensor; (2) Allowed QoS, optional: QoS allowed by the PIN type; and (3) {PE_IDs, Timer value} list (1...n), the timer value of each PE_ID indicates the validity time of the identified PIN element.

[0160] At step 1330, if a new PE 1302 is available, the PEMC 1306 may trigger the PE 1302 to join the PIN. At step 1332, the new PE 1302 may connect to the PEGC 1304 or the unavailable PE. For example, the PEGC 1304 may update the connectivity configuration between the PEs 1302 or the PE 1302 to the network (e.g., 5GS).

[0161] At step 1334, assuming that the PIN is successfully established, the PEMC 1306 may notify the network (e.g., 5GS) by transmitting a WTRU configuration update response. The WTRU configuration update response may include, but is not limited to: (1) PIN ID: integer or string; identifies the created PIN; (2) PIN element list [PE_ID...]: PIN elements, part of the created PIN; and (3) result: success or failure.

[0162] At step 1336, the network (e.g., 5GS) may transmit an update_PIN_response to the service provider (e.g., PIN server 1312). The update_PIN_response may include, but is not limited to: (1) PIN ID: integer or string; identifies the created PIN; (2) PIN element list [Application Level PIN ID, ...]: PIN element, part of the created PIN; and (3) result: success or failure. At step 1338, the PIN is updated by the network.

[0163] Although features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) 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 (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a first wireless transmit / receive unit (WTRU), the method comprising: sending a first non-access stratum (NAS) request message to a network node in a cellular network, the first non-access stratum (NAS) request message indicating a capability of the first WTRU to act as a PIN element (PE) with management capabilities (PEMC) in a personal Internet of Things network (PIN); receiving a first NAS response message from the network node in the cellular network, the first NAS response message including authorization information for the first WTRU to act as the PEMC to initiate the PIN, an authorized PIN type, and a validity duration of the PIN; receiving a connection request message from a second WTRU, the connection request message including PE information associated with the second WTRU, wherein the PE information associated with the second WTRU includes a PE type of the second WTRU and a PE capability of the second WTRU; as well as Based on the PE type and the PE capabilities being compatible with the authorized PIN type, a connection response message is sent to the second WTRU, the connection response message indicating that the second WTRU is authorized to act as a PIN element (PE) of the PIN.

2. The method according to claim 1, further comprising: sending a second NAS request message to the network node in the cellular network based on the PE type and the PE capabilities being incompatible with the authorized PIN type, the second NAS request message requesting a core network (CN) or PIN server to authorize the second WTRU to act as the PE for the PIN, wherein the second NAS request message includes the PE information associated with the second WTRU; as well as A second NAS response message is received from the network node in the cellular network, the second NAS response message indicating that the second WTRU is authorized by the CN or the PIN server to act as the PE of the PIN, wherein the second NAS response message includes an authorized PIN type, a PIN ID, one or more CN connectivity parameters, and a validity period of the PIN.

3. The method according to claim 2, further comprising: Another connection response message is sent to the second WTRU, indicating that the second WTRU is authorized to act as the PE for the PIN.

4. The method of claim 2, wherein the one or more CN connectivity parameters include one or more allowed quality of service (QoS) requirements associated with the PE type of the second WTRU.

5. The method according to claim 4, further comprising: receiving another connection request message from a third WTRU, the another connection request message including PE information associated with the third WTRU, wherein the PE information associated with the third WTRU includes a PE type of the third WTRU and PE capabilities of the third WTRU; and Based on the fact that one or more QoS requirements associated with the PE type of the third WTRU are different from the one or more allowed QoS requirements associated with the PE type of the second WTRU, a third NAS request message is sent to the network node in the cellular network, wherein the third NAS request message requests the CN or the PIN server to authorize the third WTRU to act as the PE of the PIN, wherein the third NAS request message includes the PE information associated with the third WTRU.

6. The method of claim 1, wherein the authorized PIN types include home security, industrial security, home automation, industrial automation, healthcare monitoring, temperature sensing, motion detection, augmented reality (AR), virtual reality (VR), connected transportation, and autonomous transportation.

7. The method of claim 1, wherein the PE types include sensors, lights, plugs, printers, cellular phones, wearable devices, augmented reality (AR) devices, in-vehicle devices, and virtual reality (VR) devices.

8. The method of claim 1, wherein the first WTRU is capable of supporting both a 3rd Generation Partnership Project (3GPP) RAT and a non-3GPP RAT, and the second WTRU is capable of supporting the non-3GPP RAT.

9. The method of claim 8, wherein the 3GPP RATs include Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and 5G New Radio (NR), and the non-3GPP RATs include Bluetooth, Wi-Fi, Bluetooth Low Energy (BLE), Zigbee, and Z-Wave.

10. The method of claim 8, wherein the PE capabilities of the second WTRU indicate that the second WTRU supports the non-3GPP RAT.

11. The method according to claim 1, further comprising: Based on the expiration of the validity period of the PIN, a third NAS request message is sent to the network node in the cellular network, wherein the third NAS request message requests a core network (CN) or a PIN server to reauthorize the second WTRU to act as the PE of the PIN, wherein the third NAS request message includes the PE information associated with the second WTRU.

12. A first wireless transmit / receive unit (WTRU), the first wireless transmit / receive unit (WTRU) comprising: a transmitter configured to send a first non-access stratum (NAS) request message to a network node in a cellular network, the first non-access stratum (NAS) request message indicating a capability of the first WTRU to act as a PIN element (PE) with management capabilities (PEMC) in a personal Internet of Things network (PIN); A receiver, the receiver being configured to: receiving a first NAS response message from the network node in the cellular network, the first NAS response message including authorization information for the first WTRU to act as the PEMC to initiate the PIN, an authorized PIN type, and a validity duration of the PIN; as well as receiving a connection request message from a second WTRU, the connection request message including PE information associated with the second WTRU, wherein the PE information associated with the second WTRU includes a PE type of the second WTRU and a PE capability of the second WTRU; and The transmitter is configured to send a connection response message to the second WTRU based on the PE type and the PE capabilities being compatible with the authorized PIN type, the connection response message indicating that the second WTRU is authorized to act as a PIN element (PE) of the PIN.

13. The first WTRU of claim 12, wherein the transmitter is further configured to: sending a second NAS request message to the network node in the cellular network based on the PE type and the PE capabilities being incompatible with the authorized PIN type, the second NAS request message requesting a core network (CN) or PIN server to authorize the second WTRU to act as the PE for the PIN, wherein the second NAS request message includes the PE information associated with the second WTRU; and The receiver is further configured to: receiving a second NAS response message from the network node in the cellular network, the second NAS response message indicating that the second WTRU is authorized by the CN or the PIN server to act as the PE for the PIN, wherein the second NAS response message includes an authorized PIN type, a PIN ID, one or more CN connectivity parameters, and a validity duration of the PIN; and The transmitter is further configured to: Another connection response message is sent to the second WTRU, indicating that the second WTRU is authorized to act as the PE for the PIN.

14. The first WTRU of claim 13, wherein the one or more CN connectivity parameters include one or more allowed quality of service (QoS) requirements associated with the PE type of the second WTRU.

15. A first WTRU according to claim 14, wherein the receiver is further configured to receive another connection request message from a third WTRU, the other connection request message including PE information associated with the third WTRU, wherein the PE information associated with the third WTRU includes the PE type of the third WTRU and the PE capability of the third WTRU; and the transmitter is further configured to send a third NAS request message to the network node in the cellular network based on one or more QoS requirements associated with the PE type of the third WTRU being different from the one or more allowed QoS requirements associated with the PE type of the second WTRU, the third NAS request message requesting the CN or the PIN server to authorize the third WTRU to act as the PE of the PIN, wherein the third NAS request message includes the PE information associated with the third WTRU.

16. The first WTRU of claim 12, wherein the authorized PIN types include home security, industrial security, home automation, industrial automation, healthcare monitoring, temperature sensing, motion detection, augmented reality (AR), virtual reality (VR), connected transportation, and autonomous transportation.

17. The first WTRU of claim 12, wherein the PE types include sensors, lights, plugs, printers, cellular phones, wearable devices, augmented reality (AR) devices, in-vehicle devices, and virtual reality (VR) devices.

18. The first WTRU of claim 12, wherein the first WTRU is capable of supporting both a third generation partnership project (3GPP) RAT and a non-3GPP RAT, and the second WTRU is capable of supporting the non-3GPP RAT, and wherein the 3GPP RAT includes a global system for mobile communications (GSM), a universal mobile telecommunications system (UMTS), long term evolution (LTE), and 5G new radio (NR), and the non-3GPP RAT includes Bluetooth, Wi-Fi, Bluetooth low energy (BLE), Zigbee, and Z-Wave.

19. The first WTRU of claim 18, wherein the PE capabilities of the second WTRU indicate that the second WTRU supports the non-3GPP RAT.

20. The first WTRU according to claim 12, wherein the transmitter is further configured to send a third NAS request message to the network node in the cellular network based on the expiration of the validity period of the PIN, the third NAS request message requesting a core network (CN) or a PIN server to reauthorize the second WTRU to act as the PE of the PIN, wherein the third NAS request message includes the PE information associated with the second WTRU.

Images