WO2018085568A1

WO2018085568A1 - Quality of service support over evolved universal terrestrial radio access based sidelink system

Info

Publication number: WO2018085568A1
Application number: PCT/US2017/059762
Authority: WO
Inventors: Sangeetha L. Bangolae; Kyeongin Jeong; Youn Hyoung Heo
Original assignee: Intel IP Corporation
Priority date: 2016-11-04
Filing date: 2017-11-02
Publication date: 2018-05-11

Abstract

An apparatus of a user equipment (UE) comprises one or more baseband processors to encode or decode data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB, and a memory to store the data.

Description

QUALITY OF SERVICE SUPPORT OVER EVOLVED UNIVERSAL TERRESTRIAL RADIO ACCESS BASED SIDELINK SYSTEM

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of US Provisional Application No.

62/418,131 (P111823Z) filed November 4, 2016. Said Application No. 62/418,131 is hereby incorporated herein by reference in its entirety.

BACKGROUND

[0002] In the Third Generation Partnership Project (3GPP) and future standards such as Fifth Generation (5G) wireless standard and beyond, there exists an interest to use 3GPP Long- Term Evolution (LTE) technology to connect and manage the low-power wearable devices. The diverse set of wearable devices and use cases ranging from low data rate delay tolerant monitoring to high data rate delay sensitive virtual reality involves different communication capabilities. Progress in the 3GPP LTE standard to support Layer-3 user equipment to network (UE-to-NW) relaying allows LTE PC5 interface technology to support some wearable use cases. Since the main design vectors for proximity-based services (ProSe) framework target long-range and relatively low-rate broadcast communication that are robust to interference, further analysis may be directed to how a wearable as a subset of machine type communication (MTC) use cases may benefit from device-to-device (D2D) technology, and to identify the enhancements to the cellular and sidelink air- interface jointly with UE-to-NW relaying functionality in order to support a broad range of wearable use cases.

DESCRIPTION OF THE DRAWING FIGURES

[0003] Claimed subject matter is particularly pointed out and distinctly claimed in the concluding portion of the specification. However, such subject matter may be understood by reference to the following detailed description when read with the accompanying drawings in which:

[0004] FIG. 1 is a diagram of a Third Generation Partnership Project (3GPP) network having an architecture for proximity-based services (ProSe) in accordance with one or more embodiments;

[0005] FIG. 2 is a diagram of one example of a user equipment (UE) to network relay operation in accordance with one or more embodiments;

[0006] FIG. 3 is a diagram of enhanced relay discovery to support Quality of Service (QoS) in accordance with one or more embodiments; [0007] FIG. 4 is a diagram of evolved NodeB (eNB) involvement in supporting Quality of

Service (QoS) over sidelink in accordance with one or more embodiments;

[0008] FIG. 5 is a diagram of an uplink initiated bearer setup to support a specific Quality of Services (QoS) in accordance with one or more embodiments;

[0009] FIG. 6 is a diagram of multiplexing Quality of Service (QoS) support for multiple user equipment (UE) devices and/or bearers in accordance with one or more embodiments; and

[00010] FIG. 7 illustrates example components of a device in accordance with some embodiments.

[00011 ] It will be appreciated that for simplicity and/or clarity of illustration, elements illustrated in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, if considered appropriate, reference numerals have been repeated among the figures to indicate corresponding and/or analogous elements.

DETAILED DESCRIPTION

[00012] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of claimed subject matter. It will, however, be understood by those skilled in the art that claimed subject matter may be practiced without these specific details.

In other instances, well-known methods, procedures, components and/or circuits have not been described in detail.

[00013] Referring now to FIG. 1, a diagram of a Third Generation Partnership Project (3 GPP) network having an architecture for proximity-based services (ProSe) in accordance with one or more embodiments will be discussed. FIG.1 illustrates how a sidelink or PC5 interface is capable of providing a Quality of Service (QoS) guarantee so that the end-to-end QoS may be maintained. It should be noted that the PC5 interface shown in FIG. 1 and as discussed herein may comprise a Third Generation Partnership Project (3GPP) Long-Term Evolution (LTE) based proximity-based services (ProSe) sidelink, also known as indirect 3GPP communication using evolved universal terrestrial radio access (E-UTRA). Such a PC5 interface is capable of providing QoS support over the sidelink including default sidelink QoS, enhanced relay discovery and selection, and/or enhanced bearer establishment for specific QoS support. In such an arrangement, Layer 2 optimizations may be realized for a wearable device to support end-to-end QoS including over the sidelink between a remote user equipment (UE) device and a relay UE device.

[00014] FIG. 1 illustrates one example of an architecture for a 3GPP network 100 to implement proximity-based services (ProSe). ProSe services are services that may be provided by network 100 based on two or more UEs being in proximity to each other. The 3GPP system enablers for ProSe may include the following functions: EPC-level ProSe Discovery, EPC support for WLAN direct discovery and communication, Direct discovery, Direct communication, and/or UE-to-network relay. It should be noted that ProSe direct discovery may also refer to device-to- device (D2D) discovery and/or D2D communication, and such terms may be used interchangeably, although the scope of the claimed subject matter is not limited in this respect. Similarly, D2D, ProSe, and sidelink may refer to the same technology, and the scope of the claimed subject matter is not limited in this respect.

