RELAYING AND ROUTE SWITCHING

Related Applications

[0001] This application claims the benefit under 35 U.S.C. § 1 19(e) to U.S.

Provisional Application No. 62/214,063, filed September 3, 2015, the entire disclosure of which is hereby incorporated herein by this reference.

Technical Field

[0002] The disclosure may relate generally to the field of wireless

communications, and more specifically to relaying communications between remote user equipment (remote UEs) and evolved Node Bs through relay UEs.

Background

[0003] In recent years, demand for access to fast mobile wireless data for mobile electronic devices has fueled the development of the 3rd Generation Partnership Project (3GPP) long term evolution (LTE) communication system (hereinafter "LTE system"). End users access the LTE system using mobile electronic devices (known as "user equipment," or equivalently "UE") including appropriate electronics and software modules to communicate according to standards set forth by 3GPP.

Brief Description of the Drawings

[0004] FIG. 1 is a simplified block diagram of a system according to a current Enhanced LTE Device to Device ProSe work item.

[0005] FIG. 2 is a simplified block diagram illustrating a communication system including a proposed media access control (MAC) protocol structure for

implementing embodiments of the disclosure.

[0006] FIG. 3 illustrates an example of a new variable-size MAC subheader.

[0007] FIG. 4 is an example signaling diagram illustrating a downlink path switch via a relay UE. [0008] FIG. 5 is an example signaling diagram illustrating an uplink path switch via the relay UE.

[0009] FIGS. 6A-6C illustrate examples of MAC protocol data units (PDUs) to describe traffic multiplexing support at an evolved Node B (eNB).

[0010] FIG. 6A illustrates a downlink MAC PDU of a remote UE.

[0011] FIG. 6B illustrates a downlink MAC PDU of a relay UE.

[0012] FIG. 6C illustrates a combined MAC PDU including elements from the downlink MAC PDU of the remote UE and the downlink MAC PDU of the relay UE.

[0013] FIGS. 7A-7C illustrate examples of MAC PDUs to describe traffic multiplexing support at the remote UE.

[0014] FIG. 7 A illustrates an uplink MAC PDU of the remote UE.

[0015] FIG. 7B illustrates a Sidelink (SL) MAC PDU of the remote UE.

[0016] FIG. 7C illustrates a combined MAC PDU including elements of the uplink

MAC PDU of the remote UE and the SL MAC PDU of the remote UE.

[0017] FIGS. 8A-8C illustrate examples of MAC PDUs to describe traffic multiplexing support at a relay UE.

[0018] FIG. 8A illustrates an uplink MAC PDU of a remote UE.

[0019] FIG. 8B illustrates an uplink MAC PDU of the relay UE.

[0020] FIG. 8C illustrates a combined MAC PDU including elements of the uplink

MAC PDU of the remote UE and the uplink MAC PDU of the relay UE.

[0021] FIG. 9 is a simplified block diagram of an electronic device that may be used in embodiments of the disclosure.

Detailed Description of Preferred Embodiments

[0022] In the following detailed description, reference is made to the

accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those of ordinary skill in the art to practice the disclosure made herein. It should be understood, however, that the detailed description and the specific examples, while indicating examples of embodiments of the disclosure, are given by way of illustration only, and not by way of limitation. From the disclosure, various substitutions, modifications, additions, rearrangements, or combinations thereof within the scope of the disclosure may be made and will become apparent to those of ordinary skill in the art. [0023] In accordance with common practice, the various features illustrated in the drawings may not be drawn to scale. The illustrations presented herein are not meant to be actual views of any particular apparatus (e.g., device, system, etc.) or method, but are merely idealized representations that are employed to describe various embodiments of the disclosure. Accordingly, the dimensions of the various features may be arbitrarily expanded or reduced for clarity. In addition, some of the drawings may be simplified for clarity. Thus, the drawings may not depict all of the components of a given apparatus or all operations of a particular method.

[0024] Information and signals described herein may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the description may be represented by voltages, currents,

electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. Some drawings may illustrate signals as a single signal for clarity of presentation and description. It should be understood by a person of ordinary skill in the art that the signal may represent a bus of signals, wherein the bus may have a variety of bit widths and the present disclosure may be implemented on any number of data signals including a single data signal.

[0025] The various illustrative logical blocks, modules, circuits, and algorithm acts described in connection with embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and acts are described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the disclosure described herein.

[0026] In addition, it is noted that the embodiments may be described in terms of a process that is depicted as a flowchart, a flow diagram, a structure diagram, a signaling diagram, or a block diagram. Although a flowchart or signaling diagram may describe operational acts as a sequential process, many of these acts can be performed in another sequence, in parallel, or substantially concurrently. In addition, the order of the acts may be re-arranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. Furthermore, the methods disclosed herein may be implemented in hardware, software, or both. If implemented in software, the functions may be stored or transmitted as one or more computer- readable instructions (e.g., software code) on a computer-readable medium.

Computer-readable media includes both computer storage media (i.e., non-transitory media) and communication media including any medium that facilitates transfer of a computer program from one place to another.

[0027] Wireless mobile communication technology uses various standards and protocols governing communications between a base station and a wireless mobile device. For example, well-known standards include the 3rd Generation Partnership Project (3GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly known to industry groups as worldwide interoperability for microwave access (WiMAX), and the IEEE 802.1 1 standard, which is commonly known to industry groups as Wi-Fi. In 3GPP radio access networks (RANs) in LTE systems, the base station can include Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) and/or Radio Network Controllers (RNCs) in an E-UTRAN, which communicate with a wireless communication device, also known as user equipment (UE).

[0028] As used herein, the term "user equipment," or "UE," refers to end-user wireless devices capable of communicating with eNBs of an LTE network, either directly or indirectly through other UEs.

[0029] As used herein, the term "remote user equipment," or "remote UE" refers to end-user electronic devices (e.g., wearables, such as, for example, smart watches, smart glasses, etc., and/or other mobile devices such as, for example, smart phones, tablets, etc.) capable of directly communicating with other UEs, and indirectly with eNBs through the other UEs that are in direct communication with the eNBs. Remote UEs may or may not be capable of communicating directly with eNBs. For example, a remote UE implemented as a smartphone may be capable of operating as a relay UE, and also be capable of direct communication with eNBs. As another example, a remote UE implemented as a smart watch may be capable of indirect communication with eNBs through other UEs (e.g., smartphones, tablets, etc.), but not direct communication with the eNBs. [0030] As used herein, the term "relay user equipment," or "relay UE" refers to end-user electronic devices capable of directly communicating with eNBs and other UEs, and that are capable of serving as a communication relay between remote UEs and the eNBs.

[0031] As used herein, the terms "legacy," and "Legacy LTE system" refer to LTE systems built according to a legacy version of the 3GPP standards (e.g., releases 8- 12).

[0032] As used herein, the term "uplink," or equivalently "UL," refers to data flowing in a direction from a UE to an eNB. Also, as used herein, the term

"downlink," or equivalently "DL," refers to data flowing in a direction from an eNB to a UE.

