Short id management for u2u sidelink relay adaptation protocol (SRAP)

Abstract

A source remote terminal and a destination remote terminal negotiate a Short ID over an end-to-end (E2E) PCS-Radio Resource Control (RRC) communication link that includes at least one relay terminal. The at least one relay terminal is notified of the Short ID which is shorter than a ProSe UE ID. If the Short ID is acceptable to the at least one relay terminal forming the E2E PCS communication link, the source remote terminal and the destination remote terminal are notified of the confirmation. The Short ID is applied to the Sidelink Relay Adaptation Protocol (SRAP) at the at least one relay terminal and is included in the headers of E2E transmissions from the source remoter terminal and the destination remote terminal.

Description

SHORT ID MANAGEMENT FOR U2U SIDELINK RELAY ADAPTATION PROTOCOL (SRAP)CLAIM OF PRIORITY

[0001] The present application claims priority to Provisional Application No. 63 / 533,562, entitled “Short ID For SRAP In U2U Relay”, docket number TPRO 00396 US, filed August 18, 2023, and to Provisional Application No. 63 / 541 ,204, entitled “Short ID Assignment Using PC5-RRC”, docket number TPRO 00397 US, filed September 28, 2023, both assigned to the assignee hereof and hereby expressly incorporated by reference in their entirety.FIELD

[0002] This invention generally relates to wireless communications and more particularly to Short ID management for U2U Sidelink Relay Adaptation Protocol (SRAP).BACKGROUND

[0003] Many wireless communication systems that employ several base stations that provide wireless service to user equipment (UE) devices enable sidelink communication between two or more UE devices where the UE devices can communicate directly with other UE devices. In addition, one or more UE devices can be used as relay devices to form relay communication links between a source UE and a base station or between a source UE device and a destination UE device. A relayed connection between a remote UE and the network through a relay device is often referred to as a UE-to-Network (U2N) link. The U2N link includes a PC5 link between the relay device and the remote UE and Uu link between the relay device and a base station in the network.

[0004] In some conventional systems, the U2N communication links use a Sidelink Relay Adaptation Protocol (SRAP) defined by one or more revisions of the 3rdGeneration Partnership Project (3GPP) standards to transmit control and data signalsover the PC5 link and the Uu link. The SRAP is used to perform bearer mapping (signaling radio bearers (SRBs) and data radio bearers (DRBs)) between the two links. For U2N relays, a local Remote UE ID is included in both the PC5 SRAP header and the Uu SRAP header. The Layer 2 (L2) U2N Relay UE is configured by the gNB with the local Remote UE ID to be used in SRAP headers.SUMMARY

[0005] A source remote terminal and a destination remote terminal negotiate a Short ID over an end-to-end (E2E) PC5 communication link that includes at least one relay terminal. The at least one relay terminal is notified of the Short ID which is shorter than a ProSe UE ID, such as User Info ID or a L2ID. If the Short ID is acceptable to the at least one relay terminal forming the E2E PC5 communication link, the source remote terminal and the destination remote terminal are notified of the confirmation. The Short ID is applied to the Sidelink Relay Adaptation Protocol (SRAP) at the at least one relay terminal and is included in the headers of E2E transmissions from the source remoter terminal and the destination remote terminal.BRIEF DESCRIPTION OF THE DRAWINGS

[0006] FIG. 1 is a block diagram of an example of a U2U control layer protocol stack for a L2 UE-to-UE (U2U) relay terminal.

[0007] FIG. 2A is a block diagram of a system for an example of Short ID (Local ID) selection for PC5 SRAP for an E2E PC5 communication link with multiple hops.

[0008] FIG. 2B is a block diagram of the system for an example of Short ID (Local ID) selection for PC5 SRAP for E2E PC5 communication links for multiple destination terminals.

[0009] FIG. 2C is a block diagram of the system for an example of Short ID (Local ID) selection for PC5 SRAP for E2E PC5 communication links for multiple destination terminals and multiple relay terminals.

[0010] FIG. 2D is a block diagram of a system for an example of Short ID (Local ID) selection for PC5 SRAP for an E2E PC5 communication link with multiple hops without negotiation between the remote terminals over the E2E PC5 communication link.

[0011] FIG. 3 is a block diagram of an example of a UE device suitable for use as each of the terminal devices.

[0012] FIG. 4A is a message diagram for an example of Short ID (Local ID) selection for PC5 SRAP for the E2E PC5 communication link with multiple hops.

[0013] FIG. 4B is a message diagram for an example of Short ID (Local ID) negotiation between the remote source terminal and the remote destination terminal.

[0014] FIG. 4C is a message diagram for an example of Short ID (Local ID) negotiation between the remote source terminal and the remote destination terminal where the source-proposed Short ID is not acceptable to the remote destination terminal.

[0015] FIG. 5 is a flow chart of an example of method of managing Short IDs for an E2E PC5 communication link performed at a remote terminal.

[0016] FIG. 6 is a flow chart of an example of method of managing Short IDs for an E2E PC5 communication link performed at a relay terminal.DETAILED DESCRIPTION

[0017] As discussed above, a relay communication link can be established between a remote source UE device (remote source terminal) and a remote destination UE device (remote destination terminal) through one or more relay devices (relay terminals). The relay communication link, often referred to as a UE-to-UE (U2U) communication link, includes PC5 links between the remote source terminal and the relay terminal, between the relay terminal and the remote destination terminal, and between relay terminals if more than one relay terminal forms the U2U communication link. Each relay terminal in the U2U link has a PC5 ingress link to a terminal and a PC5 egress link to another terminal. For a U2U link with a single relay terminal, therefore, the relay terminal is connected to the remote source terminal over an ingress PC5 link usingPC5 Relay radio link control (RLC) channels over a first hop PC5 link and is connected to the remote destination terminal over an egress PC5 link using PC5 Relay RLC channels over a second hop PC5 link. Some conventional systems adopt the SRAP for U2N links for use in the U2U link to map the SRBs and DRBs of the ingress PC5 link and egress PC5 link. As discussed above, a U2N relay is configured by the network (e.g., gNB) with a Local Remote UE ID (Short ID) to be used in both the PC5 SRAP header and the Uu SRAP header. U2U relay terminals, however, cannot rely on the gNB or network to configure the local Remote UE ID since all of the terminals may be out of coverage and unreachable by the gNB. One potential technique for selecting a UE ID for Uu SRAP includes using the Layer 2 UE ID (L2ID). Unfortunately, the L2ID is 24 bits long and is longer than a Short ID which is expected to be 8 bits long or less. Accordingly, conventional systems are limited since a Short ID cannot be used in SRAP headers for a U2U communication link. For the examples herein, however, a Short ID for SRAP is negotiated between the remote source terminal and the remote destination terminal and then shared and confirmed by the one or more relay terminals.