[00015] As shown in FIG. 1, UE may include mobile devices or machine type devices in the network 100. For D2D discovery and communication, UE A 110 and UE B 112 may be equipped with a corresponding ProSe application 116 and ProSe application 114, respectively, and may directly transmit or receive data to and/or from each other by means of the PC5 interface. Evolved NodeB (eNodeB or eNB) 118 may operate as the control node for the cell level radio resources. The eNB 118 has functions for radio resource management such as radio bearer control, radio admission control, connection mobility control, dynamic allocation of radio resources to UEs in both uplink scheduling and downlink scheduling in the radio interface, and also has function of routing of user plane data to the serving gateway (SGW) of serving gateway and packet data network gateway (PGW) (S/PGW) 122. The eNB 118 is connected to UE A 110 and UE B 112 via an Uu interface or an LTE-Uu interface, to the mobility management entity (MME) 120 via an Sl-MME interface, to the SGW of S/PGW 122 via a Sl-U interface, and to one or more other eNBs via an X2 interface.

[00016] The MME 120 is the control node which processes the signaling between the UEs and the core network (CN) which includes MME 120 and S/PGW 122. One example of such signaling is for session management handling or for mobility management handling of idle mode UEs. The protocols running between the UE and the CN are known as the Non- Access Stratum (NAS) protocol. All user internet protocol (IP) packets are transferred through the SGW of S/PGW 122, which serves as the local mobility anchor for the data bearers when the UEs move between different eNBs. The SGW of S/PGW 122 also retains the information about the bearers when a UE is in idle state, known as ECM_IDLE, and temporarily buffers downlink data while the MME 120 initiates paging of the UE to re-establish the bearers. The PGW of S/PGW 122 is responsible for IP address allocation for the UEs, as well as for QoS enforcement and flow-based charging according to the rules from the Policy and Charging Rules Functions (PCRF) module.

[00017] The Home Subscriber Server (HSS) 124 contains subscription data for users such as QoS profile, access restriction information for roaming, accessible Packet Data Network, and so on. The Secure User Plane Location Platform (SLP) 126 is the node to detect the user location or its proximity area. The ProSe Function 128 performs a Direct Provisioning Function (DPF) which is used to provision the UE with necessary parameters for ProSe Direct Discovery and ProSe Direct Communication. The ProSe Function 128 is used to provision the UEs with public land mobile network (PLMN) specific parameters that allow the UE to use ProSe in a specific PLMN. For direct communication for Public Safety, DPF also may be used to provision the UE with parameters that are used when the UE is not served by the evolved Universal Terrestrial Radio Access Network (EUTRAN) comprising eNB 118. For restricted ProSe Direct Discovery, the ProSe function 128 also generates and maintains the ProSe Discovery UE identifier (PDUID). Additional parameters also may include the radio resource management related configuration.

[00018] The ProSe function 128 also has a Direct Discovery Name Management Function used for open Prose Direct Discovery to allocate and process the mapping of ProSe Applications IDs and ProSe Application Codes used in ProSe Direct Discovery, the ProSe function 127 uses ProSe related subscriber data stored in HSS 124 for authorization for each discovery request. The ProSe function 128 also provides the UE with security material to protect discovery messages transmitted over the air. In restricted ProSe Direct Discovery, [00018] The ProSe function 128 also interacts with the ProSe Application Server 120 via PC2 reference points for the authorization of the discovery requests. The ProSe Function 128 also has an authorization function for a ProSe UE or user. Information may be exchanged between the ProSe Function 128 and the UE such as UE A 110 or UE B 112 via the PC3 interface.

[00019] It should be noted that the D2D (ProSe) feature as shown in FIG. 1 enables the direct discovery or the direct communication among UEs over the cellular radio spectrum. Although the examples described herein are directed to Evolved Universal Terrestrial Radio Access (EUTRA) in a network 100 compliant with a Third Generation Project Partnership (3GPP) Long-Term Evolution (LTE) standard, the embodiments herein also may be applied to other wireless systems in compliance with various other wireless standards, and the scope of the claimed subject matter is not limited in this respect.

[00020] Referring now FIG. 2, a diagram of one example of a user equipment (UE) to network relay operation in accordance with one or more embodiments will be discussed. FIG. 2 illustrates one example of relay operations from a remote UE 212 to the network 100 which enables the data transmission or reception between the network 100 and the remote UE 212 via a relay UE such as relay UE #1 214, relay UE #2 218, or relay UE #3 216. A relay UE is the UE that has the capability for providing the relay operations between a remote UE 212 and the network 100. As one example of relay operations, for the direction from remote UE 212 to network 100, a relay UE such as relay UE #3 216 receives the data sent from remote UE 212 to network 100 over the PC5 interface, and then relay UE #3 216 transmits that data to the eNB 118 through the Uu interface on behalf of the remote UE 212.

[00021 ] Similarly, for the direction from network 100 to the remote UE 212, relay UE #3 216 receives the data that is sent from the eNB 118 sent to remote UE 212 over the Uu interface, and then relay UE #3 216 transmits that data to remote UE 212 through the PC5 interface on behalf of the eNB 118. Such a relay operation may be helpful especially when remote UE 212 is not reachable from the eNB 118 such that remote UE 212 cannot directly transmit and/or receive data to and/or from the eNB 118, and when another node such as access point 210 is not available to connect remote UE 100 to network 100.

