Link control for layer 2 (L2) user equipment (UE) to UE (U2U) relay

Abstract

In one aspect, a user equipment (UE) acting as a source remote UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, is configured to establish a public or mission critical 5 (PC5) link with a target remote UE through a relay UE. The PC5 link is assigned a pair of local IDs identifying the source remote UE and the target remote UE. The UE is further configured to transmit to the relay UE, a link modification request to modify the PC5 link and receive, from the relay UE, a configuration information to release the pair of local IDs or add a new pair of local IDs. In a further aspect, the UE is also be configured to transmit, to the relay UE, QoS information indicating the QoS requirements and receive, from the relay UE, split QoS information indicating after split QoS requirements per target remote UE

Description

LINK CONTROL FOR LAYER 2 (L2) USER EQUIPMENT (UE) TO UE (U2U) RELAYFIELD

[0001] This disclosure relates to wireless communication networks including techniques for PC5 link control for L2 U2U relay.BACKGROUND

[0002] As the number of mobile devices within wireless networks, and the demand for mobile data traffic, continue to increase, changes are made to system requirements and architectures to better address current and anticipated demands. New features and enhancements continue to evolve to include solutions for efficiency and reliability. For example, some wireless communication networks (e.g., fifth generation (5G) or new radio (NR) networks) may be developed to include UE to UE (U2U) sidelink relay communication.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals may designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and may mean at least one, one or more, etc.

[0004] Fig. 1 illustrates a diagram showing examples of UE to UE (U2U) relay communications in accordance with various aspects.

[0005] Fig. 2 illustrates a signaling diagram including link establishment and release for Layer 2 (L2) UE to UE (U2U) relay communications in accordance with various aspects.

[0006] Fig. 3 illustrates a signaling diagram including link modification for L2 U2U relay communications in accordance with various aspects.

[0007] Fig. 4A illustrates an example of a link modification operation code information element in accordance with various aspects.

[0008] Fig. 4B and Fig. 4C illustrate examples of bits information indicating various link modification operation in accordance with various aspects.

[0009] Fig. 5A illustrates example control plane protocol stacks using a L2 U2U Relay according to various aspects.

[0010] Fig. 5B illustrates user plane protocol stacks using a a L2 U2U Relay according to various aspects.

[0011] Fig. 6 illustrates a diagram showing an example of a control plane protocol stack for per-hop controls of L2 U2U relay communications in accordance with various aspects.

[0012] Fig. 7 illustrates a signaling diagram of QoS flow maintenance for L2 U2U relay communications in accordance with various aspects.

[0013] Fig. 8 illustrates an ASN. 1 example for QoS information reporting in accordance with various aspects.

[0014] Figs. 9A-9B illustrate ASN. 1 examples for QoS information reporting respectively for QoS information reporting and split QoS information reporting in accordance with additional aspects.

[0015] Fig. 10 illustrates an ASN. 1 example for QoS information reporting including the SDAP mapping of the QoS flows to SLRBs included in UE information request message in accordance with various aspects.

[0016] Fig. 11 illustrates a signaling diagram of QoS flow maintenance for L2 U2U relay communications including base station assistance in accordance with various aspects.

[0017] Fig. 12 illustrates an ASN. 1 example for QoS information reporting including base station assistance in accordance with various aspects.

[0018] Fig. 13 illustrates an ASN. 1 example for QoS information reporting including base station assistance in accordance with additional aspects.

[0019] Fig. 14 illustrates a flow diagram showing L2 U2U relay communications in accordance with various aspects.

[0020] Fig. 15 illustrates a flow diagram showing L2 U2U relay communications in accordance with additional aspects.

[0021] Fig. 16 illustrates a flow diagram showing L2 U2U relay communications in accordance with further aspects.

[0022] Fig. 17 is a block diagram of some aspects of a wireless communication network according to one or more implementations described herein.

[0023] Fig. 18 is a diagram of some aspects of components of a device according to one or more implementations described herein.

[0024] Fig. 19 is a diagram of example interfaces of baseband circuitry according to one or  more implementations described herein.DETAILED DESCRIPTION

[0025] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0026] In a system architectural level, proximity service (ProSe) is a feature that specifies the architecture of direct communication between user equipments (UEs) . Direct communication between UEs can use a public or mission critical 5 (PC5) interface. PC5 interface was originally defined to address the needs of mission-critical communication for public safety community (Public Safety-LTE, or PS-LTE) , in order to allow law enforcement agencies or emergency rescue to use the radio communication even when the infrastructure is not available, such as in a natural disaster scenario. Later, the use of PC5 interface has been expanded to meet various commercial needs, such as communication involving wearable devices such as smartwatch. PC5 interface can be re-applied to the direct communication in mobile devices including UEs or Vehicle UEs. In 3rd generation partnership project (3GPP) specifications, "sidelink" is the terminology to refer to the direct communication over PC5. In this case, the communication with the base station is not required.

[0027] Sidelink communication may be performed by two or more UEs inside and outside of radio network, in order to bypass and offload the base station, to facilitate direct device-to-device communication, and to enable a quick exchange of data over a short period. In addition, sidelink communication can also serve as relay operations including UE to network (U2N) relay and UE to UE (U2U) relay for coverage extension. U2N relay provides connectivity to the network for U2N remote UE (s) . U2U relay provides connectivity and coverage extension of the sidelink transmissions between U2U remote UEs via a U2U relay UE. A PC5 link is established including a pair of hops between a source remote UE and the U2U relay UE and between the U2U relay UE and a target remote UE.

[0028] As will be described in more detail below, when establishing the PC5 link end-to-end for layer 2 (L2) U2U relay, a pair of local IDs is assigned by the U2U relay UE based on L2 IDs of the source remote UE and the target remote UE. The local ID pair is used as a joint linking two per-hop PC5 links. The two local IDs are encapsulated in “SRC UE ID” and “DST UE ID” fields in SRAP header. Notified by a per-hop direct link modification operation using PC5  signaling (PC5-S) , the U2U relay UE adds or removes the local ID pair, such that PC5 links are properly maintained for L2 U2U relay in accordance with various aspects.

[0029] In some further aspects, QoS flow maintenance is enhanced by source remote UE tracking QoS flows on sidelink radio bearer (SLRB) and reporting to the U2U relay UE indicating QoS information per SLRB. The U2U relay UE then performs quality of service (QoS) split per sidelink radio bearer (SLRB) or per QoS flow, using a PC5 radio resource control (RRC) signaling. Another option is to let the relay UE split the QoS per flow, but the remote UE or relay UE would generate the per-SLRB QoS based on after-split per-flow QoS. This options requires the QoS-flow-to-SLRB needs to be conveyed from remote UE to the relay UE. By performing QoS split per SLRB rather than per QoS flow, the U2U relay UE can correctly identify the required after split QoS for the ingress SLRB traffic and determine a corresponding PC5 relay RLC channel based on the bearer ID that is included in the SRAP header. The per-SLRB option also helps to reduce the signaling overhead.

[0030] The U2U relay UE or the source remote UE can determine, or solicit a base station to determine, PC5 relay RLC channels based on the per SLRB QoS information. In some further aspects, the PC5 RRC signaling may also be used to report L2 ID change and trigger local ID pair modification, if needed, when there is a link modification or link identifier update procedure triggered.

[0031] Fig. 1 illustrates a diagram 100 showing an example of U2U relay communications in accordance with various aspects. As shown in Fig. 1, a U2U relay UE 110-R can be connected with one or more source remote UEs, such as a first source remote UE 110-S1 and a second source remote UE 110-S2 respectively via a first ingress hop H10 and a second ingress hop H20. The U2U relay UE 110-R can further connect with one or more target remote UEs, such as a first target remote UE 110-T1 and a second target remote UE 110-T2 respectively via a first egress hop H01 and a second egress hop H02. The U2U UEs are connected with one another via PC5 interfaces. This way, the source remote UEs 110-S1, 110-S2 and the target remote UEs 110-T1, 110-T2 that are not directly reachable from one another within the sidelink coverage are communicated via the U2U relay UE 110-R. As an example, a first PC5 link may be established for a first pair of remote UEs (e.g., the first source remote UE 110-S1 and the first target remote UE 110-T1) using the first ingress hop H10 and the first egress hop H01. A second PC5 link may be established for a second pair of remote UEs (e.g., the first source remote UE 110-S1 and the second target remote UE 110-T2) using the first ingress hop H10 and the second egress hop H02. The second PC5 link may be supported concurrently with the first PC5 link, or replace the first PC5 link.

[0032] When the second PC5 link replaces the first PC5 link, the first ingress hop H10 is still in use by the second PC5 link and thus needs to be maintained, while the first egress hop H01 is not in use anymore and needs to be removed. Also, the second egress hop H02 needs to be newly added with the second target remote UE 110-T2 added as a new target remote UE. The removal of the first egress hop H01 and the first target remote UE 110-T1 should be properly notified to the U2U relay UE 110-R. In addition, after adding a new end-to-end PC5 link, the relay UE (e.g., U2U relay UE 110-R, or a different re-selected relay UE) needs to be properly informed about the new UEs in use in upper layer, such that the relay UE triggers AS layer properly.

[0033] In some aspects (ASPECT 1) , per-hop direct link establishment and modification operations are supported for L2 U2U relay link maintenance using PC5 signaling (PC5-S) . For example, after receiving a link modification request, the U2U relay UE (e.g., U2U relay UE 110-R) forwards the link modification request to the old target remote UE (e.g., first target remote UE 110-T1) , and removes or replaces the local ID pair after receiving a link modification acceptance. The U2U relay UE (e.g., U2U relay UE 110-R) may also transmit a direct link establishment request to the new target remote UE (e.g., the second target remote UE 110-T2) , and assign a new local ID pair after receiving a direct link establishment acceptance. By implementing direct link modification procedures, PC5 links are properly maintained for L2 U2U relay in accordance with various aspects.

