Methods, architectures, apparatuses, and systems for improved service continuity for out-of-range proximity wireless transmit / receive devices

Abstract

Programs, methods, architectures, apparatus, systems, devices, and computer program products are provided for improved service continuity with respect to wireless transmit / receive devices that do not remain in close / proximity to each other to continue device-to-device (D2D) communication.

Description

[0001] This is a divisional application. The parent application is entitled "Method, Architecture, Apparatus and System for Improved Service Continuity for Remotely Approaching Wireless Transmitting / Receiving Devices", filed on January 29, 2021, with application number 202180015673.2.

[0002] Cross-references to related applications This application claims priority to U.S. Provisional Patent Application No. 62 / 967,505, filed January 29, 2020, which is incorporated herein by reference. Technical Field

[0003] The embodiments disclosed herein relate generally to wireless and / or wired communications, and, for example, to methods, architectures, apparatuses, and systems for improved service continuity for use with wireless transmitting / receiving devices that are out of range. Background Technology

[0004] Direct device-to-device connectivity enables the establishment of communication paths between two devices that are close to or within range of each other. Current mechanisms for maintaining service continuity for applications running on direct communication paths are insufficient to address the possibility of devices not remaining within range of each other to continue direct communication. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are illustrative. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and contemplated. Additionally, similar reference numerals (“ref.”) in the drawings indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system; Figure 1B It shows that it can be used Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C It shows that it can be used Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D It shows that it can be used Figure 1A System diagram of another exemplary RAN and another exemplary CN used in the communication system shown; Figure 1E This is a block diagram illustrating various exemplary components of an exemplary communication system; Figure 1FThis is a block diagram illustrating an exemplary architecture of an exemplary communication system; Figure 2A An exemplary user plane for the PC5 interface (PC5-U) is shown; Figure 2B An exemplary discovery plane PC5 interface (PC5-D) is shown. Figure 2C An exemplary PC5 signaling protocol stack is shown; Figure 2D The granularity of multiple PC5 unicast links is shown; Figure 2E This is a block diagram illustrating an exemplary mapping of the per-flow QoS model for the PC5 interface; Figure 3 This is a block diagram illustrating an exemplary architecture of a WTRU according to an implementation scheme; Figure 4 This is a flowchart illustrating exemplary processes for performing service continuity according to various implementation schemes; Figure 5 The message exchange related to notification reporting is shown; Figure 6 An example non-access stratum (NAS) message is shown; Figure 7 The message exchange related to subscription and notification operations for exposed notification events is shown; Figure 8 This is a message diagram illustrating an exemplary sidelink state transition notification procedure; Figure 9 This is a block diagram illustrating an exemplary WTRU architecture according to an implementation scheme; Figure 10 This is a flowchart illustrating exemplary processes for performing service continuity according to various implementation schemes; Figure 11 The message exchange related to notification reporting is shown; Figure 12 The message exchange related to subscription and notification operations for exposed notification events is shown; Figure 13 This is a message diagram illustrating an exemplary sidelink state transition notification procedure; Figure 14 This is a block diagram illustrating an exemplary WTRU architecture according to an implementation scheme; Figure 15 This is a flowchart illustrating exemplary processes for performing service continuity according to various implementation schemes; Figure 16 The message exchange related to notification reporting is shown; Figure 17The message exchange related to subscription and notification operations for exposed notification events is illustrated; and Figures 18 to 24 This is a flowchart illustrating exemplary processes for performing service continuity according to various implementation schemes. Detailed Implementation

[0006] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments and / or examples disclosed herein. However, it should be understood that such embodiments and examples may be practiced without some or all of the specific details set forth herein. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to obscure the following description. Furthermore, embodiments and examples not specifically described herein may be practiced in place of, or in combination with, the embodiments and other examples expressly, implicitly, and / or inherently described, disclosed, or otherwise provided herein (collectively, the “Provided”). Although various embodiments are described and / or claimed herein, in which apparatuses, systems, devices, etc., and / or any elements thereof perform operations, processes, algorithms, functions, etc., and / or any part thereof, it should be understood that any embodiment described herein and / or protected by the claims presupposes that any apparatus, system, device, etc., and / or any element thereof is configured to perform any operation, process, algorithm, function, etc., and / or any part thereof.

[0007] Exemplary communication system The methods, apparatus, and systems provided herein are well-suited for communications involving both wired and wireless networks. Wired networks are well-known. Compared to... Figures 1A to 1D An overview of various types of wireless devices and infrastructures is provided, wherein various elements of the network may utilize, perform, be arranged according to, and / or be adapted to and / or configured with respect to the methods, apparatuses and systems provided herein.

[0008] Figure 1AThis is a diagram of an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. The exemplary communication system 100 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. The communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. The communication system 100 enables multiple wireless users to access such content through the 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 (ZT) Unique Word (UW) Discrete Fourier Transform (DFT) Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0009] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, radio access networks (RANs) 104 / 113, core networks (CNs) 106 / 115, public switched telephone networks (PSTNs) 108, the 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 can be any type of device configured to operate and / or communicate in a wireless environment. As an example, WTRUs 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 wireless signals and may include (or) 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, 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.

[0010] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to, for example, facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or Network 112. As an example, base stations 114a and 114b may be any of a base transceiver station (BTS), a node B (NB), an evolved node B (eNB), a home node B (HNB), a home evolved node B (HeNB), a g node B (gNB), an NR node B (NR NB), a site controller, an access point (AP), a wireless router, 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.

[0011] 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. Thus, 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 or any sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

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

[0013] 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, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may 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 Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0014] In one implementation, 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-A Pro) to establish air interface 116.

[0015] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.16 (i.e., Global Microwave Access Interoperability (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), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

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

[0017] 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 a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by various types of radio access technologies and / or transmissions sent to / from various types of base stations (e.g., eNBs and gNBs).

[0018] In other implementations, base station 114a and WTRUs 102a, 102b, and 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), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0019] Figure 1A Base 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), roads, etc. In implementations, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In implementations, base station 114b and WTRUs 102c and 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In implementations, base station 114b and WTRUs 102c and 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish any of the following: microcell, picocell, or femtocell. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0020] 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, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN104 / 113 and / or CN 106 / 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, CN106 / 115 can also communicate with another RAN (not shown) that uses any of the following radio technologies: GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or Wi-Fi.

[0021] CN 106 / 115 may also act as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired 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 / 114 or a different RAT.

[0022] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multi-mode capabilities (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 base station 114a, which can employ cellular-based radio technology, and with base station 114b, which can employ IEEE 802 radio technology.

[0023] Figure 1B This is a system diagram of an exemplary WTRU 102. The exemplary WTRU 102 is provided for illustrative purposes only and is not intended to limit the disclosed embodiments. 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 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.

[0024] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can 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, for example, in an electronic package or chip.

[0025] 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 one 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 embodiments, transmitting / receiving element 122 may be configured to transmit and 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.

[0026] Furthermore, 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. For example, WTRU 102 may employ MIMO technology. Therefore, 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.

[0027] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals 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 various RATs such as NR and IEEE 802.11.

[0028] 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 and store information from any suitable type of memory, such as non-removable memory 130 and / or removable memory 132. 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 user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access and store information from memory that is not physically located on WTRU 102 (e.g., on a server or home computer (not shown)).

[0029] 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, fuel cells, etc.

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

[0031] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules / units and / or hardware modules / units providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (e.g., for photos or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth.® Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, 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.

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

[0033] Figure 1C This is a system diagram of RAN 104 and CN 106 according to another implementation scheme. As described 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.

[0034] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, Evolved Nodes B 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 receive radio signals from WTRU 102a.

[0035] 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, user scheduling in the uplink (UL) and / or downlink (DL), etc. Figure 1C As shown, evolution nodes 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

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

[0038] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

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

[0040] 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 conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0041] Despite WTRU in Figures 1A to 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.

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

[0043] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (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 out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (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 Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. IBSS communication mode may sometimes be referred to as "ad-hoc" communication mode in this document.

[0044] 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 wide 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, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0045] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0046] 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 split into two streams by a segment parser. 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 data can be transmitted via a 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 sent to Media Access Control (MAC).

[0047] 802.11af and 802.11ah support operating modes below 1 GHz. 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 communication (MTC), 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).

[0048] WLAN systems supporting multiple channels, as well as channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as primary channels. A 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.

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

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

[0051] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the implementation scheme. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In the implementation scheme, 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 the implementation scheme, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In the implementation scheme, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

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

[0053] 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 or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 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 Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used 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.

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

[0055] 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 at least one 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.

[0056] 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 be used 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 Packet Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c, for example, based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, etc. AMF 162 can provide control plane functions for handover between RAN113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-APro and / or non-3GPP access technologies, such as Wi-Fi.

[0057] 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, Ethernet-based, etc.

[0058] 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 packet-switched networks (such as Internet 110), for example, to facilitate communication between WTRU 102a, 102b, 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.

[0059] 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 serves as an interface between CN 115 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, 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 an embodiment, WTRUs 102a, 102b, and 102c may be connected to DNs 185a and 185b via UPFs 184a and 184b through an N3 interface to UPFs 184a and 184b and an N6 interface between UPFs 184a and 184b and local data networks (DNs) 185a and 185b.

[0060] Given Figures 1A to 1D as well as Figures 1A to 1D The functions described herein, including one or more of the functions described with reference to any of the following, may be performed by one or more emulation components / devices (not shown): WTRU102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b, and / or any other components / 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.

[0061] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more 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. The one or more simulation devices may perform one or more 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.

[0062] The one or more simulation 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, the simulation 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. The one or more simulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0063] Figure 1E This is a block diagram illustrating various exemplary components of a communication system 100. Such components may be included, for example, in an embodiment of the communication system 100 configured according to 5G and / or NR. Components may include elements of the WTRU 102, (R)AN 113, DN 185, and core network 115, including AMF 182, SMF 183, UPF 184, Policy Control Function (PCF) 186, Network Exposure Function (NEF) 187, and Unified Data Management Function (“UDM”) 191. For ease of explanation and simplicity, the terms “5G core network” and “5GC” may be used interchangeably with CN 115.

[0064] AMF 182 can perform various functions, including, for example, any of the following: termination of the RAN CP interface (N2), termination of the NAS (N1), NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception, etc. SMF 183 can perform various functions, including, for example, any of the following: session management (including session establishment, modification, and release), IP address allocation, selection and control of user plane functions, etc. PCF 186 can perform various functions, including, for example, any of the following: providing support for a unified policy framework to manage network behavior, providing policy rules to one or more control plane functions to enforce them, etc. NEF 187 can perform various functions, including, for example, any of the following: displaying capabilities and events, providing information to network security from external applications, etc. UPF184 can perform various functions, including, for example, any of the following: operating as an anchor point for intra / inter-RAT mobility, UE IP address allocation, external PDU session point for interconnection with DNs (such as DN 185), packet routing and forwarding, packet inspection, etc. RAN 113 can be configured as either an NG-RAN or a non-3GPPAN. RAN 113 can be connected to a CN, for example, which can be configured as a 5G core network.

[0065] Figure 1F This is a block diagram illustrating an exemplary architecture of a communication system 100 configured according to 5G and / or NR. For ease of explanation and simplicity, the term "5G system" and its abbreviation "5GS" may be used herein to refer to the communication system 100 configured according to 5G and / or NR. Figure 1F The exemplary architecture shown can be applied to a variety of services in 5GS, including any of the proximity-based services (ProSe), vehicle-to-everything (V2X) services, and other device-to-device (D2D) communication services. Exemplary architectures may include WTRU 102a-102d, NG-RAN 113, DN 185, and 5GC 115.

[0066] Each of WTRU 102a-102d may include an application (“WTRU application”) 103. The WTRU application may be any of, for example, a ProSe application, a V2X application, and other similar types of applications. DN185 may include an application server 189. The application server 189 may include one or more applications that serve any of the WTRU applications.

[0067] D1 is a reference point between WTRU application 103 and the application in application server 189. D5 is a reference point between WTRU applications 103 (e.g., between and / or among two or more WTRU applications 103 in WTRU 102a-102d). PC5 is a D2D interface for direct D2D communication between and / or among two or more in WTRU 102a-102d. The PC5 interface can be configured as, for example, LTE-based PC5, NR-based PC5, etc. The terms PC5 interface and "side link" (at the PHY layer) are used interchangeably herein.

[0068] As described above, direct D2D communication (such as ProSe direct communication) enables the establishment of communication paths between two or more WTRUs 102 that are close to or within range of each other. WTRU 102 can use direct D2D discovery (such as ProSe direct discovery) to identify other WTRUs in proximity. For example, details on providing WTRUs for direct communication and / or direct discovery and / or for both within-coverage and beyond-coverage scenarios can be found in 3GPP TS 23.303 V15.1.0.

[0069] Sidelink communication can be performed using either autonomous transmission mode or scheduled transmission mode. For example, autonomous transmission mode can be used for WTRUs (CM-IDLE and RRC_IDLE) outside coverage. In autonomous transmission mode, radio resources can be read from a System Information Block (SIB) (such as SIB 18). For WTRUs within coverage (CM-CONNECTED / CM-IDLE, RRC_IDLE / RRC_CONNECTED, with or without an active PDU session), either scheduled transmission mode or autonomous transmission mode can be used for sidelink communication. For each of ProSe direct communication and ProSe direct discovery, Table 1 lists which transmission mode is selectable based on whether the WTRU is within or outside coverage. For each of ProSe direct communication and ProSe direct discovery, Table 1 also lists whether transmit resources are pre-configured or indicated by the RAN.

[0070] Table 1 Figure 2A An exemplary user plane for the PC5 interface (PC5-U) is shown. Exemplary details of the PDCP / RLC / MAC / PHY functions can be found, for example, in 3GPP TS 36.300.

[0071] Figure 2BAn exemplary discovery plane PC5 interface (PC5-D) is shown. The ProSe protocol can be used to handle ProSe direct discovery. Exemplary details of PC5-D can be found, for example, in 3GPP TS 24.334.

[0072] Figure 2C An exemplary PC5 signaling protocol stack is shown. The PC5 signaling protocol stack is used for control plane signaling on PC5, including, for example, signaling for establishing, maintaining, and releasing Security Layer-2 links on the PC5 interface, TMGI monitoring requests, cell ID announcement requests, etc. The SDU type field (which can be 3 bits) in the PDCP header can be used to distinguish between IP, ARP, and PC5 signaling protocols.

