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] This application is a continuation of patent application number 2023800641718, filed on August 10, 2023, entitled “Service continuity associated with inter-PINE communication changing from direct mode to using PEGC,” the disclosure of which is incorporated by reference herein in its entirety.

[0002] Cross Reference to Related Applications

[0003] This application claims the benefit of U.S. provisional application 63 / 396,755, filed on August 10, 2022, the disclosure of which is incorporated by reference herein in its entirety. BACKGROUND

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

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

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

[0007] The WTRU can configure service continuity between entities. The WTRU can be a PEMC. The WTRU can receive notification messages. These notification messages can indicate a loss of service continuity between a first PINE and a second PINE. The notification message can indicate a PINEID and a session ID. The WTRU can transmit discovery request messages to both the first and second PINEs. These discovery messages can indicate PEGC discovery. The WTRU can receive discovery response messages. These discovery response messages can indicate (e.g., from the first PINE) first PEGC discovery information and (e.g., from the second PINE) second PEGC discovery information. The WTRU can determine a PEGC based on the first and second PEGC discovery information. The WTRU can transmit a selection message to the determined PEGC for service continuity between the first and second PINEs. This selection message can indicate the first PINE ID associated with the first PINE and the second PINE ID associated with the second PINE. The selection message can indicate a context token. The WTRU can receive an acknowledgment message from the identified PEGC, indicating the configuration of service continuity between the first PINE and the second PINE. The acknowledgment message may indicate the PEGC Internet Protocol (IP) address. The WTRU can transmit configuration messages to the first PINE and the second PINE, for example, indicating service continuity configuration information. Attached Figure Description

[0008] Figure 1A This is a system diagram illustrating an example communication system that can be implemented in one or more of the disclosed embodiments.

[0009] Figure 1B This is an example of what can be achieved according to the implementation plan. Figure 1A A system diagram of an example wireless transceiver unit (WTRU) used in the illustrated communication system.

[0010] Figure 1C This is an example of what can be achieved according to the implementation plan. Figure 1A The illustrated system diagram shows an example radio access network (RAN) and an example core network (CN) used within the communication system.

[0011] Figure 1D This is an example of what can be achieved according to the implementation plan. Figure 1A A system diagram of another example RAN and another example CN used in the illustrated communication system.

[0012] Figure 2 An example of a personal Internet of Things (PIN) network for home automation is shown.

[0013] Figure 3An example wearable PIN is shown.

[0014] Figure 4 An example PIN structure is shown.

[0015] Figure 5 An example PIN application architecture is shown.

[0016] Figure 6 An example of service continuity via PEGC is shown.

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

[0018] Figure 8 An example procedure for service continuity ALT1 is shown.

[0019] Figure 9 An example procedure for service continuity is shown.

[0020] Figure 10 An example procedure for service continuity is shown. Detailed Implementation

[0021] Figure 1A This is a diagram illustrating an example communication system 100 that can be implemented according to one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources (including wireless bandwidth). For example, 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 Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, and Filter Bank Multicarrier (FBMC), etc.

[0022] like Figure 1AAs shown, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, 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, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, UEs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive radio signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0023] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, Internet 110, and / or other networks 112). By way of example, base stations 114a and 114b can be base transceiver stations (BTS), Node Bs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation Node Bs (gNBs), NR Node Bs, site controllers, access points (APs), and wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0024] 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 (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A 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 embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

[0025] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0026] More specifically, as noted above, communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 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).

[0027] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-APro) to establish air interface 116.

[0028] In the implementation scheme, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR radio access, which can use New Radio (NR) to establish air interface 116.

[0029] In the implementation scheme, base station 114a and WTRUs 102a, 102b, and 102c can implement various radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for example, use the dual connectivity (DC) principle to implement both LTE and NR radio access. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions to / from various types of base stations (e.g., eNBs and gNBs).

