Service continuity associated with changing inter-PINE communication from direct mode to the use of intermediate PEGCs

Abstract

Systems and methods are described herein with respect to service continuity. Service continuity may be implemented and / or provided, for example, when (e.g., when) wireless transmit / receive unit (WTRU)-to-WTRU communications change from direct mode to using an intermediate gateway-capable WTRU. A personal internet of things network (PIN) may be used. A WTRU may be part of a PIN. A WTRU within a PIN may be referred to as a PIN element (PINE). A WTRU and / or a PINE within a PIN may be associated with different capabilities. For example, a PINE within a PIN may be a PINE with gateway capabilities (PEGC). For example, a PINE within a PIN may be a PINE with management capabilities (PEMC).

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Application No. 63 / 396,755, filed August 10, 2022, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] Mobile communications using radio communications continues to evolve. The fifth generation may be referred to as 5G. Previous (traditional) generations of mobile communications may be, for example, fourth generation (4G) long term evolution (LTE). Summary of the Invention

[0003] Systems and methods are described herein with respect to service continuity. Service continuity may be implemented and / or provided, for example, when (e.g., when) wireless transmit / receive unit (WTRU)-to-WTRU communications change from direct mode to using an intermediate gateway-capable WTRU. A personal internet of things network (PIN) may be used. A WTRU may be part of a PIN. A WTRU within a PIN may be referred to as a PIN element (PINE). A WTRU and / or a PINE within a PIN may be associated with different capabilities. For example, a PINE within a PIN may be a PINE with gateway capabilities (PEGC). For example, a PINE within a PIN may be a PINE with management capabilities (PEMC).

[0004] In an example, a PINE (e.g., a WTRU) can subscribe to a PEMC for service continuity. The PEMC may authorize a PIN service and obtain a context token (e.g., that may store a session context associated with the service). The PEMC may trigger PEGC selection within the PINE, for example, by a message (e.g., an application layer message). The PEMC may configure the selected PEGC for service continuity (e.g., for the PINE to use for service continuity). The PEMC can configure the PINE to connect to the selected PEGC for service continuity.

[0005] The WTRU may configure service continuity between entities. The WTRU may be a PEMC. The WTRU may receive a notification message. The notification message may indicate a loss of service continuity between the first PINE and the second PINE. The notification message may indicate a PINE ID and a session ID. The WTRU may send a discovery request message to the first PINE and the second PINE. The discovery message may indicate PEGC discovery. The WTRU may receive a discovery response message. The discovery response message may indicate first PEGC discovery information (e.g., from the first PINE) and second PEGC discovery information (e.g., from the second PINE). The WTRU may determine a PEGC based on the first and second PEGC discovery information. The WTRU may send a selection message to the determined PEGC for service continuity between the first PINE and the second PINE. The selection message may indicate the first PINE ID associated with the first PINE and the second PINE. The selection message may indicate a context token. The WTRU may receive a confirmation message from the determined PEGC indicating that service continuity between the first PINE and the second PINE is configured. The confirmation message may indicate a PEGC Internet Protocol (IP) address. The WTRU may, for example, send a configuration message to the first PINE and the second PINE indicating service continuity configuration information. [Brief explanation of the drawings]

[0006] [Figure 1A] FIG. 1 is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] 1B is a system diagram illustrating an exemplary wireless transmit / receive unit (WTRU) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1C]1A is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 1D] 1B is a system diagram illustrating a further exemplary RAN and a further exemplary CN that may be used within the communication system illustrated in FIG. 1A, according to one embodiment. [Figure 2] FIG. 1 illustrates an example of a Personal Internet of Things (PIN) network of home automation things. [Figure 3] FIG. 1 illustrates an exemplary wearable PIN. [Figure 4] FIG. 1 illustrates an exemplary PIN architecture. [Figure 5] FIG. 1 illustrates an exemplary PIN application architecture. [Figure 6] FIG. 1 illustrates an exemplary service continuity via a PEGC. [Figure 7] FIG. 1 illustrates an example of service continuity through two or more PEGCs. [Figure 8] FIG. 1 illustrates an exemplary procedure ALT1 for service continuity. [Figure 9] FIG. 1 illustrates an example procedure for service continuity. [Figure 10] FIG. 1 illustrates an example procedure for service continuity. DETAILED DESCRIPTION OF THE INVENTION

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

