Service continuity associated with changing from direct mode to inter-PINE communication using intermediate PEGC

Abstract

Systems and methods for service continuity are described herein. For example, if (e.g., when) an inter-wireless transmit / receive unit (WTRU) communication is changed from a direct mode to using a WTRU having an intermediate gateway capability, service continuity may be performed and / or provided. A personal Internet of Things network (PIN) may be used. The WTRU may be part of a PIN. The WTRU in the PIN may be referred to as a PIN element (PINE). The WTRU and / or PINE in the PIN may be associated with different capabilities. For example, a PINE in the PIN may be a PINE (PEGC) with gateway capability. For example, a PINE in the PIN may be a Management Capable PINE (PEMC).

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0003] Mobile communications using wireless communications continue to evolve. The fifth generation may be referred to as 5G. Previous (legacy) mobile communications may be, for example, fourth generation (4G) Long Term Evolution (LTE). Summary of the invention

[0004] Systems and methods for service continuity are described herein. For example, if (e.g., when) communications between wireless transmit / receive units (WTRUs) are changed from direct mode to using a WTRU with intermediate gateway capabilities, service continuity may be performed and / or provided. A personal Internet of Things network (PIN) may be used. The WTRU may be part of a PIN. The WTRU in the PIN may be referred to as a PIN element (PINE). The WTRU and / or PINE in the PIN may be associated with different capabilities. For example, the PINE in the PIN may be a PINE with gateway capabilities (PEGC). For example, the PINE in the PIN may be a PINE with management capabilities (PEMC).

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

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

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

[0008] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within an illustrated communication system.

[0009] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of an example Radio Access Network (RAN) and an example Core Network (CN) for use within an illustrated communication system.

[0010] Figure 1D is an example of a method that can be used according to an embodiment of the present invention. Figure 1A System diagram of another example RAN and another example CN for use within the illustrated communication system.

[0011] Figure 2 An example of a home automation Personal Internet of Things Network (PIN) is illustrated.

[0012] Figure 3An example wearable PIN is illustrated.

[0013] Figure 4 An example PIN architecture is illustrated.

[0014] Figure 5 An example PIN application architecture is illustrated.

[0015] Figure 6 Example service continuity through PEGC is illustrated.

[0016] Figure 7 An example of service continuity through two or more PEGCs is illustrated.

[0017] Figure 8 An example procedure for service continuity ALT1 is illustrated.

[0018] Fig. 9 An example process for service continuity is illustrated.

[0019] Fig.10 An example process for service continuity is illustrated. DETAILED DESCRIPTION

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

[0021] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, 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 UE 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and / or "STA") may be configured to send and / or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular 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 WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0022] 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 that is configured to interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106 / 115, the Internet 110, and / or 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 (gNB), an 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.

[0023] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. 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. A cell may be further divided into cell sectors. For example, a 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.

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

[0025] 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. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

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

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

[0030] Figure 1AThe 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, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN 106 / 115.

[0031] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have 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 / 115 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 text and video, the CN 106 / 115 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. 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 / 115 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. Figure 1A Although not shown in the figure, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0032] The CN 106 / 115 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 / 113 or a different RAT.

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

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

[0035] 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) circuit, any other type of integrated circuit (IC) and 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.

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

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

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

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

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

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

[0042] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, and an activity tracker, etc. The peripheral device 138 may include one or more sensors, which 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 geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0043] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via signal processing performed via 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 WRTU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0047] 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 (or PGW) 166. While each of the foregoing elements are depicted as being 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.

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

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

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

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

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

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

[0054] 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 destination. 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 destination 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.

[0055] 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 width dynamically set via signaling. 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 sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0056] High throughput (HT) STAs 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.

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

[0058] 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 instrument type control / machine type communications, 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).

[0059] WLAN systems and channel bandwidths that can support multiple channels (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 (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

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

[0062] The RAN 113 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, 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).

[0063] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable parameter sets. 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 transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or varying absolute time lengths over time).

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

[0065] 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, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

[0066] Figure 1DThe illustrated CN 115 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 each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 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 PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of 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 mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0068] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 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 enforcement and QoS, and providing downlink data notifications. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

[0069] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 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 downlink packets, and providing mobility anchoring, etc.

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

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

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

[0073] 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 lab 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.

