Wireless transmitting / receiving unit and method performed by same

Abstract

A wireless transmit / receive unit (WTRU) and a method performed by the same, the WTRU comprising: a processor configured to: determine that at least one trigger for performing path switching from a PC5 communication link to a Uu-based network communication link has occurred; transmitting a path switching request to a second WTRU via the PC5 communication link; receiving first information from the second WTRU, wherein the first information includes a path switching response for communicating via the Uu-based network communication link; performing a protocol data unit (PDU) session establishment with a network node or a PDU session modification process with the network node based on receiving the path switching response to establish a network-based PDU session; and transmitting second information to the second WTRU for communication via the Uu-based network communication link.

Description

[0001] This divisional application is a divisional application of the application with the filing date of January 27, 2023, application number 202380023078.2, and invention title "Path Switching between PC5 Interface and Uu Interface".

[0002] Cross - reference to related applications

[0003] This application claims the priority of U.S. Provisional Application No. 63 / 390,384 filed in the United States on July 19, 2022, U.S. Provisional Patent Application No. 63 / 321,977 filed in the United States on March 21, 2022, and U.S. Provisional Patent Application No. 63 / 303,733 filed in the United States on January 27, 2022, and the entire content of each of these applications is incorporated herein by reference. Background of the Invention

[0004] The 5G system has been enhanced to support a number of functions, including, for example, direct communication path switching between proximity services, the Uu interface (e.g., the communication interface between a WTRU and a gNB), and the PC5 interface (e.g., the communication interface between a first WTRU and a second WTRU). Summary of the Invention

[0005] A wireless transmit / receive unit (WTRU) may be configured to transmit on a first interface and determine to transmit on a second interface. The WTRU may receive configuration information. For example, the configuration information may include a path switching ability indication (e.g., path switching enabled / disabled), a path switching strategy, and / or an information sharing method indication. The path switching strategy may include one or more of the following: a network - triggered strategy, a preferred interface - driven strategy, a link - quality - driven strategy, and / or an application - driven strategy. Based on the configuration information, the WTRU may determine to perform a path switch. In response to determining to perform a path switch, the WTRU may retrieve certain information associated with a peer WTRU. For example, the retrieved information associated with the peer WTRU may enable the WTRU to perform a communication path switch. The WTRU may send a path - switch request to the peer WTRU based on the retrieved information associated with the peer WTRU. The WTRU may receive a response to the path - switch request sent to the peer WTRU. If the response indicates that the path - switch request has been accepted by the peer WTRU, the WTRU may perform a communication path switch from the first interface to the second interface.

[0006] The WTRU may be configured to perform a path switch, for example, between the Uu interface and the PC5 interface (or vice versa). For example, the WTRU may be configured with path - switching capabilities, configurations, strategies, etc.

[0007] In some specific implementations, the WTRU may be configured to perform a path switch based on one or more path switch policies and / or one or more application layer triggers. For example, path switch enabling may be negotiated between peer WTRUs, e.g., via the PC5 interface (e.g., using PC5 discovery, PC5 link establishment, and / or PC5 link modification techniques). The WTRU may receive a path switch trigger from, e.g., the application layer or the network. Additionally, or alternatively, the WTRU may determine to perform a path switch based on one or more path switch policies.

[0008] The WTRU may perform a path switch from the PC5 interface to the Uu interface (or vice versa). The WTRU may exchange (e.g., across peer WTRUs) IP addresses associated with an already established protocol data unit (PDU) session. Additionally, or alternatively, the PC5 link establishment procedure may be used to trigger a path switch. The WTRU may exchange PDU session related information with a peer WTRU via the PC5 interface (e.g., using a keep-alive mechanism). For example, the ProSe layer may retrieve information (e.g., IP address) related to the PDU session from the application layer.

[0009] WTRU path switching may be network-controlled and / or network-assisted. For example, a WTRU registered with the network may specify its path switching capabilities (e.g., enable / disable). Similarly, path switching capabilities may also be, or alternatively, provisioned for the WTRU (e.g., enable / disable). The network may trigger a path switch at the WTRU. WTRU path switching may be supported by certain network functions, such as the access and mobility management function (AMF), session management function (SMF), user plane function (UPF), direct discovery name management function (DDNMF), network data analytics function (NWDAF), etc. Additionally, or alternatively, a path switch assistance function (PSAF) may be provided.

[0010] The WTRU may be configured to perform a path switch from the PC5 interface to the Uu interface using on-demand PDU session establishment. For example, the WTRU may be configured to establish a PDU session during the path switch process.

[0011] The first WTRU may be configured to receive a message from a second WTRU via a PC5 communication link. For example, the message may indicate that the second WTRU is capable of performing a path switch from the PC5 communication link to a Uu-based network communication link. The WTRU may be configured to determine that at least one trigger for performing the path switch has occurred. The first WTRU may be configured to transmit a path switch request to the second WTRU. The first WTRU may be configured to receive a path switch response from the second WTRU. For example, the path switch response may include the IP address of the second WTRU for communicating via the Uu-based network communication link. The first WTRU may be configured to perform protocol data unit (PDU) session establishment with a network node based on, for example, receiving the path switch response to establish a network-based PDU session. The first WTRU may be configured to transmit a path switch confirmation to the second WTRU. For example, the path switch confirmation may include the IP address of the first WTRU for communicating via the Uu-based network communication link.

[0012] In an example, the first WTRU may be configured to receive a message from a network node indicating permission for the path switch and / or indicating one or more policies for implementing the path switch.

[0013] In an example, the one or more triggers may include the first WTRU being in a location area where path switching is permitted, the PC5 link quality being below a threshold, an indication from an application, and / or the Uu link quality being above a threshold.

[0014] In an example, the first WTRU may be configured to determine that the link quality of the PC5 communication link is below a threshold. In an example, the first WTRU may be configured to determine that the one or more triggers for performing the path switch have occurred based on determining that the link quality of the PC5 communication interface has dropped below the threshold.

[0015] In an example, the first WTRU may be configured to transmit a response to the second WTRU. For example, the response may indicate that the first WTRU is capable of performing a path switch from the PC5 communication link to the Uu-based network communication link.

[0016] In an example, the first WTRU may be configured to transmit a path switch request to the second WTRU based on determining that one or more triggers have occurred and / or that the second WTRU is capable of performing the path switch.

[0017] In an example, the path switch request may indicate whether the PC5 communication link should be retained after the path switch. In an example, the path switch request may be transmitted to the second WTRU via the PC5 communication link, where the path switch response may be received from the second WTRU via the PC5 communication link. In an example, the path switch confirmation may be transmitted to the second WTRU via the PC5 communication link.

[0018] In an example, a first WTRU may perform a method for path switching. Receive a message from a second WTRU via a PC5 direct communication link, the message indicating that the second WTRU is capable of performing a path switch from the PC5 direct communication link to a Uu-based network communication link. A method may include determining that one or more triggers for performing the path switch have occurred. The method may include transmitting a path switch request to the second WTRU. The method may include receiving a path switch response from the second WTRU. For example, the path switch response may include the IP address of the second WTRU for communicating via the Uu-based network communication link. The method may include performing a PDU session establishment with a network node based on, for example, receiving the path switch response to establish a network-based PDU session. The method may include transmitting a path switch confirmation to the second WTRU. For example, the path switch confirmation may include the IP address of the first WTRU for communicating via the Uu-based network communication link.

[0019] In an example, the method may include receiving a message from a network node indicating permission for the path switch and / or indicating one or more policies for implementing the path switch.

[0020] In an example, the one or more triggers may include the first WTRU being in a location where path switching is permitted, the PC5 link quality being below a threshold, an indication from an application, and / or the Uu link quality being above a threshold.

[0021] In an example, the method may include determining that the link quality of the PC5 communication link is below a threshold. In an example, it is determined that one or more triggers for performing the path switch have occurred based on determining that the link quality of the PC5 communication interface has dropped below the threshold.

[0022] In an example, the method may include transmitting a response to the second WTRU. For example, the response may indicate that the first WTRU is capable of performing a path switch from the PC5 communication link to a Uu-based network communication link.

[0023] In an example, the method may include transmitting a path switch request to the second WTRU based on determining that one or more triggers have occurred and / or that the second WTRU is capable of performing the path switch.

[0024] In an example, the path switch request indicates whether the PC5 communication link should be retained after the path switch.

[0025] In an example, the method may include transmitting a message to an application. For example, the message may indicate the IP address of the first WTRU for communicating via the Uu-based network communication link network.

[0026] In an example, the method may include transmitting the path switch request to the second WTRU via the PC5 communication link. In an example, the method may include receiving the path switch response from the second WTRU via the PC5 communication link. In an example, the method may include transmitting a path switch confirmation to the second WTRU via the PC5 communication link.

[0027] In an example, a first WTRU may be configured to perform a policy and parameter provisioning process. In an example, the first WTRU may be configured to perform a PC5 unicast connection establishment with a second WTRU based on the policy and / or parameter provisioning process. For example, the PC5 unicast connection may include a set of one or more PC5 quality of service (QoS) flows, and the set of one or more PC5 quality of service (QoS) flows may be associated with an allowed QoS list for PC5 QoS flows for ProSe services. In an example, the first WTRU may be configured to determine to perform a path switch with the second WTRU. In an example, the first WTRU may be configured to transmit a message to a network node. For example, the message may include a protocol data unit (PDU) session establishment request to establish a network-based PDU session based on, for example, performing the PC5 unicast connection establishment. In an example, the first WTRU may be configured to receive a PDU session establishment response from the network.

[0028] In an example, a WTRU may be configured to determine whether a QoS flow can be switched between PC5 and Uu based on, for example, verification of compatible user plane (UP) security levels between PC5 and Uu.

[0029] In an example, the first WTRU may be configured to use the established PC5 unicast link to exchange traffic for an application. In an example, the first WTRU may be configured to cancel the path switch with the second WTRU based on one or more of the following. The first WTRU may be configured to cancel the path switch with the second WTRU based on determining that the establishment of the PDU session with the second WTRU fails. In an example, the first WTRU may be configured to cancel the path switch with the second WTRU in a case where the PDU session does not include a QoS flow whose QoS level is compatible with the QoS level of the PC5 QoS flow for the application. In an example, the first WTRU may be configured to cancel the path switch with the second WTRU in a case where the security level activated for the PDU session is not compatible with the required security level of the selected PC5 QoS flow. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1A is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented;

[0031] Figure 1B is an illustration of an example wireless transmit / receive unit (WTRU) that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0032] Figure 1C is an illustration of an example radio access network (RAN) and an example core network (CN) that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0033] Figure 1D is an illustration of another example RAN and another example CN that may be used within the Figure 1A illustrated communication system in accordance with an embodiment;

[0034] Figure 2 illustrates an example path switch procedure from a direct PC5 interface to a direct Uu interface implemented by a WTRU;

[0035] Figure 3 illustrates an example associated with a path switch where the peer WTRU has an established PC5 unicast link and on-demand PDU session establishment;

[0036] Figure 4 illustrates an example procedure associated with a network-triggered path switch from a direct PC5 interface to a direct Uu interface;

[0037] Figure 5 illustrates an example path switch procedure associated with a switch from a direct Uu interface to a direct PC5 interface;

[0038] Figure 6 Illustrates another example path switching process for switching from the direct Uu interface to the direct PC5 interface;

[0039] Figure 7 Illustrates another example process for network-triggered path switching from the direct Uu interface to the direct PC5 interface;

[0040] Figure 8 Illustrates an example path switching process from the PC5 interface to the Uu interface with path switching parameter allocation; and

[0041] Figure 9 Illustrates an example path switching process from the Uu interface to the PC5 interface with parameter allocation (e.g., path switching parameter allocation). Detailed implementation mode