[0018] A network node is any apparatus, equipment, device, or combination of devices, on the network side of the communication system that is connected to the communication network or is part of communication network. Some examples of a network node include a base station, a node B, an E-UTRA Node B, Evolved Node B, eNodeB, eNB, a New Generation eNB (ng-eNB), a gNodeB (also known as a gNB) in new radio (NR) technology, a macro station, pico station, and a femto station. The network node may form, or be a part of, the radio access network (RAN) that provides a connection between the core network and terminal communication devices. A RAN may be organized into three functional blocks including a Radio Unit (RU), a Distributed Unit (DU) and a Centralized Unit (CU). The RU transmits, receives, amplifies, and digitizes radio frequency signals and typically located near, or integrated into, the antenna. The DU and CU perform computations and / or processing to send and receive digitalized radio signals to and from the core network. The DU is typically located at or near the RU and the CU may be closer to the core network. The infrastructure or connection between the RU and the DU is often referred to as fronthaul and the infrastructure or connection between the DU and the CU is often referred to as amidhaul. The communication node, therefore, may perform the functions of one or more of the RU, DU and / or CU depending on the particular implementation.

[0019] A terminal communication device (terminal), such as a remote terminal and a relay terminal, is a communication device on the terminal side of the communication system and is sometimes referred to as user equipment (UE), a UE device, a terminal device, wireless mobile device, wireless communication device and other terms. Some examples of a terminal communication device include a mobile phone, a smart phone, a personal digital assistant (PDA), tablet, and laptop computer. In some situations, the terminal communication device is a machine type communication (MTC) communication device or Internet-of-Things (IOT) device. In addition, the terminal communication device may be, or may be a part of, a wearable device or a vehicle where the vehicle may be terrestrial vehicle, watercraft, or aircraft (including unmanned aerial vehicles). The terminal communication device, therefore, is any fixed, mobile, or portable equipment that performs the functions of the terminal device described herein.

[0020] FIG. 1 is a block diagram of an example of a U2U control layer protocol stack 100 for a L2 UE-to-UE (U2U) relay terminal. The control layer protocol stack 100 includes a Radio Resource Control (RRC) Layer 102, a Packet Data Convergence Protocol (PDCP) layer 104, an adaptation layer 106, a Radio Link Control (RLC) layer 108, a Medium Access Control (MAC) layer 110 and a physical (PHY) layer 112. The PHY layer 112 is typically referred to as Layer 1 (L1 ) 114 and the RLC layer 108 and the MAC layer 110 typically form Layer 2 (L2) 116. SRAP is applied to the adaptation layer 106 for RBs mapping where a SRAP entity is implemented at each device for each link hop. Each SRAP entity has transmitting and receiving portions. For the first hop PC5 interface 118, the transmitting portion of the SRAP entity 120 at the remote source UE (remote source terminal) has a corresponding receiving portion of the SRAP entity 122 at the U2U relay UE (relay terminal), and the transmitting portion of the SRAP entity 122 at the U2U relay UE (relay terminal) has a corresponding receiving portion of the SRAP entity 120 at the source remote UE (remote source terminal).

[0021] For the second hop PC5 interface 124, the transmitting portion of the SRAP entity 126 at the remote destination (target) UE (destination terminal) has a corresponding receiving portion of the SRAP entity 128 at the U2U relay UE (relayterminal), and the transmitting portion of the SRAP entity 128 at the U2U relay UE (relay terminal) has a corresponding receiving portion of the SRAP entity 126 at the remote destination UE (remote destination terminal).

[0022] For the example, the U2U control layer protocol stack 100 is in accordance with at least one revision of the 3GPP communication specification. The identity information in the SRAP entities used for the hop-by-hop mappings of the PC5 RLC channels to RBs between the two remote terminals (UEs) however, is a Local ID (Short ID) for the examples herein. Therefore, each SRAP entity 120, 122, 126, 128 includes the Short ID (Local ID). The Short ID is shorter than the L2IDs and the User Info IDs of the remote IDs. In some situations, the Short ID is 8 bits long but can be shorter in other situations.

[0023] Regarding the first hop to the L2 U2U Relay, the N:1 mapping is supported by the first hop PC5 adaptation layer 120, 122 between the remote UE sidelink (SL) RBs and first hop PC5-RLC channels for relaying. The first hop adaptation layer over the first PC5 hop 118 between the source remote UE and the relay UE supports identification of traffic destined to different remote destination UEs. Regarding the second hop of L2 U2U relay 124, the second hop PC5 adaptation layer 126, 128 supports bearer mapping between the ingress RLC channels over the first PC5 hop and egress RLC channels over the second PC5 hop 124 at the L1 U2U relay UE. The PC5 Adaptation layer supports the 1X1:1 bearer mapping between multiple ingress PC5 RLC channels over the first PC5 hop 122 and one egress PC5 RLC channel over the second PC5 hop 124 and supports the Remote UE identification function. The identity information (Short ID) of the remote UE is included in the adaptation layer 106 in the first PC5 hop and the second PC5 hop.

[0024] The adaptation layer 106 is supported over the second PC5 link for the L2 U2U relay. For L2 U2U relay, the adaptation layer 106 is laid over the RLC sublayer for both the control plane and the user plane over the second PC5 link 124. The sidelink Service Data Adaptation Protocol (SDAP)ZPacket Data Convergence Protocol (PDCP) and RRC are terminated between the remote terminals, while the RLC, MAC and PHY are terminated in each PC5 link.

[0025] FIG. 2A is a block diagram of a system 200 for an example of Short ID (Local ID) selection for PC5 SRAP for an E2E PC5 communication link 202 with multiple hops 204, 206, 208. A source remote terminal 210 establishes an E2E PC5 communication link 202 between the source remote terminal 210 and a destination remote terminal 212 through a first relay terminal 214 and a second relay terminal 216. For the example, the remote and relay terminals use ProSe UE IDs to establish the E2E PC5 link 202 in accordance with known techniques. Examples of ProSe UE IDs include Application Layer IDs and L2IDs. A User Info ID is an Application layer ID. The E2E PC5 link 202 includes a PC5 first hop 204 between the source remote terminal 210 and the first relay terminal 214, a PC5 second hop 206 between the first relay terminal 214 and the second relay terminal 216, and a PC5 third hop 218 between the second relay terminal 216 and the destination remote terminal 212. For the examples, E2E PC5-RRC messages are encapsulated in the hop-by-hop PC5-RRC messages.

[0026] After the E2E PC5 link (U2U relay communication) is established, the remote source terminal and the remote destination terminal may each transmit information over the established E2E link. In other words, the remote source terminal may be a transmitting terminal or a receiving terminal and the remote destination terminal may be transmitting terminal or a receiving terminal. Before a Short ID is established for the link 202, transmissions to a relay terminal from the remote terminals 210, 212 include the ProSe UE ID such as the User Info ID in a header of the transmissions. The relay terminal at the other endpoint of the hop recognizes the ProSe UE ID of the transmitting remote terminal. As is known, the User Info of a terminal (UE) is essentially a unique permanent identifier of the terminal. In some situations where the remote source terminal has the appropriate information, the ProSe UE ID may be the L2ID.

