CN113891292B

CN113891292B - Method and apparatus for establishing side link radio bearers for inter-UE relay communication in a wireless communication system

Info

Publication number: CN113891292B
Application number: CN202110705756.6A
Authority: CN
Inventors: 潘立德; 曾立至; 郭豊旗
Original assignee: Asustek Computer Inc
Current assignee: Asustek Computer Inc
Priority date: 2020-07-01
Filing date: 2021-06-24
Publication date: 2024-01-12
Anticipated expiration: 2041-06-24
Also published as: KR20230054640A; US20220007445A1; KR20220003456A; KR20240018552A; CN113891292A; US11871465B2

Abstract

The invention provides a method and equipment for establishing a side link radio bearer for relay communication between UE (user equipment) in a wireless communication system. In one embodiment, the method includes a first remote user equipment establishing a first sidelink data radio bearer for transmission to a second remote user equipment via a relay user equipment, wherein the first sidelink data radio bearer is identified by a radio bearer identification. The method further includes the first remote user equipment encrypting a side link packet to be sent to the second remote user equipment on the first side link data radio bearer based at least on the radio bearer identification.

Description

Method and apparatus for establishing side link radio bearers for inter-UE relay communication in a wireless communication system

Cross Reference to Related Applications

The present application claims the benefit of U.S. provisional patent application Ser. No. 63/046,901, filed on even 1 at 7/2020, U.S. provisional patent application Ser. No. 63/057,138, filed on even 27/2020, U.S. provisional patent application Ser. No. 63/173,061, filed on even 9/2021, the entire disclosure of which is incorporated herein by reference in its entirety.

Technical Field

The present disclosure relates generally to wireless communication networks and, more particularly, to methods and apparatus for establishing side-link radio bearers for inter-user equipment relay (UE-to-UE relay) communications in a wireless communication system.

Background

With the rapid increase in demand for large amounts of data to and from mobile communication devices, conventional mobile voice communication networks evolve into networks that communicate with internet protocol (Internet Protocol, IP) data packets. Such IP packet communications may provide voice over IP, multimedia, multicast, and on-demand communication services for users of mobile communication devices.

An exemplary network structure is the evolved universal terrestrial radio access network (E-UTRAN). The E-UTRAN system may provide high data throughput for implementing the above-described IP-bearing voice and multimedia services. Currently, the 3GPP standards organization is discussing new next generation (e.g., 5G) radio technologies. Thus, changes to the current body of the 3GPP standard are currently being submitted and considered to evolve and complete the 3GPP standard.

Disclosure of Invention

A method and apparatus are disclosed from the perspective of a first remote User Equipment (UE). In one embodiment, the method includes a first remote UE establishing a first Side Link (SL) Data Radio Bearer (DRB) for transmission via a relay UE to a second remote UE, wherein the first SL DRB is identified by a Radio Bearer (RB) Identification (ID). The method further includes the first remote UE encrypting a side link packet to be sent to the second remote UE on the first SL DRB based at least on the RB ID.

Drawings

Fig. 1 shows a diagram of a wireless communication system according to an example embodiment.

Fig. 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 example embodiment.

Fig. 3 is a functional block diagram of a communication system according to an exemplary embodiment.

FIG. 4 is a functional block diagram of the program code of FIG. 3 according to one exemplary embodiment.

Fig. 5 is a reproduction of fig. 6.1.2.6.2 of 3gpp C1-202875.

Fig. 6 is a reproduction of fig. 6.1.2.7.2 of 3gpp C1-202875.

Fig. 7 is a reproduction of fig. 5.2.1.4-1 of 3GPP 23.287 V16.4.0.

Fig. 8 is a reproduction of fig. 6.3.3.1-1 of 3GPP 23.287 V16.4.0.

Fig. 9 is a reproduction of fig. 5.8.9.1.1-1 of 3GPP TS 38.331 V16.4.1.

Fig. 10 is a reproduction of fig. 6.8.2.1-1 of 3GPP TR 23.752 V2.0.0.

Fig. 11 is a reproduction of fig. 6.8.2.2-1 of 3GPP TR 23.752 V2.0.0.

Fig. 12 is a reproduction of fig. 6.9.2.1.1-1 of 3GPP TR 23.752 V2.0.0.

Fig. 13 is a reproduction of fig. 6.9.2.1.2-1 of 3GPP TR 23.752 V2.0.0.

Fig. 14 is a reproduction of fig. 6.9.2.1.2-1 of 3GPP TR 23.752 V2.0.0.

Fig. 15 is a reproduction of fig. 5.1-1 of 3GPP TR 38.836 V17.0.0.

Fig. 16 is a reproduction of fig. 5.2-1 of 3GPP TR 38.836 V17.0.0.

Fig. 17 is a reproduction of fig. 5.5.1-1 of 3GPP TR 38.836 V17.0.0.

Fig. 18 is a reproduction of fig. 5.5.1-2 of 3GPP TR 38.836 V17.0.0.

Fig. 19 illustrates an example of a user plane protocol stack for inter-user equipment (inter-UE) relay communication in accordance with an example embodiment.

Fig. 20 illustrates an example of a control plane protocol stack for inter-UE relay communication according to an example embodiment.

Fig. 21 illustrates an example of a control plane protocol stack for inter-UE relay communication according to an example embodiment.

FIG. 22 is a flowchart in accordance with an exemplary embodiment.

FIG. 23 is a flowchart in accordance with an exemplary embodiment.

FIG. 24 is a flowchart in accordance with an exemplary embodiment.

FIG. 25 is a flowchart in accordance with an exemplary embodiment.

FIG. 26 is a flowchart in accordance with an exemplary embodiment.

FIG. 27 is a flowchart in accordance with an exemplary embodiment.

FIG. 28 is a flowchart in accordance with an exemplary embodiment.

Fig. 29 is a flowchart in accordance with an exemplary embodiment.

FIG. 30 is a flowchart in accordance with an exemplary embodiment.

Detailed Description

The exemplary wireless communication systems and apparatus described below employ wireless communication systems that support broadcast services. Wireless communication systems are widely deployed to provide various types of communication such as voice, data, and so on. These systems may be based on code division multiple access (code division multiple access, CDMA), time division multiple access (time division multiple access, TDMA), orthogonal frequency division multiple access (orthogonal frequency division multiple access, OFDMA), 3GPP long term evolution (Long Term Evolution, LTE) Radio access, 3GPP long term evolution-advanced (Long Term Evolution Advanced, LTE-a or LTE-advanced), 3GPP2 ultra mobile broadband (Ultra Mobile Broadband, UMB), wiMax, 3GPP New Radio (NR), or some other modulation technique.

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 an association named "third generation partnership project" (referred to herein as 3 GPP), including: TS23.287V16.4.0, "architecture enhancement (release 16) of 5G system (5 GS) for supporting vehicle-to-everything (V2X) services"; c1-202875, "PC5 unicast Link Security establishment", high-pass company; TS 24.587V16.0.0, "vehicle-to-everything (V2X) service in 5G System (5 GS); stage 3 (version 16) "; TS 38.331V16.4.1, "NR; radio Resource Control (RRC) protocol specification (release 16) "; TS 38.300V16.1.0, "Radio Resource Control (RRC) protocol specification; stage 2 (version 16) "; TR 23.752V2.0.0, "study of system enhancements for proximity-based services (ProSe) in 5G system (5 GS) (release 17)"; TS 38.323V16.2.0, "Packet Data Convergence Protocol (PDCP) specification (release 16)"; and TR 38.836V17.0.0, "with respect to NR side link relay; (version 17) ". The standards and documents listed above are expressly incorporated herein by reference in their entirety.

Fig. 1 illustrates a multiple access wireless communication system according to one embodiment of the present invention. Access network 100 (AN) includes multiple antenna groups, one including antennas 104 and 106, another including antennas 108 and 110, and a further including antennas 112 and 114. In fig. 1, only two antennas are shown for each antenna group, but more or fewer antennas may be utilized for each antenna group. Access terminal 116 (AT) is in communication with antennas 112 and 114, where antennas 112 and 114 transmit information to access terminal 116 over forward link 120 and receive information from access terminal 116 over reverse link 118. An Access Terminal (AT) 122 is in communication with antennas 106 and 108, where antennas 106 and 108 transmit information to Access Terminal (AT) 122 over forward link 126 and receive information from Access Terminal (AT) 122 over 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 that used by reverse link 118.

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

In communication via forward links 120 and 126, the transmit antennas of access network 100 may utilize beamforming in order to improve signal-to-noise ratio of forward links for the different access terminals 116 and 122. Also, an access network that uses beamforming to transmit to access terminals scattered randomly through the coverage of the access network typically causes less interference to access terminals in neighboring cells than an access network that transmits through a single antenna to all its access terminals.

AN Access Network (AN) may be a fixed station or base station used for communicating with the terminals 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 terminology. 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 terminology.

Fig. 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.

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.

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. The data rate, coding, and modulation for each data stream may be determined by execution of instructions in memory 232 by processor 230.

The modulation symbols for all data streams are then provided to a TX MIMO processor 220, which TX MIMO processor 220 may further process the modulation symbols (e.g., for OFDM). TX MIMO processor 220 then applies N _T Providing the modulated symbol streams 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.

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 over the MIMO channel. Then respectively from N _T The antennas 224a through 224t transmit N from the transmitters 222a through 222t _T And modulated signals.

At the receiver system 250, the signal is represented by N _R Each antenna 252 a-252 r receives the transmitted modulated signals and provides the received signal from each antenna 252 to a respective receiver (RCVR) 254 a-254 r. 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.

RX data processor 260 then proceeds to process the data from N based on a particular receiver _R The N is received and processed by a plurality of receivers 254 _R Receiving a symbol stream to provide N _T A "detected" symbol stream. RX data processor 260 then performs, for eachThe detected symbol stream is demodulated, deinterleaved, and decoded to recover the traffic data for the data stream. The processing by RX processor 260 is complementary to that performed by TX MIMO processor 220 and TX data processor 214 at transmitter system 210.

The processor 270 executes instructions in the 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.

The reverse link message may comprise various types of information regarding the communication link and/or the received data stream. The reverse link message is then processed by a TX data processor 238 (which TX data processor 238 also receives traffic data for a number of data streams from a data source 236), modulated by a modulator 280, conditioned by transmitters 254a through 254r, and transmitted back to transmitter system 210.

At transmitter system 210, the modulated signals from receiver system 250 are received by antennas 224, conditioned by receivers 222, demodulated by a demodulator 240, and processed by a RX data processor 242 to extract the reverse link message transmitted by receiver system 250. Processor 230 then determines which pre-coding matrix to use to determine the beamforming weights and then processes the extracted message.

Turning to fig. 3, this figure shows an alternative simplified functional block diagram of a communication device in accordance with one embodiment of the present invention. As shown in fig. 3, the UEs (or ATs) 116 and 122 in fig. 1 or the base station (AN) 100 in fig. 1 may be implemented with a communication apparatus 300 in a wireless communication system, and the wireless communication system is preferably AN LTE system or 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 (central processing unit, CPU) 308, a memory 310, program code 312, and a transceiver 314. The control circuit 306 executes the program code 312 in the memory 310 via the CPU 308, thereby controlling the operation of the communication device 300. The communication device 300 may receive signals input by a user through an input device 302 (e.g., a keyboard or keypad) and may output images and sounds through an output device 304 (e.g., a display or speaker). The transceiver 314 is used to receive and transmit wireless signals to pass the received signals to the control circuit 306 and to wirelessly output signals generated by the control circuit 306. The AN 100 of fig. 1 may also be implemented with a communication device 300 in a wireless communication system.

Fig. 4 is a simplified block diagram of the program code 312 shown in fig. 3 according to one embodiment of the invention. In this embodiment, program code 312 includes an application layer 400, a layer 3 portion 402, and a layer 2 portion 404, and is coupled to a layer 1 portion 406. Layer 3 portion 402 generally performs radio resource control. Layer 2 portion 404 generally performs link control. Layer 1 portion 406 typically performs physical connections.

3GPP C1-202875 describes a security setup procedure for PC5 unicast communications as follows:

6.1.2.6 PC5 unicast link authentication procedure

6.1.2.6.1 overview

The PC5 unicast link authentication procedure is used to perform mutual authentication of UEs that establish a PC5 unicast link and derive a new K shared between two UEs during the PC5 unicast link establishment procedure or the PC5 unicast link key update procedure _NRP . After successful completion of the PC5 unicast link authentication procedure, the new K _NRP Security setup during security mode control procedure for PC5 unicast link, as specified in section 6.1.2.7. The UE that sends the direct link authentication request message is referred to as an "originating UE" and the other UE is referred to as a "target UE".

6.1.2.6.2 initiated by the PC5 unicast link authentication procedure by the initiating UE

The initiating UE should satisfy one of the following preconditions before initiating the PC5 unicast link authentication procedure:

a) The target UE has initiated the PC5 unicast link setup procedure towards the initiating UE by sending a direct link setup request message:

1) Direct link setup request message:

1) A target user information IE containing an application layer ID of the initiating UE; or (b)

2) Does not contain the target user information IE and the initiating UE is interested in the V2X service identified by the V2X service identifier in the direct link setup request message; and is also provided with

2)K _NRP The ID is not included in the direct link setup request message, or the initiating UE does not have K for inclusion in the direct link setup request message _NRP Existing K of ID _NRP Or initiate UE hopes to derive new K _NRP The method comprises the steps of carrying out a first treatment on the surface of the Or (b)

b) The target UE has initiated the PC5 unicast link key update procedure towards the initiating UE by sending a direct link key update request message, and the direct link request message includes a re-authentication indication.

To initiate the PC5 unicast link authentication procedure, the initiating UE will generate a direct link authentication request message. In this message, the initiating UE:

a) Will contain a key establishment information container.

Note that: the key establishment information container is provided by an upper layer.

After generating the direct link authentication request message, the initiating UE passes this message to the lower layer for transmission, to the layer 2ID of the initiating UE for unicast communication, and to the layer 2ID of the target UE for unicast communication.

The initiating UE will start a timer T5aaa. While the timer T5aaa is running, the UE will not send a new direct link authentication request message to the same target UE.

Fig. 6.1.2.6.2 entitled "PC5 unicast link authentication procedure" in 3gpp C1-202875 is reproduced as fig. 5]

6.1.2.6.3 PC5 unicast link authentication procedure accepted by target UE

