Method and apparatus for quality of service (QoS) information modification in a wireless communication system

Abstract

A method and apparatus for modifying quality of service information from the perspective of a remote user equipment is disclosed. In one embodiment, the method includes the remote user equipment transmitting a first message to a relay user equipment for quality of service information modification, wherein the first message includes at least one quality of service rule and / or at least one quality of service flow description associated with a protocol data unit session.

Description

[0001] Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 082,226, filed September 23, 2020, and U.S. Provisional Patent Application No. 63 / 082,243, filed September 23, 2020, the entire disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to wireless communication networks, and more specifically, to a method and apparatus for modifying Quality of Service (QoS) information in a wireless communication system. Background Technology

[0004] With the rapid growth in demand for transmitting large amounts of data to and from mobile communication devices, traditional mobile voice communication networks have evolved into networks that communicate with Internet Protocol (IP) packets. This type of IP packet communication provides users of mobile communication devices with IP-bearing voice, multimedia, multicast, and video-on-demand communication services.

[0005] An exemplary network architecture is the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). E-UTRAN systems can provide high data throughput to enable the aforementioned IP-based voice and multimedia services. Currently, the 3GPP standards organization is discussing new next-generation (e.g., 5G) radio technologies. Therefore, changes to the current body of the 3GPP standards are being submitted and considered to evolve and finalize the 3GPP standards. Summary of the Invention

[0006] This invention discloses a method and apparatus for modifying QoS information from the perspective of a remote user equipment (UE). In one embodiment, the method includes the remote user equipment (UE) transmitting a first message to a relay UE for QoS information modification, wherein the first message includes at least one QoS rule and / or at least one QoS flow description associated with a Protocol Data Unit (PDU) session. Attached Figure Description

[0007] Figure 1 A diagram illustrating a wireless communication system according to an exemplary embodiment is shown.

[0008] Figure 2 This is a block diagram of a transmitter system (also referred to as an access network) and a receiver system (also referred to as a user equipment or UE) according to an exemplary embodiment.

[0009] Figure 3 This is a functional block diagram of a communication system according to an exemplary embodiment.

[0010] Figure 4 According to an exemplary embodiment Figure 3 Functional block diagram of the program code.

[0011] Figure 5 For 3GPP TR 23.752V0.4.0 Figure 6 Reproduction of .24.1-1.

[0012] Figure 6 For 3GPP TR 23.752V0.4.0 Figure 6 Reproduction of .25.1-1.

[0013] Figure 7 For 3GPP TS 23.287V16.2.0 Figure 5 Reproduction of 4.1.1.1-1.

[0014] Figure 8 For 3GPP TS 23.287V16.2.0 Figure 5 Reproduction of 4.1.1.3-1.

[0015] Figure 9 For 3GPP TS 23.287V16.2.0 Figure 6 Reproduction of .3.3.1-1.

[0016] Figure 10 For 3GPP TS 23.287V16.2.0 Figure 6 Reproduction of .3.3.4-1.

[0017] Figure 11 For 3GPP TS 23.502V16.5.1 Figure 4 Reproduction of .3.2.2.1-1.

[0018] Figure 12 For 3GPP TS 23.502V16.5.1 Figure 4 Reproduction of .3.3.2-1.

[0019] Figure 13 This is a reproduction of Table 8.3.7.1.1 of 3GPP TS 24.501V16.5.1.

[0020] Figure 14 This is a flowchart according to an exemplary embodiment. Specific Implementation

[0021] The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication, such as voice and data. These systems may be based on Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Orthogonal Frequency Division Multiple Access (OFDMA), 3GPP Long Term Evolution (LTE) radio access, 3GPP Long Term Evolution Advanced (LTE-A or Advanced LTE), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation techniques.

[0022] Specifically, the exemplary wireless communication systems and apparatus described below can be designed to support standards, such as one or more standards provided by a consortium referred to herein as 3GPP, known as the "3rd Generation Partnership Project," including TS 23.303V16.0.0, "Property Services (ProSe); Phase 2 (Revision 16)"; TR 23.752V0.4.0, "System Enhancement Study for Proper Services (ProSe) in 5G Systems (5GS) (Revision 17)"; TS 23.287V16.2.0, "Architectural Enhancements Enabling 5G Systems (5GS) to Support Vehicle-to-Everything (V2X) Services (Revision 16)"; TS23.502V16.5.1, "5G System (5GS) Procedure; Phase 2 (Revision 16)"; TS TS 24.501V16.5.1, “Non-Access-Stratum (NAS) of 5G Systems (5GS); Phase 3 (Revision 16)”; and TS 23.501v16.5.1, “System Architecture of 5G Systems (5GS); Phase 2 (Revision 16)”. The standards and documents listed above are hereby expressly incorporated in their entirety by reference.

[0023] Figure 1 A multiple access wireless communication system according to an embodiment of the present invention is illustrated. Access network 100 (AN) includes multiple antenna groups, one group comprising 104 and 106, another group comprising 108 and 110, and an additional group comprising 112 and 114. Figure 1In this diagram, only two antennas are shown in each antenna group; however, each antenna group may utilize more or fewer antennas. Access terminal 116 (AT) communicates with antennas 112 and 114, which transmit information to AT 116 via forward link 120 and receive information from AT 116 via reverse link 118. Access terminal (AT) 122 communicates with antennas 106 and 108, which transmit information to AT 122 via forward link 126 and receive information from AT 122 via reverse link 124. In a Frequency Division Duplex (FDD) system, communication links 118, 120, 124, and 126 may use different frequencies for communication. For example, forward link 120 may use a frequency different from that used by reverse link 118.

[0024] Each antenna group and / or the area in which the antenna groups are designed to communicate is often referred to as a sector of the access network. In an embodiment, each antenna group is designed to communicate with an access terminal in a sector of an area covered by access network 100.

[0025] In communications via forward links 120 and 126, the transmit antennas of access network 100 can utilize beamforming to improve the signal-to-noise ratio of the forward links used for different access terminals 116 and 122. Furthermore, compared to an access network that transmits to all its access terminals via a single antenna, an access network that uses beamforming to transmit to access terminals randomly distributed within its coverage area causes less interference to access terminals in neighboring cells.

[0026] An access network (AN) can be a fixed station or base station used for communication with terminals, and may also be referred to as an access point, Node B, base station, enhanced base station, evolved Node B (eNB), network node, network, or other terms. An access terminal (AT) may also be referred to as a user equipment (UE), wireless communication device, terminal, access terminal, or other terms.

[0027] Figure 2 This is a simplified block diagram of an embodiment of a Multiple Input Multiple Output (MIMO) system 200, specifically a transmitter system 210 (also referred to as an access network) and a receiver system 250 (also referred to as an access terminal (AT) or user equipment (UE)). At the transmitter system 210, service data for multiple data streams is provided from a data source 212 to a transport (TX) data processor 214.

[0028] In one embodiment, each data stream is transmitted via a corresponding transmit antenna. The TX data processor 214 formats, encodes, and interleaves the service data of each data stream based on a specific encoding scheme selected for the data stream to provide encoded data.

[0029] Orthogonal Frequency Division Multiplexing (OFDM) technology can be used to multiplex the coded data and pilot data of each data stream. The pilot data is typically a known data pattern processed in a known manner and can be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data of each data stream are then modulated (i.e., symbol-mapped) based on a specific modulation scheme selected for the data stream (e.g., Binary Phase Shift Keying (BPSK), Quadrature Phase Shift Keying (QPSK), Multiple Phase Shift Keying (M-PSK), or Quadrature Amplitude Modulation (M-QAM)). The data rate, coding, and modulation of each data stream can be determined by instructions executed by processor 230.

[0030] The modulation symbols of all data streams are then provided to the TX MIMO processor 220, which can further process the modulation symbols (e.g., for OFDM). The TX MIMO processor 220 then... T A modulation symbol stream is provided to N T Transmitters (TMTRs) 222a to 222t. In some embodiments, the TX MIMO processor 220 applies beamforming weights to the symbols of the data stream and to the antennas transmitting symbols from it.

[0031] Each transmitter 222 receives and processes a corresponding symbol stream to provide one or more analog signals, and further modulates (e.g., amplifies, filters, and upconverts) the analog signals to provide modulated signals suitable for transmission over a MIMO channel. Subsequently, from N... T Antennas 224a to 224t transmit N from transmitters 222a to 222t. T A modulated signal.

[0032] At receiver system 250, by N REach antenna 252a to 252r receives the transmitted modulated signal and provides the signal received from each antenna 252 to a corresponding receiver (RCVR) 254a to 254r. Each receiver 254 modulates (e.g., filters, amplifies, and down-converts) the corresponding received signal, digitizes the modulated signal to provide a sample, and further processes the sample to provide a corresponding "received" symbol stream.

[0033] The RX data processor 260 then receives and processes data from N based on specific receiver processing technology. R N received by 254 receivers R A symbol stream to provide N T Each detected symbol stream is then demodulated, deinterleaved, and decoded by the RX data processor 260 to recover the service data of the data stream. The processing performed by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and TX data processor 214 at the transmitter system 210.

[0034] Processor 270 periodically determines which precoding matrix to use (discussed below). Processor 270 formulates a reverse link message that includes the matrix index portion and the rank portion.

[0035] The reverse link message may include various types of information about the communication link and / or the received data stream. The reverse link message is then processed by the TX data processor 238, which also receives service data from multiple data streams from the data source 236, modulated by the modulator 280, regulated by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

[0036] At transmitter system 210, the modulated signal from receiver system 250 is received by antenna 224, conditioned by receiver 222, demodulated by demodulator 240, and processed by RX data processor 242 to obtain the reverse link message transmitted by receiver system 250. Processor 230 then determines which precoding matrix to use to determine beamforming weights and then processes the acquired message.

