WO2017196611A1

WO2017196611A1 - Devices and methods for power efficient d2d communications for wearables/iot

Info

Publication number: WO2017196611A1
Application number: PCT/US2017/030884
Authority: WO
Inventors: Martino M. Freda; Saad Ahmad; Diana Pani; Benoit Pelletier
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2016-05-11
Filing date: 2017-05-03
Publication date: 2017-11-16

Abstract

Systems, methods, and instrumentalities are disclosed for power efficient device to device (D2D) communications for wearables and internet of things (IoT). A wireless transmit/receive unit (WTRU) may determine to enter a power saving state. The power saving state may be a discontinuous reception (DRX) mode. The WTRU may receive an indication from an eNB. The indication may be sent at the beginning of a data burst. The indication may indicate a time to monitor for data. The indication may indicate one or more resources to monitor. The indication may be received via a physical downlink control channel (PDCCH) message. The WTRU may determine to wake-up from the power saving state to monitor for data. The WTRU may determine to wake-up based on the received indication.

Description

DEVICES AND METHODS FOR POWER EFFICIENT D2D COMMUNICATIONS FOR

WEARABLES/IOT

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent Application No.

62/334,768, filed on May 11, 2016; U.S. Provisional Patent Application No. 62/373,122, filed on August 10, 2016; and U.S. Provisional Patent Application No. 62/416,468, filed on November 2, 2016, the contents of all of which being hereby incorporated by reference as if fully set-forth herein in their respective entirety, for all purposes.

BACKGROUND

[0002] Direct device-to-device (D2D) communications has gained a lot of interest recently as major standardization bodies like IEEE and 3 GPP have defined or are in the process of defining specifications to support D2D communications. In the case of 3GPP and LTE based radio access, support for D2D communications is being introduced to allow for cost-efficient and high- capability public safety communications using LTE technology. Support for D2D

communications using LTE technology is motivated by the desire to harmonize the radio access technology across jurisdictions to lower the CAPEX and OPEX of radio-access technology available for the use of public safety (PS) type of applications. Support for D2D communications using LTE technology is motivated by the fact that LTE as a scalable wideband radio solution that allows for efficient multiplexing of different services types like voice and video.

[0003] It is expected that once deployed, D2D communications may be available not only for PS type of applications, but also for commercial use cases. For example, utility companies who often also require support for 2-way radio communications in areas not covered by network infrastructure may deploy D2D communications using LTE technology. D2D services such as Discovery are suitable signaling to allow for proximity based services and/or traffic offload using LTE based radio access in commercial use cases. SUMMARY

[0004] One or more example embodiments as described more fully below provide apparatuses, functions, procedures, processes, execution of computer program instruction tangibly embodying a computer readable memory, functions and operation of methods for one or more of the following. Systems, methods, and instrumentalities are disclosed for PHY layer multiplexing of different types of traffic in 5G systems. Power savings over PC5 may be provided while in connected mode. A wireless transmit/receive unit (WTRU) may autonomously determine to move to discontinuous reception (DRX) mode. The DRX and/or power saving behavior of the WTRU may be controlled by one or more other WTRUs. A remote WTRU may perform power efficient discovery and/or attachment. A WTRU may maintain one or more established radio bearers. A remote WTRU may receive some or all RRC messaging from a relay WTRU, for example, when connected to the relay WTRU. A remote WTRU may respond to a network paging (e.g., establishing an RRC connection) via a relay WTRU. A relay WTRU may monitor paging over a Uu interface, for example, on behalf of one or more remote WTRUs.

[0005] A WTRU may determine to enter a power saving state. The power saving state may be a DRX mode. The WTRU may receive an indication from an eNB. The indication may be sent at the beginning of a data burst. The indication may indicate a time to monitor for data. The indication may indicate one or more resources to monitor. The indication may be received via a physical data control channel (PDCCH) message. The WTRU may determine to wake up from the power saving state to monitor for data. The WTRU may determine to wake up based on the received indication.

[0006] A wireless transmit/receive unit (WTRU) may comprise a memory. The WTRU may be referred to as a first WTRU. The first WTRU may comprise a receiver. The receiver may be configured to receive paging configuration information for a second WTRU. The first WTRU may comprise a processor. The processor may be configured to determine one or more paging occasions for the second WTRU from the paging configuration information. The first WTRU may monitor at least one of the one or more paging occasions on an Uu interface. The receiver may be configured to receive at least one paging message directed to the second WTRU at the at least one of the one or more paging occasions. The processor may be configured to initiate a discovery procedure of the second WTRU on at least one of: a PC5 interface, or a non-3GPP interface, upon the receipt of the at least one paging message. The processor may be configured to establish at least one of: a PC5 link, or a non-3GPP link with the second WTRU based on a result of the discovery procedure. The processor may be configured to initiate a transfer of the at least one paging message to the second WTRU on the at least one of: the PC5 link, or the non- 3 GPP link with the second WTRU.

[0007] A wireless transmit/receive unit (WTRU) may comprise a memory. The WTRU may be referred to as a first WTRU. The first WTRU may comprise a processor. The processor may be configured to determine paging configuration information for the first WTRU. The processor may be configured to initiate a transmission of the paging configuration information for the first WTRU to a second WTRU. The processor may be configured to detect a discovery request of the first WTRU by the second WTRU on at least one of: a PC5 interface, or a non-3 GPP interface. The processor may be configured to establish at least one of: a PC5 link, or a non- 3GPP link with the second WTRU based on the discovery request. The first WTRU may comprise a receiver. The receiver may be configured to receive at least one paging message directed to the first WTRU from the second WTRU on the at least one of: the PC5 link, or the non-3GPP link with the second WTRU.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 A is a system diagram of an example communications system in which one or more disclosed embodiments may be implemented.

[0009] FIG. IB is a system diagram of an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1 A.

[0010] FIG. 1C is a system diagram of an example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1A.

[0011] FIG ID is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1 A.

[0012] FIG. IE is a system diagram of another example radio access network and an example core network that may be used within the communications system illustrated in FIG. 1 A.

[0013] FIG. 2 depicts an example transmitter block diagram for an example relay architecture.

[0014] FIG. 3 depicts an example indication to start or stop PC5 monitoring.

[0015] FIG. 4 depicts an example radio bearer and logical channel handling.

[0016] FIG. 5 depicts an example paging configuration for a remote device. DETAILED DESCRIPTION

[0017] A detailed description of illustrative embodiments will now be described with reference to the various Figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be examples and in no way limit the scope of the application.

[0018] FIG. 1A is a diagram of an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single- carrier FDMA (SC-FDMA), and the like.

[0019] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, and/or 102d (which generally or collectively may be referred to as WTRU 102), a radio access network (RAN) 103/104/105, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d may be configured to transmit and/or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, consumer electronics, and the like.

[0020] The communications systems 100 may also include a base station 114a and a base station 114b. Each of the base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, and/or the networks 112. By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0021] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 114a and/or the base station 114b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in one embodiment, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In another embodiment, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0022] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).

[0023] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 using wideband CDMA (WCDMA).

WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).

[0024] In another embodiment, the base station 114a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE- A).

[0025] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for

Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim

Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0026] The base station 114b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d may utilize a cellular- based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in FIG. 1 A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be required to access the Internet 110 via the core network 106/107/109.

[0027] The RAN 103/104/105 may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in FIG. 1 A, it will be appreciated that the RAN 103/104/105 and/or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or a different RAT. For example, in addition to being connected to the RAN 103/104/105, which may be utilizing an E-UTRA radio technology, the core network

106/107/109 may also be in communication with another RAN (not shown) employing a GSM radio technology.

[0028] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b,

102c, 102d to access the PSTN 108, the Internet 110, and/or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service

(POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or a different RAT.

[0029] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0030] FIG. IB is a system diagram of an example WTRU 102. As shown in FIG. IB, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment. Also, embodiments contemplate that the base stations 114a and 114b, and/or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node-B gateway, and proxy nodes, among others, may include some or all of the elements depicted in FIG. IB and described herein.

[0031] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller,

Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 118 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the

transmit/receive element 122. While FIG. IB depicts the processor 118 and the transceiver 120 as separate components, it will be appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0032] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 115/116/117. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In another embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0033] In addition, although the transmit/receive element 122 is depicted in FIG. IB as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.

[0034] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.

[0035] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 118 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0036] The processor 118 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0037] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0038] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.

[0039] FIG. 1C is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 1C, the RAN 103 may include Node-Bs 140a, 140b, 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0040] As shown in FIG. 1C, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node- Bs 140a, 140b, 140c may communicate with the respective RNCs 142a, 142b via an Iub interface. The RNCs 142a, 142b may be in communication with one another via an lur interface. Each of the RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which it is connected. In addition, each of the RNCs 142a, 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macrodiversity, security functions, data encryption, and the like.

[0041] The core network 106 shown in FIG. 1C may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and/or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0042] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0043] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet- switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0044] As noted above, the core network 106 may also be connected to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0045] FIG. ID is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0046] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0047] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink and/or downlink, and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0048] The core network 107 shown in FIG. ID may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator.

[0049] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer

activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0050] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0051] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0052] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0053] FIG. IE is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 117. As will be further discussed below, the communication links between the different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points. [0054] As shown in FIG. IE, the RAN 105 may include base stations 180a, 180b, 180c, and an ASN gateway 182, though it will be appreciated that the RAN 105 may include any number of base stations and ASN gateways while remaining consistent with an embodiment. The base stations 180a, 180b, 180c may each be associated with a particular cell (not shown) in the RAN 105 and may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handoff triggering, tunnel establishment, radio resource management, traffic classification, quality of service (QoS) policy enforcement, and the like. The ASN gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0055] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an Rl reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication,

authorization, IP host configuration management, and/or mobility management.

[0056] The communication link between each of the base stations 180a, 180b, 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0057] As shown in FIG. IE, the RAN 105 may be connected to the core network 109. The communication link between the RAN 105 and the core network 109 may defined as an R3 reference point that includes protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements are depicted as part of the core network 109, it will be appreciated that any one of these elements may be owned and/or operated by an entity other than the core network operator. [0058] The MIP-HA may be responsible for IP address management, and may enable the WTRUs 102a, 102b, 102c to roam between different ASNs and/or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and for supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and/or operated by other service providers.

[0059] Although not shown in FIG. IE, it will be appreciated that the RAN 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference, which may include protocols for facilitating interworking between home core networks and visited core networks.

[0060] In view of Figures 1A-1E, and the corresponding description of Figures 1A-1E, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 114a-b, Node B 140a-c, RNC 142a-b, MSC 146, SGSN 148, MGW 144, CGSN 150, eNode-B 160a-c, MME 162, Serving Gateway 164, PDN Gateway 166, Base Station 180a- c, ASN Gateway 182, AAA 186, MIP-HA 184, and/or Gateway 188, or the like, may be performed by one or more emulation devices (not shown) (e.g., one or more devices configured to emulate one or more, or all, of the functions described herein).

[0061] The one or more emulation devices may be configured to perform the one or more, or all, functions in one or more modalities. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented/deployed as part of a wired and/or wireless communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The one or more emulation devices may perform the one or more, or all, functions while not being implemented/deployed as part of a wired and/or wireless communication network (e.g., such as in a testing scenario in a testing laboratory and/or a non-deployed (e.g. testing) wired and/or wireless communication network, and/or testing performed on one or more deployed components of a wired and/or wireless communication network). The one or more emulation devices may be test equipment.

[0062] Device-to-device (D2D) communications may include public safety (PS) type of applications. PS type of applications may require radio communications in areas that are often not under radio coverage of an LTE network, e.g., in tunnels, in deep basements, or following catastrophic system outages. Support for D2D communications for PS may be required in absence of any operating network and/or prior to the arrival of an AdHoc deployed radio infrastructure. PS communications may require higher reliability than commercial services (e.g., even when operating in presence of operating network infrastructure).

[0063] PS type of applications, e.g., between first responders, may include direct push-to-talk speech services. The direct push-to-talk speech services may include using multiple talk groups. PS type of applications may include services such as video push and/or download (e.g., to make efficient use of the capabilities an LTE broadband radio provides).

[0064] D2D communications using LTE based radio access may be configured to operate in network-control mode and/or in WTRU autonomous mode. Network-control mode may be referred to as Mode 1. WTRU autonomous mode may be referred to as Mode 2. D2D communications may operate in Mode 1 if the D2D terminal is in radio range of an LTE base station. The D2D terminal may fall back to Mode 2 operation (e.g., from Mode 1 operation) if the D2D terminal cannot communicate with the LTE base station. The D2D terminal may use one or more channel access parameters. The one or more channel access parameters may be pre- stored on the D2D terminal itself.

[0065] For D2D communications using Mode 1 operation, an LTE base station may identify (e.g., reserve) a first set of uplink (UL) subframes to allow for D2D transmissions. The LTE base station may identify (e.g., announce) a second set of UL subframes with associated parameters in which D2D communications for one or more neighbor cells or Mode 2 terminals may be received. Some LTE system bandwidth (BW) may be unavailable for D2D

transmissions in a subframe reserved for D2D. When operating in Mode 1, radio resources for D2D communications may be granted to a D2D terminal by the serving cell. The D2D grant from the network may be preceded by an UL transmission that indicates an amount of available D2D data. The UL transmission may be sent by the D2D terminal on the cellular UL. The D2D grant received by the D2D terminal from the LTE base station on the cellular downlink (DL) may allow the D2D terminal to use one or more selected radio resources, e.g., some radio blocks (RBs) occurring in some subframes over a predetermined scheduling period.