[0030] In other implementations, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0031] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), and roads. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. 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.

[0032] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 / 113 and / or CN106 / 115 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 / 113 or a different RAT. For example, in addition to being connected to RAN 104 / 113 which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA or WiFi radio technology.

[0033] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmit Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0035] Figure 1B This is a system diagram illustrating the example WTRU 102. For example... Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

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

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

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

[0039] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals to be received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via multiple RATs (such as NR and IEEE 802.11).

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

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

[0042] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0043] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functionality, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, etc. Modules, 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. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0044] WTRU 102 may include a full-duplex radio for which the 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 through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

[0045] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to the implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0046] RAN 104 may include evolved Node Bs 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Node Bs while remaining consistent with the implementation scheme. Each evolved Node B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Node Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0047] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0048] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0049] MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can act as a control node. For example, MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c. MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0050] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during handover between evolved Nodes B, triggering paging when DL data is available to WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0051] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0052] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Furthermore, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0053] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

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

[0055] A WLAN in Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with that 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 out of the BSS. Traffic originating outside the BSS and destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be transmitted to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted via the AP, for example, where a source STA can transmit traffic to the AP, and the AP can 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 can be transmitted between a source STA and a destination STA (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs within a STA) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as a "self-organizing" communication mode in this document.

[0056] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, such as in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented. For CSMA / CA, each STA (including the AP) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one site) can transmit at any given time within a given BSS.

[0057] High-throughput (HT) STAs can communicate using a 40MHz wide channel (e.g., via a combination of a primary 20MHz channel and adjacent or non-adjacent 20MHz channels) to form a 40MHz wide channel.

[0058] Very High Throughput (VHT) STAs support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be processed by a segment parser that can split the data into two streams. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels and transmitted by the transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be transmitted to Media Access Control (MAC).

[0059] 802.11af and 802.11ah support sub-1 GHz operating modes. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 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 (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0060] WLAN systems supporting multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can 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 Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and potentially available.

[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 available bandwidth for 802.11ah is 6MHz to 26MHz, depending on the country code.

[0062] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to the implementation scheme. As noted above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0063] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In another implementation, gNBs 180a, 180b, and 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 implementation, gNBs 180a, 180b, and 180c may implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0064] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with a scalable set of parameters. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various lengths or scalable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0065] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as evolved Node B 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node B 160a, 160b, and 160c. In a non-standalone configuration, evolved Node B 160a, 160b, and 160c can act as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0066] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, dual connectivity, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0067] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. 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.

[0068] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, and managing mobility. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service utilized by WTRU 102a, 102b, and 102c. For example, different network slices can 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. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies (such as WiFi).

[0069] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, and Ethernet-based, etc.

[0070] UPF 184a and 184b can be connected via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 113. These gNBs can provide WTRU 102a, 102b, and 102c with access to a packet-switched network (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0072] Given Figures 1A-1D as well as Figures 1A-1D The corresponding descriptions herein refer to one or more of the functions described herein, or all of the functions described herein, which may be performed by one or more emulation devices (not shown): WTRU102a to 102d, base stations 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 devices described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0073] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier 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 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. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0074] One or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. One or more emulation devices may be test rigs. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0075] This document describes systems and methods for service continuity. For example, service continuity can be performed and / or provided when (e.g., when) communication between Wireless Transmit / Receive Units (WTRUs) changes from a direct mode to, for example, using a WTRU with intermediate gateway capabilities. A Personal Internet of Things (PIN) network can be used. A WTRU can be part of a PIN. A WTRU in this PIN can be referred to as a PIN element (PINE). The WTRU and / or PINE in this PIN can be associated with different capabilities. For example, a PINE in a PIN can be a PINE with gateway capabilities (PEGC). For example, a PINE in a PIN can be a PINE with management capabilities (PEMC).

