Method for providing ip prefix using existing pc5 link

Abstract

Methods for providing prefix information to a remote wireless transmit / receive unit (WTRU) are described herein. One method can include sending or receiving a protocol data unit (PDU) over a link to a remote WTRU, the PDU including a first IP address associated with a PDU session utilizing a session service and session continuity mode 3 (SSC3). The method can include receiving a message for modifying the PDU session indicating a request for reactivation, and sending a message for modifying the PDU session. The method can include receiving new IP prefix information, sending a message including the new IP prefix information to the remote WTRU over the link, and sending or receiving a PDU over the link to the remote WTRU, the PDU including a second IP address generated based on the new IP prefix information.

Description

[0001] Cross-references to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 457,710, filed April 6, 2023, the contents of which are incorporated herein by reference. Background Technology

[0002] In cellular networks operating according to the 3GPP (3rd Generation Partnership Project) technical specifications for fifth-generation (5G) standards, an integral aspect of data services is session and service continuity, thereby ensuring a seamless user experience regardless of changes in the user's Internet Protocol (IP) address or relocation of the core network anchor point.

[0003] In 4G Long Term Evolution (LTE) packet systems, IP session continuity can be maintained by preserving the IP addresses of both the P-GW and the user's Protocol Dedicated Unit (PDU) sessions, regardless of mobility events. However, not all applications require guaranteed IP session continuity, even though service continuity remains essential. With the advent of 5G, networks can provide enhanced flexibility by offering various types of session continuity tailored to WTRUs or service types.

[0004] To meet the diverse continuity requirements of different applications and services, the 5G system architecture introduces three Session and Service Continuity (SSC) modes. Once an SSC mode is assigned to a PDU session, it remains fixed for the entire duration of the session. The 5G architecture gives applications the right to influence the selection of the SSC mode based on the specific needs of the data service. Summary of the Invention

[0005] This document describes a method for providing prefix information to a remote wireless transmit / receive unit (WTRU). One method may include transmitting or receiving a Protocol Data Unit (PDU) via a link to the remote WTRU, the PDU including a first IP address associated with a PDU session utilizing Session Service and Session Continuity Mode 3 (SSC3). The method may include receiving a message indicating a request to reactivate for modifying the PDU session, and transmitting a message for modifying the PDU session. The method may also include receiving new IP prefix information, transmitting a message including the new IP prefix information to the remote WTRU via the link, and transmitting or receiving a PDU via the link to the remote WTRU, the PDU including a second IP address generated based on the new IP prefix information. Attached Figure Description

[0006] A more detailed understanding can be obtained from the following description, given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the figures indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments may be implemented; Figure 1B The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows an example wireless transmit / receive unit (WTRU) used in a communication system. Figure 1C The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows an example radio access network (RAN) and an example core network (CN) used in the communication system. Figure 1D The illustration shows a method according to one embodiment. Figure 1A The illustrated system diagram shows another example RAN and another example CN used in the communication system. Figure 2 This is a diagram illustrating an example of a procedure for releasing a PC5 link based on a cause code; Figure 3 This diagram illustrates several solutions for PDU session establishment / reconstruction when a relay WTRU provides IP prefix information to a remote WTRU; Figure 4 This is a diagram illustrating an exemplary procedure executed upon receiving a "New PC5 Link" instruction (MBB PC5 Link); and Figure 5 This is a flowchart illustrating a method for initiating link release and reconstruction based on the included cause values ​​provided by the relay WTRU; Figure 6 This is a flowchart illustrating a method performed by a relay WTRU to provide an IP prefix to a remote WTRU; and Figure 7 It is a flowchart illustrating the method executed by a remote WTRU, which performs a make-before-break procedure to establish a link. Detailed Implementation

[0007] Figure 1AThis is a schematic 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, and broadcasts to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word Discrete Fourier Transform Spread Spectrum OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0008] like Figure 1A As shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which can be referred to as a station (STA)) can be configured to transmit and / or receive wireless signals and can include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0010] Base station 114a may be part of RAN 104, and may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. The cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

[0012] More specifically, as described above, the communication system 100 can be a multi-access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish an air interface 116 using Wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

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

[0014] In one embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as NR wireless access, which can use NR to establish air interface 116.

[0015] In one embodiment, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can jointly implement LTE radio access and NR radio access, for example, using the dual connectivity (DC) principle. Therefore, the air interface used by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

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

[0017] For example, Figure 1A Base station 114b can be a wireless router, home node B, home eNodeB, or access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for drone use), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can be directly connected to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN106.

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

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

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

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

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

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

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

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

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

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