[0027] After the E2E PC5 link 202 is established, the remote source terminal and the remote destination terminal negotiate 218 via the E2E PC5 link 202 to select a Short ID (Local ID) for use in the SRAP layer of the protocol stack by both relay terminals 214, 216. In some cases, the terminals negotiate over the E2E PC5-S link established after the respective Direct Communication Request / Response (DCR) for each hop is completed and the E2E PC5-S is established. The negotiation 218 may also be after theE2E PC5-RRC communication link is established. Where the negotiation 218 is over the E2E PC5-RRC communication link, the E2E PC5-RRC messages are encapsulated in the hop-by-hop PC5-RRC transmissions. As discussed below, an example of a suitable negotiation procedure includes the source remote terminal 210 proposing a Short ID (source-proposed Short ID) and the destination remote terminal 212 either confirming the source-proposed Short ID or rejecting it by proposing another short ID (destination- proposed Short ID). The source remote terminal 210 then confirms the destination- proposed Short ID or proposes a second source-proposed Short ID. The process continues until a proposed Short ID is confirmed. A remote terminal confirms a proposed Short ID when the proposed Short ID is unique to the other communications at remote terminal. In other words, the proposed Short ID is confirmed when the remote terminal determines that the Short ID is not in use and there will be no “collision”.

[0028] After the remote terminals 210, 212 have selected a Short ID, the relay terminals 214, 216 are informed of the selection. For the example, the source remote terminal sends the Short ID to the first relay terminal 21 and, if the first relay terminal 214 confirms the Short ID is unique, the first relay terminal 214 sends the Short ID to the second relay terminal 216. If the second relay terminal 216 confirms the Short ID is unique to other Short ID(s) used by the second relay terminal, the remote terminals 210, 212 are notified of the confirmations.

[0029] For the example of FIG. 2A, the source remote terminal 210 sends the Short ID over the PC5 first hop 204 to the first relay terminal 214 in an RRCReconfigurationSidelink message 220 using a PC5-RRC link. The first relay terminal 214 evaluates the Short ID and forwards the Short ID to the second relay terminal 216 if the first relay terminal 214 determines that the Short ID does not conflict with any other communication at the first relay terminal 214. The Short ID is included in a RRCReconfigurationSidelink message 222 sent over the PC5 second hop 206 using the PC5-RRC link. The second relay terminal 216 evaluates the Short ID and confirms to the remote destination terminal 212 and the first relay terminal 214 that the Short ID is acceptable. A RRCReconfigurationSidelink message 224 is transmitted to the target remote terminal 212 indicating that the Short ID is confirmed. The remote destinationterminal 212 confirms receipt of the message 224 with a RRCReconfigurationCompleteSidelink message 225 for the example. A RRCReconfigurationCompleteSidelink message 226 is transmitted to the first relay terminal 214 indicating that the Short ID is confirmed. The first relay terminal then transmits a RRCReconfigurationCompleteSidelink message 228 to the source remote terminal 212 indicating that the Short ID is confirmed.

[0030] In some situations, the negotiation 218 is skipped and the remote source terminal proposes a Short ID to the first relay terminal and the short ID is forwarded to each successive relay terminal to the remote destination terminal 212. An example is discussed with reference to FIG. 2D below.

[0031] If the first relay terminal 214 determines that the Short ID is not acceptable, the first relay terminal 214 transmits a Short ID rejection message 230 to the source remote terminal 210. For the example, the Short ID rejection message 230 is a RRCReconfigurationFailureSidelink message 230. If the second relay terminal 216 determines that the Short ID is not acceptable, the second relay terminal 216 transmits a Short ID rejection message 232 to the first relay terminal 210. For the example, the Short ID rejection message 232 is a RRCReconfigurationFailureSidelink message 232. The first relay terminal transmits the Short ID rejection message 230 to the source remote terminal 210 in response to receiving the Short ID rejection message 232 from the second relay terminal 216.

[0032] For the example, the source remote terminal 210 does not initiate any other Short ID negotiations until the current the Short ID is applied to the SRAP for the E2E PC5 link 202. Such a technique avoids confusion regarding multiple Short IDs and confirmation messages 220, 222, 224, 226, 228 with other messages for another E2E link.

[0033] After remote terminals 210, 212 are notified of the confirmations, the Short ID is applied to the SRAP layer and each remote terminal includes the Short ID in the SRAP header for E2E transmissions. If the Short ID is not confirmed by all of the relay terminals, the source remote terminal proposes another Short ID and repeats the negotiation 218 and the confirmation process.

[0034] Although the example of FIG. 2A includes two relay terminals supporting the E2E link 202, the principles described above can be applied to E2E links including any number of relay terminals. In some situations, the SRAP Short ID management technique may be applied to an E2E link including only a single relay terminal.

[0035] FIG. 2B is a block diagram of the system 200 for an example of Short ID (Local ID) selection for PC5 SRAP for E2E PC5 communication links 202, 240 for multiple destination terminals 212, 242. A source remote terminal 210 establishes a first E2E PC5 communication link 202 between the source remote terminal 210 and a first destination remote terminal 212 through a relay terminal 214 and establishes a second E2E PC5 communication link 240 between the source remote terminal 210 and a second destination remote terminal 242 through the relay terminal 214. For the example, the remote and relay terminals use the ProSe UE IDs, such as the User Info IDs to establish the E2E PC5 links 202, 240 in accordance with known techniques. In some situations, the L2IDs may be used. The first U2E PC5 link 202 includes a PC5 first hop 244 between the source remote terminal 210 and the relay terminal 214, and a PC5 second hop 246 between the relay terminal 214 and the first destination remote terminal 212. The second U2E PC5 link 242 includes a PC5 first hop 248 between the source remote terminal 210 and the relay terminal 214, and a PC5 second hop 250 between the relay terminal 214 and the second destination remote terminal 242.

[0036] After the first E2E PC5 link 202 is established, the source remote terminal 210 and the first destination remote terminal 212 negotiate 252 via the first E2E PC5 link 202 to select a first Short ID (Local ID) for use in the SRAP layer of the protocol stack by the relay terminal 214 for the first E2E link 202. After the second E2E PC5 link 240 is established, the source remote terminal 210 and the second destination remote terminal 242 negotiate 254 via the second E2E PC5 link 240 to select a second Short ID (Local ID) for use in the SRAP layer of the protocol stack by the relay terminal 214 for the second E2E link 240. An example of a suitable negotiation procedure includes the source remote terminal 210 proposing the Short IDs (source-proposed Short ID) and the destination remote terminals 212, 242 either confirming a source-proposed Short ID or rejecting it by proposing other short IDs (destination-proposed Short IDs).

[0037] After the remote terminals 210, 212, 242 have selected the first Short ID and the second Short ID, the relay terminal 214 is informed of the selection. For the example of FIG. 2B, the confirmation messages for the second Short ID for the second E2E link 242 are not transmitted until the confirmation messages for the first Short ID for the first E2E link 240 have been sent and the first Short ID is applied to the SRAP layer for the first E2E link 202. In some situations, the second E2E link 242 is not established until after the first Short ID is applied to the SRAP layer for the first E2E link 202.