[0076] In various examples, a PINE (e.g., WTRU) may subscribe to service continuity from a PEMC. The PEMC may authorize the 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 the selection of a PEGC within 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 the PINE to use for service continuity). The PEMC may configure the PINE to connect to the selected PEGC for service continuity.

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

[0078] Personal IoT networks can be provided and / or used.

[0079] Devices that communicate using (e.g., traditional) cellular networks can utilize Internet of Things (IoT) features. IoT-enabled devices can utilize (e.g., require) better power performance (e.g., compared to the power performance of devices without IoT capabilities) and can improve network efficiency for batch operations.

[0080] For example, if (e.g., when) multiple IoT devices are deployed in an environment (e.g., a private environment), IoT-capable WTRUs can be organized into a Personal IoT Network (PIN). For example, in a home environment, security sensors, smart lights, smart plugs, printers, and cellular phones can be managed (e.g., a residential gateway) and can communicate with each other. In this case, (e.g., all) devices in the home can constitute a Personal IoT Network (PIN). Devices (e.g., each device in the network) can include (e.g., referred to as) PIN elements, and different PIN elements can have different capabilities. For example, a residential gateway can include a gateway-capable PIN element (PEGC) that provides connectivity between PIN elements and connectivity between the network and one or more PIN elements. A PIN element with management capabilities (PEMC) can be a PIN element that provides components for (e.g., enabling) configuring and managing PINs (e.g., an authorized administrator for configuring and managing PINs). For example, a residential gateway that can be used as a PEGC can also support PIN management functionality and can be a PIN element with management capabilities.

[0081] Figure 2 Examples of home automation PINs are illustrated. Wearable devices can constitute another type of PIN. Smartphones can be used as PIN elements with gateway capabilities (PEGC) and PIN elements with management capabilities (PEMC). Smartwatches, VR / AR glasses, and / or Apple wireless earphones can communicate with each other in the PIN or communicate with other WTRUs via a network.

[0082] Figure 3 An example wearable PIN is shown.

[0083] It can provide personal IoT network architecture.

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

[0085] Figure 4 An example of a personal Internet of Things (IoT) network architecture is illustrated.

[0086] PIN elements can communicate with each other (e.g., via PEGC and / or directly). PIN elements can communicate with the system to obtain services or (e.g., via the core network) with the data network.

[0087] PIN elements with management capabilities and PIN elements with gateway capabilities (e.g., PIN elements with only management capabilities and PIN elements with gateway capabilities) can be WTRUs. Communication within the PIN (e.g., all other communication) can be performed via communication (e.g., such as WiFi and / or Bluetooth).

[0088] A PIN application architecture (e.g., PINAPP) may be provided and / or used.

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

[0090] An application-layer architecture can be designed for PINs (e.g., to meet PIN requirements). It can support a PIN application-layer functional model.

[0091] An application architecture for enabling PINAPP can be provided (e.g., as described in this article).

[0092] Figure 5 The example PINAPP architecture is shown.

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

[0094] Service disruptions can be minimized if (for example, when) the PIN element changes its communication path, such as from communication between PINEs (e.g., direct communication) to using an intermediate PEGC.

[0095] Figure 6 An example of service continuity via PEGC is shown.

[0096] PINs can include different PIN elements (e.g., sensors, AR / VR, smart TVs, etc.), and these PIN elements (PINEs) may have different requirements. PIN elements can interact directly (e.g., without PEGC connection).

[0097] For example, due to the mobility of PINEs, they may drift out of each other's range. Service between (e.g., two) PINEs may be interrupted. Appropriate PEGCs can be discovered, selected, and configured to continue service through them, for example, to achieve service continuity.

[0098] Discovery and selection of executable PEGCs.

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

[0100] Figure 7 An example of service continuity through multiple PEGCs is shown.

[0101] In various examples (e.g., to restore service continuity between two PINEs), PEGCs can be used (e.g., if required) (e.g., more than one) depending on the location of the PINE. In this scenario, multiple PEGCs can be configured (e.g., after selection) to achieve service continuity (e.g., via application layer mechanisms).

