Delay measurement method, delay reporting and corresponding transmission reconfiguration

Abstract

In an aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The method can be performed by a user equipment. In certain configurations, the user equipment receives packets from a forwarding station. The forwarding station is a source station or a connecting relay node of a network, and the user equipment is a destination station or a relay node. The user equipment performs delay measurements on the packets according to a delay measurement configuration to obtain delays of the packets. The user equipment generates a delay measurement report including the measured delays of the packets, and transmits the delay measurement report to one or more reporting receiving stations according to a delay report configuration. Upon receiving the delay measurement report, the reporting receiving stations can perform transmission reconfiguration.

Description

[0001] Cross-referencing

[0002] This application claims the benefit of PCT application No. PCT / CN2023 / 128472 (titled “Method for measuring delay, reporting delay and corresponding transmission reconfiguration”), filed on October 31, 2023, the entire contents of which are hereby expressly incorporated by reference. Technical Field

[0003] This disclosure generally relates to communication systems, and more specifically, to techniques for methods and apparatus for delay measurement, delay reporting, and corresponding transmission reconfiguration. Background Technology

[0004] The statements in this section provide only background information in relation to this disclosure and may not constitute prior art.

[0005] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Typical wireless communication systems employ multiple access technologies, supporting communication with multiple users by sharing available system resources. Examples of such multiple access technologies include code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

[0006] These multiple access technologies have been adopted in various telecommunications standards to provide a common protocol enabling different wireless devices to communicate at the city, national, regional, and even global levels. One example of a telecommunications standard is 5G New Radio (NR). 5G NR is part of the ongoing evolution of mobile broadband driven by the Third Generation Partnership Project (3GPP) to meet new requirements related to latency, reliability, security, scalability (e.g., the Internet of Things (IoT)), and other needs. Some aspects of 5G NR may be based on the 4G Long Term Evolution (LTE) standard. Further improvements to 5G NR technology are still needed. These improvements may also apply to other multiple access technologies and the telecommunications standards that adopt them. Summary of the Invention

[0007] The following content presents one or more aspects in a simplified form to provide a basic understanding of these aspects. This summary is not a comprehensive overview of all hypothetical aspects, nor is it intended to identify key or important elements of all aspects, nor to define the scope of any or all aspects. Its sole purpose is to present certain concepts of one or more aspects in a simplified form as a prelude to a more detailed description thereafter.

[0008] In one aspect of this disclosure, a method, a computer-readable medium, and an apparatus are provided. The method can be performed by user equipment (UE). In some configurations, the UE receives multiple packets from a forwarding station. The forwarding station is a source station or connection relay node of a network, and the UE acts as a destination station or relay node. The UE performs delay measurements on the packets according to a delay measurement configuration to obtain the delay of the packets. The UE generates a delay measurement report containing the measured delay of the packets and sends the delay measurement report to one or more report receiving stations according to a delay report configuration.

[0009] In another aspect of this disclosure, a method, a computer-readable medium, and an apparatus are provided. The method can be performed by a network originating station. In some configurations, the originating station sends multiple packets to a UE or a relay node. The originating station receives a delay measurement report from the UE or the relay node. In response to receiving the delay measurement report, the originating station performs a transmission reconfiguration based on the delay measurement report.

[0010] To achieve the foregoing and related objectives, one or more aspects include the following features, which will be described in detail below and specifically pointed out in the claims. The following description and accompanying drawings illustrate in detail certain exemplary features of one or more aspects. However, these features only indicate a portion of how the principles of the various aspects can be applied, and this description is intended to cover all such aspects and their equivalents. Attached Figure Description

[0011] Figure 1 This is a schematic diagram illustrating an example of a wireless communication system and access network.

[0012] Figure 2 This is a schematic diagram illustrating how the base station communicates with the UE in the access network.

[0013] Figure 3 This section describes an example logical architecture for a distributed access network.

[0014] Figure 4 This describes an example physical architecture for a distributed access network.

[0015] Figure 5 The diagram illustrates an example where DL is the center time slot.

[0016] Figure 6 This is a schematic diagram showing an example where UL is the center time slot.

[0017] Figure 7 This diagram illustrates an example process of a UE connecting to the source station in a binding scenario.

[0018] Figure 8 This diagram illustrates an example process where a UE connects to the source station through multiple relay nodes in a mesh / multi-hop scenario.

[0019] Figure 9 This diagram illustrates the process of a UE connecting to the source station via a relay node, and provides example procedures for per-link, per-link set, and per-path delay.

[0020] Figure 10 This diagram illustrates an example process for performing latency measurements for each packet.

[0021] Figure 11 The diagram illustrates an example process for periodically performing delay measurements on packets.

[0022] Figure 12 This diagram illustrates an example process for performing delay measurements using the timestamps in each packet.

[0023] Figure 13 This is a schematic diagram illustrating an example process for performing delay measurement by recording packet transmission delay.

[0024] Figure 14 This diagram illustrates an example process for performing delay measurement using timestamps in a single-hop scenario, where the hop node synchronizes with both the source and destination stations via a local link clock source.

[0025] Figure 15 This diagram illustrates an example process for performing latency measurement via timestamps in a multi-hop scenario, where hop nodes are synchronized using a unified timestamp.

[0026] Figure 16 This diagram illustrates an example process for performing latency measurement using timestamps and measuring the latency of each link set in a multi-hop scenario.

[0027] Figure 17 This diagram illustrates an example process for performing delay measurement through self-recording packet transmission delay in a bound scenario.

[0028] Figure 18 This diagram illustrates an example process for a UE to periodically send delay measurement reports.

[0029] Figure 19 This is a schematic diagram illustrating an example process where the UE sends a delay measurement report based on a trigger event.

[0030] Figure 20 This diagram illustrates an example process where the destination station performs a delay measurement and sends a delay measurement report.

[0031] Figure 21 This is a schematic diagram illustrating an example process where the source station performs transmission reconfiguration after receiving a delay measurement report.

[0032] Figure 22 This is a flowchart of the UE wireless communication method (process).

[0033] Figure 23 This is a flowchart of the wireless communication method (process) for the network source station. Detailed Implementation

[0034] The detailed description below, taken in conjunction with the accompanying drawings, is intended to describe various configurations and is not intended to represent the only configuration in which the concepts described herein can be implemented. The detailed description includes specific details to provide a thorough understanding of the various concepts. However, those skilled in the art will understand that these concepts can be implemented without these specific details. In some cases, to avoid obscuring these concepts, known structures and components are shown in block diagram form.

[0035] Several aspects of telecommunications systems will now be introduced in conjunction with various devices and methods. These devices and methods will be described in detail below and illustrated with accompanying drawings as various modules, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements can be implemented through electronic hardware, computer software, or any combination thereof. Whether an element is implemented in hardware or software depends on the specific application and design constraints imposed on the overall system.

[0036] For example, a single element, any part of an element, or any combination of elements can be implemented as a "processing system" containing one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on a chip (SoCs), baseband processors, field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other hardware suitable for performing the various functions described in this disclosure. One or more processors in the processing system can execute software. Software should be understood broadly as instructions, instruction sets, code, code segments, program code, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads of execution, procedures, functions, etc., regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description languages, or other names.

[0037] Therefore, in one or more examples, the functionality can be implemented by hardware, software, or any combination thereof. If implemented in software, these functions can be stored in or encoded as one or more instructions or codes stored on a computer-readable medium. Computer-readable media include computer storage media. Storage media can be any existing medium accessible to a computer. For example, but not limited to, such computer-readable media can include random-access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, combinations of computer-readable media of the above types, or any medium that can be used to store computer-executable code in the form of instructions or data structures and is accessible to a computer.

[0038] Figure 1 This diagram illustrates a wireless communication system and access network 100. The wireless communication system (also known as a wireless wide area network (WWAN)) includes base station 102, user equipment (UE) 104, evolved packet core (EPC) 160, and another core network 190 (e.g., 5G core network (5GCore (5GC))). Base station 102 may include macro cells (high-power cellular base stations) and / or small cells (low-power cellular base stations). Macro cells include base stations. Small cells include femtocells, picocells, and microcells.

[0039] Base station 102 configured as 4G LTE (collectively referred to as the Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN)) can be connected to EPC 160 via backhaul link 132 (e.g., SI interface). Base station 102 configured as 5G NR (collectively referred to as Next Generation RAN (NG-RAN)) can be connected to core network 190 via backhaul link 184. In addition to other functions, base station 102 may perform one or more of the following functions: user data transmission, radio channel encryption and decryption, integrity protection, header compression, mobility control functions (e.g., handover, dual connectivity), inter-cell interference coordination, connection establishment and release, load balancing, non-access stratum (NAS) message distribution, NAS node selection, synchronization, radio access network (RAN) sharing, multimedia broadcast multicast service (MBMS), user and equipment tracking, RAN information management (RIM), paging, location, and warning message delivery. Base station 102 may communicate with each other directly or indirectly (e.g., via EPC160 or core network 190) via backhaul link 134 (e.g., X2 interface). Backhaul link 134 may be wired or wireless.

[0040] Base station 102 can wirelessly communicate with UE 104. Each base station 102 can provide communication coverage for a corresponding geographic coverage area 110. Geographic coverage areas 110 may overlap. For example, the coverage area 110' of small cell 102' may overlap with the coverage area 110 of one or more macro base stations 102. A network containing small cells and macro cells may be referred to as a heterogeneous network. The heterogeneous network may also include Evolved Node B (eNB) (HeNB), which can provide services to a restricted group called a closed subscriber group (CSG). The communication link 120 between base station 102 and UE 104 may include an uplink (UL) (also known as a reverse link) transmission from UE 104 to base station 102 and / or a downlink (DL) (also known as a forward link) transmission from base station 102 to UE 104. Communication link 120 may employ multiple-input multiple-output (MIMO) antenna technology, including spatial multiplexing, beamforming, and / or transmit diversity. The communication link may be implemented using one or more carriers. Base station 102 / UE 104 may use up to 7 MHz (e.g., 5, 10, 15, 20, 100, 400 MHz) bandwidth per carrier, allocating up to a total of Yx MHz (x component carriers) for transmission in each direction in carrier aggregation. Carriers may be adjacent or non-adjacent. Carrier allocation may be asymmetrical in the DL and UL directions (e.g., more or fewer carriers allocated to DL than UL). Component carriers may include primary component carriers and one or more auxiliary component carriers. The primary component carrier may be referred to as the primary cell (PCell), and the auxiliary component carriers may be referred to as secondary cells (SCells).