[0038] The first Short ID is sent from the remote source terminal 210 to the relay terminal 214 in a first Short ID message 256. If the relay terminal 214 confirms the first Short ID is unique, the relay terminal 214 sends a confirmation message 258 for the first Short ID to the remote source terminal 210 and a confirmation message 260 for the first Short ID to the first destination terminal 212.

[0039] For the example of FIG. 2B, the source remote terminal 210 sends the Short ID over the PC5 first hop (1 ) 244 to the relay terminal 214 in an RRCReconfigurationSidelink message 256 using a PC5-S link. The relay terminal 214 evaluates the first Short ID and confirms to the remote terminals 210, 212 that the Short ID is acceptable with the confirmation messages 258, 260. An example of a suitable confirmation message includes a RRCReconfigurationCompleteSidelink message transmitted via a PC5-RRC link. In the example, therefore, the relay terminal 214 transmits RRCReconfigurationCompleteSidelink message 258 to the remote source terminal indicating that the first Short ID is confirmed and transmits another RRCReconfigurationSidelink message 260 to the first remote destination terminal 212 indicating that the Short ID is confirmed. The first remote destination terminal 212 confirms receipt of the confirmation message 260 with a RRCReconfigurationCompleteSidelink message 261 .

[0040] If the relay terminal 214 determines that the first Short ID is not acceptable, the relay terminal 214 transmits a first Short ID rejection message 262 to the source remote terminal 210. For the example, the Short ID rejection message 262 is a RRCReconfigurationFailureSidelink message 262. The remote source terminal 210 selects a new Short ID to propose the first remote destination terminal 212. The remoteterminals 210, 212 negotiate a new first Short ID and the conformation process is repeated for the new first Short ID.

[0041] For the example, the source remote terminal 210 does not initiate any other Short ID negotiations until the current the Short ID is applied to the SRAP for the E2E PC5 RRC link 202. Such a technique avoids confusion regarding multiple Short IDs and confirmation messages with other messages for another E2E link. For the example, therefore, the remote source terminal 210 does not send a second Short ID message 264 until the remote source terminal receives a confirmation or a failure message from the relay terminal 214. The remote source terminal 210 transmits a RRCReconfigurationSidelink message 264 identifying the second Short ID to the relay terminal 214 over the PC5 first hop (2) 248. If the second Short ID is acceptable to the relay terminal 214, the relay terminal sends a second Short ID confirmation message 266, such as a RRCReconfigurationCompleteSidelink message 266, to the remote source terminal 210 over the PC5 first hop (2) 248. The relay terminal 214 also sends a second Short ID confirmation message 268 to the second remote destination terminal 242. For the example, the relay terminal 214 also transmits a RRCReconfigurationSidelink message 268 to the second remote destination terminal 242 identifying the second Short ID over the PC5 second hop (2) 268. The second remote destination terminal 212 confirms receipt of the confirmation message 268 with a RRCReconfigurationCompleteSidelink message 269. Therefore, the Short ID confirmation messages 260, 268 are RRCReconfigurationSidelink messages in the examples. If the second Short ID is not acceptable to the relay terminal 214, the relay terminal 214 transmits a second Short ID rejection message 270 to the remote source terminal 210.

[0042] After remote terminals 210, 212 are notified of the confirmations, the second Short ID is applied to the SRAP layer for the second E2E link and each remote terminal 210, 242 includes the Short ID in the SRAP header for E2E transmissions.214.

[0043] FIG. 2C is a block diagram of the system 200 for an example of Short ID (Local ID) selection for PC5 SRAP for E2E PC5 communication links 202, 240 formultiple destination terminals 212, 242 and multiple relay terminals 214, 216. A source remote terminal 210 establishes a first E2E PC5 communication link 202 between the source remote terminal 210 and a first destination remote terminal 212 through a first relay terminal 214 and a second relay terminal 216. The source remote terminal 210 also establishes a second E2E PC5 communication link 240 between the source remote terminal 210 and a second destination remote terminal 242 through the relay terminal 214. For the example, the remote and relay terminals use the PreoSe UE IDs such as the L2IDs or User Info IDs to establish the E2E PC5 links 202, 240 in accordance with known techniques. The first E2E PC5 link 202 includes a PC5 first hop 204 between the source remote terminal 210 and the relay terminal 214, a PC5 second hop (2) 206 between the first relay terminal 214 and the second relay terminal 216 and a PC5 third hop 208 between the second relay terminal 216 and the first destination remote terminal 212. The second E2E PC5 link 240 includes a PC5 first hop 248 between the source remote terminal 210 and the relay terminal 214, and a PC5 second hop 250 between the relay terminal 214 and the second destination remote terminal 242.

[0044] After the first E2E PC5 link 202 is established, the source remote terminal 210 and the first destination remote terminal 212 negotiate 218 via the first E2E PC5 link 202 to select a first Short ID (Local ID) for use in the SRAP layer of the protocol stack by the relay terminals 214, 216 for the first E2E link 202. After the second E2E PC5 link 240 is established, the source remote terminal 210 and the second destination remote terminal 242 negotiate 254 via the second E2E PC5 link 240 to select a second Short ID (Local ID) for use in the SRAP layer of the protocol stack by the relay terminal 214 for the second E2E link 240. An example of a suitable negotiation procedure includes the source remote terminal 210 proposing the Short IDs (source-proposed Short IDs) and the destination remote terminals 212, 242 either confirming the source- proposed Short ID or rejecting it by proposing other short IDs (destination-proposed Short IDs).

[0045] After the remote terminals 210, 212, 242 have selected the first Short ID and the second Short ID, the relay terminals 214, 216 are informed of the selection. For the example of FIG. 2C, the confirmation messages for the second Short ID for the secondE2E PC5 link 240 are not transmitted until the confirmation messages for the first Short ID for the first E2E link 202 have been sent and the first Short ID is applied to the SRAP layer for the first E2E link 202. In some situations, the second E2E PC5 link 240 is not established until after the first Short ID is applied to the SRAP layer for the first E2E PC5 link 202.

[0046] The first Short ID is sent from the remote source terminal 210 to the relay terminal 214 in a first Short ID message 220. If the first relay terminal 214 confirms the Short ID is unique and acceptable, the first relay terminal 214 sends the Short ID to the second relay terminal 216. If the second relay terminal 216 confirms the Short ID is unique to other Short ID(s) used by the second relay terminal, the remote terminals 210, 212 are notified of the confirmations.

[0047] For the example of FIG. 2C, the source remote terminal 210 sends the first Short ID over the PC5 first hop (1 ) 204 to the first relay terminal 214 in an RRCReconfigurationSidelink message 220 using a PC5-S link. The first relay terminal 214 evaluates the first Short ID and forwards the first Short ID to the second relay terminal 216 if the first relay terminal 214 determines that the first Short ID does not conflict with any other communication at the first relay terminal 214. The Short ID is included in a RRCReconfigurationSidelink message 222 sent over the PC5 second hop (1 ) 206 using the PC5-RRC link. The second relay terminal 216 evaluates the Short ID and confirms to the first target remote terminal 212 and the first relay terminal 214 that the Short ID is acceptable. A RRCReconfigurationSidelink message 224 is transmitted to the target remote terminal 212 indicating that the Short ID is confirmed. The remote destination terminal 212 confirms receipt of the message 224 with a RRCReconfigurationCompleteSidelink message 225 for the example.