[0074] Systems and methods for service continuity are described herein. For example, if (e.g., when) communication between wireless transmit / receive units (WTRUs) is changed from direct mode to, for example, using a WTRU with intermediate gateway capabilities, service continuity may be performed and / or provided. A personal Internet of Things network (PIN) may be used. The WTRU may be part of a PIN. The WTRU in the PIN may be referred to as a PIN element (PINE). The WTRU and / or PINE in the PIN may be associated with different capabilities. For example, the PINE in the PIN may be a PINE with gateway capabilities (PEGC). For example, the PINE in the PIN may be a PINE with management capabilities (PEMC).

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

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

[0077] A personal IoT network may be provided and / or used.

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

[0079] For example, if (e.g., when) multiple IoT devices are deployed in an environment (e.g., a private environment), WTRUs with IoT capabilities may be organized in a personal IoT network (PIN). For example, in a home environment, security sensors, smart lights, smart plugs, printers, cellular phones may be managed (e.g., by a residential gateway) and may communicate with each other. In this case, (e.g., all) devices in the home may constitute a personal IoT network (PIN). A device (e.g., each of the devices) may include (e.g., referred to as) a PIN element, and different PIN elements may have different capabilities. For example, a residential gateway may include a PIN element (PEGC) with gateway capabilities that provides connections between PIN elements and connections between a network and one or more PIN elements. A PIN element (PEMC) with management capabilities may be a PIN element that provides a component for (e.g., enabling) configuration and management of a PIN (e.g., an authorized administrator to configure and manage a PIN), for example, a residential gateway that may be used as a PEGC may also support PIN management functions and may be a PIN element with management capabilities.

[0080] Figure 2 An example of a home automation PIN is illustrated. Wearable devices may constitute another type of PIN. A smartphone may be used as a PIN element with gateway capabilities (PEGC) and a PIN element with management capabilities (PEMC). Smart watches, VR / AR glasses, and / or Apple wireless headphones may communicate with each other in a PIN or with other WTRUs via a network.

[0081] Figure 3 An example wearable PIN is illustrated.

[0082] Can provide personal Internet of Things network architecture.

[0083] A personal Internet of Things network (PIN) may include PIN elements (PE / PINE), PIN management (PEMC), and PIN gateways (PEGW). For example, a PIN element may be a WTRU or device that can communicate within a PIN. A PIN management device may be a PIN element that has the ability to manage a PIN. A PEGC may be a PIN element that can provide connectivity to and from a network for other PIN elements (e.g., has the ability to provide connectivity to and from a network).

[0084] Figure 4 An example personal IoT network architecture is illustrated.

[0085] PIN elements may communicate with each other (eg, via PEGC and / or directly). PIN elements may communicate with the system to obtain services or with a data network (eg, via a core network).

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

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

[0088] Application layer support may be provided and / or enabled for a Personal IoT Network (PIN).

[0089] The application layer architecture may be designed for PIN (eg, meet the requirements of PIN). The PIN application layer functional model may be supported.

[0090] An application framework for enabling PINAPP may be provided (eg, as described herein).

[0091] Figure 5 An example PINAPP architecture is illustrated.

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

[0093] If (e.g., when) a PIN element changes a communication path, such as from communication between PINEs (e.g., direct communication) to using an intermediate PEGC, service interruption can be minimized. If (e.g., when) a PIN element changes a communication path, such as from communication between PINEs (e.g., direct communication) to using one or more intermediate PEGCs, service interruption can be minimized.

[0094] Figure 6 Example service continuity through PEGC is illustrated.

[0095] PIN may include different PIN elements (e.g., sensors, AR / VR, smart TV, etc.), and these PIN elements (PINE) may have different requirements. PIN elements may interact directly (e.g., not connected through PEGC).

[0096] For example, due to the mobility of PINEs, PINEs may be out of range of each other. Service between (e.g., two) PINEs may be interrupted. A suitable PEGC may be discovered, selected, and configured to continue service through it, e.g., to achieve service continuity.

[0097] Discovery and selection of PEGCs may be performed.

[0098] The (eg, correct) PEGC discovery and selection process may be triggered (eg, from an application layer). The selected PEGC may be configured for service continuity. An application layer mechanism may be used to configure the selected PEGC for service continuity.

[0099] Figure 7 An example of service continuity through multiple PEGCs is illustrated.

