WO2016164670A1

WO2016164670A1 - Flexible d2d discovery

Info

Publication number: WO2016164670A1
Application number: PCT/US2016/026568
Authority: WO
Inventors: Benoit Pelletier; Chao-cheng TU; Mahmoud Watfa; Guanzhou Wang; Martino M. Freda
Original assignee: Interdigital Patent Holdings, Inc.
Priority date: 2015-04-08
Filing date: 2016-04-08
Publication date: 2016-10-13

Abstract

Systems, methods, and instrumentalities are disclosed for applying flexible D2D discovery. A first wireless transmit/receive unit (WTRU) may determine a duration of a transmission to a second WTRU within a scheduling period. The first WTRU may determine a time offset for the transmission based on the determined duration. The time offset may indicate a transmission start time when the transmission starts within the scheduling period. The first WTRU may send a scheduling assignment that includes a time offset parameter. The time offset parameter may indicate the transmission start time. The time offset parameter may be determined on a random basis. The time offset parameter may be determined based on an identifier, e.g., such as a group destination identification (ID). The first WTRU may send an indication of a number of transport blocks in the transmission.

Description

FLEXIBLE D2D DISCOVERY

CROSS REFERENCE TO RELATED APPLICATIONS

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

62/144,803, filed April 8, 2015; and U.S. Provisional Patent Application No. 62/160,862, filed May 13, 2015; the contents of which are incorporated by reference herein.

BACKGROUND

[0002] In a device-to-device (D2D) discovery process, a device (e.g. , such as a wireless transmit/receive unit (WTRU)) may broadcast a D2D discovery message to indicate presence of the device to other devices. One or more of the other devices may discover the device by monitoring broadcast discovery messages. The D2D discovery message may carry a fixed number of bits. A payload size of the D2D discovery message may be 232 bits. The payload size of the D2D discovery message may exclude a cyclic redundancy check (CRC). A message with a fixed size discovery payload may not carry additional information and/or support dynamic payload sizes. A one-way discovery may limit the capabilities of device discovery.

SUMMARY

[0003] Systems, methods, and instrumentalities are disclosed for applying flexible D2D discovery. A first wireless transmit/receive unit (WTRU) may determine a duration of a transmission to a second WTRU within a scheduling period. The first WTRU may determine a time offset for the transmission based on the determined duration. The time offset may indicate a transmission start time when the transmission starts within the scheduling period. The first WTRU may send a scheduling assignment that includes a time offset parameter. The time offset parameter may indicate the transmission start time. The time offset parameter may be determined on a random basis, for example from a set of allowed time offset values. The set of allowed time offset values may include one or more time offset values for which the first WTRU can transmit the data in its buffer within the duration of the scheduling period. The time offset parameter may be determined based on an identifier, e.g., such as a group destination identification (ID). A subset of bits from the group destination ID may indicate the time offset. The time offset parameter may include one or more of a number of time resource patterns (T- RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

[0004] The first WTRU may send an indication of a number of transport blocks in the transmission. The indication of the number of transport blocks may be included in one or more of the scheduling assignment or a MAC header. The indication of the number of transport blocks may include one or more of a number of T-RPTs, MAC PDUs, subframes, or

milliseconds. The first WTRU may select one or more resources for the transmission. The first WTRU may send buffered data in the transmission using the one or more resources during the scheduling period according to the time offset.

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0006] 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. 1A.

[0007] 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.

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

1A.

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

[0010] FIG. 2 is a diagram illustrating an example of open direct discovery.

[0011] FIG. 3 is a diagram illustrating an example of open direct discovery.

[0012] FIG. 4 is a diagram illustrating an example of WTRU-to-Network (NW) Relay discovery for open direct discovery.

[0013] FIG. 5 is a diagram illustrating an example of WTRU-to-Network (NW) Relay discovery for open direct discovery.

[0014] FIG. 6 is a diagram illustrating an example of unicast communication with ProSe UE- to- NW Relay discovery for open direct discovery. [0015] FIG. 7 is a diagram illustrating an example of group member discovery for open direct discovery.

[0016] FIG. 8 is a diagram illustrating an example of group member discovery for open direct discovery.

[0017] FIG. 9 is an example of a discovery message with a discovery payload having multiple transport blocks.

[0018] FIG. 10 is an example of a discovery message with a discovery payload having multiple transport blocks where the number of discovery payload segments may be dynamically adjusted.

[0019] FIG. 11 is an example of a discovery message with a discovery payload having multiple transport blocks with a pre-determined number of transport blocks having dynamically adjusted TBS dimensions.

[0020] FIG. 12 is an example of a discovery message with a discovery payload having multiple transport blocks with different TBS dimensions.

[0021] FIG. 13 is an example of a discovery message with a discovery payload having multiple transport blocks with different TBS dimensions.

[0022] FIG. 14 is an example transmission of a discovery payload with a single transport block.

[0023] FIG. 15 is an example transmission of multiple discovery segments that may rely on a single transmission check.

[0024] FIG. 16 is an example transmission of multiple discovery segments that may rely on a single transmission check.

DETAILED DESCRIPTION

[0025] 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 exemplary and in no way limit the scope of the application. In addition, the figures may illustrate messaging charts, which are meant to be exemplary. Other embodiments may be used. The order of the messages may be varied where appropriate. Messages may be omitted if not needed, and, additional flows may be added.

[0026] 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 system 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.

[0027] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs), e.g., 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. 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.

[0028] The communications system 100 may also include a base station 114a and a base station 114b. 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 base stations 114a, 114b are depicted as single elements, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and/or network elements.

[0029] 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 some embodiments, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an example, the base station 114a may employ multiple-input multiple output (MIMO) technology. Base station 114a may, for example, utilize multiple transceivers for each sector of the cell.

[0030] 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).

[0031] 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).

[0032] 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).

[0033] 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.

[0034] 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 some embodiments, 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. 1A, the base station 114b may have a direct connection to the Internet 110. Thus, the base station 114b may not be needed to access the Internet 110 via the core network 106/107/109.

[0035] 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.

[0036] 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.

[0037] One or more 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. [0038] 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 or HeNodeB), a home evolved node-B gateway, and proxy nodes, among others, may include one or more of the elements depicted in FIG. IB and described herein.

[0039] 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.

[0040] 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 some embodiments, 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.

[0041] 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 some embodiments, 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.

[0042] 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.

[0043] 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).

[0044] 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.

[0045] 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 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 implementation while remaining consistent with an embodiment. [0046] 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.

[0047] 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. A Node-B may have 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.

[0048] 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 Iur interface. RNCs 142a, 142b may be configured to control the respective Node-Bs 140a, 140b, 140c to which they are 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.

[0049] 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.

[0050] 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 land-line communications devices.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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 some embodiments, 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.

[0055] 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 (UL) and/or downlink (DL), and the like. As shown in FIG. ID, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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 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.

[0061] 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.

[0062] 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 some embodiments, 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.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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 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.

[0067] 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.

[0068] Systems, methods, and instrumentalities are disclosed for applying flexible D2D discovery. Flexible D2D discovery may include one or more communications, for example via the PC5 interface (e.g. , the D2D communication interface; may also be referred to as the sidelink) and/or with ProSe Function(s) over network. For example, flexible D2D discovery may include sending one or more of a content in a discovery message. The content of the discovery message may include one or more of a discovery code, a type of entity, a network configuration, a resource used for a discovery message, and/or the like. Flexible D2D discovery may provide a flexible D2D message payload size. For example, a single variable size transport block transmission be used for D2D discovery. In an example, multiple fixed payload size discovery messages may be used for D2D discovery. In an example, multiple variable size transport blocks may be used for D2D discovery.

[0069] Flexible D2D discovery may utilize flexible message payload formats associated with multiple transport block sizes. Flexible D2D discovery may utilize flexible message payload formats associated with one or more types of payload content. Flexible D2D discovery may utilize flexible payload support, such as by indicating and/or utilizing one or more of a transmission duration, a transmission termination, and/or a transmission offset in a D2D scheduling period. Flexible D2D discovery may provide flexible payload support by enabling selection of a resource pool associated with a scheduling period. The resource pool may be selected from a plurality of associated resource pools and scheduling periods. One or more resources for retransmissions of a segment in a payload and/or for different segments in the payload may be based on (e.g. , derived deterministically from) a single resource selection value. For example, one or more resources for retransmissions of a segment in a payload and/or for different segments in the payload may determine based on a random resource selection value. Multiple segments may be reassembled based on association with one or more transmission resources allocated based on a single resource selection value. Delay-sensitive D2D payload transmission may be expedited. For example, delay-sensitive D2D payload transmission may be expedited by configuring a WTRU differently for delay-sensitive and non-delay-sensitive payloads. For example, the WTRU may assign one or more of a different priority, a different transmission probability, a timer value, bias to an access-related random variable threshold, and/or change a function and/or parameters of a function to generate an access-related random variable based on whether or not the transmission is delay-sensitive.