After receiving the direct link authentication request message, if the target UE determines that the direct link authentication request message can be accepted, the target UE will generate a direct link authentication response message. In this message, the target UE:

a) Will contain a key establishment information container.

After generating the direct link authentication response message, the target UE passes this message to the lower layer for transmission, to the layer 2ID of the target UE for unicast communication, and to the layer 2ID of the initiating UE for unicast communication.

6.1.2.6.4 completion of PC5 unicast link authentication procedure by initiating UE

After receiving the direct link authentication response message, the initiating UE will stop the timer T5aaa.

Note that: initiating UE derives new K during PC5 unicast link authentication procedure _NRP Depending on the authentication method used.

[...]

6.1.2.7 PC5 unicast link security mode control program

6.1.2.7.1 overview

The PC5 unicast link security mode control procedure is used to establish security between two UEs during the PC5 unicast link establishment procedure or the PC5 unicast link key update procedure. After successful completion of the PC5 unicast link security control procedure, the selected security algorithm and key are used for integrity protection and encryption of all PC5 signaling messages exchanged between UEs, and the security context may be used to protect all PC5 user plane data exchanged between UEs. The UE that sends the direct link security mode command message is referred to as the "initiating UE" and the other UE is referred to as the "target UE".

The editor annotates: whether the user plane is protected by a security association is to be studied further.

6.1.2.7.2 initiated by the PC5 unicast Link Security mode control procedure by the initiating UE

The initiating UE will meet the following precondition before initiating the PC5 unicast link security mode control procedure:

1) Direct link setup request message:

i) A target user information IE containing an application layer ID of the initiating UE; or (b)

ii) no target user information IE is contained and the initiating UE is interested in the V2X service identified by the V2X service identifier in the direct link setup request message; and is also provided with

2) The initiating UE has been based on K contained in the direct link setup request message _NRP ID identifies the existing K _NRP Or derive a new K _NRP The method comprises the steps of carrying out a first treatment on the surface of the Or (b)

b) The target UE has initiated the PC5 unicast link key update procedure towards the initiating UE by sending a direct link key update request message, and:

1) If the target UE has included a reauthentication indication in the direct link key update request message, then the initiating UE has derived a new K _NRP 。

If the initiating UE has derived a new K _NRP Then the initiating UE will generate K _NRP 16 MSBs of ID to ensure the resulting K _NRP The ID is unique in the initiating UE.

Next, the initiating UE will:

a) Generating a 128 bit nonce_2 value;

b) From K received in direct link setup request message _NRP Deriving K from Nonce_2 and Nonce_1 _NRP-sess For example 3GPP TS 33.536[yy]Is specified in (a);

c) From K _NRP-sess And the selected security algorithm derives an NR PC5 encryption key NRPEK and an NR PC5 integrity key NRPIK, e.g. 3GPP TS 33.536[yy]Is specified in (a), and

d) A direct link security mode command message is generated. In this message, the initiating UE:

1) If a new K has been derived at the initiating UE _NRP And is used for generating K _NRP The authentication method of (1) needs to send information to complete the authentication procedure, then a key establishment information container is included;

2) If a new K has been derived at the initiating UE _NRP Then will contain K _NRP MSB of ID;

3) Nonce_2, which will contain a 128-bit temporary value set to be generated by the initiating UE for the purpose of session key establishment over this PC5 unicast link;

4) Will contain the selected security algorithm;

5) The direct link establishment request message or the direct link key update request message contains the UE security capability received from the target UE; and is also provided with

6) Will contain K selected by the initiating UE _NPR-sess 8 LSBs of ID, e.g. 3GPP TS 33.536[yy]As specified in (a).

The editor annotates: if the PC5 unicast link security mode control procedure is triggered during the PC5 unicast link setup procedure, the initiating UE shall further investigate whether the UE PC5 unicast signaling security policy received from the target UE is contained in the direct link setup request message.

The initiating UE will update the request message according to the K received in the direct link establishment request message or the direct link key _NPR-sess 8 MSBs of ID and K contained in direct link security mode command message _NPR-sess The 8 LSBs of the ID form K _NPR-sess ID。

The initiating UE will not encrypt the direct link security mode command message, but will integrity protect it with the new security context.

After generating the direct link security mode command message, the initiating UE passes this message to the lower layer for transmission, to the layer 2ID of the initiating UE for unicast communication, and to the layer 2ID of the target UE for unicast communication, and starts a timer T5bbb. When the timer T5bbb is running, the UE will not send a new direct link security mode command message to the same target UE.

Fig. 6.1.2.7.2 entitled "PC5 unicast link security mode control procedure" in 3gpp C1-202875 is reproduced as fig. 6]

6.1.2.7.3 PC5 unicast Link Security mode control procedure accepted by target UE

After receiving the direct link security mode command message, if the PC5 unicast link security mode control procedure is triggered during the PC5 unicast link setup procedure, the target UE will verify the K contained in the direct link security mode command message _NPR-sess The 8 LSBs of the ID are not set to the same value as the value received from another UE in response to the direct link setup request message of the target UE.

Next, the target UE will:

a) K received from direct link security mode command message _NRP Deriving K from Nonce_1 and Nonce_2 _NRP-sess For example 3GPP TS 33.536[yy]Is specified in (a); and

b) From K _NRP-sess And the selected security algorithm derives NRPEK and NRPIK, e.g. 3GPP TS 33.536[yy ]As specified in (a).

The target UE will determine whether the direct link security mode command message can be accepted by:

a) Checking the integrity of the direct link security mode command message using NRPIK; and

b) The received UE security capability is checked as not changed compared to the value the target UE sent to the initiating UE in the direct link setup request message or the direct link key update request message.

The editor annotates: whether the target UE needs to perform a check related to the UE signaling security policy is to be further investigated.

If the target UE does not include K in the direct link setup request message _NRP ID, target UE includes reauthentication indication in direct link key update request message or initiating UE has selected to derive new K _NRP Then the target UE will derive K _NRP For example 3GPP TS 33.536[yy]As specified in (a). The target UE will select K _NRP 16 LSBs of ID to ensure the resulting K _NRP The ID is unique in the target UE. The target UE will be based on the received K _NRP MSB of ID and K selected by the same _NRP LSB of ID to form K _NRP ID, and will store a memory with K _NRP Complete K of (2) _NRP ID。

If the target UE accepts the direct link security mode command message, the target UE will generate a direct link security mode complete message. In this message, the target UE:

a) Will contain PQFI and corresponding PC5 QoS parameters;

b) If IP communication is used, then an IP address configuration IE will be included set to one of the following values:

1) "IPv6 router" if the target UE only supports IPv6 address allocation mechanism, i.e., acts as an IPv6 router; or (b)

2) "IPv6 address assignment is not supported" if IPv6 address assignment mechanism is not supported by the target UE;

c) If IP communication is used and the IP address configuration IE is set to "IPv6 address allocation is not supported," then a link local IPv6 address IE formed locally based on IETF RFC 4862[6] will be included; and

d) If a new K is derived _NRP Then will contain K _NRP 16 LSBs of the ID.

The editor annotates: whether the target UE includes its UE PC5 unicast user plane security policy in the direct link security mode completion is to be further investigated.

The target UE will update the K that it has sent in the direct link setup request message or the direct link key according to _NPR-sess 8 MSBs of ID and K received in direct link security mode command message _NPR-sess 8 LSBs of ID to form K _NPR-sess ID。

The target UE will encrypt and integrity protect the direct link security mode complete message with the new security context.

After generating the direct link security mode complete message, the target UE passes this message to the lower layer for transmission, to the layer 2ID of the target UE for unicast communication, and to the layer 2ID of the initiating UE for unicast communication.

6.1.2.7.4 is completed by the PC5 unicast link security mode control procedure by the initiating UE

After receiving the direct link security mode complete message, the initiating UE will stop timer T5bbb and check the integrity of the direct link security mode complete message. If the integrity check passes, the initiating UE will continue to trigger the procedure of the PC5 unicast link security mode control procedure.

[…]

3GPP TS 23.287 states:

5.2.1.4 unicast mode communication over PC5 reference point

Unicast communication mode is supported only by the NR based PC5 reference point. Fig. 5.2.1.4-1 shows an example of a PC5 unicast link.

[ FIG. 5.2.1.4-1 in 3GPP 23.287V16.4.0 entitled "instance of PC5 unicast Link" is reproduced as FIG. 7]

When carrying V2X communications over a PC5 unicast link, the following principles apply:

the PC5 unicast link between two UEs allows V2X communication between one or more pairs of peer V2X services among these UEs. All V2X services in the UE using the same PC5 unicast link use the same application layer ID.

Note 1: due to privacy, the application layer ID may change from time to time as described in sections 5.6.1.1 and 6.3.3.2. This does not result in re-establishment of the PC5 unicast link. The UE triggers a link identifier update procedure as specified in section 6.3.3.2.

-if one or more V2X service types are associated with at least the peer application layer IDs of a pair of PC5 unicast links, then this PC5 unicast link supports these V2X service types. For example, as shown in fig. 5.2.1.4-1, UE a and UE B have two PC5 unicast links, one between peer application layer ID 1/UE a and application layer ID 2/UE B and one between peer application layer ID 3/UE a and application layer ID 4/UE B.

And (2) injection: the source UE is not required to know whether different target application layer IDs on different PC5 unicast links belong to the same target UE.

The PC5 unicast link supports V2X communication using a single network layer protocol (e.g., IP or non-IP).

The PC5 unicast link supports per-flow QoS model as specified in section 5.4.1.

If multiple V2X service types use one PC5 unicast link, one PC5 QoS flow identified by the PFI may be associated with more than one V2X service type.

When an application layer in the UE initiates data transfer for V2X services requiring unicast communication mode through the PC5 reference point:

-if the network layer protocols of the pair of equal application layer IDs and the existing PC5 unicast link are the same as those required by the application layer in the UE for this V2X service, the UE will reuse this PC5 unicast link and modify the existing PC5 unicast link as specified in section 6.3.3.4 to add this V2X service type; otherwise

The UE will trigger the establishment of a new PC5 unicast link as specified in section 6.3.3.1.

After the PC5 unicast link is successfully established, UE a and UE B use the same pair of layer 2 IDs for subsequent PC5-S signaling message exchanges and V2X service data transfers, as specified in section 5.6.1.4. The V2X layer of the transmitting UE indicates to the AS layer whether the transmission is for a PC5-S signaling message (i.e., direct communication request/accept, link identifier update request/response/Ack, disconnect request/response, link modification request/accept, keep alive/Ack) or for V2X service data.

For each PC5 unicast link, the UE itself assigns a different PC5 link identifier that uniquely identifies the PC5 unicast link over the lifetime of the PC5 unicast link in the UE. Each PC5 unicast link is associated with a unicast link profile comprising:

-an application layer ID and a layer 2ID of UE a; and

-an application layer ID and a layer 2ID of UE B; and

-a network layer protocol used on a PC5 unicast link; and

-information about PC5 QoS flows. For each PC5 QoS flow, a PC5 QoS context and PC5 QoS rules as defined in section 5.4.1.1.3.

For privacy reasons, the application layer ID and layer 2ID may change during the lifetime of the PC5 unicast link as described in sections 5.6.1.1 and 6.3.3.2, and if so, should be updated accordingly in the unicast link profile. The UE indicates a PC5 unicast link to the V2X application layer using the PC5 link identifier, so the V2X application layer identifies the corresponding PC5 unicast link even if there is more than one unicast link associated with one V2X service type (e.g., the UE establishes multiple unicast links with multiple UEs for the same V2X service type).

After a layer 2 link modification to the established PC5 unicast link specified in section 6.3.3.4 or a layer 2 link identifier update specified in section 6.3.3.2, the unicast link profile should be updated accordingly.

Upon receiving an indication from the AS layer to release the PC5-RRC connection due to RLF, the V2X layer in the UE locally releases the PC5 unicast link associated with this PC5-RRC connection. The AS layer indicates to the V2X layer the PC5 unicast link that releases the PC5-RRC connection using the PC5 link identifier.

After the PC5 unicast link is released AS specified in section 6.3.3.3, the V2X layer of each UE for the PC5 unicast link notifies the AS layer that the PC5 unicast link has been released. The V2X layer uses the PC5 link identifier to indicate the released unicast link.

[…]

5.6.1.4 identifier for unicast mode V2X communication over PC5 reference point

For unicast mode V2X communications through the PC5 reference point, the destination layer 2ID used depends on the communicating peer. The layer 2ID of the communication peer identified by the application layer ID may be discovered during establishment of the PC5 unicast link, or known to the UE via previous V2X communication (e.g., an existing or previous unicast link to the same application layer ID), or obtained from an application layer service notification. The initial signaling for establishing the PC5 unicast link may use a known layer 2ID of the communication peer or a preset destination layer 2ID associated with a V2X service type configured for PC5 unicast link establishment, as specified in section 5.1.2.1. During the PC5 unicast link setup procedure, the layer 2ID will be exchanged and should be used for future communication between two UEs, as specified in section 6.3.3.1.

The application layer ID is associated with one or more V2X applications within the UE. If a UE has more than one application layer ID, each application layer ID of the same UE may be considered as an application layer ID of a different UE from the perspective of a peer UE.

Since the V2X application layer does not use the layer 2ID, the ue maintains a mapping between the application layer ID and the source layer 2ID for the PC5 unicast link. This allows the source layer 2ID to be changed without interrupting the V2X application.

When the application layer ID changes, if the PC5 unicast link is used for V2X communication with the changed application layer ID, the source layer 2ID of this link should be changed.

Updating the new identifier of the source UE to the peer UE for the established unicast link may cause the peer UE to change its layer 2ID and optionally IP address/prefix (if IP communication is used as defined in section 6.3.3.2) based on the privacy configuration as specified in section 5.1.2.1.

The UE may establish multiple PC5 unicast links with peer UEs and use the same or different source layer 2 IDs for these PC5 unicast links.

[…]

6.3.3 unicast mode V2X communication through PC5 reference Point

6.3.3.1 establishing a layer 2 link through a PC5 reference point

In order to perform unicast mode V2X communication through the PC5 reference point, the UE is configured with related information as described in section 5.1.2.1.

Fig. 6.3.3.1-1 shows a layer 2 link setup procedure for unicast mode of V2X communication through a PC5 reference point.

[3GPP 23.287V16.4.0, FIG. 6.3.3.1-1 entitled "layer 2 Link setup procedure" is reproduced as FIG. 8]