[0033] The current Enhanced LTE Device to Device ProSe (also referred to herein as D2D) work item (i.e., 3GPP TS 23.303, "Technical Specification Group Services and System Aspects; Proximity -based services (ProSe)") provides for communication between a remote UE and an eNB via a UE functioning as a communication relay (also referred to herein as "relay UE" between the remote UE and the eNB. Under the current Enhanced LTE Device to Device ProSe work item, a relay UE functions as a Layer-3 relay (i.e. an IP router), and the following functions are to be supported by the relay UE:

• Unicast relaying: Based on one-to-one direct communication between a

Remote UE, that is not served directly by E-UTRAN, including support for the relaying of unicast traffic (UL and DL) between the Remote UEs and the E- UTRAN. The ProSe UE-to-Network Relay provides a generic Layer-3 forwarding function that can relay any type of IP traffic that is relevant for public safety communication.

• eMBMS relay support: One to many communication, including support for the relaying of eMBMS to Remote UEs served by the UE-to-network (UE-toNW) NW Relay.

• ECGI announcement: The announcement of the ECGI by a ProSe UE-to-NW Relay allowing remote UEs served by a ProSe UE-to-NW Relay to receive the value of the ECGI of the cell serving the ProSe UE-to-NW Relay.

[0034] FIG. 1 is a simplified block diagram of a system 100 according to the current Enhanced LTE Device to Device ProSe work item. As shown in FIG. 1 , a remote UE 1 10 is generally considered out-of-coverage of a network, but may use relay support, through a ProSe UE-to-network relay 120 (sometimes referred to herein as "relay UE" 120, "UE" 120, or "relay" 120) to access the network. The system 100 may also include at least one eNB 130 (e.g., including at least a computer readable media (CRM) 132) configured to serve as a point of

communication that the relay UE 120 may communicate with to access the network. The primary use case driving this scenario is public safety.

[0035] The remote UE 1 10 may access the network via the relay UE 120 using an interface called a "PC5" interface. Also, the relay UE 120 may connect to the network (in other words, to the eNB 130) using a legacy Uu interface. The relay UE 120 is assumed to be in-coverage substantially all the time.

[0036] The introduced LTE ProSe framework may be further enhanced to support General use cases that transport any type of data communication traffic in-between UEs 120 or between the E-UTRAN and the UEs 120 (i.e., through the eNB 130) for seamless services, regardless of whether the connection is direct or with intervention from relays. Embodiments disclosed herein relate to an advanced relaying capability designed to achieve better network traffic management/offloading and improved user experience. Goals of the advanced relaying capability include the following:

• route any network traffic (e.g., control-plane network traffic, user-plane

network traffic, and a combination thereof) over any paths that may involve different interfaces. By way of non-limiting example, the PC5 interface may be used for device-to-device (D2D) communications, and the Uu interface may be used for direct communications between UEs and the E-UTRAN.

• provide flexible multiplexing of network traffic over any link

• support dynamic path switching with minimal service interruption

• support remote UEs 1 10 both in RRC-Connected and in RRC-ldle, and both out of coverage and in coverage.

[0037] One principle of the disclosure is to modify a Legacy LTE system (e.g., as of Rel-13) to support data relaying for remote UEs 1 10 through relay UEs 120 without routing configuration when the relay changes, or when direct to relay-path change occurs. In other words, embodiments of the disclosure accommodate how data (either control-plane or user-plane) from the remote UE 1 10 may be conveyed on a newly discovered or switched path, immediately after the decision for the newly discovered or switched path is made, without having to set-up the routing

configurations along the new path that may incur signalling overhead and/or service interruption.

[0038] In the legacy LTE system, each time a relay change or direct to relay-path change occurs, the agreed Layer-3 Relay (i.e., IP router) specifies that the 1 -to-1 direct communication over PC5 interface between the Remote UE 1 10 and the new relay UE 120 be established, and that an IP address for routing be configured. Other solutions may perform the Layer-2 relaying above a MAC/RLC/PDCP layer. Thus, each time relay changes, or a direct to relay-path change occurs, it is specified that routing configurations along the new path be set up, such as the 1 -to-1 direct communication over PC5 interface between the remote UE 1 10 and the new relay UE 120 and the corresponding LC (Logical Channel) mapping configurations. As a result, relatively involved signalling overhead between the remote UE 1 10, the relay UE 120, and an E-UTRAN may occur, and may lead to service interruptions.

Moreover, due to the specifications, the support of the remote UE 1 10 may be limited to being RRC-Connected in both Layer-3 Relay and Layer-2 Relay above

MAC/RLC/PDCP layer solutions.

[0039] The advanced relaying capability disclosed herein does not use such routing configurations when relaying network traffic (e.g., data) from the remote UE 1 10, regardless of whether the remote UE 1 10 is operating in RRC-Connected or in RRC-ldle. Relaying of network traffic may, therefore, follow substantially

immediately on a new path once a switch and/or a new path is decided.

[0040] Some example embodiments disclosed herein include remote User Equipment (remote UE). The remote UE includes one or more communication elements configured to enable the remote UE to communicate with relay User Equipment (relay UE). The remote UE also includes control circuitry including at least one processor programmed with elements of a protocol stack including a media access control (MAC) layer. The MAC layer includes at least a Uu interface entity and a PC5 interface entity. The at least one processor is also programmed with a MAC-Relay configured to enable the at least one processor to communicate with an evolved Node B (eNB) through the relay UE, and perform route switching of network traffic within the MAC layer between the Uu interface entity and the PC5 interface entity. [0041] Some example embodiments disclosed herein include relay User

Equipment (relay UE) including wireless data links configured to enable the relay UE to communicate with remote User Equipment (remote UE) and an evolved node B (eNB). The relay UE also includes logic, at least a portion of which includes circuitry configured to implement elements of a protocol stack including a layer-2. The layer- 2 includes at least a Uu interface entity and a PC5 interface entity. Circuitry is also configured to implement a relay configured to communicatively couple (De)- Multiplexing & Logical Channel Prioritization (Mux & LCP) components and Hybrid Automatic Repeat Request (HARQ) components of the Uu interface entity and the PC5 interface entity across the Uu interface entity and the PC5 interface entity, and perform network traffic relaying between the remote UE and the eNB.

[0042] Some example embodiments disclosed herein include an enabled evolved Node B (eNB) including a non-transitory computer-readable medium operably coupled ot a processor. The non-transitory computer-readable medium includes computer-readable instructions stored thereon. The computer-readable instructions are configure to instruct the processor to execute a layer-2 relay configured to enable the eNB to communicate with remote User Equipment (remote UE) through relay User Equipment (relay UE). The layer-2 relay is also configured to perform route switching of network traffic within a layer-2 between different interface entities of the relay UE

[0043] FIG. 2 is a simplified block diagram illustrating a communication system 200 including a proposed MAC-relay protocol structure for implementing

embodiments of the disclosure. The MAC-Relay protocol may be referred to herein simply as "MAC-Relay." The MAC-relay protocol structure may include legacy protocol stacks 240A, 240B, and 240C (sometimes referred to herein together as "legacy stacks" 240) (e.g., layer 3: RRC/IP 202, layer 2: PDCP 204, RLC 206, and MAC 208) at each of a remote UE 210, a relay UE 220, and an eNB 230,

respectively. The MAC-relay protocol structure may also include MAC-Relay protocols 250A, 250B, and 250C (sometimes referred to herein generically together as "MAC-Relays" 250, and separately as "MAC-Relay" 250), respectively, at each of the remote UE 210, the relay UE 220, and the eNB 230.

[0044] The MAC-Relay protocols 250 may support route switching of network traffic, forwarding of network traffic, relaying of network traffic, or combinations thereof while other protocol layers (e.g., RRC/IP 202, PDCP 204, RLC 206, and MAC 208) are kept intact. The MAC-Relays 250 may be located between (De)- Multiplexing & Logical Channel Prioritization components 262A1 , 262A2, 262B1 , 262B2, 262C1 , and 262C2 (sometimes referred to herein generically together as "MUX & LCP" 262, and separately as "MUX & LCP" 262) and HARQ components 264A1 , 264A2, 264B1 , 264B2, 264C1 , and 264C2 (sometimes referred to herein generically together as "HARQ" 264, and separately as "HARQ" 264) of the legacy MAC-layer 208.

[0045] The MAC-Relays 250 may connect the MUX & LCP 262 and the HARQ 264 over different MAC entities 208 (e.g., PC5-MAC and UU-MAC). By way of non- limiting example, FIG. 2 illustrates that the MAC-Relay 250A connects the MUX & LCP 262A1 and the HARQ 264 A1 of the UU-MAC 208A1 to the MUX & LCP 262A2 and the HARQ 264A2 of the PC5-MAC 208A2 within the remote UE 210. Similar connectivity is achieved within the relay UE 220 and the eNB 230 by the

MAC-Relays 250B and 250C, respectively.

[0046] The Mux & LCP 262 may be connected to logical channels that are established as default, when necessary, or a combination thereof. Functions performed by the MUX & LCP 262 may be similar to those performed by legacy (De)-Multiplexing and the legacy Logical Channel Prioritization within a MAC layer that assembles/dissembles a MAC PDU from/into RLC PDUs of the associated logical channels, jointly with MAC CEs.

[0047] Similar to legacy HARQ, the HARQ components 264B2, 264C1 of Uu interface MAC entities 208B2, 208C1 (sometimes referred to herein as "Uu-MAC" 208B2, 208C1 ) may be connected to legacy transport channels of DL-SCH and UL- SCH. Also similar to legacy HARQ, the HARQ components 264A2, 264B1 of PC5 interface MAC entity 208A2, 208B1 (sometimes referred to herein as "PC5-MAC" 208A2, 208B1 ) may be connected to the legacy transport channel of SL-SCH. The function performed in HARQ 264 may be similar to those performed by the legacy HARQ within a MAC layer that supports re-transmissions, error-correction, and HARQ feedbacks to an associated MAC PDU.

[0048] In the UE side (including the Remote UE 210 and the Relay UE 220), MAC-Relays 250 may connect Mux & LCP 262 and HARQ 264 components over PC5-MAC 208A2, 208B1 and Uu-MAC 208A1 , 208B2. In the eNB 230 side, MAC- Relays 250 may connect Mux & LCP 262 and HARQ 264 components over Uu-MAC entities 208C1 , 208C2 of all the UEs that are served by the eNB 230. In the specific implementation shown in FIG. 2, in the eNB 230 side, there are different Uu-MAC entities 208 for each served UE. It is also contemplated within the scope of the disclosure that there may be a single MAC entity 208 in the eNB 230 side that supports all the served UEs simultaneously, wherein a MAC-Relay 250 of the eNB 230 may be located in-between a single Mux & LCP component 262 and a single HARQ component 264.

[0049] Description of a Downlink (DL) Data Flow When a New Path is Via a Relay UE 220.

[0050] In the downlink direction, if a DL path switch via the relay UE 220 is decided, the MAC-Relay 250C of the eNB 230 may map a MAC PDU for the remote UE 210 (generated by the Mux & LCP 262C2 of the Uu-MAC 208C2 corresponding to the remote UE 210) onto the HARQ component 264C1 of the Uu-MAC 208C1 corresponding to the relay UE 220 at the eNB 230. The MAC PDU may be further delivered to the MAC-Relay 250B of the relay UE 220 through the DL-SCH and the HARQ 264B2 of the Uu-MAC 208B1 of the relay UE 220. The MAC-Relay 250B of the relay UE 220 may deliver the MAC PDU to the Mux & LCP component 262A1 of the Uu-MAC 208A1 of the remote UE 210 by passing the MAC PDU through the HARQ 264B1 of the PC5-MAC 208B2 of the relay UE 220, the SL-SCH, the HARQ 264A2 of the PC5-MAC 208A2 , and finally through the MAC-Relay 250A of the remote UE 210.

[0051] In other words, the MAC-Relays 250A and 250C at the Remote UE 210 and the eNB 230 may perform route switching, while the MAC-Relay 250B of the relay UE 220 may perform network traffic relaying. For the DL direction, the eNB 230 may know the new path decision so that the MAC-Relay 250C of the the eNB 230 may perform the proper route switching substantially immediately after the new DL path is decided. On the other hand, the MAC-Relays 250A and 250B at the relay UE 210 and at the remote UE 220 may not know the new DL path decision. The MAC-Relays 250A and 250B may learn the new DL path while a MAC PDU is being delivered along the new DL path. Moreover, the MAC-Relay 250B of the Relay UE 220 may learn that a MAC PDU delivered through its DL-SCH is intended to be delivered to the remote UE 210, not to itself (in legacy, a UE assumes that a DL MAC PDU delivered through DL-SCH resources allocated by an eNB and addressed to the UE is intended to be delivered to itself). [0052] A new variable-size MAC subheader may be used to resolve these issues. For example, FIG. 3 illustrates an example of a new variable-size MAC subheader 300 format that may be used. The new variable-size MAC subheader 300 may include reserved bits 310 (sometimes referred to herein as "R bits" 310), an extension field 320 (sometimes referred to herein as Έ field" 320), a version field 330 (sometimes referred to herein as "V field" 330) (e.g. , 5 bits), and an information field 340 (sometimes referred to herein as "FIX(V) field" 340). The reserved bits 310 (R 310) may be generally set to "0". To support relaying of MAC PDUs from the relay UE 220 to other UEs (e.g. , the remote UE 210), however, at least one of reserved bits 310 may be set to the value "1 " (e.g. , RR="1 1 ", RR = "01 ", or RR = "10"). Accordingly, the reserved bits 310 may be used to indicate to the relay UE 220 whether the MAC PDU is intended for the relay UE 220 (i.e. , R = "00"), or whether the MAC PDU is intended for another UE (e.g. , the remote UE 210) (i.e. , R ≠ "00").

[0053] The extension field 320 (E field 320) may be a flag indicating whether more fields are present in the MAC header. By way of non-limiting example, the extension field 320 may be set to "1 " to indicate that there is another set of at least R/R/E/LCID fields. Also by way of non-limiting example, the extension field 320 may be set to "0" to indicate that one of MAC SDU, a MAC control element, and a padding element starts at the next byte.

[0054] The information field 340 (FIX(V) field 340) may contain information, such as a Layer-2 ID, that instructs the MAC-Relays 250 to perform certain functions. The content and the size of the information field 340 may be pre-defined and fixed, depending on the values of the version field 330 that are used. By way of non- limiting example, if the version field 330 has 5 bits, up to 32 different cases may be supported.

[0055] Referring to FIGS. 2 and 3 together, the new MAC subheader 300 for DL- SCH/UL-SCH/SL-SCH may be designed not to be associated with a MAC service data unit (SDU) or a MAC control element (CE). The MAC-Relay 250C at the eNB 230 may prefix the new MAC subheader 300 to the MAC PDU of the remote UE 210 before passing to the HARQ component 264C1 of the Uu-MAC 208C1 associated with the relay UE 220 at the eNB 230. The FIX(V) field 340 may be addressed to the layer-2 ID of the remote UE 210 so that once the MAC-Relay 250B of the relay UE 220 receives the MAC PDU through the DL-SCH and the HARQ component 264B2 of the Uu-MAC 208B1 , the relay UE 220 may be informed that the MAC PDU is not intended to itself, but instead should be forwarded to the remote UE 210.

[0056] The FIX(V) field 340 may include a new layer-2 ID assigned by the eNB 230 that the remote UE 210 should update accordingly for the local layer-2 ID uniqueness. In order to relay the MAC PDU further to the remote UE 210 through the PC5 interface, the MAC-Relay 250B of the relay UE 220 may prefix the legacy SL-SCH MAC subheader to the MAC PDU (where the SRC field is addressed to the layer-2 ID of the relay UE 220 and the DST field is addressed to the most significant 16 bits of the layer-2 ID of the remote UE 210). Once the MAC-Relay 250A of the remote UE 210 receives the MAC PDU through SL-SCH and the HARQ component 264A2 of PC5-MAC 208A2, the MAC-Relay 250A may remove the legacy SL-SCH MAC subheader, and determine that the MAC PDU is intended for itself by reading the MAC subheader 300. The MAC-Relay 250A of the remote UE 210 may further remove the new MAC subheader 300 and deliver the remaining MAC PDU (i.e., the MAC PDU of the remote UE 210 generated at the eNB 230) to the Mux & LCP 262A1 of the Uu-MAC 208A1 .

[0057] FIG. 4 is an example signalling diagram 400 illustrating a downlink path switch via the relay UE 220. After a path switch decision 460 or 570, the DL MAC PDU immediately follows on the new relay-path without additional signalling overhead between the remote UE 210, the relay UE 220, and the eNB 230. In order to support this seamless mobility feature for a DL path switch, the eNB 230 should initiate the DL flow on the new path, regardless of whether the DL path switch is decided by the remote UE 210 or by the eNB 230.

[0058] For a DL path switch, the remote UE 210 of interest may be assumed to be operating 440 in an RRC-Connected mode. If the remote UE 210 is operating instead in an RRC-ldle mode, it may be assumed that the remote UE 210 will switch to operate 440 in the RRC-Connected mode at least before operations 460 or 470 because the remote UE 210 in RRC-ldle should operate in RRC-Connected to receive the DL traffic. The DL traffic may be received either directly (e.g., by paging) or via the relay UE 220. Signalling for establishing the RRC connection may be the same or similar to that used for a legacy LTE system.

[0059] The remote UE 210 may discover 450 relay UEs 220 that are proximate to the remote UE 210. The signalling for performing the discovery 450 may be the same or similar to that used for discovery in a legacy LTE system. By way of non- limiting example, discovery 450 may be based on Model A, where relay UEs 220 periodically transmit an announcement message. Also by way of non-limiting example, discovery 450 may be based on Model B discovery, where the remote UE 210 transmits a solicitation message and any relay UE 220 that receives the solicitation message may respond. Once discovery 450 is completed, the remote UE 210 may obtain a layer-2 ID(s) of the relay UE(s) 220 that are proximate to the remote UE 210.

[0060] Once discovery 450 is completed, and the remote UE 210 obtains the layer-2 IDs of the relay UEs 220, a DL path switch may be decided 460 or 470 by either the eNB 230 or the remote UE 210, respectively. In some embodiments, the eNB 230 may decide 460 the DL path switch. In order for a DL path switch to be decided 460 by the eNB 230, the remote UE 210 may perform measurement reporting 460A to the eNB 230. The reported measurements may indicate an identity (e.g., a layer 2 ID) of the remote UE 210, and the layer-2 ID(s) of the relay UE(s) 220 discovered during discovery 450. In some embodiments, the reporting measurement may also include measurements of at least one of a signal level and a signal quality of each of the communication links from the relay UE(s) 220 to the network. In some embodiments, the reporting measurement may also include measurements of at least one of a signal level and a signal quality of the

communication links from the remote UE 210 to the relay UE(s) 220 (e.g., the PC5 link qualities between the remote UE 210 and the relay UE(s) 220) instead of, or in addition to, the level and quality of the communication links between the relay UE(s) 220 and the network. Configuration parameters to control the measurement reporting 460A may have been previously provided by the eNB 230 to the remote UE 210, in some instances.

[0061] Once the eNB 230 receives measurement reporting 460A, the eNB 230 may enlist the layer-2 ID of the remote UE 210, if that has not yet been done. The eNB 230 may select 460 one relay UE 220 for a new DL path, and the decision 470A may be made based, at least in part, on the information provided during the measurement reporting 460A, measurements taken by the eNB 230, other information (e.g., traffic load, etc.), and combinations thereof.

[0062] In some embodiments, the remote UE 210 may decide 470 the DL path switch. The remote UE 210 may decide 470 the DL path switch by selecting one of the relay UE(s) 220 discovered during discovery 450. In some embodiments, a decision 470A may be made based, at least in part, on at least one of a signal level and a quality of the communication links between the relay UE(s) 220 and the network (e.g., the eNB 230). In some embodiments, the decision 460A may be made based, at least in part, on at least one of a signal level and a quality of the communication links between the remote UE 210 and the relay UE(s) 220 instead of, or in addition to, the signal level and/or quality of the communication links between the relay UE(s) 220 and the network. In some embodiments, the decision 470A may be made based, at least in part, on other information, such as, for example, traffic load.

[0063] The remote UE 210 may inform the eNB 230 by transmitting 470B an RRC connection reestablishment request message or a new message that includes at least the identities of the remote UE 210 and the chosen relay UE 220. The eNB 230 may enlist the layer-2 ID of the remote UE 210 if it has not previously been done.

[0064] Once a relay UE 220 is chosen for a new DL path to the remote UE 210, the eNB 230 may perform 480 any of several operations. For example, the eNB 230 may prepare DL handover (HO). By way of non-limiting example, if the chosen relay UE 220 is served by another eNB 230 (target eNB 230) in a different entity, the eNB 230 may send the layer-2 configurations of the remote UE to the target eNB 230. The target eNB 230 may assign a new cell radio network temporary identifier (C- RNTI) and a new Layer-2 ID to the remote UE 210 that can be delivered together with a DL MAC PDU of the remote UE 210 (during delivery 490 of the DL user data through the relay UE 220). In such instances, the target eNB 230 may perform operations 490, 492, and 494, as will be discussed below.

[0065] Referring now to FIGS. 2, 3, and 4 together, the DL MAC PDU may follow 490 on the new relay path from the eNB 230. Following the new DL path switching, a MAC-Relay 250C of the eNB 230 may route 492 the DL MAC PDU of the remote UE 210 to a HARQ 208C1 of a Uu-MAC 208C1 at the eNB 230 that is associated with the relay UE 220. The MAC-Relay 450C may prefix the MAC subheader 300 to the MAC PDU, and a FIX(V) field 340 of the MAC subheader 300 may indicate the Layer-2 ID of the remote UE 210. The FIX(V) field 340 may also indicate a new layer-2 ID for the remote UE 210 to update the Layer-2 ID for local Layer-2 ID uniqueness. [0066] The MAC PDU may be transported 494 to the relay UE 210 over a Uu interface, similarly to how the MAC PDU is transported in legacy LTE systems. Also, DL resource allocation for the Uu interface may be similar to that for legacy LTE systems.

[0067] A MAC-Relay 250B of the relay UE 220 may also perform 496 some operations. For example, the MAC-Relay 250B may receive the MAC PDU through the UU interface. The new MAC subheader 300 may indicate to the MAC-Relay 250B that the MAC PDU should be forwarded to the remote UE 210. The MAC- Relay 250 may notify the higher-layer to enlist itself as a relay for the DL flow of the remote UE DL, if that has not been previously done. The MAC-Relay 250B may then prefix a legacy SL-SCH MAC subheader to the MAC PDU, and route the MAC PDU with the legacy SL-SCH MAC subheader to a HARQ component 264A2 of the PC5-MAC 208A2 of the remote UE 210. If the new layer-2 ID of the remote UE 210 is included in the new MAC subheader 300, the relay UE 210 may update the layer-2 ID of the remote UE 210, accordingly, after the MAC PDU is delivered to the remote UE 210.

[0068] Transporting 498 the MAC PDU to the remote UE 210 through the PC5 interface may be performed similarly as in legacy LTE systems. The resource allocation for the PC5 interface may also be similar to that of legacy LTE systems. By way of non-limiting example, the resource allocation for the PC5 interface may be based on Mode A, which may involve Sidelink BSR and PDCCH (addressed by SL- RNTI) between the relay UE 210 and the eNB 230. Also by way of non-limiting example, the resource allocation for the PC5 interface may be based on Mode B of an autonomous selection over the pre-configured resource pool.

[0069] The MAC-Relay 250A of the remote UE 210 may also perform 499 several operations. For example, the MAC-Relay 250A may receive the MAC PDU. Also, the MAC-Relay 250A may read and remove the SL-SCH MAC subheader. The SL-SCH MAC subheader may indicate to the MAC-Relay 250A that the MAC PDU is from the network. The MAC-Relay 250 may notify the higher-layer to update with information indicating that the DL flow is now coming through the relay UE 220, if it has not previously been done. If a new layer-2 ID is included in the new MAC subheader 300, the remote UE 210 may notify the higher-layer to update the layer-2 ID accordingly. The MAC-Relay 250A may further remove the new MAC subheader 300 and deliver the remaining MAC PDU to the Mux & LCP component 262A1 of the Uu-MAC 208A1 of the remote UE 210.

[0070] Description of a UL Data Flow When a New Path is Via a Relay UE.

[0071] Referring again to FIGS. 2 and 3, the remote UE 210 to network direction (uplink) may roughly follow procedures that are reverse of the procedures discussed above with reference to the downlink direction. If a UL path switch via the relay UE 220 is decided, a MAC-Relay 250A of the remote UE 210 may map a MAC PDU (generated by the Mux & LCP 262A1 of the UU-MAC 208A1 of the relay UE 210) onto the HARQ component 264A2 of the PC5-MAC 208A2 of the remote UE 210. Along this mapping, the MAC-Relay 250A may sequentially prefix the MAC subheader 300 and the legacy SL-SCH MAC subheader (where the SRC field is addressed to the layer-2 ID of the remote UE 210 and the DST field is addressed to the most significant 16 bits of the layer-2 ID of the relay UE 220) to the MAC PDU. The FIX(V) field 340 of the new MAC subheader 300 may be empty, or addressed to the layer-2 ID of the remote UE 210 and/or CGI and/or C-RNTI to discriminate many different use-cases.

[0072] The MAC-Relay 250B of the relay UE 220 may receive the MAC PDU through SL-SCH and the HARQ component 264B1 of the PC5-MAC 208B2 of the relay UE 220. The MAC-Relay 250B may read and remove the legacy SL-SCH MAC subheader. The MAC-Relay 250B may then be informed that the MAC PDU should be forwarded to the network by reading the new MAC subheader 300.

Depending on the contents of the FIX(V) field, the MAC-Relay 250B at the Relay UE 220 may update the contents of the new MAC subheader 300, as appropriate. The Relay UE 220 may notify its high-layer to enlist itself as a relay for the UL flow of the remote UE 210.

[0073] The MAC PDU may be delivered to the MAC-Relay 250C of the eNB 230 through the HARQ component 264B2 of the Uu-MAC 208B1 of the relay UE, the UL- SCH interface, and the HARQ component 264C1 of the Uu-MAC 208C1 of the eNB 230. The MAC-Relay 250C at the eNB may remove the new MAC subheader 300 and deliver the remaining MAC PDU (i.e., the MAC PDU generated by the remote UE 210) to the Mux & LCP component 262C2 of the Uu-MAC 208C2 associated with the remote UE 210 at the eNB 230.

[0074] FIG. 5 is an example signalling diagram 500 illustrating an uplink path switch via the relay UE 220, and involving the remote UE 210 and the eNB 230. After a path switch decision 560A or 570B is made by the remote UE 210 or the eNB 230, respectively, the UL MAC PDU may substantially immediately follow on the new relay path without additional signalling overhead between the remote UE 210, the relay UE 220, and the eNB 230. In order to support a seamless UL path switch, the remote UE 210 may initiate UL flow on the new path, regardless of whether the UL path switch is decided by the remote UE 210 or by the eNB 230.

[0075] For a UL path switch, the Remote UE 210 of interest may be operating in either an RRC-Connected or RRC-ldle mode. A remote UE 210 operating in RRC- Idle mode, and that is out of coverage, may search for a relay UE 220 to assist in initial attach procedures through a relay path. In such instances, the UL path decision should be made by the remote UE 210, not the eNB 230. If, however, the remote UE 210 is operating in RRC-ldle mode, and is in coverage, the remote UE 210 may optionally become RRC-Connected by establishing an RRC Connection directly with the network. The remote UE 210 operating in RRC-ldle mode in coverage may also choose a relay-path for re-establishing RRC Connection.

Signalling used to establish RRC Connection may be similar to that used for a legacy LTE system.

[0076] The Remote UE may discover 550 relay UEs 220 that are proximate to the remote UE 210. The signalling for performing the discovery 550 may be the same or similar to that used for discovery in a legacy LTE system. By way of non-limiting example, discovery 550 may be based on Model A, where the relay UEs 220 periodically transmit an announcement message. Also by way of non-limiting example, discovery 550 may be based on Model B discovery, where the remote UE 210 transmits a solicitation message and any relay UE 220 that receives the solicitation message may respond. The remote UE 210 may obtain layer-2 ID(s) of the relay UE(s) 220 that are proximate to the remote UE 210.

[0077] Once discovery 550 is completed, and the remote UE 210 obtains the layer-2 ID(s) of the relay UE(s) 220, a UL path switch may be decided 560 or 570 by either the remote UE 210 or the eNB 230, respectively. In some embodiments, the remote UE 210 may decide 560 the UL path switch. The remote UE 210 may decide 560A the UL path switch by selecting one of the relay UE(s) 220 identified during discovery 550. In some embodiments, the decision 560A may be made based, at least in part, on at least one of a signal level and a quality of a communication link between the network and each of the discovered relay UEs 220. In some embodiments, the decision 560A may be made based, at least in part, on at least one of a signal level and a quality of a communication link (e.g., the PC5 links) between the remote UE 210 and each of the discovered relay UEs 220, instead of, or in addition to, the signal level and/or quality of communication links between the network and each of the discovered relay UEs 220. In some embodiments, the decision 560A may be based, at least in part, on other information (e.g., traffic load, etc.).

[0078] In order for the UL path switch to be decided 570 by the eNB 230, the remote UE may perform measurement reporting 570A. The remote UE 210 should be RRC-Connected to perform measurement reporting to the eNB 230. If the remote UE 210 is operating in RRC-ldle mode and is in coverage, the remote UE 210 may become RRC-Connected with the network. Measurements reported during the measurement reporting 570A may include the identities of the remote UE 210 and the relay UE(s) 220 discovered during discovery 550. In some embodiments, the measurements reported during the measurement reporting 570A may also include measurements of at least one of the signal level and the quality of communication links between the network and each of the discovered relay UEs 220. In some embodiments, the measurements reported during the measurement reporting 570A may include at least one of a signal level and a quality of communication link between the remote UE 210 and each of the discovered relay UEs 220. In some embodiments, the measurements reported during the measurement reporting 570A may include other information (e.g., traffic load, etc.).

[0079] Configuration parameters to control the measurement reporting 570A may have been previously provided by the eNB 230 to the remote UE 210. The eNB 230 may make a decision 570B to select one Relay UE 220 for the UL path switch. The decision 570B may be made based, at least in part, on the information received from the remote UE 210 during the measurement reporting 570A. If the selected relay UE 210 is served by another eNB 230 in a different entity, the eNB 230 may process UL handover (UL HO) preparation for the remote UE 210. For example, the eNB 230 may transmit the layer-2 configurations of the remote UE210 to the target eNB 230. The target eNB 230 may assign a new C-RNTI for the remote UE 210. In some embodiments, the new C-RNTI may be delivered as a MAC CE, together with a DL MAC PDU of the remote UE 210. In some embodiments, the new C-RNTI may be delivered through additional signalling, such as, for example, through RRC Connection Reconfiguration from the eNB 230. The target eNB 230 may enlist the layer-2 ID of the remote UE 210, if that has not yet been done. The eNB 230 may inform the remote UE 210 through RRC Connection Reconfiguration to initiate the UL MAC PDU delivery on the new path.

[0080] Referring now to FIGS. 2, 3, and 5 together, the UL MAC PDU of the remote UE 210 may follow 580 substantially immediately on the new relay path from the remote UE 210. The MAC-Relay 250A of the remote UE 210 may perform certain operations 581 . For example, following the new UL path switch, MAC-Relay 250A may route the UL MAC PDU of the remote UE 210 onto the HARQ component 264A2 of the PC5-MAC 208A2 of the remote UE 210. Also, the MAC-Relay 250A may prefix a new MAC subheader 300. The FIX(V) field 340 of the new MAC subheader 300 may indicate at least one of the layer-2 ID, the CGI, and the C-RNTI of the remote UE 210 (e.g., depending on use-cases). The MAC-Relay 250 may further prefix the legacy SL-SCH MAC subheader.

[0081] The MAC PDU may be transmitted 582 to the relay UE 220 through the PC5, which may occur similarly as in legacy LTE systems. Resource allocation for the PC5 interface may also be similar to that for a legacy LTE system. By way of non-limiting example, the resource allocation for the PC5 interface may be based on Mode A, if the remote UE is operating in RRC-Connected mode. In such instances, the resource allocation for the PC5 interface may involve Sidelink BSR and PDCCH (addressed by SL-RNTI) signalling directly between the remote UE 210 and the eNB 230. Also by way of non-limiting example, the resource allocation for the PC5 interface may be based on Mode B of the autonomous selection over the pre- configured resource pool.

[0082] The MAC-Relay 250B of the relay UE 220 may also perform 583 certain operations. For example, the MAC-Relay 250B may receive the MAC PDU and remove the SL-SCH MAC subheader. The new MAC subheader 300 may indicate to the MAC-Relay 250B that the UL MAC PDU should be forwarded to the network. The MAC-Relay 250B may also notify the higher-layer to enlist itself as a relay for the UL flow from the remote UE 210, if this has not been previously done.

[0083] The MAC layer 208B of the relay UE 220 may request UL resources to transport the UL MAC PDU of the remote UE 210 to be forwarded. A new version of a UL buffer status report (BSR) may be used because the legacy BSR is designed to report the buffer size of each logical channel group (LCG). The relay UE 220, however, may be oblivious to the LCG of the remote UE 210. Moreover, if the UL path switch is decided 560 by the remote UE (remote UE decision), the new UL BSR may include the LCG information to enable the network to prepare proactively. By way of non-limiting example, proactive preparation by the network may include UL HO preparation, connection request, other preparation, and combinations thereof.

[0084] The relay UE 220 may transmit 584 the new UL DSR to the eNB 230. In the case where the eNB 230 decides 570 the UL path (eNB decision), the remote UE 210 should be RRC-Connected, and the network should specifically know the UL path switch. In contrast, in the case where the remote UE decides 560 the UL path switch, the remote UE 210 may be operating in RRC-ldle mode, and the network may be oblivious to the UL path switch until the eNB 230 that serves the relay UE 220 receives the UL MAC PDU of the remote UE 210. As a result, additional information in the new UL BSR may be beneficial for proactive operation of the eNB 230 (e.g., eNB operations 585).

[0085] By way of non-limiting example, the new UL BSR may indicate the serving CGI, the C-RNTI, and the layer-2 ID of the remote UE 210. A CGI of the eNB 230 that receives the new UL BSR that matches with the serving CGI of the remote UE 210 may indicate that the remote UE 210 has been RRC-Connected to the eNB 230. The eNB 230 may then be informed that the UL path is switched through the relay UE 220. The eNB 230 may then perform 585 certain eNB 230 operations. For example, the eNB may enlist the layer-2 ID of the remote UE, if this has not yet been done. The eNB 230 may also update the mapping between the C-RNTI and layer-2 ID of the remote UE 210. If, however, the new UL BSR indicates a different serving CGI than that associated with the eNB 230 that receives the new UL BSR, this may indicate that the remote UE 210 has been RRC-Connected with another eNB 230 (source eNB 230). Then, the eNB 230 that receives the new UL BSR (the target eNB 230) may receive Layer-2 configurations and perform UL HO preparation with the source eNB 230. The target eNB 230 may assign C-RNTI, enlist the layer-2 ID of the remote UE 210, update the mapping between C-RNTI and layer-2 ID if necessary, and deliver the new C-RNTI to the remote UE 210.

[0086] In some instances, the new UL BSR may only indicate the layer-2 ID of the remote UE 210, and that layer-2 ID may not have been previously enlisted in the eNB 230 that received the new UL BSR. This may indicate that the remote UE is operating in RRC-ldle mode and the eNB 230 may perform Initial Attach/Connection Re-establishment via the relay UE 220 (here it may be assumed that the eNB 230 releases a layer-2 ID of a UE if it is in RRC-ldle, as in legacy, where the eNB 230 releases all Radio Bearers for an RRC-ldle UE). The eNB 230 may prepare for connection request procedures such as, for example, creating UE context, assigning C-RNTI, and enlisting the Layer-2 ID. The eNB 230 may transmit the C-RNTI MAC CE to the remote UE 210. In some instances, however, the new UL BSR may only indicate the layer-2 ID of the remote UE 210, and that layer-2 ID may have been previously enlisted in the eNB 230 that receives the UL BSR. This may indicate that the UL path of the remote UE 210 has been established through the relay UE 220 before.

[0087] UL Grant and transporting 586 may be performed. The UL Grant and transporting 586 may be similar to that of legacy LTE systems. Also, the MAC PDU over Uu interface of the remote UE may be similar as that of legacy LTE systems.

[0088] The MAC-Relay 250C of the eNB 230 may perform 587 certain operations. For example, the MAC-Relay 250C may receive the UL MAC PDU. The MAC-Relay 250C may read the new MAC subheader 300, which may indicate that the UL MAC PDU is intended for the remote UE 210. The MAC-Relay 250C may notify the higher-layer to update to accommodate for UL flow for the remote UE through the relay UE 220, if this has not yet been done. The MAC-Relay 250C may further remove the new MAC subheader 300, and deliver the remaining UL MAC PDU to the Mux & LCP 262A1 of the Uu-MAC 208A1 of the remote UE 210.

[0089] Description of Traffic Multiplexing Support at eNB

[0090] FIGS. 6A through 6C illustrate examples of MAC PDUs 602, 604, and 606 to describe traffic multiplexing support at the eNB 230 (FIG. 2). FIG. 6A illustrates a DL MAC PDU 602 of a remote UE 210. FIG. 6B illustrates a DL MAC PDU 604 of a relay UE 220. FIG. 6C illustrates a combined MAC PDU 606. Referring to FIGS. 2 and 6A-6C together, given that the DL path of the remote UE 210 is through the relay UE 220, the eNB 230 may deliver a DL MAC PDU 604 of the relay UE 220, in addition to the DL MAC PDU 602 of the remote UE (as described with reference to FIG. 4), through the DL-SCH of the relay UE 220 using the MAC subheader 300 of FIG. 3. For example, the Mux & LCP 262C2 of the Uu-MAC 208C2 corresponding to the remote UE 210 at the eNB 230 may generate the MAC PDU 602 of the remote UE 210. The MAC PDU 602 may include three MAC subheaders S1 , S2, and S3, as shown in FIG. 6A. The MAC PDU 602 may also include a corresponding MAC CE and two MAC SDUs, denoted by C1 , U2, and U3, respectively, in FIG. 6A.

[0091] Similarly, the Mux & LCP 262C1 of the Uu-MAC 208C1 corresponding to the relay UE 220 at the eNB 230 may generate the MAC PDU 604 of the relay UE 220, as shown in FIG. 6B. The MAC PDU 604 of the relay UE 220 may be similar to the the MAC PDU 602 of the remote UE 210, including subheaders S1 , S2, and S3, and MAC CE C1 , and MAC SDUs U2 and U3. A last (padding) MAC subheader may be omitted for simplicity, but may be included, in some instances.

[0092] The MAC PDUs 602 and 604 may be passed to the MAC-Relay 250C of the eNB 230. The MAC-Relay 250C may combine the MAC PDUs 602 and 604 to form a combined MAC PDU 606, as illustrated in FIG. 6C. The combined MAC PDU 606 may include the three subheaders S1 , S2, and S3 of the MAC PDU 604 of the relay UE 220 followed by a "G," and the three subheaders S1 , S2, S3 of the MAC PDU 602 of the remote UE 210. These may be followed by the MAC CE C1 , and MAC SDUs U2 and U3 of the MAC PDU 604 of the relay UE 220. Finally, these may be followed by the MAC CE C1 , and MAC SDUs U2 and U3 of the MAC PDU 602 of the remote UE. The capital letter "G" in FIG. 6C denotes the new MAC subheader 300, as shown in FIG. 3. The FIX(V) field 340 (FIG. 3) of the MAC subheader 300 "G" may indicate the layer-2 ID of the remote UE 210.

[0093] The combined MAC PDU 606 may be delivered to the MAC-Relay 250B of the relay UE 220 through the DL-SCH and the HARQ component 264B2 of the Uu- MAC 208B1 of the relay UE 220. The MAC-Relay 250B may separate the combined MAC PDU 606 back into the MAC PDUs 602 and 604. When the MAC-Relay 250B reads the combined MAC PDU 606, the MAC-Relay 250B may assume that the MAC subheaders S1 , S2, and S3 before the new MAC subheader "G" correspond to the MAC CEs or SDUs of the Relay UE 220 by default. The MAC-Relay 250B may also assume that the MAC subheaders after the new MAC subheader "G"

correspond to the remote MAC CEs or SDUs of the remote UE 210, whose Layer-2 ID is indicated by the FIX(V) 340 field of the new MAC subheader "G." It should be noted that the new MAC subheader "G" may not be associated with a MAC CE or a MAC SDU, and the original MAC subheaders and MAC SDUs generated from each MAC entity at the eNB 230 may be kept intact.

[0094] Following the same rule, DL MAC PDUs of many remote UEs 210 that use the relay UE 220 as their DL paths may be multiplexed into a DL MAC PDU of the relay UE 220, distinguished by the new MAC subheaders "G" addressed to the layer- 2 IDs of the remote UEs 210. Moreover, the eNB 230 may know QoS information of all the logical channels of all the served UEs, and the eNB 230 may adaptively change the size of DL RLC PDU of any logical channel of any served UE in parallel. As a result, the MAC-Relay 250C of the eNB 230 may perform optimization algorithms on traffic multiplexing, jointly considering the DL resource scheduling and Uu link qualities, as is done in legacy LTE systems. The eNB 230 may function differently than in legacy LTE systems, however, in that the MAC-Relay 250C may redirect a DL data stream of a remote UE 210 into a DL-SCH of another UE based on the DL path that has been chosen. In other words, the range of logical channels on which the eNB 230 may consider simultaneously in a parallel fashion for DL traffic multiplexing may be kept the same for embodiments of the disclosure as in legacy LTE systems. Other relaying solutions, where a route switch occurs above the MAC layer 208, may not share this benefit because a DL data stream of a remote UE 210 would have to be mapped onto the logical channels of the relay UE 220, and LCID space per UE is limited. In such other relaying solutions, it may be likely that some of the DL data of the remote UE 210 will be buffered and delayed.

[0095] Description of Traffic Multiplexing Support at the Remote UE

[0096] FIGS. 7A through 7B illustrate examples of MAC PDUs 702, 704, and 706 to describe traffic multiplexing support at the remote UE 210. FIG. 7A illustrates a UL MAC PDU 702 of a remote UE 210. FIG. 7B illustrates an SL MAC PDU 704 of the remote UE 210. FIG. 7C illustrates a combined MAC PDU 706. Referring to FIGS. 2 and 7A-7C together, given that the UL path of the remote UE 210 is through the relay UE 220, the remote UE 210 may be capable of substantially simultaneously delivering the SL MAC PDU 704 of the remote UE 210 (intended for the relay UE 220) in addition to the UL MAC PDU 702 (similarly to the support of traffic

multiplexing at the eNB 230, as discussed with reference to FIGS. 6A-6C), using the new MAC subheader 300 of FIG. 3. For example, the Mux & LCP 262A1 of the Uu- MAC 208A1 of the remote UE 210 may generate the UL MAC PDU 702 of the remote UE 210. The UL MAC PDU 702 may include three subheaders S1 , S2, and S3, as shown in FIG. 7A. The UL MAC PDU 702 may also include a corresponding MAC CE and two MAC SDUs, denoted by C1 , U2, and U3 in FIG. 7A.

[0097] Similarly, the Mux & LCP 262A2 of the Uu-MAC 208A1 of the remote UE 210 may generate the SL MAC PDU 704 of the remote UE 210. The SL MAC PDU 704 may include two subheaders S1 and S2, and two MAC SDUs, denoted by U1 and U2 in FIG. 7B. The last (padding) MAC subheader is not shown, for simplicity, but may be included in some instances. Also, it may be assumed that PC5 direct communication may have been established between the remote UE 210 and the relay UE 220 for two STCHs.

[0098] The UL MAC PDU 702 and the SL MAC PDU 704 may be passed to the MAC-Relay 250A of the Remote UE 210. The MAC-Relay 250A may combine the UL MAC PDU 702 and the SL MAC PDU 704 to form the combined MAC PDU 706 of FIG. 7C. The combined MAC PDU 706 may include a SL-SCH MAC subheader SL-S (e.g., a legacy SL-SCH MAC subheader), followed by the two subheaders S1 and S2 of the SL MAC PDU 704 and the new MAC subheader 300 of FIG. 3

(denoted by the capital letter "G"). The FIX(V) field 340 of the new MAC subheader "G" may be empty, or addressed to at least one of the layer-2 ID, the CGI, and the C- RNTI of the remote UE 210 to discriminate many different use-cases for the UL path switch. Following the new MAC subheader "G," the combined MAC PDU 706 may include the three subheaders S1 , S2, and S3 of the UL MAC PDU 702, followed by the two MAC SDUs U1 and U2 of the SL MAC PDU 704, and finally by the MAC CE C1 and the two MAC SDUs U2 and U3 of the UL MAC PDU 702. It should be noted that the SL-SCH MAC subheader (where the SRC field is addressed to the layer-2 address and the of the remote UE 219, and the DST field is addressed to the most significant 16 bits of the layer-2 ID of the relay UE 220) may be prefixed.

[0099] The combined MAC PDU 706 may be delivered to the MAC-Relay 150B of the relay UE 220 through the SL-SCH interface and the HARQ component 264B1 of the PC5-MAC 208B1 of the Relay UE. Tthe MAC-Relay 250B may remove the SL- SCH MAC subheader and separate the combined MAC PDU 706 back into the UL MAC PDU 702 and the SL MAC PDU 704. When the MAC-Relay 250B reads the combined MAC PDU 706, the MAC-Relay 250B may assume that the MAC subheaders S1 , S2 before the new MAC subheader "G" correspond to the PC5 MAC SDUs of the remote UE 210 are intended for the relay UE 220 by default. The MAC- Relay 250B may also assume that the MAC subheaders S1 , S2, and S3 after the new MAC subheader "G" correspond to the MAC SDUs of the remote UE 210, which should be forwarded to the network.

[0100] Similarly as discussed above with reference to FIGS. 6A-6C, once the amount of resources is decided for PC5 SL-SCH transmission (e.g., by SL resource allocation Mode 1 ), the MAC-Relay 250A of the remote UE 210 may be capable of performing and optimizing traffic multiplexing, considering QoS information of all the logical channels involved in Uu-MAC 208A1 and PC5-MAC 208A2.

[0101] Description of Traffic Multiplexing Support at Relay UE

[0102] FIGS. 8A-8C illustrate examples of MAC PDUs 802, 804, and 806 to describe traffic multiplexing support at the relay UE 220 (FIG. 2). FIG. 8A illustrates a UL MAC PDU of the remote UE. FIG. 8B illustrates a UL MAC PDU of the relay UE 220. FIG. 8C illustrates a combined MAC PDU 806. Referring to FIGS. 2 and 8A-8C together, the Mux & LCP 262A1 of the Uu-MAC 208A1 of the remote UE 210 may generate the UL MAC PDU 802 of the remote UE 210. The UL MAC PDU 802 may include the new MAC subheader 300 (denoted in FIG. 8A as "G"), and three subheaders S1 , S2, and S3, as shown in FIG. 8A. The UL MAC PDU 802 may also include a corresponding MAC CE and two MAC SDUs, denoted by C1 , U2, and U3 in FIG. 8A.

[0103] Similarly, the Mux & LCP 262B2 of the Uu-MAC 208B2 of the relay UE 220 may generate the UL MAC PDU 804 of the relay UE 220. The SL MAC PDU 804 may include three subheaders S1 , S2, and S3, a MAC CE C1 , and two MAC SDUs U1 and U2, as shown in FIG. 8B.

[0104] The relay UE 220 may not be capable of performing traffic multiplexing of its own UL MAC PDU 804. The UL MAC PDU 802 of the remote UE 210, however, may be received from the remote UE 210 in a flexible way. Assuming that the 1 -to-1 direct communication over PC5 interface between the remote UE 210 and the relay UE 220 is established, the relay UE 210 may not be capable of performing traffic multiplexing of its own SL MAC PDU intended to the remote UE 210. Aklso, the relay UE 210 may not be capable of performing traffic multiplexing of the DL MAC PDU of the remote UE 210 received from the eNB in a flexible way. Two reasons are as follows.

• Reason 1 : Although the relay UE 220 may adaptively change the size of its own MAC PDU, the MAC-Relay 250B of the relay UE 220 may not be capable of adaptively changing the size of the MAC PDU of the remote UE 210 because the MAC PDU of the remote UE 210 is not generated by the relay UE 220. For example, given the UL grant size for the UL-SCH of the relay UE 220, the relay UE 220 may not be capable of fitting the size of the combined MAC PDU 806 to this UL grant when multiplexing two MAC PDUs 802 and 804 (the UL MAC PDU 804 of the relay UE 220 and the UL MAC PDU 802 of the remote UE 210 received from the remote UE 210).

• Reason 2: Although the relay UE 220 knows QoS information of its own

logical channels when generating its own MAC PDU 804, the relay UE 220 may not know QoS information of MAC SDUs of the MAC PDU 802 of the remote UE that should be forwarded to the network.

[0105] The MAC-Relay protocol may provide solutions to these reasons. Reason 1 may be mitigated by supporting MAC SDU segmentation and re-combining between two MAC-Relays 250 over a single link. It should be noted that it may be sufficient to apply such MAC SDU segmentation and re-combining to MAC SDUs (not MAC CEs) of a MAC PDU 802 that should be forwarded. An example design for such MAC SDU segmentation is discussed below.

[0106] Reason 2 may also be mitigated by including QoS information, such as QCI or ProSe per-packet priority information, of all the MAC SDUs, as part of a MAC PDU 802 of the remote UE 210 before the remote UE 210 or the eNB 230 transmits the MAC PDU 802 to the relay UE 220. Since the remote UE 220 knows such QoS information of its own RBs, the remote UE 210 may add such information to the UL MAC PDU 802 before transmission to the relay UE 220. Similarly, since the eNB 230 knows such QoS information of the RBs of the remote UE 210, the eNB 230 may add such information to the DL MAC PDU 602 (FIG. 6A) of the the Remote UE before transmission to the relay UE 220. This can be realized either by re-using the new MAC subheader 300 of FIG. 2 or by defining a new MAC CE that may be communicated between MAC-Relays 250.

[0107] The UL grant size for the UL-SCH of the relay UE 220 may be given by the eNB 230. The relay UE 210 may adaptively choose the size of its own UL MAC SDUs (=RLC PDUs) to fit the size of this UL grant. Also, the MAC-Relay 250B of the relay UE 210 may adaptively choose segmentation sizes of received MAC SDUs from the remote UE 210 by considering its own RBs's Qos and by reading the QoS information of the new MAC subheader "G." In some embodiments, the size of the MAC PDU 804 of the relay UE 220 may be decided as shown in FIG. 8B, while two MAC SDUs of the MAC PDU 802 of the remote UE 210 may be decided to be segmented. Accordingly, the MAC-Relay 250B of the relay UE 220 may multiplex (e.g., combine) the two MAC PDUs 802 and 804 into the combined MAC PDU 806 of FIG. 8C. The MAC-Relay 250B may also update the MAC subheaders S2 and S3 of the remote UE 210, accordingly, to indicate the segmentation and the correct size of the combined PDU 806. Different values of RR bits310 (FIG. 3), e.g., RR=01 , may be used to indicate corresponding MAC SDU segmentation of the MAC PDU 806. An L field may also be updated to indicate the exact size of the MAC SDU segmented.

[0108] Once the eNB's MAC-Relay receives this combined MAC PDU, then it is further separated into two MAC PDUs as explained before. However, since the eNB's MAC-Relay can know that two MAC SDUs of the Remote UE's UL MAC PDU are segmented, it keeps them in its buffer until the other segmentations arrive further. The last piece of segmentations can be distinguished by using the different values of RR bits, e.g., RR=10, so that when the eNB's MAC-Relay receives the last piece of the Remote UE's segmented MAC SDU, it can further combine pieces altogether. The restored Remote UE's MAC SDU will then be mapped directly to its corresponding RLC layer.

[0109] Such MAC SDU segmentation (and/or RLC PDU segmentation) at the relay UE 220 and re-combining at its 1 -hop neighbour may be thought as changing the RLC PDU size accordingly along that link. Since RLC layers are involved only on both ends that are over 2-hops, (i.e., between the remote UE 210 and the eNB 230), RLC PDU size may be selected and optimized only for one link. This size may not, however, be appropriate for the other link. For example, the size of the UL RLC PDU of the remote UE 210 may be selected optimally for the PC5 link, but such size may not be appropriate for the UL Uu link from the relay UE 220 to the eNB 230. The RLC PDU size may be chosen considering both links simultaneously, but may incur additional signalling overhead between the Remote UE 210, the Relay UE 220, and the eNB. By the MAC SDU segmentation (and/or the RLC PDU segmentation) and re-combining support at provided by the MAC-Relays 250, the RLC PDU size that is optimally chosen only for one link may be further adapted appropriately for the other link.

[0110] Characteristics of Relaying Traffic.

[0111] Some of characteristic of the disclosed approach to relaying traffic may be as follows:

• EPS Bearers may be carried by direct path or Relay-path. IP addresses may be preserved regardless of which path is used to relay the traffic. • Core network and upper protocol layers such as RLC/PDCP/IP/RRC may not be aware that relaying is performed.

• Both user-plane DRBs and control-plane SRBs may be carried via a relay UE 220.

• Security and header compression (provided within the PDCP layer 204)

between the remote UE 210 and the eNB 230 may be the same regardless of the path used to carry the traffic.

• RLC operation between the remote UE 210 and the eNB 230:

o RLC PDUs that are lost at direct/relay path switch or relay UE 220 change may be recovered,

o RLC PDUs lost on either link may be retransmitted on both links, o RLC PDU size that is optimally chosen only for one link may be further adapted appropriately for other links along the path.

• There may be no 1 -to-1 direct communication over PC5 interface, if the

remote UE 210 is only interested in UL/DL traffics to the network via the relay UE 220.

[0112] FIG. 9 is a simplified block diagram of an electronic device 900 that may be used in embodiments of the disclosure. By way of non-limiting example, the remote UE 210, the relay UE 220, and the eNB 230 of FIG. 2 may each include at least a portion of the features that will be discussed with reference to the electornic device 900. As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware.

[0113] Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software, such as the communication system 200 of FIG. 2. FIG. 9 illustrates, for one embodiment, example components of the electronic device 900. In embodiments, the electronic device 900 may be a user equipment (UE), an evolved Node B (eNB), a relay UE, a remote UE, or some other electronic device. In some embodiments, the electronic device 900 may include application circuitry 902, baseband circuitry 904, Radio Frequency (RF) circuitry 906, front-end module (FEM) circuitry 908 and one or more antennas 910, coupled together at least as shown in FIG. 9.

[0114] The application circuitry 902 may include one or more application processors. By way of non-limiting example, the application circuitry 902 may include one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processor(s) may be operably coupled and/or include memory/storage, and may be configured to execute instructions stored in the memory/storage to enable various applications

and/or operating systems to run on the system.

[0115] By way of non-limiting example, the baseband circuitry 904 may include one or more single-core or multi-core processors. The baseband circuitry 104 may include one or more baseband processors and/or control logic. The baseband circuitry 904 may be configured to process baseband signals received from a receive signal path of the RF circuitry 906. The baseband 904 may also be configured to generate baseband signals for a transmit signal path of the RF circuitry 906. The Baseband processing circuitry 904 may interface with the application circuitry 902 for generation and processing of the baseband signals, and for controlling operations of the RF circuitry 906.

[0116] By way of non-limiting example, the baseband circuitry 904 may include at least one of a second generation (2G) baseband processor 904A, a third generation (3G) baseband processor 904B, a fourth generation (4G) baseband processor 904C, other baseband processor(s) 904D for other existing generations, and generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 904 (e.g., at least one of baseband processors 904A-904D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 906. By way of non-limiting example, the radio control functions may include signal modulation/demodulation,

encoding/decoding, radio frequency shifting, other functions, and combinations thereof. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 904 may be programmed to perform Fast-Fourier Transform (FFT), preceding, constellation mapping/demapping functions, other functions, and combinations thereof. In some embodiments, encoding/decoding circuitry of the baseband circuitry 904 may be programmed to perform convolutions, tail-biting convolutions, turbo, Viterbi, Low Density Parity Check (LDPC) encoder/decoder functions, other functions, and combinations thereof. Embodiments of

modulation/demodulation and encoder/decoder functions are not limited to these examples, and may include other suitable functions.

[0117] In some embodiments, the baseband circuitry 904 may include elements of a protocol stack 240 (FIG. 2). By way of non-limiting example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC) 208 (FIG. 2), radio link control (RLC) 206 (FIG. 2), packet data convergence protocol (PDCP) 204 (FIG. 2), and/or radio resource control (RRC) elements 202 (FIG. 2). A central processing unit (CPU) 904E of the baseband circuitry 904 may be programmed to run elements of the protocol stack 240 for signaling of the PHY, MAC 208, RLC 206, PDCP 204 and/or RRC 202 layers.

[0118] In some embodiments, the baseband circuitry 904 may include one or more audio digital signal processor(s) (DSP) 904F. The audio DSP(s) 904F may include elements for compression/decompression and echo cancellation. The audio DSP9s) 904F may also include other suitable processing elements.

[0119] The baseband circuitry 904 may further include memory/storage 904G. The memory/storage 904G may include data and/or instructions for operations performed by the processors of the baseband circuitry 904 stored thereon. In some embodiments, the memory/storage 904G may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 904G may also include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache, buffers, etc. In some embodiments, the memory/storage 904G may be shared among the various processors or dedicated to particular processors.

[0120] Components of the baseband circuitry 904 may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some

embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 904 and the application circuitry 902 may be

implemented together, such as, for example, on a system on a chip (SOC).

[0121] In some embodiments, the baseband circuitry 904 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 904 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 904 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

[0122] The RF circuitry 906 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 906 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. The RF circuitry 906 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 908, and provide baseband signals to the baseband circuitry 904. The RF circuitry 906 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 904, and provide RF output signals to the FEM circuitry 908 for

transmission.

[0123] In some embodiments, the RF circuitry 906 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 906 may include mixer circuitry 906A, amplifier circuitry 906B and filter circuitry 906C. The transmit signal path of the RF circuitry 906 may include filter circuitry 906C and mixer circuitry 906A. The RF circuitry 906 may further include synthesizer circuitry 906D configured to synthesize a frequency for use by the mixer circuitry 906A of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 906A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 908 based on the synthesized frequency provided by synthesizer circuitry 906D. The amplifier circuitry 906B may be configured to amplify the down-converted signals.

[0124] The filter circuitry 906C may include a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 904 for further processing. In some embodiments, the output baseband signals may include zero-frequency baseband signals. In some

embodiments, the mixer circuitry 906A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[0125] In some embodiments, the mixer circuitry 906A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 906D to generate RF output signals for the FEM circuitry 908. The baseband signals may be provided by the baseband circuitry 904 and may be filtered by filter circuitry 906C. The filter circuitry 906C may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

[0126] In some embodiments, the mixer circuitry 906A of the receive signal path and the mixer circuitry 906A of the transmit signal path may include two or more mixers, and may be arranged for quadrature downconversion and/or upconversion, respectively. In some embodiments, the mixer circuitry 906A of the receive signal path and the mixer circuitry 906A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 906A of the receive signal path and the mixer circuitry 906A may be arranged for direct downconversion and/or direct

upconversion, respectively. In some embodiments, the mixer circuitry 906A of the receive signal path and the mixer circuitry 906A of the transmit signal path may be configured for super-heterodyne operation.

[0127] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In such embodiments, the RF circuitry 906 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 904 may include a digital baseband interface to communicate with the RF circuitry 906.

[0128] In some dual-mode embodiments, separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect. [0129] In some embodiments, the synthesizer circuitry 906D may include one or more of a fractional-N synthesizer and a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 906D may include a delta-sigma synthesizer, a frequency multiplier, a synthesizer comprising a phase- locked loop with a frequency divider, other synthesizers and combinations thereof.

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

[0131] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO). Divider control input may be provided by either the baseband circuitry 904 or the applications processor 902 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 902.