[0070] A device-to-device (D2D) discovery may comprise one or more discovery messages transmitted between a discoveree device (e.g., such as a discoveree WTRU) and a discoverer device (e.g., such as a discoverer WTRU) using one or more discovery mechanisms. The size of a message payload may vary dynamically. Additional information may be delivered during the D2D discovery. A discovery mechanism (e.g., such as broadcast) may be employed to support one or more other applications.

[0071] Additional information may include, for example, various system-related signaling in support of one or more advanced D2D features. In an example, Proximity Service (ProSe) WTRU-Network Relays may carry messages similar to a System Information Block (SIB). The messages may, for example, indicate one or more Access Point Names (APNs) and/or a set of Temporary Mobile Group Identities (TMGIs). As another example of delivering additional information, one or more security -related parameters in a D2D discovery payload may utilize a larger payload size.

[0072] During a D2D discovery, one or more interactions may be performed between the discoverer device and the discoveree device. For example, the discoverer device may send a solicitation message. The discoveree device may receive the solicitation message. In response to the discoverer device's solicitation message, the discoveree may send (e.g., return) semantic information (e.g. , metadata). For example, a taxi application may send a taxi driver's name, company, charging rate, and/or the like during a D2D discovery.

[0073] A discovery mechanism (e.g. , broadcast) may be employed to support one or more other applications. For example, a discovery mechanism may be used to support transmission of a cooperative awareness message (CAM) in a vehicle-to-everything (V2X) communication. The CAM may be a periodic transmission from a vehicle. The CAM may provide vehicle information such as presence, position, heading, temperature, and/or other basic status information. The CAM supported with a discovery mechanism may include a discovery message with metadata.

[0074] A flexible payload may be implemented in a variety of discovery techniques.

Examples of discovery techniques may be referred to as "models."

