Method for user equipment connected with network in wireless communication system

Abstract

The invention discloses a method for user equipment connected with a network and the user equipment. A user equipment delivers a first protocol data unit from a first set of protocol data units of a quality of service flow to a first data radio bearer. The user equipment also receives a message or indication from the network for remapping the quality of service flow from the first data radio bearer to the second data radio bearer. Further, the user equipment delivers a second protocol data unit of the first set of protocol data units to the first data radio bearer, where the second protocol data unit is delivered to the first data radio bearer after receiving the message or indication.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 535,877 filed on August 31, 2023 and U.S. Provisional Patent Application No. 63 / 602,550 filed on November 24, 2023, the entire disclosures of the above U.S. Provisional Patent Applications are incorporated herein by reference in their entirety. Technical Field

[0003] The present disclosure relates generally to a wireless communication network, and more particularly, to a method and apparatus for remapping Quality of Service (QOS) flows with Protocol Data Unit (PDU) set considerations in a wireless communication system. Background Art

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

[0005] An exemplary network structure is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). The E-UTRAN system can provide high data throughput to enable the above-mentioned IP-borne voice and multimedia services. Currently, the 3GPP standards organization is discussing new radio technologies for the next generation (e.g., 5G). Therefore, changes to the current body of 3GPP standards are currently being submitted and considered to enable the 3GPP standards to evolve and be completed. Summary of the invention

[0006] A method and apparatus for a user equipment (UE) connected to a network are disclosed. In one embodiment, the UE delivers a first protocol data unit (PDU) from a first set of quality of service (QoS) flows to a first data radio bearer (DRB). The UE also receives a message or indication from the network for remapping the QoS flow from the first DRB to a second DRB. In addition, the user equipment delivers a second PDU of the first PDU set to the first DRB, wherein the second PDU is delivered to the first DRB after receiving the message or indication. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1A diagram showing a wireless communication system according to an exemplary embodiment;

[0008] Figure 2 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 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 It is 3GPP TS 38.331V17.0.0 Figure 5 .3.5.1-1 reappearance;

[0012] Figure 6 It is 3GPP TS 37.324V17.0.0 Figure 4 .2.2-1 reappearance;

[0013] Figure 7 It is 3GPP TS 37.324V17.0.0 Figure 6 .2.2.1-1 reappearance;

[0014] Figure 8 It is 3GPP TS 37.324V17.0.0 Figure 6 .2.2.2-1 reappearance;

[0015] Fig. 9 It is 3GPP TS 37.324V17.0.0 Figure 6 .2.2.3-1 reappearance;

[0016] Fig.10 It is 3GPP TS 37.324V17.0.0 Figure 6 .2.3-1 reappearance;

[0017] Fig.11 It is a reproduction of Table 6.3.3-1 of 3GPP TS 37.324 V17.0.0;

[0018] Fig.12 It is a reproduction of Table 6.3.6-1 of 3GPP TS 37.324 V17.0.0;

[0019] Fig.13 It is a reproduction of Table 6.3.7-1 of 3GPP TS 37.324 V17.0.0;

[0020] Fig.14 It is 3GPP TS 38.300V17.0.0 Figure 6 .6-1 reappearance;

[0021] Fig.15 It is 3GPP TS 38.300V17.0.0 Figure 12-1 the reappearance of;

[0022] Fig.16 is a reproduction of Figure A.1-1 of 3GPP TS 38.300 V17.0.0;

[0023] Fig.17 is a reproduction of Figure A.6-1 of 3GPP TS 38.300 V17.0.0;

[0024] Fig.18 It is 3GPP TR 23.700-60V1.2.0 Figure 6 .7.3.1.1-1 reappearance;

[0025] Fig.19 It is 3GPP TR 23.700-60V1.2.0 Figure 6 .7.3.2-1 reappearance;

[0026] Fig. 20 It is 3GPP TR 23.700-60V1.2.0 Figure 6 .7.3.3-1 reappearance;

[0027] Fig.21 is a flow chart according to an exemplary embodiment;

[0028] Fig. 22 is a flow chart according to an exemplary embodiment;

[0029] Fig.23 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION

[0030] The exemplary wireless communication systems and devices described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communications, such as voice, data, etc. These systems can 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), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation technology.

[0031] In particular, the exemplary wireless communication systems and devices described below may be designed to support one or more standards, such as those provided by a consortium named "3rd Generation Partnership Project", referred to herein as 3GPP, including: TS 38.331 V17.0.0, "NR; Radio Resource Control (RRC) Protocol Specification (Release 17)"; TS 37.324 V17.0.0, "NR; Service Data Adaptation Protocol (SDAP) Specification (Release 17)"; TS 38.323 V17.0.0, "NR; Packet Data Convergence Protocol (PDCP) Specification (Release 17)"; TS 38.300 V17.0.0, "NR; NR and NG-RAN Overall Description; Stage 2 (Release 17)"; TR 23.700-60 V1.2.0, "Study on XR (Extended Reality) and Media Services (Release 18)"; TR 38.835 V18.0.1, "Study on XR Enhancements for NR (Release 18)"; 3GPP RAN2 Meeting Chair Notes: "RAN2-122 LTE MUSIM QoE XR (Tero)_2023-05-23-1704.docx" (RAN2#122) and "R2_123_SL_Session Notes (Kyeongin Jeong)_EoM.docx" (RAN2#123); 3GPP Email Discussion [Post124]

[040] [XR] 38.331 CR (Huawei), "In TS 38.331_rev2_v00_rapp.docx"; and 3GPP email discussion [Post124]

[042] [XR] 38.323CR(LGE), "Introduction of R2-23xxxxx 38323CR0128r1XREnhancements_r0.docx". The standards and documents listed above are hereby expressly incorporated by reference in their entirety.

[0032] Figure 1 1 shows a multiple access wireless communication system according to an embodiment of the present invention. An access network 100 (AN) includes multiple antenna groups, one including 104 and 106, another including 108 and 110, and another including 112 and 114. Figure 1 In the figure, only two antennas are shown for each antenna group, however, each antenna group may utilize more or fewer antennas. Access terminal 116 (Access terminal, AT) communicates with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 via forward link 120 and receive information from access terminal 116 via reverse link 118. Access terminal (Access terminal, AT) 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to access terminal (Access terminal, AT) 122 via forward link 126 and receive information from access terminal (Access terminal, AT) 122 via reverse link 124. In an 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 the frequency used by reverse link 118.

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

[0034] In communicating over forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve the signal-to-noise ratio of the forward links for the different access terminals 116 and 122. Also, an access network that uses beamforming to transmit to access terminals that are randomly dispersed throughout the coverage area of ​​the access network may generate less interference to access terminals in neighboring cells than an access network that transmits to all of its access terminals via a single antenna.

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

[0036] Figure 22 is a simplified block diagram of an embodiment of 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)) in a MIMO system 200. At the transmitter system 210, traffic data for a number of data streams is provided from a data source 212 to a transmit (TX) data processor 214.

[0037] In one embodiment, each data stream is transmitted through a respective transmit antenna.TX data processor 214 formats, codes, and interleaves the traffic data for each data stream based on a particular coding scheme selected for that data stream to provide coded data.

[0038] The coded data for each data stream may be multiplexed with pilot data using OFDM techniques. The pilot data is typically a known data pattern that is processed in a known manner and may be used at the receiver system to estimate the channel response. The multiplexed pilot and coded data for each data stream is then modulated (i.e., symbol mapped) based on a particular modulation scheme (e.g., BPSK, QPSK, M-PSK, or M-QAM) selected for that data stream to provide modulation symbols. Instructions executed by processor 230 may determine the data rate, coding, and modulation for each data stream.

[0039] The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which may further process the modulation symbols (e.g., for OFDM). The TX MIMO processor 220 then converts the N T The modulation symbol stream is provided to N T transmitters (TMTR) 222a through 222t. In certain embodiments, TX MIMO processor 220 applies beamforming weights to the symbols of the data streams and to the antenna from which the symbol is being transmitted.

[0040] Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (eg, amplifies, filters, and up-converts) the analog signals to provide a modulated signal suitable for transmission via a MIMO channel. T The antennas 224a to 224t transmit the N signals from the transmitters 222a to 222t. T a modulated signal.

[0041] At the receiver system 250, N RThe transmitted modulated signals are received by each antenna 252a through 252r and the received signal from each antenna 252 is provided to a respective receiver (RCVR) 254a through 254r. Each receiver 254 conditions (e.g., filters, amplifies, and downconverts) a respective received signal, digitizes the conditioned signal to provide samples, and further processes the samples to provide a corresponding “received” symbol stream.

[0042] RX data processor 260 then extracts the N R The receiver 254 receives and processes N R received symbol streams to provide N T The RX data processor 260 then demodulates, deinterleaves, and decodes each detected symbol stream to recover the traffic data for the data stream. The processing by the RX data processor 260 is complementary to the processing performed by the TX MIMO processor 220 and the TX data processor 214 at the transmitter system 210.

[0043] Processor 270 periodically determines which pre-coding matrix to use (discussed below). Processor 270 formulates a reverse link message comprising a matrix index portion and a rank value portion.

[0044] 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 traffic data for a number of data streams from the data source 236), modulated by the modulator 280, conditioned by the transmitters 254a to 254r, and transmitted back to the transmitter system 210.

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

[0046] Go to Figure 3 , this figure shows an alternative simplified functional block diagram of a communication device according to one embodiment of the present invention. Figure 3 As shown, the communication device 300 in the wireless communication system can be used to implement Figure 1 UE (or AT) 116 and 122 in or Figure 1The base station (or AN) 100 in 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, a program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 through the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 can receive signals input by the user through the input device 302 (for example, a keyboard or a keypad), and can output images and sounds through the output device 304 (for example, a monitor or a speaker). The transceiver 314 is used to receive and transmit wireless signals, pass the received signals to the control circuit 306, and wirelessly output the signals generated by the control circuit 306. The communication device 300 in the wireless communication system can also be used to implement Figure 1 AN 100 in.

[0047] Figure 4 According to one embodiment of the present invention, Figure 3 4. In this embodiment, program code 312 includes application layer 400, layer 3 portion 402, and layer 2 portion 404, and is coupled to 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 connectivity.

[0048] 3GPP TS 38.331 introduces Radio Resource Control (RRC) reconfiguration for UE to establish Radio Bearers / Radio Link Control (RLC) channels as follows:

[0049] 5.3.5RRC Reconfiguration

[0050] 5.3.5.1 General

[0051] [3GPP TS 38.331 V17.0.0 titled "RRC reconfiguration, success" Figure 5 .3.5.1-1 is reproduced as Figure 5 ]

[0052] […]

[0053] The purpose of this procedure is to modify the RRC connection, such as establish / modify / release RB / BH RLC channels, perform reconfiguration with synchronization, set up / modify / release measurements, add / modify / release SCells and cell groups, add / modify / release conditional handover configuration, add / modify / release conditional PSCell change or conditional PSCell add configuration. As part of the procedure, NAS specific information may be transferred from the network to the UE.

[0054] Performing RRC reconfiguration with synchronized reconfiguration includes but is not limited to the following:

[0055] - Reconfiguration with synchronization and security key refresh involving RA of PCell / PSCell, MAC reset, security refresh, and re-establishment of RLC and PDCP triggered by explicit L2 indicators;

[0056] - Reconfiguration with synchronization but without security key refresh, involving RA of PCell / PSCell, MAC reset, and RLC re-establishment and PDCP data resumption (for AM DRB or AM MRB) triggered by explicit L2 indicators.

[0057] - Reconfiguration with synchronization and security key refresh for DAPS, involving establishment of RA, target MAC of target PCell, and

[0058] - For non-DAPS bearers: security refresh and re-establishment of RLC and PDCP triggered by explicit L2 indicators;

[0059] - For DAPS bearer: establishment of RLC for target PCell, security refresh, and reconfiguration of PDCP to add encryption function, integrity protection function and ROHC function of target PCell;

[0060] - For SRB: security refresh and establishment of RLC and PDCP for the target PCell;

[0061] - Reconfiguration with synchronization for DAPS but without security key refresh, involving establishment of RA, target MAC of target PCell, and

[0062] - For non-DAPS bearers: RLC re-establishment and PDCP data resumption (for AMDRB or AM MRB) triggered by explicit L2 indicators.

[0063] - For DAPS bearer: establishment of RLC for target PCell, reconfiguration of PDCP for adding encryption function, integrity protection function and ROHC function of target PCell;

[0064] - For SRB: Establishment of RLC and PDCP for the target PCell.

[0065] In (NG)EN-DC and NR-DC, SRB3 can be used for measurement configuration and reporting, UE-assisted (re)configuration and reporting for power saving, IP address (re)configuration and reporting for IAB nodes, to (re)configure constants for MAC, RLC, BAP, physical layer and RLF timers and SCG configuration, and for communication with SK gNB or SRB3 and reconfigure PDCP for DRBs associated with SK in NGEN-DC and NR-DC gNB The associated DRB reconfiguration SDAP, and adding / modifying / releasing conditional PSCell change configuration, provided that the (re)configuration does not require any MN participation, and RRC messages are transmitted between MN and UE during fast MCG link recovery. In (NG)EN-DC and NR-DC, only measConfig, radioBearerConfig, conditionalReconfiguration, bap-Config, iab-IP-AddressConfigurationList, otherConfig and / or secondaryCellGroup are included in the RRCReconfiguration received via SRB3, except when the RRCReconfiguration is received within DLInformationTransferMRDC.

[0066] 5.3.5.2 Initiation

[0067] The network may initiate the RRC reconfiguration procedure to the UE in RRC_CONNECTED. The network applies the following procedure:

[0068] - Establishment of RBs is performed only when AS security has been activated (not SRB1, which is established during RRC connection establishment);

[0069] - Establishment of the BH RLC channel for IAB is performed only if AS security has been activated;

[0070] - Establishment of Uu relay RLC channels for L2 U2N relay UEs is performed only if AS security has been activated;

[0071] - Addition of secondary cell groups and SCells is performed only when AS security has been activated;

[0072] - reconfigurationWithSync is included in secondaryCellGroup only if at least one RLC bearer or BH RLC channel is set up in the SCG;

[0073] - reconfigurationWithSync is included in the masterCellGroup only if AS security has been activated, and SRB2 with at least one DRB or multicast MRB or SRB2 for IAB is set and not suspended;

[0074] -ConditionalReconfiguration for CPC is included only if at least one RLC bearer is set up in the SCG;

[0075] -Contains conditionalReconfiguration for CHO or CPA only if AS security is activated, and SRB2 with at least one DRB or SRB2 for IAB is set up and not suspended.

[0076] 5.3.5.3UE receives RRCReconfiguration

[0077] The UE shall perform the following actions after receiving RRCReconfiguration or after performing a conditional reconfiguration (CHO, CPA or CPC):

[0078] 1> If RRCReconfiguration is received neither in mrdc-SecondaryCellGroup nor in E-UTRARRCConnectionReconfiguration nor in E-UTRARRCConnectionResume:

[0079] 2> If RRCReconfiguration contains scg-State:

[0080] 3>Perform SCG deactivation as specified in 5.3.5.13b;

[0081] 2> Otherwise:

[0082] 3>Perform SCG activation as specified in 5.3.5.13a;

[0083] Editor's Note: How to ensure that notifications to the MAC are only processed when the SCG configuration (if included) is processed is for further study.

[0084] 1> If RRCReconfiguration is applied due to conditional reconfiguration execution after cell selection when timer T311 is running, as defined in 5.3.7.3, then:

[0085] 2> Remove all entries in VarConditionalReconfig (if they exist);

[0086] 1> If RRCReconfiguration contains daps-SourceRelease:

[0087] 2> Reset the source MAC and release the source MAC configuration;

[0088] 2> For each DAPS bearer:

[0089] 3> Release the RLC entity or entities as specified in clause 5.1.3 of TS 38.322 [4] and the associated logical channels for the source SpCell;

[0090] 3> reconfigure the PDCP entity to release the DAPS as specified in TS 38.323 [5];

[0091] 2>For each SRB:

[0092] 3> Release the PDCP entity for the source SpCell;

[0093] 3> Release the RLC entity and associated logical channels for the source SpCell as specified in TS 38.322 [4] clause 5.1.3;

[0094] 2> Release the physical channel configuration for the source SpCell;

[0095] 2>Discard the key (K gNB Key, K RRCenc Key, K RRCint Key, K UPint Key and K UPenc key) (if it exists);

[0096] 1> If RRCReconfiguration is received via other RAT (i.e., inter-RAT handover to NR):

[0097] 2> If RRCReconfiguration does not contain fullConfig and the UE is connected to 5GC (i.e., differential signaling during intra-frame 5GC switching):

[0098] 3> Reuse the source RAT SDAP and PDCP configuration if available (i.e. the current SDAP / PDCP configuration for all RBs from the source E-UTRA RAT before receiving the Inter-RAT HORRCReconfiguration message);

[0099] 1> Otherwise:

[0100] 2> If RRCReconfiguration contains fullConfig:

[0101] 3> Perform the full configuration procedure as specified in 5.3.5.11;

[0102] 1> If RRCReconfiguration contains masterCellGroup:

[0103] 2> According to 5.3.5.5, perform cell group configuration for the received masterCellGroup;

[0104] 1> If RRCReconfiguration contains masterKeyUpdate, then:

[0105] 2>Perform the AS security key update procedure as specified in 5.3.5.7;

[0106] 1> If RRCReconfiguration contains sk-Counter, then:

[0107] 2>Perform the security key update procedure as specified in 5.3.5.7;

[0108] 1> If RRCReconfiguration contains secondaryCellGroup, then:

[0109] 2>Perform SCG cell group configuration according to 5.3.5.5;

[0110] 1> If RRCReconfiguration contains mrdc-SecondaryCellGroupConfig:

[0111] 2> If mrdc-SecondaryCellGroupConfig is set to:

[0112] 3>If mrdc-SecondaryCellGroupConfig contains mrdc-ReleaseAndAdd:

[0113] 4>Perform MR-DC release as specified in clause 5.3.5.10;

[0114] 3> If the received mrdc-SecondaryCellGroup is set to nr-SCG:

[0115] 4> According to 5.3.5.3, perform RRC reconfiguration for the RRCReconfiguration message contained in nr-SCG;

[0116] 3> If the received mrdc-SecondaryCellGroup is set to eutra-SCG:

[0117] 4> Perform RRC connection reconfiguration for the RRCConnectionReconfiguration message contained in the eutra-SCG as specified in TS 36.331

[10] clause 5.3.5.3;

[0118] 2> Otherwise (mrdc-SecondaryCellGroupConfig is set to release):

[0119] 3>Perform MR-DC release as specified in clause 5.3.5.10;

[0120] 1> If the RRCReconfiguration message contains radioBearerConfig:

[0121] 2> Perform radio bearer configuration according to 5.3.5.6;

[0122] 1> If the RRCReconfiguration message contains radioBearerConfig2:

[0123] 2> Perform radio bearer configuration according to 5.3.5.6;

[0124] 1> If the RRCReconfiguration message contains measConfig:

[0125] 2> Execute the measurement configuration procedure as specified in 5.5.2;

[0126] 1> If the RRCReconfiguration message contains dedicatedNAS-MessageList:

[0127] 2> Forward each element of dedicatedNAS-MessageList to the upper layer in the same order as listed;

[0128] 1> If the RRCReconfiguration message contains dedicatedSIB1-Delivery:

[0129] 2> Perform actions after receiving SIB1, as specified in 5.2.2.4.2;

[0130] NOTE 0: If this RRCReconfiguration is associated with an MCG and contains reconfigurationWithSync in spCellConfig and dedicatedSIB1-Delivery, then according to clause 5.2.2.3.5, the UE shall initiate (if necessary) a request to obtain the required SIBs only after the random access procedure towards the target SpCell is completed.

[0131] 1> If the RRCReconfiguration message contains dedicatedSystemInformationDelivery:

[0132] 2> Perform actions after receiving system information, as specified in 5.2.2.4;

[0133] 1> If the RRCReconfiguration message contains dedicatedPosSysInfoDelivery:

[0134] 2> perform actions after receiving the contained posSIB, as specified in clause 5.2.2.4.16;

[0135] 1> If the RRCReconfiguration message contains otherConfig:

[0136] 2>Perform other configuration procedures, as specified in 5.3.5.9;

[0137] 1> If the RRCReconfiguration message contains bap-Config:

[0138] 2>Execute the BAP configuration procedure as specified in 5.3.5.12;

[0139] 1> If the RRCReconfiguration message contains iab-IP-AddressConfigurationList:

[0140] 2> If iab-IP-AddressToReleaseList is included:

[0141] 3>Perform release of IP addresses, as specified in 5.3.5.12a.1.1;

[0142] 2> If iab-IP-AddressToAddModList is included:

[0143] 3> Perform IAB IP address addition / update as specified in 5.3.5.12a.1.2;

[0144] 1> If the RRCReconfiguration message contains conditionalReconfiguration:

[0145] 2>Perform conditional reconfiguration as specified in 5.3.5.13;

[0146] 1> If the RRCReconfiguration message contains needForGapsConfigNR:

[0147] 2> If needForGapsConfigNR is set to set:

[0148] 3> regard itself as configured to provide measurement gap requirement information for the NR target band;

[0149] 2> Otherwise:

[0150] 3> regard itself as not configured to provide measurement gap requirement information for the NR target band;

[0151] 1> If the RRCReconfiguration message contains needForNCSG-ConfigNR:

[0152] 2> If needForNCSG-ConfigNR is set to set:

[0153] 3> regard itself as configured to provide the measurement gap and NCSG requirement information of the NR target band;

[0154] 2> Otherwise:

[0155] 3> Treat itself as not configured to provide measurement gap and NCSG requirement information for the NR target band;

[0156] 1> If the RRCReconfiguration message contains needForNCSG-ConfigEUTRA:

[0157] 2> If needForNCSG-ConfigEUTRA is set to:

[0158] 3> regard itself as configured to provide measurement gap and NCSG requirement information for the E-UTRA target band;

[0159] 2> Otherwise:

[0160] 3> Treat itself as not configured to provide measurement gap and NCSG requirement information for the E-UTRA target band;

[0161] 1> If the RRCReconfiguration message contains sl-ConfigDedicatedNR:

[0162] 2> Execute the sidelink-specific configuration procedure as specified in 5.3.5.14;

[0163] NOTE 0a: If an sl-ConfigDedicatedNR is received embedded in an E-UTRARRCConnectionReconfiguration message, the UE does not construct an NRRCReconfigurationComplete message for the received sl-ConfigDedicatedNR.

[0164] 1> If the RRCReconfiguration message contains sl-L2RelayUEConfig:

[0165] 2> Perform the L2 U2N relay UE configuration procedure as specified in 5.3.5.15;

[0166] 1> If the RRCReconfiguration message contains sl-L2RemoteUEConfig:

[0167] 2> Perform the L2 U2N remote UE configuration procedure as specified in 5.3.5.16;

[0168] 1> If the RRCReconfiguration message contains dedicatedPagingDelivery:

[0169] 2> If the ue-Identity contained in the PagingRecord in the paging message matches the UE identity in the sl-PagingIdentity-RemoteUE in the sl-PagingInfo-RemoteUE received in the RemoteUEInformationSidelink message according to 5.8.9.8.3:

[0170] 3> Initiate Uu message transmission in the side link as specified in 5.8.9.9;

[0171] 1> If the RRCReconfiguration message contains sl-ConfigDedicatedEUTRA-Info:

[0172] 2> Execute the relevant procedures for V2X sidelink communication according to TS 36.331

[10] clauses 5.3.10 and 5.5.2;

[0173] 1> If the RRCReconfiguration message contains ul-GapFR2-Config:

[0174] 2>Perform the FR2 UL gap configuration procedure as specified in 5.3.5.13c;

[0175] 1> If the RRCReconfiguration message contains musim-GapConfig:

[0176] 2> For each periodic musim-GapID included in the received musim-GapToReleaseList:

[0177] 3> Release the MUSIM periodic gap associated to musim-GapID from musim-GapConfigList;

[0178] 2> For each periodic musim-GapID included in the received musim-GapToAddModList:

[0179] 3> If an entry with a matching musim-GapID exists in musim-GapConfigList:

[0180] 4> Replace the entry with the value received for this musim-GapID;

[0181] 3> Otherwise:

[0182] 4>Add a new entry for this musim-GapID;

[0183] 1> If the RRCReconfiguration message contains appLayerMeasConfig:

[0184] 2> Execute the application layer measurement configuration procedure as specified in 5.3.5.13d;

[0185] 1> Set the content of the RRCReconfigurationComplete message as follows:

[0186] 2> If RRCReconfiguration contains a masterCellGroup with reportUplinkTxDirectCurrent:

[0187] 3>Contain uplinkTxDirectCurrentList for each MCG serving cell with UL;

[0188] 3> Include uplinkDirectCurrentBWP-SUL in uplinkTxDirectCurrentList for each MCG serving cell configured with a SUL carrier (if any);

[0189] 2> If RRCReconfiguration contains a masterCellGroup with reportUplinkTxDirectCurrentTwoCarrier:

[0190] 3> Include the uplink Tx DC position list for configured intra-band uplink carrier aggregation in MCG in uplinkTxDirectCurrentTwoCarrierList;

[0191] 2> If RRCReconfiguration contains secondaryCellGroup with reportUplinkTxDirectCurrent:

[0192] 3> uplinkTxDirectCurrentList containing each SCG serving cell with UL;

[0193] 3> Include uplinkDirectCurrentBWP-SUL in uplinkTxDirectCurrentList for each SCG serving cell configured with a SUL carrier (if any);

[0194] 2> If RRCReconfiguration contains secondaryCellGroup with reportUplinkTxDirectCurrentTwoCarrier:

[0195] 3> Include the uplink Tx DC position list for configured intra-band uplink carrier aggregation in SCG in uplinkTxDirectCurrentTwoCarrierList;

[0196] NOTE 0b: reportUplinkTxDirectCurrentTwoCarrier is expected to be received only in masterCellGroup or secondaryCellGroup but not in both.

[0197] 2> If the RRCReconfiguration message contains mrdc-SecondaryCellGroupConfig, where mrdc-SecondaryCellGroup is set to eutra-SCG:

[0198] 3> In accordance with TS 36.331

[10] clause 5.3.5.3, include the E-UTRA RRCConnectionReconfigurationComplete message in the eutra-SCG-Response;

[0199] 2> If the RRCReconfiguration message contains mrdc-SecondaryCellGroupConfig, where mrdc-SecondaryCellGroup is set to nr-SCG:

[0200] 3> Include SCG RRCReconfigurationComplete message in nr-SCG-Response;

[0201] 3> If the RRCReconfiguration message is applied due to conditional reconfiguration execution:

[0202] 4>Contain condReconfigId of the selected cell for conditional reconfiguration execution in selectedCondRRCReconfig;

[0203] 2> If RRCReconfiguration contains reconfigurationWithSync in spCellConfig of MCG:

[0204] 3> If the UE has logged measurements available for the NR and if the RPLMN is contained in the plmn-IdentityList stored in the VarLogMeasReport:

[0205] 4> If sigLoggedMeasType in VarLogMeasReport is included:

[0206] 5> Include sigLogMeasConfigAvailable in the RRCReconfigurationComplete message and set it according to the following:

[0207] 6> If the T330 timer is running:

[0208] 7> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message;

[0209] 6> Otherwise:

[0210] 7> Set sigLogMeasConfigAvailable to false in the RRCReconfigurationComplete message;

[0211] 4> Include logMeasAvailable in the RRCReconfigurationComplete message;

[0212] 4> If Bluetooth measurements are included in the logged measurements, the UE can be used for NR:

[0213] 5> Include logMeasAvailableBT in the RRCReconfigurationComplete message;

[0214] 4> If WLAN measurements are included in the logged measurements, the UE can be used for NR:

[0215] 5> Include logMeasAvailableWLAN in the RRCReconfigurationComplete message;

[0216] 3> If sigLoggedMeasType in VarLogMeasReport is included:

[0217] 4> If the T330 timer is running:

[0218] 5> Set sigLogMeasConfigAvailable to true in the RRCReconfigurationComplete message;

[0219] 4> Otherwise:

[0220] 5> If the UE has recorded measurements available for NR:

[0221] 6> Set sigLogMeasConfigAvailable to false in the RRCReconfigurationComplete message;

[0222] 3> If the UE has connection establishment failure or connection recovery failure information available in VarConnEstFailReport and if RPLMN is equal to the plmn-Identity stored in VarConnEstFailReport or VarConnEstFailReportList:

[0223] 4> Include connEstFailInfoAvailable in the RRCReconfigurationComplete message;

[0224] 3> if the UE has radio link failure or handover failure information available in the VarRLF-Report and if the RPLMN is contained in the plmn-IdentityList stored in the VarRLF-Report; or

[0225] 3> If the UE has radio link failure or handover failure information available in the VarRLF-Report of TS 36.331

[10] and if the UE is capable of inter-RAT RLF reporting and if the RPLMN is contained in the plmn-IdentityList stored in the VarRLF-Report of TS 36.331

[10] :

[0226] 4> Include rlf-InfoAvailable in the RRCReconfigurationComplete message;

[0227] 3> If the UE was configured with successHO-Config when connected to the source PCell; and

[0228] 3> If the RRCReconfiguration applied is not due to a conditional reconfiguration after cell selection performed while timer T311 is running, as defined in 5.3.7.3:

[0229] 4> after successfully completing the random access procedure triggered by reconfigurationWithSync in spCellConfig for MCG, perform the actions for successful handover report determination as specified in clause 5.7.10.6;

[0230] 3> If the UE has successful handover information available in the VarSuccessHO-Report and if the RPLMN is contained in the plmn-IdentityList stored in the VarSuccessHO-Report:

[0231] 4> Include successHO-InfoAvailable in the RRCReconfigurationComplete message;

[0232] 2> If the RRCReconfiguration message is received via SRB1 instead of within mrdc-SecondaryCellGroup or E-UTRARRCConnectionReconfiguration or E-UTRARRCConnectionResume:

[0233] 3> If the UE is configured to provide measurement gap requirement information for the NR target band:

[0234] 4> If the RRCReconfiguration message contains needForGapsConfigNR; or

[0235] 4> If the NeedForGapsInfoNR information changes compared to the last time the UE reported this information:

[0236] 5> Include NeedForGapsInfoNR and set the content as follows:

[0237] 6> Include intraFreq-needForGap and set the gap requirement information for the same-frequency measurement for each NR serving cell;

[0238] 6> If requestedTargetBandFilterNR is configured, for each supported NR band also included in requestedTargetBandFilterNR, include an entry in interFreq-needForGap and set the gap requirement information of the band; otherwise, include an entry in interFreq-needForGap and set the corresponding gap requirement information of each supported NR band;

[0239] 3> If the UE is configured to provide measurement gap and NCSG requirement information for the NR target band:

[0240] 4> If the RRCReconfiguration message contains needForNCSG-ConfigNR; or

[0241] 4> If the needForNCSG-InfoNR information changes compared to the last time the UE reported this information:

[0242] 5> Include NeedForNCSG-InfoNR and set the content as follows:

[0243] 6>contains intraFreq-needForNCSG and sets the gap and NCSG requirement information for intra-frequency measurement of each NR serving cell;

[0244] 6> If requestedTargetBandFilterNCSG-NR is configured, for each supported NR band included in requestedTargetBandFilterNCSG-NR, include an entry in interFreq-needForNCSG and set the NCSG requirement information for the band; otherwise, include an entry for each supported NR band in interFreq-needForNCSG and set the corresponding NCSG requirement information;

[0245] 3> If the UE is configured to provide measurement gap and NCSG requirement information for the E-UTRA target band:

[0246] 4> If the RRCReconfiguration message contains needForNCSG-ConfigEUTRA; or

[0247] 4> If the needForNCSG-InfoEUTRA information has changed compared to the last time the UE reported this information:

[0248] 5> Include NeedForNCSG-InfoEUTRA and set the content as follows:

[0249] 6> If requestedTargetBandFilterNCSG-EUTRA is configured, for each supported NR band included in requestedTargetBandFilterNCSG-EUTRA, include an entry in needForNCSG-EUTRA and set the NCSG requirement information for that band; otherwise, include an entry for each supported E-UTRA band in needForNCSG-EUTRA and set the corresponding NCSG requirement information;

[0250] 1> If the UE is configured with E-UTRAnr-SecondaryCellGroupConfig (UE is in (NG) EN-DC):

[0251] 2> if the RRCReconfiguration message is received via E-UTRA SRB1 as specified in TS 36.331

[10] ; or

[0252] 2> If the RRCReconfiguration message is received via the E-UTRARRC message RRCConnectionReconfiguration within MobilityFromNRCommand (handover from NR standalone to (NG)EN-DC);

[0253] 3> If RRCReconfiguration is applied due to conditional reconfiguration execution for CPC, the CPC is configured via conditionalReconfiguration contained in nr-SecondaryCellGroupConfig specified in TS 36.331

[10] :

[0254] 4> Submitting the RRCReconfigurationComplete message via the E-UTRA MCG embedded in the E-UTRARRC message ULInformationTransferMRDC as specified in TS 36.331

[10] clause 5.6.2a.

[0255] 3> Otherwise if the RRCReconfiguration message is included in the E-UTRARRCConnectionResume message:

[0256] 4> submitting an RRCReconfigurationComplete message via E-UTRA embedded in the E-UTRA RRC message RRCConnectionResumeComplete as specified in TS 36.331

[10] clause 5.3.3.4a;

[0257] 3> Otherwise:

[0258] 4> submitting RRCReconfigurationComplete via E-UTRA embedded in the E-UTRARRC message RRCConnectionReconfigurationComplete as specified in TS 36.331

[10] clause 5.3.5.3 / 5.3.5.4 / 5.4.2.3;

[0259] 3> If scg-State is not included in the E-UTRARRCConnectionReconfiguration message containing the RRCReconfiguration message:

[0260] 4> if reconfigurationWithSync is included in spCellConfig of SCG; or

[0261] 4> If the SCG is deactivated before the reception of the E-UTRA RRC message containing the RRCReconfiguration message and the lower layers consider that a random access procedure is required for SCG activation:

[0262] 5> Initiate a random access procedure on the SpCell as specified in TS 38.321[3];

[0263] 4> Otherwise:

[0264] 5>The program ends;

[0265] 3> Otherwise:

[0266] 4>The program ends;

[0267] 2> If the RRCReconfiguration message is received in nr-SecondaryCellGroupConfig in an RRCConnectionReconfiguration message received via SRB3 in DLInformationTransferMRDC:

[0268] 3> submitting RRCReconfigurationComplete via E-UTRA embedded in the E-UTRARRC message RRCConnectionReconfigurationComplete as specified in TS 36.331

[10] clauses 5.3.5.3 / 5.3.5.4;

[0269] 3> If reconfigurationWithSync is included in spCellConfig of SCG:

[0270] 4> Initiate a random access procedure on the SpCell as specified in TS 38.321[3];

[0271] 3> Otherwise:

[0272] 4>The program ends;

[0273] NOTE 1: The order in which the UE sends the RRCConnectionReconfigurationComplete message and performs the random access procedure towards the SCG depends on the UE implementation.

[0274] 2> Otherwise (RRCReconfiguration is received via SRB3) but not in DLInformationTransferMRDC:

[0275] 3> Submit the RRCReconfigurationComplete message to the lower layer via SRB3 to transmit using the new configuration;

[0276] NOTE 2: In (NG)EN-DC and NR-DC, in the case where RRCReconfiguration is received via SRB1 or via SRB3 within DLInformationTransferMRDC, random access is triggered by the RRC layer itself, as there may not be other UL transmissions. In the case where RRCReconfiguration is received via SRB3 but not within DLInformationTransferMRDC, random access is triggered by the MAC layer due to the arrival of RRCReconfigurationComplete.

[0277] 1> Otherwise if the RRCReconfiguration message is received via SRB1 in nr-SCG in mrdc-SecondaryCellGroup (UE in NR-DC, mrdc-SecondaryCellGroup is received via SRB1 in RRCReconfiguration or RRCResume):

[0278] 2> If RRCReconfiguration is applied due to conditional reconfiguration execution for CPC, the CPC is configured via conditionalReconfiguration contained in nr-SCG within mrdc-SecondaryCellGroup:

[0279] 3> Submit an RRCReconfigurationComplete message via the NR MCG embedded in the NR RRC message ULInformationTransferMRDC as specified in clause 5.7.2a.3.

[0280] 2> If scg-State is not included in the RRCReconfiguration or RRCResume message containing the RRCReconfiguration message:

[0281] 3> if reconfigurationWithSync is included in spCellConfig in nr-SCG; or

[0282] 3> If the SCG is deactivated before the reception of the NR RRC message containing the RRCReconfiguration message, and the lower layers consider that a random access procedure is required for SCG activation:

[0283] 4> Initiate a random access procedure on the PSCell as specified in TS 38.321[3];

[0284] 3> Otherwise:

[0285] 4>The program ends;

[0286] 2> Otherwise

[0287] 3>The program ends;

[0288] NOTE 2a: The order in which the UE sends the RRCReconfigurationComplete message and performs the random access procedure towards the SCG depends on the UE implementation.

[0289] 1> Otherwise if the RRCReconfiguration message is received via SRB3 (UE in NR-DC):

[0290] 2> If the RRCReconfiguration message is received in DLInformationTransferMRDC:

[0291] 3> If the RRCReconfiguration message is received in nr-SCG within mrdc-SecondaryCellGroup (NR SCG RRC reconfiguration):

[0292] 4> If reconfigurationWithSync is included in spCellConfig in nr-SCG:

[0293] 5> Initiate a random access procedure on the PSCell as specified in TS 38.321[3];

[0294] 4> Otherwise:

[0295] 5>The program ends;

[0296] 3> Otherwise:

[0297] 4> Submit the RRCReconfigurationComplete message to the lower layer via SRB1 to transmit using the new configuration;

[0298] 2> Otherwise:

[0299] 3> Submit the RRCReconfigurationComplete message to the lower layer via SRB3 to transmit using the new configuration;

[0300] 1> Otherwise (RRCReconfiguration received via SRB1):

[0301] 2> Submit the RRCReconfigurationComplete message to the lower layer via SRB1 to transmit using the new configuration;

[0302] 2> If this is the first RRCReconfiguration message after the RRC re-establishment procedure is successfully completed:

[0303] 3> Resume the suspended SRB2, SRB4 and DRB, multicast MRB, and BH RLC channel for IAB-MT;

[0304] 1> If reconfigurationWithSync is included in the spCellConfig of the MCG or SCG, then when the MAC of the NR cell group successfully completes the random access procedure triggered above:

[0305] 2> Stop the timer T304 of the cell group;

[0306] 2> Stop the timer T310 of the source SpCell (if it is running);

[0307] 2> Apply the part of CSI report configuration, scheduling request configuration and sounding RS configuration that does not require the UE to know the SFN of the corresponding target SpCell (if any);

[0308] 2> After obtaining the SFN of the target SpCell accordingly, apply the part of the measurement and radio resource configuration that requires the UE to know the SFN of the target SpCell (e.g., measurement gaps, periodic CQI reports, scheduling request configuration, sounding RS configuration) (if any);

[0309] 2> For each DRB configured as a DAPS bearer, request uplink data handover to the PDCP entity as specified in TS 38.323 [5];

[0310] 2> If reconfigurationWithSync is included in spCellConfig of MCG:

[0311] 3> If the T390 is in operation:

[0312] 4> For all access categories, stop timer T390;

[0313] 4> Perform actions as specified in 5.3.14.4.

[0314] 3> If the T350 is in operation:

[0315] 4> Stop timer T350;

[0316] 3> If RRCReconfiguration does not include dedicatedSIB1-Delivery, and

[0317] 3> If the active downlink BWP indicated by firstActiveDownlinkBWP-Id of the target SpCell of the MCG has a common search space configured via searchSpaceSIB1:

[0318] 4> Get the SIB1 of the target SpCell of the MCG, which is scheduled as specified in TS 38.213

[13] ;

[0319] 4> After obtaining SIB1, perform the actions specified in clause 5.2.2.4.2.

[0320] 2> if reconfigurationWithSync is included in the spCellConfig of MCG; or

[0321] 2> If reconfigurationWithSync is included in the spCellConfig of the SCG and the CPA or CPC is configured

[0322] 3>Remove all entries in VarConditionalReconfig (if they exist);

[0323] 3> Remove all entries in VarConditionalReconfiguration as specified in TS 36.331

[10] clause 5.3.5.9.6 (if any);

[0324] 3> For each measId of the source SpCell configuration, if the associated reportConfig has reportType set to condTriggerConfig:

[0325] 4>For the associated reportConfigId:

[0326] 5> Remove the entry with matching reportConfigId from reportConfigList in VarMeasConfig;

[0327] 4> If the associated measObjectId is associated only with a reportConfig with reportType set to condTriggerConfig, then:

[0328] 5> Remove the entry with matching measObjectId from measObjectList in VarMeasConfig;

[0329] 4> Remove the entry with matching measId from measIdList in VarMeasConfig;

[0330] 2> If reconfigurationWithSync is included in masterCellGroup or secondaryCellGroup:

[0331] 3> if the UE initiated transmission of a UEAssistanceInformation message for the corresponding cell group during the last 1 second, and the UE is still configured to provide UE assistance information for the corresponding cell group; or

[0332] 3> If the RRCReconfiguration message applies due to conditional reconfiguration execution, and the UE is configured to provide UE assistance information for the corresponding cell group, and the UE has initiated transmission of a UEAssistanceInformation message for the corresponding cell group because it is configured to do so according to 5.7.4.2:

[0333] 4> Initiate the transmission of a UEAssistanceInformation message for the corresponding cell group to provide the UE assistance information involved according to clause 5.7.4.3;

[0334] 4> Start or restart the prohibit timer associated with the UE assistance information involved (if any), where the timer value is set to the value in the corresponding configuration;

[0335] 3> If SIB12 is provided by the target PCell; and the UE initiates transmission of a SidelinkUEInformationNR message indicating a change of relevant NR sidelink communication related parameters in the target PCell (i.e., a change of sl-RxInterestedFreqList or sl-TxResourceReqList) during the last 1 second before receiving an RRCReconfiguration message containing reconfigurationWithSync in the spCellConfig of the MCG:

[0336] 3> If the RRCReconfiguration message applies due to conditional reconfiguration execution and the UE is capable of NR sidelink communication and SIB12 is provided by the target PCell and the UE has initiated transmission of the SidelinkUEInformationNR message because it is configured to do so according to 5.8.3.2:

[0337] 4> Initiate the transmission of SidelinkUEInformationNR message according to 5.8.3.3;

[0338] 2>The program ends.

[0339] NOTE 3: If the UE can obtain the broadcast SIB1 without interrupting unicast or MBS multicast data reception, then the UE only needs to obtain the broadcast SIB1, that is, the broadcast and unicast / MBS multicast beams are quasi-co-located.

[0340] NOTE 4: The UE sets the content of UEAssistanceInformation according to the latest configuration (i.e., the configuration after applying the RRCReconfiguration message) and the latest UE preferences. The UE may include more content than the UE assistance information involved in UEAssistanceInformation according to 5.7.4.2. Therefore, the content of the UEAssistanceInformation message may not be the same as the content of the previous UEAssistanceInformation message.

[0341] […]

[0342] 5.3.5.6 Radio Bearer Configuration

[0343] 5.3.5.6.1 General

[0344] The UE shall perform the following actions based on the received RadioBearerConfig IE:

[0345] 1> If RadioBearerConfig contains srb3-ToRelease or srb4-ToRelease:

[0346] 2>Perform SRB release as specified in 5.3.5.6.2;

[0347] 1> If RadioBearerConfig contains srb-ToAddModList or if any DAPS bearer is configured:

[0348] 2> Perform SRB addition or reconfiguration as specified in 5.3.5.6.3;

[0349] 1> If RadioBearerConfig contains drb-ToReleaseList:

[0350] 2>Perform DRB release as specified in 5.3.5.6.4;

[0351] 1> If RadioBearerConfig contains drb-ToAddModList:

[0352] 2> Perform DRB addition or reconfiguration as specified in 5.3.5.6.5;

[0353] 1> If RadioBearerConfig contains mrb-ToReleaseList:

[0354] 2>Perform multicast MRB release as specified in 5.3.5.6.6;

[0355] 1> If RadioBearerConfig contains mrb-ToAddModList:

[0356] 2> Perform multicast MRB addition or reconfiguration as specified in 5.3.5.6.7;

[0357] 1> Release all SDAP entities (if any) that do not have an associated DRB as specified in clause 5.1.2 of TS 37.324

[24] and indicate to upper layers the release of the user plane resources of the PDU Sessions associated with the released SDAP entities;

[0358] 1> Release all SDAP entities that do not have associated multicast MRBs and indicate to upper layers the release of user plane resources for these MBS multicast sessions.

[0359] […]

[0360] 5.3.5.6.4DRB Release

[0361] The UE shall:

[0362] 1> for each drb-Identity value contained in the drb-ToReleaseList that is part of the current UE configuration; or

[0363] 1> For each drb-Identity value released due to full configuration according to 5.3.5.11:

[0364] 2> Release the PDCP entity and drb-Identity;

[0365] 2> If the SDAP entity associated with this DRB is configured:

[0366] 3> Indicate the release of the DRB to the SDAP entity associated with this DRB (TS 37.324

[24] clause 5.3.3);

[0367] 2> If the DRB is associated with eps-BearerIdentity:

[0368] 3> If no new bearer for NR or E-UTRA with the same eps-BearerIdentity is added:

[0369] 4>Indicate the release of the DRB and the eps-BearerIdentity of the released DRB to the upper layer.

[0370] NOTE 1: If the drb-ToReleaseList contains any drb-Identity value that is not part of the current UE configuration, the UE does not consider the message as erroneous.

[0371] NOTE 2: Whether the RLC and MAC entities associated with this PDCP entity are reset or released is determined by the CellGroupConfig.

[0372] 5.3.5.6.5DRB Addition / Modification

[0373] The UE shall:

[0374] 1> For each drb-Identity value contained in drb-ToAddModList that is not part of the current UE configuration (including DRB establishment using the full configuration selection scheme):

[0375] 2> Establish and configure the PDCP entity according to the received pdcp-Config;

[0376] 2> If the PDCP entity of this DRB is not configured with cipheringDisabled:

[0377] 3> If the target RAT of the handover is E-UTRA / 5GC; or

[0378] 3> If the UE is connected to E-UTRA / 5GC:

[0379] 4> If the UE is capable of E-UTRA / 5GC but not NGEN-DC:

[0380] 5> Using the encryption algorithm and K configured / derived as specified in TS 36.331

[10] UPenc Key configuration PDCP entity;

[0381] 4> Otherwise (i.e., the UE is capable of NGEN-DC):

[0382] 5> Configure the PDCP entity using the encryption algorithm according to securityConfig and apply the master key (K eNB ) or secondary key (SK gNB ) is associated with the key (K UPenc ) (if applicable);

[0383] 3> Otherwise (i.e., UE is connected to NR or UE is connected to E-UTRA / EPC):

[0384] 4> Configure the PDCP entity using the encryption algorithm according to securityConfig and apply the master key (K eNB / K gNB ) or secondary key (SK gNB / SK eNB ) associated with K UPenc Key;

[0385] 2> If the PDCP entity of this DRB is configured with integrityProtection:

[0386] 3> Configure the PDCP entity using the integrity protection algorithm according to securityConfig and apply the master key (K eNB / K gNB ) or secondary key (SK gNB ) associated with K UPint Key;

[0387] 2> If sdap-Config is included:

[0388] 3> If the SDAP entity with the received pdu-Session does not exist:

[0389] 4> Establish an SDAP entity as specified in TS 37.324

[24] clause 5.1.1;

[0390] 4> If the SDAP entity with the received pdu-Session did not exist before receiving this reconfiguration:

[0391] 5> Instruct the upper layer to establish user plane resources for pdu-Session;

[0392] 3> configure the SDAP entity according to the received sdap-Config and associate the DRB with the SDAP entity as specified in TS 37.324

[24] ;

[0393] 3> For each QFI value added in mappedQoS-FlowsToAdd, if the QFI value was previously configured, the QFI value is released from the old DRB;

[0394] 2> If the DRB is associated with eps-BearerIdentity:

[0395] 3> If the DRB was configured with the same eps-BearerIdentity by NR or E-UTRA before receiving this reconfiguration:

[0396] 4> Associate the established DRB with the corresponding eps-BearerIdentity;

[0397] 3> Otherwise:

[0398] 4> Indicate to the upper layer the establishment of the DRB and the eps-BearerIdentity of the established DRB;

[0399] 1> For each drb-Identity value included in drb-ToAddModList as part of the current UE configuration and configured as a DAPS bearer:

[0400] 2> reconfigure the PDCP entity to configure the ciphering function, integrity protection function and ROHC function for the target cell group for the DAPS as specified in TS 38.323 [5] and configure it according to the received pdcp-Config;

[0401] 2> If masterKeyUpdate is received:

[0402] 3> If the encryption function of the target cell group PDCP entity is not configured with cipheringDisabled:

[0403] 4> Configure the encryption function of the target cell group PDCP entity with the encryption algorithm according to securityConfig, and apply the encryption algorithm with the master key (K gNB ) associated with K UPenc key, as indicated in keyToUse, i.e. the ciphering configuration shall be applied to all subsequent PDCP PDUs received from and sent by the UE to the target cell group;

[0404] 3> If the integrity protection function of the target cell group PDCP entity is configured with integrityProtection:

[0405] 4> Configure the integrity protection function of the target cell group PDCP entity with the integrity protection algorithm according to securityConfig, and apply the master key (K gNB ) associated with K UPint the key, as indicated in keyToUse;

[0406] 2> Otherwise:

[0407] 3> Configure the encryption function and integrity protection function of the target cell group PDCP entity with the same security configuration as the PDCP entity of the source cell group;

[0408] 2> If sdap-Config is included and when an indication of successful completion of random access towards the target cell is received from lower layers as specified in [3]:

[0409] 3> Reconfigure the SDAP entity according to the received sdap-Config as specified in TS 37.324

[24] ;

[0410] 3> For each QFI value added in mappedQoS-FlowsToAdd, if the QFI value was previously configured, the QFI value is released from the old DRB;

[0411] 1> For each drb-Identity value included in drb-ToAddModList that is part of the current UE configuration and is not configured as a DAPS bearer:

[0412] 2> If reestablishPDCP is set:

[0413] 3> If the target RAT of the handover is E-UTRA / 5GC; or

[0414] 3> If the UE is connected to E-UTRA / 5GC:

[0415] 4> If the UE is capable of E-UTRA / 5GC but not NGEN-DC:

[0416] 5> If the PDCP entity of this DRB is not configured with cipheringDisabled:

[0417] 6> Using the encryption algorithm and K configured / derived as specified in TS 36.331

[10] clause 5.4.2.3 UPenc The key configuration PDCP entity, i.e. the ciphering configuration shall be applied to all subsequent PDCP PDUs received and sent by the UE;

[0418] 4> Otherwise (i.e., the UE is capable of NGEN-DC):

[0419] 5> If the PDCP entity of this DRB is not configured with cipheringDisabled:

[0420] 6>Use the encryption algorithm and the master key (K eNB ) or secondary key (SK gNB ) associated with K UPenc The key configuration PDCP entity, i.e. the ciphering configuration shall be applied to all subsequent PDCP PDUs received and sent by the UE;

[0421] 3> Otherwise (i.e., UE connected to NR or UE connected to E-UTRA / EPC (in EN-DC or capable of EN-DC)):

[0422] 4> If the PDCP entity of this DRB is not configured with cipheringDisabled:

[0423] 5>Use the encryption algorithm and the master key (K eNB / K gNB ) or secondary key (SK gNB / SK eNB ) associated with K UPenc The key configuration PDCP entity, i.e. the ciphering configuration shall be applied to all subsequent PDCP PDUs received and sent by the UE;

[0424] 4> If the PDCP entity of this DRB is configured with integrityProtection:

[0425] 5> Configure the PDCP entity using the integrity protection algorithm according to securityConfig and apply the master key (K eNB / K gNB ) or secondary key (SK gNB ) associated with K UPint Key;

[0426] 3> If drb-ContinueROHC is included in pdcp-Config:

[0427] 4>Indicate to the lower layer that drb-ContinueROHC has been configured;

[0428] 3> If drb-ContinueEHC-DL is included in pdcp-Config:

[0429] 4>Indicate to the lower layer that drb-ContinueEHC-DL has been configured;

[0430] 3> If drb-ContinueEHC-UL is included in pdcp-Config:

[0431] 4>Indicate to the lower layer that drb-ContinueEHC-UL is configured;

[0432] 3> If drb-ContinueUDC is included in pdcp-Config:

[0433] 4> Indicate to the lower layer that drb-ContinueUDC is configured; 3> Re-establish the PDCP entity for this DRB as specified in clause 5.1.2 of TS 38.323 [5];

[0434] 2> Otherwise, if recoverPDCP is set:

[0435] 3> The PDCP entity that triggered this DRB performs data recovery as specified in TS 38.323[5];

[0436] 2> If pdcp-Config is included:

[0437] 3> Reconfigure the PDCP entity according to the received pdcp-Config.

[0438] 2> If sdap-Config is included:

[0439] 3> Reconfigure the SDAP entity according to the received sdap-Config as specified in TS37.324

[24] ;

[0440] 3> For each QFI value added in mappedQoS-FlowsToAdd, if the QFI value was previously configured, the QFI value is released from the old DRB;

[0441] Note 1: Empty.

[0442] NOTE 2: When determining whether the drb-Identity value is part of the current UE configuration, the UE does not distinguish in which RadioBearerConfig and DRB-ToAddModList the DRB was originally configured. eNB To SK gNB , K gNB To SK eNB , K gNB To SK gNB or vice versa) reassociation, the network provides the drb-Identity value in the (target) drb-ToAddModList and sets the reestablishPDCP flag. The network does not list the drb-Identity in the (source) drb-ToReleaseList.

[0443] NOTE 3: When the reestablishPDCP flag for a radio bearer is set, the network ensures that the RLC receiver entity does not deliver old PDCP PDUs to the reestablished PDCP entity, for example by triggering a reconfiguration synchronized with the group of cells carrying the old RLC entity, or by releasing the old RLC entity.

[0444] NOTE 4: In this specification, unless otherwise stated, UE configuration refers to parameters configured by NR RRC.

[0445] NOTE 5: DRBs can enable or disable ciphering and integrity protection. Enabling / disabling ciphering or integrity protection can only be changed by releasing and adding DRBs.