[0008] 1A, communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of 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 "STA," may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a mobile phone, 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 (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., a robot and / or other wireless device operating in an industrial and / or automated processing chain context), a consumer electronics device, a device operating on a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be referred to interchangeably as a UE.

[0009] The communications system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communications networks, such as the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node B, an eNode B (eNB), a Home Node B, a Home eNode B, a gNode B (gNB), an NR Node B, a site controller, an access point (AP), a wireless router, etc. Although 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.

[0010] 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 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 licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage for a specific geographic area, which may be relatively fixed or may change over time. A cell may be further 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 transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers per sector of the cell, for example, using beamforming to transmit and / or receive signals in desired spatial directions.

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

[0012] 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, etc. For example, the base station 114 a and the WTRUs 102 a, 102 b, 102 c in the RAN 104 / 113 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 communications protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

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

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

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

[0017] 1A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. 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 establish a picocell or a femtocell using a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.). As shown in FIG. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 through the CN 106 / 115.

[0018] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, application, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput, latency, error tolerance, reliability, data throughput, and mobility requirements. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in FIG. 1A , it will be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing 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 utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0019] 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 other networks 112. The PSTN 108 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, which 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. The network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the network 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.

[0020] 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 a base station 114a, which may employ a cellular-based wireless technology, and a base station 114b, which may employ an IEEE 802.2 wireless technology.

[0021] 1B is a system diagram illustrating an example WTRU 102. As shown in FIG. 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 source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0022] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) 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 function 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. 1B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0023] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., 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, 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 light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0024] 1B 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.

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

[0026] The processor 118 of the WTRU 102 may be coupled to and may receive user-entered data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Additionally, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or 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, etc. 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 home computer (not shown).

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

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

[0029] 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 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, etc. The peripheral device 138 may include one or more sensors, which may be one or more of a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, a direction 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.

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

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

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

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

[0034] 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 foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

[0037] The SGW 164 may be connected to a 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.

[0038] 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 landline communications devices. For example, the CN 106 may include or 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. Additionally, the CN 106 may provide the WTRUs 102a, 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.

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

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

[0041] A WLAN in infrastructure Basic Service Set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface with a Distribution System (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS to a STA may arrive through the AP and be delivered to the STA. Traffic originating from a STA to a destination outside the BSS may be sent to the AP to be delivered to the respective destination. Traffic between STAs within a BSS may be sent, for example, through the AP, where the source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between (e.g., directly between) a source STA and a destination STA 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 an Independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as an "ad hoc" communication mode.

[0042] When using the 802.11ac infrastructure mode of operation or a similar mode of operation, an AP may transmit beacons on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., a 20 MHz wide bandwidth) or a width that is dynamically configured via signaling. The primary channel may be the operating channel of the BSS and may be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. With CSMA / CA, STAs (e.g., all STAs), including the AP, may sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, the particular STA may back off. One STA (e.g., only one station) may transmit in a given BSS at any given time.

[0043] High Throughput (HT) STAs may use 40 MHz wide channels 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.

[0044] A Very High Throughput (VHT) STA may support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. A 40 MHz and / or 80 MHz channel may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining eight 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, after channel encoding, the data may pass through a segment parser that may split the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped to two 80 MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration may be reversed, and the combined data may be sent to Medium Access Control (MAC).

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

[0046] WLAN systems that can support multiple channels and channel bandwidths, such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be configured and / or limited by the STAs among all STAs operating in the BSS that support the minimum bandwidth operating mode. In an 802.11ah embodiment, the primary channel can be 1 MHz wide for STAs (e.g., MTC-type devices) that support (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) configuration can depend on the status of the primary channel. For example, if the primary channel is busy due to a STA (that only supports 1 MHz operating mode) transmitting to the AP, the entire available frequency band may be considered busy, even though most of the frequency band may remain idle and be available for use.

[0047] 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.

[0048] 1D is a system diagram illustrating the RAN 113 and the CN 115, according to one embodiment. As mentioned above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also communicate with the CN 115.