1. As specified in section 5.6.1.4, the UE determines the destination layer 2ID for signaling reception for PC5 unicast link establishment. As specified in section 5.1.2.1, the UE is configured with a layer 2ID of interest.

The V2X application layer in ue-1 provides application information for PC5 unicast communication. The application information contains the V2X service type and the application layer ID of the originating UE. The application information may include an application layer ID of the target UE.

The V2X application layer in UE-1 may provide V2X application requirements for this unicast communication. As specified in section 5.4.1.4, UE-1 determines PC5 QoS parameters and PFI.

If UE-1 decides to reuse the existing PC5 unicast link as specified in section 5.2.1.4, then the UE initiates the layer 2 link modification procedure as specified in section 6.3.3.4.

Ue-1 sends a direct communication request message initiating a unicast layer 2 link setup procedure. The direct communication request message includes:

-source user information: the application layer ID of the UE (i.e., the application layer ID of UE-1) is initiated.

-if the V2X application layer provides the application layer ID of the target UE in step 2, then the following information is contained:

-target user information: the application layer ID of the target UE (i.e., the application layer ID of UE-2).

-V2X service information: information about the V2X service type requesting layer 2 link establishment.

-security information: information for establishing security.

Note 1: security information and the necessary protection for source and target user information are defined in TS 33.536[26 ].

The source layer 2ID and the destination layer 2ID for transmitting the direct communication request message are determined as specified in sections 5.6.1.1 and 5.6.1.4. The destination layer 2ID may be a broadcast or unicast layer 2ID. When using the unicast layer 2ID, the target user information should be included in the direct communication request message.

The UE-1 transmits a direct communication request message via the PC5 broadcast or unicast using the source layer 2ID and the destination layer 2ID.

4. The security of UE-1 is established as follows:

4a. If the target user information is included in the direct communication request message, the target UE, UE-2, responds by establishing security with UE-1.

4b. If the target user information is not included in the direct communication request message, the UE of V2X service type interested in using notification through the PC5 unicast link with UE-1 responds by establishing security with UE-1.

And (2) injection: signaling for security procedures is defined in TS 33.536[26 ].

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

-if IP communication is used:

-IP address configuration: for IP communications, this link requires an IP address configuration, and the IP address configuration indicates one of the following values:

-an "IPv6 router", i.e. acting as an IPv6 router if the IPv6 address allocation mechanism is supported by the initiating UE; or (b)

"IPv6 address allocation not supported", if the IPv6 address allocation mechanism is not supported by the initiating UE.

-link local IPv6 address: in the case where the UE-1 does not support the IPv6IP address allocation mechanism, i.e., in the case where the IP address configuration indicates "IPv6 address allocation is not supported," a link local IPv6 address formed locally based on RFC 4862[21 ].

QoS information: information about the PC5QoS flows to be added. For each PC5QoS flow, the PFI, the corresponding PC5QoS parameters (i.e., PQI and other parameters of the conditionality, such as MFBR/GFBR, etc.), and the associated V2X service type.

As specified in 5.6.1.1 and 5.6.1.4, the source layer 2ID for the security setup procedure is determined. The destination layer 2ID is set to the source layer 2ID of the received direct communication request message.

Upon receiving the security setup procedure message, UE-1 obtains the layer 2ID of the peer UE for future communications for signaling and data traffic for this unicast link.

5. The target UE that has successfully established security with UE-1 sends a direct communication accept message to UE-1:

(UE-oriented layer 2 link establishment) if the direct communication request message contains target user information, then the target UE, i.e., UE-2, responds with a direct communication accept message if the application layer ID for UE-2 matches.

(layer 2 link establishment for V2X service) if the target user information is not included in the direct communication request message, UEs interested in using the notified V2X service respond to the request by transmitting direct communication accept messages (UE-2 and UE-4 in fig. 6.3.3.1-1).

The direct communication accept message includes:

-source user information: an application layer ID of the UE transmitting the direct communication accept message.

QoS information: information about the PC5 QoS flow requested by UE-1. For each PC5 QoS flow, the PFI, the corresponding PC5 QoS parameters (i.e., PQI and other parameters of the conditionality, such as MFBR/GFBR, etc.), and the associated V2X service type.

-if IP communication is used:

-an "IPv6 router", i.e. acting as an IPv6 router if the IPv6 address allocation mechanism is supported by the target UE; or (b)

"IPv6 address allocation is not supported" if the IPv6 address allocation mechanism is not supported by the target UE.

-link local IPv6 address: based on the link local IPv6 address formed locally by RFC 4862[21], if the target UE does not support the IPv6IP address allocation mechanism, i.e., the IP address configuration indicates "IPv6 address allocation is not supported", and UE-1 includes the link local IPv6 address in the direct communication request message. The target UE should contain a non-conflicting link local IPv6 address.

If both UEs (i.e., the initiating UE and the target UE) are selected to use the link-local IPv6 address, they will disable the dual address detection defined in RFC 4862[21 ].

And (3) injection: when the initiating UE or the target UE indicates support for the IPv6 router, the corresponding address configuration procedure will be implemented after the layer 2 link is established and the link local IPv6 address is ignored.

The V2X layer of the UE that establishes the PC5 unicast link passes down the PC5 link identifier assigned to the unicast link and information related to the PC5 unicast link to the AS layer. The information related to the PC5 unicast link contains layer 2ID information (i.e., source layer 2ID and destination layer 2 ID) and corresponding PC5 QoS parameters. This enables the AS layer to maintain PC5 link identifiers and PC5 unicast link related information.

6. V2X service data is transmitted over the established unicast link as follows:

the PC5 link identifier and PFI and V2X service data are provided to the AS layer.

In addition, layer 2ID information (i.e., source layer 2ID and destination layer 2 ID) is optionally provided to the AS layer.

And (4) injection: providing the layer 2ID information to the AS layer is implemented by the UE.

UE-1 transmits V2X service data using a source layer 2ID (i.e., layer 2ID of UE-1 for this unicast link) and a destination layer 2ID (i.e., layer 2ID of peer UE for this unicast link).

And (5) injection: the PC5 unicast link is bi-directional, so that a peer UE of UE-1 may send V2X service data to UE-1 over the unicast link with UE-1.

The 3gpp TS 38.331 describes a side chain Radio Resource Control (RRC) procedure as follows:

5.8 side links

5.8.1 overview

NR side link communication consists of unicast, multicast and broadcast. For unicast, the PC5-RRC connection is a logical connection between a pair of source layer 2ID and destination layer 2ID in the AS. PC5-RRC signaling may be initiated after its corresponding PC5 unicast link establishment (TS 23.287[55 ]), as specified in section 5.8.9. When the PC5 unicast link is released, the PC5-RRC connection and the corresponding side link SRB and side link DRB are released, as indicated by the upper layer.

For each PC5-RRC connection that is unicast, one side link SRB (i.e., SL-SRB 0) is used to transmit the PC5-S message before the PC5-S security is established. One side link SRB (i.e., SL-SRB 1) is used to transmit a PC5-S message that establishes PC5-S security. One side link SRB (i.e., SL-SRB 2) is used to transmit the protected PC5-S message after the PC5-S security is established. One side link SRB (i.e., SL-SRB 3) is used to transport PC5-RRC signaling, which is protected and sent only after PC5-S security is established.

For unicast of NR side link communication, AS security consists of integrity protection and encryption of PC5 signaling (SL-SRB 1, SL-SRB2, and SL-SRB 3) and user data (SL-DRB). The encryption and integrity protection algorithms and parameters for the PC5 unicast link are exchanged by PC5-S messages in the upper layers, AS specified in TS 33.536[60], and for the corresponding PC5-RRC connection in the AS. Once AS security is activated for the PC5 unicast link in the upper layer, AS specified in TS 33.536[60], all messages for SL-SRB2 and SL-SRB3 and/or user data for the corresponding PC5-RRC connected SL-DRB are PDCP integrity protected and/or encrypted by.

For unicast of NR side link communication, if the change of key is indicated by an upper layer, as specified in TS 24.587[57], the UE re-establishes PDCP entities of SL-SRB1, SL-SRB2, SL-SRB3 and SL-DRB on the corresponding PC5-RRC connection.

Note 1: in the case of acquiring a configuration for NR side link communication via E-UTRA, as specified in TS 36.331[10], the configurations in systemiformationblocktype 28 and sl-ConfigDedicatedNR within RRCConnectionReconfiguration provide configurations for NR side link communication in SIB12 and sl-ConfigDedicatedNR within RRCReconfiguration in section 5.8, respectively.

And (2) injection: in this version, as specified in TS 38.300[2], there is a one-to-one correspondence between PC5-RRC connections and PC5 unicast links.

And (3) injection: all SL-DRBs associated with the same PC5-RRC connection have the same activation/deactivation settings for ciphering and the same activation/deactivation settings for integrity protection as in TS 33.536[60 ].

[...]

5.8.9 side link RRC procedure

5.8.9.1 side link RRC reconfiguration

5.8.9.1.1 overview

[ FIG. 5.8.9.1.1-1 entitled "side Link RRC Reconfiguration successful" in 3GPP TS 38.331V16.4.1 is reproduced as FIG. 9]

[...]

The purpose of this procedure is to modify the PC5-RRC connection, e.g. to set up/modify/release the side link DRB, (re) configure NR side link measurements and reports, (re) configure side link CSI reference signal resources and CSI reporting delay bounds.

The UE may initiate a side link RRC reconfiguration procedure and perform the operations in section 5.8.9.1.2 on the corresponding PC5-RRC connection in the following cases:

Releasing the side link DRB associated with the peer UE as specified in section 5.8.9.1a.1;

-establishing a side link DRB associated with the peer UE, as specified in section 5.8.9.1a.2;

-modifying parameters contained in SLRB-Config of the side link DRB associated with the peer UE, as specified in section 5.8.9.1a.2;

- (re) configuring peer UEs to perform NR sidelink measurements and reporting.

Side link CSI reference signal resources and CSI reporting latency bounds are (re) configured.

In rrc_connected, the UE applies the NR side link communication parameters provided in rrcrecon configuration (if present). In rrc_idle or rrc_inactive, the UE applies NR side-link communication parameters provided in the system information (if present). For other cases, the UE applies the NR side link communication parameters provided in the sidlinkpreconfignr (if present). When the UE performs a state transition between the above three cases, the UE applies NR side link communication parameters provided in the new state after acquiring the new configuration. The UE continues to apply the NR side link communication parameters provided in the old state before acquiring the new configuration.

5.8.9.1.2 actions related to the delivery of RRCRECONfigure Sidelink messages

The UE shall set the content of the rrcrecon configuration sip link message as follows:

1> for each side link DRB to be released, according to section 5.8.9.1a.1.1, due to configuration by sl-ConfigDedicatedNR, SIB, sidlinkpreconfignr or by upper layers:

2> setting SLRB-PC5-ConfigIndex contained in SLRB-ConfigToReleaseList corresponding to the side link DRB;

1> for each side link DRB to be established or modified, according to section 5.8.9.1a.2.1, since sl-ConfigDedicatedNR, SIB12 or sidlinkpreconfignr is received:

2> setting slRB-Config contained in SLRB-ConfigtoadModList according to the received slR-radio BearerConfig and slR-RLC-BearerConfig corresponding to the side link DRB;

1> the sl-MeasConfig is set as follows:

2> if the frequency for NR side link communication is contained in the sl-FreqInfoToAddModList in the sl-ConfigDedimonium NR within the RRCReconfiguration message or in the sl-ConfigCommonNR within SIB 12:

3> if the UE is in rrc_connected:

4> setting sl-MeasConfig according to the NR side link measurement configuration information stored for this destination;

3> if the UE is in rrc_idle or rrc_inactive:

4> setting sl-MeasConfig according to the stored NR side link measurement configuration received from SIB 12;

2> otherwise:

3> setting sl-MeasConfig according to sl-measpreffig in the SidelinkPreconfigNR;

1> for a destination associated with a side link DRB, start timer T400;

1> setting sl-CSI-RS-Config;

1> set sl-latex boundsi-Report,

note 1: how to set the parameters contained in the sl-CSI-RS-Config and sl-latency boundsi-Report depends on the UE implementation.

The UE will submit an rrcrecon configuration sip link message to the lower layer for transmission.

5.8.9.1.3 receiving RRCRECONfigure Sidelink by UE

The UE will perform the following actions after receiving the rrcrecon configuration sidelink:

1> if rrcrecon configuration sidelink contains sl-ResetConfig, then:

2> performing a side link reset configuration procedure, as specified in 5.8.9.1.10;

1> if rrcrecon configuration sidelink contains slrb-ConfigToReleaseList:

2> for each SLRB-PC5-ConfigIndex value contained in SLRB-ConfigToReleaseList as part of the current UE side link configuration;

3> side link DRB release procedure is performed according to section 5.8.9.1a.1;

1> if rrcrecon configuration sidelink contains slrb-configtoadmodlist:

2> for each slrb-PC5-ConfigIndex value contained in the slrb-configtoadmodlist that is not part of the current UE side link configuration:

3> if si-mappdqos-flowstoadlist is included:

4> applying SL-PQFI contained in SL-MappedQoS-FlowsToAddList;

3> side link DRB addition procedure is performed according to section 5.8.9.1a.2;

2> for each slrb-PC5-ConfigIndex value contained in the slrb-configtoadmodlist as part of the current UE side link configuration:

3> if si-mappdqos-flowstoadlist is included:

4> adding SL-PQFI contained in SL-mappdqos-flowstoadlist to the corresponding side link DRB;

3> if si-mappdqos-flowstroreleaselist is included:

4> removing SL-PQFI contained in SL-MappedQoS-FlowsToReleaseList from the corresponding side link DRB;

3> if the side link DRB release condition as described in section 5.8.9.1a.1.1 is met:

4> side link DRB release procedure is performed according to section 5.8.9.1a.1.2;

3> otherwise if the side link DRB modification condition as described in section 5.8.9.1a.2.1 is satisfied:

4> side link DRB modification procedure is performed according to section 5.8.9.1a.2.2;

1> if the rrcrecon configuration sidelink message contains sl-MeasConfig, then:

2> performing a side link measurement configuration procedure, as specified in 5.8.10;

1> if the rrcrecon configuration sidelink message contains sl-CSI-RS-Config, then:

2> application side link CSI-RS configuration;

1> if the rrcrecon configuration sidelink message contains sl-LatencyBoundCSI-Report, then:

2> applying a configured side link CSI reporting delay bound;

1> if the UE is not able to follow the (partial) configuration contained in rrcrecon configuration sidelink (i.e. side link RRC reconfiguration failure):

2> continuing to use the configuration used before the rrcrecon configuration sidelink message is received;

2> setting the content of the RRCRECONfigure FailureSINEDLK message;

3> submitting an rrcrecon configuration failure message to the lower layer for transmission;

1> otherwise:

2> setting the content of the RRCReconfigurationCompleteSidelink message;

3> submit rrcrecon configuration completesinink message to lower part for transmission;

note 1: when the same logical channel is configured by another UE for a different RLC mode, the UE handles the situation as a side-link RRC reconfiguration failure.

[...]

5.8.9.1.9 receiving RRCRECONfigure ComplemeSidelnk by UE

The UE will perform the following actions after receiving rrcrecnonfigurationcompleteindelink:

1> stop timer T400 for the destination (if running);

1> consider the configuration in the application corresponding rrcrecon configuration sip link message.

[...]

5.8.9.1a side chain radio bearer management

[...]

5.8.9.1a.2 side link DRB addition/modification

5.8.9.1a.2.1 side link DRB addition/modification Condition

For NR side link communication, side link DRB addition is initiated only if:

1> if any side link QoS flows are (re) configured by sl-ConfigDedicatedNR, SIB, sidlinkpreconfignr and will map to one side link DRB that is not established; or (b)

1> if any side link QoS flows are reconfigured by rrcrecon configuration sidelink and will map to non-established side links DRB;

for NR side link communication, side link DRB modification is initiated only if:

1> if for one side link DRB established, any one of the side link DRB related parameters is changed by sl-ConfigDedicatedNR, SIB, sidelinkPreconfigNR or RRCRECONfigure Sidelink;

5.8.9.1a.2.2 side link DRB addition/modification operations

For a sidelink DRB that satisfies its sidelink DRB addition condition as in section 5.8.9.1a.2.1, an NR sidelink communication capable UE configured by an upper layer to perform NR sidelink communication should:

1> for multicast and broadcast; or (b)

1> for unicast, if a side link DRB addition is triggered due to the reception of the RRCReconfigurationSidelink message; or (b)

1> for unicast, after receiving the rrcrecon configuration completesidlink message, if the side link DRB addition is triggered due to configuration received by or indicated by the upper layer in sl-ConfigDedicatedNR, SIB, sidlinkpreconfignr:

2> if there is no SDAP entity communicating with the NR side link associated with the destination and broadcast type of the side link DRB:

3> establishing an SDAP entity for NR side link communication as specified in section 5.1.1 of TS 37.324[24 ];

2, (re) configuring the SDAP entity according to the sl-SDAP-ConfigPC5 received in RRCReconfiguration Sidelnk or the sl-SDAP-Config received in sl-ConfigDedicatedNR, SIB, sidelinkPreconfigNR associated with the side link DRB;

2> establishing a PDCP entity for NR side link communication and configuring the PDCP entity according to the sl-PDCP-ConfigPC5 received in the rrcrecnonfigurationsidelink or the sl-PDCP-Config received in the sl-ConfigDedicatedNR, SIB, sidelink prefonfignr associated with the side link DRB;

2> establishing RLC entities for NR side link communication and configuring the RLC entities according to sl-RLC-ConfigPC5 received in rrcrecconfiguration sidelink or sl-RLC-Config received in sl-ConfigDedicatedNR, SIB, sidelink prefonfignr associated with side link DRB;

2> if this procedure is due to the reception of an RRCReconfigurationSidelink message, then:

3> configuring the MAC entity with a logical channel according to the sl-MAC-LogicalChannelConfigPC5 received in the rrcrecconfiguration sidelink associated with the side link DRB and executing the side link UE information procedure in section 5.8.3 for unicast when needed;

2> otherwise:

3> the MAC entity is configured with the logical channel associated with the side link DRB by assigning a new logical channel identity according to the sl-MAC-LogicalChannelConfig received in the sl-ConfigDedicatedNR, SIB, sidelink prefonfignr.

Note 1: when the side link DRB addition is due to the configuration of RRCReconfigurationSidelink, the side link DRB configuration of parameters of the transmission side link DRB as needed is selected depending on the UE implementation from the received sl-configdedicatedtnr (if in rrc_connected), SIB12 (if in rrc_idle/INACTIVE), sidelinkpinconfignr (if not in coverage) with the same RLC mode as that configured in RRCReconfigurationSidelink.

[...]

-RRCReconfiguration

The rrcrecon configuration message is a command to modify the RRC connection. It may deliver information for measurement configuration, mobility control, radio resource configuration (including RB, MAC primary configuration and physical channel configuration) and AS security configuration.

Signaling radio bearers: SRB1 or SRB3

RLC-SAP：AM

Logical channel: DCCH (DCCH)

The direction is: network to UE

RRCRECONfigure message

-SL-ConfigDedicatedNR

The IE SL-ConfigDedicatedNR specifies dedicated configuration information for link communication on the NR side.

SL ConfigDedimatiedNR information element

/>

-SL-RadioBearerConfig

IE SL-radio beareconfig specifies the side link DRB configuration information for NR side link communication.

SL radio beaererconfig information element

/>

-SL-PDCP-Config

The IE SL-PDCP-Config is used to set configurable PDCP parameters for side-link radio bearers.

SL-PDCP-Config information element

/>

-SL-SDAP-Config

The IE SL-SDAP-Config is used to set the configurable SDAP parameters of the side link DRB.

SL-SDAP-Config information element

/>

-SL-RLC-BearerConfig

The IE SL-RLC-BearerConfig specifies SL RLC bearer configuration information for NR side link communication.

SL-RLC-BearerConfig information element

/>

-SL-LogicalChannelConfig

The IE SL-LogicalChannelConfig is used to configure side link logical channel parameters.

SL LogicalchannelConfig information element

/>

-RRCReconfigurationSidelink

The rrcrecon configuration sip message is a command for the AS configuration of the PC5 RRC connection. It is used only for unicast NR side link communication.

Signaling radio bearers: SL-SRB3

RLC-SAP：AM

Logical channel: SCCH (SCCH)

The direction is: UE-to-UE

RRCRECONfigure Sidelink message

/>

maxNrofSL-QFIs-r16 INTEGER::＝2048--Maximum number of QoS flow for NR sidelink communication per UE

maxNrofSL-QFIsPerDest-r16 INTEGER::＝64--Maximum number of QoS flow per destination for NR sidelink communication

maxNrofSL-Dest-r16 INTEGER::＝32--Maximum number of destination for NR sidelink communication

3GPP TS 23.752 states:

6.8 solution #8: inter-UE relay selection without relay discovery

6.8.1 describes

When the source UE wants to communicate with the target UE, it will first attempt to find the target UE by sending a direct communication request or solicitation message with the target UE information. If the source UE cannot reach the target UE directly, it may attempt to explore inter-UE relays to reach the target UE, which may also trigger relay discovery of the target UE. For greater efficiency, this solution attempts to integrate target UE discovery and inter-UE relay discovery and selection, including two alternatives:

alternative 1: inter-UE relay discovery and selection may be integrated into the concept of unicast link setup procedure as described in section 6.3.3 of TS 23.287[5]

Alternative 2: inter-UE relay discovery and selection is integrated into the model B direct discovery procedure.

It is proposed to add a new field in the direct communication request or solicitation message to indicate whether relaying can be used in the communication. A field may be referred to as a relay_indication. When a UE wants to broadcast a direct communication request or solicitation message, it indicates in the message whether inter-UE relay can be used. For version 17, it is assumed that the indicated value is limited to a single hop.

When the inter-UE relay receives a direct communication request or solicitation message in which the relay_indication has been set, it should then decide whether to forward the message (i.e. modify the message and broadcast it in its vicinity) according to, for example: relay service code (if present), application ID, authorization policy (e.g., relay for a particular ProSe service), current traffic load of the relay, radio conditions between source UE and relay UE, etc.

The following may be present: the target UE may be reached using multiple inter-UE relays, or the target UE may also receive direct communication requests or solicitation messages directly from the source UE. The target UE may choose which to reply based on, for example, signal strength, local policy (e.g., traffic load of inter-UE relay), relay service code (if present), or operator policy (e.g., always prefer direct communication or use of only some specific inter-UE relay).

The source UE may relay from among multiple UEs and may also receive responses directly from the target UE, the source UE selecting a communication path according to, for example, signal strength or operator policy (e.g., always preferring direct communication or using only some specific inter-UE relays).

6.8.2 procedure

6.8.2.1 inter-UE relay discovery and selection integrated into unicast link setup procedure (alternative 1)

FIG. 6.8.2.1-1, entitled "5G ProSe inter UE Relay selection (alternative 1)" in 3GPP TR 23.752V2.0.0, is reproduced as FIG. 10]

Fig. 6.8.2.1-1 shows the procedure of the proposed method.

The UE is authorized to use the services provided by the inter-UE relay. inter-UE relay is authorized to provide services that relay traffic among UEs. Authorization and parameter provisioning may use ki#8 solutions, e.g., sol#36. Authorization may be accomplished when the UE/relay registers with the network. Security related parameters may be supplied so that the UE and relay can verify the authorization (if needed) with each other.

UE-1 wants to establish unicast communication with UE-2 and the communication may be through a direct link with UE-2 or via an inter-UE relay. Then, UE-1 broadcasts a direct communication request with relay_indication enabled. The message will be received by relay-1, relay-2. If UE-2 is in proximity to UE-1, the message may also be received by UE-2. UE-1 contains source UE information, target UE information, application ID, and relay service code (if present). If the UE-1 does not want the communication to involve relaying, it will deactivate the relay_indication.

Note 1: the data type of the relay_indication may be determined in stage 3. The details of the direct communication request/accept message will be determined in stage 3.

2. Relay-1 and relay-2 decide to participate in the procedure. They broadcast a new direct communication request message nearby without enabling relay _ indication. If the relay receives this message, it will only discard the message. When the relay broadcast direct communication request message, it includes source UE information, target UE information, and relay UE information (e.g., relay UE ID) in the message and uses the relayed L2 address as a source layer 2ID. The relay maintains an association between the source UE information (e.g., source UE L2 ID) and the new direct communication request.

Ue-2 receives direct communication requests from relay-1 and relay-2. UE-2 may also receive a direct communication request message directly from UE-1 if UE-2 is in communication range of UE-1.

Ue-2 selects relay-1 and replies with a direct communication accept message. If UE-2 receives a direct communication request directly from UE-1, it may choose to establish a direct communication link by sending a direct communication accept message directly to UE-1. After receiving the direct communication acceptance, the inter-UE relay retrieves the source UE information stored in step 2 and transmits a direct communication acceptance message to the source UE, wherein relay UE information is added in the message.

After step 4, UE-1 and UE-2 each establish a PC5 link with the relay between the selected UEs.

And (2) injection: security establishment between UE1 and relay-1 and between relay-1 and UE-2 is performed before relay-1 and UE-2 send direct communication accept messages. The details of the authentication/security establishment procedure are determined by the SA WG 3. The security setup procedure may be skipped if there is already a PC5 link between the source (or target) UE and the relay available for relaying traffic.

Ue-1 receives a direct communication accept message from relay-1. UE-1 selects a path according to, for example, a policy (e.g., always select a direct path if possible), signal strength, etc. If UE-1 receives a direct communication accept/response message request accept directly from UE-2, it may choose to set up a direct PC 5L 2 link with UE-2 as described in 6.3.3 of TS 23.287[5], and then skip step 6.

For the L3 inter-UE relay case, UE-1 and UE-2 complete establishment of the communication link via the selected inter-UE relay. The link establishment information may vary depending on the relay type (e.g., L2 or L3 relay). Then, UE-1 and UE-2 may communicate via a relay. Regarding IP address assignment for source/remote UEs, the address may be assigned by a relay or by the UE itself (e.g., link local IP address), as defined in section 6.3.3 of TS 23.287[5 ].

For the layer 2 inter-UE relay case, the source and target UEs may establish an end-to-end PC5 link via relay. UE-1 sends a unicast E2E direct communication request message to UE-2 via relay-1, and UE-2 responds to UE-1 with a unicast E2E direct communication accept message via relay-1. Relay-1 delivers the message based on the identification information of UE-1/UE-2 in the adaptation layer.

And (3) injection: how relay-1 may communicate messages based on the identification information of UE-1/UE-2 in the adaptation layer needs to cooperate with RAN2 during the normalization phase.

And (4) injection: for relay or path selection, the source UE may set a timer after sending out a direct communication request to collect the corresponding response message before making a decision. Similarly, the target UE may also set a timer after receiving a first copy of the direct communication request/message for multiple copies of the collected message from different paths before making the decision.

And (5) injection: when the UE receives a message from an inter-UE relay for the first time, the UE needs to verify whether the relay is authorized to be an inter-UE relay. Also, inter-UE relay may also need to verify whether the UE is authorized to use relay services. The authentication details and how to secure the communication between two UEs through inter-UE relay will be defined by the savg g 3.

6.8.2.2 Integration of inter-UE relay discovery and selection into model B direct discovery procedure (alternative 2)

The procedure of the inter-UE relay discovery model B is depicted in fig. 6.8.2.2-1, and the discovery/selection procedure is separate from hop-by-hop and end-to-end link establishment.

FIG. 6.8.2.2-1, entitled "5G ProSeUE-to-Relay selection (alternative 2)" in [3GPP TR 23.752V2.0.0, is reproduced as FIG. 11]

UE-1 broadcasts a discovery solicitation message carrying UE-1 information, target UE information (UE-2), application ID, relay service code (if present), UE-1 may also indicate that relay_indication is enabled.

2. Upon receiving the discovery solicitation, the candidate relay UE-R broadcasts a discovery solicitation carrying UE-1 information, UE-R information, target UE information. The relay UE-R uses the relayed L2 address as the source layer 2ID.

3. The target UE-2 responds to the discovery message. If the UE-2 receives the discovery solicitation message in step 1, the UE-2 responds to the discovery response with the UE-1 information, the UE-2 information in step 3 b. If not received and the UE-2 receives a discovery solicitation in step 2, the UE-2 responds to a discovery response message with UE-1 information, UE-R information, UE-2 information in step 3 a.

4. Upon receiving the discovery response in step 3a, the UE-R transmits a discovery response with UE-1 information, UE-R information, UE-2 information. If more than one candidate relay UE responds to the discovery response message, UE-1 may select one relay UE based on, for example, implementation or link check.