[0132] Synthesizer circuitry 906D of the RF circuitry 906 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some

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

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

[0134] FEM circuitry 908 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 910, amplify the received signals, and provide the amplified versions of the received signals to the RF circuitry 906 for further processing. The FEM circuitry 908 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 906 for transmission by at least one of the one or more antennas 910.

[0135] In some embodiments, the FEM circuitry 908 may include a TX/RX switch configured to switch between a transmit mode and a receive mode operation. The FEM circuitry 908 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 908 may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 906). The transmit signal path of the FEM circuitry 908 may include a power amplifier (PA) configured to amplify input RF signals (e.g., provided by RF circuitry 906), and one or more filters configured to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 910.

[0136] In some embodiments, the electronic device 900 may include additional elements such as, for example, memory/storage, a display, a camera, one of more sensors, an input/output (I/O) interface, other elements, and combinations thereof.

[0137] In some embodiments, the electronic device 900 may be configured to perform one or more processes, techniques, and/or methods as described herein, or portions thereof.

[0138] A non-exhaustive list of examples follows. Each of these examples may be combined with any others of the examples, and with embodiments disclosed herein, except as would be understood by one of ordinary skill to not be combinable.

[0139] Example 1 : Remote User Equipment (remote UE), including: one or more communication elements configured to enable the remote UE to communicate with relay User Equipment (relay UE); and control circuitry including at least one processor programmed with: elements of a protocol stack including a media access control (MAC) layer including at least a Uu interface entity and a PC5 interface entity; and a MAC-Relay configured to enable the at least one processor to communicate with an evolved Node B (eNB) through the relay UE, and perform route switching of network traffic within the MAC layer between the Uu interface entity and the PC5 interface entity.