[0102] A PINE subscription for service continuity can be used and / or enabled.

[0103] One or more PINEs interacting between PINEs can subscribe to service continuity from the PEMC. The PEMC can authorize requests from the PIN server. If the subscription is valid, the PEMC can take actions to maintain service continuity, for example, if (e.g., when) a PINE loses contact and service continuity is required. Context tokens can be used to store the context of service continuity between the PINE, PEMC, PEGC, and / or the PIN server.

[0104] For example, an application mechanism can be used to trigger PEGC discovery via PINE.

[0105] A PINE that may lose connection with another PINE can notify the PEMC of a service interruption. The PEMC can initiate a service continuity process and can (e.g., decide) select, for example, PEGCs that can provide service continuity. The PEMC can trigger (e.g., a specific) PEGC selection process, which can be initiated by a PINE. The PEMC can send a message to the PINE, for example, to trigger the PEGC selection process. The PEMC can 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).

[0106] For example, PEGC can be configured using the application mechanism.

[0107] PEMC can transmit configuration information to PEGC (e.g., configure PEGC) for service continuity with PINE information such as PINEID, PINE endpoint identifier, and / or policies related to service continuity for PINE. PEGC can, for example, update forwarding tables and / or allocate resources based on policy information.

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

[0109] PEMC can be configured with PINE to achieve service continuity via PEGC.

[0110] PEMC can use PEGC information to configure PINE (e.g., to transmit configuration information indicating PEGC information). PINE can use PEG information to connect to PEGC (e.g., to enable continued service via PEGC).

[0111] Context tokens can be used.

[0112] To achieve service continuity features, context tokens can be used. When an endpoint changes due to service continuity, context tokens can be used between PINAPP application clients to retrieve endpoint information and / or application context and / or update tokens.

[0113] Figure 1 illustrates an example of a context token.

[0114]

[0115]

[0116] Table 1: Context Token Data Types

[0117] Service continuity (SC) can be enabled and / or provided via (e.g., a single) PEGC.

[0118] Figure 8 An example procedure for service continuity ALT1 is shown.

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

[0120] PINE can perform one or more of the following to achieve service continuity.

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

[0122] The PEMC can authorize the SC request to the PIN server. The PEMC can transmit (e.g., the PINE ID of two PINEs), service type, the presence of connectivity (e.g., direct connectivity) between PINEs (e.g., D2D sessions), session ID, etc.

[0123] The PIN server can authorize PINEs for service continuity and can create context tokens. These tokens can include the PINE ID, session ID, session type, policy information, etc. The PIN server can respond to the PEMC by transmitting SC authorization information and the context token.

[0124] PEMC may (optionally) forward a context token with authorization information to PINE, allowing PINE to use / update the context token (e.g., if needed).

[0125] like Figure 8 As shown, at point 820, PINE may lose connectivity. It can be assumed that service is interrupted at this point (e.g., when PINE loses connectivity). For example, PINE can notify PEMC of the service interruption by transmitting an SC loss with a PINE ID and / or session ID. For example, if (e.g., when) service is lost, PINE can use the application context to update the context token. For example, the application context may contain one or more of the following: the state of the PINE application (e.g., such as initialization, startup, game scene 1, etc.); the dataset at the time of connectivity loss; counters and time values ​​(e.g., via a timer); the last data packet received (e.g., a data packet); etc. PINE can transmit the updated context token to PEMC.

[0126] like Figure 8 As shown, at 830, the PEMC (e.g., a PIN management client) can store the updated context token and verify whether the PINE is authorized for use with the SC. The PEMC can retrieve the authorized policy from the context token used for (e.g., each) PINE.

[0127] The PEMC (PIN Management Client) determines that communication exists between devices, which can be direct communication. The PEMC can, for example, determine the PEGC that might (e.g., needs) be selected for service continuity based on the associated session ID.

