Handling error cases in U2U sidelink relay networks

Abstract

A sidelink relay protocol entity, which may be a sidelink relay adaptation protocol (SRAP) entity, is configured for a user equipment (UE) in a sidelink relay network. The UE is configured to receive, from an entity, a packet including a header containing a first and a second UE ID fields. The sidelink relay protocol entity discards the packet if a first identifier in the first UE ID field or a second identifier in the second UE ID field do not match a respective identifier in the configuration information or a third identifier indicated in the bearer ID field does not match a respective identifier in the configuration information. The first identifier may be a source (SRC) UE identifier, and the second identifier may be a destination (DST) UE identifier.

Description

BACKGROUND Field Certain examples of the present disclosure provide one or more techniques for handling error cases in U2U Sidelink Relay networks, for example in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) network. Description of the Related Art Various acronyms, abbreviations and definitions used in the present disclosure are defined at the end of this description. 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 v17.0.0, 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 fora 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. Figures 1 and 2 respectively show User and Control plane protocol stacks for L2 UE-to-UE (U2U) Relay, as captured in the 3GPP TR 38.836 v17.0.0. 3GPP agreed to introduce the Adapt layer on the PC5 links, as shown in Figures 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 Figures 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 will determine SRAP UE ID and BEARER ID and add the SRAP header. At the Remote UE, on the downlink (DL), the SRAP will remove the SRAP header and deliver the packet to higher layers. At the Relay UE, on the UL the SRAP will 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 will 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 (v18.0.0); however, the issue of error handling at SRAP layer is still open for the U2U case. The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present invention. SUMMARY 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. According to a first aspect of the present disclosure, there is provided a user equipment (UE) in a sidelink relay network, the UE comprising a receiver and a processor, wherein a sidelink relay protocol entity is configured for the UE, wherein the UE is configured to receive a packet from an entity, the packet having a header including a first UE ID field and a second UE ID field; and wherein the sidelink relay protocol entity is configured to discard 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. According to various examples, the first identifier is a source (SRC) UE identifier and the second identifier is a destination (DST) UE identifier. According to various examples, the sidelink relay protocol entity is configured to: if the first identifier matches a fourth identifier included in the configuration information and the second identifier does not match a fifth identifier included in the configuration information, discard the received packet; and / or if the first identifier does not match the fourth identifier included in the configuration information and the second identifier matches the fifth identifier included in the configuration information, discard the received packet. According to various examples, the fifth identifier is an identifier for the UE and the fourth identifier is an identifier for the entity. According to various examples, the UE is a remote UE or a relay UE. According to various examples, the UE is a UE-to-UE (U2U) remote UE and the entity is a U2U relay UE; or wherein the UE is a U2U relay UE and the entity is a U2U remote UE. According to various examples, the UE is a remote UE; and wherein the sidelink relay protocol entity is configured to: if the first identifier and the second identifier match respective identifiers included in the configuration information and the third identifier does not match the respective identifier included in the configuration information, discard the received packet. According to various examples, the UE is a remote UE; wherein the sidelink relay protocol entity is configured to: if the first identifier matches the fourth identifier and the second identifier matches the fifth identifier, and the third identifier does not match a sixth identifier included in the configuration information, discard the received packet; and wherein the sixth identifier is configured by the combination of the fourth identifier and the fifth identifier. According to various examples, the UE is a remote UE or a relay UE; and wherein: the fourth identifier is sl-PeerRemoteUE-Localldentity and the fifth identifier is sl-RemoteUE-Local Identity. According to various examples, the sidelink relay protocol entity is a sidelink relay adaptation protocol (SRAP) entity; wherein the header is a SRAP header; and / or wherein the received packet is a SRAP data protocol data unit (PDU). According to various examples, the UE is a U2U relay UE and the entity is a first other UE connecting to a second other UE via the U2U relay UE, and wherein the sidelink relay protocol entity is configured to: discard the received packet if the SRC identifier does not match a local ID of the first other UE or a local ID of the second other UE corresponding to an ingress link for the connection between the first other UE and the second other UE, the local ID of the first other UE and the local ID of the second other UE being included in the configuration information. According to various examples, the UE is a U2U relay UE and the entity is another UE, and wherein the sidelink relay protocol entity is configured to: determine an identifier in the configuration information that is associated with a L2 ID of an ingress link; and if the SRC UE identifier does not match the determined identifier, discard the received packet. According to a second aspect of the present disclosure, there is provided a method of a user equipment (UE) in a sidelink relay network wherein a sidelink relay protocol entity is configured for the UE, the method comprising: receiving a packet from an entity, the packet having a header including a first UE ID field and a second UE ID field; and discarding, by the sidelink protocol entity, 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. According to various examples, the first identifier is a source (SRC) UE identifier and the second identifier is a destination (DST) UE identifier. According to various examples, discarding the received packet comprises: if the first identifier matches a fourth identifier included in the configuration information and the second identifier does not match a fifth identifier included in the configuration information, discarding the received packet; and / or if the first identifier does not match the fourth identifier included in the configuration information and the second identifier matches the fifth identifier included in the configuration information, discarding the received packet According to various examples, the fifth identifier is an identifier for the UE and the fourth identifier is an identifier for the entity. According to various examples, the UE is a remote UE or a relay UE. According to various examples, the UE is a UE-to-UE (U2U) remote UE and the entity is a U2U relay UE; or wherein the UE is a U2U relay UE and the entity is a U2U remote UE. According to various examples, the UE is a remote UE; and wherein discarding the received packet comprises or wherein the method further comprises: if the first identifier and the second identifier match respective identifiers included in the configuration information and the third identifier does not match the respective identifier included in the configuration information, discarding the received packet According to various examples, the UE is a remote UE; wherein discarding the received packet comprises or wherein the method further comprises: if the first identifier matches the fourth identifier and the second identifier matches the fifth identifier, and the third identifier does not match a sixth identifier included in the configuration information, discarding the received packet; and wherein the sixth identifier is configured by the combination of the fourth identifier and the fifth identifier. According to various examples, the UE is a remote UE or a relay UE; and wherein: the fourth identifier is sl-PeerRemoteUE-Localldentity and the fifth identifier is sl-RemoteUE-Local Identity. According to various examples, the sidelink relay protocol entity is a sidelink relay adaptation protocol (SRAP) entity; wherein the header is a SRAP header; and / or wherein the received packet is a SRAP data protocol data unit (PDU). According to various examples, the UE is a U2U relay UE and the entity is a first other UE connecting to a second other UE via the U2U relay UE, and wherein discarding the received packet comprises or wherein the method further comprises: discarding the received packet if the SRC identifier does not match a local ID of the first other UE or a local ID of the second other UE corresponding to an ingress link for the connection between the first other UE and the second other UE, the local ID of the first other UE and the local ID of the second other UE being included in the configuration information. According to various examples, the UE is a U2U relay UE and the entity is another UE, wherein the method comprises determining, by the sidelink relay protocol entity, an identifier in the configuration information that is associated with a L2 ID of an ingress link; and wherein discarding the received packet comprises or wherein the method further comprises: if the SRC UE identifier does not match the determined identifier, discard the received packet. According to a third aspect of the present disclosure, there is provided 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 one of the aspects or examples given above. The present invention 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 invention. Other aspects, advantages and salient features of the invention will become apparent to those skilled in the art from the following detailed description taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates an exemplary User Plane protocol stack for L2 UE-to-UE (U2U) Relay (from 3GPPTR 38.836 V17.0.0); Figure 2 illustrates an exemplary Control Plane protocol stack for L2 UE-to-UE (U2U) Relay (from 3GPP TR 38.836 V17.0.0); and Figure 3 is a block diagram of an exemplary network entity that may be used in certain examples of the present disclosure. Figure 4 is a flow diagram illustrating a method in accordance with various examples of the present disclosure. 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 invention, 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 invention. 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 invention. 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 invention. 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 invention 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 invention is not limited to the specific examples disclosed herein. For example: • The techniques disclosed herein are not limited to 3GPP 5G. • One or more entities in the examples disclosed herein may be replaced with one or more alternative entities performing equivalent or corresponding functions, processes or operations. • One or more of the messages in the examples disclosed herein may be replaced with one or more alternative messages, signals or other type of information carriers that communicate equivalent or corresponding information. • One or more further elements or entities may be added to the examples disclosed herein. • One or more non-essential elements or entities may be omitted in certain examples. • The functions, processes or operations of a particular entity in one example may be divided between two or more separate entities in an alternative example. • The functions, processes or operations of two or more separate entities in one example may be performed by a single entity in an alternative example. • Information carried by a particular message in one example may be carried by two or more separate messages in an alternative example. • Information carried by two or more separate messages in one example may be carried by a single message in an alternative example. • The order in which operations are performed and / or the order in which messages are transmitted may be modified, if possible, in alternative examples. 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. 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-Localldentity, sl-RemoteUE-L2ldentity, sl-PeerRemoteUE-Localldentity, sl-PeerRemoteUE-L2ldentity 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-ldentity be identifies an end-to-end bearer between the two Remote UEs. At Remote UE, if a packet is received with UE ID field for DST UE not matching sl-RemoteUE-Localldentity, but UE ID field for SRC UE does match sl-PeerRemoteUE-LocalIdentity, the packet is discarded. • If a packet is received with UE ID field for DST UE not matching sl-RemoteUE-LocalIdentity, but UE ID field for SRC UE does match sl-PeerRemoteUE-Localldentity, the packet is not discarded if sl-PeerRemoteUE-Localldentity corresponds to a sl-PeerRemoteUE-L2ldentity of one of the peer UEs of the Remote UE. In this case, packet is passed on to higher layer entities for said sl-RemoteUE-L2ldentity. At Remote UE, if a packet is received with UE ID field for SRC UE not matching sl-PeerRemoteUE-Localldentity, but UE ID field for DST UE does match sl-RemoteUE-LocalIdentity, the packet is discarded. • If a packet is received with UE ID field for SRC UE not matching sl-PeerRemoteUE-LocalIdentity, but UE ID field for DST UE does match sl-RemoteUE-LocalIdentity, the packet is alternatively kept. At Remote UE, if a packet is received with UE ID field for SRC UE not matching sl-PeerRemoteUE-Localldentity, and UE ID field for SRC UE not matching sl-RemoteUE-LocalIdentity, the packet is discarded. At Remote UE, if a packet is received with UE ID field for SRC UE matching sl-PeerRemoteUE-Localldentity, and UE ID field for DST UE matching sl-RemoteUE-LocalIdentity but whose BEARER ID does not match any sl-RemoteUE-SLRB-ldentity configured for that combination of (SRC UE ID, DST UE ID), the packet is discarded. At Remote UE, if a packet is received whose BEARER ID does not match any sl-RemoteUE-SLRB-ldentity configured forthat UE i.e., any combination of (SRC UE ID, DST UE ID), and the UE ID field for DST UE does not match the sl-RemoteUE-Localldentity forthat UE, the packet is discarded. • If a packet is received with UE ID field for DST UE matching sl-RemoteUE-Localldentity but whose BEARER ID does not match any sl-RemoteUE-SLRB-ldentity configured forthat UE i.e., there is no match for any combination of (SRC UE ID, DST UE ID), the packet is not discarded if sl-RemoteUE-SLRB-ldentity is not configured. Handling of error cases and misconfiguration at U2U Relay UE At Relay UE, if a packet is received with UE ID field for DST UE not matching any sl-RemoteUE-Localldentity, but UE ID field for SRC UE does match a sl-PeerRemoteUE-LocalIdentity, the packet is discarded. At Relay UE, if a packet is received with UE ID field for SRC UE not matching any sl-PeerRemoteUE-Localldentity, but UE ID field for DST UE does match a sl-RemoteUE-LocalIdentity, the packet is discarded. • If a packet is received with UE ID field for SRC UE not matching any sl-PeerRemoteUE-Localldentity, but UE ID field for DST UE does match a sl-RemoteUE-LocalIdentity, the packet is alternatively kept and the PeerRemoteUE-Localldentity is determined as corresponding to sl-PeerRemoteUE-L2ldentity of the ingress link is received by U2U Relay UE. SRAP header is rewritten so that the SRC UE ID field corresponds to said sl-PeerRemoteUE-Localldentity. At Relay UE, if a packet is received with UE ID field for SRC UE not matching any sl-PeerRemoteUE-Localldentity in the Relay configuration, and UE ID field for DST UE not matching any sl-RemoteUE-Localldentity in the Relay configuration, the packet is discarded. At Relay UE, if a packet is received whose BEARER ID does not match any sl-RemoteUE-SLRB-ldentity configured for any pair of remote UEs, the packet is discarded. At Relay UE, if a packet is received whose BEARER ID does not match any sl-RemoteUE-SLRB-ldentity configured for any pair of remote UEs while UE ID field for SRC UE matches any sl-PeerRemoteUE-Localldentity in the Relay configuration, and UE ID field for DST UE matches any sl-RemoteUE-Localldentity in the Relay configuration, the packet is not discarded and is forwarded to the DST UE. At Relay UE, if a packet is received whose UE IDs appear in the configuration table but the relevant entries do not match the BEARER ID in the packet, the packet is sent on a default channel. This default channel can be part of the initial Relay UE configuration, and can also be re-configurable. • In an embodiment of this invention, the default channel is a dedicated, pre-configured and / or configurable mapping between an RLC channel ID (= the default channel) and one or more E2E bearer IDs (identified by the BEARER ID in the SRAP packet). In a refinement of this embodiment, there is an explicit indication about default channel for this erroneous case to distinguish it from normal use case contained in the E2E bearer<->RLC channel configuration (i.e. Relay UE SRAP configuration). 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. Specification Examples A number of examples of how the existing specification 3GPP TS 38.351 V18.0.0 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. --------------------------3GPP TS 38.351 V18.0.0 Example 1 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if si-Localidentity and sl-Remote UE-RB-Id 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. For U2U Remote UE, if sl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, 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-LocaHdentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfizPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-CvnfigU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2N Relay UE, the SRAP entity sha 11: - 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-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-IdentityinclnAQd in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-Localldentity corresponding to sl-L2IdentityRemote of 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 1 Example 2: no discarding at U2U Remote UE when only SRC UE ID is not a match, so long as corresponding sl-PeerRemoteUE-Localldentity matches one of the peer UEs --------------------------3GPP TS 38.351 V18.0.0 Example 2 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE. if sl-Localldentity 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. ForU2U Remote UE, Hsl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP header that contains a DST UE ID field u hich does not match sl-RemoteUE-Localldentity included in sl-SRAP-ConfigPC5 and sl-PeerRemoteUE-Localldentitv does not correspond to sl-L21dentitvRemote of one of the peer UEs of the U2U Remote UE, or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentitv included in sl-SRAP-ConfigPC5 and sl-PeerRemoteUE-Localldentity does not correspond to sl-L2IdentityRemote of one of tire peer UEs of the U2U Remote UE, or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConflgU2U 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-Localldentity or sl-RemotelJE-RB-M included in sl-SRAP-ConflgRelay 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-Localldentity 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-Localldentity. sl-PeerRemoteUE-Localldentity. and sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConflgPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-RemoteUE-Localldentity corresponding to sl-L21dentityRemote of 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 2 -------------------------- Example 3: no discarding at U2U Relay UE when only SRC UE ID is not a match --------------------------3GPP TS 38.351 V18.0.0 Example 3-------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if si-Localidentity and sl-Remote UE-RB-Id 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. For U2U Remote UE, if sl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, 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-LocaHdentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-CvnfigU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2N Relay UE, the SRAP entity sha 11: - 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-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-IdentityinclnAQd in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-RemoteUE-Localldentitv corresponding to sl-L2IdentityRemote of the ingress link is received by U2U 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 SRC UE ID field field which does not match sl-PeerRemoteUE-Localldentity included insl-SRAP-ConfigPC5 and DST UE ID field and BEARER ID field which match sl-RemoteUE-Localldentity and sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigPC5 and sl-SRAP-ConflgU2U is received, tire SRAP entity shall: - rewrite the SRAP header so that the SRC UE ID field matches sl-RemoteUE-Localldentity corresponding to sl-L2IdentitvRemote 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 3 Example 4: no discarding at U2U Relay UE when only BEARER ID is not a match --------------------------3GPP TS 38.351 V18.0.0 Example 4 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if si-Localidentity and sl-Remote UE-RB-Id 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. For U2U Remote UE, if sl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, 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-LocaHdentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfizPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-CvnfigU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2N Relay UE, the SRAP entity sha 11: - 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-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-IdentityinclnAQd in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-RemoteUE-Localldentitv corresponding to sl-L2IdentityRemote of the ingress link is received by U2U 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 and SRC UE ID field matching respectively sl-RemoteUE-Localldentity and sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfigPC5, and a BEARER ID which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigPC5, the SRAP entity' shall: - 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: - discard the received SRAP PDU. --------------------------3GPP TS 38. 351 V18.0.0 Example 4 -------------------------- Example 5: discarding at U2U Relay UE when SRC UE ID or DST UE ID do not match relevant sl-L2ldentityRemote / sl-SourceUE-ldentity, regardless of BEARER ID --------------------------3GPP TS 38.351 V18.0.0 Example 5 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE. if sl-Localldentity and sl-RemoteUE-RB-ldentity 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. ForU2U Remote UE, Hsl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentitv, and sl-RemoteUE-SLRB-Identity are all configured, when a SRAP Data PDU with SRAP header that contains a DST UE ID field u hich does not match sl-RemoteUE-Localldentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentitv included in sl-SRAP-ConfigPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConflgU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity 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-Localldentity, sl-PeerRemoteUE-LocalIdentity, and sl-RemoteUE-SLRB-Identity included 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-Localldentity corresponding to sl-SourceUE-ldentity 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 tire concerned sl-RemoteUE-Localldentity 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 5 -------------------------- Example 6: discarding at U2U Relay UE when SRC UE ID or DST UE ID do not match relevant sl-L2ldentityRemote / sl-SourceUE-ldentity or sl-SourceUE-ldentity I sl-L2ldentityRemote, regardless of BEARER ID --------------------------3GPP TS 38.351 V18.0.0 Example 6 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if sl-Localldentity and sl-RemoteUE-RB-Identity are both configured, when a SRAP Data PDU with SRAP header (hat contains a UE ID field or BEARER ID field which does not match sl-Localldenlity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. ForU2U Remote UE. if sl-RemoteUE-Localldentitv. sl-PeerRemoteUE-Localldentity, 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-Localldentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included msl-SRAP-ConflgPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConflgU2U is received from a U2U Relay UE, 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-Localldentity or si-Remote ([JE-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-Localldentity 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-Localldentitv. sl-PeerRemoteUE-Localldentity. and sl-RemoteUE-SLRB-Identity included in sl-SRAP-ConfigPC5 and sl-SRAP-ConflgU2U is received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-Localldentitv corresponding to sl-L2IdentitvRemote 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-RemoteUE-Localldentity corresponding to sl-L2IdentityRemote of the ingress link, 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 6 -------------------------- --------------------------3GPP TS 38.351 V18.0.0 Example 7 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if si-Localidentity and sl-Remote UE-RB-Id 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. For U2U Remote UE, if sl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, 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-LocaHdentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfizPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-CvnfigU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2N Relay UE, the SRAP entity sha 11: - 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-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-IdentityinclnAQd in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match the concerned sl-PeerRemoteUE-Localldentity corresponding to sl-SourceUE-ldentitv 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-Localldentity corresponding to sl-L2IdentitvRemote 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-Localldentity 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-Localldentitv 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 7 -------------------------- --------------------------3GPP TS 38.351 V18.0.0 Example 8 -------------------------- 5.4 Handling of unknown, unforeseen, and erroneous protocol data For U2N Remote UE, if si-Localidentity and sl-Remote UE-RB-Id 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-Localldentity or sl-RemoteUE-RB-ldentity included in sl-SRAP-ConfigRemote is received, the SRAP entity shall: - discard the received SRAP Data PDU. For U2U Remote UE, if sl-RemoteUE-Localldentity, sl-PeerRemoteUE-Localldentity, 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-LocaHdentity or a SRC UE ID field which does not match sl-PeerRemoteUE-Localldentity included in sl-SRAP-ConfizPC5 or BEARER ID field which does not match sl-RemoteUE-SLRB-Identity included in sl-SRAP-CvnfigU2U is received from a U2U Relay UE, 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-Localldentity or sl-RemoteUE-RB-ldentity 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-Localldentity corresponding to sl-L2IdentityRemote of the ingress link is received by U2N Relay UE, the SRAP entity sha 11: - 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-Localldentity, sl-PeerRemoteUE-Localldentity, and sl-RemoteUE-SLRB-IdentityinclnAQd in sl-SRAP-ConfigPC5 and sl-SRAP-ConfigU2Uis received, or when a SRAP Data PDU that contains a SRC UE ID which does not match either the concerned sl-RemoteUE-Localldentitv or the concerned sl-PeerRemoteUE-Localldentity 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: - discard the received SRAP PDU. --------------------------3GPP TS 38.351 V18.0.0 Example 8 Figure 3 is a block diagram of an exemplary network entity that may be used in examples of the present disclosure. For example, a UE in the examples of Figures 1 and 2 may comprise an entity of Figure 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. Figure 4 is a flow diagram illustrating a method according to various examples 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, 5 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. 10 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. 15 While the invention 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 invention, as defined by the appended claims. Abbreviations / Definitions In the present disclosure, the following acronyms / definitions may be used. 3GPP 5G 3rd Generation Partnership Project 5th Generation 5 6G 6th Generation AMF Access and Mobility Management Function DL DownLink DST Destination E2E End-to-End 10 eNB Base Station gNB 5G Base Station ID Identity L2 Layer 2 NB Base Station 15 NR New Radio PC5 Direct communication link between capable ProSe UEs PDU Protocol Data Unit ProSe Proximity Services R18 Release 18 20 RAN Radio Access Network Rei Release RLC Radio Link Control SL SideLink SMF Session Management Function 25 SRAP Sidelink Relay Adaption Protocol SRC Source TR Technical Report TS Technical Specification U2N UE-to-Network 30 U2U UE-to-UE UE User Equipment UL UpLink Uu Air interface between terminal and base station / access point