[0042] Figure 1A Is a diagram illustrating an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multi-access system that provides content such as voice, data, video, messages, broadcasts, etc. to multiple wireless users. The communication system 100 may enable 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 unique word DFT spread OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multicarrier (FBMC), etc.

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

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

[0045] 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 a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. The cell may provide coverage of wireless services to a specific geographical area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in the desired spatial direction.

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

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

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

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

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

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

[0052] Figure 1AThe base station 114b therein may be, for example, a wireless router, a home Node B, a home evolved Node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premise, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, etc. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.11) to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a pico base station or a femto base station. As Figure 1A shown, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not need to access the Internet 110 via the CN 106 / 115.

[0053] The RAN 104 / 113 may communicate with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. The CN 106 / 115 may provide call control, billing services, location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not shown in Figure 1A it, it should be understood that the RAN 104 / 113 and / or the CN 106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113 that may utilize NR radio technology, the CN 106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

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

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

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

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

[0061] The processor 118 of the 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) display 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, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any such type of suitable memory. The non-removable memory 130 may include random access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. In other embodiments, the processor 118 may access information from a memory that is not physically located on the WTRU 102 (such as a server or a home computer (not shown)) and store data in that memory.

[0062] The processor 118 may receive power from a 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.), a solar cell, a fuel cell, etc.

[0063] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information via an air interface 116 from a base station (e.g., base stations 114a, 114b) 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 embodiments, the WTRU 102 may obtain location information by any suitable location determination method.

[0064] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or videos), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, 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. The peripheral device 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; geographical location sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0065] The 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 139, which is used to reduce and / or substantially eliminate self-interference through signal processing via hardware (e.g., chokes) or via a processor (e.g., a separate processor (not shown) or via the processor 118). In one embodiment, the WRTU 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)).

[0066] Figure 1C Is a system diagram illustrating the RAN 104 and CN 106 according to an embodiment. As noted above, the RAN 104 may communicate with the WTRU 102a, 102b, 102c via the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the CN 106.

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

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

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

[0070] The MME 162 may be connected via the S1 interface to each of the evolved Node Bs 162a, 162b, 162c in the RAN 104 and may act as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during the initial attachment of the WTRUs 102a, 102b, 102c, etc. The MME 162 may provide control plane functions for interworking between the RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

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

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

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

[0074] Although the WTRU is described as a wireless terminal in Figures 1A to 1D it is contemplated that in some representative embodiments, such a terminal can (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0075] In a representative embodiment, the other network 112 can be a WLAN.

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

[0077] When operating in 802.11ac infrastructure operation mode or a similar operation mode, the AP can send beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., 20 MHz bandwidth) or a width dynamically set via signaling. The primary channel can be the operation channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, for example, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented in an 802.11 system. For CSMA / CA, the STA (e.g., 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, the particular STA can back off. Only one STA (e.g., only one station) can transmit at any given time in a given BSS.

[0078] High Throughput (HT) STAs can communicate using 40 MHz wide channels, e.g., by combining the primary 20 MHz channel with an adjacent or non - adjacent 20 MHz channel to form a 40 MHz wide channel.

[0079] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. The 40 MHz channel and / or 80 MHz channel can be formed by combining consecutive 20 MHz channels. The 160 MHz channel can be formed by combining eight consecutive 20 MHz channels, or by combining two non - consecutive 80 MHz channels (which can be referred to as the 80 + 80 configuration). For the 80 + 80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. The Inverse Fast Fourier Transform (IFFT) processing and time - domain processing can be performed separately on each stream. These streams can be mapped to two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operations for the 80 + 80 configuration described above can be reversed, and the combined data can be delivered to the Media Access Control (MAC).

[0080] 802.11af and 802.11ah support operation modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, the channel operation bandwidth and carriers are reduced in 802.11af and 802.11ah. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication, such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, such as limited capabilities, including supporting (e.g., only supporting) certain bandwidths and / or limited bandwidths. MTC devices can include a battery with a battery life higher than a threshold (e.g., to maintain a very long battery life).

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

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

[0083] Figure 1D FIG. is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As noted above, RAN 113 can employ NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN 113 can also communicate with CN 115.

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

[0085] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with a scalable parameter set. For example, the OFDM symbol interval and / or the OFDM subcarrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using various or scalable-length subframes or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or having an absolute time length that continuously varies).

[0086] gNBs 180a, 180b, 180c can be configured to communicate with WTRUs 102a, 102b, 102c in a stand-alone configuration and / or a non-stand-alone configuration. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c without accessing other RANs (e.g., such as evolved Node Bs 160a, 160b, 160c). In the stand-alone configuration, WTRUs 102a, 102b, 102c can use one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the stand-alone configuration, WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In the non-stand-alone configuration, WTRUs 102a, 102b, 102c can communicate / connect with gNBs 180a, 180b, 180c while also communicating / connecting with another RAN (such as evolved Node Bs 160a, 160b, 160c). For example, WTRUs 102a, 102b, 102c can implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more evolved Node Bs 160a, 160b, 160c substantially simultaneously. In the non-stand-alone configuration, evolved Node Bs 160a, 160b, 160c can act as the mobility anchor for WTRUs 102a, 102b, 102c, and gNBs 180a, 180b, 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, 102c.

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

[0088] Figure 1DThe illustrated CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and possibly data networks (DN) 185a, 185b. Although each of the foregoing elements is depicted as part of 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.

[0089] The AMF 182a, 182b may be connected via an N2 interface to one or more of the gNBs 180a, 180b, 180c in the RAN 113 and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of a particular SMF 183a, 183b, management of the registration area, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRUs 102a, 102b, 102c based on the type of service utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services that rely on ultra-reliable low-latency (URLLC) access, services that rely on enhanced mobile broadband (eMBB) access, services for machine type communication (MTC) access, etc. The AMF 162 may provide control plane functions for handover between the RAN 113 and other RANs (not shown) that employ other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

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

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

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

[0093] In view of Figures 1A to 1D and Figures 1A to 1D In view of the corresponding descriptions of, one or more or all of the functions described herein for one or more of the following may be performed by one or more emulation devices (not shown): WTRUs 102a-d, base stations 114a-b, evolved Node Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMFs 182a-ab, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any one or more other devices described herein. The emulation device(s) can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation device(s) can be used to test other devices and / or simulate network and / or WTRU functions.

[0094] Emulation devices can be designed to implement one or more tests of other devices in a laboratory environment and / or in an operator network environment. For example, one or more emulation devices can perform one or more (e.g., or all) functions while being fully or partially implemented and / or deployed as part of a wired communication network and / or a wireless communication network to test other devices within the communication network. One or more emulation devices can perform one or more (e.g., or all) functions while being temporarily implemented / deployed as part of a wired communication network and / or a wireless communication network. An emulation device can be directly coupled to another device for testing. An emulation device can use over-the-air wireless communication to perform tests.

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

[0096] The phrase first WTRU may be used interchangeably herein with the acronym WTRU1. The phrase second WTRU may be used interchangeably herein with the acronym WTRU2.

[0097] Techniques for supporting path switching between a direct Uu interface and a direct PC5 interface (e.g., in a non-relayed scenario) are described herein. For example, techniques for determining whether and / or how to support path switching between a direct NR Uu interface and a direct NR PC5 interface (e.g., in a non-relayed scenario) may be described herein.

[0098] To enable a WTRU to implement path switching functionality, techniques for enabling the WTRU to determine whether and / or when traffic should be switched from Uu to PC5 (e.g., or vice versa) are disclosed herein. For example, a WTRU can be configured to determine whether a peer WTRU of the WTRU supports path switching. When used herein, the term "peer WTRU" can be used to refer to other WTRUs that communicate with a given WTRU. A WTRU can be configured to determine whether a peer WTRU of the WTRU agrees to perform a path switching. For example, a WTRU can determine when to trigger a path switching based on one or more policies, criteria observed regarding the peer WTRU, information about an ongoing communication session, and / or radio link conditions, etc. A WTRU can be configured to determine whether a peer WTRU is ready to implement a path switching before performing the path switching.

[0099] If the WTRU and / or a peer of the WTRU supports and / or consents to use path switching functionality, the WTRU may be configured to notify and / or otherwise indicate (e.g., via signaling) to its peer that a path switch will be performed. If the WTRU and / or a peer of the WTRU supports and / or consents to use path switching functionality, the WTRU may be configured to synchronize such path switches between the relevant peer WTRUs. The WTRU may be configured to implement procedures associated with an IP address change when performing a path switch. The WTRU may be configured to utilize information about a pre-switch communication session in order to establish one or more parameters for communicating over the post-switch interface (e.g., QoS information, PDU session information, priority information, etc.).

[0100] The techniques described herein may address how and / or when a WTRU determines to trigger and / or perform a path switch from a Uu interface to a PC5 interface. The techniques described herein may address how a WTRU determines that a peer WTRU is ready / able to perform a path switch. The techniques described herein may address how a WTRU notifies a peer WTRU that a path switch will be performed. The techniques described herein may address how to configure a WTRU to handle a change in IP address associated with different communication paths. The techniques described herein may address how a WTRU determines that a peer WTRU supports and / or consents to perform a path switch. The techniques described herein may relate to how to provide a WTRU with information for identifying a peer of the WTRU (e.g., during a PC5 discovery procedure). The techniques described herein may relate to how a WTRU establishes a PDU session (e.g., a QoS flow having a QoS level corresponding to the QoS level of the PC5 interface).

[0101] The WTRU may be configured (e.g., via configuration information) to determine whether to trigger a path switch from an NR Uu interface to an NR PC5 interface (e.g., and / or vice versa). The WTRU may be configured to determine that one or more peer WTRUs are ready to switch communication paths. The WTRU may be configured to notify or otherwise indicate to its peer WTRUs that the WTRU has determined to perform a path switch (e.g., based on a path switching policy, a received application trigger, and / or a received network trigger). The WTRU may be configured to handle a change in IP address associated with different paths. The WTRU may be configured to determine that a peer of the WTRU supports and / or consents to use path switching.

[0102] This document may describe one or more techniques that enable a WTRU to perform a path switch from a PC5 interface (e.g., an NR PC5 interface) to a Uu interface (e.g., an NR Uu interface) and vice versa. Although example techniques may be described for 5G / NR communication systems, these techniques may be applicable to other types of communication systems. Also, although certain techniques are described herein with respect to ProSe layer techniques, it is understood that other application-specific layer techniques (e.g., V2X) may be used or alternatively used.

[0103] The WTRU may be configured (e.g., via configuration information) with path switch capabilities and path switch policies. For example, these path switch policies may indicate whether path switching of the WTRU is enabled / disabled, a preferred interface (e.g., PC5 or Uu), certain thresholds and / or parameters for enabling path switching (e.g., radio configurations and / or network configurations indicative of whether path switching may be performed).

[0104] The WTRU may indicate to the network and / or its peer WTRUs its ability to support path switching. For example, the WTRU may indicate its ability to support path switching during PC5 discovery, PC5 link establishment, and / or initial network registration.

[0105] The WTRU may agree to use path switching, for example, during PC5 link establishment. The use and policies of path switching (e.g., including interface preference and / or link quality thresholds) may also be negotiated during this process.

[0106] The WTRU may be configured (e.g., via configuration information) to perform a path switch based on a path switch policy. For example, the WTRU may receive a trigger (e.g., via signaling) that is configured to cause the WTRU to perform a path switch. The WTRU may also or alternatively be configured to determine to perform a path switch based on a policy. For example, the policy may be a preferred interface-driven policy, a link quality-driven policy, and / or an application-driven policy. The policy may also or alternatively be network-controlled.

[0107] For example, if the policy is preferred interface-driven, the preferred interface for a given application may be configured as a Uu interface and / or a PC5 interface.