[0140] Example 2: The remote UE of Example 1 , wherein: each of the Uu interface entity and the PC5 interface entity includes a (De)-Multiplexing & Logical Channel Prioritization (MUX & LCP) component and a Hybrid Automatic Repeat Request (HARQ) component; and the MAC-Relay is configured to connect the MUX & LCP component and the HARQ component over the Uu interface entity and the PC5 entity.

[0141] Example 3: The remote UE of either one of Examples 1 and 2, wherein the MAC-Relay is configured to perform the route switching for an uplink (UL) direction and a downlink (DL) direction separately.

[0142] Example 4: The remote UE of any one of Examples 1 through 3, wherein the MAC-Relay is configured to decide at least one of a new DL path and a new UL path, and at least one of receive and transmit data through the relay UE on the new path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0143] Example 5: The remote UE of any one of Examples 1 through 3, wherein the MAC-Relay is configured to receive data indicating a new UL path decided on by the eNB, and wherein the MAC-Relay is configured to transmit uplink data on the new UL path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0144] Example 6: The remote UE of any one of Examples 1 through 5, wherein the MAC-Relay is configured to transmit a MAC protocol data unit (PDU) including a MAC subheader indicating a unique identification identifying the remote UE to the relay UE to aid the relay UE in relaying the MAC PDU to the eNB.

