CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of Provisional U.S. Patent Application No. 63/324,458, filed March 28, 2022, the disclosure of which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] Mobile communications using wireless communication continue to evolve. A fifth generation may be referred to as 5G. A previous (legacy) generation of mobile communication may be, for example, fourth generation (4G) long term evolution (LTE).

SUMMARY

[0003] Systems, methods, and instrumentalities are described herein associated with a wireless transmit/receive unit (WTRU) configured to manage a personal loT network (PIN). The WTRU, in addition to acting as a personal Internet of things (loT) network (PIN) element (PINE) with a gateway capability (PEGW), may act as a PINE with a management capability (PEMC).

[0004] The WTRU may send a registration request message to a network node. The registration request message may indicate a request to register the WTRU with the PIN and include an application-level PIN element identifier (PEID) associated with a PIN element (PINE). The WTRU may receive a registration response message from the network node. The registration response message may indicate that the WTRU is registered with the PIN and indicate a PIN management policy associated with the PIN. The WTRU may receive a PIN message that includes the application-level PEID associated with the PINE. When the WTRU receives the PIN message from the PINE, the WTRU may modify information in the PIN message based on the PIN management policy such that the application-level PEID, in accordance with the PIN management policy, is replaced by a network-level PEID. For example, the PIN management policy may indicate a PEID association and a charging policy. The PEID association may indicate an association between the application-level PEID and the network-level PEID. The WTRU may modify the information in the PIN message based on the PIN message, the charging policy, and the PEID association.

[0005] The PIN message may indicate a request for a service. The WTRU may determine, based on the PIN management policy, that the service is to be provided by a core network. The core network may include one or more network nodes. Based on the determination, the WTRU may send the registration request message as described herein to the network node. In examples, the one or more network nodes may include the network node to which the modified PIN message is sent. The one or more network nodes may not include the PINE. In some examples, the WTRU may determine, based on the PIN management policy, that the service is to be provided by a third-party service provider associated with a data network. Based on this determination, the WTRU may still send the registration request message as described herein to the network node so that the network node may contact the third-party service provider regarding the service. In examples, the data network may not include the PINE or the network node to which the modified PIN message is sent.

[0006] The WTRU may send, to the network node, the modified PIN message that includes the networklevel PEID and indicates that the WTRU is registered with the PIN. The modified PIN message sent to the network node may indicate the request from the PINE for the service.

[0007] In some examples, the PIN management policy may indicate a PEID association but may not indicate the charging policy. The PEID association may further indicate an association between a device ID associated with the PINE and the network-level PEID.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0010] FIG. 1C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0011] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment.

[0012] FIG. 2 is a diagram illustrating an example of a home automation PIN.

[0013] FIG. 3 is a diagram illustrating an example showing wearable PINs.

[0014] FIG. 4 is a diagram illustrating an example of a PIN architecture.

[0015] FIG. 5 is a diagram illustrating an example of a ProSe direct discovery with Model A.

[0016] FIG. 6 is a diagram illustrating an example of a ProSe direct discovery with Model B.

[0017] FIG. 7 is a diagram illustrating an example where PEID(s) is delivered to a PEMC for assignment. [0018] FIG. 8 is a diagram illustrating an example of PEID assignment based on application-level identifier(s).

[0019] FIG. 9 is a diagram illustrating an example of delivery and assignment of PEID(s) generated by a CN.

[0020] FIG. 10 is a diagram illustrating an example where a CN sends a PGA or a PGA-ID to a PEMC.

DETAILED DESCRIPTION

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

[0022] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a RAN 104/113, a CN 106/115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated 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” and/or a “STA”, may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE. [0023] The communications systems 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/115, the Internet 110, and/or the other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B (eNB), a Home Node B, a Home eNode B, a gNode B (gNB), a NR NodeB, 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.

[0024] The base station 114a may be part of the RAN 104/113, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, i.e., one 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 transmit and/or receive signals in desired spatial directions.

[0025] 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).

[0026] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 104/113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink (DL) Packet Access (HSDPA) and/or High-Speed UL Packet Access (HSUPA). [0027] 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 LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

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

[0029] 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 implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).

[0030] 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 1 X, 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), and the like.

[0031] The base station 114b in FIG. 1A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g , for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the GN 106/115.

[0032] The RAN 104/113 may be in communication with the CN 106/115, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106/115 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 shown in FIG. 1A, it will be appreciated that the RAN 104/113 and/or the CN 106/115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104/113 or a different RAT. For example, in addition to being connected to the RAN 104/113, which may be utilizing a NR radio technology, the CN 106/115 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0033] The CN 106/115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 112. The PSTN 108 may include circuit- switched telephone networks that provide 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), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104/113 or a different RAT.

[0034] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications 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 over different wireless links). For example, the WTRU 102c shown in FIG. 1A 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.

[0035] FIG 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include 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, among others. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0036] 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 in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0038] Although the transmit/receive element 122 is depicted in FIG. 1 B 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.

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

[0040] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or 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 the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. 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, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

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

[0042] 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 over the air interface 116 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable locationdetermination method while remaining consistent with an embodiment.

[0043] The processor 118 may further be coupled to other peripherals 138, which may include one or more software 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 e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors, the sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and/or a humidity sensor.

[0044] 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 particular subframes for both the UL (e.g., for transmission) and downlink (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate self-interference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the downlink (e.g., for reception)).

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

[0046] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-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 eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0047] Each of the eNode-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, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

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

[0049] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/d eactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. 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

[0050] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the 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 user planes during inter- eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like. [0051] 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.

[0052] 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 communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves 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 the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0053] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0054] In representative embodiments, the other network 112 may be a WLAN.

[0055] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the

BSS and one or more stations (STAs) associated with the AP. The AP may have an access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to- peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.11e DLS or an 802.11z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an "ad-hoc” mode of communication.

[0056] When using the 802.11ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in in 802.11 systems For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0057] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0058] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC).

[0059] Sub 1 GHz modes of operation are supported by 802.11 af and 802.11 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.11 ah relative to those used in 802.11 n, and 802.11 ac. 802.11 af supports 5 MHz, 10 MHz and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non- TVWS spectrum. According to a representative embodiment, 802.11 ah may support Meter Type Control/Machine-Type Communications, such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.11 n, 802.11 ac, 802.11 af, and 802.11 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode), transmitting to the AP, the entire available frequency bands may be considered busy even though a majority of the frequency bands remains idle and may be available.

[0061] In the United States, the available frequency bands, which may be used by 802.11 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.11 ah is 6 MHz to 26 MHz depending on the country code.

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

[0063] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit 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, the gNB 180a may transmit multiple component carriers to the 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, the 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).

