PIN configuration, management, and application service discovery
The PIN management system addresses IoT device challenges by enabling efficient discovery and management of application servers, optimizing network resource utilization and service accessibility.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- INTERDIGITAL PATENT HOLDINGS INC
- Filing Date
- 2025-12-22
- Publication Date
- 2026-05-19
AI Technical Summary
Existing IoT devices face challenges in efficiently discovering and managing application servers within local and non-local networks, leading to suboptimal utilization of resources and services.
A system and method for managing Personal Internet of Things (IoT) networks (PINs) that involve a WTRU determining local and non-local application servers based on criteria, updating network configurations, and facilitating communication between client devices and application servers using a PIN configuration server and manager.
Enhances the efficiency of IoT device service discovery and management, optimizing resource utilization and service accessibility within local and non-local networks.
Smart Images

Figure 2026082805000001_ABST
Abstract
Description
Technical Field
[0001] Cross - reference to Related Applications This application claims the priority of U.S. Provisional Patent Application No. 63 / 324,493, filed in the United States on March 28, 2022, the entire contents of each of which are incorporated herein by reference.
Background Art
[0002] The Internet is a global system of interconnected computers and computer networks that adopt standard Internet protocol suites (e.g., Transmission Control Protocol (TCP) and Internet Protocol (IP)) to communicate with each other. The Internet of Things (IoT) is based on the concept that, aside from computers and computer networks, everyday objects can be readable, recognizable, locatable, addressable, and controllable via an IoT communication network.
[0003] Some market trends are driving the development of IoT devices. For example, the increasing energy costs have led to strategic government investments in supporting future - type consumption such as smart grids, as well as electric vehicles and public charging stations. The increasing medical costs and the aging population have promoted the development of remote / connected healthcare and fitness services. Technological innovations in the home have driven the development of new "smart" services, including the integration by service providers to market "N" play (e.g., data, voice, video, security, energy management, etc.) and expand home networks. Buildings are becoming smarter and more convenient to reduce the operating costs of corporate facilities.
[0004] The Internet of Things (IoT) plays a crucial role in several applications. For example, in the field of smart grids and energy management, utility companies can optimize energy supply to homes and businesses, and customers can better monitor their energy usage. In the field of home automation and building automation, smart homes and smart buildings can provide centralized control over virtually any device or system within a home or office, from household appliances to plug-in electric vehicle (PEV) security systems. In the field of asset tracking, businesses, hospitals, factories, and other large organizations can accurately track the location of expensive equipment, patients, vehicles, and more. Finally, in the field of health and wellness, people can track the progress of their fitness routines, and doctors can remotely monitor the health of their patients. [Overview of the project]
[0005] The WTRU may receive a first message from a local client device within the local network. The local network may include a personal IoT network (PIN). The first message may include one or more criteria associated with an application server. The first message may include information associated with a registration request. The information associated with a registration request may include one or more of the following: a personal IoT network (PIN) application server (PAS) name, a uniform resource locator (URL), a PIN element identifier (PE-ID), or capability information. One or more criteria may include one or more of the following: a PIN application server (PAS) name, a PIN element identifier (PE-ID), location information, provider information, or capability information. The WTRU may determine whether any local application server within the local network meets one or more criteria. If one or more local application servers meet one or more criteria, the WTRU may send a second message to the local client device. One or more local application servers may include a PIN Application Server (PAS) within the PIN. The second message may contain information for accessing one or more local application servers within the local network. If a local application server within the local network does not meet one or more criteria, the WTRU may send a third message to the central application management server. The third message may contain one or more criteria.
[0006] If a local application server within the local network does not meet one or more criteria, the WTRU may receive a fourth message from the central application management server indicating one or more non-local application servers that meet one or more criteria. These one or more non-local application servers may be located outside of the PIN. The WTRU may be configured as the local PIN application manager (LPAM) for the PIN. If a local application server within the local network does not meet one or more criteria, the WTRU may send a fifth message to the local client device. This fifth message to the local client device may contain information for accessing one or more non-local application servers.
[0007] The WTRU may accept a registration request. The WTRU may send an update message to the central application management server. The update message may contain information associated with the registration request. Upon acceptance of the registration request, the WTRU may send a registration acceptance message to the local client device. Upon acceptance of the registration request, the WTRU may update the network. The update may indicate one or more Domain Name System (DNS) rules or classifier information associated with routing traffic to one or more local application servers. Information for accessing one or more local or non-local application servers may include one or more Personal Internet of Things (IoT) Network (PIN) Application Server (PAS) Uniform Resource Locators (URLs) or PAS capabilities.
[0008] A WTRU may send a message to a Personal Internet of Things (IoT) network (PIN) configuration server (PCS) containing information associated with the creation of a PIN. A PIN may be associated with one or more local application servers. A WTRU may receive a message from the PCS containing a PIN identifier (PIN ID) and / or PIN element identifier (PE-ID). A WTRU may send a message to a PIN configuration manager (PCM) requesting the creation of a PIN. Messages to the PCM may contain one or more of the following: PIN ID, PE-ID, PIN type, and authorization information. In response to the WTRU sending a message to the PCS requesting available PINs, a WTRU may receive a message containing a PIN ID and one or more supported application services. [Brief explanation of the drawing]
[0009] [Figure 1A] This is a system diagram illustrating an exemplary communication system in which one or more disclosed embodiments are implemented. [Figure 1B] This figure illustrates an exemplary wireless transmit / receive unit (WTRU) used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This figure illustrates an exemplary radio access network (rRAN) and core network (CN) used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1D] This is a system diagram illustrating further exemplary RAN and CN used in the communication system of Figure 1A according to one embodiment. [Figure 2] This system diagram illustrates an example of a personal Internet of Things (IoT) network (PIN) in a home automation environment. [Figure 3]This is a system diagram illustrating an example of a Personal Internet of Things (IoT) network (PIN) in an environment with one or more wearable devices. [Figure 4] This is an architecture diagram illustrating an example of a PIN architecture. [Figure 5] This is a process diagram illustrating an exemplary discovery mode for providing Proximity Services (ProSe) discovery. [Figure 6] This process diagram illustrates an exemplary discovery mode for providing proximity service (ProSe) discovery. [Figure 7] This diagram illustrates an example of a PIN application function. [Figure 8] This is a flowchart illustrating an example process for creating a PIN. [Figure 9] This is a flowchart illustrating an example process for PIN discovery. [Figure 10] This is a flowchart illustrating an exemplary process for joining PIN. [Figure 11] This is a flowchart illustrating an exemplary process for initiating a PIN. [Figure 12] This diagram illustrates an exemplary PIN application client (PAC) and an exemplary PIN application server (PAS). [Figure 13] This is an illustrative diagram illustrating a PIN Element with Management Capability (PEMC), a PIN Application Client (PAC), a PIN Application Server (PAS), a PIN Configuration Manager (PCM), a Local PIN Application Manager (LPAM), a PIN Client (PC), and a Central PIN Application Manager (CPAM). [Figure 14] This diagram illustrates an exemplary PAS registry and an exemplary discovery procedure. [Figure 15] This diagram illustrates the architecture of the PIN application framework. [Modes for carrying out the invention]
[0010] Figure 1A illustrates an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, message transmission, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may use 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 filtering OFDM, and filter bank multicarrier (FBMC).
[0011] As shown in Figure 1A, the communication system 100 may include radio transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a radio environment. For example, WTRU102a, 102b, 102c, 102d, all of which may be referred to as “station” and / or “STA”, may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed subscriber units or mobile subscriber units, subscriber-based units, radio paging, mobile phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, radio sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., for remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in industrial and / or automated processing chain contexts), consumer electronics devices, devices operating on commercial radio networks and / or industrial radio networks, etc. WTRU102a, 102b, 102c, and 102d can all be referred to as WTRU for compatibility purposes.
[0012] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base station transceivers (BTS), node B, enode B, home node B, home enode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each illustrated as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.
[0013] Base station 114a may be part of RAN 104 / 113 and may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be authorized spectrum, unlicensed spectrum, or a combination of authorized and unlicensed spectrum. The cell may provide wireless service coverage to a specific geographic area that may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.
[0014] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 may be established using any suitable radio access technology (RAT).
[0015] More specifically, as described above, the communication system 100 can be a multiple access system, and can use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).
[0016] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish the air interface 116.
[0017] In one embodiment, the base station 114a, and the WTRUs 102a, 102b, 102c may implement radio technologies such as NR radio access, which can use New Radio (NR) technology to establish the air interface 116.
[0018] In one embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may feature multiple types of radio access technologies and / or transmissions to and from multiple types of base stations (e.g., eNB and gNB).
[0019] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wireless Fidelity, WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access, WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).
[0020] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114b and WTRU 102c, 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base stations 114b and WTRUs 102c, 102d may establish picocells or femtocells using cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.
[0021] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calls, internet connectivity, video distribution, etc., and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs using the same RAT as RAN104 / 113 or a different RAT. For example, in addition to being connected to RAN104 / 113 which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0022] CN106 / 115 may also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use common communication protocols such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the Internet protocol (IP) of the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN104 / 113 or a different RAT.
[0023] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode functionality (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114b, which may employ IEEE 802 radio technology.
[0024] Figure 1B is a system diagram illustrating an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment.
[0025] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Figure 1B illustrates the processor 118 and the transceiver 120 as separate components, but it will be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.
[0026] The transmit / receive element 122 may be configured to transmit or receive signals to and from a base station (e.g., base station 114a) via 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 one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.
[0027] Although the transmit / receive element 122 is depicted as a single element in Figure 1B, 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 sending and receiving radio signals via the air interface 116.
[0028] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. As described above, the WTRU 102 may have multimode capabilities. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.
[0029] The processor 118 of the WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit) and may receive user input from these. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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 memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.
[0030] The processor 118 may be configured to receive power from the power supply 134 and distribute and / or control power to other components in the WTRU 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, etc.
[0031] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or instead of, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method while maintaining consistency with one embodiment.
[0032] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. The peripheral device 138 may include one or more sensors, one or more of which may be a gyroscope, accelerometer, Hall effect sensor, magnetometer, compass sensor, proximity sensor, temperature sensor, time sensor, geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, and / or humidity sensor.
[0033] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of the signals associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., chokes) or signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In one embodiment, WRTU102 may include a half-duplex radio for the transmission and reception of any of the signals (e.g., associated with specific subframes for either UL (e.g., for transmission) or downlink (e.g., for reception)).
[0034] Figure 1C is a system diagram illustrating RAN104 and CN106 according to one embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.
[0035] RAN104 may include e-nodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of e-nodes B while maintaining consistency with one embodiment. Each of e-nodes B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, e-nodes B160a, 160b, and 160c may implement MIMO technology. Thus, e-node B160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU102a.
[0036] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.
[0037] The CN106 shown in Figure 1C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. Although each of the aforementioned elements is illustrated as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0038] The MME162 can be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may perform roles such as authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.
[0039] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.
[0040] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.
[0041] CN106 can facilitate communication with other networks. For example, CN106 can provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. In addition, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0042] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in certain representative embodiments, such a terminal is intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).
[0043] In a typical embodiment, the other network 112 may be a WLAN.
[0044] A WLAN in Infrastructure Basic Service Set (BSS) mode may have access points (APs) of the BSS and one or more stations (STAs) associated with the APs. APs may have access to or interfaces with other types of wired / wireless networks that carry traffic entering and / or leaving the Distribution System (DS) or BSS. Traffic originating outside the BSS and destined for the STAs may reach and be delivered to the STAs via the APs. Traffic originating from the STAs for destinations outside the BSS may be sent to the APs for delivery to their respective destinations. Traffic between STAs within the BSS may be transmitted, for example, through the APs; a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be transmitted between a source STA and a destination STA (for example, directly between them) using a direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have APs, and STAs within or using IBSS (e.g., all STAs) may communicate directly with one another. The IBSS mode of communication may be referred to herein as “ad hoc” communication mode.
[0045] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS, but may be used by an STA to establish a connection with the AP. In certain typical embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, an STA, including the AP (e.g., all STAs), may sense the primary channel. If the primary channel is detected / discovered and / or determined to be busy by a particular STA, that STA may be backed off. A single STA (e.g., only one station) may transmit at any given time in a given BSS.
[0046] High-throughput (HT) STAs may use a 40 MHz wide channel for communication, which may be formed, for example, through a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels.
[0047] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining multiple consecutive 20 MHz channels. 160 MHz channels can be formed by combining eight consecutive 20 MHz channels, or by combining two non-consecutive 80 MHz channels, which may be referred to as an 80+80 configuration. In the 80+80 configuration, after channel coding, data can pass through a segment parser that can split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately for each stream. The streams may be mapped to two 80 MHz channels, and data can be transmitted by a transmitting STA. In a receiving STA, the operation described above for an 80+80 configuration may be reversed, and the combined data may be sent to Medium Access Control (MAC).
[0048] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, while 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to a typical embodiment, 802.11ah may support meter-type control / machine-type communications, such as MTC devices within a macro communication range area. MTC devices may have limited capabilities, including support for certain capabilities, e.g., support for certain and / or limited bandwidths (e.g., support for these only). MTC devices may include batteries with battery life exceeding a threshold (e.g., to maintain very long battery life).
[0049] A WLAN system capable of supporting multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes a channel that can be designated as the primary channel. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel may be 1 MHz wide for an STA (e.g., an MTC type device) that supports (e.g., only) the 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. For example, if the primary channel is operational due to an STA (which only supports 1MHz operating mode) transmitting to the AP, the majority of the frequency band may remain idle, and even if it could be available, the entire available frequency band may be considered operational.
[0050] In the United States, the available frequency band that can be used by 802.11ah is 902MHz to 928MHz. In South Korea, the available frequency band is 917.5MHz to 923.5MHz. In Japan, the available frequency band is 916.5MHz to 927.5MHz. The total bandwidth available for 802.11ah is 6MHz to 26MHz, depending on the country code.
[0051] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can communicate with WTRU102a, 102b, and 102c via air interface 116 using NR radio technology. RAN113 can also communicate with CN115.
[0052] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c may implement MIMO technology. For example, gNB180a and 108b may use beamforming to transmit signals to and / or receive signals from gNB180a, 180b, and 180c. Thus, gNB180a may, for example, use multiple antennas to transmit and / or receive radio signals to and from WTRU102a. In one embodiment, gNB180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unauthorized spectrum, while the remaining component carriers may be on the authorized spectrum. In one embodiment, gNB180a, 180b, and 180c may implement coordinated multi-point (CoMP) technology. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).
[0053] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable neurology. For example, OFDM symbol intervals and / or OFDM subcarrier intervals may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may also communicate with gNB180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or having varying absolute time durations).
[0054] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unauthorized bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with and connect to gNB180a, 180b, and 180c, while also communicating with and connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement DC principles for substantially simultaneous communication with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, e-nodes B160a, 160b, and 160c can function as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.
[0055] Each of the gNB180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, support for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a and 182b, and so on. As shown in Figure 1D, the gNB180a, 180b, and 180c can communicate with each other via the Xn interface.
[0056] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although each of the aforementioned elements is illustrated as part of the CN115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0057] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and may function as control nodes. For example, AMF182a and 182b may perform roles such as user authentication for WTRU102a, 102b, and 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a and 183b, management of registration areas, termination of NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of service utilizing WTRU102a, 102b, and 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, and services for machine type communication (MTC) access. AMF162 may provide control plane functions for exchange between RAN113 and other RANs (not shown) using other radio technologies such as LTE, LTE-A, LTE-A Pro and / or WiFi.
[0058] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b may select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b may perform other functions such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet-based, etc.
[0059] UPF184a, 184b may be connected via the N3 interface to one or more gNB180a, 180b, 180c in RAN113, thereby providing WTRU102a, 102b, 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multiple home PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.
[0060] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between CN115 and PSTN108. In addition, CN115 can provide WTRU102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a, 102b, 102c may be connected to DN185a, 185b via UPF184a, 184b through an N3 interface to UPF184a, 184b, and an N6 interface between UPF184a, 184b and local data networks (DNs) 185a, 185b.
[0061] In view of Figures 1A to 1D and their corresponding descriptions, one or more of the functions described herein may be implemented by one or more emulation devices (not shown) with respect to one or more of the WTRU102a to d, base stations 114a and b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a and b, SMF183a and b, DN185a and b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.
[0062] Emulation devices may be designed to perform one or more tests on other devices in a laboratory and / or carrier network environment. For example, one or more emulation devices may perform one or more or all of the functions while fully or partially implemented and / or deployed as part of a wired and / or wireless network to test other devices in a communications network. One or more emulation devices may perform one or more or all of the functions while temporarily implemented / deployed as part of a wired and / or wireless network. Emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial wireless communication.
[0063] One or more emulation devices may perform one or more functions, including all of the above, while not implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test laboratory test scenario, and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing purposes), to perform testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation device to transmit and / or receive data.
[0064] Internet of Things (IoT) functionality is designed for devices that communicate using conventional cellular networks. Devices with IoT capabilities may require improved power consumption performance and increased network efficiency for bulk operation.
[0065] Figure 2 is an illustrative diagram of a personal Internet of Things (IoT) network (PIN) 200 in a home automation environment. When multiple IoT devices 210 are deployed in a private environment, IoT-capable WTRUs 220 can be organized in a personal IoT network (PIN). For example, in a home environment, security sensors, smart lights, smart plugs, printers, mobile phones, etc., are managed by a residential gateway and communicate with each other. One or more devices 210 in the home can make up a PIN. Each of the devices 210 is called a PIN element or PIN device. In one example, different PIN elements may have different capabilities. For one example, a residential gateway may be a PIN element (PIN GW) 230 with gateway capabilities that provide connectivity between PIN elements and connectivity between the 5G network and the PIN elements. A PIN element with management capabilities (PIN Mgmt) may be a PIN element that provides a means for an authorized administrator to configure and manage PINs. For one example, a residential gateway operating as a PIN GW 230 may support PIN management functions and / or also operate as a PIN Mgmt. One or more PIN devices or PIN elements may be implemented in the WTRU. The terms PIN device, PIN element, WTRU, PIN client, and / or similar terms may be used interchangeably in this specification.
[0066] Figure 3 is an illustrative diagram of a PIN in a wearable device environment. A wearable device can create a certain type of PIN, for example, a wearable PINa 300a or a wearable PINb 300b. For example, a smartphone can act as a PIN GW and PIN Mgmt. A smartwatch 330a or 330b, VR / AR glasses 320a or 320b, and / or AirPods 310a or 310b can communicate with other WTRUs 340a or 340b, for example, via a PIN and / or a 5G network 350.
[0067] Figure 4 shows an example of an exemplary PIN network architecture 400. A PIN may include one or more of the following: PIN Element (PE) 410, PIN Management (PIN Mgmt) 420, and / or PIN Gateway (PIN GW) 430. A PIN Element may be a WTRU, or one of several different non-3GPP devices capable of communicating within the PIN. A PIN Management device may be a PIN Element capable of managing the PIN. A PIN GW may be a PIN Element capable of providing connectivity to and from the 5G network for one or more other PIN Elements.
[0068] PIN elements 410 can communicate with each other through several means, such as through the PIN GW 430. PIN elements can also communicate with each other directly. In addition, PIN elements can communicate with the 5G system to obtain 5G services. PIN elements can also communicate with the data network 450 via the 5G core network 440. One or more PIN elements with management capabilities can be a WTRU. One or more PIN elements with gateway capabilities can be a WTRU. Communication within the PIN can be performed using one or more of several non-3GPP communication methods, such as WiFi and Bluetooth.
[0069] In one exemplary embodiment, the disclosure relates to a wireless transceiver unit (WTRU) comprising a processor and memory, configured to participate in, manage, or otherwise support a personal IoT network (PIN). A PIN may be a network of devices that communicate to access one or more shared services or applications. For example, a PIN may be formed in a home environment to support smart home type applications and may include various devices such as security systems, smart lights, smart plugs, home assistants, and mobile phones. PIN devices may receive connections through one or more common gateways.
[0070] In one example, one or more PIN devices may be implemented in a WTRU. The WTRU may be configured to transmit identification information to a Personal Things Internet Network (PIN) Configuration Server (PCS). In an exemplary embodiment, the WTRU receives configuration and authorization information from the PCS and transmits information based on the identification, configuration, and / or authorization information to a PIN Configuration Manager (PCM).
[0071] In one example of this disclosure, the WTRU receives Personal Internet of Things (PIN) information from the PCM and initiates a PIN-related control procedure based on configuration information, authorization information, and / or PIN information.
[0072] One or more devices may be involved in and / or provide support for PIN management functions for client devices. For example, a PCS may communicate with a PIN client (PC) located in a WTRU. A PIN Gateway Manager (PGM) may provide a connection to one or more application servers that provide services and applications to support PIN operations. For example, a PC (e.g., in a WTRU) may obtain configuration and authorization information from the PCS to create or join a PIN. The PC may work with the PCM to initiate, join, create, or otherwise manage PINs.
[0073] One or more devices within a PIN may be configured to facilitate the discovery of the application server for the PIN. For example, a local registry may be maintained by a PIN device such as a Local PIN Application Manager (LPAM). The LPAM may be embedded in a PCS, and / or the PCS may communicate with a device implementing the LPAM. A PIN device may communicate with a device outside the PIN to receive information related to a global registry of PIN applications (e.g., a larger and / or more robust list). The global registry may be maintained by a Central PIN Application Manager. In one example, a PC (e.g., in a WTRU) may retrieve information maintained by the LPAM from the PCS. For example, registration and inquiry messages, which can be triggered by a user, may be sent by the PC to the LPAM. If the LPAM / PCS cannot obtain the information necessary to respond to the registration and inquiry messages, the LPAM / PCS may query the CPAM to obtain the information and provide it to the PC.
[0074] Figure 5 shows an exemplary proximity service (ProSe) direct discovery mode 500. ProSe may include services that can be provided (e.g., by a 3GPP system) based on the relative location of one WTRU 510 to one or more other WTRUs 520a, 520b, 520c, 520d, etc. To provide ProSe, a WTRU may perform a ProSe discovery procedure to discover one or more other WTRUs in its vicinity (e.g., WTRU 520a, 520b, 520c, and / or 520d, etc.). WTRU 510 (e.g., announcing WTRU) may broadcast one or more announcement messages 530 having a ProSe code. The ProSe code may be associated with the ID of the announcing WTRU and / or with the services provided by the announcing WTRU 510. One or more other WTRUs receiving the notification message (e.g., WTRU520a, 520b, 520c, 520d, etc.) (e.g., monitoring WTRUs) may determine that they are within a reasonably close range to the notification WTRU510.
[0075] Figure 6 shows an exemplary ProSe direct discovery mode 600. A WTRU 610 (e.g., a discovering WTRU) may broadcast one or more solicitation messages 630 using a ProSe query code that may be associated with the ID of WTRU 610. For example, the ID of a WTRU may be associated with a ProSe service that can be discovered or should be discovered. One or more other WTRUs receiving the solicitation messages (e.g., discovered WTRUs 620a, 620b, 620c, 620d, etc.) may respond to the request with a ProSe response code. For example, one or more of the discovered WTRUs 620a, 620b, 620c, 620d may send a response message 640 having a ProSe response code in response to one or more solicitation messages 630. The ProSe response code may be associated with the ID of the discovered WTRU and / or with a ProSe service. The ProSe service may be provided by the discovered WTRU (e.g., the discovered WTRU 620a, 620b, 620c, or 620d). The discovering WTRU 610 may determine that it is in a specific proximity to the discovered WTRU (e.g., the discovered WTRU 620a, 620b, 620c, or 620d).
[0076] Discovery mode can be used to perform group discovery. An example of group discovery is the discovery of one or more WTRUs that may belong to a particular group. Discovery mode can also be used to perform WTRU-to-network relay discovery. An example of WTRU-to-network relay discovery is the discovery of WTRU-to-network relays that can provide connectivity to a 5G network.
[0077] In the case of group discovery, the discovery message (e.g., notification message, request message 630, and / or response messages 640, 650, etc.) may include the group ID. In the case of WTRU-to-Network Relay discovery, the discovery message may use a relay service code instead of a ProSe code to indicate the WTRU-to-Network Relay service.
[0078] A PIN network may be managed by an MNO (Mobile Network Operator) to support application services (e.g., gaming and remote health) provided by one or more managed service providers. Users (e.g., at home, in a business, or any location) may set up a PIN to operate the application services.
[0079] An application service provider may supply one or more PIN elements, and a user may purchase these PIN elements. Each PIN element may be a 3GPP device or a non-3GPP device. For example, a PIN element may receive configuration information through an application-level information exchange mechanism before becoming part of a PIN and / or before being managed by an MNO. A PIN element may be a non-3GPP device that can use, for example, BT, WiFi technology, and / or other similar technologies.
[0080] A PIN can support a variety of application services. An exemplary way in which a PIN supports a variety of application services is for various application clients and / or application servers to operate on one or more PIN elements. PINs can exist in a distributed and diverse environment, and may or may not rely entirely on network-level methods to discover and connect to application servers. PEs may need to determine application-level configurations that can be used for PIN management functions, such as creating, discovering, joining, and / or initiating PINs. For example, if a PE wants to create a PIN where one does not already exist, the application-level configuration for creation may need to be determined. Similarly, if a PE wants to discover whether a PIN already exists in a location and what application services it provides application-level configurations for discovery, this may need to be determined. For example, if a PE wants to join an existing PIN, the application-level configuration for joining may need to be determined. An application-level configuration for initiation may need to determine, for example, when a PIN should be initiated, which may occur, for example, when a PIN has been created but is not yet operational. A PE may, for example, choose to make a PIN operational at a specific point in time. In certain situations, such as registering an application server or entering queries to an application server, it may be desirable to determine means to facilitate application server discovery using application-level mechanisms. It may be desirable for the application framework to determine the architectural requirements for supporting PIN activities, such as activities related to PIN management and application server discovery. Solutions for PIN management may involve employing application functions PCS (PIN Configuration Server), PC (PIN Client), PCM (PIN Configuration Management), and / or PGM (PIN Gateway Manager). One solution for PIN management may be for the PC to obtain configuration and authorization information from the PCS, create a PIN, and participate in it. Another solution for PIN management may be for the PC to initiate, participate in, or create a PIN in cooperation with the PCM.Solutions to PIN application server discovery may include a local registry LPAM (Local PIN Application Manager) and a global registry CPAM (Central PIN Application Manager). Another solution may involve the PC obtaining LPAM information from the PCS (Personal Computer System). Furthermore, user-triggered registration and inquiry messages may be sent to the LPAM by the PC. Finally, if information is not found within the LPAM, it may be retrieved from the CPAM.
[0081] Figure 7 is an illustrative diagram illustrating PIN application functionality. For example, a PIN configuration server (PCS) 710 may be an application function that facilitates PIN management procedures. The PCS 710 may be a central entity that may have knowledge of one or more PINs in the network. A PIN client (PC) 720 may be an example of an application function that facilitates PIN management procedures. The PC 720 may be a client within a PIN element that can obtain information from the PCS to enable PIN management operations. A PIN configuration manager (PCM) 730 may be an example of an application function that facilitates PIN management procedures. The PCM 730 may be an application function associated with a PIN element that has management capabilities. The PCM 730 may locally track the PIN management of PINs. A PIN gateway manager (PGM) 740 may be an example of an application function that facilitates the existence of PIN management procedures. The PGM 740 may be an application function within a PE with gateway capabilities. The PCS 710 may, for example, maintain information about one or more PINs across an MNO network. PCS710 may maintain information including authorization and policy-related information regarding PEs, such as whether PEs are permitted to create PINs, participate in PINs, and are permitted for specific application services. PCS710 may maintain information about the ID assigned to the PE and / or authorize the PE to participate in a PIN. PCS710 may maintain information about available PINs, their PIN IDs at specific locations, and / or authorized application services. PCS710 may maintain information about PCM730 for each PIN, and information about how to reach PCM730 for a specific PIN ID. PC720 may be a function within the PE and may be supplied with PCS710 information. PC720 may provide the ability to retrieve information about available PINs, PIN IDs, available services, and / or PCM730 information about PINs from PCS710. PC720 may provide the ability to retrieve the application-level PE-ID from PCS710 in order to participate in or create a PIN. In addition, PC720 may provide the ability to assist the PE in executing and / or creating PINs, and / or participating in PINs with PCS710 and PCM730. PCM730 may be a local PIN management function and may be part of PEMC. The PCM730 can maintain local PIN information such as PIN ID, available PEs and PE-IDs, PEs that participated in the PIN, authorization information, and policy information. The PCM730 can also verify, update, and / or synchronize information about local PINs with the PCS. The PGM740 may be a function that may be available with a gateway-enabled PE. The PGM740 can obtain and implement gateway configurations from the PCM730 and / or PCS710. A PIN may not exist in a position where a user might want to initiate a PIN for a particular application service. In an exemplary scenario, a user might want to own a PE and use that PE to create a PIN. The PE owned by the user may be a WTRU with PEMC capabilities (e.g., a 3GPP WTRU). The PE owned by the user may also be a non-3GPP device without PEMC capabilities.
[0082] Figure 8 illustrates an exemplary process 800 for creating a PIN, which results in the creation of a PIN. In 810, the PIN client (PC) may indicate to the PCS its intention and / or ability to create a PIN by providing information such as, for example, a user ID, a device ID, location information, whether the PE is PEMC compliant, desired application services on the PIN, and / or other types of similar or related information. In 812, the PCS may authenticate and authorize the user and create a PIN ID and / or PE-ID. The PCS may determine suitable PCM functions based on the capabilities of the PE. In 814, the PCS may respond by providing the device's PIN-ID and / or PE-ID. The PCS may also include PCM information in its response. In 816, after obtaining information from the PCS, the PC may send a creation request to the PCM along with information such as, for example, a PIN ID, PE-ID, PIN type, and / or authorization information. In 818, the PCM may verify the newly created PIN ID with the PCS. The PCM may obtain information from the PCS regarding which PEs may be required to support the application service. In 818, the PCM may send a query message to the PCS that may include a PIN ID. The PCS may return one or more PE IDs that can be used to create a PIN and support the desired service. In 820, the PCM may determine whether the required PE is available and permitted to join. For example, if the PCM determines in 820 that the required PE is available and permitted to join, the PCM may determine that it can create a PIN and notify the PC of the success of the PIN creation. For example, if the PCM determines in 820 that the PE is not available and / or not permitted to join, the PCM may send an instruction such as an error or PIN creation failure. The PCM may also update the PCS for one or more PE-IDs that are available to join or have already joined. In 822, the PCM may send a configuration update message to the PGM, which may include information such as a PIN ID, one or more PE-IDs, and / or one or more authorized QoS. In 824, the PCM may update the 3GPP network using PIN creation details.
[0083] Figure 9 illustrates an exemplary process 900 for PIN discovery. For example, a user with a PE may participate in the PIN to use an application service. The user may discover whether a PIN is available at a specific location where the desired application service is provided. The PE (Primary Equipment) may or may not be a 3GPP device. The PE may or may not perform network-level discovery. Application-level service discovery can enable a uniform discovery method for 3GPP and / or non-3GPP PEs. PC910 may query PCS920 for available PINs having location information and / or PLMN information. For example, PC910 may send a query message to PCS920 in 912. The query message may contain location information and / or PLMN information. PCS920 may check its database to determine available PINs at a particular location. PCS920 may respond to PC910 with a list of available PINs at a particular location by sending, for example, a PIN ID and supported application services in 922. PC910 may select the PINs it wishes to participate in to use a particular application service.
[0084] Figure 10 illustrates an example of step 1000 included in PIN participation. After the PIN is discovered by the PE, the next step may be to participate in the PIN. Once the PE determines which PIN to participate in, the PE may obtain authorization from the PCS to participate in the PIN. For example, in 1010, the PC may send a participation request by sending information including the PIN ID, user ID, and / or PIN type of the PIN it wishes to participate in. In 1012, the PCS may authenticate and / or approve the participation request sent by the PC based on the user ID and / or PIN type. If the PCS determines that the participation request is permitted, the PCS may respond in 1012 by sending a message to the PC, for example, OK, which may include information such as the PE-ID assigned to the PE by the PCS, PCM information, local PCM for PIN management, and / or authorization information for the local PIN. In 1014, the PC may contact the PCM and notify it of its intention to participate in the PIN. For example, in 1014, the PC may transmit certain information to the PCM, such as a PIN ID that may have been previously discovered and approved by the PCS, its own PE-ID, PIN type, and / or approval information. The PCM may verify whether the PE's participation can be supported, and may do so by considering conditions including the current state of the application service, available QoS, and / or other available PEs. The PCM may also contact the PCS to verify the PE ID and / or whether the PE is permitted to participate. In 1016, if the PE is permitted and may be supported to participate, the PCM may respond by transmitting an approval instruction to the PC, along with an instruction on the outcome of the request. Examples of instructions on the outcome of the request may be permitted, prohibited, not supported, or another outcome. In 1018, the PCM may update the PCS with updated PIN information indicating a new PE that has joined the PIN. In 1020, the PCM may transmit a configuration update message to the PGM, which may include information such as a PIN ID, one or more PE-IDs, and / or one or more permitted QoS.In 1022, the PCM may update the 3GPP network with PIN participation details. PIN participation details may include, for example, recreation, update operations, and / or other information.
[0085] Figure 11 is a flowchart illustrating an exemplary process 1100 for initiating a PIN. After creating or joining a PIN, the user may initiate the PIN. Creating or joining a PIN may set the PIN to one or more available PEs, PEMCs, and / or PEGWs. In one example, PIN initiation may make the PIN operational when one or more time-based PEs are operational and available. The user may initiate the PIN by sending a trigger to the PC. In 1110, PEs with or without PEMC capability may trigger PIN initiation. The initiation trigger may originate from the PC and be sent to the PCM. At 1110, the PC may send a start trigger indicating the PIN ID and set the start instruction to true. At 1112, the PCM may send the PIN IDs and / or one or more PE-IDs of the PEs participating in the PIN to the PCS along with the start request. At 1114, the PCS verifies the PIN ID, one or more PE-IDs, and / or timer values. At 1114, the PCS may send an OK instruction. At 1116, the PCM may send a configuration update to the PGM function and set the state from start to true. At 1118, the PCM may send an OK instruction to the PC requesting the start. The PCM may also trigger other PEs to enter the start state by sending an OK instruction (e.g., 200OK (start==true)) to one or more other PEs. At 1120 and 1122, the PCS may send a start instruction to the 3GPP network to start the PIN. The PCM may send a start instruction to the 3GPP network, for example, at 1122. The PCS may, for example, in 1120, send a start instruction to the 3GPP network.
[0086] Figure 12 illustrates an exemplary PIN application client (PAC) 1210 and an exemplary PIN application server (PAS) 1220. PE 1230 or 1260 may provide services through the PIN application server (PAS) 1220. PAC 1210 may consume one or more services from one or more other PASs (e.g., PAS 1250). PAC 1210 may discover and / or connect to other PAS 1250s to consume one or more services. PAS 1220 may register PAC 1210 and make it discoverable to one or more other PACs (e.g., PAC 1240). Discovery and consumption of PAS 1220 and 1250 may occur locally within the PIN. Discovery and consumption of PAS 1220 and 1250 may occur outside the PIN, such as within another PIN, within the EDN, within 5GS, on the Internet, or at any other location.
[0087] Figure 13 is an illustrative Figure 1300 illustrating a PIN element with management capabilities (PEMC) 1310, a PIN application client (PAC) 1320, a PIN application server (PAS) 1330, a PIN configuration manager (PCM) 1340, a local PIN application manager (LPAM) 1350, a PIN client (PC) 1360, and a central PIN application manager (CPAM) 1370. Service registry functionality may be made available in the context of local PINs to facilitate the discoverability of PAS 1330. A global PAS 1330 registry may be used for discovery across PINs and in the EDN. A PIN local-level service registry and management function, e.g., LPAM 1350, may reside within PEMC 1310. A local PIN application server may register services with LPAM 1350. LPAM 1350 may be hosted within PEMC 1310. CPAM 1370 may function as a global registry for PAS (e.g., PAS 1330). CPAM1370 can be deployed in core networks such as EDN (e.g., 5G CN).
[0088] Figure 14 illustrates an example of procedure 1400 involved in PIN application server (PAS) registration and discovery. A PIN client (PC) 1420 in the PE may obtain local PIN application manager (LPAM) 1440 information from the PIN configuration server (PCS) 1450 by sending a Get_lpam_info message to the PCS 1450 at 1412. The PCS 1450 may respond to the PC 1420 with LPAM 1440 information at 1414. In the exemplary PAS registration procedure, the PAS 1410 may send a registration request to the PC 1420 at 1416. Along with the registration request, the PAS 1410 may send the application server name and details on how to reach the PAS 1410 at 1416. The PC 1420 may send a registration request to the LPAM 1440 at 1418. The registration request sent at 1418 may include information such as the PAS name, URL, PE-ID, and / or PE-ID capability. LPAM1440 may accept the registration request, update the local service registry, and send an OK message to PC1420 at 1422. PC1420 may send an OK message to PAS1410 at 1424. LPAM1440 may also update CPAM at 1426 with information including the PAS name, URL, PE-ID, and / or capability. LPAM1440 and CPAM1320 may update the 3GPP network at 1428 with information including Domain Name System (DNS) rules and classifier information for appropriate routing or traffic steering to application servers. In an exemplary query procedure, the query procedure may be initiated by PAC1410 at 1432. At 1432, PAC1410 may send a query message to PC1420 that may include the PAS name and / or one or more selection criteria. The query message to PC1420 may include information such as the PAS's PE-ID, location, provider, and / or capabilities. At 1434, PC1420 may send the query message to LPAM1440, along with details such as the PAS name, PE-ID, and / or other selection criteria that may include location, capabilities, and / or provider.LPAM1440 may search its registry to determine if PAS information is available. If it is not available, LPAM1440 may query CPAM1320 with the same information at 1436. After LPAM1440 finds PAS information, LPAM may respond to PC1420 at 1438 with PAS information such as PAS URL, capabilities, and / or other PAS information. PC1420 may send the PAS information to PAC1410 at 1442. The PAS information may include, for example, a PAS URL and / or PAS capabilities.
[0089] Figure 15 is an illustrative diagram of the PIN application framework architecture 1500. The illustrative application framework is described based on the management and application server discovery procedure requirements described above. In an illustrative set of interactions for PIN management, PIN1 may connect the application client / server (PAS / PAC) (ACS) 1510 and PC 1520. PIN1 is a trigger for creating, starting, and / or discovering PINs. A user application, application client, initiates PIN creation, PIN discovery, and / or PIN starting. PIN2 may connect PC 1520 and PCS 1530. PIN2 may perform creation and / or starting. PC 1520, pre-configured with PCS information, may contact PCS 1530 to create or start a PIN, during which time PCS 1530 may assign a PEID and / or PIN ID. PCS 1530 may also provide PCM information to PC 1520. PIN2 may also perform discovery while the PC can obtain the PIN ID and / or PCM information. PIN3 can connect PC1520 and PCM1550. In the case of PIN3, after obtaining the PIN ID and PE ID from PCS, PC1520 can initiate the create, join, and / or start procedure with PCM1550, during which the create PIN, join PIN, and / or start PIN are executed. PIN5 can connect PCM1550 and PCS1530, which may enable PCM1550 to update information to PCS1530. PIN5 can execute the PIN start and / or PIN policy information acquisition process. PIN7 can connect PCM1550 and PGM1560, which may enable PCM1550 to send configuration information to PGM1560, for example, to set up one or more PIN paths. PIN7 can update the PIN ID and / or PE-ID. In an exemplary set of interactions related to PIN application service management, PIN1 can connect ACS1510 and PC1520. PIN1 can perform registration and inquiries to the PC initiated by the user application.PIN1 can perform service registration, including registration of application servers in the PE. PIN1 can also perform queries that may be initiated by application clients within the PE. PIN2 can connect PC1520 and PCS1530. PIN2 can perform LPAM information acquisition actions, during which time the PC can acquire LPAM (Local Registry) information. PIN4 can connect PC1520 and LPAM1570. PIN4 can perform service registration and service query actions. PIN6 can connect LPAM1570 and CPAM1540. PIN6 can perform update registration and query actions for services not found in LPAM1570.
Claims
1. A wireless transmit / receive unit (WTRU) comprising a processor and memory, wherein the processor The application server receives a first message containing one or more criteria associated with it from a local client device on the local network. Determine whether any of the local application servers within the local network meets one or more of the criteria. On the condition that one or more local application servers satisfy one or more of the criteria, a second message containing information for accessing one or more local application servers in the local network is sent to the local client device. Under the condition that a local application server within the local network does not meet one or more of the above criteria, A third message containing one or more of the aforementioned criteria is sent to the central application management server. A fourth message indicating one or more non-local application servers that meet one or more of the aforementioned criteria is received from the central application management server. A WTRU configured to send a fifth message to the local client device containing information for accessing one or more of the aforementioned non-local application servers.
2. The WTRU according to claim 1, wherein the local network includes a Personal Internet of Things (IoT) network (PIN), the one or more local application servers include PIN application servers (PAS) within the PIN, the one or more non-local application servers are located outside the PIN, and the WTRU is configured as a Local PIN Application Manager (LPAM) for the PIN.
3. The WTRU according to claim 1 or 2, wherein the one or more criteria include one or more of the following: PIN application server (PAS) name, PIN element identifier (PE-ID), location information, provider information, or capability information.
4. The WTRU according to any one of claims 1 to 3, wherein the first message includes information associated with a registration request.
5. The WTRU according to claim 4, wherein the information associated with the registration request includes one or more of the following: Personal Internet of Things (IoT) Network (PIN) Application Server (PAS) name, Uniform Resource Locator (URL), PIN Element Identifier (PE-ID), or Capability Information.
6. The aforementioned processor, Accepting the aforementioned registration request, The WTRU according to claim 4 or 5, further configured to send an update message containing the information associated with the registration request to the central application management server.
7. The WTRU according to claim 6, wherein the processor is further configured to send a registration acceptance message to the local client device in response to the acceptance of the registration request.
8. The WTRU according to claim 6 or 7, wherein the processor is further configured to update the network in response to acceptance of the registration request, and the update includes one or more Domain Name System (DNS) rules or classifier information associated with routing traffic to one or more local application servers.
9. The WTRU according to any one of claims 1 to 8, wherein the information for accessing one or more local application servers or non-local application servers includes one or more Personal Internet of Things (IoT) Network (PIN) Application Server (PAS) Uniform Resource Locator (URL) or PAS capabilities.
10. The aforementioned processor, A sixth message is sent to the Personal Internet of Things (IoT) Network (PIN) Configuration Server (PCS) containing information associated with creating PINs associated with one or more local application servers. A seventh message including a PIN identifier (PIN ID) and a PIN element identifier (PE-ID) is received from the PCS. Send an eighth message to the PIN Configuration Manager (PCM) requesting the creation of a PIN, the eighth message to the PCM including one or more of the following: PIN ID, PE-ID, PIN type, and authorization information. The WTRU according to claim 1, further configured to receive a ninth message in response to the eighth message, the WTRU including a PIN ID and supported application services.
11. A method performed by a wireless transmit / receive unit (WTRU), wherein the method includes receiving a first message containing one or more criteria associated with an application server from a local client device in a local network, Determining whether any of the local application servers within the local network meets one or more of the criteria, On the condition that one or more local application servers satisfy one or more of the criteria, a second message containing information for accessing one or more local application servers in the local network is sent to the local client device, Under the condition that a local application server within the local network does not meet one or more of the above criteria, Sending a third message containing one or more of the aforementioned criteria to the central application management server, Receiving a fourth message from the central application management server indicating one or more non-local application servers that meet one or more of the aforementioned criteria, A method comprising sending a fifth message to the local client device containing information for accessing one or more non-local application servers.
12. The method according to claim 11, wherein the local network includes a Personal Internet of Things (IoT) network (PIN), the one or more local application servers include PIN application servers (PAS) within the PIN, the one or more non-local application servers are located outside the PIN, and the WTRU is configured as a Local PIN Application Manager (LPAM) for the PIN.
13. The method according to claim 11 or 12, wherein the one or more criteria include one or more of the following: PIN application server (PAS) name, PIN element identifier (PE-ID), location information, provider information, or capability information.
14. The method according to any one of claims 11 to 13, wherein the first message includes information associated with a registration request.
15. The method according to claim 14, wherein the information associated with the registration request includes one or more of the following: Personal Internet of Things (IoT) network (PIN) application server (PAS) name, uniform resource locator (URL), PIN element identifier (PE-ID), or capability information.
16. Accepting the aforementioned registration request, The method according to claim 14 or 15, further comprising sending an update message containing the information associated with the registration request to the central application management server.
17. The method according to claim 16, further comprising sending a registration acceptance message to the local client device in response to the acceptance of the registration request.
18. The method according to claim 16 or 17, further comprising updating the network in response to acceptance of the registration request, wherein updating the network includes indicating one or more Domain Name System (DNS) rules or classifier information associated with routing traffic to one or more local application servers.
19. The method according to any one of claims 11 to 18, wherein the information for accessing one or more local application servers or non-local application servers includes one or more Personal Internet of Things (IoT) Network (PIN) Application Server (PAS) Uniform Resource Locators (URLs) or PAS capabilities.
20. Sending a sixth message to a Personal Internet of Things (IoT) Network (PIN) Configuration Server (PCS) containing information associated with creating PINs associated with one or more local application servers, Receiving a seventh message from the PCS that includes a PIN identifier (PIN ID) and a PIN element identifier (PE-ID), Sending an eighth message to the PIN Configuration Manager (PCM) requesting the creation of a PIN, the eighth message including one or more of the PIN ID, PE-ID, PIN type, and authorization information to the PCM, The method according to claim 11, further comprising receiving a ninth message in response to the eighth message, the ninth message including a PIN ID and a supported application service.