[0034] In some further aspects (ASPECT 2) , QoS flow maintenance is enhanced by a source remote UE (e.g., the first source remote UE 110-S1) tracking QoS flows on sidelink radio bearer (SLRB) and reporting to a U2U relay UE (e.g., the U2U relay UE 110-R) indicating QoS information per SLRB (rather than per QoS flow) . The U2U relay UE (e.g., the U2U relay UE 110-R) then performs quality of service (QoS) split per SLRB using a PC5 radio resource control (RRC) signaling. The U2U relay UE (e.g., U2U relay UE 110-R) or the source remote UE (e.g., the first source remote UE 110-S1) can determine, or solicit a base station to determine, PC5 relay RLC channels based on the per SLRB QoS information and the bearer ID that is included in the SRAP header. In some further aspects, the PC5 RRC signaling may also be used to report L2 ID change and trigger local ID pair modification when there is a link modification.

[0035] Fig. 2 illustrates a signaling diagram including link establishment and release for L2 U2U relay communications in accordance with various aspects. As shown in Fig. 2, a U2U relay UE 110-R can be connected with a first source remote UE 110-S1 via a first ingress hop H10 and further connected with a first target remote UE 110-T1 via a first egress hop H01. Both the first ingress hop H10 and the first egress hop H01 are via PC5 interfaces. This way, the first source remote UE 110-S1 and the first target remote UE 110-T1 that are not directly reachable within  the sidelink coverage are communicated via the U2U relay UE 110-R. In some aspects, acts 101 show a general concept of PC5 link establishment, and acts 103 show a general concept of PC5 link release for L2 U2U relay communication.

[0036] For link establishment, after sidelink establishment between the first source remote UE 110-S1 and the first target remote UE 110-T1 via the U2U relay UE 110-R, end-to-end PC5 link connection establishment is performed between the first source remote UE 110-S1 and the first target remote UE 110-T1.

[0037] In some aspects, at act 1.1, a discovery and selection process is performed. To perform ProSe U2U relay discovery, the first source remote UE 110-S1, the first target remote UE 110-T1, and the U2U relay UE 110-R may be pre-configured or provisioned with the related information among other available UEs. For example, information provisioned in a UE in support of the UE assuming the role of a U2U relay UE may include: authorization policy for acting as a ProSe L2 UE-to-UE relay and ProSe relay discovery policy / parameters for ProSe UE-to-UE Relay. In some aspects, multiple modes may be supported for ProSe U2U relay discovery, such as Model A that uses a single discovery protocol message by one-way announcement, Model B that uses two discovery protocol messages by solicitation and response procedures, or an integrated discovery procedure. For Model A, the U2U relay UE 110-R may transmit a U2U relay discovery announcement message respectively to the first source remote UE 110-S1 and the first target remote UE 110-T1, after the U2U relay UE 110-R has discovered other UEs in proximity. The U2U relay discovery announcement message may include the type of discovery message, user information IDs of the U2U relay UE 110-R and / or other UEs in proximity. For Model B, as an example, a solicitation message is sent by source remote UE 110-S to the U2U relay UE 110-R and further received by the first target remote UE 110-T1. If information matches, the U2U relay UE 110-R sends a ProSe U2U relay discovery response message. The ProSe U2U relay discovery response message may include the type of discovery message, user information IDs of the U2U relay UE 110-R and / or other UEs in proximity including the first source remote UE 110-S1 and the first target remote UE 110-T1.

[0038] After discovery, the first source remote UE 110-S1 selects a suitable U2U relay UE (110-R) for the communication with the first target remote UE 110-T1.

[0039] In some aspects, at acts 1.2A and 1.2B, PC5 L2 per-hop link establishment procedures are performed between the U2U relay UE 110-R and the first source remote UE 110-S1 (act 1.2A) and also between the U2U relay UE 110-R and the first target remote UE 110-T1 (act 1.2B) .

[0040] At act 1.3, after and based on the establishment of two PC5 L2 per-hop link  establishment procedures (e.g., act 1.2A, 1.2B) , the U2U relay UE 110-R is triggered to allocate a pair of local IDs for the end-to-end PC5 link connection establishment of the first source remote UE 110-S1 and the first target remote UE 110-T1. The pair of local IDs is respectively associated the L2 IDs or user information IDs of the first source remote UE 110-S1 and the first target remote UE 110-T1. For example, a pair of local IDs <1, 1> may be allocated by the U2U relay UE 110-R for the end-to-end PC5 link connection establishment of the first source remote UE 110-S1 and the first target remote UE 110-T1.

[0041] At acts 1.3A, 1.3B, a PC5-RRC message is communicated from the U2U relay UE 110-R respectively to the first source remote UE 110-S1 and the first target remote UE 110-T1 to assign the pair of local IDs. As an example, the PC5-RRC message may be a RRC reconfiguration sidellink message such as “RRCReconfigurationSidelink” . In some aspects, optionally, PC5 relay RLC channels are assigned for end-to-end sidelink data radio bearers (SL-DRB (s) ) .

[0042] At act 1.4, the end-to-end PC5 link connection establishment is completed. In one aspect, the end-to-end PC5 link connection establishment includes a PC5-RRC request transmitted from the first source remote UE 110-S1 and a PC5-RRC acceptance response transmitted from the first target remote UE 110-T1. The PC5-RRC request and the PC5-RRC acceptance response may be associated with the assigned pair of local IDs and default PC5 Relay RLC Chanel for SL SRB (s) . For example, the PC5-RRC request uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB0. The PC5-RRC acceptance response uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB2.

[0043] At act 102, after the end-to-end PC5 link connection is established, data communication can be performed between the first source remote UE 110-S1 and the first target remote UE 110-T1 using relay traffic via the U2U relay UE 110-R, until a release event or a modification event presents. In some aspects, the release event triggers link release acts 103.

[0044] For link release as shown by acts 103, end-to-end PC5 link release is firstly communicated between the first source remote UE 110-S1 and the first target remote UE 110-T1. Then per-hop link modification procedures are performed on PC5-S messages before local ID pair release.

[0045] At act 2.1, the PC5 link is released end-to-end. In one aspect, the end-to-end PC5 link release includes a request transmitted from the first source remote UE 110-S1 and an acceptance response transmitted from the first target remote UE 110-T1. The request and the acceptance response are PC5-S signalling performed end-to-end. The request and the acceptance response  may be associated with the assigned pair of local IDs <1, 1> and default PC5 Relay RLC Chanel for SL SRB (s) . For example, the PC5-RRC request uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB0. The PC5-RRC acceptance response uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB2.

[0046] At acts 2.2A and 2.2B, in some aspects, PC5 L2 per-hop link release procedures are performed between the U2U relay UE 110-R and the first source remote UE 110-S1 (act 2.2A) and also between the U2U relay UE 110-R and the first target remote UE 110-T1 (act 2.2B) .

[0047] At acts 2.3A, 2.3B, a PC5-RRC message is communicated from the U2U relay UE 110-R respectively to the first source remote UE 110-S1 and the first target remote UE 110-T1 to release the pair of local IDs. As an example, the PC5-RRC message may be a RRC reconfiguration sidelink message such as “RRCReconfigurationSidelink” .

[0048] Fig. 3 illustrates a signaling diagram including link modification for L2 U2U relay communications in accordance with various aspects. Fig. 3 may be applied to L2 U2U relay communications together with Fig. 2 or standalone separately from Fig. 2. As shown in Fig. 3, a U2U relay UE 110-R can be connected with the first source remote UE 110-S1 via a first ingress hop H10 and further connected with a second target remote UE 110-T2 that is newly added to the relay communication via a second egress hop H02, such that a new PC5 link is established between the first source remote UE 110-S1 and the second target remote UE 110-T2. As discussed associated with Fig. 1 and Fig. 2, the first ingress hop H10 is maintained while the second egress hop H02 is newly added. The U2U relay UE 110-R needs to assign a new local ID pair (e.g., local ID pair =<1, 2>) for the newly PC5 link. The first source remote UE 110-S1 may decide to add the new PC5 link (e.g., local ID pair =<1, 2>) in parallel to the previously established PC5 link (e.g., local ID pair =<1, 1>) or replace the previously established PC5 link (e.g., local ID pair =<1, 1>) with the new PC5 link (e.g., local ID pair =<1, 2>) . The initiation of the link modification may be triggered by act 3.1, where the first source remote UE 110-S1 decides to change or add a PC5 link.