[0041] Some UEs 104 can communicate with each other via device-to-device (D2D) communication link 158. D2D communication link 158 can use DL / UL WWAN spectrum. D2D communication link 158 can use one or more sidelink channels, such as physical sidelink broadcast channel (PSBCH), physical sidelink discovery channel (PSDCH), physical sidelink shared channel (PSSCH), and physical sidelink control channel (PSCCH). D2D communication can be implemented through various wireless D2D communication systems, such as FlashLinQ, WiMedia, Bluetooth, ZigBee, Wi-Fi based on the IEEE 802.11 standard, LTE, or NR.

[0042] The wireless communication system may also include a Wi-Fi access point (AP) 150 that communicates with the Wi-Fi station (STA) 152 via a communication link 154 in the 5 GHz unlicensed spectrum. During unlicensed spectrum communication, the STA 152 / AP 150 may perform a clear channel assessment (CCA) before communication to determine channel availability.

[0043] Small cell 102' can operate in licensed and / or unlicensed spectrum. When operating in unlicensed spectrum, small cell 102' can employ NR and use the same 5 GHz unlicensed spectrum as Wi-Fi AP 150. Employing NR in unlicensed spectrum can enhance the coverage and / or increase the capacity of the access network.

[0044] Whether it's a small cell 102' or a large cell (e.g., a macro base station), base station 102 can include an eNB, gNodeB (gNB), or other types of base stations. Some base stations (e.g., gNB 180) can communicate with UE 104 in conventional sub-6 GHz bands, millimeter wave (mmW) frequencies, and / or near mmW frequencies. When gNB 180 operates at millimeter wave or near mmW frequencies, gNB 180 can be referred to as a millimeter wave base station. Extremely high frequency (EHF) belongs to the radio frequency (RF) portion of the electromagnetic spectrum. EHF ranges from 30 GHz to 300 GHz, with wavelengths between 1 mm and 10 mm. Radio waves in this band can be referred to as millimeter waves. Near mmW can extend down to 3 GHz with a wavelength of 100 mm. Super high frequency (SHF) bands range from 3 GHz to 30 GHz, also known as centimeter waves. Communication using millimeter-wave / near-millimeter-wave radio frequency bands (e.g., 3 GHz-300 GHz) suffers from extremely high path loss and short range. Millimeter-wave base station 180 can use beamforming 182 to communicate with UE 104 to compensate for the extremely high path loss and short range.

[0045] Base station 180 can transmit beamforming signals to UE 104 in one or more transmit directions 108a. UE 104 can receive beamforming signals from base station 180 in one or more receive directions 108b. UE 104 can also transmit beamforming signals to base station 180 in one or more transmit directions. Base station 180 can receive beamforming signals from UE 104 in one or more receive directions. Base station 180 and UE 104 can perform beam training to determine their respective optimal receive and transmit directions. The transmit and receive directions of base station 180 can be the same or different. The transmit and receive directions of UE 104 can be the same or different.

[0046] EPC 160 may include a Mobility Management Entity (MME) 162, other MMEs 164, a Serving Gateway 166, a Multimedia Broadcast Multicast Service (MBMS) Gateway 168, a Broadcast Multicast Service Center (BM-SC) 170, and a Packet Data Network (PDN) Gateway 172. MME 162 can communicate with the Home Subscriber Server (HSS) 174. MME 162 is the control node that handles signaling between UE 104 and EPC 160. Generally, MME 162 provides bearer and connection management. All user Internet Protocol (IP) packets are transmitted through the Serving Gateway 166, which is itself connected to the PDN Gateway 172. The PDN Gateway 172 provides UE IP address allocation and other functions. The PDN Gateway 172 and BM-SC 170 are connected to the IP service 176. IP service 176 may include the Internet, intranet, IP Multimedia Subsystem (IMS), Packet Switched Streaming Service (PS Streaming Service), and / or other IP services. BM-SC 170 can provide and deliver MBMS user services. BM-SC 170 can serve as an entry point for MBMS transmission by content providers, can be used to authorize and initiate MBMS bearer services within a public land mobile network (PLMN), and can be used to schedule MBMS transmissions. MBMS gateway 168 can be used to distribute MBMS traffic to base station 102 belonging to a Multicast Broadcast Single Frequency Network (MBSFN) area that broadcasts specific services, and can be responsible for session management (start / stop) and collecting billing information related to Enhanced MBMS (eMBMS).

[0047] The core network 190 may include an Access and Mobility Management Function (AMF) 192, other AMFs 193, a Location Management Function (LMF) 198, a Session Management Function (SMF) 194, and a User Plane Function (UPF) 195. The AMF 192 can communicate with the Unified Data Management (UDM) 196. The AMF 192 is the control node that handles signaling between the UE 104 and the core network 190. Generally, the SMF 194 provides QoS flow and session management. All user IP packets are transmitted through the UPF 195. The UPF 195 provides UE IP address allocation and other functions. The UPF 195 connects to an IP service 197. The IP service 197 may include the Internet, intranet, IMS, packet-switched streaming services, and / or other IP services.

[0048] A base station may also be referred to as a gNB, Node B, eNB, access point, base transceiver station, wireless base station, wireless transceiver, transceiver function, basic service set (BSS), extended service set (ESS), transmit reception point (TRP), or other suitable terms. Base station 102 provides UE 104 with access to EPC 160 or core network 190. Examples of UE 104 include cellular phones, smartphones, session initiation protocol (SIP) phones, laptops, personal digital assistants (PDAs), satellite radios, GPS devices, multimedia devices, video devices, digital audio players (e.g., MP3 players), cameras, game consoles, tablets, smart devices, wearable devices, vehicles, electricity meters, gas pumps, large or small kitchen appliances, medical devices, implants, sensors / actuators, displays, or any other similarly functional device. Some UEs 104 may be referred to as IoT devices (e.g., parking meters, gas pumps, toasters, vehicles, heart monitors, etc.). UE 104 may also be referred to as a station, mobile station, user station, mobile unit, user unit, radio unit, remote unit, mobile device, radio device, wireless communication device, remote device, mobile user station, access terminal, mobile terminal, radio terminal, remote terminal, handheld device, user agent, mobile client, client, or other suitable terms.

[0049] While this disclosure may relate to 5G NR, it also applies to other similar fields, such as LTE, LTE-Advanced (LTE-A), Code Division Multiple Access (CDMA), Global System for Mobile communications (GSM), or other radio / radio frequency access technologies.

[0050] Figure 2This is a block diagram illustrating communication between base station 210 and UE 250 in the access network. In the DL, IP packets from EPC 160 can be provided to controller / processor 275. Controller / processor 275 implements protocol layer 3 and protocol layer 2 functions. Protocol layer 3 includes the radio resource control (RRC) layer, and protocol layer 2 includes the packet data convergence protocol (PDCP) layer, radio link control (RLC) layer, and medium access control (MAC) layer. The controller / processor 275 provides RRC layer functions related to system information (e.g., MIB, SIB) broadcasting, RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-radio access technology (RAT) mobility, and measurement configuration of UE measurement reports; PDCP layer functions related to header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functions related to upper-layer packet data units (PDU) transmission, error correction via ARQ, concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions related to mapping between logical channels and transport channels, multiplexing of MAC SDUs to transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority handling, and logical channel priority.

[0051] The transmit (TX) processor 216 and the receive (RX) processor 270 implement Layer 1 functions related to various signal processing functions. Layer 1 (including the physical (PHY) layer) may include error detection of the transport channel, forward error correction (FEC) encoding / decoding of the transport channel, interleaving, rate matching, mapping to the physical channel, modulation / demodulation of the physical channel, and MIMO antenna processing. The TX processor 216 processes the mapping to signal constellations according to various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), and M-quadrature amplitude modulation (M-QAM)). The encoded, decoded, and modulated symbols can then be split into parallel streams. Each stream can then be mapped to an OFDM subcarrier, multiplexed with a reference signal (e.g., a pilot) in the time and / or frequency domains, and then combined using an inverse fast fourier transform (IFFT) to generate a physical channel carrying the time-domain OFDM symbol stream. The OFDM streams undergo spatial pre-coding / decoding to generate multiple spatial streams. Channel estimates from channel estimator 274 can be used to determine the encoding / decoding and modulation schemes, as well as spatial processing. The channel estimates can be derived from the reference signal and / or channel state feedback transmitted by UE 250. Each spatial stream can then be provided to different antennas 220 via a separate transmitter 218TX. Each transmitter 218TX can be transmitted using an RF carrier modulated with the corresponding spatial stream.

[0052] At UE 250, each receiver 254RX receives signals through its corresponding antenna 252. Each receiver 254RX recovers the information modulated onto the RF carrier and provides the information to the RX processor 256. The TX processor 268 and RX processor 256 implement Layer 1 functions related to various signal processing functions. The RX processor 256 can perform spatial processing on the information to recover any spatial stream oriented towards UE 250. If multiple spatial streams are oriented towards UE 250, they can be merged into a single OFDM symbol stream by the RX processor 256. The RX processor 256 then uses a Fast Fourier Transform (FFT) to transform the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal consists of a separate OFDM symbol stream for each OFDM signal subcarrier. The symbols on each subcarrier, along with the reference signal, are recovered and demodulated by determining the most probable signal constellation point transmitted by base station 210. These soft decisions can be based on a channel estimate calculated by channel estimator 258. The soft decision is then decoded and deinterleaved to recover the data and control signals initially transmitted by base station 210 on the physical channel. The data and control signals are then provided to controller / processor 259, which implements Layer 3 and Layer 2 functions.

[0053] The controller / processor 259 can be associated with a memory 260 that stores program code and data. The memory 260 may be referred to as a computer-readable medium. In the UL, the controller / processor 259 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between transport and logical channels to recover IP packets from the EPC 160. The controller / processor 259 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0054] Similar to the functions described in the DL transmission of base station 210, controller / processor 259 provides RRC layer functions related to system information (e.g., MIB, SIB) acquisition, RRC connection, and measurement reporting; PDCP layer functions related to header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions related to upper-layer PDU transmission, error correction via ARQ, connection, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions related to mapping between logical channels and transport channels, multiplexing of MAC SDUs to TBs, demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction via HARQ, priority processing, and logical channel priority.