[0075] For example, a model (e.g., which may be referred to as Model-A may include an open direct discovery. For example, the model may not require an explicit permission from a discoveree WTRU being considered by a discoverer WTRU. Model-A may be referred to as an "I am here" discovery technique. A WTRU may announce its presence to one or more other WTRUs who may be interested in reading and/or processing discovery messages.

[0076] FIG. 2 is a diagram illustrating an example of open direct discovery 200. FIG. 2 presents an example of a high level Model A discovery. The example open direct discovery 200 may include one or more WTRUs 210 that interface with a ProSe Function 220 of a home public land mobile network (HPLMN) 202. The ProSe Function 220 may interface with a plurality of ProSe Functions 230 of one or more other public land mobile networks (PLMNs) 204. A service authorization 240 may be established between the one or more WTRUs 210 and the ProSe Function 220. For example, a first WTRU 212 may send an authorization request for direct discovery to the ProSe Function 220 of the HPLMN 202. The ProSe Function 220 may receive authorization information from one or more of the plurality of ProSe Functions 230 of the one or more other PLMNs 204. The ProSe Function 220 may send the authorization information to the first WTRU 212. The first WTRU 212 of the one or more WTRUs 210 may represent an announcing WTRU.

[0077] The first WTRU 212 may, for example, determine to announce its presence and/or a presence of a certain service. The first WTRU 212 may request a code 250 from the ProSe Function 220. The first WTRU 212 may announce the code 252 allocated by the ProSe Function 220. A second WTRU 214 may be interested in discovering the presence of one or more other WTRUs or services. The second WTRU 214 may represent a monitoring WTRU. The second WTRU 214 may send a monitoring request 254 to the ProSe Function 220. The ProSe Function 220 may provide one or more discovery filters to the second WTRU 214. The one or more discovery filters may enable the second WTRU 214 to decode the allocated code transmitted by the first WTRU 212. The second WTRU 214 may monitor 256 for the allocated code transmitted by the first WTRU 212. The second WTRU 214 may detect and/or receive the code sent by the first WTRU 212. The second WTRU 214 may decode (e.g., partially or fully decode) the received code. The example open direct discovery 200 may be complete, for example, when the code is fully decoded. The second WTRU 214 may send a match report 258 to the ProSe Function 220, for example, when the code is partially decoded. A response from the ProSe Function 220 may enable the second WTRU 214 to fully decode the received code.

[0078] As shown in FIG. 2, the discovery announcement on PC5 252 may have a length of 232 bits. Table 1 presents an example discovery announcement content in 232 bits.

Tablel : Example discovery announcement on PC5

[0079] Other examples of discovery techniques may include sending a discovery message that solicits a response, referred to as Model-B discovery, WTRU-to-network relay discovery and/or group member discovery. Discovery techniques may be used in public safety and/or nonpublic safety scenarios (e.g. , a commercial application).

[0080] Model-B discovery may be referred to as "Who is there?" or "Are you there?" discovery. A discoverer WTRU may try to discover one or more discoveree WTRUs. For example, the discoverer WTRU may send a discovery message that solicits a response from the one or more discoveree WTRUs. The response may be considered an "I am out here" response.

[0081] FIG. 3 is a diagram illustrating an example of open direct discovery 300. FIG. 3 presents an example of a high level procedure for Model B. In FIG. 3, WTRU 1 310 may be a discoverer WTRU. WTRU 2 320 may be a discoveree WTRU.

[0082] As shown in FIG. 3, the discoverer WTRU 310 may send a Model-B discovery message 340. The Model-B discovery message 340 may comprise a discovery code obtained from the ProSe Function 330. The discoverer WTRU 310 may monitor for a response 348 from one or more discoveree WTRUs. For example, the discoverer WTRU 310 may monitor for any Model-B discovery response. Monitoring for a response by the discoverer WTRU 310 may be similar to monitoring by a monitoring WTRU for open discovery (e.g. , such as the second WTRU 214 of FIG. 2).

[0083] A discoveree WTRU 320 may monitor discoverer messages 342, for example, by monitoring a known code indicating a Model-B discovery request over PC5. The discoveree

WTRU 320 may have obtained 344 the known code from the ProSe Function. The discoveree

WTRU 320 may send a discovery response message 346, for example, when a message comprising a known code is detected. The discovery response message 346 may comprise a discovery code obtained from the ProSe Function 330. The discovery code in the response message may be the same or different compared to the known code in the discovery message. The Model-B discovery message 340 and/or the discovery response message 346 may be sent over PC5.

[0084] The discoverer WTRU 310 may monitor 348 for discovery responses. The discoverer WTRU 310 may detect the response 346 from the discoveree 350. A response code may be processed. The discoverer WTRU 310 may determine 350 that the response code matches (e.g. , partially matches) a known response code. The discoverer WTRU 310 may send a match report 360 to the ProSe Function 330. The discoverer WTRU 310 may send the match report 360 when a partial match occurs. The ProSe Function 330 may send a match report acknowledge (ACK) message 365 to the discoverer WTRU 310. The match report ACK message 365 may include a full code that indicates the discoveree WTRU response. The match report ACK message 365 may include metadata that indicates one or more services offered by the discoveree WTRU 320. The match report 360 and/or the match report ACK message 365 may be sent over PC3.

[0085] In WTRU-to-network relay discovery, a remote WTRU may not have network coverage. The remote WTRU may be provided with connectivity to the network via a WTRU- to-Network Relay. For example, the remote WTRU may connect to the network via another WTRU. The remote WTRU may discover the WTRU-to-Network Relay. The WTRU-to- Network Relay may relay unicast traffic between the remote WTRU and the network. For example, the WTRU-to-Network Relay may receive unicast traffic from the remote WTRU. The WTRU-to-Network Relay may send the unicast traffic to the network.

[0086] FIG. 4 is a diagram illustrating an example of WTRU-to-Network (NW) Relay discovery 400 for open direct discovery. The example WTRU-to-NW Relay discovery 400 shown in FIG. 4 may represent an example of a high level procedure of relay discovery for Model A, i.e., "I am here" discovery. An announcing WTRU 410 may send a discovery message 430, 432, 434, 436 to one or more monitoring WTRUs 420, 422, 424, 426. The discovery message 430, 432, 434, 436 may include one or more of a message type field, a discovery type field, a PLMN ID field, a connection information field, a ProSe Relay WTRU ID field, or a status information field.

[0087] FIG. 5 is a diagram illustrating an example of WTRU-to-Network (NW) Relay discovery 500 for open direct discovery. The example WTRU-to-NW Relay discovery 500 shown in FIG. 5 may represent an example of a high level procedure of relay discovery for Model B, i.e., "Who is there?" or "Are you there?" discovery. A discoverer WTRU 510 may send a discovery message 530, 532, 534, 536 to one or more discoveree WTRUs 520, 522, 524, 526. The discovery message 530, 532, 534, 536 may be a WTRU-to-NW Relay discovery message. The discovery message 530, 532, 534, 536 may include one or more of a message type field, a discovery type field, a PLMN ID field, a connection information field, a ProSe Relay WTRU ID field, or a status information field. A first discoveree WTRU 520 may send a first response message 540 to the discoverer WTRU 510. A second discoveree WTRU 522 may send a second response message 542 to the discoverer WTRU 510. The first and second response messages 540, 542 may include one or more of a message type field, a discovery type field, a PLMN ID field, a connection information field, a ProSe Relay WTRU ID field, or a status information field. For example, the discovery type field may indicate WTRU-to-NW Relay discovery. The PLMN ID field may include an identifier that indicates a PLMN for one or more radio frequencies used on a link associated with the remote WTRU. The connection information field may include one or more parameters associated with the WTRU-to-Network Relay to indicate connectivity (e.g. , APN information). The status field may indicate, for example, whether the relay is temporarily without connectivity, whether the relay has a low battery, and/or the like. One or more associated remote WTRUs may seek and/or re-select another relay, for example, based on a status field.

[0088] The UE-to-NW Relay discovery message 530, 532, 534, 536 and/or the response messages 540, 542 may be broadcast over PC5. Message content may be extended.

[0089] Unicast communication with a WTRU-to-NW relay may involve some configuration. For example, a connection may be established between a remote WTRU and a Relay WTRU.

[0090] FIG. 6 is a diagram illustrating an example unicast communication 600 with ProSe WTRU-to-NW Relay discovery for open direct discovery. The example unicast communication 600 shown in FIG. 6 may represent an example of a high level relay discovery applicable to Model A and/or Model B discovery. A relay WTRU 612 may perform an E-UTRAN attach 620 with a network. The network may include a MME 614 and/or a home subscriber server (HSS) 616. The relay WTRU 612 may request PDN connectivity 620 with the network. A remote WTRU 610 may discover 622 the relay WTRU 612 (e.g., using Model-A or Model-B discovery). The remote WTRU 610 may establish 624 a connection with the relay WTRU 612 for one-to- one (e.g., device to device) communication. The remote WTRU 610 may establish 624 the connection with or without evolved packet core (EPC) involvement (e.g. , as determined by the standards). The remote WTRU 610 and/or the relay WTRU 612 may assign 626 an IPv6 prefix for the connection. Assignment of the IPv6 prefix may include the remote WTRU 610 sending a router solicitation message 628 to the relay WTRU 612. The relay WTRU 612 may send a router advertisement message 630 to the remote WTRU 610. The router advertisement message 630 may be sent in response to the router solicitation message 628. The remote WTRU 610 and/or the relay WTRU 612 may assign an IPv4 address for the connection. The remote WTRU 610 may send a DHCPv4 discovery message 634 to the relay WTRU 612. The relay WTRU 612 may send a DHCPv4 offer message 636 to the remote WTRU 610 (e.g. , in response to receipt of the DHCPv4 discover message 634). The remote WTRU 610 may send a DHCPv4 request message 638 to the relay WTRU 612 (e.g., in response to receipt of the DHCPv4 offer message 636). The relay WTRU 612 may send a DHCPv4 ACK message 640 to the remote WTRU 610 (e.g. , in response to receipt of the request message 638).

[0091] As shown in FIG. 6, in an example call flow for ProSe WTRU-Network Relay discovery, connection establishment 624 can be carried out over a PC5 interface, for example, via an exchange of control messages, e.g. using PC5 signaling protocol (PC5-S).

[0092] In group member discovery, a group of WTRUs (e.g. , such as public safety WTRUs) may determine which group members are in proximity of a communication range at a given time.

[0093] FIG. 7 is a diagram illustrating an example group member discovery 700 for open direct discovery. The example group member discovery 700 shown in FIG. 7 may represent an example of a high level group member discovery for Model A, i.e., "I am here" discovery. An announcing group WTRU 710 may send a discovery message 730, 732, 734, 736 to one or more monitoring group WTRUs 720, 722, 724, 726. The discovery message 730, 732, 734, 736 may include one or more of a message type field, a discovery type field, an announcing group WTRU information field, or a ProSe WTRU ID field. For example, the discovery type field may indicate a Group member discovery. The ProSe WTRU ID field may indicate a link layer identifier that may be used for direct communication. The announcing group WTRU

information field may provide information about the announcing group WTRU 710 (e.g., for the application layer).

[0094] FIG. 8 is a diagram illustrating an example group member discovery 800 for open direct discovery. The example group member discovery 800 shown in FIG. 8 may represent an example of a high level procedure of group member discovery for Model B, i.e., "Who is there?" or "Are you there?" discovery. A discoverer group WTRU 810 may send a group member discovery message 830, 832, 834, 836 to one or more discoveree group WTRUs 820, 822, 824, 826. The group member discovery message 830, 832, 834, 836 may include one or more of a message type field, a discovery type field, a discoveree group information field, a discoverer group information field, or a ProSe WTRU ID field. A first discoveree group WTRU 820 may send a first response message 840 to the discoverer group WTRU 810. A second discoveree group WTRU 822 may send a second response message 842 to the discoverer group WTRU 810. The first and second response messages 840, 842 may include one or more of a message type field, a discovery type field, a discoveree group infrormation field, or a ProSe WTRU ID field. For example, the discovery type field may indicate a group member discovery. The ProSe WTRU ID field may indicate a link layer identifier that may be used for direct communication. The discoveree group information field may provide information about the discoveree group WTRU 820, 822, 824, 826. The information may include a targeted user and/or a targeted group (e.g. , for the application layer).

[0095] The group member discovery message 830, 832, 834, 836 and/or the response messages 840, 842 may be broadcast over PC5.

[0096] The discovery techniques described above may assume a relatively rigid discovery message payload, for example a fixed payload size. In order to provide a flexible payload for D2D discovery, one or more the discovery formats, one or more of the message sizes, and/or techniques related to one-way broadcast discovery may be changed or modified. Various performance improvements may be realized by relaxing discovery techniques to provide a flexible payload for D2D discovery. For example, relaxing discovery techniques may reduce latency, payload sizes may be varied statically and dynamically, discoverer and discoveree may interact during discovery and/or discovery transport mechanism and communication mechanism efficiency may be improved. A WTRU may be configured to perform discovery procedures taking into account that the pay loads may be of variable size and/or importance.

[0097] Latency (e.g. , with regard to receipt of metadata by a discoverer) may be reduced by avoiding match report and/or acknowledgment messaging over a PC3 interface. For example, when a partial match is detected (e.g. , such as in FIG. 3) a match report may be sent to the ProSe Function. Metadata may be included by the ProSe Function in the match report ACK message.

[0098] Latency in the report and/or acknowledgment messaging may occur for a variety of reasons. A Model-B discovery that may return metadata may rely on the PC3 interface. The PC3 interface may comprise the interface between the WTRU and the ProSe Function. The PC3 interface may introduce additional latency to discovery procedures. The PC3 interface may restrict the Model-B discovery to in-network coverage applications. The Model-B discovery may fail due to network congestion that prevents the WTRU from sending a match report. Congestion may become worse, for example, when the WTRU is switched from an idle mode to a connected mode. Additional signaling may be involved to establish an IP connection. The additional signaling may include an RRC connection and/or other NAS procedures. The additional signaling may further congest a congested network.

[0099] A Model-B discovery over the PC5 interface (e.g., without the PC3 interface) may reduce latency and/or failure rates for the Model-B discovery. The Model-B discovery over the PC5 interface may expand Model-B discovery (e.g. , with metadata feedback) to public safety uses.

[0100] A more efficient discovery transport may improve D2D discovery. For example, discovery transport in various discovery techniques may be improved by accommodating a larger payload size. For example, a WTRU-to-Network Relay discovery may utilize additional information that exceeds a default discovery payload size. The additional information may fit in the larger payload size.

[0101] Discovery transport in various discovery techniques may be improved by supporting a dynamic discovery payload size. For example, a discovery payload size may be flexible enough to send a TMGI and/or a cell ID between a remote WTRU and a relay WTRU. The discovery payload size may match one or more variable sizes of metadata, for example, when metadata is sent over the PC5 interface.

[0102] Discovery transport in various discovery techniques may be improved by supporting one or more interactions between a discoverer WTRU and a discoveree WTRU. A discovery announcing message may be associated with a response message, for example, in Model B discovery.

[0103] A more efficient communication transport may improve D2D discovery and/or other data exchange with varying traffic types (e.g. , signaling supporting the PC5-S interface). For example, communication transport in various discovery techniques may be improved by supporting a variable configuration. A D2D communication may rely on a transmission of a scheduling assignment (SA). The SA may be valid for the duration of a configurable scheduling period (e.g., 40ms to 320ms). The flexible set of values for the configurable scheduling period may tradeoff signaling overhead (SA) with transmission delay. Efficiency may be improved by permitting the configuration to vary for a set of resources, for example, given that a WTRU may be subject to transmission of data with various traffic characteristics (e.g. , such as VoIP with predictable traffic patterns, transmission of short control signals, and/or the like).

[0104] Communication transport in various discovery techniques may be improved by efficient decoding. For example, a WTRU, having received an SA, may attempt to decode data for the entire duration of the scheduling period. Decoding may not be needed during the entire scheduling period. Efficient decoding may avoid excessive battery usage, for example, when only a few of the received data slots (e.g., as signaled by the SA) actually carry data.

[0105] Metadata may include data that provides information about one or more aspects of other data. Metadata may refer to one or more other types of data. Metadata may include data that provides information about control data, a discovery announcement, a solicitation, a response message, and/or information data.

[0106] Various metadata transmissions may be used to reduce latency. For example, one or more devices (e.g., WTRUs) may exchange metadata directly via the PC5 interface. The one or more devices may receive metadata from a ProSe Function via the network.

[0107] A variety of metadata transmissions may be available. For example, a first WTRU may be configured to receive metadata from a PC5 interface and/or the ProSe Function.

Metadata received directly from a second WTRU via the PC5 interface may be known at the first WTRU. The metadata received directly from the second WTRU via the PC5 interface may be more dynamic in nature than metadata information known by and/or received from the ProSe Function.

[0108] For example, a WTRU may search for a service using Model-B discovery. For example, the service may be provided by a nearby restaurant. The WTRU may receive a response over the PC5 interface. The response may comprise, for example, initial and/or first service metadata. In the restaurant example, the initial and/or first service metadata may include a restaurant name, a cuisine type, a seating availability, and/or the like. Additional and/or second service metadata may be received from the ProSe Function. The additional and/or second service metadata may include a restaurant address, a phone number, a featured menu, a special of the day, opening hours, and/or the like. The initial and/or first service metadata over PC5 may comprise, for example, shorter and/or dynamic information regarding the discoveree (e.g., such as a seating availability). Additional service metadata from the ProSe Function may comprise, for example, longer and/or more detailed information regarding the discoveree (e.g. , such as a featured menu).

[0109] A WTRU may be configured to transmit and/or receive metadata over the PC5 interface for one or more services. For example, a decision to transmit metadata directly over the PC5 interface may depend on the application. The WTRU may use one or more approaches to determine whether to send and/or receive metadata over the PC5 interface. The WTRU may determine to send and/or receive metadata over the PC5 interface based on discovery message solicitation content. The WTRU may determine to send and/or receive metadata over the PC5 interface based on one or more preconfigured codes. The WTRU may determine to send and/or receive metadata over the PC5 interface based on one or more other entities. The WTRU may determine to send and/or receive metadata over the PC5 interface based on a network configuration (e.g. , via radio resource control (RRC) signaling). The WTRU may determine to send and/or receive metadata over the PC5 interface based on one or more resources used for a solicitation message.

[0110] A WTRU may determine whether to send and/or receive metadata over the PC5 interface based on discovery message solicitation content. For example, the WTRU may be pre- configured to transmit metadata over the PC5 interface when one or more specific discovery solicitation messages are detected. The one or more specific discovery solicitation messages may comprise, for example, information related to one or more special discoverer WTRUs, announcement requests, application identities, and/or the like. A discoveree WTRU may be pre- configured to exchange metadata over the PC5 interface when any model-B discovery solicitation is detected.

[0111] A WTRU may determine whether to send and/or receive metadata over the PC5 interface based on one or more preconfigured codes. For example, a discoveree WTRU may be configured by a ProSe Function over the PC3 interface with one or more known discovery codes. The WTRU may be configured to respond (e.g., transmit) with metadata over the PC5 interface, for example, upon receipt of the one or more known codes. The ProSe Function may have one or more local policies to determine which codes trigger direct transmission over the PC5 interface. The one or more local policies may be based on, for example, subscription

information, an application identity, a discovery type (e.g., Model-A, Model-B,

announcement/solicitation request and/or monitor request), an application layer identity, and/or the like.

[0112] A WTRU may determine whether to send and/or receive metadata over the PC5 interface based on one or more other entities. For example, a ProSe Function may configure one or more WTRUs to use the PC5 interface for metadata exchange based on one or more entities. The one or more entities may comprise, for example, one or more application servers, one or more 3GPP network nodes and/or one or more other WTRUs.

[0113] An Application Server may trigger PC5 metadata exchange, for example when it may be impractical and/or less efficient to carry the metadata to the ProSe Function. For example, for one or more services with frequent updates from the device, the ProSe Function and/or the device itself may determine to send metadata directly via the PC5 interface. A 3GPP network node (e.g. , a HSS or a MME) may trigger PC5 metadata exchange, for example, to alleviate network congestion and/or improve radio resource efficiency. Another WTRU may trigger PC5 metadata exchange, for example, when the other WTRU is in close proximity to the transmitting WTRU.

[0114] A WTRU may determine whether to send and/or receive metadata over the PC5 interface based on a configuration by a network (e.g. , via RRC). For example, the network may configure one or more WTRUs to use the PC5 interface, for example, via one or more system information blocks (SIBs) and/or via RRC configuration. The network configuration may trigger PC5 metadata exchange, for example, to control the amount of communication resources (e.g. , for mode 2 communications).

[0115] For example, a WTRU may be configured to request PC5 resources (e.g. , via BSR and/or via RRC) for transmission of metadata. The WTRU may be configured to indicate to the application layer, for example, when the network denies transmission of a discovery response (e.g. , to transmit metadata) via the PC5 interface. For example, the WTRU may not receive a grant after a timer has expired. The WTRU may receive an explicit indication from the network that the WTRU has not been granted PC5 resources. The application may transmit a message to the ProSe Function and/or to the application server on the network side, for example, using normal cellular communication over IP.

[0116] A WTRU may determine whether to send and/or receive metadata over the PC5 interface based on one or more resources used for a solicitation message. For example, the WTRU may be configured to transmit and/or receive metadata through the PC5 interface based on the one or more resources used for the solicitation message. The WTRU may be configured to use a designated set of resources for transmission of a discovery solicitation. The discovery solicitation may request a response to carry additional metadata over the PC5 interface. The discovery solicitation may be implicitly determined as a request to carry additional metadata over the PC5 interface using specific transmission parameters. For example, a specific hopping pattern and/or a specific discovery period may indicate such the request to carry additional metadata over the PC5 interface.

[0117] A direct transport message (e.g., PC5 message) may be used to support data exchange between two or more WTRUs. Although the following is described in the context of discovery transmission, the efficient direct transport may be applicable to the exchange of multiple types of data, such as metadata, control information, other broadcast, multicast information, application layer data (e.g. , V2x CAM messages or other messages), discovery announcements, solicitation messages, and/or response messages. Control information (e.g., PC5-S signaling data) may comprise unicast control information between D2D WTRUs. Other broadcast and/or multicast control information may comprise relay-related information, such as TMGI

announcements/requests and/or ECGI announcements/requests.

[0118] Discovery techniques may be designed and/or modified to support flexible transport. One or more modifications may use extensions and/or other modifications of discovery and/or communication. [0119] D2D discovery may support flexible discovery payload sizes. Transmission and/or reception of discovery transport block sizes (TBSs) may have different dimensions (e.g., larger or smaller, than a fixed TBS, such as 232 bits). A WTRU may be configured to use one or more transport blocks having fixed and/or variable TBSs to carry a payload (e.g., such as a discovery payload).

[0120] For example, a WTRU may be configured with one or more discovery transport formats that provide variable TBSs. A discovery transport format may refer to the transmission format used for transmitting a PC5 message. The WTRU may be configured, for example, with a discovery transport format table with one or more entries representing various TBS dimensions for discovery payloads, which may be associated with transport formats. Table 2 is an example variable TBS table for discovery payload. The WTRU may be configured to select an appropriate transport format to send a discovery message. For example, the WTRU may select a transport format that matches a discovery payload received from the application.

Table 1: Example Transport block size table for discovery payload

[0121] For example, selecting a proper transport format may depend on the actual data being carried by the discovery payload. For example, a WTRU may be configured to determine a discovery payload format based on the discovery payload. A set of discovery payload formats may be characterized by the content of discovery payload. Table 3 is an example of a discovery payload format table with several example fields, such as discovery model and system-related signaling type. For example, as shown in Table 3, a choice of discovery content index may be 2 when a WTRU is configured to carry encrypted metadata in Model-B discovery.

Table 2: Example Discovery payload index table

[0122] For example, there may be a relationship between a discovery payload format and a discovery transport format. Each discovery payload format in multiple formats may be associated with a discovery transport format. An association of discovery payload format to discovery transport format may, for example, be one-to-one to eliminate ambiguity in the selection of a discovery payload format in response to a discovery transport format.

[0123] A WTRU may be configured to send a discovery message with a segmented payload. For example, more than one transport block (TB) may be used to transmit discovery messages. As an example, multiple segments of a discovery payload may be transmitted in multiple TBs. Each of the multiple TBs may have a fixed and/or variable TBS dimension. In an example, each of the multiple TBs may be transmitted multiple times (e.g., repetition to facilitate reception by the discovery peer).

[0124] FIG. 9 is an example of a discovery message with a discovery payload having multiple transport blocks. For example, one or more of the multiple (e.g., three in this example) TBs in the discovery payload may have a fixed TBS dimension (e.g. , 376 bits).

[0125] A number of discovery payload segments (N) may be dynamically adjusted. For example, the number of discovery payload segments (N) may be dynamically adjusted based on a discovery payload size. A WTRU may be configured to determine the number of segments. For example, the WTRU may determine the number of segments based on the discovery payload, available fixed TBSs, and/or variable TBSs.

[0126] FIG. 10 is an example of a discovery message with a discovery payload having multiple transport blocks where the number of discovery payload segments may be dynamically adjusted. For example, one or more TBs among multiple (N) TBs in the discovery payload may have a fixed TBS dimension (e.g., 232 bits).

[0127] For example, the number of transport blocks may be pre-determined. The TBS (M) of the one or more transport blocks may be dynamically adjusted.

[0128] FIG. 11 is an example of a discovery message with a discovery payload having multiple transport blocks with a pre-determined number of transport blocks having dynamically adjusted TBS dimensions. For example, one or more of the multiple TBs in the discovery payload may have a dynamically adjustable TBS dimension (e.g. , M bits).

[0129] A WTRU may be configured to send a discovery message using one or more transport blocks (e.g., such as a basic TB) along with one or more transport blocks of a different size (e.g., such as an extension TB). For example, the number of basic TBs and/or extension TBs may be fixed. TBS dimension(s) may be dynamically selected, for example, from a TBS table. [0130] FIG. 12 is an example of a discovery message with a discovery payload having multiple transport blocks with different TBS dimensions. For example, a first (e.g. , basic) group of TBs may have a first TBS dimension, Ml bits. A second (e.g. , extension) group of TBs may have a second TBS dimension, M2 bits. The number of TBs and/or TBS dimensions may be statically or dynamically selected.

[0131] For example, TBS dimension(s) of one or more various (e.g., basic and/or extension) transport blocks may be fixed. The number of the one or more various transport blocks may be dynamically adjusted, for example, according to the discovery message sizes.

[0132] FIG. 13 is an example of a discovery message with a discovery payload having multiple transport blocks with different TBS dimensions. For example, a variable number M first (e.g., basic) TBs may have a first TBS dimension of 232 bits. A variable number N second (e.g. , extension) TBs may have a second TBS dimension of 114 bits. The number of TBs and/or TBS dimensions may be statically or dynamically selected.

[0133] Regardless of example or implementation, the number of PRBs may be configured to be fixed or dynamic.

[0134] One or more resources may be allocated for multiple discovery payload segments. A WTRU may determine whether to transmit and/or retransmit a transport block based on a single check of an access-related random value, for example, when a WTRU is configured to use a single segment (e.g., without segmentation) of the discovery payload.

[0135] FIG. 14 is an example of a transmission 1400 of a discovery payload with a single transport block. A WTRU may be configured to use a single segment of a discovery payload. For example, a first discovery payload 1406 may be transmitted during a first discovery period 1404. The first discovery payload 1406 may use one or more resources in a first transport block. A first random resource selection 1402 may be performed for transmission of the first discovery payload 1406. The first random resource selection 1402 may assign one or more resources for the first discovery payload 1406. A second discovery payload 1416 may be transmitted during a second discovery period 1414. The second discovery payload 1416 may use one or more resources in a second transport block. A second random resource selection 1412 may be performed for the second discovery payload 1416. The second random resource selection 1412 may assign one or more resources for transmission of the second discovery payload 1416. A transmission of a transport block may be configured with one or more (e.g. , three) retransmissions. An access-related random value may be generated and/or checked, for example, at the beginning of each transmission and/or re-transmission. A resource may be selected (e.g. , randomly selected) among one or more available resource pool(s) for a (e.g., first) transmission of a single segment, for example, when a selected (e.g. , random) value meets and/or exceeds (e.g. , above or below) a predetermined threshold. A deterministic transmission pattern may be based on a previously selected random resource. The deterministic transmission pattern may be used for one or more re-transmissions.

[0136] A WTRU may be configured to use a set of resources. The WTRU may use the set of resources to permit a receiving WTRU to re-assemble (e.g., in a relatively efficient manner), for example, when transmitting multiple discovery payload segments.

[0137] A WTRU transmission check may be applicable to multiple (e.g., all) segments in a discovery payload. A segment in a discovery payload may comprise one or more transport blocks. For example, a (e.g., each) transport block may be a segment of a discovery payload. A WTRU may transmit multiple (e.g. , all) segments of a discovery payload, for example, based on a single check of an access-related (e.g., random) value. A single random value may be denoted i. The WTRU may be configured to transmit multiple (e.g. all) segments of a discovery payload, for example, when pi is uniformly distributed between 0 and 1 and/or exceeds (e.g. , is above or below) a predetermined threshold. A transmission of multiple (e.g., all) segments of a discovery payload may be performed without a further check of the access-related random value i. One or more transmissions may occur during one or more discovery periods.

[0138] One or more random resources may be selected for multiple discovery segments. For example, random resource selection may be applied for a (e.g., first) transmission of a (e.g. , first) segment and/or transport block. One or more resources for re-transmissions and/or other (e.g. , second, third, etc.) segments and/or transport blocks may be determined (e.g. , derived) from the selection of the one or more random resources, for example, in a deterministic way. A single draw of a random value may determine the one or more resources to use for transmissions and/or retransmissions of multiple (e.g. , all) segments associated with a discovery message.

[0139] FIG. 15 is an example of a transmission 1500 of multiple discovery segments that may rely on a single transmission check. For example, one or more (e.g., three) discovery segments 1502, 1504, 1506 may be transmitted in a discovery period 1508. Transmission and/or retransmission for each of the one or more segments may be determined based on (e.g. , derived from) a random selection 1510.

[0140] For example, a random resource selected may be applied for a (e.g., first) transmission of a (e.g. , first) transport block. One or more other (e.g. , such as subsequent, deterministic and/or derived) resources may be used for a (e.g. , first) transmission of a (e.g. , second) transport block, and/or a (e.g., first) transmission of another (e.g. , third) transport block, etc. [0141] FIG. 16 is an example of a transmission of multiple discovery segments 1602, 1604, 1606 that may rely on a single transmission check. For example, a first transmission 1612, a first retransmission 1614, a second retransmission 1616 and/or a third retransmission 1618 may be sent in a discovery period 1608. The first transmission 1612, the first retransmission 1614, the second retransmission 1616, and/or the third retransmission 1618 may be determined based on (e.g. , derived from) a random selection 1610.

[0142] For example, a single random value pi may be associated with multiple segments of discovery payloads (e.g., such as discovery segments 1602, 1604, 1606) that span one or more discovery periods. One or more resources for re-transmissions that may span one or more discovery periods may be determined (e.g. , derived), for example, from the first selected random resource, e.g. , in a deterministic manner.

[0143] A discovery transmission pattern may be repeated for multiple segments of a discovery payload. The discovery transmission partem may characterize one or more resources used for the discovery payload having a (e.g., one) transport block, which may be referred to as a single segment. The discovery transmission pattern (e.g., an overall pattern) may rely on one or more repetitions in a transmission pattern employed for a single segment. For example, when a WTRU is configured to transmit multiple segments of a discovery payload, which may have a larger size, the discovery transmission pattern may be determined based on one or more repetitions. A discovery transmission pattern that is being repeated (e.g., for multiple segments of a discovery payload) may include a pattern employed for a (e.g., first) transport block and/or one or more re-transmissions of the transport block. A repeated discovery transmission pattern (e.g. , for multiple segments of a discovery payload) may be a transmission (e.g. , a first transmission) of multiple (e.g. , all) transport blocks. One or more repetitions may apply to discovery payloads that span one or more discovery periods.

[0144] Multiple discovery payload segments may be reassembled. The multiple discovery payload segments may be reassembled, for example, based on a transmission partem. A WTRU receiving a discovery message may be configured, for example, to determine a set of discovery segments belonging to the discovery message. The set of discovery segments may include multiple discovery payload segments. The WTRU may determine the set of discovery segments based on a pre-defined association between one or more resources used for transmission of the set of discovery segments. For example, the WTRU may determine the set of discovery segments based on a single selected value of pi for the multiple (e.g. , all) discovery segments of the discovery message. An order of the set of discovery segments may be determined. For example, the order of the set of discovery segments may be determined based on a transmission order and/or a pre-defined time-sequence. A receiving WTRU may determine that a set of segments belong to a discovery message. The receiving WTRU may pass the set of segments belonging to the discovery message to one or more higher layers (e.g., for reassembly in an appropriate order).

[0145] Multiple discovery payload segments may be reassembled, for example, based on a destination ID. The multiple discovery payload segments may be reassembled, for example, based on an indication to identify one or more MAC PDUs belonging to an RLC and/or PDCP PDU. For example, a transmitting WTRU may indicate (e.g. , explicitly indicate) an identity of a source of a discovery message. The identity of the source of the discovery message may be indicated, for example, in an L2 header (e.g. , RLC, MAC or PDCP) and/or at one or more higher layers. A receiving WTRU may assemble one or more discovery segments from a source, for example, based on an order received. For example, the one or more discovery segments may be numbered (e.g. , explicitly). The numbering of the one or more discovery segments may permit the receiving WTRU to assemble the one or more discovery segments in order (e.g., regardless of the order that the one or more discovery segments are received).

[0146] A discovery payload transport format may be determined. There may be one or more discovery transport formats. Detection of a discovery message may rely on monitoring various, e.g. , one or more, resource patterns over a given set of resource pools. The one or more discovery transport formats may be determined, for example, by blind detection, explicit control information, explicit configuration and/or resource pool configuration.

[0147] A discovery payload transport format may be determined by blind detection. A WTRU may be configured with one or more discovery transport formats. The WTRU may use blind discovery format detection to detect potential discovery messages. For example, the WTRU may be pre-configured to search over a limited number of resources for one or more transport formats, which may simplify operation.

[0148] A discovery payload transport format may be determined by explicit control information. A WTRU may indicate one or more configurations explicitly via a transmission of control information, for example, when multiple transport blocks are employed. For example, a first transport block transmitted by the WTRU may carry the control information. The control information may be sent using a preconfigured format and/or one or more transmission characteristics. A receiving WTRU may determine the one or more transmission characteristics for a discovery message, for example, by decoding the content of the control information.

[0149] A discovery payload transport format may be determined based on an explicit configuration. A WTRU may be configured, for example, to rely on a Physical Sidelink Broadcast Channel (PSBCH) to indicate the discovery payload transport format being used. An indication may be included in system and/or synchronization related information transmitted from the WTRU through the PSBCH.

[0150] A discovery payload transport format may be determined based on a resource pool configuration. A discovery resource pool may be associated with a discovery transport format. A WTRU may be configured to transmit a discovery message using a discovery payload transport format associated with the resource pool. The WTRU may be configured to select a resource pool, for example, based on a discovery payload format and/or a discovery transport block size.

[0151] A WTRU may be configured with one or more resource pools. A resource pool may be associated with a discovery transport format. For example, a WTRU may select a resource pool associated with a transport format that supports the discovery payload format received from the application layer. A WTRU receiving data in a resource pool may, for example, determine the discovery transport format. The WTRU may decode (e.g., attempt to decode) the received data according to an associated transport format.

[0152] A WTRU may indicate additional information in a scheduling assignment (SA), for example, in support of flexible data exchange. A D2D communication mechanism may have the flexibility to carry data having variable sizes.

[0153] A transmitting WTRU may be configured to indicate transmission information in a scheduling period to a receiving WTRU. Indicating transmission information may improve battery life of one or more WTRU receivers, for example, by having advance knowledge of transmissions. For example, using the advance knowledge, a receiving WTRU may improve efficiency of D2D resources during a scheduling period. One or more resources may be allocated for all or a portion of a scheduling period as indicated in the transmission information. The receiving WTRU may, for example, turn off (e.g. , power down) a receiving capability (e.g. , a receiver or a portion of its receiving circuit) during the times in the scheduling period when no data is to be received as determined based on the transmission information.

[0154] Transmission information may be explicit. A WTRU may receive, for example via the SA and/or MAC header, an indication of a duration of transmission during a scheduling period. For example, a WTRU may be configured with a specific count value. The specific count value may represent, for example, a number of transmissions (e.g. , MAC PDUs), D2D subframes, T-RPTs, and/or time (e.g., in milliseconds). A receiving WTRU may update a counter accordingly (e.g., every MAC PDU period, D2D subframe, T-RPT, etc.). The receiving WTRU may update the counter until it reaches the specific count value. The WTRU may be configured to stop monitoring and/or decoding, for example, when a count is reached (e.g. , given that the transmitting WTRU indicated it, it would cease transmitting data for the remainder of a scheduling period).

[0155] A transmitting WTRU may be configured to determine a duration of transmission. The transmission may be a transmission to a receiving WTRU. For example, the transmitting WTRU may determine a number of total transmissions, subframes (e.g., considering the T-RPT used) and/or time. The determined duration of transmission may include an allotment for one or more potential re-transmissions. The duration of transmission may be determined, for example, based on a size of an information message (e.g. , such as a CAM message or another type of message), a buffer size and/or a WTRU configured grant, e.g., via (e)PDCCH and/or a preconfiguration. The transmitting WTRU may send an indication of the duration of transmission. For example, the transmitting WTRU may send an indication of a number of transport blocks in the transmission. The indication of the number of transport blocks may be included in an SA and/or a MAC header. The indication of the number of transport blocks may include one or more of a number of T-RPTs, MAC PDUs, subframes, or milliseconds.

[0156] In an example of providing a count value and/or other transmission information, a WTRU may indicate transmission information (e.g. , such as a count value) explicitly in the SA. The SA may include one or more transmission information bit fields. The transmission information may be indicated in the one or more transmission information bit fields in the SA. The transmission information may be embedded in a MAC header. For example, a WTRU may provide the transmission information in the MAC header of a first MAC PDU transmission. The transmission information may be carried in one or more (e.g., all) MAC PDUs, for example, to improve the probability that the transmission information is received (e.g., accurately received) by a WTRU receiver. The transmission information may be adjusted in a subsequent MAC PDU to account for the reduced remaining time of the transmission.

[0157] A WTRU may be configured to determine (e.g. , blindly determine) an SA format, for example, given that an SA may have a different transmission size (e.g. due to the added information field). For example, the SA format may be determined based on a fixed set of allowed formats. The SA format may be associated with the resource pool.

[0158] A first WTRU (e.g., a transmitting WTRU) may determine a time offset for a D2D transmission to a second WTRU. The time offset may be determined based on a duration of the D2D transmission. The first WTRU may determine the duration of the D2D transmission. The time offset may be determined based on a number of MAC PDUs to transmit. The time offset may be determined based on a duration of the scheduling period. The time offset may be determined based on a number of retransmissions configured. The time offset may be determined based on one or more T-RPT characteristics. The one or more T-RPT characteristics may include the number of transmissions out of a fixed number of opportunities (e.g., k=2 transmissions out of N=8 opportunities). For example, the first WTRU may determine the duration of the D2D transmission. The time offset may be determined on a random basis. For example, the first WTRU may randomly select the time offset. The time offset may be determined based on a group destination identification (ID). For example, a subset of bits from the group destination ID may indicate the time offset. The time offset may indicate a transmission start time. The transmission start time may be a time when the D2D transmission starts within a scheduling period. The first WTRU may send an SA that includes an offset (e.g., a time offset) parameter. The offset parameter may randomize interference in time. The time offset may indicate a data transmission start time within a scheduling period. The time offset may be combined with a transmission duration. For example, the first WTRU may send the transmission duration to the second WTRU. A WTRU may save battery power by attempting to decode data when it knows data is present while avoiding decoding when data is not present.

[0159] A time offset parameter may be selected to transmit data during a scheduling period. For example, the time offset parameter may be selected based on the amount of data to be transmitted, an expected time required to transmit the amount of data to be transmitted, remaining time towards the end of the scheduling period, and/or the like. For example, the time offset parameter may be represented by one or more of a number of T-RPT, MAC PDUs, (D2D) subframes, milliseconds, etc. A transmitting WTRU may indicate a time offset parameter in the SA. A WTRU may receive a time offset parameter in the SA. The WTRU may be configured to receive and/or decode information at a time after the start of the scheduling period as indicated by the time offset parameter.

[0160] Data may be known to be sent and/or received at a particular time within a scheduling period. The particular time may start at a time other than the beginning of the scheduling period. Transmission information may improve efficiency and/or decrease interference, for example, when more than one WTRU is sending data over the PC5 interface. The WTRU may select a random time offset value uniformly within a set of allowed time offset values. The set of allowed time offset values may include one or more time offsets which allow the WTRU to empty its buffer within one scheduling period, for example according to the expected time for transmission of the data. For example, the WTRU may determine the time offset on a random bases from the set of allowed time offset values. The set of allowed time offset values may include one or more time offset values for which the WTRU can transmit data in its buffer (e.g., buffered data) within the duration of the scheduling period.

[0161] For example, a transmitting WTRU may be configured to indicate (e.g., implicitly indicate) a number of transmissions that a receiving WTRU should expect in an upcoming scheduling period. The receiving WTRU may determine the number of transmissions to expect in the upcoming scheduling period. For example, the number of transmissions to expect in a scheduling period (e.g. , a count value) may be preconfigured and/or otherwise fixed based on one or more specifications. For example, the number of transmissions in the scheduling period may be 1 for certain cases and/or under certain circumstances. The transmitting WTRU may be configured to indicate that a preconfigured number of (e.g., PDU) transmissions will be sent in an upcoming scheduling period by using one or more of the following.

[0162] For example, the transmitting WTRU may be configured to indicate (e.g., implicitly indicate) a number of transmissions to expect in an upcoming scheduling period using one of a set of preconfigured resources the transmitting WTRU uses for transmission. The receiving WTRU may determine the number of transmissions to expect in the upcoming scheduling period based on a preconfigured resource used for the transmission. For example, a WTRU may be configured with one or more sets of D2D communications resource pools. For example, each D2D communications resource pool may be configured for using a fixed number of

transmissions. The one or more sets of D2D communications resource pools may be associated with different types of traffic and/or messages. The receiving WTRU may determine the number of transmissions to expect for the D2D communications resource pool based on the type of traffic being transmitted in the pool (e.g., such as discovery messages, TMGI/ECGI

announcements, V2x CAM messages, etc.). The transmitting WTRU may be configured to use one or more resources with the predefined fixed number of transmissions. When using the one or more resources for transmission, the WTRU may be configured to transmit the preconfigured number of transmissions associated with the pool. The WTRU receiving over those resources may be configured to monitor for the preconfigured number of transmissions.

[0163] For example, the transmitting WTRU may be configured to indicate (e.g., implicitly indicate) a number of transmissions to expect in an upcoming scheduling period based on an identifier in the SA. For example, the group destination ID in the SA may indicate that the number of transmissions is fixed and/or preconfigured. For example, the WTRU may be configured with one or more special destination IDs that are associated with a fixed and/or a predefined number of transmissions for a scheduling period. The one or more special destination IDs may be used for example for indicating one or more broadcast discovery messages (e.g. , announcements, solicitation, responses) or other types of short messages (e.g. , TMGI/ECGI announcements, V2x CAM messages, and/or the like). The transmitting WTRU may be configured to use the one or more special destination IDs for example when transmitting special messages and/or message types. The transmitting WTRU may perform the number of transmissions in accordance with the predefined fixed number of transmissions associated with the one or more special destination IDs. Upon reception of the one or more special destination IDs, the receiving WTRU may determine the number of transmissions in the scheduling period. The receiving WTRU may monitor for an appropriate predefined number of transmissions based on the one or more special destination IDs.

[0164] For example, the transmitting WTRU may be configured to indicate (e.g., implicitly indicate) a number of transmissions to expect in an upcoming scheduling period based on one or more parameters in an SA. The receiving WTRU may determine the number of transmission to expect in the upcoming scheduling period based on the one or more parameters in the SA. The one or more parameters in the SA may be associated with a fixed and/or predefined number of transmissions for a scheduling period. The one or more parameters may be used to indicate the use of a fixed number of transmissions for a scheduling period.

[0165] For example, the transmitting WTRU may be configured to indicate (e.g., implicitly indicate) an offset (e.g. , a time offset) parameter for transmissions. For example, the offset parameter may be indicated using one or more fields and/or parameters in the SA. For example, a time offset parameter may be determined by associating a time offset value with a destination ID, or a portion of a destination ID. For example, the time offset value may be linked and/or associated with the group destination ID or a portion of the group destination ID. The association between the time offset value and the group destination ID may be pre-configured. For example, each group destination ID may correspond to a specific time offset value (e.g. , based on a predefined relationship). In another example, a subset of destination IDs may be associated with one or more predetermined offset values. The time offset parameter may be determined from the group destination ID via a special relation and/or function (e.g. , via a modulo operation of the group destination ID with a maximum number of transmissions in a scheduling period). In another example, a number of bits from the group destination ID may indicate the time offset value (e.g., the 4 LSB). The remaining bits may indicate the actual group destination ID.

[0166] A transmitting WTRU may indicate that a transmission is terminated or about to be terminated for a scheduling period. The WTRU may indicate that the transmission is terminated or about to be terminated to indicate a transmission duration to a receiving WTRU.

[0167] A termination indication may be indicated, for example, by including a control message (e.g. , an early termination message) in the MAC layer (e.g., in the MAC header). A transmitting WTRU may, for example, include the control message in the MAC header of the last MAC PDU to be transmitted during a scheduling period. The control message may indicate, for example, the last MAC PDU and that the transmissions may stop after transmission of the last MAC PDU is completed. The control message may indicate, for example, that the transmission may stop after completion of an upcoming (e.g., future) MAC PDU. For example the control message may indicate that the transmission may stop after transmission of the next MAC PDU. In another example, a non-increasing count value indicating the number of remaining MAC PDUs to be transmitted in a scheduling period may be indicated in the control message (e.g. , in the MAC header of the control message). The receiving WTRU may determine the expected termination time based on the non-increasing count value. For example, in order to reduce the overhead, the count value may include a maximum number of bits (e.g. , 2). The WTRU may set the maximum value of the count value when the count value would be larger than the bit field can represent. A termination indication may be included in a MAC header, for example, in consideration of potential delays in header processing time at one or more receiving WTRUs. A receiving WTRU may respond to a termination indication, for example, by stopping monitoring of possible resource patterns. The receiving WTRU may stop monitoring, for example, starting at a D2D subframe. The D2D subframe may be indicated in the termination indication. The D2D subframe may be determined based on the termination indication.

[0168] A WTRU may be configured to select a resource pool with an appropriate scheduling period to transmit the data.

[0169] A WTRU may be configured with a set of resource pools, which may have different scheduling periods. Access to different scheduling periods may permit data to be exchanged between WTRUs more efficiently during a scheduling period. One or more round-trip communication delays may be reduced using different scheduling periods, which may facilitate handshaking between WTRUs.

[0170] A WTRU may be configured to select a resource pool, for example, based on one or more characteristics of the data that the WTRU transmits. For example, the WTRU may determine the resource pool based on one or more of a data delay requirement, an amount of data to transmit, a traffic type (e.g. , VoIP, Video, FTP, control, V2x, and/or the like), and/or application versus control.

[0171] For example, a WTRU may be configured to select a specific resource pool with a particular (e.g. , shorter) scheduling period to fulfill potential delay requirements, for example, when the WTRU determines that the data is control-related signaling. The WTRU may be configured to select a resource pool with a particular (e.g., longer) scheduling period to accommodate a length of the information, for example, when data comprises a message having a larger size. The WTRU may select a resource pool with a particular (e.g., longer) scheduling period, for example, when the traffic is VoIP.

[0172] One or more transmissions may be delay-sensitive. Transmission of a discovery payload with delay requirements may be expedited. Transmission of the discovery payload may be delayed, for example, due to higher priority WAN traffic preventing transmission of the discovery payload, due to a sequence of failure of the access-related random value and/or or other reasons. One or more approaches may be used in any order or combination to mitigate transmission delays, e.g., when a discovery payload has a latency requirement. The one or more approaches may be applicable to one or more types of discovery message (e.g. , including V2x messages).

[0173] For example, a WTRU may be configured with a different set of parameters when transmitting discovery payload with latency requirements. The WTRU may be configured to transmit a delay-sensitive discovery payload with a higher priority than WAN traffic. The WTRU may be configured with a different tx-Probability value and/or one or more different random variable functions associated with a delay sensitive discovery payload, e.g., to improve probability of transmission at any discovery occasion.

[0174] For example, a WTRU may be configured with a timer. The timer may be associated with one or more discovery messages and/or payloads. The timer may be defined in terms of absolute time, in terms of discovery periods, and/or the like.

[0175] A WTRU may be configured to start a timer, for example, based on a payload latency requirement. The WTRU may be configured to start the timer, for example, when a WTRU generates a discovery payload for transmission (e.g., a delay sensitive payload). The WTRU may stop and/or reset the timer, for example, when the WTRU successfully transmits the discovery payload. The WTRU may be configured to perform one or more actions, for example, when a timer expires and the discovery payload has not yet been transmitted. The one or more actions that may be performed may include, for example, forcing transmission of the discovery payload, indicating one or more failures to higher layers and/or dropping a payload (e.g. , stopping further attempts to transmit a payload).

[0176] Transmission of a discovery payload may be forced. A WTRU may be configured to use one or more approaches in any order or combination, e.g. , to improve the probability of transmission success. Transmission may be prioritized. A WTRU may be configured, for example, to force a transmission of a discovery payload. Transmission may be forced, for example, regardless of WAN priority and/or a state of an access-related random variable. A value of an access-related random variable threshold may be biased. A WTRU may be configured, for example, with additional (e.g. , a second and/or a third) tx-Probability values. A WTRU may be configured to use an additional value of the tx-Probability threshold, for example, when a timer expires, to improve the chances of success for an access-related random variable. A different access-related random function may be used. A WTRU may be configured, for example, with a different random function and/or a random function with different parameters. A different random function and/or a random function with different parameters may be used, for example, when the timer expires, to improve the chances of success for an access-related random variable. For example, a range of a uniformly distributed random function may be updated from [0, 1] to, for example, [0, a], where a < 1. A random value pi may be chosen from a uniformly distributed function. A WTRU may be pre-configured with a non-uniformly distributed random function. A pre-configuration may be based on, for example, different traffic/service types, QoS requirements, (group) priorities, subscriptions, etc., associated with a WTRU.

[0177] Systems, methods, and instrumentalities have been disclosed for applying flexible D2D discovery. Flexible D2D discovery may provide flexible D2D discovery and/or communication (e.g., PC5 interface and ProSe Function over network), for example, based on one or more of a content in a discovery message, a discovery code, a type of entity, a network configuration, a resource used for a discovery message, etc. Flexible D2D discovery may provide a flexible D2D message payload size, for example, with a variable size single transport block or multiple fixed and/or variable size transport blocks. Flexible D2D discovery may provide flexible message payload formats associated with multiple transport block sizes and/or types of payload content. Flexible D2D discovery may provide flexible payload support, such as by providing a transmission duration, a termination, and/or an offset in a D2D scheduling period. Flexible D2D discovery may include selecting a resource pool associated with a scheduling period from a plurality of associated resource pools and/or scheduling periods. One or more resources for retransmissions of a segment in a payload and/or for different segments in the payload may be based on (e.g. , derived deterministically from) a single (e.g. , random) resource selection value. Multiple segments may be reassembled based on association with one or more transmission resources allocated based on the single resource selection value. Delay-sensitive D2D payload transmission may be expedited, for example, by configuring a WTRU differently for delay-sensitive and non-delay-sensitive payloads. The WTRU may configured differently, e.g. , by assigning one or more of a different priority, a different transmission probability, a timer, by applying a bias to an access-related random variable threshold and changing a function and/or parameters of a function to generate an access-related random variable.

[0178] The processes and instrumentalities described herein may apply in any combination, may apply to other wireless technologies, and for other services.

[0179] A WTRU may refer to an identity of the physical device, or to the user's identity such as subscription related identities, e.g., MSISDN, SIP URI, etc. WTRU may refer to application- based identities, e.g. , user names that may be used per application.

[0180] The processes described above may be implemented in a computer program, software, and/or firmware incorporated in a computer-readable medium for execution by a computer and/or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted over wired and/or wireless connections) and/or 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, but not limited to, internal hard disks and removable disks, magneto-optical media, and/or optical media such as CD-ROM disks, and/or digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a UE, terminal, base station, RNC, and/or any host computer.