[0064] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the 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 gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and/or lasting varying lengths of absolute time). [0065] 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 the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0066] Each of the gNBs 180a, 180b, 180c 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, support of network slicing, dual connectivity, interworking between NR and E- UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0067] The CN 115 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While each of the foregoing elements are depicted as part of the CN 115, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0068] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 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 machine type communication (MTC) access, and/or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

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

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

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

[0072] In view of Figures 1 A-1 D, and the corresponding description of Figures 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0073] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, 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. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or may performing testing using over-the-air wireless communications.

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

[0075] Systems, methods, and instrumentalities are described herein associated with a wireless transmit/receive unit (WTRU) configured to assign a user identifier associated with an Internet of Things (loT) network to an loT device and/or generate the user identifier associated with the loT network. The WTRU may send a request to generate an loT network (e.g., to create a personal loT network (PIN)). The WTRU may receive, at an application level, a list of user identifiers associated with the loT network (e.g., a PIN). The WTRU may assign to an loT device (e.g., a personal loT network element (PE)), a user identifier of the list of user identifiers associated with the loT network. The WTRU may send a non-access stratum (NAS) message that includes the assigned user identifier of the list of user identifiers associated with the loT network. The WTRU may receive an indication to create the loT network from the loT device. The WTRU may receive an identifier of the loT network (e.g., PIN identifier) at the application level and assign the identifier of the loT network to the loT device. The NAS message may include the assigned identifier of the loT network. The WTRU may include a personal loT network element with management capability. The user identifier of the list of user identifiers associated with the loT network may be generated at a server associated with the loT network, for example, using a PEID Generation Algorithm (PGA). The PGA may be sent from a PIN server to a core network or to a PIN Element with Management Capability (PEMC). The list of user identifiers associated with the loT network may include a personal loT network element identifier. The loT network may include a personal loT network.

[0076] In some examples, an loT device (e.g., a PE) may send a request to a server associated with an loT network (e.g., a PIN). The loT device may receive a message from the server associated with the loT network. The message may include an application-level user identifier associated with the loT network and information of a management element (e.g., a PEMC) associated with the loT network. The loT device may send the application-level user identifier associated with the loT network to the management element associated with the loT network. The loT device may receive an authorization to join the loT network. The loT device may include a WTRU. The management element associated with the loT network may receive an application-level user identifier associated with the loT network. The management element associated with the loT network may send a registration reguest that comprises the application-level user identifier associated with the loT network. The management element associated with the loT network may receive a registration response that comprises an association between the application-level user identifier associated with the loT network and a network-level user identifier associated with the loT network. The management element associated with the loT network may send an authorization to join the loT network. The registration response may include a list of user identifiers associated with the loT network. The management element associated with the loT network may include a WTRU. Systems, methods, and instrumentalities are described herein associated with a wireless transmit/receive unit (WTRU) configured to manage a personal loT network (PIN). The WTRU, in addition to acting as a PINE with a gateway capability (PEGW), may act as a PINE with a management capability (PEMC).

[0077] Systems, methods, and instrumentalities are described herein associated with a wireless transmit/receive unit (WTRU) configured to manage a personal loT network (PIN). The WTRU, in addition to acting as a personal Internet of things (loT) network (PIN) element (PINE) with a gateway capability (PEGW), may act as a PINE with a management capability (PEMC).

[0078] The WTRU may send a registration request message to a network node. The registration request message may indicate a request to register the WTRU with the PIN and include an application-level PIN element identifier (PEID) associated with a PIN element (PINE). The WTRU may receive a registration response message from the network node. The registration response message may indicate that the WTRU is registered with the PIN and indicate a PIN management policy associated with the PIN. The WTRU may receive a PIN message that includes the application-level PEID associated with the PINE. When the WTRU receives the PIN message from the PINE, the WTRU may modify information in the PIN message based on the PIN management policy such that the application-level PEID, in accordance with the PIN management policy, is replaced by a network-level PEID. For example, the PIN management policy may indicate a PEID association and a charging policy. The PEID association may indicate an association between the application-level PEID and the network-level PEID. The WTRU may modify the information in the PIN message based on the PIN message, the charging policy, and the PEID association. [0079] The PIN message may indicate a request for a service. The WTRU may determine, based on the PIN management policy, that the service is to be provided by a core network. The core network may include one or more network nodes. Based on the determination, the WTRU may send the registration request message as described herein to the network node. In examples, the one or more network nodes may include the network node to which the modified PIN message is sent. The one or more network nodes may not include the PINE. In some examples, the WTRU may determine, based on the PIN management policy, that the service is to be provided by a third-party service provider associated with a data network. Based on this determination, the WTRU may still send the registration request message as described herein to the network node so that the network node may contact the third-party service provider regarding the service. The data network may not include the PINE or the network node to which the modified PIN message is sent.

[0080] The WTRU may send, to the network node, the modified PIN message that includes the networklevel PEID and indicates that the WTRU is registered with the PIN. The modified PIN message sent to the network node may indicate the request from the PINE for the service.

[0081] In some examples, the PIN management policy may indicate a PEID association but may not indicate the charging policy. The PEID association may further indicate an association between a device ID associated with the PINE and the network-level PEID.

[0082] As an example, a WTRU (e.g., PEMC) may include a processor configured to: send a registration request message to a network node, wherein the registration request message indicates a request to register the WTRU with a PIN and comprises an application-level PEID, wherein the application-level PEID is associated with a PINE, the PIN, and a charging policy; receive a registration response message from the network node, wherein the registration response message indicates that the WTRU is registered with the PIN, indicates a PEID association, and indicates a network-level PEID associated with the WTRU, wherein the PEID association indicates that the application-level PEID is to be replaced by the networklevel PEID for a request from the PINE for a service in accordance with the charging policy; receive a service request message from the PINE, wherein the service request message indicates the request from the PINE for the service and comprises the application-level PEID; determine that the service is unavailable locally; modify the service request message based on the PEID association such that application-level PEID is replaced by the network-level PEID in accordance with the charging policy; and send the modified service request message to the network node, wherein the modified service request message indicates the request from the PINE for the service, indicates that the WTRU is registered with the PIN, and comprises the network-level PEID.

[0083] Personal loT network (PIN) identity management may be part of PIN management, for example, performed by a PEMC. Identity allocation, authentication, and/or authorization may be performed in one or more examples, as described herein. [0084] A network (e.g., a 3GPP network) may support user-centric identifiers and authentication. For example, a user identifier in one or more examples herein may be independent of identifiers relating to a subscription or a device (e.g., independent of International mobile subscriber identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), IP Multimedia Private Identity (IMPI), IMS Public User Identity (IMPU), Subscription Permanent Identifier (SUPI), Generic Public Subscription Identifier (GPSI), International Mobile Eguipment Identities (IMEI)) and of other user identifiers.