5. The source and target UEs may need to establish a PC5 link with the relay before communicating with each other. Step 5a may be skipped if there is already a PC5 link between UE-1 and UE-R that is available for relaying. Step 5b may be skipped if there is already a PC5 link between UE-2 and UE-R that is available for relaying.

Step 6a is the same as step 6a described in section 6.8.2.1.

For layer 2 inter-UE relay, an E2E unicast direct communication request message is sent from UE1 to the selected relay via the per-hop link (established in step 5 a) and adaptation layer information identifying the peer UE (UE 3) as the destination. The inter-UE relay conveys E2E messages based on the identity information of the peer UE in the adaptation layer. The initiator (UE 1) knows the adaptation layer information identifying the peer UE (UE 3) after the discovery procedure. The UE3 responds in the same way with an E2E unicast direct communication accept message.

Note 1: for the inter-layer 2UE relay case, whether step 5b is performed before step 6b or the trigger will be decided at the normative phase during step 6b.

And (2) injection: how relay-1 may communicate messages based on the identification information of UE-1/UE-2 in the adaptation layer needs to cooperate with RAN2 during the normalization phase.

6.8.3 effects on services, entities and interfaces

Impact on UEs supporting new relay related functions.

6.9 solution #9: connection establishment via UE interlayer 2 relay

6.9.1 description

6.9.1.1 overview

Using the solution described in this section, inter-UE relay enables the target UE to discover the source UE. Authorizing inter-UE relay relays messages between two UEs over the PC5 interface via authorization and provisioning, as in the solution of section 6.Y key issue # 4: inter-UE relay grant and provisioning.

The source UE informs its supported applications or discovers the target UE using known discovery mechanisms, e.g., using a user-oriented or service-oriented approach as defined in TS 23.287[5 ].

The inter-UE relay listens for ProSe application advertisements (e.g., direct discovery or direct communication request messages) from surrounding UEs and if the broadcasted application matches one from the relay policies/parameters it supplies, the inter-UE relay advertises it as a relayed application by adding a relay indication to the message.

The target UE discovers the source UE via inter-UE relay. The target UE receives the broadcast direct communication request message with the relay indication.

A secure "extended" PC5 link is set up between the source UE and the target UE via inter-UE relay. The source/target UE sends the message to the inter-UE relay and receives the message through the inter-UE relay. However, the security association and PC5 unicast link are established directly between the source UE and the target UE. The inter-UE relay forwards the message in opaque mode without being able to read, modify its content or replay the message, except for discovery messages and direct communication request messages that are sent in the clear (i.e., without security protection) visible to the inter-UE relay and modified to add relay indications. Upon detecting the relay indication contained in the received message, the source/target UE detects that link establishment is traversing the inter-UE relay.

inter-UE relay maintains a managed connection between the relay UE and each source/target UE, and maintains 1 or more "extended" end-to-end PC5 unicast links between the source UE and the target UE. The inter-UE relay forwards messages between the source UE and the target UE using an adaptation layer. Details of the identification information of the source UE and the target UE for forwarding or routing the message in the adaptation layer will be defined in connection with the RAN WG during the normalization phase.

Note that: additional security related parameters and procedures may be required to protect relay related messages. Its definition needs to be coordinated with the SA WG 3.

Link management (i.e., keep-alive, link modification, link identifier update, and link release) is supported by direct unicast links and also requires link support by extended PC 5. Because the security association of the extended PC5 link is between peer UEs, all messages sent over the extended PC5 link (including link management (i.e., PC 5-S) messages) can only be handled by those two UEs.

6.9.1.2 control and user plane protocol stack

The control and user plane protocol stacks are based on the architectural reference model described in annex a.

6.9.2 procedure

6.9.2.1 connection establishment

Connection establishment for relay between L2 UEs includes two cases:

connection establishment integrating inter-UE relay discovery and selection

Connection establishment after relay discovery and selection between UEs

6.9.2.1.1 connection establishment integrating inter-UE relay discovery and selection

Two methods defined in TS 23.287[5], namely, service-oriented and user-oriented methods, are supported using the procedure described in this section.

Fig. 6.9.2.1.1-1 shows peer discovery and unicast link establishment through a PC5 reference point via inter-UE relay.

Fig. 6.9.2.1.1-1 entitled "connection establishment procedure integrating inter-UE relay discovery and selection" in 3GPP TR 23.752V2.0.0 is reproduced as fig. 12

inter-UE relay registers in the network and provides its inter-UE relay capability. Authorization and parameter provisioning may use the solution of KI #8 and inter-UE relay is provided with relay policy parameters.

Note 1: step 0 is optional and policy parameters may be preconfigured.

1. The target UE (i.e., UE2, UE3, and UE 4) determines the destination layer 2ID for signaling reception for PC5 unicast link establishment, as specified in section 5.6.1.4 of TS23.287[5 ]. The destination layer 2ID is configured to use the target UE, as specified in section 5.1.2.1 of TS23.287[5 ].

2. On the source UE (i.e., UE 1), the application layer provides information to the ProSe layer for PC5 unicast communications (e.g., broadcast layer 2ID, proSe application ID, application layer ID of the UE, application layer ID of the target UE, relay applicable indication), as specified in section 6.3.3.1 of TS23.287[5 ].

The ProSe layer triggers a peer UE discovery mechanism by sending a broadcast direct communication request message. The message is sent using the source layer 2ID and the broadcast layer 2ID as destinations and contains other parameters related to the provided application as formulated in section 6.3.3.1 of TS23.287[5 ].

Inter-ue relay receives the broadcast direct communication request message and verifies if it is configured to relay this application, i.e. it compares the notified ProSe application ID with its provisioned relay policy/parameters

The inter-UE relay forwards the E2E broadcast direct communication request message by using its own layer 2ID as the source L2 ID, and also includes the ID of the relay UE in the message and specifies the information identifying UE1 in the adaptation layer.

And (2) injection: the inter-UE relay processes this E2E broadcast message in the ProSe layer and forwards any subsequent E2EPC5-S messages based on the adaptation layer information.

And (3) injection: a UE, such as UE-3, may receive the direct communication request message (without adaptation layer information) directly from UE1 or via an inter-UE relay.

The target UE3 is interested in the application of the notification and if there is no existing per-hop link between UE3 and the inter-UE relay, it triggers per-hop link establishment with the inter-UE relay. The UE3 sends a per-hop link setup procedure message with its layer 2ID as source and the layer 2ID from the relay as destination.

And (4) injection: whether to perform a per-hop link update in the presence of an existing per-hop link may be determined in a normative phase.

4b. If there is no existing per-hop link between the inter-UE relay and UE1, a per-hop link setup procedure is performed between the inter-UE relay and UE 1. UE1 regards its layer 2ID as a source and relay layer 2ID as a destination.

5. If step 4a is successful, E2E authentication and security setup messages are exchanged between UE1 and UE3 via inter-UE relay. Including an adaptation layer identifying the source and/or destination UE. Upon receiving this first message from UE3 via the relay, if there is no existing per-hop link between the inter-UE relay and UE1, a per-hop link establishment procedure is performed between the inter-UE relay and UE 1.

The editor annotates: details of authentication and security procedures will be studied by the SA WG3 group.

And (5) injection: step 4b is triggered by step 5 when UE-1 receives the first security message from UE-3.

6. Once end-to-end security is established between UE3 and UE1, UE3 completes the end-to-end link establishment between UE3 and UE1 by sending an E2E unicast direct communication accept message containing adaptation layer information identifying UE 1.

The inter-UE relay forwards the E2E unicast direct communication accept message containing adaptation layer information identifying UE 3.

And (6) injection: details of the adaptation layer information identifying the source UE and the target UE and how to distinguish the E2E PC5-S message from the per-hop PC5-S message will be defined during the normalization phase in connection with the RAN WG.

8. An "extended" unicast link has been established between UE1 and UE3 by inter-UE relay. The extended link is secure end-to-end, i.e. a security association has been created between UE1 and UE 3. The protected messages (i.e., data or PC 5-S) may be switch-sealed and/or integrity/replayed between UE1 and UE 3. The inter-UE relay does not participate in the security association and therefore it cannot read or modify the protected part of the message (excluding the source and destination fields).

In addition, UE interlayer 2 relay operation is also supported by the following principles:

-inter-UE relay selection.

There may be situations where multiple inter-UE relays may be used to enable indirect communication between a target UE and a source UE. The selection of inter-UE relay may be based on local configuration rules of the UE, or based on other inter-UE relay selection solutions, such as "inter-UE relay selection without relay discovery" described in section 6.8.

QoS treatment.

During connection establishment between source UE1 and target UE3, source UE1 negotiates PC5 QoS parameters with target UE3 to achieve E2E QoS requirements. After E2E QoS negotiation as part of E2E extended unicast link establishment/setup, PC5 QoS parameters for the PC5 link between the source UE and the inter-UE relay UE and the PC5 link between the inter-UE relay UE and the target UE are determined as described in solution # 31. The AS layer configuration of PC5 QoS parameters in each PC5 link may be implemented according to conventional mechanisms in Rel-16V 2X.

In particular, the QoS flow concept may be reused between a source UE and a target UE, wherein an inter-UE relay UE performs the required adaptation between two PC5 interfaces, namely PC5 for the source UE and the inter-UE relay UE and PC5 for the inter-UE relay UE and the target UE.

The editor annotates: the details of the adaptation between the two PC5 interfaces are confirmed by the RAN WG 2.

Charging support.

The charging of the source UE and the target UE may be based on charging usage information configuration and UE reporting usage information. The billing usage information configured solution may reuse the PCF-based solution, solution #14. The solution in which the UE reports the usage information may reuse the SMF-based or AMF-based solution, i.e., solution #13 or solution #15.

6.9.2.1.2 connection establishment after inter-UE relay discovery and selection

Fig. 6.9.2.1.2-1 shows a connection establishment procedure after relay discovery and selection between UEs. inter-UE relay discovery may be model a or model B. For model B, this procedure corresponds to alternative 2 in section 6.8.2.2 of solution #8, where UE relay discovery and selection is integrated into the model B direct discovery procedure.

Fig. 6.9.2.1.2-1 entitled "connection establishment procedure after relay discovery and selection between UEs" in 3GPP TR 23.752V2.0.0 is reproduced as fig. 13]

Step 0 and step 1 are the same as those described in section 6.9.2.1.1.

2. And performing relay discovery and relay selection among independent UEs, including a model a or a model B.

3. If there is no existing per-hop link between UE1 and the selected relay UE, then UE1 establishes a new per-hop link with the selected relay UE.

An e2e unicast direct communication request message is sent from UE1 to the selected relay via the per-hop link (established in step 3) adaptation layer information identifying the peer UE (UE 3) as the destination. The inter-UE relay conveys E2E messages based on the identity information of the peer UE in the adaptation layer. The initiator (UE 1) knows the adaptation layer information identifying the peer UE (UE 3) after the discovery procedure. The UE3 responds in the same way with an E2E unicast direct communication accept message. If no existing per-hop link exists between the relay and UE3, then UE3 establishes a per-hop.

Note that: whether per-hop link establishment between relay and UE3 can be triggered by UE3 or relay will be determined in the normative phase.

6.9.2.2 connection management

6.9.2.2.1 link identifier update via management link with inter-UE relay

Fig. 6.9.2.2-1 shows a link identifier update procedure when an extended PC5 link is used. The procedure uses a management link established between UE1 and the inter-UE relay serving this extended link, and another management link established between UE2 and the same inter-UE relay.

Note that: the details of the link identifier update procedure may be calibrated during the normalization phase.

Fig. 6.9.2.2-1 entitled "link identifier update procedure via management link with UE" in 3GPP TR 23.752V2.0.0 is reproduced as fig. 14]

0) An "extended" unicast link is established between two peer UEs via inter-UE relay, i.e. as described in section 6.9.2.1, where end-to-end security is enabled.

1) UE1 receives a trigger (e.g., expiration of a privacy timer or change in application layer ID) to update its identifier (i.e., layer 2ID, security information, application layer ID, or IP address/prefix) associated with the extended link with UE 2. A management link between UE1 and the inter-UE relay has been established.

2) UE1 updates its identifier (i.e., layer 2ID, security information, and optionally application layer ID and IP address/prefix) and sends a link identifier update request message to the inter-UE relay via the management link. The message contains the new layer 2ID of UE1 and an indication specifying that the message is related to an extended link (e.g., an "extended link" indication), i.e., it is not applied to the management link itself. The message also contains a layer 2ID of the inter-UE relay and a layer 2ID for identifying UE1 of the extended link.

a. Other identifiers (i.e., security information, application layer ID, and IP address/prefix) are not included because they are not used by and should not be exposed to inter-UE relays.

3) The inter-UE relay maintains the new layer 2ID of UE1 in its mapping table while maintaining the current ID and updates its own layer 2ID instead of the current inter-UE relay L2 ID used on the extended link and known by UE 2. It replies with a link identifier update response message containing its new inter-UE relay layer 2ID and an "extended link" indication.

4) UE1 sends a link identifier update request message to UE2 containing the new inter-UE relay L2 ID received at step 3, updated security information for UE1, and optionally the new application layer ID and IP address/prefix.

a. The link identifier update request message is used as usual except for the new L2 ID parameter that carries the new inter-UE relay L2 ID to be used by UE 2.

5) UE2 tracks the received parameters. A management link between UE2 and the inter-UE relay has been established.

6) As for UE1 in step 2, UE2 updates its identifier associated with the extended link with UE1 and sends a link identifier update request message to the inter-UE relay via the management link. The link identifier update request message contains an "extended link" indication, the layer 2ID of the current inter-UE relay and the layer 2ID of UE2 (identifying the extended link), and the new layer 2ID of UE2 associated with the extended link.

7) The inter-UE relay maintains the new layer 2ID of UE2 in its mapping table while maintaining the current ID and updates its own layer 2ID instead of the current inter-UE relay L2 ID used on the extended link and known by UE 1. It replies with a link identifier update response message containing its new inter-UE relay layer 2ID and an "extended link" indication.

8) UE2 sends a link identifier update response message to UE1 containing the new inter-UE relay L2 ID received at step 7, the updated security information for UE2, and optionally the new application layer ID and IP address/prefix. UE2 also contains the parameters received at step 4 on the link identifier update request message.