[0145] Example 7: The remote UE of Example 6, wherein the MAC subheader further includes data indicating a cell global identifier (CGI), and a cell radio network temporary identifier (C-RNTI).

[0146] Example 8: The remote UE of either one of Examples 6 and 7, wherein the MAC subheader further includes data indicating at least one of quality of service (QoS) information and priority information regarding MAC service data units (SDUs) configured to aid the relay UE in performing traffic multiplexing. [0147] Example 9: The remote UE of any one of Examples 1 through 8, wherein the MAC-Relay is configured to transmit to the relay UE a MAC protocol data unit (PDU) including both uplink data to be delivered to the eNB through the relay UE and at least one of Sidelink (SL) data and device-to-device (D2D) data intended for the relay UE without communication of further overhead messages between the remote UE and the relay UE.

[0148] Example 10: The remote UE of Example 9, wherein the MAC-Relay is configured to simultaneously multiplex and perform logical channel prioritization on the uplink data and the at least one of the SL data and the D2D data.

[0149] Example 1 1 : Relay User Equipment (relay UE), including: data links configured to enable the relay UE to communicate with remote User Equipment (remote UE) and an evolved Node B (eNB); and logic, at least a portion of which includes circuitry configured to implement: elements of a protocol stack including a layer-2, wherein the layer-2 includes at least a Uu interface entity and a PC5 interface entity; and a relay configured to communicatively couple (De)-Multiplexing & Logical Channel Prioritization (Mux & LCP) components and Hybrid Automatic Repeat Request (HARQ) components of the Uu interface entity and the PC5 interface entity across the Uu interface entity and the PC5 interface entity, and perform network traffic relaying between the remote UE and the eNB.