Claims

1. A user equipment (UE) in a sidelink relay network, the UE comprising a receiver and a processor, wherein a sidelink relay protocol entity is configured for the UE,wherein the UE is configured to receive a packet from an entity, the packet having a header including a first UE ID field and a second UE ID field; andwherein the sidelink relay protocol entity is configured to discard 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.

2. The UE of claim 1, wherein the first identifier is a source (SRC) UE identifier and the second identifier is a destination (DST) UE identifier.

3. The UE of any one of the previous claims, wherein the sidelink relay protocol entity is configured to:if the first identifier matches a fourth identifier included in the configuration information and the second identifier does not match a fifth identifier included in the configuration information, discard the received packet; and / orif the first identifier does not match the fourth identifier included in the configuration information and the second identifier matches the fifth identifier included in the configuration information, discard the received packet.

4. The UE of claim 3, wherein the fifth identifier is an identifier for the UE and the fourth identifier is an identifier for the entity.

5. The UE of any one of the previous claims, wherein the UE is a remote UE or a relay UE.

6. The UE of claim 5, wherein the UE is a UE-to-UE (U2U) remote UE and the entity is a U2U relay UE; orwherein the UE is a U2U relay UE and the entity is a U2U remote UE.

7. The UE of claim any one of the previous claims, wherein the UE is a remote UE; andwherein the sidelink relay protocol entity is configured to:if the first identifier and the second identifier match respective identifiers included in the configuration information and the third identifier does not match the respective identifier included in the configuration information, discard the received packet.