9) UE1 tracks the updated parameters received from UE2 and sends a link identifier update Ack message to UE2 containing the parameters received on the link identifier update response message at step 8.

10 UE1 sends a link identifier update Ack message to the inter-UE relay including the new inter-UE relay layer 2ID and the "extended link" indication received at step 3.

UE2 sends a link identifier update Ack message to the inter-UE relay including the new inter-UE relay layer 2ID and the "extended link" indication received at step 7. All UEs (i.e., UE1, UE2, and inter-UE relay) begin using the new layer 2ID, new security information, and optionally the new application layer ID and new IP address/prefix.

6.9.3 impact on services, entities and interfaces

The solution has an impact in the following entities:

UE：

support of procedures for inter-ProSe 5G UE relay and communication via inter-ProSe 5G UE relay is required.

A procedure for extended communication management needs to be supported via communication relayed with ProSe 5G UEs.

3GPP TS 38.323 states:

5.8 encryption and decryption

The ciphering function includes both ciphering and deciphering, and is performed in PDCP (if configured). The ciphered data units are the data portion of the MAC-I (see section 6.3.4) and PDCP data PDUs (see section 6.3.3), except for the SDAP header and the SDAP control PDU (if included in the PDCP SDU). Ciphering is not applicable to PDCP control PDUs.

For the downlink and uplink, the ciphering algorithm and key to be used by the PDCP entity are configured through an upper layer TS38.331[3], and the ciphering method is applied as specified in TS 33.501[6 ].

The encryption function is activated/suspended/resumed by the upper layer at TS38.331[ 3]. When security is active and not suspended, the ciphering function will be applied to all PDCP data PDUs TS38.331[3] indicated by the upper layer for downlink and uplink, respectively.

For DAPS bearers, the PDCP entity will perform ciphering or deciphering of PDCP SDUs based on which cell the PDCP SDUs are transferred to/received from using ciphering algorithms and keys configured for the source cell or configured for the target cell.

For downlink and uplink ciphering and deciphering, parameters required for ciphering by the PDCP are defined in TS 33.501 < 6 > and input to the ciphering algorithm. The required inputs to the encryption function include the COUNT value and DIRECTION (transfer DIRECTION: set as specified in TS 33.501[6 ]). The parameters required for providing PDCP of TS38.331[3] by the upper layer are listed below:

BEARER (defined as radio BEARER identifier in TS 33.501[6 ]. It will use the value RB identity-1 as in TS 38.331[3 ];

KEY (encryption KEYs for control plane and user plane are K respectively) _RRCenc And K _UPenc )。

For NR side link communication, the ciphering algorithm and key to be used by the PDCP entity are configured by the upper layer as specified in TS 24.587[16] and the ciphering method is to be applied as specified in TS 33.536[14 ].

For NR side link communication, the encryption function is activated by the upper layer for side link SRB (except SL-SRB 0) and/or side link DRB for the PC5 unicast link, as specified in TS 38.331[3 ]. When security is activated for the sidelink SRB, the ciphering function will be applied to all PDCP data PDUs belonging to the sidelink SRB of the PC5 unicast link (except for carrying direct Security mode Command messages, as specified in TS 33.536[14 ]). When security is activated for the sidelink DRB, the ciphering function will be applied to all PDCP data PDUs belonging to the sidelink DRB of the PC5 unicast link.

For NR side link communications, the encryption and decryption functions as specified in TS 33.536[14] apply KEY (NRPEK), COUNT, BEARER (LSB 5 bits of LCID, as specified in TS 38.321[4 ]), and DIRECTION (the value of which will be set as specified in TS 33.536[14 ]) as inputs.

3GPP TR 38.836 states:

5 inter-UE relay based on side links

5.1 cases, assumptions and requirements

inter-UE relay achieves coverage extension and power saving for side link transmission between two side link UEs. The coverage scenarios considered in this study are as follows:

1) All UEs (source UE, relay UE, destination UE) are within coverage.

2) All UEs (source UE, relay UE, destination UE) are out of coverage.

3) Local coverage, wherein at least one of the UEs involved in the relay (source UE, relay UE, destination UE) is in coverage and at least one of the UEs involved in the relay is out of coverage.

RAN2 strives to find a common solution for both in-and out-of-coverage situations. For inter-UE relay, a scenario is supported in which the UE may be within coverage of different cells.

Fig. 5.1-1 shows a scenario considered for inter-UE relay. In fig. 5.1-1, coverage means that the source/destination UE and/or inter-UE relay UE is within coverage and can access the network on Uu.

Fig. 5.1-1, named "case for inter-UE relay (where coverage status is not shown)" in 3GPP TR 38.836V17.0.0 is reproduced as fig. 15]

An NR-side link is assumed with respect to PC5 between a remote UE and an inter-UE relay.

cross-RAT configuration/control of source UE, inter-UE relay and destination UE is not considered, i.e. eNB/ng-eNB does not control/configure NR source UE, destination UE or inter-UE relay UE. For inter-UE relay, the present study focuses on unicast data traffic between a source UE and a destination UE.

It is not within the scope of this study to configure/schedule UEs (source UE, destination UE or inter-UE relay UE) to perform NR side link communication through SN.

For inter-UE relay, it is assumed that a remote UE has an active end-to-end connection at a given time via only a single relay UE.

Once the PC5 link is established between the source UE, the inter-UE relay, and the destination UE, data relay between the source UE and the destination UE may occur.

No restrictions are assumed regarding the RRC state of any UE involved in the inter-UE relay.

During mobility of this version, the requirement of service continuity is only for UE-to-network relay and not for inter-UE relay.

5.2 discovery of

inter-UE relay supports model a and model B discovery models as defined in section 5.3.1.2 of TS 23.303[3], and may support integrated PC5 unicast link setup procedures based on SA2 conclusions. The protocol stack of the discovery message is depicted in fig. 5.2-1.

Fig. 5.2-1, named "protocol stack for discovery message for inter-UE relay" in 3GPP TR 38.836V17.0.0 is reproduced as fig. 16]

When triggered by an upper layer, the relay UE or the remote UE is allowed to transmit the discovery message.

Both the remote UE and the relay UE may rely on pre-configuration unless the relevant radio configuration is provided by the network via system information or dedicated signaling.

The resource pool that transmits the discovery message may be shared with or separate from the resource pool used for data transmission.

For the shared resource pool and the separate resource pool, a new LCID is introduced for the discovery message, i.e. the discovery message is carried by the new SL SRB.

Within separate resource pools, discovery messages are handled equally to each other during LCP procedures.

5.3 Relay selection (reselection) criteria and procedure

The baseline solution for relay selection (reselection) is as follows:

the radio measurements at the PC5 interface are considered part of the relay selection (reselection) criteria.

The remote UE uses at least the radio signal strength measurement of the side link discovery message to evaluate whether the PC5 link quality of the relay UE meets the relay selection and reselection criteria.

When the remote UE connects to the relay UE, it may use SL-RSRP measurements on the sidelink unicast link to evaluate whether the PC5 link quality of the relay UE meets the relay reselection criteria.

Additional details regarding the PC5 radio measurement standard, such as in the case of no transmission over a side-link unicast link, may be discussed in the WI stage. How to perform RSRP measurements based on the RSRP of the discovery message and/or SL-RSRP in case the remote UE has a PC5-RRC connection with the relay UE may be decided in the WI phase.

For relay selection (reselection), the remote UE compares the PC5 radio measurements of the relay UE with a gNB-configured or preconfigured threshold. For relay selection (reselection), the remote UE also needs to consider higher-layer criteria, but the details may be determined by SA 2. Relay selection (reselection) may be triggered by an upper layer of the remote UE.

If the NR side link signal strength of the current side link relay is below a (pre) configured threshold, then a relay reselection should be triggered. And, if RLF of the PC5 link with the current relay UE is detected by the remote UE, a relay reselection may be triggered.

The above-described baselines for relay selection (reselection) apply to both L2 and L3 relay solutions. For both L2 and L3 inter-UE relay solutions, additional AS layer criteria may be considered in the WI stage.

For relay selection (reselection), when the remote UE has a plurality of suitable relay UE candidates meeting all AS-layer and higher-layer criteria and the remote UE needs to select one relay UE itself, a decision is made by the UE implementation AS to which relay UE to select.

As acquired in TR 23.752, solution #8 and solution #50 in TR 23.752 are considered to be baseline solutions for relay reselection between L2 and L3 UEs, and solution #8 and solution #11 in TR 23.752 are considered to be baseline solutions for relay selection between L3 UEs.

5.4 Relay/remote UE authorization

RAN2 concludes: the authorization of both the relay UE and the remote UE has no RAN2 impact.

5.5 layer 2 Relay

5.5.1 architecture and protocol stack

For the L2 inter-UE relay architecture, the protocol stack is similar to L2 UE-to-network relay, but the termination point is two remote UEs. The protocol stacks for the user plane and control plane of the L2 inter-UE relay architecture are depicted in fig. 5.5.1-1 and fig. 5.5.1-2.

The adaptation layer is supported by a second PC5 link relayed between the L2 UEs (i.e., a PC5 link between the relay UE and the destination UE). For inter-L2 UE relay, the adaptation layer is above the RLC sublayer for CP and UP on the second PC5 link. The side links SDAP/PDCP and RRC terminate between the two remote UEs, while RLC, MAC and PHY terminate in each PC5 link.

Fig. 5.5.1-1, entitled "user plane protocol stack for inter-L2 UE relay" in 3GPP TR 38.836V17.0.0 is reproduced as fig. 17]

Fig. 5.5.1-2, entitled "control plane protocol stack for inter-L2 UE relay" in 3GPP TR 38.836V17.0.0 is reproduced as fig. 18]

For the first hop of the inter-L2 UE relay:

the first hop PC5 adaptation layer between the remote UE SL radio bearer and the first hop PC5 RLC channel supports the N:1 mapping for relaying.

The adaptation layer on the first PC5 hop between the source remote UE and the relay UE supports identifying traffic destined for different destination remote UEs.

For the second hop of the inter-L2 UE relay:

the second hop PC5 adaptation layer may be used to support bearer mapping between an incoming RLC channel on a first PC5 hop and an outgoing RLC channel on a second PC5 hop at the relay UE.

The PC5 adaptation layer supports N:1 bearer mapping between a plurality of incoming PC5 RLC channels on a first PC5 hop and one outgoing PC5 RLC channel on a second PC5 hop and supports remote UE identity functionality.

For inter-L2 UE relay:

the identification information of the remote UE end-to-end radio bearer is contained in the adaptation layer in the first and second PC5 hops.

In addition, the identification information of the source remote UE and/or the identification information of the destination remote UE is a candidate information to be included in the adaptation layer, which will be decided in the WI phase.

5.5.2 QoS

QoS treatment for inter-L2 UE relay is affected by upper layers, such as solution #31 in TR 23.752 studied by SA 2.

5.5.3 Security