[0049] In some aspects, PC5 L2 link establishment / modification procedures are performed per-hop for L2 U2U relay. The PC5 L2 link establishment / modification procedures are performed between the U2U relay UE 110-R and the source remote UE (e.g., the first source remote UE 110-S1) (act 3.2A-1, act 3.2A-2) and also between the U2U relay UE 110-R and the target remote UE (e.g. the second target remote UE 110-T2 (act 3.2B-1, act 3.2B-2) . An example is provided below for a scenario where the first source remote UE 110-S1 maintained the same as the source remote UE of the previous PC5 link, and the second target remote UE 110-T2 is a target remote UE newly added.

[0050] At act 3.2A-1, in some aspects, the link modification request message for L2 U2U relay adopts the ProSe direct link modification procedure. The additional target remote UE is added and uses existing ProSe direct link between the current source remote UE (e.g., 110-S1) and the U2U relay UE 110a. A link modification request message is transmitted from the first source remote UE 110-S1 to the U2U relay UE 110-R. The link modification request message may include or indicate local IDs, L2 IDs, and / or user information IDs of the first source remote UE 110-S1 and the second target remote UE 110-T2. The link modification request message may also include an information element including or indicating a link modification operation code in accordance with various aspects. Examples of the link modification operation code are provided below associated with Figs. 4A-4C. At act 3.2B-1 and 3.2B-2, direct link establishment request and accept messages are communicated between the U2U relay UE 110-R and the second target remote UE 110-T2. After receiving the direct link establishment accept message from the second target remote UE 110-T2, the U2U relay UE 110-R transmits a link modification accept message to the first source remote UE 110-S1. The direct link establishment accept message from the second target remote UE 110-T2 may include the source remote UE info set to the user info ID of the first source remote UE 110-S1 and the target remote UE info set to the user info ID of the second target remote UE 110-T2. The link modification accept message from the U2U relay UE 110-R may include the second target remote UE info set to the user info ID of the second target remote UE 110-T2. The link modification request and accept messages are PC5-S signalling performed by hop.

[0051] At act 3.3, after and based on the PC5 L2 per-hop link establishment / modification procedures, the U2U relay UE 110-R is triggered to allocate local ID pairs for the end-to-end PC5 link connection establishment / modification of the first source remote UE 110-S1 and the second target remote UE 110-2T. A pair of local IDs may be respectively associated the L2 IDs or user information IDs of the first source remote UE 110-S1 and the second target remote UE 110-T2. For example, a pair of local IDs <1, 2> may be allocated by the U2U relay UE 110-R for the end-to-end PC5 link connection establishment. The old pair of local IDs <1, 1> as described in Fig. 2 may be released by the U2U relay UE 110-R.

[0052] At acts 3.3A, 3.3B, a PC5-RRC message is communicated from the U2U relay UE 110-R respectively to the first source remote UE 110-S1 and the second target remote UE 110-T2 to configure the L2 U2U relay communication. As an example, the PC5-RRC message may be a RRC reconfiguration sidelink message such as “RRCReconfigurationSidelink” . In some aspects, the U2U relay UE 110-R assigns the new pair of local IDs <1, 2>. Optionally, PC5 relay RLC channels are assigned for end-to-end sidelink data radio bearers (SL-DRB (s) ) .

[0053] At acts 3.4-1, 3.4-2, the end-to-end PC5 link connection establishment is completed. In one aspect, the end-to-end PC5 link connection establishment includes a request (act 3.4-1) transmitted from the first source remote UE 110-S1 and an acceptance response (act 3.4-2) transmitted from the second target remote UE 110-T2. The request and the acceptance response are PC5-S signalling performed end-to-end. The request and the acceptance response may be associated with the assigned pair of local IDs <1, 2> and default PC5 Relay RLC Chanel for SL SRB (s) . For example, the PC5-RRC request uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB0. The PC5-RRC acceptance response uses the pair of local IDs (e.g. <1, 1>) assigned and default PC5 Relay RLC Chanel for SL SRB2. In some aspects, specified PC5 relay RLC channel configuration is used on each hop.

[0054] Fig. 4A illustrates an example of a link modification operation code information element in accordance with various aspects. In the example, the link modification operation code is a type 3 information element, with a length of 2 octets. A first octet, OCTET1, includes information identifying link modification operation code information element. A second octet, OCTET2, includes bits information indicating various link modification operation. For example, a list of link modification operation codes is provided, including a code to add a new remote UE or remove an existing remote UE for the L2 U2U relay communication.

[0055] Fig. 4B and Fig. 4C illustrate examples of bits information indicating various link modification operation in accordance with various aspects. As shown by Fig. 4B and Fig. 4C as examples, the code (s) can be separate (e.g., Fig. 4B) or combined (e.g., Fig. 4C) for adding / removing layer 2 or layer 3 end (i.e., remote) UEs. The content of Fig. 4B and Fig. 4C is incorporated as entireties and not repeated herein.

[0056] Fig. 5A illustrates example control plane protocol stacks using a L2 U2U Relay according to various aspects. Fig. 5B illustrates user plane protocol stacks using a a L2 U2U Relay according to various aspects. As an example, layer 2 is split into the following sublayers: Medium Access Control (MAC) , Radio Link Control (RLC) , Packet Data Convergence Protocol (PDCP) and Service Data Adaptation Protocol (SDAP) . In general, the physical layer (PHY) provides to the MAC sublayer transport channels; the MAC sublayer provides to the RLC sublayer logical channels; the RLC sublayer provides to the PDCP sublayer RLC channels; the PDCP sublayer provides to the SDAP sublayer radio bearers; and the SDAP sublayer provides QoS flows. Radio bearers are categorized into two groups: data radio bearers (DRB) for user plane data and signalling radio bearers (SRB) for control plane data.

[0057] An adaptation layer, SRAP sublayer, is placed above the RLC sublayer for both CP and UP at both PC5 interfaces (e.g. H10 and H01 as described) . PC5-S, PC5-RRC, PC5 SDAP, and PC5 PDCP are terminated between two source / target remote UEs (i.e., end-to-end) , while  SRAP, RLC, MAC and PHY are terminated in each hop of the PC5 link. As described below associated with Fig. 6, PC5-S, PC5-RRC, and PC5-PDCP also support per-hop communication for local link control without the SRAP sublayer.

[0058] The SRAP sublayer at source / target remote UE performs bearer mapping between end-to-end PC5 Radio Bearers (SL-SRBs or SL-DRBs) and at each hop of PC5 relay RLC channel between the source / target remote UE and the L2 U2U relay UE. The different end-to-end PC5 Radio Bearers (SL-SRBs or SL-DRBs) can be multiplexed to the same PC5 Relay RLC channel between the source remote UE and the L2 U2U relay UE or between the L2 U2U relay UE and the target remote UE. The SRAP sublayer at L2 U2U relay UE determines the egress PC5 relay RLC channel based on the mapping of the end-to-end PC5 Radio Bearer and egress PC5 relay RLC channel.

[0059] As described above, the local ID pair of the source remote UE and the target remote UE are assigned by the L2 U2U relay UE along with the corresponding L2 IDs. The identity information of the end-to-end PC5 Radio Bearer and two local IDs are included in the SRAP header in order for the target remote UE to correlate the received packets for the specific PDCP entity associated with the right end-to-end PC5 Radio Bearer of the source remote UE. QoS information, such as QoS flow identifier (QFI) or PC5 QoS Flow Identifier (PQFI) is not included in the SRAP header, and thus not known by the L2 U2U relay UE. Therefore, in some aspects, a mapping between the QoS information and the identity information of the end-to-end PC5 Radio Bearer needs to be communicated to the L2 U2U relay UE, such that QoS split can be performed per SLRB rather than per QoS flow. The QoS split per SLRB can be subsequently communicated to the source remote UE, and then the U2U relay UE can correctly identify the after split QoS for the ingress SLRB traffic from the source remote UE and determine a corresponding PC5 Relay RLC channel based on the BEARER ID that is included in the SRAP header. Thus, QoS flows can be properly maintained.

[0060] Fig. 6 illustrates a diagram showing an example of a control plane protocol stack for per-hop controls of L2 U2U relay communications in accordance with various aspects. As shown in Fig. 6, control plane protocol stack of the per-hop PC5 unicast link between resource or target remote UE and L2 U2U relay UE reuses the PC5-S protocol stack. A unicast can refers to a one-to-one transmission from one point in the network to another point; that is, one sender and one receiver, where each can have a network address uniquely identifying a single endpoint. Notably, PC5-S messages over per-hop PC5 unicast links and over end-to-end PC5 unicast links are both supported. An end-to-end PC5-S message is the message transferred between the source and target remote UEs and a direct PC5-S message is the message transferred between the source and target remote UEs and L2 U2U relay UE.

[0061] Fig. 7 illustrates a signaling diagram of QoS flow maintenance for L2 U2U relay communications in accordance with various aspects. A U2U relay UE 110-R can be connected with a source remote UE 110-S via a first ingress hop H10 and further connected with a target remote UE 110-T via a first egress hop H01. Both the first ingress hop H10 and the second hop H01 are PC5 interfaces. The signaling for link establishment / modification illustrated and described above associated with Figs. 1-3 can be applied to set up PC5 link for end-to-end QoS flow communication. The source remote UE 110-S needs to establish end-to-end SL-SRB / DRBs with the target remote UE 110-T before user plane data transmission.

[0062] As shown in Fig. 7, in some aspects, at act 1.5, End-to-End QoS flows are mapped on one or more DRBs. At act 1.6A, QoS flows are changed, such as adding new flows and / or release old QoS flows. At act 1.6, in response to the QoS flow change, a PC5-S request and response procedure can be performed to add, modify, or release QoS flows. Then, as shown by acts 1.7 and 1.8 below, a QoS information reporting per SLRB by the source remote UE 110-S and a QoS split per SLRB by the relay UE 110-R based on the QoS information reporting are performed, in order to meet overall end-to-end QoS requirements efficiently.

[0063] At act 1.7, QoS information is transmitted from the source remote UE 110-S to the U2U relay UE 110-R. The QoS information may be transmitted via PC5-RRC. The QoS information may include QoS profiles for all the end-to-end QoS flows. As an example, QoS profiles may be QoS metrics such as delay or error rates and can be included in standardized or non-standardized PC5 QoS Identifier (PQI) . In some aspects, the QoS information reporting includes aggregated QoS requirements per SLRB. In some alternative aspects, the reported QoS information can be on individual end-to-end QoS flows, and SDAP mapping of the QoS flows to SLRBs is included in the QoS information reporting for the relay UE to determine the QoS requirements per SLRB. The SDAP mapping of the QoS flows to SLRBs may be included in an enhanced IE in a message such as UEInformaitonRequestSidelink, RemoteUEInformationSidleink, or RRCReconfigurationSidelink. The SDAP mapping of the QoS flows to SLRBs can be included together with the QoS flow list in the UEInformaitonRequestSidelink, and thus has less overhead, compared to including the SDAP mapping of the QoS flows to SLRBs in any message different from UEInformaitonRequestSidelink, while the QoS flow list information is included in the UEInformaitonRequestSidelink.

[0064] At act 1.8, the L2 U2U relay UE 110-R performs QoS split to meet the end-to-end QoS requirements. For example, the QoS split may be performed for packet delay budget (PDB) per SLRB such that the aggregated time delay of the two-hop traffic is acceptable. The L2 U2U  relay UE 110-R sends the split QoS value (e.g., PDB) per SLRB via PC5-RRC message to the source remote UE 110-S. Whenever a QoS flow has been add / modify / release, QoS split procedures should be repeated, and the QoS split per-SLRB should be reported again to the relay UE 110-R.

[0065] At act 1.9, the source remote UE 110-S or a serving base station of the source remote UE 110-S derives the PDCP and SDAP configuration for end-to-end SL-DRB and provides the portion of the configuration related to reception to the target remote UE 110-T using end-to-end RRCReconfigurationSidelink messages.

[0066] The end-to-end bearer IDs for SL-SRB and SL-DRB are used as input for the L2 U2U Relay ciphering and deciphering at PDCP. The source remote UE 110-S or a serving base station may also derive the first hop configuration (e.g. PC5 relay RLC channel configuration) for SL-DRB and provide to the L2 U2U relay UE 110-R of the configuration related to receiving on the first hop (i.e., Rx by the relay UE) , using per-hop RRCReconfigurationSidelink message.

[0067] The L2 U2U relay UE or a serving base station of the L2 U2U relay UE 110-R derives the second hop configuration (e.g. PC5 relay RLC channel configuration) for each SL-DRB and provides to the relay UE 110-R of the configuration related to receiving data packets on the second hop (i.e., RX by the relay UE 110-R) , using per-hop RRCReconfigurationSidelink message.

[0068] At act 2.0, the source remote UE 110-S and the target remote UE 110-T transmit or receive data via L2 U2U relay UE 110-R.

[0069] Fig. 8 illustrates an ASN. 1 example 800 for QoS information reporting in accordance with various aspects. As shown in Fig. 8, a UE information sidelink message 802 “UEInformationRequestSidelink” is used to transfer UE information in sidelink including the end-to-end QoS information for L2 U2U Relay operation. The UE information sidelink message 802 may use SL-SRB3 as the signaling radio bearer and sidelink control channel (SCCH) as the logic channel. The UE information sidelink message 802 is transmitted from a L2 U2U remote UE to a L2 U2U relay UE. The UE information sidelink message 802 may report a full set of per-SLRB QoS information 804 ( “SL-E2E-SLRBQoS” ) for all target remote UEs ( “destinationidentity” ) available. For each entry, the TX UE (i.e., source remote UE) includes a sequence of target remote UE Identity 806 ( “destinationidentity” ) . For each target remote UE, an identity of end-to-end SLRB 808 and QoS information related to the end-to-end SLRB 810 are reported. The ASN. 1 example 800 also reflects the possibility of an empty target remote UE list for QoS information reporting. When UE includes an empty list for a target remote UE, the source remote UE 110-S no longer uses the relay for the particular target remote UE, due to  reselection of a relay UE or release of the End-to-End PC5 link. A response UE information sidelink message UEInformationResponseSidelink can also be used to report after split QoS information from a L2 U2U relay UE to a L2 U2U remote UE in a similar way as described but with end-to-end reporting replaced by a single hop QoS reporting.

[0070] Figs. 9A-9B illustrate ASN. 1 examples 900A, 900B respectively for QoS information reporting and split QoS information reporting in accordance with additional aspects. In the example 900A, still the UE information sidelink message 902, “UEInformationRequestSidelink” is used to communicate UE information in sidelink including the end-to-end QoS information for L2 U2U Relay operation. Compared to the example 800 in Fig. 8, instead of reporting a full set of per-SLRB QoS information for all target remote UEs available, the examples 900A, 900B shows an option to only report QoS information for SLRB and target remote UE that has a change (which may be referred to as “delta” reporting) . The examples 900A, 900B improve reporting efficiency compared to the example 800, since only SLRBs with changed QoS information would be reported.

[0071] As shown in an example 900A, a list of SLRBs with QoS changes 904 ( “sl-E2E-QoS-ToAddModListPC5-r18” ) is provided to indicate mappings of the SLRBs to QoS flows that are added or modified. A list of SLRBs with no QoS change 906 ( “sl-E2E-QoS-ToRelease ListPC5-r18” ) is provided to indicate the SLRBs with no QoS change and thus should be removed from reporting. For each entry, the TX UE (i.e., source remote UE) includes a sequence of target remote UE Identity 908 ( “destinationidentity” ) . For each target remote UE, an identity of end-to-end SLRB 910 ( “sl-E2eRB-r18” ) and QoS information related to the end-to-end SLRB 912 ( “sl-E2eQoS-Info-r18” ) are reported.

[0072] As shown in the example 900B, in response to the QoS information reporting, the relay UE sends split QoS information using the response UE information sidelink message 914 “UEInformationResponseSidelink” to a L2 U2U remote UE in a similar way as described but with end-to-end reporting replaced by a single hop reporting. In the example 900B, the index 916 presented in the request message ( “sl-E2eQoS-PC5-Index-r18” ) can be used to identify the SLRB.

[0073] Fig. 10 illustrates an ASN. 1 example 1000 for QoS information reporting including the SDAP mapping of the QoS flows to SLRBs included in UE information request message in accordance with various aspects. As shown in the example 1000, the source remote UE reports QoS information in a UE information request message 1002 “UEInformaitonRequestSidelink” , including the Qos-flow identifier 1004 (QFI or PQFI (PC5 QoS Flow Identifier) ) and the corresponding SLRB index 1006 ( “sl-E2eRB-r18” ) , per each target remote UE 1008  ( “DestinationIdentityRemoteUE” ) .

[0074] Fig. 11 illustrates a signaling diagram of QoS flow maintenance for L2 U2U relay communications including base station assistance in accordance with various aspects. A U2U relay UE 110-R can be connected with a source remote UE 110-S via a first ingress hop H10 and further connected with a target remote UE 110-T via a first egress hop H01. The source remote UE 110-S is a sidelink capable UE that initiates the U2U relay communication with the target remote UE 110-T and selects the U2U relay UE 110-R. Both the first ingress hop H10 and the second hop H01 are PC5 interfaces. The signaling for link establishment / modification illustrated and described above associated with Figs. 1-3 can be applied to set up PC5 link for end-to-end QoS flow communication. The source remote UE 110-S needs to establish end-to-end SL-SRB / DRBs with the target remote UE 110-T before user plane data transmission.

[0075] In some aspects, a first base station 120-S serves the source remote UE 110-S. When the source remote UE 110-S is within coverage and connected with the first base station 120-S, the source remote UE 110-S communicates with the first base station 120-S using RRC signalling to facilitate QoS split and a proper SRAP mapping of QoS flows to an PC5 Relay RLC channel, as described later in more detail associated with acts 11.1-1, 11.1-2, 11.2-1, and 11.2-2.

[0076] In some further or additional aspects, a second base station 120-R serves the U2U relay UE 110-R. When the U2U relay UE 110-R is within coverage and connected with the second base station 120-R, the U2U relay UE 110-R communicates with the second base station 120-R using RRC signalling to facilitate a proper SRAP mapping of QoS flows to an PC5 Relay RLC channel, as described later in more detail associated with acts 11.3-1 and 11.3-2.

[0077] As shown in Fig. 11, in some aspects, at act 1.5, End-to-End QoS flows are mapped on one or more DRBs. At act 1.6, in response to QoS flow change, a PC5-S request and response procedure can be performed to add, modify, or release QoS flows.

[0078] At act 11.1-1 in some aspects, when the source remote UE 110-S is within coverage and connected with the first base station 120-S, the source remote UE 110-S reports end-to-end QoS / traffic profile per QoS flow using first UE information SidelinkUEInformation to the first base station 120-S. The first UE information SidelinkUEInformation may include an IE sl-U2U-e2e-QoS-report-r18, indicating QoS information per QoS flow. The first UE information SidelinkUEInformation solicits the SLRB configurations for end-to-end traffic.

[0079] At act 11.1-2, the source remote UE 110-S receives downlink configuration RRCReconfiguration and maps QoS flows to SLRBs based on the downlink configuration  RRCReconfiguration. As an example, the downlink configuration RRCReconfiguration may include an IE sl-SDAP-config, indicating SLRB mappings for end-to-end QoS flows.

[0080] Then, as shown by acts 1.7 and 1.8 below, the source remote UE 110-S reports QoS information per SLRB per target remote UE using a sidelink UE information request message, such as “UEInformationRequestSidelink” . The relay UE 110-R then responds with a QoS split information per SLRB using a sidelink UE information response message, such as “UEInformationResponseSidelink” based on the reported QoS information, in order to meet overall end-to-end QoS requirements efficiently. The sidelink UE information request message and the sidelink UE information response message may be communicated via PC5-RRC. The QoS information may include QoS profiles for all the end-to-end QoS flows. As an example, QoS profiles may be QoS metrics such as delay or error rates and can be included in standardized or non-standardized PC5 QoS Identifier (PQI) . In some aspects, the QoS information reporting includes aggregated QoS requirements per SLRB.

[0081] After receiving the split QoS per SLRB from the relay UE 110-R at act 1.8, at act 11.2-1, the source remote UE 110-S reports the split QoS per SLRB to the first base station 120-S. In response, at act 11.2-2, the first base station 120-S may identify the split QoS based on its association to SLRB and determine whether the PC5 Relay RLC channel (either directly configured by the base station in dedicated RRC signaling or derived based on sidelink RLC bearer configuration provided in SIB12 or pre-configuration) needs to be reconfigured (e.g, replace the old bearer mapping with a new PC5 relay RLC channel to be associated with a certain end-to-end SL-DRB) . The downlink reconfiguration may be included in a RRC reconfiguration message RRCReconfigurationSidelink message. The downlink reconfiguration may include an IE sl-RLC-ChannelToAddModList-r17 indicating update of the bearer mapping used in SRAP layer and PC5 Relay RLC channel configuration.

[0082] After receiving the split QoS per SLRB from act 1.8, at act 11.3-1, the U2U relay UE 110-R may send a UE information message SidelinkUEInformaiton to the second base station 120-R, reporting the split QoS per end-to-end SLRB per target remote UE for the egress hop. Consistent with the relay UE 110-R in IDLE / INACTIVE state, the split QoS is also reported per end-to-end SLRB when the relay UE 110-R is in CONNECTED state, and no per-flow QoS split information needs to be reported. At act 11.3-2, based on split QoS per end-to-end SLRB per target remote UE for the egress hop, the second base station 120-R derives the egress hop configuration (e.g. PC5 relay RLC channel configuration) for each SL-DRB and provides to the relay UE 110-R of the configuration related to receiving data packets on the egress hop. The configuration may be included in a per-hop RRCReconfigurationSidelink message.

[0083] Fig. 12 illustrates an ASN. 1 example for QoS information reporting including base station assistance in accordance with various aspects. As described above and shown in Fig. 12, when the source remote UE 110-S is within coverage and connected with the first base station 120-S, the source remote UE 110-S may report QoS information to the first base station 120-S respectively before and after relay UE sending QoS split. Prior to the QoS split, a first reporting 1202 “sl-U2U-e2e-QoS-report-r18” includes end-to-end QoS / traffic profile per QoS flow 1206, “sl-E2E-QoS-InfoList-r18” . The first base station 120-S uses the first reporting 1202 to generate the SLRB configurations for end-to-end traffic. After the QoS split, a second reporting 1204 “sl-QoS-reportAfterSplit-r18” includes the per-hop split QoS per SLRB 1208 “sl-PerHop-QoS-InfoList-r18” . The first base station 120-S uses the second reporting 1204 to identify the split QoS based on its association to SLRB and to determine whether the PC5 Relay RLC channel needs to be reconfigured. A reporting 1210 of the split QoS information per SLRB is also shown in Fig. 12.

[0084] Fig. 13 illustrates an ASN. 1 example for QoS information reporting including base station assistance in accordance with additional aspects. As described above and shown in Fig. 13, when the relay UE 110-R is within coverage and connected with the second base station 120-R, the relay UE 110-R may report QoS information to the second base station 120-R after relay UE sends the QoS split. After the QoS split, a UE reporting 1302 includes the split QoS per SLRB for the egress hop 1304 “sl-PerHop-QoS-InfoList-r18” . The second base station 120-R uses the UE reporting 1302 to configure PC5 relay RLC channel and provide to the relay UE 110-R of the configuration related to receiving data packets on the egress hop. A reporting 1306 of the split QoS information per SLRB is also shown in Fig. 13.

[0085] Fig. 14 illustrates a flow diagram 1400 showing a source remote UE to perform L2 U2U relay communications in accordance with various aspects.

[0086] At act 1410, the source remote UE establishes a PC5 link with a target remote UE through a relay UE. The PC5 link is assigned a pair of local IDs by the relay UE identifying the source remote UE and the target remote UE. The pair of local IDs may be assigned by the relay UE based on a pair of L2 IDs associated with the source remote UE and the target remote UE.

[0087] At act 1420, in response to determining to add a new remote UE or remove a current remote UE, the source remote UE transmits a link modification request to the relay UE to modify the PC5 link. In some aspects, the link modification request includes or indicates the pair of local IDs, L2 IDs of the source remote UE and the target remote UE, and / or user information IDs of the source remote UE and the target remote UE. The link modification request may further include a link modification operation code selected from a list of link modification operation  codes. The link modification operation code indicates to add a new remote UE or remove an existing remote UE for the L2 U2U relay communication.

[0088] At act 1430, in some aspects, the source remote UE receives a link modification response from the relay UE. The link modification request may be included in a PC5-S message. The link modification response may be included in a PC5-S message.

[0089] At act 1440, the source remote UE receives a configuration information from the relay UE to release the pair of local IDs or add a new pair of local IDs. The configuration information may include an updated pair of L2 IDs. The configuration information may be included in PC5-radio resource control (PC5-RRC) message. The configuration information may assign PC5 relay radio link control (RLC) channels for end-to-end sidelink data radio bearers (SL-DRB (s) ) .

[0090] Fig. 15 illustrates a flow diagram showing a relay UE to perform L2 U2U relay communications in accordance with additional aspects.

[0091] At act 1510, the relay UE establishes a PC5 link by relaying between a source remote UE and a target remote UE.

[0092] At act 1520, the relay UE receives, from the source remote UE, QoS information indicating QoS requirements per sidelink radio bearer (SLRB) per target remote UE. In some aspects, the QoS information may include aggregated QoS requirements per SLRB. In some alternative aspects, the QoS information may include end-to-end QoS flows and mappings of the end-to-end QoS flows to SLRBs for determining the QoS requirements per SLRB. The QoS requirements per SLRB are then determined by the relay UE. The QoS information may be received whenever a new QoS flow is added or a current QoS flow is removed.

[0093] In some aspects, the QoS information includes a full set of the QoS requirements for all target remote UEs and all SLRBs. In some alternative aspects, the QoS information includes the QoS requirements only for selected target remote UEs and SLRBs with updated QoS flows. In some aspects, indices are used to identify SLRBs. A maximum number of indices for the reporting of the QoS information per SLRB is the maximum number of end-to-end SLRB.

[0094] At act 1530, the relay UE transmits, to the source remote UE, split QoS information indicating after split QoS requirements per target remote UE. In some aspects, the indices presented in the QoS information are used to identify SLRBs for the split QoS information. The split QoS information includes one or more indices presented in the QoS information to identify one or more SLRBs with updated QoS flows.

[0095] At act 1540, in some aspects, optionally, the relay UE may determine a sidelink  SRAP mapping to a PC5 Relay RLC channel based on the split QoS information. In some further aspects, if the relay UE is in coverage of a base station, the relay UE may transmit, to the base station, the split QoS requirements for the egress hop in order to determine a mapping to PC5 relay RLC channel. The base station may configure a sidelink SRAP mapping to a PC5 relay radio link control (RLC) channel based on the split QoS information. Alternatively, the base station may provide information such as options or preferences for the relay UE to determine a sidelink SRAP mapping to a PC5 relay radio link control (RLC) channel based on the split QoS information.

[0096] Fig. 16 illustrates a flow diagram showing a source remote UE to perform L2 U2U relay communications in accordance with further aspects.

[0097] At act 1610, the source remote UE establishes a PC5 link with a target remote UE through a relay UE.

[0098] At act 1620, optionally if the source remote UE is in coverage of a base station, the source remote UE transmit to the base station first sidelink UE information indicating end-to-end QoS or traffic profile of QoS flows.

[0099] At act 1630, optionally, the source remote UE receives, from the base station and based on the first sidelink UE information, a configuration information to generate QoS requirements per sidelink radio bearer (SLRB) per target remote UE;

[0100] At act 1640, the source remote UE transmits, to the relay UE, QoS information indicating the QoS requirements. The QoS information may be derived or directly received from the configuration information received from the base station.

[0101] At act 1650, the source remote UE receives, from the relay UE, split QoS information indicating after split QoS requirements per target remote UE.

[0102] At act 1660, optionally, the source remote UE transmits, to the base station, second sidelink UE information indicating the split QoS information, for the base station to determine or help the relay UE to determine, a sidelink SRAP mapping to a PC5 Relay RLC channel.

[0103] Fig. 17 is an example network 1700 according to one or more implementations described herein. Example network 1700 may include UEs 110-1, 110-2 etc. (referred to collectively as “UEs 110” and individually as “UE 110” ) , a radio access network (RAN) 120, a core network (CN) 130, application servers 140, and external networks 150.

[0104] The systems and devices of example network 1700 may operate in accordance with one or more communication standards, such as 2nd generation (2G) , 3rd generation (3G) , 4th generation (4G) (e.g., long-term evolution (LTE) ) , and / or 5th generation (5G) (e.g., new radio  (NR) ) communication standards of the 3rd generation partnership project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 1700 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc. ) , institute of electrical and electronics engineers (IEEE) standards (e.g., wireless metropolitan area network (WMAN) , worldwide interoperability for microwave access (WiMAX) , etc. ) , and more.