Claims

CLAIMS What is Claimed:

1. A method of device to device (D2D) communication, the method comprising:

a first wireless transmit/receive unit (WTRU) determining a duration of a transmission to a second WTRU within a scheduling period;

the first WTRU determining a time offset for the transmission based on the determined duration, wherein the time offset indicates a transmission start time when the transmission starts within the scheduling period; and

the first WTRU sending a scheduling assignment that includes a time offset parameter, the time offset parameter indicating the transmission start time.

2. The method of claim 1 , wherein the time offset is determined on a random basis from a set of allowed time offset values.

3. The method of claim 2, wherein the set of allowed time offset values comprises one or more time offset values for which the first WTRU can transmit data in its buffer within the scheduling period.

4. The method of claim 1, wherein the time offset is determined based on a group destination identification (ID).

5. The method of claim 4, wherein a subset of bits from the group destination ID indicate the time offset.

6. The method of claim 1 , wherein the time offset parameter comprises one or more of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

7. The method of claim 1, further comprising the first WTRU sending an indication of a number of transport blocks in the transmission.

8. The method of claim 7, wherein the indication of the number of transport blocks is included in one or more of the scheduling assignment or a medium access control (MAC) header.

9. The method of claim 7, wherein the indication of the number of transport blocks comprises one or more of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