As described in section 6.9.1.2 (solution # 9) of TR 23.752, in the case of inter-L2 UE relay, security is established at the PDCP layer in an end-to-end manner between UE1 and UE 2. Security aspects require acknowledgement of SA 3.

5.5.4 control plane procedure

RAN2 regards the SA2 solution in TR 23.752[6] as the baseline. Other RAN2 effects (if present) may be discussed in the WI stage.

According to 3GPP TS 23.287,UE (e.g., UE 1) a PC5 unicast link setup procedure (e.g., layer 2 link setup) may be performed with a peer UE (e.g., UE 2) to establish a unicast link between the two UEs. Basically, the peer UE's layer 2ID, identified by the peer UE's application layer ID, may be discovered during establishment of the PC5 unicast link, or known to the UE via previous V2X communications (e.g., existing or previous unicast links to the same application layer ID), or obtained from an application layer service notification. The initial signaling (i.e., direct communication request) for establishing the PC5 unicast link may use a known layer 2ID of the peer UE or a preset destination layer 2ID associated with a V2X service type (e.g., PSID/ITS-AID) configured for PC5 unicast link establishment. During the PC5 unicast link setup procedure, the layer 2 IDs of the two UEs may be exchanged and used for future communication between the two UEs.

In addition, according to 3GPP C1-202875, the two UEs can exchange security information with each other during PC5 unicast link establishment, such that the two UEs can use negotiated security algorithms and/or keys to protect the content of traffic (including, for example, PC5-S signaling, PC5-RRC signaling, and/or PC5 user plane data) sent over the PC5 unicast link.

According to 3gpp TS 23.752, inter-UE relay is to be supported for side link communication, which means that in case two UEs cannot communicate directly with each other, one or more relay UEs may be used to support data communication between the two UEs. For privacy reasons, the content of traffic communicated between the two UEs cannot be read or known by the relay UE. Thus, it is assumed that the security context for protecting the user plane (session traffic sent on SL DRB) on both UEs should be isolated from the security context established between the relay UE and each of both UEs. It is also assumed that some PC5-S signaling not related to the relay UE (i.e. these PC5-S signaling sent on the SL SRB may be exchanged between UE1 and UE 2) may also be protected by the security context established for protecting the user plane. With this in mind, examples of protocol stacks for the user plane and the control plane may be shown in fig. 19 and 20, respectively. In general, fig. 19 illustrates an example of a user plane protocol stack for inter-UE relay communication according to one embodiment, and fig. 20 illustrates an example of a control plane protocol stack for inter-UE relay communication according to one embodiment.

Furthermore, some PC5-S signaling and/or PC5-RRC signaling may be protected by a security context established between the relay UE and each of the two UEs. For example, UE1 and the relay UE may establish a first security context to protect some PC5-S signaling and/or PC5-RRC signaling for a first leg that controls or maintains inter-UE relay communications, while UE2 and the relay UE may establish a second security context to protect some PC5-S signaling and/or PC5-RRC signaling for a second leg that controls or maintains inter-UE relay communications. An example of a protocol stack for these cases may be shown in fig. 21. In general, fig. 21 illustrates an example of a control plane protocol stack for inter-UE relay communication in accordance with one embodiment.

Based on the working assumptions above, it should be considered how relay communications are supported over current side link communications.

The situation is as follows: switching from "direct communication mode" to "relay communication mode"

Basically, session transfer between the two UEs may begin with PC5 unicast link communication. The two UEs may move while they are performing PC5 unicast link communications. And, the two UEs may be too far apart to successfully receive the side link packet from the peer UE. In this case, the transmission of Radio Link Control (RLC) Packet Data Units (PDUs) will achieve a maximum retransmission time. For this purpose, a side link radio link error (RLF) will be declared and the PC5-RRC connection between the two UEs will be released due to the side link RLF. Then, the release of the PC5-RRC connection is indicated to the upper layer of the two UEs. Currently, the upper layer considers the PC5 unicast link communication unavailable, so that the upper layer stops the service session through the PC5 unicast link.

In the case where a relay communication mode (two UEs communicate with each other via a relay UE) is supported, when a direct communication mode (two UEs directly communicate with each other) is not available, the traffic session may continue in the relay communication mode. The switch to the relay communication mode may be triggered by, for example, the distance between the two UEs. According to 3gpp TS 23.752, one or more relay UEs may be known in advance to other UEs in the vicinity, for example, by notification messages or findings broadcast by these relay UEs, and these relay UEs may be used to support relay communications. UE1 and UE2 may perform a procedure for determining a relay UE for relay communication therein.

After selecting or determining the candidate relay UE, UE1 and UE2 may further perform a procedure for connecting the relay UE. Because both UEs are aware of the selected candidate relay UE, each of the two UEs may independently perform the procedure for connecting the relay UE. When each of the two UEs completes a procedure for connecting the relay UE, an upper layer (e.g., V2X layer or SL layer) of each UE may pass the layer 2ID of this UE and the layer 2ID of the selected candidate relay UE to a lower layer (including, for example, a Radio Resource Control (RRC) layer, a Service Data Adaptation Protocol (SDAP) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and/or a Physical (PHY) layer) for transmitting and/or receiving side link packets between this UE and the selected candidate relay UE.

According to 3GPP TS 38.331, if a UE has a side-link packet to transmit to a peer UE, the UE transmits a PC5 Radio Resource Control (RRC) reconfiguration message (e.g., RRCRECONfigure Sidelink) to the peer UE to configure one or more side-link Data Radio Bearers (DRBs). More specifically, each of these sidelink DRBs (established by the UE) is associated with a sidelink logical channel, and this sidelink DRB or sidelink logical channel is identified using a sidelink logical channel assigned by the UE. For inter-UE relay communication, each side link packet transmitted from UE1 to UE2 via the relay UE will be protected by the security context established between UE1 and UE 2. When encrypting these side link packets to be transmitted to UE2 via the relay UE, UE1 may need some other information in the security context than the security key. For example, the other information may include side link logical channel identities (associated with one side link radio bearer used to transmit the side link packets).

Similarly, UE2 also needs this information to decrypt these received side link packets. Because these sidelink packets are communicated from UE1 to the relay UE on a first sidelink radio bearer or logical channel and then from the relay UE to UE2 on a second sidelink radio bearer or logical channel, the sidelink logical channel identity of the first sidelink radio bearer or logical channel should be the same as the sidelink logical channel identity of the second radio bearer or logical channel. Therefore, when the relay UE configures UE2 to establish the second sidelink radio bearer or logical channel (through the rrcrecnonfigurationsidelink transmitted from the relay UE to UE 2), the relay UE cannot allocate a new sidelink logical channel identification for the second sidelink radio bearer or logical channel. In practice, the relay UE may still assign a sidelink logical channel identity of the first sidelink radio bearer or logical channel to the second sidelink radio bearer or logical channel. More specifically, UE1 may send a first rrcrecon configuration sidelink message to the relay UE to establish a first sidelink radio bearer or logical channel.

The first rrcrecconfiguration sidelink message sent from UE1 to the relay UE may include one Side Link Radio Bearer (SLRB) configuration of the first side link radio bearer or logical channel and a side link logical channel identification allocated (by UE 1) to the first side link radio bearer or logical channel. More specifically, the relay UE may send a second rrcrecon configuration sidelink message to UE2 to establish a second side link radio bearer or logical channel.

The second rrcrecconfiguration sidelink message sent from the relay UE to UE2 may contain one SLRB configuration of the second sidelink radio bearer or logical channel and the second sidelink radio bearer or logical channel may be allocated or set as a sidelink logical channel identification of the first sidelink radio bearer or logical channel. More specifically, the first sidelink radio bearer or logical channel may have been configured and/or established prior to the second sidelink radio bearer or logical channel being configured. Such SLRB configurations may include, for example, an SDAP configuration, a PDCP configuration, an RLC configuration, and/or a MAC configuration for an associated side link radio bearer or logical channel. Such side link packets may be IP packets, non-IP packets, SDAP PDUs, and/or PDCP PDUs.

Fig. 22 is a flow diagram 2200 from the perspective of a relay UE for establishing one or more side-link radio bearers to forward side-link packets from a first UE to a second UE in accordance with an example embodiment. In step 2205, the relay UE transmits a third PC5-RRC message to the second UE to establish a second sidelink radio bearer for transmitting sidelink packets from the relay UE to the second UE, wherein the third PC5-RRC message includes a second SLRB configuration of the second sidelink radio bearer and a sidelink logical channel identity associated with the second sidelink radio bearer, and wherein the sidelink logical channel identity is allocated by the first UE.

In one embodiment, a relay UE may receive a first PC5-RRC message from a first UE to establish a first sidelink radio bearer for transmitting sidelink packets from the first UE to the relay UE, wherein the first PC5-RRC message includes a first SLRB configuration of the first sidelink radio bearer and a sidelink logical channel identification associated with the first sidelink radio bearer. Further, the relay UE may transmit a second PC5-RRC message to the first UE, wherein the second PC5-RRC message is used to confirm that the relay UE is compliant with the first PC5-RRC message. In addition, the relay UE may receive a fourth PC5-RRC message from the second UE, wherein the fourth PC5-RRC message is used to confirm compliance of the second UE with the third PC5-RRC message.

In one embodiment, the second PC5-RRC message may be sent after the fourth PC5-RRC message is received. The second PC5-RRC message may also be sent before the fourth PC5-RRC message is received. Further, the first PC5-RRC message may be received before the third PC5-RRC message is sent.

In one embodiment, the first sidelink radio bearer and the second sidelink radio bearer may be associated with the same sidelink logical channel identification. The first or third PC5-RRC message may be an RRCRECONfigure Sidelink. The second or fourth PC5-RRC message may be an RRCRECONfigure CompleteSidelink.

In one embodiment, receiving a sidelink packet on a first sidelink radio bearer may be transmitted on a second sidelink radio bearer. The first or second sidelink radio bearer may be a Sidelink (SL) DRB.

Referring back to fig. 3 and 4, in one exemplary embodiment in which the first UE establishes a first sidelink radio bearer for transmitting sidelink packets from the first UE to the relay UE, wherein the first PC5-RRC message includes a first SLRB configuration of the first sidelink radio bearer and a sidelink logical channel identification associated with the first sidelink radio bearer. The first UE 300 includes program code 312 stored in memory 310. The CPU 308 may execute the program code 312 to enable the first UE to transmit a third PC5-RRC message to the second UE to establish a second side-link radio bearer for transmitting side-link packets from the relay UE to the second UE, wherein the third PC5-RRC message includes a second SLRB configuration of the second side-link radio bearer and a side-link logical channel identification associated with the second side-link radio bearer, and wherein the side-link logical channel identification is allocated by the first UE. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Fig. 23 is a flow diagram 2300 for establishing one or more side link logical channels to forward side link packets from a first UE to a second UE from the perspective of a relay UE, according to an example embodiment. In step 2305, the relay UE receives a first PC5-RRC message from the first UE to establish a first sidelink logical channel for transmitting sidelink packets from the first UE to the relay UE. In step 2310, the relay UE transmits a third PC5-RRC message to the second UE to establish a second sidelink logical channel for transmitting sidelink packets from the relay UE to the second UE, wherein the first sidelink logical channel and the second sidelink logical channel use the same sidelink logical channel identity.

Referring back to fig. 3 and 4, in one exemplary embodiment where the relay UE establishes one or more side link logical channels for forwarding side link packets from the first UE to the second UE. Relay UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a relay UE to: (i) Receiving a first PC5-RRC message from a first UE to establish a first sidelink logical channel for transmitting sidelink packets from the first UE to a relay UE, and (ii) transmitting a third PC5-RRC message to a second UE to establish a second sidelink logical channel for transmitting sidelink packets from the relay UE to the second UE, wherein the first sidelink logical channel and the second sidelink logical channel use the same sidelink logical channel identity. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Fig. 24 is a flowchart 2400 from the perspective of a relay UE for establishing one or more side link logical channels to forward side link packets from a first UE to a second UE, according to an example embodiment. In step 2405, the relay UE receives a first PC5-RRC message from the first UE to establish a first sidelink logical channel for transmitting sidelink packets from the first UE to the relay UE, wherein the first PC5-RRC message includes a first sidelink logical channel identification of the first sidelink logical channel. In step 2410, the relay UE transmits a third PC5-RRC message to the second UE to establish a second sidelink logical channel for transmitting sidelink packets from the relay UE to the second UE, wherein the third PC5-RRC message includes a second sidelink logical channel identity of the second sidelink logical channel, and the second sidelink logical channel identity is equal to the first sidelink logical channel identity.

Referring back to fig. 3 and 4, in one exemplary embodiment where the relay UE establishes one or more side link logical channels for forwarding side link packets from the first UE to the second UE. Relay UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a relay UE to: (i) Receiving a first PC5-RRC message from the first UE to establish a first sidelink logical channel for transmitting sidelink packets from the first UE to the relay UE, wherein the first PC5-RRC message includes a first sidelink logical channel identification of the first sidelink logical channel, and (ii) transmitting a third PC5-RRC message to the second UE to establish a second sidelink logical channel for transmitting sidelink packets from the relay UE to the second UE, wherein the third PC5-RRC message includes a second sidelink logical channel identification of the second sidelink logical channel, and the second sidelink logical channel identification is equal to the first sidelink logical channel identification. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

In the context of the embodiments shown in fig. 23 and 24 and described above, in one embodiment, the relay UE may transmit a second PC5-RRC message to the first UE, wherein the second PC5-RRC message is used to confirm that the relay UE is compliant with the first PC5-RRC message. Further, the relay UE may receive a fourth PC5-RRC message from the second UE, wherein the fourth PC5-RRC message is used to confirm compliance of the second UE with the third PC5-RRC message.

In one embodiment, the first PC5-RRC message may include a first SLRB configuration of the first side link logical channel. The third PC5-RRC message may include a second SLRB configuration of a second sidelink logical channel.

In one embodiment, the first PC5-RRC message may include the sl-LogicalChannelIdentity of the first sidelink logical channel set to a certain value. The third PC5-RRC message may include the sl-LogicalChannelIdentity of the second sidelink logical channel set to the value.

In one embodiment, the first PC5-RRC message may be received before the third PC5-RRC message is sent. The first sidelink logical channel and the second sidelink logical channel may use the same sidelink logical channel identification. The first or third PC5-RRC message may be an RRCRECONfigure Sidelink. The second or fourth PC5-RRC message may be an RRCRECONfigure CompleteSidelink.

In one embodiment, the relay UE may receive side link packets from the first UE on a first side link logical channel and may then forward them to the second UE via a second side link logical channel.

According to 3GPP TS 38.331, if the UE has a side-link packet to transmit to the peer UE, the UE transmits a PC5 RRC reconfiguration message (e.g., RRCRECONfigure Sidelink) to the peer UE to configure one or more side-link DRBs. Each SL DRB terminates at UE1 and UE 2. More specifically, each of these sidelink DRBs (established by the UE) is associated with a sidelink logical channel, and this logical channel uses a sidelink logical channel identity assigned by the UE. For inter-UE relay communication, each side link packet transmitted from UE1 to UE2 via the relay UE will be protected by the security context established between UE1 and UE 2. When encrypting these side link packets to be transmitted to UE2 via the relay UE, UE1 may need some other information in the security context than the security key.

For example, according to 3gpp TS 38.323, the other information may include side link logical channel identities (associated with one side link radio bearer used for transmitting these side link packets). Similarly, UE2 also needs this information to decrypt these received side link packets. According to 3GPP TR 38.836, for inter-UE relay communication, the adaptation layer at the first and second hops will be supported. If there is more than one SL DRB mapped to a single first-hop SL RLC channel, then when these packets are sent from UE1 to UE2 via relay UE, the first-hop adaptation layer in UE1 will be responsible for delivering the packets from the SL DRB to the particular first-hop SL RLC channel. Thus, UE2 will receive these packets from the relay UE, and the second hop adaptation layer in UE2 will be responsible for delivering the received packets from the second hop SL RLC channel to the specific SL DRB.

Because these side link packets are communicated from UE1 to the relay UE on the first hop SL RLC channel and then from the relay UE to UE2 on the second hop SL RLC channel, UE1 may encrypt the side link packets with the side link Logical Channel Identification (LCID) of the first hop SL RLC channel while UE2 may decrypt the received side link packets with the LCID of the second hop SL RLC channel. The LCID of the first hop SL RLC channel may be different from the LCID of the second hop SL RLC channel. In this case, the decryption result may be erroneous. Means to solve this problem should be considered.

In one alternative, UE1 may encrypt the side link packet using the identity of this SL DRB (i.e., radio Bearer (RB) Identity (ID)) instead of the LCID, and UE2 also decrypts the received side link packet using the same RB ID. In this alternative, the SL DRB at UE1 may be associated with the identity of the SL DRB (for ciphering on the SL DRB) and mapped to the first hop SL RLC channel. In one embodiment, the RB ID may be included in a header of the adaptation layer PDU such that UE2 may be aware of the RB ID associated with the received side link packet when receiving the adaptation layer PDU including the received side link packet from the relay UE, wherein the adaptation layer PDU includes at least the header and the side link packet.

More specifically, the identification of the SL DRB for encryption or decryption on the SL DRB may be assigned by UE1 or a base station (e.g., gNB) serving UE1. The RB ID for encryption or decryption as described above may also be replaced with an index of the side link DRB configuration of the SL DRB (e.g., SLRB-Uu-ConfigIndex or SLRB-PC 5-ConfigIndex). And, the index of the side link DRB configuration may be included in the header of the adaptation layer PDU.

Alternatively, the encrypted side link channel or bearer identification used to map onto the SL DRB of the first-hop SL RLC channel may be an identification of the second-hop SL RLC channel (i.e., the LCID of the second-hop SL RLC channel). UE2 may decrypt the side link packet on the SL DRB mapped to the second-hop SL RLC channel based on the identity of the second-hop SL RLC channel. In this alternative, the LCID of the second hop SL RLC channel should be sent to UE1 by the relay UE, e.g. via a PC5 RRC message.

More specifically, the LCID of the second hop SL RLC channel may be allocated by the relay UE or a base station (e.g., gNB) serving such relay UE. An index for setting up a side link logical channel configuration of the second-hop SL RLC channel for ciphering or deciphering as described above may also be used.

Alternatively, the encrypted side link channel or bearer identification used to map onto the SL DRB of the first-hop SL RLC channel may be an identification of the first-hop SL RLC channel (i.e., the LCID of the first SL RLC channel). UE2 may decrypt the side link packets on the SL DRB mapped to the second-hop SL RLC channel based on the identity of the first-hop SL RLC channel. In this alternative, the LCID of the first hop SL RLC channel should be sent to UE2 by the relay UE, e.g. via a PC5 RRC message.

More specifically, the LCID of the first hop SL RLC channel may be allocated by UE1 or a base station (e.g., gNB) serving UE 1. An index for setting up a side link logical channel configuration of the first-hop SL RLC channel for ciphering or deciphering as described above may also be used.

More specifically, UE1 may send a first rrcrecon configuration sip link message to the relay UE to establish the first hop SL RLC channel. The first rrcrecon configuration sidelink message sent from UE1 to the relay UE may contain the RB ID of the SL DRB and/or the LCID of the first hop SL RLC channel.

More specifically, the relay UE may send a second rrcrecon configuration sip link message to UE2 to establish the second-hop SL RLC channel. The second rrcrecconfiguration sidelink message sent from the relay UE to UE2 may contain the RB ID of the SL DRB and/or the LCID of the second hop SL RLC channel. The second rrcrecon configuration sidelink message may also contain LCID of the first hop SL RLC channel.

More specifically, the relay UE may send a third rrcrecon configuration sip link message to UE1, wherein the third rrcrecon configuration sip link message may include the LCID of the second hop SL RLC channel. More specifically, the LCID of the first-hop SL RLC channel may be the same or different than the LCID of the second-hop SL RLC channel. Such side link packets may be IP packets, non-IP packets, SDAP PDUs, and/or PDCP PDUs.

In one embodiment, the relay UE mentioned above may be a layer 2 (layer 2 based) relay.

Fig. 25 is a flowchart 2500 from the perspective of a first remote UE, according to an example embodiment. In step 2505, the first remote UE establishes a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE, wherein the SL DRB is associated with the RB ID. In step 2510, the first remote UE encrypts a side-link packet to be sent to the second remote UE on the SL DRB based on the RB ID.

In one embodiment, a first remote UE may establish a first SL RLC channel for transmission from the first remote UE to a relay UE, wherein the first SL RLC channel is identified by a first LCID.

Referring back to fig. 3 and 4, in one exemplary embodiment of the first remote UE. The first remote UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a first remote UE to: (i) Establishing a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE, wherein the SL DRB is associated with an RB ID, and (ii) encrypting side link packets to be sent to the second remote UE on the SL DRB based on the RB ID. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Fig. 26 is a flowchart 2600 from the perspective of a first remote UE, according to an example embodiment. In step 2605, the first remote UE establishes a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE. In step 2610, the first remote UE establishes a first SL RLC channel for transmission from the first remote UE to the relay UE, wherein the first SL RLC channel is identified by the first LCID. In step 2615, the first remote UE encrypts a side link packet to be sent to the second remote UE on the SL DRB based on a second LCID associated with a second SL RLC channel established between the relay UE and the second remote UE.

Referring back to fig. 3 and 4, in one exemplary embodiment of the first remote UE. The first remote UE 300 includes program code 312 stored in memory 310. CPU308 may execute program code 312 to enable a first remote UE to: (i) establishing a SL DRB for transmission from a first remote UE to a second remote UE via a relay UE, (ii) establishing a first SL RLC channel for transmission from the first remote UE to the relay UE, wherein the first SL RLC channel is identified by a first LCID, and (iii) encrypting side link packets to be sent to the second remote UE on the SL DRB based on a second LCID associated with the second SL RLC channel, wherein the second SL RLC channel is established between the relay UE and the second remote UE. Further, the CPU308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

In the context of the embodiments shown in fig. 25 and 26 and described above, in one embodiment, the first remote UE may deliver side link packets from the SL DRB to the first SL RLC channel based on a mapping of RB IDs and first LCIDs. The SL DRB may map to the first SL RLC channel. The side link packet may be sent from a first remote UE to a relay UE on a first SL RLC channel and then forwarded from the relay UE to a second remote UE on a second SL RLC channel. The RB ID may be included in a header of the adaptation layer PDU.

In one embodiment, the header and side link packets may be included in an adaptation layer PDU. The relay UE may be a layer 2 (layer 2 based) relay.

Fig. 27 is a flowchart 2700 from the perspective of a second remote UE according to an example embodiment. In step 2705, the second remote UE establishes a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE, wherein the SL DRB is associated with the RB ID. In step 2710, the second remote UE decrypts the side link packet received from the first remote UE via the relay UE on the SL DRB based on the RB ID.

In one embodiment, the second remote UE may establish a second SL RLC channel for reception from the relay UE, wherein the second SL RLC channel is identified by a second LCID.

Referring back to fig. 3 and 4, in one exemplary embodiment of the second remote UE. The second remote UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a second remote UE to: (i) Establishing a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE, wherein the SL DRB is associated with an RB ID, and (ii) decrypting side link packets received on the SL DRB from the first remote UE via the relay UE based on the RB ID. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Fig. 28 is a flow chart 2800 from the perspective of a second remote UE according to an example embodiment. In step 2805, the second remote UE establishes a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE. In step 2810, the second remote UE establishes a second SL RLC channel for reception from the relay UE, wherein the second SL RLC channel is identified by a second LCID. In step 2815, the second remote UE decrypts the sidelink packet received on the SL DRB from the first remote UE via the relay UE based on the first LCID associated with the first SL RLC channel established between the relay UE and the first remote UE.

Referring back to fig. 3 and 4, in one exemplary embodiment of the second remote UE. The second remote UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a second remote UE to: (i) establishing a SL DRB for transmission from the first remote UE to the second remote UE via the relay UE, (ii) establishing a second SL RLC channel for reception from the relay UE, wherein the second SL RLC channel is identified by the second LCID, and (iii) decrypting side-link packets received on the SL DRB from the first remote UE via the relay UE based on the first LCID associated with the first SL RLC channel, wherein the first SL RLC channel is established between the relay UE and the first remote UE. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

In the context of the embodiments shown in fig. 27 and 28 and described above, in one embodiment, side link packets may be sent from a first remote UE to a relay UE on a first SL RLC channel and then may be forwarded from the relay UE to a second remote UE on a second SL RLC channel. The RB ID may be included in a header of the adaptation layer PDU. The header and side link packets may be included in the adaptation layer PDU. The relay UE may be a layer 2 (layer 2 based) relay.

Fig. 29 is a flow chart 2900 from the perspective of a first remote UE according to an example embodiment. In step 2905, the first remote UE establishes a first SL DRB for transmission to the second remote UE via the relay UE, wherein the first SL DRB is identified by the RB ID. In step 2910, the first remote UE encrypts a side link packet to be transmitted to the second remote UE via the relay UE on the first SL DRB based at least on the RB ID.

In one embodiment, a first remote UE may establish a first SL RLC channel for transmission to a relay UE, wherein the first SL RLC channel is identified by a first LCID and a SL DRB is mapped to the first SL RLC channel.

In one embodiment, the RB ID may be included in a header of the adaptation layer PDU. The header and side link packets may be included in the adaptation layer PDU.

In one embodiment, the first remote UE may establish a second SL DRB for direct transmission to the third UE, wherein the second SL DRB maps to a second SL RLC channel and the second SL RLC channel is identified by a second LCID. The first remote UE may also encrypt a side link packet to be sent to the third UE on the second SL DRB based at least on the second LCID.

Referring back to fig. 3 and 4, in one exemplary embodiment of the first remote UE. The first remote UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a first remote UE to: (i) Establishing a first SL DRB for transmission via the relay UE to the second remote UE, wherein the first SL DRB is identified by an RB ID, and (ii) encrypting side link packets sent on the first SL DRB via the relay UE to the second remote UE based at least on the RB ID. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Fig. 30 is a flowchart 3000 from the perspective of a second remote UE, according to an example embodiment. In step 3005, the second remote UE establishes a first SL DRB for reception from the first remote UE via the relay UE, wherein the first SL DRB is identified by the RB ID. In step 3010, the second remote UE decrypts the side-link packet received from the first remote UE via the relay UE on the first SL DRB based at least on the RB ID.

In one embodiment, the second remote UE may establish a first SL RLC channel for reception from the relay UE, wherein the first SL RLC channel is identified by the first LCID and the first SL DRB is mapped to the first SL RLC channel.

In one embodiment, the second remote UE may establish a second SL DRB for direct reception from the third UE, wherein the second SL DRB maps to a second SL RLC channel and the second SL RLC channel is identified by a second LCID. The second remote UE may also decrypt a side link packet received from the third UE on the second SL DRB based at least on the second LCID.

Referring back to fig. 3 and 4, in one exemplary embodiment of the second remote UE. The second remote UE 300 includes program code 312 stored in memory 310. CPU 308 may execute program code 312 to enable a second remote UE to: (i) Establishing a first SL DRB for reception from a first remote UE via a relay UE, wherein the first SL DRB is identified by an RB ID, and (ii) decrypting side link packets received on the first SL DRB from the first remote UE via the relay UE based at least on the RB ID. Further, the CPU 308 may execute the program code 312 to perform all of the above-described acts and steps, as well as other acts and steps described herein.

Various aspects of the disclosure have been described above. It should be apparent that the teachings herein may be embodied in a wide variety of forms and that any specific structure, function, or both being disclosed herein is merely representative. Based on the teachings herein one skilled in the art should appreciate that an aspect disclosed herein may be implemented independently of any other aspects and that two or more of these aspects may be combined in various ways. For example, an apparatus may be implemented or a method practiced using any number of the aspects set forth herein. Moreover, such an apparatus may be implemented or such a method may be practiced using other structure, functionality, or structure and functionality in addition to or other than one or more of the aspects set forth herein. As an example of some of the concepts described above, in some aspects, parallel channels may be established based on pulse repetition frequencies. In some aspects, parallel channels may be established based on pulse position or offset. In some aspects, parallel channels may be established based on a time hopping sequence. In some aspects, parallel channels may be established based on pulse repetition frequency, pulse position or offset, and time hopping sequences.

Those of skill in the art would 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 voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, processors, means, circuits, and algorithm steps described in connection with the 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 coding or some other technique), and various forms of program or design code with instructions (which may be referred to herein as "software" or "software modules" for convenience), or combinations of both. To clearly illustrate this 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 upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