[0085] PIN Element (PE)-identifier(s)(ID(s)) may be assigned, for example, by a PIN Element with Management Capability (PEMC) or a PIN server. In an example, a PEMC may assign PEID(s). A user may start creating a PIN using his/her PEMC device (e.g., a WTRU may act as PEMC). The PEMC may contact a PIN server to create a PIN. The PIN server may send a list of PEIDs and/or a PI NJD, for example, to the PEMC. The PEMC may assign PEID(s) and/or the PINJD, for example, to individual PEs. The PEMC may send a NAS message about assigned PI N_l D and/or PEIDs, for example, to a core network (CN).

[0086] In an example, a PIN server may assign PEID(s). A user associated with a PE may want to join a PIN. The PE may contact the PIN server. The PIN server may assign application-level PEID(s) to the PE. The PE may receive an application-level PE ID and/or PEMC information. The PE may determine or identify a PEMC using the PEMC information. The PE may join the PIN by sending the application-level PEID to the PEMC. The PEMC may validate the application-level PE ID with a CN. The CN may send a network-level PEID to the PEMC. The CN may associate the application-level PE ID to the network-level PEID, for example, for policy, charging, and/or inter-network identification. The CN may validate the application-level PEID(s) and/or associate the application-level PEID(s) with network-level PEID(s). The CN may provide a PIN management policy (e.g., for policy, association(s) of identifiers, charging, and/or internetwork identification) to the PEMC. For example, the PIN management policy may include a PEID association and/or a charging policy. The PEMC may use the PEID association to change the applicationlevel PEID to the network-level PEID. In examples, the PEID association may indicate that, when the PINE reguests a service, the application-level PEID is to be replaced by the network-level PEID. A charging policy may indicate how a PINE (e.g., a WTRU PINE) is to be charged or billed for a service (e.g., for a service provided by PIN). A network (e.g., a core network) may provide a charging policy, for example, by using network-level identifier(s) for the PINE. A routing policy may indicate how traffic (e.g., data traffic or control information traffic) is to be routed (e.g., routed through 5GS, routed internally, offloaded to other network(s) etc.).

[0087] PEID(s) may be generated, for example, at a CN or at a PEMC. In an example, PEID(s) may be generated at the CN (e.g., using a PEID generation algorithm) and/or delivered to the PEMC. The PEID generation algorithm may be provided to a CN or a PEMC to generate of PEID(s). In an example, PEID(s) may be generated, for example, using a PEID generation algorithm at a PEMC.

[0088] A PIN may be used as an example of an loT network in one or more examples, as described herein. A PEID may be used as an example of a user identifier associated with an loT network in one or more examples, as described herein. A PE may be used as an example of an loT device in one or more examples, as described herein. A PE in one or more examples herein may include a WTRU. A PEMC in one or more examples herein may include a WTRU.

[0089] Personal Internet of Things (loT) networks may be generated. loT feature(s) may have been designed for devices that communicate using a cellular network (e.g., the traditional cellular network). Devices with loT capabilities may work with (e.g., with a requirement of) a better power consuming performance and/or an increased network efficiency, for example, for bulk operations.

[0090] When multiple loT devices are deployed in a private environment, the WTRUs with loT capabilities can be organized in a Personal loT Network (PIN). For example, in a home environment, one or more security sensor(s), smart light(s), smart plug(s), printer(s), cellphone(s) or the like may be managed by a residential gateway and may communicate with each other. FIG. 2 a diagram illustrating an example of a home automation PIN. In this case, some or all devices in home may constitute a PIN. A device in the home (e.g., each device in the home) may be called a PIN element. Different PEs may have different capabilities. For example, a residential gateway may be a PIN Element with Gateway Capability (PEGW) to provide connections between PIN elements and/or connections between 5G network and the PIN Elements. A PIN Element with Management Capability (PEMC) may be a PIN Element may allow an authorized administrator to configure and/or manage a PIN. For example, a residential gateway, which may be acting as a PEGW, may support PIN management function and be a PIN element with management capability. In one or more examples herein, the term “PEGW” and the term “PEGG” are interchangeable.

[0091] Wearable device(s) may constitute a PIN (e.g., a kind of PIN that is different from other kinds of PIN such as a home automation PIN). A WTRU may be a wearable device, such as a wearable PINE. A WTRU may be a PINE. A smart phone, which may be a WTRU, may act as a PEGW as well as a PEMC, for example, in the PIN associated with the wearable device(s). The PIN associated with the wearable device(s) may be a wearable PIN. Wearable device(s) (e.g., one or more smart watch(es), VR/AR glasses, or airpod(s)) may communicate with other WTRUs via 5G network, for example, using smart phones as the PEGW and the PEMC. Wearable device(s) may communicate with each other in the PIN. FIG. 3 is a diagram illustrating an example, at 300, of wearable PINs. The wearable PINs are used as examples in FIG. 3. FIG. 3 may be applicable to other types of PINs (e.g., to the example home automation PIN in FIG. 2). As shown in FIG. 3, a wearable PIN 330 may include PINE 306 (e.g., an airpord), PINE 308 (e.g., VR glasses), PINE 310 (e.g., an apple watch), and PINE 304 (e.g., a smart phone). PINE 304 may act as a PEGW and a PEMC for the wearable PIN 330. A wearable PIN 340 may include PINE 316 (e.g., an airpord), PINE 318 (e.g., VR glasses), PINE 320 (e.g., an apple watch), and PINE 314 (e.g., a smart phone). PINE 316 may communicate with PINE 318 (e.g., directly). PINE 314 may act as a PEGW and a PEMC for the wearable PIN 340. As shown in FIG. 3, PINE 304 may communicate with a network (e.g., a 5GS) to authorize the access of one or more of PINE 306, PINE 308, or PINE 310 to the network and manage how the communications associated with the network and one or more one or more of PINE 306, PINE 308, or PINE 310. For example, PINE 310 may request a service by sending a message to PINE 304, which may update the message and may send the updated message to the network. PINE 304 may be used as a PEGW and a PEMC for PIN 330. PINE 314 may be used as a PEGW and a PEMC for the wearable PIN 340. PINE 310 may communicate with PINE 320, for example, via network 302. In examples, a service may not be locally available for PINE 310. The service that is not locally available may be available via network 302. PINE 310 may send a request to PINE 304 for the service, and PINE 304 may contact network 302 to inform network 302 about the request for the service.

[0092] A PIN architecture may include multiple components. FIG. 4 is a diagram illustrating an example of a PIN architecture.