[0105] As shown, UEs 110 may include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, UEs 110 may include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, etc. In some implementations, UEs 110 may include internet of things (IoT) devices (or IoT UEs) that may comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. Additionally, or alternatively, an IoT UE may utilize one or more types of technologies, such as machine-to-machine (M2M) communications or machine-type communications (MTC) (e.g., to exchanging data with an MTC server or other device via a public land mobile network (PLMN) ) , proximity-based service (ProSe) or device-to-device (D2D) communications, sensor networks, IoT networks, and more. Depending on the scenario, an M2M or MTC exchange of data may be a machine-initiated exchange, and an IoT network may include interconnecting IoT UEs (which may include uniquely identifiable embedded computing devices within an Internet infrastructure) with short-lived connections. In some scenarios, IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network. UEs 110 may be understood as one or more of the source remote UE 110-S, the relay UE 110-R, or the target remote UE 110-T as described throughout this specification. In various aspects of the disclosure, one or more of the source remote UE 110-S, the relay UE 110-R, or the target remote UE 110-T may not within or not always within coverage of a network.

[0106] UEs 110 may communicate and establish a connection with (e.g., be communicatively coupled) with RAN, which may involve one or more wireless channels 114-1 and 114-2, each of which may comprise a physical communications interface  / layer. In some implementations, a UE may be configured with dual connectivity (DC) as a multi-radio access technology (multi-RAT) or multi-radio dual connectivity (MR-DC) , where a multiple receive and transmit (Rx / Tx) capable UE may use resources provided by different network nodes (e.g., 120-1 and 120-2) that may be connected via non-ideal backhaul (e.g., where one network node provides NR access and the other network node provides either E-UTRA for LTE or NR access  for 5G) . In such a scenario, one network node may operate as a master node (MN) and the other as the secondary node (SN) . The MN and SN may be connected via a network interface, and at least the MN may be connected to the CN 130. Additionally, at least one of the MN or the SN may be operated with shared spectrum channel access, and functions specified for UE 110 can be used for an integrated access and backhaul mobile termination (IAB-MT) . In some implementations, a base station (as described herein) may be an example of network node 120 or an exchangeable term of network node.