Further, the various illustrative logical blocks, modules, and circuits described in connection 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 (digital signal processor, DSP), an application specific integrated circuit (application specific integrated circuit, ASIC), a field programmable gate array (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, external to 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, e.g., 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.

It should be understood that any particular order or hierarchy of steps in any disclosed process is an example of an example approach. It should be understood that the particular order or hierarchy of steps in the process may be rearranged based on design preferences while remaining within the scope of the present disclosure. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

The steps of a method or algorithm described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. Software modules (e.g., including executable instructions and associated data) and other data may reside in a data memory, such as RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, 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 (which may be referred to herein as a "processor" for convenience), such that the processor can read information (e.g., code) from, and write information to, the storage medium. An example storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user equipment. In the alternative, the processor and the storage medium may reside as discrete components in a user device. Furthermore, in some aspects, any suitable computer program product may comprise a computer-readable medium comprising code relating to one or more of the aspects of the disclosure. In some aspects, the computer program product may include packaging material.

While the invention has been described in connection with various aspects, it will be appreciated that the invention is capable of further modifications. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the invention and including such departures from the present disclosure as come within known and customary practice within the art to which the invention pertains.

Claims

1. A method for a first user device, comprising:

establishing a side link data radio bearer for transmission via a relay user equipment to a second user equipment or for direct transmission to the second user equipment, wherein a configuration of the side link data radio bearer is identified by a configuration index, and the side link data radio bearer is mapped to a link radio link control channel,

wherein the side link radio link control channel is established between the first user equipment and the relay user equipment or between the first user equipment and the second user equipment, wherein the side link radio link control channel is identified by a logical channel identification;

encrypting a side link packet to be sent to the second user equipment via the relay user equipment on the side link data radio bearer if the side link data radio bearer is established for the transmission to the second user equipment via the relay user equipment using at least the configuration index as an input to an encryption algorithm; and

And if the side link data radio bearer is established for the direct transfer to the second user equipment, encrypting a side link packet to be sent directly to the second user equipment on the side link data radio bearer using at least the logical channel identification as an input to an encryption algorithm.

2. The method of claim 1, wherein the configuration index is included in a header of an adaptation layer packet data unit.

3. The method of claim 2, wherein the header and the side link packet are included in the adaptation layer packet data unit.

4. A method for a second user device, comprising:

establishing a side link data radio bearer for reception from a first user equipment via a relay user equipment or for direct reception from the first user equipment, wherein a configuration of the side link data radio bearer is identified by a configuration index, and the side link data radio bearer is mapped to a link radio link control channel,

wherein the side link radio link control channel is established between the second user equipment and the relay user equipment or between the first user equipment and the second user equipment, wherein the side link radio link control channel is identified by a logical channel identification;

If the side link data radio bearer is established for the reception from the first user equipment via the relay user equipment, decrypting a side link packet received from the first user equipment via the relay user equipment on the side link data radio bearer using at least the configuration index as an input to a decryption algorithm; and

and if the side link data radio bearer is established for the direct reception from the first user equipment, decrypting a side link packet to be received directly from the first user equipment on the side link data radio bearer using at least the logical channel identification as an input to a decryption algorithm.

5. The method of claim 4, wherein the configuration index is included in a header of an adaptation layer packet data unit.

6. The method of claim 5, wherein the header and the side link packet are included in the adaptation layer packet data unit.

7. A first user device, comprising:

a control circuit;

a processor mounted in the control circuit; and

a memory mounted in the control circuit and operatively coupled to the processor;

Wherein the processor is configured to execute program code stored in the memory to:

8. The first user equipment of claim 7, wherein the configuration index is included in a header of an adaptation layer packet data unit.

9. The first user device of claim 8, wherein the header and the side link packet are included in the adaptation layer packet data unit.