[0446] NOTE 6: In a DAPS handover, upon receiving an indication of successful completion of random access towards the target cell from lower layers as specified in TS 38.321 [3], the UE may perform PDCP entity re-establishment (if reestablishPDCP is configured) or PDCP data recovery (if recoverPDCP is configured) for non-DAPS bearers. In this case, the UE suspends data transmission and reception for all non-DAPS bearers in the source MCG for the duration of the DAPS handover.

[0447] […]

[0448] -RRCReconfiguration

[0449] The RRCReconfiguration message is a command to modify the RRC connection. It can convey information for measurement configuration, mobility control, radio resource configuration (including RB, MAC primary configuration and physical channel configuration) and AS security configuration.

[0450] Signaling radio bearer: SRB1 or SRB3

[0451] RLC-SAP:AM

[0452] Logical channel: DCCH

[0453] Direction: Network to UE

[0454] RRCReconfiguration message

[0455]

[0456] -RadioBearerConfig

[0457] IE RadioBearerConfig is used to add, modify and release signaling, multicast MRB and / or data radio bearers. Specifically, this IE carries parameters for PDCP and, if applicable, SDAP entities for radio bearers.

[0458] RadioBearerConfig Information Element

[0459]

[0460]

[0461]

[0462]

[0463]

[0464] -SDAP-Config

[0465] The IE SDAP-Config is used to set the configurable SDAP parameters for the data radio bearer. All configured instances of SDAP-Config with the same value of pdu-Session correspond to the same SDAP entity as specified in TS 37.324

[24] .

[0466] SDAP-Config Information Elements

[0467]

[0468]

[0469]

[0470] -DRX-ConfigIE DRX-Config is used to configure DRX related parameters.

[0471] DRX-Config Information Elements

[0472]

[0473]

[0474]

[0475]

[0476] -PDCP-Config IE PDCP-Config is used to set configurable PDCP parameters for signaling, MBS multicast and data radio bearers.

[0477] PDCP-Config Information Element

[0478]

[0479]

[0480]

[0481]

[0482]

[0483]

[0484]

[0485]

[0486]

[0487] 3GPP TS 37.324 states:

[0488] 4.2.2SDAP Entity

[0489] The SDAP entity is located in the SDAP sublayer. Several SDAP entities can be defined for the UE. There is an SDAP entity configured for each individual PDU session or MBS session for NR Uu. For the NR sidelink, the SDAP entity is configured in the UE per destination layer 2 ID and broadcast type.

[0490] The SDAP entity receives / passes SDAP SDUs from / to the upper layer, and submits / receives SDAP data PDUs to / from its peer SDAP entity via the lower layer.

[0491] - At the transmitting side, when the SDAP entity receives an SDAP SDU from the upper layer, it constructs the corresponding SDAP data PDU and submits it to the lower layer;

[0492] - At the receiving side, when the SDAP entity receives an SDAP data PDU from the lower layer, it retrieves the corresponding SDAP SDU and passes it to the upper layer.

[0493] Figure 4 .2.2-1 shows a functional view of the SDAP entity for the SDAP sublayer; it should not limit the implementation. The figure is based on the radio interface protocol architecture defined in TS 38.300 [2].

[0494] [3GPP TS 37.324 V17.0.0 is named "SDAP layer, functional view" Figure 4 .2.2-1 is reproduced as Figure 6 ]

[0495] If the DL SDAP header has been configured, then Reflective QoS Flow to DRB mapping is performed at the UE as specified in clause 5.3.2.

[0496] Reflective QoS flow to MRB mapping is not supported. No SDAP header is present for MRB.

[0497] For NR sidelink communications, reflective PC5 QoS flow to SL-DRB mapping is not supported.

[0498] […]

[0499] 5.2 Data Transmission

[0500] 5.2.1 Uplink

[0501] Upon receiving an SDAP SDU for a QoS flow from upper layers, the transmitting SDAP entity shall:

[0502] - If there are no stored QoS flow to DRB mapping rules for the QoS flow as specified in clause 5.3:

[0503] -Map SDAP SDU to preset DRB;

[0504] -otherwise:

[0505] -Map SDAP SDU to DRB according to the stored QoS flow to DRB mapping rules;

[0506] - if the DRB to which the SDAP SDU is mapped is configured by RRC (TS 38.331[3]) in which the SDAP header is present,

[0507] - construct the UL SDAP data PDU as specified in clause 6.2.2.3;

[0508] -otherwise:

[0509] - construct the UL SDAP data PDU as specified in clause 6.2.2.1;

[0510] - Submit the constructed UL SDAP data PDU to the lower layer.

[0511] NOTE 1: If there is neither a provisioned DRB nor a stored QoS flow to DRB mapping rule for a QoS flow, the UE behavior is undefined.

[0512] NOTE 2: The default DRB is always configured with a UL SDAP header (TS 38.331[3]).

[0513] 5.2.2 Downlink

[0514] Upon receiving an SDAP Data PDU for a QoS flow from lower layers, the receiving SDAP entity shall:

[0515] - If this SDAP data PDU is received from an MRB:

[0516] - Retrieve SDAP SDU from DL SDAP Data PDU as specified in clause 6.2.2.1.

[0517] - If the DRB from which this SDAP DATA PDU was received was configured by RRC (TS 38.331 [3]) in which the SDAP header was present:

[0518] - Perform reflective QoS flow to DRB mapping as specified in clause 5.3.2;

[0519] -Perform RQI processing as specified in clause 5.4;

[0520] - Retrieve SDAP SDU from DL SDAP Data PDU as specified in clause 6.2.2.2.

[0521] -otherwise:

[0522] - retrieve the SDAP SDU from the DL SDAP data PDU as specified in clause 6.2.2.1;

[0523] -Deliver the retrieved SDAP SDU to upper layers.

[0524] […]

[0525] 5.3 QoS Flow to DRB Mapping

[0526] 5.3.1 Configuration

[0527] When RRC (TS 38.331[3]) configures UL QoS flow to DRB mapping rules for QoS flows, the SDAP entity shall:

[0528] - If the SDAP entity has been established and there is no stored QoS flow to DRB mapping rule for the QoS flow and the preset DRB is configured:

[0529] - construct an end marker control PDU for the QoS flow as specified in clause 6.2.3;

[0530] -Map the end marker control PDU to the preset DRB;

[0531] - Submit the end marker control PDU to the lower layer.

[0532] - If the stored UL QoS flow to DRB mapping rules are different from the configured QoS flow to DRB mapping rules for the QoS flow, and the DRBs according to the stored QoS flow to DRB mapping rules are configured by RRC in which the UL SDAP header is present (TS 38.331 [3]):

[0533] - construct an end marker control PDU for the QoS flow as specified in clause 6.2.3;

[0534] - Map the end marker control PDU to the DRB according to the stored QoS flow to DRB mapping rules;

[0535] - Submit the end marker control PDU to the lower layer.

[0536] -Store the configured UL QoS flow to DRB mapping rules for QoS flows.

[0537] When RRC (TS 38.331[3]) releases the UL QoS flow to DRB mapping rules for a QoS flow, the SDAP entity shall:

[0538] - Remove UL QoS flow to DRB mapping rules for QoS flows.

[0539] 5.3.2 Reflective Mapping

[0540] For each received DL SDAP DATA PDU with RDI set to 1, the SDAP entity shall:

[0541] - Process the QFI field in the SDAP header and determine the QoS flow;

[0542] - If there is no stored QoS flow to DRB mapping rule for the QoS flow and the preset DRB is configured:

[0543] - construct an end marker control PDU for the QoS flow as specified in clause 6.2.3;

[0544] -Map the end marker control PDU to the preset DRB;

[0545] -Submit the end marker control PDU to the lower layer;

[0546] - If the stored UL QoS flow to DRB mapping rules for the QoS flow are different from the QoS flow to DRB mapping of the DL SDAP data PDU, and the DRB according to the stored QoS flow to DRB mapping rules is configured by RRC in which the UL SDAP header is present (TS 38.331 [3]):

[0547] - construct an end marker control PDU for the QoS flow as specified in clause 6.2.3;

[0548] - Map the end marker control PDU to the DRB according to the stored QoS flow to DRB mapping rules;

[0549] -Submit the end marker control PDU to the lower layer;

[0550] -Store the QoS flow to DRB mapping of DL SDAP data PDUs as QoS flow to DRB mapping rules for UL.

[0551] 5.3.3DRB Release

[0552] When RRC (TS 38.331[3]) indicates that the DRB is released, the SDAP entity shall:

[0553] - Remove all QoS flow-to-DRB mappings associated with the released DRB based on clauses 5.3.1 and 5.3.2.

[0554] 5.4 RQI treatment

[0555] For each received DL SDAP Data PDU with RQI set to 1, the SDAP entity shall:

[0556] - Inform the NAS layer of RQI and QFI.

[0557] […]

[0558] 6.1 Protocol Data Unit

[0559] 6.1.1 Data PDU

[0560] SDAP Data PDUs are used to communicate one or more of the following:

[0561] -SDAP header;

[0562] - User plane data.

[0563] 6.1.2 Control PDU

[0564] a) End marker control PDU

[0565] The End Marker Control PDU is used by the SDAP entity at the UE to instruct it to stop mapping the SDAP SDUs of the QoS flow indicated by the QFI / PQFI to the DRB / SL-DRB that conveyed the End Marker PDU.

[0566] 6.2 Format

[0567] 6.2.1 General

[0568] SDAP PDU is a bit string that is byte aligned (i.e., a multiple of 8 bits) in length. In the figure in clause 6.2, the bit string is represented by a table, where the first and most significant bit is the leftmost bit of the first row of the table, the last and least significant bit is the rightmost bit of the last row of the table, and more generally, the bit string will be read from left to right and then in the order in which the rows are read.

[0569] The SDAP SDU is a bit string that is byte-aligned (ie, a multiple of 8 bits) in length. The SDAP SDU is included in the SDAP PDU from the first bit onwards.

[0570] For multicast and broadcast of NR sidelink communications, only SDAP data PDUs without SDAP header are supported.

[0571] 6.2.2 Data PDU

[0572] 6.2.2.1 Data PDU without SDAP header

[0573] The SDAP PDU consists only of the data field and does not consist of any SDAP header, such as Figure 6 .Described in 2.2.1-1.

[0574] [3GPP TS 37.324 V17.0.0 is titled "SDAP Data PDU Format without SDAP Header" Figure 6 .2.2.1-1 is reproduced as Figure 7 ]

[0575] 6.2.2.2 DL Data PDU with SDAP Header

[0576] Figure 6 .2.2.2-1 shows the format of the SDAP data PDU of the DL in which the SDAP header is configured.

[0577] [3GPP TS 37.324 V17.0.0 entitled "DL SDAP data PDU format with SDAP header" Figure 6 .2.2.2-1 is reproduced as Figure 8 ]

[0578] 6.2.2.3 UL Data PDU with SDAP Header

[0579] Figure 6 .2.2.3-1 shows the format of the SDAP data PDU of the UL in which the SDAP header is configured.

[0580] [3GPP TS 37.324 V17.0.0 entitled "UL SDAP Data PDU format with SDAP header" Figure 6 .2.2.3-1 is reproduced as Fig. 9 ]

[0581] […]

[0582] 6.2.3 End Marker Control PDU

[0583] Figure 6 .2.3-1 shows the format of the end marker control PDU.

[0584] [3GPP TS 37.324 V17.0.0 is named "End marker control PDU" Figure 6 .2.3-1 is reproduced as Fig.10 ]

[0585] 6.3 Parameters

[0586] 6.3.1 General

[0587] If not otherwise mentioned in the definition of each field, the bits in the parameter should be interpreted as follows: the leftmost bit is the first and most significant bit, and the rightmost bit is the last and least significant bit.

[0588] Unless otherwise mentioned, integers are encoded in standard binary encoding for unsigned integers. In all cases, the bits appear ordered from MSB to LSB when read in a PDU.

[0589] 6.3.2 Data

[0590] Length: Variable

[0591] This field contains the SDAP SDU.

[0592] 6.3.3D / C

[0593] Length: 1 bit,

[0594] The D / C bit indicates whether the SDAP PDU is a SDAP data PDU or a SDAP control PDU.

[0595] [Table 6.3.3-1 named "D / C field" of 3GPP TS 37.324 V17.0.0 is reproduced as Fig.11 ]

[0596] 6.3.4QFI

[0597] Length: 6 characters

[0598] The QFI field indicates the ID of the QoS flow (TS23.501[4]) to which the SDAP PDU belongs.

[0599] 6.3.5R

[0600] Length: 1 bit

[0601] Reserved. In this version of the specification, the reserved bit shall be set to 0. Receivers shall ignore the reserved bit.

[0602] 6.3.6RQI

[0603] Length: 1 bit,

[0604] The RQI bit indicates whether NAS should be informed of updates to the SDF to QoS flow mapping rules (TS 23.501 [4]).

[0605] [Table 6.3.6-1 named "RQI field" of 3GPP TS 37.324 V17.0.0 is reproduced as Fig.12 ]

[0606] 6.3.7RDI

[0607] Length: 1 bit,

[0608] The RDI bit indicates whether the QoS flow to DRB mapping rules should be updated.

[0609] [Table 6.3.7-1 named "RDI field" of 3GPP TS 37.324 V17.0.0 is reproduced as Fig.13 ]

[0610] 3GPP TS 38.323 states:

[0611] 4.2.2 PDCP Entity

[0612] The PDCP entity is located in the PDCP sublayer. Several PDCP entities can be defined for a UE. Each PDCP entity carries data for one radio bearer. The PDCP entity is associated to the control plane or the user plane depending on which radio bearer the data it carries is used for.

[0613] […]

[0614] 5.2.1Transfer Operation

[0615] Upon receiving a PDCP SDU from upper layers, the transmitting PDCP entity shall:

[0616] - Start the discardTimer associated with this PDCP SDU (if configured).

[0617] For PDCP SDUs received from upper layers, the transmitting PDCP entity shall:

[0618] - associating a count value corresponding to TX_NEXT with this PDCP SDU;

[0619] NOTE 1: Associating more than half of the PDCP SN space of consecutive PDCP SDUs with PDCP SNs, for example when discarding or transmitting PDCP SDUs without ACK, may cause HFN desynchronization problem. How to prevent HFN desynchronization problem depends on UE implementation.

[0620] - Perform header compression of PDCP SDUs using ROHC as specified in clause 5.7.4 and / or using EHC as specified in clause 5.12.4;

[0621] - Perform uplink data compression of PDCP SDUs as specified in clause 5.14.4;

[0622] - perform integrity protection and encryption using TX_NEXT as specified in clauses 5.9 and 5.8 respectively;

[0623] - Set the PDCP SN of the PDCP data PDU to TX_NEXT modulo 2 [pdcp-SN-SizeUL] ;

[0624] -Increment TX_NEXT by one;

[0625] - Submit the resulting PDCP Data PDUs to lower layers as specified below.

[0626] When submitting a PDCP PDU to lower layers, the transmitting PDCP entity shall:

[0627] - If the transmitting PDCP entity is associated with an RLC entity:

[0628] - Submitting PDCP PDUs to the associated RLC entity;

[0629] - Otherwise, if the transmitting PDCP entity is associated with at least two RLC entities:

[0630] - If PDCP duplication is activated for RB:

[0631] - If the PDCP PDU is a PDCP data PDU:

[0632] - duplicating the PDCP data PDUs and submitting the PDCP data PDUs to the associated RLC entity activated for PDCP duplication;

[0633] -otherwise:

[0634] - Submit PDCP control PDU to the primary RLC entity;

[0635] - Otherwise (i.e., PDCP duplication is deactivated for the RB, or the RB is a DAPS bearer):

[0636] - if a split secondary RLC entity is configured; and

[0637] If the total amount of PDCP data and RLC data pending for initial transmission (as specified in TS 38.322 [5]) in the primary RLC entity and the split secondary RLC entities is equal to or greater than ul-DataSplitThreshold:

[0638] - Submitting PDCP PDUs to the primary RLC entity or the split secondary RLC entity;

[0639] - Otherwise, if the transmitting PDCP entity is associated with a DAPS bearer:

[0640] - If uplink data handover has not been requested:

[0641] - Submit the PDCP PDU to the RLC entity associated with the source cell;

[0642] -otherwise:

[0643] - If the PDCP PDU is a PDCP data PDU:

[0644] - Submitting the PDCP data PDU to the RLC entity associated with the target cell;

[0645] -otherwise:

[0646] - If the PDCP Control PDU is associated with the source cell:

[0647] - Submitting the PDCP control PDU to the RLC entity associated with the source cell;

[0648] -otherwise:

[0649] - Submitting the PDCP control PDU to the RLC entity associated with the target cell;

[0650] -otherwise:

[0651] - Submit PDCP PDU to the primary RLC entity.

[0652] NOTE 2: If the transmitting PDCP entity is associated with two RLC entities, the UE should minimize the amount of PDCP PDUs submitted to the lower layers before receiving the request from the lower layers and minimize the PDCP SN gap between the PDCP PDUs submitted to the two associated RLC entities to minimize the PDCP reordering delay when receiving the PDCP entities.

[0653] 5.2.2 Receiving Operation

[0654] 5.2.2.1 Actions when a PDCP data PDU is received from lower layers

[0655] In these Terms, the following definitions apply:

[0656] - HFN (state variable): the HFN part of the state variable (i.e., the number of most significant bits is equal to the HFN length);

[0657] - SN (state variable): the SN part of the state variable (i.e., the number of least significant bits is equal to the PDCP SN length);

[0658] -RCVD_SN: PDCP SN of the received PDCP data PDU contained in the PDU header;

[0659] -RCVD_HFN: HFN of the received PDCP data PDU calculated by the receiving PDCP entity;

[0660] -RCVD_COUNT: count of received PDCP data PDUs = [RCVD_HFN, RCVD_SN].

[0661] Upon receiving a PDCP data PDU from lower layers, the receiving PDCP entity shall determine the count value of received PDCP data PDUs, RCVD_COUNT, as follows:

[0662] -If RCVD_SN <SN(RX_DELIV)-Window_Size:

[0663] -RCVD_HFN = HFN(RX_DELIV) + 1.

[0664] - Otherwise, if RCVD_SN >= SN(RX_DELIV) + Window_Size:

[0665] -RCVD_HFN = HFN(RX_DELIV) - 1.

[0666] - Otherwise:

[0667] -RCVD_HFN = HFN(RX_DELIV);