[0108] If the policy is link quality-driven, one or more of the following may be applied. The WTRU may be configured with a link quality threshold. The WTRU may be configured to monitor link quality. The WTRU may be configured to trigger a communication path switch when the threshold is met (e.g., the link quality of an interface is below the threshold).

[0109] If the policy is application-driven, one or more of the following may be applied. The WTRU may receive an application layer trigger. For example, the trigger may be configured to cause the ProSe layer to switch from the Uu interface to a direct PC5 connection (e.g., or vice versa). The WTRU may receive an application layer trigger from a ProSe application server. For example, the application layer trigger received from the ProSe application server may include an explicit trigger and / or additional or updated service parameters (e.g., QoS requirements, service requirements, etc.). The application layer may trigger a path switch based on this information, which may be received, for example, via the PC1 interface.

[0110] If the path switch policy is network-controlled, one or more of the following may be applied. The network may trigger the WTRU to switch from the Uu interface to a direct PC5 connection (e.g., or vice versa). For example, the network may trigger the WTRU to switch from Uu communication to a direct PC5 connection (e.g., or vice versa) based on certain criteria such as network congestion, expected link quality degradation, and / or predicted QoS.

[0111] The WTRU may initiate a path switch, for example, by using a new PC5 path switch procedure and / or during PC5 link establishment.

[0112] In some scenarios, the WTRU may know certain information related to the Uu communication path of a peer WTRU, which may be used to trigger a path switch. For example, the WTRU may know that: the peer of the WTRU has an established PDU session; the peer of the WTRU does not have an established PDU session; the peer of the WTRU does not have an established PDU session and / or has the ability to establish a PDU session; and / or the peer of the WTRU does not have an established PDU session but is unable to establish a PDU session. Peer WTRUs exchange information related to the Uu path with each other (e.g., PDU session established, PDU session released, able to establish PDU session, unable to establish PDU session, etc.). Information related to the Uu path may be saved locally (e.g., at the WTRU). The WTRU may consider the information related to the Uu path to determine whether to trigger a path switch.

[0113] The PC5 keep-alive procedure and / or an additional PC5 request / response message procedure may also or alternatively be used to exchange and / or query information related to the Uu path across peer WTRUs. For example, the keep-alive procedure may be triggered whenever additional or updated information is to be exchanged across peer WTRUs. For example, if a PDU session meets certain criteria for a given application (e.g., an application running on the PC5 interface), the WTRU may notify the peer WTRU of the existence of the PDU session.