[0093] As shown in FIG. 4, a PIN 430 may include one or more PEs, a PEMC, and a PEGW. A PIN element may be a WTRU or another device, such as a non-3GPP device, that may communicate within a PIN. A PIN management device may be a PIN Element capable of managing a PIN. A PEGW may be a PIN Element that has the ability to provide connectivity to and from a network, which may be a 5G network, for other PEs. For example, PEGW may authorize the access of a PINE to a network 440 (e.g., a 5G Core network (5GC)) through a node associated with a RAN, and a PEMC may manage a PIN (e.g., PIN identity management such as identity allocation, authentication, and/or authorization associated with a PE). One or more entities may act as PEMC and PEGW. For example, a PINE may act as PEMC and PEGW for a PIN. The network 440 may be a core network, which may be associated with a RAN, an AMF, an SMF, and a UPF. The network 440 may include one or more network nodes As shown in FIG. 4, the network 440 may include a network node associated with the RAN, a network node associated with the AMF, a network node associated with the SMF, and a network node associated with the UPF. The network 440 may not include a PINE associated with the PIN 430 (e.g., the PEMC, the PEGW, and other PINEs).

[0094] A data network (e.g., a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN)) may be a different network from a core network. As shown in FIG. 4, the network 460 may be a data network. The data network may be provided (e.g., operated and managed) by a third-party service provider. The network 440 may access the network 460, for example, through a network node associated with the UPF. The network 460 may not include the network nodes in the network 440 (e.g., the network node associated with the RAN, the network node associated with the AMF, the network node associated with the SMF, and the network node associated with the UPF). The network 460 may or may not include a PINE associated with the PIN 430 (e.g., the PEMC, the PEGW, and other PINEs).

[0095] PINEs may communicate with each other. For example, PINEs may communicate with each other directly or may communicate with each other via a PEGW.

[0096] Some services may be provided by a PINE. For example, a PINE may include a temperature sensor that provides temperature readings of a location. The PINE may provide the temperature readings of the location to a network (e.g., to a network node (e.g., an AF) associated with a 5GC or associated with a data network such as via Internet) or to a different PINE (e.g., an AF associated with the different PINE). The different PINE may be associated with the same PIN as the one associated with the PINE or associated with a PIN that is different from the one associated with the PINE. Some services may be provided by a core network and/or a third-party service provider (e.g., these services may not be provided by a PINE or by other PINEs in a PIN).

[0097] PINEs may communicate with a system (e.g., a 5G system) to obtain services (e.g., 5G services) or communicate with a data network via the core network (e.g., a 5G CN). For example, a PE may obtain a service (e.g., a 5G service) from the network 440 by sending a service request to a PEMC, a PEGW, or a PINE that acts as a PEMC and a PEGW.

[0098] The PEMC, the PEGW, or the PINE that acts as a PEMC and a PEGW may determine whether a service requested by a PINE is allowed, for example, based on a PIN management policy. For example, a PINE may send a PEMC a message that indicates a request for a PIN service such as “Create PIN” or “Join PIN). The message may indicate that the PIN service is requested to start a video streaming application (e.g., a video streaming service from an application service on the Internet). The PEMC may determine whether the request for the PIN service (e.g., for the video streaming application) is permitted based on the PIN management policy. The PIN management policy may have been sent by one or more of a core network, an AF, or a PIN server, and/or provisioned to the PEMC.

[0099] The PEMC, the PEGW, or the PINE that acts as a PEMC and a PEGW may send, to the network 440, a message indicating the service request, for example, after modifying information in the service request. The service request may be sent in a message (e.g., in a message associated with a PIN). The message may indicate one or more of a request for a status update, a request for an authorization by a core network, a request for an association with a PIN, a requestion for a change of service (e.g., a change in an end point of a service such as switching from a WTRU to a PINE that is a TV display), etc. [0100] The services that are requested and/or obtained by a PINE may include PIN services. The PIN services may include one or more of creation of a PIN, association with a PIN (e.g., joining a PIN or leaving a PIN), a change of service (e.g., a service switch), a continuation with a service (e.g., service continuity). The services that are requested and/or obtained by a PINE may be provided by a network (e.g., the network 440 or the network 460, for example, if the services are provided by the network 460, the services may be third-party managed services). For example, the network may be configured to provide one or more of voice services, data services, application services (e.g., gaming, wearable applications such as remote health, home automation etc.), VoIP services, call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution etc. In examples, the PIN services may enable a fulfilment of the services that are provided by the network. For example, a PINE may be required to join a PIN to access a gaming service provided by a data network.

[0101] In some examples, a WTRU that acts as PEMC(s) and/or PEGW(s) (e.g., only as PEMC(s) and/or PEGW(s)) may use a first type of communication (e.g., 3GPP communication), and other communications within a PIN may be carried out using a second type of communication (e.g., non-3gpp communication such as WiFi or Bluetooth).

[0102] A network may use an authentication layer in addition to a subscription authentication layer. In some examples, a network, such as a 5G network, may be enhanced to support a user-centric authentication layer (e.g., in addition to a subscription authentication, such as being on top of the existing subscription authentication). As an example, a system, such as a 3GPP system, may provide different users that use the same WTRU with customized services. Users of devices behind a gateway with a subscription but without a dedicated subscription (e.g., users of devices with a 3GPP subscription but without a dedicated 3GPP subscription) may be identified. A user identifier may be linked to a subscription to access services (e.g., access 3GPP services via non-3GPP access). In some examples, user identity requirements may include, for example, requirements captured in a standard, such as 3GPP.

[0103] A user identity (e.g., a user Identity in a 3GPP system) may identify a device (e.g., where the device may be a WTRU or a device without a subscription, a person, or an application) to a mobile network operator (MNO) that may be associated with the device, person, or application. The MNO may have a business relationship with the device, person, or application and/or may be responsible for authenticating and authorizing device, person, or application requests and/or for maintaining information record(s) that are associated with the device, person, or application.

[0104] Proximity-based services (ProSe) may be used, for example, to generate a PIN. [0105] ProSe may include services (e.g., services that can be provided by the 3GPP system) based on WTRUs being in proximity to each other To provide ProSe, WTRU(s) may perform ProSe discovery procedure(s) to discover other WTRU(s) in proximity.

[0106] One or more ProSe discovery modes (e.g., model A and model B) may be used to discover WTRU(s).

[0107] In model A, a WTRU (e.g., the announcing WTRU) may broadcast announcement messages with a ProSe code which may be associated with the announcing WTRU’s ID or be associated with a service provided by the announcing WTRU. Other WTRUs who received an announcement message (e.g , the monitoring WTRU(s)) may learn that an announcing WTRU may be in proximity. FIG. 5 is a diagram illustrating an example of a ProSe direct discovery with model A.