[0066] The D2D terminal may transmit a Scheduling Assignment (SA) message in a first set of one or more D2D subframe(s). The D2D terminal may transmit the D2D data in a second set of the one or more D2D subframes in a scheduling period. An SA may include an identifier field, an MCS field, a resource indicator, and/or a TA field. A D2D data packet may include a MAC header with a source address and/or a destination address. Multiple logical channels may be multiplexed. The multiple logical channels may be sent as part of a single transport block (TB) in a given D2D subframe by a WTRU.

[0067] For D2D communications using Mode 2, the D2D terminals may select time/frequency radio resources autonomously. One or more channel access parameters (e.g., such as the subframes for use with transmissions of SA control messages and corresponding D2D data, scheduling periods, and/or monitoring subframes) may be pre-configured and/or stored on the D2D terminal. A Mode 2 terminal may follow the same transmission behavior (e.g., except the preceding UL traffic volume indication and DL D2D grant phase) as a Mode 1 terminal. For example, the Mode 2 terminal may transmit SAs followed by D2D data in scheduling periods.

[0068] For D2D communications Mode 1 and Mode 2, D2D terminals may transmit one or more auxiliary D2D signals. The one or more auxiliary D2D signals may include D2D

synchronization signals and/or channel messages (e.g., to aid receivers in demodulating their transmissions).

[0069] D2D communications using LTE based radio access may include one or more voice channels, data packets, and/or data streams. D2D discovery service may be a case of D2D communications. D2D discovery (e.g., unlike voice channels) may require small packet transmissions. A small packet transmission may fit in a small number of (e.g., one, two, or a few) subframes. For example, small packet transmissions may include application data announcing availability of devices and/or SW applications to participate in D2D data exchanges with one or more terminals in the vicinity.

[0070] D2D discovery may use the channel access protocol used for D2D communications for voice and/or generic D2D data. For D2D discovery service when in coverage of an LTE base station, one or more D2D discovery resources can be allocated separately from those used for

D2D communications for voice and/or generic D2D data. Radio resources for D2D discovery messages may be selected autonomously by D2D terminals from a set of resources reserved by the eNB. The radio resources for D2D discovery messages may be selected autonomously by

D2D terminals from a set of periodically recurring time-frequency radio resources in certain UL subframes (e.g., such as in a Type 1 discovery). The radio resources for D2D discovery messages may be selected autonomously by the D2D terminals from a set of resources that are explicitly allocated by the LTE serving cell to the D2D terminals (e.g., such as in a Type 2 discovery). Selecting radio resources from a set of resources that are explicitly allocated by the LTE serving cell may be similar to D2D communications Mode 1. Transmissions of scheduling assignments may not be required when transmitting D2D discovery messages. D2D terminals (e.g., only transmitting D2D discovery messages) may transmit one or more auxiliary D2D synchronization signals (e.g., to assist receivers).

[0071] LTE technology may be used to connect and/or manage low cost MTC devices. Low cost devices may include wearables (e.g., wearable devices). A wearable may use a WTRU (e.g., a smartphone) as a relay (e.g., due to its close proximity).

[0072] Enhancements to D2D communications for Wearables and IoT devices may include enhancement of WTRU-to-Network relaying functionality and/or enhancements to enable reliable unicast PC5 link to at least support low power, low rate, low complexity, and/or low cost devices.

[0073] WTRU-to-Network relaying functionality may be enhanced to support end-to-end (E2E) security, service continuity, E2E QOS, multiple remote WTRUs, and/or efficient path switching.

The WTRU-to-Network relaying architecture in ProSe may not differentiate the traffic of a remote WTRU from the traffic of a relay WTRU in the access stratum. Not differentiating the traffic of the remote WTRU and the relay WTRU may prevent the network and/or the operator to treat the remote WTRU as a separate device, e.g., for billing and/or security. For example, the

3GPP security associations may not reach E2E between the network and the remote WTRU and the relay WTRU may have clear text access to the communications of the remote WTRU.

WTRU-to-Network relaying may be enhanced to support E2E security through the relay link, service continuity, E2E QoS, efficient operation with multiple remote WTRUs, and/or efficient path switching between Uu and D2D air-interfaces. Relaying using D2D may be based on non-

3GPP technologies such as Bluetooth and/or Wi-Fi. Some enhancements (e.g., such as service continuity) may make relaying more advantageous for such technologies in commercial use cases. Relaying may enable power savings for remote WTRUs (e.g., remote WTRUs that are getting their traffic relayed). A cost-effective way of introduce relaying may include using unidirectional D2D links between remote devices and relay devices. For example, the relay

WTRU may be utilized to relay only uplink data from the remote WTRU. When the relay

WTRU is used to relay only uplink data from the remote WTRU, additional RF capability for

D2D reception may not be needed for the remote WTRU. [0074] Enhancements may be provided to enable reliable unicast PC5 link to support low power, low rate, low complexity, and/or low cost devices. Low cost D2D devices may be enabled by using Narrow Band (NB) IoT and/or eMTC developments, e.g., a NB-IoT/eMTC uplink waveform can be reused for D2D. Low cost D2D devices may use a single modem for communicating with the Internet/cloud and for communicating with one or more proximal devices. A broadcast oriented PC5 link design driven by public safety use cases, may result in a bottleneck that prevents low power and reliable D2D communication, e.g., due to lack of any link adaptation and/or feedback mechanisms. The broadcast oriented PC5 link design may not allow achieving target performance metrics for wearable and/or MTC use cases in terms of power consumption, spectrum efficiency, and/or device complexity.

[0075] FIG. 2 depicts an example relay architecture. For example, a remote WTRU may have a first connection, IF3, with an eNB and a second connection, IF2, with a relay WTRU. The relay WTRU may have a third connection, IF1, with the eNB. One or more of the following assumptions may be associated with the example relay architecture. The third connection, IF1, may be a Uu interface between the relay WTRU and the eNB. The second connection, IF2, may be a D2D link. The D2D link may be PC5 or a non-3GPP link (e.g., such as Bluetooth, WiFi, or other non-3GPP links). The first connection, IF3, may be a Uu interface. The Uu interface may be assumed to be NB-IoT (e.g., the Remote WTRU may be in extended coverage with the eNB through NB-IoT repetitions).

[0076] Data and/or control information may be routed to and/or from the remote WTRU over different interfaces. For example, some or all control and data may be sent via the relay WTRU. The control and data to and/or from the remote WTRU may be sent over the second connection, IF2. The remote WTRU, when connected to the relay WTRU, may monitor broadcast signaling over the first connection IF3, and/or may receive the broadcast signaling via the relay WTRU.

[0077] Control and data to and/or from the remote WTRU may be split between the first connection, IF3, and the second connection, IF2. For example, control information and/or control procedures may be performed via IF3 and data (e.g., both UL and DL data) may be transmitted over IF2. The remote WTRU may save the power associated with transmission and reception of data via IF2.

[0078] Data and control information may be split based on uplink and downlink. For example, UL data (e.g., both control and data) may be sent via IF2 and DL data (e.g., both control and data) may be sent via IF3. The remote WTRU may save power in not having to transmit in the uplink. [0079] The remote WTRU may transmit UL user plane data to the relay WTRU via IF2. Other traffic (e.g., DL user plane as well as control plane) may be transmitted via IF3.

[0080] WTRU to network relays in Rell3 D2D may have several shortcomings which reduce their utility for IoT and/or wearable devices. For example, use of Rell3 D2D WTRU to network relays for IoT and/or wearable devices may be associated with one or more of a potential lack of ProSe function, more eNB control, a power savings problem, different connection assumptions, and/or different coverage assumptions.

[0081] The wearables and/or IoT use case may be configured for commercial use. For the wearables and/or IoT use case, the ProSe function may disappear or may have to work in more close association with the eNB and/or the network.

[0082] To enable better QoS and/or utilization of resources (e.g., to address a potentially large number of relays), the eNB may be given a greater amount of control as compared to Rell3 relays. For example, relaying may be performed at L2 for the wearables and/or IoT use case.

[0083] The PC5 interface for D2D may be designed for public safety WTRUs. Power consumption of public safety WTRUs may not be a major concern. D2D technology for IoT and/or wearables may require power savings enhancements for the PC5 interface.

[0084] For a wearables use case, a wearable device may be considered in coverage of the eNB and/or the D2D link may be utilized for power savings purposes. The wearables use case may be different from the R13 relay assumption, where the D2D link may be used to address a loss of connectivity with the eNB by the remote WTRU. The connection and/or coverage assumptions for the wearables and IoT relays may be different than those for R13 D2D relays (e.g., leading to different assumptions related to connectivity and access).

[0085] Power savings may be required for the D2D link to support low power operation. Access and/or connection control may be needed to ensure eNB control and/or low power operation.

The WTRU in IDLE and/or CONNECTED mode may be reconsidered when the remote WTRU is connected to the relay WTRU (e.g., depending on the routing assumptions described herein).

[0086] The embodiments described herein may be for the case of two or more WTRUs communicating using D2D under the control of an LTE network. The embodiments described herein may be applicable to future 5G RAT. For example, eNB in this disclosure may refer to a cell, a transmission/reception point (TRP), and/or an equivalent network control point in 5G.

[0087] The D2D link described herein and/or the associated embodiments may be applicable to

PC5 (i.e. the traditional LTE D2D link) and to other technologies such as non-3GPP technologies which are part of the LTE SI, as well as future device to device communication techniques for

5G, including both 3GPP-based and non-3GPP based. [0088] Power savings over PC5 may be provided while in connected mode. Power savings may be provided without eNB involvement. For example, power savings may be provided for the PC5 interface between two WTRUs communicating in D2D. The power savings may be provided for the case where one of the WTRUs is a remote WTRU and the other is a relay WTRU in the context of relay connection (e.g., in the wearables or IoT scenario).

[0089] A D2D WTRU autonomous PC5-based DRX method may include a WTRU providing DRX information to other WTRUs it may communicate with via D2D. A WTRU may autonomously determine to move to DRX mode with respect to PC5 communications. The WTRU may move to power saving mode. The WTRU may not be required to decode any SA messages on the receive pools it is configured with. The WTRU may autonomously move to DRX mode when the WTRU has not received any scheduling assignments (SAs) over a configurable period of time. The configurable period of time may be configured by the network in terms of frames, subframes, SA periods, and/or absolute time. The WTRU may autonomously move to DRX mode when the WTRU has received less than x SAs over a configurable period of time. The number of SAs "x" may also be configurable. The configurable period of time may be based on a number of frames, subframes, SA periods, and/or absolute time. The WTRU may autonomously move to DRX mode when the WTRU has not transmitted any messages over PC5 in a configurable period of time. The configurable period of time may be configured by the network in terms of frames, subframes, SA periods, and/or absolute time. The WTRU may autonomously move to DRX mode when the WTRU has transmitted less than y messages over a configurable period of time. The WTRU may autonomously move to DRX mode when the WTRU has no data available for transmission on PC5 on at least one of its configured PC5 logical channels. The WTRU may autonomously move to DRX mode when the WTRU has detected that the PC5 medium is busy or that the transmission priority of its own transmissions is lower than the priority of any ongoing transmissions by other WTRUs for a configurable period of time.

[0090] A WTRU may indicate a decision to move to DRX mode. For example, the WTRU may indicate to one or more other WTRUs and/or to the eNB that it is moving to DRX mode (e.g., so that potential transmitters are aware of the DRX state of the WTRU).

[0091] The WTRU may send a DRX indication message to one or more (e.g., all) of the WTRUs. The WTRU may send the DRX indication message using a multicast and/or broadcast address/L2 ID/ProSe ID or a similar identifier. Such an identifier may be negotiated and/or configured prior to establishing the communication on PC5. [0092] The WTRU may send the DRX indication message individually to each of the WTRUs it is in communication with over PC5.

[0093] The DRX indication message may be sent using a certain type of SA message. The DRX indication message may be encoded as part of the SA message. For example, the SA may include a certain T-RPT pattern which indicates the transmission of the DRX indication message. The source of the transmission may be identified by the LI address transmitted as part of the SA. Different TRPT patterns may be reserved to send the information in the DRX indication message. The information within the DRX indication message may be included as part of the data portion of the transmission. A T-RPT (e.g., a fixed and/or pre-known T-RPT) may indicate which resources the information within the DRX indication message is located in.

[0094] The DRX indication message may be sent using a PHY layer channel. The DRX indication message may be transmitted on a new PHY layer channel. For example, one or more specific resources within the SA and/or Data pools may be reserved for control information transmitted by the WTRU.

[0095] The DRX indication message may be sent in the SL-BCH. For example, the DRX indication message may be sent by the WTRU in the SL-BCH as part of the SL-MIB.

[0096] The DRX indication message may be sent using a MAC control message. For example, the DRX indication message may be transmitted in the MAC PDU as a control message. The control message may be added to the D2D MAC layer which can be added to the MAC PDU. The control message may include (e.g., as part of its payload) the information within the DRX indication message.

[0097] The DRX indication message may be sent in the payload of the transmitted data. For example, the DRX indication message may be sent within one of the MAC SDUs. The DRX indication message may be interpreted by one or more upper layers (e.g., the RRC layer). The

MAC SDU may be tagged with a logical channel associated with RRC-related data.

[0098] The DRX indication message may indicate an amount of time (e.g., in seconds, frames, subframes, and/or SA periods) in which the sending WTRU will be in DRX mode, and hence unreachable. The DRX indication message may include one or more special SA resources for