[0114] The WTRU may also or alternatively be configured to notify its peer WTRU when the WTRU is able (e.g., or not) to establish a PDU session (e.g., taking into account mobility events, allowed slices, etc.). For example, the WTRU may be located in an area where its service is restricted and / or otherwise not allowed (e.g., due to a single network slice selection assistance information (S-NSSAI) not being supported in the WTRU's current routing area, radio access technology (RAT) restrictions, service area restrictions, and / or service interruptions (e.g., due to a disaster situation)). For example, if the WTRU is located in an area where its service is restricted and / or otherwise unavailable, the WTRU may be configured to send a PDU session status indication to the peer WTRU. For example, the PDU session status may notify the peer WTRU of a given WTRU whether the given WTRU is able and / or allowed to establish a PDU session (e.g., based on its service access context / status). This information exchange across peer WTRUs may be agreed upon during PC5 link establishment and / or saved locally at each of the peer WTRUs. Saving the information locally at each of the peer WTRUs may enable path switching decisions to occur more quickly. For example, if the path switching policy indicates that PC5 is the preferred interface and / or the peer WTRUs are not traveling in the same direction, the PC5 link quality may degrade. However, if certain information is shared across peer WTRUs (e.g., a given peer WTRU has established a PDU session), the communication path may be switched to the Uu interface before the link on the PC5 interface is lost.

[0115] If a peer WTRU knows that a peer WTRU has established a PDU session and / or is able to establish a PDU session, a path switching process may be triggered (e.g., immediately) between the peer WTRUs. As another example, if the path switching policy indicates that Uu is the preferred interface and / or a given WTRU is currently outside of network coverage (e.g., a WTRU currently outside of network coverage may communicate using the PC5 interface) and / or if the WTRU knows that its peer WTRU has established a PDU session and / or is able to establish a PDU session, then, for example, the WTRU may immediately trigger a path switch to the Uu interface after the WTRU enters network coverage and / or establishes a PDU session.

[0116] Once the WTRU establishes a PDU session, the IP address associated with that session (which is known at the NAS layer) may also be provided to the application layer. The application layer may pass the IP address associated with the PDU session to the ProSe layer. For example, the ProSe layer may use the IP address associated with the PDU session during a path switching process.

[0117] The WTRU may be configured to exchange information across layers to enable path switching. For example, the ProSe layer may query the application layer to obtain information related to an existing PDU session (e.g., IP address, link quality, etc.). The ProSe layer may query the application layer during a path switching procedure to obtain the IP address associated with the PDU session. As described herein, information related to link quality may also be queried and / or considered to enable path switching.

[0118] As described herein, the WTRU may be configured to switch from the Uu interface to the PC5 interface. In an example, peer WTRUs may be configured to discover each other and / or establish a PC5 unicast link via the PC5 interface. For example, the peer WTRUs may be configured to establish a PC5 unicast link before initiating a path switching. As described herein, the peer WTRUs may also be configured to agree to use certain policies related to path switching, for example, during the PC5 link establishment procedure.

[0119] In an example, the peer WTRUs may have already established a PC5 unicast link. The PC5 link modification and / or path switching procedure may be used to negotiate path switching usage and / or policies (e.g., in a scenario where path switching is not yet enabled on the PC5 link), as described herein.

[0120] The WTRU may be configured to switch from the PC5 to the Uu interface. In an example, the peer WTRUs may be configured to communicate via the PC5 link. The peer WTRUs may also have agreed to enable path switching functionality and / or use certain mechanisms to exchange information. For example, the peer WTRUs may have agreed to use a keep-alive mechanism to exchange information about the existence of a PDU session.

[0121] The WTRU may be configured to determine (e.g., based on a preferred interface or link quality) to switch from the PC5 interface to the Uu interface via a PDU session.

[0122] If the WTRU determines to switch from the PC5 interface to the Uu interface, for example, based on a preferred interface, one or more of the following may be applied. The WTRU may establish and / or may be able to establish a PDU session that meets the requirements (e.g., QoS) of a given application. The WTRU may also be configured with a preferred interface for the given application. For example, the preferred interface for the application may be set to the Uu. The WTRU may determine the existence of the PDU session and / or may establish (e.g., using a keep-alive mechanism) on its peer WTRU.

[0123] If a WTRU determines to switch from a PC5 interface to a Uu interface, for example, based on link quality, one or more of the following may be applied. The WTRU may be configured with a link quality threshold, and / or the WTRU may determine that the PC5 link quality is degrading (e.g., the PC5 link quality is below the threshold). The WTRU may determine that a PDU session has been established and / or may be established on the WTRU and the WTRU's peer. As described herein, the WTRU may determine that a PDU session has been established on the WTRU's peer based on a keep-alive mechanism.

[0124] Additionally, or alternatively, the WTRU may be configured to receive a trigger (e.g., from a given application and / or network) that causes the WTRU to switch from the PC5 interface to the Uu interface via a PDU session.

[0125] If the WTRU receives an application trigger that causes the WTRU to switch from the PC5 interface to the Uu interface, one or more of the following may be applied. The WTRU may receive an application layer trigger that is configured to cause the ProSe layer to switch from a direct PC5 connection to a Uu connection. For example, the application layer trigger may be received based on new service parameters. The application layer trigger may also or alternatively include an explicit trigger received from an application server.

[0126] As described herein, the WTRU may receive a network trigger that causes the WTRU to switch from the PC5 interface to the Uu interface. For example, the WTRU may receive a network trigger that causes the WTRU to switch from the PC5 interface to the Uu interface based on the WTRU's mobility settings, handover duration, and / or network conditions.

[0127] As described herein, the WTRU may be configured to determine whether the WTRU's peer has an established PDU session for an application suitable for running on the PC5 link. The WTRU may use, for example, a keep-alive mechanism to determine via information exchange whether the peer has established a PDU session. For example, when a PDU session is established (e.g., or released), a given WTRU is configured to notify the WTRU's peer by triggering a keep-alive process and / or including the PDU session state. Other PC5 messages / processes (e.g., a new information sharing process and / or a link modification process) may also or alternatively be used to notify the peer WTRU of PDU session establishment and / or release.

[0128] Figure 2 An example path switch procedure 200 implemented by the WTRU is illustrated. As Figure 2As shown, network 203 (e.g., 5G Core Network (CN)) may transmit a message to WTRU1 202 at 206. The message 206 may indicate the provisioning of WTRU1 202. For example, path switching capabilities (e.g., enable / disable), path switching policies (e.g., preferred interfaces, link quality thresholds, as described herein), and / or information sharing methods (e.g., keep-alive procedures) may be provisioned (e.g., via configuration information) for WTRU1 202. Referring Figure 2 to the example illustrated, WTRU1 202 may move out of network coverage, for example, after provisioning.

[0129] At 208, a PC5 link (e.g., a PC5 unicast link) may be established between WTRU1 202 and WTRU2 204. Certain path switching parameters (e.g., enable / disable path switching, policies, information sharing methods) may be specified during the establishment of the PC5 link. For example, the path switching parameters may be specified (e.g., in cases where the path switching parameters need to be protected) using a Direct Communication Request (DCR) message and / or a Direct Security Mode (DSM) command message, and / or via a DSM complete message and a Direct Communication Accept (DCA) message. The path switching capabilities of the PC5 link may be an attribute of the PC5 link. If a new QoS flow and / or another service is added to the link, WTRU1 202 and / or WTRU2 204 may determine to establish a new PC5 link, and / or reuse the existing PC5 link, for example, in cases where the new service meets the path switching requirements (e.g., the additional service supports path switching). In an example, there may be certain services for which path switching is not preferred. If a PC5 link with path switching attributes has been established and / or another service for which path switching is not preferred is added, the WTRU (e.g., WTRU1 202) may be configured to establish a new PC5 link with the same WTRU (e.g., WTRU2 204).

[0130] Peer WTRUs may be configured to share information associated with an existing PDU session with each other. As Figure 2 shown, WTRU2 204 may be configured to notify WTRU1 202 of its existing PDU session, for example, by using a PC5 keep-alive mechanism. For example, WTRU2 204 may be configured to send a PC5 keep-alive request message 210. The PC5 keep-alive request message may include the PDU session state of WTRU2 204 (e.g., available). Similarly, both WTRU1 202 and / or WTRU2 204 may ensure that their respective peer WTRUs update the latest PDU session state using the keep-alive mechanism.

[0131] In an example, for instance, based on a keep-alive request message received from WTRU2 204, WTRU1 202 can be configured to track (e.g., maintain) the PDU session presence / status of WTRU2 204. At 212, WTRU1 202 can locally save information.

[0132] In response to a keep-alive request message 210 received from WTRU2 204, WTRU1 202 can send a keep-alive response message 214. The keep-alive response message 214 can include the PDU session state of WTRU1. For example, as Figure 2 shown, WTRU1 202 can send a keep-alive response message 214 to WTRU2 204 to indicate that WTRU1 202 does not have any established PDU sessions.

[0133] At 216, WTRU1 202 can establish a PDU session with the network 203, e.g., after WTRU1 202 enters network coverage. WTRU1 202 can retrieve information related to WTRU2 204 from the memory of WTRU1 202, where the information indicates the state of the PDU session (e.g., via a PC5 communication link). Although not shown in Figure 2 it, WTRU1 202 can use, for example, the keep-alive mechanism described herein to update the presence of its PDU session to WTRU2 204. Additionally or alternatively, WTRU1 202 can initiate a path switch procedure.

[0134] At 218, WTRU1 202 can, for example, retrieve certain information related to WTRU2 204 (e.g., the presence of a PDU session) from local storage, and / or determine whether WTRU2 204 has an existing PDU session available for a path switch. WTRU1 202 can detect and / or receive a trigger that is configured to cause WTRU1 202 to initiate a path switch from the PC5 interface to the Uu interface. For example, a trigger configured to cause WTRU1 202 to initiate a path switch from the PC5 interface to the Uu interface can include one or more of the following: PDU session establishment at WTRU1 202 and / or WTRU2 204 (e.g., when the preferred path policy indicates the Uu interface); a low link quality measurement value on the PC5 link (e.g., the PC5 link quality is below a configured threshold); a network trigger; and / or an application layer trigger.

[0135] If the WTRU1 202 determines that the WTRU2 204 has an available PDU session, the WTRU1 202 may be configured to trigger a path switch, for example, by sending a PC5 path switch request message 220 to the WTRU2 204. The PC5 path switch request message may include the IP address used on the PDU session of the WTRU1 and / or the path switch direction (e.g., PC5 to Uu). As described herein, the WTRU1 202 may retrieve the IP address associated with its PDU session from the application layer. The PC5 path switch request message 220 sent by the WTRU1 202 (e.g., the IP address of the WTRU1 on the PDU session, PC5 to Uu) may also specify, for example, whether the PC5 link should be retained (e.g., as a backup link) after a successful path switch.

[0136] The WTRU2 204 may be configured to track certain information related to the PDU session of the WTRU1 202, including, for example, the IP address of the WTRU1 on the PDU session and / or the existence of the WTRU1 PDU session. If the WTRU2 204 is able to perform a path switch, the WTRU2 204 may respond to the WTRU1 202 by sending a PC5 path switch response message 222. For example, as Figure 2 shown, the PC5 path switch response message 222 of the WTRU2 may include the PDU session IP address of the WTRU2 (e.g., the IP address on the PDU session). The WTRU2 204 may determine that the WTRU1 is ready to switch traffic via the PDU session. For example, the WTRU2 204 may wait to receive traffic from the WTRU1 202 via the PDU session (e.g., to ensure that the PC5 path switch response message has been received by the WTRU1 202), and / or wait for the duration of a retransmission timer value associated with the path switch request message. However, if the WTRU2 204 determines not to switch paths (e.g., because the PDU session has just been released), the WTRU2 204 may send a PC5 path switch rejection message to the WTRU1 202. The PC5 path switch rejection message may include the reason for the WTRU2 204 to reject the path (e.g., indicating that the PDU session has been released). For example, if the WTRU1 202 receives a PC5 path switch rejection message from the WTRU2 204, the WTRU1 202 may abort the path switch process.

[0137] After a successful path switch, at 224a and / or 224b (e.g., the path switch response message is sent by the WTRU2 204 and received by the WTRU1 202, as Figure 2As shown in FIG. 200, the WTRU1 202 and / or the WTRU2 204 may notify their applications and / or their peer WTRUs of the successful path switch and / or the IP addresses associated with the PDU session of their peer WTRUs. After a successful path switch, the WTRU1 202 and / or the WTRU2 204 may also be configured to send traffic via the PDU session and / or stop transmitting traffic via the PC5 link.

[0138] For example, after a successful path switch to the Uu interfaces 224a, 224b, the PC5 unicast link may be retained. If it is intended to retain the PC5 unicast link, an indication thereof (e.g., a "retain link" indication) may be included in the PC5 path switch request message 220 / PC5 path switch response message 222 (e.g., such that the two WTRUs agree to retain the PC5 link). For example, in the case where a path switch from the Uu interface to the PC5 interface is required, PC5 unicast link keep-alive may allow the WTRU to skip the PC5 discovery and / or PC5 link establishment process.

[0139] The WTRU may be configured to establish an on-demand PDU session. As described herein, the WTRU may determine whether its peer WTRU is able to establish a PDU session suitable for a given application (e.g., an application running on the PC5 link) (e.g., is permitted to establish a PDU session). For example, the WTRU may determine whether its peer WTRU is able to establish a PDU session (e.g., is permitted to establish a PDU session) by exchanging information with the peer WTRU (e.g., using a keep-alive mechanism). The WTRU may be configured to notify (e.g., immediately notify) its peer WTRU whether the WTRU is able to establish a PDU session, e.g., via the keep-alive mechanism. The WTRU may also or alternatively be configured to notify its peer WTRU of any change in the WTRU's ability to establish a PDU session. In addition, although the keep-alive mechanism may be used to describe the exchange of information regarding their respective PDU session states between peer WTRUs via the PC5 link, other messages / processes (e.g., PC5 messages / processes) may also or alternatively be used (e.g., an additional information sharing process and / or a link modification process).

[0140] Figure 3 An example process 300 associated with path switching is illustrated, where the peer WTRUs have an established PC5 unicast link. At 306, the network (e.g., the 5G core network 303) may allocate the first WTRU 302 (e.g., the WTRU1 302). At 308, for example, the first WTRU1 302 may negotiate path switching functionality and / or policies with the second WTRU (e.g., the WTRU2 304), or vice versa. As Figure 3As shown, peer WTRUs (e.g., WTRU1 302 and / or WTRU2 304) may be configured to exchange their respective PDU session states via the PC5 interface and / or trigger a path switch from the PC5 interface to the Uu interface when requested and / or when needed and / or when possible. The WTRU may determine to establish an on-demand PDU session, e.g., when initiating a path switch procedure. For example, the WTRU may initiate a path switch under the following conditions: the Uu interface is the preferred interface and / or both WTRUs are capable of establishing a PDU session; and / or the PC5 interface is the preferred interface and / or the link quality of the PC5 link degrades; and so on.

[0141] As Figure 3 shown, the network (e.g., 5G CN) 303 may allocate WTRU1 302 at 306. For example, the WTRU may be allocated (e.g., via configuration information, using one or more parameters) path switch capabilities (e.g., enable / disable), path switch policies (e.g., preferred interface, link quality threshold, as described herein), and / or information sharing methods (e.g., keep-alive procedure). Referring Figure 3 to the example illustrated, WTRU1 302 may move out of network coverage after allocation.

[0142] A PC5 link may be established between WTRU1 302 and WTRU2 304. Certain path switch parameters (e.g., enable / disable path switch, policy, information sharing method) may be specified during the establishment of the PC5 link. For example, the path switch parameters may be specified using a direct communication request (DCR) message and / or a direct security mode (DSM) command message, and / or via a DSM complete message and / or a direct communication acceptance (DCA) message (e.g., in cases where the path switch parameters need to be protected). The path switch capability of the PC5 link may be an attribute of the PC5 link. If a new QoS flow and / or a new service is added to the link, WTRU1 302 and / or WTRU2 304 may determine to establish a new PC5 link and / or reuse the existing PC5 link, e.g., in cases where the new service meets the path switch requirements (e.g., the new service supports path switching). There may be certain services that do not prefer path switching. For example, if a PC5 link with path switching attributes has been established and a service that does not prefer path switching is added, the WTRU (e.g., WTRU1 302) may establish a new PC5 link with the same WTRU (e.g., WTRU2 304).

[0143] Peer WTRUs may be configured to share with each other information associated with their existing PDU sessions. As Figure 3As shown, the WTRU 2 304 may be configured to use the PC5 keep-alive mechanism to notify the WTRU 1 302 of the ability of the WTRU 2 304 to establish a PDU session. For example, the WTRU 2 304 may send a message to the WTRU 1 302 at 310. The message may indicate a PC5 keep-alive request message 310 including the PDU session status of the WTRU 2 (e.g., the WTRU 2 304 is capable of establishing a PDU session and / or the WTRU 2 304 is capable of performing a path switch from a PC5 communication link to a Uu-based network communication link). The message may be transmitted via the PC5 communication link. The WTRU 1 302 and / or the WTRU 2 304 may update their latest PDU session status to their peer WTRUs. For example, the PDU session status of a WTRU may indicate that the WTRU is capable of establishing a PDU session; no PDU session has been established for the WTRU currently; the WTRU is not capable of establishing a PDU session; and / or a PDU session has been established; and so on.

[0144] For example, if the WTRU 2 304 is not capable of establishing a PDU session, in addition to the PDU session status of the WTRU, the WTRU 2 304 may also notify the WTRU 1 302 of the reason(s) / cause(s) why the WTRU 2 304 is not capable of establishing a PDU session. At 311, for example, the WTRU 1 302 may save information (e.g., locally). The saved information may include the PDU session status of the WTRU 2 as sent from the WTRU 2 304 to the WTRU 1 302 (e.g., via the keep-alive request 310). The WTRU 1 302 may track the ability of the peer WTRU to establish a PDU session. In an example, the WTRU 1 302 and the WTRU 2 304 may exchange their ability to establish a PDU session (e.g., mobility restrictions).

[0145] As Figure 3 shown, the WTRU 1 302 may be configured to maintain and / or track the PDU session status of the WTRU 2 (e.g., the WTRU 2 may establish a PDU session). The WTRU 1 302 may respond to the keep-alive request message received from the WTRU 2 304, for example, by sending a keep-alive response message 312. The keep-alive response message 312 may include the PDU session status of the WTRU 1 (e.g., the WTRU 1 302 is not capable of establishing a PDU session). For example, if the WTRU 1 302 is not capable of establishing a PDU session, the keep-alive response message 312 may also or alternatively include the reason(s) / cause(s) why the WTRU 1 302 is not capable of establishing a PDU session. At 313, for example, the WTRU 1 302 may obtain (e.g., locally obtain) WTRU 2 304 information and / or trigger a path switch. The WTRU 1 302 may consider the ability of the WTRU 2 304 to establish a PDU session (e.g., before triggering a path switch).

[0146] The WTRU1 302 may be able to establish a PDU session (e.g., the WTRU1 302 moves into network coverage and / or an area that allows the WTRU1 302 to establish a PDU session). The WTRU1 302 may determine whether conditions for triggering a path switch are met (e.g., low link quality measured on the PC5 link, the path switch policy of the WTRU1 indicates that the Uu interface is the preferred interface, a trigger has been received from the application layer, etc.). The WTRU1 302 may retrieve certain information related to the WTRU2 304 (e.g., the PDU session state of the WTRU2) and / or determine whether the WTRU2 304 is able to switch communication from the PC5 interface to the Uu interface.

[0147] Although not shown in Figure 3 the WTRU1 302 may update the updated PDU session state of the WTRU1 302 to the WTRU2 304, for example, by sending a keep-alive request message 310. For example, the keep-alive request message 310 sent by the WTRU1 302 may notify the WTRU2 304 that the WTRU1 302 is ready for a path switch and / or confirm that the locally stored PDU session state is accurate. In turn, the WTRU2 304 may send a keep-alive response message 312 to the WTRU1 302, which may indicate that the WTRU2 304 is ready for a path switch and / or confirm that the locally stored PDU session state is accurate.

[0148] If the WTRU1 302 determines that the WTRU2 304 is able to accept a path switch (e.g., via a keep-alive mechanism as described herein), the WTRU1 302 may initiate a path switch by sending a PC5 path switch request message 314 to the WTRU2 304. Additionally or alternatively, the WTRU1 302 may transmit a path switch request message 314 to the WTRU2 304 based on determining that one or more triggers have occurred and / or the WTRU2 304 is able to perform a path switch. For example, the PC5 path switch request message 314 may include an indication of the path switch direction (e.g., PC5 to Uu). The path switch request message 314 may be transmitted to the WTRU2 304 via the PC5 communication link. The path switch request message 314 may include triggering a path switch through the PC5 interface. The WTRU1 302 may also or alternatively specify whether the PC5 link should be retained (e.g., as a backup link) after a successful path switch to the Uu interface. For example, if the WTRU1 302 already has an established PDU session available for path switching, the PC5 path switch request message 314 may include the IP address associated with the established PDU session of the WTRU1 302.

[0149] As Figure 3 shown, if a PDU session is not established, the WTRU 2304 can establish a PDU session (e.g., at 315). The WTRU 2304 can also or alternatively modify an existing PDU session (e.g., adjust QoS).

[0150] The WTRU 2304 can respond to a PC5 path switch request message 314 from the WTRU 1. For example, the WTRU 2304 can respond to the path switch request message 314 by sending a PC5 path switch response message 316. The PC5 path switch response message 316 can include an IP address associated with the PDU session of the WTRU 2. The WTRU 1302 can receive the path switch response from the WTRU 2304 via the PC5 communication link. However, if the WTRU 2304 is no longer able to establish a PDU session and / or perform a path switch and / or if the PDU session establishment of the WTRU 2 fails, the WTRU 2304 can send a PC5 path switch rejection message. If a PC5 path switch rejection message is sent, the path switch process (e.g., the initiated path switch process) can be aborted. After the path switch process is aborted, a retry timer can be started. After the retry timer expires, the path switch process can be initiated (e.g., re-initiated). For example, after the retry timer expires and / or if both WTRUs have established a PDU session and / or are able to establish a PDU session and / or meet the conditions for initiating a path switch from the PC5 interface to the Uu interface (e.g., policy-driven path switch, link quality-driven path switch, and / or application layer-driven path switch), the path switch process can be re-initiated.

[0151] As Figure 3 shown, the WTRU 1302 can maintain or track the IP address of the WTRU 2 on a given PDU session. At 317, the WTRU 1302 can also establish a PDU session and / or modify an existing PDU session (e.g., establish a network-based PDU session with a network node based on the received path switch response).

[0152] The WTRU1 302 may send a PC5 path switch confirmation message 318 to the WTRU2 304. For example, the PC5 path switch confirmation message 318 sent by the WTRU1 302 may include an IP address associated with the PDU session of the WTRU1 302. The WTRU2 304 may receive the path switch confirmation message 318 that may be transmitted from the WTRU1 302 via the PC5 communication link. For example, after sending the PC5 path switch confirmation message 318, the WTRU1 302 may switch traffic to the established PDU session. The WTRU2 304 may maintain and / or track the IP address associated with the PDU session of the WTRU1. In an example (e.g., alternatively used for sending the PC5 path switch confirmation), the WTRU1 302 may send a PC5 path switch abort message to abort the path switch process, e.g., in the case of a failed PDU session establishment. In an example, the WTRU1 302 may not send the PC5 path switch confirmation message 318 if the WTRU1 302 already has an established PDU session and / or if the WTRU1 302 provided an IP address associated with the PDU session in the PC5 path switch request message.

[0153] The WTRU1 302 and / or the WTRU2 304 may notify their respective applications of a successful path switch. Additionally or alternatively, the WTRU1 302 and / or the WTRU2 304 may notify their respective applications of the IP address of the PDU session of their peer WTRU. The WTRU1 302 and / or the WTRU2 304 may switch traffic from the PC5 link to the established PDU session.

[0154] As described herein, the network 303 may control the PC5-to-Uu handover and / or assist with the PC5-to-Uu handover. One or more of the following may be applied. In an example, the WTRUs may report their location while in motion and / or periodically and / or aperiodically (e.g., via a tracking area (TA) update in the case of Uu, and / or by reporting to a direct discovery name management function (DDNMF) in the case of PC5). If the WTRUs are too far apart and / or outside the line of sight (e.g., outside the typical PC5 range), the PC5 connection of the WTRUs may not work properly.

[0155] In an example, although the WTRUs may be located close enough within the same cell, PC5 functionality may be limited, for example, by terrain, vertical movement (e.g., within a high-rise building), etc. (e.g., due to blockage). In an example, the WTRU may switch from the Uu interface to PC5 for a fixed duration, and / or after that fixed duration, the network may trigger the WTRU to switch back to the Uu interface. In an example, certain network functions, such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), User Plane Function (UPF), DDNMF, and / or certain application functions triggered based on applications, may report to an analytics function (e.g., NWDAF) in the network and / or subscribe to an analytics function (e.g., NWDAF) in the network. For example, the analytics function in the network may perform analysis and / or provide relevant information to appropriate network functions to trigger a path switch.

[0156] In some scenarios, peer WTRUs may have a direct PC5 connection with each other while these WTRUs have an active PDU session with the network (e.g., within a single Public Land Mobile Network (PLMN), or with different PLMNs in the case where the two WTRUs do not belong to the same PLMN). In an example, the network may trigger the WTRU to perform a path switch and / or provide the relevant WTRUs with information related to their PDU sessions with each other, for example, when valid conditions are met (e.g., as described above).

[0157] A Path Switching Assistance Function (PSAF) may provide network path assistance. The PSAF may be co-located with existing network functions (e.g., DDNMF, SMF, and / or ProSe AS), as shown herein.

[0158] Figure 4 An example process 400 associated with network-triggered path switching is illustrated. One or more of the following may be applied. During initial registration 406a, 406b, WTRU1 402 and / or WTRU2 404 may provide their respective path switching capabilities to the network, as Figure 4 shown. For example, WTRU1 402 and / or WTRU2 404 may indicate their ability to switch from the PC5 interface to the Uu interface (e.g., or vice versa) based on network trigger. Also as shown, WTRU1 402 and / or WTRU2 404 may have an ongoing PC5 unicast link (e.g., at 408). This PC5 unicast link may be based on a policy and / or parameter provisioning process. This PC5 unicast connection may include a set of one or more PC5 Quality of Service (QoS) flows, and this set of one or more PC5 Quality of Service (QoS) flows may be associated with an allowed QoS list for PC5 QoS flows for ProSe services.

[0159] One or more (e.g., each) WTRUs (e.g., WTRU1 402 and / or WTRU2 404) may be configured to send request messages 410a, 410b to their respective PSAFs (e.g., DDNMF, SMF). For example, request message 410a and / or request message 410b may include a request for network path switching assistance. The request messages (e.g., 410a and / or 410b) may also provide information associated with the requesting WTRU, such as the corresponding WTRU ID (e.g., ProSe ID, layer 2 ID, IP address, etc.), serving PLMN ID, and / or PC5 link information and / or Uu link information. For example, the PC5 link information and / or Uu link information may indicate whether the PC5 interface and / or Uu link is currently active or inactive, an indication of the services and / or QoS flow indicators (QFIs) being used for a given interface, and / or the IP address associated with a given interface, etc.

[0160] Based on receiving the requests from WTRU1 and WTRU2, the DDNMF (e.g., DDNMF1 405a and / or DDNMF2 405b) may perform one or more of the following: verify authorization for path switching assistance based on the WTRU's subscription information and local policies (e.g., having a policy control function (PCF) for service QoS requirements); query the network (e.g., via a network exposure function (NEF)) to obtain information about the WTRU's Uu link information (e.g., session parameters, QoS information about the link, WTRU location, etc.); subscribe to mobility event notifications of the WTRU from the AMF (e.g., based on location reports from the RAN), which may be used for path switching decisions; contact DDNMFs of other PLMNs for path switching assistance establishment and activation; and / or subscribe to data analytics from the NWDAF (e.g., NWDAF1 407a and / or NWDAF2 407b) and PCF (e.g., for policy enforcement, which may be used for path switching decisions). After receiving a request from the DDNMF / ProSe AS, the NEF may query different network nodes, such as the AMF, PCF, SMF, possibly together with the NWDAF (e.g., NWDAF1 407a and / or NWDAF2 407b), to obtain the corresponding information and / or transmit the corresponding information to the DDNMF (e.g., DDNMF1 405a and / or DDNMF2 405b) and / or ProSe AS.

[0161] As Figure 4As shown, WTRU1 402 and / or WTRU2 404 may each receive response message 412a and / or response message 412b. For example, the response message (e.g., 412a and / or 412b) may confirm that network path switching assistance has been enabled / accepted. After activating / enabling network path switching assistance, one or more of the following may be applied: WTRU1 402 and / or WTRU2 404 may be configured to periodically report their location and QoS parameters to DDNMF1 405a and / or DDNMF2 405b respectively (e.g., at 414a and / or at 414b); and / or DDNMF1 405a and DDNMF2 405b may exchange the location and QoS information of peer WTRUs (e.g., at 416).

[0162] As Figure 4 shown, at 418, the DDNMF / ProSe AS may forward the information received from the WTRU (e.g., the location and QoS information of the WTRU) to the corresponding NWDAF. For example, the NWDAF (e.g., NWDAF1 407a and / or NWDAF2 407b) may analyze the information received from the WTRU and then may use the information to trigger path switching. Additionally or alternatively, the AMF may send WTRU mobility information to the NWDAF (e.g., NWDAF1 407a and / or NWDAF2 407b), including for example the tracking area, the timestamp when the location was reported, etc. The DDNMF (e.g., DDNMF1 405a and / or DDNMF2 405b) and / or the AMF may also or alternatively forward the WTRU mobility information to an application server in the data network, which may be used for example for application-level triggering of path switching.

[0163] In some scenarios, WTRU1 402 and / or WTRU2 404 may have established corresponding PDU sessions after communication with the DDNMF (e.g., at 420a and / or at 420b), as Figure 4 shown. However, if the WTRU determines that the existing PDU session is no longer suitable after path switching (e.g., not suitable for the desired service), then WTRU1 402 and / or WTRU2 404 may establish and / or modify the PDU session with their respective networks. Additionally, in some examples, the UP connection of the PDU session may not have been activated.

[0164] At 422, the WTRU may determine (e.g., mutually determine) to switch the communication path from the PC5 interface to the Uu interface based on information exchanged between the DDNMF / ProSe AS. Then, two DDNMFs (e.g., DDNMF1 405a and / or DDNMF2 405b) may convey a path switch request (e.g., indicating a switch from the PC5 interface to the Uu interface) to each WTRU in the respective WTRUs. The path switch request may include, for example, information to assist the WTRU in establishing a PC5 connection. For example, the DDNMF (e.g., DDNMF1 405a and / or DDNMF2 405b) may include a discovery code / filter, QoS information, peer WTRU layer 2 ID, security policy, etc. in the path switch request 422. The path switch trigger message 422 may also or alternatively include information to notify the WTRU whether the path switch is a temporary path switch or a permanent path switch. For example, if the path switch is a temporary path switch, the path switch trigger message may include a possible valid time period / window. The WTRU may start a receive timer, and when the receive timer expires, the WTRU may be configured to implicitly switch the path back to PC5 communication.

[0165] Additionally or alternatively, as shown at 424, at 426a and / or 426b, the NWDAF (e.g., NWDAF1 407a and / or NWDAF2 407b) may indicate (e.g., via the path switch request) to the NF (e.g., NF1 403a and / or NF2 403b) whether any of the conditions for a path switch from the PC5 interface to the Uu interface have been met. For example, the path switch request may include a WTRU ID, a location area (e.g., based on a tracking area), and / or a maximum time window before a Uu connection must be established for a seamless handover (e.g., for a UP connection). For example, if the Uu connection is not established before the maximum time window expires, the path switch may not be performed.

[0166] NF1 403a may be configured to trigger a path switch, for example, by sending a path switch request 428a to WTRU1 402. Similarly, NF2 403b may be configured to trigger a path switch, for example, by sending a path switch request to WTRU2 404 428b. For example, each path switch request (e.g., 428a and / or 428b) may include a timer value before which the path switch must be completed. In one example, the trigger may also or alternatively be sent to one of the peer WTRUs (e.g., WTRU1 402 and / or WTRU2 404 may already be ready / synchronized to perform the path switch).

[0167] As Figure 4As shown, WTRU 1 402 and / or WTRU 2 404 may be configured to send an indication 430 of a path switch to each other. The indication 430 sent by WTRU 1 402 and / or WTRU 2 404 may include the IP addresses of their respective PDU sessions. For example, if both WTRUs receive an indication / trigger from the network to perform a path switch, WTRU 1 402 and / or WTRU 2 404 may not send an indication 430 of the path switch to each other. Additionally, WTRU 1 402 and / or WTRU 2 404 may be configured to notify their respective applications of the path switch. WTRU 1 402 and / or WTRU 2 404 may also be configured to notify the IP addresses of their respective peer WTRUs, and / or switch traffic from the PC5 link to the Uu interface.

[0168] As described herein, a WTRU may be configured to perform a communication path switch from the Uu interface to the PC5 interface. One or more of the following may be applied. Peer WTRUs may be configured to communicate via the Uu interface. These peer WTRUs may determine (e.g., may jointly determine / agree) to enable a path switch at the application layer, which may pass this information (e.g., path switch enabled) along with certain information to the ProSe layer to identify the peer WTRUs via the PC5 interface (e.g., for future use, as described herein). For example, the information for identifying the peer WTRUs via the PC5 interface may include user information of WTRU 1 associated with the application and / or user information of WTRU 2. The application may also or alternatively send (e.g., forward) the IP address associated with the PDU session (e.g., the IP address to be switched to the PC5 interface) to the ProSe layer.

[0169] A WTRU may be configured to determine whether / when to switch the communication path from the Uu interface to the PC5 interface. For example, the WTRU may be configured to determine whether / when to perform a path switch to the PC5 interface based on a preferred interface (e.g., an application preferred interface) or link quality. The WTRU may also or alternatively be configured to determine whether / when to perform a path switch to the PC5 interface based on a trigger received from the network.

[0170] The WTRU may be configured to determine whether / when to perform a path switch to the PC5 interface based on a preferred interface. One or more of the following may apply. The WTRU may be configured (e.g., provisioned) to communicate with a peer WTRU via the Uu interface. However, in some scenarios, the preferred interface associated with the application currently running on the WTRU may specify that the PC5 interface is the preferred interface. The WTRU may be configured to trigger a path switch, for example, during the establishment of the PC5 link with the peer WTRU or at / after the establishment of the PC5 link (e.g., if the link quality of the PC5 interface meets a link quality threshold, such as the threshold provisioned for the application).

[0171] The WTRU may be configured to determine whether / when to perform a path switch to the PC5 interface based on link quality. One or more of the following may apply. In an example, the preferred interface associated with the application currently running on the WTRU may specify that the Uu interface is the preferred interface. However, the WTRU may move out of network coverage (e.g., due to WTRU mobility), and / or the link quality on the Uu interface may drop below a link quality threshold. The WTRU may be configured to determine to perform a path switch to the PC5 interface, for example, in response to the Uu link quality dropping below the link quality threshold.

[0172] The WTRU may be configured to determine whether / when to perform a path switch to the PC5 interface based on a trigger received from the network. One or more of the following may apply. In some scenarios, the network may trigger the WTRU to switch from the Uu interface to a direct PC5 connection. For example, the network may trigger the WTRU to perform a path switch to the PC5 interface based on certain criteria, such as network congestion, an expected drop in link quality, and / or predicted QoS measurements.

[0173] Figure 5 An example path switch process 500 from a direct Uu interface to a direct PC5 interface is illustrated. As Figure 5 shown, the WTRU (e.g., WTRU1 502 and / or WTRU2 504) may agree to enable path switch functionality and / or exchange information related to the PDU session (e.g., active / inactive, established / released, etc.). For example, the WTRU (e.g., WTRU1 502 and / or WTRU2 504) may be configured to use a keep-alive mechanism to exchange information about the PDU session during the PC5 discovery process and / or the PC5 link establishment process. The most recent status information about the PDU session may enable the path switch capability from the PC5 interface to the Uu interface (e.g., if the peer WTRUs are not close to each other for a period of time).

[0174] In an example, the PC5 link establishment procedure can be used to trigger a path switch from the Uu interface to the PC5 interface. Additionally, or alternatively, a PC5 path switch procedure can be performed after the PC5 link establishment procedure.

[0175] As Figure 5 shown, the WTRU1 502 and / or the WTRU2 504 can each establish a PDU session with the network (e.g., at 506a and / or at 506b). The WTRU1 502 and the WTRU2 504 can also each allocate (e.g., at 508a and / or at 508b) one or more of the following: path switch capabilities (e.g., path switch enable / disable), path switch policies, and / or path switch information sharing methods (e.g., keep-alive mechanisms). At 510, the WTRU1 502 can obtain information related to connectivity on the Uu interface (e.g., obtained from the application layer). For example, the ProSe layer (e.g., the ProSe layer of the WTRU1 502) can retrieve / obtain the corresponding IP address used on the corresponding PDU session, for example, from the application layer. At 510, the ProSe layer can also retrieve / obtain the corresponding application user information (e.g., the ProSe layer can retrieve / obtain the corresponding application user information of the WTRU1 and / or the WTRU2).

[0176] The ProSe layer (e.g., the ProSe layer of the WTRU1 502) can trigger a PC5 discovery procedure (e.g., at 512). For example, the PC5 discovery procedure can be used to discover the WTRU2 504 via the PC5 interface, for example, using the application user information of the WTRU2 504. A trigger for establishing a PC5 unicast link and / or a path switch can be received from the application layer. In some scenarios, the ProSe layer may not trigger the PC5 discovery procedure 512, and / or the discovery of the WTRU2 504 can be performed during the PC5 link establishment procedure (e.g., Figure 5 in 514).

[0177] As Figure 5 shown, the WTRU1 502 can be configured to trigger the establishment of a PC5 unicast link by sending a DCR message 514 to the WTRU2 504. For example, the DCR message 514 can include a path switch request and / or the PDU session IP address of the WTRU1. The WTRU2 504 can be configured to trigger a security establishment procedure, for example, by sending a DSM command message 516 to the WTRU1 502. The DSM command message 516 can include a path switch acceptance and / or the PDU session IP address of the WTRU2.

[0178] The WTRU1 502 may be configured to complete the security establishment process, for example, by sending a DSM completion message 518 to the WTRU2 504. For example, the DSM completion message 518 may include a path switch request indication and / or the PDU session IP address of the WTRU1. Additionally, or alternatively, the path switch request and / or the PDU session IP address of the WTRU1 may be included in the DCR message 514.

[0179] The WTRU2 504 may be configured to complete the PC5 link establishment, for example, by sending a DCA message 520. The WTRU2 may send the DCA message 520 to the WTRU1 502. For example, the DCA message 520 may include a path switch acceptance indication and the PDU session IP address of the WTRU2. Additionally, or alternatively, the path switch request and / or the PDU session IP address of the WTRU2 may be included in the DSM command message 518. For example, if the WTRU2 504 determines not to switch traffic from the PDU session to the PC5 interface, the WTRU2 504 may be configured to send a DCA message 520 including a path switch rejection indication to the WTRU1 502. The WTRU1 502 and / or the WTRU2 504 may be configured to indicate a path switch to the application layer, and / or application traffic may be switched to the PC5 interface.

[0180] Figure 6 An example path switch process 600 illustrating a switch from a direct Uu interface to a direct PC5 interface is provided. Referring Figure 6 to the example provided, the WTRU may determine (e.g., jointly determine / agree) to enable path switch functionality after the PC5 link establishment. For example, the WTRU may determine to use a PC5 link modification process and / or a path switch process to enable the path switch functionality. The WTRU may be configured to trigger a path switch from the Uu interface to the PC5 interface, for example, before or after a path switch negotiation between peer WTRUs (e.g., after a link modification process).

[0181] The WTRU1 602 and / or the WTRU2 604 may each establish a PDU session with the network. The WTRU1 602 and / or the WTRU2 604 may each allocate (e.g., at 606a and / or 606b) one or more of the following: path switch capabilities (e.g., path switch enable / disable), path switch policies, and / or path switch information sharing methods (e.g., keep-alive processes). For example, the WTRU1 602 and / or the WTRU2 604 may be configured with a path switch policy indicating that the PC5 is the preferred interface.

[0182] The ProSe layer may retrieve / receive information related to connectivity on the Uu interface and / or PDU session (e.g., the IP address used on the corresponding PDU session, the application user information of WTRU1, and / or the application user information of WTRU2) (e.g., at 608) from the application layer. The WTRU may be configured to consider the retrieval / reception of this information by the ProSe layer as a trigger for performing a path switch (e.g., network-triggered or application-triggered).

[0183] WTRU1 602 may be configured to determine whether a PC5 link exists between the user information of WTRU1 and the user information of WTRU2. If WTRU1 602 determines that the PC5 link does not exist, WTRU1 602 may be configured to trigger a PC5 discovery process via the PC5 interface (e.g., at 610) and / or discover WTRU2 604. In an example, if WTRU1 602 determines that the PC5 link does not exist, WTRU1 602 may not trigger the PC5 discovery process 610 via the PC5 interface and / or discover WTRU2 604. Instead, WTRU1 602 may perform a PC5 link establishment 612 with WTRU2 604. If WTRU1 602 determines that the PC5 link does exist, WTRU1 602 may send a link modification request message 614 and / or send a path switch request 618.

[0184] At 612, a PC5 link may be established between WTRU1 602 and WTRU2 604, and / or the ProSe layer may notify the corresponding application layer of the establishment of the PC5 link between WTRU1 602 and WTRU2 604. WTRU1 602 and / or WTRU2 604 may be configured to negotiate the enabling of path switch functionality, for example, by using a link modification process. For example, if the path switch functionality is not enabled at the time of PC5 link establishment, WTRU1 602 may be configured to send a link modification request 614 including a path switch enable indication as a parameter. The peer WTRU (e.g., WTRU2 604) may be configured to send an acknowledgement, for example, in a link modification acceptance message 616. The WTRU may use a similar link modification process to deactivate the path switch. For example, when the path switch is enabled on the PC5 link, WTRU1 602 may send a link modification request 614 including a "path switch deactivate" indication, and / or the acknowledgement sent by WTRU2 604 may include the same "path switch deactivate" indication.

[0185] WTRU1 602 and / or WTRU2 604 may not send the corresponding link modification request 614 / link modification acceptance message 616, and / or, conversely, WTRU1 602 may send a path switch request 618 (e.g., WTRU1 602 may not transmit a link modification request 614 to WTRU2 604 and / or WTRU1 602 may not receive a link modification acceptance 616 from WTRU2 604).

[0186] WTRU2 604 may be configured to accept path switch enablement, for example, by sending a link modification acceptance message 616 that includes a "path switch enabled" indication / parameter. Similarly, WTRU2 604 may be configured to reject path switch enablement, for example, by sending a link modification rejection message that includes a "path switch enablement rejected" indication / parameter.

[0187] The path switch procedure described herein may also or alternatively be used (e.g., with respect to Figure 2 the path switch procedure described) to perform a path switch between WTRU1 602 and WTRU2 604. For example, as Figure 6 shown, WTRU1 602 may be configured to send a path switch request 618 to WTRU2 604. At 618, the path switch request sent by WTRU1 602 may be triggered (e.g., sent as a response) after PC5 link establishment and / or path switch negotiation (e.g., after a period of time). WTRU1 602 may be configured to wait for certain thresholds to be met, e.g., QoS on the PC5 link is acceptable and / or network coverage is low.

[0188] WTRU2 604 may be configured to accept a path switch request 618, for example, by sending a path switch response message 620 to WTRU1 602. Similarly, WTRU2 604 may be configured to reject a path switch request, for example, by sending a path switch rejection message that includes an indication of rejecting the path switch (e.g., "not ready for path switch" or "target link unavailable"). WTRU1 602 and / or WTRU2 604 may be configured to notify and / or inform their respective application layers of the path switch, and / or application traffic may be switched to the PC5 link.

[0189] Although not shown in Figure 6 , WTRU1 602 and WTRU2 604 may have established a PC5 link prior to the path switch decision (e.g., from Uu to PC5). In this case, PC5 discovery and / or PC5 unicast link establishment may not be performed. Similarly, if the PC5 peer WTRUs have agreed to path switch enablement and / or policies, link modification request / acceptance messages may not be sent.

[0190] Figure 7 Illustrates an example process 700 of network-triggered path switching. One or more of the following may be applied. The network may control the path switching from Uu to PC5 and / or assist in the path switching from Uu to PC5. For example, if the network is experiencing congestion, the network may trigger one or more WTRUs to perform a path switch to the PC5 interface. In other scenarios, such as due to WTRU mobility and / or real-time radio conditions, prediction and / or network analysis functions may predict / anticipate QoS degradation and / or link failure (e.g., a vehicle approaching a tunnel and / or entering an underground parking lot, etc.), and / or the network may trigger one or more WTRUs to switch from the Uu interface to the PC5 interface. In these scenarios, certain network functions (such as AMF, SMF, UPF, DDNMF, and / or application functions triggered based on applications) may report to certain analysis functions in the network and / or subscribe to certain analysis functions in the network. For example, a network function may subscribe to NWDAF, and NWDAF may perform analysis and / or indicate / trigger a path switch to the appropriate network function.

[0191] In the example, the WTRU may have a PDU session established through the Uu interface and / or may switch to the PC5 interface in response to a network trigger. For example, the network may trigger a path switch based on certain network analysis. A peer WTRU may have been discovered through the PC5 interface. Similarly, a PC5 link may have been established. However, the WTRU may be configured to wait for a network trigger before initiating / performing a path switch from the Uu interface to the PC5 interface. In some scenarios, a PC5 link may not have been established between peer WTRUs, and / or the PC5 link will be established after the network has triggered a path switch.

[0192] As Figure 7As shown, during initial network registration (e.g., at 706a and / or 706b), WTRU1 702 and / or WTRU2 704 may provide their respective path switching capabilities (e.g., from PC5 to Uu (or vice versa)) to the network (e.g., 707a and / or 707b). Additionally, or alternatively, the path switching capability may be associated with a PDU session (e.g., at 708a and / or 708b), and / or the WTRU may be configured to send the ability to switch paths to PC5 when establishing a PDU session. The WTRU may be configured to send, for example, a request for a given PDU session (e.g., at 708a and / or 708b) that depends on network path switching assistance during PDU session establishment. The SMF may verify, for example, based on subscriptions with the UDM and / or operator policies with the PCF, that path switching assistance has been authorized. As described herein, the SMF may communicate with the NWDAF, for example, to assist in making path switching decisions (e.g., to obtain predicted service experience data on the Uu link). The WTRU may receive, for example, in a PDU session acceptance message, confirmation that network-assisted path switching has been enabled for the PDU session.

[0193] WTRU1 702 and / or WTRU2 704 may continue to communicate via the Uu link (e.g., an established PDU session) (e.g., at 708a and / or 708b). At 710, a network function such as the AMF may instruct the respective WTRU to subscribe to the corresponding DDNMF, for example, to obtain proximity alerts. At 710, for example, WTRU1 702 and / or WTRU2 704 may subscribe to proximity alerts via their respective DDNMFs. When WTRU1 702 and / or WTRU2 704 are in proximity, the corresponding DDNMF may trigger discovery (e.g., at 712a and / or 712b). At 714, WTRU1 702 and / or WTRU2 704 may perform PC5 discovery and / or may establish a PC5 link (e.g., but not necessarily use). For example, if the WTRUs have established their PC5 links, the WTRUs may be configured to request network path switching assistance using a PSAF (e.g., DDNMF, SMF), as described herein with respect to Figure 4 as described.

[0194] In an example, DDNMF1 703a and / or DDNMF2 703b may determine (e.g., jointly determine) to trigger a path switch. For example, DDNMF1 703a and / or DDNMF2 703b may determine (e.g., jointly determine) to trigger a path switch based on information exchanged between the DDNMFs / ProSe ASs of the two WTRUs. At 716, as Figure 7As shown, two DDNMFs (e.g., DDNMF1 703a and / or DDNMF2 703b) can send a path switch request (e.g., from the Uu interface to the PC5 interface) to each WTRU in the corresponding WTRU. The path switch request information can include information for assisting the WTRU in establishing a PC5 connection. For example, the DDNMF (e.g., DDNMF1 703a and / or DDNMF2 703b) can send one or more of the following items: discovery code / filter, QoS information, peer WTRU layer 2 ID, security policy, etc. The path switch trigger message can include information for notifying the WTRU whether the path switch is a temporary path switch or a permanent path switch. If the path switch is a temporary path switch, the path switch trigger message can include a valid time period / window associated with the temporary path switch. The WTRU can be configured to start a reception timer and / or switch the communication path back to the Uu interface when the timer expires.

[0195] In an example, at 718, certain network functions (NFs) (such as AMF, SMF, UDM, etc.) can report and / or subscribe to path switch indications to the NWDAF (e.g., 705a and / or 705b), and / or provide WTRU mobility information, including tracking area, timestamp, etc.

[0196] At 720a and / or 720b, for example, the NWDAF (e.g., 705a and / or 705b) can provide certain information to certain network functions (e.g., SMF / PCF), and this information can be used by the corresponding network functions to determine whether the conditions for path switching have been met (e.g., based on service experience data). For example, the information provided by the NWDAF (e.g., 705a and / or 705b) can include one or more of the following items: WTRU ID, WTRU location (e.g., based on the tracking area), and / or the maximum time window before a PC5 link must be established.

[0197] As Figure 7As shown, NF1 707a can trigger a path switch to WTRU1 702 and / or NF2 707b can trigger a path switch to WTRU2 704 (e.g., based on information received by the NWDAF). For example, NF1 707a and / or NF2 707b can send a path switch request (e.g., at 722a and / or 722b), which includes a timer value that must be completed before the path switch, and / or a QoS threshold. In response to the corresponding path switch request (e.g., at 722a and / or 722b), WTRU1 702 and / or WTRU2 704 can perform unicast link establishment with each other via the PC5 interface. Additionally, or alternatively, if a PC5 link has been established between WTRU1 702 and WTRU2 704, then the path switch process described in Figure 5 can be performed (e.g., the processes 8 to 10 of Figure 6 can be performed). WTRU1 702 and / or WTRU2 704 can notify their respective applications of the path switch, and / or traffic can be switched from the PDU session to the PC5 link.

[0198] The WTRU can be provisioned with one or more parameters associated with path switching (e.g., path switching parameters). One or more of the following can be applied. The WTRU can be configured with a path switching policy that indicates whether path switching between the Uu interface and PC5 is allowed. For example, the path switching policy can also indicate whether path switching between the Uu interface and PC5 is allowed for each ProSe service. For example, if the application uses multiple ProSe services, different path switching policies can be applied for each ProSe service. Path switching parameters (e.g., including a list of allowed QoS for the PC5 QoS flow) can be provided for each ProSe service for which path switching is allowed. The selected PC5 QoS flow with the corresponding QoS level (e.g., selected from the list of allowed QoS) can be switched to the QoS flow with the corresponding QoS level in the PDU session associated with the Uu interface. In some scenarios, the path switching parameters can include a QoS list. If provided, the QoS list in the path switching parameters can include a subset of the QoS list in the ProSe parameters for the ProSe service (e.g., the subset can be provided by the network). If no QoS list is provided, the WTRU can determine to use the QoS list included in the ProSe parameters of the ProSe service as the list of allowed QoS for the PC5 QoS flow.

[0199] Additionally, or alternatively, one or more PDU session parameters (e.g., DNN, SSC mode, S-NSSAI, etc.) can be provided to the WTRU. For example, the WTRU can use these PDU session parameters to establish a PDU session over the Uu interface (e.g., for an application using the ProSe service). In some scenarios, the WTRU can be assigned a dedicated DNN and / or network slice for a given application. For example, these PDU session parameters can be provided to the WTRU via a WTRU Routing Selection Policy (URSPI) rule.

[0200] The AF associated with a given application can provide certain application-level session information and / or be associated with certain application-level session information. When the AF associated with an application provides application-level session information (e.g., including service requirements and / or a list of target WTRUs), the AF can also or alternatively include an indication regarding the allowance of path switching between the PC5 interface and the Uu interface for that application.

[0201] The Policy Control Function (PCF) can receive certain application-level session information for a given application. When the PCF receives the application-level session information for an application, the PCF can determine Policy and Charging Control (PCC) rules for existing or future PDU sessions associated with that application. If the PCF knows that path switching between the PC5 interface and the Uu interface is allowed for that application (e.g., when the PCF is determining the associated PCC rules), the PCF can include a QoS list for QoS flows over the Uu interface and / or a QoS list for PC5 QoS flows over the PC5 interface (e.g., to make the application compatible with path switching).

[0202] The PCF can allocate a security policy for the WTRU (e.g., a security policy for each ProSe service), which can indicate whether signaling, user plane (UP) confidentiality, and / or integrity protection are required, preferred, or not required for the PC5 interface. On the Uu side, the RAN can activate UP confidentiality and / or UP integrity protection (e.g., for each DRB of a PDU session according to the network UP security policy). The WTRU can determine whether a QoS flow can be switched between the PC5 interface and the Uu interface, for example, based on the verification of the compatible UP security levels between the PC5 interface and the Uu interface. For example, if UP confidentiality protection is not activated for a PDU session, the WTRU can determine that QoS flows associated with ProSe services (e.g., ProSe services for which the security policy indicates preference or non-requirement for confidentiality) can be switched to the Uu interface. Additionally, or alternatively, the WTRU can not switch the QoS flows of ProSe services for which the security policy indicates a requirement for confidentiality.

[0203] Figure 8Illustrates an example path switch procedure 800 from a PC5 interface to a Uu interface with path switch parameter allocation. One or more of the following may be applied. At 806, as Figure 8 shown, a path switch policy and / or associated parameters (e.g., path switch parameters) may be provided for WTRU1 802 and / or WTRU2 804. At 808, WTRU1 802 and / or WTRU2 804 may establish a PC5 unicast connection (e.g., including a PC5 QoS flow) for a given application. For example, a target QoS for the PC5 QoS flow may be selected (e.g., selected from a list of allowed QoS for the PC5 QoS flow associated with the ProSe service for the application). At 810, when communicating with each other for the application, e.g., WTRU1 802 and / or WTRU2 804 may decide to perform a path switch from the PC5 interface to the Uu interface for the ProSe service. WTRU1 802 and / or WTRU2 804 may negotiate / determine whether to perform the path switch for the ProSe service. Additionally, or alternatively, the path switch negotiation / determination 810 may be performed after a PDU session establishment (e.g., after WTRU 1 802 receives a PDU session establishment response at 814a). For example, if the path switch negotiation / determination 810 is performed after a PDU session establishment, the path switch negotiation 810 may include the following indication: successful PDU session establishment for the application from WTRU1 802 and / or successful PDU session establishment for the application from WTRU2 804.

[0204] At 812a, the WTRU 1 802 may request PDU session establishment from the network (e.g., 5GCN) using certain PDU session parameters (e.g., DNN, SSC mode, and / or S-NSSAI) assigned for the application used for ProSe services. After determining to perform a path switch, the WTRU 1 802 may request a PDU session from the network. The WTRU 1 802 may indicate that the requested PDU session will serve the application whose traffic will switch from the PC5 interface to the Uu interface. After receiving the PDU session establishment request 812a, the network (e.g., 5GCN) may know that the WTRU 1 802 is requesting a PDU session for the application to switch from the PC5 interface and / or the Uu interface (e.g., based on the indication and / or the requested DNN when it is dedicated to the application that allows path switching between the PC5 interface and / or the Uu interface). Based on the associated PCC rules, the network (e.g., 5GCN) may authorize the PDU session establishment request and / or assign QoS flows with QoS rules for the application, and these QoS flows may be included in the PDU session response at 814a. After successful PDU session establishment, e.g., the WTRU 1 802 may transmit a path switch request to the WTRU 2 804. The path switch request may also or alternatively include the PDU session establishment result.

[0205] Additionally, or alternatively, after receiving a path switch response from the WTRU 2 804, the WTRU 1 802 may trigger PDU session establishment. However, if a path switch rejection is received, the WTRU 1 802 may not establish a PDU session and / or may release and / or deactivate the previously established PDU session for path switching for the application.

[0206] At 812b, after determining to perform a path switch, for example, the WTRU 2 804 may request the establishment of a PDU session with the network (e.g., 5GCN) using certain PDU session parameters assigned for the application associated with the corresponding ProSe service (e.g., DNN, SSC mode, and / or S-NSSAI). The WTRU 2 804 may indicate that the requested PDU session will serve the application whose traffic will switch from the PC5 interface to the Uu interface. After receiving the PDU session establishment request, for example, the network (e.g., 5GCN) may know that the WTRU 2 804 requests a PDU session for the application to switch from the PC5 interface and / or the Uu interface (e.g., according to the indication and / or the requested DNN when it is dedicated to the application that allows path switching between the PC5 interface and the Uu interface). Based on the associated PCC rules, the network (e.g., 5GCN) may authorize the PDU session establishment request and / or assign QoS flows with QoS rules for the application, and these QoS flows may be included in the PDU session response at 814b. When the WTRU 2 804 receives a path switch request, the WTRU 2 804 may respond with a path switch response. The WTRU 2 804 may include the result of the PDU session establishment in the response to the received path switch request from the WTRU 1 802.

[0207] Additionally, or alternatively, the PDU session establishment may be performed after receiving a path switch request from the WTRU 1 802, and / or the WTRU 2 804 may respond to the path switch request based on the result of the PDU session establishment. At 816, the WTRU 1 802 and / or the WTRU 2 804 may cancel the path switch in the following cases: the PDU session establishment fails and / or the PDU session establishment does not include QoS flows whose QoS levels are compatible with the QoS level of the PC5 QoS flow for the application; and / or the activated PDU session security level is not compatible with the required security level of the selected PC5 QoS flow. However, if the PDU session establishment from the WTRU 1 802 and / or the WTRU 2 804 is successful, the WTRU 1 802 and / or the WTRU 2 804 may start using the established PDU session to exchange the traffic of the application.

[0208] Additionally, or alternatively, the WTRU 1 802 and / or the WTRU 2 804 may exchange additional signaling, for example, to confirm the successful establishment of the PDU session. After the signaling, the WTRU 1 802 and / or the WTRU 2 804 may start using the established PDU session to exchange the traffic of the application.

[0209] Figure 9Illustrates an example path switching process 900 from the Uu interface to the PC5 interface with parameter coordination (e.g., path switching parameter coordination at 906). One or more of the following may be applied. As Figure 9 shown, a path switching strategy and / or associated path switching parameters (e.g., at 906) may be provided for WTRU1902 and / or WTRU2 904. For a given application, WTRU1 902 and / or WTRU2 904 may establish a PDU session and / or communicate with each other. Based on the received path switching strategy for the application, a path switching process from the Uu interface to the PC5 interface may be initiated. WTRU1 902 and / or WTRU2 904 may share (e.g., both may share) the PC5-related information of the application, such as an identifier associated with the application (e.g., AppID1), and / or an identifier of the user of WTRU1 902 (e.g., UserID1), and / or an identifier of the user of WTRU2 904 (e.g., UserID2).

[0210] WTRU1 902 and / or WTRU2 904 may initiate an application traffic switching path from the Uu interface to the PC5 interface. For example, the path switching may be initiated from the application layer or the like based on the path switching strategy. At 908, WTRU1 902 and / or WTRU2 904 may perform a PC5 discovery process. During the PC5 discovery process 908, WTRU1 902 and / or WTRU2 904 may discover each other, for example, using relevant identifiers (e.g., AppID1, UserID1, and / or UserID2).

[0211] When transmitting an announcement message, for example, WTRU1 902 may include AppID1, UserID1, and UserID2 as application layer metadata. WTRU2 904 may determine whether the application layer metadata includes AppID1, UserID1, and / or UserID2. Additionally, or alternatively, UserID1 and / or UserID2 may be included in the user information of the PC5 discovery message. Additionally, or alternatively, AppID1, UserID1, and / or UserID2 may be used as input values to derive a source layer 2 ID and / or a target layer 2 ID for the PC5 discovery process.

[0212] At 910, the WTRU 1 902 may transmit a Direct Communication Request (DCR) message to the WTRU 2 904. For example, the WTRU 1 902 may include in the DCR message 910 application information, user information of the WTRU 1 902, and / or target user information of the WTRU 2 904. During or after enabling security protection, the WTRU 1 902 may transmit additional information, such as the available QoS levels of the PC5 QoS flows compatible with the QoS flows for the application traffic on the Uu interface. When the WTRU 1 902 selects a certain QoS level, the WTRU 1 902 may select that QoS level from the allowed QoS list of the PC5 QoS flows. After receiving the DCR message 910 from the WTRU 1 902, the WTRU 2 904 may know that a path switch has been requested for that application (e.g., based on the application information, user information of the WTRU 1 902, and / or user information of the WTRU 2 904).

[0213] Additionally, or alternatively, the WTRU 1 902 may include a path switch indication in the DCR 910 sent to the WTRU 2 904, and / or the WTRU 2 904 may know that a path switch has been requested for that application based on the path switch indication.

[0214] When the WTRU 2 904 receives the available QoS levels from the WTRU 1 902, the WTRU 2 904 may determine whether these QoS levels are within the allowed QoS list of the PC5 QoS flows of the WTRU 2. If these QoS levels are within the allowed QoS list of the WTRU 2 904, the WTRU 2 904 may accept the DCR 910, for example, by transmitting a Direct Communication Accept message at 912. If these QoS levels are not within the allowed QoS list of the WTRU 2 904, the WTRU 2 904 may select other QoS values from the allowed QoS list of the WTRU and / or include other QoS values in the Direct Communication Accept message 912 (e.g., via a rejection code). When receiving the Direct Communication Accept message 912 with a rejection code and alternative QoS levels, the WTRU 1 902 may review the other QoS levels, and / or initiate another direct communication establishment process, and / or alternatively the WTRU 1 902 may accept the QoS levels included in the Direct Communication Accept message 912.

[0215] As Figure 9As shown, if path switch negotiation is successful (e.g., a PC5 link with an acceptable QoS level is successfully established), the WTRU 1902 and the WTRU 2904 may exchange user traffic for the application via the PC5 link (e.g., at 914). After the path switch is successful, the WTRU 1902 and / or the WTRU 2904 may release the PDU session for the application (e.g., at 916a and / or 916b).

[0216] Although the features and elements have been described above in particular combinations, one of ordinary skill in the art will understand that each feature or element may be used alone or in any combination with other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (sent via wired or wireless connections) 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 disks (DVDs)). A processor associated with software may be used to implement a radio frequency transceiver for a WTRU, terminal, base station, RNC, or any host computer.