[0108] In model B, a WTRU (e.g., the discoverer WTRU) may broadcast solicitation request message(s) with a ProSe Query code, which may be associated with the WTRU’s ID to be discovered or be associated with the ProSe service to be discovered. Other WTRUs who received the solicitation request message(s) (e.g., the discoveree WTRU) may respond to the request with ProSe response code(s) (e.g., a response code which may be associated with the discoveree WTRU’s ID or associated with the ProSe service provided by the discoveree WTRU). The discoverer WTRU may learn that the discoveree WTRU may be in proximity. FIG. 6 is a diagram illustrating an example of a ProSe direct discovery with model B.

[0109] One or more discovery modes may be used to perform a group discovery (e.g., to discover WTRUs that belong to a specific group) and a WTRU-to-Network relay discovery (e.g., to discover a WTRU-to-Network relay that provides a connection with a 5G network).

[0110] For a group discovery, the discovery message (e.g., Announcement, Solicitation Request/Response) may include a group ID. For a WTRU-to-Network relay discovery, the discovery message (e.g., Announcement, Solicitation Request/Response) may use a relay service code (e.g., instead of ProSe code) to indicate the WTRU-to-Network relay service.

[0111] A user (e.g., a homeowner and/or an enterprise system administrator) may install a PIN using off- the-shelf devices (e.g., one or more of smart light(s), camera(s), motion sensor(s), TV(s), etc.). The devices may be pre-configured and/or authorized by a Mobile Network Operator ( NO) or a Managed Service Provider. The devices may be configured (e.g., presumably) with an identifier, for example, by a service provider. The identifier may be, for example, an application-level identifier.

[0112] Before a PE can operate in a PIN, which may be managed by a core (e.g., a 5GC), the PE may use (e.g., need) a PIN element identifier (PEID), a form of identifier that a network (e.g., a 3GPP network) identifies a PE with. PE and/or PINE may be used to refer to a PIN element herein. [0113] Based on the PEID, a PINE may be identified, tracked, or authorized (e.g., uniquely identified, tracked, authorized, etc.). The PEID may help facilitate the core, such as the 5GC, to configure with PIN management policies (e.g., charging and routing policies for the data traffic originating from a PINE). For example, a CN may configure a PEMC with PIN management policies, which the PEMC may use to manage a PINE in a PIN.

[0114] How a PEID may be assigned to a PE is shown in one or more examples herein. How a PEID may be constructed or realized is shown in one or more examples herein.

[0115] In one or more examples, a PEID may be assigned to a PE by a PEMC. A PEMC may connect with a PIN server (e.g., a managed service provider). The PEMC may send PEMC information, for example, to the PIN server. The PEMC may request one or more PEID(s), for example, from the PIN server. The PIN server may send one or more PEIDs (e.g., set(s) of PEIDs) to the PEMC. The PEMC may assign a PEID to a respective PE or assign multiple PEIDs to a PE. The PEMC may update a CN with information on a PIN and/or update the CN with information on PINEs. The information may include one or more of association(s) of PEIDs and application-IDs (e.g., association(s) of network-level PEIDs and application-level PEIDs), an association of a PIN-Type and a PEID range, etc. The CN may send a Non- Access Stratum (NAS) response to the PEMC.

[0116] In one or more examples, a PEID may be assigned to a PE by a PIN server. A PE may contact a PIN server to create and/or join a PIN. The PIN server may authenticate the PE and/or assign a PEID (e.g., an application-level PEID). The PE may join the PIN by contacting a PEMC and/or may send the PEMC the PEID assigned by the PIN server. The PEMC may send an application-level identifier (e.g., the applicationlevel identifier may be the PEID received from the PE). In examples, the PEMC may send the applicationlevel identifier along with one or more of a device ID, a location, network ID, etc., to a system (e.g., a 5G System (5GS)). A system, such as a 5GS, may construct a network-level PEID and/or store the association between the application-level ID and the network-level PEID. A managed service provider may be informed about the availability of the PE associated with the application-level Identifier (e.g., based on a received network-level PEID that is associated with the application-level PEID).

[0117] PEID(s) may be generated. PEID(s) may be generated at a PIN server in one or more examples herein. A PIN server may decide to generate PEID(s) within a system, such as a 5GS. A PIN server may decide to generate PEID(s) at a PEMC. A PIN server may decide whether to generate PEID(s) within a 5GS, or at a PEMC. The PIN server may generate PEID(s) by providing a PEID Generation Function (PGF) (e.g., PEID Generation Function Algorithm (PGA)) to a system, such as the 5GS, or the PEMC. In examples, if a PIN server decides to generate PEID(s) within a 5GS, the PIN server may provide a PEID Generation Function (PGF) algorithm to the 5GS. If a PIN server decides to generate PEID(s) within a PEMC, the PIN server may provide a PEID Generation Function (PGF) algorithm to the PEMC.

[0118] In example, PEID(s) may be generated in a network function (e.g., a 5G Network Function (NF)). In an example, the network function may be a PGF. A PEMC may send a registration reguest to a CN indicating its PEMC capability. An AMF may facilitate the authentication and/or authorization of the PEMC, and, upon success, may trigger the PGF to generate PEID(s). The PGF may implement the PGA. The PGF may take one-time input(s) (e.g., such as one or more of time, date, random number, etc.) into the PGA, and/or generate a set of PEIDs for the PEMC (e.g., a PEMC WTRU). The CN may send the set of PEIDs back to the PEMC (e.g., via a RAN with Registration Accept message) and may receive an acknowledgment.

[0119] A PGA may be sent for PEID generation at PEMC. A PEMC may send a registration request to the CN indicating its PEMC capability. Upon successful PEMC registration, the AMF (or Policy Control Function (PCF), Unified Data Management (UDM), Authentication Server Function (AUSF), etc.) may trigger the PGF, for example, with a request for a PGA. The PGF may send back the PGA to the PEMC (e.g., via the AMF and RAN in the Registration Accept message), and the CN may receive an acknowledgment.

[0120] PEID(s) may be assigned to a PE by a PEMC. FIG. 7 is a diagram illustrating an example where PEID(s) is delivered to a PEMC (e.g., the PEID(s) sent to and received by the PEMC) for assignment. The PEID(s) may be delivered to a PEMC from a PIN server. A PEMC may contact a PIN server. The PIN server may send PEID(s) to the PEMC. The PEMC may receive a set of PEIDs associated with the PEs. The PEMC may assign the set of PEIDs to the PEs (e.g., assign each of the sets of the PEIDs to a respective PE). The PEMC may inform a CN about the assigned PEID and/or PIN ID, for example, using an NAS message.

