HANDLING ERROR CASES IN U2U SIDELINK RELAY NETWORKS

The disclosure relates to a 5G or 6G communication system for supporting a higher data transmission rate. A method performed by a first UE in a wireless communication system includes identifying ID information including a local ID of a first remote UE and a local ID of a second remote UE, the local IDs being used for a U2U sidelink in a SRAP; receiving, from a second UE, a data packet with a UE ID, wherein the UE ID includes a destination UE ID indicating a destination of the data packet and a source UE ID indicating a source of the data packet; determining whether the received data packet is an erroneous data packet, based on the identified ID information and the UE ID; and discarding the received data packet, in case that the received data is determined as the erroneous data packet.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based on and claims priority under 35 U.S.C. § 119 to United Kingdom Patent Application No. GB2402148.7 filed on Feb. 15, 2024, United Kingdom Patent Application No. GB2402235.2 filed on Feb. 16, 2024, and United Kingdom Patent Application No. GB2418270.1 filed on Dec. 12, 2024, all filed in the United Kingdom Intellectual Property Office, the disclosures of which are incorporated by reference herein in their entirety.

BACKGROUND

The disclosure related to the field of communication, and more particularly, for handling error cases of user-to-user (U2U) sidelink relay networks in a wireless communication system.

2. Description of the Related Art

To meet an increasing demand for wireless data communication services since the deployment of the fourth generation (4G) communication system, efforts have been made to develop an improved fifth generation (5G) or pre-5G communication system, referred to as a beyond 4G network or post long term evolution (LTE) system.

5G mobile communication technologies define broad frequency bands such that high transmission rates and new services are possible, and can be implemented not only in sub 6 gigahertz (GHz) bands such as 3.5 GHz, but also in above 6 GHz bands referred to as millimeter wave (mmwave) bands including 28 GHz and 39 GHz bands. In addition, it has been considered to implement 6G mobile communication technologies (referred to as beyond 5G systems) in terahertz bands (e.g., 95 GHz to 3 THz bands) to accomplish transmission rates fifty times faster than 5G mobile communication technologies and ultra-low latencies one-tenth of 5G mobile communication technologies.

The Rel-17 3GPP RAN Study Item “Study on NR Sidelink Relay,” completed in 2021 and whose outcome is captured in 3GPP TR 38.836, considered both UE-to-network relay and UE-to-UE relay coverage extension. However, the subsequent Rel-17 normative work in RAN focused exclusively on UE-to-network relay.

UE-to-UE (U2U) relay enables the coverage extension of the sidelink (SL) transmissions between two sidelink UEs, without relying on the use of uplink or downlink. This is especially important for the partial coverage scenario whereby at least one of the UEs involved in relaying (source UE, relay UE, destination UE) is in-coverage, and at least one of the UEs involved in relaying is out-of-coverage. When relay UE is in-coverage, it can access the network via the Uu link. Relaying of data between a source UE and a destination UE can occur once a PC5 link is established between the source UE and UE-to-UE relay, and a PC5 link is established between the destination UE and UE-to-UE relay, and a PC5 link is established between the source UE and the destination UE. Connected to a relay UE there may be multiple destination (DST) remote UEs for a single source (SRC) remote UE, and there may be multiple SRC remote UEs for a single DST remote UE. In Rel-18 there is only one hop; in future releases, there may also be multiple hops/links between a SRC and a DST remote UE.

There are ongoing discussions regarding the U2U sidelink relay, and need to handle errors and misconfigurations that may occur in the U2U remote UE and the U2U relay UE.

SUMMARY

Various acronyms, abbreviations and definitions used in the present disclosure are defined at the end of this description.

It is an aim of certain examples of the present disclosure to address, solve and/or mitigate, at least partly, at least one of the problems and/or disadvantages associated with the related art, for example at least one of the problems and/or disadvantages described herein. It is an aim of certain examples of the present disclosure to provide at least one advantage over the related art, for example at least one of the advantages described herein.