[0073] Unicast communication mode can be supported via PC5 references (e.g., NR-based PC5 reference points). Figure 2D The granularity of multiple PC5 unicast links is illustrated. As shown, the granularity is one PC5 unicast link for each pair of application layer identifiers of WTRU 102a and 102b. If a service is associated with the same pair of application layer identifiers, a PC5 unicast link can support one or more services. As shown, WTRU 102a has two PC5 unicast links with WTRU 102b. The first PC5 unicast link can be identified by application layer identifier 2, and the second PC5 unicast link can be identified by application layer identifier 4. A PC5 unicast link can support one or more PC5 QoS flows for the same or different services.

[0074] When an application layer initiates a service using PC5 unicast communication, WTRU 102a can use a Layer-2 link establishment procedure to establish a PC5 unicast link with the corresponding WTRU 102b. During unicast link establishment, each of WTRUs 102a and 102b can assign its own PC5 link identifier and associate the assigned PC5 link identifier with the link profile of the established unicast link. The PC5 link identifier can have a unique value within the WTRU.

[0075] The link profile identified by the PC5 link identifier may include any of the following: the application layer identifier of WTRU 102a, the layer-2 identifier of WTRU 102a, the application layer identifier of WTRU 102b, the layer-2 identifier of WTRU 102b, and information about one or more PC5 QoS flows. Information about one or more PC5 QoS flows may include one or more PC5 QoS Flow Identifiers (PFIs) along with one or more QoS parameters for each PFI (e.g., PC5 QoS context and PC5 QoS rules). Figure 2EThis is a block diagram illustrating an exemplary mapping of a per-flow QoS model for a PC5 interface (e.g., an NR PC5 interface).

[0076] Regardless of any changes to either the application layer identifier or the layer-2 identifier, the PC5 link identifier and PFI remain unchanged for the established unicast link. A beneficial consequence of this unchanged PFI is that the WTRU's access layer (AS) can identify PC5 QoS flows based on (e.g., solely on) the corresponding PFI provided to it. For example, the AS layer does not need to rely on either the source or destination layer-2 identifiers (and does not need to track any changes to them) to identify PC5 QoS flows.

[0077] PC5 link identifiers can be used to indicate PC5 unicast links to the application layer. The application layer can identify PC5 unicast links based on (e.g., only on) the PC5 link identifiers provided to it. PC5 link identifiers can be (at least locally) unique to allow the application layer to identify a corresponding PC5 unicast link from multiple unicast links associated with a service type (e.g., if a WTRU establishes multiple unicast links with one or more other WTRUs for the same service type).

[0078] As described above, the current mechanism for maintaining service continuity for applications running on the PC5 communication path is not optimized for the possibility of WTRUs not remaining close / within each other to continue D2D communication. The current PC5 signaling protocol provides a keep-alive function. Among other things, the WTRU uses this function to detect whether the PC5 side link is feasible or remains feasible (or conversely, infeasible or no longer feasible) for communication between WTRUs. If the WTRU detects that the PC5 side link is infeasible or no longer feasible for communication (e.g., due to a timeout), it executes an implicit Layer-2 link release procedure on the PC5. The implicit Layer-2 link release procedure is as follows: One WTRU (“WTRU 102a”) sends a disconnect request message to the other WTRUs (“WTRU 102b”); WTRU 102a deletes all context data associated with the Layer-2 link; Upon receiving the disconnect request message, WTRU 102b sends a disconnect response message to WTRU 102a (e.g., as an acknowledgment); and WTRU 102b removes all context data associated with Layer-2 links.

[0079] The consequence of executing the implicit Layer-2 link release procedure is that, because the unroutable Layer-2 address is used for PC5 flows, once the Layer-2 link is released, the WTRU lacks a routable address to forward application (service) packets (e.g., ProSe packets). Another consequence of executing the implicit Layer-2 link release procedure is that user plane applications and the corresponding PC5 flows running on the PC5 side links inevitably break down and eventually terminate.

[0080] Service continuity is possible using existing 3GPP mechanisms. However, existing 3GPP mechanisms require a large number of message exchanges—no fewer than 33.

[0081] As those skilled in the art will understand based on the teachings herein, the implementations described herein are covered, but not limited to, programs, methods, architectures, apparatuses, systems, devices, and computer program products for improving service continuity in relation to the possible occurrence of WTRUs not maintaining proximity / range to continue D2D communication.

[0082] A first method, which can be implemented in a first WTRU and may include any of the following: determining the state of a sidelink between the first WTRU and a second WTRU (“sidelink state”); transmitting first information indicating the sidelink state and a first identifier and a second identifier associated with the first WTRU and the second WTRU to a first network element of the CN, wherein at least the first identifier and the second identifier are transmitted from the first network element to an application server; receiving information from a second network element of the core network to trigger a WTRU request to establish or modify a PDU session; transmitting to the second network element a description of the traffic flow associated with the sidelink (“traffic flow description”) and second information indicating the request to establish or modify the PDU session; transmitting outbound traffic of the traffic flow and the address of the first WTRU to the application server according to the PDU session; and receiving inbound traffic of the traffic flow from the application server according to the PDU session. In various embodiments, the first network element may include an AMF, and the second network element may include an SMF.

[0083] A second method, which can be implemented in a first WTRU and may include any of the following in programs, methods, architectures, apparatuses, systems, devices, and computer program products: determining the sidelink state of a sidelink between the first WTRU and the second WTRU; transmitting first information indicating the sidelink state and a first identifier and a second identifier associated with the first WTRU and the second WTRU to a network element of the core network, wherein at least the first identifier and the second identifier are transmitted from the network element to an application server; transmitting to the network element second information indicating a traffic flow description associated with the sidelink and a request to establish or modify a PDU session; transmitting outbound traffic of the traffic flow and the address of the first WTRU to the application server according to the PDU session; and receiving inbound traffic of the traffic flow from the application server according to the PDU session. In various embodiments, the network element may include an SMF.

[0084] A third method, which can be implemented in a first WTRU and may include any of the following in programs, methods, architectures, apparatuses, systems, devices, and computer program products: determining the sidelink status of a sidelink between the first WTRU and the second WTRU; transmitting first information indicating the sidelink status, a traffic flow description associated with the sidelink, and a first identifier and a second identifier associated with the first WTRU and the second WTRU to a network element of the core network, wherein at least the traffic flow description and the first and second identifiers are transmitted from the network element to an application server; transmitting outbound traffic of the traffic flow and the address of the first WTRU to the application server according to a PDU session; and receiving inbound traffic of the traffic flow from the application server according to the PDU session. In various embodiments, the third method may include transmitting second information indicating a request to establish a PDU session when the first WTRU is not in connected mode.

[0085] The fourth method, which can be implemented in a first WTRU and may include any of the following in a program, method, architecture, apparatus, system, device, or computer program product: determining the sidelink state of a sidelink between the first WTRU and the second WTRU; transmitting first information indicating the sidelink state, a traffic flow description associated with the sidelink, and a first identifier and a second identifier associated with the first WTRU and the second WTRU to a first network element of the core network, wherein at least the traffic flow description and the first and second identifiers are transmitted from the first network element to an application server; receiving information from the first or second network element of the core network to trigger a request to establish or modify a PDU session; transmitting second information indicating the request to establish or modify a PDU session; transmitting outbound traffic of the traffic flow and the address of the first WTRU to the application server according to the PDU session; and receiving inbound traffic of the traffic flow from the application server according to the PDU session.

[0086] In various embodiments of any of the first, second, third, and fourth methods, determining the sidelink state may include any of the following: monitoring keep-alive transmissions; and determining the sidelink state based on the number of keep-alive transmissions received within a certain time period. In various embodiments, (i) if the number of keep-alive transmissions received within the time period fails to meet a first threshold, the sidelink state may be a first value, and (ii) if the number of keep-alive transmissions received within the time period meets a second threshold, the sidelink state may be a second value. In various embodiments, the first threshold and the second threshold may be the same threshold. In various embodiments, the first value may indicate that the sidelink is infeasible or no longer feasible for communication with the second WTRU.

[0087] In various implementations, any one of the first, second, third, and fourth methods may include any one of the following: receiving the address of the second WTRU from the application server; and transmitting outbound traffic using the address of the second WTRU.

[0088] The fifth method, which can be implemented in an application server and may include any of the following, is a program, method, architecture, apparatus, system, device, and computer program product: receiving from one or more network elements of one or more core networks (i) a first sidelink state indicating a sidelink between a first WTRU and a second WTRU, a traffic flow description of a traffic flow associated with the sidelink, and first information of a first identifier and a second identifier associated with the first WTRU and the second WTRU, wherein the first information originates from the first WTRU; and (ii) a second sidelink state indicating a sidelink, a traffic flow description, and second information of a third identifier and a fourth identifier associated with the first WTRU and the second WTRU, wherein the second information originates from the second WTRU; receiving a first flow of traffic and an address of the first WTRU from the first WTRU; receiving a second flow of traffic and an address of the second WTRU from the second WTRU; transmitting the second flow using the first address; and transmitting the first flow using the second address.

[0089] In various embodiments, receiving first information and second information from network elements of the core network may include any one of the following: (i) receiving first information from a first network element in response to a first event based on a first subscription of the first network element; and (ii) receiving second information from a second network element in response to a second event based on a second subscription of the second network element. In various embodiments, the first event may be when a first state indicates that communication with the second WTRU is infeasible or no longer feasible via the sidelink, and the second event may be when a second state indicates that communication with the second WTRU is infeasible or no longer feasible via the sidelink.

[0090] In various embodiments, the fifth method may include any one of the following: obtaining a first subscription from a first network element; and obtaining a second subscription from a second network element. In various embodiments, the fifth method may include any one of the following: transmitting a second address of a second WTRU to a first WTRU; and transmitting a first address of a first WTRU to a second WTRU.

[0091] In various implementations, the fifth method may include any of the following: transmitting third information to a first network element or a third network element within a network element to trigger the establishment of a third PDU session or the modification of a first PDU session; and transmitting fourth information to a second network element or a fourth network element within a network element to trigger the establishment of a fourth PDU session or the modification of a second PDU session.

[0092] In various implementations of the fifth method, the network element may include any one of the following: a first AMF associated with a first WTRU, a second AMF associated with a second WTRU, and an SMF associated with both the first and second WTRUs.

[0093] In various embodiments of any of the first, second, third, fourth, and fifth methods, the first identifier may include either the application layer identifier of the first WTRU or the layer-2 identifier of the first WTRU, and the second identifier may include either the application layer identifier of the second WTRU or the layer-2 identifier of the second WTRU. In various embodiments of the fifth method, the third identifier may include either the application layer identifier of the first WTRU or the layer-2 identifier of the first WTRU, and the fourth identifier may include either the application layer identifier of the second WTRU or the layer-2 identifier of the second WTRU.

[0094] In various implementations of any of the first, second, third, fourth, and fifth methods, the traffic flow description may include any of the PFI and one or more QoS rules.

[0095] In various embodiments of any of the first, second, third, fourth, and fifth methods, the first information may be transmitted as a notification message or transmitted within a notification message. In various embodiments of the fifth method, the second information may be transmitted as a notification message or transmitted within a notification message.

[0096] In various embodiments of any of the first, second, third, fourth, and fifth methods, the first information is transmitted as or in connection with either a NAS message or an RRC message. In various embodiments of the fifth method, the second information is transmitted as or in connection with either a NAS message or an RRC message.

[0097] In various implementations of the fifth method, (i) if the number of keep-alive transmissions received during the time period fails to meet a first threshold, the first-side hop state can be a first value, and (ii) if the number of keep-alive transmissions received during the time period meets a second threshold, the first-side hop state can be a second value. In various implementations, the first threshold and the second threshold can be the same threshold.

[0098] In various implementations of the fifth method, (i) if the number of keep-alive transmissions received during the time period fails to meet the third threshold, the second-side hop state can be the third value, and (ii) if the number of keep-alive transmissions received during the time period meets the fourth threshold, the second-side hop state can be the fourth value. In various implementations, the third and fourth thresholds can be the same threshold. In various implementations, the first, second, third, and fourth thresholds can be the same threshold. In various implementations, the first threshold can be the same as the third threshold, and the second threshold can be the same as the fourth threshold.

[0099] In various implementations of the first, second, third, fourth, and / or fifth methods, the first identifier, second identifier, third identifier, fourth identifier, and PFI may be included in the link profile identified by the PC5 link identifier.

[0100] The sixth method, which can be implemented in a WTRU and may include the following in programs, methods, architectures, devices, systems, equipment, and computer program products: generating a PC5 notification report based on PC5 infeasibility information associated with a PC5 sidelink, wherein the PC5 notification report may include one or more identifiers (“sidelink identifiers”) associated with the PC5 sidelink, such as one or more identifiers included in the link profile identified by the PC5 link identifier; invoking an entity of the communication protocol stack to transmit the PC5 notification report to a network element; sending the PC5 notification report to the network element in the message according to the protocol of the entity of the communication protocol stack; and when the WTRU is not in connection management... Under the following conditions: The process transitions to a connected management state and initiates a Protocol Data Unit (PDU) session establishment request, including one or more QoS rule / packet filter sets associated with one or more sidelink identifiers, such as one or more of the QoS rule / packet filter sets included in the link profile identified by the PC5 link identifier; under the condition that the WTRU is in a connected management state, the process initiates a PDU session modification request, including one or more QoS rule / packet filter sets associated with one or more sidelink identifiers; and transmits packets to the application server using the PDU session established in response to the PDU session establishment request or the PDU session modified in response to the PDU session modification request. In an implementation, the method may further include determining whether the PC5 sidelink is infeasible or no longer feasible for communication with another WTRU; and providing information to the Sidelink Event Exposure Function (SL-EEF) indicating that the PC5 sidelink interface is infeasible or no longer feasible.

[0101] In an implementation, the method may further include providing one or more active PC5 link identifiers to the SL-EEF.

[0102] In this implementation, one or more sidelink identifiers may include application layer identifiers, layer-2 identifiers, and any of the PFI set. In this implementation, each PFI may be associated with one or more QoS parameters.

[0103] In the implementation scheme, a PC5 notification report can be generated, and the SL-EEF can invoke entities of the communication protocol stack. In the implementation scheme, the entities of the communication protocol stack can be either NAS or RRC entities. In the implementation scheme, the communication protocol can be either the NAS protocol or the RRC protocol.

[0104] In the implementation scheme, the message according to the protocol of the entity in the communication protocol stack can be a NAS service request message, and the PC5 notification report can be carried in the NAS message container of the NAS service request message.

[0105] In the implementation plan, the message according to the protocol of the entity in the communication protocol stack can be RRC. Measurement Report Messages, and PC5 notification reports can be carried in RRC Measurement Report In the message's information element (IE).