Claims

1. A first wireless transmit / receive unit (WTRU) comprising: a processor configured to: determine that at least one trigger has occurred for performing a path switch from a PC5 communication link to a Uu-based network communication link; transmit a path switch request to a second WTRU via the PC5 communication link; receive first information from the second WTRU, wherein the first information includes a path switch response for communicating via the Uu-based network communication link; perform a protocol data unit (PDU) session establishment with a network node or a PDU session modification procedure with the network node based on receiving the path switch response to establish a network-based PDU session; and transmit second information to the second WTRU for communicating via the Uu-based network communication link.

2. The first WTRU according to claim 1, wherein the processor is configured to receive a message from a network node indicating permission for path switching or a policy for enabling path switching.

3. The first WTRU according to claim 1, wherein the at least one trigger includes the first WTRU being in a location area where path switching is permitted, the PC5 link quality being below a threshold, an indication from an application, or the Uu link quality being above a threshold.

4. The first WTRU according to claim 1, wherein the processor is configured to: determine that the link quality of the PC5 communication link is below a threshold; and based on determining that the link quality of the PC5 communication link has dropped below the threshold, determine that the at least one trigger for performing the path switch has occurred.

5. The first WTRU according to claim 1, wherein the processor is configured to: receive provisioning information, wherein the provisioning information includes path switching capabilities, one or more path switching policies, or a path switching information sharing method; and determine that the at least one trigger for performing the path switch is based on the provisioning information.