[0048] A RRCReconfigurationCompleteSidelink message 226 is transmitted to the first relay terminal 214 indicating that the first Short ID is confirmed. The first relay terminal 214 then transmits a RRCReconfigurationCompleteSidelink message 228 to the source remote terminal 212 indicating that the first Short ID is confirmed.

[0049] If the relay terminal 214 determines that the first Short ID is not acceptable, the first relay terminal 214 transmits a first Short ID rejection message 262 to the sourceremote terminal 210. For the example, the first Short ID rejection message 262 is a RRCReconfigurationFailureSidelink message 262. If the second relay terminal 216 determines that the first Short ID is not acceptable, the second relay terminal 216 transmits a first Short ID rejection message 232 to the first relay terminal 214. For the example, the Short ID rejection message 232 is a RRCReconfigurationFailureSidelink message 232. The first relay terminal 214 transmits the Short ID rejection message 262 to the source remote terminal 210 in response to receiving the Short ID rejection message 232 from the second relay terminal 216. The remote source terminal 210 selects a new Short ID to propose the first remote destination terminal 212. The remote terminals 210, 212 negotiate a new first Short ID and the confirmation process is repeated for the new first Short ID.

[0050] For the example, the source remote terminal 210 does not initiate any other Short ID negotiations until the current the Short ID is applied to the SRAP for the E2E PC5 RRC link 202. Such a technique avoids confusion regarding multiple Short IDs and confirmation messages with other messages for another E2E link. For the example, therefore, the remote source terminal 210 does not send a second Short ID message 264 until the remote source terminal receives a confirmation or a failure message from the relay terminal 214. The remote source terminal 210 transmits a RRCReconfigurationSidelink message 264 identifying the second Short ID to the relay terminal 214 over the PC5 first hop (2) 248. If the second Short ID is acceptable to the relay terminal 214, the relay terminal sends a second Short ID confirmation message 266, such as a RRCReconfigurationCompleteSidelink message 266, to the remote source terminal 210 over the PC5 first hop (2) 248. The relay terminal 214 also sends a second Short ID confirmation message 268 to the second remote destination terminal 242. For the example, the relay terminal 214 transmits a RRCReconfigurationSidelink message 268 to the second remote destination terminal 242 identifying the second Short ID over the PC5 second hop (2) 268. The second remote destination terminal 242 confirms receipt of the message 268 with a RRCReconfigurationCompleteSidelink message 269 for the example.

[0051] If the second Short ID is not acceptable to the relay terminal 214, the relay terminal 214 transmits a second Short ID rejection message 270 to the remote source terminal 210.

[0052] After remote terminals 210, 212 are notified of the confirmations, the second Short ID is applied to the SRAP layer for the second E2E link and each remote terminal 210, 242 includes the second Short ID in the SRAP header for E2E transmissions.

[0053] FIG. 2D is a block diagram of a system 200 for an example of Short ID (Local ID) selection for PC5 SRAP for an E2E PC5 communication link 202 with multiple hops 204, 206, 208. For the example of FIG. 2D, the Short ID is not selected by the remote terminals 210, 212 over the E2E PC5 link prior to the confirmation process. Instead, the Short ID is proposed to the chain of relay terminals and then to the remote destination terminal 212 if all of the delay terminals confirm the Short ID is acceptable. A source remote terminal 210 establishes an E2E PC5 communication link 202 between the source remote terminal 210 and a destination remote terminal 212 through a first relay terminal 214 and a second relay terminal 216. For the example, the remote and relay terminals use ProSe UE IDs to establish the E2E PC5 link 202 in accordance with known techniques.

[0054] After the E2E PC5 link (U2U relay communication) is established, the remote source terminal and the remote destination terminal may each transmit information over the established E2E link. In other words, the remote source terminal may be a transmitting terminal or a receiving terminal and the remote destination terminal may be transmitting terminal or a receiving terminal.

[0055] For the example of FIG. 2D, the source remote terminal 210 selects and sends a Short ID over the PC5 first hop 204 to the first relay terminal 214 in an RRCReconfigurationSidelink message 220 using a PC5-RRC link. The message 220 includes at least the Short ID and the ProSe UE ID of the remote destination terminal 212. In some situations, the remote source terminal 210 selects the Short ID based on the ProSe UE ID of the remote source terminal and the ProSe UE ID of the remote destination. An example of a suitable Short ID generated by the remote source terminal includes a Short ID including 4 bits of the L2ID of the remote source terminal 210 and 4bits of the L2ID of the remote destination terminal 212. The first relay terminal 214 evaluates the Short ID and forwards the Short ID to the second relay terminal 216 if the first relay terminal 21 determines that the Short ID does not conflict with any other communication at the first relay terminal 214. The Short ID is included in a RRCReconfigurationSidelink message 222 sent over the PC5 second hop 206 using the PC5-RRC link. The second relay terminal 216 evaluates the Short ID and forwards the Short ID to the remote destination terminal 212 in a Short ID message 280. If the Short ID is acceptable to the remote destination terminal 212, the remote destination terminal 212 confirms the Short ID is acceptable and sends a confirmation message 282 to the second relay terminal 216. In response to the confirmation, the second relay terminal 212 sends a confirmation message 226 to the first relay terminal. In response to the confirmation message 226, the first relay terminal 214 sends a confirmation message 228 to the remote source terminal 210. For the example, the Short ID messages 220, 222, 280 are RRCReconfigurationSidelink messages. The confirmation messages 224, 226, 282, are RRCReconfigurationCompleteSidelink messages. If any of the terminals determine the Short ID unacceptable, the terminal device transits a Short ID rejection message, a terminal device also sends a Short ID rejection message in response to receiving a Short ID rejection message from another terminal device. Accordingly, the remote destination terminal 212 sends a Short ID rejection message 284 to the second relay terminal 216 if the Short ID is in use by the remote destination terminal 212 or if the Short ID is otherwise unacceptable. The second relay terminal 216 sends a Short ID rejection message 232 to the first relay terminal 216 if the Short ID is unacceptable to either the second relay terminal or the remote destination terminal 212. The first relay terminal 214 sends a Short ID rejection message 230 to the remote source terminal 210 if the Short ID is unacceptable to the second relay terminal 216 or in response to receiving a Short ID rejection message 232 from the second relay terminal 216. For the example, the Short ID rejection messages 230, 232, 284 are RRCReconfigurationFailureSidelink m essages.

[0056] Although the example of FIG. 2D includes two relay terminals supporting the E2E link 202, the principles described above can be applied to E2E links including anynumber of relay terminals. In some situations, the SRAP Short ID management technique may be applied to an E2E link including only a single relay terminal.