[0106] In one implementation, a PDU session modification request may include one or more IEs configured to carry any of a QoS rule / packet filter set and a PFI. In another implementation, a PDU session establishment request may include one or more IEs configured to carry any of a QoS rule / packet filter set and a PFI. In yet another implementation, the IE may include any of an extended protocol configuration option IE, a requested QoS rule IE, and a requested QoS flow description IE.

[0107] In an implementation, the method may further include a mapping between a receiving-side link identifier and one or more routable addresses on which packets are transmitted.

[0108] The methods included in programs, methods, architectures, apparatuses, systems, devices, and computer program products are methods that can be implemented in network elements and may include: receiving a PC5 notification report in a message according to the protocol of an entity of the communication protocol stack, wherein the PC5 notification report includes one or more sidelink identifiers associated with the PC5 sidelink of the WTRU; accepting a PDU session establishment request, including one or more QoS rules / packet filter sets associated with the sidelink identifier, when the WTRU is not in a connection management state of a connection; accepting a PDU session modification request, including a QoS rules / packet filter set, when the WTRU is in a connection management state of a connection; and at least providing the QoS rules / packet filter set associated with the sidelink identifier to an application server.

[0109] In this implementation, the sidelink identifier may include application layer identifiers, layer-2 identifiers, and any of the PFIs in the PFI set. In this implementation, each PFI is associated with one or more QoS parameters.

[0110] In this implementation, the entity of the communication protocol stack can be either a NAS or an RRC entity. In this implementation, the protocol of the communication protocol can be either a NAS protocol or an RRC protocol. In this implementation, the message according to the protocol of the entity of the communication protocol stack can be a NAS service request message, and the PC5 notification report can be carried in the NAS message container of the NAS service request message.

[0111] In the implementation plan, the message according to the protocol of the entity in the communication protocol stack can be RRC. Measurement Report Messages, and PC5 notification reports can be carried in RRC Measurement Report In the IE of the message. In an implementation, a PDU session modification request may include one or more IEs configured to carry any of the QoS rules / packet filter set and the PFI. In an implementation, a PDU session establishment request may include one or more IEs configured to carry any of the QoS rules / packet filter set and the PFI. In an implementation, the IE may include any of the extended protocol configuration options IE, the requested QoS rule IE, and the requested QoS flow description IE.

[0112] In programs, methods, architectures, apparatuses, systems, devices, and computer program products, thereare apparatuses that may include either a processor or memory, configured to perform any of the methods and implementations thereof for the improved service continuity provided herein. In various implementations, the apparatus may be configured as and / or configured with WTRUs. In various implementations, the apparatus may be configured as and / or configured with network elements. In various implementations, the apparatus may be configured as and / or configured with application servers.

[0113] In programs, methods, architectures, apparatuses, systems, devices, and computer program products is a system, which may include either a processor or memory, configured to perform any of the methods and implementations thereof for the improved service continuity provided herein. Also in programs, methods, architectures, apparatuses, systems, devices, and computer program products is a tangible computer-readable storage medium having stored thereon computer-executable instructions for performing any of the methods and implementations thereof for the improved service continuity provided herein.

[0114] For ease of explanation and simplicity, various implementation schemes are described in conjunction with service continuity between the PC5 interface and the Uu interface. Those skilled in the art will recognize that such teachings apply to service continuity in other situations, such as those relating to the movement of WTRUs across different PLMNs, NPNs (SNPNs or PNI-NPNs).

[0115] An improved mechanism is provided for service continuity between the PC5 interface and the Uu interface, which relates to the potential occurrence of WTRUs not maintaining proximity / ProSe communication range with each other. The service continuity mechanism can be implemented as follows.

[0116] 1. PC5 Notification Report: WTRU 102a can generate and send PC5 notification reports to application server 189 (e.g., via one or more networks in the network of communication system 100). The generation and / or sending of PC5 notification reports can be triggered in response to determining that a PC5 sidelink is infeasible or no longer feasible for communication between one or more of WTRU 102a and WTRU 102b / 102c / 102d. The PC5 notification report may include contextual information about the PC5 unicast link. Contextual information may include the PC5 link profile associated with the PC5 unicast link and the status of the PC5 Layer-2 link, such as the application layer identifier and PFI.

[0117] 2. Migration of some or all of existing PC5 flows to new and / or existing PDU sessions: WTRU 102a can use a WTRU-requested PDU session establishment request to request the migration of existing PC5 flows to a new PDU session. WTRU 102a can also use a WTRU-requested PDU session modification request to request the migration of existing PC5 flows to an existing PDU session. WTRU-requested PDU session establishment requests and / or WTRU-requested PDU session modification requests may include QoS rules (packet filter sets) associated with the sidelink identifier.

[0118] 3. Mapping and routing packets between the PC5 and Uu interfaces. The ProSe application server can construct a mapping between unicast link profile attributes (derived from PC5 notification reports) and the routable destination address of the WTRU (derived from the establishment or modification of a PDU session). The ProSe application server can then use the constructed mapping table to forward ProSe packets to the WTRU. Alternatively and / or additionally, the ProSe application server can provide (e.g., send) the constructed mapping table to the WTRU, enabling subsequent ProSe packets to be addressed using the routable destination address.

[0119] For ease of explanation and simplicity, these mechanisms are described in conjunction with service continuity for two WTRUs and various connection management states. Those skilled in the art will recognize that the same mechanisms apply to more than two WTRUs and / or other connection management states.

[0120] Figure 3This is a block diagram illustrating an exemplary architecture of a WTRU (“WTRU architecture”) 300 according to an implementation scheme. The WTRU architecture 300 may be adapted to generate PC5 notification reports and / or transmit PC5 notification reports to an AMF, such as AMF 182 (Figure 1). The WTRU architecture 300 may include a link profile 310, a PC5 signaling protocol stack 312, a sidelink event exposure function (SL-EEF) 314, and a NAS entity 316. The PC5 signaling protocol stack 312 may include a PC5 signaling protocol entity 312a, a PDCP entity 312b, an RLC entity 312c, a MAC entity 312d, and a PHY entity 312e.