[00022] In order for the transmission and/or reception data via the relay UE, remote UE 212 may select a corresponding relay UE which is located in its proximity area. Once remote UE 212 selects a relay UE, remote UE 212 also may reselect a relay UE when multiple relay UEs become available in its proximity area. For example, if three relay UEs such as relay UE #1 214, relay UE #2 218, and relay UE #3 216 become available in the proximity area of remote UE 212 as shown in FIG. 3, if remote UE 212 selected a relay UE #1 214 as the first relay UE, but now relay UE #2 218 is a more suitable relay UE based on signal strength and/or quality, remote UE 212 may reselect relay UE #2 218 from the relay UE #1 214. One factor to determine a more suitable relay UE may be the measured radio quality over the PC5 interface. For example, the relay UE with the better radio quality over the PC5 interface than the other relay UEs may be considered as a more suitable relay UE. In one or more embodiments, we would a sidelink or PC5 interface may provide a Quality of Service (QoS) guarantee so that the end-to-end QoS can be maintained. It should be noted that the PC5 interface as discussed herein is assumed to be radio link over 3GPP LTE based ProSe link or sidelink which also may be referred to as Indirect 3GPP communication using E- UTRA. Various aspects of QoS support over the sidelink including default sidelink QoS, enhanced relay discovery and selection, and/or enhanced bearer establishment for specific QoS support may be provided. In one or more embodiments, as discussed herein, ProSe-Per- Packet- Priority (PPPP) may provide priority per packet over sidelink, and QoS Class Identifier (QCI) may refer to the way QoS is classified over LTE link wherein each bearer may support a different QCI scalar.

[00023] In one embodiment, default sidelink QoS support may be similar to default QCI, wherein a sidelink QoS may be classified as a default sidelink QoS sidelink channel identifier that does not have stringent QoS requirements but supports QoS corresponding to QCI default values such as QCI value 9. When the relay UE, or evolved relay (eRelay) UE, advertises that it supports only default QoS over the sidelink, this means that the setup does not involve additional signaling in establishing dedicated bearers, and the relaying link only supports the default QoS Sidelink channel Identifier (QSI). The sidelink between the remote UE, or evolved remote (eRemote) UE, and the eRelay UE may still support PPPP but it will map into a default QCI bearer over the Uu interface.

[00024] The eNB 118 couples the relay UE 216 to serving gateway (S-GW) 220 over an Sl-U interface for the relay UE 214, and the eNB 118 couples the remote UE 212 to S-GW 220 over an Sl-U interface for the remote UE 212. Similarly, S-GW 220 couples to PDN gateway (P- GW) 222 vis an S5/S8 interface for the remote UE 212, and via an S5/S8 interface for relay UE 216. An example of enhanced relay discovery to support QoS is shown in and described with respect to FIG. 3, below.

[00025] Referring now to FIG. 3, a diagram of enhanced relay discovery to support Quality of Service (QoS) in accordance with one or more embodiments will be discussed. The embodiment shown in FIG. 3 relates to updates to enhanced ProSe UE-to-network relay discovery and selection. One of the potential reasons for an eRemote UE to change the link from direct to indirect using an eRelay UE would be to achieve better QoS. As part of such relaying enhancement, QoS over sidelink also may be supported to provide a reasonable end-to-end QoS guarantee at least while the relaying is done using the 3 GPP E-UTRA link.

[00026] As part of the discovery announcement message, the announcing UE may provide its supported QoS characteristic in the form of "QCI" or "PPPP" that the eNB 118 and/or cell allows for the eRelay UE. Such a situation could potentially mean that the UE has evolved packet system (EPS) bearers established with this QoS support, or that the UE has exchanged sidelink information message with the eNB 118 such that the eNB 118 has informed and/or confirmed the support of these QCI/PPPP types.

[00027] As part of the relay discovery solicitation message, the monitoring UE could request a specific QoS characteristic that it needs supported as part of its application. The application could provide a generic PPPP or a specific PPPP or QCI that it needs supported which may be sent as part of the discovery request message. The responding UE responds whether it supports the required QoS.

[00028] As shown in FIG. 3, as part of such a discovery process 310, relay UE (eRelay UE w/ ProSe) 214 may send an announcement message 312 to remote UE (eRemote UE w ProSe) 212 that QoS is supported in including QCI or PPPP. Alternatively, remote UE (eRemote UE w ProSe) 212 may send a solicitation request message 314 to relay UE (eRelay UE w/ ProSe) 214 indicating a required QoS including QCI or PPPP. The relay UE (eRelay UE w/ ProSe) 214 may then send a solicitation response message 316 to remote UE (eRemote UE w ProSe) 212 indicating whether or not relay UE (eRelay UE w/ ProSe) 214 supports the required QoS including QCI or PPPP. [00029] It should be noted that if the legacy discovery messages cannot accommodate more bits for including additional information, the QoS related information may be included as part of existing parameters, for example discoverer info or relay service code, or as part of discovery through communication messages. The QoS related information may be coded using a bitwise operator by allocating each bit to a different PPPP or QCI value. Alternatively, this information also may be sent by a new control plane protocol between remote UE 212 and relay UE 214, for example a light- weighted radio resource control (RRC) protocol designed between remote UE 212 and relay UE 214. As another alternative, this information also may be sent via a D2D communication channel. In addition, relay UE 214 may provide its QoS support through capability information and D2D and/or sidelink related capability information may be made available between remote UE 212 and relay UE 214 of their respective relevant information. An example of eNB involvement in supporting QoS over sidelink is shown in and described with respect to FIG. 4, below.