10. The method of claim 1 , further comprising:

the first WTRU selecting resources for the transmission; and

the first WTRU sending buffered data in the transmission during the scheduling period according to the time offset.

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

a processor configured to:

determine a duration of a transmission to a second WTRU within a scheduling period;

determine a time offset for the transmission based on the determined duration, wherein the time offset indicates a transmission start time when the transmission starts within the scheduling period; and

send a scheduling assignment that includes a time offset parameter, the time offset parameter indicating the transmission start time.

12. The first WTRU of claim 11, wherein the time offset parameter is determined on a random basis from a set of allowed time offset values.

13. The first WTRU of claim 12, wherein the set of allowed time offset values comprises one or more time offset values for which the first WTRU can transmit data in its buffer within the scheduling period.

14. The first WTRU of claim 11, wherein the time offset parameter is determined based on a group destination identification (ID).

15. The first WTRU of claim 14, wherein a subset of bits from the group destination ID indicate the time offset.

16. The first WTRU of claim 11, wherein the time offset parameter comprises one or more of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

17. The first WTRU of claim 11, wherein the processor is further configured to send an indication of a number of transport blocks in the transmission.

18. The first WTRU of claim 17, wherein the indication of the number of transport blocks is included in one or more of the scheduling assignment or a medium access control (MAC) header.