DRX monitoring. For example, the DRX indication message may indicate one or more specific resources to use to wake up the WTRU sending the DRX indication message. A WTRU in DRX may wakeup (e.g., only) to monitor one or more specific D2D resources (e.g., such as SA and/or data) rather than an entire pool of resources. The WTRU may (e.g., prior to moving to DRX) indicate to the one or more other WTRUs which resources that may be used to communicate with the WTRU while it is in DRX. The DRX indication message may indicate one or more specific conditions of the DRX (e.g., whether the DRX is continued or interrupted) if the WTRU in DRX transmits a message to the WTRU that receives the DRX indication message. For example, the WTRU transmitting the DRX indication message may indicate that it will interrupt DRX mode if a transmission is required prior to the end of the DRX/power saving period. The DRX indication message may indicate a DRX period that corresponds to the future expected wakeup times of the WTRU. For example, the WTRU may send a DRX period of N SA periods, which may indicate that the first wakeup time for the WTRU corresponds to N SA periods after the current SA period.

[0099] A second WTRU may receive a DRX indication message sent by a first WTRU. Upon receiving the DRX indication message, the second WTRU may buffer any traffic destined to the first WTRU. The second WTRU may buffer the traffic for a period of time. The period of time may be determined based on the contents of the DRX indication message. The period of time may be predetermined (e.g., statically configured and/or configured by the network).

[0100] The second WTRU may send an SA to the first WTRU using the resources indicated by the DRX indication message. The resources indicated by the DRX indication message may be used for a first SA transmission to the second WTRU. Subsequent resource transmissions may utilize any resources in the transmit pool of the first WTRU.

[0101] A first WTRU may perform DRX until expiration of an absolute wakeup time. DRX in a D2D communication may include one or more absolute wakeup times which are known to one or more WTRUs (e.g., all WTRUs). For example, the first WTRU may determine to autonomously perform DRX for a period of time. The period of time may expire at an absolute wakeup time. The first WTRU may not transmit any DRX indication message. A second WTRU, which is transmitting to the first WTRU, may determine that it cannot reach the first WTRU based on a fixed schedule of wakeup times, which may be known by one or more, or all, WTRUs. The fixed schedule may be static or configured by the network. The fixed schedule may be based on identification of the frame, subframe, and/or scheduling period. The absolute wakeup times may be the same for one or more, or all, WTRUs performing D2D communication and may be associated with a specific WTRU. For example, a WTRU may receive the absolute wakeup times for DRX from system information received from the eNB.

[0102] The absolute wakeup times may be preconfigured in the WTRU. For example, a WTRU which is out of coverage may be preconfigured to use a set of absolute wakeup times. The set of absolute wakeup times may be referenced to a time reference transmitted by one of the D2D WTRUs in the D2D synchronization channel. [0103] A WTRU may receive its absolute wakeup times from the eNB via dedicated signaling. The set of absolute wakeup times may be specific to a peer D2D WTRU. For example, a WTRU may receive a set tUl l, tU12, tU13... , etc., of scheduled wakeup times to be used for communications with WTRU1, and a set tU21, tU22, tU23... , etc., of scheduled wakeup times to be used for communications with WTRU2.

[0104] Scheduling periods may be identified similar to a frame, such that the DRX period or power savings mode may be defined in terms of a number of scheduling periods.

[0105] A WTRU's scheduled wakeup times may be defined as one in N subframes. A WTRU's scheduled wakeup times may be defined as one in N D2D subframes. A WTRU's scheduled wakeup times may be defined as one in N SA periods. A WTRU may monitor for SCIs on (e.g., only on) one out of every SA periods associated to one or more reception pools.

[0106] With a fixed or absolute schedule of wakeup times, the first WTRU may go to DRX at a particular time instant which depends on one or more traffic related triggers described herein. The first WTRU may wakeup at a specific time which is determined by the configuration of the network (e.g., a fixed SA number). Following the wakeup at this specific time instant, when the conditions to move to autonomous DRX are again satisfied, the first WTRU may again move to DRX and wakeup at the next absolute time instant for wakeup.

[0107] DRX based on absolute wakeup times may allow a WTRU, which may be in D2D communication with multiple WTRUs, to have a guaranteed availability or reachability time (e.g., regardless of the traffic characteristics with a specific WTRU).

[0108] A transmitting WTRU may be in communication with a receiving WTRU. The receiving WTRU may move to DRX. DRX may be based on absolute wakeup times.

[0109] The transmitting WTRU may assume that the receiving WTRU is accessible when the time between transmissions from the transmitting WTRU does not exceed a predefined time interval (e.g., in subframes, frames, or SA periods). The predefined time interval may be a guaranteed awake period.

[0110] If the time between successive transmissions exceeds the guaranteed awake period, the transmitting WTRU may not transmit any pending traffic to the receiving WTRU. The transmitting WTRU may buffer the traffic until the next absolute wakeup time of the receiving WTRU.

[0111] The transmitting WTRU may determine whether to send pending data to the receiving

WTRU based on whether an acknowledgement has been received. If data is pending for transmission to the receiving WTRU and the time since the last transmission by the transmitting

WTRU exceeds the guaranteed awake period, the transmitting WTRU may send the pending data. If an ACK or a NACK is not received by the receiving WTRU, the transmitting WTRU may buffer retransmissions and/or new transmissions until the next guaranteed wakeup period.

[0112] The transmitting WTRU may determine whether there are any D2D messages destined to and/or from the receiving WTRU based on the SA associated with transmissions by the receiving WTRU or transmissions by WTRUs other than the receiving WTRU. If the transmitting WTRU has data pending for the receiving WTRU, and if the time since the last transmission by the transmitting WTRU, another WTRU, or the receiving WTRU exceeds the guaranteed wakeup time, the transmitting WTRU may buffer the traffic until the next absolute wakeup time.

[0113] The absolute time instants for wakeup of any given WTRU may be fixed. The absolute time instants for wakeup may be the same for one or more, or all, WTRUs performing D2D under the control of an eNB.

[0114] A first WTRU may be configured with a dedicated schedule of absolute wakeup times. The first WTRU may exchange its absolute wakeup times with a second WTRU which it may communicate with. For example, the first WTRU may periodically transmit its scheduled absolute wakeup times in discovery messages. As another example, the first WTRU may provide its schedule of absolute wakeup times as part of PC5 signaling for one-to-one communication establishment or similar communication establishment (e.g., as part of connection establishment between a remote WTRU and a relay WTRU). As another example, the first WTRU may periodically broadcast its absolute wakeup times on the SL-BCH. The second WTRU may send its absolute wakeup times to the first WTRU, for example, as described herein.

[0115] A WTRU may determine a schedule of wakeup times from the eNB. For example, the WTRU may transmit a SidelinkUEInformation message to the eNB. The

SidelinkUEInformation message may include an identification of the one or more WTRUs it wishes to perform D2D communication with. The eNB may provide a resource configuration for communication with the one or more WTRUs (e.g., the TX pools). The eNB may provide the absolute wakeup times for the one or more WTRUs. The eNB may indicate the absolute wakeup times for the one or more WTRUs in the RRC Configuration of a transmitting WTRU (RRCConnectionReconfiguration).

[0116] A WTRU configured with DRX (for example, based on absolute wakeup times, or based on wakeup times relative to the sending of the DRX indication message), may perform one or more of the following. A WTRU configured with DRX may be associated with one or more

DRX Trigger conditions. DRX may be triggered if the WTRU does not receive any messages on the SL-SCH and/or the WTRU does not transmit any messages on SL-SCH for a number N of consecutive scheduling periods. A WTRU may receive an indication from the network (e.g., on PC5) to move to DRX. While in DRX, a WTRU may monitor SL-SCH for SCI from other WTRUs only once every M SA periods. The value of M may correspond to the DRX cycle configured on the SL-SCH. The SA periods in which the WTRU decodes the SCI may correspond to the absolute wakeup times configured in the WTRU. The SA periods in which the WTRU decodes the SCI may correspond to SA periods separated by M (e.g., starting from the transmission of the DRX indication message by the WTRU).

[0117] While in DRX, if the WTRU decodes the SCI with a destination ID of interest for the SCI, the WTRU may receive from the SL-SCH for the associated SC period and the WTRU may continue to decode SCI for the next P consecutive SA periods or until the occurrence of P SA periods without having decoded a message on the SCI.

[0118] Following P consecutive SC periods without any successful SCI decodings, a WTRU may move back to DRX.

[0119] A WTRU in DRX may cancel DRX as a result of any transmissions it makes over the SL-SCH. For example, the WTRU may monitor SL-SCH on one or more, or all, SA periods following its transmission, and may move (e.g., only move) back to DRX following a DRX trigger condition.

[0120] A WTRU may perform autonomous DRX on a per resource pool basis. For instance, the WTRU may be configured with multiple resource pools. The autonomous DRX embodiments described herein may be applied separately on one or more, or each, of the multiple resource pools. The WTRU may be configured with different parameters for one or more, or each, of the multiple resource pools. The different parameters may include the absolute wakeup times, the values of x and y used for triggering WTRU autonomous DRX, and/or whether a WTRU can trigger autonomous DRX for a specific pool or not.

[0121] If a WTRU is in autonomous DRX or power savings mode with a first resource pool and not in DRX or power savings mode with a second resource pool, the WTRU may be required only to decode the SA resources associated with the second resource pool (e.g., which it is not in DRX with). For example, if a WTRU is in DRX on N pools simultaneously, the WTRU may decode the SA for a pool at the time SA associated with the wakeup time for the pool. One or more, or all, other SAs associated with a pool which are not associated with the wakeup time for the pool are not decoded by the WTRU.

[0122] A WTRU may determine whether to perform autonomous DRX for one or more, or each,

WTRU of one or more WTRUs. The WTRU may perform DRX or move to power saving mode independently with respect to the transmissions of a specific D2D WTRU of the one or more WTRUs. The WTRU may be provided with the transmission pools of the WTRUs with which it may be communicating. The autonomous DRX embodiments described herein may be applied separately for one or more, or each, transmitting WTRU of the one or more WTRUs. The WTRU may be configured with different parameters for one or more, or each, transmitting WTRU. The different parameters may include the absolute wakeup times, the values of x and y used for triggering WTRU autonomous DRX, and/or whether a WTRU can trigger autonomous DRX for a specific transmitting WTRU.

[0123] A WTRU autonomous DRX (e.g., or a power-saving period) for a WTRU may be canceled when the WTRU has pending data for transmission. For example, the WTRU may cancel its DRX overall. The WTRU may cancel its DRX per resource pool. The WTRU may cancel its DRX per WTRU.

[0124] Cancellation of DRX may include one or more of moving out of DRX, transmitting the data that is pending for transmission, and/or starting the check for trigger conditions described herein for WTRU autonomous DRX.

[0125] The WTRU may cancel WTRU-autonomous DRX when data is available for transmission and/or when the destination WTRU of the transmission is not also in DRX.

[0126] The DRX and/or power-saving behavior of a WTRU may be controlled by one or more WTRUs. For example, the WTRU may be put into DRX as a result of a D2D message transmitted by at least one of the one or more WTRUs.

[0127] A first D2D-capable WTRU may transmit a DRX command to a second D2D capable WTRU via the PC5 interface. The WTRU may transmit the DRX command following the transmission of one or more, or all, pending packets in the buffers (e.g., RLC) associated with transmissions to the receiving WTRU. The WTRU may transmit the DRX command following the acknowledgement of the last packet transmitted for which the buffers associated with transmissions to the receiving WTRU are empty. The WTRU may transmit the DRX command following a trigger from one or more upper layers and/or the application layer. For example, the application layer service which may be communicating to a specific receiving WTRU may trigger transmission of the DRX command. The WTRU may transmit the DRX command following indication from the eNB for the DRX command. For example, the eNB may indicate to the relay WTRU to transmit a DRX command over PC5 to the remote WTRU. The WTRU may transmit the DRX command following receipt of a NAS-related message by the transmitting WTRU from the network.

[0128] A DRX command may be transmitted in accordance with the DRX indication message transmission embodiments described herein. [0129] A DRX command may be transmitted by the transmitting WTRU following termination of the transmission of a transport block over a predetermined scheduling period. For example, the transmitting WTRU may transmit a special signal and/or a PHY layer sequence in the resources used to transmit the data or transport block. The transmitting WTRU may transmit the DRX command in a signal included in one or more spare time and/or frequency resources that are not utilized to transmit the different HARQ retransmissions of a transport block.

[0130] The DRX command may be transmitted in one or more resources which are unused by the transmitting WTRU as a result of an acknowledgement, transmitted by the receiving WTRU, of a transport block.

[0131] A DRX command may include an amount of time for which the receiving WTRU may remain in DRX, one or more resources for wakeup monitoring, and/or a redirection of remote WTRU to the Uu interface.

[0132] The amount of time for which the receiving WTRU may remain in DRX may be indicated in seconds, frames, subframes, and/or SA periods on the PC5 interface.

[0133] The specific resources, resource pools, and/or timing of resources (e.g., over Uu or PC5) that the receiving WTRU may monitor to determine whether the receiving WTRU needs to come out of DRX. For example, the transmitting WTRU may indicate one or more specific PC5 resources that the receiving WTRU may monitor when determining whether to come out of DRX. In another example, the transmitting WTRU (e.g., a relay WTRU) may transmit the frame number and/or subframe number that the receiving WTRU may monitor PDCCH to determine whether to come out of DRX.

[0134] One or more specific actions may be performed by the receiving WTRU over the Uu interface. A DRX command may indicate, to the receiving WTRU, which of the one or more specific actions may be performed via the Uu interface. For example, a relay WTRU may transmit the DRX command to the remote WTRU. The DRX command may indicate that the remote WTRU may start or stop monitoring for system information over the Uu interface.