[0107] RAN may include one or more RAN nodes 120-1 and 120-2 (referred to collectively as RAN nodes 120, and individually as RAN node 120) that enable channels 114-1 and 114-2 to be established with UEs 110. RAN nodes 120 may include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples therefore, a RAN node may be an E-UTRAN Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next generation base station (e.g., a 5G base station, NR base station, next generation eNBs (gNB) , etc. ) . RAN nodes 120 may include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 120 may be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or other like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. References herein to a base station, RAN node 120, etc., may involve implementations where the base station, RAN node 120, etc., is a terrestrial network node and also to implementation where the base station, RAN node 120, etc., is a non-terrestrial network node (e.g., satellite) .

[0108] Some or all of RAN nodes 120 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP) . In these implementations, the CRAN or vBBUP may implement a RAN function split, such as a packet data convergence protocol (PDCP) split wherein radio resource control (RRC) and PDCP layers may be operated by the CRAN / vBBUP and other Layer 2 (L2) protocol entities may be operated by individual RAN nodes 120; a media access control (MAC)  / physical (PHY) layer split wherein RRC, PDCP, radio link control (RLC) , and MAC layers may be operated by the CRAN / vBBUP and the PHY layer may be operated by individual RAN nodes 120; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer may be operated by the CRAN / vBBUP and lower portions of the PHY layer may be operated by  individual RAN nodes 120. This virtualized framework may allow freed-up processor cores of RAN nodes 120 to perform or execute other virtualized applications.