[0049] The RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that the RAN 113 may include any number of gNBs while remaining consistent with the embodiments. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNB 180a, 180b may transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c using beamforming. Thus, the gNB 180a may transmit wireless signals to and / or receive wireless signals from the WTRU 102a using, for example, multiple antennas. 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, the WTRU 102a may receive coordinated transmissions from the gNBs 180a and 180b (and / or 180c).

[0050] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with 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 the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of different or scalable lengths (e.g., including different numbers of OFDM symbols and / or lasting different lengths of absolute time).

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

[0052] 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 for network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data to User Plane Functions (UPFs) 184a, 184b, routing of control plane information to Access and Mobility Management Functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, the gNBs 180a, 180b, 180c may communicate with each other via an Xn interface.

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

[0054] 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 function as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting a particular SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, etc. Network slicing may be used by the AMF 182a, 182b to customize the CN support of the WTRUs 102a, 102b, 102c based on the type of service utilizing the 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, etc. 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.

[0055] The SMFs 183a and 183b may be connected to the AMFs 182a and 182b in the CN 115 via an N11 interface. The SMFs 183a and 183b may also be connected to the UPFs 184a and 184b in the CN 115 via an N4 interface. The SMFs 183a and 183b may select and control the UPFs 184a and 184b and configure the routing of traffic through the UPFs 184a and 184b. The SMFs 183a and 183b may perform other functions such as managing and assigning IP addresses for UEs, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0056] The UPFs 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, thereby providing 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 UPFs 184, 184b may perform other functions such as routing and forwarding packets, enforcing user plane policy, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, etc.

[0057] The CN 115 may facilitate communication with other networks. For example, the CN 115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 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, the WTRUs 102a, 102b, 102c may be connected to local data networks (DNs) 185a, 185b through the UPFs 184a, 184b via an N3 interface to the UPFs 184a, 184b and an N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.

[0058] 1A-1D and the corresponding descriptions thereof, one or more or all of the functions described herein with respect to one or more of the WTRUs 102a-d, base stations 114a-b, eNodeBs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other devices 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 simulate network and / or WTRU functions.

[0059] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and / or an operator network environment. For example, one or more emulation devices may perform one or more or all functions while fully or partially implemented and / or deployed as part of a wired and / or wireless communications network to test other devices in the communications network. One or more emulation devices may perform one or more or all functions while temporarily implemented / deployed as part of a wired and / or wireless communications network. The emulation devices may be directly coupled to another device for testing purposes and / or may perform testing using terrestrial wireless communications.

[0060] One or more emulation devices may perform one or more functions, inclusive, while not being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be utilized in test scenarios in a test lab and / or in an undeployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (which may include, e.g., one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0061] Systems and methods are described herein with respect to service continuity. Service continuity may be implemented and / or provided, for example, when (e.g., when) wireless transmit / receive unit (WTRU)-to-WTRU communication changes from a direct mode to, for example, using an intermediate gateway-capable WTRU. A personal internet of things network (PIN) may be used. A WTRU may be part of a PIN. A WTRU within a PIN may be referred to as a PIN element (PINE). A WTRU and / or a PINE within a PIN may be associated with different capabilities. For example, a PINE within a PIN may be a PINE with gateway capabilities (PEGC). For example, a PINE within a PIN may be a PINE with management capabilities (PEMC).

[0062] In an example, a PINE (e.g., a WTRU) can subscribe to a PEMC for service continuity. The PEMC may authorize a PIN service and obtain a context token (e.g., that may store a session context associated with the service). The PEMC may trigger PEGC selection within the PINE, for example, by a message (e.g., an application layer message). The PEMC may configure the selected PEGC for service continuity (e.g., for the PINE to use for service continuity). The PEMC can configure the PINE to connect to the selected PEGC for service continuity.

[0063] The WTRU may configure service continuity between entities. The WTRU may be a PEMC. The WTRU may receive a notification message. The notification message may indicate a loss of service continuity between the first PINE and the second PINE. The notification message may indicate a PINE ID and a session ID. The WTRU may send a discovery request message to the first PINE and the second PINE. The discovery message may indicate PEGC discovery. The WTRU may receive a discovery response message. The discovery response message may indicate first PEGC discovery information (e.g., from the first PINE) and second PEGC discovery information (e.g., from the second PINE). The WTRU may determine a PEGC based on the first and second PEGC discovery information. The WTRU may send a selection message to the determined PEGC for service continuity between the first PINE and the second PINE. The selection message may indicate the first PINE ID associated with the first PINE and the second PINE. The selection message may indicate a context token. The WTRU may receive a confirmation message from the determined PEGC indicating that service continuity between the first PINE and the second PINE is configured. The confirmation message may indicate a PEGC Internet Protocol (IP) address. The WTRU may, for example, send a configuration message to the first PINE and the second PINE indicating service continuity configuration information.