[0100] In various examples (e.g., to restore service continuity between two PINEs), (e.g., more than one) PEGC may be used (e.g., required) depending on the location of the PINEs. In such a scenario, multiple PEGCs may be configured (e.g., after selection) (e.g., by an application layer mechanism) to achieve service continuity.

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

[0102] One or more PINEs interacting between PINEs may subscribe to the PEMC for service continuity. The PEMC may authorize requests from the PIN server. If the subscription is valid, the PEMC may take action to maintain service continuity, for example, if (e.g., when) the PINE loses contact and service continuity is required. Context tokens may be used to save the context of service continuity between PINEs, PEMCs, PEGCs, and / or PIN servers.

[0103] PEGC discovery may be triggered by PINE, for example, using an application mechanism.

[0104] A PINE that may have lost contact with another PINE may notify the PEMC of the service interruption. The PEMC may start a service continuity process and may (e.g., decide to) select, for example, a PEGC that may provide service continuity. The PEMC may trigger a (e.g., a specific) PEGC selection process, which may be initiated by the PINE. The PEMC may transmit a message to the PINE, for example, to trigger the PEGC selection process. The PEMC may select one or more PEGCs for service continuity, for example, if the PINE reports back to the PEMC the discovered PEGCs (e.g., after the PINE reports back to the PEMC the discovered PEGCs).

[0105] For example, PEGC may be configured using an application mechanism.

[0106] The PEMC may transmit configuration information to the PEGC (eg, configure the PEGC) for service continuity with PINE information (such as PINEID, PINE endpoint identifier, and / or policy related to service continuity for PINE). The PEGC may, for example, update a forwarding table and / or allocate resources based on the policy information.

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

[0108] PEMC can configure PINE to achieve service continuity through PEGC.

[0109] The PEMC may configure the PINE using the PEGC information (eg, transmit configuration information indicating the PEGC information). The PINE may use the PEG information to connect to the PEGC (eg, so that service may continue through the PEGC).

[0110] A context token may be used.

[0111] To implement the service continuity feature, a context token may be used. When the endpoint changes due to service continuity, the context token may be used between PINAPP application clients to retrieve endpoint information and / or application context and / or update tokens.

[0112] FIG. 1 illustrates an example of a context token.

[0113]

[0114]

[0115] Table 1: Context token data types

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

[0117] Figure 8 An example procedure for service continuity ALT1 is illustrated.

[0118] like Figure 8 As shown, at 810 , PINE1 and PINE2 may communicate (eg, directly) via (eg, any type of) D2D technology (eg, WiFi, ProSe / PC5, Bluetooth).

[0119] PINE may perform one or more of the following to achieve service continuity.

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

[0121] The PEMC may authorize the SC request to the PIN server. The PEMC may transmit the PINE IDs of (eg, two) PINEs, service types, the existence of connectivity (eg, direct connectivity) between the PINEs (eg, D2D sessions), session IDs, and the like.

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

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

[0124] like Figure 8 As shown, at 820, the PINE may lose connectivity. It may be assumed that at this point (e.g., the PINE loses connectivity) the service is interrupted. For example, by transmitting a SC Loss with the PINE ID and / or Session ID, the PINE may notify the PEMC about the service interruption. For example, if (e.g., when) the service is lost, the PINE may update the context token using the application context. For example, the application context may include one or more of the following: the state of the PINE application (e.g., such as initialization, startup, game scene 1, etc.); a data set when connectivity was lost; a counter and time value (e.g., via a timer); the last data packet received (e.g., a data packet); etc. The PINE may transmit the updated context token to the PEMC.

[0125] like Figure 8 As shown, at 830, the PEMC (eg, PIN management client) may save the updated context token and may verify whether the PINE is authorized for the SC. The PEMC may retrieve the authorized policy from the context token for (eg, each) PINE.

[0126] The PEMC (PIN Management Client) may determine that there is communication between the devices, which may be direct communication. The PEMC may determine, for example, based on the associated session ID, a PEGC that may (eg, needs to) be selected for service continuity.

[0127] The PEMC may perform (e.g., be capable of performing) various PEGC selection procedures. In this scenario, the PIN management client may select a (e.g., a specific) PEGC selection procedure, which may, for example, involve PEGC discovery by the PINE. The PIN management client may trigger the discovery procedure by transmitting a message (e.g., "start PEGC discovery for SC") to the PIN client. The message may include policy and authentication information for the PINE to start discovering the PEGC.