[0135] A first WTRU communicating with a second WTRU may move to DRX/power saving mode upon reception of the DRX command. The first WTRU may be in communication with multiple WTRUs. The first WTRU may move to DRX upon receipt of multiple coinciding DRX commands from the multiple WTRUs. For example, a receiving WTRU may receive a DRX command from the first WTRU and a second WTRU the receiving WTRU is communicating with during the same SA period. The first WTRU may indicate a first sleep time of x SA periods. The second WTRU may indicate a second sleep time of y SA periods. The receiving

WTRU may sleep for the shorter of the first sleep time and the second sleep time. [0136] A WTRU may only perform DRX when the WTRU has received a DRX command from one or more, or all, of the WTRUs it is communicating with in D2D. The WTRU may only perform DRX when the time periods indicated by one or more, or each, of the WTRUs has some overlapping component.

[0137] The transmitting WTRU of a DRX command may assume that the receiving WTRU moves to DRX following transmission of the DRX command. The transmitting WTRU may determine that the receiving WTRU is in DRX only after it receives a DRX indication message from the receiving WTRU.

[0138] A WTRU in DRX or power saving mode may stay in DRX until the reception of a wakeup signal and/or indication sent over PC5. The wakeup indication may be sent over a specific resource pool, time frequency resource, SA resource, and/or the like. For example, a WTRU may be configured to monitor a specific SA resource (e.g., a particular resource block pair) when it is in DRX or power saving mode. The specific SA resource to monitor may be configured by the network or statically preconfigured. The specific SA resource to monitor may be sent to the WTRU as part of the DRX command that moved the WTRU to DRX mode.

[0139] A specific resource (e.g., such as the specific SA resource described herein) which forces the WTRU to wakeup may be configured only on certain SA period identifications or values, on certain frames, subframes, and/or the like.

[0140] For example, a relay WTRU may configure one or more (e.g., all) its remote WTRUs with single resource for wakeup. The relay WTRU may wakeup the one or more remote WTRUs in DRX via the transmission of a single wakeup indication. A relay WTRU may configure a separate SA resource for signaling wakeup for one or more, or each, of its remote WTRUs. The separate SA resource may allow for waking up one particular remote WTRU (e.g., while the other WTRUs stay in power savings mode).

[0141] Multiple stage wakeup indication over PC5 may be provided. A WTRU in D2D communication may monitor a reserved SA resource and/or one or more RX pools of the reserved SA resource for a wakeup indication. A WTRU may send a wakeup indication using multiple separate signaling. The receiving WTRU may come out of DRX/Power saving mode when the signaling (e.g., some or all of the signaling) associated to wakeup is received by the receiving WTRU.

[0142] For two stage wakeup signaling, the first stage and/or second stage signaling may be transmitted over one or more of an SA resource, a dedicated time frequency resource in the scheduling period, a data resource indicated by a previous SA resource, and/or a resource over Uu from the eNB. [0143] For example, a specific SA resource may be associated with a wakeup indication. The specific SA resource may be used by multiple WTRUs transmitting D2D. Since collisions may occur because of multiple transmitting WTRUs using the same SA resource, a transmitting WTRU may perform scheduling on another SA resource (e.g., a resource that is part of the TX pool of the transmitting WTRU). A receiving WTRU in DRX, in this example, may perform one or more of the following.

[0144] The WTRU may wakeup at one or more, or each, occurrence of the reserved SA resource associated with a first level of wakeup signaling. If the wakeup signal has not been transmitted, the WTRU may return to DRX/power saving mode.

[0145] A WTRU may move from PC5 monitoring to PDCCH monitoring in response to an implicit indication (e.g., via a message) and/or following inactivity on one or more links. If the WTRU detects transmission of the wakeup signal on the reserved SA resource, the WTRU may monitor the receive pool and/or the transmit pool of the WTRU which transmitted the wakeup. The pool may occur during the same SA period. The pool may occur at a later SA period.

[0146] If the WTRU detects a message for the WTRU on the pool, the receiving WTRU may come out of DRX mode. If the WTRU does not detect a message for the WTRU on the pool, the receiving WTRU may return to DRX.

[0147] FIG. 3 depicts an example indication to start or stop PC5 monitoring. A PDCCH indication may be used to start and/or stop PC5 monitoring. A WTRU may receive an indication (e.g., the PDCCH indication) from the eNB to start and/or stop monitoring of PC5 for a D2D message sent over PC5. The indication may be received from the WTRU via one or more of a PDCCH message (e.g., such as a special DCI format, or an existing format that may have a different interpretation for a remote WTRU in DRX mode), a MAC CE transmitted by the eNB, and/or a RRC message (e.g., dedicated or broadcast signaling).

[0148] The PDCCH message or indication may include an indication to the WTRU to start or stop PC5 monitoring, a time at which PC5 may be monitored, one or more resources (e.g., carrier frequency, resource pools, resource elements, SA, etc.) that may be monitored, and/or a duration of time in which the monitoring may take place or continue (e.g., before the WTRU goes back to sleep).

[0149] For example, a remote WTRU may be in DRX/power saving state and may monitor only signaling from the eNB over IF3. The WTRU may be in regular operation. The WTRU may wakeup periodically to monitor PDCCH. After a wakeup period in which no activity on PDCCH is detected, the WTRU may move back to DRX or power saving state. During the wakeup period, the WTRU may receive a MAC CE indicating that the WTRU may monitor the PC5 resource pool for D2D messages intended for the WTRU in a subsequent subframe. The eNB may indicate the specific resources pool and/or the specific resources to be monitored. For example, the eNB may be aware of the resources that will be used, as the transmission may be a Mode 1 D2D transmission by the relay WTRU. When the eNB indicates the specific resources pool and/or the specific resources to be monitored, the remote WTRU might not monitor one or more, or all, resource pools when the specific resources are known - thus saving power.

[0150] A remote WTRU may be configured to receive control signaling over IF3 to indicate when monitoring of PC5 for data transmission is needed. The indication may be sent regularly (e.g., one indication per SA period which contains PC5 data for the WTRU). The indication may be sent at the beginning and/or end of a data burst expected on PC5.

[0151] A WTRU may be configured to move from the monitoring of a first link to the monitoring of a second link following inactivity on the first link. For example, a WTRU may move from monitoring of the PC5 link for SA messages to monitoring of the Uu link (e.g., as a result of inactivity on the PC5 link for several SA periods). The WTRU may move from monitoring of the Uu link to monitoring of the PC5 link following a number of subframes without any PDCCH messages intended for the WTRU. The inactivity time may be provided by the network through broadcast and/or dedicated signaling.

[0152] Moving from the monitoring of a first link to the monitoring of a second link may be extended to other non-3 GPP RATs (e.g., WLAN or Bluetooth) when the idle state WTRU having a direct link over non-3 GPP RAT may be able to move to the LTE RAT when there is data for the WTRU from the eNB. A WTRU may wake to monitor the PC5 link at specified time intervals when the WTRU is in idle mode. A remote WTRU may identify an indication on the PC5 link. The indication may be the result of an eNB informing the relay WTRU that it needs to contact the remote WTRU. The remote WTRU may transition to connected mode to receive the intended MT signaling and/or MT data from the eNB over the Uu link. The WTRU may go back to idle mode after the MT transaction and may continue monitoring the PC5 channel at the mentioned time intervals for MT messages. The remote WTRU might not monitor the resources on the Uu link (e.g., unless requested by the eNB through the relay WTRU).

[0153] A receiving D2D WTRU may receive, from an eNB, an indication of one or resources of a transmitting D2D WTRU. A start/stop indication may be used for purposes which include but are not limited to power savings. A first WTRU which receives D2D transmissions from a second WTRU may receive the specific resources that may be monitored to receive the D2D transmissions (e.g., directly from the eNB). A receiving WTRU may receive, from the eNB, one or more of the contents of the SA, the specific resource pool used by the transmitting WTRU (e.g., SA pool or data pool or both), or the specific TRPT pattern used by the transmitting WTRU.

[0154] A receiving WTRU may use information received from the eNB (e.g., contents of the SA, a specific resource pool used by a transmitting WTRU, and/or a specific TRPT partem used by the transmitting WTRU) to decode the D2D data channel and/or receive data from the transmitting WTRU. For example, the transmitting WTRU may be a relay WTRU while the receiving WTRU may be a remote WTRU behaving as a wearable or IoT device connected to a relay WTRU.

[0155] A remote WTRU may perform power efficient discovery and/or attachment. A remote WTRU may perform a network triggered discovery and/or relay connection. The remote WTRU may start the discovery and/or attachment procedure with a relay node following a trigger from the network. The remote WTRU may not be allowed to perform network discovery

autonomously (e.g., without receiving the trigger from the network).

[0156] A network-triggered discovery and/or attachment procedure may avoid power consumption of a WTRU autonomous decision of when to perform discovery, and with which devices. For example, the network may be in a better position to determine whether the WTRU is close to the relay. The network may determine whether the WTRU is close to the relay based on the camped cell or transmission point, location-based services provided by the network, and/or the like. For example, the network may determine, based on one or more tracking area updates sent by the WTRU in idle mode, that the WTRU is in proximity of a relay, and may transmit paging to the WTRU to initiate relay discovery.

[0157] The remote WTRU may receive a network triggered discovery while connected through an RRC command indicating to start such network discovery.

[0158] The RRC command may indicate the RAT which may be used for discovery (e.g., PC5, WiFi, Bluetooth). For example, the network may prioritize one type of connection over another. The connection priority may depend on the capability, relay capability, and/or proximity to a relay of the WTRU.

[0159] The RRC command may indicate RAT specific information required to start or trigger the discovery. The RAT specific information may include the WiFi or Bluetooth channel, a specific technology, one or more security parameters, and/or authentication information (e.g., passwords).

[0160] The RRC command may indicate one or more resources and/or resource pools to use for discovery. The one or more resources and/or resource pools may be a subset of the resource pools used by the WTRU for PC5 discovery for purposes other than relay discovery. [0161] The RRC command may indicate an identification of the relay WTRUs. Such identification may include the D2D L2 ID of the relay WTRU, Bluetooth or WiFi specific identifier (such as SSID), and/or the like.

[0162] The RRC command may indicate a transmit power to use for discovery.

[0163] The RRC command may indicate one or more PHY layer transmission characteristics of the discovery signals for which the remote WTRU may limit its measurements to.

[0164] A WTRU may receive a new paging message that initiates a discovery and/or connection establishment with a relay WTRU.

[0165] A WTRU may receive a new paging message which initiates a discovery process and/or a connection establishment with a specific relay WTRU. Receiving the network triggered discovery and/or connection while in idle mode via a paging message may allow a WTRU to have its relay connection controlled by the network (e.g., without any additional signaling and power consumption from the remote WTRU).

[0166] Paging may be used to initiate discovery. For example, a WTRU in idle mode may receive a paging message which initiates a discovery procedure. The paging message may include a discovery command. The paging message may include the discovery resources to be used by the WTRU to perform discovery. The WTRU may receive, in the paging message, the radio interface to use when the discovery will be performed on a non-3 GPP interface (e.g., Bluetooth, Wifi, etc.) and/or the specific channel on which to perform discovery. The WTRU may perform discovery while remaining in IDLE mode. The WTRU may initiate a connection establishment based on receipt of the paging message. The WTRU may receive the discovery command and associated discovery resources and/or information during or following connection establishment.

[0167] A WTRU may perform discovery for a finite period of time. The discovery time period may be configured by the network apriori, known by the WTRU (e.g., statically configured), and/or provided in the paging message. A WTRU may consider the discovery process completed upon the expiry of the discovery time period. A WTRU may consider the discovery process completed upon having found one or more suitable relay WTRUs. A WTRU, following completion of the discovery, may send a connection establishment, RACH message, or similar message to the network as a result of the occurrence of one or more of the following. The

WTRU may send a connection establishment, RACH message, or similar message to the network when the WTRU completes the discovery procedure. The WTRU may send a connection establishment, RACH message, or similar message to the network when the WTRU completes the discovery procedure and has found at least one suitable relay. A suitable relay may be defined as a relay whose measurements exceed a threshold. A suitable relay may be defined as a relay whereby the Uu measurements of the relay with the eNB exceed a threshold. A suitable relay may be defined as a relay that provides the specific service required by the WTRU initiating the discovery. The WTRU may send a connection establishment, RACH message, or similar message to the network when the WTRU completes the discovery procedure and has found a suitable relay whose measurements are better than the current relay the WTRU is connected to (e.g., measurements exceed the current relay by a threshold amount).

[0168] A connection establishment message, RACH message, or similar message, sent by the WTRU may include the results of the discovery process. For example, the connection establishment message, RACH message, or similar message, may include an identification of the relay WTRUs found during the discovery procedure (e.g., ProSe WTRU ID of the relay, C-RNTI of the relay, Bluetooth identification of the relay, etc.). The connection establishment message, RACH message, or similar message, may include one or more measurements of the relay WTRUs (e.g., over the relay link and/or over the Uu link). The connection establishment message, RACH message, or similar message, may include a list of services provided by the relay WTRU. The connection establishment message, RACH message, or similar message, may include buffer status, load, and/or related measurements of the discovered relay WTRU.

[0169] A WTRU may, as a result of transmission of the connection establishment message, remain in IDLE mode. The WTRU may receive further instructions from the eNB during the connection establishment procedure which cause the WTRU to start another discovery process and/or initiate a connection with a specific relay WTRU (e.g., either selected by the remote WTRU or identified by the network).