In accordance with an aspect of the disclosure, a method performed by a first user equipment (UE) in a wireless communication system includes identifying identification (ID) information including a local ID of a first remote UE and a local ID of a second remote UE, wherein the local ID of the first remote UE and the local ID of the second remote UE are used for a user-to-user (U2U) sidelink in a sidelink relay adaptation protocol (SRAP); receiving, from a second UE, a data packet with a UE ID, wherein the UE ID includes a destination (DST) UE ID indicating a destination of the data packet and a source (SRC) UE ID indicating a source of the data packet; determining whether the received data packet is an erroneous data packet, based on the identified ID information and the UE ID; and discarding the received data packet, in case that the received data is determined as the erroneous data packet.

In accordance with an aspect of the disclosure, a first user equipment (UE) in a wireless communication system includes a transceiver; and a processor coupled with the transceiver and configured to: identify identification (ID) information including a local ID of a first remote UE and a local ID of a second remote UE, wherein the local ID of the first remote UE and the local ID of the second remote UE are used for a user-to-user (U2U) sidelink in a sidelink relay adaptation protocol (SRAP), receive, from a second UE, a data packet with a UE ID, wherein the UE ID includes a destination (DST) UE ID indicating a destination of the data packet and a source (SRC) UE ID indicating a source of the data packet, determine whether the received data packet is an erroneous data packet, based on the identified ID information and the UE ID, and discard the received data packet, in case that the received data is determined as the erroneous data packet.

The present disclosure is defined in the independent claims. Advantageous features are defined in the dependent claims. Embodiments or examples disclosed in the description and/or figures falling outside the scope of the claims are to be understood as examples useful for understanding the present disclosure.

Other aspects, advantages and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings.

DETAILED DESCRIPTION

The following description of examples of the present disclosure, with reference to the accompanying drawings, is provided to assist in a comprehensive understanding of the present disclosure, as defined by the claims. The description includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the disclosure.

The same or similar components may be designated by the same or similar reference numerals, although they may be illustrated in different drawings.

Detailed descriptions of techniques, structures, functions, operations or processes known in the art may be omitted for clarity and conciseness, and to avoid obscuring the subject matter of the present disclosure.

The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the disclosure.