[0128] The PEGC discovery by the PINE may be triggered (e.g., by receiving a message "start PEGC discovery for SC"). The PINE may report the discovered PEGC information back to the PEMC. The PEMC may select a (e.g., best) PEGC. The PIN node may be involved in the PEGC discovery. For example, based on the completion of the discovery process (e.g., after the discovery process is completed), the PIN management client may be (e.g., made aware of) the selected PEGC. It may be assumed that the PIN management client is informed of the IP address, PEGCID, and / or associated policies of the selected PEGC.

[0129] In ALT 1 (e.g. Figure 8 As shown), (e.g., only one) PEGC can be selected by the PEMC. Figure 8 As shown, the PIN management client in the PEMC may configure (e.g., start configuration) the selected PEGC for service continuity at 840. The PIN management client in the PEMC may transmit a message (e.g., a selection message, such as a "Configure PEGC for SC" message) to the selected PEGC (PIN gateway client), which may include the PINE ID and context token of (e.g., two) PINEs.

[0130] The PIN gateway client may configure a forwarding table in the PEGC so that (e.g., service-related) PINE traffic may be passed back and forth. The PIN gateway client may parse the context token to perform one or more of the following: determine a policy associated with the PINE and allocate forwarding resources based on the policy; determine whether a new IP address will be allocated or whether the PINE's IP address will be restored (e.g., if the IP address will be restored, the PINE IP address may be retrieved from the context token and set correctly); determine application context and establish a forwarding path based on application state and application requirements; allocate a port number (e.g., port #) for a (e.g., specific) session (e.g., two port numbers may be allocated for two PINEs); etc.

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

[0132] like Figure 8 As shown, at 850, the PIN management client in the PEMC may instruct the PIN enabler client in the PINE to connect to the selected PEGC, for example, by transmitting a message (e.g., a "Configure PINE with PEGC Information" message). The message may include the PEGC ID, PEGC IP address, and port # created for the PINE service / session.

[0133] like Figure 8 As shown, at 860, the PINE (e.g., PIN enabler client) can establish a connection to the PEGC using the PEGC IP address, port #, etc. For example, if (e.g., when) the PINE is connected, the PEGC can use DHCP to assign a different (e.g., new) address according to the policy for the PINE. Otherwise, for example, if supported by the PEGC, the PINE IP address can be restored for seamless service continuity. For example, based on the successful establishment (e.g., after the successful establishment), the service between PINE1 and PINE2 can be continued.

[0134] Service continuity (SC) across multiple PEGCs may be enabled.

[0135] For example, if (eg, when) the PEMC selects more than one PEGC, a process for providing service continuity may be enabled.