[0109] In some implementations, an individual RAN node 120 may represent individual gNB-distributed units (DUs) connected to a gNB-control unit (CU) via individual F1 interfaces. In such implementations, the gNB-DUs may include one or more remote radio heads or radio frequency (RF) front end modules (RFEMs) , and the gNB-CU may be operated by a server (not shown) located in RAN or by a server pool (e.g., a group of servers configured to share resources) in a similar manner as the CRAN / vBBUP. Additionally, or alternatively, one or more of RAN nodes 120 may be next generation eNBs (i.e., gNBs) that may provide evolved universal terrestrial radio access (E-UTRA) user plane and control plane protocol terminations toward UEs 110, and that may be connected to a 5G core network (5GC) 130 via an NG interface.

[0110] Any of the RAN nodes 120 may terminate an air interface protocol and may be the first point of contact for UEs 110. In some implementations, any of the RAN nodes 120 may fulfill various logical functions for the RAN including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. UEs 110 may be configured to communicate using orthogonal frequency-division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 120 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an OFDMA communication technique (e.g., for downlink communications) or a single carrier frequency-division multiple access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink (SL) communications) , although the scope of such implementations may not be limited in this regard. The OFDM signals may comprise a plurality of orthogonal subcarriers.

[0111] The RAN nodes 120 may be configured to communicate with one another via interface 123. In implementations where the system is an LTE system, interface 123 may be an X2 interface. The X2 interface may be defined between two or more RAN nodes 120 (e.g., two or more eNBs  / gNBs or a combination thereof) that connect to evolved packet core (EPC) or CN 130, or between two eNBs connecting to an EPC. In some implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C) . The X2-U may provide flow control mechanisms for user data packets transferred over the X2 interface and may be used to communicate information about the delivery of user data between eNBs or gNBs. For example, the X2-U may provide specific sequence number information for user data transferred from a master eNB (MeNB) to a secondary eNB (SeNB) ; information about successful in sequence delivery of PDCP packet data units (PDUs) to a UE 110 from an SeNB  for user data; information of PDCP PDUs that were not delivered to a UE 110; information about a current minimum desired buffer size at the SeNB for transmitting to the UE user data; and the like. The X2-C may provide intra-LTE access mobility functionality (e.g., including context transfers from source to target eNBs, user plane transport control, etc. ) , load management functionality, and inter-cell interference coordination functionality.

[0112] As shown, RAN may be connected (e.g., communicatively coupled) to CN 130. CN 130 may comprise a plurality of network elements 332, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 110) who are connected to the CN 130 via the RAN. In some implementations, CN 130 may include an evolved packet core (EPC) , a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 130 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) . In some implementations, network function virtualization (NFV) may be utilized to virtualize any or all the above-described network node roles or functions via executable instructions stored in one or more computer-readable storage mediums (described in further detail below) . A logical instantiation of the CN 130 may be referred to as a network slice, and a logical instantiation of a portion of the CN 130 may be referred to as a network sub-slice. Network Function Virtualization (NFV) architectures and infrastructures may be used to virtualize one or more network functions, alternatively performed by proprietary hardware, onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches. In other words, NFV systems may be used to execute virtual or reconfigurable implementations of one or more EPC components / functions.

[0113] As shown, CN 130, application servers 140, and external networks 150 may be connected to one another via interfaces 134, 136, and 138, which may include IP network interfaces. Application servers 140 may include one or more server devices or network elements (e.g., virtual network functions (VNFs) offering applications that use IP bearer resources with CM 330 (e.g., universal mobile telecommunications system packet services (UMTS PS) domain, LTE PS data services, etc. ) . Application servers 140 may also, or alternatively, be configured to support one or more communication services (e.g., voice over IP (VoIP sessions, push-to-talk (PTT) sessions, group communication sessions, social networking services, etc. ) for UEs 110 via the CN 130. Similarly, external networks 150 may include one or more of a variety of networks, including the Internet, thereby providing the mobile communication network and UEs 110 of the network access to a variety of additional services, information, interconnectivity, and other network features.

[0114] Fig. 18 is a diagram of an example of components of a device according to one or more implementations described herein. In some implementations, the device 1800 can include application circuitry 1802, baseband circuitry 1804, RF circuitry 1806, front-end module (FEM) circuitry 1808, one or more antennas 1810, and power management circuitry (PMC) 1812 coupled together at least as shown. The components of the illustrated device 1800 can be included in a UE or a RAN node, such as the source remote UE 110-S, the relay UE 110-R, or the target remote UE 110-T as described throughout the specification. In some implementations, the device 1800 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1802, and instead include a processor / controller to process IP data received from a CN such as a 5GC or an Evolved Packet Core (EPC) ) . In some implementations, the device 1800 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1800, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0115] The application circuitry 1802 can include one or more application processors. For example, the application circuitry 1802 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 1800. In some implementations, processors of application circuitry 1802 can process IP data packets received from an EPC.

[0116] The baseband circuitry 1804 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1804 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1806 and to generate baseband signals for a transmit signal path of the RF circuitry 1806. Baseband circuity 1804 can interface with the application circuitry 1802 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1806. For example, in some implementations, the baseband circuitry 1804 can include a 3G baseband processor 1804A, a 4G baseband processor 1804B, a 5G baseband processor 1804C, or other baseband processor (s) 1804D for other existing generations, generations in development or to be developed in the future (e.g., 2G, 6G, etc. ) . The baseband circuitry 1804 (e.g., one or more of baseband processors 1804A-D) can handle various radio control functions  that enable communication with one or more radio networks via the RF circuitry 1806. In other implementations, some or all of the functionality of baseband processors 1804A-D can be included in modules stored in the memory 1804G and executed via a Central Processing Unit (CPU) 1804E. The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, modulation / demodulation circuitry of the baseband circuitry 1804 can include Fast-Fourier Transform (FFT) , precoding, or constellation mapping / de-mapping functionality. In some implementations, encoding / decoding circuitry of the baseband circuitry 1804 can include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder / decoder functionality. Implementations of modulation / demodulation and encoder / decoder functionality are not limited to these examples and can include other suitable functionality in other implementations.

[0117] In some implementations, the baseband circuitry 1804 can include one or more audio digital signal processor (s) (DSP) 1804F. The audio DSPs 1804F can include elements for compression / decompression and echo cancellation and can include other suitable processing elements in other implementations. Components of the baseband circuitry can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some implementations. In some implementations, some or all of the constituent components of the baseband circuitry 1804 and the application circuitry 1802 can be implemented together such as, for example, on a system on a chip (SOC) .

[0118] In some implementations, the baseband circuitry 1804 can provide for communication compatible with one or more radio technologies. For example, in some implementations, the baseband circuitry 1804 can support communication with a NG-RAN, an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) , etc. Implementations in which the baseband circuitry 1804 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0119] RF circuitry 1806 can enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 1806 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1806 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 1808 and provide baseband signals to the baseband circuitry 1804. RF circuitry 1806 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband  circuitry 1804 and provide RF output signals to the FEM circuitry 1808 for transmission.

[0120] In some implementations, the receive signal path of the RF circuitry 1806 can include mixer circuitry 1806A, amplifier circuitry 1806B and filter circuitry 1806C. In some implementations, the transmit signal path of the RF circuitry 1806 can include filter circuitry 1806C and mixer circuitry 1806A. RF circuitry 1806 can also include synthesizer circuitry 1806D for synthesizing a frequency for use by the mixer circuitry 1806A of the receive signal path and the transmit signal path. In some implementations, the mixer circuitry 1806A of the receive signal path can be configured to down-convert RF signals received from the FEM circuitry 1808 based on the synthesized frequency provided by synthesizer circuitry 1806D. The amplifier circuitry 1806B can be configured to amplify the down-converted signals and the filter circuitry 1806C can be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals can be provided to the baseband circuitry 1804 for further processing. In some implementations, the output baseband signals can be zero-frequency baseband signals, although this is not a requirement. In some implementations, mixer circuitry 1806A of the receive signal path can comprise passive mixers, although the scope of the implementations is not limited in this respect.