[0668] -RCVD_COUNT = [RCVD_HFN, RCVD_SN].

[0669] After determining that the count value of the received PDCP data PDU = RCVD_COUNT, the receiving PDCP entity shall:

[0670] - Perform decryption and integrity verification of the PDCP data PDU using the count = RCVD_COUNT;

[0671] - If the integrity verification fails:

[0672] - Indicate to the upper layer that the integrity verification has failed;

[0673] - Discard the PDCP data PDU and consider it as not received;

[0674] - If RCVD_COUNT < RX_DELIV; or

[0675] - If a PDCP data PDU with the count = RCVD_COUNT has been received previously:

[0676] - Discard the PDCP data PDU;

[0677] If the received PDCP data PDU with the count value = RCVD_COUNT is not discarded above, the receiving PDCP entity shall:

[0678] - Store the resulting PDCP SDU in the receive buffer;

[0679] - If RCVD_COUNT >= RX_NEXT:

[0680] - Update RX_NEXT to RCVD_COUNT + 1.

[0681] - If outOfOrderDelivery is configured:

[0682] - Deliver the resulting PDCP SDU to the upper layer after header decompression is performed using EHC.

[0683] - If RCVD_COUNT = RX_DELIV:

[0684] - If not decompressed previously, deliver to the upper layer in ascending order of the associated count values after header decompression is performed;

[0685] - All stored PDCP SDUs with continuously associated count values starting from count = RX_DELIV;

[0686] - Update RX_DELIV to the count value of the first PDCP SDU not yet delivered to the upper layer, where the count value > RX_DELIV;

[0687] - If t-Reordering is in operation and if RX_DELIV >= RX_REORD:

[0688] - Stop and reset t-Reordering.

[0689] - If t-Reordering is not in operation (including the case when t-Reordering is stopped due to the above action) and RX_DELIV < RX_NEXT:

[0690] - Update RX_REORD to RX_NEXT;

[0691] - Start t-Reordering.

[0692] 5.2.2.2 Actions when t-Reordering expires

[0693] When t-Reordering expires, the receiving PDCP entity shall:

[0694] - If not decompressed previously, deliver to the upper layer in ascending order of the associated count values after header decompression is performed:

[0695] - All stored PDCP SDUs with associated count values < RX_REORD;

[0696] - All stored PDCP SDUs with continuously associated count values starting from RX_REORD;

[0697] - Update RX_DELIV to the count value of the first PDCP SDU not yet delivered to the upper layer, where the count value >= RX_REORD;

[0698] -if RX_DELIV <RX_NEXT:

[0699] - Update RX_REORD to RX_NEXT;

[0700] -Start t-Reordering.

[0701] […]

[0702] 5.3SDU discard

[0703] When the discardTimer expires for a PDCP SDU or the successful delivery of the PDCP SDU is confirmed by a PDCP status report, the transmitting PDCP entity shall discard the PDCP SDU together with the corresponding PDCP Data PDU. If the corresponding PDCP Data PDU has been submitted to lower layers, the discard is indicated to the lower layers.

[0704] For SRB, when upper layers request PDCP SDU discard, the PDCP entity shall discard all stored PDCP SDUs and PDCP PDUs.

[0705] NOTE: Discarding a PDCP SDU that has been associated with a PDCP SN causes a SN gap in the transmitted PDCP data PDUs, which increases the PDCP reordering delay in the receiving PDCP entity. How to minimize the SN gap after SDU discard depends on the UE implementation.

[0706] 3GPP TS 38.300 states:

[0707] 6.4PDCP Sublayer

[0708] 6.4.1 Services and Features

[0709] The main services and functions of the PDCP sublayer include:

[0710] -Data transmission (user plane or control plane);

[0711] -Maintenance of PDCP SN;

[0712] -Header compression and decompression using ROHC protocol;

[0713] - Header compression and decompression using the EHC protocol;

[0714] - Compression and decompression of uplink PDCP SDU: only UDC based on DEFLATE;

[0715] - Encryption and decryption;

[0716] -Integrity protection and integrity verification;

[0717] -Timer-based SDU discard;

[0718] - For split bearers, routing;

[0719] -copy;

[0720] - Re-sequencing and ordered delivery;

[0721] - Unordered delivery;

[0722] - Duplicate discard.

[0723] Since PDCP does not allow counts to wrap around in DL and UL, it is up to the network to prevent this from happening (e.g., by using release and addition of corresponding radio bearers or full configuration).

[0724] 6.5SDAP Sublayer

[0725] The main services and functions of SDAP include:

[0726] - Mapping between QoS flows and data radio bearers;

[0727] - Marking of QoS Flow ID (QFI) in both DL and UL packets.

[0728] A single protocol entity of SDAP is configured for each individual PDU session.

[0729] 6.6L2 Data Flow

[0730] Figure 6 .6-1 depicts an example of layer 2 data flow, where the data from RB x The two RLC PDUs and the y A transport block is generated by MAC from an RLC PDU. x The two RLC PDUs each correspond to an IP packet (n and n+1), and the y The RLC PDU is a fragment of the IP packet (m).

[0731] Note: H delineates header and subheader.

[0732] [3GPP TS 38.300 V17.0.0 entitled "Data Flow Instances" Figure 6 .6-1 is reproduced as Fig.14 ]

[0733] […]

[0734] 12.1 Overview

[0735] The 5G QoS model is based on QoS flows (see TS23.501[3]) and supports QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). At the NAS level (see TS23.501[3]), a QoS flow is therefore the finest granularity of QoS differentiation within a PDU session. A QoS flow is identified within a PDU session by a QoS flow ID (QFI) carried in the encapsulation header via NG-U.

[0736] QoS architecture in NG-RAN for NR connected to 5GC and E-UTRA for 5GC Figure 12-1 Depicted in and described below:

[0737] -For each UE, 5GC establishes one or more PDU sessions;

[0738] - Except for NB-IoT and IAB-MT in SA mode, for each UE, the NG-RAN establishes at least one Data Radio Bearer (DRB) together with the PDU session, and additional DRBs for the QoS flows of that PDU session may be configured subsequently (it is up to the NG-RAN when to do so);

[0739] - If the NB-IoT UE supports NG-U data transfer, the NG-RAN may establish a data radio bearer (DRB) together with the PDU session, and one PDU session is mapped to only one DRB;

[0740] -NG-RAN maps packets belonging to different PDU sessions to different DRBs;

[0741] -NAS level packet filters in the UE and in the 5GC to associate UL and DL packets with QoS flows;

[0742] - AS-level mapping rules in the UE and in the NG-RAN associate UL and DL QoS flows with DRBs.

[0743] [3GPP TS 38.300 V17.0.0 is titled "QoS Architecture" Figure 12-1 Reproduced as Fig.15 ]

[0744] NG-RAN and 5GC ensure the quality of service (e.g. reliability and target latency) by mapping packets to appropriate QoS flows and DRBs. Therefore, there is a 2-step mapping of IP flows to QoS flows (NAS) and QoS flows to DRBs (access layer).

[0745] At the NAS level, a QoS flow is characterized by a QoS profile provided by the 5GC to the NG-RAN and QoS rules provided by the 5GC to the UE. The QoS profile is used by the NG-RAN to determine the processing on the radio interface, while the QoS rules specify the mapping between uplink user plane traffic and QoS flows to the UE. A QoS flow can be GBR or non-GBR depending on its profile. The QoS profile of a QoS flow contains QoS parameters, such as (see TS 23.501 [3]):

[0746] -For each QoS flow:

[0747] -5G QoS Identifier (5QI);

[0748] - Allocation and Retention Priority (ARP).

[0749] - In case of GBR-only QoS flows:

[0750] - Guaranteed Flow Bit Rate (GFBR) for both uplink and downlink;

[0751] - Maximum Flow Bit Rate (MFBR) for both uplink and downlink;

[0752] - Maximum packet loss rate for both uplink and downlink;

[0753] - Delay critical resource types;

[0754] -Notification control.

[0755] NOTE: Maximum packet loss ratio is provided only for GBR QoS flows belonging to voice media (UL, DL).

[0756] - In case of non-GBR QoS only:

[0757] - Reflective QoS Attribute (RQA): When included, RQA indicates that some (not necessarily all) traffic carried on this QoS flow is subject to Reflective Quality of Service (RQoS) at the NAS;

[0758] - Additional QoS flow information.

[0759] The QoS parameter Notification Control indicates whether to request a notification from the RAN when the GFBR can no longer (or again) be met for a QoS flow. If, for a given GBR QoS flow, the Notification Control is enabled and the RAN determines that the GFBR cannot be guaranteed, the RAN shall send a notification towards the SMF and maintain the QoS flow (i.e. while the NG-RAN does not deliver the requested GFBR for this QoS flow), unless specific conditions at the NG-RAN require the release of NG-RAN resources for this GBR QoS flow, e.g. due to a radio link failure or RAN internal congestion. When applicable, the NG-RAN sends a new notification informing the SMF that the GFBR can be guaranteed again.

[0760] If an alternative set of QoS parameters is received with the notification control parameter, the NG-RAN may also include in the notification a reference to the set of QoS parameters that it can currently satisfy, as specified in TS 23.501 [3]. The target NG-RAN node may include a reference to the set of QoS parameters that it can currently satisfy in the notification control indication passed via Xn to the source NG-RAN node during handover.

[0761] Additionally, the aggregate maximum bit rate is associated to each PDU session (Session-AMBR), to each UE (UE-AMBR) and to each slice per UE (UE-Slice-MBR). The Session-AMBR limits the aggregate bit rate that is expected to be provided across all non-GBR QoS flows for a particular PDU session and is ensured by the UPF. The UE-AMBR limits the aggregate bit rate that is expected to be provided across all non-GBR QoS flows of the UE and is ensured by the RAN (see clause 10.5.1). The UE-Slice-MBR limits the aggregate bit rate that is expected to be provided across all GBR and non-GBR QoS flows of the PDU session corresponding to the UE for the same slice (S-NSSAI) as specified in TS23.501 [3] and is ensured by the RAN (see clause 10.5.1).

[0762] 5QI is associated to QoS characteristics, giving guidelines for setting node-specific parameters for each QoS flow. Standardized or pre-configured 5G QoS characteristics are derived from 5QI values ​​and are not explicitly signaled. Signaled QoS characteristics are included as part of the QoS profile. QoS characteristics consist of, for example, the following (see TS 23.501 [3]):

[0763] - Priority;

[0764] -Packet delay budget (including core network packet delay budget);

[0765] -Packet error rate;

[0766] - averaging window;

[0767] - Maximum data burst size.

[0768] At the access level, Data Radio Bearers (DRBs) define packet handling over the radio interface (Uu). DRBs serve packets with the same packet forwarding handling. The QoS flow to DRB mapping by NG-RAN is based on the QFI and the associated QoS profile (i.e., QoS parameters and QoS characteristics). Separate DRBs may be established for QoS flows that require different packet forwarding handling, or several QoS flows belonging to the same PDU session may be multiplexed in the same DRB.

[0769] In the uplink, the mapping of QoS flows to DRBs is controlled by mapping rules that are signaled in two different ways:

[0770] - Reflective mapping: For each DRB, the UE monitors the QFI of the downlink packets and applies the same mapping in the uplink; that is, for a DRB, the UE maps the uplink packets belonging to the QoS flow corresponding to the QFI and the PDU session observed in the downlink packets for that DRB. To achieve this reflective mapping, the NG-RAN marks the downlink packets on Uu with the QFI.

[0771] - Explicit configuration: QoS flow to DRB mapping rules can be explicitly signaled by RRC.

[0772] The UE always applies the latest update of the mapping rules, regardless of whether it is performed via reflective mapping or explicit configuration.

[0773] When updating the QoS flow to DRB mapping rules, the UE sends an end marker on the old bearer.

[0774] In the downlink, the QFI is signaled by the NG-RAN over Uu for RQoS purposes, and if neither the NG-RAN nor the NAS (as indicated by the RQA) intends to use reflective mapping for a QoS flow carried in a DRB, then no QFI is signaled over Uu for that DRB. In the uplink, the NG-RAN may configure the UE to signal the QFI over Uu.

[0775] For each PDU session, a preset DRB may be configured: if an incoming UL packet matches neither an RRC configuration rule nor a reflective mapping rule, the UE then maps the packet to the preset DRB for the PDU session. For non-GBR QoS flows, the 5GC may send additional QoS flow information parameters associated with certain QoS flows to the NG-RAN to indicate that traffic may occur more frequently on these flows than on other non-GBR QoS flows established on the same PDU session.

[0776] Within each PDU session, it is NG-RAN dependent how multiple QoS flows are mapped to DRBs. NG-RAN can map GBR flows and non-GBR flows, or more than one GBR flow to the same DRB, but the mechanisms to optimize these cases are outside the scope of the standardization.

[0777] […]

[0778] A.1PDU Session Establishment

[0779] The following figure shows an example message flow for PDU session establishment. Details of the NAS procedures between gNB and 5GC can be found in TS 23.501 [3], TS 23.502

[22] and TS 38.413

[26] .

[0780] [Figure A.1-1 of 3GPP TS 38.300 V17.0.0 entitled "PDU Session Establishment" is reproduced as Fig.16 ]

[0781] 1.UE requests AMF to establish a PDU session.

[0782] 2. The AMF sends a PDU Session Resource Setup Request message to the gNB, which contains the NAS message to be sent to the UE together with the NAS QoS related information.

[0783] 3. The gNB sends an RRCReconfiguration message including the configuration of at least one DRB and the NAS message received in step 2 to the UE.

[0784] 4. The UE establishes a DRB for the new PDU session and creates a QFI to DRB mapping rule.

[0785] 5. The UE sends the RRCReconfigurationComplete message to the gNB.

[0786] 6. The gNB sends the PDU Session Resource Setup Response message to the AMF.

[0787] 7. User plane data may then be exchanged between the UE and gNB over the DRB and between the UPF and gNB over the tunnel for the PDU session according to the mapping rules. The QFI marking over Uu is optional (see clause 12), while the QFI marking over NG-U is always present.

[0788] […]

[0789] A.6UE-initiated UL QoS flow

[0790] The following figure shows an example message flow when the UE AS receives an UL packet for a new QoS flow where a QFI to DRB mapping rule does not exist.

[0791] [Figure A.6-1 of 3GPP TS 38.300 V17.0.0 entitled "UL Packet with New QoS Flow in Which No Mapping Exists in UE"] is reproduced as Fig.17 ]

[0792] 0.PDU session and DRB (including preset DRB) have been established.

[0793] 1. UE AS receives a packet with a new QFI from UE NAS.

[0794] 2. The UE uses the QFI of the packet to map it to a DRB. If there is no QFI to DRB mapping in the AS mapping rules for this PDU session, the packet is assigned to a preset DRB.

[0795] 3. UE sends UL packet on the preset DRB. UE includes QFI in SDAP header.

[0796] 4. The gNB sends the UL packet to the UPF and includes the corresponding QFI.

[0797] 5. If the gNB wants to use a new DRB for this QoS flow, it establishes a DRB. It may also choose to move the QoS flow to an existing DRB using RQoS or RRC signaling (see clauses A.2 and A.3).

[0798] 6. User plane data for the new QoS flow may then be exchanged between the UE and gNB through the DRB and between the UPF and gNB through the tunnel for the PDU session according to the updated mapping rules.

[0799] 3GPP TR 23.700-60 states:

[0800] 6.7.3.1 Packets that identify PDU collections

[0801] 6.7.3.1.1RTP

[0802] Packets belonging to a PDU set can be identified by examining a combination of fields in the RTP header (sequence number, timestamp, M bit) and RTP header extensions (e.g., IETF frame marking RTP extension header, draft-ietf-avtext-framemarking

[11] ) and the media payload header (e.g., RTP payload NAL unit type field).

[0803] [3GPP TR 23.700-60 V1.2.0 is titled "Identifying the start and end of a PDU set" Figure 6 .7.3.1.1-1 is reproduced as Fig.18 ]

[0804] The first packet of a PDU set has an RTP header with a new timestamp, a new type field in the NAL unit header, and a sequence number that follows the packet with the RTP header M bit set to 1 (i.e., the sequence number is 1 greater than the packet with the M bit set to 1). Detection of the first packet may require a combination of fields because the timestamps may not be increasing for enhancement layers (PDU sets). If the RTP experimental extension header is present, the S bit is set to 1. These fields may identify the start of a PDU set.

[0805] The last packet of a PDU set has the RTP header M bit set to 1, or preceded by a packet / sequence number with a new timestamp. If the RTP experimental extension header is present, the E bit is set to 1.

[0806] 6.7.3.1.2HTTP

[0807] HTTP / 1.1 packets belonging to a PDU set can be identified by inspecting the HTTP payload to determine the start, middle packets, and end. HTTP payloads with the same timestamp and content type belong to a PDU set. Enhancement layers can be detected by changes in content type (while the timestamp may not be incremented). Out-of-order packet arrival can be managed by tracking TCP sequence numbers along with the content type of the packet.

[0808] HTTP / 2 and HTTP / 3 packets carry multiple streams that are dynamically ordered (i.e., their ordering is based on application priority, network latency, etc.) The combination of dynamically ordered streams or possible encryption makes it processing intensive to identify and characterize PDU sets at line rate without additional metadata.

[0809] Methods for HTTP / 2 and HTTP / 3:

[0810] 1. Combination of IP header fields and flow fingerprint

[0811] UPF uses IP header fields (flow label, DSCP) to distinguish flows, because a flow (single transport connection) has multiple dynamically ordered flows. Within the identified HTTP / 2 flow, the flow fingerprint (including packet size, burst, inter-frame arrival time) is used to identify the PDU set boundaries. Flow fingerprints are configured as described in clause 6.7.3.2.3.

[0812] 2. New TCP / UDP options with media metadata

[0813] Media-aware application servers on N6 add new TCP options for HTTP / 2

[44] or UDP options for HTTP / 3

[45] to carry metadata on codecs (audio, video, haptics), media encoding in packets (base layer, enhancement layers), timestamps, and PDU aggregation information (start / end of frame). For HTTP / 3, extensions to QUIC / UDP metadata to prioritize media with priority / importance

[64] and support other PDU aggregation features may be options to be considered in collaboration with the IETF.

[0814] Since the metadata is in the TCP / UDP options of the packet, no new routing / destination information is required (unlike using tunnels in N6).

[0815] 6.7.3.1.3 PDU Sequence Flag