8. The UE of claim 3 or claim 4, wherein the UE is a remote UE;wherein the sidelink relay protocol entity is configured to:if the first identifier matches the fourth identifier and the second identifier matches the fifth identifier, and the third identifier does not match a sixth identifier included in the configuration information, discard the received packet; andwherein the sixth identifier is configured by the combination of the fourth identifier and the fifth identifier.

9. The UE of claim 3 or claim 4, wherein the UE is a remote UE or a relay UE; and wherein:the fourth identifier is sl-PeerRemoteUE-Localldentity and the fifth identifier is sl-RemoteUE-Localldentity.

10. The UE of any previous claim, wherein the sidelink relay protocol entity is a sidelink relay adaptation protocol (SRAP) entity;wherein the header is a SRAP header; and / orwherein the received packet is a SRAP data protocol data unit (PDU).

11. The UE of claim 2, wherein the UE is a U2U relay UE and the entity is a first other UE connecting to a second other UE via the U2U relay UE, andwherein the sidelink relay protocol entity is configured to:discard the received packet if the SRC identifier does not match a local ID of the first other UE or a local ID of the second other UE corresponding to an ingress link for the connection between the first other UE and the second other UE, the local ID of the first other UE and the local ID of the second other UE being included in the configuration information.

12. The UE of claim 2, wherein the UE is a U2U relay UE and the entity is another UE, and wherein the sidelink relay protocol entity is configured to:determine an identifier in the configuration information that is associated with a L2 ID of an ingress link; andif the SRC UE identifier does not match the determined identifier, discard the received packet.