[0121] In some implementations, the mixer circuitry 1806A of the transmit signal path can be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1806D to generate RF output signals for the FEM circuitry 1808. The baseband signals can be provided by the baseband circuitry 1804 and can be filtered by filter circuitry 1806C.

[0122] In some implementations, the mixer circuitry 1806A of the receive signal path and the mixer circuitry 1806A of the transmit signal path can include two or more mixers and can be arranged for quadrature down conversion and up conversion, respectively. In some implementations, the mixer circuitry 1806A of the receive signal path and the mixer circuitry 1806A of the transmit signal path can include two or more mixers and can be arranged for image rejection (e.g., Hartley image rejection) . In some implementations, the mixer circuitry 1806A of the receive signal path and the mixer circuitry 1806A can be arranged for direct down conversion and direct up conversion, respectively. In some implementations, the mixer circuitry 1806A of the receive signal path and the mixer circuitry 1806A of the transmit signal path can be configured for super-heterodyne operation.

[0123] In some implementations, the output baseband signals, and the input baseband signals, can be analog baseband signals, although the scope of the implementations is not limited in this respect. In some alternate implementations, the output baseband signals, and the input  baseband signals, can be digital baseband signals. In these alternate implementations, the RF circuitry 1806 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1804 can include a digital baseband interface to communicate with the RF circuitry 1806.

[0124] In some dual-mode implementations, a separate radio IC circuitry can be provided for processing signals for each spectrum, although the scope of the implementations is not limited in this respect.

[0125] In some implementations, the synthesizer circuitry 1806D can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, although the scope of the implementations is not limited in this respect as other types of frequency synthesizers can be suitable. For example, synthesizer circuitry 1806D can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[0126] The synthesizer circuitry 1806D can be configured to synthesize an output frequency for use by the mixer circuitry 1806A of the RF circuitry 1806 based on a frequency input and a divider control input. In some implementations, the synthesizer circuitry 1806D can be a fractional N / N+1 synthesizer.

[0127] In some implementations, frequency input can be provided by a voltage-controlled oscillator (VCO) , although that is not a requirement. Divider control input can be provided by either the baseband circuitry 1804 or the applications circuitry 1802 depending on the desired output frequency. In some implementations, a divider control input (e.g., N) can be determined from a look-up table based on a channel indicated by the applications circuitry 1802.

[0128] Synthesizer circuitry 1806D of the RF circuitry 1806 can include a divider, a delay-locked loop (DLL) , a multiplexer and a phase accumulator. In some implementations, the divider can be a dual modulus divider (DMD) and the phase accumulator can be a digital phase accumulator (DPA) . In some implementations, the DMD can be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example implementations, the DLL can include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these implementations, the delay elements can be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0129] In some implementations, synthesizer circuitry 1806D can be configured to generate a carrier frequency as the output frequency, while in other implementations, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate  multiple signals at the carrier frequency with multiple different phases with respect to each other. In some implementations, the output frequency can be a LO frequency (fLO) . In some implementations, the RF circuitry 1806 can include an IQ / polar converter.

[0130] FEM circuitry 1808 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 1810, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1806 for further processing. FEM circuitry 1808 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 1806 for transmission by one or more of the one or more antennas 1810. In various implementations, the amplification through the transmit or receive signal paths can be done solely in the RF circuitry 1806, solely in the FEM circuitry 1808, or in both the RF circuitry 1806 and the FEM circuitry 1808.

[0131] In some implementations, the FEM circuitry 1808 can include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1806) . The transmit signal path of the FEM circuitry 1808 can include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1806) , and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1810) .

[0132] In some implementations, the PMC 1812 can manage power provided to the baseband circuitry 1804. In particular, the PMC 1812 can control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1812 can often be included when the device 1800 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 1812 can increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0133] While Fig. 18 shows the PMC 1812 coupled only with the baseband circuitry 1804. However, in other implementations, the PMC 1812 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1802, RF circuitry 1806, or FEM circuitry 1808.

[0134] In some implementations, the PMC 1812 can control, or otherwise be part of, various power saving mechanisms of the device 1800. For example, if the device 1800 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it can enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1800 can power down for brief intervals of time and  thus save power.

[0135] If there is no data traffic activity for an extended period of time, then the device 1800 can transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1800 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1800 may not receive data in this state; to receive data, it can transition back to RRC_Connected state.

[0136] An additional power saving mode can allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours) . During this time, the device is totally unreachable to the network and can power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

[0137] Processors of the application circuitry 1802 and processors of the baseband circuitry 1804 can be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1804, alone or in combination, can be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the baseband circuitry 1804 can utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers) . As referred to herein, Layer 3 can comprise a RRC layer, described in further detail below. As referred to herein, Layer 2 can comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 can comprise a physical (PHY) layer of a UE / RAN node, described in further detail below.

[0138] Fig. 19 is a diagram of example interfaces of baseband circuitry according to one or more implementations described herein. As discussed above, the baseband circuitry 1804 of Fig. 18 can comprise processors 1804A-1804E and a memory 1804G utilized by said processors. Each of the processors 1804A-1804E can include a memory interface, 1904A-1904E, respectively, to send / receive data to / from the memory 1804G.

[0139] The baseband circuitry 1804 can further include one or more interfaces to communicatively couple to other circuitries / devices, such as a memory interface 1912 (e.g., an interface to send / receive data to / from memory external to the baseband circuitry 1804) , an application circuitry interface 1914 (e.g., an interface to send / receive data to / from the application circuitry 1802 of Fig. 18) , an RF circuitry interface 1916 (e.g., an interface to send / receive data to / from RF circuitry 1806 of Fig. 11) , a wireless hardware connectivity interface 1918 (e.g., an interface to send / receive data to / from Near Field Communication (NFC) components, Bluetooth components, Wi-Fi components, and other communication components) , and a power  management interface 1920 (e.g., an interface to send / receive power or control signals to / from the PMC 1812) .

[0140] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor (e.g., processor , etc. ) with memory, an application-specific integrated circuit (ASIC) , a field programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0141] In Example 1, which may also include one or more of the examples described herein, a baseband processor for a user equipment (UE) is provided acting as a source remote UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication. When executing instructions stored in a memory coupled to the baseband processor, the baseband processor is configured to perform operations comprising establishing a public or mission critical 5 (PC5) link with a target remote UE through a relay UE, wherein the PC5 link is assigned a pair of local IDs identifying the source remote UE and the target remote UE; encoding, for transmission to the relay UE, a link modification request to modify the PC5 link; and receiving, from the relay UE, a configuration information to release the pair of local IDs or add a new pair of local IDs.

[0142] Example 2 includes the subject matter of example 1, including or omitting optional elements, wherein the link modification request is encoded in response to determining to add a new remote UE or remove the source remote UE or the target remote UE.

[0143] Example 3 includes the subject matter of any of examples 1-2, including or omitting optional elements, wherein the operations further comprises receiving a link modification response from the relay UE.

[0144] Example 4 includes the subject matter of any of examples 1-3, including or omitting optional elements, wherein the link modification request includes a link modification operation code selected from a list of link modification operation codes, and wherein the link modification operation code indicates to add a new remote UE or remove an existing remote UE for the L2 U2U relay communication.

[0145] Example 5 includes the subject matter of any of examples 1-4, including or omitting optional elements, wherein the link modification request is included in PC5 signaling (PC5-S) message.

[0146] Example 6 includes the subject matter of any of examples 1-5, including or omitting optional elements, wherein the pair of local IDs is assigned by the relay UE based on a pair of L2 IDs associated with the source remote UE and the target remote UE.

[0147] Example 7 includes the subject matter of any of examples 1-6, wherein the configuration information includes removing a pair of L2 IDs associated with the pair of local IDs or adding a new pair of L2 IDs associated with the new pair of local IDs.

[0148] Example 8 includes the subject matter of any of examples 1-7, including or omitting optional elements, wherein the configuration information includes or indicates the L2 IDs and / or user information IDs of the source remote UE and the target remote UE associated with local ID pair.

[0149] Example 9 includes the subject matter of any of examples 1-8, including or omitting optional elements, wherein the configuration information is included in PC5-radio resource control (PC5-RRC) message.

[0150] Example 10 includes the subject matter of any of examples 1-9, including or omitting optional elements, wherein the configuration information to release the local ID pair is triggered by a termination of the PC5 link between the source remote UE and the target remote UE ) .

[0151] In Example 11, which may also include one or more of the examples described herein, a user equipment (UE) acting as a relay UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, comprising: a memory; a processor coupled to the memory, and when executing instructions stored in the memory, configured to establish a public or mission critical 5 (PC5) link by relaying between a source remote UE and a target remote UE; receive, from the source remote UE, quality of service (QoS) information indicating QoS requirements per sidelink radio bearer (SLRB) per target remote UE; and transmit, to the source remote UE, split QoS information indicating after split QoS requirements per target remote UE.

[0152] Example 12 includes the subject matter of example 11, including or omitting optional elements, wherein the QoS information includes aggregated QoS requirements per SLRB.

[0153] Example 13 includes the subject matter of any of examples 11-12, including or omitting optional elements, wherein the QoS information includes requirements for end-to-end QoS flows and mappings of the end-to-end QoS flows to SLRBs for determining the QoS requirements per SLRB.