[0170] For example, the network may determine, based on tracking area updates sent by the WTRU in IDLE mode, that the WTRU is in proximity of a relay. The network may transmit the paging message to the WTRU to initiate relay discovery.

[0171] The network may determine when to trigger discovery based on relative location information of the relay WTRU and the remote WTRU. The relative location information may be provided by a location service in the network. For example, the network may trigger a discovery procedure if the two devices are within a predetermined distance (e.g., x meters) of each other for a certain period of time. The network (e.g., the eNB) may be periodically informed of the location of one or more, or each, WTRU.

[0172] A WTRU in IDLE mode that receives a paging message may initiate a connection establishment with a relay WTRU (e.g., as a result of the reception of a paging message). A paging message may include a connection command itself. A paging message may include an identification of a relay WTRU to which the connection may be established, for example, the relay WTRUs ProSe L2 ID, or an index identifying the WTRU from a list of discovered candidate WTRUs. A paging message may indicate PC5 resources, such as TX or RX resource pool(s) used to establish connection with the relay WTRU.

[0173] When a connection with a relay WTRU has been established, a WTRU may continue to remain in IDLE mode with the eNB. The WTRU may assume an associated state with the relay WTRU and may perform any procedures related to an associated state as described herein.

[0174] A WTRU may receive paging which initiates a relay connection specifically while having an association with a relay WTRU, but while not having an active connection with the relay WTRU. Specifically, a remote WTRU may initiate a connection with a specific relay WTRU that is known to the remote WTRU while in IDLE mode. Knowledge of the remote WTRU may be result from a previous connection with a relay WTRU, a predefined association, a semi-static association configured by the network, and/or a relay selection performed by the remote WTRU based on measurements made from discovery.

[0175] A remote WTRU (e.g., a wearable or IoT device) may regularly perform discovery and/or relay selection and may maintain a best relay for connection. During relay selection and/or maintenance, the remote WTRU may inform the network of a currently selected best relay WTRU. Upon reception of the paging message from the network, the remote WTRU may initiate a connection with the currently selected best relay WTRU.

[0176] A WTRU may provide the network with a list of authorized relay devices that the WTRU may connect to as a remote WTRU. The list may be determined by the application layer of the WTRU, the ProSe layer of the WTRU, and/or the like. The list may be determined based on the RAT(s) that the remote WTRU may use for the D2D connection. For example, for a Bluetooth link, the Bluetooth software may provide one or more lower layers of the WTRU with the list of devices that the remote WTRU has previously connected to or authenticated with. The WTRU may send, to the network, the list of devices that the remote WTRU has previously connected to or authenticated with. The WTRU may provide the list in RRC signaling. The WTRU may send the list to the network upon initial connection establishment with the network. The WTRU may send an updated list periodically. The WTRU may send the updated list when the list has been changed based on changes in the application layer rules, new connection status, and/or updated software.

[0177] A list of pre-connected relay devices may be generated by the WTRU (e.g., based on prior relay connections). For example, the WTRU may be configured with a time interval of interest. The WTRU may determine a list of pre-connected relay devices by maintaining the relay devices which the WTRU has established a relay connection with over the time interval of interest. The WTRU may restrict the list to include only devices where the relay connection had a duration that exceeds a predetermined time interval.

[0178] A remote WTRU may receive a set of relay WTRU identifiers. The remote WTRU may perform and/or maintain one or more measurements from the discovery only on the WTRUs which match the received identifiers. For example, the WTRU may only perform L3 filtering and/or measurements on discovery messages sent by a relay WTRU with a specific L2 ID.

[0179] A remote WTRU may limit measurements to relay WTRUs which have a specific PHY layer characteristic, signature, transmission structure, and/or the like. Such PHY layer characteristics may have been configured by the eNB and may be used to avoid measurements of relay WTRUs not in close proximity of the remote WTRU. For example, a location of one or more reference signals transmitted by the relay WTRU may be used to determine whether to measure the discovery transmissions of a specific relay WTRU.

[0180] Discovery may be triggered by proximity. Discovery may be triggered by the application layer. For example, a remote WTRU may be triggered by the application layer, or an application in the core network, to request to the network to start a discovery. Discovery may be triggered when the location service determines that the devices (e.g., the remote WTRU and the relay WTRU) are in close proximity, for example.

[0181] The application layer in the remote WTRU, upon reception of a trigger from the application server, may trigger a request to the eNB in the AS to start a discovery. The request may be sent by the WTRU using RRC messaging. The request may include one or more of a discovery type, an identity or identities of the relay WTRUs which it may use to perform discovery with, and/or a RAT, or preferred RAT for the eventual link (e.g., PC5, Bluetooth) [0182] The network may permit the WTRU to initiate discovery based on the request. The WTRU may receive any parameters indicated in the discovery command from the network's response. The WTRU may be restricted from performing the discovery. The WTRU may be provided with one or more alternate relay WTRUs, an alternate discovery type, and/or one or more alternate RATs on which to perform discovery.

[0183] A data and/or control path may be received as a result of a connection establishment.

Bearer information may be received as a result of a connection establishment. A WTRU which performs connection establishment may have its path for control and/or data provided by the network (e.g., at the completion of the connection establishment). The path for control and/or data may include the route (e.g., Uu or PC5) in which the remote WTRU may transmit and/or receive data, the route (e.g., Uu or PC5) in which the remote WTRU may transmit/receive control information, and/or the route in which system information may be obtained by the remote WTRU.

[0184] A WTRU may perform connection establishment of the D2D link upon selection of the relay WTRU. The connection establishment may be performed by the associated RAT. For example, for PC5, the ProSe layer may trigger a connection establishment using PC5 signaling. For Bluetooth, the Bluetooth connectivity software may trigger the connection establishment on the underlying RAT.

[0185] Upon a successful connection by the associated application and/or management layer described herein, the WTRU may trigger an indication to the eNB to inform it of the successful connection. The indication may be sent via RRC. The indication may include an identity of the relay WTRU with which the connection was made and/or a RAT of the link (e.g., PC5,

Bluetooth).

[0186] The WTRU may, following transmission of the indication, or reception of

acknowledgment from the eNB, modify its behavior over Uu according to the new (e.g., fresh) paths for data and/or control. The WTRU may receive the specific behavior from the eNB in the acknowledgement. For example, a first remote WTRU may be indicated, from the eNB, to receive some or all DL traffic (control and Data) over IF2. The first remote WTRU may send some or all UL traffic (control and data) over IF3. A second remote WTRU may be indicated to TX and RX data over IF2 and/or control over IF3.

[0187] A WTRU may receive bearer related information (e.g., following connection

establishment). The bearer related information may be applied on the PC5 link with a relay WTRU. The bearer related information may include the UEBearerList, a list of DL bearers, and/or one or more associated QoS parameters.

[0188] A remote WTRU may maintain a configuration of its radio bearers over Uu and may have the radio bearers configured to go through the relay WTRU. The relay WTRU may be informed of the configuration.

[0189] FIG. 4 depicts an example radio bearer and logical channel handling. When connection is established between a remote WTRU and a relay WTRU, the remote WTRU may maintain one or more (e.g., all) established radio bearers (DRB/SRB). The remote WTRU may modify one or more underlying transport mechanisms so that the one or more established radio bearers are routed via the relay WTRU.

[0190] During connection establishment, the relay WTRU may be provided, by the eNB and/or the remote WTRU, with the radio bearer configuration of the remote WTRU. The radio bearer configuration may allow the relay WTRU to properly forward a message intended for the remote WTRU over PC5 in the appropriate manner (e.g., the required QoS).

[0191] A relay WTRU may create a set of logical channels over PC5 (e.g., upon connection establishment with the remote WTRU). The creation of the set of logical channels may use the information related to the radio bearers which were currently in use or being used by the remote WTRU to communication over IF3.

[0192] The relay WTRU may receive the information of the radio bearers that were in use by the remote WTRU (e.g., in order to establish the PC5 logical channels). The radio bearer information may be the UEBearerList associated with the context of the remote WTRU. The radio bearer information may include one or more of a logical channel ID of the radio bearer, a logical channel group ID associated with one or more, or each, logical channel, and/or one or more QoS parameters associated with the bearer (e.g., such as, TFT, max bit rate, guaranteed bit rate, HARQ usage, etc.).

[0193] The relay WTRU may receive the radio bearer information from the network. Following connection establishment and/or acknowledgement of the connection with the remote WTRU by the network, the relay WTRU may receive the information from the eNB via RRC signaling. The relay WTRU may receive the information following a request made to the eNB after connection establishment with the remote WTRU. For example, the application layer and/or ProSe layer in the relay WTRU may trigger the relay WTRU to send a request to the network for the radio bearer information. The request may be sent by RRC and may include the identity of the remote WTRU. The relay WTRU may receive the radio bearer information of the remote WTRU from the remote WTRU (e.g., following connection establishment). The radio bearer information may be received by the remote WTRU after the connection establishment.

[0194] The relay WTRU may create a set of logical channels based on the radio bearer information of the remote WTRU. The relay WTRU may create a single logical channel for one or more, or each, of the radio bearers. The relay WTRU may create one logical channel for several radio bearers having similar QoS parameters.

[0195] A relay WTRU may assign the same logical channel IDs and/or logical channel group

IDs to the PC5 logical channel as the remote WTRU logical channel IDs. The remote WTRU may create a list of logical channels. The remote WTRU may maintain the associated mapping when it relays data from a remote WTRU logical channel to a PC5 logical channel.

[0196] A relay WTRU may receive signaling from the network on how to map the radio bearers to the created PC5 logical channels. The received signaling may include a logical channel ID to assign to one or more, or each, PC5 logical channel, a mapping to the remote WTRU logical channel, and/or a mapping of one or more PC5 Logical Channels to a logical channel group ID (e.g., to use for BSR).

[0197] The remote WTRU may create a set of logical channels (e.g., as described herein for the relay WTRU) for PC5 communication based on uplink logical channel information of the remote WTRU.

[0198] A remote WTRU may receive some or all RRC messaging directly from the relay WTRU when it is connected to the relay. The remote WTRU may be configured to receive the RRC messaging via a set of dedicated D2D resources reserved specifically for RRC signaling. The remote WTRU may be configured to receive the RRC messaging via a dedicated and/or high priority pool.

[0199] The relay WTRU may be configured to forward some or all RRC messaging (e.g., associated with a remote WTRU SRB) received from the eNB that is intended for the remote WTRU. The relay WTRU may be configured to forward the RRC messages over a pool dedicated for RRC signaling. The relay WTRU may be configured to forward the RRC messages over the pool of resources associated with the highest priority.

[0200] A WTRU Associated state may be provided. A remote WTRU connected to a relay may maintain a Uu connection. The remote WTRU may monitor the PDCCH using a reduced and/or modified set of rules for when (e.g., related to an SA period) and how (e.g., via reduced DCI decoding) PDCCH is decoded. A remote WTRU may maintain its RRC CONNECTED state with the eNB when the remote WTRU becomes connected with the relay WTRU (e.g., following access procedures). In the RRC_CONNECTED state, one or more procedures related to the RRC CONNECTED state may be changed as a result of the presence of the relay connection. For example, one or more RRC CONNECTED mode procedures may be disabled (e.g., stopped, interrupted, and/or replaced) by equivalent procedures with the relay node (e.g., over PC5) when the remote WTRU is connected to the relay. The one or more RRC CONNECTED mode procedures may include an uplink timing advance, a power headroom reporting, a Uu-based DRX, a buffer status reporting on Uu, and/or a transmission of SRS, CQI, RI, etc.

[0201] The WTRU may maintain its RRC CONNECTED state perhaps for example as long as the WTRU has active traffic with the network. The active traffic may be sent over PC5 and/or Uu.

[0202] A remote WTRU may be in an associated state when it is considered RRC IDLE from the network perspective, but the remote WTRU may maintain a connection and/or pairing with a relay WTRU. A remote WTRU may be considered in an associated state while the remote

WTRU maintains an RRC connection, for example, from the network perspective. A remote WTRU in an associated state may exhibit behavior with respect to the Uu interface which is different than its behavior in an IDLE state and/or a RRC CONNECTED state, but the remote WTRU may be considered as RRC IDLE and/or as RRC CONNECTED while in this state. In the terminology which follows, the associated state may refer to the state of the remote WTRU, and its behavior with respect to the Uu interface, while the association may refer to the connection with the relay WTRU, for example.

[0203] A remote WTRU to a relay WTRU connection and/or association may be based on one or more of the following.

[0204] A remote WTRU may have a one-to-one connection and/or a similar active PC5 connection with a relay WTRU. For example, the remote WTRU and the relay WTRU may monitor the PC5 interface sidelink control information (SCI) which may be transmitted by the other WTRU.

[0205] The remote WTRU and/or the relay WTRU may be paired with each other from the perspective of a non-3GPP RAT. For example, the remote WTRU and relay WTRU may have a Bluetooth pairing and/or may be authenticated or associated from the point of view of a WiFi connection.

[0206] The remote WTRU and/or the relay WTRU may have an inactive PC5 connection. The remote WTRU and/or the relay WTRU may have a PC5 connection which is being monitored according to the PC5 DRX rules described herein.

[0207] The remote WTRU and the relay WTRU may not have an active connection, but may be able to establish an active connection on demand. For example, the remote WTRU and/or the relay WTRU may perform periodic measurements of the relay WTRU and/or the remote WTRU, for example, using discovery messages. A relationship of trust between the remote WTRU and the relay WTRU may be established through a pre-configuration, a network configuration, a previous successful connection establishment and authentication, and/or the like.