[0150] Example 12: The relay UE of Example 1 1 , wherein the relay is configured to receive and process a Media Acess Control (MAC) protocol data unit (PDU) including a MAC subheader indicating a layer-2 identification of the remote UE from one of the remote UE and the eNB.

[0151] Example 13: The relay UE of Example 12, wherein the MAC PDU also includes uplink data from the remote UE that is intended to be routed to the eNB through the relay UE, and at least one of Sidelink (SL) and device-to-device (D2D) data addressed to the relay UE itself.

[0152] Example 14: The relay UE of Example 13, wherein the relay is configured to separate the MAC PDU into the uplink data that is intended to be routed to the eNB and the at least one of SL data and D2D data addressed to the relay UE itself, and route the uplink data to the eNB without further overhead communication between the relay UE, the remote UE, and the eNB.

[0153] Example 15: The relay UE of any one of Examples 13 and 14, wherein the relay is configured to forward the uplink data to the eNB and perform MAC service data unit (SDU) segmentation without further overhead communication between the relay UE, the remote UE, and the eNB.

[0154] Example 16: The relay UE of any one of Examples 13 through 15, wherein the relay is configured to forward the uplink data from the remote UE and its own uplink data to the eNB in a single combined MAC PDU without further overhead communication between the relay UE and the eNB.

[0155] Example 17: The relay UE of Example 16, wherein the relay is configured to simultaneously perform multiplexing and logical channel prioritization on its own uplink data, and MAC service data unit (SDU) segmentation on the MAC PDU from the remote UE based, at least in part, on at least one of a determined quality of service (QoS) and a determined priority.

[0156] Example 18: The relay UE of any one of Examples 12 through 17, wherein the MAC PDU also includes downlink data from the eNB that is intended to be routed to the remote UE through the relay UE, and downlink data that is intended for the relay UE itself.

[0157] Example 19: The relay UE of Example 18, wherein the relay is configured to separate the MAC PDU into the downlink data that is intended to be routed to the remote UE and the downlink data that is intended for the relay UE itself, and relay the downlink data that is intended to be routed to the remote UE to the remote UE.

[0158] Example 20: An evolved Node B (eNB), including: a computer-readable medium (e.g., non-transitory) operably coupled to a processor, and including computer-readable instructions stored thereon, the computer-readable instructions configured to instruct the processor to execute a layer-2 relay configured to: enable the eNB to communicate with remote User Equipment (remote UE) through relay User Equipment (relay UE); and perform route switching of network traffic within a layer-2 between different interface entities of the relay UE.

[0159] Example 21 : The eNB of Example 20, wherein the layer-2 relay is configured to perform the route switching for the remote UE in an uplink direction and a downlink direction separately.

[0160] Example 22: The eNB of either one of Examples 20 and 21 , wherein the layer-2 relay is configured to decide at least one of a new uplink path and a new downlink path for the remote UE, and at least one of transit and receive receive data on the new path without further overhead communication between the remote UE, the relay UE, and the eNB. [0161] Example 23: The eNB of either one of Examples 20 and 21 , wherein the layer-2 relay is configured to receive information indicating a new downlink path decided by the remote UE, prepare the new downlink path switch, and receive downlink data on the new downlink path without further overhead communication between the eNB, the relay UE and the remote UE.

[0162] Example 24: The eNB of either one of Examples 20 through 23, wherein the layer-2 relay is configured to transmit a combined MAC PDU to the relay UE, the combined MAC PDU including downlink data intended for both the remote UE and the relay UE without additional overhead communication between the eNB and the relay UE.

[0163] Example 25: The eNB of either one of Examples 20 and 24, wherein the layer-2 relay is configured to perform multiplexing and logical channel prioritization of downlink data intended for both the remote UE and the relay UE simultaneously, and transmit a combined MAC PDU to the relay UE, the combined MAC PDU including the downlink data intended for both the remote UE and the relay UE.

[0164] Example 26: A method of operating remote User Equipment (remote UE), including: communicating with an evolved Node B (eNB) through a relay UE; and performing route switching of network traffic within a MAC layer between a UU interface entity of the remote UE and a PC5 interface entity of the remote UE.