Throughout the description and claims of this specification, the words “comprise,” “include” and “contain” and variations of the words, for example “comprising” and “comprises,” means “including but not limited to,” and is not intended to (and does not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and/or groups thereof.

Throughout the description and claims of this specification, the singular form, for example “a,” “an” and “the,” encompasses the plural unless the context otherwise requires. For example, reference to “an object” includes reference to one or more of such objects.

Throughout the description and claims of this specification, language in the general form of “X for Y” (where Y is some action, process, operation, function, activity or step and X is some means for carrying out that action, process, operation, function, activity or step) encompasses means X adapted, configured or arranged specifically, but not necessarily exclusively, to do Y.

Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and/or groups thereof described or disclosed in conjunction with a particular aspect, embodiment, example or claim are to be understood to be applicable to any other aspect, embodiment, example or claim described herein unless incompatible therewith.

The skilled person will appreciate that the techniques described herein may be used in any suitable combination.

Certain examples of the present disclosure provide one or more techniques for handling error cases in U2U Sidelink relay networks, for example in a 3GPP 5G NR network. However, the skilled person will appreciate that the present disclosure is not limited to these examples, and may be applied in any suitable system or standard, for example one or more existing and/or future generation wireless communication systems or standards, including any existing or future releases of the same standards specification, for example 3GPP 5G, 5G-advanced or 6th Generation (6G).

The functionality of the various network entities and other features disclosed herein may be applied to corresponding or equivalent entities or features in the same or any other suitable communication systems or standards. Corresponding or equivalent entities or features may be regarded as entities or features that perform the same or similar role, function or purpose within the network.

For example, the functionality of a base station or the like (e.g., eNB, gNB, NB, RAN node, access point, wireless point, transmission/reception point, central unit, distributed unit, radio unit, remote radio head, etc.) in the examples below may be applied to any other suitable type of entity performing RAN functions, and the functionality of a UE or the like (e.g., electronic device, user device, mobile station, subscriber station, customer premises equipment, terminal, remote terminal, wireless terminal, vehicle terminal, etc.) in the examples below may be applied to any other suitable type of device.

A particular network entity may be implemented as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and/or as a virtualised function instantiated on an appropriate platform, e.g., on a cloud infrastructure.

The skilled person will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:

Certain examples of the present disclosure may be provided in the form of an apparatus/device/network entity configured to perform one or more defined network functions and/or a method therefor. Certain examples of the present disclosure may be provided in the form of a system (e.g., network or wireless communication system) comprising one or more such apparatuses/devices/network entities, and/or a method therefor.

Certain examples of the present disclosure provide a UE, base station (e.g., eNB, gNB) and/or other network entity (e.g., AMF, SMF, etc.) configured to perform a method according to any example, aspect, embodiment and/or claim disclosed herein.

Certain examples of the present disclosure provide a network (or wireless communication system) comprising a UE, base station (e.g., eNB, gNB) and/or other network entity (e.g., AMF, SMF, etc.), according to any examples, aspects, embodiments and/or claims disclosed herein.

Certain examples of the present disclosure provide a computer program comprising instructions which, when the program is executed by a computer or processor, cause the computer or processor to carry out a method according to any example, aspect, embodiment and/or claim disclosed herein.

Certain examples of the present disclosure provide a computer or processor-readable data carrier having stored thereon a computer program according to any example, aspect, embodiment and/or claim disclosed herein.

Certain examples of the present disclosure provide one or more techniques for handling of unknown, unforeseen, and erroneous protocol data. Various examples will now be described in detail. The skilled person will appreciate that the following techniques, and individual features thereof, may be used in any suitable combination.

FIG. 1 illustrates an exemplary user plane protocol stack for L2 UE-to-UE (U2U) relay, and FIG. 2 illustrates an exemplary control plane protocol stack for L2 UE-to-UE (U2U) relay.

3GPP agreed to introduce the adapt layer on the PC5 links, as shown in FIGS. 1 and 2 in shaded boxes. The adapt layer is also present on the Uu link, between the relay UE and the gNB (not shown in FIGS. 1 and 2) for L2 UE-to-network (U2N) relay.

For L2 U2N relay, the main agreed functionality of adapt on the Uu link is mapping of UL PC5 bearers onto UL Uu bearers, and performing the inverse process on the DL. The main agreed functionality of adapt on the PC5 link is mapping of DL/UL Uu bearers onto PC5 RLC channels.

This adapt layer was (re)named sidelink relay adaptation protocol, or SRAP for short (TS 38.351). The following is the basic model and operation of SRAP for Rel-17 U2N SL relaying, as agreed by 3GPP:

On the U2N relay UE, the SRAP sublayer contains one SRAP entity at Uu interface and a separate collocated SRAP entity at the PC5 interface. On the U2N remote UE, the SRAP sublayer contains only one SRAP entity at the PC5 interface.

Each SRAP entity has a transmitting part and a receiving part. Across the PC5 interface, the transmitting part of the SRAP entity at the U2N remote UE has a corresponding receiving part of an SRAP entity at the U2N relay UE, and vice-versa. Across the Uu interface, the transmitting part of the SRAP entity at the U2N relay UE has a corresponding receiving part of an SRAP entity at the gNB, and vice-versa.

At the remote UE, in the uplink (UL) direction the SRAP may determine SRAP UE ID and BEARER ID and add the SRAP header. At the remote UE, on the downlink (DL), the SRAP may remove the SRAP header and deliver the packet to higher layers.

At the relay UE, on the UL the SRAP may map the packet from a PC5 channel to a Uu channel using the SRAP UE ID and BEARER ID contained in the packet itself, and the mapping configuration provided by the network. At the relay UE, on the DL the SRAP may map the packet from a Uu channel to a PC5 channel using SRAP UE ID and BEARER ID contained in the packet itself, and the mapping configuration provided by the network.

For Rel-18 L2 UE-to-UE relay, functionalities of the SRAP layer are very similar, with one major difference being that while the identity information of remote UE end-to-end sidelink Radio Bearer is included in the SRAP layer (same as in the U2N case), the identity information of both source remote UE and destination remote UE are included in the SRAP header. Similar to U2N, a new “local” ID is introduced for purposes of SRAP layer addressing.

The initial version of R18 SRAP spec is now available; however, the issue of error handling at SRAP layer is still open for the U2U case.

Handling of Error Cases and Misconfiguration at U2U Remote UE

At remote UE, the mapping configuration is provided by its relay UE. The mapping configuration can include sl-RemoteUE-LocalIdentity, sl-RemoteUE-L2Identity, sl-PeerRemoteUE-LocalIdentity, sl-PeerRemoteUE-L2Identity where the 1st two parameters indicate the identifiers for the remote UE itself and the last two parameters indicate the identifiers for the peer remote UE. At remote UE, sl-RemoteUE-SLRB-Identity identifies an end-to-end bearer between the two remote UEs.

Handling of Error Cases and Misconfiguration at U2U Relay UE

In another example of error handling at U2U relay UE, the configuration at relay UE is given as {SRC L2 ID, src local id, DST L2 ID, dst local id, bearer id for src to dst direction, ingress link, PC5 RLC channel id for src to dst direction ingress link, egress link, PC5 RLC channel id for src to dst direction egress link}, and similarly for the other direction. PC5 RLC channel id for src to dst direction ingress link is optional in this embodiment. Other parameters may be optional elsewhere. Using a specific example: {SRC L2 ID-UE1, local id-ue1, SRC L2 ID-UE2, local id-ue2, bearer #1 for UE1-UE2 PC5 connection, ingress link for UE1-UE2 connection, PC5 RLC channel #A for bearer #1, egress link for UE1-UE2 connection, PC5 RLC channel #B for bearer #1} and {SRC L2 ID-UE2, local-id ue2, SRC L2 ID-UE1, local id ue1, ingress link for UE2-UE1 connection, bearer #1 for UE2-UE1 PC5 connection, egress link for UE2-UE1 connection, PC5 RLC channel #B for bearer #1, PC5 RLC channel #B for bearer #1}. When error related to ingress link (i.e., whether the relevant L2 ID of the ingress link maps to a local ID) is considered, it is checked for the ingress link of each direction i.e., whether the SRC UE ID of the packet matches either local id-ue1 or the concerned local id-ue2 corresponding to the ingress link.

A number of examples of how the existing specification 3GPP TS 38.351 may be modified to incorporate one or more of the above techniques will now be described. In the following examples, additions are indicated with underline.

The skilled person will appreciate that the changes in the following examples may be applied in any suitable combination. For example, a combination of methods for U2U remote UE from Example #i (#i=1, 2, 3, 4, 5, 6, 7 and/or 8) and U2U relay UE from Example #j (#j=1, 2, 3, 4, 5, 6, 7 and/or 8) may be used.

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2U

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

Example 2: No Discarding at U2U Remote UE When Only SRC UE ID is Not a Match, so Long as Corresponding sl-PeerRemoteUE-LocalIdentity Matches One of the Peer UEs

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Remote UE, if sl-RemoteUE-LocalIdentity, sl-PeerRemoteUE-LocalIdentity, and

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

included in sl-SRAP-ConfigPC5 and sl-PeerRemoteUE-LocalIdentity does not correspond

to sl-L2IdentityRemote of one of the peer UEs of the U2U Remote UE, or a SRC UE ID

field which does not match sl-PeerRemoteUE-LocalIdentity included in sl-SRAP-

ConfigPC5 and sl-PeerRemoteUE-LocalIdentity does not correspond to sl-

L2IdentityRemote of one of the peer UEs of the U2U Remote UE, or BEARER ID field

which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigU2U is

received from a U2U Relay UE, or the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-RemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2U

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

Example 3: No Discarding at U2U Relay UE When Only SRC UE ID is Not a Match

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-RemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2U

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a SRC UE

ID field which does not match sl-PeerRemoteUE-LocalIdentity included in sl-SRAP-

ConfigPC5 and DST UE ID field and BEARER ID field which match sl-RemoteUE-

LocalIdentity and sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigPC5 and sl-

- rewrite the SRAP header so that the SRC UE ID field matches sl-RemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link and forward

the SRAP Data PDU to the DST UE ID.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

Example 4: No Discarding at U2U Relay UE When Only BEARER ID is Not a Match

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Remote UE, if sl-RemoteUE-LocalIdentity, sl-PeerRemoteUE-LocalIdentity, and

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-RemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2U

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field and SRC UE ID field matching respectively sl-RemoteUE-LocalIdentity and sl-

PeerRemoteUE-LocalIdentity included in sl-SRAP-ConfigPC5, and a BEARER ID which

does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigPC5, the SRAP

- forward the SRAP Data PDU to the DST Remote UE.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

Example 5: Discarding at U2U Relay UE When SRC UE ID or DST UE ID Do Not Match Relevant sl-L2IdentityRemote/sl-SourceUE-Identity, Regardless of BEARER ID

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Remote UE, if sl-RemoteUE-LocalIdentity, sl-PeerRemoteUE-LocalIdentity, and

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-

LocalIdentity corresponding to sl-SourceUE-Identity of the ingress link is received by U2U

Relay UE, or when a SRAP Data PDU that contains a DST UE ID which does not match

the concerned sl-RemoteUE-LocalIdentity corresponding to sl-L2IdentityRemote of any of

the egress links is received by U2U Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

Example 6: Discarding at U2U Relay UE When SRC UE ID or DST UE ID Do Not Match Relevant sl-L2IdentityRemote/sl-SourceUE-Identity or sl-SourceUE-Identity/sl-L2IdentityRemote, Regardless of BEARER ID

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Remote UE, if sl-RemoteUE-LocalIdentity, sl-PeerRemoteUE-LocalIdentity, and

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-

LocalIdentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2U

Relay UE, or when a SRAP Data PDU that contains a SRC UE ID which does not match

the concerned sl-Remote UE-LocalIdentity corresponding to sl-L2IdentityRemote of the

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-Remote UE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-

LocalIdentity corresponding to sl-SourceUE-Identity of the ingress link is received by U2U

Relay UE, or when a SRAP Data PDU that contains a DST UE ID which does not match

the concerned sl-RemoteUE-LocalIdentity corresponding to sl-L2IdentityRemote of any of

the egress links is received by U2U Relay UE, or when a SRAP Data PDU that contains a

SRC UE ID which does not match the concerned sl-RemoteUE-LocalIdentity

corresponding to sl-SourceUE-Identity of the ingress link is received by U2U Relay UE, or

when a SRAP Data PDU that contains a DST UE ID which does not match the concerned

sl-PeerRemoteUE-LocalIdentity corresponding to sl-L2IdentityRemote of any of the egress

links is received by U2U Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

5.4  Handling of unknown, unforeseen, and erroneous protocol data

For U2N Remote UE, if sl-LocalIdentity and sl-RemoteUE-RB-Identity are both

configured, when a SRAP Data PDU with SRAP header that contains a UE ID field or

BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-Identity

included in sl-SRAP-ConfigRemote is received, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Remote UE, if sl-RemoteUE-LocalIdentity, sl-PeerRemoteUE-LocalIdentity, and

sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP

header that contains a DST UE ID field which does not match sl-RemoteUE-LocalIdentity

or a SRC UE ID field which does not match sl-PeerRemoteUE-LocalIdentity included in

sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-

Identity included in sl-SRAP-ConfigU2U is received from a U2U Relay UE, the SRAP

- discard the received SRAP Data PDU.

For U2N Relay UE, when a SRAP Data PDU with SRAP header that contains a UE ID

field or BEARER ID field which does not match sl-LocalIdentity or sl-RemoteUE-RB-

Identity included in sl-SRAP-ConfigRelay is received except in the case where the SRAP

Data PDU from SL-RLC1 as specified in TS 38.331 [3] is the first SRAP Data PDU

received from a U2N Remote UE, or when a SRAP Data PDU that contains a UE ID which

does not match the concerned sl-LocalIdentity corresponding to sl-L2IdentityRemote of the

ingress link is received by U2N Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

For U2U Relay UE, when a SRAP Data PDU with SRAP header that contains a DST UE

ID field or SRC UE ID field or BEARER ID field which does not match sl-RemoteUE-

in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2U is received, or when a SRAP Data PDU

that contains a SRC UE ID which does not match either the concerned sl-RemoteUE-

LocalIdentity or the concerned sl-PeerRemoteUE-LocalIdentity corresponding to the

ingress link is received by U2U Relay UE, the SRAP entity shall:

- discard the received SRAP Data PDU.

When any of the U2N Remote UE, the U2N Relay UE, the U2U Remote UE or the U2U

Relay UE receives a SRAP PDU with invalid or reserved values, the SRAP entity shall:

FIG. 3 illustrates an exemplary network entity according to various embodiment of the present disclosure.

For example, a UE in the examples of FIGS. 1 and 2 may comprise an entity of FIG. 3. The skilled person will appreciate that a network entity may be implemented, for example, as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, and/or as a virtualised function instantiated on an appropriate platform, e.g., on a cloud infrastructure.

The entity 300 comprises a processor (or controller) 301, a transmitter 303 and a receiver 305. The receiver 305 is configured for receiving one or more messages from one or more other network entities, for example as described above. The transmitter 303 is configured for transmitting one or more messages to one or more other network entities, for example as described above. The processor 301 is configured for performing one or more operations, for example according to the operations as described above.

FIG. 4 illustrates a method according to various embodiments of the present disclosure.

The method involves (e.g., is performed by, is at least partly performed by, or is at least performed by a component or entity thereof) a UE in a sidelink relay network, where a sidelink relay protocol entity (e.g., SRAP entity) is configured for the UE.

In operation S410, the UE receives a packet from an entity, the packet having a header including a first UE ID field and a second UE ID field.

In operation S420, the sidelink protocol entity discards the received packet if: (a) a first identifier indicated in the first UE ID field or a second identifier indicated in the second UE ID field does not match a respective identifier included in configuration information, or (b) a third identifier indicated in a bearer ID field included in the header does not match a respective identifier included in the configuration information.

In various examples, the method may also include one or more of the operations/features set out in the appended claims.

The techniques described herein may be implemented using any suitably configured apparatus and/or system. Such an apparatus and/or system may be configured to perform a method according to any aspect, embodiment, example or claim disclosed herein. Such an apparatus may comprise one or more elements, for example one or more of receivers, transmitters, transceivers, processors, controllers, modules, units, and the like, each element configured to perform one or more corresponding processes, operations and/or method steps for implementing the techniques described herein. For example, an operation/function of X may be performed by a module configured to perform X (or an X-module). The one or more elements may be implemented in the form of hardware, software, or any combination of hardware and software.

It will be appreciated that examples of the present disclosure may be implemented in the form of hardware, software or any combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory such as, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium such as, for example, a CD, DVD, magnetic disk or magnetic tape or the like.

It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement certain examples of the present disclosure. Accordingly, certain examples provide a program comprising code for implementing a method, apparatus or system according to any example, embodiment, aspect and/or claim disclosed herein, and/or a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection.

While the disclosure has been shown and described with reference to certain examples, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the scope of the disclosure, as defined by the appended claims.