[0057] FIG. 3 is a block diagram of an example of a UE device 300 suitable for use as each of the terminal devices 210, 212, 214, 216, 242. In some examples, the UE device 300 is any wireless communication device such as a mobile phone, a transceiver modem, a personal digital assistant (PDA), a tablet, or a smartphone. In other examples, the UE device 300 is a machine type communication (MTC) communication device or Internet-of-Things (IOT) device. The UE device 300, therefore is any fixed, mobile, or portable equipment that performs the functions described herein. The various functions and operations of the blocks described with reference to UE device 300 may be implemented in any number of devices, circuits, or elements. Two or more of the functional blocks may be integrated in a single device, and the functions described as performed in any single device may be implemented over several devices.

[0058] The UE device 300 includes at least electronics 302, a transmitter 304 and a receiver 306. The electronics 302 include any combination of hardware, software, and / or firmware for communicating with and controlling other UE device components to execute the functions described herein as well as facilitating the overall functionality of a communication device. The electronics 302, therefore, cooperatively operate with other UE device components to initiate tasks and perform the operations and functions of the UE device 300. An example of suitable electronics 302 includes code running on a microprocessor or processor arrangement connected to memory 310. The transmitter 304 includes electronics configured to transmit wireless signals. In some situations, the transmitter 304 may include multiple transmitters. The receiver 306 includes electronics configured to receive wireless signals. In some situations, the receiver 306 may include multiple receivers. The receiver 306 and transmitter 304 receive and transmit signals, respectively, through antenna 308. The antenna 308 may include separate transmit and receive antennas. In some circumstances, the antenna 308 may include multiple transmit and receive antennas.

[0059] The transmitter 304 and receiver 306 in the example of FIG. 3 perform radio frequency (RF) processing including modulation and demodulation. The receiver 306,therefore, may include components such as low noise amplifiers (LNAs) and filters. The transmitter 304 may include filters and amplifiers. Other components may include isolators, matching circuits, and other RF components. These components in combination or cooperation with other components perform the communication device functions. The required components may depend on the particular functionality required by the communication device.

[0060] The transmitter 304 includes a modulator (not shown), and the receiver 306 includes a demodulator (not shown). The modulator can apply any one of a plurality of modulation orders to modulate the signals to be transmitted as part of the uplink signals. The demodulator demodulates the downlink signals in accordance with one of a plurality of modulation orders.

[0061] The UE device 300 is capable of transmitting and receiving sidelink signals to and from other UE devices as well as communicating with base stations. The electronics 302, in conjunction with the receiver 306, measure an evaluate signals transmitted by other devices, such as base stations and UE devices. The electronics 302 and the receiver 306, therefore, can receive, measure, and evaluate downlink reference signals transmitted by a base station. Signal measurements and evaluations can be stored in the memory 310. The electronics 302 and receiver 306 can also receive, measure and evaluate discovery signals transmitted by nearby UE devices to generate a neighbor list that includes neighbor UE devices within the maximum distance. The neighbor list is stored in the memory 310 and may be transmitted to a base station.

[0062] FIG. 4A is a message diagram for an example of Short ID (Local ID) selection for PC5 SRAP for the E2E PC5 communication link 202 with multiple hops 204, 206, 208.

[0063] At event 402, an E2E communication link is established between the source remote terminal 210 and the remote destination terminal 212. In accordance with known techniques and using the ProSe UE IDs, the E2E PC5 communication link is established.

[0064] At event 404, the source remote terminal 210 and the destination remote terminal 212 negotiate over the E2E PC5 link to select a Short ID. Using PC5-S signaling, the source remote terminal 210 and the destination remote terminal 212 transmit and receive messages to identify a Short ID that is not in use by either terminal 210, 212.

[0065] At transmission 406, a Short ID notification message is sent from the source remote terminal 210 to the first relay terminal 214. For the example, a RRCReconfigurationSidelink message is sent over the PC5 first hop to the first relay terminal 210.

[0066] At event 408, the first relay terminal 214 evaluates the Short ID and determines the Short ID is acceptable. The relay terminal 214 receives the Short ID notification and determines whether the Short ID is being used for another communication link.

[0067] At transmission 410, first relay terminal transmits a Short ID notification to the second relay terminal 216. In response to determining the Short ID is acceptable, the first relay terminal 214 transmits a RRCReconfigurationSidelink message over the PC5 second hop to the second relay terminal 216.

[0068] At event 412, the second relay terminal 216 evaluates the Short ID and determines the Short ID is acceptable. The relay terminal 216 receives the Short ID notification and determines whether the Short ID is being used for another communication link.

[0069] At event 414, the second relay terminal 216 sends a Short ID confirmation notification to the first relay terminal 214 indicating the Short ID is acceptable. In response to determining the Short ID is acceptable, the second relay terminal 216 transmits a RRCReconfigurationCompleteSidelink message over the PC5 second hop to the first relay terminal 214.

[0070] At event 416, the second relay terminal 216 sends a Short ID confirmation notification to the remote destination terminal 212 indicating the Short ID is acceptable. In response to determining the Short ID is acceptable, the second relay terminal 216transmits a RRCReconfigurationCompleteSidelink message over the PC5 third hop to the remote destination terminal 214.

[0071] At event 418, the first relay terminal 214 sends a Short ID confirmation notification to the remote source terminal 210 indicating the Short ID is acceptable. In response to receiving the Short ID confirmation notification from the second relay terminal 216, the first relay terminal 214 transmits a RRCReconfigurationCompleteSidelink message over the PC5 first hop to the remote source terminal 214.

[0072] At event 420, the terminals 210, 212, 214, 216 apply the Short ID to the E2E PC5 communication link 202. The relay terminals 214, 216 apply the short ID to their respective adaption layer entities to perform RB mapping for the E2E PC5 link 202. The headers of E2E transmissions from the remote terminals 210, 212 include the Short ID.

[0073] FIG. 4B is a message diagram for an example of Short ID (Local ID) negotiation between the remote source terminal 210 and the remote destination terminal 212. The example of FIG. 4B is directed to a situation where the source- proposed Short ID is acceptable to the remote destination terminal 212. Events and transmissions 424, 426, 428, 430 are an example of the negotiation event 404 of FIG. 4A.

[0074] After the E2E communication link is established between the source remote terminal 210 and the remote destination terminal 212 at event 402, the remote source selects a Short ID. The selection may be performed in accordance with the remote source terminal implementation. An example of a suitable technique includes selecting a value between 0 and 255 (8 bits) that is not in use.

[0075] At transmission 426, the source remote terminal 210 sends the source- proposed Short ID selected at event 424 to the remote destination terminal 212. Using PC5-S signaling over the E2E connection and the L2IDs of the remote terminals 210, 212, the remote source terminal conveys the source-proposed Short ID to the remote destination terminal 212.

[0076] At event 428, the remote destination terminal 212 determines that the source- proposed Short ID is acceptable. The remote destination terminal 212 evaluates all other communications through, or with, the destination terminal 212 and determines that the Short ID is not in use and is unique to the other communications. Therefore, the remote destination terminal confirms than no other PC5 links where the terminal 212 is either a remote terminal or relay terminal are using the source-proposed Short ID.