[0037] Turning Figure 3 This figure illustrates an alternative simplified functional block diagram of a communication device according to an embodiment of the present invention. Figure 3 As shown, this can be achieved using the communication device 300 in a wireless communication system. Figure 1 UE (or AT) 116 and 122 or Figure 1The communication device 300 includes a base station (or AN) 100, and the wireless communication system is preferably an NR system. The communication device 300 may include an input device 302, an output device 304, a control circuit 306, a central processing unit (CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by a user via the input device 302 (e.g., a keyboard or keypad) and can output images and sounds via the output device 304 (e.g., a display or speaker). The transceiver 314 is used to receive and transmit wireless signals, transmit the received signals to the control circuit 306, and wirelessly output the signals generated by the control circuit 306. Alternatively, the communication device 300 in a wireless communication system can also be used. Figure 1 AN 100 in the middle.

[0038] Figure 4 According to an embodiment of the present invention, in Figure 3 A simplified block diagram of program code 312 is shown below. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 typically performs radio resource control. Layer 2 portion 404 typically performs link control. Layer 1 portion 406 typically performs physical connections.

[0039] 3GPP TS 23.303 specifies UE-to-network relay discovery for public safety use. Both Model A discovery and Model B discovery are supported for discovering UE-to-network relays.

[0040] 3GPP TR 23.752 proposes the following solutions to support UE-to-network relay for version 17:

[0041] Solution 6.16 #16: Service Authorization and Provisioning for UE-to-Network Relay

[0042] 6.16.1 Overview

[0043] The procedures used for service authorization and provisioning are based on the V2X procedures for service authorization and provisioning as specified in Clause 6.2 of TS 23.287[5].

[0044] Editor's Note: This solution is for Layer 3 UE to network relay. Whether this solution can also be used for Layer 2 UE to network relay requires further investigation.

[0045] 6.16.2 PCF-based service authorization and pre-configuration for UE-to-network relay

[0046] For PCF-based service authorization and provisioning for UE-to-network relay, the registration procedure as defined in Clause 4.2.2.2 of TS 23.502[8], the UE policy association establishment procedure as defined in Clause 4.16.11 of TS 23.502[8], and the UE policy association modification procedure as defined in Clause 4.16.12 of TS 23.502[8] shall apply in the following additional circumstances:

[0047] For UE to network relay:

[0048] -UE indicates the UE's network relay capability in the registration request message.

[0049] -PCF determines the UE-to-network relay parameters used for UE-to-network relay and provides them to UE-to-network relay as described in Solution #17.

[0050] For remote UEs:

[0051] -UE indicates the UE's network relay access capability in the registration request message.

[0052] -PCF determines the parameters used by the remote UE to relay to the network and provides them to the remote UE as described in Solution #17.

[0053] 6.16.3 Authorization and configuration parameters for UE to network relay

[0054] Provide the following UE-to-network relay parameters to UE-to-network relay:

[0055] 1) Authorization policy used for UE-to-network relay:

[0056] - A Public Land Mobile Network (PLMN) where the UE is authorized to provide remote UE relay services.

[0057] 2) UE to network relay discovery strategy / parameters:

[0058] -UE to network relay service code or service ID, which identifies the connectivity service provided by UE to network relay.

[0059] - The associated PDU session parameters (S-NSSAI, DNN, SSC mode, etc.) will be used for each UE's relay service to the network relay service code or service ID.

[0060] Note 1: Whether associated PDU session parameters are included depends on the UE-to-network relay discovery solution. For example, if the associated PDU session parameters can be broadcast via the relay service code in the PC5 interface, then these parameters may not require pre-configuration.

[0061] Note 2: The NSSAI configured for UE to network relay includes the S-NSSAI required to support relay services for associated service codes or service IDs.

[0062] Editor's Note: Further research is needed on the details of UE to network relay slice configuration updates.

[0063] - Security-related parameters for UE-to-network relay discovery for each UE-to-network relay service code or service ID.

[0064] Note 3: Further details regarding security requirements will be specified in SA WG3.

[0065] Provide the following UE-to-network relay parameters to the remote UE:

[0066] 1) Acting as an authorization policy for remote UEs:

[0067] - Indicates whether the UE is authorized to use the UE to relay to the network.

[0068] 2) Provide UE-to-network relay discovery policies / parameters;

[0069] - List of authorized UE to network relay service codes / IDs.

[0070] - PDU session parameters (S-NSSAI, DNN, SSC mode, etc.) associated with each UE to the network relay service code or service ID.

[0071] Note 4: Whether associated PDU session parameters are included depends on the UE-to-network relay discovery solution. For example, if the associated PDU session parameters can be broadcast via the relay service code in the PC5 interface, then these parameters may not require pre-configuration.

[0072] -UE to network relay selection strategy.

[0073] Editor's Note: Further research is needed to determine the details of the UE-to-network relay selection strategy.

[0074] Note 5: This clause specifies only the UE-to-network relay service-specific parameters. All other parameters used for general authorization and configuration parameters (e.g., radio parameters used for discovery or communication) will be defined by the solution for KI 8.

[0075] Note 6: This solution does not support off-site operations of NW trunks that are outside coverage or for public safety purposes.

[0076] [...]

[0077] Solution 6.24 #24: End-to-end QoS support for Layer 3 UE to network relay

[0078] 6.24.1 General Description

[0079] This solution addresses key issue #3, “Supporting UE-to-Network Relay.” Specifically, this solution addresses the questions of “how to support end-to-end requirements between remote UEs and the network via UE-to-network relay, including QoS (e.g., data rate, reliability, latency)” and “how the network allows and controls the QoS requirements for 5G ProSe UE-to-NW relay.”

[0080] In the Layer 3 UE to NW trunk solution (Solution #6), the data flow of the remote UE is served by the PDU session of the trunk UE. The UE to network trunk path includes the following... Figure 6 The two branches (PC5 and Uu) shown in .24.1-1 can only satisfy end-to-end QoS if the QoS requirements are correctly divided and meet the requirements of the two branches respectively.

[0081] [3GPP TR titled "End-to-End QoS Allocation for Layer 3 UE to Network Relay Solution"]

[0082] 23.752V0.4.0 Figure 6 .24.1-1 reproduced as Figure 5 ]

[0083] The QoS requirements for PC5 links are controlled using the PC5 QoS rules and PC5 QoS parameters (PQI, GFBR, MFBR, PC5 LINK-AMBR, range, etc.) specified in Clause 5.4 of TS 23.287[5]. The QoS requirements for Uu links are controlled using the 5G QoS rules and 5G QoS parameters (5QI, GFBR, MFBR, etc.) specified in Clause 5.7 of TS 23.501[6].

[0084] The QoS of the Uu tributary is associated with the PDU session established by the UE to the network relay, and therefore the procedures defined in Clauses 4.3.2 and 4.3.3 of TS 23.502[8] apply. The UE to network relay's Session Management Function (SMF) provides the corresponding QoS rules and flow-level QoS parameters to the UE to network relay.

[0085] As explained above, UE-to-network relay requires converting Uu QoS information into corresponding PC5 QoS parameters to achieve appropriate end-to-end QoS. Since remote UEs and UE-to-network relays use PC5 unicast communication mode, most flow-level QoS parameters can be directly reused. The only parameter requiring assistance in the conversion is the mapping between 5QI and PQI. Therefore, UE-to-network relay must be configured with appropriate mapping information.

[0086] Note: The UE can be configured with a mapping of 5QI and PQI based on each relay service code to the network relay.

[0087] Based on the information received from the SMF, the UE establishes a corresponding PC5 QoS flow to the network relay using the procedure defined in Clause 6.3.3.4 of TS 23.287[5]. A one-to-one mapping may exist between the PC5 QoS flow and the Uu QoS flow for the remote UE.

[0088] When a remote UE requests a dedicated PC5 QoS flow when establishing an L2 link on PC5, the UE can map the PC5 QoS request to the Uu QoS request and perform the UE-requested PDU session modification as defined in Clause 4.3.3 of TS 23.502[8].

[0089] 6.24.2 Enhancements to support dynamic QoS processing

[0090] like Figure 6 As shown in .24.1-1, the end-to-end connection from the remote UE to the AS involves two air links, namely Uu and PC5. Therefore, to meet the PDB requirements for a specific service, the AN PDB utilized by the NG-RAN needs to be reduced to allocate some budget for the PC5 link. It should be noted that this is independent of whether an L2 or L3 trunk architecture is used.

[0091] One way to achieve this without affecting NG-RAN is to modify the PDB (Power Deposit Parameter) signaled to NG-RAN in the QoS profile of the QoS flow for services used by remote UEs, for the SMF. The SMF deducts the PDB according to PCC rules (if it is a deterministic PCF) or based on local configuration.

[0092] When dynamic PCC control is supported, the SMF can determine the PDB to use based on PCC rules. Otherwise, the SMF can determine whether and how to modify the PDB based on pre-configuration, such as using a DNN and / or S-NSSAI.

[0093] When dynamic PCC control is supported, the AF may be able to request certain QoS processing for a service when a remote UE initiates a session. This can be achieved by using features as defined in Clause 6.1.3.22 of TS 23.503

[18] . The AF can locate the PCF of the UE to the network trunk using procedures as defined in Clause 6.1.1.2 of TS 23.503

[18] because the remote UE uses an address belonging to the PDU session of the UE to the network trunk.

[0094] The PCF can generate corresponding PCC rules, and the SMF generates QoS rules and flow-level QoS parameters, and uses the PDU session modification procedure to signal the UE to the network relay. The UE then uses the L2 link modification procedure defined in Clause 6.3.3.4 of TS 23.287[5] to set the relevant PC5 QoS flow.

[0095] 6.24.2 Procedure

[0096] Existing procedures defined in TS 23.502[8] and TS 23.287[5] can be used to manage QoS streams and PC5 QoS streams to serve remote UEs.

[0097] 6.24.3 Impact on services, entities, and interfaces

[0098] The solution has an impact on the following entities:

[0099] SMF:

[0100] -SMF optionally supports PDBs for QoS flows used to serve remote UEs, based on PCC rules or pre-configured modifications.

[0101] UE:

[0102] -5G ProSe UE to network relay supports mapping of Uu flow-level QoS parameters to PC5 QoS parameters, including 5QI to PQI mapping based on configuration or standardized mapping.