[0028] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information on the air interface 116 from base stations (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 the WTRU 102 may acquire location information using any suitable location determination method while remaining consistent with the embodiments.

[0029] The processor 118 may be further coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors. Sensors may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors, altimeters, light sensors, touch sensors, magnetometers, barometers, attitude sensors, biosensors, humidity sensors, etc.

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

[0031] Figure 1C This diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

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

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

[0034] 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 (PGW) 166. Although the foregoing elements are described as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

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

[0036] The SGW 164 can connect to each of the eNode Bs 160a, 160b, and 160c in RAN104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during inter-eNode B handover, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0037] SGW 164 can connect to PGW 166, which can provide WTRU 102a, 102b, 102c with access to packet-switched networks such as Internet 110, so as to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

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

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

[0040] In a representative embodiment, another network 112 may be a WLAN.

[0041] A WLAN in Infrastructure Basic Services 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 access or interface with a distributed system (DS) or another type of wired / wireless network that transmits traffic to and / or out of the BSS. Traffic originating outside the BSS destined for a STA can reach the STA via the AP and can be delivered to the STA. Traffic originating from a STA destined for an external BSS can be sent to the AP for delivery to the appropriate destination. For example, traffic between STAs within the BSS can be transmitted via the AP, where the source STA can send traffic to the AP, and the AP can deliver 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 transmitted between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode is sometimes referred to here as a "self-organizing" communication mode.

[0042] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of a fixed width (e.g., a wide bandwidth of 20 MHz) or a dynamically configured width. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA, including the AP, can sense the primary channel. If a particular STA senses / detects and / or determines that the primary channel is busy, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

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

[0044] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. A 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 an 80+80 configuration. For the 80+80 configuration, after channel coding, the data passes through a segment resolver, which splits the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped onto two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0045] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 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 may support metering-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

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

[0047] In the United States, the available frequency band for 802.11ah is from 902 MHz to 928 MHz. In South Korea, the available frequency band is from 917.5 MHz to 923.5 MHz. In Japan, the available frequency band is from 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.

[0048] Figure 1D This diagram illustrates a system diagram of RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0049] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c on air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, for example, gNB 180a may use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers (not shown) to WTRU 102a. A subset of these component carriers can be on unlicensed spectrum, while the remaining component carriers can be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0050] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable digitization. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can differ for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a variable number of OFDM symbols and / or a continuously variable absolute time).

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

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

[0053] Figure 1DThe CN 106 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0054] AMF 182a and 182b can connect to one or more gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the service type used by WTRU 102a, 102b, and 102c. For example, different network slices can be created for different use cases, such as services relying on Ultra Reliable Low Latency Time (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, services for MTC access, and so on. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies such as WiFi.

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

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

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

[0058] Given Figure 1A-1D as well as Figure 1A-1D As described herein, one or more of the following functions can be performed by one or more emulation devices (not shown): WTRU 102a-d, Base Station 114a-b, eNode-B160a-c, MME 162, SGW 164, PGW 166, gNB180a-c, AMF 182a-b, UPF 184a-b, SMF183a-b, DN185a-b, and / or any other device(s) described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0059] Simulation devices can be designed to perform tests on one or more other devices in laboratory and / or carrier network environments. For example, one or more simulation devices can perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device and / or use over-the-air wireless communication to perform tests for testing purposes.

[0060] One or more simulation devices may perform one or more functions, including all functions, rather than being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices may be used to test test scenarios in laboratory and / or non-deployment (e.g., testing) wired and / or wireless communication networks to implement the testing of one or more components. One or more simulation devices may be test devices. Simulation devices may transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0061] The following paragraphs provide a general description of Session and Service Continuity (SSC) modes. The 5G system architecture supports SSC to meet the diverse continuity requirements of different applications / services. SSC modes, which remain unchanged throughout the entire lifetime of a PDU session, are an integral part of the system. Three SSC modes are defined. SSC Mode 1 (SSC1) ensures the network maintains WTRU connectivity, thereby maintaining IP addresses for PDU sessions of IPv4, IPv6, or IPv4v6 type. For PDU sessions utilizing SSC Mode 2 (SSC2), the network can release the WTRU connection service and the corresponding PDU session, resulting in the release of one or more IP addresses allocated for IPv4, IPv6, or IPv4v6 type. On the other hand, SSC Mode 3 (SSC3) allows visible changes to the WTRU's user plane while ensuring no connection loss. The network establishes connections through new PDU session anchors before terminating existing connections, which carries the burden of service continuity. However, when the PDU session anchor changes, the IP address used for IPv4, IPv6, or IPv4v6 types cannot be guaranteed to remain in SSC mode 3.