[0816] A PDU set is identified by a sequence number "PDU Sequence Marker" appended to all packets (start to end packet) of the PDU set. More than one bit may be used for the PDU Sequence Marker field if, for example, an out-of-order packet spans multiple PDU sets. For example, a 2-bit counter would incrementally cycle through 4 distinct PDU Sequence Markers for each subsequent PDU set using modular arithmetic (i.e., mod-4 in this case). This allows the QoS handler to make decisions based on the PDU set as a whole, and distinguish from previous or subsequent PDU sets. The PDU Sequence Marker (PSM) is carried in a GTP extension and is further described in clause 6.7.3.3.

[0817] Since packets may arrive out of order, packets with out-of-order sequence numbers may be part of a new PDU set. If a packet has a new timestamp and a new media header field, the packet belongs to a new PDU set, and a higher PDU sequence mark (i.e., (current PSM+1) mod-n) is used to indicate that it belongs to a different PDU set.

[0818] 6.7.3.2 Classifying the importance of packets in a PDU set

[0819] This clause describes how packets of a PDU set are classified based on the importance of the media payload they carry. The media payload header NAL (e.g., RFC 3711

[10] , the frame marking RTP header extension, draft-ietf-avtext-framemarking

[11] ) or RFC 3550 [9] RTP extension header contains information about media priorities and dependencies and is further defined in clause 6.7.3.2.1, with media classification with HTTP payload covered in 6.7.3.2.2.

[0820] Some PDU sets have well understood importance (e.g., independent frames have high importance, or droppable frames have low importance), but in other cases the application may indicate a preference (e.g., an application with high motion may give more importance to temporal enhancement PDU sets than to spatial or quality data). PDU sets for enhancement layers (e.g., spatial, temporal) have dependencies on base layer PDU sets and are of relatively lower importance than base layer PDU sets that carry essential data. Applications may configure these preferences as defined in clause 6.7.3.2.2.

[0821] The QoS handler is provided with a PDU Priority Mark (PPM) which represents the importance and dependency of a PDU set in terms of a linear priority value (e.g., high / medium / low, 0-7), the PPM being related to the PDU set delay budget, error rate, and other parameters associated with each priority value. The QoS handler can use the PPM along with the PDU set boundaries to handle packets of the PDU set in a flow without having to understand the details of the various coded media. The PPM is thus extensible for new types of media.

[0822] The QoS model in clause 5.7 of TS 23.501 [2] is extended for media PDU handling, such as Figure 6 .As shown in 7.3.2-1.

[0823] [3GPP TR 23.700-60 V1.2.0 entitled "QoS model with extensions for media PDU classification" Figure 6 .7.3.2-1 is reproduced as Fig.19 ]

[0824] Protocol data units arriving at the UPF with media classification functionality are filtered and classified based on the starting point (3-tuple) or 5-tuple flow information, as defined in clause 5.6.7 of TS23.501 [2]. Media PDU filtering information is supplied by the application (AF) in 5GC and further details are in clause 6.7.3.2.2. If it is not a media PDU, the PDU bypasses the media filter and flow-based QoS is handled as defined in clause 5.7 of TS23.501 [2]. The (filtered) media PDU is classified using the RTP header / payload header information, which identifies the importance of the packet payload, and the details are in clause 6.7.3.2.1. The PPM of the PDU set and the importance information in the sequence are carried in the GTP extension header, as summarized in clause 6.7.3.3.

[0825] A mapping of meta-information available from the media transport is presented to the QoS handler as a scale of increasing / decreasing priority of the PPM (e.g., high / medium / low, scale 0-7). The PPM applies only to the selective handling (e.g., deferring, dropping) of packets of a set of PDUs within a flow. The actions taken by the QoS handler based on the PPM are based on network conditions or other factors and the implementation of the QoS handler, and are not further defined here.

[0826] The UPF with media classification functionality follows the following extended QoS handling:

[0827] 1.PDU collection mark:

[0828] If an incoming packet matches the media filtering criteria and is unclassified (ie, does not have a PPM), the media packet classifier uses the rules configured in clause 6.7.3.2.2 to select a PPM value by matching on the RTP / payload header fields of the incoming packet.

[0829] If there is no match, the packet is marked with the lowest priority PPM.

[0830] 2. Apply the flow-based QoS in clause 5.7 of TS 23.501 [2].

[0831] The flow is processed using the QoS defined in 23.501, 5.7. The PDB, PER, GBR, MBR remain the same and the rules are based on the existing PDR for the PDU session.

[0832] 3. Extended QoS treatment for media packets:

[0833] Within the QoS rules for a flow, if PPM is available, the QoS handler can use it to optimize the handling of packets (e.g., defer, or selectively drop when congestion exceeds a threshold level). The PDU set delay budget, error rate, and other parameters associated to each priority value in the PPM are used.

[0834] For classification of upstream packets, the UE is provisioned with a PPM during PDU session establishment / modification based on the S-NSSAI / DNN for the PDU session. The PPM rules are sent from the 5GC to the UE in the N1 SM container defined in the Session Management Procedure in clause 4.3 of TS23.502 [3]. The PPM is used in the UE to map to the appropriate MAC transmit buffer. The handling of UL PDU sets in the UE is implementation specific.

[0835] 6.7.3.2.1 Mapping RTP / Payload Header Values ​​to PPM

[0836] The packet of a PDU set has a set of headers in the IP, RTP transport and payload headers that can be used to assign importance and dependencies to other PDU sets. After detecting the start of a new PDU set, various header information can be used in each of the following situations:

[0837] 1.RTP (unencrypted header and payload).

[0838] The RTP payload / NAL unit header with information about media coding priorities, dependencies (e.g. H.264

[19] , SVC, draft-ietf-avtext-framemarking

[11] ) is used to map to per-packet QoS priority values ​​in the PPM. Independent frames / PDU sets without dependencies are marked with the highest priority, while PDU sets carrying temporal, spatial or quality enhancements are configured on a per-application basis in terms of importance level. This is further defined in clause 6.7.3.2.3.

[0839] 2.SRTP (unencrypted extended experimental header, encrypted payload).

[0840] An experimental IETF draft with an extension header (frame marking RTP header extension, draft-ietf-avtext-framemarking

[11] ) contains coded media information that can be used to map to PPM values. For example, "I" (independent / IDR frames with temporal independence) can be marked as important, while selected LID / TID values ​​(spatial / quality / temporal frames with dependencies indicated by the value) can have medium PPM priority, and others are marked as low.

[0841] 3.SRTP (unencrypted header, encrypted payload).

[0842] The RTP unencrypted header does not provide meta information to determine the coded media carried in the packet and the NAL unit header is part of the encrypted payload. Since the unencrypted header does not convey enough information about the carried media, applications supplement by using different IPv6 flow labels, DSCP, sender ports to convey different required QoS treatment priorities. The values ​​are configurable per application and are further specified in clause 6.7.3.2.3.

[0843] 6.7.3.2.2 Mapping HTTP Transport Payload to PPM

[0844] The method described in 6.7.3.1.2 contains the identification of PDU sets and the classification of packets with HTTP media transport.

[0845] 1. HTTP / 1.1 (unencrypted headers and payload)

[0846] The content type, base layer and enhancement layer are detected by inspection of the media payload and mapped to a per-packet QoS priority value in the PPM. Independent frames / PDU sets with no dependencies are marked with the highest priority, while PDU sets carrying temporal, spatial or quality enhancements are configured on a per-application basis in terms of importance level. This is further defined in 6.7.3.2.3

[0847] 2. HTTP / 2 and HTTP / 3 (dynamically ordered streams and possible encryption)

[0848] HTTP / 2 or HTTP / 3 headers do not provide meta information to determine the coded media.

[0849] IP header fields (flow label, DSCP) are used to differentiate flows, because a flow (a single transport connection) has multiple flows that are dynamically ordered.

[0850] If metadata about the codec (audio, video, haptic), media encoding in the packet (base layer, enhancement layer), timestamps and PDU aggregation information (start / end of frame) is available in TCP options for HTTP / 2

[44] or UDP options for HTTP / 3

[45] , this information is used to classify and map to per-packet QoS priority values. For HTTP / 3, an option could be to use QUIC / UDP metadata to prioritize media with priority / importance

[64] , and to collaborate with IETF to extend to support other PDU aggregation features.

[0851] 6.7.3.2.3 Provisioning Application Information

[0852] This clause describes the provisions necessary to filter media PDUs and apply QoS classification based on the importance required by the application for different media encodings. For example, a video stream encoding significant motion may wish to prioritize PDUs with enhancement layers with temporal information over PDUs carrying quality.

[0853] Media Packet Filtering:

[0854] Application Function (AF) signals 5GC and provides details on the criteria used to filter services that carry media services and the criteria used to determine the importance of packets / PDUs. Media services are identified using a 3-tuple (server address / end-user address, port protocol) or a 5-tuple flow, as described in clause 5.6.7 of TS23.501 [2] (impact of application functions on service routing).

[0855] Media Pack Categories:

[0856] The media traffic is then classified using rules configured based on the application priority of the corresponding field in the RTP / SRTP transport or payload header. Some PDU sets have a well-understood importance (e.g., independent frames have high importance, or discardable frames have low importance), but in other cases the application may indicate a preference (e.g., an application with high-speed motion may give more importance to temporal enhancement PDU sets than to spatial or quality data).

[0857] AF sends information to 5GC to configure presets and dedicated information: |

[0858] 1. Classification for RTP (unencrypted header and payload).

[0859] The configured parameters include the following:

[0860] - If the NAL I flag is set to 1, then PPM = High Importance.

[0861] - The NAL Priority field value set for the enhancement layer is mapped to PPM based on application preference of motion or quality.

[0862] - If no configuration applies, the default is PPM = Low Importance.

[0863] 2. Classification for SRTP (unencrypted extended experimental header, encrypted payload).

[0864] The configured parameters are based on the RFC 3550[9] RTP extension header:

[0865] - If the I flag is set to 1, then PPM = high importance.

[0866] - If the D flag is set to 1, PPM = low importance.

[0867] -TID / LID / TLOPICIDX values ​​are mapped to PPM based on application preference of motion or quality.

[0868] - If no configuration applies, the default is PPM = Low Importance.

[0869] 3. Classification for SRTP (unencrypted header, encrypted payload).

[0870] The configured parameters include (one or more of) the following:

[0871] - An IPv6 Flow Label

[12] value corresponding to the application preference of the importance of the PDU.

[0872] - DSCP corresponding to the application preference of the importance of the PDU:

[0873] (For example, if DSCP = d1, then PPM = high importance).

[0874] -Sending IP port and corresponding importance in PPM:

[0875] (For example, if send port = p1, then PPM = medium importance).

[0876] - If no configuration applies, the default is PPM = Low Importance.

[0877] 4. Classification for HTTP

[0878] The configured parameters include the following:

[0879] - Parameters for adding fingerprints to the stream, including packet size, burst rate, and inter-frame arrival time.

[0880] - An IPv6 Flow Label

[12] value corresponding to the application preference of the importance of the PDU.

[0881] - DSCP corresponding to the application preference of the importance of the PDU:

[0882] (For example, if DSCP = d1, then PPM = high importance.

[0883] - If no configuration applies, the default is PPM = Low Importance.

[0884] These parameters are configured using the PFD (Packet Flow Description) procedures in clause 4.18 of TS23.502 [3] and clause 4.2.4 of TS23.503 [4] as a basis (AF->NEF (PFDF)->UDR). The SMF subscribes to the PFDManagement service from the NEF to retrieve the configuration as specified in clause 5.2.6 of TS23.502 [3] (NEF Services). The SMF uses the N4 PFD Management procedure in clause 4.4.3.5 of TS23.502 [3] to provision these PFDs in the UPF.

[0885] 6.7.3.3 Protocol Extensions

[0886] The media PDU classification with the PPM described in clause 6.7.3.2 and the sequence of PDU sets described in clause 6.7.3.1 is carried in the RAN / other UPF to the QoS handler (clause 8.3.1 of TS23.501 [2], TS29.281

[16] ) using the GTP-U extension header. New GTP extension header fields are required for the PPM / importance information and for the boundaries / sequence of PDU sets.

[0887] An example of a GTP-U envelope that carries QoS media classification results is shown in Figure 6 .As shown in 7.3.3-1.

[0888] [3GPP TR 23.700-60 V1.2.0 entitled "Example of QoS media classification in GTP-U extension" Figure 6 .7.3.3-1 is reproduced as Fig. 20 ]

[0889] Figure 6 .7.3.3-1 shows a sequence of PDU sets (I frames followed by B frames and P frames). There are two sets of classification results carried in the GTP-U extension. The field with the importance of each PDU defined as PPM contains the importance level of each PDU set as described in clause 6.7.3.2. In the example here, 3 importance levels are conveyed for the QoS handler to act on.

[0890] PDU set boundaries are identified as described in clause 6.7.3.1, and each of the PDU sets is marked with a sequence number, ie a PDU sequence marker (PSM) shown here in the figure as a single alternating bit. (A larger PSM may be used).

[0891] 6.7.4 Impact on Services, Entities, and Interfaces

[0892] AF: Procedure for supplying application preferences for filtering and PDU classification (clause 6.7.3.2.3).

[0893] UPF: Classification of importance, enumeration of PDU sets using the provided rules (clauses 6.7.3.1, 6.7.3.2). Encoding of importance, enumeration of PDU sequence flags in the GTP-U extension header (clause 6.7.3.3).

[0894] RAN: Ability to use classification and importance information.

[0895] UE: If the UE does not support the TCP / UDP option, it will be ignored (ie, has no impact on the UE).

[0896] […]

[0897] 3GPP TR 38.835 states:

[0898] 4.1 Extended Reality Types

[0899] Extended Reality (XR) refers to all combined real and virtual environments and human-computer interactions generated by computer technology and wearables. XR is an umbrella term for different types of reality (see TR 26.918[5] and TR 26.928[7]):

[0900] - Virtual Reality (VR) is a rendered version of a delivered visual and audio scene. The rendering is designed to mimic the visual and audio sensory stimulation of the real world as naturally as possible to the observer or user as the observer or user moves within the limits defined by the application. Virtual Reality typically, but not necessarily, requires the user to wear a head mounted display (HMD), completely replace the user's field of view with simulated visual components, and wear headphones to provide the user with accompanying audio. Some form of head and motion tracking of the user in VR is also typically required to allow the simulated visual and audio components to be updated to ensure that objects and sound sources remain consistent with the user's movements from the user's perspective.

[0901] - Augmented Reality (AR) is when a user is provided with additional information or artificially generated items or content overlaid on their current environment. Such additional information or content will typically be visual and / or audible, and the observation of their current environment may be direct, processing and rendering without intermediate sensing, or indirect, where the perception of their environment is relayed via sensors and may be augmented or processed.

[0902] - Mixed reality (MR) is an advanced form of AR in which some virtual elements are inserted into the physical scene with the intention of providing the illusion that these elements are part of the real scene.

[0903] Other terms used in the context of XR are "immersion" as the sense of being surrounded by the virtual environment and "presence" which provides a sense of being physically and spatially located in the virtual environment. The sense of presence provides significant minimum performance requirements for different technologies, such as tracking, latency, persistence, resolution, and optical properties.

[0904] This document uses the acronym XR throughout to refer to devices, applications, and functionality for VR, AR, and MR. Examples include (but are not limited to) HMDs for VR, optical see-through glasses and camera see-through HMDs for AR and MR, and mobile devices with positional tracking and cameras. They all provide some degree of spatial tracking, and the spatial tracking results in interaction to view some form of virtual content.

[0905] […]

[0906] 5.1XR Perception

[0907] 5.1.1 General

[0908] In both uplink and downlink, XR awareness helps optimize gNB radio resource scheduling and relies on at least the concepts of PDU sets and data bursts (see TR 23.700-60[9]): a PDU set consists of one or more PDUs that carry the payload of an information unit generated at the application level (e.g., a frame or a video slice), while a data burst is a collection of data PDUs generated and sent by an application in a short time period.

[0909] NOTE 1: A data burst may consist of multiple PDUs belonging to one or more PDU sets. During a data burst, no periods of data transfer inactivity should be assumed. Although the duration of a data burst may vary, it may be assumed to remain within the same order of magnitude. Also, the arrival time of the first packet of a data burst cannot be provided by the 5GC.

[0910] The following information may be provided by the CN to the RAN (see TR 23.700-60[9]):

[0911] - Semi-static information per QoS flow:

[0912] - Periodicity of UL and DL traffic for QoS flows provided via TSCAI / TSCAC;

[0913] - DL traffic jitter information (eg, jitter range) associated with each periodicity of QoS flows provided via TSCAI / TSCAC.

[0914] - PDU set QoS parameters for the QoS flow provided by the SMF via NGAP (i.e., the set of all PDUs applicable to the QoS flow):

[0915] - PDU aggregate error rate (PSER): defines an upper limit on the aggregate PDU loss rate between the RAN and the UE that is not related to congestion (see TR 23.700-60 [9]).

[0916] NOTE 2: In this version, a PDU set is considered successfully delivered only if all PDUs of the PDU set are successfully delivered, and if PSER is available, the use of PSER replaces the use of PER.

[0917] - PDU Set Delay Budget (PSDB): The time between the reception of the first PDU (at the UPF in DL, at the UE in UL) and the successful delivery of the last arriving PDU of a PDU set (at the UE in DL, at the UPF in UL). PSDB is an optional parameter and when provided, PSDB replaces PDB (see TR 23.700-60 [9]).

[0918] - PDU Set Integration Handling Indication (PSIHI): Indicates whether the use of a PDU set by the application layer requires all PDUs in the PDU set.

[0919] -PDU set information and identification (dynamic information for DL ​​provided by the user plane in the GTP-U header):

[0920] -PDU set sequence number;

[0921] - PDU aggregate size in bytes (for further study);

[0922] -PDU SN within the PDU set;

[0923] - indication of the end PDU of a PDU set;

[0924] -PDU Set Importance (PSI): Identifies the relative importance of a PDU set compared to other PDU sets within a QoS flow. The RAN can use this for PDU set level packet discard in the presence of congestion;

[0925] - End of data burst indication in the header of the last PDU of a data burst (optional).

[0926] For uplink XR traffic, the UE needs to be able to dynamically identify PDU sets and data bursts, including PSI, but no in-band marking on the Uu of the PDU is required. Additional potential improvements to enhance scheduling of uplink resources are given in clause 5.3.2.

[0927] When PSIHI is set for a QoS flow, once one PDU in a known PDU set is lost, the remaining PDUs in the PDU set may be considered no longer required by the application and may be subject to discard operations (see clause 5.3.2).

[0928] NOTE 3: It cannot always be assumed that the remaining PDUs are not useful and can be safely discarded.

[0929] NOTE 4: In the case of Forward Error Correction (FEC), active discarding of PDUs when it is assumed that a sufficiently large number of packets have been transmitted for FEC to recover with no remaining PDUs is not recommended, as it may trigger the addition of FEC packets (see S4aV220921

[14] ).

[0930] […]

[0931] 5.3.2 Layer 2 Enhancement

[0932] To enhance the scheduling of uplink resources for XR, the following improvements are envisaged:

[0933] - One or more additional BS tables to reduce quantization errors in BSR reports (e.g., for high bit rates);

[0934] - Knowledge of the delay of the buffered data, which consists of e.g. the remaining time and distinguishes how much data is buffered for which delay. It will be determined whether the delay information is reported as part of the BSR or as a new MAC CE. Also, how up-to-date the delay information can be, e.g. taking into account scheduling and transmission delays, needs further study.

[0935] - Additional BSR triggering conditions to allow timely availability of buffer status information may be further studied.

[0936] - Delivery of some auxiliary information (eg periodically) reusing TSCAI as a baseline. Assuming that all information may not always be available at the UE application, one may further consider whether additional mechanisms are needed.

[0937] - Signalling of UL traffic arrival information from UE to gNB, e.g. handling jitter in tethered case (FFS).

[0938] For PDCP discard operation in uplink, the timer-based discard operation (when configured) shall be applied to all SDUs / PDUs belonging to the same PDU set. In addition, for a PDU set in a QoS flow with PSIHI set, when one PDU of the PDU set is known to be lost or associated to a discarded SDU (see clause 5.1.1), all remaining PDUs of the PDU set may be discarded at the transmitter to release radio resources.

[0939] In case of congestion, PSI can be used for PDU aggregate discard (see clause 5.1.1) and in the uplink, a PDU aggregate discard mechanism taking PSI into account will be introduced.

[0940] In the uplink, the use of configured grants brings the potential benefit of having enhanced XR services recommended in clause 5.3.1, while in the downlink, enhancements to semi-persistent scheduling are not expected to bring any benefit.

[0941] NOTE: Tier 2 components of the organization recommended in clause 5.3.1 will be specified.

[0942] As indicated in the 3GPP RAN2 meeting chairperson's notes, the 3GPP RAN2 meeting made the following agreements:

[0943] (For RAN2#122)

[0944] -About perception:

[0945] - The range of jitter that the UE reports to the RAN in its UL traffic is defined in a similar way to that of N6 jitter.

[0946] - The reference time is defined in a similar way to the BAT (Burst Arrival Time) at the UE side.

[0947] - Report UL assistance information per QoS flow (burst arrival time, UL jitter, periodicity for further study). The network can configure for which QoS flow the UE should report assistance information.

[0948] - Update the RRC UAI framework for Rel-18 to support the signaling UL assistance information agreed so far for XR (jitter, burst arrival time, periodicity are for further study).

[0949] - Re-use of existing mechanisms (eg (padding) BSR with BS value equal to zero) as implicit End of Data Burst (EoDB) indicator for RAN.

[0950] - On the UL, the identification of PDU sets, data bursts and PSI depends on the UE implementation. This does not mean that the UE cannot use the information provided by upper layers, but RAN2 does not intend to specify how to do it.

[0951] -About power saving:

[0952] -Define the DRX cycle based on rational numbers. Inform the RAN1 / 4 of this and ask them to indicate if this causes issues in their specifications.

[0953] - Broadcast signaling for counters and reference SFN in XR is not used

[0954] -About capacity enhancement:

[0955] - The UE calculates the remaining time based on the PDCP discard timer value. Whether the UE reports one or more values ​​is for further study. How this is modeled in the PDCP specification is for further study. Which UEs support this is for further study.

[0956] - When / if the UE reports the remaining time, the reference time for the remaining time is determined from the point of first transmission of the information. Whether intra-UE prioritization can affect this is for further study.

[0957] - Support of one static BSR table with 8-bit BS field for Rel-18 XR (for all cases).

[0958] - We do not support the additional piecewise linear BSR table in Rel-18. Piecewise linearity can be considered when discussing how to define BSR table values.

[0959] -PDU set discard indication for UL is configured using RRC to handle the discard functionality based on PDU sets (ie, whether the UE discards all packets in a PDU set when discarding one PDU). Configured per PDCP entity.

[0960] - The network instructs the UE to apply the PSI-based XR discard mechanism via dedicated signaling.

[0961] - How / whether to indicate minimization of additional UL signaling after this is for further study.

[0962] Whether the -NW indication is a single or subsequent packet is for further study.

[0963] - For retransmission-less CG enhancement in XR, adapt the NTN solution by disabling the HARQ RTT timer configured per CG. Specifically, the following modifications should be introduced:

[0964] - New RRC parameter drx-HARQ-RTT-TimerUL for deactivating CG configuration;

[0965] - Changes in the procedural text for DRX operation of CG in the MAC specification;

[0966] - New UE capability to support drx-HARQ-RTT-TimerUL with deactivated CG configuration.

[0967] (For RAN2#123)

[0968] - The UE uses UAI to report the burst arrival time and jitter associated with the UL data burst periodicity in the uplink.

[0969] - The UE uses UAI to report the UL data burst periodicity in uplink.

[0970] - All UAI fields for XR are optional fields in RRC. How to handle the persistence of the signaled information is for further study (e.g. UE reports BAT first and then jitter).

[0971] -Consider exact jitter range later (e.g. via email discussion)

[0972] - UE may also report the absence of jitter (e.g. for posture)

[0973] - Reusing the UAI framework, for example, the network can configure when the UE is allowed to report UAI. The exact trigger when configured and the change of UAI depends on the UE implementation. The network can configure a prohibit timer for reporting.

[0974] -The maximum value of the counter (NSFN) is 2^16=65536.

[0975] - The network sets the DRX-ReferenceSFN to 0 or 512 in the same way as in Rel-16 IIoT.

[0976] - Use the following option (Option A): Both counters NSFN and DRX reference SFN drx-ReferenceSFN are added to the DRX formula. NSFN is initialized to 0.

[0977] - The network can configure whether the UE triggers a delay status report. Whether we have some threshold per LCG is for further study.

[0978] - When the UE triggers reporting of the delay information of the LCG, and the UE also reports the buffer status associated with the remaining time.

[0979] -RAN2 intends to define a single MAC CE for DSR reporting (including buffer status). Whether this is an extension of the BSR MAC CE or a new MAC CE is for further study.

[0980] - Many companies think a single value per LCG is sufficient. Some companies think the scheduler needs more information.

[0981] - Working assumption: A new separate MAC CE for DSR (remaining delay and associated data volume) reporting is defined, e.g. DSR reporting is not coupled with BSR reporting. The detailed definition of the associated data volume is for further study.

[0982] - Support threshold-based DSR reporting, for example, DSR reporting is triggered when the remaining delay of a PDU / PDU set is below a NW configured threshold. The threshold is configured per LCG. Whether to support configuration of multiple thresholds for an LCG is for further study. The definition of the remaining time is for further study.

[0983] - The PDCP discard timer for a PDU aggregate supports the case where the PDUs of the PDU aggregate arrive at different time instances.

[0984] - The company should bring a detailed Phase 3 proposal, preferably co-signed by several proponents, to the next meeting, when RAN2 aims to decide which solution to use.

[0985] - Send LS to RAN1 (MTK) to inform it of the error in the formula and to inform RAN2 that the HARQ process formula in the RAN2 specification will be captured. Ask RAN1 if the validity will be defined in the RAN1 specification. If there is ambiguity in the RAN2 specification, clarification on how the validity works may be requested.

[0986] - UE capabilities will be discussed in the next meetings based on company input. Companies are encouraged to also provide Stage 3 details of their proposals, e.g., a draftCR on capabilities to allow better comparison of proposals.

[0987] - Interested companies bringing documents to this AI should contact the regulatory investigator offline to solidify their proposal.

[0988] The 3GPP email discussion ([Post124]

[040] [XR]38.331CR) describes the following:

[0989] -PDCP-Config

[0990] The IE PDCP-Config is used to set the configurable PDCP parameters for signaling, MBS multicast and data radio bearers. PDCP-Config information element

[0991]

[0992]

[0993]

[0994]

[0995]

[0996]

[0997] The 3GPP email discussion ([Post124]

[042] [XR]38.323) describes the following:

[0998] 3.1 Definition

[0999] […]

[1000] Delay critical PDCP SDU: A PDCP SDU for which the remaining time until the discardTimer expires is less than remainingTimeThreshold. If pdu-SetDiscard is configured, all PDCP SDUs (including already stored PDCP SDUs and newly received PDCP SDUs) belonging to the PDU set to which at least one delay critical PDCP SDU belongs are considered as delay critical PDCP SDUs. If the corresponding PDCP data PDU has been submitted to the lower layers, the delay critical indication for the PDCP data PDU is provided to the lower layers.

[1001] […]

[1002] PDU set: One or more PDUs that carry the payload of one information unit (e.g., a frame or video slice for an XR service) generated at the application layer, as defined in TS 23.501 [xx]. A PDU in a PDU set corresponds to a PDCP SDU.

[1003] […]

[1004] 5.2.1Transfer Operation

[1005] Upon receiving a PDCP SDU from upper layers, the transmitting PDCP entity shall:

[1006] - If psi-BasedDiscard is configured and PSI-based SDU discard is activated, and the PDCP SDU belongs to the low importance PDU set:

[1007] - start the discardTimerForLowImportance associated with this PDCP SDU (if configured);

[1008] -otherwise:

[1009] - Start the discardTimer associated with this PDCP SDU (if configured).

[1010] NOTE 1: The identification of the PSI of a PDU set and the determination of the low importance PDU set depends on the UE implementation.

[1011] For PDCP SDUs received from upper layers, the transmitting PDCP entity shall:

[1012] - associating a count value corresponding to TX_NEXT with this PDCP SDU;

[1013] NOTE 2: Correlating more than half of the PDCP SN space of contiguous PDCP SDUs with PDCP SNs, for example, when discarding or transmitting PDCP SDUs without ACK, may cause HFN desynchronization issues. How to prevent HFN desynchronization issues depends on the UE implementation.

[1014] - Perform header compression of PDCP SDUs using ROHC as specified in clause 5.7.4 and / or using EHC as specified in clause 5.12.4;

[1015] - Perform uplink data compression of PDCP SDUs as specified in clause 5.14.4;

[1016] - perform integrity protection and encryption using TX_NEXT as specified in clauses 5.9 and 5.8 respectively;

[1017] - Set the PDCP SN of the PDCP data PDU to TX_NEXT modulo 2 [pdcp-SN-SizeUL] ;

[1018] -Increment TX_NEXT by one;

[1019] - Submit the resulting PDCP Data PDUs to lower layers as specified below.

[1020] When submitting a PDCP PDU to lower layers, the transmitting PDCP entity shall:

[1021] - If the transmitting PDCP entity is associated with a SRAP entity:

[1022] - Submit the PDCP PDU to the associated SRAP entity;

[1023] - Otherwise, if the transmitting PDCP entity is associated with an RLC entity:

[1024] - Submitting PDCP PDUs to the associated RLC entity;

[1025] - Otherwise, if the transmitting PDCP entity is associated with at least two RLC entities:

[1026] - If PDCP duplication is activated for RB:

[1027] - If the PDCP PDU is a PDCP data PDU:

[1028] - duplicating the PDCP data PDUs and submitting the PDCP data PDUs to the associated RLC entity activated for PDCP duplication;

[1029] -otherwise:

[1030] - Submit PDCP control PDU to the primary RLC entity;

[1031] - Otherwise (i.e., PDCP duplication is deactivated for the RB, or the RB is a DAPS bearer):

[1032] - if a split secondary RLC entity is configured; and

[1033] If the total amount of PDCP data and RLC data pending for initial transmission (as specified in TS 38.322 [5]) in the primary RLC entity and the split secondary RLC entities is equal to or greater than ul-DataSplitThreshold:

[1034] - Submitting PDCP PDUs to the primary RLC entity or the split secondary RLC entity;

[1035] - Otherwise, if the transmitting PDCP entity is associated with a DAPS bearer:

[1036] - If uplink data handover has not been requested:

[1037] - Submit the PDCP PDU to the RLC entity associated with the source cell;

[1038] -otherwise:

[1039] - If the PDCP PDU is a PDCP data PDU:

[1040] - Submitting the PDCP data PDU to the RLC entity associated with the target cell;

[1041] -otherwise:

[1042] - If the PDCP Control PDU is associated with the source cell:

[1043] - Submitting the PDCP control PDU to the RLC entity associated with the source cell;

[1044] -otherwise:

[1045] - Submitting the PDCP control PDU to the RLC entity associated with the target cell;

[1046] -otherwise:

[1047] - Submit PDCP PDU to the primary RLC entity.

[1048] NOTE 3: If the transmitting PDCP entity is associated with two RLC entities, the UE should minimize the amount of PDCP PDUs submitted to the lower layer before receiving the request from the lower layer and minimize the PDCP SN gap between the PDCP PDUs submitted to the two associated RLC entities to minimize the PDCP reordering delay when receiving the PDCP entity.

[1049] 5.3SDU discard

[1050] When successful delivery of a PDCP SDU is confirmed by a PDCP status report, the transmitting PDCP entity shall discard the PDCP SDU together with the corresponding PDCP data PDU.

[1051] When discardTimer or discardTimerForLowImportance expires for a stored PDCP SDU, the transmitting PDCP entity shall:

[1052] - If pdu-SetDiscard is configured:

[1053] - discarding all PDCP SDUs belonging to the PDU set to which the PDCP SDU together with the corresponding PDCP data PDU belongs (including already stored PDCP SDUs and newly received PDCP SDUs);

[1054] -otherwise:

[1055] -Discarding the PDCP SDU together with the corresponding PDCP data PDU.

[1056] If the corresponding PDCP data PDU has been submitted to the lower layer, then the lower layer is indicated to discard it.

[1057] For SRB, when upper layers request PDCP SDU discard, the PDCP entity shall discard all stored PDCP SDUs and PDCP PDUs.

[1058] NOTE: Discarding a PDCP SDU that has been associated with a PDCP SN causes a SN gap in the transmitted PDCP data PDUs, which increases the PDCP reordering delay in the receiving PDCP entity. How to minimize the SN gap after SDU discard depends on the UE implementation.

[1059] […]

[1060] 7.3 Timer

[1061] The transmitting PDCP entity shall maintain the following timers:

[1062] a)discardTimer

[1063] This timer is configured only for DRBs. The duration of the timer is configured by upper layers TS 38.331 [3]. In the transmitter, a new timer is started after receiving an SDU from upper layers.

[1064] b)discardTimerForLowImportance

[1065] This timer is configured only for DRBs. The duration of the timer is configured by upper layers TS 38.331 [3]. In the transmitter, if psi-BasedDiscard is configured and PSI-based SDU discard is activated, a new timer is started after receiving an SDU belonging to the low importance PDU set from upper layers.

[1066] Extended reality (XR) and cloud gaming are some of the most important 5G media applications considered in the industry. XR is an umbrella term for different types of reality and refers to all real and virtual combined environments and human-computer interactions generated by computer technology and wearables. It includes representative forms such as augmented reality (AR), mixed reality (MR) and virtual reality (VR) as well as the fields involved.

[1067] 5G NR will be designed to support applications that require high throughput and low latency, in line with the requirements set by the support of XR and edge computing applications in NR networks. XR and edge computing are services enabled by Rel-15 NR networks.

[1068] In NR, when a UE initiates a service, the UE establishes a PDU session for the service with the network. The network will establish one or more data radio bearers (DRBs) for transmitting services between the UE and the network. In order to meet the QoS requirements of each user's service towards the network, NR defines a QoS flow model for the processing of QoS requirements, where the requirement is the finest granularity for QoS differentiation of QoS flows in a PDU session. Since the user's service may contain different QoS requirements (e.g., guaranteed flow bit rate (GFBR), maximum flow bit rate (MFBR), etc.), it is possible that one or more QoS flows will be established within a PDU session (i.e., QoS flows are per PDU session). Appropriately, the network can configure the UE to map each QoS flow to a DRB, and each DRB can be configured with appropriate AS parameters (e.g., discard time in packet data convergence protocol (PDCP), logical channel priority, etc.) to meet the QoS characteristics (e.g., packet delay budget, priority, etc.) of the QoS flow mapped to this DRB.

[1069] The service data adaptation protocol (SDAP) layer of the UE may include the services (i.e., upper layer services, such as IP packets) of the QoS flow in the SDAP PDU, and deliver the SDAP PDU to the DRB for transmission based on the QoS flow to DRB mapping. The SDAP PDU is regarded as a PDCP service data adaptation unit (SDU). The UE may be able to initiate a QoS flow by itself. Since the network has not yet allocated a QoS flow to DRB mapping for the UE-initiated QoS flow, in this case, the UE may map the UE-initiated QoS flow to a preset DRB. The network may identify this UE-initiated QoS flow based on the identity of the UE-initiated QoS flow in the header of the SDAP PDU received from the UE. If necessary, the network may configure the UE to establish a new DRB and remap the UE-initiated QoS flow from the preset DRB to the new DRB. When the UE-initiated QoS flow is remapped from the preset DRB to the new DRB, the UE may send an end marker of the UE-initiated QoS flow on the preset DRB so that the network may know that there is no more service of the UE-initiated QoS flow to be sent on the preset DRB after the end marker.

[1070] For some XR media frames, all PDUs of the PDU set for the frame should be sent successfully. If there are PDUs of a PDU set that cannot be sent successfully, the remaining PDUs of the PDU set should be discarded. If the discard timer associated with a PDCP SDU (PDU used to carry the PDU set) expires and the PDCP SDU has not been successfully transmitted, not only the PDCP SDU (together with the corresponding PDCP PDUs) can be discarded, but also other PDCP SDUs associated with the same PDU set as the discarded PDCP SDU (together with the corresponding PDCP PDUs) can be discarded. According to the RAN2 protocol (as indicated in the 3GPP RAN2 meeting moderator notes), the PDU set discard operation is operated in the PDCP layer and is configured per DRB.

[1071] In 3GPP email discussion [Post124]

[040] [XR]38.331CR (Huawei), a new IE called pdu-SetDiscard and a new discard timer called discardTimerForLowImportance are introduced in the IE of PDCP-Config. When the UE receives a PDCP-Config for a DRB and the PDCP-Config contains this pdu-SetDiscard set to true, the UE considers enabling a PDU set discard operation on the DRB by using such a new discard timer. Since the PDCP discard timer for a PDU set supports the case where the PDUs of the PDU set arrive at different time instances, the IE of discardTimerForLowImportance in the PDCP-Config can be set based on the PSDB of the QoS flow mapped to the DRB. According to 3GPP email discussion [Post124]

[042] [XR]38.323CR(LGE), if the discard timer (i.e., discardTimerForLowImportance) of a PDCP SDU expires and pdu-SetDiscard is configured, the UE shall discard all PDCP SDUs (including already stored PDCP SDUs and newly received PDCP SDUs) belonging to the PDU set to which the PDCP SDU belongs together with the corresponding PDCP data PDU.

[1072] It is possible that the UE can initiate a QoS flow for XR services. In this case, the QoS flow will be mapped to the UE's preset DRB, and the UE sends the traffic of the QoS flow on the preset DRB. The network can perceive the QoS flow based on the received traffic, where the SDAP header indicates the new identity of the QoS flow. The QoS flow can serve one or more PDU sets of high importance (i.e., all PDUs of each PDU set are required). The network can configure the UE to establish a new DRB for serving the QoS flow. It is possible that the UE can deliver some PDUs of the PDU set of the QoS flow to the preset DRB before establishing the second DRB, and deliver the remaining PDUs of the PDU set of the QoS flow to the new DRB. On the other hand, it is also possible that the UE uses the first DRB (i.e., not the preset DRB) to serve the QoS flow for XR services, and the network can configure the UE to remap the QoS flow from the first DRB to the second DRB. Similarly, the UE can deliver some PDUs of the PDU set of the QoS flow to the first DRB, and then deliver the remaining PDUs of the PDU set of the QoS flow to the second DRB. Since the discard timer may be started for the (exactly) first PDU of a PDU set and operates per DRB, one may consider how to take this into account for handling the two scenarios.

[1073] For a given QoS flow, there may be a PDU set containing at least a first PDU and a second PDU. The QoS flow may first be mapped to a first DRB. The UE may receive a first PDU from an upper layer and deliver the first PDU to the first DRB. The UE may start a first discard timer associated with the first PDU (or PDU set). The UE may be configured / instructed by the network to remap the QoS flow from the first DRB to the second DRB. Thereafter, the UE may receive a second PDU from an upper layer and deliver the second PDU to the second DRB.

[1074] After the first discard timer expires, the UE may discard the first PDU delivered to the first DRB (if the PDU has not been successfully transmitted). The UE may also discard the second PDU delivered to the second DRB in response to the first discard timer expiring.

[1075] Alternatively, in response to receiving the second PDU from the upper layer, the UE may start a second discard timer for the second PDU on the second DRB. The length of the second discard timer may be set based on the discardTimerForLowImportance of the PDCP-Config for the second DRB and the elapsed time of the first discard timer on the first DRB. For example, the length of the second discard timer may be set to "the value of the discardTimerForLowImportance IE for the second DRB" minus (-) "the elapsed time of the first discard timer on the first DRB". It should be noted that for the discard timer (for other PDU sets) that will be started on the second DRB subsequently, its length may still be set to the discardTimerForLowImportance IE of the PDCP-Config for the second DRB. In this alternative, after the first discard timer expires, the UE may just discard the first PDU delivered to the first DRB; and after the second discard timer expires, the UE may subsequently discard the second PDU delivered to the second DRB (and any remaining PDUs belonging to the same PDU set of the second PDU).

[1076] More specifically, the first DRB may be a preset DRB and the second DRB may be a non-preset DRB. More specifically, both the first DRB and the second DRB may be non-preset DRBs.

[1077] Fig.2121 is a flowchart for a UE. In step 2105, the UE starts a first discard timer for a first PDU from a set of PDUs of a QoS flow and delivers the first PDU to a first DRB. In step 2110, the UE receives a message from the network for remapping the QoS flow from the first DRB to a second DRB. In step 2115, the UE delivers a second PDU of the PDU set to a second DRB. In step 2120, in response to the expiration of the first discard timer, the UE performs a discard for the first PDU on the first DRB and the second PDU on the second DRB.

[1078] In one embodiment, the message may be an RRCReconfiguration message. The first PDU may be included in a first PDCP SDU or may correspond to the first PDCP SDU. The second PDU may be included in a second PDCP SDU or may correspond to the second PDCP SDU.

[1079] In one embodiment, the first discard timer may be a per-PDU set discard timer or a discardTimerForLowImportance.The second PDU may be the very first PDU of the PDU set delivered to the second DRB.

[1080] In one embodiment, the UE may not start any discard timer for the second PDU or start a second discard timer for the second PDU. The length of the second discard timer may be set based on the configuration of the second DRB and the elapsed / remaining / elapsed time of the first discard timer. The configuration of the second DRB may contain at least the IE of discardTimerForLowImportance.

[1081] In one embodiment, the second discard timer may be a per-PDU set discard timer or a discardTimerForLowImportance.The first DRB may be a preset DRB.

[1082] In one embodiment, the network may contain at least one of a base station (gNB), an SMF, an AMF and a UPF.

[1083] Reference now Figure 3 and Figure 4, in an exemplary embodiment from the perspective of the UE. The UE 300 includes program code 312 stored in the memory 310. The CPU 308 can execute the program code 312 to enable the UE to: (i) start a first discard timer for a first PDU from a PDU set of the QoS flow and deliver the first PDU to a first DRB, (ii) receive a message from the network for remapping the QoS flow from the first DRB to the second DRB, (iii) deliver the second PDU of the PDU set to the second DRB, and (iv) perform a discard for the first PDU on the first DRB and the second PDU on the second DRB in response to the expiration of the first discard timer. In addition, the CPU 308 can execute the program code 312 to perform all of the above actions and steps or other actions and steps described herein.

[1084] Alternatively, following the above example, the UE may still deliver the second PDU to the first DRB even if remapping of the QoS flow from the first DRB to the second DRB occurs before the second PDU is received from the upper layer. In other words, once the UE has delivered any PDU of the PDU set of the QoS flow to the first DRB, then in the event that remapping of the QoS flow from the first DRB to the second DRB occurs, the UE may continue to deliver the remaining PDUs of the PDU set to the first DRB, and then send an end marker for the QoS flow on the first DRB. Thereafter, the UE may deliver subsequent PDUs of the (other) PDU set of the QoS flow to the second DRB. In this alternative, the effort of handling discard timers across different DRBs may be saved.

[1085] Fig. 22 is a flow chart 2200 for a UE. In step 2205, the UE delivers a first PDU from a first PDU set of the QoS flow to a first DRB. In step 2210, the UE receives a message from the network for remapping the QoS flow from the first DRB to a second DRB. In step 2215, the UE delivers a second PDU of the first PDU set to the first DRB, wherein the second PDU is the last PDU of the first PDU set. In step 220, the UE sends an end marker of the QoS flow on the first DRB, wherein the end marker is sent after the second PDU.

[1086] In one embodiment, the UE may deliver a third PDU from the second PDU set of the QoS flow to the second DRB. The second PDU may be sent after receiving the message.

[1087] In one embodiment, the message may be an RRCReconfiguration message. The first PDU may be included in the first PDCP SDU or may correspond to the first PDCP SDU. The second PDU may be included in the second PDCP SDU or may correspond to the second PDCP SDU. The third PDU may be included in the third PDCP SDU or may correspond to the third PDCP SDU. The end marker may be an SDAP control PDU. The first DRB may be a preset DRB.

[1088] In one embodiment, the network may contain at least one of a base station (gNB), an SMF, an AMF and a UPF.

[1089] Reference now Figure 3 and Figure 4 , in an exemplary embodiment from the perspective of a UE. UE 300 includes program code 312 stored in memory 310. CPU 308 can execute program code 312 to enable the UE to: (i) deliver a first PDU from a first PDU set of a QoS flow to a first DRB, (ii) receive a message from the network for remapping the QoS flow from the first DRB to a second DRB, (iii) deliver a second PDU of the first PDU set to the first DRB, wherein the second PDU is the last PDU of the first PDU set, and (iv) send an end marker of the QoS flow on the first DRB, wherein the end marker is sent after the second PDU. In addition, CPU 308 can execute program code 312 to perform all of the above actions and steps or other actions and steps described herein.

[1090] On the other hand, the preset DRB can serve such UE-initiated QoS flows associated with high importance and some QoS flows with low importance (i.e., some PDUs of the PDU set may be lost). Basically, the length of the discardTimer of the PDU from the QoS flow with high importance will need a longer value (to cover the situation where the PDUs of the PDU set arrive at different time instances), and the length of the discardTimer of the PDU from the QoS flow with low importance will be short. If the discardTimer IE of the PDCP-Config for the preset DRB follows tradition and is set to a longer value, it will cause UE buffer congestion because it takes a longer time to buffer those PDUs with low importance. If the discardTimer IE of the PDCP-Config for the preset DRB follows tradition and is set to a shorter value, it will cause those PDUs with high importance to fail to meet the requirements of their corresponding PSDB. Therefore, it is possible to consider how to set the value of the discardTimer IE for the preset DRB.

[1091] The PDCP-Config of a preset DRB may contain two different length values ​​for discardTimer operation. For example, in response to receiving a first PDU of a first QoS flow from an upper layer, the UE may start a first discardTimer with a first length value for the first PDU on a preset DRB; and in response to receiving a second PDU of a second QoS flow from an upper layer, the UE may start a second discardTimer with a second length value for the second PDU on a preset DRB. The first QoS flow may be associated with high importance and the second QoS flow may be associated with low importance. The first length value may be longer than the second length value. Since the preset DRB can serve such UE-initiated QoS flows associated with high importance, the network may (need to) (always) indicate such pdu-SetDiscard IE (set to true) in the PDCP-Config of the preset DRB. When reconfiguring the preset DRB (via an RRCReconfiguration message), the network may not or may not be allowed or may be prohibited from changing such pdu-SetDiscard IE in the PDCP-Config of the preset DRB. For example, the network may send a first RRCReconfiguration message to the UE to establish a preset DRB for the PDU session, and the first RRCReconfiguration message may include such a pdu-SetDiscard IE. The network may send a second RRCReconfiguration message to the UE to reconfigure the preset DRB, wherein the second RRCReconfiguration message may still include such a pdu-SetDiscard IE. The second RRCReconfiguration message cannot exclude such a pdu-SetDiscard IE or cannot include such a pdu-SetDiscard IE set to false.

[1092] Alternatively, in addition to being a traditional preset DRB, a second preset DRB can also be introduced to serve such UE-initiated QoS flows with high importance. If the UE itself initiates a first QoS flow with high importance, the UE can map the first QoS flow to the second preset DRB; if the UE itself initiates a second QoS flow with low importance, the UE can map the second QoS flow to the traditional preset DRB. The discardTimerIE of the PDCP-Config for the second preset DRB may be present in the RRCReconfiguration message sent to the UE for establishing the second preset DRB. The PDCP-Config for the second preset DRB or the RRCReconfiguration message containing the PDCP-Config for the second preset DRB may include such pdu-SetDiscard IE (set to true). Similarly, if necessary, the network may still be able to remap the first QoS flow from the second preset DRB to other DRBs. The related discard operations may also follow the above solution.

[1093] Fig.23 2300 is a flow chart for a UE connected to a network. In step 2305, the UE delivers a first protocol data unit (PDU) from a first PDU set of a quality of service (QoS) flow to a first data radio bearer (DRB). In step 2310, the UE receives a message or indication from the network for remapping the QoS flow from the first DRB to a second DRB. In step 2315, the UE delivers a second PDU of the first PDU set to the first DRB, wherein the second PDU is delivered to the first DRB after receiving the message or indication.

[1094] In one embodiment, the UE may deliver the third PDU of the second PDU set from the QoS flow to the second DRB after receiving the message or indication. The message may be an RRCReconfiguration message. The indication may be a reflective QoS flow to DRB mapping indication (RDI).

[1095] In one embodiment, the UE may send an end marker of the QoS flow on the first DRB, wherein the end marker is sent after sending the last PDU of the first PDU set. The first / second PDU set may contain one or more PDUs carrying a payload of an information unit (e.g., a frame or a video slice) generated at the application layer.

[1096] Reference now Figure 3 and Figure 4, in an exemplary embodiment from the perspective of the UE. The UE 300 includes program code 312 stored in the memory 310. The CPU 308 can execute the program code 312 to enable the UE to: (i) deliver a first protocol data unit (PDU) from a first PDU set of a quality of service (QoS) flow to a first data radio bearer (DRB), (ii) receive a message or indication from the network for remapping the QoS flow from the first DRB to the second DRB, and (iii) deliver a second PDU of the first PDU set to the first DRB, wherein the second PDU is delivered to the first DRB after receiving the message or indication. In addition, the CPU 308 can execute the program code 312 to perform all of the above actions and steps or other actions and steps described herein.

[1097] Various aspects of the present disclosure have been described above. It should be understood that the teachings herein can be implemented in a wide variety of forms, and any specific structure, function, or both disclosed herein are only representative. Based on the teachings herein, it should be understood by those skilled in the art 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 a device or practice method. In addition, other structures, functionality, or structures and functionality other than one or more aspects set forth herein or different from the aspects can be used to implement such devices or practice such methods. As examples of some of the above concepts, in some aspects, parallel channels can be established based on pulse repetition frequencies. In some aspects, parallel channels can be established based on pulse positions or offsets. In some aspects, parallel channels can be established based on hopping sequences. In some aspects, parallel channels can be established based on pulse repetition frequencies, pulse positions or offsets, and time hopping sequences.

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

[1099] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, processors, components, circuits, and algorithm steps described in conjunction with the various aspects disclosed herein may be implemented as electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two that may be designed using source decoding or some other technique), various forms of programs or design code incorporating instructions (which, for convenience, may be referred to herein as "software" or "software modules"), or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in 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 overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[1100] In addition, the various illustrative logical blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented within or performed by an integrated circuit ("IC"), an access terminal, or an access point. The 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 the IC, outside the IC, or both. A general purpose processor may be a microprocessor, but in the alternative, 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, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[1101] It should be understood that any specific order or hierarchy of steps in any disclosed process is an example of an exemplary method. It should be understood that based on design preferences, the specific order or hierarchy of steps in a process can be rearranged while remaining within the scope of the present disclosure. The accompanying method claims present the elements of the various steps in a sample order and are not intended to be limited to the specific order or hierarchy presented.