[0103] Solution 6.25 #25: QoS Processing for Layer 3 UE to Network Relay

[0104] 6.25.1 Description

[0105] This is a solution for critical issue #3 UE to network relay, specifically for QoS control of Layer 3 UE to network relay.

[0106] For remote UEs accessing the network via a network relay, QoS control between the remote UE and the UPF comprises two parts: one part is the QoS control for the connection between the remote UE and the network relay, and the other part is the QoS control for the connection between the network relay and the UPF. In this solution, the PCF is responsible for separately setting the QoS parameters between the UE and the network relay (referred to as "PC5 QoS parameters") and the QoS parameters between the network relay and the UPF (referred to as "Uu QoS parameters") to support the QoS requirements between the remote UE and the UPF.

[0107] For the PC5 interface, when using the standardized PQI, the PC5 QoS parameters include the PQI and other optional QoS parameters, such as GFBR. When using the non-standardized PQI, it also includes the complete set of PC5 QoS features.

[0108] PCF ensures that the PDB associated with 5QI in the Uu QoS parameters and the PDB associated with PQI in the PC5 QoS parameters support PDB between the remote UE and the UPF. PCF also ensures that other QoS parameters / QoS features in the Uu QoS parameters and PC5 QoS parameters are compatible, for example, having the same value.

[0109] The UE to network trunk and remote UE is pre-configured with one or more authorized services and associated PC5 QoS parameters. These services and parameters can be provided by the PCF during the configuration process. The PCF can also provide default PC5 QoS parameters to NW trunk and remote UEs, which can be used for remote UEs outside coverage or for applications that are not frequently used.

[0110] When a remote UE wants to use a service provided by an AF through a 3GPP network, it selects a network relay and establishes a PC5 connection between the remote UE and the NW relay. If the remote UE does not have the PC5 QoS parameters for the service, then the default PC5 QoS flow is set using the default PC5 QoS parameters in the configuration information.

[0111] UE-to-network relay also includes, for example, setting up a corresponding PDU session for relay based on S-NSSAI and DNN requests from remote UEs. After IP address / prefix allocation, UE-to-network relay reports the IP information of the remote UE to the SMF, and the PCF also receives the IP information of the remote UE from the SMF.

[0112] If the remote UE does not have the PC5 QoS parameters for the service, then after the PC5 connection and related PDU session setup, the remote UE interacts with the AF to obtain the application layer control messages required for the service. This interaction is transmitted via the default PC5 QoS stream and default QoS stream of the PDU session. The AF then provides the service request to the PCF. When the PCF has received the remote UE report from the SMF, the PCF knows that the target UE requested by the AF is a remote UE. The PCF then generates PCC rules (for QoS control of Uu) and PC5 QoS parameters (for QoS control of PC5). The PCF decision may be based, for example, on the service request and operator policy received from the AF, as well as the rates for Uu and PC5.

[0113] 6.25.2 Program

[0114] [3GPP TR 23.752V0.4.0 titled "QoS Control for L3 UE to Network Relay"] Figure 6 .25.1-1 reproduced as Figure 6 ]

[0115] 1. When a remote UE wants to use the services provided by the AF through the 3GPP network, it selects a network relay and establishes a PC5 connection between the remote UE and the NW relay, which is the same as the PC5 portion of step 3 described in clause 6.6.2. In this step, if the remote UE does not have the PC5 QoS parameters for the service, then the default PC5 QoS flow is set using the default PC5 QoS parameters in the configuration information.

[0116] 2. UE to network relay, for example, based on the S-NSSAI, DNN settings requested by the remote UE, the corresponding PDU session can be set up or an existing PDU session can be used for relay.

[0117] 3. After IP address / prefix allocation, the UE reports the IP information of the remote UE to the SMF via the network relay, and the SMF forwards the received report to the PCF.

[0118] 4. If the remote UE does not have the PC5 QoS parameters for the service, then the remote UE interacts with the AF to obtain the application layer control messages required for the service. This interaction is transmitted via the default PC5 QoS stream and the default QoS stream of the PDU session.

[0119] 5. Since the address used by the remote UE belongs to the PDU session from the UE to the network relay, the AF can locate the PCF from the UE to the network relay and provide the service request to the PCF.

[0120] 6. For example, using the IP information provided by the AF and the IP information of the remote UE received from the SMF, the PCF learns that the target UE requested by the AF is a remote UE. The PCF generates PCC rules (for QoS control of Uu) and PC5 QoS parameters (for QoS control of PC5). The PCF decision may be based, for example, on the service requirements and operator policies received from the AF, as well as the rates for Uu and PC5. The PCF provides the PCC decision to the SMF.

[0121] 7. Based on the PCC rules received from the PCF, the SMF can decide to set up new QoS flows or modify existing QoS flows for the PDU session. The SMF generates QoS rules that will be enforced at the UE-to-network trunk and QoS profiles that will be enforced at the RAN for QoS control in the Uu segment. The PDU session modification procedure is executed. PC5 QoS parameters are also provided to the UE-to-network trunk along with the relevant QoS rules.

[0122] 8. The UE initiates a Layer 2 link modification procedure as described in TS 23.287[5] using the PC5 QoS parameters received from the CN to the network relay.

[0123] 6.25.3 Impact on services, entities, and interfaces

[0124] -PCF generates PCC rules (for QoS control of Uu) and PC5 QoS parameters (for QoS control of PC5).

[0125] -UE to network relay is based on the PC5 QoS parameters received from the CN to modify the Layer 2 link.

[0126] 3GPP TS 23.287 specifies the following procedures for licensing and provisioning of vehicle-to-everything (V2X) communications, QoS processing for V2X communications, and the establishment and modification of Layer 2 links via the PC5 reference point:

[0127] 5.1.2 Licensing and Pre-configuration for V2X Communication via PC5 Reference Point

[0128] 5.1.2.1 Strategy / Parameter Pre-configuration

[0129] The following set of information for V2X communication via the PC5 reference point will be pre-configured to the UE:

[0130] [...]

[0131] 6) Strategy / parameters when selecting NR PC5:

[0132] - A mapping that combines V2X service types (e.g., PSID or ITS-AID) of one or more geographic regions to V2X frequencies.

[0133] - A mapping of one or more destination layer 2 IDs and V2X service types, such as PSID or ITS-AID for broadcast V2X applications.

[0134] - A mapping of one or more destination layer 2 IDs and V2X service types, such as PSID or ITS-AID for V2X applications used for multicast.

[0135] - A mapping of the default destination layer 2 ID used for initial signaling to establish a unicast connection and the V2X service type, such as the PSID or ITS-AID for V2X applications.

[0136] Note 3: The same default destination stratum 2 ID used for unicast initial signaling can be mapped to more than one V2X service type. When different V2X services are mapped to different default destination stratum 2 IDs, when the UE intends to establish a single unicast link that can be used for more than one V2X service type, the UE can select any of the default destination stratum 2 IDs for initial signaling.

[0137] -PC5 QoS image configuration:

[0138] -Input from the V2X application layer:

[0139] - V2X service type (e.g., PSID or ITS-AID).

[0140] - (Optional) V2X application requirements for V2X service types, such as priority requirements, security requirements, latency requirements, and range requirements.

[0141] Note 4: Details of the V2X application requirements for V2X service types depend on the implementation method and are outside the scope of this specification.

[0142] Output:

[0143] - PC5 QoS parameters as defined in Clause 5.4.2 (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0144] -AS layer configuration (see TS 38.331

[15] ), for example when the UE is "not served by E-UTRA".

[0145] Furthermore, "not served by NR" refers to the mapping of one or more PC5 QoS profiles to one or more radio bearers.

[0146] The PC5 QoS profile contains the PC5 QoS parameters described in Clause 5.4.2, as well as QoS characteristics for priority, average window, and maximum data burst size when the default values ​​are not used as defined in Table 5.4.4-1.

[0147] …

[0148] 5.4.1 QoS processing for V2X communication via the PC5 reference point

[0149] 5.4.1.1 QoS Model

[0150] 5.4.1.1.1 Overview

[0151] For LTE-based PC5, QoS processing is defined in TS23.285[8] based on ProSe per packet priority (PPPP) and ProSe per packet reliability (PPPR).

[0152] For NR-based PC5, a QoS model similar to that defined in TS 23.501[6] for Uu reference points is used, i.e., based on 5QI, with additional parameter ranges as described in Clauses 5.4.2, 5.4.3 and 5.4.4. For V2X communication via NR-based PC5 reference points, PC5 QoS flows are associated with PC5 QoS rules and PC5 QoS parameters as defined in Clause 5.4.2. A set of standardized PC5 5QIs (PQIs) is defined in Clause 5.4.4. The UE may be configured with a set of default PC5 QoS parameters for V2X service types as defined in Clause 5.1.2.1. For NR-based unicast, multicast and broadcast PC5 communication, a per-flow QoS model for PC5 QoS management should be applied. Figure 5 Section 4.1.1.1-1 shows an example image of the per-flow QoS model for NR PC5. Details of PC5 QoS rules and PFI-related operations are described in sections 5.4.1.1.2 and 5.4.1.1.3.

[0153] [3GPP TS 23.287V16.2.0 titled "Per-stream PC5 QoS Model for NR PC5"] Figure 5 4.1.1.1-1 reproduced as Figure 7 ]

[0154] When performing V2X communication via the PC5 reference point, the following principles apply:

[0155] - The application layer can use the PPPP and PPPR models or the PQI and range models defined in TS 23.285[8] as described in Clause 5.4.4 to set the V2X application requirements for V2X communication. Depending on the type of PC5 reference point selected for the transport, i.e., LTE-based or NR-based, the UE can map the V2X application requirements provided by the application layer to the appropriate QoS parameters to be passed to the lower layers. The mapping between the two QoS models is defined in Clause 5.4.2. For V2X communication via NR-based PC5, different V2X packets may require different QoS treatment. In that case, the V2X packets should be sent from the V2X layer to the access layer within the PC5 QoS stream identified by different PFIs.