13. A method of a user equipment (UE) in a sidelink relay network wherein a sidelink relay protocol entity is configured for the UE, the method comprising:receiving a packet from an entity, the packet having a header including a first UE ID field and a second UE ID field; anddiscarding, by the sidelink protocol entity, 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.

14. The method of claim 13, wherein the first identifier is a source (SRC) UE identifier and the second identifier is a destination (DST) UE identifier.

15. The method of claim 13 or claim 14, wherein discarding the received packet comprises: if the first identifier matches a fourth identifier included in the configuration information and the second identifier does not match a fifth identifier included in the configuration information, discarding the received packet; and / orif the first identifier does not match the fourth identifier included in the configuration information and the second identifier matches the fifth identifier included in the configuration information, discarding the received packet.

16. The method of claim 15, wherein the fifth identifier is an identifier for the UE and the fourth identifier is an identifier for the entity.

17. The method of any one of claims 13 to 16, wherein the UE is a remote UE or a relay UE.

18. The method of claim 17, wherein the UE is a UE-to-UE (U2U) remote UE and the entity is a U2U relay UE; orwherein the UE is a U2U relay UE and the entity is a U2U remote UE.

19. The method of any one of claims 13 to 17, wherein the UE is a remote UE; and wherein discarding the received packet comprises:if the first identifier and the second identifier match respective identifiers included in the configuration information and the third identifier does not match the respective identifier included in the configuration information, discarding the received packet.