[0208] A remote WTRU (e.g., an RRC connected remote WTRU) may receive an RRC

Connection Release message or a similar message while connected with a relay WTRU. The remote WTRU may move to an associated state where a connection is maintained with the relay WTRU.

[0209] A RRC CONNECTED remote WTRU may move to an associated state while maintaining the RRC CONNECTION upon establishment of a relay connection and/or upon indication to the network that a relay connection was established. The associated state may be associated with a remote WTRU in idle mode and/or in RRC Connected mode (e.g., with respect to the network). [0210] The associated state may be characterized by the remote WTRU, in idle mode, continuing to maintain DL synchronization with the eNB at the idle mode wakeup times and/or read system information. The associated state may be characterized by the remote WTRU continuing to maintain DL synchronization, in idle mode or connected mode, with the eNB while relying on the relay WTRU to receive system information. The associated state may be characterized by the remote WTRU monitoring the PC5 interface and/or a non-3GPP link for DL data from the network and the remote WTRU transmitting UL (e.g., some or all UL) data over the PC5 interface, the non-3GPP link, and/or the Uu interface. The associated state may be characterized by the remote WTRU transmitting tracking area updates via the relay WTRU. The associated state may be characterized by the remote WTRU, in connected mode, transmitting UL data over the PC5 interface and/or the non-3GPP link. The associated state may be characterized by the remote WTRU, in connected mode, receiving DL data via the PC5 interface, the non-3GPP link, and/or the Uu interface. The associated state may be characterized by the remote WTRU, in idle mode or connected mode, stopping monitoring the PDCCH from the eNB.

[0211] The associated state may be characterized by the remote WTRU monitoring the PDCCH from the eNB only at times associated with a fixed subset of subframes (e.g., such as according to a DRX inactivity time, an idle mode wakeup time, and/or a new period defined for monitoring PDCCH from the eNB while in the associated state). The idle mode wakeup time may be defined by a network configuration (e.g., such as in system information and/or dedicated RRC signaling). The remote WTRU, in connected mode, may start monitoring the PDCCH from the eNB upon connection to the relay WTRU and/or upon indication by the WTRU to the network that the connection to the relay WTRU has been established. The associated state may be characterized by the remote WTRU, in idle mode, performing a subset of normal IDLE mode procedures over IF3 (e.g., such as cell reselection and/or cell measurements). The associated state may be characterized by the remote WTRU, in idle mode or connected mode, performing one or more measurements of one or more relays (e.g., the relay WTRU to which it retains association). The associated state may be characterized by the remote WTRU, in idle mode or connected mode, receiving paging over the PC5 interface and/or over the Uu interface. When the remote WTRU receives paging over the PC5 interface only, one or more procedures related to reading the paging channel (PCH) may no longer be performed with the eNB in the associated state.

[0212] The associated state may be characterized by the remote WTRU, in idle mode or connected mode, performing one or more measurements of one or more relay WTRUs (e.g., a currently associated relay WTRU and/or one or more other relay WTRUs). The associated state may be characterized by the remote WTRU, in idle mode or connected mode, performing reselection from one relay WTRU to another relay WTRU. The associated state may be characterized by the remote WTRU, in idle mode or connected mode, performing discovery with one or more other relay WTRUs (e.g., other than the currently associated relay WTRU). The remote WTRU, in idle mode or connected mode, may perform discovery with the other relay WTRUs based on a determination that the one or more measurements of the relay WTRU are below a predefined and/or configured threshold.

[0213] A remote WTRU (e.g., an RRC connected WTRU) may be in an associated state when it has a connection and/or an association with a relay WTRU. The remote WTRU may be placed in the associated state when it receives an RRC message from the eNB while connected to the relay WTRU. The RRC message may be an RRCConnectionRelease message or a similar message. The remote WTRU may, in the associated state, receive system information and/or transmit/receive data directly from the relay WTRU. While performing TX/RX with the relay WTRU, the remote WTRU may maintain (e.g., periodically maintain) synchronization with the eNB (e.g., to maintain timing for the D2D channel and/or prepare for any UL transmissions required directly to the eNB via the normal connection establishment). The remote WTRU may receive system information related to connection establishment parameters (e.g., such as RACH preamble, etc.) from the relay WTRU.

[0214] A WTRU may be placed in an associated state and may maintain a connected state with the eNB. A WTRU in associated state and/or having established a connection with a relay may perform one or more of the following connected mode procedures or behavior with the eNB.

[0215] A WTRU in associated state and/or having established a connection with a relay may monitor PDCCH for DCI format 5 only. If the WTRU is configured with Mode 1

communication on the sidelink, the WTRU may decode only DCI Format 5 messages (e.g., or any DCI formats which may contain only D2D scheduling information) from the eNB for potential sidelink resource allocations, and not decode other DCI messages

[0216] A WTRU in associated state and/or having established a connection with a relay may monitor only PSS and SSS. If the WTRU is configured with Mode 2 communication on the sidelink, the WTRU may ignore decoding of any messages on the PDCCH for the duration of the connection with the relay WTRU. The WTRU may monitor the PSS and SSS to maintain the eNB timing.

[0217] A WTRU in associated state and/or having established a connection with a relay may monitor only PDCCH on subframes related to SA period. The WTRU may be configured with and/or provided a set of subframes (e.g., once every N subframes) in which it may monitor PDCCH for possible DL messages directly from the eNB (e.g., message to stop monitoring PC5, switch or associate with another relay WTRU, etc.). The set of subframes may be different than the IDLE mode and/or DRX configuration provided to the WTRU. The set of subframes may, for example, be dependent on a frequency of scheduling periods on the sidelink channel and/or a DRX schedule being followed by the WTRU on the sidelink channel.

[0218] For example, the WTRU may be configured to monitor the PDCCH on one or more, or each, subframe which occurs immediately prior and/or immediately following the Nth SA period on the sidelink channel.

[0219] A WTRU may be moved between a state of reduced connected mode behavior and normal connected mode state. Such transition may occur implicitly during the connection or release from a relay. For example, immediately following connection with a relay, a WTRU may transition to reduced connected mode behavior with the eNB, and when the connection with the relay is broken, the remote WTRU may move to legacy connected mode behavior. A transition may be triggered by the connection (e.g., PC5 or RRC signaling used to establish the connection) or loss of connection.

[0220] A WTRU may transition between the two states or behavior cases while maintaining the connection to the relay WTRU. A transition between states may be triggered by the reception of a PDCCH message from the eNB commanding the transition (for example, occurring on one of the subset of subframes where the WTRU is required to monitor PDCCH from the eNB). A transition between states may be triggered by the reception of MAC CE and/or RRC message from the eNB. A transition between states may be triggered by the reception of a MAC CE and/or RRC from the relay itself.

[0221] A remote WTRU in IDLE state or having an association with a relay WTRU in an associated state, may perform a connection establishment with the eNB when one or more measurements of the relay WTRU drop below a predefined threshold. The remote WTRU may perform the connection establishment with the eNB when an RLF or similar condition over IF2 is determined by the WTRU. The RLF may be specific to the RAT (e.g., PC5, Bluetooth, etc.) used for IF2. The remote WTRU may perform the connection establishment with the eNB when the remote WTRU performs reselection and/or re-association with another relay WTRU.

[0222] As part of the connection establishment, the remote WTRU may provide a cause for the connection establishment (e.g., such as loss of relay connection (without replacement), request and/or indication to reselect to a different relay, measurements below a threshold, etc.). As part of the connection establishment, the remote WTRU may provide an identification of one or more other relays. As part of the connection establishment, the remote WTRU may provide one or more associated measurements of the other relays (e.g., which may be used for a new relay connection).

[0223] For example, a WTRU in associated state may receive one or more paging messages via the relay WTRU. The eNB may use to maintain a part of the remote WTRU context in the associated state. Paging from the network may be forwarded through the relay WTRU as dedicated RRC signaling (e.g., rather than using the LTE Uu paging mechanism). The remote WTRU may inform the eNB in the case the association with the relay WTRU is lost and an alternate relay WTRU cannot be found (e.g., so that the eNB no longer forwards paging messages through the relay WTRU). Perhaps for example as a result of the remote WTRU connection establishment, the remote WTRU may be placed in legacy IDLE mode and/or the context of the remote WTRU may be deleted.

[0224] A RRC IDLE remote WTRU in network coverage may perform one or more procedures if it is associated with a relay WTRU (e.g., connected with a relay WTRU and/or has a logical connection with a remote WTRU). For example, a remote WTRU may respond to a network paging (e.g., establishing an RRC connection) via the relay WTRU.

[0225] A remote WTRU may respond to a network paging (e.g., over the Uu interface) via the relay WTRU based on a measured quality of the cell on which the remote WTRU is camped being below a predefined threshold. A remote WTRU may respond to a network paging (e.g., over the Uu interface) via the relay WTRU based on whether the remote WTRU has a connection to a relay WTRU. A remote WTRU may respond to a network paging (e.g., over the Uu interface) via the relay WTRU based on whether the remote WTRU has an association with a relay WTRU while not being connected to the relay WTRU and the measurements of the relay WTRU are above a predefined threshold. A remote WTRU may respond to a network paging (e.g., over the Uu interface) via the relay WTRU based on whether the remote WTRU can detect a relay WTRU (e.g., through discovery) having measurements which are above a predefined threshold and/or having measurements which are above a predefined threshold within the last T seconds. T may be a configurable timer (e.g., T may be reset one or more, or each, time a measurement is made of a relay which is above a configured threshold). A remote WTRU may respond to a network paging (e.g., over the Uu interface) via the relay WTRU based on the paging message including an indication that explicitly or implicitly indicates (e.g., based on the specific paging occasion used, control channel resources to send the paging, etc.) that the response may be sent via the relay WTRU.

[0226] Upon reception of the paging message, a remote WTRU may start discovery with one or more relay WTRUs. The relay WTRUs may be predefined and/or preconfigured. Upon reception of the paging message, the remote WTRU may establish a connection to a currently monitored relay WTRU, a relay with the best measurements, and/or to an associated relay. Upon reception of the paging message, the remote WTRU may cancel and/or move out of DRX operation with an associated relay WTRU (e.g., by sending a DRX cancellation message to the relay WTRU).

[0227] Upon connection establishment with the relay WTRU, the remote WTRU may respond to the network paging message via the relay WTRU. For example, the remote WTRU may transmit an RRC Connection request message to the relay WTRU over the PC5 interface or the non-3GPP link.

[0228] In addition to information in the RRC connection request message for response to the paging, the remote WTRU may send, to the relay WTRU, one or more of an identity of the relay WTRU, measurements of the relay WTRU, a Cell ID of the cell from which the paging was received, or measurements of the cell on which the remote WTRU was camped.

[0229] A relay WTRU may receive, from the network, a dedicated message (e.g., a RRC message) that includes a network paging message of a remote WTRU. The remote WTRU in IDLE mode, when associated with the relay WTRU, may be paged by the network over the PC5 interface. Paging the remote WTRU by the network may avoid sending the paging message over the air through many eNBs. The paging may be based on knowledge of association between the relay WTRU and the remote WTRU.

[0230] The eNB may maintain a partial context of the remote WTRU when the remote WTRU moves to IDLE. The partial context may include the knowledge of the association between the remote WTRU and a specific relay. The eNB (e.g., rather than transmitting the paging over Uu) may send the paging only to the relay WTRU in question. The MME may require sending the paging only to the specific target eNB.

[0231] A relay WTRU may receive a remote WTRU-destined paging message from the eNB via a special RRC message. Since the SRBs of the remote WTRU may not be established, the RRC message received by the relay WTRU may be specifically identified with one or more of a message type (e.g., paging), an identification of the remote WTRU to send to, one or more PC5 resources (e.g., TX pool, or dedicated SA resources or the like) to use when sending the paging message, and/or the remote WTRU-destined paging message (e.g., with contents similar to a legacy paging message) if it were to be sent using legacy mechanisms directly to the remote WTRU.