[0077] At transmission 430, the remote destination terminal 212 sends a Short ID confirmation message to the remote source terminal 210 indicating the source-proposed short ID is acceptable. Using PC5-S signaling over the E2E connection and the L2IDs of the remote terminals 210, 212, the remote destination terminal 212 confirms to the remote source terminal 210 that the source-proposed Short ID can be used.

[0078] FIG. 4C is a message diagram 440 for an example of Short ID (Local ID) negotiation between the remote source terminal 210 and the remote destination terminal 212 where the source-proposed Short ID is not acceptable to the remote destination terminal 212. Events and transmissions 424, 426, 442, 444, 446, 448, 450 are an example of the negotiation event 404 of FIG. 4A.

[0079] After the E2E communication link is established between the source remote terminal 210 and the remote destination terminal 212 at event 402, the remote source terminal selects a Short ID at event 424. At transmission 426, the remote source terminal 210 sends the selected source-proposed Short ID to the remote destination terminal 212. Using PC5-S signaling over the E2E connection and the L2IDs of the remote terminals 210, 212, the remote source terminal conveys the source-proposed Short ID to the remote destination terminal 212.

[0080] At event 442, the remote destination terminal 212 determines that the source- proposed Short ID is not acceptable. The remote destination terminal 212 evaluates all other communications through, or with, the destination terminal 212 and determines that the Short ID is in use and is not unique to the other communications.

[0081] At event 444, the remote destination terminal 212 selects an alternate Short ID (destination-proposed Short ID). In accordance with the implementation of the remote source terminal, the remote source terminal 210 selects another Short ID that isnot in use. For the example, the remote source terminal 210 selects another value between 0 and 255 that is not use.

[0082] At transmission 446, the remote destination terminal 212 sends the selected destination-proposed Short ID to the remote source terminal 210. Using PC5-S signaling over the E2E connection and the L2IDs of the remote terminals 210, 212, the remote destination terminal conveys the destination-proposed Short ID to the remote source terminal 210.

[0083] At event 448, the remote source terminal 210 determines that the destination- proposed Short ID is acceptable. The remote source terminal 210 evaluates all other communications through, or with, the remote source terminal 210 and determines that the Short ID is not in use and is unique to the other communications. Therefore, the remote source terminal confirms than no other PC5 links where the terminal 210 is either a remote terminal or relay terminal are using the destination-proposed Short ID.

[0084] At transmission 450, the remote source terminal 210 sends a Short ID confirmation message to the remote destination terminal 212 indicating the destination- proposed Short ID is acceptable. Using PC5-S signaling over the E2E connection and the L2IDs of the remote terminals 210, 212, the remote source terminal 210 confirms to the remote destination terminal 212 that the destination-proposed Short ID can be used.

[0085] FIG. 5 is a flow chart of an example of method of managing Short IDs for an E2E PC5 communication link performed at a remote terminal. The method may be performed in a system such the system 100 discussed herein. For the example, the method is performed by a remote terminal, such as the remote source terminal 210. The method may be performed using any of several techniques involving any combination of software, hardware, and firmware. For example, software code running on electronics including a processor, computer or other processor arrangement within the network node may facilitate the generation, formatting, reception and transmission of signals and messages. One or more of the steps may be omitted, combined, performed in parallel, or performed in a different order than that described herein or shown in FIG. 5. In still further examples, additional steps may be added that are not explicitly described in connection with the example discussed with reference to FIG. 5.

[0086] At step 502, an E2E PC5 communication link is established between the remote source terminal and the remote destination terminal. Using the L2IDs the PC5-S signaling between the remote and relay terminals, the E2E PC5 communication link is established.

[0087] At step 504, the remote source terminal and the remote destination terminal negotiate to select a Short ID.

[0088] At step 506, the relay terminals are informed of the selected Short ID. The remote source terminal transmits a Short ID notification message identifying the Short ID to a first relay terminal of the one or more relay terminals facilitating the E2E PC5 communication link.

[0089] At step 508, it is determined whether Short ID has been confirmed by the one or more relay terminals. The remote source terminal determines whether a Short ID confirmation message or a Short ID rejection message has been received from the first relay terminal. If the Short ID has been confirmed as acceptable to the relay terminals, the method continues to sept 510. Otherwise, the method returns to step 504 and the remote terminals negotiate a new Short ID.

[0090] At step 510, the Short ID is included in headers of E2E PC5-RRC transmissions over the E2E PC5-RRC communication link.

[0091] FIG. 6 is a flow chart of an example of method of managing Short IDs for an E2E PC5 communication link performed at a relay terminal. The method may be performed in a system such the system 100 discussed herein. For the example, the method is performed by a relay terminal such as the relay terminal 214 or the relay terminal 216. The method may be performed using any of several techniques involving any combination of software, hardware, and firmware. For example, software code running on electronics including a processor, computer or other processor arrangement within the remote terminal device may facilitate the reception of signals, measurements, and transmissions. One or more of the steps may be omitted, combined, performed in parallel, or performed in a different order than that described herein or shown in FIG. 6. In still further examples, additional steps may be added that are not explicitly described in connection with the example discussed with reference to FIG. 6.

[0092] At step 602, the relay terminal provides relay service to the establish and maintain an E2E PC5 communication link between the remote source terminal and the remote destination terminal.

[0093] At step 604, a Short ID notification message is received from a transmitting terminal. In some situations, the transmitting terminal is the remote source terminal. In other situations, the transiting terminal is another relay terminal. The Short ID notification message identifies the Short ID selected by the remote source terminal and the remote destination terminal.

[0094] At step 606, it is determined whether the Short ID is acceptable to the relay terminal. The relay terminal evaluates other PC5 communication links to, or through the relay terminal to determine whether the Short ID is unique. If the Short ID is acceptable, the method proceeds to step 606. Otherwise, the method continues at step 608 where the relay terminal sends a Short ID rejection message to the transmitting terminal.

[0095] At step 606, the relay terminal determines whether the egress hop is to the remote destination terminal. Therefore, the relay terminal determines if the relay terminal is the last relay to the remote destination terminal in the link 202 or if the egress hop is to another relay terminal. If the egress hop is directly to the remote destination terminal, the method proceeds to step 610. Otherwise, the method continues at step 612.

[0096] At step 610, the relay terminal sends a Short ID confirmation message to the transmitting terminal and sends a Short ID confirmation message to the remote destination terminal. The Short ID confirmation messages indicate that the Short ID is acceptable.

[0097] At step 614, the relay terminal applies the Short ID to the SRAP for the E2E PC5 communication link.

[0098] At step 612, the relay terminal sends a Short ID notification message to the next relay terminal.

[0099] At step 616, it is determined whether the Short ID has been confirmed. If a Short ID confirmation message is received from the next relay terminal, the relayterminal determines that the Short ID is confirmed and the method proceeds to step 618 where relay terminal sends a Short ID confirmation message to the transmitting terminal. If a Short ID rejection message is received from the next relay terminal, the relay terminal determines that the Short ID is not acceptable and is not confirmed and the method proceeds to step 608 where relay terminal sends the Short ID rejection message to the transmitting terminal.