[0154] Example 14 includes the subject matter of example 13, including or omitting optional elements, wherein the requirements for end-to-end QoS flows and the mappings of QoS flows to SLRB are included in the same PC5-RRC message received from the source remote UE.

[0155] Example 15 includes the subject matter of example 13, including or omitting optional elements, wherein the requirements for end-to-end QoS flows and the mappings of QoS flows to SLRB are included in different PC5-RRC messages received from the source remote UE.

[0156] Example 16 includes the subject matter of any of examples 11-15, including or omitting optional elements, wherein the QoS information is received whenever a new QoS flow  is added or a current QoS flow is removed.

[0157] Example 17 includes the subject matter of any of examples 11-16, including or omitting optional elements, wherein the QoS information includes a full set of the QoS requirements for all target remote UEs and all SLRBs.

[0158] Example 18 includes the subject matter of any of examples 11-17, including or omitting optional elements, wherein the QoS information includes the QoS requirements only for selected target remote UEs and SLRBs with updated QoS information.

[0159] Example 19 includes the subject matter of any of examples 11-18, including or omitting optional elements, wherein the split QoS information includes the QoS requirement index representing of selected target remote UEs and selected SLRBs with updated QoS information.

[0160] Example 20 includes the subject matter of any of examples 11-19, including or omitting optional elements, wherein the processor is further configured to update a sidelink SRAP mapping to a PC5 relay radio link control (RLC) channel based on the split QoS information.

[0161] Example 21 includes the subject matter of any of examples 11-20, including or omitting optional elements, wherein the processor is further configured to establish a new PC5 relay RLC channel towards the target remote UE if the mapped PC5 Relay RLC channel is not established yet.

[0162] Example 22 includes the subject matter of any of examples 11-21, including or omitting optional elements, the UE is further configured to transmit, to a base station, sidelink UE information indicating the split QoS information, for the base station to determine and configure a sidelink SRAP mapping to a PC5 Relay RLC channel towards the target remote UE.

[0163] In Example 23, which may also include one or more of the examples described herein, a UE acting as a source remote UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, comprises: a memory; a processor coupled to the memory, and when executing instructions stored in a memory, configured to establish a public or mission critical 5 (PC5) link with a target remote UE through a relay UE; transmit, to a base station if the source remote UE is in coverage of the base station, first sidelink UE information indicating end-to-end QoS or traffic profile of QoS flows; receive, from the base station and based on the first sidelink UE information, a configuration information to configure an end-to-end sidelink radio bear (SLRB) towards the target remote UE; transmit, to the relay UE, QoS information indicating the QoS requirements; receive, from the relay UE, split QoS information indicating after split QoS requirements per target remote UE; and transmit, to the base station, second sidelink UE information indicating the split QoS information, for the base station to determine and configure  a sidelink SRAP mapping to a PC5 Relay RLC channel towards the target remote UE.

[0164] Example 24 is an apparatus that includes means for performing functions corresponding to the operations performed by the baseband processor or one or more processors or devices of examples 1-23.

[0165] Example 25 is a UE including the baseband processor of examples 1-11.

[0166] Example 26 is a method that includes any action or combination of actions as substantially described herein in the Detailed Description.

[0167] Example 27 is a method as substantially described herein with reference to each or any combination of the Figures included herein or with reference to each or any combination of paragraphs in the Detailed Description.

[0168] Example 28 is a user equipment configured to perform any action or combination of actions as substantially described herein in the Detailed Description as included in the user equipment.

[0169] Example 29 is a network node configured to perform any action or combination of actions as substantially described herein in the Detailed Description as included in the network node.

[0170] Example 30 is a non-volatile computer-readable medium that stores instructions that, when executed, cause the performance of any action or combination of actions as substantially described herein in the Detailed Description.

[0171] Example 31 is a baseband processor of a user equipment configured to perform any action or combination of actions as substantially described herein in the Detailed Description as included in the user equipment.

[0172] Example 32 is a baseband processor of a network node configured to perform any action or combination of actions as substantially described herein in the Detailed Description as included in the user equipment.

[0173] Example 33 is a method that includes functions corresponding to the operations performed by the baseband processor or one or more processors of examples 1-22.

[0174] Example 34 is an apparatus that includes means for performing functions corresponding to the operations performed by the baseband processor or one or more processors of examples 1-22.

[0175] Example 35 is a UE including the baseband processor of examples 16-20.

[0176] Other examples may include a method (e.g., a process) and / or a computer-readable medium implementation of any of the foregoing examples or combinations thereof. The above description of illustrated examples, implementations, aspects, etc., of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the  disclosed aspects to the precise forms disclosed. While specific examples, implementations, aspects, etc., are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such examples, implementations, aspects, etc., as those skilled in the relevant art can recognize.

[0177] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0178] In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc. ) , the terms (including a reference to a “means” ) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent) , even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given, or particular, application.

[0179] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or” . That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including” , “includes” , “having” , “has” , “with” , or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising. ” Additionally, in situations wherein one or more numbered items are discussed (e.g., a “first X” , a “second X” , etc. ) , in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context may indicate that  they are distinct or that they are the same.

[0180] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A baseband processor for a user equipment (UE) acting as a source remote UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, when executing instructions stored in a memory coupled to the baseband processor, configured to perform operations comprising:establishing a public or mission critical 5 (PC5) link with a target remote UE through a relay UE, wherein the PC5 link is assigned a pair of local IDs identifying the source remote UE and the target remote UE;encoding, for transmission to the relay UE, a link modification request to modify the PC5 link; andreceiving, from the relay UE, a configuration information to release the pair of local IDs or add a new pair of local IDs.2.The baseband processor of claim 1, wherein the link modification request is encoded in response to determining to add a new remote UE or remove the source remote UE or the target remote UE.3.The baseband processor of claim 1, the operations further comprising:receiving a link modification response from the relay UE.4.The baseband processor of claim 1,wherein the link modification request includes a link modification operation code selected from a list of link modification operation codes, andwherein the link modification operation code indicates to add a new remote UE or remove an existing remote UE for the L2 U2U relay communication.5.The baseband processor of claim 1, wherein the link modification request is included in PC5 signaling (PC5-S) message.6.The baseband processor of claim 1, wherein the pair of local IDs is assigned by the relay UE based on a pair of L2 IDs associated with the source remote UE and the target remote UE.7.The baseband processor of claim 1, wherein the configuration information includes removing a pair of L2 IDs associated with the pair of local IDs or adding a new pair of L2 IDs associated with the new pair of local IDs.8.The baseband processor of claim 1, wherein the configuration information includes or indicates the L2 IDs and / or user information IDs of the source remote UE and the target remote UE associated with local ID pair.9.The baseband processor of claim 1, wherein the configuration information is included in PC5-radio resource control (PC5-RRC) message.10.The baseband processor of claim 1, wherein the configuration information to release the local ID pair is triggered by a termination of the PC5 link between the source remote UE and the target remote UE) .11.A user equipment (UE) acting as a relay UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, comprising:a memory;a processor coupled to the memory, and when executing instructions stored in the memory, configured to:establish a public or mission critical 5 (PC5) link by relaying between a source remote UE and a target remote UE;receive, from the source remote UE, quality of service (QoS) information indicating QoS requirements per sidelink radio bearer (SLRB) per target remote UE; andtransmit, to the source remote UE, split QoS information indicating after split QoS requirements per target remote UE.12.The UE of claim 11, wherein the QoS information includes aggregated QoS requirements per SLRB.13.The UE of claim 11, wherein the QoS information includes requirements for end-to-end QoS flows and mappings of the end-to-end QoS flows to SLRBs for determining the QoS requirements per SLRB.14.The UE of claim 13, wherein the requirements for end-to-end QoS flows and the mappings of QoS flows to SLRB are included in the same PC5-RRC message received from the source remote UE.15.The UE of claim 13, wherein the requirements for end-to-end QoS flows and the mappings of QoS flows to SLRB are included in different PC5-RRC messages received from the source remote UE.16.The UE of claim 11, wherein the QoS information is received whenever a new QoS flow is added or a current QoS flow is removed.17.The UE of claim 11, wherein the QoS information includes a full set of the QoS requirements for all target remote UEs and all SLRBs.18.The UE of claim 11, wherein the QoS information includes the QoS requirements only for selected target remote UEs and SLRBs with updated QoS information.19.The UE of claim 11, wherein the split QoS information includes the QoS requirement index representing of selected target remote UEs and selected SLRBs with updated QoS information.20.The UE of claim 11, wherein the processor is further configured to update a sidelink SRAP mapping to a PC5 relay radio link control (RLC) channel based on the split QoS information.21.The UE of claim 11, wherein the processor is further configured to establish a new PC5 relay RLC channel towards the target remote UE if the mapped PC5 Relay RLC channel is not established yet.22.The UE of claim 11, further comprising:transmit, to a base station, sidelink UE information indicating the split QoS information, for the base station to determine and configure a sidelink SRAP mapping to a PC5 Relay RLC channel towards the target remote UE.23.A user equipment (UE) acting as a source remote UE for performing layer 2 (L2) UE-to-UE (U2U) relay communication, comprising:a memory;a processor coupled to the memory, and when executing instructions stored in a memory, configured to:establish a public or mission critical 5 (PC5) link with a target remote UE through a relay UE;transmit, to a base station if the source remote UE is in coverage of the base station, first sidelink UE information indicating end-to-end QoS or traffic profile of QoS flows;receive, from the base station and based on the first sidelink UE information, a configuration information to configure an end-to-end sidelink radio bear (SLRB) towards the target remote UE;transmit, to the relay UE, QoS information indicating the QoS requirements;receive, from the relay UE, split QoS information indicating after split QoS requirements per target remote UE; andtransmit, to the base station, second sidelink UE information indicating the split QoS information, for the base station to determine and configure a sidelink SRAP mapping to a PC5 Relay RLC channel towards the target remote UE.

Images