[0136] Fig. 9 An example process for service continuity is illustrated. Fig. 9 As shown, if (e.g., when) multiple PEGCs are selected, service continuity can be provided. Fig. 9 As shown, the steps may be similar to (for example, regarding Figure 8The process described in this article can be used Figure 8 The illustrated process (e.g., Fig. 9 (For example, in Fig. 9 The process in Figure 8 The illustrated process, for example, wherein (for example, in Fig. 9 (in Chinese) Alternative 2 (ALT2) can be performed.

[0137] like Fig. 9 As shown, at 940, ALT2 may include the following. The PINE may discover the PEGC and may transmit the PEGC information to the PEMC. The PEMC may not (e.g., be unable to) find a (e.g., single) PEGC that can serve the (e.g., two) PINEs. In this case, the PEMC may select multiple (e.g., two or more) PEGCs (e.g., the best PEGC) for service continuity, such as PEGC1 and PEGC2 that can provide communication paths for PINE1 and PINE2 (e.g., such as Fig.10 shown).

[0138] Fig.10 An example process for service continuity is illustrated.

[0139] The PEMC (eg, PIN management client) may configure (eg, start configuring) the selected PEGCs (eg, PEGC1 and PEGC2) for service continuity. The PEMC may decide that PEGC1 will be used by PINEl and PEGC2 will be used by PIN2.

[0140] The PEMC may transmit a message (e.g., a selection message, such as a "Configure PEGC for SC" message) to the selected PEGCs (e.g., PEGC1 and PEGC2). The message (e.g., a selection message, such as a "Configure PEGC for SC" message) may include one or more of the following: PINE ID 1 and a context token to PEGC1; and / or PINE ID 2 and a context token to PEGC2.

[0141] (Eg., each) PEGC (e.g., PIN gateway client) can configure its forwarding table, for example, so that PINE (e.g., PINE 1 and PINE 2) traffic related to the service can be forwarded correctly. The PEGC can parse the context token, for example, to perform one or more of the following: determine the policy related to the PINE and allocate forwarding resources based on the policy; according to the policy of the PINE, when the PINE is connected, the PEGC can use DHCP to allocate a new address, otherwise if supported by the PEGC, the PINE IP address can be restored for seamless service continuity; determine the application context based on the application state and application requirements and establish a forwarding path; allocate port numbers for (e.g., specific) sessions (e.g., two may be allocated for two PINEs).

[0142] The PEGC (eg, PIN gateway client) may transmit a confirmation to the PEMC (eg, including the PEGC IP address and the port number of the PINE), eg, based on (eg, after) successful configuration.

[0143] For example, if (e.g., when) PEMC interacts with a system such as 5GS (e.g., AMF, PCF) to obtain forwarding / routing rules between selected PEGCs (e.g., PEGC1, PEGC2, etc.), PEMC (e.g., PIN management client) can trigger another process by transmitting a (e.g., internal) message (e.g., obtain packet forwarding information of SC through PEGC (PEGC list)) to the PEMCNAS layer. The system (e.g., 5GS) can transmit the forwarding rules to PEGC1 and PEGC2. PEGC Client 1 and PEGC Client 2 can update the forwarding table with the inter-PEGC forwarding rules.

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

[0145] like Fig. 9As shown, at 960, the PIN enabler clients in PINE1 and PINE2 may establish (e.g., begin establishing) connections to PEGC1 and PEGC2, for example, using PEGC IP addresses, port #s, etc. For example, based on the successful establishment (e.g., after the successful establishment), the service between PINE1 and PINE2 is continued through PEGC1 and PEGC2.

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

[0147] Although the implementation described herein may consider 3GPP specific protocols, it should be understood that the implementation described herein is not limited to such scenarios and is applicable to other wireless systems. For example, although the solution described herein considers LTE, LTE-A, New Radio (NR) or 5G specific protocols, it should be understood that the solution described herein is not limited to such scenarios and is also applicable to other wireless systems.

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

Claims

1. A wireless transmit / receive unit (WTRU), the wireless transmit / receive unit (WTRU) comprising: A processor, the processor being configured to: receiving a notification message, wherein the notification message indicates a loss of service continuity between a first personal Internet of Things network element (PINE) and a second PINE; transmitting a first discovery request message to the first PINE and transmitting a second discovery request message to the second PINE, wherein the discovery message indicates initiation of a PINE with gateway capability (PEGC) discovery; receiving a first discovery response message and a second discovery response message, wherein the first discovery response message indicates first PEGC discovery information from the first PINE, and wherein the second discovery response message indicates second PEGC discovery information from the second PINE; determining a PEGC based on the first PEGC discovery information and the second PEGC discovery information; transmitting a selection message to the determined PEGC for service continuity between the first PINE and the second PINE; receiving a confirmation message from the determined PEGC, the confirmation message indicating configuration of service continuity between the first PINE and the second PINE; as well as A first configuration message is transmitted to the first PINE, and a second configuration message is transmitted to the second PINE, wherein the first configuration message and the second configuration message indicate service continuity configuration information.

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

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

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

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

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

7. A method comprising: receiving a notification message, wherein the notification message indicates a loss of service continuity between a first personal Internet of Things network element (PINE) and a second PINE; transmitting a first discovery request message to the first PINE and transmitting a second discovery request message to the second PINE, wherein the discovery message indicates initiation of a PINE with gateway capability (PEGC) discovery; receiving a first discovery response message and a second discovery response message, wherein the first discovery response message indicates first PEGC discovery information from the first PINE, and wherein the second discovery response message indicates second PEGC discovery information from the second PINE; determining a PEGC based on the first PEGC discovery information and the second PEGC discovery information; transmitting a selection message to the determined PEGC for service continuity between the first PINE and the second PINE; receiving a confirmation message from the determined PEGC, the confirmation message indicating configuration of service continuity between the first PINE and the second PINE; as well as A first configuration message is transmitted to the first PINE, and a second configuration message is transmitted to the second PINE, wherein the first configuration message and the second configuration message indicate service continuity configuration information.

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

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

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

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

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

Images