Method and apparatus for mapping uu radio bearer to PC5 radio link control bearer
By transmitting specific RRC messages and adaptation layer PDUs in the wireless communication system, Uu radio bearer to PC5 radio link control bearer mapping is realized, solving the mapping efficiency and quality problems in the prior art, and improving the performance of the communication system.
Patent Information
- Application Number
- CN202510151467.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2020-11-16
- Filing Date
- 2021-11-04
- Publication Date
- 2025-04-25
AI Technical Summary
The prior art is difficult to effectively implement Uu radio bearer to PC5 radio link control bearer mapping in wireless communication systems, resulting in communication efficiency and quality problems.
By transmitting an RRC message between the network node and the relay user equipment, it contains first information indicating the mapping, indicating the association between the Uu radio bearer and the SL RLC bearer, and includes second information identifying the remote UE associated with the mapping. Meanwhile, the network node transmits an adaptation layer PDU to the relay UE, and its header contains the identity of the Uu radio bearer and the local UE identifier of the remote UE.
The effective mapping between Uu radio bearer and SL RLC bearer is realized, the efficiency and quality of the communication system are improved, and the stable connection between the remote UE and the network is ensured.
Smart Images

Figure CN119893752A_ABST
Abstract
Description
[0001] This invention is a divisional application of the invention patent application with application number 202111302514.9 filed on November 4, 2021, and invention name: "Method and device for mapping UU radio bearer to PC5 radio link control bearer".
[0002] CROSS-REFERENCE TO RELATED APPLICATIONS
[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 114,158, filed on November 16, 2020, the entire disclosure of which is incorporated herein by reference in its entirety. Technical Field
[0004] The present disclosure relates generally to wireless communication networks, and more particularly, to methods and apparatus for Uu radio bearer to PC5 Radio Link Control (RLC) bearer mapping in a wireless communication system. Background Art
[0005] 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 with Internet Protocol (IP) data packet communications, which can provide IP-bearing voice, multimedia, multicast and on-demand communication services to users of mobile communication devices.
[0006] 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 next-generation (e.g., 5G) radio technologies. Therefore, changes to the current body of 3GPP standards are currently being submitted and considered to evolve and complete the 3GPP standards. Summary of the invention
[0007] A method and apparatus for Uu radio bearer to sidelink (SL) radio link control (RLC) mapping is disclosed. In one embodiment, the method includes a network node transmitting a radio resource control (RRC) message to a relay user equipment (UE), wherein the RRC message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRC message also includes second information identifying a remote UE associated with the mapping. The method further includes the network node transmitting an adaptation layer protocol data unit (PDU) to the relay UE, wherein a header of the adaptation layer PDU includes an identification of the Uu radio bearer and a local UE identifier of the remote UE. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Figure 1 A diagram showing a wireless communication system according to an exemplary embodiment;
[0009] 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;
[0010] Figure 3 is a functional block diagram of a communication system according to an exemplary embodiment;
[0011] Figure 4 According to an exemplary embodiment Figure 3 Functional block diagram of the program code;
[0012] Figure 5 It is 3GPP TS 23.303 V16.0.0 Figure 5 .3.1-1 reappearance;
[0013] Figure 6 It is 3GPP TS 23.303 V16.0.0 Figure 5 .3.1-2 reappearance;
[0014] Figure 7 It is 3GPP TS 23.303 V16.0.0 Figure 5 .3.1-3 reappearance;
[0015] Figure 8 It is 3GPP TS 23.303 V16.0.0 Figure 6 .44.2-1 reappearance;
[0016] Fig. 9 It is 3GPP 38.331 V16.1.0 Figure 5 .3.3.1-1 reappearance;
[0017] Fig.10 It is 3GPP 38.331 V16.1.0 Figure 5 .3.5.1-1 reappearance;
[0018] Fig.11 It is 3GPP 38.331 V16.1.0 Figure 5 .8.3.1-1 reappearance;
[0019] Fig.12 is a flow chart according to an exemplary embodiment;
[0020] Fig.13 is a flow chart according to an exemplary embodiment. DETAILED DESCRIPTION
[0021] 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 or LTE-Advanced), 3GPP2 Ultra Mobile Broadband (UMB), WiMax, 3GPP New Radio (NR), or some other modulation technology.
[0022] Specifically, the exemplary wireless communication systems and devices described below can be designed to support one or more standards, such as those provided by an association named "3rd Generation Partnership Project" (referred to herein as 3GPP), including: TS 23.303 V16.0.0, "Proximity-based Services (ProSe); Stage 2 (Release 16)"; TR 23.752 V0.5.0, "Study on System Enhancements for Proximity-based Services (ProSe) in 5G System (5GS) (Release 17)"; TS 23.502 V16.5.1, "Procedures for 5G System (5GS); Stage 2 (Release 16)"; TS 38.331 v16.1.0, "NR; Radio Resource Control (RRC) Protocol Specification (Release 16)"; and R2-2008047, "Research Aspects of UE-to-Network Relay and Solutions for L2 Relay", Huawei, HiSilicon. The standards and documents listed above are expressly incorporated by reference in their entirety.
[0023] Figure 1 A multiple access wireless communication system according to an embodiment of the present invention is shown. Access network 100 (AN) includes multiple antenna groups, one antenna group includes antennas 104 and 106, another antenna group includes antennas 108 and 110, and another antenna group includes antennas 112 and 114. Figure 1, only two antennas are shown for each antenna group, but each antenna group may utilize more or fewer antennas. Access terminal 116 (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 (AT) 122 communicates with antennas 106 and 108, where antennas 106 and 108 transmit information to access terminal (AT) 122 via forward link 126 and receive information from 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 different frequency than the frequency used by reverse link 118.
[0024] Each antenna group 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.
[0025] In communicating via 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.
[0026] 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, NodeB, base station, enhanced base station, evolved NodeB (eNB), network node, network, or some other term. An access terminal (AT) may also be referred to as user equipment (UE), a wireless communication device, a terminal, an access terminal, or some other term.
[0027] Figure 2 2 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.
[0028] In one embodiment, each data stream is transmitted via 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.
[0029] 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 are 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. The data rate, coding, and modulation for each data stream may be determined by execution of instructions in memory 232 by processor 230.
[0030] 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). TX MIMO processor 220 then provides NT modulation symbol streams to NT 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.
[0031] Each transmitter 222 receives and processes a respective symbol stream to provide one or more analog signals, and further conditions (e.g., amplifies, filters, and upconverts) the analog signals to provide a modulated signal suitable for transmission via the MIMO channel. NT modulated signals from transmitters 222a through 222t are then transmitted from NT antennas 224a through 224t, respectively.
[0032] At receiver system 250, the transmitted modulated signals are received by NR antennas 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.
[0033] The RX data processor 260 then receives and processes the NR received symbol streams from the NR receivers 254 based on a particular receiver processing technique to provide NT "detected" symbol streams. 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 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.
[0034] Processor 270 executes instructions in memory 272 to periodically determine 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.
[0035] The reverse link message may include various types of information related to 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.
[0036] 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.
[0037] Steering 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 in FIG. , 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 (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 display or a speaker). The transceiver 314 is used to receive and transmit wireless signals to transfer 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 implemented Figure 1 AN100 in.
[0038] 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 generally performs radio resource control. Layer 2 portion 404 generally performs link control. Layer 1 portion 406 generally performs physical connectivity.
[0039] 3GPP TS 23.303 specifies two mechanisms (i.e., Model A and Model B) for UE to discover other UEs for relay discovery from UE to network. 3GPP TR 23.752 further proposes to support relay from UE to network, and subsequent versions (i.e., Release 17) include Layer 2 (L2) and Layer 3 (L3) relay solutions. The relevant issues and L2 relay solutions in 3GPP TR 23.752 are as follows:
[0040] 5.3 Key Issue #3: Support for UE-to-Network Relay
[0041] 5.3.1 Overview
[0042] According to TS 22.261[3] and TS 22.278[2], support for UE-to-network relay needs to be studied. In addition, Rel-16 5G architecture design (e.g., flow-based QoS communication over PC5 / Uu interface) should also be considered.
[0043] Need to consider Figure 5.3.1-1 shows a situation in which the UE may be able to access the network via direct network communication or indirect network communication, where path #1 is a direct network communication path that may not exist, and path #2 and path #3 are indirect network communication paths via different UEs to network repeaters.
[0044] [3GPP TS 23.303 V16.0.0 entitled "Example scenarios of direct or indirect network communication paths between UE and network" Figure 5 .3.1-1 reproduced as Figure 5 ]
[0045] Therefore, 5G ProSe needs to support UE-to-network relay. Specifically, the following aspects need to be studied:
[0046] -How to authorize UE to be a 5G UE to network relay and how to authorize UE to access 5GC via 5G UE to network relay.
[0047] - How to establish a connection between a remote UE and a UE-to-network relay to support connectivity to the network for the remote UE.
[0048] - How to support end-to-end requirements between the remote UE and the network via the UE-to-network relay, including handling of QoS (e.g. data rate, reliability, latency) and PDU session related attributes (e.g. S-NSSAI, DNN, PDU session type and SSC mode).
[0049] -How the network allows and controls QoS requirements for 5G ProSe UE to NW relay.
[0050] -How to transfer data between remote UE and network through UE-to-network relay.
[0051] NOTE 1: Security and privacy aspects will be handled by SA WG3.
[0052] - How to (re)select UE to network relay for two indirect network communication paths (i.e. Figure 5 .3.1-1) between path #2 and path #3).
[0053] - How to implement a direct network communication path (i.e. Figure 5 .3.1-1) and the indirect network communication path (i.e., Figure 5 .3.1-1) between path #2 or path #3).
[0054] - How to ensure service continuity during these communication path switching procedures for switching between a direct network communication path and an indirect communication path and for switching between two indirect network communication paths.
[0055] NOTE 2: Support for non-unicast mode communications (i.e., one-to-many communications / broadcast or multicast) between the network and UE to network relay UE and between UE to network relay and remote UE depends on the results of FS_5MBS operation.
[0056] Regarding the UE to network relay, Figure 5 .3.1-2 shows the UE served by the gNB to the network relay and Figure 5 Two cases can be considered for the support of UE to network relay served by ng-eNB as shown in .3.1-3.
[0057] [3GPP TS 23.303 V16.0.0 entitled "UE to Network Relay Served by gNB" Figure 5 .3.1-2 reproduced as Figure 6 ]
[0058] [3GPP TS 23.303 V16.0.0 entitled "UE to Network Relay Served by ng-eNB" Figure 5 .3.1-3 reproduced as Figure 7 ]
[0059] NOTE 3: Whether support for the case where UE to network relay is served by ng-eNB depends on the solution that will be identified in this study and RAN decision.
[0060] NOTE 4: When UE-to-network relay moves to E-UTRAN, ProSe UE-to-network relay based on LTE PC5 may be supported as defined in TS 23.303 [9] for public safety.
[0061] 6.44 Solution #44: QoS treatment for layer 2 relays
[0062] 6.44.1 Description
[0063] This is a solution to key issue #3 “Support for UE to network relay”, which applies to Layer 2 UE to network relay QoS treatment.
[0064] In the layer 2UE to NW relay solution (Solution #7), the data flow of the remote UE is served by its own PDU session. The RAN understands that the PDU session is for layer 2UE to NW relay. In order to meet the QoS parameters, the RAN needs to determine the appropriate configuration on the PC5 branch and the Uu branch. In order to reduce the RAN impact, the SMF can provide some guidance to the RAN. The SMF generates the Uu QoS attribute set and the PC5 QoS attribute set, and then provides them to the RAN. The RAN will take these QoS attribute sets as principles for determining the configuration on the PC5 branch and the Uu branch. If dynamic PCC control is supported, the SMF can generate the Uu QoS attribute set and the PC5 QoS attribute set based on the PCC rules on the Uu branch and the PC5 branch provided by the PCF.
[0065] In this solution, it is assumed that the core network of the remote UE is aware that the remote UE is accessing via the UE-to-network relay.
[0066] NOTE: The details of how the configuration on the Uu and PC5 legs is determined is implemented by the RAN.
[0067] 6.44.2 Procedure
[0068] [3GPP TS 23.303 V16.0.0 entitled "QoS treatment for layer 2 relay" Figure 6 .44.2-1 Reappears as Figure 8 ]
[0069] 0. It is assumed that there is an indirect communication link for the remote UE via UE to network relay based on layer 2 relay.
[0070] 1. During the PDU session establishment or modification procedure, if dynamic PCC control is supported, the PCF generates PCC rules on the Uu branch and PC5 branch based on the operator policy and the rates on Uu and PC5, and then sends them to the SMF in the SM policy association establishment or SM policy association modification procedure.
[0071] 2. The SMF generates the corresponding Uu QoS attribute set and PC5 QoS attribute set based on the received PCC rules on the Uu branch and PC5 branch.
[0072] 3.SMF sends the corresponding Uu QoS attribute set and PC5 QoS attribute set to RAN.
[0073] 4. RAN issues configuration on the Uu branch and PC5 branch based on the Uu QoS attribute set and PC5 QoS attribute set provided by SMF.
[0074] 6.44.3 Impact on Services, Entities, and Interfaces
[0075] PCF:
[0076] - Generate PCC rules on Uu and PC5 (for QoS control on Uu and PC5).
[0077] SMF:
[0078] - Generate QoS attribute sets on Uu and PC5 (for QoS control on Uu and PC5).
[0079] RAN:
[0080] - Perform configuration on Uu and PC5 based on the QoS attribute set provided by SMF.
[0081] 3GPP TS 23.502 specifies the Protocol Data Unit (PDU) Session Establishment Procedure for the UE to establish a new PDU session with the network as follows:
[0082] 4.3.2 PDU Session Establishment
[0083] 4.3.2.1 General
[0084] PDU Session Establishment may correspond to:
[0085] -PDU session establishment procedure initiated by UE.
[0086] - UE initiated PDU session handover between 3GPP and non-3GPP.
[0087] - UE initiated PDU session handover from EPS to 5GS.
[0088] -PDU session establishment procedure triggered by the network. In this case, the network sends a device trigger message to the application on the UE side. The payload contained in the device trigger request message contains information that the application on the UE side is expected to trigger the PDU session establishment request. Based on the information, the application on the UE side triggers the PDU session establishment procedure. For more details, refer to section 4.13.2.
[0089] If the UE is simultaneously registered to a non-3GPP access via an N3IWF / TNGF / W-AGF located in a PLMN different from the PLMN for the 3GPP access, the functional entities in the following procedures are located in the accessed PLMN used to exchange NAS with the UE for the PDU session.
[0090] As specified in TS 23.501 [2] section 5.6.1, a PDU session can be (a) associated with a single access type at a given time, i.e., 3GPP access or non-3GPP access, or (b) associated with multiple access types simultaneously, i.e., one 3GPP access and one non-3GPP access. A PDU session associated with multiple access types is called a Multi-Access PDU (MA-PDU) session and it can be requested by a UE supporting ASSS.
[0091] Section 4.3.2.2 below specifies the procedures for establishing a PDU Session that is associated with a single Access Type at a given time. Specific procedures associated with MA PDU Sessions are specified in Section 4.22 as part of the ATSSS procedures.
[0092] 4.3.2.2 UE-requested PDU session establishment
[0093] 4.3.2.2.1 Non-roaming and roaming with local interruption
[0094] Section 4.3.2.2.1 specifies PDU Session establishment for non-roaming and roaming with local breakout conditions. The procedures are used to:
[0095] - establish a new PDU session;
[0096] - Handover of a PDN connection in EPS to a PDU session in 5GS without using the N26 interface;
[0097] - Switching an existing PDU Session between a non-3GPP access and a 3GPP access. The specific system behavior in this case is further defined in Section 4.9.2; or
[0098] -Request a PDU session for emergency services.
[0099] […]
[0100] 3GPP TS 38.331 specifies signaling radio bearers, RRC connection establishment, RRC reconfiguration and sidelink UE information procedures as follows:
[0101] 4.2.2 Signalling Radio Bearer
[0102] A "Signaling Radio Bearer" (SRB) is defined as a Radio Bearer (RB) used only for transmitting RRC and NAS messages.
[0103] More precisely, the following SRBs are defined:
[0104] -SRB0 is used for RRC messages using CCCH logical channel;
[0105] -SRB1 is used for RRC messages (which may include piggybacked NAS messages) and NAS messages before establishing SRB2, all of which use the DCCH logical channel;
[0106] -SRB2 is used for NAS messages and for RRC messages containing logged measurement information, all of which use the DCCH logical channel. SRB2 has a lower priority than SRB1 and can be configured by the network after AS security activation;
[0107] -SRB3 is used for specific RRC messages when the UE is in (NG)EN-DC or NR-DC, all of which use the DCCH logical channel.
[0108] In the downlink, piggybacking of NAS messages is used only for one related (ie, with joint success / failure) procedure: bearer establishment / modification / release. In the uplink, piggybacking of NAS messages is used only for the transfer of initial NAS messages during connection setup and connection recovery.
[0109] Note 1: The NAS message delivered via SRB2 is also included in the RRC message, however, the RRC message does not contain any RRC protocol control information.
[0110] Once AS security is activated, all RRC messages on SRB1, SRB2 and SRB3, including those containing NAS messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to NAS messages, see TS 24.501
[23] .
[0111] Split SRB is supported for all MR-DC options for SRB1 and SRB2 (split SRB is not supported for SRB0 and SRB3).
[0112] For operation with shared spectrum channel access, SRB0, SRB1, and SRB3 are assigned the highest priority channel access priority class (CAPC), (ie, CAPC=1), while the CAPC for SRB2 is configurable.
[0113] […]
[0114] 5.3.3 RRC Connection Establishment
[0115] 5.3.3.1 General
[0116] [3GPP 38.331 V16.1.0 entitled "RRC Connection Establishment, Success" Figure 5 .3.3.1-1 Reproduced as Fig. 9 ]
[0117] […]
[0118] The purpose of this procedure is to establish an RRC connection. The RRC connection establishment involves SRB1 establishment. The procedure is also used to transfer initial NAS dedicated information / messages from the UE to the network.
[0119] For example, the following network applications:
[0120] -When an RRC connection is established;
[0121] - When the UE is resuming or re-establishing an RRC connection and the network is unable to retrieve or verify the UE context. In this case, the UE receives RRCSetup and responds with RRCSetupComplete.
[0122] […]
[0123] 5.3.5RRC Reconfiguration
[0124] 5.3.5.1 General
[0125] [3GPP 38.331 V16.1.0 entitled "RRC reconfiguration, success" Figure 5 .3.5.1-1 Reproduced as Fig.10 ]
[0126] […]
[0127] The purpose of this procedure is to modify the RRC connection, such as establish / modify / release RB, 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 configuration. As part of the procedure, NAS specific information may be transferred from the network to the UE.
[0128] […]
[0129] 5.3.5.2 Initiation
[0130] The network may initiate an RRC connection reconfiguration procedure to the UE in RRC_CONNECTED. The network applies the following procedure:
[0131] - Establishment of RBs is performed only when AS security has been activated (not SRB1, which is established during RRC connection establishment);
[0132] - Addition of secondary cell groups and SCells is performed only when AS security has been activated;
[0133] - reconfigurationWithSync is included in secondaryCellGroup only if at least one RLC bearer is set up in the SCG;
[0134] - reconfigurationWithSync is included in the masterCellGroup only if AS security has been activated, and SRB2 with at least one DRB or SRB2 for IAB is set and not suspended;
[0135] -ConditionalReconfiguration for CPC is included only if at least one RLC bearer is set up in the SCG;
[0136] -Contains conditionalReconfiguration for CHO only if AS security has been activated, and SRB2 with at least one DRB or SRB2 for IAB is set up and not suspended.
[0137] […]
[0138] 5.8.3 Sidelink UE Information for NR Sidelink Communications
[0139] 5.8.3.1 General
[0140] [3GPP 38.331 V16.1.0 entitled "Sidelink UE information for NR sidelink communications" Figure 5 .8.3.1-1 Reproduced as Fig.11 ]
[0141] The purpose of this procedure is to inform the network that the UE:
[0142] - is interested or no longer interested in receiving or transmitting NR sidelink communications,
[0143] - is requesting the assignment or release of transmission resources for NR sidelink communications,
[0144] - is reporting the set of parameters and QoS attributes related to NR sidelink communications,
[0145] - Reporting that a sidelink radio link failure or sidelink RRC reconfiguration failure has been detected.
[0146] 5.8.3.2 Initiation
[0147] A UE capable of NR sidelink communication under RRC_CONNECTED may initiate a procedure to indicate that it is (interested in) receiving or transmitting NR sidelink communications in several situations, including upon successful establishment of a connection or resumption or upon a change of interest or upon a change of QoS attribute set or upon a change to a PCell providing SIB12 (including sl-ConfigCommonNR). A UE capable of NR sidelink communication may initiate a procedure to request assignment of dedicated sidelink DRB configuration and transmission resources for NR sidelink communication transmission. A UE capable of NR sidelink communication may initiate a procedure to report to the network a declared sidelink radio link failure or a sidelink RRC reconfiguration failure.
[0148] When initiating this procedure, the UE shall:
[0149] 1> If SIB12 containing sl-ConfigCommonNR is provided by PCell:
[0150] 2> Ensure that there is a valid version of SIB12 for PCell;
[0151] 2> If configured by upper layers to receive NR sidelink communications on the frequencies included in sl-FreqInfoList in SIB12 of PCell:
[0152] 3> if the UE has not transmitted a SidelinkUEInformationNR message since the last time it entered the RRC_CONNECTED state; or
[0153] 3> if, since the last time the UE transmitted a SidelinkUEInformationNR message, the UE has been connected to a PCell that does not provide SIB12 containing sl-ConfigCommonNR; or
[0154] 3> If the last transmission of the SidelinkUEInformationNR message did not contain sl-RxInterestedFreqList; or if the frequency configured by upper layers to receive NR sidelink communications has changed since the last transmission of the SidelinkUEInformationNR message, then:
[0155] 4> According to 5.8.3.3, initiate the transmission of the SidelinkUEInformationNR message to indicate the NR sidelink communication reception frequency of interest;
[0156] 2> Otherwise:
[0157] 3> If the last transmission of the SidelinkUEInformationNR message contains sl-RxInterestedFreqList, then:
[0158] 4> According to 5.8.3.3, initiate the transmission of the SidelinkUEInformationNR message to indicate that it is no longer interested in receiving NR sidelink communications;
[0159] 2> If configured by upper layers to transmit NR sidelink communications on the frequencies in the sl-FreqInfoList contained in SIB12 of the PCell:
[0160] 3> if the UE has not transmitted a SidelinkUEInformationNR message since the last time it entered the RRC_CONNECTED state; or
[0161] 3> if, since the last time the UE transmitted a SidelinkUEInformationNR message, the UE has been connected to a PCell that does not provide SIB12 containing sl-ConfigCommonNR; or
[0162] 3> If the last transmission of the SidelinkUEInformationNR message did not contain sl-TxResourceReqList; or if the information carried by sl-TxResourceReqList has changed since the last transmission of the SidelinkUEInformationNR message, then:
[0163] 4> According to 5.8.3.3, initiate the transmission of the SidelinkUEInformationNR message to indicate the NR sidelink communication transmission resources required by the UE;
[0164] 2> Otherwise:
[0165] 3> If the last transmission of the SidelinkUEInformationNR message contains sl-TxResourceReqList:
[0166] 4> According to 5.8.3.3, initiate the transmission of the SidelinkUEInformationNR message to indicate that it no longer requires NR sidelink communication transmission resources.
[0167] 5.8.3.3 Actions related to the transmission of SidelinkUEInformationNR message
[0168] The UE shall set the content of the SidelinkUEInformationNR message as follows:
[0169] 1> If the UE initiates a procedure to indicate that it is (no longer) interested in receiving NR sidelink communications or to request (configuration / release) of NR sidelink communication transport resources or to report to the network that a sidelink radio link failure or sidelink RRC reconfiguration failure has been declared (i.e. the UE contains all relevant information regardless of who triggered the procedure), then:
[0170] 2> If SIB12 containing sl-ConfigCommonNR is provided by PCell:
[0171] 3> If configured by upper layers to receive NR sidelink communications:
[0172] 4> Include sl-RxInterestedFreqList and set it to the frequency used for NR sidelink communication reception;
[0173] 3> If configured by upper layers to transmit NR sidelink communications:
[0174] 4> Contains sl-TxResourceReqList and sets its fields (if necessary) as follows for each destination requesting the network to assign NR sidelink communication resources:
[0175] 5> Set sl-DestinationIdentity to the destination identity configured by the upper layer for NR sidelink communication transmission;
[0176] 5> set sl-CastType to the cast type of the associated destination identifier configured by upper layers for NR sidelink communication transmission;
[0177] 5> If the associated bidirectional sidelink DRB has been established due to the configuration of RRCReconfigurationSidelink, then sl-RLC-ModeIndication is set to the QoS attribute set of the sidelink QoS flow containing the RLC mode and optionally the associated RLC mode;
[0178] 5> Set sl-QoS-InfoList to contain the set of QoS attributes of the sidelink QoS flows of the associated destination configured by upper layers for NR sidelink communication transmission;
[0179] 5> Set sl-InterestedFreqList to indicate the frequencies used for NR sidelink communication transmissions;
[0180] 5> Set sl-TypeTxSyncList to the current synchronization reference type used on the associated sl-InterestedFreqList for NR sidelink communication transmissions.
[0181] 5> Set sl-CapabilityInformationSidelink to contain the UECapabilityInformationSidelink message received from the peer UE (if any).
[0182] 4> Contains sl-FailureList and sets its fields as follows for each destination for which an NR side link communication failure is reported:
[0183] 5> Set sl-DestinationIdentity to the destination identity configured by the upper layer for NR sidelink communication transmission;
[0184] 5> If a sidelink RLF is detected as specified in subsection 5.8.9.3, sl-Failure shall be set to rlf for the associated destination for NR sidelink communication transmission;
[0185] 5> If RRCReconfigurationFailureSidelink is received, then sl-Failure is set to configFailure for the associated destination for the NR sidelink communication transmission;
[0186] 1> If the UE initiates the procedure when connected to the E-UTRA PCell, then:
[0187] 2> Submit SidelinkUEInformationNR to the lower layer via SRB1, which is embedded in the LTE RRC message ULInformationTransferIRAT as specified in TS 36.331
[10] section 5.6.x;
[0188] 1> Otherwise:
[0189] 2> Submit the SidelinkUEInformationNR message to the lower layer for transmission.
[0190] …
[0191] -RRCReconfiguration
[0192] The RRCReconfiguration message is a command to modify the RRC connection. It can deliver information for measurement configuration, mobility control, radio resource configuration (including RB, MAC primary configuration and physical channel configuration) and AS security configuration.
[0193] RRCReconfiguration message
[0194] …
[0195]
[0196]
[0197] SL-ConfigDedicatedNR
[0198] IE SL-ConfigDedicatedNR specifies dedicated configuration information for NR side link communication.
[0199] SL-ConfigDedicatedNR Information Element
[0200]
[0201]
[0202]
[0203] The SidelinkUEInformationNR message is used to indicate the NR sidelink UE information to the network.
[0204]
[0205]
[0206]
[0207] According to the normal RRC connection establishment procedure specified in 3GPP TS 38.331, an RRCSetupRequest message is transmitted by the UE to the gNB on SRB0. In response to the reception of the RRCSetupRequest message, the gNB will transmit an RRCSetup message on SRB0 to the UE to establish SRB1. The UE then replies with an RRCSetupComplete message on SRB1. The RRCSetup message contains the IE RadioBearerConfig associated with SRB1, while the IE RLC-BearerConfig associated with SRB1 is contained in the preset SRB configuration predefined in 3GPP TS 38.331. SRB2 and SRB3 can be established via the RRC reconfiguration procedure after AS security has been activated.
[0208] 3GPP R2-200847 gives an overview of the research on UE to network relay, focusing on the solution of L2 UE to network relay. Figure 2 (not shown in this application) describes the protocol stack for L2 UE to network relay. Basically, there are two branches in the protocol stack, namely the PC5 (or SL) branch between the remote UE and the relay UE and the Uu branch between the relay UE and the gNB. Regarding the signaling radio bearer (SRB) and data radio bearer (DRB) configuration, 3GPP R2-2008047 proposes the following:
[0209] Proposal 3: Uu SRB0, PC5 and related RLC bearer parameters on the Uu link for remote UEs are predefined by the specification.
[0210] Proposal 4: Related PDCP and RLC bearer parameters on Uu SRB1 and Uu SRB2, PC5 and Uu links for remote UEs can be configured by the gNB.
[0211] Proposal 5: For Uu DRBs of remote UEs, PC5 and related Uu SDAP, Uu PDCP and RLC bearer parameters on the Uu link can be configured by the gNB.
[0212] Regarding bearer mapping at remote UE and relay UE (in 3GPP R2-2008047 Figure 3 (not shown in this application), 3GPP R2-2008047 proposes the following:
[0213] Proposal 6: For remote UEs, only one-to-one mapping between Uu PDCP entity and SL RLC bearer is supported.
[0214] Proposal 7: For relay UEs, support 1-to-1 mapping and N-to-1 mapping between SL RLC bearers and Uu RLC bearers.
[0215] Proposal 8: In L2 UE to network relay, all bearer / LCH mappings at the remote UE and relay UE are configured by the gNB.
[0216] Below is an example of how the gNB can configure the bearer mapping:
[0217] - In case of N:1 mapping, the bearer ID identifying the remote UE’s Uu DRB may be added in the adaptation layer header for bearer mapping at the relay UE and gNB.
[0218] - At the remote UE, the mapping table between Uu DRB ID to SL RLC ID is configured by the gNB.
[0219] - At the relay UE, the following mapping tables may be configured by the gNB: 1) SL RLC ID to Uu RLC ID for UL; 2) Bearer ID in the adaptation header to SL RLC ID for DL.
[0220] However, it is also possible to support N-to-1 mapping between Uu Packet Data Convergence Protocol (PDCP) entity and SL RLC bearers for remote UEs. In this case, it may also be necessary to introduce an adaptation layer between Uu PDCP and PC5 RLC in the remote UE to add and remove the bearer ID in the adaptation layer header.
[0221] About the adaptation layer (refer to 3GPP R2-2008047 Figure 3 (not shown in this application), 3GPP R2-2008047 proposes the following:
[0222] Proposal 9: No adaptation layer is required in the SL hop for UE to network relay.
[0223] Proposal 10: An adaptation layer on Uu RLC is required in the Uu hop for UE to network relay.
[0224] Proposal 11: The bearer ID of the remote UE's DRB should be added in the adaptation layer to support N:1 mapping between SL RLC bearers to Uu RLC bearers at the relay UE.
[0225] If multiple remote UEs can access the gNB via the same relay UE, a local UE identifier is required between the relay UE and the gNB to distinguish between the remote UE and the relay UE. Figure 6 (not shown in this application) shows the data routing between the remote UE and the gNB via the relay UE as follows:
[0226] Step 1: gNB knows which UE the DL data belongs to (i.e., relay UE, remote UE1 or remote UE2)
[0227] The gNB establishes higher L2 entities (i.e., Uu Service Data Adaptation Protocol (SDAP) and Uu PDCP) for DRBs for each UE sharing the same lower L2 entities (i.e., RLC and Medium Access Control (MAC)), and the gNB maintains a UE context including a local UE identifier for each UE.
[0228] When DL data arrives from a PDCP entity, the gNB knows which UE the PDCP entity belongs to. Correspondingly, the gNB is able to determine the local UE identifier to include in the adaptation layer header. The gNB then sends the PDCP PDU together with the adaptation layer header to the relay UE.
[0229] Step 2: The relay UE receives the data and determines which remote UE the data belongs to
[0230] Previously, the relay UE and the gNB have exchanged the local UE identifier, which means that the relay UE and the gNB can use it as a reference to a dedicated remote UE or relay UE. After receiving data from the gNB, the relay UE is able to interpret the adaptation layer header and get the information contained, i.e. the local UE identifier. Based on the local UE identifier, the relay UE is able to know the associated remote UE or the relay UE itself.
[0231] For uplink data transmission, the complete procedure is similar, i.e., the relay UE receives the uplink PDCP PDU from the remote UE or the relay UE itself via SL unicast. The relay UE is able to determine the local UE identifier based on the configuration previously provided by the gNB. The relay UE then adds the adaptation layer header containing the local UE identifier to the received PDCP PDU. Finally, the relay UE transmits the PDCP PDU together with the adaptation layer header to the gNB.
[0232] Therefore, the following is proposed:
[0233] Proposal 12: For UE to network L2 relay, the local identifier contained in the adaptation layer header is used for routing.
[0234] Proposal 13: The local identifier is allocated by the relay UE and uniquely identifies a remote UE within the range of the relay UE.
[0235] In addition, 3GPP R2-2008047 Figure 7 (Not shown in this application) The following describes how the remote UE establishes an RRC connection with the gNB via the relay UE:
[0236] Step 1: Relay UE Discovery
[0237] In general, we believe that the basic discovery procedures and relay UE (re)selection criteria defined in LTE can be reused.
[0238] Step 2: Unicast connection establishment
[0239] A unicast connection between the remote UE and the relay UE should be established. The details depend on SA2.
[0240] Step 2a / 2b: Unified access control
[0241] As discussed below, access control on the remote UE is supported in this procedure. The relay UE may provide the UAC parameters to the remote UE when establishing the SL unicast connection. For example, it may be transmitted as a dedicated parameter via a SL RRC message or included in SIB1 as an RRC container. After receiving the UAC parameters, the remote UE performs access control itself. If access is allowed, the remote UE triggers the RRC setup procedure with the gNB via the relay UE.
[0242] Step 3: Remote UE sends Uu RRCSetupRequest to gNB via relay UE
[0243] The remote UE transmits the RRCSetupRequest message to the relay UE so that the relay UE can relay this message to the gNB. Specifically, the remote UE can transmit the RRCSetupRequest message to the relay UE via a preset SL RLC bearer, that is, a preset SL RLC bearer should be introduced to support the transmission of SRB0 related messages, such as RRCSetupRequest, RRCSetup.
[0244] After receiving the RLC SDU encapsulating the RRCSetupRequest via the preset SL RLC bearer between the remote UEs, the relay UE is able to know that it is a new remote UE. The relay UE then allocates a local UE identifier to the remote UE and stores it together with the unicast connection ID as the context of the remote UE, the unicast connection ID being the SRC L2 ID and the DST L2 ID.
[0245] In addition, the relay UE forwards the received RRCSetupRequest message to the gNB, for example, via a preset Uu RLC bearer. Specifically, the relay UE adds an adaptation layer header containing a local UE identifier to the received RRCSetupRequest message, and then transmits the adaptation layer PDU to the gNB. A preset Uu RLC bearer is introduced to carry SRB0 related messages in Uu.
[0246] Step 4: gNB transmits the RRCSetup message to the remote UE via the relay UE
[0247] If the gNB accepts the request from the remote UE, it responds with an RRCSetup message to the remote UE via the relay UE. Specifically, the gNB adds an adaptation layer header including a local identifier to the RRC PDU and transmits this adaptation layer PDU to the relay UE.
[0248] Upon receiving the adaptation layer PDU encapsulating the RRCSetup message, the relay UE obtains the local UE identifier from the adaptation layer header and determines the linked remote UE based on the local UE identifier. The relay UE can then relay the received RRC PDU to the remote UE.
[0249] Step 5: The remote UE transmits the RRCSetupComplete message to the gNB via the relay UE
[0250] The remote UE generates a PDCP PDU encapsulating the RRCSetupComplete message and transmits this PDCP PDU to the relay UE via the sidelink unicast connection. Upon receiving the PDCP PDU encapsulating the RRCSetupComplete message, the relay UE is able to determine the associated local UE id. The relay UE then adds an adaptation layer header containing the local identifier to the PDCP PDU and sends it to the gNB.
[0251] 3GPP R2-2008047 Figure 5 The protocol stack applied in the RRCSetupComplete message transmission procedure is shown in (not shown in this application).
[0252] Step 6: Initial AS security activation procedure between remote UE and gNB
[0253] Initial AS security activation is performed between the remote UE and the gNB via the relay UE.
[0254] Step 7: RRC reconfiguration procedure between remote UE and gNB
[0255] Similarly, RRC reconfiguration is performed between the remote UE and the gNB via the relay UE.
[0256] As mentioned in 3GPP R2-2008047, upon receiving the RLC SDU encapsulating the RRCSetupRequest sent from the remote UE via the preset SL RLC bearer, the relay UE may know that it is a new remote UE. And, the relay UE assigns or allocates a local UE identifier to the remote UE and stores it in the context of the remote UE together with the unicast connection ID, i.e., the source L2 ID and the destination L2 ID. Alternatively, the local UE identifier of the remote UE may be assigned or allocated by the gNB and provided to the relay UE.
[0257] The relay UE then forwards the received RRCSetupRequest message to the gNB via the preset Uu RLC bearer. Specifically, the relay UE includes the local UE identifier (ID) in the adaptation layer header and then transmits the adaptation layer PDU encapsulating the received RRCSetupRequest message to the gNB. Upon receiving the RLC SDU encapsulating the RRCSetupRequest forwarded by the relay UE, the gNB may maintain the UE context including the local UE ID of the remote UE and the initial UE identity of the remote UE included in the RRCSetupRequest message.
[0258] After the RRC connection between the remote UE and the gNB is established, the remote UE may initiate a PDU session establishment procedure with the network to establish a PDU session. In response, the gNB may transmit a first RRCReconfiguration message to allocate Uu radio bearer configuration, SL RLC bearer configuration and / or Uu radio bearer to SL RLC bearer mapping (or association) to the remote UE. The relay UE may then forward the first RRCReconfiguration message to the remote UE based on the local UE ID included in the adaptation layer header.
[0259] At the same time, the gNB may transmit a second RRCReconfiguration message to allocate at least one of the following items to the relay UE to support the relay of the UE to the network: SL RLC bearer configuration, Uu radio bearer mapped to (or associated with) the SL RLC bearer (for UL), SL RLC bearer to Uu RLC bearer mapping (for UL), Uu radio bearer to SLRLC bearer mapping (for DL), and Uu RLC bearer configuration. For example, the Uu RLC bearer configuration may be optional because the relevant Uu RLC bearer may have established other Uu radio bearers for the same remote UE or other remote UEs. And, if the Uu radio bearer is unidirectional (i.e., UL only or DL only), then some of the items may not exist. In addition, if the same Uu radio bearer identity or Uu radio bearer configuration index is shared by both UL and DL, then one of the Uu radio bearer mapped to (or associated with) the SL RLC bearer and the Uu radio bearer to SL RLC bearer mapping may be omitted. On the other hand, because the second RRCReconfiguration message is for the relay UE, the gNB may not need to include the adaptation header for this message when transmitting this message.
[0260] Because the adaptation layer header in DL contains the local UE ID of the remote UE and the bearer ID of the Uu radio bearer used to transmit the adaptation layer PDU, the value of the bearer ID should be valid within the scope of the remote UE, which means that the same bearer ID value can be shared by multiple remote UEs connected to the relay UE. When receiving the adaptation layer PDU from the gNB, the relay UE will first determine the remote UE based on the local UE ID, and then select the SL RLC bearer to forward the corresponding adaptation layer SDU to the remote UE based on the bearer ID contained in the adaptation layer header and the Uu radio bearer to SL RLC bearer mapping configured by the gNB.
[0261] In this case, the relay UE needs to know to which remote UE the Uu radio bearer to SL RLC bearer mapping is assigned. Therefore, the second RRCReconfiguration message for allocating the Uu radio bearer to SL RLC bearer mapping to the relay UE also needs to include information indicating the remote UE associated with the Uu radio bearer to SL RLC bearer mapping. For example, the information may be the local UE ID of the remote UE. Table 1 below shows an exemplary Uu radio bearer to SL RLC bearer mapping table maintained in the relay UE of 3 remote UEs connected to the relay UE.
[0262] Table 1: Uu radio bearer to SL RLC bearer mapping table in relay UE
[0263]
[0264] In Table 1 above, an identity is used to identify a Uu radio bearer or a SL RLC bearer. An index associated with a Uu radio bearer configuration of a Uu radio bearer or a SL RLC bearer configuration of a SL RLC bearer may also be used. One possible way to indicate the mapping of a Uu radio bearer to a SL RLC bearer is to include an identity of the Uu radio bearer or an index of the Uu radio bearer configuration of the Uu radio bearer in the SL RLC bearer configuration of the SL RLC bearer. The SL RLC bearer configuration may include an identity of the Uu radio bearer and / or an index of the SL RLC bearer configuration.
[0265] A similar problem may also exist in the UL direction, where the relay UE needs to know to which remote UE the Uu radio bearer to SL RLC bearer mapping is assigned so that it can determine that the bearer ID is to be included in the adaptation layer header when receiving SDUs from the remote UE via the SL RLC bearer. Therefore, the second RRCReconfiguration message may be used to provide first information indicating that the Uu radio bearer to SL RLC bearer mapping also needs to include second information indicating the remote UE associated with the first information. An identification of the Uu radio bearer or an index of the Uu radio bearer configuration of the Uu radio bearer may be included in the SL RLC bearer configuration of the SL RLC bearer to indicate that the Uu radio bearer is mapped to (or is associated with) a SL RLC bearer.
[0266] Similarly, an identity of a Uu RLC bearer or an index of a Uu RLC bearer configuration of a Uu RLC bearer may be included in the SL RLC bearer configuration of the SL RLC bearer to indicate that the SL RLC radio bearer is mapped to (or associated with) the Uu RLC bearer.
[0267] In one embodiment, the key concepts of the above solution can be described as follows:
[0268] The gNB may transmit an RRCReconfiguration message to the relay UE, wherein the RRCReconfiguration message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRCReconfiguration message further includes second information identifying a remote UE associated with the mapping. The mapping between the Uu radio bearer and the SL RLC bearer may be used for UL transmission, DL transmission, or both. It is also possible to use other RRC messages to transmit the above information.
[0269] Basically, the Uu radio bearer may be identified by a Uu radio bearer identity, and / or the SL RLC bearer may be identified by an SLRLC bearer identity or a logical channel identity (LCID). The RRCReconfiguration message may also include information indicating the SL RLC bearer configuration of the SLRLC bearer, the SL RLC bearer to Uu RLC bearer mapping, and / or the Uu RLC bearer configuration of the Uu RLC bearer. The identity of the Uu radio bearer may be included in the SL RLC bearer configuration of the SL RLC bearer to indicate the Uu radio bearer to SL RLC bearer mapping.
[0270] Given all mappings between Uu radio bearers and SL RLC bearers associated with a remote UE (multiple mappings may be provided via multiple RRCReconfiguration messages), the relay UE may determine the SL RLC bearer for forwarding the SDU corresponding to the adaptation layer PDU received from the gNB to the remote UE based on the bearer ID contained in the adaptation layer header and the local UE identifier of the remote UE. The bearer ID is an identification of the Uu radio bearer from which the data in the adaptation layer PDU originates. For UL transmissions, based on the SL RLC bearer on which the service data unit (SDU) is received, the relay UE is able to determine that the bearer ID will be included in the header of the adaptation layer PDU transmitted to the gNB when the SDU is received from the remote UE. Based on the bearer ID, the gNB may determine to which Uu PDCP entity to deliver the received SDU. From the perspective of the adaptation layer, the PDU may include the SDU and the header.
[0271] In the UE-to-network relay scenario where the relay UE supports multiple remote UEs, the gNB may transmit another RRCReconfiguration message to the relay UE to configure Uu radio bearer to SL RLC bearer mapping for other remote UEs.
[0272] Fig.12 is a flow chart 1200 for Uu radio bearer to SL RLC bearer mapping according to an exemplary embodiment from the perspective of a network node. In step 1205, the network node transmits an RRC message to a relay UE, wherein the RRC message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRC message further includes second information identifying a remote UE associated with the mapping. In step 1210, the network node transmits an adaptation layer protocol data unit (PDU) to the relay UE, wherein a header of the adaptation layer PDU includes an identification of the Uu radio bearer and a local UE identifier of the remote UE.
[0273] Return to reference Figure 3 and Figure 4, in an exemplary embodiment of a network node for Uu radio bearer to SL RLC bearer mapping. The network node 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the network node to: (i) transmit an RRC message to a relay UE, wherein the RRC message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRC message also includes second information identifying a remote UE associated with the mapping, and (ii) transmit an adaptation layer protocol data unit (PDU) to the relay UE, wherein a header of the adaptation layer PDU includes an identification of the Uu radio bearer and a local UE identifier of the remote UE. 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.
[0274] Fig.13 1300 is a flowchart for Uu radio bearer to SL RLC bearer mapping according to an exemplary embodiment from the perspective of a relay UE. In step 1305, the relay UE receives an RRC message from a network node, wherein the RRC message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRC message also includes second information identifying a remote UE associated with the mapping. In step 1310, the relay UE receives an adaptation layer protocol data unit (PDU) from the network node, wherein a header of the adaptation layer PDU includes an identification of the Uu radio bearer and a local UE identifier of the remote UE. In step 1315, the relay UE transmits a service data unit (SDU) corresponding to the adaptation layer PDU to the remote UE on the SL RLC bearer, wherein the SL RLC bearer is associated with the Uu radio bearer according to the mapping.
[0275] Return to reference Figure 3 and Figure 4, in an exemplary embodiment of a relay UE for Uu radio bearer to SL RLC bearer mapping. The network node 300 includes program code 312 stored in a memory 310. The CPU 308 can execute the program code 312 to enable the relay UE to: (i) receive an RRC message from the network node, wherein the RRC message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a SL RLC bearer, and wherein the RRC message also includes second information identifying a remote UE associated with the mapping, (ii) receive an adaptation layer PDU from the network node, wherein a header of the adaptation layer PDU includes an identification of the Uu radio bearer and a local UE identifier of the remote UE, and (iii) transmit an SDU corresponding to the adaptation layer PDU to the remote UE on the SL RLC bearer, wherein it is determined that the SL RLC bearer is associated with the Uu radio bearer based on the mapping. 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.
[0276] exist Fig.12 and Fig.13 In the context of the embodiments shown in and discussed above, a PC5 RRC connection or unicast link may be established between a relay UE and a remote UE. The RRC message may include information indicating a SL RLC bearer configuration of a SL RLC bearer, a SLRLC bearer to Uu RLC bearer mapping, and / or a Uu RLC bearer configuration of a Uu RLC bearer. An identification of the Uu radio bearer may be included in the SL RLC bearer configuration of the SL RLC bearer. The SL RLC bearer configuration may include an SLRLC bearer identification or a logical channel identification (LCID) of the SL RLC bearer, and / or an index to the SL RLC bearer configuration.
[0277] In one embodiment, the RRC message may be an RRCReconfiguration. The Uu radio bearer may be identified by a Uu radio bearer identifier, and / or the SL RLC bearer may be identified by a SL RLC bearer identifier or a logical LCID. The adaptation layer may be higher than the Uu RLC layer. The second information identifying the remote UE may be a local UE identifier of the remote UE. The local UE identifier of the remote UE may be allocated or assigned by the relay UE or the network node. The Uu radio bearer may be a data radio bearer (DRB) or a signaling radio bearer (SRB).
[0278] Various aspects of the present disclosure have been described above. It should be clear 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, by using other structures, functionality, or structures and functionality other than one or more aspects of the aspects set forth herein or different from one or more aspects of the aspects set forth herein, this device can be implemented or this method can be practiced. As an example of some of the above concepts, in some aspects, parallel channels can be established based on pulse repetition frequency. In some aspects, parallel channels can be established based on pulse position or offset. In some aspects, parallel channels can be established based on time hopping sequences. In some aspects, parallel channels can be established based on pulse repetition frequency, pulse position or offset, and time hopping sequences.
[0279] 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.
[0280] 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, which may be designed using source decoding or some other technique), and various forms of programs or design code with instructions (which may be referred to herein as "software" or "software modules" for convenience), or a combination of the two. To clearly illustrate this interchangeability of hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether this 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.
[0281] 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. An IC may include a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, electrical components, optical components, mechanical components, or any combination thereof designed to perform the functions described herein, and may execute code or instructions residing within 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. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a combination of multiple microprocessors, one or more microprocessors in combination with a DSP core, or any other such configuration.
[0282] 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 elements of the various steps in an exemplary order, but are not meant to be limited to the specific order or hierarchy presented.
[0283] 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 may 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 computer-readable storage medium known in the art. An example storage medium may be coupled to a machine such as a computer / processor (for convenience, the machine may be referred to as a "processor" in this article) so that the processor can read information (e.g., code) from the storage medium and write information to the storage medium. An example storage medium may be integrated with the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user device. In an alternative, the processor and the storage medium may reside in a user device as discrete components. In addition, in some aspects, any suitable computer program product may include a computer-readable medium, and the computer-readable medium includes a code related to one or more aspects of the present disclosure. In some aspects, a computer program product may include packaging materials.
[0284] Although the present invention has been described in conjunction with various aspects, it will be appreciated that the present invention is capable of further modification. This application is intended to cover any changes, uses or adaptations of the present invention, which generally follow the principles of the present invention and include such deviations from the present disclosure, which are within the scope of known and customary practice in the technical field to which the present invention belongs.
Claims
1. A method for mapping a Uu radio bearer to a sidelink radio link control bearer, characterized in that include: the network node transmitting a radio resource control message to a relay user equipment, wherein the radio resource control message comprises first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a sidelink radio link control bearer, and wherein the radio resource control message further comprises second information identifying a remote user equipment associated with the mapping; and The network node transmits an adaptation layer protocol data unit to the relay user equipment after transmitting the radio resource control message, wherein a header of the adaptation layer protocol data unit includes an identification of the Uu radio bearer and a local user equipment identifier of the remote user equipment.
2. The method according to claim 1, characterized in that A PC5 radio resource control connection or unicast link is established between the relay user equipment and the remote user equipment.
3. The method according to claim 1, characterized in that The radio resource control message includes information indicating a sidelink radio link control bearer configuration of the sidelink radio link control bearer, a sidelink radio link control bearer to Uu radio link control bearer mapping, and / or a Uu radio link control bearer configuration of the Uu radio link control bearer.
4. The method according to claim 1, characterized in that The Uu radio bearer is identified by the identifier of the Uu radio bearer, and / or the sidelink radio link control bearer is identified by a sidelink radio link control bearer identifier or a logical channel identifier.
5. The method according to claim 3, characterized in that: The identification of the Uu radio bearer is included in the sidelink radio link control bearer configuration of the sidelink radio link control bearer.
6. The method according to claim 3, characterized in that The sidelink radio link control bearer configuration includes a sidelink radio link control bearer identifier or a logical channel identifier of the sidelink radio link control bearer and / or an index of the sidelink radio link control bearer configuration.
7. The method according to claim 1, characterized in that An adaptation layer corresponding to the adaptation layer protocol data unit is higher than a Uu radio link control layer.
8. The method according to claim 1, characterized in that The second information identifying the remote user equipment is the local user equipment identifier of the remote user equipment.
9. The method according to claim 1, characterized in that: The local user equipment identifier of the remote user equipment is allocated or assigned by the relay user equipment or the network node.
10. A method for Uu radio bearer to sidelink radio link control bearer mapping, characterized in that, include: The relay user equipment receives a radio resource control message from a network node, wherein the radio resource control message includes first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a sidelink radio link control bearer, and wherein the radio resource control message further includes second information identifying a remote user equipment associated with the mapping, wherein the relay user equipment determines, based on the second information, that the first information is associated with the remote user equipment; After receiving the radio resource control message, the relay user equipment receives an adaptation layer protocol data unit from the network node, wherein a header of the adaptation layer protocol data unit includes an identification of the Uu radio bearer and a local user equipment identifier of the remote user equipment; as well as The relay user equipment transmits a service data unit corresponding to the adaptation layer protocol data unit to the remote user equipment over the sidelink radio link control bearer, wherein the sidelink radio link control bearer is associated with the Uu radio bearer as determined according to the mapping.
11. The method according to claim 10, characterized in that A PC5 radio resource control connection or unicast link is established between the relay user equipment and the remote user equipment.
12. The method according to claim 10, characterized in that The radio resource control message includes information indicating a sidelink radio link control bearer configuration of the sidelink radio link control bearer, a sidelink radio link control bearer to Uu radio link control bearer mapping, and / or a Uu radio link control bearer configuration of the Uu radio link control bearer.
13. The method according to claim 10, characterized in that The Uu radio bearer is identified by the identifier of the Uu radio bearer, and / or the sidelink radio link control bearer is identified by a sidelink radio link control bearer identifier or a logical channel identifier.
14. The method according to claim 12, characterized in that The identification of the Uu radio bearer is included in the sidelink radio link control bearer configuration of the sidelink radio link control bearer.
15. The method according to claim 12, characterized in that The sidelink radio link control bearer configuration includes a sidelink radio link control bearer identifier or a logical channel identifier of the sidelink radio link control bearer and / or an index of the sidelink radio link control bearer configuration.
16. The method according to claim 10, characterized in that An adaptation layer corresponding to the adaptation layer protocol data unit is higher than a Uu radio link control layer.
17. The method according to claim 10, characterized in that The second information identifying the remote user equipment is the local user equipment identifier of the remote user equipment.
18. The method according to claim 10, characterized in that The local user equipment identifier of the remote user equipment is allocated or assigned by the relay user equipment or the network node.
19. The method according to claim 10, characterized in that The Uu radio bearer is a data radio bearer or a signalling radio bearer.
20. A relay user equipment for Uu radio bearer to sidelink radio link control bearer mapping, characterized in that, include: Control circuit; a processor installed in the control circuit; as well as a memory installed in the control circuit and operatively coupled to the processor; The processor is configured to execute the program code stored in the memory to perform the following operations: receiving a radio resource control message from a network node, wherein the radio resource control message comprises first information indicating a mapping, the mapping representing an association between a Uu radio bearer and a sidelink radio link control bearer, and wherein the radio resource control message further comprises second information identifying a remote user equipment associated with the mapping; determining, according to the second information, that the first information is associated with the remote user equipment; receiving, after receiving the radio resource control message, an adaptation layer protocol data unit from the network node, wherein a header of the adaptation layer protocol data unit comprises an identification of the Uu radio bearer and a local user equipment identifier of the remote user equipment; as well as A service data unit corresponding to the adaptation layer protocol data unit is transmitted to the remote user equipment over the sidelink radio link control bearer, wherein the sidelink radio link control bearer is determined to be associated with the Uu radio bearer according to the mapping.