[0156] - When using multicast mode for V2X communication via NR-based PC5, the range parameter is associated with the QoS parameters used for V2X communication. The range can be provided by the V2X application layer or use default values ​​mapped from the V2X service type based on the configuration defined in Clause 5.1.2.1. The range indicates the minimum distance that needs to be satisfied with the QoS parameters. The range parameter, along with the QoS parameters, is passed to the AS layer for dynamic control.

[0157] - NR-based PC5 supports three communication modes: broadcast, multicast, and unicast. QoS processing for these different modes is described in clauses 5.4.1.2 through 5.4.1.4.

[0158] - The UE can process broadcast, multicast, and unicast services by considering, for example, all their priorities as indicated by the PQI.

[0159] - For broadcast and multicast modes of V2X communication via NR-based PC5, the UE applies the standard PQI value because there is no signaling at the PC5 reference point in these cases.

[0160] - When using network scheduling operation mode, the UE-PC5-AMBR for NR-based PC5 is applicable to all types of communication modes and is used by NG-RAN to limit UE's NR-based PC5 transmissions in resource management. The UE-PC5-AMBR should be set to the sum of the aggregated maximum bit rates of all types of communication (i.e., unicast, multicast, and broadcast modes) at the PC5 reference point.

[0161] 5.4.1.1.2 Export PC5 QoS parameters and assign PFI to PC5 QoS flows

[0162] The following description applies to both the network scheduling operation mode and the UE autonomous resource selection mode.

[0163] When a service data or request is received from the V2X application layer, the UE determines whether there is any existing PC5 QoS flow that matches the service data or request, i.e., based on the PC5 QoS rules used for existing PC5 QoS flows.

[0164] If no matching service data or requested PC5 QoS flow exists, the UE derives PC5 QoS parameters based on the V2X application requirements and V2X service type (e.g., PSID or ITS-AID) provided by the V2X application layer (if available) according to the PC5 QoS image configuration defined in Clause 5.1.2.1, and performs the following:

[0165] -If no existing PC5 QoS flow exists that satisfies the derived PC5 QoS parameters, then:

[0166] - The UE generates a new PC5 QoS stream for the exported PC5 QoS parameters; and

[0167] The UE then assigns a PFI to this PC5 QoS flow and exports PC5 QoS rules.

[0168] Otherwise, the UE updates the PC5 packet filter set in the PC5 QoS rules for such PC5 QoS flows.

[0169] For V2X communication via NR PC5 reference points, PC5 QoS flows are the finest granularity of QoS differences within the same destination, identified by the destination layer 2ID. User plane services with the same PFI receive the same service forwarding processing (e.g., scheduling, admission thresholds). The PFI is unique within the same destination.

[0170] 5.4.1.1.3 Processing PC5 QoS flows based on PC5 QoS rules

[0171] For each communication mode (e.g., broadcast, multicast, unicast), the UE maintains a mapping from the PFI to the PC5 QoS context and the PC5 QoS rules for each destination, identified by the destination layer 2 ID. The PC5 QoS context contains PC5 QoS parameters (e.g., PQI and range) and the V2X service type (e.g., PSID or ITS-AID). When the UE assigns a new PFI for a V2X service type, it stores it along with the corresponding PC5 QoS context and PC5 QoS rules for the destination. When the UE releases the PFI, it removes the corresponding PC5 QoS context and PC5 QoS rules for the destination. For unicast, the unicast link profile defined in Clause 5.2.1.4 contains additional information from the PFI map for unicast operations.

[0172] A PC5 QoS rule contains the PFI of the associated PC5 QoS flow, a priority value, and a set of PC5 packet filters as defined in Clause 5.4.1.1.4. The priority value determines the order in which PC5 QoS rules are evaluated. PC5 QoS rules with lower priority values ​​are evaluated before those with higher priority values.

[0173] The V2X layer provides information for PC5 QoS operations per destination (e.g., identified by the destination layer 2 ID) to the AS layer for per-flow QoS model operations, as follows:

[0174] 1) To add a new PC5 QoS flow or modify any existing PC5 QoS flow, the V2X layer will provide the following information for the PC5 QoS flow to the AS layer.

[0175] -PFI;

[0176] - Corresponding PC5 QoS parameters; and

[0177] - Source / destination layer 2 ID for broadcast and multicast, or PC5 link identifier for unicast.

[0178] 2) To remove any existing PC5 QoS flow, the V2X layer will provide the following information for the PC5 QoS flow to the AS layer.

[0179] -PFI; and

[0180] - Source / destination layer 2 ID for broadcast and multicast, or PC5 link identifier for unicast.

[0181] In addition, the V2X layer provides communication modes (e.g., broadcast, multicast, unicast), radio frequencies (RFs), and Tx profiles to the AS layer for PC5 operation. RFs and Tx profiles are determined based on the V2X service type. The V2X layer ensures that V2X service types associated with different RFs (e.g., identified by PSID or ITS-AID) are classified into different PC5 QoS flows.

[0182] Figure 5 4.1.1.3-1 illustrates an example of classifying and labeling user plane traffic using PC5 QoS rules, as well as the mapping of PC5 QoS flows to radio resources at the access layer.

[0183] [3GPP TS 23.287V16.2.0, titled "Processing PC5 QoS Streams Based on PC5 QoS Rules"] Figure 5 4.1.1.3-1 reproduced as Figure 8 ]

[0184] like Figure 5As shown in .4.1.1.3-1, for a given pair of source and destination Layer 2 IDs, there may be multiple radio bearers, each corresponding to a different PC5 QoS level. The AS layer can determine the mapping of multiple PC5 QoS flows to the same radio bearer based on the information provided. For broadcast and multicast, the L2 link leads to all nearby UEs identified by the destination Layer 2 ID.

[0185] 5.4.1.1.4 PC5 Package Filter Set

[0186] The PC5 packet filter set supports two types of packet filters: IP packet filter set and V2X packet filter set. PC5 QoS rules contain either an IP packet filter set or a V2X packet filter set.

[0187] The set of IP packet filters is defined in Clause 5.7.6.2 of TS 23.501[6].

[0188] The V2X packet filter set will support packet filtering based on at least any combination of the following:

[0189] -V2X service type (e.g., PSID or ITS-AID);

[0190] -Source / Destination Layer 2 ID;

[0191] - Application layer ID (e.g., site ID);

[0192] - Extended parameters.

[0193] Editor's Note: Phase 3 can determine extended parameters that support input parameters, such as those from upper-layer protocols or extended header fields (e.g., the TC field of the GeoNetworking common header, WAVE cell extensions, etc.).

[0194] [...]

[0195] 6.3.3.1 Establishing a Layer 2 Link via PC5 Reference Point

[0196] To perform unicast mode V2X communication via the PC5 reference point, the UE is configured with the relevant information as described in Clause 5.1.2.1.

[0197] Figure 6 3.3.1-1 shows the Layer 2 link establishment procedure for unicast mode V2X communication via the PC5 reference point.

[0198] [The 3GPP TS 23.287V16.2.0 document titled "Layer 2 Link Establishment Procedure"] Figure 6 .3.3.1-1 reproduced as Figure 9 ]

[0199] 1. One or more UEs determine a destination layer 2 ID for signaling reception used for establishing a PC5 unicast link as specified in Clause 5.6.1.4. The destination layer 2 ID is configured with one or more UEs as specified in Clause 5.1.2.1.

[0200] 2. The V2X application layer in UE-1 provides application information for PC5 unicast communication. This application information includes one or more V2X service types (e.g., one or more PSIDs or one or more ITS-AIDs) and the application layer ID of the initiating UE. The application information may also include the application layer ID of the target UE.

[0201] The V2X application layer in UE-1 can provide the V2X application requirements for this unicast communication. UE-1 determines the PC5 QoS parameters and PFI as specified in Clause 5.4.1.4.

[0202] If UE-1 decides to reuse an existing PC5 unicast link as specified in Clause 5.2.1.4, then the UE triggers the Layer 2 link modification procedure as specified in Clause 6.3.3.4.

[0203] 3. UE-1 sends a Direct Communication Request message to initiate a unicast Layer 2 link establishment procedure. The Direct Communication Request message includes:

[0204] - Source user information: Application layer ID of the initiating UE (i.e., application layer ID of UE-1).

[0205] - If the V2X application layer provides the target UE's application layer ID in step 2, then the following information is included:

[0206] - Target user information: Application layer ID of the target UE (i.e., application layer ID of UE-2).

[0207] -V2X Service Information: Information about one or more V2X services (e.g., one or more PSIDs or one or more ITS-AIDs) established on the request layer 2 link.

[0208] - Security information: Information used to establish security.

[0209] Note 1: Security information and the necessary protection of source user information and target user information are defined by SA WG3.

[0210] As specified in Clauses 5.6.1.1 and 5.6.1.4, determine the source Layer 2 ID and destination Layer 2 ID used to send the direct communication request message. The destination Layer 2 ID can be a broadcast or unicast Layer 2 ID. When using a unicast Layer 2 ID, the target user information should be included in the direct communication request message.

[0211] UE-1 sends direct communication request messages by broadcasting or unicasting PC5 using source layer 2 ID and destination layer 2 ID.

[0212] 4. Establish UE-1's security as follows:

[0213] 4a. If the target user information is contained in the direct communication request message, then the target UE, i.e., UE-2, responds by establishing security with UE-1.

[0214] 4b. If the target user information is not included in the direct communication request message, then UEs interested in using the V2X service notified via the PC5 unicast link with UE-1 respond by establishing security with UE-1.

[0215] Note 2: Signaling used for security procedures is defined by SA WG3.

[0216] When security protection is enabled, UE-1 sends the following information to the target UE:

[0217] -If using IP communication:

[0218] - IP address configuration: For IP communication, this link requires IP address configuration, and the IP address configuration indicates one of the following values:

[0219] - "IPv6 router", which acts as an IPv6 router if the IPv6 address allocation mechanism is supported by the initiating UE; or

[0220] - "IPv6 address allocation is not supported" if the IPv6 address allocation mechanism is not supported by the initiating UE.