[0064] Personal Internet of Things network(s) may be provided and / or used.

[0065] Internet of Things (IoT) features may be used by devices that communicate using (e.g., traditional) cellular networks. Devices with IoT capabilities may use (e.g., require) better power consumption performance (e.g., compared to the power consumption performance of devices without IoT capabilities) and may increase network efficiency for bulk operations.

[0066] WTRUs with IoT capabilities may be organized into a personal IoT network (PIN), for example, when multiple IoT devices are deployed in an environment (e.g., a private environment). For example, in a home environment, security sensors, smart lights, smart plugs, printers, and mobile phones may be managed (e.g., by a residential gateway) and communicate with each other. In this case, (e.g., all) devices in the home may constitute a personal IoT network (PIN). The devices (e.g., each of the devices) may include (e.g., be referred to as) a PIN element, and different PIN elements may have different capabilities. For example, a residential gateway may include a PIN element with gateway capabilities (PEGC) that provides, for example, connectivity between PIN elements and between a network and one or more PIN elements. A PIN element with management capabilities (PEMC) may be a PIN element that provides (e.g., enables) means for configuring and managing PINs (e.g., an administrator authorized to configure and manage PINs); for example, a residential gateway that may act as a PEGC may also support PIN management functionality and be a PIN element with management capabilities.

[0067] 2 is a diagram illustrating an example of a home automation PIN. A wearable device may configure another type of PIN. A smartphone can act as a PIN element with gateway capabilities (PEGC) and a PIN element with management capabilities (PEMC). A smartwatch, VR / AR glasses, and / or airpods can communicate PINs with each other or with other WTRUs over a network.

[0068] FIG. 3 is a diagram illustrating an exemplary wearable PIN.

[0069] A personal internet of things network architecture may be provided.

[0070] A Personal Internet of Things Network (PIN) may include a PIN Element (PE / PINE), a PIN Management (PEMC), and a PIN Gateway (PEGW). A PIN Element may be a WTRU or a device capable of communicating within a PIN. A PIN Management Device may be a PIN Element with the ability to manage PINs. A PEGC may be a PIN Element that can provide (e.g., have the ability to provide) connectivity to and from the network for other PIN Elements.

[0071] FIG. 4 illustrates an exemplary personal Internet of Things network architecture.

[0072] PIN components may communicate with each other (e.g., via a PEGC or directly), with the system to obtain services, or with a data network (e.g., via a core network).

[0073] A PIN element with management capabilities and a PIN element with gateway capabilities (e.g., only a PIN element with management capabilities and a PIN element with gateway capabilities) may be a WTRU. Communications within the PIN (e.g., all other communications) may be performed over a network (e.g., WiFi and / or Bluetooth, etc.).

[0074] A PIN application framework (eg, PINAPP) may be provided and / or used.

[0075] Application layer support may be provided and / or enabled for Personal IoT Networks (PINs).

[0076] The application layer architecture may be designed for PIN (e.g., meets the requirements of PIN) and may support a PIN application layer functional model.

[0077] An application architecture may be provided to enable PINAPP (eg, as described herein).

[0078] FIG. 5 is a diagram illustrating an exemplary PINAPP architecture.

[0079] Application entities such as a PIN client in PINE, a PIN gateway client in PEGC, a PIN management client in PEMC, and / or a PIN server in the data network may be part of the PINAPP architecture and may enable (e.g., desired) features within the PIN. These functional entities and PIN nodes may be used (e.g., interchangeably) to enable, for example, PINAPP functionality. A PIN node may assume a PIN functional entity; for example, PINE may refer to a PIN client, a PEMC may refer to a PIN management client, and a PEGC may refer to a PIN gateway client.

[0080] Service interruptions can be minimized if (e.g., when) a PIN element changes a communication path, for example, from communication between PINEs (e.g., direct communication) to the use of an intermediate PEGC. Service interruptions can be minimized if (e.g., when) a PIN element changes a communication path, for example, from communication between PINEs (e.g., direct communication) to the use of one or more intermediate PEGCs.