[0165] Example 27: The method of Example 26, further including connecting a (De)-Multiplexing & Logical Channel Prioritization (MUX & LCP) component and a Hybrid Automatic Repeat Request (HARQ) component of each of the Uu interface entity and the PC5 interface entity over the Uu interface entity and the PC5 entity.

[0166] Example 28: The method of any one of Examples 26 and 27, wherein performing route switching includes performing the route switching for an uplink (UL) direction and a downlink (DL) direction separately.

[0167] Example 29: The method of any one of Examples 26 through 28, further including: deciding at least one of a new DL path and a new UL path; and at least one of receiving and transmitting data through the relay UE on the new path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0168] Example 30: The method of any one of Examples 26 through 28, further including: receiving data indicating a new UL path decided on by the eNB; transmitting uplink data on the new UL path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0169] Example 31 : The method of any one of Examples 26 through 30, further including transmitting a MAC protocol data unit (PDU) including a MAC subheader indicating a unique identification identifying the remote UE to the relay UE to aid the relay UE in relaying the MAC PDU to the eNB.

[0170] Example 32: The method of Example 31 , wherein transmitting a MAC PDU including a MAC subheader further includes transmitting the MAC PDU including the MAC subheader, which includes data indicating a cell global identifier (CGI), and a cell radio network temporary identifier (C-RNTI).

[0171] Example 33: The method of any one of Examples 31 and 32, wherein transmitting a MAC PDU including a MAC subheader further includes transmitting the MAC PDU including the MAC subheader, which includes data indicating at least one of quality of service (QoS) information and priority information regarding MAC service data units (SDUs) configured to aid the relay UE in performing traffic multiplexing.

[0172] Example 34: The method of any one of Examples 26 through 33, further including transmitting to the relay UE a MAC protocol data unit (PDU) including both uplink data to be delivered to the eNB through the relay UE and at least one of Sidelink (SL) data and device-to-device (D2D) data intended for the relay UE without communication of further overhead messages between the remote UE and the relay UE.

[0173] Example 35: The method of Example 34, further including simultaneously multiplexing and performing logical channel prioritization on the uplink data and the at least one of the SL data and the D2D data.

[0174] Example 36: A method of operating relay User Equipment (relay UE), including: communicatively coupling (De)-Multiplexing & Logical Channel

Prioritization (Mux & LCP) components and Hybrid Automatic Repeat Request (HARQ) components of a Uu interface entity and a PC5 interface entity of the relay UE across the Uu interface entity and the PC5 interface entity; and performing network traffic relaying between a remote UE and an evolved Node B.

[0175] Example 37: The method of Example 36, further including receiving and processing a Media Acess Control (MAC) protocol data unit (PDU) including a MAC subheader indicating a layer-2 identification of the remote UE from one of the remote UE and the eNB.

[0176] Example 38: The method of Example 37, wherein receiving and

processing a MAC PDU further includes receiving and processing the MAC PDU including uplink data from the remote UE that is intended to be routed to the eNB through the relay UE, and at least one of Sidelink (SL) and device-to-device (D2D) data addressed to the relay UE itself.

[0177] Example 39: The method of Example 38, further including separating the MAC PDU into the uplink data that is intended to be routed to the eNB and the at least one of SL data and D2D data addressed to the relay UE itself, and routing the uplink data to the eNB without further overhead communication between the relay UE, the remote UE, and the eNB.

[0178] Example 40: The method of any one of Examples 38 and 39, further including forwarding the uplink data to the eNB, and performing MAC service data unit (SDU) segmentation without further overhead communication between the relay UE, the remote UE, and the eNB.

[0179] Example 41 : The method of any one of Examples 38 through 40, further including forwarding the uplink data from the remote UE and uplink data of the relay UE to the eNB in a single combined MAC PDU without further overhead

communication between the relay UE and the eNB.

[0180] Example 42: The method of Example 41 , further including simultaneously performing multiplexing and logical channel prioritization on the uplink data of the relay UE, and MAC service data unit (SDU) segmentation on the MAC PDU from the remote UE based, at least in part, on at least one of a determined quality of service (QoS) and a determined priority.

[0181] Example 43: The method of any one of Examples 37 through 42, wherein receiving and processing a MAC PDU further includes receiving and processing a MAC PDU including downlink data from the eNB that is intended to be routed to the remote UE through the relay UE, and downlink data that is intended for the relay UE itself.

[0182] Example 44: The method of Example 43, further including: separating the MAC PDU into the downlink data that is intended to be routed to the remote UE and the downlink data that is intended for the relay UE itself; and relaying the downlink data that is intended to be routed to the remote UE to the remote UE. [0183] Example 45: A method of operating an evolved Node B (eNB), including: enabling the eNB to communicate with remote User Equipment (remote UE) through relay User Equipment (relay UE); and performing route switching of network traffic within a layer-2 between different interface entities of the relay UE.

[0184] Example 46: The method of Example 45, further including performing the route switching for the remote UE in an uplink direction and a downlink direction separately.

[0185] Example 47: The method of any one of Examples 45 and 46, further including deciding at least one of a new uplink path and a new downlink path for the remote UE, and at least one of transmitting and receiving data on the new path without further overhead communication between the remote UE, the relay UE, and the eNB.

[0186] Example 48: The method of any one of Examples 45 and 46, further including: receiving information indicating a new downlink path decided by the remote UE; preparing the new downlink path switch; and receiving downlink data on the new downlink path without further overhead communication between the eNB, the relay UE and the remote UE.

[0187] Example 49: The method of any one of Examples 45 through 48, further including transmitting a combined MAC PDU to the relay UE, the combined MAC PDU including downlink data intended for both the remote UE and the relay UE without additional overhead communication between the eNB and the relay UE.

[0188] Example 50: The method of any one of Examples 45 through 49, further including performing multiplexing and logical channel prioritization of downlink data intended for both the remote UE and the relay UE simultaneously, and transmitting a combined MAC PDU to the relay UE, the combined MAC PDU including the downlink data intended for both the remote UE and the relay UE.

[0189] Example 51 : A computer-readable storage media including computer- readable instructions stored thereon, the computer-readable instructions configured to instruct a processor to perform the method according to any one of Examples 26 through 50.

[0190] Example 52: Remote User Equipment (remote UE), including: one or more communication elements configured to enable the remote UE to communicate with relay User Equipment (relay UE); and control circuitry including at least one processor programmed with: elements of a protocol stack including a media access control (MAC) layer including at least a Uu interface entity and a PC5 interface entity; and a MAC-Relay configured to enable the at least one processor to communicate with an evolved Node B (eNB) through the relay UE, and perform route switching of network traffic within the MAC layer between the Uu interface entity and the PC5 interface entity.

[0191] Example 53: The remote UE of Example 52, wherein: each of the Uu interface entity and the PC5 interface entity includes a (De)-Multiplexing & Logical Channel Prioritization (MUX & LCP) component and a Hybrid Automatic Repeat Request (HARQ) component; and the MAC-Relay is configured to connect the MUX & LCP component and the HARQ component over the Uu interface entity and the PC5 entity.

[0192] Example 54: The remote UE of any one of Examples 52 and 53, wherein the MAC-Relay is configured to perform the route switching for an uplink (UL) direction and a downlink (DL) direction separately.

[0193] Example 55: The remote UE of any one of Examples 52 through 54, wherein the MAC-Relay is configured to decide a new UL path, and transmit data to the eNB through the relay UE on the new UL path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0194] Example 56: The remote UE of any one of Examples 52 through 54, wherein the MAC-Relay is configured to receive data indicating a new UL path decided on by the eNB, and wherein the MAC-Relay is configured to transmit uplink data on the new UL path without communicating further overhead messages between the remote UE, the relay UE, and the eNB.

[0195] Example 57: The remote UE of any one of Examples 52 through 55, wherein the MAC-Relay is configured to decide a new DL path, notify the network of the new DL path, and receive data through the new DL path without communication of further overhead messages between the remote UE, the relay UE, and the eNB.

[0196] Example 58: The remote UE of any one of Examples 52 through 57, wherein the MAC-Relay is configured to transmit a MAC protocol data unit (PDU) including a MAC subheader indicating a unique identification identifying the remote UE to the relay UE to aid the relay UE in relaying the MAC PDU to the eNB.

[0197] Example 59: The remote UE of Example 58, wherein the MAC subheader further includes data indicating a cell global identifier (CGI), and a cell radio network temporary identifier (C-RNTI). [0198] Example 60: The remote UE of any one of Examples 58 and 59, wherein the MAC subheader further includes data indicating at least one of quality of service

(QoS) information and priority information regarding MAC service data units (SDUs) configured to aid the relay UE in performing traffic multiplexing.

[0199] Example 61 : The remote UE of Example 60, wherein the QoS information includes at least one of a QoS class indicator (QCI) and per packet priority

indication.

[0200] Example 62. The remote UE of any one of Examples 52 through 61 , wherein the MAC-Relay is configured to transmit to the relay UE a MAC protocol data unit (PDU) including both uplink data to be delivered to the eNB through the relay UE and at least one of Sidelink (SL) data and device-to-device (D2D) data intended for the relay UE.

[0201] Example 63: The remote UE of Example 62, wherein the MAC-Relay is configured to transmit the MAC PDU to the relay UE without communication of further overhead messages between the remote UE and the relay UE.

[0202] Example 64: The remote UE of any one of Examples 62 and 63, wherein the MAC-Relay is configured to simultaneously multiplex and perform logical channel prioritization on the uplink data and the at least one of the SL data and the D2D data.

[0203] Example 65: Relay User Equipment (relay UE), including: data links configured to enable the relay UE to communicate with remote User Equipment (remote UE) and an evolved Node B (eNB); and logic, at least a portion of which includes circuitry configured to implement: elements of a protocol stack including a layer-2, wherein the layer-2 includes at least a Uu interface entity and a PC5 interface entity; and a relay configured to communicatively couple (De)-Multiplexing & Logical Channel Prioritization (Mux & LCP) components and Hybrid Automatic Repeat Request (HARQ) components of the Uu interface entity and the PC5 interface entity across the Uu interface entity and the PC5 interface entity, and perform network traffic relaying between the remote UE and the eNB.

[0204] Example 66: The relay UE of Example 65, wherein the relay is configured to receive and process a Media Acess Control (MAC) protocol data unit (PDU) including a MAC subheader indicating a layer-2 identification of the remote UE from one of the remote UE and the eNB.

[0205] Example 67: The relay UE of Example 66, wherein the MAC PDU also includes uplink data from the remote UE that is intended to be routed to the eNB through the relay UE, and at least one of Sidelink (SL) and device-to-device (D2D) data addressed to the relay UE itself.

[0206] Example 68: The relay UE of Example 67, wherein the relay is configured to separate the MAC PDU into the uplink data that is intended to be routed to the eNB and the at least one of SL data and D2D data addressed to the relay UE itself, and route the uplink data to the eNB without further overhead communication between the relay UE, the remote UE, and the eNB.

[0207] Example 69: The relay UE of any one of Examples 67 and 68, wherein the relay is configured to forward the uplink data to the eNB and perform MAC service data unit (SDU) segmentation without further overhead communication between the relay UE, the remote UE, and the eNB.

[0208] Example 70: The relay UE of any one of Examples 67 through 69, wherein the relay is configured to forward the uplink data from the remote UE and its own uplink data to the eNB in a single combined MAC PDU without further overhead communication between the relay UE and the eNB.

[0209] Example 71 : The relay UE of Example 70, wherein the relay is configured to simultaneously perform multiplexing and logical channel prioritization on its own uplink data, and MAC service data unit (SDU) segmentation on the MAC PDU from the remote UE based, at least in part, on at least one of a determined quality of service (QoS) and a determined priority.

[0210] Example 72: The relay UE of any one of Examples 66 through 71 , wherein the MAC PDU also includes downlink data from the eNB that is intended to be routed to the remote UE through the relay UE, and downlink data that is intended for the relay UE itself.

[0211] Example 73: The relay UE of Example 72, wherein the relay is configured to separate the MAC PDU into the downlink data that is intended to be routed to the remote UE and the downlink data that is intended for the relay UE itself, and relay the downlink data that is intended to be routed to the remote UE to the remote UE.

[0212] Example 74: The relay UE of any one of Examples 66 through 73, wherein the relay is configured to receive at least one of quality of service (QoS) information and per-packet priority information from the remote UE in the MAC subheader.

[0213] Example 75: The relay UE of any one of Examples 65 through 74, wherein the relay is configured to receive an uplink MAC protocol data unit (PDU) including an uplink buffer status report (BSR) indicating at least one of a serving cell global identifier (CGI), a cell radio network temporary identifier (C-RNTI), and a layer-2 unique identifier of the remote UE.

[0214] Example 76: An evolved Node B (eNB), including: a non-transitory computer-readable medium operably coupled to a processor, and including computer-readable instructions stored thereon, the computer-readable instructions configured to instruct the processor to execute a layer-2 relay configured to: enable the eNB to communicate with remote User Equipment (remote UE) through relay User Equipment (relay UE); and perform route switching of network traffic within a layer-2 between different interface entities of the relay UE.