[0055] The channel estimate derived by the channel estimator 258 from the reference signal or feedback sent by the base station 210 can be used by the TX processor 268 to select appropriate encoding / decoding and modulation schemes and facilitate spatial processing. The spatial stream generated by the TX processor 268 can be provided to different antennas 252 via individual transmitters 254TX. Each transmitter 254TX can be transmitted using the corresponding spatial stream modulated on an RF carrier. Uplink transmission is processed at the base station 210 in a manner similar to the reception function at the UE 250. Each receiver 218RX receives the signal through its corresponding antenna 220. Each receiver 218RX recovers the information modulated onto the RF carrier and provides the information to the RX processor 270.

[0056] The controller / processor 275 may be associated with a memory 276 storing program code and data. The memory 276 may be referred to as a computer-readable medium. In the uplink, the controller / processor 275 provides demultiplexing, packet reassembly, decryption, header decompression, and control signal processing between the transport channel and the logical channel to recover IP packets from the UE 250. IP packets from the controller / processor 275 can be provided to the EPC 160. The controller / processor 275 is also responsible for error detection using ACK and / or NACK protocols to support HARQ operation.

[0057] NR can refer to a radio configured to operate under a new air interface (e.g., an air interface not based on Orthogonal Frequency Divisional Multiple Access (OFDMA)) or a fixed transport layer (e.g., non-IP). NR can use OFDM with a cyclic prefix (CP) on both the uplink and downlink, and may include support for half-duplex operation using time division duplexing (TDD). NR may include Enhanced Mobile Broadband (eMBB) service (targeting wide bandwidth (e.g., above 80 MHz)), mmW (targeting high carrier frequencies (e.g., 60 GHz)), massive MTC (mMTC) (targeting non-backward-compatible MTC technologies), and / or mission-critical services targeting ultra-reliable low-latency communications (URLLC).

[0058] It can support a single component carrier bandwidth of 100 MHz. In one example, an NR resource block (RB) can span 12 subcarriers with a subcarrier bandwidth of 60 kHz and a duration of 0.25 ms, or a bandwidth of 30 kHz and a duration of 0.5 ms (similarly, a 15 kHz sub-carrier space (SCS) has a bandwidth of 50 MHz over a duration of 1 ms). Each radio frame can consist of 10 subframes (10, 20, 40, or 80 NR slots) with a length of 10 ms. Each slot can indicate the link direction of data transmission (i.e., DL or UL), and the link direction of each slot can be dynamically switched. Each slot can include DL / UL data and DL / UL control data. The UL and DL slots of NR will be discussed in conjunction below. Figure 5 and Figure 6 To provide a more detailed description.

[0059] NRRAN can include a central unit (CU) and distributed units (DU). NR base stations (e.g., gNB, 5G Node B, Node B, TRP, AP) can correspond to one or more base stations. NR cells can be configured as access cells (ACell) or data-only cells (DCell). For example, the RAN (e.g., central unit or distributed unit) can configure these cells. DCells can be used for carrier aggregation or dual connectivity and may not be used for initial access, cell selection / reselection, or handover. In some cases, DCells may not transmit synchronization signals (SS); in others, they may transmit SS. NR base stations can transmit downlink signals to the UE indicating the cell type. Based on the cell type indication, the UE can communicate with the NR base station. For example, the UE can determine whether the NR base station is used for cell selection, access, handover, and / or measurement based on the indicated cell type.

[0060] Figure 3An example logical architecture of a distributed RAN 300 is shown according to relevant aspects of this disclosure. A 5G access node 306 may include an access node controller (ANC) 302. This ANC may be a CU of the distributed RAN. The backhaul interface to the next-generation core network (NG-CN) 304 may terminate at the ANC. The backhaul interface to neighboring next-generation access nodes (NG-CN) 310 may terminate at the ANC. The ANC may include one or more TRPs 308 (also referred to as base stations (BS), new radio base stations (NR BS), Node B, 5G NB, AP, or other terms). As mentioned above, TRPs may be used interchangeably with "cells".

[0061] TRP 308 can be a DU. A TRP can connect to one ANC (ANC 302) or multiple ANCs (not shown). For example, for RAN sharing, radio as a service (RaaS), and service-specific ANC deployments, a TRP can connect to multiple ANCs. A TRP may include one or more antenna ports. A TRP can be configured to provide services to the UE individually (e.g., dynamically selected) or jointly (e.g., jointly transmitted).

[0062] The local architecture of the distributed RAN 300 can be used to illustrate the fronthaul definition. This architecture can be defined to support fronthaul solutions for different deployment types. For example, the architecture can be based on transport network capabilities (e.g., bandwidth, latency, and / or jitter). The architecture can share features and / or components with LTE. Depending on the relevant aspects, the NG-AN 310 can support dual connectivity with NR. The NG-AN can share a common fronthaul for both LTE and NR.

[0063] This architecture enables collaboration between and within TRPs 308. For example, collaboration can be pre-defined within a TRP and / or implemented across TRPs via ANC 302. Depending on the relevant parties, inter-TRP interfaces may be unnecessary or nonexistent.

[0064] According to relevant sources, the distributed RAN 300 architecture allows for dynamic configuration of segmentation logic functions. PDCP, RLC, and MAC protocols can be adaptively placed in the ANC or TRP.

[0065] Figure 4An example physical architecture of the distributed RAN 400 is illustrated according to relevant aspects of this disclosure. A centralized core network unit (C-CU) 402 can host core network functions. The C-CU can be centrally deployed. C-CU functions can be offloaded (e.g., to advanced wireless services (AWS)) to handle peak capacity. A centralized RAN unit (C-RU) 404 can host one or more ANC functions. Optionally, the C-RU can host core network functions locally. The C-RU can be distributed. The C-RU can be located closer to the network edge. A DU 406 can host one or more TRPs. The DU can be located at the network edge with RF functionality.

[0066] Figure 5 Figure 500 illustrates an example of a DL-centered timeslot. The DL-centered timeslot may include a control section 502. The control section 502 may exist in the initial or beginning portion of the DL-centered timeslot. The control section 502 may include various scheduling and / or control information corresponding to different portions of the DL-centered timeslot. In some configurations, the control section 502 may be a physical downlink control channel (PDCCH), such as... Figure 5 As shown. The DL-centered time slot may also include a DL data portion 504. The DL data portion 504 may sometimes be referred to as the payload of the DL-centered time slot. The DL data portion 504 may include communication resources used for communicating DL data from a scheduling entity (e.g., UE or BS) to a subordinate entity (e.g., UE). In some configurations, the DL data portion 504 may be a physical DL shared channel (PDSCH).

[0067] The DL-centered time slot may also include a general UL section 506. The general UL section 506 may sometimes be referred to as a UL burst, general UL burst, and / or other appropriate terms. The general UL section 506 may include feedback information corresponding to the various parts of the DL-centered time slot. For example, the general UL section 506 may include feedback information corresponding to the control section 502. Examples of non-limiting feedback information may include ACK signals, NACK signals, HARQ indicators, and / or other appropriate types of information. The general UL section 506 may include additional or alternative information, such as information related to random access channel (RACH) procedures, scheduling requests (SR), and other appropriate types of information.

[0068] like Figure 5 As shown, the end of the DL data section 504 can be time-separated from the start of the general UL section 506. This time separation may sometimes be referred to as a gap, protection period, protection interval, and / or other appropriate terms. This separation provides time for the switching from DL communication (e.g., a receiving operation of a subordinate entity (e.g., a UE)) to UL communication (e.g., a transmitting operation of a subordinate entity (e.g., a UE)). Those skilled in the art will understand that the above is merely an example of a DL-centered time slot, and alternative structures with similar characteristics may exist without departing from the relevant aspects described herein.

[0069] Figure 6 Figure 600 illustrates an example of a UL-centered time slot. A UL-centered time slot may include a control section 602. The control section 602 may be present at the beginning or start of the UL-centered time slot. Figure 6 The control section 602 in the above reference can be used as a reference. Figure 5 The control section 502 is described similarly. The UL-centered timeslot may also include a UL data section 604. The UL data section 604 may sometimes be referred to as the payload of the UL-centered timeslot. The UL section may refer to the communication resources used by a subordinate entity (e.g., UE) to communicate UL data to a scheduling entity (e.g., UE or BS). In some configurations, the control section 602 may be a PDCCH.

[0070] like Figure 6 As shown, the end of control section 602 can be time-separated from the start of UL data section 604. This time separation may sometimes be referred to as a gap, protection cycle, protection interval, and / or other appropriate terms. This separation provides time for switching from DL communication (e.g., a receiving operation of a scheduling entity) to UL communication (e.g., a transmitting operation of a scheduling entity). The UL-centered time slot may also include a general UL section 606. Figure 6The general UL section 606 in the document can be referenced above. Figure 5 The general UL section 506 described is similar. The general UL section 606 may also include information related to a channel quality indicator (CQI), sounding reference signals (SRS), and other suitable types of information. Those skilled in the art will understand that the above is merely an example of a UL-centered time slot, and alternative structures with similar characteristics may exist without departing from the relevant aspects described herein.

[0071] In some cases, two or more dependent entities (e.g., UEs) can communicate using sidelink signals. Practical applications of such sidelink communication can include public safety, proximity services, UE-to-network relay, vehicle-to-vehicle (V2V) communication, Internet of Everything (IoE) communication, IoT communication, mission-critical mesh networks, and / or other suitable applications. Generally, a sidelink signal can refer to a signal used for communication from one dependent entity (e.g., UE 1) to another dependent entity (e.g., UE 2) without relaying the communication through a scheduling entity (e.g., a UE or BS), although the scheduling entity may be used for scheduling and / or control purposes. In some examples, sidelink signals can communicate using licensed spectrum (unlike wireless LANs that typically use unlicensed spectrum).

[0072] One trend in network deployment towards B5G / 6G is the support for distributed architectures. Source stations can provide services to their destination stations through one or more hopping relay nodes, which increases the challenges of quality of service (QoS) control. Therefore, UE-assisted latency measurement, reporting, and corresponding transport reconfiguration are ways for systems to meet service QoS requirements and packet delay budget (PDB) to adapt to potential network deployments.