[00030] Referring now to FIG. 4, a diagram of evolved NodeB (eNB) involvement in supporting Quality of Service (QoS) over sidelink in accordance with one or more embodiments will be discussed. The method 400 shown in FIG. 4 illustrates how the eNB 118 participates in supporting QoS over sidelink. The required QoS over the sidelink accordingly needs to be supported over the Uu interface by the relay UE (eRelay UE w/ ProSe) 214. When the application running on remote UE (eRemote UE w/ProSe) 212 requests a specific PPPP or QCI, the bearer at the remote UE 212 and relay UE 214 may or may not already be established as this application requirement or type may not have been used before. Therefore, based on the request of remote UE 212, relay UE 214 may check with the eNB 118 whether this QoS type can be supported over end-to-end. Thus, a discovery announcement message 410 may be transmitted from relay UE 214 to remote UE 212, or a solicitation request message 412 may be sent from remote UE 212 to relay UE 214. The relay UE 214 may respond to the solicitation request message 412 by sending a SidelinkUEInformation message 414 to the eNB 118.

[00031 ] The eNB 118 may respond with a new message such as SidelinkUEInformationResponse message 416 to let the relay UE know whether it can support the required QoS. Furthermore, the eNB 118 or the network 118 could pre-authorize some relay UEs 214 to support specific QoS characteristics by which the relay UE 214 could respond immediately to a solicitation request message 412. The network 100 also may provide a list of relay UEs 214 that are pre-authorized to support specific QoS characteristics to the remote UE 212 when remote UE 212 is in the coverage area of eNB 118 so that the remote UE 212 may utilize the list when remote UE 212 is out of the coverage area of eNB 118. The relay UE 214 also may advertise support of specification application codes instead of specific QoS such as latency or bit rate. Alternatively, a solicitation request message 412 may be sent by anew control plane protocol between remote UE 212 and relay UE 214, for example a light-weighted RRC protocol designed between remote UE 212 and relay UE 214. As another alternative, a solicitation request message 412 also may be sent via a D2D communication channel. As needed, eNB 118 may send an RRC connection reconfiguration message 418 to relay UE 214, and relay UE 214 may respond to eNB 118 with an RRC reconfiguration complete message 420, and may send a solicitation response message 422 to remote UE 212.

[00032] Referring now to FIG. 5, a diagram of an uplink initiated bearer setup to support a specific Quality of Services (QoS) in accordance with one or more embodiments will be discussed. The uplink (UL) initiated bearer method 500 is shown in FIG. 5. If a specific QoS has to be supported over the sidelink by the relay UE (eRelay UE w/ProSe) 214 and remote UE (eRemote UE w/ProSe) 212, the necessary bearer may be established as shown in FIG. 5. Common messages may be used to perform these procedures by the relay UE 214 on behalf of the remote UE 212. These procedures may be implemented if a required QCI/PPPP/QSI does not have bearers already established wherein remote UE 212 and/or relay UE 214 are in idle mode and the bearers are torn down and need to be re-established due to a specific application request.

[00033] As shown in FIG. 5, relay UE 214 may send a discovery announcement message 510 to remote UE 212, or remote UE 212 may send a solicitation request message 512 to relay UE 214. Relay UE 214 may then send a bearer resource allocation request (non-access stratum message) message 514 to mobility management entity (MME) 120 with the required QCI for remote relay 214 and relay UE 212. MME 12 may then respond to relay UE 214 with an activate dedicated EPS bearer context request (non-access stratum response message) message 516 for remote UE 212 and relay UE 214. MME 120 also may send an EPS radio access bearer (E-RAB) setup request message 518 to eNB 118. In turn, eNB 118 may send an RRCConnectionReconfiguration message 520 including dedicated radio bearer (DRB) information to relay UE 214, and the relay UE 214 may respond with an RRCConnectionReconfigurationComplete message 522. Relay UE 214 may then send a solicitation response message 524 to remote UE 212.

[00034] Referring now to FIG. 6, a diagram of multiplexing Quality of Service (QoS) support for multiple user equipment (UE) devices and/or bearers in accordance with one or more embodiments will be discussed. The embodiment of FIG. 6 illustrates how data from multiple remote UEs, such as remote UE1 610 and remote UE2 612 and/or multiple bearers including multiple bearers from a same remote UE, map onto the same Uu bearer belonging to the relay (eRelay) UE 214. The Uu bearer of relay UE 214 may or may not match to the corresponding EPS bearer of the remote UE. The eNB 118 may couple with MME 120, serving gateway (S-GW) 220 and PDN gateway (P-GW) 222 as discussed herein.