[0128] PEMC can execute (e.g., is capable of executing) various PEGC selection procedures. In this scenario, the PIN management client can select (e.g., a specific) PEGC selection procedure, which may involve PEGC discovery performed by PINE. The PIN management client can trigger the discovery process by sending a message (e.g., "Start PEGC discovery for SC") to the PIN client. This message may include policies and authentication information for PINE to begin PEGC discovery.

[0129] PEGC discovery by PINE can be triggered (e.g., by receiving the message "Start PEGC discovery for SC"). PINE can report the discovered PEGC information back to PEMC. PEMC can select (e.g., the best) PEGC. PIN nodes can be involved in PEGC discovery. For example, based on the completion of the discovery process (e.g., after the discovery process is completed), the PIN management client can (e.g., make known) the selected PEGC. It can be assumed that the IP address, PEGCID, and / or associated policy of the selected PEGC are notified to the PIN management client.

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

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

[0132] The PEGC client may (for example, based on successful configuration) send an acknowledgment to the PEMC, which may include, for example, the PEGC IP address and port number of the PINE.

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

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

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

[0136] For example, if (for instance) more than one PEGC is selected for PEMC, a process for providing service continuity can be enabled.

[0137] Figure 9 Example procedures for service continuity are illustrated. For example... Figure 9 As shown, service continuity can be provided if (for example, when) multiple PEGCs are selected. Figure 9 As shown, the steps can be similar to (for example, regarding) Figure 8The process described in this article. It can be used... Figure 8 The illustrated process (e.g., such as) Figure 9 As shown). (For example, in Figure 9 The process in (the process) may differ from Figure 8 The illustrated process, for example, where (for example, in) Figure 9 Alternative solution 2 (ALT2) can be implemented in the Chinese.

[0138] like Figure 9 As shown, at 940, ALT2 may include the following: PINE can discover PEGCs and can transmit PEGC information to PEMC. PEMC may not (e.g., cannot) find a (e.g., a single) PEGC that can serve (e.g., both) PINEs. In this case, 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., as...). Figure 10 (As shown).

[0139] Figure 10 An example procedure for service continuity is shown.

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

[0141] PEMC can send messages (e.g., selection messages, such as "Configure PEGC for SC" message) to selected PEGCs (e.g., PEGC1 and PEGC2). These messages (e.g., selection messages, such as "Configure PEGC for SC" message) may include one or more of the following: PINEID 1 and a context token to PEGC1; and / or PINEID 2 and a context token to PEGC2.

[0142] For example, each PEGC (e.g., a PIN gateway client) can configure its forwarding table to correctly forward service-related PINE (e.g., PINE 1 and PINE 2) traffic. The PEGC can resolve context tokens to perform one or more of the following: determine the policy associated with the PINE and allocate forwarding resources based on that policy; assign a new address using DHCP when the PINE connects, depending on the PINE's policy, or otherwise, if supported by the PEGC, restore the PINE IP address for seamless service continuity; determine the application context and establish forwarding paths based on application state and application requirements; and assign port numbers for (e.g., specific) sessions (e.g., possibly two for two PINEs).

[0143] The PEGC (e.g., a PIN gateway client) may, for example, send an acknowledgment to the PEMC based on successful configuration (e.g., after successful configuration) (e.g., which includes the PEGC IP address and the PINE port number).

[0144] For example, if (e.g., when) the 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.), the PEMC (e.g., a PIN management client) can trigger another process by sending (e.g., internal) messages (e.g., obtaining packet forwarding information for SCs via PEGCs (PEGC list)) to the PEMCNAS layer. The system (e.g., 5GS) can then forward the rules to PEGC1 and PEGC2. PEGC client 1 and PEGC client 2 can then update their forwarding tables using the inter-PEGC forwarding rules.

[0145] like Figure 9 As shown, at 950, the PIN management client in the PEMC can 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). This 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.