[0221] -Link-local IPv6 address: If UE-1 does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration indicates "IPv6 address allocation is not supported", then based on RFC 4862

[21]

[0222] A local link is formed using a local IPv6 address.

[0223] - QoS Information: Information about one or more PC5 QoS flows. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0224] As specified in Clauses 5.6.1.1 and 5.6.1.4, determine the source Layer 2 ID used for the security establishment procedure. The destination Layer 2 ID is set to the source Layer 2 ID of the received direct communication request message.

[0225] Once the security establishment procedure message is received, UE-1 obtains the Layer 2 ID of the peer UE for signaling and data services used for this unicast link for future communication.

[0226] 5. One or more target UEs that have successfully established security with UE-1 will directly communicate to receive messages sent to UE-1:

[0227] 5a. (Layer 2 Link Establishment for UE) If the direct communication request message contains target user information, then in the case of application layer ID matching for UE-2, the target UE, i.e., UE-2, responds with a direct communication receive message.

[0228] 5b. (Layer 2 Link Establishment for V2X Services) If the direct communication request message does not contain target user information, then the UE interested in using one or more notifications for V2X services (in...) Figure 6 UE-2 and UE-4 in .3.3.1-1 respond to requests by sending a direct communication accept message.

[0229] Direct communication message reception includes:

[0230] - Source User Information: The application layer ID of the UE that sent the direct communication message.

[0231] - QoS Information: Information about one or more PC5 QoS flows. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters requested by UE-1 (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0232] -If using IP communication:

[0233] - IP address configuration: For IP communication, this link requires IP address configuration, and the IP address configuration indicates one of the following values:

[0234] - "IPv6 router", which acts as an IPv6 router if the IPv6 address allocation mechanism is supported by the target UE; or

[0235] - "IPv6 address allocation is not supported" if the IPv6 address allocation mechanism is not supported by the target UE.

[0236] - Link-local IPv6 address: If the target UE does not support the IPv6 IP address allocation mechanism, i.e., the IP address configuration indicates "IPv6 address allocation is not supported", and UE-1 contains the link-local IPv6 address in the direct communication request message, then the link-local IPv6 address is formed locally based on RFC 4862

[21] . The target UE should contain a non-conflicting link-local IPv6 address.

[0237] If two UEs (i.e., the initiating UE and the target UE) are selected to use the link-local IPv6 address, dual address detection as defined in RFC4862

[21] will be disabled.

[0238] Note 3: When the initiating UE or the target UE indicates support for the IPv6 router, the corresponding address configuration procedure will be performed after the Layer 2 link is established, and the link-local IPv6 address will be ignored.

[0239] The V2X layer of a UE establishing a PC5 unicast link will pass down the allocated PC5 link identifier and PC5 unicast link-related information to the AS layer. The PC5 unicast link-related information includes Layer 2 ID information (i.e., source Layer 2 ID and destination Layer 2 ID). This allows the AS layer to store the PC5 link identifier and the PC5 unicast link-related information.

[0240] 6. V2X service data is transmitted via the established unicast link as follows:

[0241] The PC5 link identifier and PF, along with V2X service data, are provided to the AS layer.

[0242] Alternatively, layer 2 ID information (i.e., source layer 2 ID and destination layer 2 ID) may be provided to the AS layer.

[0243] Note 4: The UE implementation plan provides the Layer 2 ID information to the AS layer.

[0244] UE-1 uses the source stratum 2 ID (i.e., the stratum 2 ID of UE-1 for this unicast link) and the destination stratum 2 ID (i.e., the stratum 2 ID of the peer UE for this unicast link) to send V2X service data.

[0245] Note 5: PC5 unicast links are bidirectional, so UE-1's peer UE can send V2X service data to UE-1 through the unicast link with UE-1.

[0246] [...]

[0247] 6.3.3.4 Layer 2 Link Modification for Unicast Links

[0248] Figure 6 Section 3.3.4-1 illustrates the Layer 2 link modification procedure for unicast links. This procedure is used to:

[0249] - Add one or more new V2X services to an existing PC5 unicast link.

[0250] - Remove one or more V2X services from the existing PC5 unicast link.

[0251] - Add one or more new PC5 QoS flows to an existing PC5 unicast link.

[0252] - Modify one or more existing PC5 QoS flows in an existing PC5 unicast link.

[0253] - Remove one or more existing PC5 QoS flows from an existing PC5 unicast link.

[0254] [3GPP TS 23.287V16.2.0 titled "Layer 2 Link Modification Procedure"] Figure 6 .3.3.4-1 reproduced as Figure 10 ]

[0255] 0. UE-1 and UE-2 have unicast links established as described in Clause 6.3.3.1.

[0256] 1. The V2X application layer in UE-1 provides application information for PC5 unicast communication. This application information includes one or more V2X service types (e.g., one or more PSIDs or one or more ITS-AIDs) for one or more V2X applications, and the application layer ID of the initiating UE. The application information may also include the application layer ID of the target UE. If UE-1 decides to reuse an existing PC5 unicast link as specified in Clause 5.2.1.4, and therefore decides to modify the unicast link established with UE-2, then UE-1 sends a link modification request to UE-2.

[0257] The link modification request message includes:

[0258] a) Add one or more new V2X services to existing PC5 unicast links:

[0259] -V2X Service Information: Information about one or more V2X services to be added (e.g., one or more PSIDs or one or more ITS-AIDs).

[0260] - QoS Information: Information about one or more PC5 QoS flows for each V2X service to be added. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0261] b) Remove one or more V2X services from existing PC5 unicast links:

[0262] -V2X Service Information: Information about one or more V2X services (e.g., one or more PSIDs or one or more ITS-AIDs) to be removed.

[0263] c) Add one or more new PC5 QoS flows to an existing PC5 unicast link:

[0264] -V2X Service Information: Information about one or more V2X services (e.g., one or more PSIDs or one or more ITS-AIDs) that require the addition of new QoS flows.

[0265] - QoS Information: Information about one or more PC5 QoS flows to be modified. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0266] d) Modify one or more PC5 QoS flows in an existing PC5 unicast link:

[0267] - QoS Information: Information about one or more PC5 QoS flows to be modified. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0268] e) Remove one or more PC5 QoS flows from an existing PC5 unicast link:

[0269] -PFI.

[0270] 2. UE 2 responds with a link modification acceptance message.

[0271] The link modification acceptance message includes:

[0272] -For cases a), c), and d) described in step 1:

[0273] - QoS Information: Information about one or more PC5 QoS flows. For each PC5 QoS flow, the PFI and the corresponding PC5 QoS parameters (i.e., PQI and conditionally other parameters such as MFBR / GFBR).

[0274] Each UE's V2X layer provides information about unicast link modifications to the AS layer. This enables the AS layer to update the context associated with the modified unicast link.

[0275] 3GPP TS 23.502 specifies the UE-requested PDU session establishment and PDU session modification for accessing services provided by the data network (DN), as follows:

[0276] 4.3.2.2 UE-Requested PDU Session Establishment

[0277] 4.3.2.2.1 Non-roaming and roaming with local interruptions

[0278] Clause 4.3.2.2.1 specifies the establishment of PDU sessions in non-roaming and roaming situations with local interruptions. The procedure is used to:

[0279] - Establish a new PDU session;

[0280] - Switch the PDN connection in the EPS to the PDU session in the 5GS without using the N26 interface;

[0281] - Switching existing PDU sessions between non-3GPP access and 3GPP access. In this case, specific system behavior is further defined in Clause 4.9.2; or

[0282] - Request a PDU session for emergency services.

[0283] In roaming scenarios, the AMF determines whether to establish a PDU session in LBO or home routing. In LBO, the procedure is the same as in non-roaming scenarios, except that the AMF, SMF, UPF, and PCF are located within the visited network. PDU sessions used for emergency services are never established in home routing mode. If control plane CIoT 5GS optimization is enabled for PDU sessions with LBO, the NEF is not used as the anchor point for this PDU session.

[0284] Note 1: As described in Clause 5.15.5.3 of TS 23.501[2], the UE provides both the home PLMN and the visited PLMN to the network.

[0285] [3GPP TS23.502V16.5.1 titled "PDU Session Establishment for UE Requests for Non-Roaming and Roaming with Local Interruptions"] Figure 4 .3.2.2.1-1 reproduced as Figure 11 ]

[0286] [...]

[0287] 4.3.3 PDU Session Modification

[0288] 4.3.3.1 Overview

[0289] The procedure is used to modify one or more of the QoS parameters exchanged between the UE and the network.

[0290] Note: The conditions for using this procedure for QoS changes and QoS parameters exchanged between the UE and the network are defined in Clause 5.7 of TS 23.501[2].

[0291] 4.3.3.2 PDU session modification requested by the UE or network (non-roaming and roaming with local interruption)

[0292] exist Figure 4Section 3.3.2-1 describes the PDU session modification procedure requested by the UE or network (non-roaming and roaming with local interruption scenarios).

[0293] [3GPP TS 23.502V16.5.1 titled "UE or Network Request for PDU Session Modification (for Non-Roaming and Roaming with Local Interruptions)"] Figure 4 .3.3.2-1 reproduced as Figure 12 ]

[0294] [...]

[0295] 3GPP TS 24.501 specifies the Quality of Service (QoS) and defines the PDU Session Modification Request message as follows:

[0296] 6.2.5 Service Quality

[0297] 6.2.5.1 Overview

[0298] 6.2.5.1.1 QoS Rules

[0299] 6.2.5.1.1.1 Overview

[0300] In PDU sessions of IPv4, IPv6, IPv4v6, and Ethernet PDU session types, the NAS protocol implements different forwarding processes for UL user packets in one or more QoS flows based on signaling QoS rules, derived QoS rules, or any combination thereof.

[0301] In an unstructured PDU session, all UL user packets are associated with the same QoS flow.

[0302] 6.2.5.1.1.2 Signaling QoS Rules

[0303] The NAS protocol enables the network to provide the UE with signaling QoS rules associated with the PDU session.

[0304] The network can provide the UE with one or more signaling QoS rules associated with the PDU session at the PDU session establishment point or at the PDU session modification point.