[0073] In some configurations, the source station cannot know the packet transmission delay between the relay node and the destination station. Due to the different hop nodes and corresponding packet routing algorithms in various scenarios, the uncertainty of packet transmission delay increases significantly. This uncertainty leads to violations of PDB and potential QoS requirements. Referring to 3GPP specifications (e.g., 3GPP TR 38.838), PDB is defined as the packet-tolerable transmission delay and is one of the key performance indicators (KPIs) for XR services. Therefore, network scheduling, link adaptation, rate adaptation, and network topology planning become more difficult. Consequently, certain aspects of this disclosure relate to methods and apparatus for performing delay measurement, providing delay reports, and corresponding transmission reconfiguration in different scenarios. If the relay node and / or destination station provides packet delay reports, better destination station transmission allocation can be achieved, including adaptive scheduling, link adaptation, path selection / handover decisions, and routing decisions. Specifically, for low-latency traffic served through multi-path, multi-hop, or potentially 6G mesh and distributed network deployments, the proposed methods and apparatus provide a variety of alternative general solutions for delay measurement and reporting methods. In some configurations, (pre)configured delay measurements of links / link sets / paths and timing can be based on timestamps inserted into the adaptation layer, PDCP layer, or other transport layers in the user plane. Delay measurements can be performed on control packets and / or data packets. Packet delays measured by relay nodes and / or destination stations are further derived as report values ​​in various formats. The measured delays are included in delay measurement reports, which may include delays for packet transmission per link / link set / path, and / or information on tethering mode activation, and / or estimates of average throughput per link / link set / path. Delay measurement reports can be distributed to connection stations or source stations, and the timing and / or period of the reports can be (pre)configured. Upon receiving a delay measurement report, transport reconfiguration / adaptation is performed, including codec rate adaptation and / or link adaptation and / or adaptive scheduling and / or path switching and / or routing decisions. Transport reconfiguration of sites / nodes can be performed proactively in a decentralized network topology or passively in a centralized topology.

[0074] Figure 7 The diagram illustrates an example process of a UE connecting to a source station in a bonded scenario. Specifically, process 700 shows a bonded topology where a destination station 730 (e.g., a UE) is served by a source station 710 (e.g., a base station or gNB) via a bonded path and a direct path. When the bonded link is enabled, the source station 710 (e.g., the gNB) sends packets to a relay node 720 (e.g., another UE) via the UMTS air interface (also known as the "Uu interface") on the relay path. The relay node 720 forwards the packets to the destination station 730 on the bonded path. When the direct link is enabled, the source station 710 can directly send packets via the Uu interface on the direct path.

[0075] Figure 8 This diagram illustrates an example process where a UE connects to the source station via multiple relay nodes in a mesh / multi-hop scenario. Specifically, process 800 demonstrates a mesh topology, supporting future B5G / 6G mesh deployments and applicable to IIoT, environmental IoT, or V2X. In process 800, multiple tools, devices, or vehicles connect to each other to build a mesh topology, where one device acts as a gateway / central control device, connecting other devices to the network and distributing computing tasks / sensing tasks / motion commands to the connected devices.

[0076] like Figure 8 As shown, in a mesh / multi-hop topology, multiple relay nodes 820 (e.g., UEs) are configured between the source station 810 (e.g., a base station or gNB) and the destination station 830 (e.g., a UE), including relay nodes A, B, C, and D. Specifically, the source station 810 sends packets to relay node A, which forwards the packets to relay node C or D until the packets reach the destination station 830. The source station 810 can also send packets to relay node B, which forwards the packets to relay node C or D until the packets reach the destination station. In this case, the mesh / multi-hop topology allows for multiple packet transmission routes between the source station 810 and the destination station 830.

[0077] In some configurations, within process 800 or 900, the source station (e.g., gNB 810 or 910) can configure delay measurement and delay reporting for each UE (e.g., relay node 820 or 920 or destination station 830 or 930) in each scenario. This allows each UE to perform corresponding delay measurements and generate corresponding delay measurement reports for the source station and other relay nodes. Therefore, the source station (and in some cases, relay nodes) can perform transmission reconfiguration upon receiving the delay measurement report.

[0078] Figure 9 This diagram illustrates an example process of a UE connecting to the source station via a relay node, considering per-link, per-link set, and per-path delays. Figure 9 As shown, multiple relay nodes 920 (e.g., UEs) are set up between the source station 910 (e.g., a base station or gNB) and the destination station 930 (e.g., a UE). Specifically, Figure 9 Only two relay nodes, A and B, are shown to represent a series of consecutive relay nodes 920. In procedure 900, the packet transmission delay to be measured can be further classified into per-link delay, per-link set delay, and per-path delay. In other words, the delay to be measured for the UE (e.g., relay node 920 and destination station 930) can be identified as packet transmission per link and / or per link set and / or per path.

[0079] like Figure 9As shown, during the process of source station 910 sending a packet to relay node A, the delays of source station 910, relay node 920 (e.g., relay nodes A and B), and / or destination station 930 are measurable. Relay node A continues to forward the packet to relay node B through multiple consecutive relay nodes, and relay node B forwards the packet to destination station 930. Specifically, the entire packet transmission delay from source station 910 to destination station 930 is classified as per-path delay. The packet transmission delay between two adjacent nodes (e.g., between source station 910 and relay node A, or between relay node B and destination station 930) is classified as per-link delay. The packet transmission delay between two nodes connected through one or more relay nodes (e.g., between relay nodes A and B through other relay nodes) is classified as per-linkset delay, where a linkset represents a collection of multiple consecutive transmission links. A transmission path consists of one or more links, one or more linksets, or any combination of links and linksets. Similarly, per-path delay consists of one or more per-link delays, one or more per-link set delays, or any combination of per-link and per-link set delays.

[0080] One issue related to latency measurement is the timing of latency measurement for each node / site. In some configurations, latency measurement can be performed per packet. Alternatively, in some configurations, latency measurement can be performed periodically on packets or time slots according to a (pre)configured period. Furthermore, in some configurations, latency measurement can be performed by triggering events.

[0081] Figure 10 The following diagram illustrates an example flow for performing delay measurements per packet. Flow 1000 shows a delay measurement performed per packet, where a measurement station / node 1020 (which may be a relay node or a destination station) is connected to a reference station / node 1010 (which may be a source station or a relay node), causing the measurement station / node 1020 to perform a delay measurement based on each packet sent by the reference station / node 1010.

[0082] like Figure 10 As shown, reference station / node 1010 sends delay measurement configuration 1030 to measurement station / node 1020 to set the delay measurement performed by measurement station / node 1020. Specifically, delay measurement configuration 1030 may be a (pre)configuration for delay measurement of measurement station / node 1020, indicating that delay measurement is performed per packet. In some configurations, delay measurement configuration 1030 may be generated by the network (e.g., the source station) and forwarded to measurement station / node 1020 via reference station / node 1010. In some configurations, delay measurement configuration 1030 may be sent as an RRC message, a MAC control element (CE) command, or a PDCCH. In operation 1040, measurement station / node 1020 configures the delay measurement according to delay measurement configuration 1030.

[0083] In operation 1050, reference station / node 1010 performs a packet transmission (e.g., sending a packet to measurement station / node 1020). In operation 1060, measurement station / node 1020 measures the delay of the received packet. In some configurations, the transmitted and measured packets can be control packets or data packets. In operation 1070, reference station / node 1010 performs another packet transmission. In operation 1080, measurement station / node 1020 measures the delay of the received packet. The delay measurement operation is repeated whenever a packet transmission occurs between reference station / node 1010 and measurement station / node 1020.

[0084] Figure 11 The following diagram illustrates an example process for periodically performing delay measurements on packets. Process 1100 shows that delay measurements are performed periodically over a measurement period N, where a measurement station / node 1120 (which may be a relay node or a destination station) is connected to a reference station / node 1110 (which may be a source station or a relay node), such that the measurement station / node 1120 periodically performs delay measurements based on the packets transmitted by the reference station / node 1110 within each measurement period N.

[0085] like Figure 11 As shown, reference station / node 1110 sends delay measurement configuration 1130 to measurement station / node 1120 to set the delay measurement to be performed by measurement station / node 1120. Specifically, delay measurement configuration 1130 may be a (pre)configuration for delay measurement of measurement station / node 1120, indicating that delay measurement is performed periodically at measurement period N. In some configurations, delay measurement configuration 1130 may be generated by the network (e.g., the source station) and forwarded to measurement station / node 1120 via reference station / node 1110. In some configurations, delay measurement configuration 1130 may be sent as an RRC message, MAC CE command, or PDCCH. In operation 1140, measurement station / node 1120 configures the delay measurement according to delay measurement configuration 1130.

[0086] In operations 1150 to 1155, reference station / node 1110 performs a series of packet transmissions within measurement period N (e.g., sending multiple packets to measurement station / node 1120). In operation 1160, measurement station / node 1120 measures the delay of packets received within measurement period N. In some configurations, each transmitted and measured packet can be a control packet or a data packet. In operations 1170 to 1175, reference station / node 1110 performs another series of packet transmissions within another measurement period N. In operation 1180, measurement station / node 1120 measures the delay of packets received within measurement period N. The delay measurement operation between reference station / node 1110 and measurement station / node 1120 is repeated periodically.

[0087] In some configurations, the delay measurement configuration (e.g., delay measurement configuration 1030 or 1130) may include one or more fields, including: information about the measurement period (e.g., the measurement period N in process 1100 when the measurement station / node performs packet delay measurement), information about the measurement object (e.g., the corresponding link / link set / path that performs the delay measurement, indicated by the start station ID and end station ID), information about the measurement method, information about the measurement packet (e.g., the packet ID or traffic to be measured), information about the measurement station (e.g., the station ID of the measurement station / node performing the delay measurement), and other relevant information.

[0088] In some configurations, even if the delay measurement configuration is not sent by the reference station / node, the measurement station / node can still trigger delay measurements on its own for scheduling / path selection / optimization purposes.

[0089] As described above, delay measurement configurations can include information about the measurement method. In some configurations, the measurement station / node (e.g., a relay node or a destination station) can perform delay measurements using multiple methods. For example, one method for measuring delay is to use a timestamp inserted into each transmitted packet. In some configurations, the timestamp can be carried by the packet via protocol layer 2 and / or protocol layer 3, such as at the PDCP layer, adaptation layer (e.g., SRAP layer), or IP layer. For each corresponding packet, the timestamp indicates the timing of when the source station generated the corresponding header for each packet, or the timing of when the relay node forwarded each corresponding packet.