[1102] The steps of the method or algorithm described in conjunction with the various aspects disclosed herein can be implemented directly with hardware, with a software module executed by a processor, or with a combination of the two. Software modules (e.g., including executable instructions and related data) and other data can reside in a data memory, such as a RAM memory, a flash memory, a ROM memory, an EPROM memory, an EEPROM memory, a register, a hard disk, a removable disk, a CD-ROM, or any other form of a computer-readable storage medium known in the art. A sample storage medium can be coupled to a machine such as a computer / processor (for convenience, the machine can be referred to as a "processor" in this article) so that the processor can read information (e.g., code) from a storage medium and write information to a storage medium. A sample storage medium can be integrated with a processor. The processor and the storage medium can reside in an ASIC. The ASIC can reside in a user device. In an alternative, the processor and the storage medium can reside in a user device as discrete components. In addition, in some aspects, any suitable computer program product may include a computer-readable medium, which includes a code related to one or more of the various aspects of the present disclosure. In some aspects, a computer program product may include packaging materials.

Claims

1. A method for a user device connected to a network, characterized in that: The method comprises: The user equipment delivers a first protocol data unit from a first set of protocol data units of the quality of service flow to a first data radio bearer; The user equipment receives a message or an indication from the network for remapping the quality of service flow from the first data radio bearer to a second data radio bearer; and The user equipment delivers a second protocol data unit of the first set of protocol data units to the first data radio bearer, wherein the second protocol data unit is delivered to the first data radio bearer after receiving the message or the indication.

2. The method according to claim 1, characterized in that The method further comprises: The user equipment delivers a third protocol data unit from the second set of protocol data units of the quality of service flow to the second data radio bearer after receiving the message or the indication.

3. The method according to claim 1, characterized in that: The message is an RRCReconfiguration message.

4. The method according to claim 1, characterized in that The indication is a reflective quality of service flow to data radio bearer mapping indication.

5. The method according to claim 1, characterized in that The method further comprises: The user equipment sends an end marker of the quality of service flow on the first data radio bearer, wherein the end marker is sent after sending a last protocol data unit of the first set of protocol data units.

6. The method according to claim 1, characterized in that The first protocol data unit set or the second protocol data unit set contains one or more protocol data units carrying a payload of an information unit generated at the application layer.

7. A user equipment, characterized in that: The user equipment comprises: Control circuit; a processor installed in the control circuit; and a memory installed in the control circuit and operatively coupled to the processor; wherein the processor is configured to execute program code stored in the memory to: delivering a first protocol data unit from a first set of protocol data units of the quality of service flow to a first data radio bearer; receiving a message or indication from the network to remap the quality of service flow from the first data radio bearer to a second data radio bearer; and A second protocol data unit of the first set of protocol data units is delivered to the first data radio bearer, wherein the second protocol data unit is delivered to the first data radio bearer after receiving the message or the indication.

8. The user equipment according to claim 7, characterized in that The processor is further configured to execute program code stored in the memory to: A third protocol data unit from a second set of protocol data units of the quality of service flow is delivered to the second data radio bearer after receiving the message or the indication.

9. The user equipment according to claim 7, characterized in that: The message is an RRCReconfiguration message.

10. The user equipment according to claim 7, characterized in that The indication is a reflective quality of service flow to data radio bearer mapping indication.

11. The user equipment according to claim 7, characterized in that: The processor is further configured to execute program code stored in the memory to: An end marker of the quality of service flow is sent on the first data radio bearer, wherein the end marker is sent after a last protocol data unit of the first set of protocol data units is sent.

12. The user equipment according to claim 7, characterized in that The first protocol data unit set or the second protocol data unit set contains one or more protocol data units carrying a payload of an information unit generated at the application layer.

Images