[0305] Each signaling QoS rule contains:

[0306] a) Whether the QoS rule is the default QoS rule;

[0307] b) QoS Rule Identifier (QRI);

[0308] c) QoS Flow Identifier (QFI);

[0309] d) Optionally, include a filter set; and

[0310] e) Priority value.

[0311] Note 1: The default QoS rule indication (DQR) of signaling QoS rules cannot be changed.

[0312] For situation d) above:

[0313] 1) If the QoS rule is the default rule for a PDU session of IPv4, IPv6, IPv4v6, or Ethernet PDU session type, then the packet filter set contains zero or more packet filters for the DL direction, and may additionally contain one of the following:

[0314] A) Matching all package filters for UL orientation;

[0315] B) Matching all package filters for UL and DL directions;

[0316] C) Zero or more package filters for the UL orientation (in addition to matching all package filters for the UL orientation);

[0317] D) Zero or more package filters for UL and DL orientations (in addition to matching all package filters for UL and DL orientations); or

[0318] E) One or more package filters for the UL direction (excluding all-matching package filters for the UL direction) and one or more package filters for the UL and DL directions (excluding all-matching package filters for the UL and DL directions).

[0319] The default rule's packet filter set will not be empty. If the default QoS rule contains a filter that matches all packets, then the highest priority value will be used for the default QoS rule.

[0320] 2) If the QoS rule is the default rule for a PDU session of IPv4, IPv6, IPv4v6, or Ethernet PDU session type, and is not the default QoS rule, then the packet filter set contains zero or more packet filters for the DL direction, and may additionally contain one of the following:

[0321] A) Zero or more package filters for UL orientation (in addition to all matched package filters for UL orientation); and

[0322] B) Zero or more packet filters for both UL and DL directions (except for all packet filters that match for both UL and DL directions).

[0323] The packet filter set used for QoS rules that are not the default QoS rule will not be empty.

[0324] 3) For PDU sessions of the unstructured PDU session type, there is only one QoS rule associated with it, and the packet filter set of the QoS rule is empty.

[0325] If a UE requests a new QoS rule, it will assign a priority value to the signaling QoS rule, which is not in the range of 70 to 99 (decimal).

[0326] Note 2: In this version of the manual, there is no support for the match all packet filter for the DL direction.

[0327] Note 3: To support QoS differentiation when accessing PLMN services via SNPN, UEs within SNPN can construct packet filters based on destination IP addresses to reach N3IWF in PLMN and the Security Parameter Index (SPI) for IPsec SA.

[0328] Note 4: To support QoS differentiation when accessing SNPN services via PLMN, UEs within PLMN can construct packet filters based on destination IP addresses to reach N3IWF in SNPN and the Security Parameter Index (SPI) for IPsec SA.

[0329] Note 5: When a UE requests a QoS rule from the network by setting the segregation bit to 1 to combine the service data stream described by the QoS rule into a dedicated QoS stream, the above conditions of the priority value of the signaling QoS rule are applied to the UE.

[0330] In NB-N1 mode, there is only one QoS rule associated with the PDU session and which is the default QoS rule. As described in 3GPP TS 23.501[8], when the SMF determines that the UE has:

[0331] a) Move from the tracking area in WB-N1 mode to the tracking area in NB-N1 mode;

[0332] b) Move from the tracking area in WB-S1 mode to the tracking area in NB-N1 mode; or

[0333] c) Move from the tracking area in the NR connected to the 5GCN to the tracking area in the NB-N1 mode;

[0334] For each PDU session that remains active, the SMF will initiate a PDU session modification procedure (see Sub-clause 6.3.3.2) to remove each QoS rule that is not the default QoS rule (if it exists).

[0335] Within a PDU session:

[0336] a) Each signaling QoS rule has a unique QRI;

[0337] b) At least one signaling QoS rule exists;

[0338] c) A signaling QoS rule is the default QoS rule; and

[0339] d) There may be zero, one or more signaling QoS rules associated with a given QFI.

[0340] 6.2.5.1.1.3 Exporting QoS Rules

[0341] Exporting QoS rules is only applicable to PDU sessions of IPv4, IPv6, IPv4v6, or Ethernet PDU session types.

[0342] The reflected QoS in the UE creates derived QoS rules associated with the PDU session based on DL user packets received via the PDU session.

[0343] Each exported QoS rule contains:

[0344] a) QoS Flow Identifier (QFI);

[0345] b) Packaging filters for UL applications; and

[0346] c) is the priority value of 80 (decimal).

[0347] Note: On the network side, the corresponding QoS rules can be associated with different priority values ​​in the range of 70 to 99 (decimal).

[0348] Within a PDU session:

[0349] a) There may be zero, one, or more derived QoS rules associated with a given QFI; and

[0350] (b) At most one derived QoS rule can exist associated with a given packet filter used for the UL direction.

[0351] In the UE, timer T3583 is run for each derived QoS rule.

[0352] Reflection QoS is not supported in NB-N1 mode.

[0353] 6.2.5.1.1.4 QoS Flow Description

[0354] The network can provide the UE with one or more QoS flow descriptions associated with the PDU session at the PDU session establishment or PDU session modification.

[0355] Each QoS flow description contains:

[0356] a) QoS Flow Identifier (QFI);

[0357] b) If the flow is a GBR QoS flow, then:

[0358] 1) Guaranteed Stream Bit Rate (GFBR) for UL;

[0359] 2) Guaranteed Stream Bit Rate (GFBR) for DL;

[0360] 3) Maximum Stream Bit Rate (MFBR) for UL;

[0361] 4) Maximum Stream Bit Rate (MFBR) for DL; and

[0362] 5) Optionally, the average window for both UL and DL is applied;

[0363] c) 5QI, if the QFI is not the same as the 5QI of the QoS flow identified by the QFI; and

[0364] d) Optionally, the EPS bearer identifier (EBI) if the QoS flow can be mapped to the EPS bearer specified in subclause 4.11.2 of 3GPP TS23.502[9].

[0365] If the average window is not included in the QoS flow description of a GBRQoS flow with 5QI indicated in Table 5.7.4-1 of 3GPP TS 23.501[8], then the average window associated with 5QI in Table 5.7.4-1 of 3GPP TS 23.501[8] applies to the average window.

[0366] If the average window is not included in the QoS flow description for a GBR QoS flow with 5QI not indicated in Table 5.7.4-1 of 3GPP TS 23.501[8], then a standard value of two seconds is used as the average window.

[0367] 6.2.5.1.2 Session - AMBR

[0368] The NAS protocol enables the network to provide the UE with a session-AMBR associated with the PDU session.

[0369] The standard value of two seconds is used as the average window for the UE to enforce the UL rate limit indicated by the session-AMBR.

[0370] 6.2.5.1.2A Void

[0371] 6.2.5.1.3 UL User Data Packet Matching

[0372] For PDU sessions of IPv4, IPv6, IPv4v6, or Ethernet PDU session type, after receiving UL user packets from the upper layer used for transmission via the PDU session, the UE will attempt to associate the UL user packets with the following by evaluating QoS rules in ascending order of their priority values:

[0373] a) A QFI of signaling QoS rules associated with a PDU session having a packet filter set, the QFI containing a packet filter for UL direction for matching UL user packets or a packet filter for both UL and DL directions for matching UL user packets; or

[0374] b) Exporting the QFI of QoS rules, the QFI being associated with a PDU session having a packet filter for matching UL user packets in the UL direction;

[0375] This continues until UL user packets are associated with QFI or all QoS rules are evaluated.

[0376] For PDU sessions of the unstructured PDU session type, after receiving UL user data packets from the upper layer used for transmission via the PDU session, the UE will associate the UL user data packets with the QFI of the default QoS rule associated with the PDU session.

[0377] If the UL user data packet is associated with QFI, then the UE will pass the QFI down to the lower layer along the UL user data packet for transmission.

[0378] Note: UL user data packets are marked with QFI by the lower layer.

[0379] If all QoS rules are evaluated and the UL user data packet is not associated with QFI, then the UE will discard the UL user data packet.

[0380] [...]

[0381] 8.3.7 PDU Session Modification Request

[0382] 8.3.7.1 Message Definition

[0383] The UE sends a PDU session request message to the SMF to request modification of the PDU session. See Table 8.3.7.1.1.

[0384] Message type: PDU session modification request

[0385] Significance: Double

[0386] Direction: UE to network

[0387] The table in 3GPP TS 24.501V16.5.1 with the title "PDU Session Modification Request Message Content"

[0388] 8.3.7.1.1 Reproduced as Figure 13 ]

[0389] Note: Earlier versions of UEs conforming to this specification may send a mapped EPS bearer context IE with an IEI value of "7F" in response to this message.

[0390] [...]

[0391] 8.3.7.7 Requested QoS rules

[0392] This IE is included in the message when the UE requests specific QoS processing.

[0393] 8.3.7.8 Requested QoS Flow Description

[0394] This IE is included in the message when the UE requests a specific QoS flow description.

[0395] [...]

[0396] 3GPP TS 23.501 specifies the following packet filter set:

[0397] 5.7.6 Package Filter Set

[0398] 5.7.6.1 Overview

[0399] Packet filter sets are used in QoS rules and PDRs to identify one or more packet (IP or Ethernet) flows.

[0400] Note 1: A QoS flow is characterized by one or more PDRs and one or more QoS rules as described in Clause 5.7.1.1.

[0401] Note 2: For example, for IMS purposes, the UE may need DL packet filters in the packet filter set of QoS rules.

[0402] A package filter set may contain one or more package filters. Each package filter may be suitable for DL ​​direction, UL direction, or both.

[0403] Note 3: The packet filters in the packet filter set that allow all UL services (also known as matching all packet filters) are described in TS 24.501

[47] .

[0404] There are two types of packet filter sets corresponding to those PDU session types: IP packet filter sets and Ethernet packet filter sets.

[0405] 5.7.6.2 IP Packet Filter Set

[0406] For IP PDU session types, the packet filter set will support packet filtering based on at least any combination of the following:

[0407] - Source / destination IP address or IPv6 prefix.