[0081] FIG. 6 is a diagram illustrating an exemplary service continuity via a PEGC.

[0082] A PIN may include different PIN elements (e.g., sensors, AR / VR, smart TVs, etc.), and these PIN elements (PINs) may have different requirements. PIN elements can interact with each other directly, for example, without connecting through a PEGC.

[0083] PINEs may be out of range of each other, e.g., due to PINE mobility. Service between (e.g., two) PINEs may be interrupted. An appropriate PEGC may be discovered, selected, and configured to continue service through it, e.g., to enable service continuity.

[0084] PEGC discovery and selection can be performed.

[0085] A (e.g., correct) PEGC discovery and selection procedure can be triggered (e.g., from the application layer). The selected PEGC can be configured for service continuity. Application layer mechanisms can be used to configure the selected PEGC for service continuity.

[0086] FIG. 7 is a diagram illustrating an example of service continuity through multiple PEGCs.

[0087] In an example (e.g., to restore service continuity between two PINEs), (e.g., two or more) PEGCs may be used (e.g., required) depending on the location of the PINEs. In this scenario, multiple PEGCs (e.g., after selection) may be configured (e.g., through application layer mechanisms) to enable service continuity.

[0088] A PINE subscription for service continuity may be used and / or enabled.

[0089] One or more PINEs that interact among themselves can subscribe to a PEMC for service continuity. The PEMC may authorize requests from the PIN server. If the subscription is valid, the PEMC may take action to maintain service continuity if (e.g., when) a PINE loses contact and requires service continuity. A context token may be used to store the context of service continuity between the PINE, PEMC, PEGC, and / or PIN server.

[0090] PEGC discovery can be triggered by PINE, for example, using application mechanisms.

[0091] A PINE that may lose contact with another PINE may notify the PEMC about the interruption in service. The PEMC may initiate a service continuity procedure, e.g., select (e.g., decide to select) a PEGC that may provide service continuity. The PEMC may trigger a (e.g., specific) PEGC selection procedure that may be initiated by the PINE. The PEMC may, for example, send a message to the PINE to trigger the PEGC selection procedure. The PEMC may select one or more PEGCs for service continuity, e.g., if (e.g., thereafter) the PINE returns discovered PEGCs to the PEMC.

[0092] The PEGC may be configured, for example, using an application mechanism.

[0093] The PEMC may send configuration information to the PEGC (e.g., configure the PEGC) for service continuity along with PINE information such as a PINE ID, a PINE endpoint identifier, and / or policies related to service continuity for the PINE. The PEGC may, for example, update forwarding tables and / or allocate resources based on the policy information.

[0094] The PEMC may request the system (e.g., 5GS) to provide configuration information to the PEGC. The PEMC client may (e.g., internally) trigger the PEMC NAS layer to send a request to the system (e.g., 5GS) for PEGC packet forwarding configuration information. The system (e.g., 5GS) can provide forwarding rules to selected PEGCs to enable packet forwarding internally as well as between PEGCs.

[0095] The PEMC may configure the PINE to enable service continuity through the PEGC.

[0096] The PEMC can configure the PINE with the PEGC information (e.g., send configuration information indicating the PEGC information). The PINE can use the PEG information to connect to the PEGC (e.g., so that services can continue through the PEGC).

[0097] A context token can be used.

[0098] To enable service continuity features, context tokens may be used between PINAPP application clients to retrieve endpoint information and / or application context and / or to update tokens as endpoints change due to service continuity.

[0099] An example of a context token is illustrated in Figure 1.

[0100] [Table 1]

[0101] Service continuity (SC) may be enabled and / or provided through a (eg, single) PEGC.

[0102] FIG. 8 is a diagram illustrating an exemplary procedure ALT1 for service continuity.

[0103] As shown at 810 in FIG. 8, PINE1 and PINE2 can communicate (eg, directly) via (eg, any kind of) D2D technology (eg, WiFi, ProSe / PC5, Bluetooth).

[0104] PINE may do one or more of the following to enable service continuity:

[0105] A PINE (e.g., a PIN client) can subscribe to a PEMC, for example, to request support for service continuity. The PEMC can create a list of PINEs that have requested an SC and / or sessions for which an SC is required. The PEMC can determine (e.g., based on the session and PINE ID) that the PINE is communicating over a session that may be a D2D session (e.g., without a gateway) and can use one or more gateways for service continuity (e.g., if the D2D session is lost).

[0106] The PEMC may use the PIN server to authorize the SC request. The PEMC may send the PINE IDs of (e.g., two) PINEs, the type of service, the existence of connectivity (e.g., direct connectivity) between the PINEs (e.g., D2D session), the session ID, etc.

[0107] The PIN server can authorize the PINE for service continuity and can create a context token. The token can include the PINE ID, session ID, session type, policy information, etc. The PIN server can respond to the PEMC by sending the SC authorization information and the context token.

[0108] The PEMC may (eg, optionally) forward the context token along with authorization information to the PINE so that the PINE can use / update the context token (eg, if needed).

[0109] As shown at 820 in FIG. 8, the PINE may lose connectivity. At that point (e.g., the PINE loses connectivity), it can be assumed that service is interrupted. The PINE can notify the PEMC about the service discontinuity, for example, by sending SC Lost with the PINE ID and / or session ID. The PINE can update a context token in the application context, for example, when (e.g., when) service is lost. For example, the application context can include one or more of the following: the state of the PINE application (e.g., Init, Startup, Game Scene 1, etc.); the dataset when connectivity was lost; counters and time values ​​(e.g., via timers); the last data packet received (e.g., data pkt); etc. The PINE can send the updated context token to the PEMC.

[0110] 8, the PEMC (e.g., PIN management client) can store the updated context token and can verify whether the PINE is authorized to the SC. The PEMC may retrieve the authorized policy from the context token for (e.g., each) PINE.

[0111] A PEMC (PIN management client) may determine that there has been communication, which may be direct communication between devices. The PEMC may determine that a PEGC may be (e.g., should be) selected for service continuity based on, for example, an associated session ID.

[0112] The PEMC may perform (e.g., may be capable of performing) various PEGC selection procedures. In this scenario, the PIN management client may select a (e.g., a particular) PEGC selection procedure, which may involve, for example, PEGC discovery by the PINE. The PIN management client may trigger the discovery procedure by sending a message (e.g., Initiate PEGC Discovery for SC) to the PIN client. The message may include policy and authorization information for the PINE to initiate PEGC discovery.

[0113] PEGC discovery by the PINE may be triggered (e.g., by receiving a message, e.g., PEGC discovery start for SC). The PINE may report discovered PEGC information to the PEMC. The PEMC may select a (e.g., optimal) PEGC. The PIN node may be involved in PEGC discovery. The PIN management client may become aware of (e.g., be made aware of) the selected PEGC, e.g., based on (e.g., after) completion of a discovery procedure. The PIN management client may be assumed to be informed of the selected PEGC's IP address, PEGC ID, and / or associated policies.

[0114] In ALT1 (e.g., as shown in FIG. 8), (e.g., only one) PEGC may be selected by the PEMC. As shown at 840 in FIG. 8, the PIN management client in the PEMC may configure (e.g., initiate configuration) the selected PEGC for service continuity. The PIN management client in the PEMC may send a message (e.g., a selection message such as a Configure PEGC for SC message) to the selected PEGC (PIN Gateway Client), which may include the PINE IDs and context tokens of the (e.g., two) PINEs.