[0146] like Figure 9As shown, at 960, the PIN enabler clients in PINE1 and PINE2 can, for example, use the PEGC IP address, port #, etc., to establish (e.g., begin establishing) a connection to PEGC1 and PEGC2. For example, based on a successful establishment (e.g., after a successful establishment), the service between PINE1 and PINE2 continues through PEGC1 and PEGC2.

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

[0148] While the specific implementations described herein may take into account 3GPP-specific protocols, it should be understood that the specific implementations described herein are not limited to this scenario and are applicable to other wireless systems. For example, although the solutions described herein take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to this scenario and are also applicable to other wireless systems.

[0149] The processes described above can be implemented in computer programs, software, and / or firmware incorporated in a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted 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, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROM disks and / or digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A wireless transceiver unit (WTRU), the wireless transceiver unit (WTRU) comprising: Processor, the processor being configured to: Receive a notification message, wherein the notification message indicates a loss of service continuity between the first PINE and the second PINE; A first discovery request message is sent to the first PINE, and a second discovery request message is sent to the second PINE, wherein the first discovery message and the second discovery message indicate the initiation of a PINE (PEGC) discovery with gateway capability; Receive 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; PEGC is determined based on the first PEGC discovery information and the second PEGC discovery information; Select and configuration messages are sent to the PEGC for service continuity between the first PINE and the second PINE; Receive an acknowledgment message from the PEGC, the acknowledgment message indicating the configuration of service continuity between the first PINE and the second PINE; as well as A first configuration message is sent to the first PINE, and a second configuration message is sent 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 WTRU further comprises a PIN client.

3. The WTRU of claim 1, wherein the selection and configuration messages are transmitted using management functions associated with the WTRU.

4. The WTRU of claim 1, wherein the selection and configuration message includes first PINE information and second PINE information, wherein the first PINE information is associated with the first PINE, and wherein the second PINE information is associated with the second PINE.

5. The WTRU of claim 4, wherein the first PINE information indicates a first context token, and wherein the second PINE information indicates a second context token.

6. The WTRU of claim 1, wherein the acknowledgment message indicates the service continuity configuration information, wherein the service continuity configuration information indicates configuration information associated with the PEGC.

7. The WTRU of claim 1, wherein the first discovery message and the second discovery message indicate PEGC information.

8. A method, the method comprising: Receive a notification message, wherein the notification message indicates a loss of service continuity between the first PINE and the second PINE; A first discovery request message is sent to the first PINE, and a second discovery request message is sent to the second PINE, wherein the first discovery message and the second discovery message indicate the initiation of a PINE (PEGC) discovery with gateway capability; Receive 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; PEGC is determined based on the first PEGC discovery information and the second PEGC discovery information; Select and configuration messages are sent to the PEGC for service continuity between the first PINE and the second PINE; Receive an acknowledgment message from the PEGC, the acknowledgment message indicating the configuration of service continuity between the first PINE and the second PINE; as well as A first configuration message is sent to the first PINE, and a second configuration message is sent to the second PINE, wherein the first configuration message and the second configuration message indicate service continuity configuration information.

9. The method of claim 8, wherein the method is performed by a PIN client.

10. The method of claim 8, wherein the selection and configuration messages are transmitted using management functions associated with the wireless transmit / receive unit (WTRU).

11. The method of claim 8, wherein the selection and configuration message includes first PINE information and second PINE information, wherein the first PINE information is associated with the first PINE, and wherein the second PINE information is associated with the second PINE.

12. The method of claim 11, wherein the first PINE information indicates a first context token, and wherein the second PINE information indicates a second context token.

13. The method of claim 8, wherein the confirmation message indicates the service continuity configuration information, wherein the service continuity configuration information indicates configuration information associated with the PEGC.

14. The method of claim 8, wherein the first discovery message and the second discovery message indicate PEGC information.

Images