[0408] - Source / destination port number.

[0409] -The protocol ID of the protocol in the IP / Next header type.

[0410] - Type of Service (TOS) (IPv4) / Class of Service (IPv6) and mask.

[0411] - Flow label (IPv6).

[0412] - Security parameter index.

[0413] - Package filter direction.

[0414] Note 1: Unspecified values ​​in the packet filter match any value in the corresponding information within the packet.

[0415] Note 2: IP address or prefix can be combined with prefix mask.

[0416] Note 3: The port number can be specified as a range of ports.

[0417] [...]

[0418] In version 16 (as described in 3GPP TS 23.303), both Model A discovery and Model B discovery are supported for discovering UEs to network relays. Model A uses a single discovery protocol message (i.e., notification), while Model B uses two discovery protocol messages (i.e., request and response). These two discovery mechanisms can also be used in future versions of UE-to-network relay discovery.

[0419] After a remote UE discovers a network relay (or relay UE), the remote UE can then establish a unicast link with the relay UE for transmitting services related to the data network (DN) involved via the relay UE. The remote UE can transmit a direct communication request message to establish a unicast link with the relay UE.

[0420] According to 3GPP TS 23.287, a direct communication request message can be transmitted using either the known Layer 2 ID of the relay UE or a default destination Layer 2 ID associated with the V2X service of interest to the remote UE. Furthermore, the default destination Layer 2 ID is configured for PC5 unicast link establishment. Additionally, the direct communication request message may contain service information (e.g., Provider Service Identifier (PSID) or Intelligent Transport System Application Identifier (ITS-AID)) to indicate the connectivity service. In response, the relay UE can reply with a direct communication accept message to complete the unicast link establishment. The direct communication accept message can address to the Layer 2 ID of the remote UE.

[0421] To relay services between a remote UE and a data network (DN), the relay UE needs to establish a PDU session with the DN before or after establishing a unicast link with the remote UE. According to 3GPP TS 24.501, the NAS protocol enables the core network (CN) to provide the UE (i.e., the relay UE in a UE-to-network relay scenario) with signaling QoS rules associated with the PDU session. The network can provide the UE with one or more signaling QoS rules associated with the PDU session at the point of PDU session establishment or modification, for example, via a PDU session establishment accept message or a PDU session modification command message sent to the UE. Each signaling QoS rule may contain at least one of the following parameters:

[0422] a) Whether the QoS rule is the default QoS rule;

[0423] b) QoS Rule Identifier (QRI);

[0424] c) QoS Flow Identifier (QFI);

[0425] d) Optionally, include a filter set; and

[0426] e) Priority value.

[0427] Therefore, within a PDU session:

[0428] a) Each signaling QoS rule has a unique QRI;

[0429] b) At least one signaling QoS rule exists;

[0430] c) A signaling QoS rule is the default QoS rule; and

[0431] d) There may be zero, one or more signaling QoS rules associated with a given QFI.

[0432] In addition, the core network may provide the UE with one or more QoS flow descriptions associated with the PDU session at the PDU session establishment or PDU session modification. Each QoS flow description may contain at least one of the following parameters:

[0433] a) QoS Flow Identifier (QFI);

[0434] b) If the flow is a GBR QoS flow, then:

[0435] 1) Guaranteed Stream Bit Rate (GFBR) for UL;

[0436] 2) Guaranteed Stream Bit Rate (GFBR) for DL;

[0437] 3) Maximum Stream Bit Rate (MFBR) for UL;

[0438] 4) Maximum Stream Bit Rate (MFBR) for DL; and

[0439] 5) Optionally, the average window for both UL and DL is applied;

[0440] c) 5QI, if the QFI is not the same as the 5QI of the QoS flow identified by the QFI; and

[0441] d) Optionally, the EPS bearer identifier (EBI) if the QoS flow can be mapped to the EPS bearer specified in subclause 4.11.2 of 3GPP TS 23.502.

[0442] For PDU sessions of IPv4, IPv6, IPv4v6, or Ethernet PDU session types, after receiving UL user packets from the upper layer used for transmission via the PDU session, the UE will attempt to associate UL user packets with the QFI of the QoS rules associated with the PDU session and the PDU session with the packet filter set in ascending order of their priority values ​​to match the UL user packets, until the UL user packets are associated with the QFI or all QoS rules have been evaluated.

[0443] For PDU sessions of the unstructured PDU session type, after receiving UL user data packets from the upper layer used for transmission via the PDU session, the UE will associate the UL user data packets with the QFI of the default QoS rule associated with the PDU session.

[0444] If the UL user data packet is associated with QFI, the UE will pass the QFI along the UL user data packet to the lower layer for transmission. Otherwise, the UE will discard the UL user data packet.

[0445] In the NR sidelink (or V2X) as described in 3GPP TS 23.287, the UE will derive PC5 QoS parameters and PC5 QoS rules for PC5 QoS flows based on the V2X application requirements and V2X service types (e.g., PSID or ITS-AID) provided by the V2X application layer (if available), and will also assign a PC5 flow identifier (PFI) to each PC5 QoS flow.

[0446] In a UE-to-NW relay scenario, the data flow of the remote UE is served by the relay UE's PDU session. Essentially, the UE-to-network relay path includes two branches (i.e., a PC5 branch and a Uu branch). If the QoS rules derived by the UE are applied by the remote UE to UL services on the PC5 branch, and the QoS rules configured by the network are applied by the relay UE to UL services on the Uu branch, then the remote UE needs to provide the parameters used in the packet filter associated with each QoS flow (e.g., source / destination IP address, source / destination port number, protocol ID, type of service (TOS) / service category, flow label, and security parameters, etc.) to the remote UE, so that the relay UE can map packets received from the remote UE to QoS flows according to the network-configured QoS rules. This will incur significant signaling overhead.

[0447] A better solution would provide the relay UE with QoS rules associated with the PDU session to the remote UE, allowing the remote UE to map packets to QoS flows based on the QoS rules and transmit packets with QoS flow IDs to the relay UE. Furthermore, the relay UE can simply follow the QoS flow IDs generated by the remote UE and map the QoS flows received from the remote UE to the data radio bearers (DRBs) on the Uu tributary according to the QoS flow-to-DRB mapping information provided by the network, so as to transmit packets to the network via the mapped DRBs.

[0448] After a PDU session is established, if the PDU session is established before the direct communication message is received, the relay UE can, for example, transmit the QoS rules associated with the PDU session to the remote UE via this message. Alternatively, if the PDU session is established after a PC5 unicast link has been established, the relay UE can, for example, transmit the QoS rules associated with the PDU session to the remote UE via a link modification request message. Using other (new) messages is also possible. Preferably, the QoS flow description (e.g., QoS profile) can also be transmitted by the relay UE to the remote UE in a related message.

[0449] Regarding QoS handling for UE-to-network relay, solution #24 in 3GPP TR 23.752 describes the data flow of remote UEs served by the PDU session of the relay UE. Since the UE-to-network relay path includes, as in 3GPP TR 23.752... Figure 6 .24.1-1 (reproduced as) Figure 5 As shown in the diagram, the two branches (PC5 and Uu) mean that end-to-end QoS can only be satisfied if the QoS requirements are correctly divided and meet the requirements of each branch separately. This is especially true for the QoS parameter of packet delay budget (PDB). For example, the end-to-end PDB can be split into the PDB on the Uu branch and the PDB on the PC5 branch (e.g., end-to-end PDB = PDB on the Uu branch + PDB on the PC5 branch).

[0450] 3GPP TS 23.502 specifies the PDU session establishment procedure for establishing a PDU session. The network may provide the authorized QoS rules and authorized QoS flow descriptions associated with the PDU session to the UE in the PDU session establishment accept message (e.g., in a relay UE in a UE-to-NW relay scenario). After the PDU session has been established, the UE may request modification of the PDU session. For example, the UE may include the requested QoS rules and / or requested QoS flow descriptions associated with the PDU session in a PDU session modification request message sent to the network.

[0451] In a UE-to-NW relay scenario, it is assumed that the remote UE can determine whether the current QoS meets the requirements. Therefore, for the relay UE to initiate a PDU session modification procedure for a PDU session, the remote UE needs to transmit the requested QoS rules and / or the requested QoS flow description to the relay UE (e.g., in a link modification request message).

[0452] In one embodiment, the requested QoS rule indicates at least one QoS rule to be used for the PDU session. Each QoS rule may contain at least one of the following parameters: QoS Rule Identifier (QRI), QoS Flow Identifier (QFI), packet filter set, and priority value. Furthermore, each packet filter may be formed by at least any combination of the following: source / destination IP address or IPv6 prefix, source / destination port number, protocol ID of the protocol on the IP / Next Header type, Type of Service (TOS) (IPv4) / Class of Service (IPv6) and mask, flow label (IPv6), security parameter index, and packet filter direction. The requested QoS flow description indicates at least one QoS flow description to be used for the PDU session. Each QoS flow description may contain at least one of the following parameters: QoS Flow Identifier (QFI), QoS identifier (e.g., 5QI), Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MFBR), and EPS Bearer Identifier (EBI).

[0453] Since the PDU session modification procedure is primarily used to modify PDU sessions on the Uu tributary, one possible solution is for the remote UE to transmit a QoS identifier (e.g., 5QI) associated with the Uu tributary, allowing the relay UE to provide the same QoS identifier (e.g., 5QI) to the network. Alternatively, the remote UE can transmit a QoS identifier (e.g., 5QI) for end-to-end communication (i.e., covering both the Uu and PC5 tributaries) to the relay UE. The relay UE can then derive the QoS identifier associated with the Uu tributary from the end-to-end QoS identifier and deliver it to the network. The QoS identifier associated with the Uu tributary can be derived from the end-to-end QoS identifier according to an allocation ratio, which can be a fixed value, a default value specified in the standard, a configuration value contained in system information received from the network, or a configuration value contained in dedicated signaling received from the network. Alternatively, the relay UE can forward only the end-to-end QoS identifier to the network, and the network can then determine or derive the QoS identifier associated with the Uu tributary itself. Regarding QoS parameters, apart from the QoS identifier, in the QoS flow description, the relay UE may only forward the QoS parameters to the network.

