Method and apparatus for service continuity in individual internet of things (IOT) network (PIN)

Abstract

Methods and apparatus for service continuity for a personal IoT network (PIN) element (PINE) are described. A first message is received from a PIN server, the first message including contextual information including an identifier of a PINE, an identifier of a session of the PINE with an application server, and an identifier of a first PIN gateway (PEGC) providing 3GPP network services to the PINE for the session. A second message is received from the first PEGC, the second message indicating a loss of connectivity with the PINE and including the identifier of the PINE and the contextual information. It is determined that the PINE is authorized to connect to a second PEGC. The context information is updated to include an identifier of the second PEGC. A third message is sent to the second PEGC, the third message containing the identifier of the PINE, the updated context information, and an indication to activate service continuity of the PINE.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 396,838, filed on August 10, 2022, the contents of which are incorporated herein by reference. Background Art

[0003] The Internet of Things (IoT) has been designed for devices that use traditional cellular networks for communication. IoT-enabled devices may require better power performance and improved network efficiency for bulk operations. When multiple IoT devices are deployed in a private environment, IoT-enabled wireless transmit / receive units (WTRUs) may be organized into personal IoT networks (PINs). Summary of the invention

[0004] A method and apparatus for service continuity for a personal IoT network (PIN) element (PINE) is described. A first message is received from a PIN server, the first message including context information, the context information including an identifier of the PINE, an identifier of a session of the PINE with an application server, and an identifier of a first PIN gateway (PEGC) providing 3GPP network services to the PINE for the session. A second message is received from the first PEGC, the second message indicating a loss of connectivity with the PINE and including the identifier of the PINE and the context information. A determination is made that the PINE is authorized to connect to a second PEGC. The context information is updated to include an identifier of the second PEGC. A third message is sent to the second PEGC, the third message including the identifier of the PINE, the updated context information, and an indication to activate service continuity for the PINE. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

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

[0010] Figure 2 is a system diagram of an exemplary home automation PIN;

[0011] Figure 3 is a system diagram of an exemplary system using a wearable PIN;

[0012] Figure 4 is a block diagram of an exemplary personal IoT network architecture;

[0013] Figure 5 is a block diagram of an exemplary PIN application (PINAPP) framework;

[0014] Figure 6 is a signal diagram illustrating an exemplary scenario, where a PINE detaches from its current PIN gateway PEGC-1 and attaches to another PIN gateway PEGC-2;

[0015] Fig. 7A is a signal diagram illustrating an example of achieving service continuity;

[0016] Figure 7B is a flow chart of an exemplary method of implementing service continuity;

[0017] Figure 8 is a signal diagram for another example of achieving service continuity;

[0018] Fig. 9 is a signal diagram for another example of achieving service continuity;

[0019] Fig.10 is a signal diagram of another example of implementing SC, where simultaneous sessions are enabled for PINE; and

[0020] Fig.11 is another signal diagram that illustrates an example of service continuity through 5GS. DETAILED DESCRIPTION

[0021] Figure 1A1 is a diagram illustrating 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, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single carrier FDMA (SC-FDMA), zero tail unique word discrete Fourier transform spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, and filter bank multi-carrier (FBMC), etc.

[0022] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110 and other networks 112, but it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a station (STA)) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), consumer electronic devices, and devices operating on a commercial and / or industrial wireless network, etc. Any of the UEs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs.

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

[0024] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), and relay nodes. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an 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 send and / or receive signals in a desired spatial direction.

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

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

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

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

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

[0030] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 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).

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

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

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

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

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

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

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

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

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

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

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

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

[0043] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (FM) radio units, digital music players, media players, video game player modules, Internet browsers, virtual reality and / or augmented reality (VR / AR) devices and activity trackers, etc. The peripheral device 138 may include one or more sensors. The sensor may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geographic location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and a humidity sensor, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0057] A high throughput (HT) STA may communicate using a 40 MHz wide channel (eg, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels) to form a 40 MHz wide channel.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0075] Figure 2 2 is a system diagram 200 of an exemplary system including a home automation PIN 202 that includes a plurality of IoT devices referred to as PIN elements (PINEs). Figure 2 In the example depicted, the PINEs may include security sensors 204, motion sensors 206, visitor PINEs 208, smart keys 210, smart locks 212, smart plugs 214, 218, and 219, smart light bulbs 216, and smartphone 224. Such PINEs are typical of IoT devices used in home automation PINs.

[0076] Within the home automation PIN 202, each of the PINEs may communicate with each other, typically via non-3GPP communications (such as Bluetooth or WiFi), and each of the PINEs may have different capabilities. For example, the residential gateway 220 may be a PINE with gateway capabilities and may provide wireless connectivity between a 3GPP network (such as a 5G network) and the PINEs in the PIN 202. For another example, some PINEs may have relay capabilities to relay signaling from one PINE to another PINE within the PIN 202. Figure 2In the illustrated example, security sensor 204 and motion sensor 206 may send communications 234a and 234b, respectively, which may be relayed by smart light bulb 216 to residential gateway 220. Visitor PINE 208 and smart key 210 may send communications 234d and 234e to smart lock 212. Smart lock 212 may send communication 234c, which may be relayed to residential gateway 220 and to smartphone 224 via smart plug 219. Smart light bulb 216 may send communication 234f, which may be relayed to residential gateway 220 by smart plug 218. Printer 222 may communicate with residential gateway 220 via Ethernet connection 226. Residential gateway 220, acting as a gateway between the PIN and 5G core network 228, may send communications from the PINE in PIN 202 to smartphone 230 via Uu interface 232. The PINE may also be a PINE with management capabilities and may provide a means for an authorized administrator to configure and manage the PIN. For example, residential gateway 220 in PIN 202 acting as a PIN gateway may support PIN management functions and may be a PINE with management capabilities.