[0215] Example 77: The eNB of Example 76, wherein the layer-2 relay is configured to perform the route switching for the remote UE in an uplink direction and a downlink direction separately.

[0216] Example 78: The eNB of either one of Examples 76 and 77, wherein the layer-2 relay is configured to decide a new downlink path for the remote UE, and receive downlink data on the new downlink path without further overhead

communication between the remote UE, the relay UE, and the eNB.

[0217] Example 79: The eNB of either one of Examples 76 and 77, wherein the layer-2 relay is configured to receive information indicating a new downlink path decided by the remote UE, prepare the new downlink path switch, and receive downlink data on the new downlink path without further overhead communication between the eNB, the relay UE and the remote UE.

[0218] Example 80: The eNB of any one of Examples 76 through 78, wherein the layer-2 relay is configured to decide a new uplink path for the remote UE and notify the remote UE to transmit uplink data on the new uplink path without further overhead communication between the remote UE, the relay UE, and the eNB.

[0219] Example 81 : The eNB of any one of Examples 76 through 80, wherein the layer-2 relay is configured to receive an uplink buffer status report (BSR) indicating at least one of a serving cell global identifier (CGI), a cell radio network temporary identifier (C-RNTI), and a layer-2 unique identifier of the remote UE, and prepare an uplink path switch.

[0220] Example 82: The eNB of any one of Examples 76 through 81 , wherein the layer-2 relay is configured to transmit a MAC PDU to the relay UE, the MAC PDU including a MAC subheader including data indicating a unique identifier of the remote UE to indicate to the relay UE where to forward at least a portion of the MAC PDU to. [0221] Example 83: The eNB of any one of Examples 76 through 82, wherein the layer-2 relay is configured to transmit a combined MAC PDU to the relay UE, the combined MAC PDU including downlink data intended for both the remote UE and the relay UE without additional overhead communication between the eNB and the relay UE.

[0222] Example 84: The eNB of any one of Examples 76 through 83, wherein the layer-2 relay is configured to perform multiplexing and logical channel prioritization of downlink data intended for both the remote UE and the relay UE simultaneously, and transmit a combined MAC PDU to the relay UE, the combined MAC PDU including the downlink data intended for both the remote UE and the relay UE.

[0223] Example 85: The eNB of any one of Examples 76 through 84, wherein the layer-2 relay is configured to distinguish and buffer a segmented MAC service data unit (SDU) within a MAC subheader as part of a MAC protocol data unit (PDU) received from the relay UE without further overhead communication between the eNB and the relay UE.

[0224] Example 86: The eNB of any one of Examples 76 through 85, wherein the layer-2 relay is configured to combine segmented MAC service data units (SDUs) and restore the segmented MAC SDUs to their original form once all parts of the MAC SDUs are delivered.

[0225] Example 87: A remote User Equipment or (UE) that is ProSe-enabled and includes radio frequency (RF) circuitry and/or baseband circuitry to communicate to a network either through direct communication over a Uu type of link or through a relay UE over a PC5 interface.

[0226] Example 88: The remote UE of Example 87 or some other example herein, wherein the remote participates in uplink/downlink (UL/DL) communication with the network, and is capable of route switching within layer 2 (e.g., a medium access control (MAC) layer) between a Uu interface and a PC5 interface (i.e., between remote UE and relay UE).

[0227] Example 89: The remote UE of Example 87 or some other example herein, wherein the UE is further to switch paths (either a path directly with the network or a path via a relay) for UL direction and DL direction separately.

[0228] Example 90: The remote UE of Example 87 or some other example herein, wherein the UE is further to decide the UL path either directly to the network or via a relay UE, and is further to send UL data on the new path without communicating any messages between the remote UE, the relay UE, and the network.

[0229] Example 91 : The remote UE of Example 87 or some other example herein, wherein the UE is notified by the network about the new UL path either directly or via a relay UE, and is further to send UL data on the new path without communicating any messages between the remote UE, the relay UE, and the network.

[0230] Example 92: The remote UE of Example 87 or some other example herein, wherein the remote UE is further to decide a DL path either directly to the network or via a relay UE, and is further to notify the network to send DL data on the new path without communicating any further messages between the remote UE, the relay UE, and the network.

[0231] Example 93: The remote UE of Example 87 or some other example herein, wherein the remote UE is further to send its identifier (ID_ (such as remote UE ID or Layer-2 ID) within the MAC subheader as part of the MAC protocol data unit (PDU) to aid the relay UE to forward it to the network.

[0232] Example 94: The remote UE of Example 87 or some other example herein, wherein the remote UE is further to send information (such as a cell global identity CGI or a cellular radio network temporary identifier (C-RNTI)) within the MAC subheader as part of the MAC PDU to aid the network about its establishment cause or connection type.

[0233] Example 95; The remote UE of example 87 or some other example herein, wherein the remote UE is further to send quality of service (QoS) information (such as a QoS class identifier (QCI) or ProSe Per-packet priority information (PPPP)) within the MAC subheader as part of the MAC PDU about one or more MAC service data unit(s) (SDU(s)) in this MAC PDU to aid the relay UE to perform traffic multiplexing.

[0234] Example 96: The remote UE of Example 87 or some other example herein, wherein the remote UE has both UL data destined to the network via the relay and SL (Sidelink) or device to device (D2D) data destined to the relay UE, and is further to send both simultaneously to the relay UE as a single MAC PDU without communicating any messages between the remote UE and the relay UE.

[0235] Example 97: The remote UE of Example 87 or some other example herein, wherein the remote UE has both UL data destined to the network via the relay and SL or D2D data destined to the relay UE, and is further to perform multiplexing and logical channel prioritization over two simultaneously into a single MAC PDU to the relay UE.

[0236] Example 98: A relay User Equipment or (UE) that is ProSe-enabled, and includes baseband and/or radio frequency (RF) circuitry to communicate to the network, and configured to act as UE-to-Network relay.

[0237] Example 99: The relay UE of Example 98 or some other example herein, wherein the relay UE is further to receive the MAC PDU from the remote UE or the network with the MAC subheader containing the remote UE ID or Layer-2 ID.

[0238] Example 100: The relay UE of Example 98 or some other example herein, wherein the relay UE is further to receive the MAC PDU from the remote UE that simultaneously contains SL or D2D data destined to the relay UE itself and UL data destined to the network without communicating any messages between the relay UE and the remote UE.

[0239] Example 101 : The relay UE of Example 98 or some other example herein, wherein the relay UE is further to receive the MAC PDU from the network that simultaneously contains DL data destined to the relay UE itself and other DL datas destined to other remote UEs without communicating any messages between the relay UE and the eNB.

[0240] Example 102: The relay UE of Example 100 or some other example herein, wherein the relay UE is further to separate the MAC PDU received from the remote UE into SL MAC PDU destined to the relay UE itself and UL MAC PDU destined to the network.

[0241] Example 103: The relay UE of Example 101 or some other example herein, wherein the relay UE is further to separate the MAC PDU received from the network into DL MAC PDU destined to the relay UE itself and each DL MAC PDU destined to each remote .

[0242] Example 104: The relay UE of Example 98 or some other example herein, wherein the relay UE has a remote UE's UL MAC PDU to forward to the network, and is further to send the uplink BSR that includes the remote UE ID or Layer-2 ID, and includes other information such as CGI or C-RNTI if indicated to do so.

[0243] Example 105: The relay UE of Example 98 or some other example herein, wherein the relay UE is further to receive from the remote UE the QoS information within the MAC subheader as part of the remote UE's MAC PDU about MAC SDU(s) in this MAC PDU.

[0244] Example 106: The relay UE of Example 98 or some other example herein, wherein the relay UE has a remote UE's UL MAC PDU to forward to the network, and is further to perform MAC SDU segmentations to fit the uplink grant size or based on QoS without communicating any messages between the relay UE, the remote UE, and the eNB.

[0245] Example 107: The relay UE of Example 98 or some other example herein, wherein the relay UE has a remote UE(s)' UL MAC PDU(s) to forward to the network and its own UL data to the network, and is further to send them simultaneously to the network as a single MAC PDU without communicating any messages between the relay UE and the eNB.

[0246] Example 108: The relay UE of Example 105 or some other example herein, wherein the relay UE has remote UE(s)' UL MAC PDU(s) to forward to the network and its own UL data to the network, and is further to simultaneously perform multiplexing and logical channel prioritization on its own UL data and MAC SDU segmentations on remote UE(s)' UL MAC PDU(s) based on QoS, into a single MAC PDU to the network.

[0247] Example 109: An evolved NodeB (eNB) or similar network node which can support ProSe D2D communication along with relay operation and configure certain UEs to act as UE-to-Network relays (relay UEs) and send or receive communication from such relays

[0248] Example 1 10: The eNB of Example 109 or some other example herein, wherein the eNB is further to route switch within layer 2 (MAC) between a remote UE's Uu interface and a relay UE's Uu interface

[0249] Example 1 1 1 : The eNB of Example 109 or some other example herein, wherein the eNB is further to switch path for remote UE (either directly with the network or via a relay) for UL direction and DL direction separately.

[0250] Example 1 12: The eNB of Example 109 or some other example herein, wherein the eNB is to decide a DL path for remote UE either directly to the network or via a relay UE, and is to send DL data on new path without communicating any messages between the remote UE, the relay UE, and the network.

[0251] Example 1 13: The eNB of Example 109 or some other example herein, wherein the eNB is to receive a notification from a remote UE about a new DL path either directly or via a relay UE, and is to prepare a DL path switch such as handover preparation and sending DL data on new path without communicating any messages between the eNB, the relay UE, and the remote UE.

[0252] Example 1 14: The eNB of Example 109 or some other example herein, wherein the eNB is to decide a UL path for remote UE either directly to the network or via a relay UE, and is to notify the remote UE to send UL data on new path without communicating any further messages between the remote UE, the relay UE, and the network.

[0253] Example 1 15: The eNB of Example 109 or some other example herein, wherein the eNB is to receive an uplink BSR that contains remote UE ID or Layer-2 ID and/or CGI and/or C-RNTI and prepare a UL path switch such as handover preparation.

[0254] Example 1 16: The eNB of Example 109 or some other example herein, wherein the eNB is further to send a remote UE's ID (such as remote UE ID or Layer-2 ID) within the MAC subheader as part of the MAC PDU to aid the relay UE to forward it to the remote UE.

[0255] Example 1 17: The eNB of Example 109 or some other example herein, wherein the eNB is to relay UE's DL data and DL data(s) destined to remote UEs via the relay, and is to send them simultaneously to the relay UE as a single MAC PDU without communicating any messages between the eNB and the relay UE.

[0256] Example 1 18: The eNB of Example 109 or some other example herein, wherein the eNB is to relay UE's DL data and DL data(s) destined to remote UEs via the relay, and is to perform multiplexing and logical channel prioritization over them simultaneously into a single MAC PDU to the relay UE.

[0257] Example 1 19: The eNB of Example 109 or some other example herein, wherein the eNB is to distinguish and buffer the segmented MAC SDU within the MAC subheader as part of the MAC PDU received from the relay UE without communicating any messages between the eNB and the relay UE.

[0258] Example 120: The eNB of Example 1 19 or some other example herein, wherein the eNB is to re-combine the segmented MAC SDUs and restoring the original MAC SDU once all the pieces are delivered.

[0259] Example 121 : An apparatus including means to perform one or more elements of a method described in or related to any of Examples 1 through 120, or any other method or process described herein. [0260] Example 122: One or more non-transitory computer-readable media including instructions to cause an electronic device, upon execution of the

instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of Examples 1 through 120, or any other method or process described herein.

[0261] Example 123: An apparatus including logic, modules, and/or circuitry to perform one or more elements of a method described in or related to any of

Examples 1 through 120, or any other method or process described herein.

[0262] Example 124: A method, technique, or process as described in or related to any of Examples 1 through 120, or portions or parts thereof.

[0263] Example 121 : A method of communicating in a wireless network as shown and described herein.

[0264] Example 122: A system for providing wireless communication as shown and described herein.

[0265] Example 123: A device for providing wireless communication as shown and described herein.

[0266] While certain illustrative embodiments have been described in connection with the figures, those of ordinary skill in the art will recognize and appreciate that embodiments encompassed by the disclosure are not limited to those embodiments explicitly shown and described herein. Rather, many additions, deletions, and modifications to the embodiments described herein may be made without departing from the scope of embodiments encompassed by the disclosure, such as those hereinafter claimed, including legal equivalents. In addition, features from one disclosed embodiment may be combined with features of another disclosed embodiment while still being encompassed within the scope of embodiments encompassed by the disclosure, as contemplated by the inventors.