[0121] As shown in FIG. 7, at 702, a PEMC may discover PEs (e.g., loT devices) and may trigger creation of a PIN, for example, with the help of an administrative user. In examples, the administrative user associated with the PEMC may decide that the PIN is to be created.

[0122] At 704, the PEMC may connect with a PIN server using a service protocol or an application layer protocol in the data network. The PIN server may be a managed service provider. The PEMC may send a request to create a PIN (PIN creation). The request (e.g., the PIN creation request) may include one or more of a user ID (e.g., an application ID and/or a user identifier), PEMC capabilities (e.g., capabilities such as one or more of mobile, stationary, max PE cardinality, max PIN cardinality, services, etc.), a list of available device types (e.g., the device types of the PEs) and the networking technologies used by the available devices (e.g., non-3GPP networking technologies), application services, a subscription ID of a WTRU (e.g., a subscription ID of a PEMC or a subscription ID of a PE), location information (e.g., a Public Land Mobile Network (PLMN) ID the PEMC subscribes to, and geographic location information of the PE and/or the PEMC, if applicable), an authorization request for PEID management (e.g., PIN types to be created), etc. The PIN creation request may include an explicit request for PEIDs.

[0123] At 706, the PIN server may authenticate the PEMC and examine the request (e g., the PIN creation request) by the PEMC and/or the information included in the request by the PEMC. The PIN server may authorize the request.

[0124] At 708, a response message may be sent based on a successful authentication of the PEMC and a successful authorization of the request. Upon successful authentication and authorization, the PIN server may send to the PEMC a response that includes an "OK" message indicating a successful authorization. The response may include a PIN ID (PI N_l D) and a list of PEIDs that the PEMC may assign to the PEs (e.g., loT devices). In examples, the response message may include a PIN management policy that indicates the PINJD) and the list of PEIDs that the PEMC may assign to the PEs (e.g., loT devices). The PIN server may send set(s) of PEIDs (e.g., each set may be dedicated to a PIN Type and/or associated with certain PIN type information). For example, PEIDs ranging 1001-1020 for PEs associated with a first PIN type (e.g., wearables PIN elements), PEIDs 1021-2020 for PEs associated with a second PIN type (e.g., Home Appliance PIN elements), and so on A PE associated with a first PIN type and a PE associated with a second PIN type may request different services, for example, by sending different service requests to the PEMC.

[0125] At 710, the PEMC may assign PEIDs to the PEs. PEID assignment may include creating a different or new PIN using the PIN_ID received from the CN (e.g., the PI N_l D received at 708). In some examples, in addition to assigning PEIDs and/or creating a PIN, the PEMC may assign policies, such as PIN management policies (e.g., 3GPP policies such as charging policies or routing policies), etc., if applicable. For instance, a PE (e.g., off-the-shelf loT device(s)) may be equipped with an integrated iSIM that can be activated and configured remotely such that some policies (e.g., 3GPP policies) may be configured in the PE. Activating iSIM in a device may convert the device into a WTRU, which may be a 3GPP WTRU.

[0126] At 712, the PEMC may send an updated PIN message (e.g., a modified PIN message), for example, to the PIN server and/or other CN network nodes or functions. The updated PIN message may be a message that has been modified based on a message that has been received from a PE associated with a PIN. In example, a first message may have been sent by the PE and received by the PEMC. The first message may indicate information associated with the PIN (e.g., by including information associated with the PIN). The first message may be a PIN message. The first message may indicate a request for a service. The first message may include an application-level PEID associated with the PE. The PEMC may modify information in the first message before the PEMC sends the modified information (e.g., the PEMC may send a modified message including the modified the information), for example, to a network. The PEMC may modify the information in the first message based on a PIN management policy. For example, the PEMC may modify the information in the first message based on the first message, the PEID association, and a charging policy. For example, the PEMC may determine a network-level PEID based on an application-level PEID and the PEID association. The PEMC may determine how the PE that requested the service is to be charged (e.g., based on the network-level PEID). For example, the PEMC may modify the information in the first message by replacing the application-level PEID with the network-level PEID (e.g., in accordance with the PEID association indicated by the PIN management policy) and by indicating how the PE that requested the service is to be charged The PEMC may send a second message (e.g , a modified first message) that includes the network-level PEID and/or indicates how the PE is to be charged. The modified message may be a PIN message. The PEMC may determine, based on the PIN management policy, that the service requested (e.g., as indicated in the first message) is to be provided by a core network or by a third-party service provider.

[0127] The updated PIN message may indicate the request from the PINE for the service and indicate that the WTRU is registered with the PIN. The updated PIN message may include one or more of user I D(s), a P I N_l D for the configured PIN and a list of PEID(s) (e.g., a list of network-level PEIDs), device types, and device ID(s) for the PIN element(s) in the PIN, signifying association(s) among the identities. For example, the updated PIN message may include a network-level PEID that has replaced an applicationlevel PEID in a PIN message sent by a PE to the PEMC. In some examples, by translating an applicationlevel PEID to a network-level PEID, the PEMC may not reveal the network-level PEID to the PE.

[0128] At 714, the PIN server may acknowledge, for example, the delivery of the updated PIN message, by sending an OK message. A network-level procedure may be started.

[0129] At 716, the PEMC may send a NAS message that includes one or more of the PIN ID(s) for the PIN, an application ID for a PE (e.g., a respective application-level identifier for each PE), and a list of one or more of device IDs, PEIDs, and a PIN type. The NAS message may indicate an association among the PEIDs, device IDs and the PIN type for the PIN to which the devices/PEs are linked. In some examples, the PEMC, by sending the NAS message, may update a network (e.g , 5GC or an AMF) about an association between an application-level PEID and a network-level PEID (e.g., the NAS message may include the network-level PEID).

[0130] At 718, an AMF or a SMF may receive the PE and PIN information and/or may update PIN-NF(s) and/or other network functions (NFs) such as the unified data management (UDM). [0131] At 720, the AMF may send to the PEMC a NAS response message as an acknowledgement to the update received (e.g., the reception of the updated PIN message, for example, if the updated PIN message has been sent to the AMF). A NAS response may be a Registration Accept, a WTRU configuration update, or a simple NAS response.

[0132] PEID(s) may be assigned to PE by a PIN server. FIG. 8 is a diagram illustrating an example of PEID assignment based on application-level identifier(s).

[0133] PEs may connect to a PEMC, for example, using their corresponding wireless technologies, which may be non-3GPP wireless technologies. A WTRU may act as the PEMC. The PEMC may collect, from devices (e.g., from the PEs) application-level identifier(s), which may be used by one or more of the PEMC, the CN, and/or the managed service providers, to track and allocate PEIDs (e.g., network level- PEIDs).