[0077] Figure 3 300 is a system diagram of an exemplary system including wearable PINs 302 and 304. Figure 3 In the illustrated example, two wearable PINs 302 and 304 each include earbuds 306, 316, virtual reality (VR) / augmented reality (AR) glasses 308, 316, and smartphones 312, 318. The wearable PIN 302 also includes a smartwatch 310. Figure 2 Home Automation PIN 202, PINE (e.g., Figure 2 Earbuds, VR / AR glasses, smartphones, and smart watches in the headset can communicate with each other via non-3GPP communications such as Bluetooth or WiFi. Figure 3 In the illustrated example, in the wearable PIN 302, earbuds 306, VR / AR glasses 308, and smartwatch 310 send communications 322a, 322b, and 322c, respectively, to smartphone 312. Smartphone 312 may be configured with a gateway capability (similar to Figure 23GPP / 5G communication can be enabled for the wearable PIN 302, acting as a gateway between the PINE and the 3GPP / 5G core network 326. In the wearable PIN 304, the earbud 314 can send communication 324, which can be relayed by the AR / VR glasses 316 to the smartphone 318. Similar to the wearable PIN 302, the smartphone 318 can be configured with gateway capabilities. Therefore, the smartphone 312 can enable 3GPP / 5G communication for the wearable PIN 304, acting as a gateway between the PINE and the 3GPP / 5G core network 326.

[0078] Figure 4 is a system diagram of an exemplary system including a PIN architecture 400. Figure 4 In the illustrated example, the system includes a PIN 402 and a 5G core network 404. The 5G core network 404 may include a radio access network (RAN) node that may communicate with a PEGC 412 to provide 5G connectivity to the PINEs 406, 408, as well as an access and mobility management function (AMF) 416 and a session management function (SMF) 418. The 5G core network 404 may also include a user plane function (UPF) 420 that may be used to communicate with a data network 422.

[0079] Similar to Figure 2 and Figure 3 As shown, the PIN 402 includes a plurality of PINEs 406, 408, which may be wireless transmit / receive units (WTRUs) or other non-3GPP devices that may communicate with each other using non-3GPP communications such as Bluetooth or Wifi. A PIN management device (PEMC) 410 may be included in the PIN 402 and may be provided with the ability to manage the PIN 402. The PIN 402 may also include a PIN gateway (PEGC) 412, which may be configured to provide services to other PINEs (e.g., Figure 4 406 and 408 in the 5G core network 404) provide connectivity to and from the 5G core network 404. The PIN elements can communicate with each other via the PEGC 412 or directly. In addition, the PINEs 406, 408 can communicate with the 5G core network 404 to obtain 5G services or communicate with the data network 422 via the 5G core network. In some embodiments, the PINEs 406, 408 can use the 5G core network 404 to obtain information from the PIN server 424 via the data network 424.

[0080] According to the 3GPP Release 18 study on personal IoT networks, only PINEs with management capabilities and PINEs with gateway capabilities can be WTRUs. All other communications within a PIN may be performed via non-3-3GPP communications such as WiFi or Bluetooth.

[0081] 3GPP SA6 is studying application layer support for PIN. Aspects of the study include application layer architecture requirements for PIN, identifying key issues, and supporting PIN application layer functional models. A PIN Application (PINAPP) architecture has been proposed.

[0082] Figure 5 is a block diagram of an exemplary PINAPP architecture 500. Figure 5 In the illustrated example, the PINAPP architecture 500 includes a PIN 502, which includes five PINEs 508, 510, 512, 514, and 530. The exemplary PINAPP architecture 500 also includes a 3GPP core network 504 and a data network 506. In some embodiments, the PIN 502 can use the 3GPP core network 504 to communicate with an application server (AS) 534 on the data network 504.

[0083] Each of the PINEs 508, 510, and 512 includes an application client 516, 520, 524, and a PIN client 518, 522, 526, respectively. The PINE 514 may be a PEGC including a PIN gateway client 528. The PINE 514 may be a PEMC including a PIN management client 532. The application clients 516, 520, 524 of the PINEs 508, 510, 512 may communicate with the AS 534 of the data network 506 directly via the 5GS or indirectly via the PEGC 530. Within the PIN 502, the application clients 516, 520, 524 may communicate with other application clients in the same PIN 502 directly or via the PEGC 530. The application clients 516, 520, 524 may also communicate with other application clients in another PIN via the PEGC 530. The data network 506 may also include a PIN server 536 , which may provide configuration information to the WTRU, authorize PIN creation requests, and arrange PEGC information regarding access control to the PIN 502 .

[0084] As described above, the PIN may include different PINEs (e.g., sensors, AR / VR, smart TV, etc.). These PINEs may have different requirements (e.g., monitoring, maintenance, tracking), and may need to access different 5G core network services. Therefore, the PINEs may need to use different PIN GWs (PEGCs) to communicate with the corresponding / supported core networks to access the services they need.

[0085] A PINE may attach to a PEGC to access 5G core network services. A PINE may lose connectivity with a PEGC due to mobility. A PINE may lose connectivity with a PEGC due to a variety of reasons, such as mobility of the PINE (where a mobile PINE moves away from the PEGC and is out of range), mobility of the PEGC (where a mobile PEGC moves away from the PINE and eventually the radio signal between the PINE and the PEGC degrades resulting in a loss of communication), and / or PIN reconfiguration (when the PEMC decides, on its own or is instructed by a PIN server, to remove a PEGC connected to a PINE). For PIN reconfiguration, the PEMC may instruct the PINE to find another PEGC.

[0086] Figure 6 is a signal diagram illustrating an exemplary scenario in which PINE 610a is detached from its current PIN gateway PEGC-1 606 and attached to another PIN gateway PEGC-2 608 (as represented by PINE 610b). Alternatively or in addition, PINE 610a may move out of the PIN entirely and access services through 5GS 504 (as represented by PINE 610c).

[0087] When accessing services such as streaming, monitoring, and / or AI / ML, PINE 610 may establish a session with an AS (not shown) through PEGC1 606. Services with PEGC1 606 may be interrupted due to PINE 606 leaving the communication range or PIN reconfiguration. In order to provide service continuity, PINE 610 may need to find another PEGC (e.g., PEGC2 608) to connect to AS 602 via 5GS 604. Then, the ongoing session between PINE 610, PEGC1 606, and AS may be resumed / continued through PEGC2 608.

[0088] In order to provide service continuity, some issues need to be considered. For example: how to identify the session context that needs to be restored with a new PEGC, how to restore the service through the new PEGC with minimal interruption (such as no repetition, waiting, etc.), and how to configure PEGC and AS to restore the service with minimal interruption. In addition, when PEGC is not available for PINE connectivity, the default PINE can connect to the application server through 5GS. Therefore, in order to provide service continuity, it should also be determined how to restore the service through 5GS with minimal interruption when the PINE is outside the PIN coverage or the PEMC is not available. In addition, in order to be able to restore the service, it should have the ability to identify and mark the application sessions that require service continuity (SC). In addition, how to maintain and restore the identified application session context to provide service continuity when the PINE changes PEGC should be addressed.

[0089] More specifically, due to mobility or PIN reconfiguration, the PINE may lose connectivity with the AS. In order to maintain service continuity, the embodiments described herein may provide a PINE subscription for service continuity of a PIN server or PEMC. The PEMC may authorize the request to the PCS / PIN server. Once the PEMC is authorized, it may initiate an action to maintain service continuity. Additionally or alternatively, when the PINE loses connectivity, it may notify the PEMC of the last packet successfully received, and buffering may start at the AS or in the PEGC. Additionally or alternatively, after the PINE regains connectivity with the new PEGC, the AS may restore the session based on the new target information and buffering information. For scenarios involving PIN reconfiguration, the PEMC may configure the PINE and the PEGC, and then reconfigure the PIN. The PEMC may notify the PIN server and the AS to start buffering. When the PINE is reconnected to another PEGC, the session may be restored. In one, multiple or all embodiments described herein, context information may be used to track the PINE, PEGC information, policy information, and application context, such as the last packet received, application status, and the like. In some embodiments, as described in more detail below, the policy information may be or include a context token.

[0090] A context token may be an information structure that may include PINE session related information that may be exchanged in a PIN environment by a PIN server (PCS), a PIN manager (PEMC), a PIN gateway (PEGC), and an application server (AS) to establish / restore a session. A context token may be created by a PCS for global reference of a service session, and may optionally be maintained and modified locally by a PEMC for use with individual PINs. If authorized by a PCS, a context token may be dynamically updated by a PEMC, PEGC, and PINE. The attributes of an exemplary context token are given in Table 1 below.

[0091] Table 1: Context token data types

[0092]

[0093]

[0094] Referring to Table 1, the token ID may be a unique identifier of a context token exchanged between elements in the PIN and may be a string data type. The application client may use the token ID to query the token. The PIN identifier may be required to identify the PIN network in the 5G system. The PIN ID may be a string data type. The PIN ID may have sub-attributes such as a PIN description, which may detail information such as the PIN location, the PIN manager (service provider or any 3rd party), the type of service provided by the PIN network (e.g., health monitoring, streaming, security monitoring, etc.). This attribute may store a large amount of information and requires rich text formatting, and may therefore be a long text string data type.

[0095] The PINE list may list the PINEs involved in service continuity and may include sub-attributes, such as PINE IDs. The PINE ID may be a unique identifier for a PIN element in a PIN network. The identifier may help identify the type of PIN element, such as a PINE, PEMC, PEGC-S, or PEGC-T. The identifier may be one or more of a GPSI, an IP address, or an MSISDN. Further, a PINE policy, which may be a data type long text string, may list rules related to service continuity for a PINE. The policy may include, but is not limited to, whether a SC will be allowed for a particular PINE, the QoS of the SC for the PINE, the location of the PINE that utilizes the service continuity feature, the time limit or available time slots that can utilize the SC, and / or the network resources reserved for implementing the SC.

[0096] The Application Server ID may be a unique identifier for the AS. This attribute may be needed to identify the platform on which the PINE consumes the service when parsing the context token. The Service ID (a subtype of the Application Server ID) may be a string and may identify a service hosted in the AS that is being consumed by the PINE. The service may be any service including, for example, AI / ML, streaming, and / or monitoring. The Session Identifier (Session ID) may be included in the context token or sent explicitly in the message exchange in the PIN environment. The Session ID may be a string and may identify the session establishment between the PINE and the AS.

[0097] The application context may include a string data type pkt_marker for identifying application data packets, in particular for the purpose of activating and releasing buffers. The application context may store information about the application's logical state, state variables, tables, data, counter values ​​and timer values.

[0098] Fig. 7A 7 is a signal diagram 700 illustrating an example of implementing service continuity. A PINE 702 may have a session established with an AS 714 for consuming services such as streaming, monitoring, and / or AI / ML via a 5GS 710. AS 714 may provide a computing platform for hosting applications consumed by PINE 702. In the example illustrated in FIG. 7 , while PINE 702 may be involved in an ongoing service session (717) with AS 714, in the event that PINE 702 is unable to connect to the PEGC, it may subscribe to a PIN Configuration Server (PCS) 712 for service continuity (SC). In a subscription request (718), PINE 702 may send one or more of its PINE ID (PE ID) (which may be a PINE unique identifier, which may be any one of, for example, a GPSI, an IP address, an MSISDN, etc.), an indication that SC is required for all sessions (which may be as simple as a flag indicating that SC is required for all sessions), and / or IDs of individual sessions (which may be a list of specific session IDs for which SC is requested). For all sessions, optionally, the subscription request (718) may include information that all sessions running at the PINE may include. This subscription request (718) may be sent from the PINE 702 to the PCS 712 over the user plane using an application layer mechanism such as a REST API. Alternatively, the PINE 702 may request a SC with the same set of information from the PEMC 708. The PEMC 708 may obtain the request authorized by the PCS 712.

[0099] Upon receiving a request from PINE 702 or PEMC 708, PCS 712 may authorize (720) PINE 702 to the SC and create context information, such as a context token, as described in detail above. Referring to Table 1 above, context information such as a context token may include information such as the PINE ID of PINE 702, PINE policy, where PINE 702 is consuming services (e.g., Fig. 7A The PCS 712 may send an enable SC message (722) to a PINE with management capability (PEMC) 708 and may provide context information to allow the PEMC 708 to track the PINEs including the PINE 702 and the associated sessions that require SC.

[0100] PEMC 708 may parse the context token to determine the authorized PINE for SC processing. The PEMC may also determine the PEGC associated with PINE 702, such as PEGC-S 704. PEMC 708 may notify PEGC-S 704 of the PINE 702 and the sessions that are eligible for SC by sending an Enable SC message (724). In the same message, PEMC 708 may also send the context token to PEGC-S 704. PEGC-S 704 may parse the context token to identify PINE 702 and the sessions that require SC.

[0101] Events such as PINE mobility may cause the PINE 702 to lose connectivity with the PEGC-S 704. It may be assumed that when connectivity is lost (726), the PEGC client may obtain event notifications from lower layers, such as connectivity loss events (e.g., Wi-Fi, BT L2 events), which may include a device ID or a PINE ID. Based on the PINE ID, the PEGC 704 may retrieve a context token, identify a session ID, or otherwise detect that the PINE 702 has lost contact with the PEGC-S 704 (728). The PEGC 704 may also store the last packet successfully sent for the session when connectivity was lost. The signaling including 717, 718, 722, and 724 may be collectively considered to be the SC subscription initiation message 716, and may be used to establish a service continuity service for the PINE 702 in the event that the PINE 702 loses connection with the PEGC-S 704.

[0102] After receiving the connectivity loss event notification, the PEGC client may send an activation SC message (732) to the PEMC 708, which includes the PE-ID of the PINE lost by the PEGC client and its own IP address and context token. The PEGC-S 704 may also send a packet marker to the PEMC 708, which may be set to the last packet successfully sent. The activation SC message (732) along with the PINE, packet marker, and context token related information may be forwarded to the PCS 712 (734).

[0103] PCS 712 may notify AS 714 of SC activation for PINE 702 by sending an Enable SC message (738). The message (738) may contain a context token, which may include a PINE ID, a session ID, an IP address of PEGC S 704, a port # of PEGC-S 704, and / or a packet tag. AS 714 may identify a session based on the PINE ID, the session ID, and / or the PEGC address. The AS may begin buffering application data packets from the packet marker that are scheduled to be sent to PINE 702. A flag buffered at the AS may be indicated in this message. If buffering is enabled at AS 714, this flag may be set to true. Alternatively, if buffering is not enabled at AS 714, this flag may be set to false. In this scenario, buffering is enabled at AS 714, and a flag buffered at the AS = true.

[0104] The PINE 702 may find the new PEGC (PEGC-T) 706 (736) and may connect to it. The PEMC 708 may be aware of the PINE 702 and know that it has connected to the PEGC-T 706. Alternatively, the PEGC-T 706 may notify the PEMC 708 of the new PINE 702. The PINE 702, the PEGC-S 704, the PEGC-T 706, and the PEMC 708 may perform an admission process with the PINE 702 with the PEGC-T 706 (740). For example, the PEGC-T 706 may establish a session with the PINE 702 based on the PINE ID and the policy information.

[0105] In a scenario where the PEGC-S 704 and the PEGC-T 706 are not managed by the same PEMC, an inter-PEMC process of exchanging SC context tokens may be used. For example, the PEGC-T 706 may notify the new PEMC that it needs a SC. The new PEMC may request SC information for the PINE from the PCS by sending the PINE ID. Based on the PINE ID, the PCS may send the old PEMC information. The new PEMC may contact the old PEMC to obtain the context token. The new PEMC may parse the context token to identify the PINE, session ID, AS ID, policy, etc., which may update the context token with new information such as the PEGC-T information.

[0106] PEMC 708 may configure PEGC-T 706 for service continuity with incoming PINE 702. PEMC 708 may send a PEGC configuration message (744) which may include the PINE ID and context token and have a flag set to activate SC. PEGC-T 706 may establish a port # for receiving incoming packets from AS 714, which may be configured to receive packets from AS 714 using the AS ID and / or AS IP address.

[0107] PEMC 708 may send a Done SC message (746) to PEGC-S 704, which may inform PEGC-S 704 that the resources may now be removed and the PINE context (e.g., PE ID, session ID, and port number corresponding to PINE 702) may be deleted. PEMC 708 may request PCS 714 to establish a new session with PINE 702 via PEGC-T 706, providing the PEGC-T ID, the PEGC-T IP address for layer 3 routing of application data packets, the PINE ID, the port # for the session to be conducted with AS 714, the session ID, and the context token (748).

[0108] PCS 712 may send a resume session command (750) to AS 714 to resume the service session with PINE 702 via PEGC-T 706 by sending all necessary PEGC-T related information. This information may include one or more of the following: a PEGC-T ID (PEGC-T identifier), a PINE ID (PE ID), and an IP address of PINE 702 that AS 714 will use to resume the session, a port # of a port reserved for session establishment between AS 714 and PEGC-T 706, and a context token including the PIN ID and the policy of PINE 702. The session ID may be an identifier of the session that AS 714 will establish with PINE 702 via PEGC-T 706 and a corresponding port number where the session terminates. After receiving the configuration information, AS 714 may configure the session by, for example, changing the IP address from PEGC-S 704 to PEGC-T 706, changing to a new port # provided by PEGC-T 706, including the PINE address in the packet header, using the session ID to identify the buffer, and using packet marking to release the buffer and resume service.

[0109] Figure 7B is a flow chart of an exemplary method 755 for achieving service continuity. Figure 7B In the illustrated example, the method may be implemented in a PEMC, which in some embodiments may be a WTRU.

[0110] The PEMC may receive a first message from the PCS (760). The first message may include context information for at least one PINE. The context information may include at least an identifier of at least one PINE element being authorized for SC, an identifier of at least one session established with the AS for at least one PINE, and an identifier of a first PEGC providing 3GPP network services to at least one PINE for at least one session. In some embodiments, the context information may be or include a context token. In some embodiments, the context information may also include at least one of the following: an identifier of a PIN, a list of PINEs including the PINE that subscribe to SC services, a type of each PINE in the list, a PINE policy that manages the behavior of multiple PINEs in the PIN, or an identifier of one or more services in the AS that multiple PINEs are using. In some embodiments, the first message may be an enable SC message.

[0111] The PINE may be a non-3GPP device configured to communicate with other PINEs in the PIN using non-3GPP communications. At least one session with the AS may be used for at least one of streaming, monitoring, artificial intelligence (AI), or machine learning (ML). In some embodiments, the 3GPP network service may be a 5G network service.

[0112] The PEMC may receive a second message from the first PEGC that may indicate a loss of connectivity with at least one PINE (765). The second message may also include an identifier and context information for the at least one PINE. In some embodiments, the second message may also include a marker for the last packet successfully sent for the at least one session. In some embodiments, the PEMC may forward the second message to the PCS. In some embodiments, the second message may be an SC activation message.

[0113] The PEMC may determine that the at least one PINE is authorized to connect to the second PEGC (770). In some embodiments, the PEMC may determine that the PINE has connected to the second PEGC based on receiving a message from the second PEGC containing information about the at least one PINE or detecting that the at least one PINE has connected to the second PEGC.

[0114] The PEMC may update the context information to include an identifier of the second PEGC (775). The PEMC may send a third message to the second PEGC including an indication that the second PEGC activated the SC for the at least one PINE (780). The third message may also include the updated information and the identifier of the at least one PINE. In some embodiments, the third message may be a PEGC configuration message.

[0115] In some embodiments, the PEMC may send a fourth message to the first PEGC after sending the third message to the second PEGC. The fourth message may include an indication that the first PEGC may remove resources and delete information related to the context information. In some embodiments, the fourth message may be an SC completion message. In some embodiments, the PEMC may send a fifth message to the PCS after sending the third message to the second PEGC. The fifth message may include a request for the PCS to establish a new session for the PINE and the AS and updated context information. In some embodiments, the fifth message may be an SC establishment message.

[0116] Figure 8 FIG. 8 is another example of a signal diagram 800 for implementing service continuity. Figure 8 In the illustrated example, the PINE may be considered static and the PINE does not experience PEGC changes due to mobility events. However, the PINE may experience PEGC changes due to events such as PIN reconfiguration, PEGC failure, failure, and PINE or PEGC mobility (out of communication range).

[0117] Similar to Fig. 7A ,exist Figure 8 In the illustrated example, PINE 802 may have a session established with AS 814 for consuming services such as streaming, monitoring, and / or AI / ML via 5GS 810. AS 814 may provide a computing platform for hosting applications consumed by PINE 802. Figure 8 In the illustrated example, while PINE 802 may be involved in an ongoing service session (816) with AS 814, in the event that PINE 802 cannot connect to the PEGC, it may subscribe to a PIN Configuration Server (PCS) 812 for service continuity (SC). In a subscription request (818), PINE 802 may send one or more of its PINE ID (PE ID) (which may be a PINE unique identifier, which may be any of, for example, a GPSI, an IP address, an MSISDN, etc.), an indication that SC is required for all sessions (which may be as simple as a flag indicating that SC is required for all sessions), and / or IDs of individual sessions (which may be a list of specific session IDs for which SC is requested). For all sessions, the subscription request (818) may optionally include information that all sessions running at the PINE may be included. This subscription request (818) from PINE 702 to PCS 812 may be sent over the user plane using an application layer mechanism such as a REST API. Alternatively, PINE 802 may request a SC with the same set of information from PEMC 808. PEMC 808 may obtain the request authorized by PCS 812.

[0118] Upon receiving a request from PINE 802 or PEMC 808, PCS 812 may authorize (820) PINE 802 to the SC and create context information, such as a context token, as described in detail above. Referring to Table 1 above, context information such as a context token may include information such as the PINE ID of PINE 802, PINE policy, where PINE 802 is consuming services (e.g., Figure 8 The PCS 812 may send an enable SC message (822) to a PINE with management capability (PEMC) 808 and may provide context information to allow the PEMC 808 to track the PINEs including the PINE 802 and associated sessions that require SC.

[0119] PEMC 808 may select PIN reconfiguration for policy-related reasons. Before starting the reconfiguration process, PEMC 808 may select an appropriate PEGC for PINE 802 after parsing the received PINE context token information. PEMC may initiate the preparation phase (824) by sending a Prepare and SC message (826) for PIN reconfiguration to inform PINE 802 that it may lose connectivity with PEGC-S 804 and may include information about an appropriate PEGC-T 806 to which it may connect for service continuity.

[0120] PEMC 808 may utilize PINE information to configure PEGC-T 806 for service continuity, which PEGC-T may connect to the PEMC after reconfiguration. PEMC may send a PEGC configuration message (828) that may include a PINE ID and a context token, and may optionally set a flag to activate SC. PEGC-T 806 may use the PINE ID and policy information to discover and / or authorize PINE 802. PEGC-T 806 may parse the context token to prepare to receive packets from AS 814 using AS ID and AS IP address. PEGC-T 806 may establish a port # for receiving incoming packets from AS 814 having AS ID and AS IP address. Optionally, a flag activate SC may be indicated in the message. If the flag activate SC is set to true, PEGC-T 806 may be enabled to start discovering PINE 802 based on PINE ID, and a session with PINE 802 may be established based on PINE ID and policy information. The flag may also be set to maintain or false. In those cases, PEGC-T 806 will not initiate discovery and session establishment with PINE 802.

[0121] PEMC 808 may send an Activate SC message (830) to PCS 812. The message may include the PINE ID of the PINE for which SC activation is requested, as well as the IP address of the PINE reserved for incoming connections from AS 814, the session ID, and the port # of the PINE. At this stage, PEMC 808 may update the context token to include the new PEGC-T related information.

[0122] The PCS may parse the context token to determine the PINE ID and PEGC-T information. Based on this information, the PCS may retrieve PEGC-T policy information and update the context token. The PCS may also retrieve the application server ID, AS IP address, and service ID from the context token to determine the appropriate AS for restoring service continuity. The PCS may notify AS814 (832) about SC processing for the PINE by sending an Enable SC message. The message may include the PINE ID, session ID, and context token, which may have PEGC-S, PEGC-T, application context, and policy related information.

[0123] The flag buffering at the AS can be indicated in the enable SC message (832) from PCS 812. If buffering is enabled at AS 814, this flag can be set to true. Alternatively, if buffering is not enabled at AS 814, this flag can be set to false. In this scenario, buffering can be enabled at AS 814, so the flag buffering at the AS = true. AS 814 can identify the session based on PINE ID and / or session ID. AS 814 can parse the context token to determine the application context, PEGC information and policy. Based on these, AS 814 can start buffering the data packets (834) from the last sent application packet to PEGC-S 804. AS 814 can update the context token with the last sent application packet of PEGC-S information.

[0124] After reconfiguring the PIN (836), the PEMC 808 may deactivate the PEGC-S 804 so that all network resources reserved for the PEGC-S 804 in the PIN may be released and all service sessions through the PEGC-S 804 may be terminated. The endpoint information and ID of the PEGC S may be removed from the repository of the PEMC.

[0125] PEGC-T 806 may already be configured with the SC for the incoming PINE 802. Therefore, at this stage, PEMC 808 may initiate a connection between PINE 802 and PEGC-T 806. Establishing PINE connectivity with the new gateway client may allow communication between PINE 802 and AS 814 through PEGC-T 806. PEMC 808 may send a message (838) to PINE 802 initiating a connection with the PEGC-T, which may include a PEGC-T ID and a PEGC-T IP address.

[0126] PINE may send a connect confirm message (840) to PEMC 808 to update PEMC 808 with respect to the session ID and the port number that PINE 802 has reserved for the incoming connection from AS 814. When PEMC 808 receives the connectivity confirm message from PINE 802, PEMC 808 may notify PCS 812 by sending a resume session message (842) that PINE 802 is configured and ready to resume service continuity through PEGC-T 806. The message (842) may include a PEGC-T ID and a context token. According to Table 1, the context token may include one or more of a PEGC-T IP address, a PEGC-T port #, a PINE ID and a PINE IP address, a session type and session ID, an AS ID, a service ID, a PINE policy, and / or an updated application context (if any). PCS 812 may parse the context token to verify the AS ID and / or the AS IP address based on the PINE ID and the policy information.

[0127] PCS 812 may send a Resume SC command (844) to AS 814 to resume the service session with PINE 802 through PEGC-T 806 by sending PEGC-T related information. Such information may include, for example, a PEGC-T ID and IP address (this information may help AS 814 identify PEGC-T 806 and initiate routing for packet delivery), a PINE ID and IP address (which may enable identification of the PINE to which the session will be resumed), a port # of a port reserved for session establishment between AS 814 and PEGC-T 806, a session ID, and a context token. The session ID may be an identifier of the session that AS 814 will establish with PINE 802 through PEGC-T 806 and the corresponding port number at which the session terminates. The context token may include a PIN ID and a policy of PINE 802.

[0128] After receiving the configuration information, AS 814 may configure the session 846. In doing so, AS 814 may change the IP address from PEGC-S 814 to PEGC-T 806, change to a new port # provided by PEGC-T 806, include the PINE address in the packet header, use the session ID to identify the buffer, and release the buffer from the last sent data packet for the given session ID.

[0129] Fig. 9 is another example of a signal diagram 900 for implementing service continuity. The initial message exchange for service continuity may be similar to Fig. 7A and related descriptions, and this stage may be referred to as the SC subscription initial message (916). Fig. 9 In the illustrated example, PINE 902 may have a session established with AS 914 for consuming services such as streaming, monitoring, and / or AI / ML via 5GS 910. AS 914 may provide a computing platform for hosting applications consumed by PINE 902. Fig. 9 In the illustrated example, while the PINE 902 may be involved in an ongoing service session (918) with the AS 914, in the event that the PINE 902 cannot connect to the PEGC, it may subscribe to a PIN Configuration Server (PCS) 912 for service continuity (SC). In a subscription request (920), the PINE 902 may send one or more of its PINE ID (PE ID) (which may be a PINE unique identifier, which may be any of, for example, a GPSI, an IP address, an MSISDN, etc.), an indication that SC is required for all sessions (which may be as simple as a flag indicating that SC is required for all sessions), and / or IDs of individual sessions (which may be a list of specific session IDs for which SC is requested). For all sessions, the subscription request (920) may optionally include information that all sessions running at the PINE may be included. This subscription request (920) from the PINE 902 to the PCS 912 may be sent over the user plane using an application layer mechanism such as a REST API. Alternatively, the PINE 902 may request a SC with the same set of information from the PEMC 908. The PEMC 908 may obtain the request authorized by the PCS 912.

[0130] Upon receiving a request from a PINE 902 or PEMC 908, PCS 912 may authorize (922) PINE 902 to the SC and create context information, such as a context token, as described in detail above. Referring to Table 1 above, context information such as a context token may include information such as a PINE ID of the PINE 902, a PINE policy, a location from which the PINE 902 is consuming services (e.g., Fig. 9The PCS 912 may send an enable SC message (924) to a PINE with management capability (PEMC) 908, and may provide context information to allow the PEMC 908 to track the PINEs including the PINE 902 and associated sessions that require SC.

[0131] The PEMC 908 may parse the context token to determine the authorized PINE for SC processing. The PEMC may also determine the PEGC associated with the PINE 902, such as PEGC-S 904. The PEMC 908 may notify the PEGC-S 904 of the PINE 902 and the sessions that are eligible for SC by sending an Enable SC message (926). In the same message, the PEMC 908 may also send the context token to the PEGC-S 904. The PEGC-S 904 may parse the context token to identify the PINE 902 and the sessions that require SC.

[0132] Events such as PINE mobility may cause the PINE 902 to lose connectivity with the PEGC-S 904. It may be assumed that when connectivity is lost (928), the PEGC client may obtain event notifications from lower layers, such as connectivity loss events (e.g., Wi-Fi, BT L2 events), which may include a device ID or a PINE ID. Based on the PINE ID, the PEGC 904 may retrieve a context token, identify a session ID, or otherwise detect that the PINE 902 has lost contact with the PEGC-S 904 (930). The PEGC 904 may also store the last packet successfully sent for the session when connectivity was lost.

[0133] Events such as PINE mobility may cause the PINE 902 to lose connectivity with the PEGC-S 904 and may result in service interruption. Even though the PINE 902 may lose connectivity with the AS 914, the PEGC-S 904 may still maintain a live service session (934) with the AS 914. This event may trigger buffering (936) of application data packets sent from the AS 914 to the PINE 902 at the PEGC-S 904. Packet buffering (936) at the PEGC-S 904 may be initiated for undelivered packets, marked with a packet marker, and may be scheduled to be sent to the PINE 902 once it regains connectivity.

[0134] PINE 902 may find a new PEGC client (PEGC-T 906) and connect to PEGC-T 906 (938). PEMC 908 may know that PINE 902 has been connected to PEGC-T 906. Alternatively, PEGC-T 906 may also notify PEMC 908 of the new PINE connectivity. In a scenario where PEGC-S 904 and PEGC-T 906 are not managed by the same PEMC, an inter-PEMC process of exchanging SC context tokens may be required. The inter-PEMC process may include PEGC-T 906 notifying the new PEMC that it needs a SC. The new PEMC may request SC information for PINE 902 from the PIN server by sending the PINE ID. Based on the PINE ID, the PIN server may send the old PEMC information. The new PEMC may contact the old PEMC to obtain a context token. The context token may list information of one or more sessions that require service continuity. The new PEMC may parse the context token to identify the PINE, session ID, AS ID, policy, etc. The new PEMC may update the context token with new information such as PEGC-T information. This process may be referred to as the admission process (940) for PINE 902 and PEGC-T 906.

[0135] PEMC 908 may configure PEGC-T 906 for service continuity with incoming PINE 902. PEMC 908 may send a PEGC configuration message (942) that may include a PINE ID and / or a context token, and may set a flag to activate SC. PEGC-T 906 may establish a session with PINE 902 based on the PINE ID and / or policy information. PEGC-T 906 may establish a port # for receiving incoming packets from AS 914, configured to receive packets from AS 914 using the AS ID and AS IP address. Optionally, a flag to activate SC may be indicated in the message. If the flag to activate SC is set to true, the PEGC-T 906 may be enabled to establish a session with PINE 902 based on the PINE ID and policy information. The flag may also be set to remain or false; in those cases, the PEGC-T 906 may not begin to establish a session with PINE 902.

[0136] The PEMC 908 may send an Update SC message (944) to the PCS 912. This message may provide the PCS 912 with information that a SC for the PINE 902 will be initiated via the PEGC-T 906. The Update SC message may include the PINE ID, PEGC-T ID, Port #, and IP address of the PINE 902 that requires service continuity (which may be used by the AS 914 to restore service via the PEGC-T 906), the PEGC-S IP address and Port # (allowing the PCS 912 to notify the AS 914 that the service session established with Port #2 of the PEGC-S should be terminated and the service session restored for the PINE 902 with the Port # of the PEGC-T). The context token may be updated by the PEMC 908 with the new PEGC-T information.

[0137] PCS 912 may notify AS 914 of SC processing for PINE 902 by sending an Enable SC message (948). The message may contain a context token, which may include a PINE ID, a session ID, an IP address of PEGC S 904, and / or a port # of PEGC S 904. AS 914 may identify a session based on the PINE ID, the session ID, and the PEGC address. A flag buffered at the AS may be indicated in this message. If buffering is enabled at AS 914, this flag may be set to true. Alternatively, if buffering is not enabled at AS 914, this flag may be set to false. In this scenario, buffering may be enabled at PEGC S 904. Therefore, the flag buffered at the AS = false.

[0138] The PEMC may send a release buffer command (946) to the PEGC-S 904. In this message, the PEMC 908 may send information of the PEGC-T to the PEGC-S 904 to enable buffer release to the PEGC-T 906. The list of information in the release buffer message may include: the PE ID of the PINE 902 (for which buffering is enabled in the PEGC-S 904), the PEGC-TID and IP address information required to release the buffer to the PEGC-T 906, the session identifier and port #2 required to identify the buffer corresponding to the specific service session terminated at port #2, and the context token with updated PEGC-T related information received by the PCS 912 from the PEMC 908. In the case where the PEGC-S 904 and the PEGC-T 906 are managed by different PEMCs, the above-mentioned release buffer information may be followed. Fig. 7A Describes the context token exchange process between PEMCs.

[0139] At this stage, PEGC-S 904 may establish a session to transfer the buffered packets to PEGC-T 906 (950). Once the buffered transfer is complete, the session may be deleted, resources belonging to the session may be released, and PINE 902 may receive the buffered data through PEGC-T 906.

[0140] When sending the buffered data is complete, PEGC-T 906 may send a restore service message (952) to PCS 912. This message may include information such as PINE ID, PEGC-T ID, and IP address, port #, and session ID. The context token may be parsed to retrieve the application server ID, AS IP address, and service ID to determine the appropriate AS for restoring service continuity.

[0141] In the resume service message (952), PEGC-T 906 may explicitly send packet marking information to inform PCS 912 that the session is scheduled to be resumed from a given marked packet number. PCS 912 may send a resume SC command (954) to AS 914 to resume the service session with PINE 902 through PEGC-T 906 by sending PEGC-T related information. This information may include, for example, PEGC-T ID and IP address. This information may help AS identify PEGC-T 906 and initiate routing for packet delivery from the marked packet. Such information may also include PINE ID and IP address, which may enable identification of PINE902 where the session will be resumed. Such information may also include port #, session ID and context token of the port reserved for session establishment between AS 914 and PEGC-T 906. Session ID may be an identifier of the session that AS 914 will establish with PINE 902 through PEGC-T 906 and the corresponding port number at which the session terminates. The context token may include the PIN ID and the policy of the PINE 902 .

[0142] After receiving the configuration information, AS 914 may configure the session. This may be accomplished, for example, by changing the IP address from PEGC-S 904 to PEGC-T 906, changing to a new port # provided by PEGC-T 906, including the PINE address in the packet header, and using the packet marking information to resume sending application data from the marked packets. The session may thus be resumed between AS 914 and PINE 902 via PEGC-T 906 (956).

[0143] Fig.10 is a signal diagram 1000 of another example of implementing SC, where simultaneous sessions are enabled for PINE 1002. The initial message exchange (1016) may be similar to Fig. 9 and the first few messages in the relevant description.

[0144] PINE 1002 may have a session established with AS 1014 for consuming services such as streaming, monitoring, and / or AI / ML via 5GS 1010. AS 1014 may provide a computing platform for hosting applications consumed by PINE 1002. Fig.10 In the illustrated example, although PINE 1002 may be involved in an ongoing service session (1018) with AS 1014, in the event that PINE 1002 cannot connect to PEGC-S 1004, it may subscribe to SC from PCS 1012. In a subscription request (1020), PINE 1002 may send one or more of its PINE ID (PE ID) (which may be a PINE unique identifier, which may be any of, for example, GPSI, IP address, MSISDN, etc.), an indication that SC is required for all sessions (which may be as simple as a flag indicating that SC is required for all sessions), and / or IDs of individual sessions (which may be a list of specific session IDs for which SC is requested). For all sessions, the subscription request (1020) may optionally include information that all sessions running at the PINE may be included. This subscription request (1020) from PINE 1002 to PCS 1012 may be sent on the user plane using an application layer mechanism such as a REST API. Alternatively, PINE 1002 may request a SC with the same set of information from PEMC 1008. PEMC 1008 may obtain the request authorized by PCS 1012. PINE 1002 may also send information about whether it can support simultaneous sessions in a SC subscription message (1020).

[0145] Upon receiving a request from PINE 1002 or PEMC 1008, PCS 1012 may authorize (1022) PINE 1002 to the SC and create context information, such as a context token, as described in detail above. Referring to Table 1 above, context information such as a context token may include information such as the PINE ID of PINE 1002, PINE policy, where PINE 1002 is consuming services (e.g., Fig.10 The PCS 1012 may send an enable SC message (1024) to a PINE with management capability (PEMC) 1008, and may provide context information to allow the PEMC 1008 to track the PINEs including the PINE 1002 and the associated sessions that require SC.

[0146] PEMC 1008 may parse the context token to determine the authorized PINE for SC processing. The PEMC may also determine the PEGC associated with PINE 1002, such as PEGC-S 1004. PEMC 1008 may notify PEGC-S 1004 of the PINE 1002 and the sessions that are eligible for SC by sending an Enable SC message (1028). In the same message, PEMC 1008 may also send the context token to PEGC-S 1004. PEGC-S 1004 may parse the context token to identify PINE 1002 and the sessions that require SC. In addition, PEMC may send an Enable SC message (1030) to PINE 1002 along with the credentials so that PINE 1002 may be able to discover PEGC clients in its vicinity.

[0147] Events such as PINE mobility may result in the possibility that PINE 1002 loses connectivity with PEGC-S 1004, resulting in a service interruption. Therefore, PINE 1002 may discover another PEGC client (PEGC-T 1006) in its vicinity using the generic credentials (1032). PINE 1002 may notify PEMC 1008 of the PEGC-T discovery by sending a PEGC-T found for simultaneous sessions SC message (1034) to PEMC 1008. PEMC 1008 may send specific credentials to establish a simultaneous connection with PEGC-T 1006 by sending an Enable SC Simultaneous Sessions message (1036) to PINE 1002. PINE 1002 may preemptively and establish another connection with PEGC-T 1006. PEMC 1008 may be aware that PINE 1002 has established simultaneous connections with PEGC-S 1004 and PEGC-T 1006.

[0148] In a scenario where PEGC-S 1004 and PEGC-T 1006 are not managed by the same PEMC, an inter-PEMC process of exchanging SC context tokens may be required. The process may include PEGC-T 1006 notifying the new PEMC that it needs a SC. The new PEMC may request SC information for PINE 1002 from PCS 1012 by sending the PINE ID. Based on the PINE ID, PCS 1012 may send the old PEMC information. The new PEMC may contact the old PEMC to obtain a context token. The context token may list information about one or more sessions that require service continuity. The new PEMC may parse the context token to identify the PINE, session ID, AS ID, policy, etc., and the new PEMC may update the context token with new information such as PEGC-T information.

[0149] PEMC 1008 may configure PEGC-T 1006 for service continuity with incoming PINE 1002. PEMC 1008 may send a PEGC configuration message (1038) that may include a PINE ID and a context token. Optionally, a flag activating SC may be indicated in the message. If the flag activating SC is set to true, PEGC-T (1006) may establish a specific session requiring SC with the PINE based on the PINE ID. Session-specific information such as session ID, session type, QOS, etc. may be retrieved from the context token. The flag may also be set to hold or false. In those cases, PEGC-T 1006 will not start session establishment with PINE 1002 and may wait for instructions from PEMC 1008 in the future. PEGC-T 1006 may establish a port # for receiving incoming packets from AS 1014. This may be configured to receive packets from AS 1014 using AS ID and / or AS IP address.

[0150] PEGC-T 1006 may send a secondary session establishment request message (1040) to PCS 1012 to provide the PE ID (PINE ID) for which the secondary session is requested. In addition, PEGC-T 1006 may send its own ID and IP address to notify that a secondary session for a given PE ID (PINE ID) needs to be established by PEGC-T 1006. PCS 1012 may parse the context token and retrieve: the application server ID and service ID, which are used to identify AS 1014 and the service being consumed by PINE 1002; the session ID (an identifier of a session established between AS 1014 and PINE 1002 that needs to be repeated); and the reserved port number. The reserved port number may be sent to PCS 1012 to notify PEGC-T 1006 that a secondary session will be established on the given port number.

[0151] PCS 1012 may send a copy session message (1042) to AS 1014 to conduct a secondary service session with PINE 1002 via PEGC-T 1006. The secondary session may be used for replication, redundancy, and / or aggregation. To replicate the service session, PCS 1012 may send all necessary PEGC-T related information to AS 1014, including: PEGC-T ID (PEGC-T identifier), PEID (PINE ID), and the IP address of PINE 1002 that AS 1014 will use to replicate the session, the port # of the reserved port established for the secondary session between AS 1014 and PEGC-T 1006, the session ID (the identifier of the session that needs to be replicated and the corresponding port number where the session terminates), and the context token. The context token may include the PIN ID and the policy of PINE 1002 (e.g., specifying that the PINE supports simultaneous sessions for the same service).

[0152] When the duplicate session establishment (1044) with PINE 1002 by PEGC-T 1006 is complete, PEGC-T 1006 may send a duplicate session information message (1046) to PEMC 1008. The message may include the PINE identifier for which the duplicate session is being established, as well as other information such as a session ID, port number, and context token.

[0153] Upon receiving the context information of the duplicate session, the PEMC 1008 may trigger a local PIN timer (1048) to observe whether any of the following events occurs before the threshold time set by the PEMC expires: one of the duplicate sessions is disconnected due to PINE mobility resulting in loss of connectivity with the PEGC-S 1004 or PEGC-T 1006, or one of the PEGC clients (PEGC-S 1004 or PEGC-T 1006) is lost due to PIN reconfiguration. If either of these two events occurs, the PEMC 1008 may stop and delete the timer. If neither of the above two events occurs and the duplicate session of the same PINE is maintained, in this case, the PEMC 1008 may delete one of the duplicate sessions. The decision to delete one of the duplicate sessions may be based on the PINE policy or based on evaluating the QoS performance of the session.

[0154] PEMC 1008 may send a duplicate session end message to PCS 1012 (1050). In this message, PEMC 1008 may inform PCS 1012 that one of the duplicate sessions selected based on the above criteria may need to be interrupted. PCS 1012 may forward the duplicate session end message to AS 1014 (1052). PCS 1012 may send the PINE ID, PEGC-S or PEGC-T ID and IP address in this message as well as the session ID and port number (depending on the session selected for deletion). Based on this information from PCS 1012, AS 1014 may configure the session by deleting one of the sessions (1054) based on the session ID sent by PEMC 1008 (the session ID corresponding to the session from PEGC-S 1004 or PEGC-T 1006), and including the PINE address in the packet header.

[0155] PINE 1002 may also initiate a repeated session end message. Session selection may be made at a general system level with the help of Quality of Experience (QoE) metrics such as throughput, reliability, mean opinion score, etc. Alternatively, the repeated session end message may be sent by AS 1014. However, AS 1014 may not have all the local QoS policy related information between PINE 1002 and PEGC to make an optimal choice when ending either of the two sessions with PINE 1002.

[0156] Fig.11 1108 is a signal diagram for another example of service continuity through 5GS1108. This process allows WTRU / PINE to connect directly to AS1112 through 5GS1108 without any PEGC client.

[0157] The initial message exchange for SC can be similar to Fig. 9 and related descriptions, and this stage may be referred to as the SC subscription initial message (1128). Fig.11 In the illustrated example, PINE 1102 may have a session established with AS 1112 for consuming services such as streaming, monitoring, and / or AI / ML via 5GS 1108. AS 1112 may provide a computing platform for hosting applications consumed by PINE 1102. Fig.11In the illustrated example, although PINE 1102 may be involved in an ongoing service session (1114) with AS 1112, in the event that PINE 1102 cannot connect to PEGC 1104, it may subscribe to PCS 1110 for service continuity (SC). In a subscription request (1116), PINE 1102 may send one or more of its PINE ID (PE ID) (which may be a PINE unique identifier, which may be any of, for example, GPSI, IP address, MSISDN, etc.), an indication that SC is required for all sessions (which may be as simple as a flag indicating that SC is required for all sessions), and / or IDs of individual sessions (which may be a list of specific session IDs for which SC is requested). For all sessions, the subscription request (1116) may optionally include information that all sessions running at PINE 1102 may be included. This subscription request (1116) from PINE 1102 to PCS 1110 may be sent on the user plane using an application layer mechanism such as a REST API. Alternatively, the PINE 1102 may request a SC with the same set of information from the PEMC 1106. The PEMC 1106 may obtain the request authorized by the PCS 1110.

[0158] Upon receiving a request from PINE 1102 or PEMC 1106, PCS 1110 may authorize (1118) PINE 1102 to the SC and create context information, such as a context token, as described in detail above. Referring to Table 1 above, context information such as a context token may include a PINE ID such as PINE 902, a PINE policy, a location from which PINE 1102 is consuming services (e.g., Fig.11 The PCS 1110 may send an enable SC message (1120) to a PINE with management capability (PEMC) 1106 and may provide context information to allow the PEMC 1106 to track the PINEs including the PINE 1102 and the associated sessions that require SC.

[0159] PEMC 1106 may parse the context token to determine the authorized PINE for SC processing. The PEMC may also determine the PEGC associated with PINE 1102, such as PEGC-S 1104. PEMC 1106 may send an enable SC command (1122) to PINE 1102, which may update PINE 1102 with the SC subscription context token. This context token may be parsed by PINE 1102 to connect to AS 1112 via 5GS 1108.

[0160] Events such as PINE mobility (1124) may cause PINE 1102 to lose connectivity with PEGC-S 1104 and possibly leave PIN network coverage, resulting in service interruption. It may be assumed that when connectivity is lost, the PEGC client may obtain event notifications (1126) from lower layers, such as connectivity loss events (e.g., Wifi, BT L2 events), which may include device IDs or PINE IDs. Based on the PINE ID, PEGC 1104 may retrieve a context token and identify a session ID. PEGC 1104 may also store the last packet successfully sent for the session when connectivity was lost.

[0161] After receiving the connectivity loss event notification, the PEGC client 1104 may send an activation SC message (1130) to the PCS 1110, which includes the PE ID of the PINE it lost and its own IP address and context token. The PEGC-S 1104 may also send a packet marker to the PCS 1110, which is set to the last packet successfully sent. At the same time, the PINE 1102 may not be able to connect to any PEGC client (for example, the PINE is not under PIN coverage). The PCS 1110 may notify the AS 1112 by sending an enable SC message (1134) with a list of WTRU related information. The list may include the PE ID and the IP address of the PINE / WTRU, the session identifier and port number, the packet marker, and the context token. The session identifier and port number may be sent so that the AS 1112 can track the corresponding PINE session. The packet marker may be set to the last packet successfully received at the PEGC-S 1104. The context token may include the PINE / WTRU policy and location.

[0162] The AS may buffer application data packets (1136) from the packet marker provided by the PCS 1110 until the PINE / WTRU resumes service session connectivity. When the PINE 1102 is outside of PIN coverage and connected to the 5GS 1108, it may be represented as a WTRU (i.e., a 3GPP connected device). The PINE may send a message PIN_ResumeSC_5GS (1138) to the PCS 1110 to notify it that it wants to resume connectivity with the AS 1112 through the 5G core. The list of information provided with the message may include the PINE ID and IP address for identification and data plane routing to the PINE, the port # and session ID reserved for establishing a service session with the AS 1112, and a context token that may primarily include the location of the PINE / WTRU.

[0163] The PCS 1110 may prepare to establish a session between the AS 1112 and the PINE / WTRU. The process for establishing the session (1140) may include the PCS 1110 checking the policy related to the PINE and updating the PINE / WTRU profile to indicate that the PINE 1102 has left the PIN. The PCS 1110 may initiate a 5GS PDU session establishment / modification process via the NEF. After completing the 5GS related process, the PCS may send a ResumeSC_5GS command (1142) to the AS (1112). In order to be able to resume service continuity, the AS 1112 may be provided with one or more of the PINE / WTRU identifier, the PINE IP address, the PIN port number, the session ID, and the context token.

[0164] After receiving the configuration information, AS1112 can resume SC with PINE 1102 by changing the PEGC-SID to the 5G UPF endpoint identifier, changing to the new port # provided by PINE 1102, including the PINE address in the packet header, using the session ID to identify the buffer, and using packet marking to release the buffer and resume service.

[0165] Although the features and elements are described above in specific combinations, it will be understood by those of ordinary skill in the art that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as built-in hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: Transceiver; and processor, wherein the transceiver and the processor are configured to receive a first message from a personal Internet of Things (IoT) network (PIN) server (PCS), wherein the first message includes context information, the context information including at least an identifier of at least one PIN element (PINE) being authorized for service continuity (SC), an identifier of at least one session established for the at least one PINE with an application server (AS), and an identifier of a first PIN gateway (PEGC) providing 3GPP network services to the at least one PINE for the at least one session, wherein the transceiver and the processor are further configured to receive a second message from the first PEGC, wherein the second message indicates a loss of connectivity with the at least one PINE and includes the identifier of the at least one PINE and the context information, wherein the transceiver and the processor are further configured to determine that the at least one PINE is authorized to connect to a second PEGC and to update the context information to include an identifier of the second PEGC, and The transceiver and the processor are further configured to send a third message to the second PEGC, wherein the third message includes at least the identifier of the at least one PINE, updated context information, and an indication that the second PEGC activates the SC of the PINE.

2. The WTRU of claim 1 , wherein the second message further comprises a marker of the last packet successfully sent for the at least one session, and wherein the transceiver and the processor are further configured to forward the second message to the PCS.

3. The WTRU of claim 1 or 2, wherein the transceiver and the processor are further configured to send a fourth message to the first PEGC after sending the third message to the second PEGC, wherein the fourth message includes an indication that the first PEGC is able to remove resources and delete information related to the context information.

4. The WTRU according to any one of claims 1 to 3, wherein the transceiver and the processor are further configured to send a fifth message to the PCS after sending the third message to the second PEGC, wherein the fifth message includes a request for the PCS to establish a new session between the PINE and the AS and the updated context information.

5. The WTRU of any one of claims 1 to 4, wherein the PINE is a non-3GPP device configured to communicate with other PINEs in the PIN using non-3GPP communications.

6. The WTRU according to any one of claims 1 to 5, wherein the 3GPP network service is a 5G network service.

7. The WTRU of any one of claims 1 to 6, wherein the at least one session with the AS is used for at least one of streaming, monitoring, artificial intelligence (AI), or machine learning (ML).

8. A WTRU according to any one of claims 1 to 7, wherein the context information also includes at least one of the following: an identifier of the PIN, a list of multiple PINEs including the PINE that subscribe to SC services, a type of each PINE in the list, a PINE policy that manages the behavior of the multiple PINEs in the PIN, or an identifier of one or more services in the AS that the multiple PINEs are using.

9. The WTRU of any one of claims 1 to 8, wherein the transceiver and the processor are configured to determine that the PINE is connected to the second PEGC based on receiving a message containing information about the at least one PINE from the second PEGC or detecting that the at least one PINE is already connected to one of the second PEGCs.

10. The WTRU of any one of claims 1 to 9, wherein the WTRU is a PIN manager (PEMC).

11. The WTRU of any one of claims 1 to 10, wherein the context information is a context token.

12. A WTRU according to any one of claims 1 to 11, wherein the first message is an SC enable message, the second message is an SC activation message, the third message is a PEGC configuration message, the fourth message is an SC completion message, and the fifth message is an SC establishment message.

13. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: receiving a first message from a personal internet of things (IoT) network (PIN) server (PCS), wherein the first message includes context information including at least an identifier of at least one PIN element (PINE) being authorized for service continuity (SC), an identifier of at least one session established for the at least one PINE with an application server (AS), and an identifier of a first PIN gateway (PEGC) providing 3GPP network services to the at least one PINE for the at least one session; receiving a second message from the first PEGC, wherein the second message indicates a loss of connectivity with the at least one PINE and includes the identifier of the at least one PINE and the context information; determining that the at least one PINE is authorized to connect to a second PEGC; updating the context information to include an identifier of the second PEGC; as well as A third message is sent to the second PEGC, wherein the third message includes at least the identifier of the at least one PINE, updated context information, and an indication that the second PEGC activates the SC of the PINE.

14. The method of claim 13, wherein the second message further comprises a marker of a last packet successfully sent for the at least one session, and wherein the method further comprises forwarding the second message to the PCS.

15. The method according to claim 13 or 14, the method further comprising sending a fourth message to the first PEGC after sending the third message to the second PEGC, wherein the fourth message contains an indication that the first PEGC can remove resources and delete information related to the context information.

16. The method according to any one of claims 13 to 15, further comprising sending a fifth message to the PCS after sending the third message to the second PEGC, wherein the fifth message includes a request for the PCS to establish a new session between the PINE and the AS and the updated context information.

17. The method of any one of claims 13 to 16, wherein the PINE is a non-3GPP device configured to communicate with other PINEs in the PIN using non-3GPP communications.

18. The method according to any one of claims 13 to 17, wherein the 3GPP network service is a 5G network service.

19. The method according to any one of claims 13 to 18, wherein the at least one session with the AS is used for at least one of streaming, monitoring, artificial intelligence (AI), or machine learning (ML).

20. A method according to any one of claims 13 to 19, wherein the context information also includes at least one of the following: an identifier of the PIN, a list of multiple PINEs including the PINE that subscribe to SC services, a type of each PINE in the list, a PINE policy that manages the behavior of the multiple PINEs in the PIN, or identifiers of one or more services in the AS that the multiple PINEs are using.

21. The method of any one of claims 13 to 20, wherein determining that the at least one PINE has been connected to a second PEGC is based on one of receiving a message from the second PEGC containing information about the PINE or detecting that the PINE has been connected to the second PEGC.

22. The method of any one of claims 13 to 21, wherein the WTRU is a PIN manager (PEMC).

23. A method according to any one of claims 13 to 22, wherein the context information is a context token.

24. The method according to any one of claims 13 to 23, wherein the first message is an enable SC message, the second message is an SC activation message, the third message is a PEGC configuration message, the fourth message is an SC completion message, and the fifth message is an SC establishment message.

Images