19. The first WTRU of claim 17, wherein the indication of the number of transport blocks comprises one or more of a number of time resource pattems (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

20. The first WTRU of claim 11, wherein the processor is further configured to:

select resources for the transmission; and

send buffered data in the transmission during the scheduling period according to the time offset.

21. A method of device to device (D2D) communication, the method comprising:

a first wireless transmit/receive unit (WTRU) receiving a scheduling assignment associated with a transmission with a second WTRU, wherein the scheduling assignment includes a time offset parameter that indicates a transmission start time when the transmission starts within a scheduling period; and

the first WTRU determining to receive, at the transmission start time, data from the second WTRU during the scheduling period.

22. The method of claim 21, further comprising the first WTRU turning off a receiving capability before the transmission start time within the scheduling period.

23. The method of claim 21, wherein the time offset parameter comprises one or more of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

24. The method of claim 21, further comprising the first WTRU receiving an indication of a number of transport blocks in the transmission.

25. The method of claim 24, wherein the indication of the number of transport blocks is included in one or more of the scheduling assignment or a medium access control (MAC) header.

26. The method of claim 24, wherein the indication of the number of transport blocks comprises one or more of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

27. A first wireless transmit/receive unit, the first WTRU comprising:

a processor configured to:

receive a scheduling assignment associated with a transmission with a second WTRU, wherein the scheduling assignment includes a time offset parameter that indicates a transmission start time when the transmission starts within a scheduling period; and

determine to receive, at the transmission start time, data from the second WTRU during the scheduling period.

28. The first WTRU of claim 27, wherein the processor is further configured to turn off a receiving capability before the transmission start time within the scheduling period.

29. The first WTRU of claim 27, wherein the time offset parameter comprises at least one of a number of time resource patterns (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.

30. The first WTRU of claim 27, wherein the processor is further configured to receive an indication of a number of transport blocks in the transmission.

31. The first WTRU of claim 30, wherein the indication of the number of transport blocks is included in one or more of the scheduling assignment or a medium access control (MAC) header.

32. The first WTRU of claim 30, wherein the indication of the number of transport blocks comprises one or more of a number of time resource pattems (T-RPTs), medium access control (MAC) protocol data units (PDUs), subframes, or milliseconds.