6. The first WTRU according to claim 1, wherein the processor is configured to: transmit the path switch request to the second WTRU based on determining that one or more triggers have occurred.

7. The first WTRU according to claim 1, wherein the path switch request indicates whether the PC5 communication link should be retained after the path switch.

8. The first WTRU according to claim 1, wherein the path switch request is transmitted to the second WTRU via the PC5 communication link; wherein the path switch response is received from the second WTRU via the PC5 communication link; and wherein the path switch confirmation is transmitted to the second WTRU via the PC5 communication link.

9. The first WTRU according to claim 1, wherein the processor is configured to switch traffic or one or more proximity services from the PC5 communication link to the Uu-based network communication link.

10. The first WTRU according to claim 1, wherein the receipt of the first information indicates that the path switch request has been accepted.

11. A method performed by a first wireless transmit / receive unit (WTRU), the method comprising: Determining that at least one trigger has occurred for performing a path switch from a PC5 communication link to a Uu-based network communication link; Transmitting a path switch request to a second WTRU via the PC5 communication link; Receiving first information from the second WTRU, wherein the first information includes a path switch response for communicating via the Uu-based network communication link; Based on receiving the path switch response, performing a protocol data unit (PDU) session establishment with a network node or a PDU session modification procedure with the network node to establish a network-based PDU session; And Transmitting second information to the second WTRU for communicating via the Uu-based network communication link.