[0232] A relay WTRU may monitor paging over the Uu interface, for example, on behalf of one or more remote WTRUs. [0233] A relay WTRU may be configured to receive paging messages, over the Uu interface, transmitted by the network that are intended for one or more remote WTRUs. The relay WTRU may monitor the PDCCH for a Paging Radio Network Temporary Identity (P-RNTI) with the WTRU ID of the remote WTRU (e.g., the paging occasions may be computed by the relay WTRU, for example, based on the remote WTRU's WTRU ID). The WTRU ID may be obtained by the relay WTRU as part of the remote WTRU's paging configuration. The relay WTRU may receive the paging occasions and/or any additional paging configuration information needed for the relay WTRU to receive paging on behalf of the remote WTRU. The paging configuration information may contain (e.g., sufficient) information related to the remote WTRU's paging occasions over the Uu interface. This information may allow the relay WTRU to compute the remote WTRU's paging occasions and/or receive paging messages destined to the remote WTRU.

[0234] A relay WTRU may receive the paging occasions and/or paging configuration for a remote WTRU (e.g., one or more, or each, of the remote WTRUs) from the remote WTRU (for example, in a paging configuration message). For example, the relay WTRU may receive the paging occasions and/or paging configuration of the remote WTRU directly via messaging with the remote WTRU. The remote WTRU may send its paging occasions and/or paging configuration to the relay WTRU upon establishing a connection with the relay WTRU. The remote WTRU may send its paging occasions and/or paging configuration to the relay WTRU periodically, based on a predefined and/or preconfigured period. The remote WTRU may send its paging occasions and/or paging configuration to the relay WTRU upon determination, by the remote WTRU, that the remote WTRU has moved out of coverage while in IDLE mode. For example, a remote WTRU may indicate to an associated relay WTRU when it moves into or out of coverage based on a specific control message sent over the PC5 interface or the non-3GPP link between the relay WTRU and the remote WTRU. The remote WTRU may send its paging occasions and/or paging configuration to the relay WTRU upon modification of the paging occasions and/or paging configuration by the network while the remote WTRU is in coverage of the network.

[0235] A relay WTRU may receive the paging occasions and/or paging configuration for a remote WTRU (e.g., one or more, or each, of the remote WTRUs) directly from the network (for example, from a paging configuration message). For example, the relay WTRU may receive the paging occasions and/or paging configuration of its remote WTRUs by request. The relay

WTRU may request the paging occasions and/or paging configuration of the remote WTRUs for which it has established an association. As another example, the relay WTRU may receive the paging occasions and/or paging configuration of its remote WTRUs by subscription. For example, the relay WTRU, upon establishing an association, may request to receive any updates to the paging occasions and/or paging configuration of a specific remote WTRU when such information has changed. The relay WTRU may send a subscription upon reception of an indication that the remote WTRU has moved out of coverage of the network. The relay WTRU may send the subscription upon initiation of the association between the relay WTRU and the remote WTRU. The remote WTRU may cancel the subscription with the network, for example, when the remote WTRU determines that it is in coverage of the network and/or when the association between the relay WTRU and the remote WTRU is terminated.

[0236] A relay WTRU may receive the paging occasions and/or paging configuration for a remote WTRU (e.g., one or more, or each, of the remote WTRUs) via an indication from the network. For example, the relay WTRU may receive dedicated signaling from the network (e.g., a RRC message) with the paging occasions and/or paging configuration of the associated remote WTRUs. FIG. 5 depicts an example paging configuration for a remote WTRU that includes a relay WTRU monitoring paging occasions of the remote WTRU based on paging configuration information (e.g., provided by the network/eNB/MME and/or the remote WTRU).

[0237] A paging configuration message may contain one or more pieces of information and/or data as described herein. For example, a paging configuration message may include the P-RNTI (and/or similar ID) with which the relay WTRU might monitor paging on the Uu interface (e.g., possibly if different than the P-RNTI of the relay WTRU).

[0238] A paging configuration message may include one or more parameters which can be used to compute the Remote WTRU paging occasions. The one or more parameters may include one or more of the following:

a WTRU-specific DRX cycle of the remote WTRU (e.g., configured by NAS layer);

- the default DRX cycle in the cell currently camped on by the remote WTRU, and/or the last cell on which the remote WTRU was camped;

- WTRU ID or some part of the WTRU ID, such as IMSI mod n (for example where n can be some integer value, such as 1024 for example, and/or can be set to the remote WTRU's DRX cycle);

one or more other DRX parameters received by the remote WTRU in system information such as nB, Nn, and/or maxPagingCarriers; and/or

- potential information restricting and/or down selecting the number of paging

occasions applicable to the remote WTRU. [0239] For example, the remote WTRU may be configured with one or more rules to down select a subset of the paging occasions that might be monitored on Uu interface which could be applicable when:

- the remote WTRU may notify the network it has some association; and/or

- the remote WTRU may be a low-power device and/or has some capabilities

indicating such status.

[0240] The one or more rules may be sent in the form of a mask, configuration index, and/or index to a rule in specification, etc.

[0241] A paging configuration message may include one or more of:

beamforming information, such as for example, the beam index, beam width, and/or beam timing, and/or the like, of the remote WTRU's receiver beam;

an eNB ID of the current eNB and/or last eNB to which the remote WTRU may/might have been camped;

- paging area identification of the paging area in which the WTRU may be currently located, and/or last located in, perhaps prior to possibly moving out of coverage; and/or

a SFN and/or subframe number of one or more WTRU paging occasions, perhaps for example as computed by the remote WTRU.

[0242] A remote WTRU may initiate transmission of the paging configuration to the relay WTRU, perhaps for example upon an initiation of one-to-one connection with the relay WTRU. The remote WTRU may send the paging configuration message using an application-like, RRC- like and/or MAC CE message to the relay WTRU, perhaps for example following a successful connection with the relay WTRU. The paging configuration message may be sent as part of a relay control messaging between the remote WTRU and relay WTRU.

[0243] The remote WTRU may send the paging configuration message to the relay WTRU in one or more of: upon a change to one or more of the paging related parameters for the remote WTRU, such as for example, the DRX cycle;

at a time(s) in which the remote WTRU's measurements of the cell to which it is camped may be below an acceptable threshold (e.g., the cell on which the

WTRU might have been previously camped becomes unsuitable);

at a time(s) in which the remote WTRU might not be able to find a suitable cell with quality at or above a specific and/or predetermined threshold. For example, the remote WTRU may be configured with one or more thresholds by the network. Perhaps for example when camped on a cell in IDLE mode and/or (e.g., simultaneously) connected to a relay WTRU, the remote WTRU may compare the cell quality of the camped cell with a threshold. Perhaps for example if the cell quality is above a threshold, the remote WTRU may monitor paging on the Uu interface. Perhaps for example when the cell quality at the remote WTRU falls below a threshold, the remote WTRU may send the paging configuration message to the relay WTRU; at a time(s) in which remote WTRU's battery power might be below a specific and/or predetermined threshold; and/or

as a result of initiation by a user and/or the application layer.

[0244] The remote WTRU may (e.g., first) send the paging configuration message at a timing instant given by one of the instances and/or circumstances described herein (e.g., at an initiation of the one-to-one connection with the relay). The remote WTRU may send an indication to the relay WTRU to start/stop monitoring paging, perhaps for example at some later time. For instance, the remote WTRU may send an indication for the relay WTRU to start monitoring paging. At that time, for example, the remote WTRU may itself stop monitoring paging on the Uu interface. At the transmission of such an indication, for example, the remote WTRU may move into DRX on the PC5 link and/or direct link, as described herein. At the transmission of such an indication, for example, the remote WTRU may provide the relay WTRU with its DRX cycle and/or wakeup instances on the PC5 and/or direct link.

[0245] At a transmission of the monitoring paging start indication to the relay WTRU, for example, the remote WTRU may start monitoring for paging messages coming (e.g., directly) from the relay WTRU over PC5 and/or direct link. The remote WTRU may stop monitoring PC5 (e.g., at that time). The remote WTRU may switch to the DRX period and/or DRX behavior defined for the PC5 link during this period of time. The remote WTRU may send the start paging indication message to the relay WTRU, perhaps for example to indicate to the relay WTRU that it can monitor paging on behalf of the remote WTRU, at one or more of the following times:

following establishment of a one-to-one connection with the relay;

at a time(s) in which the remote WTRU's measurements of the cell to which it is camped may be below an acceptable threshold (e.g. the cell on which the

WTRU might have been previously camped becomes unsuitable). For example, the remote WTRU may be configured with one or more thresholds by the network. Perhaps for example when camped on a cell in IDLE mode and/or (e.g., simultaneously) connected to a relay WTRU, the remote WTRU may compare the cell quality of the camped cell with a threshold. Perhaps for example if the cell quality is above a threshold, the remote may WTRU monitor paging on the Uu interface. Perhaps for example when the cell quality at the remote WTRU falls below a threshold, the remote WTRU may send the start paging message to the relay WTRU. The remote WTRU may be configured with at least two such thresholds, for example. Perhaps for example if the cell quality falls below a first threshold, the remote WTRU may initiate a connection to a relay WTRU and/or send the paging configuration. Perhaps for example if the cell quality falls below a second threshold, the remote WTRU may send the start paging indication message to trigger the relay WTRU to start monitoring the paging;

at a time(s) in which the remote WTRU might not be able to find a suitable cell with quality above a specific threshold;

at a time(s) in which the remote WTRU's battery power may below a specific threshold; and/or

as a result of an initiation by a user and/or the application layer.

[0246] A remote WTRU, perhaps for example following a transmission of the start monitoring paging indication message to the relay WTRU, may continue to monitor paging on the Uu link. Such a WTRU may perform (e.g., soft) combining of the paging messages received from the Uu link and the PC5/direct link.

[0247] A remote WTRU, perhaps for example following a transmission of the start monitoring paging indication message to the relay WTRU, may (e.g., periodically) perform a determination of the quality of a service cell over the Uu interface. Such determinations may be performed at the DRX period of the Uu interface, of the DRX period of the PC5 interface, and/or some other configured and/or predetermined period. The remote WTRU may perform a (e.g., a periodic) determination of the quality of a serving cell, perhaps for example at a rate which may be lower

(e.g., much lower) than the original DRX cycle. This may save battery power in monitoring the

Uu interface. The remote WTRU may, perhaps for example upon determining that the serving cell strength is above a threshold, may transmit a stop monitoring paging indication to the relay

WTRU. In some scenarios, the remote WTRU may start to monitor paging on the Uu interface.

[0248] A remote WTRU may be configured with one or more thresholds associated to the measured signal strength of the serving cell over Uu. The one or more thresholds may be used to determine when to transmit the start/stop indication to the relay WTRU, when to switch to monitoring paging over Uu, and/or when to receive paging over PC5/direct link with the relay WTRU. The remote WTRU may determine and/or modify such thresholds based on one or more of:

currently remaining battery power;

- speed of the WTRU;

estimated and/or indicated (e.g. from upper layers) proximity with the relay

WTRU and/or the cell; and/or

indoor/outdoor location status.

[0249] For example, the remote WTRU may change from one or more thresholds, or a set of thresholds, to other thresholds or another set of thresholds, based on a change in one or more of the aforementioned events/statuses.

[0250] The remote WTRU may (e.g., periodically) perform one or more cell reselection rules, perhaps for example while monitoring PC5 for paging which may be sent to it by the relay WTRU. Upon reselection to a different cell, for example, among other scenarios, the remote WTRU may perform one or more of:

- transmit the cell ID of the new (e.g. fresh or next) cell to the relay WTRU; send the paging configuration message to the relay WTRU with potentially new (e.g. fresh) paging configuration parameters;

- transmit the RAU or PAU to the relay WTRU, perhaps for example if the WTRU changes tracking area, and/or RAN paging area; and/or

receive on PC5: wakeup behavior, and/or when to wakeup, perhaps for example based on coverage condition(s).

[0251] A relay WTRU, perhaps for example upon reception of a paging configuration message, may compute the paging occasions for the corresponding remote WTRU. The relay WTRU may monitor the paging of (e.g., one or more, or each, of) its remote WTRUs. For instance, perhaps upon reception of the paging configuration message, upon establishment of a one-to-one connection with a remote WTRU, and/or upon reception of a start paging indication from a remote WTRU, a relay WTRU may start monitoring for paging messages transmitted according to the remote WTRU's paging occasions.

[0252] A relay WTRU, perhaps for example upon reception of a paging message transmitted with P-RNTI, may decode the message to determine the presence of the WTRU ID (e.g., IMSI) of any of the connected remote WTRU IDs. In scenarios such as for example where the WTRU ID of any connected remote WTRUs may be present in the paging record, the relay may send a paging message over PC5/direct link to that specific remote WTRU.

[0253] The relay WTRU may forward the entire RRC paging message over the PC5/direct link to one or more, or each, remote WTRU. The paging message received by the relay WTRU may be encapsulated and/or sent in a control message over the PC5 link. The relay WTRU may forward such message(s) transparently in an RRC message transmitted over PC5, for example. The relay WTRU may encapsulate such message(s) in an application layer control message, such as a control message over Bluetooth and/or Wifi, for example.

[0254] The relay WTRU, perhaps for example upon successful reception of a TB from the PCH, may transmit the TB (e.g., directly) over PC5, perhaps without forwarding the TB to one or more upper layers. The relay WTRU may transmit the same TB to one or more, or each, of the connected remote WTRUs which may have requested monitoring of the paging channel by the relay WTRU on their behalf, as described herein.

[0255] The relay WTRU may transmit the paging message received over Uu to one or more, or all, of the connected remote WTRUs, perhaps for example using a broadcast channel defined over a PC5/direct link. Such a broadcast channel may be defined based for example on the radio access technology (RAT) that may be used for the direct link. For instance, in scenarios with a PC5 link with the remote WTRUs, the relay WTRU may use a dedicated broadcast layer 2 (L2) ID to broadcast the paging message to one or more, or each, of the connected remote WTRUs.

[0256] A relay WTRU may buffer paging message(s), perhaps for example until the next available DRX on period on a PC5/direct link, as described herein.

[0257] A relay WTRU may monitor the paging occasions and/or receive paging messages for one or more remote WTRUs, for example, using the paging occasion and/or paging

configuration information from the remote WTRU. The relay WTRU may perform monitoring of paging occasions of the remote WTRU, for example, when configured to do so by the network through dedicated signaling. The relay WTRU may monitor and/or receive paging for the remote WTRU following an indication to begin doing so received by the remote WTRU, such as an indication that the remote WTRU has moved out of coverage. A relay WTRU may stop monitoring paging for the remote WTRU based on an indication from the remote WTRU (e.g., such as that the remote WTRU has moved back in coverage).

[0258] A relay WTRU in IDLE mode may wake up at the paging occasions of one or more, or each, of the associated remote WTRUs. A relay WTRU in IDLE mode may wake up at the paging occasions of one or more, or each, of the associated remote WTRUs that have requested to have relay WTRU monitor paging. A relay WTRU in IDLE mode may wake up at the paging occasions of the associated remote WTRUs for which the network requested to have the relay WTRU monitor paging. For example, the relay WTRU may maintain a list of associated remote WTRUs which are outside of network coverage. The relay WTRU may wake up at the paging occasions associated with one or more, or each, of these remote WTRUs in the list, for example, to monitor paging on behalf of the remote WTRUs.