[0100] To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, module, etc. can be configured to perform one or more of the functions described herein. The term "configured to" or "configured for" as used herein with respect to a specified operation or function refers to processors, devices, components, circuits, electronics, and equipment that are physically constructed, programmed, instructed and / or arranged to perform the specified operation or function. Furthermore, the various illustrative logical blocks, modules, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), other electronics or combinations thereof. (ASIC), a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, electronics, and circuits can further include antennas and / or transceivers to communicate with various components within the network or within the device. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein.

[0101] When implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps of a method or algorithm disclosed herein can be implemented as software stored on a computer- readable medium. Computer readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.

[0102] Therefore, the methods and apparatus of this invention may take the form, at least partially, of program logic or program code (i.e., instructions) embodied in tangible media, such as a machine-readable storage medium. When the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. The methods and apparatus of the present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via any other form of transmission. When the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

[0103] Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the present disclosure. It will be appreciated that, for clarity purposes, the above description has described embodiments of the present disclosure with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be usedwithout detracting from the present disclosure. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Therefore, references to specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.

[0104] Clearly, other embodiments and modifications of this invention will occur readily to those of ordinary skill in the art in view of these teachings. The above description is illustrative and not restrictive. This invention is to be limited only by the following claims, which include all such embodiments and modifications when viewed in conjunction with the above specification and accompanying drawings. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

Claims

CLAIMS1 . A method comprising: providing, by a relay terminal, at least a portion of an end-to-end (E2E) PC5 communication link between a remote source terminal and a remote destination terminal; receiving, from a transmitting terminal, a Short ID notification message identifying a Short ID identified by the remote source terminal, the Short ID being shorter than a ProSe UE ID of the remote source terminal and being shorter than a ProSe UE ID of the remote destination terminal; and at least partially in response to determining the Short ID is acceptable to the relay terminal, applying the Short ID to the Sidelink Relay Adaptation Protocol (SRAP) for communication over the E2E PC5 communication link.

2. The method of claim 1 , wherein the Short ID is selected by the remote source terminal and the remote destination terminal.

3. The method of claim 2, at least partially in response to determining the Short ID is acceptable to the relay terminal, transmitting a first Short ID confirmation message to the transmitting terminal.

4. The method of claim 3, further comprising: in response to determining the Short ID is acceptable to the relay terminal, transmitting a second Short ID confirmation message to the remote destination terminal.

5. The method of claim 4, wherein the Short ID notification message is a RRCReconfigurationSidelink message, the first Short ID confirmation message is a first RRCReconfigurationCompleteSidelink message, and the second Short ID confirmation message is a second RRCReconfigurationSidelink message.

6. The method of claim 3, further comprising:in response to determining the Short ID is unacceptable to the relay terminal, transmitting a Short ID rejection message to the transmitting terminal indicating that the Short ID is unacceptable.

7. The method of claim 6, wherein the Short ID rejection message is a RRCReconfigurationFailureSidelink message.

8. The method of claim 6, further comprising: receiving an E2E PC5-RRC message from the transmitting terminal, the E2E RRC-PC5 message comprising a header including the Short ID; and forwarding the E2E RRC-PC5 message to the remote destination terminal.

9. The method of claim 2, wherein the transmitting terminal device is the remote source terminal.

10. The method of claim 2, wherein the E2E PC5 communication link comprises a PC5 first hop between the remote source terminal and the relay terminal, a PC5 second hop between the relay terminal and the another relay terminal and PC5 third hop between the another relay terminal and the remote destination device, the method further comprising: in response to determining the Short ID is acceptable to the relay terminal, transmitting another Short ID notification message identifying the Short ID to the another relay terminal; and in response to receiving a Short ID confirmation message from the another relay terminal indicating the Short ID is acceptable to the another relay, transmitting another Short ID confirmation message to the transmitting terminal.11 . The method of claim 4, wherein the Short ID notification message is a RRCReconfigurationSidelink message, the Short ID confirmation message is a first RRCReconfigurationCompleteSidelink message, and the second Short ID confirmation message is a second RRCReconfigurationCompleteSidelink message.

12. The method of claim 10, further comprising: in response to receiving a Short ID rejection message from indicating the Short ID is unacceptable to the another relay terminal, transmitting another Short ID rejection message to the transmitting terminal indicating that the Short ID is unacceptable.

13. The method of claim 10, wherein the Short ID rejection message is a RRCReconfigurationFailureSidelink message and the another Short ID rejection message is another RRCReconfigurationFailureSidelink message .

14. The method of claim 10, further comprising: receiving an E2E PC5-RRC message from the transmitting terminal, the E2E RRC-PC5 message comprising a header including the Short ID; and forwarding the E2E RRC-PC5 message to the another relay terminal.

15. A relay terminal comprising: a transceiver comprising a transmitter and a receiver, the transceiver configured to provide at least a portion of an end-to-end PC5 communication link between a remote terminal and a remote destination terminal, the receiver configured to receive, from a transmitting terminal, a Short ID notification message identifying a Short ID selected by the remote source terminal and the remote destination terminal, the Short ID being shorter than each of the ProSe UE IDs of the remote source terminal and the remote destination terminal; and a processor configured to, at least partially in response to determining the Short ID is acceptable to the relay terminal, apply the Short ID to the Sidelink Relay Adaptation Protocol (SRAP) for communication over the E2E PC5 communication link.

16. The relay terminal of claim 15, the transmitter configured to, at least partially in response to determining the Short ID is acceptable to the relay terminal, transmit a first Short ID confirmation message to the transmitting terminal.

17. The relay terminal of claim 16, the transmitter further configured to, in response to determining the Short ID is acceptable to the relay terminal, transmit a second Short ID confirmation message to the remote destination terminal.

18. The relay terminal of claim 17, wherein the Short ID notification message is a RRCReconfigurationSidelink message, the first Short ID confirmation message is a first RRCReconfigurationCompleteSidelink message, and the second Short ID confirmation message is a second RRCReconfigurationCompleteSidelink message.

19. The relay terminal of claim 16, further the electronics further configured to, in response to determining the Short ID is unacceptable to the relay terminal, transmit a Short ID rejection message to the transmitting terminal indicating that the Short ID is unacceptable.

20. The relay terminal of claim 19, wherein the Short ID rejection message is a RRCReconfigurationFailureSidelink message.21 . A method comprising: establishing an end-to-end (E2E) PC5 communication link between a remote source terminal and a remote destination terminal through one or more relay terminals; negotiating, by the remote source terminal with the remote destination terminal, to select a Short ID for the E2E PC5 communication link, the Short ID being shorter than each of the ProSe UE IDs of the remote source terminal and the remote destination terminal; transmitting a Short ID notification message identifying the Short ID to a first relay terminal of the one or more relay terminals facilitating the E2E PC5 communication link; receiving a Short ID confirmation message indicating the Short ID is acceptable to the one or more relay terminals; and in response to receiving the confirmation message, including the Short ID in the headers of E2E PC5-RRC transmissions over the E2E PC5 communication link.

22. The method of claim 21 , wherein the Short ID notification message is a RRCReconfigurationSidelink message and the Short ID confirmation message is a first RRCReconfigurationCompleteSidelink message.

Images