[0121] The keep-alive function of the PC5 signaling protocol entity can be used to determine the PC5 side link for use with adjacent WTRUs (in Figure 3 Whether communication (not shown) is feasible or remains feasible (or conversely, infeasible or no longer feasible). If it is determined that the PC5 side link is infeasible or no longer feasible for communication (e.g., due to timeout), information indicating that the PC5 side link is infeasible or no longer feasible (e.g., PC5 keep-alive timeout message or indicator) may be provided to the SL-EEF 314. Functions other than (or instead of) the keep-alive function may be used to determine whether communication with the adjacent WTRU is feasible or remains feasible (or conversely, infeasible or no longer feasible) for the PC5 side link. This other function may not be a function of the PC5 signaling protocol entity, but a function of another entity shown here, and / or may provide the SL-EEF 314 with information indicating that the PC5 side link is infeasible or no longer feasible (“PC5 infeasibility information”). The PC5 infeasibility information may be provided to the SL-EEF 314 on any push or pull basis.

[0122] The SL-EEF 314 can obtain PC5 infeasibility information from the PC5 signaling protocol or other entities. The SL-EEF 314 can obtain one or more sidelink identifiers from the link profile 210. The SL-EEF 314 can use the PC5 infeasibility information and sidelink identifiers to generate a PC5 notification report. For example, the SL-EEF 314 can connect or otherwise combine the PC5 infeasibility information and sidelink identifiers to form a PC5 notification report.

[0123] The SL-EEF 314 can provide PC5 notification reports to NAS entity 216 for transmission to AMF 182. NAS entity 216 can invoke NAS protocols to transmit PC5 notification reports to AMF, for example, using the N1 interface.

[0124] Figure 4This is a flowchart illustrating an exemplary process 400 for performing service continuity according to various implementation schemes. Process 400 can be adapted to perform service continuity in which two WTRUs involved in sidelink communication are in connection management states CM-IDLE and RRC_IDLE, without active PDU sessions. For ease of illustration and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link (… Figure 2D The process 400 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 400.

[0125] Furthermore, as those skilled in the art will recognize, some of the processes in 400 can be performed independently by the two WTRUs. Therefore, for ease of explanation and simplicity, in the following description, the designations “WTRU 102a (WTRU 102b)” and “WTRU 102b (WTRU 102a)” are used to reflect the individual performance of the WTRUs. Also for ease of explanation and simplicity, in the following description, the term “WTRU 102a” refers to one of the two WTRUs, and the term “WTRU 102b” refers to the other WTRU.

[0126] The WTRU application layer of WTRU 102a (e.g., WTRU application 103) can initiate a service using PC5 unicast communication (402). WTRU 102a can establish a Security Layer-2 link with WTRU 102b on the PC5 interface (404). In an implementation, WTRU 102a can send a direct communication request message to WTRU 102b. Sending a direct communication request message can trigger mutual authentication. WTRU 102b can receive the direct communication request message and can initiate a procedure for mutual authentication. Successful completion of the mutual authentication procedure completes the establishment of a Security Layer-2 link on PC5.

[0127] WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to maintain the Layer-2 link on PC5 (406). WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to determine if the PC5 side link is not feasible or no longer feasible for communication with WTRU 102b (WTRU 102a) (e.g., as a proxy for detecting that WTRUs are not within each other's proximity / ProSe communication range) (408).

[0128] The SL-EEF 314 of WTRU 102a (WTRU 102b) can generate a PC5 notification report (410) using PC5 infeasibility information and a side link identifier. For example, the SL-EEF 314 can connect or otherwise combine PC5 infeasibility information and a side link identifier to form a PC5 notification report.

[0129] SL-EEF 314 can provide PC5 notification reports to NAS entity 216 for transmission to AMF 182 (412). NAS entity 216 can invoke the NAS protocol to transmit the PC5 notification report to AMF 182 using the N1 interface. The NAS entity can transmit the PC5 notification report to AMF 182 within the NAS message container of the service request message (414). Sending a NAS message to the network when WTRU 102a (WTRU 102b) is in RRC_IDLE mode enables the WTRU to initiate an RRC connection (and enter RRC_CONNECTED mode).

[0130] WTRU 102a (WTRU 102b) can listen for responses (416) to service request messages from AMF182. This response can be, for example, a service rejection message or a service acceptance message (or another similar type of message).

[0131] If the response to the service request message is a service rejection message, WTRU 102a (WTRU 102b) can continue to initiate a Layer-2 link release on PC5 and can terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation can be considered unsuccessful. If the response to the service request message is a service acceptance message, WTRU 102a (WTRU 102b) can transition from the connection management state CM-IDLE to CM-CONNECTED (418). While in the CM-CONNECTED state, WTRU 102a (WTRU 102b) can initiate a PDU session establishment request requested by the UE and may include a set of QoS rules / packet filters for the sidelink identifier (420).

[0132] WTRU 102a (WTRU 102b) can listen to the network to receive a response (422) to a UE's request for PDU session establishment. The response can be, for example, a PDU session establishment accept message or a PDU session establishment reject message (or another similar message). If the response to the UE's request for PDU session establishment is a PDU session establishment reject message, WTRU 102a (WTRU 102b) can proceed to initiate a Layer-2 link release on PC5 (424) and can terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation can be considered unsuccessful. Alternatively, if the response to the UE's request for PDU session establishment is a PDU session establishment accept message, the application layer of WTRU 102a can use the newly established PDU session to send ProSe packets to the ProSe application server (426). WTRU 102a (WTRU 102b) can initiate a Layer-2 link release on PC5 (424) and can terminate the PC5 service continuity procedure. In these cases, PC5 service continuity operations can be considered successful.

[0133] PDU session establishment request messages and / or PDU session modification request messages may include one or more IEs configured to carry either a requested packet filter (QoS rule) or a requested QoS flow description. The packet filter (QoS rule) associated with the sidelink identifier may be carried by the PDU session establishment (modification) request message in various ways (e.g., in various IEs of the message). For example, the packet filter (QoS rule) may be carried in an extended protocol configuration option IE of the PDU session establishment (modification) request message. Alternatively, the packet filter (QoS rule) may be carried in one or more other IEs of the PDU session establishment (modification) request message (e.g., in extensions), such as in either the "Requested QoS Rule" IE or the "Requested QoS Flow Description" IE.

[0134] Figure 5 The message exchange 500 related to PC5 notification reporting is shown. PC5 notification reports can be transmitted to AMF 182 using the WTRU activity notification procedure. For ease of explanation and simplicity, refer to the WTRU architecture 200 (Figure 2) and the PC5 unicast link (…). Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe the message exchange 500. Different architectures can also be used to perform message exchange.

[0135] Furthermore, message exchange 500 can be applied to or combined (e.g., support) to perform service continuity related to two WTRUs participating in side link communication. As those skilled in the art will recognize, message exchange 500 can be performed individually by the two WTRUs and their corresponding AMF, NEF, and UDM. However, for the sake of convenience and simplicity, the names “WTRU,” “AMF,” “NEF,” and “UDM” (i.e., the singular form) are used in the following description.

[0136] refer to Figure 5 When in CM-IDLE state, WTRU 102 can send a PC5 notification report (502) to AMF 182 within the NAS message container of the service request message. In this implementation, the PC5 notification report can be carried within one or more IEs of the NAS message container, such as the NAS message container content IE (e.g., such as...). Figure 6 (As depicted in the exemplary NAS message container shown).

[0137] Because WTRU 102 can send service request messages while in CM-IDLE state, its IE (Interceptor Message) can be sent as a non-plaintext IE since the service request message is the initial NAS message. WTRU 102 in CM-IDLE state can use the service request procedure to request the establishment of a secure connection with AMF 182. Alternatively, the network (e.g., 5GC) can use the service request procedure to request the establishment of a secure connection between WTRU 102, AMF 182, and the application server. The service request procedure can be used by WTRU 102 in CM-IDLE and / or CM-CONNECTED state to activate the user plane connection of the established PDU session.

[0138] AMF 182 may send a service acceptance message (504) to WTRU 102 to acknowledge that the network has accepted the service request. Alternatively, for example, if the network is unable to accept the service request, AMF 182 may send a service rejection message to WTRU 102 (504).

[0139] PC5 notification events can be used by AMF 182 Namf_EventExposure Service exposure (e.g., in addition to other events exposed). In the implementation, AMF 182 can initiate to UDM 191 Namf_EventExposure_ Notify Service operation message (506). UDM 191 can receive messages for WTRU 102. Namf_EventExposure_ Notify Service operation message (506), and may trigger and / or send appropriate notification to NEF 187 (not shown).

[0140] Alternatively, AMF 182 may initiate (for example, directly to) NEF 187. Namf_EventExposure_Notify Service operation message (508). For example, if UDM 191 indicates that the notification will be sent directly to NEF 187 and / or if AMF182 has been notified by NEF 187 that NEF 187 will receive the notification directly from AMF 182, then AMF182 can do so. For example, NEF 187 can send... Namf_EventExposure_Subscribe_service The operation message is sent to AMF 182 as follows.

[0141] WTRU 102 can transition from CM-IDLE to CM-CONNECTED after receiving a service acceptance message from AMF 182. When in CM-CONNECTED state, WTRU 102 can initiate a PDU session establishment request message for WTRU request, which includes a set of QoS rules / packet filters (510) associated with the sidelink identifier.

[0142] Figure 7 The diagram illustrates message exchange 700 related to PC5 notification event subscription and notification operations. PC5 notification events can be handled by, for example, AMF 182. Namf_EventExposure Service exposure (e.g., events other than those exposed by AMF 182). According to Message Exchange 700, ProSe Application Server 189 can receive one or more notifications of PC5 notification events. For ease of explanation and simplicity, refer to WTRU Architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe the message exchange 700. Different architectures can also be used to perform message exchange.

[0143] Furthermore, message exchange 700 can be applied to or combined (e.g., support) to perform service continuity related to two WTRUs participating in side-link communication. As those skilled in the art will recognize, some of the message exchange 700 can be performed individually by the NEF and AMF associated with each of the two WTRUs participating in side-link communication. However, for the sake of convenience and simplicity of illustration, the names “AMF” and “NEF” (i.e., the singular form) are used in the following description.

[0144] refer to Figure 7 NEF 187 can be used, for example... Namf_EventExposure_Subscribe A request to send a subscription to PC5 notification events to AMF 182 (e.g., in addition to other events exposed by AMF 182) (702). NEF 187 can... Namf_EventExposure_SubscribeThe request includes an identifier for the PC5 notification event. NEF 187 can provide the associated notification endpoint for the PC5 notification event. The associated endpoint can be NEF 187 itself. Alternatively, the associated endpoint can be the ProSe application server 189. AMF 182 can authorize reporting event subscriptions and can log the association between event triggers and requester identities.

[0145] AMF 182 can confirm execution. Namf_EventExposure_Subscribe (704). ProSe application server 189 can, for example, use Nnef_EventExposure_Subscribe A request to send a subscription to PC5 notification events to NEF 187 (e.g., in addition to other events exposed by AMF 182 and / or NEF 187) (706). ProSe application server 189 can... Nnef_EventExposure_Subscribe The request includes an identifier for the PC5 notification event. The ProSe application server 189 can include this request (e.g., in...). Nnef_EventExposure_Subscribe (In the request) Provide the associated notification endpoints for the PC5 notification event. The associated endpoints can be, for example, ProSe application server 189 and / or NEF 187. NEF 187 can authorize reporting event subscriptions and can log the association between event triggers and requester identities (such as the identifier of ProSe application server 189 (the identifier associated with ProSe application server 189, assigned to ProSe application server 189, etc.)).

[0146] NEF 187 can confirm execution. Nnef_EventExposure_Subscribe (708). The AMF 182 can detect that a monitored PC5 notification event has occurred, and can, for example, use... Namf_EventExposure_Notify The message sends an event report (710) to the notification endpoint. For example, the notification endpoint could be NEF 187 and / or ProSe application server 189. NEF 187 can receive PC5 notification event reports from AMF 182 and can, for example, use... Nnef_EventExposure_ Notify The message sends the PC5 notification event report to the ProSe application server 189 (712).

[0147] In this implementation, the ProSe application server 189 can receive PC5 notification reports from each of two (or more) WTRUs. In this implementation, the ProSe application server 189 can receive PC5 notification reports and can extract the corresponding unicast link profile identified by the PC5 link identifier.

[0148] In the implementation, the ProSe application server 189 can create and maintain a mapping between two (or more) WTRUs, at least in part, based on unicast link profiles. The ProSe application server 189 can use a table (data structure) to create and / or maintain the mapping between two (or more) WTRUs. An example of a table (“PC5 Notification Mapping Table”) could be Table 2 below, where the entries in the first two columns are populated based on the PC5 notification reports of the two WTRUs (columned as WTRU 102a and WTRU 102b) (e.g., using the identifiers provided in those PC5 notification reports).

[0149] WTRU 102a Application Layer ID WTRU 102b Application Layer ID WTRU 102a source address WTRU 102b source address A B 1 2 C D 3 4 Table 2 - PC5 Notification Mapping In one implementation, after successfully establishing a PDU session for WTRU 102a, ProSe application server 189 can receive ProSe packets from WTRU 102a. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address. If not previously populated, ProSe application server 189 can populate the discovered source address of WTRU 102a into the corresponding entry in a PC5 notification map table (e.g., Table 2). If the PC5 notification map table (e.g., Table 2) includes an entry populated with the source address of WTRU 102b, ProSe application server 189 can forward the ProSe packet to WTRU 102b. If the PC5 notification map table lacks sufficient information to forward such packets, ProSe application server 189 can buffer the ProSe packets. In various implementations, ProSe application server 189 can send some or all of the constructed PC5 notification map tables (e.g., mappings corresponding to WTRUs) to the WTRU. WTRU can receive mappings and can use routable destination addresses to send subsequent ProSe packets (addressing).

[0150] In the implementation, after a successful PDU session is established for WTRU 102b, ProSe application server 189 can receive ProSe packets from WTRU 102b. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address.

[0151] If not previously populated, the ProSe application server 189 can populate the source address discovered by WTRU 102b into the corresponding entry in the PC5 notification map table (e.g., Table 2). If the PC5 notification map table (e.g., Table 2) includes an entry populated with the source address of WTRU 102a, the ProSe application server 189 can forward ProSe packets to WTRU 102a. If the PC5 notification map table lacks sufficient information to forward such packets, the ProSe application server 189 can buffer ProSe packets. In various implementations, the ProSe application server 189 can send some or all of the constructed PC5 notification map table mappings (e.g., mappings corresponding to WTRUs) to the WTRU. The WTRU can receive the mappings and can use the routable destination address to send subsequent ProSe packets (addressing).

[0152] Figure 8 This is a message diagram illustrating an exemplary sidelink state transition notification procedure 800. The sidelink state transition notification procedure 800 can be suitable for scenarios where two WTRUs involved in the sidelink transmission are in connection management states CONNECTED and RRC_CONNECTED, but do not have active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link (… Figure 2D The architecture of the side link state transition notification procedure is described in Figure 1, along with the architecture of the communication system 100. Different architectures can also be used to execute the side link state transition notification procedure.

[0153] Furthermore, the sidelink state transition notification procedure 800 can be applied to or combined with (e.g., support) the execution of service continuity related to two WTRUs participating in sidelink communication. As those skilled in the art will recognize, the sidelink state transition notification procedure 800 can be executed individually by the two WTRUs and their corresponding RANs and AMFs. However, for the sake of convenience and simplicity, the names “WTRU,” “RAN,” and “AMF” (i.e., the singular form) are used in the following description.

[0154] refer to Figure 8 When a target WTRU (e.g., WTRU 102a) is in a CM-CONNECTED state, AMF 182 can request RAN 113 to report side link state information (802). The side link state change report requested by AMF 182 can be based on each WTRU.

[0155] AMF 182 can send a WTRU-side traverse state transition notification request to RAN113 (802). The WTRU-side traverse state transition notification request message can identify the WTRU to be notified. The WTRU-side traverse state transition notification request can indicate the notification behavior for subsequent traverse state transitions when the WTRU moves into or out of ProSe communication range.

[0156] RAN 113 can receive UE-side traversal state transition notification requests and can configure / update the traversal measurement configuration to include PC5 infeasibility information (e.g., PC5 keepalive timeout) as a criterion for triggering the WTRU to send a traversal measurement report (804). The V2X / ProSe layer in the WTRU can notify the AS layer of the PC5 infeasibility information. Alternatively, RAN 113 can configure a threshold for RRC measurements of PC5 link quality, and the WTRU can send an RRC measurement when the PC5 quality is below the set threshold. When in CM-CONNECTED and RRC_CONNECTED states, the WTRU can send an RRC carrying a PC5 notification report to RAN 113. Measurement Report Message (806).

[0157] The RAN can send a WTRU-side traverse state notification message (808) to the AMF 182, which may include a PC5 notification report. The WTRU-side traverse state transition notification request can specify a notification action. For example, if specified as a notification action in a UE-side traverse state transition notification request, the WTRU-side traverse state notification message can be sent as a switch notification. Alternatively, if specified as a notification action in a UE-side traverse state transition notification request, the WTRU-side traverse state notification message can be sent each time the traverse state changes. The AMF 182 can send a cancel UE-side traverse state notification message (810) to notify the RAN 113 that notifications for a given WTRU should be terminated.

[0158] Figure 9 This is a block diagram illustrating an exemplary WTRU architecture 900 according to an implementation scheme. The WTRU architecture 900 may be adapted to generate PC5 notification reports and / or transmit PC5 notification reports to an AMF, such as AMF 182 (Figure 1). The WTRU architecture 900 is similar to... Figure 3 The WTRU architecture 300 differs in that the SL-EEF 314 can transmit PC5 notification reports to RAN 113 via RRC entity 950 and / or invoke the RRC protocol to transmit new PC5 notification reports to RAN 113.

[0159] Figure 10This is a flowchart illustrating an exemplary process 1000 for performing service continuity according to various implementation schemes. Process 1000 can be adapted to perform service continuity in which two WTRUs involved in sidelink transmission are in connection management states CM-CONNECTED and RRC_CONNECTED, without having active PDU sessions. For ease of illustration and simplicity, reference is made to WTRU architecture 900 (…). Figure 9 ), PC5 unicast link ( Figure 2D The process 1000 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 1000.

[0160] Furthermore, as those skilled in the art will recognize, some of the processes in 1000 can be performed independently by the two WTRUs. Therefore, for ease of explanation and simplicity, in the following description, the designations "WTRU 102a (WTRU 102b)" and "WTRU 102b (WTRU 102a)" are used to reflect the individual performance of the WTRUs. Similarly, for ease of explanation and simplicity, in the following description, the designation "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0161] The WTRU application layer of WTRU 102a (e.g., WTRU application 103) can initiate a service using PC5 unicast communication (1002). WTRU 102a can establish a Security Layer-2 link with WTRU 102b on the PC5 interface (1004). In an implementation, WTRU 102a can send a direct communication request message to WTRU 102b. Sending a direct communication request message can trigger mutual authentication. WTRU 102b can receive the direct communication request message and can initiate a procedure for mutual authentication. Successful completion of the mutual authentication procedure completes the establishment of a Security Layer-2 link on PC5.

[0162] WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to maintain the Layer-2 link on PC5 (1006). WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to determine if the PC5 side link is not feasible or no longer feasible for communication with WTRU 102b (WTRU 102a) (e.g., as a proxy for detecting that WTRUs are not within each other's proximity / ProSe communication range) (1008).

[0163] The SL-EEF 314 of WTRU 102a (WTRU 102b) can generate a PC5 notification report (1010) using PC5 infeasibility information and side link identifiers. For example, the SL-EEF 314 can connect or otherwise combine PC5 infeasibility information and side link identifiers to form a PC5 notification report.

[0164] SL-EEF 314 can provide PC5 notification reports to RRC entity 902 (1012). RRC entity 902 can invoke the RRC protocol to transmit the PC5 notification report to RAN 113 (1014). In an implementation, the V2X / ProSe layer in WTRU 102a (WTRU 102b) can invoke the RRC protocol to transmit PC5 notification reports. RRC entity 902 of WTRU 102a (WTRU 102b) can... Measurement Report Send a PC5 notification report within the message.

[0165] WTRU 102a (WTRU 102b) can initiate a PDU session establishment request for WTRU requests and may include a set of QoS rules / packet filters (1016) with sidelink identifiers.

[0166] WTRU 102a (WTRU 102b) can listen on the network to receive a response to a PDU session establishment request requested by WTRU (1018). The response can be, for example, a PDU session establishment accept message or a PDU session establishment reject message (or another similar message). If the response to a PDU session establishment request requested by WTRU is a PDU session establishment reject message, WTRU 102a (WTRU 102b) can proceed to initiate a Layer-2 link release on PC5 (1018) and can terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation can be considered unsuccessful.

[0167] Alternatively, if the response to the PDU session establishment request requested by the WTRU is a PDU session establishment accept message, the application layer can use the newly established PDU session to send ProSe packets to the ProSe application server (1020). WTRU 102a (WTRU 102b) can initiate a Layer-2 link release on PC5 (1022) and can terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation can be considered successful.

[0168] PDU session establishment request messages and / or PDU session modification request messages may include one or more IEs configured to carry either a requested packet filter (QoS rule) or a requested QoS flow description. The packet filter (QoS rule) associated with the sidelink identifier may be carried by the PDU session establishment (modification) request message in various ways (e.g., in various IEs of the message). For example, the packet filter (QoS rule) may be carried in an extended protocol configuration option IE of the PDU session establishment (modification) request message. Alternatively, the packet filter (QoS rule) may be carried in one or more other IEs of the PDU session establishment (modification) request message (e.g., in extensions), such as in either the "Requested QoS Rule" IE or the "Requested QoS Flow Description" IE.

[0169] Figure 11 The message exchange 1100 related to PC5 notification reporting is shown. PC5 notification reports can be transmitted to AMF 182 via RAN 113 using the WTRU activity notification procedure. For ease of explanation and simplicity, refer to WTRU architecture 900 (…). Figure 9 ), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe message exchange. Different architectures can also be used to perform message exchange.

[0170] Furthermore, message exchange 1100 can be applied to or combined with (e.g., support) the performance of service continuity related to two WTRUs participating in side link communication. As those skilled in the art will recognize, message exchange 1100 can be performed individually by the two WTRUs and their corresponding RAN, AMF, UDM, and NEF. However, for the sake of convenience and simplicity, the names “WTRU,” “RAN,” “AMF,” “UDM,” and “NEF” (i.e., the singular form) are used in the following description.

[0171] refer to Figure 11 When in CM-CONNECTED and RRC_CONNECTED states, WTRU 102 can be in RRC. Measurement Report The message sends a PC5 notification report (1102) to RAN 113. RAN 113 can then use RRC. Measurement Report It can receive PC5 notification reports and can send WTRU-side link status notification messages (1104) including new PC5 notification reports to AMF 182.

[0172] PC5 notification events can be used by AMF 182 Namf_EventExposureService exposure (e.g., in addition to other events exposed). In the implementation, AMF 182 can initiate to UDM 191 Namf_EventExposure_ Notify Service operation message (1106). UDM 191 can receive messages for WTRU 102a. Namf_EventExposure_ Notify Service operation message (506), and may trigger and / or send appropriate notification to NEF 187 (not shown).

[0173] Alternatively, AMF 182 may initiate (for example, directly to) NEF 187. Namf_EventExposure_Notify Service operation message (1108). For example, if UDM 191 indicates that the notification will be sent directly to NEF 187 and / or if AMF182 has been notified by NEF 187 that NEF 187 will receive the notification directly from AMF 182, then AMF182 can do so. For example, NEF 187 can send... Namf_EventExposure_Subscribe_service The operation message notifies AMF 182 as follows. WTRU 102 can initiate a PDU session establishment request for a WTRU request, and may include a set of QoS rules / packet filters (1110) associated with the sidelink identifier.

[0174] Figure 12 The diagram illustrates a message exchange 1200 related to PC5 notification event subscription and notification operations. PC5 notification events can be handled by, for example, AMF 182 using... Namf_EventExposure Service exposure (e.g., events other than those exposed by AMF 182). Based on message exchange, ProSe application server 189 can subscribe to NEF 187 to receive notifications of PC5 notification events. For ease of explanation and simplicity, refer to WTRU architecture 900 (…). Figure 9 ), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe the message exchange 1200. Different architectures can also be used to perform message exchange.

[0175] Furthermore, message exchange 1200 can be applied to or combined with (e.g., support) the performance of service continuity related to two WTRUs participating in side-link communication. As those skilled in the art will recognize, some of the message exchange 1200 can be performed individually by the NEF and AMF associated with each of the two WTRUs participating in side-link communication. However, for the sake of convenience and simplicity of illustration, the names “AMF” and “NEF” (i.e., the singular form) are used in the following description.

[0176] refer to Figure 12 NEF 187 can be used, for example... Namf_EventExposure_SubscribeA request is sent to AMF 182 to subscribe to PC5 notification events (e.g., in addition to other events exposed by AMF 182) (1202). NEF 187 can... Namf_EventExposure_Subscribe The request includes an identifier for the PC5 notification event. NEF 187 can include this request (e.g., in...). Nnef_EventExposure_Subscribe (In the request) Provide the associated notification endpoint for the PC5 notification event. The associated endpoint can be NEF 187. Alternatively, the associated endpoint can be ProSe application server 189. AMF182 can authorize reporting event subscriptions and can log the association between event triggers and requester identities (such as the identifier of ProSe application server 189 (the identifier associated with ProSe application server 189, assigned to ProSe application server 189, etc.)).

[0177] AMF 182 can confirm execution. Namf_EventExposure_Subscribe (1204). ProSe application server 189 can, for example, use Nnef_EventExposure_Subscribe The request is to send a request (1206) to subscribe to the set of event IDs in NEF 187. ProSe application server 189 can... Nnef_EventExposure_Subscribe The request includes the identifier ID of the PC5 notification event. ProSe application server 189 can provide the associated notification endpoint for the PC5 notification event. The associated endpoint can be, for example, ProSe application server 189 and / or ProSe application server 189. NEF 187 can authorize reporting event subscriptions and can log the association between event triggers and requester identities (such as the identifier of ProSe application server 189 (the identifier associated with ProSe application server 189, assigned to ProSe application server 189, etc.)).

[0178] NEF 187 can confirm execution. Nnef_EventExposure_Subscribe (1208). The AMF 182 can detect that a monitored PC5 notification event has occurred, and can, for example, use... Namf_EventExposure_Notify The message sends an event report (1210) to the notification endpoint. For example, the notification endpoint could be NEF 187 and / or ProSe application server 189. NEF 187 can receive PC5 notification event reports from AMF 182 and can, for example, use... Nnef_EventExposure_ Notify The message sends the PC5 notification event report to the ProSe application server 189 (1212).

[0179] In this implementation, the ProSe application server can receive PC5 notification reports from two or more of the WTRU 102. In this implementation, the ProSe application server 189 can receive PC5 notification reports and can extract the corresponding unicast link profile identified by the PC5 link identifier.

[0180] In the implementation, the ProSe application server 189 can create and maintain a mapping between two (or more) WTRUs, at least in part, based on a unicast link profile. The ProSe application server 189 can use a PC5 notification mapping table to create and / or maintain the mapping between the two (or more) WTRUs. The PC5 notification mapping table can be Table 2 below, where the entries in the first two columns are populated based on the PC5 notification reports of the two WTRUs (columned as WTRU 102a and WTRU 102b) (e.g., using identifiers provided in those PC5 notification reports).

[0181] In one implementation, after successfully establishing a PDU session for WTRU 102a, ProSe application server 189 can receive ProSe packets from WTRU 102a. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address. If not previously populated, ProSe application server 189 can populate the discovered source address of WTRU 102a into the corresponding entry in the PC5 notification mapping table (e.g., Table 2). If the PC5 notification mapping table (e.g., Table 2) includes an entry populated with the source address of WTRU 102b, ProSe application server 189 can forward the ProSe packet to WTRU 102b. If the mapping table lacks sufficient information to forward such packets, ProSe application server 189 can buffer the ProSe packets. In various implementations, ProSe application server 189 can send some or all of the constructed mapping tables (e.g., mappings corresponding to WTRUs) to the WTRU. WTRU can receive mappings and can use routable destination addresses to send subsequent ProSe packets (addressing).

[0182] In the implementation, after a successful PDU session is established for WTRU 102b, ProSe application server 189 can receive ProSe packets from WTRU 102b. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address.

[0183] If not previously populated, the ProSe application server 189 can populate the source address discovered by WTRU 102b into the corresponding entry in the PC5 notification mapping table (e.g., Table 2). If the PC5 notification mapping table (e.g., Table 2) includes an entry populated with the source address of WTRU 102a, the ProSe application server 189 can forward ProSe packets to WTRU 102a. If the mapping table lacks sufficient information to forward such packets, the ProSe application server 189 can buffer ProSe packets. In various implementations, the ProSe application server 189 can send some or all of the mappings from the constructed mapping table (e.g., mappings corresponding to WTRUs) to the WTRU. The WTRU can receive the mappings and can use the routable destination address to send subsequent ProSe packets (addressing).

[0184] Figure 13 This is a message diagram illustrating an exemplary sidelink state transition notification procedure 1300. The sidelink state transition notification procedure 1300 can be suitable for scenarios where two WTRUs involved in the sidelink transmission are in connection management states CONNECTED and RRC_CONNECTED, and have one or more active PDU sessions. For ease of illustration and simplicity, refer to WTRU architecture 900 (…). Figure 9 ), PC5 unicast link ( Figure 2C The architecture of the side link state transition notification procedure is described in Figure 1, along with the architecture of the communication system 100. Different architectures can also be used to execute the side link state transition notification procedure.

[0185] Furthermore, the sidelink state transition notification procedure 1300 can be applied to or combined with (e.g., support) the execution of service continuity related to two WTRUs participating in sidelink communication. As those skilled in the art will recognize, the sidelink state transition notification procedure 1300 can be executed individually by the two WTRUs and their corresponding RANs and AMFs. However, for the sake of convenience and simplicity, the names “WTRU,” “RAN,” and “AMF” (i.e., the singular form) are used in the following description.

[0186] refer to Figure 13 When a target WTRU (e.g., WTRU 102a) is in a CM-CONNECTED state, AMF 182 can request RAN 113 to report side link state information. The side link state transition reports requested by AMF 182 can be based on each WTRU.

[0187] AMF 182 can send a WTRU-side traverse state transition notification request to RAN113 (1302). The WTRU-side traverse state transition notification request message can identify the WTRU to be notified. The WTRU-side traverse state transition notification request can indicate the notification behavior for subsequent traverse state transitions when the WTRU moves into and out of ProSe communication range.

[0188] RAN 113 can receive UE-side traversal state transition notification requests and can configure / update the traversal measurement configuration to include PC5 infeasibility information (e.g., PC5 keepalive timeout) as a criterion for triggering the WTRU to send a traversal measurement report (1304). The V2X / ProSe layer in the WTRU can notify the AS layer of the PC5 infeasibility information. Alternatively, RAN 113 can configure a threshold for RRC measurements of PC5 link quality, and the WTRU can send an RRC measurement when the PC5 quality is below the set threshold. When in CM-CONNECTED and RRC_CONNECTED states, the WTRU can send an RRC carrying a PC5 notification report to RAN 113. Measurement Report Message (1306).

[0189] The RAN can send a WTRU-side traverse state notification message (1308) to the AMF 182, which may include a PC5 notification report. The WTRU-side traverse state transition notification request can specify a notification action. For example, if specified as a notification action in a UE-side traverse state transition notification request, the WTRU-side traverse state notification message can be sent as a switch notification. Alternatively, if specified as a notification action in a UE-side traverse state transition notification request, the WTRU-side traverse state notification message can be sent each time the traverse state changes. The AMF 182 can send a cancel UE-side traverse state notification message (1310) to notify the RAN 113 that notifications for a given WTRU should be terminated.

[0190] Figure 14 This is a block diagram illustrating an exemplary WTRU architecture 1400 according to an implementation scheme. WTRU architecture 1400 may be adapted to generate PC5 notification reports and / or transmit PC5 notification reports to RAN 113. WTRU architecture 1200 is similar to... Figure 9 The WTRU architecture 900.

[0191] Figure 15This is a flowchart illustrating an exemplary process 1500 for performing service continuity according to various implementation schemes. Process 1500 can be adapted to perform service continuity in which two WTRUs involved in sidelink transmission are in connection management states CM-CONNECTED and RRC_CONNECTED, and have one or more active PDU sessions. For ease of illustration and simplicity, reference is made to WTRU architecture 1400 (…). Figure 14 ), PC5 unicast link ( Figure 2D The process 1500 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 1500.

[0192] Furthermore, as those skilled in the art will recognize, some of the processes in 1500 can be performed independently by the two WTRUs. Therefore, for ease of explanation and simplicity, in the following description, the designations “WTRU 102a (WTRU 102b)” and “WTRU 102b (WTRU 102a)” are used to reflect the individual performance of the WTRUs. Similarly, for ease of explanation and simplicity, in the following description, the designation “WTRU 102a” refers to one of the two WTRUs, and the term “WTRU 102b” refers to the other WTRU.

[0193] The WTRU application layer of WTRU 102a (e.g., WTRU application 103) can initiate a service using PC5 unicast communication (1502). WTRU 102a can establish a Security Layer-2 link with WTRU 102b on the PC5 interface (1504). In an implementation, WTRU 102a can send a direct communication request message to WTRU 102b. Sending a direct communication request message can trigger mutual authentication. WTRU 102b can receive the direct communication request message and can initiate a procedure for mutual authentication. Successful completion of the mutual authentication procedure completes the establishment of a Security Layer-2 link on PC5.

[0194] WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to maintain the Layer-2 link on PC5 (1506). WTRU 102a (WTRU 102b) may use the keep-alive or other functions of PC5 signaling protocol entity 312a to determine if the PC5 side link is not feasible or no longer feasible for communication with WTRU 102b (WTRU 102a) (e.g., as a proxy for detecting that WTRUs are not within each other's proximity / ProSe communication range) (1508).

[0195] The SL-EEF 314 of WTRU 102a (WTRU 102b) can generate a PC5 notification report (1510) using PC5 infeasibility information and side link identifiers. For example, the SL-EEF 314 can connect or otherwise combine PC5 infeasibility information and side link identifiers to form a PC5 notification report.

[0196] SL-EEF 314 can provide PC5 notification reports to RRC entity 1402 (1512). RRC entity 902 can invoke the RRC protocol to transmit the PC5 notification report to RAN 113 (1514). In the implementation, the V2X / ProSe layer in the WTRU can invoke the RRC protocol to transmit the PC5 notification report. RRC entity 902 can provide PC5 notification reports to RRC 1402 (1514). Measurement Report Send a PC5 notification report within the message.

[0197] WTRU 102a (WTRU 102b) can initiate a PDU session modification request requested by WTRU and may include a set of QoS rules / packet filters associated with a sidelink identifier (1516). WTRU 102a (WTRU 102b) can listen to the network to obtain a response to the PDU session modification request requested by WTRU (1518). The response may be, for example, a PDU session modification accept message or a PDU session modification reject message (or another similar message). If the response to the PDU session modification request requested by WTRU is a PDU session modification reject message, WTRU 102a (WTRU 102b) may continue to initiate a Layer-2 link release on PC5 (1518) and may terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation may be considered unsuccessful.

[0198] Alternatively, if the response to the PDU session modification request requested by the WTRU is a PDU session modification accept message, the application layer can use the established PDU session to send ProSe packets to the ProSe application server (1520). WTRU 102a (WTRU 102b) can initiate a Layer-2 link release on PC5 (1522) and can terminate the PC5 service continuity procedure. In these cases, the PC5 service continuity operation can be considered successful.

[0199] PDU session establishment request messages and / or PDU session modification request messages may include one or more IEs configured to carry either a requested packet filter (QoS rule) or a requested QoS flow description. The packet filter (QoS rule) associated with the sidelink identifier may be carried by the PDU session establishment (modification) request message in various ways (e.g., in various IEs of the message). For example, the packet filter (QoS rule) may be carried in an extended protocol configuration option IE of the PDU session establishment (modification) request message. Alternatively, the packet filter (QoS rule) may be carried in one or more other IEs of the PDU session establishment (modification) request message (e.g., in extensions), such as in either the "Requested QoS Rule" IE or the "Requested QoS Flow Description" IE.

[0200] Figure 16 The message exchange 1600 related to PC5 notification reporting is shown. PC5 notification reports can be transmitted to AMF 182 via RAN 113 using the WTRU activity notification procedure. For ease of explanation and simplicity, refer to WTRU architecture 1400 (…). Figure 14 ), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe message exchange. Different architectures can also be used to perform message exchange.

[0201] Furthermore, message exchange 1600 can be applied to or combined with (e.g., support) the performance of service continuity related to two WTRUs participating in side link communication. As those skilled in the art will recognize, message exchange 1600 can be performed individually by the two WTRUs and their corresponding RAN, AMF, UDM, and NEF. However, for the sake of convenience and simplicity, the names “WTRU,” “RAN,” “AMF,” “UDM,” and “NEF” (i.e., the singular form) are used in the following description.

[0202] refer to Figure 16 When in CM-CONNECTED and RRC_CONNECTED states, WTRU 102 can be in RRC. Measurement Report The message sends a PC5 notification report (1602) to RAN 113. RAN 113 can then use RRC. Measurement Report It can receive PC5 notification reports and can send WTRU-side link status notification messages (1604) including new PC5 notification reports to AMF 182.

[0203] PC5 notification events can be used by AMF 182 Namf_EventExposureService exposure (e.g., in addition to other events exposed). In the implementation, AMF 182 can initiate to UDM 191 Namf_EventExposure_ Notify Service operation message (1606). UDM 191 can receive messages for WTRU 102a. Namf_EventExposure_ Notify Service operation message (506), and may trigger and / or send appropriate notification to NEF 187 (not shown).

[0204] Alternatively, AMF 182 may initiate (for example, directly to) NEF 187. Namf_EventExposure_Notify Service operation message (1608). For example, if UDM 191 indicates that the notification will be sent directly to NEF 187 and / or if AMF182 has been notified by NEF 187 that NEF 187 will receive the notification directly from AMF 182, then AMF182 can do so. For example, NEF 187 can send... Namf_EventExposure_Subscribe_service The operation message notifies AMF 182 as follows. The WTRU can initiate a PDU session modification request for the WTRU request, and can include a set of QoS rules / packet filters that includes the side link identifier.

[0205] Figure 17 The diagram illustrates the message exchange related to PC5 notification event subscription and notification operations. PC5 notification events can be used by AMF 182. Namf_EventExposure Service exposure (e.g., events other than those exposed by AMF 182). Based on message exchange, ProSe application server 189 can subscribe to NEF 187 to receive notifications of PC5 notification events. For ease of explanation and simplicity, refer to WTRU architecture 1400 ( Figure 14 ), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe message exchange. Different architectures can also be used to perform message exchange.

[0206] Furthermore, message exchange 1700 can be applied to or combined with (e.g., support) the performance of service continuity related to two WTRUs participating in side-link communication. As those skilled in the art will recognize, some of the message exchange 170 can be performed individually by the NEF and AMF associated with each of the two WTRUs participating in side-link communication. However, for the sake of convenience and simplicity of illustration, the names “AMF” and “NEF” (i.e., the singular form) are used in the following description.

[0207] refer to Figure 17 NEF 187 can be used, for example... Namf_EventExposure_SubscribeA request to send a subscription to PC5 notification events to the AMF (e.g., in addition to events exposed by AMF 182) (1702). NEF 187 can... Namf_EventExposure_Subscribe The request includes an identifier for the PC5 notification event. NEF 187 can include this request (e.g., in...). Nnef_EventExposure_Subscribe (In the request) Provide the associated notification endpoint for the PC5 notification event. The associated endpoint can be NEF 187. Alternatively, the associated endpoint can be ProSe application server 189. AMF 182 can authorize reporting event subscriptions and can record the association between event triggers and requester identities (such as the identifier of ProSe application server 189 (the identifier associated with ProSe application server 189, assigned to ProSe application server 189, etc.)).

[0208] AMF 182 can confirm execution. Namf_EventExposure_Subscribe (1704). ProSe application server 189 can, for example, use Nnef_EventExposure_Subscribe The request is to send a request to subscribe to the set of event IDs in NEF 187 (1706). ProSe application server 189 can... Nnef_EventExposure_Subscribe The request includes the identifier ID of the PC5 notification event. The ProSe application server 189 can provide the associated notification endpoint for the PC5 notification event. The associated endpoint can be, for example, the ProSe application server 189 itself. The NEF 187 can authorize reporting event subscriptions and can record the association between event triggers and requester identities (such as the identifier of the ProSe application server 189 (the identifier associated with, assigned to, etc. of the ProSe application server 189)).

[0209] NEF 187 can confirm execution. Nnef_EventExposure_Subscribe (1708). The AMF 182 can detect that a monitored PC5 notification event has occurred, and can, for example, use... Namf_EventExposure_Notify The message sends an event report (1710) to the notification endpoint. For example, the notification endpoint could be NEF 187 and / or ProSe application server 189. NEF 187 can receive PC5 notification event reports from AMF 182 and can, for example, use... Nnef_EventExposure_ Notify The message sends the PC5 notification event report to the ProSe application server 189 (1712).

[0210] In this implementation, the ProSe application server can receive PC5 notification reports from two or more of the WTRU 102. In this implementation, the ProSe application server 189 can receive PC5 notification reports and can extract the corresponding unicast link profile identified by the PC5 link identifier.

[0211] In the implementation, the ProSe application server 189 can create and maintain a mapping between two (or more) WTRUs 102, at least in part, based on unicast link profiles. The ProSe application server 189 can use a PC5 notification mapping table to create and / or maintain the mapping between the two (or more) WTRUs. The PC5 notification mapping table can be Table 2, where the entries in the first two columns are populated based on the PC5 notification reports of the two WTRUs (columned as WTRU 102a and WTRU 102b) using the identifiers provided in those PC5 notification reports.

[0212] In one implementation, after successfully modifying the PDU session for WTRU 102a, ProSe application server 189 can receive ProSe packets from WTRU 102a. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address. If not previously populated, ProSe application server 189 can populate the discovered source address of WTRU 102a into the corresponding entry in the PC5 notification mapping table (e.g., Table 2). If the PC5 notification mapping table (e.g., Table 2) includes an entry populated with the source address of WTRU 102b, ProSe application server 189 can forward the ProSe packet to WTRU 102b. If the mapping table lacks sufficient information to forward such packets, ProSe application server 189 can buffer the ProSe packets. In various implementations, ProSe application server 189 can send a constructed mapping table to some or all of the mappings of the WTRU (e.g., mappings corresponding to the WTRU). WTRU can receive mappings and can use routable destination addresses to send subsequent ProSe packets (addressing).

[0213] In the implementation, after a successful PDU session is established for WTRU 102b, ProSe application server 189 can receive ProSe packets from WTRU 102b. ProSe application server 189 can examine one or more of the ProSe packets to identify (discover) the associated WTRU application layer identifier and routable source address.

[0214] If not previously populated, the ProSe application server 189 can populate the source address discovered by WTRU 102b into the corresponding entry in the PC5 notification mapping table (e.g., Table 2). If the ProSe application server PC5 notification mapping table (e.g., Table 2) includes an entry populated with the source address of WTRU 102a, the ProSe application server 189 can forward ProSe packets to WTRU 102a. If the mapping table lacks sufficient information to forward such packets, the ProSe application server 189 can buffer ProSe packets. In various implementations, the ProSe application server 189 can send some or all of the constructed mapping table to the WTRU (e.g., mappings corresponding to the WTRU). The WTRU can receive the mappings and can use the routable destination address to send subsequent ProSe packets (addressing).

[0215] Figure 18 This is a flowchart illustrating an exemplary process 1800 for performing service continuity according to various embodiments. The process 1800 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 8 The message exchange described, (iv) Figure 10 The process 1000, (v) combined Figure 11 The message exchange described, (vi) combined Figure 13 The described message exchange, (vii) Figure 15 The process 1500, and (vii) combined Figure 16 The message exchange is described. Process 1800 can be adapted for performing service continuity, in which the two WTRUs participating in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The process 1800 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 1800.

[0216] Furthermore, as those skilled in the art will recognize, process 1800 can be performed independently by two WTRUs. However, for the sake of convenience and simplicity, the term "WTRU" (singular form) will be used in the following description. Also for the sake of convenience and simplicity, in the following description, the term "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0217] refer to Figure 18 WTRU 102a can determine the status of the sidelink between WTRU 102a and WTRU 102b (1802). WTRU 102a can monitor transmissions and can determine the status of the sidelink based on the number of transmissions received within a certain time period, for example, using keep-alive or other functions of PC5 signaling protocol entity 312a to maintain the layer-2 link on PC5. If the number of transmissions received within that time period fails to meet a threshold (e.g., less than 1 transmission), WTRU 102a can determine the status of the sidelink to a first value, and / or if the number of transmissions received within that time period meets a threshold (e.g., greater than or equal to 1 transmission), WTRU 102a can determine the status of the sidelink to a second value. Alternatively, if the number of transmissions received during the time period fails to meet a first threshold (e.g., less than 2 transmissions), WTRU 102a can determine the state of the sidelink to a first value, and if the number of transmissions received during the time period meets a second threshold (e.g., greater than or equal to 5 transmissions), WTRU 102a can determine the state to a second value. If the number of transmissions received during the time period meets the first threshold but fails to meet the second threshold, WTRU 102a can determine the state of the sidelink to a third value. Alternatively, if the number of transmissions received during the time period meets the first threshold but fails to meet the second threshold, WTRU 102a can leave the state of the sidelink unchanged. In various embodiments, the first value can indicate that communication with WTRU 102b is infeasible or no longer feasible for the sidelink. In various embodiments, the first value can indicate that the first WTRU and the second WTRU are not within each other's communication range.

[0218] WTRU 102a can transmit first information indicating the status of the sidelink and a first identifier and a second identifier associated with WTRU 102a and WTRU 102b to a first network element of the core network, from which at least the first identifier and the second identifier are transmitted to the application server (1804). The first network element can be, for example, an AMF or an SMF. The first identifier can be, for example, either an application layer identifier of WTRU 102a or a layer-2 identifier of WTRU 102a. The second identifier can be, for example, either an application layer identifier of WTRU 102b or a layer-2 identifier of WTRU 102b. WTRU 102a can (i) obtain the first identifier and the second identifier from the link profile of the sidelink, (ii) generate first information indicating the status of the sidelink and the first identifier and the second identifier (e.g., a combination thereof) based on the status of the sidelink and the first identifier and the second identifier obtained from the link profile, and (iii) transmit the first information as a notification report (e.g., a PC5 notification report) or transmit it in a notification report. According to the disclosure herein, WTRU 102a can transmit notification reports in either NAS messages or RRC messages (e.g., in one or more IEs and / or their containers). If provided to an application server, the application server can use the first and second identifiers and / or the sidelink status to generate a mapping between WTRU 102a and WTRU 102b, for example, between the first and second identifiers and their respective routable addresses for WTRU 102a and WTRU 102b.

[0219] WTRU 102a can transmit second information (1806) to a second network element in the core network, indicating a description of the traffic flow associated with the sidelink and a request to establish or modify a PDU session. The second network element can be, for example, an SMF. The traffic flow description (“traffic flow description”) can be information (e.g., a collection of information) from which both WTRU 102a and WTRU 102b can identify and / or transmit the traffic flow. The traffic flow description can include, for example, a PFI and any one or more QoS rules (such as a set of packet filters). WTRU 102a can obtain the PFI and QoS rules (e.g., a set of packet filters) from the link profile of the sidelink. The traffic flow description can be used by the second network element to establish a PDU session or modify an existing PDU session.

[0220] WTRU 102a can transmit outbound traffic of a traffic stream and its address (e.g., IP address) to the application server (1808) based on a PDU session. The application server can use the address of WTRU 102a to further develop and / or modify (collectively, “update”) the mapping between WTRU 102a and 102b, and can use the address of WTRU 102a to forward traffic of a traffic stream received from WTRU 102b. WTRU 102a can receive inbound traffic of a traffic stream from the application server based on a PDU session (1810).

[0221] In various implementations, for example, as an option of process 1800, WTRU 102a may receive the address of WTRU 102b from an application server (not shown), and / or may use the address of WTRU 102b to transmit outbound traffic of the traffic stream. In various implementations, for example, as an option of process 1800, WTRU 102a may receive information from a second network element of the core network to trigger a request to modify a PDU session or establish another PDU session.

[0222] Figure 19 This is a flowchart illustrating an exemplary process 1900 for performing service continuity according to various embodiments. The process 1900 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 8 The message exchange described, (iv) Figure 10 The process 1000, (v) combined Figure 11 The message exchange described, (vi) combined Figure 13 The described message exchange, (vii) Figure 15 The process 1500, and (vii) combined Figure 16 The message exchange is described. Process 1900 can be adapted for performing service continuity, in which the two WTRUs participating in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The process 1900 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 1900.

[0223] Furthermore, as those skilled in the art will recognize, process 1900 can be performed independently by two WTRUs. However, for the sake of convenience and simplicity, the term "WTRU" (singular form) will be used in the following description. Also for the sake of convenience and simplicity, in the following description, the term "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0224] Process 1900 is similar to Figure 18 The process 1800 differs as follows. Instead of execution sections (1804) and (1806), WTRU 102a can transmit first information indicating the status of the sidelink, a description of the traffic flow associated with the sidelink, and first information of the first and second identifiers associated with WTRU 102a and 102b to a network element of the core network, at least the description of the traffic flow and the first and second identifiers are transmitted from that network element to the application server (1903). The network element can be, for example, an SMF. The first identifier can be either the application layer identifier of WTRU 102a or the layer-2 identifier of WTRU 102a, and the second identifier can be either the application layer identifier of WTRU 102b or the layer-2 identifier of WTRU 102b. The WTRU 102a can (i) obtain a first identifier and a second identifier, as well as either a PCI or one or more QoS rules, from the link profile of the sidelink; (ii) generate first information indicating the state of the sidelink, a traffic flow description, and the first and second identifiers, based on the state of the sidelink, together with the obtained first and second identifiers, PCI, and / or QoS rules (e.g., a combination thereof); and (iv) transmit the first information as a notification report (e.g., a PC5 notification report) or transmit it in a notification report. According to the disclosure herein, the WTRU 102a can transmit the notification report in either a NAS message or an RRC message (e.g., in one or more IEs and / or their containers).

[0225] If provided to an application server, the application server can use the first and second identifiers and / or the sidelink status to generate a mapping between WTRU 102a and WTRU 102b, for example, between the first and second identifiers and the corresponding routable addresses of WTRU 102a and WTRU 102b. Traffic flow descriptions can be used by a second network element to establish a PDU session or modify an existing PDU session through which the WTRU can transmit outbound traffic and / or receive inbound traffic.

[0226] In various implementations, for example, as an option of process 1900, WTRU 102a may receive the address of WTRU 102b from an application server (not shown), and / or may use the address of WTRU 102 to transmit outbound traffic for example through a PDU session, a modified PDU session, and / or a newly established PDU session. In various implementations, for example, as an option of process 1900, WTRU 102a may receive information from a second network element of the core network to trigger a request to modify a PDU session or establish another PDU session (through which WTRU 102 may transmit outbound traffic and / or receive inbound traffic using the address of WTRU 102b).

[0227] Figure 20 This is a flowchart illustrating an exemplary process 2000 for performing service continuity according to various embodiments. The process 2000 and the appended disclosure herein can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 8 The message exchange described, (iv) Figure 10 The process 1000, (v) combined Figure 11 The message exchange described, (vi) combined Figure 13 The described message exchange, (vii) Figure 15 The process 1500, and (vii) combined Figure 16 The message exchange is described. Process 2000 can be adapted for performing service continuity, in which the two WTRUs participating in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The process 2000 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 2000.

[0228] Furthermore, as those skilled in the art will recognize, process 2000 can be performed independently by two WTRUs. However, for the sake of convenience and simplicity, the term "WTRU" (singular form) will be used in the following description. Also for the sake of convenience and simplicity, in the following description, the term "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0229] refer to Figure 20WTRU 102a can determine the status of the side link between WTRU 102a and WTRU 102b (2002), for example, as described in this paper. Figure 18 The process is as disclosed in process 1800. WTRU 102a can transmit information indicating the status of the sidelink, a description of the traffic flow associated with the sidelink, and a first and second identifier associated with WTRU 102a and 102b to a network element of the core network, at least the description of the traffic flow and the first and second identifiers are transmitted from that network element to an application server (2003). The network function can be, for example, SMF. The first identifier can be either the application layer identifier of WTRU 102a or the layer-2 identifier of WTRU 102a, and the second identifier can be either the application layer identifier of WTRU 102b or the layer-2 identifier of WTRU 102b. WTRU 102a can (i) obtain a first identifier and a second identifier, as well as either a PCI or one or more QoS rules, from the link profile of the sidelink; (ii) generate first information indicating the state of the sidelink, a traffic flow description, and the first and second identifiers based on the state of the sidelink, together with the obtained first and second identifiers, PCI, and / or QoS rules (e.g., a combination thereof); and (iv) transmit the first information as a notification report (e.g., a PC5 notification report) or transmit it in a notification report. According to the disclosure herein, WTRU 102a can transmit notification reports in either NAS messages or RRC messages (e.g., in one or more IEs and / or their containers). If provided to an application server, the application server can use the first and second identifiers and / or the state of the sidelink to generate a mapping between WTRU 102a and WTRU 102b, for example, between the first and second identifiers and their respective routable addresses for WTRU 102a and WTRU 102b.

[0230] WTRU 102a can receive information from the application server to trigger a WTRU request to establish or modify a PDU session (2005). This information may, for example, be an indication that WTRU 102b may be out of range and / or that the quality of the side link has deteriorated. The indication may be based on the value of the side link status (or the value of the side link status provided by WTRU 102b).

[0231] WTRU 102a can transmit second information (2007) indicating a request to establish or modify a PDU session. The second information can also indicate a traffic flow description associated with the sidelink. This traffic flow description can be used by a second network element to establish or modify an existing PDU session through which the WTRU can transmit outbound traffic and / or receive inbound traffic.

[0232] WTRU 102a can transmit outbound traffic of a traffic stream and its address (e.g., IP address) to an application server based on a PDU session (2008). The application server can use the address of WTRU 102a to update the mapping between WTRU 102a and 102b, and can use the address of WTRU 102a to forward traffic of a traffic stream received from WTRU 102b. WTRU 102a can receive inbound traffic of a traffic stream from the application server based on a PDU session (2010).

[0233] In various implementations, for example, as an option of process 2000, WTRU 102a may receive the address of WTRU 102b from an application server (not shown), and / or may use the address of WTRU 102 to transmit outbound traffic of traffic streams, for example, through a PDU session, a modified PDU session, and / or a newly established PDU session. In various implementations, for example, as an option of process 2000, WTRU 102a may receive information from a second network element of the core network to trigger a request to modify a PDU session or establish another PDU session (through which WTRU 102 may transmit outbound traffic and / or receive inbound traffic using the address of WTRU 102b).

[0234] Figure 21 This is a flowchart illustrating an exemplary process 2100 for performing service continuity according to various embodiments. The process 2100 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 8 The message exchange described, (iv) Figure 10 The process 1000, (v) combined Figure 11 The message exchange described, (vi) combined Figure 13 The described message exchange, (vii) Figure 15 The process 1500, and (vii) combined Figure 16 The message exchange is described. Process 2100 can be adapted for performing service continuity, in which the two WTRUs participating in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The process 2100 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 2100.

[0235] Furthermore, as those skilled in the art will recognize, process 2100 can be performed independently by two WTRUs. However, for the sake of convenience and simplicity, the term "WTRU" (singular form) will be used in the following description. Also for the sake of convenience and simplicity, in the following description, the term "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0236] Process 2100 is similar to Figure 20 The process 2000 differs from process 2100 in that process 2100 may include portions (2104) and (2105) instead of portions (2003) and (2005) of process 2000. (See reference) Figure 21 WTRU 102a can determine the status of the side link between WTRU 102a and WTRU 102b (2102), for example, as described in this paper. Figure 18 The process was disclosed in 1800.

[0237] WTRU 102a can transmit first information indicating the status of the sidelink and a first identifier and a second identifier associated with WTRU 102a and WTRU 102b to a first network element of the core network, from which at least the first identifier and the second identifier are transmitted to the application server (2104). The first network element can be, for example, an AMF or an SMF. The first identifier can be either an application layer identifier of WTRU 102a or a layer-2 identifier of WTRU 102a. The second identifier can be either an application layer identifier of WTRU 102b or a layer-2 identifier of WTRU 102b. WTRU 102a can (i) obtain the first identifier and the second identifier from the link profile of the sidelink, (ii) generate first information indicating the status of the sidelink and the first identifier and the second identifier (e.g., a combination thereof) based on the status of the sidelink and the first identifier and the second identifier obtained from the link profile, and (iii) transmit the first information as a notification report (e.g., a PC5 notification report) or transmit it in a notification report. According to the disclosure herein, WTRU 102a can transmit notification reports in either NAS messages or RRC messages (e.g., in one or more IEs and / or their containers). If provided to an application server, the application server can use the first and second identifiers and / or the sidelink status to generate a mapping between WTRU 102a and WTRU 102b, for example, between the first and second identifiers and their respective routable addresses for WTRU 102a and WTRU 102b.

[0238] WTRU 102a can receive information from a second network element in the core network to trigger a request to establish or modify a PDU session (2105). The second network element can be, for example, an SMF. Sections (2107), (2108), and (2110) can be executed, for example, as incorporated herein by reference. Figure 20 The process 2007 is disclosed in the connecting sections (2007), (2008) and (2010).

[0239] In various implementations, for example, as an option of process 2100, WTRU 102a may receive the address of WTRU 102b from an application server (not shown), and / or may use the address of WTRU 102 to transmit outbound traffic of traffic streams, for example, through a PDU session, a modified PDU session, and / or a newly established PDU session. In various implementations, for example, as an option of process 2100, WTRU 102a may receive information from a second network element of the core network to trigger a request to modify a PDU session or establish another PDU session (through which WTRU 102 may transmit outbound traffic and / or receive inbound traffic using the address of WTRU 102b).

[0240] Figure 22 This is a flowchart illustrating an exemplary process 2200 for performing service continuity according to various embodiments. The process 2200 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 7 The described message exchange, (iv) combined Figure 8 The described message exchange, (v) Figure 10 The process 1000, (vi) combined Figure 11 The message exchange described, (vii) combined Figure 12 The described message exchange, (viii) combined Figure 13 The message exchange described, (ix) Figure 15 The process 1500, (x) combined Figure 16 The described message exchange, and (xi) combination Figure 17 The message exchange described.

[0241] Process 2200 is suitable for performing service continuity, in which the two WTRUs involved in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2DThe process 2200 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 2200.

[0242] refer to Figure 22 The application server can receive (i) first information indicating a first state of the sidelink between WTRU 102a and WTRU 102b, a traffic flow description associated with the sidelink, and a first identifier and a second identifier associated with WTRU 102a and WTRU 102b; and (ii) second information indicating a second state of the sidelink, a traffic flow description, and a third identifier and a fourth identifier associated with WTRU 102a and WTRU 102b (2220). The first information may originate from WTRU 102a, and the second information may originate from WTRU 102b. The application server can receive the first and second information from one or more network elements of one or more core networks. The network element may be, for example, an AMF associated with WTRU 102a and WTRU 102b or an SMF associated with WTRU 102a and WTRU 102b. Alternatively, the network element may be, for example, a first AMF associated with WTRU 102a and a second AMF associated with WTRU 102b. The application server can transmit or receive the first and second information as a corresponding link notification report (e.g., a PC5 notification report). According to the disclosure herein, one or more network elements can transmit notification reports to the application server in either NAS messages or RRC messages (e.g., within one or more IEs and / or their containers).

[0243] The application server can use the first and second identifiers and / or the status of the sidelink to generate a mapping between WTRU102a and WTRU102b, for example, between the first and second identifiers and the corresponding routable addresses of WTRU102a and WTRU102b. Traffic flow descriptions can be sent to and used by network elements to establish PDU sessions or modify existing PDU sessions through which WTRU102a and WTRU102b can transmit outbound traffic and / or receive inbound traffic.

[0244] The application server can receive the first traffic flow associated with the sidelink from WTRU 102a and the address of WTRU 102a (2222). The application server can receive the second traffic flow associated with the sidelink from WTRU 102b and the address of WTRU 102b (2224). The application server can use the addresses of WTRU 102a and WTRU 102b to update the mapping between WTRU 102a and 102b. The application server can use the address of WTRU 102a to transmit the second traffic flow (2226). The application server can use the address of WTRU 102b to transmit the first traffic flow.

[0245] In various implementations, such as as an option of process 2200, the application server may receive first information from one or more network elements in response to a first event, based on a first subscription of a first network element. In various implementations, such as as an option of process 2200, the application server may receive second information from one or more network elements in response to a second event, based on a second subscription of a second network element. In various implementations, the first event may be when a first state indicates that communication with WTRU 102b is infeasible or no longer feasible, and the second event may be when a second state indicates that communication with WTRU 102a is infeasible or no longer feasible.

[0246] In various implementations, such as as an option of process 2200, the application server may (i) transmit the address of WTRU 102b to WTRU 102a, and / or (ii) transmit the address of WTRU 102a to WTRU 102b, for example, via a PDU session, a modified PDU session, and / or a newly established PDU session. In various implementations, such as as an option of process 2200, the application server may transmit third information to trigger WTRU 102a to modify its PDU session or establish another PDU session (through which WTRU 102a can transmit outbound traffic and / or receive inbound traffic using the address of WTRU 102b). In various implementations, such as as an option of process 2200, the application server may transmit fourth information to trigger WTRU 102b to modify its PDU session or establish another PDU session (through which WTRU 102b can transmit outbound traffic and / or receive inbound traffic using the address of WTRU 102a).

[0247] Figure 23This is a flowchart illustrating an exemplary process 2300 for performing service continuity according to various embodiments. The process 2300 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 7 The described message exchange, (iv) combined Figure 8 The described message exchange, (v) Figure 10 The process 1000, (vi) combined Figure 11 The message exchange described, (vii) combined Figure 12 The described message exchange, (viii) combined Figure 13 The message exchange described, (ix) Figure 15 The process 1500, (x) combined Figure 16 The described message exchange, and (xi) combination Figure 17 The message exchange described.

[0248] Process 2300 is suitable for performing service continuity, in which the two WTRUs involved in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The architecture of the communication system 100 (Figure 1) is used to describe process 2300. Different architectures can also be used to execute process 2300. Process 2300 is similar to... Figure 22 The process 2200 differs from the process 2321 in that the first and second information received by the application server lacks the first and second states of the link. The first and second states of the link may not be provided and can therefore be inferred from the reported events and / or notification reports.

[0249] Figure 24 This is a flowchart illustrating an exemplary process 2400 for performing service continuity according to various embodiments. The process 2400 herein and the appended disclosure can be considered as a summary of the disclosure accompanying any of the following: (i) Figure 4 Process 400, (ii) combined Figure 5 The described message exchange, (iii) combined Figure 7 The described message exchange, (iv) combined Figure 8 The described message exchange, (v) Figure 10 The process 1000, (vi) combined Figure 11 The message exchange described, (vii) combined Figure 12 The described message exchange, (viii) combined Figure 13The message exchange described, (ix) Figure 15 The process 1500, (x) combined Figure 16 The described message exchange, and (xi) combination Figure 17 The message exchange described.

[0250] Process 2400 is suitable for performing service continuity, in which the two WTRUs involved in sidelink communication are in any connection management state, with or without active PDU sessions. For ease of explanation and simplicity, refer to WTRU architecture 200 (Figure 2), PC5 unicast link ( Figure 2D The process 2400 is described using the architecture of the communication system 100 (Figure 1). Different architectures can also be used to execute the process 2400.

[0251] Furthermore, as those skilled in the art will recognize, process 2400 can be performed independently by two WTRUs. However, for the sake of convenience and simplicity, the term "WTRU" (singular form) will be used in the following description. Also for the sake of convenience and simplicity, in the following description, the term "WTRU 102a" refers to one of the two WTRUs, and the term "WTRU 102b" refers to the other WTRU.

[0252] refer to Figure 24 A network element (e.g., AMF or SMF) in the core network can receive a first message from WTRU 102b, which includes information indicating the status of the sidelink between WTRU 102a and WTRU 102b, a traffic flow description associated with the sidelink, and information about a first identifier and a second identifier associated with WTRU 102a and WTRU 102b (2430). The first message can be a NAS message or an RRC message. For example, the network element can transmit a second message to the application server, which includes second information indicating at least the first and second identifiers (2432). The second message can be an RRC message. The network element can, for example, transmit the second message to the application server to provide second information in response to an event, based on a subscription. In various embodiments, the event is when the status indicates that the sidelink is not feasible or no longer feasible for communication with the second WTRU.

[0253] The following are incorporated into this article by reference: [1] 3GPP TS 23.501 V16.2.0 [2] 3GPP TS 23.287 V16.0.0 [3] 3GPP TS 23.303 V15.1.0 [4] 3GPP TS 36.300 [5] 3GPP TS 24.334 [6] 3GPP TS 23.502 V16.2.0 [7] 3GPP TS 24.501 V16.2.0 in conclusion Although features and elements have been provided above in specific combinations, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. This disclosure is not limited to the specific embodiments described in this patent application, which are intended as examples of various aspects. Many modifications and variations are possible without departing from the spirit and scope of the invention, as will be apparent to those skilled in the art. Unless expressly stated otherwise, no element, action, or description used in this specification should be construed as essential or necessary to the invention. Based on the foregoing description, functionally equivalent methods and apparatus within the scope of this disclosure, other than those listed herein, will be apparent to those skilled in the art. Such modifications and variations are intended to fall within the scope of the appended claims. This disclosure is limited only to the terms of the appended claims and the full scope of equivalents of such claimed claims. It should be understood that this disclosure is not limited to any particular method or system.

[0254] For simplicity, the aforementioned embodiments have been discussed regarding the terminology and structure of infrared-capable devices (i.e., infrared transmitters and receivers). However, the embodiments discussed are not limited to these systems, but can be applied to other systems that use other forms of electromagnetic waves or non-electromagnetic waves (such as sound waves).

[0255] It should also be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the term “video” or the term “image” may mean any of a snapshot, a single image, and / or multiple images displayed on a time basis. As another example, when referred to herein, the term “user equipment” and its abbreviation “UE,” the term “remote” and / or the term “head-mounted display” or its abbreviation “HMD” may mean or include (i) a wireless transmitting and / or receiving unit (WTRU); (ii) any of several embodiments of a WTRU; (iii) a device having wireless and / or wired (e.g., tetherable) capabilities configured with some or all of the structure and functions of a WTRU; (iii) a device configured with fewer than all the structure and functions of a WTRU; or (iv) etc. The following is relative to the appendix Figure 1A-1DAs another example, the various disclosed embodiments herein are described above and below as utilizing head-mounted displays. Those skilled in the art will recognize that devices other than head-mounted displays can be used, and some or all of this disclosure and the various disclosed embodiments can be modified accordingly without excessive experimentation. Examples of such other devices may include drones or other devices configured to stream information to provide an adapted, realistic experience.

[0256] Furthermore, the methods described herein can be implemented in computer programs, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

[0257] Variations of the methods, apparatus, and systems provided above are possible without departing from the scope of the invention. Given the various applicable embodiments, it should be understood that the illustrated embodiments are merely examples and should not be construed as limiting the scope of the following claims. For example, embodiments provided herein include handheld devices that may include or be used with any suitable voltage source (such as a battery) that provides any suitable voltage.

[0258] Furthermore, the embodiments provided above specify processing platforms, computing systems, controllers, and other devices including processors. These devices may include at least one central processing unit (“CPU”) and memory. According to the practice of those skilled in the art of computer programming, references to symbolic representations of actions and operations or instructions can be executed by various CPUs and memories. Such actions and operations or instructions may be considered as being “executed,” “computer-executed,” or “CPU-executed.”

[0259] Those skilled in the art will recognize that the actions and symbols representing operations or instructions include the CPU's manipulation of electrical signals. The electrical system represents data bits, which can lead to the final transformation or reduction of electrical signals and the retention of data bits at memory locations in the memory system, thereby reconfiguring or otherwise altering the CPU's operation and performing other signal processing. The memory location holding the data bits is a physical location having specific electrical, magnetic, optical, or organic properties corresponding to or representing the data bits. It should be understood that the implementation is not limited to the platform or CPU described above, and other platforms and CPUs may also support the provided methods.

[0260] Data bits may also be stored on a computer-readable medium, including disks, optical disks, and any other CPU-readable volatile (e.g., random access memory (RAM)) or non-volatile (e.g., read-only memory (ROM)) mass storage system. The computer-readable medium may include cooperative or interconnected computer-readable media that are uniquely present on the processing system or distributed across multiple interconnected processing systems, which may be local or remote relative to the processing system. It should be understood that the implementation is not limited to the aforementioned memory, and other platforms and memories may also support the provided methods.

[0261] In exemplary embodiments, any of the operations, processes, etc., described herein may be implemented as computer-readable instructions stored on a computer-readable medium. These computer-readable instructions may be executed by a processor of a mobile unit, network element, and / or any other computing device.

[0262] There is little difference between the hardware and software implementations of various aspects of the system. The use of hardware or software typically (but not always, as the choice between hardware and software can become important in certain contexts) represents a design choice that weighs cost against efficiency. Various media (e.g., hardware, software, and / or firmware) may exist to implement the processes and / or systems and / or other technologies described herein, and the preferred media may vary depending on the context of the deployment of the processes and / or systems and / or other technologies. For example, if the implementer determines that speed and accuracy are most important, the implementer may choose a media that is primarily hardware and / or firmware. If flexibility is most important, the implementer may choose a primarily software implementation. Alternatively, the implementer may choose some combination of hardware, software, and / or firmware.

[0263] The above detailed description has illustrated various embodiments of the apparatus and / or processes using block diagrams, flowcharts, and / or examples. Where such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flowcharts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or virtually any combination thereof. In embodiments, certain portions of the subject matter described herein can be implemented via application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), and / or other integration formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein can be equivalently implemented in an integrated circuit, either wholly or partially, as one or more computer programs (e.g., one or more programs running on one or more computer systems), one or more programs running on one or more processors (e.g., one or more programs running on one or more microprocessors), firmware, or virtually any combination thereof, and that designing circuits and / or writing code for software and / or firmware according to this disclosure will be entirely within the skill of those skilled in the art. Furthermore, those skilled in the art will recognize that the mechanisms of the subject matter described herein can be distributed as program products in various forms, and the exemplary embodiments of the subject matter described herein apply regardless of the specific type of signal-bearing medium used to actually implement the distribution. Examples of signal-bearing media include, but are not limited to, the following: recordable media (such as floppy disks, hard disk drives, CDs, DVDs, digital magnetic tapes, computer memory, etc.); and transmission media (such as digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.)).

[0264] Those skilled in the art will recognize that it is common practice in the art to describe devices and / or processes in the manner set forth herein, and subsequently to use engineering practice to integrate such described devices and / or processes into data processing systems. That is, at least a portion of the devices and / or processes described herein can be integrated into a data processing system through a reasonable amount of experimentation. Those skilled in the art will recognize that a typical data processing system generally includes one or more of the following: a system unit enclosure; a video display device; memory, such as volatile and non-volatile memory; a processor, such as a microprocessor and a digital signal processor; computing entities, such as an operating system, drivers, a graphical user interface, and applications; one or more interactive devices, such as a touchpad or screen; and / or a control system, including feedback loops and control motors (e.g., feedback for sensing position and / or speed, control motors for moving and / or adjusting components and / or quantities). Typical data processing systems can be implemented using any suitable commercially available components, such as those commonly found in data computing / communication and / or network computing / communication systems.

[0265] The topics described herein sometimes illustrate different components contained within or connected to different other components. It should be understood that such depicted architectures are merely examples, and many other architectures can in fact achieve the same functionality. Conceptually, any arrangement of components achieving the same function is effectively “associated” to enable the desired functionality. Therefore, any two components combined herein to achieve a particular function can be considered “associated” with each other to enable the desired function, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered “operably connected” or “operably coupled” to each other to achieve the desired function, and any two components that can be suchly associated can also be considered “operably coupled” to each other to achieve the desired function. Specific examples of operably coupled components include, but are not limited to, components that can physically cooperate and / or physically interact and / or components that can wirelessly interact and / or logically interact and / or logically interact.

[0266] Regarding virtually any plural and / or singular terms used herein, those skilled in the art can appropriately convert them from plural to singular and / or from singular to plural depending on the context and / or application. For clarity, various singular / plural permutations may be explicitly listed herein.

[0267] Those skilled in the art will understand that, in general, the terminology used herein, particularly in the appended claims (e.g., the body of the appended claims), is typically intended as “open-ended” terms (e.g., the term “comprising” should be interpreted as “including but not limited to,” the term “having” should be interpreted as “having at least,” the term “including” should be interpreted as “including but not limited to,” etc.). Those skilled in the art will also understand that if it is intended to specify a particular number of introduced claim objects, such intention will be explicitly stated in the claims, and if no such claim objects are present, such intention will not exist. For example, the term “single” or similar language may be used where only one item is anticipated. To aid understanding, the appended claims and / or the description herein may contain the use of the introductory phrases “at least one” and “one or more” to introduce claim objects. However, the use of such phrases should not be construed as implying that any particular claim containing such introduced claim objects is limited to an embodiment containing only one such claim object by using the indefinite articles “a” or “an.” Even when the same claim includes the introductory phrase "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" and / or "an" should be interpreted as meaning "at least one" or "one or more"), this is also true. The same applies to the use of definite articles used to introduce the subject matter of a claim. Furthermore, even when a specific number of the introduced subject matter of a claim is explicitly stated, those skilled in the art will recognize that such a statement should be interpreted as meaning at least the stated number (e.g., a bare statement of "two subject matters" without other modifiers means at least two subject matters, or two or more subject matters). Additionally, in instances where conventions such as "at least one of A, B, and C" are used, generally speaking, such constructions mean that those skilled in the art will understand that convention (e.g., "a system having at least one of A, B, and C" will include, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). In instances where conventions such as "at least one of A, B, or C" are used, generally speaking, such a construction implies that a person skilled in the art will understand that the convention (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A alone, having B alone, having C alone, having both A and B, having both A and C, having both B and C, and / or having both A, B, and C, etc.). A person skilled in the art should also understand that, in fact, any separate words and / or phrases presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one term, any one of the terms, or both terms.For example, the phrase “A or B” will be understood to include the possibility of “A” or “B” or “A and B”. Additionally, as used herein, the term “any one of…” followed by a list of multiple items and / or multiple item categories is intended to include items alone or in combination with other items and / or other item categories, “any one of,” “any combination,” “any multiple,” and / or “any combination of multiples of.” Furthermore, as used herein, the term “group” is intended to include any number of items, including zero. Additionally, as used herein, the term “quantity” is intended to include any quantity, including zero.

[0268] Furthermore, where features or aspects of this disclosure are described in accordance with the Markush Group, those skilled in the art will recognize that this disclosure is also described in accordance with any individual member of the Markush Group or a subgroup of its members.

[0269] As those skilled in the art will understand, for any and all purposes (such as for providing a written description), all scopes disclosed herein also encompass any and all possible subscopes and combinations thereof. Any listed scope can be readily identified as sufficiently descriptive and such that the same scope can be divided into at least two equal halves, thirds, quarters, fifths, tenths, etc. As a non-limiting example, each scope discussed herein can be readily divided into a lower third, a middle third, and an upper third, etc. As those skilled in the art will also understand, all language such as “at most,” “at least,” “greater than,” “less than,” etc., includes the referenced number and refers to a scope that can subsequently be divided into subscopes as described above. Finally, as those skilled in the art will understand, a scope includes each individual number. Thus, for example, a group having 1 to 3 units means a group having 1, 2, or 3 units. Similarly, a group having 1 to 5 units means a group having 1, 2, 3, 4, or 5 units, etc.

[0270] Furthermore, unless otherwise stated, the claims should not be construed as being limited to the order or elements provided. Additionally, the use of the term "means for..." in any claim is intended to refer to the claim format of 25 USC §112, ¶ 6 or means plus function, and any claim without the term "means for..." is not intended to be so.

Claims

1. A method implemented in a first wireless transmit / receive unit (WTRU), the method comprising: Determine the status of side link communication with the second WTRU; The first information is transmitted to the first network element, the first information indicating a first identifier associated with the first WTRU and a second identifier associated with the second WTRU; Based on the state of the side link, trigger the establishment or modification of a Protocol Data Unit (PDU) session; and The second information associated with the sidelink communication is transmitted to the application server according to the PDU session.

2. The method of claim 1, wherein determining the state of the side link communication includes: Monitor the number of keep-alive transmissions received within a certain time period.

3. The method of claim 2, wherein when the number of keep-alive transmissions fails to meet the threshold, the state is a first value, and when the number of keep-alive transmissions meets the threshold, the state is a second value.

4. The method of claim 3, wherein the first value indicates that communication with the side link of the second WTRU is not feasible or is no longer feasible.

5. The method of claim 1, wherein the second information includes one or more data packets and the address of the first WTRU.

6. The method of claim 1, further comprising transmitting the first information in any one of a Non-Access Stratum (NAS) message, a Radio Resource Control (RRC) message, and a notification message.

7. The method according to claim 1, wherein triggering the establishment of the PDU session comprises: Send a PDU session establishment request, which includes one or more packet filter sets or quality of service (QoS) rules associated with the side link.

8. The method of claim 1, wherein the first network element includes an access and mobility management function (AMF).

9. The method of claim 1, further comprising receiving information from a second network element associated with the establishment or modification of the PDU session, wherein the second network element includes a session management function (SMF).

10. A wireless transmit / receive unit (WTRU), comprising: The circuit, comprising either a processor or a transceiver, is configured to: Determine the status of side link communication with the second WTRU; The first information is transmitted to the first network element, the first information indicating a first identifier associated with the first WTRU and a second identifier associated with the second WTRU; Based on the state of the side link, trigger the establishment or modification of a Protocol Data Unit (PDU) session; and The second information associated with the sidelink communication is transmitted to the application server according to the PDU session.

11. The WTRU of claim 10, wherein, in order to determine the state of the side link communication, the circuitry is configured to monitor the number of keep-alive transmissions received within a time period.

12. The WTRU of claim 11, wherein the state is a first value when the number of keep-alive transmissions fails to meet a threshold, and the state is a second value when the number of keep-alive transmissions meets the threshold.

13. The WTRU of claim 12, wherein the first value indicates that communication with the side link of the second WTRU is not feasible or is no longer feasible.

14. The WTRU of claim 10, wherein the second information includes one or more data packets and the address of the first WTRU.

15. The WTRU of claim 10, wherein the circuitry is configured to transmit the first information in any one of a Non-Access Stratum (NAS) message, a Radio Resource Control (RRC) message, and a notification message.

16. The WTRU of claim 10, wherein, in order to trigger the establishment of the PDU session, the circuit is configured to send a PDU session establishment request, the PDU session establishment request including one or more packet filter sets or quality of service (QoS) rules associated with the side link.

17. The WTRU of claim 10, wherein the first network element includes access and mobility management functions (AMF).

18. The WTRU of claim 10, wherein the circuitry is configured to receive information from a second network element associated with the establishment or modification of the PDU session, wherein the second network element includes a session management function (SMF).

19. A network element, comprising: The circuit, comprising either a processor or a transceiver, is configured to: Receive first information from a first wireless transmit / receive unit (WTRU), the first information indicating the status of sidelink communication between the first WTRU and the second WTRU, a first identifier associated with the first WTRU, and a second identifier associated with the second WTRU; It was determined that the side-link communication between the first WTRU and the second WTRU was not feasible; Trigger the establishment or modification of a Protocol Data Unit (PDU) session associated with the first WTRU; as well as The second information is transmitted to the application server, which associates the first identifier and the second identifier of each of the first WTRU and the second WTRU with the routable addresses corresponding to the first WTRU and the second WTRU.

Images