[0090] In some configurations, the format and granularity of the timestamps can depend on the timing synchronization source of each station (e.g., source station, relay node, and destination station). For example, in one embodiment, stations within the packet transmission path are synchronized with a common reference source (e.g., higher-layer IEEE 1588 PTP protocol, GNSS). In this case, the delay measurement timestamps adopt the same format and granularity as the common reference source. In another embodiment, stations within the packet transmission path are synchronized on a separate link with a local link clock source (e.g., NR subframe number (SFN) or sidelink direct frame number (DFN)). In this case, the delay measurement timestamps adopt the format and granularity of the station whose timestamp was inserted (e.g., reference station / node 1010 or 1110). In a further embodiment, in the above-described clock source hybrid topology, if the receiving node (e.g., measurement station / node 1020 or 1120) is also synchronized with the same source, the timestamps can adopt the format of either the common reference source or the local link clock source.

[0091] In some configurations, as a timestamp is inserted into each packet, a measurement station / node can perform delay measurement by extracting the timestamp from the received packet and deriving / calculating the timing difference between the timestamp extracted from the packet and the current timestamp. This allows for the measurement of delays (which can be per link, per set of links, or per path).

[0092] Figure 12 The following is an illustration of an example process for performing delay measurements using timestamps in each packet. Process 1200 shows that a reference station / node 1202 (e.g., reference station / node 1010 or 1110), which can be a source station or a relay node, inserts timestamps into packets to be transmitted to a measurement station / node 1204 (e.g., measurement station / node 1020 or 1120), which can be a relay node or a destination station.

[0093] like Figure 12 As shown, in operation 1210, reference station / node 1202 acquires the packet to be transmitted. Specifically, reference station / node 1202 can be a source station, generating the packet to be transmitted, or a relay node, receiving the packet from a connecting station / node (e.g., a source station or a previous connecting relay node). In operation 1220, reference station / node 1202 inserts a timestamp into the packet (e.g., via protocol layer 2 and / or protocol layer 3). In operation 1230, reference station / node 1202 performs packet transmission, transmitting the timestamped packet to measurement station / node 1204. After receiving the packet, measurement station / node 1204 extracts the timestamp from the received packet in operation 1240. In operation 1250, measurement station / node 1204 calculates the timing difference between the timestamp extracted from the packet and the current timestamp to measure the delay.

[0094] Another method for measuring station / node latency is to record the packet transmission latency of each packet. Specifically, the station / node measures packet latency by recording the transmission / reception timings of the first terabyte (TB) and the last terabyte (TB) of the packet. By subtracting the recorded timing difference from the MAC and / or PHY, the packet latency of the corresponding transmission path can be measured without inserting timestamps into the packets.

[0095] Figure 13 This is an example flowchart for delay measurement by recording packet transmission delay. Flowchart 1300 shows that relay node 1315 (i.e., measurement station / node) periodically performs delay measurements between source station 1310 and destination station 1320 at a measurement period N. Relay node 1315 performs delay measurements by recording the start point of packet transmission and counting the delay at the end of packet transmission. Specifically, it is similar to... Figure 7 As shown in process 700, source station 1310 connects to relay node 1315 via Uu interface, and relay node 1315 connects to destination station 1320 via Wi-Fi binding.

[0096] like Figure 13 As shown, source station 1310 sends delay measurement configuration 1330 to relay node 1315 to set the delay measurement to be performed by relay node 1315. Specifically, delay measurement configuration 1330 may be a (pre)configuration of delay measurement for relay node 1315 (as a measurement station / node), indicating that delay measurement is performed periodically with measurement period N. In some configurations, delay measurement configuration 1330 can be sent via RRC message, MAC CE command, or PDCCH. After receiving delay measurement configuration 1330, relay node 1315 configures the delay measurement according to delay measurement configuration 1330.

[0097] Within measurement period N, source station 1310 performs a series of packet transmissions (e.g., sending multiple packets) to relay node 1315. Specifically, in operation 1340, source station 1310 performs the first packet transmission to relay node 1315. After receiving the first packet, relay node 1315 performs the first packet forwarding via Wi-Fi binding in operation 1350, forwarding the first packet to destination station 1320. The packet transmission process continues within measurement period N. In operation 1360, source station 1310 performs the Nth packet transmission to relay node 1315. After receiving the Nth packet, relay node 1315 sets the delay count start point in operation 1365, and relay node 1315 begins recording the timing of the start point (e.g., the timing at the start of the Nth packet forwarding transmission). In operation 1370, relay node 1315 performs the Nth packet forwarding via Wi-Fi binding, forwarding the Nth packet to destination station 1320. In operation 1380, at the end of the delay count (e.g., when the Nth packet forwarding transmission ends), relay node 1315 performs a delay measurement by calculating the timing difference between the start and end points, thereby obtaining the delay without a timestamp.

[0098] In some configurations, when packets are transmitted through a relay node, the relay node can be configured with relay functionality. This relay functionality is triggered when the relay node forwards the packet to the next receiving station / node (e.g., the destination station or the next relay node). Specifically, when the relay functionality is triggered, one or more corresponding operations can be performed on the received packet. Examples of operations performed by the relay functionality include, but are not limited to, timestamp conversion, timestamp extraction and insertion, routing information conversion, and early packet discarding.

[0099] In the timestamp conversion operation, the relay node converts the timestamp in the received packet into a format that the next receiving station can synchronize with the relay node. In some configurations, timestamp conversion can be performed using the following formula (1): Timestamp_ nodeB =a × Timestamp_nodeA +b (1) Here, parameter 'a' represents the timestamp conversion ratio, and parameter 'b' represents the offset. In some configurations, the parameters (i.e., the timestamp conversion ratio 'a' and the offset 'b') are maintained between two neighboring nodes (e.g., nodes A and B), which can periodically exchange timestamps to update the parameters. Alternatively, the relay node can provide the parameters (i.e., the timestamp conversion ratio 'a' and the offset 'b') to the next hop node, allowing the next hop node to perform timestamp conversion accordingly.

[0100] In the timestamp extraction and insertion operation, the relay node extracts the timestamp from the received packet and inserts it into another protocol layer to preserve timing information when the forwarding link uses a different radio access technology than the previous link.

[0101] In the routing information conversion operation, relay nodes retrieve routing information from received packets and convert it into a format recognizable by the forwarding link (e.g., the receiving station). For example, a relay node may retrieve routing information from the SRAP layer of a received packet and convert it into the IP header of that packet.

[0102] In the early packet discarding operation, the relay node checks the delay in the received packet using the timestamp as the current packet transmission delay and compares it with the PDB (Programmable Depth Block) or a delay threshold. If the current packet transmission delay exceeds the PDB or delay threshold, the packet can be discarded early. Each time a relay node discards a packet early, it collects the early packet discarding rate. Finally, the early packet discarding rate is reported to the source station to improve packet transmission reliability.

[0103] In the operations performed by the aforementioned relay function, timestamp conversion, timestamp extraction and insertion, and packet early discarding operations require the use of timestamps in delay measurement. However, routing information conversion operations can be used when timestamps are used in delay measurement, or when delay measurement is performed by recording packet transmission delays.

[0104] Figure 14 This is an example flowchart for delay measurement via timestamps in a single-hop scenario, where hop nodes synchronize with both the source and destination stations via local link clock sources. Flowchart 1400 shows that in a single-hop scenario, destination station 1420 (i.e., the measurement station / node) connects to source station 1410 via relay node 1415 for delay measurement. Relay node 1415 acts as a hop node, synchronizing locally with source station 1410 via NR link SFN and with destination station 1420 via side link DFN. In other words, relay node 1415 synchronizes with both source station 1410 and destination station 1420 via local link clock sources.

[0105] like Figure 14As shown, in operation 1430, source station 1410 generates a packet to be transmitted (hereinafter referred to as "packet 0") and inserts a timestamp equal to SFN0 into packet 0. In operation 1440, source station 1410 sends packet 0 to relay node 1415. After receiving packet 0, relay node 1415 triggers the relay function in operation 1450, performing timestamp conversion by converting the SFN value (i.e., SFN0) of the timestamp in packet 0 into the corresponding DFN value (i.e., DFN0) of the packet forwarding link clock source. In operation 1460, relay node 1415 sends / forwards packet 0 to destination station 1420. After receiving packet 0, destination station 1420 performs delay measurement in operation 1470 by extracting the timestamp (whose value is DFN0) from packet 0, and calculates the delay as the timing difference between the start time indicated by the timestamp (i.e., DFN0) and the current DFN. In other words, the delay measured at destination station 1420 is (current DFN – DFN0).

[0106] Figure 15 This is an example flowchart for delay measurement via timestamps in a multi-hop scenario, where hop nodes are synchronized using a unified timestamp. Flow 1500 employs a multi-hop scenario, setting up two hop nodes 1520 and 1525 (e.g., relay nodes A and B) between source station 1510 and destination station 1530, and hop nodes 1520 and 1525 are synchronized using a unified timestamp. Destination station 1530 serves as a measurement station / node in flow 1500.

[0107] like Figure 15 As shown, source station 1510 is connected to relay node A 1520 via the Uu interface. Relay node A 1520 is connected to relay node B 1525 via Wi-Fi. Relay node B 1525 is connected to destination station 1530 via the PC5 interface. The network configuration specifies that latency is measured per packet and per path. Latency is measured using timestamps.

[0108] Specifically, to measure per-path latency, source station 1510 inserts a uniform timestamp in the adaptation layer and forwards the packet to relay node A 1520. Relay node A 1520 triggers relay function 1522 upon receiving a packet from source station 1510 to perform a routing information conversion operation. Specifically, within relay function 1522, the adaptation header is decoded, and Layer 2 routing information is extracted. Subsequently, relay function 1522 converts the Layer 2 routing information into corresponding IP routing information and places it in the IP header of the newly generated IP packet. The entire adaptation packet header, including the timestamp information, is retained in the IP payload of the generated IP packet. Then, relay node A 1520 forwards the generated IP packet to relay node B 1525 via Wi-Fi using an IP tunnel. Relay node B 1525 decodes the received IP packet and retrieves the retained adaptation packet. Subsequently, relay node B1525 forwards the adapted packet to destination station 1530 via the PC5 interface. Destination station 1530 receives the packet routed from source station 1510 and obtains the packet with a timestamp. Therefore, the transmission delay per path can be calculated from the timing difference between the unified timestamp received by destination station 1530 and the current timestamp.

