End-to-end link management via WTRU-to-WTRU relays
The end-to-end link management system of WTRU to WTRU relay solves the problem of inefficient link management between WTRUs in the existing technology, achieves the satisfaction of end-to-end communication delay budget and reasonable allocation of resources, and improves system performance.
Patent Information
- Application Number
- CN202380094543.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-01-05
- Filing Date
- 2023-12-29
- Publication Date
- 2025-10-03
AI Technical Summary
In existing wireless communication systems, end-to-end link management suffers from inefficiency and irrational resource allocation. In particular, in link management between WTRUs, it is difficult to effectively meet the end-to-end packet delay budget requirement.
Through the end-to-end link management system of WTRU to WTRU relay, the device can receive and send link modification requests, manage the link status between WTRUs, ensure that the link delay budget meets the requirements, and optimize link utilization through keep-alive messages and link release indications to achieve effective management of end-to-end connections.
The link management efficiency between WTRUs is improved, the delay budget of end-to-end communication is ensured to meet the requirements, resource allocation is optimized, and the overall performance of the system is improved.
Smart Images

Figure CN120752958A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of Provisional U.S. Patent Application No. 63 / 437,222, filed January 5, 2023, the disclosure of which is incorporated herein by reference in its entirety. Background Art
[0003] Mobile communications using wireless communications continue to evolve. The fifth generation may be referred to as 5G. The previous (legacy) generation of mobile communications may be, for example, the fourth generation (4G) Long Term Evolution (LTE). Summary of the Invention
[0004] Systems, methods, and instrumentalities related to end-to-end link management via a wireless transmit / receive unit (WTRU) to a WTRU relay are described herein. A device may include a processor configured to perform one or more actions. The device may receive a first message from a first WTRU, wherein the first message includes a link modification request. The device may send a second message to a second WTRU, wherein the second message includes a first parameter associated with the link modification request. The device may receive a third message from the second WTRU, wherein the third message indicates acceptance of the first parameter. The device may send a fourth message to the first WTRU, wherein the fourth message indicates a second parameter associated with the link modification request.
[0005] The link modification request includes an end-to-end packet delay budget. The link modification request may be associated with a previously established connection. The previously established connection may be between a first WTRU and a second WTRU via the device. The first parameter may be a packet delay budget for the link between the device and the second WTRU. The second parameter may be a packet delay budget for the link between the device and the first WTRU. The device may determine the first parameter and the second parameter. The sum of the first parameter and the second parameter may satisfy the end-to-end packet delay budget. The device may be a relay WTRU.
[0006] A device may receive a first message from a first WTRU. The device may determine an availability status of a second WTRU. The device may send an availability message to the first WTRU indicating whether the second WTRU is available. The first message may indicate at least one of: that the first WTRU is available to communicate with the second WTRU via the device; or a request to confirm the availability of the second WTRU via the device. The device may determine that a link between the device and the second WTRU has been released. Based on the determination that the link between the device and the second WTRU has been released, the availability message may indicate that the second WTRU is unavailable.
[0007] The first message may be a keep-alive message, and the availability message may be a keep-alive confirmation message. The indication that the second WTRU is unavailable may include an error code included in the keep-alive confirmation message. Determining the availability status of the second WTRU may involve the device sending a second message. The second message may be a keep-alive message sent to the second WTRU. The device may receive a third message from the second WTRU. The third message may indicate that the second WTRU is available. Based on the third message, the availability message may indicate that the second WTRU is available.
[0008] A device (e.g., a relay WTRU) may communicate with a first wireless transmit / receive unit (WTRU) via a link. The device may receive (e.g., from the first WTRU) an indication to release the link. The indication to release the link may include an end-to-end identifier for communication between the first WTRU and the second WTRU. The device may determine that the second WTRU has an end-to-end connection with the first WTRU via the device. For example, the device may determine the end-to-end connection based on a list of WTRUs that have an end-to-end connection with the first WTRU via the device including the second WTRU. The list of WTRUs that have an end-to-end connection with the first WTRU via the device may be managed by the device and / or received from the first WTRU. The device may send an indication to the second WTRU that the first WTRU is no longer available via the device. The indication to the second WTRU may indicate that context data associated with the first WTRU is deleted from the second WTRU.
[0009] The end-to-end connection may comprise IP-based communications and / or Ethernet-based communications.The link may be a PC5 connection.
[0010] The device may communicate with a third WTRU via a second link. The device may receive, for example, a link modification request from the third WTRU, the link modification request including an end-to-end packet delay budget. The link modification request may be associated with a previously established connection, and the previously established connection may be between the third WTRU and a second WTRU via the device. A third link between the device and the second WTRU may be determined (e.g., by the device) such that a sum of the packet delay budget of the second link and the packet delay budget of the third link satisfies the end-to-end packet delay budget. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Figure 1A is a system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.
[0012] Figure 1B is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example wireless transmit / receive unit (WTRU) for use within a communication system is shown in FIG.
[0013] Figure 1C is a diagram illustrating that according to an embodiment, Figure 1A A system diagram of an example radio access network (RAN) and an example core network (CN) used within the communication system illustrated in FIG.
[0014] Figure 1D is a diagram illustrating that according to an embodiment, Figure 1A System diagram of a further example RAN and a further example CN for use within the communication system illustrated in FIG.
[0015] Figure 2 Proximity Services (ProSe) (eg, 5th Generation (5G) ProSe) discovery integrated into PC5 unicast link establishment is illustrated.
[0016] Figure 3 The keep alive feature with availability information of other WTRUs is illustrated.
[0017] Figure 4 The diagram illustrates the end-to-end keep-alive feature.
[0018] Figure 5 Illustrated is the PC5 unicast keep-alive feature with end-to-end status indication.
[0019] Figure 6 The figure shows the PC5 link release indication.
[0020] Figure 7 The link release feature of the WTRU list is illustrated.
[0021] Figure 8 Illustrated is the end-to-end link modification feature. DETAILED DESCRIPTION
[0022] Figure 1A FIG1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through 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 multi-carrier (FBMC), and the like.
[0023] like Figure 1A As shown in FIG, 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, the Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a "station" and / or "STA") may be configured to transmit and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of an industrial and / or automated process chain), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.
[0024] The communication system 100 may also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b may be any type of device 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 the CN 106 / 115, the Internet 110, and / or other networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a gNB, an NRNodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.
[0025] 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), relay nodes, 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 cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, one 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 a desired spatial direction.
[0026] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).
[0027] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may utilize Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117. WCDMA may include communication protocols such as High Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed Downlink (DL) Packet Access (HSDPA) and / or High Speed UL Packet Access (HSUPA).
[0028] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 116 using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-APro).
[0029] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology, such as NR radio access, that may establish the air interface 116 using New Radio (NR).
[0030] 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 both LTE radio access and NR radio access, for example, using dual connectivity (DC) principles. Thus, the air interface utilized by the WTRUs 102a, 102b, 102c may 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).
[0031] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi)), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[0032] Figure 1AThe base station 114b in the may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a road, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or a femtocell. Figure 1A As shown in FIG, base station 114b may have a direct connection to the Internet 110. Thus, base station 114b may not need to access the Internet 110 via CN 106 / 115.
[0033] The RAN 104 / 113 may be in communication with the CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have different quality of service (QoS) requirements, such as different throughput requirements, delay requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, video distribution, etc., and / or perform advanced security functions, such as user authentication. Although not described in Figure 1A Although not shown in the figures, it will be appreciated that the RAN 104 / 113 and / or the CN 106 / 115 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 / 113 or a different RAT. For example, in addition to being connected to the RAN 104 / 113, which may utilize NR radio technology, the CN 106 / 115 may also be in communication with another RAN (not shown) that employs GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.
[0034] The CN 106 / 115 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and / or the Internet Protocol (IP) from the TCP / IP internet protocol suite. The networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 / 113 or a different RAT.
[0035] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). Figure 1A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.
[0036] Figure 1B is a system diagram illustrating an example WTRU 102. Figure 1B As shown in FIG, the WTRU 102 may include, among other things, a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.
[0037] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.
[0038] The transmit / receive element 122 can be configured to transmit signals to a base station (e.g., base station 114a) or receive signals from a base station (e.g., base station 114a) via the 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 an emitter / 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 will be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.
[0039] Although the transmit / receive element 122 Figure 1B Although depicted as a single element in FIG. 1 , the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 116.
[0040] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to, for example, enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.
[0041] 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 from the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. 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, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).
[0042] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel-metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
[0043] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.
[0044] The processor 118 may be further coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, Modules, frequency modulation (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, and the like. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.
[0045] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference via hardware (e.g., a choke) or via signal processing performed by a processor (e.g., a separate processor (not shown) or via the processor 118). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all signals (e.g., associated with specific subframes for both UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.
[0046] Figure 1C 1 is a system diagram illustrating the RAN 104 and the CN 106 in accordance with an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.
[0047] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a.
[0048] Each of the eNode-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, and the like. Figure 1C As shown in FIG, eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.
[0049] Figure 1C The CN 106 shown in FIG may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as part of the CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0050] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.
[0051] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via an S1 interface. The SGW 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.
[0052] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.
[0053] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.
[0054] Even though the WTRU Figures 1A-1D Although described as a wireless terminal, it is contemplated that in certain representative embodiments, such a terminal may (eg, temporarily or permanently) employ a wired communication interface with a communication network.
[0055] In a representative embodiment, the other network 112 may be a WLAN.
[0056] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or an interface with a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating from outside the BSS and destined for a STA may reach the AP and be delivered to the STA. Traffic originating from a STA destined for a destination outside the BSS may be sent to the AP for delivery to the destination. Traffic between STAs within a BSS may be sent through the AP, for example, where a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within a BSS may be considered and / or referred to as point-to-point traffic. Point-to-point traffic may be sent between a source and destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs (eg, all STAs) within or using the IBSS may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad-hoc" communication mode.
[0057] When using 802.11ac infrastructure operation mode or a similar operation mode, the AP can transmit beacons on a fixed channel (such as a primary channel). The primary channel can be a fixed width (e.g., a 20 MHz wide bandwidth) or a width dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, for example, carrier sense multiple access with collision avoidance (CSMA / CA) can be implemented in an 802.11 system. For CSMA / CA, STAs (e.g., each STA) including the AP can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a specific STA, the specific STA can back off. One STA (e.g., only one station) can transmit at any given time in a given BSS.
[0058] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a primary 20 MHz channel combined with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.
[0059] Very high throughput (VHT) STAs can support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining 8 consecutive 20MHz channels, or by combining two non-contiguous 80MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, the data can pass through a segment parser that can separate the data into two streams. Each stream can be separably subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the media access control (MAC).
[0060] 802.11af and 802.11ah support operating modes below 1 GHz. The channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah relative to those used in 802.11n and 802.11ac. 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 macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., for maintaining very long battery life).
[0061] 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 primary channels. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by a STA (that supports the minimum bandwidth operating mode) from among all STAs operating in the BSS. In the example of 802.11ah, for a STA (e.g., an MTC-type device) that supports (e.g., only supports) 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 operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because a STA (that only supports 1 MHz operating mode) is transmitting to the AP, the entire available frequency band can be considered busy even if most of the frequency band remains idle and may be available.
[0062] 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. Depending on the country code, the total bandwidth available for 802.11ah ranges from 6 MHz to 26 MHz.
[0063] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 according to an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.
[0064] The RAN 113 may include gNBs 180a, 180b, and 180c, though it will be appreciated that the RAN 113 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, and 180c may implement MIMO technology. For example, the gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, and 180c. Thus, the gNB 180a may, for example, use multiple antennas to transmit wireless signals to and / or receive wireless signals from the WTRU 102a. In an embodiment, the gNBs 180a, 180b, and 180c may implement carrier aggregation techniques. For example, the gNB 180a may transmit multiple component carriers (not shown) to the WTRU 102a. 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, and 180c may implement coordinated multi-point (CoMP) techniques. For example, the WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).
[0065] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with scalable numerologies. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of varying or scalable lengths (e.g., containing varying numbers of OFDM symbols and / or varying absolute time lengths).
[0066] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNode-Bs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchor points. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect to the gNBs 180a, 180b, 180c while also communicating / connecting to another RAN, such as the eNode-Bs 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-Bs 160a, 160b, 160c may serve as mobility anchors for the WTRUs 102a, 102b, 102c and the gNBs 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.
[0067] Each of the gNBs 180a, 180b, 180c 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 UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, and the like. Figure 1D As shown in , gNBs 180a, 180b, and 180c can communicate with each other via the Xn interface.
[0068] Figure 1DThe CN 115 shown in FIG may include at least one AMF 182 a, 182 b, at least one UPF 184 a, 184 b, at least one session management function (SMF) 183 a, 183 b, and possibly data networks (DNs) 185 a, 185 b. While each of the aforementioned elements is depicted as part of the CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.
[0069] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, managing registration areas, terminating NAS signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b to customize CN support for the WTRUs 102a, 102b, 102c based on the type of services utilized by the WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for machine type communication (MTC) access, and / or the like. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) employing other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.
[0070] The SMF 183a, 183b may connect to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also connect to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, and the like. The PDU session type may be IP-based, non-IP-based, Ethernet-based, and the like.
[0071] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, providing mobility anchoring, and the like.
[0072] The CN 115 may facilitate communications with other networks. For example, the CN 115 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the CN 115 and the PSTN 108. Additionally, the CN 115 may provide the WTRUs 102a, 102b, 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, the WTRUs 102a, 102b, 102c may connect to a local data network (DN) 185a, 185b through the UPFs 184a, 184b via the N3 interface to the UPFs 184a, 184b and the N6 interface between the UPFs 184a, 184b and the DNs 185a, 185b.
[0073] Given that Figures 1A-1D as well as Figures 1A-1D
[0015] As described herein, one or more or all of the functions described herein with reference to one or more of the following may be performed by one or more emulated devices (not shown): the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MMEs 162, SGWs 164, PGWs 166, gNBs 180a-c, AMFs 182a-b, UPFs 184a-b, SMFs 183a-b, DNs 185a-b, and / or any other device(s) described herein. An emulated device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulated device may be used to test other devices and / or simulate network and / or WTRU functions.
[0074] The emulation device 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 or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network in order to test other devices within the communication network. One or more emulation devices can perform one or more functions or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. The emulation device can be directly coupled to another device for testing and / or can use over-the-air wireless communication to perform testing purposes.
[0075] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test lab and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which can include one or more antennas) can be used by the simulation device to transmit and / or receive data.
[0076] References to a timer herein may refer to the determination of a time or a time period. References to the expiration of a timer herein may refer to the determination that a time has arrived or a time period has expired. References to a timer herein may refer to a time, a time period, tracking a time, tracking a time period, etc. References to the expiration of a timer herein may refer to the determination that a time has arrived or a time period has expired.
[0077] Provided herein are features (one or more) associated with end-to-end (e.g., end WTRU to end WTRU) link management (e.g., via a relay). The keepalive feature may allow an end WTRU to verify that its peer end WTRU is still reachable over an existing PC5 link (e.g., when the PC5 link is established via a level 3 (L3) WTRU to WTRU relay).
[0078] Provided herein are features (one or more) associated with 5G proximity-based services, which may be referred to as Proximity Services (ProSe). ProSe is a service that may be provided by a 5th Generation System (5GS) based on WTRUs being in proximity to each other. ProSe (e.g., 5G ProSe) may have functionality such as 5G ProSe direct discovery, 5G ProSe direct communication, 5G ProSe WTRU-to-network relay, 5G ProSe WTRU-to-WTRU relay, and / or the like.
[0079] (One or more) features associated with unicast link management are provided herein. In 5G ProSe, link management may be performed (e.g., after a unicast link is established between two WTRUs). For example, a layer-2 (L2) link release over a PC5 reference point may be performed. The WTRU may release the L2 link by exchanging disconnect request and disconnect response messages. Upon releasing the L2 link, the WTRU may delete context data (e.g., all context data) associated with the L2 link. The ProSe layer of the WTRU (e.g., each WTRU) may notify the access stratum (AS) layer that the unicast link has been released. A PC5 link identifier may be used to indicate a released unicast link.
[0080] L2 link modification may be performed for a unicast link. To add new PC5 Quality of Service (QoS) flows, modify existing QoS flows, or delete existing QoS flows in an existing PC5 unicast link, the WTRU may exchange Link Modification Request and Link Modification Response messages (e.g., with the requested action, associated QoS information, and / or PC5 QoS rules). The QoS information may include information about the PC5 QoS flows. The QoS information may include (e.g., for each PC5 QoS flow) a PC5 QoS Flow Identifier (PFI), corresponding PC5 QoS parameters (e.g., PC5 5G QoS Identifier (PQI) and / or other parameters (e.g., Maximum Flow Bit Rate (MFBR), Guaranteed Flow Bit Rate (GFBR), etc.), and / or associated ProSe identifiers). The ProSe layer (e.g., the ProSe layer of each WTRU) may provide information about the unicast link modification to the AS layer. The information about the unicast link modification may enable the AS layer to update context (e.g., context data) related to the modified unicast link.
[0081] L2 link maintenance over the PC5 reference point may be performed. The WTRU may exchange keepalive and keepalive acknowledgement (Ack) messages to detect whether a particular PC5 unicast link is still valid. The keepalive feature may be initiated based on a trigger, for example, from the AS layer or an internal timer. The WTRU may reduce (e.g., minimize) keepalive signaling (e.g., by canceling the keepalive feature if data is successfully received on the PC5 unicast link). The WTRU (e.g., the WTRU that initiated the keepalive feature) may determine a subsequent action (e.g., proceed with an implicit L2 link release) based on the result of the signaling.
[0082]
[0014] Feature(s) associated with WTRU-to-WTRU relay are provided herein. 5G ProSe may be associated with features such as, for example, 5G ProSe direct discovery, 5G ProSe direct communication, 5G ProSe WTRU-to-network relay, and 5G ProSe WTRU-to-WTRU relay.
[0083] 5G ProSe WTRU-to-WTRU relay may enable indirect communication between two WTRUs (e.g., 5G ProSe terminal WTRUs). For 5G ProSe WTRU-to-WTRU relay, 5G ProSe WTRU-to-WTRU relay discovery and / or 5G ProSe communication via the WTRU-to-WTRU relay may be performed.
[0084] For 5G ProSe WTRU-to-WTRU relay discovery, both Model A and Model B discovery may be supported (e.g., both may be supported). Model A may use (e.g., a single) discovery protocol message (e.g., an advertisement). Model B may use two discovery protocol messages (e.g., a request and a response). Discovery integrated into the PC5 unicast link establishment feature may be supported.
[0085] 5G ProSe communication(s) via WTRU-to-WTRU relays may be performed via a 5G ProSe L2 WTRU-to-WTRU relay or a 5G ProSe L3 WTRU-to-WTRU relay. For L2 WTRU-to-WTRU relays and L3 WTRU-to-WTRU relays, 5G ProSe communication establishment with a discovery feature may be performed. Discovery may be performed integrated into the PC5 unicast link establishment feature.
[0086] Utilizing an L2 WTRU-to-WTRU relay, an end-to-end PC5 link may be established between terminating WTRUs via the relay. PC5-S messages may be exchanged (eg, then exchanged) between terminating WTRUs.
[0087] Using an L3 WTRU-to-WTRU relay, a terminating WTRU (e.g., each terminating WTRU) may establish a PC5 link with the relay. The relay may forward messages toward the terminating WTRU. PC5-S messages may be exchanged between the terminating WTRU and the relay.
[0088] Feature(s) associated with discovery integrated into PC5 unicast link establishment are provided herein.
[0089] Discovery integrated into PC5 unicast link establishment (sometimes also referred to as integrated discovery) may enhance unicast connection establishment via WTRU-to-WTRU relay (e.g., by omitting the 5G ProSe WTRU-to-WTRU relay discovery action).
[0090] For discovery integrated into PC5 link establishment, the WTRU may indicate that the WTRU allows WTRU-to-WTRU relaying to participate in a direct communication request to another WTRU. For example, the WTRU may include a relay_indication in a broadcast direct communication request message.
[0091] Figure 2 An example 5G ProSe discovery integrated into the PC5 unicast link establishment feature is illustrated. If a WTRU-to-WTRU relay receives a direct communication request including a relay_indication, the WTRU-to-WTRU relay may decide to participate and broadcast a direct communication request message (e.g., without a relay_indication) in the vicinity of the relay.
[0092] If the target WTRU (e.g. Figure 2 If WTRU-2 receives a direct communication request from one or more WTRU-to-WTRU relays, WTRU-2 may select a WTRU-to-WTRU relay to which WTRU-2 will respond. WTRU-2 may respond to the selected WTRU-to-WTRU relay (e.g., Figure 2 The relay in -1) sends a direct communication acceptance message to reply.
[0093] Relay-1 may respond with a direct communication accept message to WTRU-1.
[0094] Security establishment and IP address allocation may be performed (eg, between Relay-1 and WTRU-1, and between Relay-1 and WTRU-2).
[0095] If a source WTRU communicates with multiple target WTRUs, the PC5 link between the source WTRU and / or the WTRU-to-WTRU relay may be shared for the multiple target WTRUs (e.g., per relay service code (RSC)). A PC5 link may be established (e.g., separately established between) the WTRU-to-WTRU relay and the target WTRUs (e.g., per RSC). For the shared PC5 link, L2 link modification may be used. A shared PC5 link may be used for a target WTRU communicating with multiple source WTRUs.
[0096]
[0066] Feature(s) associated with managing a link between two terminal WTRUs via a WTRU-to-WTRU relay are provided herein.
[0097] For 5G ProSe, unicast link management may be used for (e.g., only for) direct unicast links between WTRUs (e.g., two WTRUs). For WTRUs (e.g., two WTRUs) using indirect links via a WTRU-to-WTRU relay, link management may not be defined.
[0098] Existing link management may not be applicable to links via an L3 WTRU-to-WTRU relay because current link management messages sent from a terminating WTRU will terminate at the WTRU-to-WTRU relay.
[0099] In the absence of end-to-end link management, a terminal WTRU may not be able to determine whether to release or maintain an E2E connection with another terminal WTRU. For example, if the PC5 link between a terminal WTRU and a WTRU-to-WTRU relay is released due to mobility, the E2E connection between the terminal WTRU and the other terminal WTRU via the WTRU-to-WTRU relay may not be available for traffic exchange between the two terminal WTRUs. The other terminal WTRU may be informed of the release of the PC5 link between the terminal WTRU and the WTRU-to-WTRU relay. If the other terminal WTRU is not informed of the release of the PC5 link, the other terminal WTRU may waste (one or more) resources and the quality of service may be degraded. E2E link modifications may be defined to add or remove ProSe services or (one or more) QoS flows of the E2E connection via the WTRU-to-WTRU relay.
[0100] Provided herein are features (one or more) associated with a WTRU performing link management for an end-to-end connection between WTRUs (e.g., two WTRUs) via a WTRU-to-WTRU relay. If a PC5 link is established via a WTRU-to-WTRU relay (e.g., an L3 WTRU-to-WTRU relay), a keep-alive feature may be modified to allow a terminating WTRU to verify that its peer terminating WTRU is reachable (e.g., is still reachable) over the existing PC5 link. PC5 signaling messages may be used (e.g., in conjunction with the keep-alive feature, or as a standalone feature) to notify a terminating WTRU that its peer terminating WTRU is no longer reachable.
[0101] Provided herein are (one or more) features associated with end-to-end link management via WTRU-to-WTRU relay intervention. If a PC5 connection is established between WTRU-1 and the relay and between WTRU-2 and the relay (e.g., an end-to-end connection between WTRU-1 and WTRU-2 via the relay), WTRU-1, WTRU-2, and the relay may perform (one or more) keepalive actions (e.g., a keepalive procedure). The (one or more) keepalive actions may be used to check the availability of the link between WTRU-1 and the relay and the availability of the link between WTRU-2 and the relay. The relay may be aware of the connection between WTRU-1 and other WTRUs (e.g., WTRU-2, WTRU-3, etc.). For example, the relay may maintain a list of WTRUs that have an end-to-end connection with WTRU-1 via the relay. For example, the relay may receive a list of WTRUs that have an end-to-end connection with WTRU-1 via the relay (e.g., from WTRU-1). The end-to-end connection between the WTRUs may include IP-based communication or Ethernet-based communication.
[0102] If WTRU-1 sends a KeepAlive message (e.g., to check the availability of a PC5 connection with the relay), the relay may send a KeepAliveAck message in response. The relay may send (e.g., including) an indication of whether a PC5 connection with other WTRUs is available (e.g., a list of WTRUs available via the relay via a PC5 connection). For example, based on KeepAlive messages and / or other messages exchanged between the relay and WTRU-2 and / or WTRU-3, the relay may determine and send (e.g., including) the availability status of WTRU-2 and / or WTRU-3 (e.g., which have a persistent connection with WTRU-1 via the relay). The determination of the availability of the PC5 connection with other WTRUs may be based on the results of communication(s) between the relay and the other WTRU or keepalive action(s) between the relay and the other WTRU (e.g., as described herein). WTRU-1 may (e.g., then) determine (e.g., based on the sent indication) whether WTRU-1's peer WTRUs are reachable or unreachable via the relay (e.g., whether one or more of its peer WTRUs are reachable or unreachable). For example, following an indication from WTRU-2 to release a link with the relay, the relay may determine that WTRU-2 may not be reachable via the relay. The relay may, based on the determination that WTRU-2 is no longer reachable, send an indication to the other WTRU(s) (e.g., WTRU-1) (e.g., that WTRU-2 is no longer available via the relay).
[0103] Figure 3Example keepalive action(s) (e.g., keepalive procedures) with availability information of other WTRUs (e.g., example keepalive features associated with WTRU-1 and a relay) are illustrated. The relay may include (e.g., maintain) a list of available WTRUs, for example, in the message(s) sent during the keepalive action(s).
[0104] At 0, WTRU-1 and other WTRUs (e.g., Figure 3 WTRU-2, etc. in WTRU-1 may communicate via the relay. A WTRU (eg, each WTRU) may have a PC5 connection established with the relay.
[0105] At 1, WTRU-1 may send a KeepAlive message to the relay to check the availability of the PC5 connection between WTRU-1 and the relay (e.g., the availability of the PC5 connection between WTRU-1 and the relay to communicate with other WTRUs, e.g., as described herein). If the relay does not receive a KeepAlive message from a WTRU (e.g., such as WTRU-1) (e.g., within a period of time or within a threshold time, etc.), the relay may determine that the link between the relay and WTRU-1 is unavailable (e.g., WTRU-1 is out of coverage with respect to the relay).
[0106] At 2, the relay may respond by sending a KeepAliveAck to confirm the availability of the PC5 connection between WTRU-1 and the relay. The relay may send (e.g., include) a list of available WTRUs. The list of available WTRUs may include WTRUs that have an available PC5 connection with the relay (e.g., based on ongoing connection and keepalive actions) and are communicating with WTRU-1 in the example. The relay may send (e.g., include) a list of unavailable WTRUs. The list of unavailable WTRUs may include WTRUs that recently released their PC5 connection with the relay or became unavailable for connection with the relay. If WTRU-1 does not receive a KeepAliveAck (e.g., within a threshold amount of time), WTRU-1 may determine that the PC5 connection with the relay is unavailable (e.g., no longer available).
[0107] If WTRU-1 determines (e.g., after WTRU-1 receives a KeepAliveAck message) that a terminal WTRU (such as WTRU-2) is not available (e.g., is no longer available), WTRU-1 may attempt to communicate with the terminal WTRU via another relay. If WTRU-1 determines that no communication with the terminal WTRU is available (e.g., is no longer available) via the relay, WTRU-1 may release its PC5 link with the relay.
[0108] If a WTRU (e.g., two WTRUs, such as WTRU-1 and WTRU-2) communicate via a relay, the WTRUs may perform (one or more) keepalive actions through the relay to check the availability of an end-to-end connection between the WTRUs (e.g., via the relay), such as the availability of an end-to-end connection between WTRU-1 (e.g., source) and WTRU-2 (e.g., target). In this case, target WTRU (e.g., WTRU-2) information (e.g., user information, WTRU-2 ID, etc.) may be specified in a keepalive message sent by WTRU-1 to the relay. The target WTRU information may allow the relay to detect that a KeepAlive message should be sent to WTRU-2. The KeepAlive message from the relay to WTRU-2 may include source WTRU (e.g., WTRU-1) information, target WTRU (e.g., WTRU-2) information, and / or relay information.
[0109] WTRU-1 and / or WTRU-2 may track a first time of connection between WTRU-1 and WTRU-2 (e.g., using a first timer, timer1). Timer1 may be started or restarted upon completion of a message exchange (e.g., any message exchange) between WTRU-1 and WTRU-2. If no communication occurs before timer1 expires, WTRU-1 and / or WTRU-2 may send (one or more) KeepAlive messages to WTRU-2 and / or WTRU-1, respectively, via a relay to check availability.
[0110] WTRU-1 and / or WTRU-2 may track a second time for the connection between WTRU-1 and WTRU-2 (e.g., using a second timer, timer2). Timer2 may be started or restarted after a message (e.g., any message, including a KeepAlive message) is sent. If no response is received before timer2 expires, or no traffic exchange occurs in the connection, WTRU-1 and / or WTRU-2 may determine that the connection between WTRU-1 and WTRU-2 is unavailable. In this case, WTRU-1 or WTRU-2 may drop the connection with the relay, for example, if the connection with the relay is not being used to communicate with other terminal WTRUs. WTRU-1 and / or WTRU-2 may attempt to connect to each other (e.g., establish an end-to-end connection) through other relays.
[0111] If the relay does not receive a KeepAliveAck from WTRU-2, or the relay identifies (or already knows) that the PC5 link between the relay and WTRU-2 is unavailable, the relay may send to WTRU-1 (e.g., send a response to a KeepAlive message) an indication that WTRU-2 is unavailable, e.g., a KeepAliveAck with an error code indicating that WTRU-2 is no longer available via the relay.
[0112] Figure 4 Example end-to-end keepalive action(s) (eg, keepalive procedures) are illustrated.
[0113] like Figure 4 As shown in FIG1 , WTRU-1 may send a KeepAlive message to the relay. The KeepAlive message may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1). The KeepAlive message may include an ID and / or user information associated with the relay.
[0114] At 2, the relay may recognize that the KeepAlive message is for end-to-end keepalive (e.g., keepalive between WTRU-1 and WTRU-2 via the relay). The relay may send the KeepAlive message to WTRU-2. The KeepAlive message may include the respective IDs and / or respective user information associated with WTRU-1 and WTRU-2 (e.g., the ID associated with WTRU-1, the ID associated with WTRU-2, the user information associated with WTRU-1, and / or the user information associated with WTRU-1). The KeepAlive message may include the ID or user information associated with the relay.
[0115] At step 3, if WTRU-2 receives the KeepAlive message, WTRU-2 may respond by sending a KeepAliveAck message. The KeepAliveAck message may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1). The KeepAliveAck message may include an ID and / or user information associated with the relay.
[0116] WTRU-2 may include information (e.g., further information) in the KeepAliveAck message. For example, the KeepAliveAck message may include future state expectations and / or indications / requests, such as an indication and / or a request (e.g., based on an indicated timer value) that WTRU-2 will be unavailable in the near future, to resynchronize the end-to-end connection, update the end-to-end security association, etc.
[0117] At 4, based on the KeepAliveAck message received from WTRU-2, the relay may send a KeepAliveAck message to WTRU-1. The KeepAliveAck message may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1). The KeepAliveAck message may include an ID and / or user information associated with the relay. If WTRU-2 includes future state expectations and / or indications / requests as described herein, the relay may include this information in the KeepAliveAck message sent to WTRU-1 at 4. The KeepAliveAck message may trigger WTRU-1 to perform one or more actions, such as security association establishment or modification, PC5 connection establishment, link modification, and / or the like.
[0118] If the relay does not receive a KeepAliveAck message from WTRU-2 (e.g., within a certain period of time), for example, in response to the KeepAlive message at 2, the relay may send to WTRU-1 (e.g., send a response to the KeepAlive message) an indication that WTRU-2 is unavailable, for example, a KeepAliveAck message with an error code indicating that WTRU-2 is unavailable via the relay, or that WTRU-2 did not respond to the KeepAlive message from WTRU-1 with a KeepAliveAck message.
[0119] After the relay receives the KeepAlive message (e.g., at 1), if the relay knows (e.g., already knows) that WTRU-2 is not available to communicate with the relay (e.g., is no longer available to communicate with the relay), the relay may skip the actions performed at 2 and 3 and respond to WTRU-1 with an indication that WTRU-2 is not available (e.g., a KeepAliveAck message with an error code indicating that WTRU-2 is not available to communicate via the relay).
[0120] If WTRU-1 determines that WTRU-2 is not available via a relay, WTRU-1 may attempt to establish a connection with WTRU-2 via another relay.
[0121] After the PC5 link between WTRU-2 and the relay is released, if the relay receives a KeepAlive message from WTRU-1 to check the end-to-end link between WTRU-1 and WTRU-2 via the relay, the relay may respond to WTRU-1 with an indication that WTRU-2 is unavailable (e.g., a KeepAliveAck message with an error code indicating that WTRU-2 is unavailable via the relay).
[0122] Figure 5 Illustrated are example PC5 unicast keepalive action(s) (eg, procedures) with end-to-end status indication.
[0123] like Figure 5 As shown at 0 in FIG, the relay and WTRU-2 may release the PC5 connection.
[0124] At 1, WTRU-1 may send a KeepAlive message to the relay. The KeepAlive message may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1). The KeepAlive message may include an ID or user information associated with the relay.
[0125] At 2, the relay may know that WTRU-2 is unavailable (e.g., based on the release of the PC5 connection at 1). The relay may respond to WTRU-1 with an indication that WTRU-2 is unavailable (e.g., a KeepAliveAck message with an error code indicating that WTRU-2 is unavailable).
[0126] If WTRU-1 determines that WTRU-2 is not available (eg, via messaging from a relay), WTRU-1 may attempt to establish a connection with WTRU-2 via another relay.
[0127] If the PC5 link between WTRU-1 and the relay is released, the relay may notify other WTRUs (e.g., WTRUs communicating with WTRU-1 via the relay) (including WTRU-2) that WTRU-1 is unavailable via the relay (e.g., is no longer available via the relay).
[0128] Figure 6 An example PC5 link release indication (eg, a PC5 link release indication procedure) is illustrated.
[0129] like Figure 6 As shown at 1 in FIG, WTRU-1 may release the PC5 link with the relay.
[0130] At 2, the relay may send an indication to WTRU-2 that WTRU-1 is unavailable via the relay. The relay may send an indication message to the WTRUs that have an end-to-end connection via the relay (e.g., only to that WTRU). The relay may determine the WTRUs that have an end-to-end connection via the relay based on a management list of end-to-end connections between WTRUs via the relay. The management list of end-to-end connections via the relay may be updated whenever two end-to-end WTRUs establish a PC5 connection via the relay or update an existing PC5 connection for communication between two end-to-end WTRUs via the relay. The relay may send an indication message in a broadcast manner to the WTRUs that have a PC5 link with the relay (e.g., each WTRU).
[0131] The relay may update its list of target WTRUs, for example, by removing the WTRU that released its connection with the relay from a notification message used for relay discovery. If the WTRU receives an updated notification message from the relay (e.g., which does not include WTRU-1 in the list of target WTRUs), the WTRU may determine that WTRU-1 is no longer available via the relay.
[0132] If the relay locally releases the PC5 link with WTRU-1, the relay may send an indication to the WTRU that is communicating with WTRU-1. For example, the relay may send an indication if WTRU-1 does not respond to a KeepAlive message from the relay and the number of retransmissions of the KeepAlive message has reached the maximum number of retransmissions at the relay (e.g., which may be configured in the relay during its registration and authorization as a relay, by the implementation or by signaling from the 5GC).
[0133] If WTRU-1 releases the PC5 link with the relay, WTRU-1 may include a list of target WTRUs that have a connection with WTRU-1 via the relay. The relay may update the local list(s) of connected WTRUs that have a connection with WTRU-1 via the relay.
[0134] Figure 7 Example link release action(s) (eg, procedures) with a WTRU list are illustrated.
[0135] like Figure 7As shown in FIG1 , WTRU-1 may release the PC5 link with the relay (e.g., by sending a link release request). WTRU-1 may include a list of target WTRUs (with which WTRU-1 has connections via the relay) (e.g., user information of the target WTRUs, IP addresses of the target WTRUs, etc.).
[0136] At 2, if the relay receives a link release request from WTRU-1, the relay may respond with a link release response and may delete information related to WTRU-1.
[0137] At 3, the relay may send (e.g., during or after performing the actions described at 2) an indication that an end-to-end link with WTRU-1 is not available to a WTRU (e.g., each WTRU) in a list of target WTRUs (e.g., the list of target WTRUs sent at 1).
[0138] The indication that the end-to-end link with WTRU-1 is unavailable may be embedded in other signaling messages, such as a Link Release Request, Response message, and / or KeepAlive message between the target WTRU and the relay.
[0139] After receiving the indication at 3, the WTRU may attempt to establish a connection with WTRU-1 via another relay.
[0140] After establishing a connection via the relay, WTRU-1 and WTRU-2 may update the link to add or remove some ProSe services and / or QoS flows associated with some ProSe services. If WTRU-1 and WTRU-2 update the link (e.g., via the relay), WTRU-1 and WTRU-2 may exchange link modification requests and link modification responses (e.g., which may include IDs and / or user information associated with WTRU-1 and WTRU-2, e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1, and / or the ProSe services requested for modification and related QoS parameters of the ProSe services).
[0141] Figure 8
[0066] Illustrated are(s) example end-to-end link modification action(s) (eg, processes).
[0142] like Figure 8As shown in FIG1 , WTRU-1 may send a link modification request to a relay to update a ProSe service connected to WTRU-2 via the relay. The link modification request may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1) and / or ProSe services requested between WTRU-1 and WTRU-2 via the relay and requested QoS information (e.g., end-to-end (E2E) QoS information, such as packet delay budget). The link modification request may include an ID and / or user information associated with the relay.
[0143] The QoS information may include information about (one or more) PC5 QoS flows. The QoS information may include (e.g., for each PC5 QoS flow) information about the PFI, corresponding PC5 QoS parameters (e.g., PQI and (conditionally) other parameters such as MFBR / GFBR, etc.), and (optionally) associated ProSe identifiers.
[0144] At 2, if the relay receives a link modification request for updating the ProSe service and QoS flow for the connection between WTRU-1 and WTRU-2 via the relay, the relay may send a link modification request to WTRU-2. The link modification request from the relay may include the requested ProSe service (e.g., as received at 1) and relevant QoS information for the link between the relay and WTRU-2 (e.g., which may be derived based on the end-to-end QoS information received at 1). For example, the packet delay budget for the link between the relay and WTRU-2 may be determined by the relay such that the sum of the delay between WTRU-1 and the relay and the delay between WTRU-2 and the relay does not exceed the end-to-end delay budget between WTRU-1 and WTRU-2 via the relay.
[0145] At 3, if WTRU-2 receives a Link Modification Request from the relay (e.g., which may include IDs and / or user information of WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1), as well as the requested ProSe service and related QoS information), WTRU-2 may respond by sending a Link Modification Response to the relay. The Link Modification Response may include IDs and / or user information of WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1), as well as the requested ProSe service and related QoS flow (e.g., which may implicitly indicate that the Link Modification Request is accepted by the responding terminal WTRU, or may indicate an explicit acceptance).
[0146] At 4, the relay may respond to WTRU-1 with a Link Modification Response (e.g., after receiving a Link Modification Response from WTRU-2). The Link Modification Response may include IDs and / or user information associated with WTRU-1 and WTRU-2 (e.g., an ID associated with WTRU-1, an ID associated with WTRU-2, user information associated with WTRU-1, and / or user information associated with WTRU-1), as well as the requested ProSe service and related QoS information of the ProSe service for the link between WTRU-1 and the relay.
[0147] An end-to-end link identifier (e.g., for a connection between WTRU-1 and WTRU-2 via a relay) may be determined between WTRU-1 and WTRU-2, or may be determined by the relay. The end-to-end link identifier may be included in a link modification request and a link modification response. The end-to-end link identifier may be used to determine whether the link modification request and / or response is for modifying the link between WTRU-1 and WTRU-2 and the relay. In this case, based on the end-to-end link identifier information, user information associated with WTRU-1 and WTRU-2 may be derived, and this user information may be used to check whether the request and response messages are valid and / or originate from a legitimate entity.
[0148] Although the above features and elements are described in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiment, or in various combinations with or without the other features and elements.
[0149] While the implementations described herein may consider 3GPP specific protocols, it is to be understood that the implementations described herein are not limited to such scenarios and may be applicable to other wireless systems. For example, while the solutions described herein consider LTE, LTE-A, New Radio (NR), or 5G specific protocols, it is to be understood that the solutions described herein are not limited to such scenarios and may be applicable to other wireless systems as well. For example, while the systems have been described with reference to 3GPP, 5G, and / or NR network layers, the envisioned embodiments extend beyond implementations using specific network layer technologies. Likewise, potential implementations extend to all types of service layer architectures, systems, and embodiments. The techniques described herein may be applied alone and / or in combination with other resource configuration techniques.
[0150] The processes described herein may be implemented in a computer program, software, and / or firmware incorporated into a computer-readable medium for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as compact disc (CD)-ROM disks and / or digital versatile discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for use in a WTRU, terminal, base station, RNC, and / or any host computer.
[0151] It is to be understood that the entities that perform the processes described herein may be logical entities that may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a mobile device, network node, or computer system and executed on a processor of the mobile device, network node, or computer system. That is, the processes may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a mobile device and / or network node (such as a node or computer system) that, when executed by a processor of the node, performs the processes in question. It is also to be understood that any transmission and reception processes illustrated in the figures may be performed by the communication circuitry of the node under the control of the processor of the node and the computer-executable instructions (e.g., software) executed by it.
[0152] The various techniques described herein can be implemented in combination with hardware or software, or, where appropriate, can be implemented in combination with a combination of the two. Therefore, the implementation and device of the subject matter described herein or some aspects or parts thereof can be in the form of program code (e.g., instructions), which is embedded in a tangible medium including any other machine-readable storage medium, wherein, when the program code is loaded into a machine (such as a computer) and executed by the machine, the machine becomes a device for practicing the subject matter described herein. In the case where the program code is stored on a medium, it may be the case that the program code in question is stored on one or more media that jointly perform the action in question, that is, one or more media together contain the code for performing the action, but - in the case where there is more than one separate medium - it is not required that any particular part of the code is stored on any particular medium. In the case where program code execution is performed on a programmable device, the computing device typically includes a processor, a storage medium readable by the processor (including volatile or non-volatile memory and / or storage element), at least one input device and at least one output device. One or more programs can, for example, be implemented or utilized in conjunction with the subject matter described herein by using an API, a reusable control or the like. Such programs are preferably implemented in a high-level programming language or an object-oriented programming language to communicate with a computer system. However, if desired, the program(s) may be implemented in assembly language or machine language. In any case, the language may be a compiled or interpreted language and combined with hardware implementation.
[0153] While example embodiments may refer to utilizing aspects of the subject matter described herein in the context of one or more stand-alone computing systems, the subject matter described herein is not limited thereto and may be implemented in conjunction with any computing environment, such as a network or distributed computing environment. Still further, aspects of the subject matter described herein may be implemented in or across multiple processing chips or devices, and storage across multiple devices may be similarly affected. Such devices may include personal computers, network servers, handheld devices, supercomputers, or computers integrated into other systems, such as automobiles and airplanes.
[0154] In describing preferred embodiments of the subject matter of the present disclosure, as illustrated in the figures, specific terminology is employed for the sake of clarity. However, the claimed subject matter is not intended to be limited to the specific terminology so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner to accomplish a similar purpose.
Claims
1. A device comprising: A processor configured to: communicating with a first wireless transmit / receive unit (WTRU) via a link; receiving first information from a first WTRU, wherein the first information includes an indication to release a link; determining that a second WTRU has an end-to-end connection with the first WTRU via the device based on a list of WTRUs managed by the device or a list of WTRUs received from the first WTRU, wherein the list of WTRUs includes the second WTRU; and Second information is sent to the second WTRU, wherein the second information indicates that the first WTRU is no longer available via the device. 2 . The apparatus of claim 1 , wherein the end-to-end connection is at least one of IP-based communication or Ethernet-based communication.
3. The apparatus of claim 1 , wherein the link is a PC5 connection.
4. The apparatus of claim 1 , wherein the second information further indicates deletion of context data associated with the first WTRU from the second WTRU.
5. The apparatus of claim 1 , wherein the processor is further configured to: communicating with a third WTRU via a second link; and Third information is received from a third WTRU, wherein the third information indicates a link modification request including an end-to-end packet delay budget.
6. The apparatus of claim 5, wherein the link modification request is associated with a previously established connection, and wherein the previously established connection is between a third WTRU and a second WTRU via the apparatus.
7. The apparatus of claim 5, wherein a sum of a packet delay budget of the second link and a packet delay budget of a third link between the apparatus and a second WTRU satisfies an end-to-end packet delay budget.
8. The apparatus of claim 1 , wherein the first information further indicates an end-to-end identifier for communication between the first WTRU and the second WTRU.
9. A method implemented in a device, the method comprising: communicating with a first wireless transmit / receive unit (WTRU) via a link; receiving first information from a first WTRU, wherein the first information includes an indication to release a link; determining that a second WTRU has an end-to-end connection with the first WTRU via the device based on a list of WTRUs managed by the device or a list of WTRUs received from the first WTRU, wherein the list of WTRUs includes the second WTRU; and Second information is sent to the second WTRU, wherein the second information indicates that the first WTRU is no longer available via the device.
10. The method of claim 9, wherein the end-to-end connection is at least one of IP-based communication or Ethernet-based communication. The method of claim 9 , wherein the link is a PC5 connection.
12. The method of claim 9, wherein the second information further indicates deletion of context data associated with the first WTRU from the second WTRU.
13. The method according to claim 9, further comprising: communicating with a third WTRU via a second link; as well as Third information is received from a third WTRU, wherein the third information indicates a link modification request including an end-to-end packet delay budget.
14. The method of claim 13, wherein the link modification request is associated with a previously established connection, and wherein the previously established connection is between a third WTRU and a second WTRU via the device.
15. The method of claim 13, wherein a sum of a packet delay budget of the second link and a packet delay budget of a third link between the device and a second WTRU satisfies an end-to-end packet delay budget.