12. The method according to claim 11, the method further comprising: Receiving a message from a network node indicating permission for path switching or a policy for implementing path switching.

13. The method according to claim 11, wherein the at least one trigger includes the first WTRU being in a location area where path switching is permitted, a PC5 link quality being lower than a threshold, an indication from an application, or a Uu link quality being higher than a threshold.

14. The method according to claim 11, the method further comprising: Determining that a link quality of the PC5 communication link is lower than a threshold; And Based on determining that the link quality of the PC5 communication link has dropped below the threshold, determining that the at least one trigger for performing the path switch has occurred.

15. The method according to claim 11, the method further comprising: Receiving provisioning information, wherein the provisioning information includes path switching capabilities, one or more path switching policies, or a path switching information sharing method; And Determining that the at least one trigger for performing the path switch is based on the provisioning information.

16. The method according to claim 11, the method further comprising: Based on determining that one or more triggers have occurred, transmitting a path switch request to the second WTRU.

17. The method according to claim 11, wherein the path switch request indicates whether the PC5 communication link should be retained after the path switch.

18. The method according to claim 11, the method further comprising: Switching traffic or one or more proximity services from the PC5 communication link to the Uu-based network communication link.

19. The method according to claim 11, the method further comprising: Transmitting a path switch request to the second WTRU via the PC5 communication link; Receiving a path switch response from the second WTRU via the PC5 communication link; And Transmitting a path switch confirmation to the second WTRU.

20. The method according to claim 11, wherein receipt of the first information indicates that the path switch request has been accepted.

Images