[0109] Figure 16 This is a schematic diagram illustrating an example process for delay measurement via timestamps in a multi-hop scenario, where the delay is measured for each link set. Process 1600 employs a multi-hop scenario, setting up multiple hop nodes (e.g., relay nodes) between source station 1610 and destination station 1630. It should be noted that... Figure 16 The source station 1610 shown is a UE. Specifically, Figure 16 Only two hop nodes, 1620 and 1625 (i.e., relay nodes A and B), are shown. Among these hop nodes (including relay nodes A and B and all relay nodes in between), some hop nodes synchronize via a unified PTP timestamp, while others synchronize via a local link clock source. Relay node B 1625 acts as a measurement station / node in process 1600.

[0110] like Figure 16As shown, source station 1610 (e.g., UE) is connected to destination station 1630 via relay node A 1620 and relay node B 1625. Source station 1610 is connected to relay node A 1620 via a PC5 interface. Relay node A 1620 is connected to relay node B 1625 via multiple Layer 3 non-3GPP hop nodes, where the Layer 3 non-3GPP hop nodes are unknown to source station 1610. Relay node B 1625 is connected to destination station 1630 via a PC5 interface. Source station 1610 configures the delay measurement period to be measured per packet and the delay measurement path to be measured per link set, where the link set is configured as the link between relay node A 1620 and relay node B 1625. Delay is measured using timestamps.

[0111] Specifically, source station 1610 first sends the packet to relay node A 1620. To measure per-linkset latency, relay node A 1620's relay function 1622 is triggered to perform timestamp extraction and insertion operations. Specifically, relay node A 1620 inserts a Uniform PTP timestamp into the IP header and forwards the packet via Wi-Fi at the IP transport layer. The IP packet reaches relay node B 1625 after passing through multiple non-3GPP hop nodes. According to the latency measurement configuration, relay node B 1625's relay function 1628 retrieves the timestamp information from the IP header and calculates the timing difference between this timestamp and relay node B 1625's current timestamp to determine the per-linkset latency between relay node A 1620 and relay node B 1625. Subsequently, relay node B 1625 continues to forward the packet to destination device 1630 via the PC5 interface.

[0112] Figure 17 This is a schematic diagram illustrating an example process for delay measurement via self-recording packet transmission delay in a bounded scenario. Process 1700 shows a destination station 1730 (e.g., XR glasses) connected to a source station 1710 (e.g., gNB) in a single-hop scenario via a relay node 1720 (e.g., a smartphone), with delay measurement performed by the destination station 1730. The relay node 1720 acts as the measurement station / node in process 1700.

[0113] like Figure 17 As shown, source station 1710 is connected to destination device 1730 via relay node 1720. Source station 1710 is connected to relay node 1720 via a Uu interface, and relay node 1720 is connected to destination device 1730 via Wi-Fi. The network is configured to perform delay measurement periodically at time intervals and to measure delay path per link, where the link is configured to be the link between relay node 1720 and destination station 1730.

[0114] Specifically, source station 1710 sends packets to relay node 1720. Relay node 1720 forwards the packets to destination station 1730. Within the configured latency measurement period, relay node 1720 records a timing sequence as the starting point for counting before forwarding the packets. Subsequently, relay node 1720 sends the corresponding packets via Wi-Fi binding. Once packet transmission is complete (whether the initial transmission is completed or an ACK is received from destination station 1730), relay node 1720 measures the latency by calculating the timing difference between the starting point and the end point of packet transmission.

[0115] In some configurations, delay measurement reports can be generated using various methods. Specifically, after performing a delay measurement, a delay measurement station / node can generate a delay measurement report to report the delay information to other report receiving stations (e.g., relay nodes and / or source stations). Specifically, the delay measurement report can be encapsulated and transmitted via RRC messages, MAC CE commands, or the physical uplink control channel (PUCCH). In some configurations, delay measurement reports can be transmitted / reported periodically in time slots at (pre)configured intervals, and / or when (pre)configured reporting conditions / thresholds are met (e.g., when the measured delay exceeds a configured reporting threshold), and / or via network-triggered events.

[0116] Figure 18 This is a schematic diagram illustrating an example process for a UE to periodically send delay measurement reports. Flow 1800 shows the periodic sending of delay measurement reports, where UE 1820 acts as a reporting node connected to base station 1810 (e.g., gNB). Base station 1810 can act as a source station, causing UE 1820 to periodically send delay measurement reports to base station 1810.

[0117] like Figure 18 As shown, base station 1810 sends delay report configuration 1830 to UE 1820 to configure the delay measurement reports generated / sent by UE 1820. Specifically, delay report configuration 1830 can be a (pre)configuration for delay measurement reports generated by UE 1820, indicating that delay measurement reports are sent periodically at a reporting cycle. In some configurations, delay report configuration 1830 can be generated by base station 1810 and forwarded to UE 1820 through one or more relay nodes. In some configurations, delay report configuration 1830 can be transmitted via RRC messages, MAC CE commands, or PDCCH. In operation 1840, UE 1820 configures the operation of delay measurement reports according to delay report configuration 1830.

[0118] In operation 1850, at the start of the reporting period, UE 1820 generates a delay measurement report containing the packet delay measured in the delay measurement. At the end of the reporting period, UE 1820 sends delay measurement report 1860 to base station 1810. In operation 1870, at the start of the next reporting period, UE 1820 again generates another delay measurement report containing the packet delay measured in the delay measurement. At the end of the reporting period, UE 1820 sends delay measurement report 1880 to base station 1810. In some configurations, UE 1820 may also send delay measurement reports 1860 and 1880 to other reporting receiving stations.

[0119] Figure 19 This is an example flowchart illustrating how a UE sends a delay measurement report based on a trigger event. Flowchart 1900 shows that a delay measurement report is sent as a trigger event based on (pre)configured reporting conditions. Specifically, UE 1920 is connected as a reporting node to base station 1910 (e.g., gNB), which can be the source station. Therefore, UE 1920 sends a delay measurement report to base station 1910 based on the trigger event (i.e., when the reporting conditions are met).

[0120] like Figure 19 As shown, base station 1910 sends delay report configuration 1930 to UE 1920 to set the configuration of delay measurement reports generated / sent by UE 1920. Specifically, delay report configuration 1930 can be a (pre)configuration for delay measurement reports generated by UE 1920, instructing the delay measurement reports to be sent according to trigger events. In some configurations, delay report configuration 1930 can be generated by base station 1910 and forwarded to UE 1920 through one or more relay nodes. In some configurations, delay report configuration 1930 can be sent via RRC messages, MAC CE commands, or PDCCH. In operation 1940, UE 1920 configures the operation of delay measurement reports according to delay report configuration 1930.

[0121] In operation 1950, UE 1920 determines that a triggering event has occurred, such as a reporting condition being met. Upon triggering, in operation 1960, UE 1920 generates a delay measurement report containing the packet delay measured in the delay measurement. Subsequently, UE 1920 sends the delay measurement report 1970 to base station 1910. In some configurations, UE 1920 may also send the delay measurement report 1970 to other reporting receiving stations.

[0122] In some configurations, delay reporting configurations (e.g., delay reporting configuration 1830 or delay reporting configuration 1930) can be sent via RRC messages, MAC CE commands, or PDCCH. In some configurations, the delay reporting configuration may include one or more fields, including: information on the reporting mode, indicating whether reporting is periodic or event-based; information on the reporting period, indicating the reporting time period if reporting is set to periodic; information on the reporting conditions, indicating the reporting conditions that trigger the event if reporting is set to event-based (e.g., if a delay threshold is set as a reporting condition, a report is triggered when the measured delay exceeds the delay threshold); information on the timer, which can be used to avoid frequent reporting if configured for event-based reporting; and information on the delay reporting receiving station, indicating whether the delay report is distributed to the source station and / or other reporting receiving stations.

[0123] In some configurations, the latency information carried in the latency measurement report may include one or more fields, including: information on bonded mode activation and the latency of the tested packet. Specifically, the bonded mode activation information may be a single-bit field used to indicate whether the reporting UE (e.g., the destination device) is serving in bonded mode.

[0124] In some configurations, the latency content of the tested packet in the latency measurement report may include one or more fields, including: the identifier of the measured latency, information about the tested packet, latency characteristics, latency value, and average throughput. Specifically, the identifier of the measured latency may include information indicating that the latency is per-path latency, per-linkset latency, and / or per-link latency, as well as the identifiers of the measurement start station and the measurement end station. For the tested packet, the information for each packet may be categorized by packet ID, packet size, flow ID, and / or packet QoS classification. In some configurations, each tested packet may also be classified as a control packet or a data packet.

[0125] In some configurations, latency characteristics can be represented by one or more statistical values, including: the average latency of N previously measured packet delays, or the maximum / minimum latency of N previously measured packet delays, where N is a (pre-)configured number or a number determined by the total number of packet delays measured within the reporting period; packet delay jitter; or the standard deviation of previously measured delays.

[0126] In some configurations, reported latency values ​​can be represented in one of the following formats, including: (pre)configured granularity (e.g., for a 30 ms latency, if the granularity is set to 5 ms, the latency value is reported as 6); absolute value (e.g., in milliseconds); difference from PDB (e.g., for a 30 ms latency, if the PDB is 20 ms, the latency value is reported as +10 ms); and interval value (e.g., an interval of latency variation).

[0127] In some configurations, the reported average throughput can be the average throughput of the latency-measured links / link sets / paths. In one embodiment, the average throughput is estimated by dividing the total number of data packet bits by the average latency.

[0128] In some configurations, the delay measurement report may also include side information, such as other binding-related information, such as UE buffer status (to indicate queuing on the binding path), LBT delay or channel busy ratio (if it is an unlicensed band), transmission failure rate (reliability), and / or channel quality report of the binding path.

[0129] Figure 20 This is an example flowchart illustrating how a UE performs latency measurement and sends a latency measurement report. Specifically, process 2000 shows a combination of processes between a source station 2010 (e.g., gNB) and a destination station 2020 (e.g., UE) via a relay node 2015 (e.g., UE) in a protocol layer 2 relay scenario. The destination station 2020 performs latency measurement and generates / sends a latency measurement report to the source station 2010 via protocol layer 2 relay of the relay node 2015.