[0134] 802 in FIG. 8 may be part of an application-level procedure. At 802, a PE (e.g., an loT device) may send, to a PIN server, a request to join or create a PIN (e.g., an application-level PIN request) or send a trigger to join or create the PIN.

[0135] At 818, the PIN server may authorize the request and send application-level PEID(s) to the PE. The application-level PEID(s) may be associated with the PE.

[0136] At 804, PEs may connect to a PEMC using their corresponding wireless protocol(s) (e.g., one or more non-3GPP wireless protocols)). For a (e.g., each) PE, the PEMC may receive an application-level PEID associated with the PE (e.g., the corresponding application-level PEID). 804 may be an applicationlevel process (e.g., part of the application level procedure). In some examples, 804 may be out of scope (e.g., out of scope of 3GPP).

[0137] At 806, the PEMC may send a registration request message to the CN (e.g., to a network node such as an AMF or SMF). The registration request message may indicate a request to register the PEMC with a PIN. In the registration request message, the PEMC may include information such as one or more of PIN types to be created, the application-level PEID(s), location information, the Network ID, device IDs of the devices (e.g., MAC address), etc. For example, an application-level PEID in the registration request message may be associated with a PE and have been sent from the PE to the PEMC at 804. An application-level PEID may be an index or a string of data that the provider of the service recognizes. The application-level PEID may indicate a specific characteristic of the service provider. A 5GS operator (e g., a 3GPP operator) may recognize the application-level PEID based on a service agreement with the service provider.

[0138] At 808, the network node (e.g., the AMF or SMF) may receive the registration request message, may examine the subscription and/or capabilities of the PEMC (e.g., the PEMC may be a WTRU), and/or may authenticate and authorize the PEMC. The CN (e.g., the AMF, PCF, AUSF, etc.) may determine or identify that the request requires the CN to contact a third-party-managed service provider, e.g., based on the information in the registration request message. The CN may request or may have requested from a PIN server (e.g., via a Personal loT Network-Network Exposure Function (PIN-NEF)) information related to the PE(s), including application-level PEID(s). A PIN-NF may (e.g., presumably) have been equipped with a PIN-NEF.

[0139] At 810, the PIN-NF may validate application-level PEIDs received from the PEMC (e.g., an loT device), for example, by validating the application-level PEIDs received from the PEMC against the application-level PEIDs received from the PIN server.

[0140] At 812, the PIN-NF may send, for example, to the AMF or SMF an "OK” message indicating that the application-level PEID(s) is valid and assign network-level PEID(s) for a (e.g., each) PE and provide a list of assigned PEIDs, which may indicate association(s) between application-level PEIDs and networklevel PEIDs.