[0115] The PIN gateway client can configure a forwarding table in the PEGC so that PINE traffic (e.g., related to a service) can be forwarded back and forth. The PIN gateway client can parse the context token to perform one or more of the following: determine a policy associated with the PINE and allocate forwarding resources based on the policy; determine whether a new IP address is assigned or the PINE's IP address is restored (e.g., if the IP address is restored, the PINE's IP address can be extracted from the context token and set appropriately); determine the application context and set a forwarding path based on the application state and application requirements; assign a port number (e.g., Port#) to a (e.g., particular) session (e.g., there could be two for two PINEs); etc.

[0116] The PEGC client may send a confirmation to the PEMC (eg, based on successful configuration), which may include, for example, the PEGC IP address and port number for the PINE.

[0117] 8, the PIN management client in the PEMC may instruct the PIN enabler client in the PINE to connect to the selected PEGC, for example, by sending a message (e.g., a Configure PINE with PEGC Information message). The message may include the PEGC ID, the PEGC IP address, and the port # created for the PINE service / session.

[0118] As shown at 860 in FIG. 8, a PINE (e.g., a PIN enabler client) can set up a connection to a PEGC using the PEGC IP address, port #, etc. The PEGC can use DHCP to assign a different (e.g., new) address if (e.g., when) the PINE connects, depending on, for example, PINE's policies. Otherwise, the PINE IP address can be restored for seamless service continuity, for example, if supported by the PEGC. Service between PINE1 and PINE2 can continue (e.g., thereafter), for example, based on the successful setup.

[0119] Service continuity (SC) through multiple PEGCs can be enabled.

[0120] Procedures for providing service continuity may be enabled, for example, if (eg, when) two or more PEGCs are selected by the PEMC.

[0121] 9 is a diagram illustrating an example procedure for service continuity. As shown in FIG. 9, service continuity may be provided if (e.g., when) multiple PEGCs are selected. As shown in FIG. 9, the steps may be similar to the procedure described herein (e.g., with respect to FIG. 8). The procedure shown in FIG. 8 may be used (e.g., as shown in FIG. 9). The procedure (e.g., in FIG. 9) may differ from the procedure illustrated in FIG. 8, for example, where Alternative 2 (ALT2) may be performed (e.g., in FIG. 9).

[0122] As shown at 940 in FIG. 9, ALT2 may include the following: A PINE may discover a PEGC and send PEGC information to a PEMC. The PEMC may not (e.g., cannot) find a (e.g., single) PEGC that can serve (e.g., two) PINEs. In that case, the PEMC may select multiple (e.g., two or more) PEGCs (e.g., optimal PEGCs) for service continuity, e.g., PEGC1 and PEGC2 (e.g., as shown in FIG. 10) that can provide communication paths for PINE1 and PINE2.

[0123] FIG. 10 is a diagram illustrating an exemplary procedure for service continuity.

[0124] A PEMC (e.g., a PIN management client) can configure (e.g., initiate configuration of) selected PEGCs (e.g., PEGC1 and PEGC2) for service continuity. The PEMC can determine that PEGC1 will be used by PINE1 and PEGC2 will be used by PINE2.

[0125] The PEMC may send a message (e.g., a selection message such as configure PEGC for SC) to selected PEGCs (e.g., PEGC1 and PEGC2). The message (e.g., a selection message such as configure PEGC for SC) may include one or more of PINE ID1 to PEGC1 and a context token, and / or PINE ID2 to PEGC2 and a context token.

[0126] (E.g., each) PEGC (e.g., PIN gateway client) may configure its forwarding table, e.g., so that PINE traffic associated with a service (e.g., PINE1 and PINE2) can be appropriately forwarded. The PEGC may parse the context token and, e.g., perform one or more of the following: determine a policy associated with the PINE and allocate forwarding resources based on the policy; depending on the policy for the PINE, the PEGC may use DHCP to assign a new address when the PINE connects or otherwise, if supported by the PEGC, restore the PINE's IP address for seamless service continuity; determine application context and set up forwarding paths based on application state and application requirements; assign a port number to a (e.g., particular) session (e.g., there may be two for two PINEs).

[0127] The PEGC (eg, PIN gateway client) may, for example, upon (eg, after) successful configuration, send a confirmation to the PEMC (eg, including the PEGC IP address and port number for the PIN).

[0128] The PEMC (e.g., PIN management client) can trigger another procedure by, for example, sending an (e.g., internal) message (e.g., get pkt forwarding information through PEGC (list of PEGCs) for SCs through PEGC) to the PEMC NAS layer when (e.g., when) the PEMC interacts with a system such as a 5GS (e.g., AMF, PCF) to obtain forwarding / routing rules between selected PEGCs (e.g., PEGC1, PEGC2, etc.). The system (e.g., 5GS) can send the forwarding rules to PEGC1 and PEGC2. PEGC Client 1 and PEGC Client 2 can update their forwarding tables with the inter-PEGC forwarding rules.

[0129] 9 at 950, the PIN management client in the PEMC may instruct the PIN enabler clients in PINE1 and PINE2 to connect to the selected PEGCs (PEGC1 and PEGC2) by sending a message (e.g., a Configure PINE with PEGC Information message). The message (e.g., a Configure PINE with PEGC Information message) may include one or more of the following: PEGC1 Id, PEGC1 IP address, port # created for PINE1; PEGC2 Id, PEGC2 IP address, port # created for PINE2; etc.

[0130] 9, the PIN enabler clients in PINE1 and PINE2 can set up (e.g., initiate setup) connections toward PEGC1 and PEGC2, using, for example, the PEGC IP address, port #, etc. Service between PINE1 and PINE2 continues through PEGC1 and PEGC2, for example, based on (e.g., thereafter) successful setup.

[0131] Although the 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 may be used in various combinations with or without the other features and elements.

[0132] While the implementations described herein may consider 3GPP-specific protocols, it will be understood that the implementations described herein are not limited to this scenario and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it will be understood that the solutions described herein are not limited to this scenario and may be applicable to other wireless systems.

[0133] The processes described above may be implemented in a computer program, software, and / or firmware embodied 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 via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random-access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media, magneto-optical media, such as, but not limited to, internal hard disks and removable disks, 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.

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving a notification message, the notification message indicating a loss of service continuity between a first Personal Internet of Things Network Element (PINE) and a second PINE; sending a first discovery request message to the first PINE and a second discovery request message to the second PINE, the discovery messages indicating initiating PINE with Gateway Capabilities (PEGC) discovery; receiving a first discovery response message and a second discovery response message, the first discovery response message indicating first PEGC discovery information from the first PINE and the second discovery response message indicating second PEGC discovery information from the second PINE; determining a PEGC based on the first PEGC discovery information and the second PEGC discovery information; sending a selection message to the determined PEGC for service continuity between the first PINE and the second PINE; receiving a confirmation message from the determined PEGC indicating that service continuity between the first PINE and the second PINE is configured; and transmitting a first configuration message to the first PINE and a second configuration message to the second PINE, the first configuration message and the second configuration message indicating the service continuity configuration information.

2. The WTRU of claim 1 , wherein the notification message further indicates a PINE identification (ID) and a session ID.

3. The WTRU of claim 1 , wherein the selection message indicates a first PINE identification (ID) associated with the first PINE, a second PINE ID associated with the second PINE, and a context token.

4. 10. The WTRU of claim 1, wherein the confirmation message further indicates a PEGC Internet Protocol (IP) address and port number.

5. The WTRU of claim 1 , wherein the service continuity configuration information includes a PEGC identification (ID), a PEGC Internet Protocol (IP) address, and a port number.

6. The WTRU of claim 1 , wherein the WTRU is a Personal Internet of Things network element with management capabilities.

7. 1. A method comprising: receiving a notification message, the notification message indicating a loss of service continuity between a first Personal Internet of Things Network Element (PINE) and a second PINE; sending a first discovery request message to the first PINE and a second discovery request message to the second PINE, the discovery messages indicating initiating PINE with Gateway Capabilities (PEGC) discovery; receiving a first discovery response message and a second discovery response message, the first discovery response message indicating first PEGC discovery information from the first PINE and the second discovery response message indicating second PEGC discovery information from the second PINE; determining a PEGC based on the first PEGC discovery information and the second PEGC discovery information; sending a selection message to the determined PEGC for service continuity between the first PINE and the second PINE; receiving a confirmation message from the determined PEGC indicating that service continuity between the first PINE and the second PINE is configured; sending a first configuration message to the first PINE and a second configuration message to the second PINE, wherein the first configuration message and the second configuration message indicate the service continuity configuration information.

8. The method of claim 7 , wherein the notification message further indicates a PINE identification (ID) and a session ID.

9. The method of claim 7 , wherein the selection message indicates a first PINE identification (ID) associated with the first PINE, a second PINE ID associated with the second PINE, and a context token.

10. 8. The method of claim 7, wherein the confirmation message further indicates a PEGC Internet Protocol (IP) address and port number.

11. The method of claim 7 , wherein the service continuity configuration information includes a PEGC identification (ID), a PEGC Internet Protocol (IP) address, and a port number.

12. 10. The method of claim 7, wherein the method is performed by a wireless transmit / receive unit (WTRU), the WTRU being a personal internet of things network element with management capabilities.

Images