[00035] FIG. 7 illustrates example components of a device 700 in accordance with some embodiments. In some embodiments, the device 700 may include application circuitry 702, baseband circuitry 704, Radio Frequency (RF) circuitry 706, front-end module (FEM) circuitry 708, one or more antennas 710, and power management circuitry (PMC) 712 coupled together at least as shown. The components of the illustrated device 700 may be included in a UE or a RAN node. In some embodiments, the device 700 may include less elements (e.g., a RAN node may not utilize application circuitry 702, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 700 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud- RAN (C-RAN) implementations).

[00036] The application circuitry 702 may include one or more application processors. For example, the application circuitry 702 may include circuitry such as, but not limited to, 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 processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 700. In some embodiments, processors of application circuitry 702 may process IP data packets received from an EPC.

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

[00038] In some embodiments, the baseband circuitry 704 may include one or more audio digital signal processor(s) (DSP) 704F. The audio DSP(s) 704F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry 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 704 and the application circuitry 702 may be implemented together such as, for example, on a system on a chip (SOC).

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

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

[00041 ] In some embodiments, the receive signal path of the RF circuitry 706 may include mixer circuitry 706a, amplifier circuitry 706b and filter circuitry 706c. In some embodiments, the transmit signal path of the RF circuitry 706 may include filter circuitry 706c and mixer circuitry 706a. RF circuitry 706 may also include synthesizer circuitry 706d for synthesizing a frequency for use by the mixer circuitry 706a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 706a of the receive signal path may be configured to down- convert RF signals received from the FEM circuitry 708 based on the synthesized frequency provided by synthesizer circuitry 706d. The amplifier circuitry 706b may be configured to amplify the down-converted signals and the filter circuitry 706c may be a low-pass filter (LPF) or bandpass 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 704 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 706a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[00042] In some embodiments, the mixer circuitry 706a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 706d to generate RF output signals for the FEM circuitry 708. The baseband signals may be provided by the baseband circuitry 704 and may be filtered by filter circuitry 706c.

[00043] In some embodiments, the mixer circuitry 706a of the receive signal path and the mixer circuitry 706a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 706a of the receive signal path and the mixer circuitry 706a 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 706a of the receive signal path and the mixer circuitry 706a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 706a of the receive signal path and the mixer circuitry 706a of the transmit signal path may be configured for super-heterodyne operation.

[00044] 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 these alternate embodiments, the RF circuitry 706 may include analog-to-digital converter (ADC) and digital-to- analog converter (DAC) circuitry and the baseband circuitry 704 may include a digital baseband interface to communicate with the RF circuitry 706.

[00045] In some dual-mode embodiments, a 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. In some embodiments, the synthesizer circuitry 706d may be a fractional-N synthesizer or a fractional N/N+l 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 706d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

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

[00047] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 704 or the applications processor 702 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 702.