[0130] like Figure 20 As shown, source station 2010 sends an RRC message 2030 to destination station 2020 via relay node 2015. Specifically, RRC message 2030 carries the delay measurement configuration and delay reporting configuration of destination station 2020. For example, source station 2010 sets the delay measurement configuration to per-packet measurement, with the measurement method being a timestamp set. Further, source station 2010 sets the delay reporting configuration by setting the reporting mode to periodic reporting and setting the reporting delay to true (i.e., enabling delay measurement reporting). In operation 2035, after receiving RRC message 2030, destination station 2020 configures delay measurement and delay reporting according to the delay measurement configuration and delay reporting configuration in RRC message 2030.

[0131] After configuration, source station 2010 can begin sending data packets to destination station 2020 via relay node 2015, enabling destination station 2020 to perform delay measurement and delay reporting. Specifically, in operation 2040, source station 2010 sends data packets to destination station 2020 via relay node 2015. In operation 2050, destination station 2020, according to the delay measurement configuration, begins performing delay measurement based on the timestamp in each packet to measure the packet's transmission delay. In operation 2060, source station 2010 sends another data packet to destination station 2020 via relay node 2015. In operation 2070, destination station 2020, according to the delay measurement configuration, begins performing delay measurement based on the timestamp in the packet to measure the packet's transmission delay. In operation 2080, during the delay reporting period, destination station 2020 calculates the average delay by averaging the previous delay measurement results within the reporting period and generates a delay measurement report by setting the binding mode to true and setting the delay value to the PDB difference in the report. Subsequently, at the end of the reporting period, destination station 2020 sends delay measurement report 2090 to source station 2010 via relay station 2015. In operation 2095, after receiving delay measurement report 2090, source station 2010 performs transmission reconfiguration / adjustment based on the content of delay measurement report 2090.

[0132] As described above, when the source station receives a latency measurement report, it can perform corresponding transport reconfiguration / adaptation based on the content of the report. In some configurations, transport reconfiguration / adaptation can be performed by relay nodes and / or the source station (e.g., gNB) and / or the network to meet service latency requirements (e.g., PDB) and improve user experience.

[0133] In some configurations, examples of reconfiguration / adaptation schemes may include codec rate adaptation, link adaptation, adaptive scheduling, path selection / switching, and routing decisions. In some configurations, these schemes may be implemented independently or in combination. For example, in one embodiment, the source station (e.g., gNB) may reconfigure the codec rate to meet PDB requirements. In another embodiment, the source station (e.g., gNB) may jointly reconfigure the codec rate and perform link adaptation. It should be noted that the concepts of reconfiguration and adaptation are interchangeable, used to adjust transmission attributes based on auxiliary delay information in delay measurement reports. In one embodiment, the reconfiguration option refers to half-state adjustment, and the adaptation option refers to dynamic adjustment.

[0134] In some configurations, codec rate adaptation triggered by receive delay measurement reports adjusts the source encoder behavior, including one or more of the following operations to increase / decrease the data rate: frame rate (frames per second; FPS) adjustment and packet size adjustment. In some embodiments, codec rate adaptation can be configured / signaled via RAN messages (e.g., RRC messages) or higher-layer protocols (such as the IMS protocol).

[0135] In some configurations, link adaptation triggered by the received delay measurement report may include one or more of the following operations to reduce / increase packet transmission delay based on the received delay measurement report: Quadrature Amplitude Modulation (QAM) table adjustment, Modulation and Coding Scheme (MCS) adjustment, and MIMO rank adjustment.

[0136] In some configurations, adaptive scheduling triggered by a received delay measurement report may include one or more of the following operations to reduce / increase packet transmission delay based on the received delay report: Case SL mode 1 (e.g., reconfiguring authorized resources / resource pools); Case SL mode 2 (e.g., reconfiguring resource selection windows and / or reconfiguring resource pool cycles); and Case power saving (e.g., enabling / disabling power-saving related functions to shorten / relax packet transmission timing, such as SL partial awareness and / or DRX; enabling / disabling functions to compress / extend packet transmission duration, such as BWP and / or CA).

[0137] In some configurations, path selection / switching and / or link selection / switching and / or link set selection / switching triggered by a received delay measurement report allows the triggering station (e.g., source station, relay node, or UE) to switch to a path that meets service delay requirements. In one embodiment, when the delay of an indirect path exceeds the PDB requirement, the UE can switch the UL packet transmission path from an indirect path (e.g., a bonded link) to a direct path (e.g., a Uu link). In another embodiment, when the received indirect path delay measurement report meets the PDB requirement, the base station (gNB) can switch the DL packet transmission path from a direct path to an indirect path.

[0138] In some configurations, routing decisions triggered by receive latency measurement reports allow the triggering station to optimize packet routing decisions to meet service latency requirements. Specifically, packet routing is described below.

[0139] In one embodiment, the routing path may be pre-configured by the source station or network. Specifically, upon receiving a delay measurement report, the source station or network updates the per-link / link set / path delay of the current routing topology and reconfigures the packet routing path. In some configurations, if a relay node or destination station reports an early packet drop rate to the source station / network, the source station / network may reconfigure the packet routing path if the early packet drop rate exceeds reliability requirements.

[0140] In another embodiment, the routing path is determined locally by each hop node. For example, each hop node decides the next hop node to forward packets until the packets reach the destination. Routing decisions are made based on the routing algorithm and auxiliary information from each hop node itself. Specifically, upon receiving a delay measurement report, the hop node updates the per-link / link set / path delay of the current routing topology for use in the routing algorithm decision.

[0141] In some configurations, routing / switching decisions can be performed at the per-link level, per-link-set level, per-path level, or a combination of link / link-set / path levels. Examples of routing decision algorithms can be described in several different embodiments. In one embodiment, each packet has a different path transmission based on service requirements and dynamic latency reporting information. In another embodiment, different packets have different routing paths to prioritize services or distribute service load across multiple paths. In yet another embodiment, packets are routed via the path with the shortest latency.

[0142] In some configurations, a station receiving delay measurement reports from other stations can record delays based on the packet transmission topology. In one embodiment, the packet transmission path consists of multiple links and link sets. In this case, the delay associated with each link / link set is recorded. For example, path A consists of ({link 1, delay 1}, {link set 2, delay 2}). In another embodiment, the mesh topology is broken down into multiple per-link / link set / path components, such as link 1, link 2, link set 1, and link set 2. If the reported delay of a link / link set exceeds the target delay requirement for that link / link set, that link / link set is reconfigured as an unavailable component. Therefore, any packet routing path traversing an unavailable link / link set needs to be reconfigured as a new routing path or trigger a relay node reselection event.

[0143] Figure 21 This is an example flowchart illustrating the transmission reconfiguration performed by the source station after receiving a delay measurement report. In process 2100, a destination station 2120 in a multipath scenario is introduced, where the destination station 2120 maintains a connection with the source station 2110 (e.g., gNB) via direct and indirect paths (i.e., via relay node 2115).

[0144] like Figure 21As shown, source station 2110 sends an RRC message 2130 to destination station 2120 to establish a delay measurement configuration and a delay reporting configuration. Specifically, source station 2110 sends an RRC message 2130 to destination station 2120 via relay node 2115 (i.e., the indirect path), and the delay measurement configuration and delay reporting configuration in the RRC message 2130 indicate that packets will be transmitted in the indirect path, and destination station 2120 will report the packet transmission delay of the indirect path. In operation 2140, source station 2110 sends data packets to destination station 2120 via relay node 2115. According to the configuration (i.e., delay measurement configuration and delay reporting configuration), destination station 2120 measures the packet transmission delay, and in operation 2150, destination station 2120 sends a delay measurement report to report the packet transmission delay of the indirect path. In operation 2160, after receiving the delay measurement report from destination station 2120, source station 2110 performs a path switching decision as a transmission reconfiguration / adaptation. Specifically, source station 2110 can decide to reconfigure the data transmission path to the direct path based on the delay information of the indirect path in the delay measurement report to meet the packet transmission delay requirements. After the path switching decision in operation 2170, source station 2110 sends subsequent packets to destination station 2120 through the direct path.

[0145] In some configurations, delay measurements are performed on a packet-by-packet basis. Specifically, for each packet used for delay measurement, there may be two types: control packets (e.g., ping packets) and data packets. In some configurations, control packets may be MAC CE control packets or PDCP control packets. Specifically, control packets used for delay measurement allow delay measurements to be performed in fixed-bit packets. The delay measured for control packets may reflect the channel queuing delay, buffering delay, in-site processing delay, and / or channel access delay of the measured link / link set / path. In some configurations, the measured delay may be considered as the minimum expected hop / relay delay of the measured link / link set / path.

[0146] On the other hand, data packets can also be used for latency measurement. The latency measured for data packets can reflect channel queuing latency, buffering latency, intra-site processing latency, inter-site transmission latency, channel access latency, and the time required to download data on the channel of the measured link / link set / path. In some configurations, the time required to download data on the channel may vary due to channel quality.

[0147] In some configurations, a measurement station / node can collect complete delay information for the measured link / link set / path by measuring the delays of control and data packets. Specifically, queuing delay and processing delay are collected through control packet measurements. The time delay required to download data on the channel is collected as the difference between the measurements of data and control packets. Furthermore, using the number of bits in the data packets, the measurement station can estimate the average channel throughput of the measured link / link set / path. Finally, with the aid of minimum expected hop / relay delay and average channel throughput, the station receiving this aided information can perform transmission reconfiguration (e.g., per-link / link set / path selection) while taking into account the size of the packets to be transmitted.

[0148] In one embodiment, when a station has a large data packet to transmit, the station can calculate the expected packet transmission delay of a candidate path by adding the minimum expected hop / relay delay of the path to the time delay required to download data on the channel based on the average channel throughput of that path. The station can then select the path with the minimum total delay as the packet transmission path.

[0149] In another embodiment, when a station has a small control packet to transmit, the station can use only the minimum expected hop / relay delay of the path as the expected packet transmission delay for candidate paths. Then, the station can select the path with the minimum delay value as the packet transmission path.

[0150] In some configurations, centralized and decentralized approaches to transport reconfiguration can be provided. Specifically, UE-assisted latency measurement and reporting for bonded / multi-hop / mesh topologies can be further divided into two functional modes: centralized (coordinated) mode or decentralized mode.

[0151] In some configurations, under centralized mode, a central control station / node in a bound / multi-hop / mesh topology is responsible for sending delay measurement configurations and delay reporting configurations to one or more stations / nodes in the topology. In this case, the station / node designated to perform delay measurements can send a delay measurement report back to the central control station / node according to the configuration. The central control station / node can then make transmission reconfiguration decisions for the stations / nodes in the topology based on the received auxiliary delay measurement reports. In one embodiment, the central control node / station instructs neighboring node A to switch its packet forwarding node as the routing decision based on auxiliary delay information. Neighboring node A then passively follows the instructions of the central control station / node and reconfigures its packet forwarding node.