[0454] In one embodiment, a relay UE may transmit a PDU session modification request message to the network in response to receiving a requested QoS rule and / or a requested QoS flow description from a remote UE. The PDU session modification request message may include the requested QoS rule and a QoS flow description derived from the requested QoS flow description (e.g., indicating QoS requirements on a Uu tributary) (e.g., indicating end-to-end QoS requirements). The network may then provide the authorized QoS rule and authorized QoS flow description associated with the PDU session to the relay UE in a PDU session modification command message.

[0455] Figure 14 This is a flowchart 1400 from the perspective of a remote UE used to modify QoS information, according to an exemplary embodiment. In step 1405, the remote UE transmits a first message to the relay UE for QoS information modification, wherein the first message contains at least one QoS rule and / or at least one QoS flow description associated with a Protocol Data Unit (PDU) session. In one embodiment, the remote UE receives a second message from the relay UE to complete the QoS information modification.

[0456] In one embodiment, the first message may contain an identifier of the PDU session or a relay service code (RSC) associated with the PDU session. The second message may contain an identifier of the PDU session or a relay service code (RSC) associated with the PDU session. The RSC may be transmitted by the relay UE in a UE-to-network relay discovery message, enabling the remote UE to discover the relay UE that can provide relay services for the PDU session to the remote UE.

[0457] In one embodiment, each QoS rule may contain at least one of the following parameters: QoS Rule Identifier (QRI), QoS Flow Identifier (QFI), packet filter set, and priority value. Furthermore, each QoS flow description may contain at least one of the following parameters: QoS Flow Identifier (QFI), QoS Identifier, Guaranteed Flow Bit Rate (GFBR), Maximum Flow Bit Rate (MFBR), and EPS Bearer Identifier (EBI). The QoS Identifier in each QoS flow description may indicate the QoS requirements on the Uu tributary. The QoS Identifier in each QoS flow description may indicate end-to-end QoS requirements.

[0458] In one embodiment, the PDU session is established to allow the remote user equipment to access services from the data network via a relay UE. The first message may be a link modification request message. The second message may be a link modification acceptance message.

[0459] In one embodiment, each packet filter may be formed by at least any combination of the following: source / destination IP address or IPv6 prefix, source / destination port number, protocol ID of the protocol on the IP / Next Header type, Type of Service (TOS) (IPv4) / Class of Service (IPv6) and mask, flow label (IPv6), security parameter index, and packet filter direction. The source IP address or IPv6 prefix may be the IP address or IPv6 prefix of a remote UE, and the destination IP address or IPv6 prefix may be the IP address or IPv6 prefix of a relay UE. Alternatively, the source IP address or IPv6 prefix may be the IP address or IPv6 prefix of a remote UE, and the destination IP address or IPv6 prefix may be the IP address or IPv6 prefix of a data network.

[0460] Return to reference Figure 3 and Figure 4 In an exemplary embodiment of a remote UE for modifying QoS information, the remote UE 300 includes program code 312 stored in memory 310. CPU 308 executes program code 312 to enable the remote UE to transmit a first message to a relay UE for QoS information modification, wherein the first message contains at least one QoS rule and / or at least one QoS flow description associated with a PDU session. Furthermore, CPU 308 executes program code 312 to perform all the foregoing actions and steps or other actions and steps described herein.

[0461] Various aspects of this disclosure have been described above. It should be understood that the teachings herein can be embodied in a wide variety of forms, and any specific structure, function, or both disclosed herein are merely representative. Based on the teachings herein, those skilled in the art will understand that the aspects disclosed herein can be implemented independently of any other aspects, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement an apparatus or practice. Furthermore, such apparatuses or practices can be implemented using structures, functions, or structures and functions different from those set forth herein, in addition to one or more aspects. As examples of some of the foregoing concepts, in some aspects a parallel channel can be established based on the pulse repetition frequency. In some aspects a parallel channel can be established based on the pulse position or offset. In some aspects a parallel channel can be established based on a time-hopping sequence. In some aspects a parallel channel can be established based on the pulse repetition frequency, the pulse position or offset, and the time-hopping sequence.

[0462] Those skilled in the art will understand that information and signals can be represented using any of a variety of different techniques and skills. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description can be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, light fields or light particles, or any combination thereof.

[0463] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, processors, components, circuits, and algorithm steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of both, designed using source coding or some other technology) and have instructions in various forms of program or design code (which, for convenience, may be referred to herein as "software" or "software module") or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above in general terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the system as a whole. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of this disclosure.

[0464] Additionally, the various illustrative logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented within, or executed by, an integrated circuit (“IC”), an access terminal, or an access point. An IC may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within, outside, or both of the IC. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration.

[0465] It should be understood that any particular order or hierarchy of steps in any disclosed process is an instance of a sample method. It should be understood that a particular order or hierarchy of steps in the process may be rearranged based on design preferences while remaining within the scope of this disclosure. The appended method claims present the elements of each step in a sample order, but are not intended to limit one to the specific order or hierarchy presented.

[0466] The steps of the methods or algorithms described in conjunction with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of both. The software module (e.g., containing executable instructions and associated data) and other data may reside in a data memory, such as RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, removable disk, CD-ROM, or any other form of computer-readable storage medium known in the art. The sample storage medium may be coupled to a machine such as a computer / processor (which may be referred to herein as a "processor" for convenience), such that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. The sample storage medium may be integrated with the processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a user equipment. Alternatively, the processor and storage medium may reside as discrete components in a user equipment. Furthermore, in some aspects, any suitable computer program product may include a computer-readable medium comprising code associated with one or more aspects of this disclosure. In some aspects, the computer program product may include packaging material.

[0467] While the invention has been described in conjunction with various aspects, it should be understood that further modifications are possible. This application is intended to cover any changes, uses, or adaptations of the invention that generally follow the principles of the invention and include such deviations from this disclosure, which fall within the scope of known and customary practice in the art to which this invention pertains.

Claims

1. A method for modifying service quality information, characterized in that, include: The remote user equipment transmits a first message to the relay user equipment for service quality information modification, wherein the first message contains at least one service quality rule and at least one service quality flow description associated with a protocol data unit session, the protocol data unit session being established for the remote user equipment to access services from the data network via the relay user equipment, wherein each service quality rule contains a service quality rule identifier and a packet filter set.

2. The method according to claim 1, characterized in that, Further includes: The remote user equipment receives a second message from the relay user equipment to complete the modification of the quality of service information.

3. The method according to claim 2, characterized in that, The first message contains an identifier of the Protocol Data Unit (PDU) session or a relay service code associated with the PDU session, and / or the second message contains the identifier of the PDU session or the relay service code associated with the PDU session.

4. The method according to claim 1, characterized in that, Each quality of service rule also contains at least one of the following parameters: quality of service flow identifier and priority value.

5. The method according to claim 1, characterized in that, Each Quality of Service (QoS) flow description contains at least one of the following parameters: QoS flow identifier, QoS identifier, guaranteed flow bit rate, maximum flow bit rate, and EPS bearer identifier.

6. The method according to claim 5, characterized in that, The service quality identifier in each service quality flow description indicates the service quality requirements on the Uu tributary or the end-to-end service quality requirements.

7. The method according to claim 2, characterized in that, The first message is a link modification request message, and / or the second message is a link modification acceptance message.

8. The method according to claim 4, characterized in that, Each packet filter is formed by at least any combination of the following: source / destination IP address or IPv6 prefix, source / destination port number, protocol ID of the protocol on the IP / next header type, type of service (IPv4) / class of service (IPv6) and mask, flow label (IPv6), security parameter index and packet filter direction.

9. The method according to claim 8, characterized in that, The source IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the remote user equipment, and the destination IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the relay user equipment.

10. The method according to claim 8, characterized in that, The source IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the remote user equipment, and the destination IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the data network.

11. A remote user equipment, characterized in that, include: Control circuit; A processor, which is installed in the control circuit; as well as A memory, which is installed in the control circuit and operatively coupled to the processor; The processor is configured to execute program code stored in the memory to: A first message is transmitted to a relay user equipment for service quality information modification, wherein the first message contains at least one service quality rule and at least one service quality flow description associated with a protocol data unit session, the protocol data unit session being established for the remote user equipment to access services from the data network via the relay user equipment, wherein each service quality rule contains a service quality rule identifier and a packet filter set.

12. The remote user equipment according to claim 11, characterized in that, The processor is further configured to execute program code stored in the memory to: The second message is received from the relay user equipment to complete the modification of the quality of service information.

13. The remote user equipment according to claim 12, characterized in that, The first message contains an identifier of the Protocol Data Unit (PDU) session or a relay service code associated with the PDU session, and / or the second message contains the identifier of the PDU session or the relay service code associated with the PDU session.

14. The remote user equipment according to claim 11, characterized in that, Each quality of service rule also contains at least one of the following parameters: quality of service flow identifier and priority value.

15. The remote user equipment according to claim 11, characterized in that, Each Quality of Service (QoS) flow description contains at least one of the following parameters: QoS flow identifier, QoS identifier, guaranteed flow bit rate, maximum flow bit rate, and EPS bearer identifier.

16. The remote user equipment according to claim 15, characterized in that, The service quality identifier in each service quality flow description indicates the service quality requirements on the Uu tributary or the end-to-end service quality requirements.

17. The remote user equipment according to claim 12, characterized in that, The first message is a link modification request message, and / or the second message is a link modification acceptance message.

18. The remote user equipment according to claim 14, characterized in that, Each packet filter is formed by at least any combination of the following: source / destination IP address or IPv6 prefix, source / destination port number, protocol ID of the protocol on the IP / next header type, type of service (IPv4) / class of service (IPv6) and mask, flow label (IPv6), security parameter index and packet filter direction.

19. The remote user equipment according to claim 18, characterized in that, The source IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the remote user equipment, and the destination IP address or IPv6 prefix is ​​the IP address or IPv6 prefix of the relay user equipment.

Images