[00048] Synthesizer circuitry 706d of the RF circuitry 706 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (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 these 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 provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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

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

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

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

[00053] While FIG. 7 shows the PMC 712 coupled only with the baseband circuitry 704. However, in other embodiments, the PMC 7 12 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 702, RF circuitry 706, or FEM 708.

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

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

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

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

[00058] The following are example implementations of the subject matter described herein. It should be noted that any of the examples and the variations thereof described herein may be used in any permutation or combination of any other one or more examples or variations, although the scope of the claimed subject matter is not limited in these respects.

[00059] In example one, an apparatus of a user equipment (UE) comprises one or more baseband processors to encode or decode data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB, and a memory to store the data. Example two may include the subject matter of example one or any of the examples described herein, wherein the specified QoS comprises a default QoS if the relay UE indicates it only supports the default QoS. Example three may include the subject matter of example one or any of the examples described herein, wherein the specified QoS comprises a level of QoS that the relay UE indicates it is capable of supporting. Example four may include the subject matter of example one or any of the examples described herein, wherein the one or more baseband processors are to generate a solicitation request message for the relay UE regarding a requested level of QoS at which the data is to be sent, and to process a solicitation response message from the UE indicating if the request level of QoS is supported. Example five may include the subject matter of example one or any of the examples described herein, wherein the sidelink interface comprises a PC5 interface that is capable of supporting proximity-based services (ProSe) or device-to-device (D2D) communication over the sidelink. Example six may include the subject matter of example one or any of the examples described herein, wherein the specified QoS includes proximity-based services (ProSe)-Per-Packet-Priority (PPPP) information or QoS Class Identifier (QCI) information, or a combination thereof. Example seven may include the subject matter of example one or any of the examples described herein, wherein the one or more baseband processors are to perform a reselection process to reselect to a different relay UE if the different relay UE has a better signal quality than the relay UE and if the different relay UE is capable of supporting the selected QoS.

[00060] In example eight, an apparatus of a relay user equipment (UE) comprises one or more baseband processors to generate a message to be sent to a remote UE indicating a selected quality of service (QoS) for data to be sent to or received from an evolved NodeB (eNB) via the relay UE over a sidelink, and to forward the data between the remote UE and the eNB at the selected QoS, and a memory to store the message. Example nine may include the subject matter of example eight or any of the examples described herein, wherein the message comprises an announcement message to indicate to the remote UE a level of QoS that the relay UE is capable of supporting. Example ten may include the subject matter of example eight or any of the examples described herein, wherein the message comprises a solicitation response message to indicated to the remote UE whether the relay UE supports a level of QoS requested in a solicitation request message received from the remote UE. Example eleven may include the subject matter of example eight or any of the examples described herein, wherein the one or more baseband processors are to generate a SidelinkUEInformation message to be sent to the eNB indicating a level of QoS requested by the remote UE, and to process a SidelinkEUInformationResponse message received from the eNB indicating whether the requested level of QoS is supported. Example twelve may include the subject matter of example eight or any of the examples described herein, wherein information regarding the selected QoS is to be transferred between the relay UE and the remote UE using a lightweight radio resource control (RRC) control plane protocol or using a device-to- device (D2D) communication channel. Example thirteen may include the subject matter of example eight or any of the examples described herein, wherein the one or more baseband processors are to generate another message to be sent to another remote UE indicating a selected quality of service (QoS) for data sent to or received from the eNB via the relay UE over a sidelink, and to forward the data between the other remote UE and the eNB at the selected QoS via multiplexing between the remote UE and the other remote UE.

[00061 ] In example fourteen, one or more machine -readable media may have instructions thereon that, if executed by an apparatus of a user equipment (UE), result in encoding or decoding data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB, and storing the data. Example fifteen may include the subject matter of example fourteen or any of the examples described herein, wherein the specified QoS comprises a default QoS if the relay UE indicates it only supports the default QoS. Example sixteen may include the subject matter of example fourteen or any of the examples described herein, wherein the specified QoS comprises a level of QoS that the relay UE indicates it is capable of supporting. Example seventeen may include the subject matter of example fourteen or any of the examples described herein, wherein the instructions, if executed, further result in generating a solicitation request message for the relay UE regarding a requested level of QoS at which the data is to be sent, and processing a solicitation response message from the UE indicating if the request level of QoS is supported. Example eighteen may include the subject matter of example fourteen or any of the examples described herein, wherein the sidelink interface comprises a PC5 interface that is capable of supporting proximity-based services (ProSe) or device-to-device (D2D) communication over the sidelink. Example nineteen may include the subject matter of example fourteen or any of the examples described herein, wherein the specified QoS includes proximity-based services (ProSe)- Per-Packet-Priority (PPPP) information or QoS Class Identifier (QCI) information, or a combination thereof. Example twenty may include the subject matter of example fourteen or any of the examples described herein, wherein the instructions, if executed, further result in performing a reselection process to reselect to a different relay UE if the different relay UE has a better signal quality than the relay UE and if the different relay UE is capable of supporting the selected QoS.

[00062] In example twenty-one, one or more machine-readable media may have instructions thereon that, if executed by an apparatus of a relay user equipment (UE), result in generating a message to be sent to a remote UE indicating a selected quality of service (QoS) for data sent to or received from an evolved NodeB (eNB) via the relay UE over a sidelink, and forwarding the data between the remote UE and the eNB at the selected QoS, and storing the message. Example twenty-two may include the subject matter of example twenty-one or any of the examples described herein, wherein the message comprises an announcement message to indicate to the remote UE a level of QoS that the relay UE is capable of supporting. Example twenty-three may include the subject matter of example twenty-one or any of the examples described herein, wherein the message comprises a solicitation response message to indicated to the remote UE whether the relay UE supports a level of QoS requested in a solicitation request message received from the remote UE. Example twenty-four may include the subject matter of example twenty-one or any of the examples described herein, wherein the instructions, if executed, further result in generating a SidelinkUEInformation message to be sent to the eNB indicating a level of QoS requested by the remote UE, and processing a SidelinkEUInformationResponse message received from the eNB indicating whether the requested level of QoS is supported. Example twenty-five may include the subject matter of example twenty-one or any of the examples described herein, wherein information regarding the selected QoS is to be transferred between the relay UE and the remote UE using a lightweight radio resource control (RRC) control plane protocol or using a device-to-device (D2D) communication channel. Example twenty-six may include the subject matter of example twenty-one or any of the examples described herein, wherein the instructions, if executed, further result in generating another message to be sent to another remote UE indicating a selected quality of service (QoS) for data sent to or received from the eNB via the relay UE over a sidelink, and forwarding the data between the other remote UE and the eNB at the selected QoS via multiplexing between the remote UE and the other remote UE.

[00063] In example twenty-seven, an apparatus of a user equipment (UE) comprises means for encoding or decoding data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB, and means for storing the data. Example twenty-eight may include the subject matter of example twenty-seven or any of the examples described herein, wherein the specified QoS comprises a default QoS if the relay UE indicates it only supports the default QoS. Example twenty-nine may include the subject matter of example twenty-seven or any of the examples described herein, wherein the specified QoS comprises a level of QoS that the relay UE indicates it is capable of supporting. Example thirty may include the subject matter of example twenty-seven or any of the examples described herein, further comprising means for generating a solicitation request message for the relay UE regarding a requested level of QoS at which the data is to be sent, and means for processing a solicitation response message from the UE indicating if the request level of QoS is supported. Example thirty- one may include the subject matter of example twenty-seven or any of the examples described herein, wherein the sidelink interface comprises a PC5 interface that is capable of supporting proximity-based services (ProSe) or device-to-device (D2D) communication over the sidelink. Example thirty-two may include the subject matter of example twenty- seven or any of the examples described herein, wherein the specified QoS includes proximity-based services (ProSe)- Per-Packet-Priority (PPPP) information or QoS Class Identifier (QCI) information, or a combination thereof. Example thirty-three may include the subject matter of example twenty- seven or any of the examples described herein, further comprising means for performing a reselection process to reselect to a different relay UE if the different relay UE has a better signal quality than the relay UE and if the different relay UE is capable of supporting the selected QoS.

[00064] In example thirty-four, an apparatus of a relay user equipment (UE) comprises means for generating a message to be sent to a remote UE indicating a selected quality of service (QoS) for data to be sent to or received from an evolved NodeB (eNB) via the relay UE over a sidelink, and means for forwarding the data between the remote UE and the eNB at the selected QoS, and means for storing the message. Example thirty-five may include the subject matter of example thirty-four or any of the examples described herein, wherein the message comprises an announcement message to indicate to the remote UE a level of QoS that the relay UE is capable of supporting. Example thirty-six may include the subject matter of example thirty-four or any of the examples described herein, wherein the message comprises a solicitation response message to indicated to the remote UE whether the relay UE supports a level of QoS requested in a solicitation request message received from the remote UE. Example thirty-seven may include the subject matter of example thirty-four or any of the examples described herein, further comprising means for generating a SidelinkUEInformation message to be sent to the eNB indicating a level of QoS requested by the remote UE, and means for processing a SidelinkEUInformationResponse message received from the eNB indicating whether the requested level of QoS is supported. Example thirty- eight may include the subject matter of example thirty-four or any of the examples described herein, wherein information regarding the selected QoS is to be transferred between the relay UE and the remote UE using a lightweight radio resource control (RRC) control plane protocol or using a device-to-device (D2D) communication channel. Example thirty-nine may include the subject matter of example thirty-four or any of the examples described herein, further comprising means for generating another message to be sent to another remote UE indicating a selected quality of service (QoS) for data sent to or received from the eNB via the relay UE over a sidelink, and means for forwarding the data between the other remote UE and the eNB at the selected QoS via multiplexing between the remote UE and the other remote UE. In example forty, machine- readable storage may include machine-readable instructions, when executed, to implement a method or realize an apparatus as claimed in any preceding claim.

[00065] In the description herein and/or claims, the terms coupled and/or connected, along with their derivatives, may be used. In particular embodiments, connected may be used to indicate that two or more elements are in direct physical and/or electrical contact with each other. Coupled may mean that two or more elements are in direct physical and/or electrical contact. Coupled, however, may also mean that two or more elements may not be in direct contact with each other, but yet may still cooperate and/or interact with each other. For example, "coupled" may mean that two or more elements do not contact each other but are indirectly joined together via another element or intermediate elements. Finally, the terms "on," "overlying," and "over" may be used in the following description and claims. "On," "overlying," and "over" may be used to indicate that two or more elements are in direct physical contact with each other. It should be noted, however, that "over" may also mean that two or more elements are not in direct contact with each other. For example, "over" may mean that one element is above another element but not contact each other and may have another element or elements in between the two elements. Furthermore, the term "and/or" may mean "and", it may mean "or", it may mean "exclusive-or", it may mean "one", it may mean "some, but not all", it may mean "neither", and/or it may mean "both", although the scope of claimed subject matter is not limited in this respect. In the description herein and/or claims, the terms "comprise" and "include," along with their derivatives, may be used and are intended as synonyms for each other.

[00066] Although the claimed subject matter has been described with a certain degree of particularity, it should be recognized that elements thereof may be altered by persons skilled in the art without departing from the spirit and/or scope of claimed subject matter. It is believed that the subject matter pertaining to Quality of Service (QoS) support over evolved universal terrestrial radio access (E-UTRA) based sidelink system and many of its attendant utilities will be understood by the forgoing description, and it will be apparent that various changes may be made in the form, construction and/or arrangement of the components thereof without departing from the scope and/or spirit of the claimed subject matter or without sacrificing all of its material advantages, the form herein before described being merely an explanatory embodiment thereof, and/or further without providing substantial change thereto. It is the intention of the claims to encompass and/or include such changes.

Claims

What is claimed is: 1. An apparatus of a user equipment (UE), comprising:

one or more baseband processors to encode or decode data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB; and a memory to store the data.

2. The apparatus of claim 1, wherein the specified QoS comprises a default QoS if the relay UE indicates it only supports the default QoS.

3. The apparatus of any one of claims 1-2, wherein the specified QoS comprises a level of QoS that the relay UE indicates it is capable of supporting.

4. The apparatus of any one of claims 1-3, wherein the one or more baseband processors are to generate a solicitation request message for the relay UE regarding a requested level of QoS at which the data is to be sent, and to process a solicitation response message from the UE indicating if the request level of QoS is supported.

5. The apparatus of any one of claims 1-4, wherein the sidelink interface comprises a PC5 interface that is capable of supporting proximity-based services (ProSe) or device-to-device (D2D) communication over the sidelink.

6. The apparatus of any one of claims 1-5, wherein the specified QoS includes proximity- based services (ProSe)-Per-Packet-Priority (PPPP) information or QoS Class Identifier (QCI) information, or a combination thereof.

7. The apparatus of any one of claims 1-6, wherein the one or more baseband processors are to perform a reselection process to reselect to a different relay UE if the different relay UE has a better signal quality than the relay UE and if the different relay UE is capable of supporting the selected QoS.

8. An apparatus of a relay user equipment (UE), comprising: one or more baseband processors to generate a message to be sent to a remote UE indicating a selected quality of service (QoS) for data to be sent to or received from an evolved NodeB (eNB) via the relay UE over a sidelink, and to forward the data between the remote UE and the eNB at the selected QoS; and

a memory to store the message.

9. The apparatus of claim 8, wherein the message comprises an announcement message to indicate to the remote UE a level of QoS that the relay UE is capable of supporting.

10. The apparatus of any one of claims 8-9, wherein the message comprises a solicitation response message to indicated to the remote UE whether the relay UE supports a level of QoS requested in a solicitation request message received from the remote UE.

11. The apparatus of any one of claims 8- 10, wherein the one or more baseband processors are to generate a SidelinkUEInformation message to be sent to the eNB indicating a level of QoS requested by the remote UE, and to process a SidelinkEUInformationResponse message received from the eNB indicating whether the requested level of QoS is supported.

12. The apparatus of any one of claims 8-11, wherein information regarding the selected QoS is to be transferred between the relay UE and the remote UE using a lightweight radio resource control (RRC) control plane protocol or using a device-to-device (D2D) communication channel.

13. The apparatus of any one of claims 8-12, wherein the one or more baseband processors are to generate another message to be sent to another remote UE indicating a selected quality of service (QoS) for data sent to or received from the eNB via the relay UE over a sidelink, and to forward the data between the other remote UE and the eNB at the selected QoS via multiplexing between the remote UE and the other remote UE.

14. One or more machine-readable media having instructions thereon that, if executed by an apparatus of a user equipment (UE), result in:

encoding or decoding data to be sent to or received from an evolved NodeB (eNB) via a relay UE over a sidelink interface at a specified quality of service (QoS) if the UE is in proximity to the relay UE and the UE is out of coverage with the eNB ; and

storing the data.

15. The one or more machine-readable media of claim 14, wherein the specified QoS comprises a default QoS if the relay UE indicates it only supports the default QoS.

16. The one or more machine-readable media of any one of claims 14-15, wherein the specified QoS comprises a level of QoS that the relay UE indicates it is capable of supporting.

17. The one or more machine-readable media of any one of claims 14-16, wherein the instructions, if executed, further result in generating a solicitation request message for the relay UE regarding a requested level of QoS at which the data is to be sent, and processing a solicitation response message from the UE indicating if the request level of QoS is supported.

18. The one or more machine-readable media of any one of claims 14-17, wherein the sidelink interface comprises a PC5 interface that is capable of supporting proximity-based services (ProSe) or device-to-device (D2D) communication over the sidelink.

19. The one or more machine-readable media of any one of claims 14-18, wherein the specified QoS includes proximity-based services (ProSe)-Per-Packet-Priority (PPPP) information or QoS Class Identifier (QCI) information, or a combination thereof.

20. The one or more machine-readable media of any one of claims 14-19, wherein the instructions, if executed, further result in performing a reselection process to reselect to a different relay UE if the different relay UE has a better signal quality than the relay UE and if the different relay UE is capable of supporting the selected QoS.

21. One or more machine-readable media having instructions thereon that, if executed by an apparatus of a relay user equipment (UE), result in:

generating a message to be sent to a remote UE indicating a selected quality of service (QoS) for data to be sent to or received from an evolved NodeB (eNB) via the relay UE over a sidelink, and forwarding the data between the remote UE and the eNB at the selected QoS; and storing the message.

22. The one or more machine-readable media of any one of claims 21, wherein the message comprises an announcement message to indicate to the remote UE a level of QoS that the relay UE is capable of supporting.

23. The one or more machine-readable media of any one of claims 21-22, wherein the message comprises a solicitation response message to indicated to the remote UE whether the relay UE supports a level of QoS requested in a solicitation request message received from the remote UE.

24. The one or more machine-readable media of any one of claims 21-23, wherein the instructions, if executed, further result in generating a SidelinkUEInformation message to be sent to the eNB indicating a level of QoS requested by the remote UE, and processing a SidelinkEUInformationResponse message received from the eNB indicating whether the requested level of QoS is supported.

25. The one or more machine-readable media of any one of claims 21-24, wherein information regarding the selected QoS is to be transferred between the relay UE and the remote UE using a lightweight radio resource control (RRC) control plane protocol or using a device-to- device (D2D) communication channel.

26. The one or more machine-readable media of any one of claims 21-25, wherein the instructions, if executed, further result in generating another message to be sent to another remote UE indicating a selected quality of service (QoS) for data sent to or received from the eNB via the relay UE over a sidelink, and forwarding the data between the other remote UE and the eNB at the selected QoS via multiplexing between the remote UE and the other remote UE.