[0259] A relay WTRU may perform one or more of the following upon reception of the remote WTRU-destined paging message: initiate a non-3GPP connection with the remote WTRU (e.g., in case the link is a non-3GPP link); send a wakeup indication over PC5 to the remote WTRU, followed by the message; start a discovery procedure with the remote WTRU; initiate a connection establishment procedure with the remote WTRU, or send a message to the remote WTRU which may trigger the relay WTRU to start a discovery and/or connection establishment; wait for the scheduled wakeup of the remote WTRU to send the paging message; request resources from the eNB for transmission to the remote WTRU using Mode 1 ; indicate to the remote WTRU to cancel DRX operation over the PC5 interface; and/or transmit the paging message over the PC5 interface. The relay WTRU may wait for the scheduled wakeup time of the remote WTRU when the remote WTRU is following DRX over the PC5 interface.

[0260] The paging message may be sent over PC5 using RRC format. The paging message may be sent as a special MAC CE over a specific logical channel. The paging message may be sent using a special dedicated pool and/or a high priority pool, as in the case of RRC messages forwarded to the remote WTRU. The paging message may be sent as part of the payload of the discovery and/or connection establishment (e.g., as part of the payload in one or more discovery and/or connection messages).

[0261] A relay WTRU may receive a paging message from the network. Upon reception of the paging message, the relay WTRU may initiate a discovery over PC5. The discovery may include the relay WTRU sending a discovery announcement message to one or more remote WTRUs. The discovery may trigger a connection establishment by a remote WTRU. The remote WTRU, upon reception of the discovery announcement message, may initiate a connection establishment with the relay WTRU. When initiating the connection establishment, or shortly thereafter, the remote WTRU may receive the paging message from the relay WTRU. A discovery

announcement message may be used to solicit a response from the remote WTRU. If the relay WTRU receives a response from the remote WTRU, the relay WTRU may initiate a connection establishment with the remote WTRU and may send a paging message as part of the connection establishment messaging or shortly after completion of the connection establishment. [0262] An associated state and/or a connected relay ID may be transmitted to the MME. A remote WTRU, when associating with a relay WTRU, may send the indication of the associated state and/or a connected relay ID to the MME so that any future pages of that WTRU from the MME are sent to the relay WTRU. A WTRU may send the associated state via a NAS signaling message to the MME at one of the following time instants.

[0263] A WTRU may send the associated state via a NAS signaling message to the MME when a remote WTRU connected to a relay receives an RRCConnectionRelease message from the eNB moving the WTRU into IDLE mode, perhaps for example while it may have a connection to the relay WTRU. Such connection may be a PC5 connection, or a connection via a different RAT. A WTRU may send the associated state via a NAS signaling message to the MME when a remote WTRU connected to a relay receives an RRCConnectionReconfiguration message from the eNB indicating that it may move to associated state. A WTRU may send the associated state via a NAS signaling message to the MME when a remote WTRU completes a connection with the relay WTRU. The connection may be completed via a connection completion message received via PC5 signaling protocol. The connection may be completed when one or more of the bearers are moved over the relay connection. A WTRU may send the associated state via a NAS signaling message to the MME when the remote WTRU completes a connection to a different relay (e.g., the remote WTRU moves from the connection with one relay to the connection to another relay).

[0264] The WTRU, following a trigger (e.g., as described herein) to move to the associated state, may send a NAS signaling message to the MME with an identification of the relay WTRU to which it is associated. The identification of the relay WTRU may be the ProSelD of the relay WTRU to which it is connected. The identification of the relay WTRU may be the WTRU ID's IMSI, GUTI, IP address, and/or other identity corresponding to the relay WTRU that is known by the MME.

[0265] The remote WTRU may receive the identification of the relay WTRU from the connection procedure with the relay WTRU (e.g., via PC5 signaling). The remote WTRU may receive the identification of the relay WTRU from the eNB, for example, when the eNB is involved in the connection between the remote WTRU and the relay WTRU.

[0266] The remote WTRU, following a trigger for sending the associated state information to the

MME (e.g., via a NAS message), may send an RRC message to the eNB prior to moving to the associated state, perform an RRCConnectionEstablishment to send the identity of the relay

WTRU, and/or transmit the identity of the relay WTRU on a NAS message which may be piggybacked on the RACH, or any further uplink messages sent by the WTRU as part of the RACH procedure (e.g., Msg3). For example, in Msg3, the WTRU may send an RRCConnectionRequest message with a cause indicating that it wishes to send the associated state and ID of the relay WTRU to the MME.

[0267] The relay WTRU may send information about the remote WTRU (e.g., as described herein) to the MME periodically. The relay WTRU may send information about the remote WTRU to the MME when the relay WTRU completes connection with the remote WTRU. Such connection may be completed via a connection completion message received via PC5 signaling protocol and/or when one or more of the bearers are moved over the relay connection. The relay WTRU may send information about the remote WTRU to the MME when a remote WTRU disconnects from the relay WTRU. The relay WTRU in this scenario may inform the MME that the relay connection with remote WTRU has been torn down. The relay WTRU may send information about the remote WTRU to the MME when the remote WTRU is in idle state with respect to the relay WTRU. This may happen when there is no data transmission on the PC5 link between the relay WTRU and the remote WTRU for a specified amount of time. Such inactivity on the PC5 link between the relay WTRU and the remote WTRU may cause the remote WTRU to move to idle state with respect to the PC5 link.

[0268] A relay WTRU may perform the procedure of system information reading (e.g., reading SIBs) and system information update on behalf of a connected or associated remote WTRU.

[0269] A relay WTRU, upon receiving a paging message with a SystemlnfoModification flag set, and/or upon detecting a changed value tag in SIB 1, may send the updated system information (e.g., the modified SIB) to one or more, or all, remote WTRUs connected and/or associated to the relay WTRU. The relay WTRU may send the updated system information using individual transmissions to one or more, or each, of the WTRUs. The remote WTRU may use broadcast to transmit the updated system information to the remote WTRUs under its control. The remote WTRU may broadcast the updated system information based on a specific L2 ProSe ID, a specific broadcast channel over PC5, and/or a specific set of resources or resource pool.

[0270] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer- readable storage media. Examples of computer-readable storage media include, but are not limited to, a read-only memory (ROM), a random-access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, WTRU, terminal, base station, RNC, or any host computer.

Claims

What is Claimed is:

1. A first wireless transmit/receive unit (WTRU), comprising:

a memory;

a receiver, the receiver configured at least to:

receive paging configuration information for a second WTRU; and a processor, the processor configured at least to:

determine one or more paging occasions for the second WTRU from the paging configuration information;

monitor at least one of the one or more paging occasions on an Uu interface, the receiver being further configured to receive at least one paging message directed to the second WTRU at the at least one of the one or more paging occasions;

initiate a discovery procedure of the second WTRU on at least one of: a PC5 interface, or a non-3GPP interface, upon the receipt of the at least one paging message;

establish at least one of: a PC5 link, or a non-3GPP link with the second WTRU based on a result of the discovery procedure; and

initiate a transfer of the at least one paging message to the second WTRU on the at least one of: the PC5 link, or the non-3GPP link with the second WTRU.

2. The first WTRU of claim 1, wherein the first WTRU functions as a relay WTRU in a communication network including the first WTRU and the second WTRU.

3. The first WTRU of claim 1, wherein the receiver is further configured such that the

paging configuration information is received from the second WTRU.

4. The first WTRU of claim 3, wherein the receiver is further configured such that the

paging configuration information is received from the second WTRU in at least one of: upon an establishment of a communication connection with the second WTRU, periodically, upon a departure of the second WTRU from a coverage area, or upon a change in the paging configuration information.

5. The first WTRU of claim 2, wherein the receiver is further configured such that the paging configuration information is received from an evolved NodeB (eNB) of the communication network.

6. The first WTRU of claim 5, wherein the receiver is further configured such that the paging configuration information is received from the eNB in at least one of: upon a request for the paging configuration information by the first WTRU, based on a subscription for the paging configuration information, or from a Radio Resource Control (RRC) message.

7. The first WTRU of claim 1, wherein the processor is further configured to cause the first WTRU to emerge from an energy-saving state at the at least one of the one or more paging occasions.

8. The first WTRU of claim 1, wherein the processor is further configured such that the transfer of the at least one paging message is initiated via at least one of: an application message; a Radio Resource Control (RRC) message, or a Medium Access Control (MAC) Control Element (CE) message.

9. The first WTRU of claim 1, wherein the processor is further configured to wait for a scheduled emergence of the second WTRU from an energy-saving state prior to the initiation of the discovery procedure.

10. The first WTRU of claim 1, wherein the second WTRU is a wearable device.

11. The first WTRU of claim 1, wherein the paging configuration information includes at least one of: the one or more paging occasions of the second WTRU, a system frame number (SFN) of at least one of the one or more paging occasions of the second WTRU, or a subframe number of at least one of the one or more paging occasions of the second WTRU.

12. The first WTRU of claim 1, wherein the paging configuration information includes at least one of: a Paging Radio Network Temporary Identity (P-RNTI) of the first WTRU, a P-RNTI of the second WTRU.

13. The first WTRU of claim 1, wherein the processor is further configured to determine the one or more paging occasions of the second WTRU by computing the one or more paging occasions based on the paging configuration information.

14. The first WTRU of claim 13, wherein the paging configuration information includes at least one of: a WTRU-specific discontinuous reception (DRX) cycle of the second WTRU; a WTRU Identifier (ID) of the second WTRU, a beam index of the second WTRU, a beam width of the second WTRU, a current paging area identification of the second WTRU, a last-located paging area identification of the second WTRU.

15. The first WTRU of claim 2, wherein the processor is further configured to initiate a message to a Mobility Management Entity (MME) of the communication network, the message including information regarding a state of association between the first WTRU and the second WTRU.

16. The first WTRU of claim 15, wherein the information regarding the state of association between the first WTRU and the second WTRU includes at least one of: a connected state status, or a disconnected state status.

17. A first wireless transmit/receive unit (WTRU), comprising:

a memory;

a processor, the processor configured at least to:

determine paging configuration information for the first WTRU;

initiate a transmission of the paging configuration information for the first WTRU to a second WTRU;

detect a discovery request of the first WTRU by the second WTRU on at least one of: a PC5 interface, or a non-3GPP interface; and

establish at least one of: a PC5 link, or a non-3GPP link with the second WTRU based on the discovery request; and

a receiver, the receiver configured at least to:

receive at least one paging message directed to the first WTRU from the second WTRU on the at least one of: the PC5 link, or the non-3GPP link with the second WTRU.

18. The first WTRU of claim 17, wherein the first WTRU functions as a remote WTRU in a communication network including the first WTRU and the second WTRU.

19. The first WTRU of claim 17, wherein the first WTRU is a wearable device.

20. The first WTRU of claim 17, wherein the processor is further configured such that the paging configuration information is sent to the second WTRU in at least one of: upon a change to a discontinuous reception (DRX) cycle of the first WTRU, upon one or more first WTRU measurements of a cell to which the first WTRU is camped falls below a predetermined threshold; upon the first WTRU not finding a cell with a quality above a predetermined threshold, upon battery power of the first WTRU falling below a predetermined threshold, an initiation by a user of the first WTRU, or upon an initiation by an application layer.

21. The first WTRU of claim 17, wherein the processor is further configured such that paging configuration message transmission occurs via at least one of: an application message; a Radio Resource Control (RRC) message, or a Medium Access Control (MAC) Control Element (CE) message.

22. The first WTRU of claim 17, wherein the processor is further configured to initiate a request to the second WTRU to monitor for one or more paging messages directed to the first WTRU on a Uu interface.

23. The first WTRU of claim 22, wherein the processor is further configured such that the request to monitor for one or more paging messages is sent to the second WTRU in at least one of: upon an establishment of communication with the second WTRU, upon one or more first WTRU measurements of a cell to which the first WTRU is camped falls below a predetermined threshold; upon the first WTRU not finding a cell with a quality above a predetermined threshold, upon battery power of the first WTRU falling below a predetermined threshold, an initiation by a user of the first WTRU, or an initiation by an application layer.

24. The first WTRU of claim 17, wherein the processor is further configured to initiate a request to the second WTRU to not monitor for one or more paging messages directed to the first WTRU on a Uu interface.

25. The first WTRU of claim 24, wherein the processor is further configured such that the request to not monitor for one or more paging messages is sent to the second WTRU upon a determination by the first WTRU that a serving cell signal strength meets or exceeds a predetermined threshold.

26. The first WTRU of claim 25, wherein the processor is further configured to initiate monitoring for the one or more paging messages on the Uu interface.

27. The first WTRU of claim 17, wherein the processor is further configured to initiate a message to a Mobility Management Entity (MME) of the communication network, the message including information regarding a state of association between the first WTRU and the second WTRU.

28. The first WTRU of claim 27, wherein the information regarding the state of association between the first WTRU and the second WTRU includes at least one of: a connected state status, or a disconnected state status.

29. The first WTRU of claim 28, wherein the message is a non-access stratum (NAS)

message.

30. The first WTRU of claim 29, wherein the NAS message indicates the connected state status, and the NAS message includes at least one of: a proximity -based services identifier (ProSe ID) of the second WTRU, an Internet Protocol (IP) address of the second WTRU, an identifier of the second WTRU, or an International Mobile Subscriber Identity (IMSI) of the second WTRU.