[0152] In some configurations, in distributed mode, each station and / or node actively measures latency to collect packet latency information. Specifically, the measuring station and / or node can perform transmission reconfiguration based on its measurement results. The measuring station and / or node can generate auxiliary latency measurement reports and send these reports to other nodes / stations in a bound / multi-hop / mesh topology. Based on the auxiliary latency measurement reports received from other nodes / stations in the topology, nodes / stations can perform transmission reconfiguration. In one embodiment, a node / station can actively and dynamically select a packet forwarding node as a routing decision based on its measured latency and auxiliary latency reports received from neighboring nodes.

[0153] Figure 22 This is a flowchart of a UE wireless communication method (procedure). Procedure 2200 can be executed by a UE, which can operate as a destination station (e.g., destination station 730, 830, 930, 1320, 1420, 1530, 1630, 1730, 1820, 1920, 2020, or 2120) or a relay node (e.g., relay node 720, 820, 920, 1315, 1415, 1520, 1525, 1620, 1625, 1720, 2015, or 2115). In procedure 2210, the UE receives multiple packets from a forwarding station. This forwarding station is a source station or a connection relay node in the network, and the UE acts as the destination station or relay node. In procedure 2220, the UE performs delay measurements on these packets according to a delay measurement configuration to obtain the delay of these packets. In procedure 2230, the UE generates a delay measurement report containing the measured delays of such packets, and sends the delay measurement report to one or more report receiving stations according to the delay report configuration.

[0154] In some configurations, the UE also receives the delay measurement configuration and the delay reporting configuration from the forwarding station. The delay measurement configuration and the delay reporting configuration can be received via RRC messages, MAC CE commands, or PDCCH.

[0155] In some configurations, each received corresponding packet includes a timestamp representing the timing of the header generation of each corresponding packet by the source station, or the timing of the relay node forwarding each corresponding packet. The UE extracts this timestamp from each corresponding packet. The UE performs the delay measurement by calculating the timing difference between the extracted timestamp and the current timestamp. In one embodiment, the timestamp is extracted from protocol layer 2 or protocol layer 3 of each corresponding packet.

[0156] In some configurations, the UE operates as a relay node. Within this relay node, the UE triggers a relay function, which performs one or more operations on received packets. The UE forwards the received packets to a receiving station, which is either the destination station or the next relay node. In some embodiments, the operations performed by the relay function include: converting the timestamp of each received packet to a format synchronized between the receiving station and the relay node; extracting the timestamp from each received packet and inserting the extracted timestamp into a different protocol layer of each packet; retrieving routing information from the received packets and converting the routing information to a format recognizable by the receiving station; and, in response to determining that the transmission delay of the current packet exceeds the PDB or a delay threshold based on the timestamp of the corresponding packet in the packet, prematurely discarding the corresponding packet and collecting statistical information on the premature packet discard rate.

[0157] In some configurations, the UE receives a second delay measurement report from the connection station. In response to receiving the second delay measurement report, the UE performs transmission reconfiguration based on the second delay measurement report.

[0158] In some configurations, the UE performs this delay measurement by recording the packet transmission delay of each packet.

[0159] In some configurations, the delay measurement report is encapsulated and sent to one or more report receiving stations as an RRC message, MAC CE command, or PUCCH.

[0160] In some configurations, the delay measurement report is sent periodically, or when reporting conditions are met, or based on a trigger event.

[0161] In some configurations, the latency measurement report includes at least one of the following: the measured latency of the packet, the identifier of the measured packet, and the identifier of the measured link, link set, or path.

[0162] Figure 23 This is a flowchart of a wireless communication method (process) for a network source station. Process 2300 can be executed by a source station of the network (e.g., a base station, gNB), such as source station 710, 810, 910, 1310, 1410, 1510, 1610, 1710, 1810, 1910, 2010, or 2110. In process 2310, the source station sends multiple packets to the UE or a relay node. In process 2320, the source station receives a delay measurement report from the UE or a relay node. In process 2330, in response to receiving the delay measurement report, the source station performs transmission reconfiguration based on the delay measurement report.

[0163] In some configurations, the source station sends delay measurement configuration and delay reporting configuration to the UE or relay node. These configurations can be received via RRC messages, MAC CE commands, or PDCCH.

[0164] In some configurations, each packet is either a control packet or a data packet.

[0165] In some configurations, this latency measurement is performed per link and / or per link set and / or per path packet transmission.

[0166] In some configurations, transport reconfiguration includes at least one of the following: codec rate adaptation, link adaptation, adaptive scheduling, path selection / switching or link selection / switching, and routing decision.

[0167] It should be understood that the specific order or hierarchy of blocks in the disclosed process / flowchart is merely exemplary. The specific order or hierarchy of blocks in the process / flowchart may be rearranged according to design preferences. Furthermore, some blocks may be combined or omitted. The accompanying method claims present the block elements in an exemplary order and are not limited to the specific order or hierarchy shown.

[0168] The foregoing description is intended to enable those skilled in the art to implement the various aspects described herein. Those skilled in the art will be able to readily make various modifications to these aspects, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to limit the aspects shown herein, but rather to impose a full scope consistent with the language of the claims, wherein, unless explicitly stated otherwise, a singular reference to an element does not mean “only one,” but rather “one or more.” The term “exemplary” as used herein means “as an example, instance, or illustration.” Any aspect described as “exemplary” is not necessarily to be construed as superior to other aspects. Unless explicitly stated otherwise, the term “some” means one or more. Combinations such as “at least one A, B, or C,” “one or more A, B, or C,” “at least one A, B, and C,” “one or more A, B, and C,” and “A, B, C, or any combination thereof” include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Specifically, combinations such as "at least one A, B, or C", "one or more A, B, or C", "at least one A, B, and C", "one or more A, B, and C", and "A, B, C, or any combination thereof" can be only A, only B, only C, A and B, A and C, B and C, or A, B, and C, wherein any such combination may include one or more members of A, B, or C. All known or hereafter known structural and functional equivalents of the elements of the various aspects described in this specification are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, the disclosure herein is not intended for public disclosure, whether or not such disclosure is expressly stated in the claims. Terms such as "module," "mechanism," "element," and "device" may not be substitutes for the word "means." Therefore, no element of a claim should be construed as means plus function unless the element expressly uses the phrase "means for...".

Claims

1. A wireless communication method for a user equipment, comprising: Receive multiple packets from a forwarding station, where the forwarding station is the source station or connection relay node of the network, and the user equipment is the destination station or relay node; The delay of these packets is measured according to the delay measurement configuration to obtain the delay of these packets; as well as Generate a delay measurement report containing the measured delays of the packets, and send the delay measurement report to one or more report receiving stations according to the delay report configuration.

2. The method of claim 1, further comprising: Receive the delay measurement configuration and the delay report configuration from the relay station. The delay measurement configuration and the delay reporting configuration are received via radio resource control messages, media access control element commands, or physical downlink control channels.

3. The method of claim 1, wherein each of the packets is a control packet or a data packet.

4. The method of claim 1, wherein the delay measurement is performed for packet transmission per link and / or per link set and / or per path.

5. The method of claim 1, wherein each of the received packets includes a timestamp indicating the timing of the generation of the header of each packet by the source station, or the timing of the forwarding of each packet by the relay node.

6. The method of claim 5, further comprising: Extract the timestamp from each corresponding packet; as well as The delay is measured by calculating the time difference between the extracted timestamp and the current timestamp.

7. The method of claim 6, wherein the timestamp is extracted from protocol layer 2 or protocol layer 3 of each corresponding packet.

8. The method of claim 5, wherein the user equipment acts as the relay node, and the method further comprises: Within the relay node, a relay function is triggered, wherein the relay function performs one or more operations on the received packets; as well as The received packets are forwarded to the receiving station, which is either the destination station or the next relay node.

9. The method of claim 8, wherein the one or more operations performed by the relay function include: Convert the timestamp of each received packet to a format synchronized between the receiving station and the relay node; Extract the timestamp from each of the received packets and insert the extracted timestamp into the different protocol layers of each packet; Retrieve routing information from the received packets and convert the routing information into a format recognizable by the receiving station; as well as In response to determining that the current packet transmission delay exceeds the packet delay budget or delay threshold based on the timestamp of the corresponding packet in the packets, the corresponding packet is dropped early, and statistical information on the packet early drop rate is collected.

10. The method of claim 8, further comprising: Receive a second delay measurement report from the connection station; as well as In response to receiving the second delay measurement report, a transmission reconfiguration is performed based on the second delay measurement report.

11. The method of claim 1, further comprising: This delay measurement is performed by recording the packet transmission delay of each such packet.

12. The method of claim 1, wherein the delay measurement report is encapsulated and sent to the one or more report receiving stations as a radio resource control message, a medium access control element command, or a physical uplink control channel.

13. The method of claim 1, wherein the delay measurement report is sent periodically, or when a reporting condition is met, or based on a triggering event.

14. The method of claim 1, wherein the delay measurement report comprises at least one of the following: The measured delay of these packets, The identifiers of these packets were measured, and Identifiers of the measured links, link sets, or paths.

15. A wireless communication method for a network source station, comprising: Send multiple packets to user equipment or relay nodes; Receive a delay measurement report from the user equipment or the relay node; as well as In response to receiving the delay measurement report, transmission reconfiguration is performed based on the delay measurement report.

16. The method of claim 15, further comprising: Send delay measurement configuration and delay report configuration to the user equipment or the relay node. The delay measurement configuration and the delay reporting configuration are transmitted via radio resource control messages, media access control element commands, or physical downlink control channels.

17. The method of claim 15, wherein each of the packets is a control packet or a data packet.

18. The method of claim 15, wherein each of the received packets includes a timestamp indicating the header timing of the originating station generating each packet.

19. The method of claim 15, wherein the delay measurement report is encapsulated and received as a radio resource control message, a medium access control element command, or a physical uplink control channel.

20. The method of claim 15, wherein the transmission reconfiguration comprises at least one of the following: Adaptive encoding / decoding rate Link adaptation, Adaptive scheduling Path selection / switching or link selection / switching, and Routing decision.

Images