20. The method of claim 15 or 16, wherein the UE is a remote UE;wherein discarding the received packet comprises:if the first identifier matches the fourth identifier and the second identifier matches the fifth identifier, and the third identifier does not match a sixth identifier included in the configuration information, discarding the received packet; andwherein the sixth identifier is configured by the combination of the fourth identifier and the fifth identifier.

21. The method of claim 15 or 16, wherein the UE is a remote UE or a relay UE; and wherein:the fourth identifier is sl-PeerRemoteUE-Localldentity and the fifth identifier is sl-RemoteUE-Localldentity.

22. The method of any one of claims 13 to 21, wherein the sidelink relay protocol entity is a sidelink relay adaptation protocol (SRAP) entity;wherein the header is a SRAP header; and / orwherein the received packet is a SRAP data protocol data unit (PDU).

23. The method of claim 14, wherein the UE is a U2U relay UE and the entity is a first other UE connecting to a second other UE via the U2U relay UE, andwherein discarding the received packet comprises:discarding the received packet if the SRC identifier does not match a local ID of the first other UE or a local ID of the second other UE corresponding to an ingress link for the connection between the first other UE and the second other UE, the local ID of the first other UE and the local ID of the second other UE being included in the configuration information.

24. The method of claim 14, wherein the UE is a U2U relay UE and the entity is another UE,wherein the method comprises determining, by the sidelink relay protocol entity, an identifier in the configuration information that is associated with a L2 ID of an ingress link; andwherein discarding the received packet comprises if the SRC UE identifier does not match the determined identifier, discard the received packet.

25. 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 one of claims 13 to 24.

Images