[0141] At 814, the AMF or SMF may send to the PEMC a registration response message. The registration response message may indicate that the PEMC is registered with the PIN. In the registration response message, the AMF or SMF may indicate one or more of the following (e.g., by including one or more of the following): PIN types (e.g., an interactive PIN type, a streaming PIN type, and a "mission critical” PIN type, a wireless PIN, a home automation PIN etc.); pre-authorization information from the PIN server which indicates that the PEMC is registered with the PIN and/or that the PEMC may configure the given application-level PEIDs to the PIN elements/devices; a PIN management policy indicating PEID association(s), for example, a list of assigned PEIDs which may be association(s) of network-level PEIDs and corresponding application-level PEIDs assigned to the PIN elements, etc. The PIN management policy may include additional information. For example, the PIN management policy may indicate a MAC address of a PE and/or a manufacturing ID of the PE, in addition to an association of an application-level PEID and network-level PEID of the PE, and indicate an association between the application-level PEID of the PE and one or more of the MAC address of a PE, the manufacturing ID of the PE, or the network-level PEID of the PE. For example, the PIN management policy may indicate an association of the application-level PEID to the network-level PEID of the PE for a service level (e.g., service level 1, 2, or 3). The PIN management policy may indicate the availabilities of PEs for a PIN-ID, the availabilities of PEs that are allowed for a certain service, the availabilities of PEGWs for the PE and the access information to user-plane service(s) via the PEGWs, the temporal duration for which the PEs are available, the temporal duration for which a PIN is valid, whether a PIN (or a PE) is deactivated or enters a sleep mode when the PIN is not valid, etc. The PIN management policy may indicate the levels of services and/or the types of services provided a network (e.g., the levels and/or the types of services available through a core network or a third-party managed network). The PIN management policy may indicate whether a service requested by a PE is permitted. The PIN management policy may indicate a charging policy, a routing policy, etc.

[0142] At 816, the PEMC may provision the assigned PEIDs at the PEMC and may send back an “OK” response to the PE indicating a successful connection. For example, the PEMC may not reveal a networklevel PEID to the PE and may assign the network-level PEID to an application-level PEID so that the PEMC may replace the application-level PEID with the network-level PEID when the PEMC receives the application-level PEID, before the PEMC sends the network-level PEID to the network. A network-level PEID may be one or a combination of identifiers that a network is able to decode (e.g., the network is able to understand). In examples, the network-level PEID may be an IMSI or IMEI. The network-level PEID may be a combination of an IMEI, a network ID, and a country code.

[0143] PEID(s) may be generated, for example, in a PGF or at a PEMC.

[0144] In examples, PEID(s) may be generated in a network function, such as a 5G NF (e.g., a PGF).

[0145] A CN may enable the generation of PEID(s), for example, after a WTRU (e.g., a PEMC WTRU) may be successfully authenticated and authorized as a part of the WTRU registration procedure. A PIN network function (PIN-NF) may handle some or all the procedures related to PIN management, which includes a PIN element ID Generation Function (PGF). The PIN-NF may be configured with a PEID Generation Algorithm (PGA) that the PGF implements to generate one or more PEIDs (e.g., a set of PEIDs). The PIN-NF may send the set of PEIDs to the PEMC with the registration accept message. FIG. 9 is a diagram illustrating an example of the delivery and assignment of PEID(s) generated by a CN.

[0146] At 902, devices (e.g., non-3GPP loT devices) may connect to a PEMC/PEGW (e.g., a WTRU acting as a PEMC and/or a PEGW) using their wireless connectivity (e.g., wireless connectivity such as WiFi, Bluetooth, etc.). The PEMC/PEGW may (e.g., presumably) possess wireless connectivity capabilities (e.g., non-3GPP wireless connectivity capabilities) and/or capabilities to communicate among some or all the devices connecting to the PEMC/PEGW.

[0147] At 904, the PEMC/PEGW (e.g., the WTRU acting as a PEMC and/or a PEGW) may send a WTRU registration request towards the CN (e.g., an AMF). In the request, the PEMC/PEGW may include one or more of the following: a request for PEIDs, the loT device types connected, the wireless protocols that these loT devices are connected with, or a PEMC type (e.g , Mobile or Fixed) and/or may include a requested PEID range (if applicable). The PEMC/PEGW may include the range based on the loT devices that are connected or the PIN types the PEMC supports. The PEMC capability may indicate the PIN types the PEMC can support (e.g., the PIN types may include one or more of home automation, security and surveillance, XR gaming, etc.). The PEMC/PEGW may send in the request for one or more of compatibility features with third-party managed services, support for types of wireless protocols (e.g., non-3GPP wireless protocols), etc. If the connected loT devices are part of and/or members of the third-party managed services, the PEMC/PEGW may include one or more of the names/identifiers, credentials, subscription information, etc., relating to the third-party managed service providers.

[0148] At 906, once the PEMC/PEGW may be successfully authenticated, the PEMC/PEGW's request(s) may be authorized and the request(s) may trigger the PIN-NF for the delivery of PEIDs to the PEMC/PEGW.

[0149] At 908, the PIN-NF may request and receive a PGA from a PIN server (e g., third-party manager service provider). If the PIN-NF has already been configured with one or more third party PGAs, the PIN- NF may send an authorization request to use a PGA, for example, by including a PGA-ID and receive a response from the PIN server to implement the PGA.

[0150] At 910, the PIN-NF may receive the request to generate PEIDs for the requesting PEMC/PEGW. The PIN-NF may trigger, for example, a PEID generation function (PGF) for the generation of PEID(s). The PGF may run a PEID generation algorithm (PGA). The PGA may generate PEIDs (e.g., application-level PEIDs assigned to PEs. The PGA may be run by a network. The PGA may take inputs (e.g., takes onetime inputs), such as one or more of time stamp(s), date(s), and random number(s), to generate a set of PEIDs. Either explicitly or implicitly, the PGF may consider one or more of loT device information, supported PIN types, requested PEID ranges, PEMC types, etc. for the generation of PEID(s). Based on the information, the PGF may create multiple ranges of PEIDs dedicated for PIN type(s) (e.g., each PIN type), and/or an association between a PEID set and a PIN type may also be provided, for example, PEIDs ranging 1001-1020 for Wearables PIN elements, PEIDs 1021-2020 for Home Appliance PIN elements, and so on.

[0151] At 912, the PIN-NF (e.g , act as a measurement function (PMF)) may send set(s) of PEIDs, a List of PEID range(s) and PIN/PE type(s) indicating association(s) between the PEID range(s) and the PIN/PE type(s) to the AMF.

[0152] At 914, the AMF may send to the PEMC/PEGW a registration accept message. The registration accept message may include the set(s) of PEIDs with a PEID range and PIN/PE type association information for the PEs. In examples, the registration accept message may indicate a PIN management policy that indicates the set(s) of PEIDs with the PEID range and PIN/PE type association information for the PEs.

[0153] At 916, the PEMC may assign PEIDs to the loT devices/PEs.

[0154] In examples, a PGA may be sent for the generation of PEID(s) at a PEMC. As shown in FIG. 10, the PEMC may be a WTRU that acts as the [0155] A PGA may be sent to the PEMC when the PEMC may be successfully registered with the CN, for example, as an alternative to sending a set of PEIDs generated at a PIN-NF in the CN (e.g., as shown in FIG. 9). The PEMC may be (e.g., presumably) equipped with a PGF. FIG. 10 is a diagram illustrating an example where a CN sends a PGA or a PGA-ID to a PEMC.

[0156] At 1002, devices (e g., non-3GPP loT devices) may connect to a PEMC/PEGW using their wireless connectivity (e.g., wireless connectivity such as WiFi, Bluetooth, etc.).

[0157] At 1004, the PEMC/PEGW (e.g., instead of requesting a set of PEIDs) may send a request for a PGA towards the CN in a registration request. The PEMC/PEGW may send additional information (e.g., similar to step 1 in FIG. 9). The registration request may include one or more of PGA requests, PEID request range(s), PGA-ID set(s), device type(s) connected, device wireless technolog(ies), PEMC type(s), etc.

[0158] In some examples, a PEMC may have been pre-configured with a set of PGAs. A (e.g., each) PGA may have identifiers that the CN understands. The PEMC may send, in the WTRU registration request, a set of PGA-IDs for the CN to agree on.

[0159] At 1006, the CN may receive the request from the PEMC/PEGW, may authenticate the PEMC/PEGW and, once authorized, may trigger the PIN-NF (e.g., acting as a PMF) to send PGA(s) (e.g., PGA ID(s)).

[0160] In some examples, if the CN may receive a set of PGA-IDs with a request to agree on one or more PGAs, the CN may examine one or more of the PGAs the CN supports, WTRU subscription(s), or other information and, may decide and select one or more PGAs that the PEMC may use to generate PEIDs.

[0161] At 1008, a PIN-NF (e.g., acting as a PMF) may request and receive PGA(s) (e.g., PGA ID(s)) from a PIN server (e.g., a third-party manager service provider). In examples, if the PIN-NF already holds one or more third party PGAs, the PIN-NF may send an authorization request, including a PGA-ID, and/or may receive a response from the PIN server to send a PGA to the PEMC/PEGW

[0162] At 1010, once the PIN-NF receives a trigger, the PIN-NF may send, to the AMF, PGA(s) for the PEMC. In some examples, the PIN-NF may send PGA-ID(s) for the PGA(s) the CN has agreed for the PEMC to use.

[0163] At 1012, the CN (e.g., an AMF) may send the PGA(s) (e.g., the PGA-ID(s)) to the PEMC/PEGW in the registration accept message and/or may receive an acknowledgment.

[0164] At 1014, the PGF in the PEMC/PEGW may implement the PGA received from the CN, or the PEMC/PEGW may select the PGA from its repository that the CN has agreed with the PEMC/PEGW. The PEMC/PEGW may use inputs (e.g., one-time inputs) such as one or more of date(s), time(s), random number(s), loT device type(s), PE/PIN type(s), PEMC type(s), etc., and generate set(s) of PEIDs.

[0165] At 1016, the PEMC may assign PEIDs to the loT devices/PEs.

[0166] Although features and elements described above are described in particular combinations, each feature or element may be used alone without the other features and elements of the preferred embodiments, or in various combinations with or without other features and elements.

[0167] Although the implementations described herein may consider 3GPP specific protocols, it is understood that the implementations described herein are not restricted to this scenario and may be applicable to other wireless systems. For example, although the solutions described herein consider LTE, LTE-A, New Radio (NR) or 5G specific protocols, it is understood that the solutions described herein are not restricted to this scenario and are applicable to other wireless systems as well.

[0168] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or computer-readable storage media. Examples of computer- readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as compact disc (CD)-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and/or any host computer.