[0062] Recent proposals within the 3GPP working group address issues encountered in PC5 communications and impact procedures for reactivating or establishing new Protocol Data Unit (PDU) sessions for relay WTRUs (e.g., Layer 3 (L3) WTRU to Network (WTRU) relays). In some procedures, as part of a PDU session modification process, an L3W2N relay serving a remote WTRU can rebuild the PDU session using SSC Mode 3 after receiving a cause value such as a 5G Session Management (5GSM) cause value (e.g., cause value #39 "Request Reactivation"). In this case, the Internet Protocol (IP) address / prefix used by the remote WTRU may be affected, as maintaining the IP address after PDU session reconstruction may be impossible or not permitted in SSC Mode 3.

[0063] The solution proposed in this paper can, for example, stipulate that after a new PDU session is established, the W2N trunk initiates a PC5 link release procedure, enabling the remote WTRU to establish a new PC5 link and use the new PDU session for service (i.e., the remote WTRU obtains a new IP address associated with the new PC5 link and the new PDU session).

[0064] SSC3 is described in further detail in this paper. As described in 3GPP technical specifications (e.g., 23.501 and 23.502), when using SSC3, changes to the user plane may be visible to the WTRU, while the network ensures that the WTRU does not suffer from connection loss.

[0065] As part of the PDU session modification procedure, W2N trunks can utilize SSC3 to rebuild a PDU session after receiving an indication of a cause value (e.g., 5GSM cause value #39 "Request Reactivation"). Therefore, a connection is established through a new PDU session anchor before the previous connection is terminated, allowing for better service continuity. This behavior can be referred to as "connect-before-disconnect" connection establishment. When the PDU session anchor changes, the IP address used before establishing a connection with the new PDU session anchor may not be retained. The new anchor can be associated with a new PDU session or with the same PDU session (such as in the case of a multihomed PDU session). A multihomed PDU session can be a PDU session associated with multiple PDU session anchors and / or multiple IP prefixes.

[0066] This document describes SSC3 operations with multiple PDU sessions. In some cases, a new PDU session can be established with a new anchor. It may be necessary to send a new prefix to the remote WTRU to utilize this new PDU session / anchor. The old prefix may still be used for a period of time before the old PDU session is released. The PDU session address lifetime can be provided as part of the PDU session modification procedure.

[0067] This document describes the procedure for changing the PDU session anchor (e.g., for multihomed PDU sessions utilizing SSC3). The IPv6 prefix from the new anchor can be associated with an existing PDU session and may need to be sent to a remote WTRU to use the new PDU session anchor. The old prefix can still be used for a period of time.

[0068] SSC2 is further described in this document. As described in 3GPP technical specifications (e.g., 23.501 and 23.502), when using SSC mode 2, the network can release one or more connectivity services provided to the WTRU and release the corresponding PDU session(s). The release of the PDU session can cause the release of one or more IP addresses that have been assigned to the WTRU.

[0069] As part of the PDU session release procedure, W2N trunks can re-establish a PDU session using SSC2 after receiving a cause value (e.g., 5GSM cause value #39 "Request Reactivation"). Therefore, a connection can be established through a new PDU session anchor after a previous connection has been terminated. This behavior can be referred to as "break-before-reconnect" connection establishment or reconstruction.

[0070] If a PDU session has a single PDU session anchor, the network can trigger the release of the PDU session and instruct the WTRU to immediately establish a new PDU session with the same data network. If a PDU session has multiple PDU session anchors (i.e., in the case of a multi-homed PDU session or when an uplink classifier (UL CL) is applied to the PDU session), additional PDU session anchors can be released or assigned. The term UL CL can refer to the functionality supported by the UPF designed to distribute (e.g., local diversification) the traffic matching filters provided by the SMF. UL CL can enable the forwarding of UL traffic toward different PDU session anchors, as well as the merging of DL traffic to the WTRU. For example, UL CL can merge traffic from different PDU session anchors on the link toward the WTRU. This can be performed based on the traffic detection and traffic forwarding rules provided by the SMF.

[0071] This document describes the allocation of IP addresses for remote WTRUs via W2N relays. When using IPv6, remote WTRUs can support IPv6 stateless address autoconfiguration. A remote WTRU can send a router solicitation (e.g., a solicitation message) and, additionally or alternatively, receive prefixes from the relay via a router advertisement (e.g., an advertisement message). This might occur, for example, when establishing a PC5 link. When a PDU session is established, the relay can obtain prefixes from the network via prefix delegation. In some examples, the relay WTRU can assign prefixes to remote WTRUs using the prefix range associated with the PDU session.

[0072] The PC5 link release reason codes are described in further detail in this document. Reason codes that can be sent along with the PC5 link release message may include those indicating the following: direct communication with the target WTRU is not permitted; direct communication with the target WTRU is no longer required; a Layer 2 ID conflict for unicast communication has been detected; the direct connection is no longer available; there is a lack of resources for the 5G ProSe direct link; authentication failure; integrity failure; WTRU security capability mismatch; key (e.g., K...). NRP-sess The following are possible causes: a collision in the ID bit or (one or more) least significant bits of the LSB; a mismatch in the WTRU PC5 unicast signaling security policy; the required service is not permitted; the security policy is not compliant; congestion; authentication synchronization error; failure of the 5G ProSe WTRU to network relay security procedure; and / or protocol error, not specified.

[0073] The problems addressed by the embodiments presented herein are described in the following paragraphs. One such problem concerns the release / re-establishment of a PC5 link associated with a new PDU session. The release / re-establishment of a PC5 link as proposed in C1-230694 only works if a remote WTRU triggers the establishment of a new PC5 link with the same L3 W2N trunk. As fully described in the paragraphs above, when a W2N trunk receives the GSM reason value #39 "Request Reactivation", the reason code "Protocol Error, Unspecified" may be the only currently available non-specific reason code that can be used to release the PC5 link with the remote WTRU as part of a PDU session modification or release procedure.

[0074] Therefore, it is unclear how a remote WTRU can determine to establish a new PC5 link with the same trunk after the trunk WTRU initiates a PC5 link release with the cause value "Protocol Error, Unspecified". The default behavior in this situation might be to trigger the W2N trunk discovery procedure to find another available W2N trunk, since it may be unclear why the W2N trunk initiated the PC5 link release.

[0075] One of the questions addressed by the solutions presented in this paper is how a remote WTRU determines the need to establish a new PC5 link with the same W2N trunk when a PC5 link release request is received.

[0076] Another problem addressed by the embodiments presented herein may involve the loss of connectivity at a remote WTRU. Releasing the PC5 link and establishing a new PC5 link (as proposed in C1-230694) allows the remote WTRU to obtain a new IP address associated with a new PDU session; however, this may interrupt the connection to the remote WTRU, which is inconsistent with SSC3 behavior (i.e., the network ensures that the WTRU does not suffer from connection loss) and the use of a connect-then-disconnect approach that allows for service continuity. A question answered by one or more of the solutions presented herein could be how to maintain connectivity for a remote WTRU connected to an L3 W2N trunk when the PDU session anchor of a PDU session in SSC mode 3 changes.

[0077] In the following description, the terms 5G ProSe WTRU to network relay, WTRU to network relay, W2N relay and / or relay may be used interchangeably.

[0078] This paper proposes a solution that enables a remote WTRU to determine whether a new PC5 link should be established with the same W2N trunk after receiving a PC5 link release request with a "Request Reactivation" reason value. Some solutions define a PC5 link release request message that includes a new reason code "New PDU Session Available".

[0079] Furthermore, various solutions have been proposed to maintain connectivity to remote WTRUs connected to the L3 W2N trunk when the PDU session anchor of an SS3 PDU session changes. Some solutions maintain the existing PC5 link with the remote WTRU. The trunk WTRU can provide a new prefix to use on this PC5 link. Other solutions establish a new PC5 link between the remote WTRU and the trunk WTRU, in addition to the existing PC5 link. The benefits of these solutions can include: maintaining end-to-end session connectivity (i.e., session connectivity between the remote WTRU and the network (via PC5 and Uu interfaces)) when using SSC3; and minimizing interruptions when using SSC2.

[0080] The following paragraphs describe various proposed solutions to at least the problems / questions detailed above.

[0081] In some solutions, a PC5 link release request including a "new PDU session available" reason value can be sent. The solutions presented in the following paragraphs address issues related to PC5 link release and / or rebuilding. In some solutions, as part of a PDU session modification procedure, an L3 W2N trunk can establish a new PDU session using SSC3 upon receiving a message including a reason value (e.g., a 5GSM reason value #39 indicating "reactivation request"). Alternatively or additionally, an L3 W2N trunk can utilize SSC3 to update the IPv6 prefix configuration of an existing PDU session and change the PDU session anchor.

[0082] A W2N trunk can initiate a PC5 link release procedure after establishing a new PDU session (or after changing the PDU session anchor), and can set the reason value to "new PDU session available". Based on the received PC5 link release reason value, the remote WTRU can complete the PC5 link release procedure and trigger a PC5 unicast link establishment procedure with the same W2N trunk. The PC5 unicast link establishment procedure with the same W2N trunk can be triggered immediately after receiving the PC5 link release reason value, or immediately after the PC5 link release procedure completes. A new PC5 link can be established, and an IP address associated with the new PDU session can be assigned. The W2N trunk can retain the resources allocated to this remote WTRU for a period of time to ensure that it still has sufficient resources when the remote WTRU rebuilds its PC5 connection. After a period of time, the W2N trunk can release the reserved resources and make them available to another remote WTRU.

[0083] A PDU session modification procedure can be, for example, a network-initiated session modification procedure or a WTRU-initiated session modification procedure. A PDU session modification procedure can involve message exchange between the WTRU and the network. For example, a PDU session modification procedure can involve the CN (or a logical entity within the CN, such as a Session Management Function (SMF)) sending one or more messages or commands to the WTRU, including the aforementioned reason values. The PDU session anchor mentioned herein can refer to the UPF.

[0084] Figure 2 This is a diagram illustrating an example of a procedure for releasing a PC5 link based on a cause code. The solution shown involves sending / receiving a PC5 link release request message that includes a new cause value. Figure 2As shown, at step 211a, the remote WTRU 201 may have already established a PC5 unicast link with the L3 W2N relay WTRU 202. As shown at step 211b, the W2N relay 202 may have already established a PDU session communicating with the 5G CN 203 using SSC Mode 3 (SSC3). As part of the PDU session modification procedure, the L3 W2N relay 202 may establish a new PDU session using SSC3 based on a message including a 5GSM cause value (e.g., cause value #39 indicating "reactivation request") or after receiving a message including a 5GSM cause value (e.g., cause value #39 indicating "reactivation request"). As part of establishing a new PDU session, the W2N relay 202 establishes a connection with a new PDU session anchor at CN 203, as shown at 212. Alternatively or additionally, the L3 W2N relay may update the IPv6 prefix configuration of an existing PDU session based on the use of SSC3 and the change of the PDU session anchor. W2N trunk 202 can initiate a PC5 link release procedure after a new PDU session is established, and as shown at 213, can send a PC5 link release request message to remote WTRU 201. This PC5 link release request message can include a reason value indicating that a new PDU session is available. Remote WTRU 201 can then complete the PC5 link release procedure. This may involve sending a response message, such as... Figure 2 The PC5 link release acceptance message is shown at point 214. Based on the received PC5 link release request reason value, the remote WTRU 201 can immediately trigger the PC5 unicast link establishment procedure with the same W2N trunk at point 215. As shown at point 216, a new PC5 link can be established, and an IP address associated with the new PDU session can be generated.

[0085] exist Figure 2 In some iterations of the procedure shown, existing PDU sessions can utilize SSC2. In this case, at step 212, the existing PDU session can be released, and a new PDU session can be established. The connection on the Uu interface may not be maintained. W2N trunk 202 can initiate a PC5 link release procedure (e.g., as shown in step 213) before triggering the new PDU session establishment procedure or before completing the PDU session establishment procedure, which can reduce the time that the remote WTRU 201 loses connection during this period. Subsequent steps can maintain... Figure 2 The description shown is the same as the one above.

[0086] In some solutions, the W2N trunk provides a new prefix to the remote WTRU 201 via the existing PC5 link. Using the solutions described in the following paragraphs and figures (e.g., in...), Figure 3In steps 311-312 (described in further detail below), as part of a PDU session modification procedure or a procedure to change the PDU session anchor of an existing PDU session, a W2N relay may rebuild a PDU session due to SSC3 after receiving a cause value (e.g., a 5GSM cause value #39 indicating "reactivation request").

[0087] The existing PC5 unicast link between remote WTRU 201 and W2N trunk 202 can be maintained and associated with the new IPv6 prefix. Remote WTRU 201 can automatically generate a new IPv6 address using the new prefix to utilize the new PDU session anchor. Alternatively, the PDU session can have a different SSC mode (e.g., SSC2). In this case, the existing PDU session can be released, and a new PDU session can be established. Connections on the Uu interface may not be maintained. The remote WTRU can be notified when a connection on the Uu interface is lost / re-established.

[0088] Figure 3 This diagram illustrates several solutions for PDU session establishment / reconstruction when a relay WTRU provides IP prefix information to a remote WTRU. For example... Figure 3 As shown at point 311, a PC5 unicast link can be established between remote WTRU 301 and W2N trunk 302. Remote WTRU 301 can send PDUs to W2N trunk 302 for routing to destinations within the network using the established PDU session. For the same reason, remote WTRU 301 can use the established PDU session to receive PDUs from W2N trunk 302, which can be forwarded from other sources within the data network. As shown at point 312, W2N trunk 302 and CN 303 can establish a PDU session utilizing SSC3 or SSC2 (e.g., a new PDU session). If an existing PDU session utilizing SSC3 has already been created, as part of the PDU session modification procedure, when W2N trunk 302 has received a cause value (e.g., 5GSM cause value #39 indicating "reactivation request"), W2N trunk 302 can rebuild the PDU session or change the PDU session anchor to the existing PDU session. W2N relay 302 can receive new prefixes associated with new PDU session anchors.

[0089] When creating a new session using SSC2, the existing PDU session can be released first, as shown at 314. This can be done after W2N trunk 302 receives a cause value from CN 303 (e.g., a 5GSM cause value indicating #39 "Request Reactivation" as part of the PDU session release procedure). W2N trunk 302 can send a message to remote WTRU 301 indicating that the Uu connection is temporarily lost, as shown at 315. Remote WTRU 301 can suspend data transmission. In some examples, an existing "Keep Active" message sent from W2N trunk 302 to the remote WTRU can be modified to carry an indication of the lost Uu connection. Alternatively or additionally, a new PC5-S message, such as PC5_Link Indication, can be used.

[0090] As shown at 316, W2N trunk 302 can establish another PDU session using SSC2. At 317, W2N trunk 302 can notify remote WTRU 301 (e.g., via...). Figure 3 The message shown indicates (implicitly or explicitly) that the Uu connection has been re-established. This message may not be sent if W2N relay 302 implicitly notifies remote WTRU 301 that the Uu connection has been re-established.

[0091] exist Figure 3 In the first solution further illustrated, the new IP prefix can be sent by W2N trunk 302 via the existing PC5 link. As shown in steps 318a-319a, once a new PDU session is established or modified with the new prefix, W2N trunk 302 can autonomously decide to advertise the new IPv6 prefix to remote WTRU 301 via the existing PC5 link. For example, as part of a PDU session modification or release procedure, W2N trunk 302 can receive a cause value (e.g., 5G cause value #39 indicating "reactivation request"). CN 303 can include the cause value in the message transmitted within the PDU session modification or release procedure. Once a new PDU session is established or an existing PDU session is modified, this can be interpreted as triggering W2N trunk 302 to advertise the new prefix to remote WTRU 301.

[0092] As shown at 319a, W2N trunk 302 can send an advertisement message to remote WTRU 301. The advertisement message can be sent multiple times to ensure that remote WTRU 301 receives it. Remote WTRU 301 receiving the new prefix can automatically configure the new IPv6 address associated with the PC5 link and begin using its new IP address.

[0093] In the second set of examples illustrated in steps 318b-321b, W2N trunk 302 can use an existing PC5 link to send a new IP prefix to remote WTRU 301. As shown at step 318b, W2N trunk 302 can determine or decide that a change in the IP address at remote WTRU 301 is necessary. W2N trunk 302 can send a message to remote WTRU 301 notifying it that the new prefix is ​​available. For example, as shown at step 319b, once a new PDU session is established (or modified with the new prefix), W2N trunk 302 can send a message (e.g., a PC5-S message) to remote WTRU 301 indicating that the new prefix is ​​available.

[0094] This message can be a modified keep-alive or link modification message, which includes a new indication, such as "new prefix available". Alternatively or additionally, a new PC5-S message (e.g., PC5_new prefix available or PC5_link indication (new prefix available)) can be used. In this case, the indication message can be sent multiple times to ensure that the remote WTRU receives it.

[0095] Remote WTRU 301 can receive a PC5-S message from W2N trunk 302 indicating that a new prefix is ​​available. As shown in step 320b, based on the received indication, remote WTRU 301 can trigger an IP address configuration procedure to obtain the new IPv6 prefix and change its IP address. For example, remote WTRU 301 can send a solicitation message to W2N trunk 302, which allows the remote WTRU to initiate an IP address allocation procedure. As shown in 321b, W2N trunk 302 can reply to the message received from the remote WTRU by sending the new prefix in an announcement message. Upon receiving the announcement message, remote WTRU 301 can automatically configure itself with the new IPv6 address associated with the PC5 link and begin using this new IP address.

[0096] In the third set of examples illustrated in steps 318c-322c, the remote WTRU triggers the PC5 Link Identifier Update (LIU) procedure based on an indication received from W2N relay 302. As shown... Figure 3As further illustrated in step 318c, once a new PDU session is established or modified with a new prefix, W2N trunk 302 can send a message (e.g., a PC5-S message) indicating that the new prefix is ​​available to remote WTRU 301. In some examples, this can be performed consistent with the procedures and / or steps described above. As shown in step 319c, remote WTRU 301 can receive a message (e.g., a PC5-S message) indicating that the new prefix is ​​available from W2N trunk 302. Based on the received indication, the remote WTRU can trigger the LIU procedure. The receipt of the message indicating that the new prefix is ​​available can be used as a new trigger at remote WTRU 301 to initiate the LIU procedure and new IP address configuration.

[0097] The remote WTRU 301 can request a new prefix from the W2N trunk 302 by transmitting a message (e.g., a LIU request) that includes an indication of the need for an IP prefix, as shown at 320c. As shown at step 321c, the W2N trunk 302 can respond with a response message (e.g., a LIU response) that may include the new prefix to be used with the new PDU session anchor. As shown at step 322c, the remote WTRU 301 can complete the LIU procedure by sending an acknowledgment message (e.g., a LIU ACK message).

[0098] Based on each example described in the paragraphs above, as shown at 330, the remote WTRU 301 receiving the new prefix can automatically configure itself with the new IP address to be associated with the PC5 link. The remote WTRU 301 can then send and receive data, and use the new IP address to receive data to / from W2N trunk 302 for communication via the newly created PDU session.

[0099] Some solutions described in this document can implement establish-before-disconnect behavior for PC5 links. Trunks (e.g., W2N trunk WTRUs) and remote WTRUs can establish new PDU sessions or modify existing PDU sessions with a new prefix, according to one or more procedures described in the paragraphs and figures above. Once a new PDU session is established or modified with a new prefix, the W2N trunk can notify the remote WTRU that a new PC5 link needs to be established. The W2N trunk can send a message to the remote WTRU indicating the new PC5 link request, which may include an indication of a timeout value or timeout period. The timeout value indicates how long the existing PC5 link can be maintained. The W2N trunk can provide information to identify the new PDU session (e.g., PDU session ID). Identification information may be required when the W2N trunk uses multiple PDU sessions that may serve the RSC.

[0100] Based on the received instruction, the remote WTRU can trigger a PC5 link establishment procedure with the same trunk. The remote WTRU can execute the link establishment procedure, which may include sending an instruction that the established PC5 link will replace another PC5 link. The remote WTRU may include new PDU session identification information, which may have been previously received from the trunk.

[0101] Once a new PC5 link is established and a new IP address is configured at the remote WTRU, the remote WTRU can begin using the new PC5 link. The remote WTRU can release the old PC5 link before the timeout period expires.

[0102] Figure 4 This is a diagram illustrating an exemplary procedure for creating a new PC5 link. The procedure shown may involve sending a "new PC5 link" indication (e.g., a connect-before-disconnect (MBB) PC5 link indication). Figure 4 Steps 411-413 shown can be used in conjunction with the above regarding Figure 3 The steps described in paragraphs 311-313 are performed in a similar manner. For example... Figure 4 As shown at 414, W2N trunk 402 can send a message (e.g., a PC5-S message) to remote WTRU 401 indicating the need to establish a new PC5 link or requesting the establishment of a new PC5 unicast link. The PC5-S message shown at 414 can be, for example, a modified keep-alive or link modification message, which includes new indications such as "Request new PC5 link," "New prefix available," "New PDU session available," a new PC5-S message (e.g., a new unicast link request), or a link indication. A timeout value or period can be specified in the message, indicating the length of time during which the existing PC5 link can still be used. The timeout value or period can be set based on the PDU session address lifetime value. For example, the PDU session address lifetime value can be received during a procedure for creating a new PDU session or modifying an existing PDU session (e.g., as shown in step 413). Therefore, the new PC5 link is established before the old PDU session is released to maintain the connection. Information identifying a new PDU session can be included in a message sent from W2N relay 402 to remote WTRU 401.

[0103] As shown at 415, the remote WTRU 401 can receive PC5-S messages from W2N trunk 402 and immediately trigger a PC5 link establishment procedure with the same W2N trunk 402. The remote WTRU 401 can provide information to identify new PDU sessions if the W2N trunk 402 provided them earlier. Alternatively or additionally, if the remote WTRU 401 cannot establish a new PC5 link for some reason (e.g., reaching the maximum number of PC5 links, lack of available resources, etc.), the remote WTRU 401 sends back a message indicating rejection, including a reason value (e.g., keep-alive ACK, new unicast link rejection, or link modification rejection).

[0104] At 416, a new PC5 link is established between the 401 remote WTRU and the 402 W2N trunk, and this new PC5 link is associated with a new PDU session anchor. The W2N trunk 402 can use the information to identify the new PDU session to be associated with the new PC5 link. The remote WTRU can begin using the new PC5 link, as shown at 417. The remote WTRU can release the old PC5 link before the timer expires, as shown at 418.

[0105] Figure 5 This is a flowchart illustrating a method for link release and reconstruction initiated based on a cause value provided by the relay WTRU. (Example) Figure 5 As shown, at point 510, the remote WTRU can use the IP address associated with the first PDU session to communicate with the relay WTRU via the link (i.e., send or receive PDUs). The first PDU session utilizes SSC3 mode. At point 520, the remote WTRU receives a link release request message indicating the availability of a second PDU session via the link to the relay WTRU. The indication of the availability of the second PDU session can take the form of a cause value. The remote WTRU can respond with a link release accept message. During this phase, the connection with the relay WTRU may be lost.

[0106] Both the remote WTRU and the relay WTRU can execute a link establishment procedure to establish a second link (i.e., a new link), which includes sending a message from the remote WTRU to the relay WTRU, as shown at 530. The relay WTRU may be the same relay WTRU that sent the link release request message received at 520. The connection with the relay WTRU can then be re-established. A new IP address associated with the second PDU session can be generated before or during the link establishment procedure. Once the second link is established, the remote WTRU can communicate by sending or receiving PDUs on the second link to the relay WTRU, which include a new IP address associated with the second PDU session that also utilizes SSC3 mode, as shown at 540.

[0107] Figure 6 This is a flowchart illustrating a method performed by a relay WTRU to provide an IP prefix to a remote WTRU. (For example...) Figure 6 As shown, at 610, the remote WTRU can send or receive PDUs via the link to the remote WTRU and can communicate with the network (i.e., the CN or a CN entity). The PDU includes a first IP address associated with the PDU session utilizing SSC3 mode. At 620, the WTRU receives a message from the network for modifying the PDU session, which includes a reason value indicating a request for reactivation. At 630, the WTRU sends a message to the network for modifying the first PDU session utilizing SSC3 mode. As shown at 640, the WTRU receives new IP prefix information from the network (e.g., within a message received during the PDU session modification procedure). As shown at 650, the WTRU sends an announcement including the new IP prefix information to the remote WTRU via the existing link. At 660, after the remote WTRU has generated a new IP address based on the provided IP prefix information, the relay WTRU and the remote WTRU communicate the PDU including the new IP address associated with the modified PDU session.

[0108] Figure 7 This is a flowchart illustrating a method executed by a remote WTRU, which uses a connect-then-disconnect procedure to establish a link. Figure 7 As shown at 710, the remote WTRU can communicate with the relay WTRU (i.e., send or receive PDUs) via the first link. The PDU, including the first IP address, is associated with a first PDU session utilizing SSC3 mode and a first PDU session anchor. At 720, the remote WTRU receives a link indication message from the relay WTRU, indicating that a second link to the relay WTRU should be established. This triggers the remote WTRU to perform link establishment with the same relay WTRU, and as shown at 730, the remote WTRU sends a message to establish the second link before the first link to the relay WTRU is released or expires. As shown at 740, the remote WTRU communicates with the relay WTRU (i.e., sends or receives PDUs) on the second link.

[0109] Although features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in combination with other features and elements. Furthermore, the methods described herein can 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 (transmitted via a wired or wireless connection) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor storage devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROMs and digital multifunction discs (DVDs)). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU) configured to function as a relay, the WTRU comprising: processor; as well as transceiver; The processor and the transceiver are configured to send or receive a first protocol data unit (PDU) via a PC5 unicast link to a remote WTRU, the first protocol data unit (PDU) including a first Internet Protocol (IP) address associated with a PDU session utilizing Session Service and Continuity Mode 3 (SSC3). The processor and the transceiver are configured to receive from a network node a message for modifying the PDU session, the message including a reason value indicating a request for reactivation; The processor and the transceiver are configured to send messages for modifying PDU sessions utilizing SSC3; The processor and the transceiver are configured to receive new IP prefix information from the network node; The processor and the transceiver are configured to send a message including the new IP prefix information to the remote WTRU via the PC5 unicast link; as well as The processor and the transceiver are configured to send or receive a second PDU via the PC5 unicast link to the remote WTRU, the second PDU including a second IP address generated for the PDU session based on the new IP prefix information.

2. The relay WTRU according to claim 1, wherein, The message sent to the remote WTRU that includes the new IP prefix information is an announcement message.

3. The relay WTRU of claim 1, wherein the processor and the transceiver are configured to send a link indication message indicating the availability of new IP prefix information via a link to the remote WTRU.

4. The relay WTRU of claim 3, wherein the processor and the transceiver are configured to receive a message requesting new IP prefix information via a link to the remote WTRU.

5. The relay WTRU according to claim 4, wherein, The sending of the message including the new IP prefix information is in response to a message requesting the IP prefix information.

6. The relay WTRU according to claim 1, wherein, The PDU session is associated with a first PDU session anchor and a second PDU session anchor.

7. The remote WTRU of claim 5, wherein, The message requesting new IP prefix information is a Link Identifier Update (LIU) Request message, and the message including the new IP prefix information is a LIU Response message.

8. The relay WTRU according to claim 7, wherein, The processor and the transceiver are configured to receive an acknowledgment message in response to a sent message that includes the new IP prefix information.

9. A method performed by a wireless transmit / receive unit (WTRU), the WTRU being configured to act as a relay, the method comprising: Sending or receiving a first Protocol Data Unit (PDU) via a PC5 unicast link to a remote WTRU, the first Protocol Data Unit (PDU) includes a first Internet Protocol (IP) address associated with a PDU session utilizing Session Service and Session Continuity Mode 3 (SSC3). Receive a message from a network node for modifying the PDU session, the message including a reason value indicating a request for reactivation; Send a message to modify the PDU session utilizing SSC3; Receive new IP prefix information from the network node; A message including the new IP prefix information is sent to the remote WTRU via the PC5 unicast link; as well as A second PDU is sent or received via the PC5 unicast link to the remote WTRU, the PDU including a second IP address generated for the modified PDU session based on the new IP prefix information.

10. The method according to claim 9, wherein, The message sent to the remote WTRU that includes the new IP prefix information is an announcement message.

11. The method of claim 9, further comprising sending a link indication message indicating the availability of new IP prefix information via a PC5 unicast link to the remote WTRU.

12. The method of claim 11, further comprising receiving a message requesting new IP prefix information via a PC5 unicast link to the remote WTRU.

13. The method according to claim 12, wherein, The sending of the message including the new IP prefix information is in response to a message requesting the new IP prefix information.

14. The method according to claim 9, wherein, The PDU session is associated with a first PDU session anchor and a second PDU session anchor.

15. The method according to claim 9, wherein, The message requesting new IP prefix information is a Link Identifier Update (LIU) Request message, and the message including the new IP prefix information is a LIU Response message.

16. The method of claim 15, further comprising receiving an acknowledgment message in response to a sent message including the new IP prefix information.

Images