Discovery based on 5G prose service

Abstract

Methods and apparatuses for discovery based on Proximity Services (ProSe) services are described herein. For example, a service utilizing wireless transmit / receive unit (SU-WTRU) can be provisioned with a per-service discovery type and a per-service security credential. The SU-WTRU can transmit (315) a PC5 discovery message with the discovery type and a first security element generated based on the security credential. The WTRU can then receive (325) a PC5 discovery response message from a service providing wireless transmit / receive unit (SP-WTRU) including a second security element and a service identity associated with a service provided by the SP-WTRU. Upon verifying the second security element based on the provisioned security credential, the SU-WTRU can authorize (330) the SP-WTRU to establish a PC5 communication link with the SP-WTRU.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 932,320, filed November 7, 2019, the contents of which are hereby incorporated by reference herein. BACKGROUND

[0003] Proximity-based Services (ProSe) is a device-to-device (D2D) technology that allows wireless devices to detect each other and communicate directly. In Long Term Evolution (LTE), ProSe discovery is assisted by a ProSe Function in the core network. For example, a discovery code is assigned to a peer wireless transmit / receive unit (WTRU) and converted to a service or service name / ID by the ProSe Function. In a 5G system (5GS), such a function can not exist and, in the absence of a ProSe Function in the 5GS, a WTRU needs to discover services of interest to the WTRU. Therefore, there is a need for ProSe direct discovery that ensures privacy of services while not interacting with a ProSe Function in the core network. SUMMARY

[0004] Methods and apparatuses for discovery based on proximity-based services (ProSe) services are described herein. For example, a service utilizing wireless transmit / receive unit (SU-WTRU) can be provisioned with a per-service discovery type and a per-service security credential. The SU-WTRU can transmit a PC5 discovery message with the discovery type and a first security element generated based on the security credential. The SU-WTRU can receive a PC5 discovery response message from a service providing wireless transmit / receive unit (SP-WTRU), the PC5 discovery response message including a second security element and a service identity associated with a service provided by the SP-WTRU. If the second security element is verified based on the provisioned security credential, the SU-WTRU can authorize the SP-WTRU to establish a PC5 communication link with the SP-WTRU for direct communication. BRIEF DESCRIPTION OF DRAWINGS

[0005] A more detailed understanding can be had from the following description, given by way of example in conjunction with the accompanying drawings wherein like reference numerals indicate like parts and wherein:

[0006] Figure 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0007] Figure 1B is a system diagram illustrating an example wireless transmit / receive unit (WTRU) that can be used within the communications system Figure 1A illustrated in FIG. 1;

[0008] Figure 1C is a diagram illustrating that according to one embodiment a direct discovery procedure can be performed in a communication system Figure 1A system diagram of an example radio access network (RAN) and an example core network (CN) that can be used within the communication system

[0009] Figure 1D is a diagram illustrating that according to one embodiment a direct discovery procedure can be performed in a communication system Figure 1A system diagram of another example RAN and another example CN that can be used within the communication system

[0010] Figure 2 is a diagram illustrating an example direct discovery procedure;

[0011] Figure 3 is a diagram illustrating an example service oriented discovery procedure;

[0012] Figure 4 is a diagram illustrating an example service oriented discovery procedure using metadata; and

[0013] Figure 5 is a diagram illustrating an example service based discovery procedure. DETAILED DESCRIPTION

[0014] Figure 1A is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments can be implemented. The communication system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communication system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 can 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), zero-tail unique-word discrete Fourier transform spread orthogonal frequency division multiplexing (ZT-UW-DFT-S-OFDM), unique-word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0015] As Figure 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can 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 (any of which can be referred to as a station (STA)), can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environment), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the WTRUs 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

[0016] The communication system 100 can also include a base station 114a and / or a base station 114b. Each of the base stations 114a, 114b can 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 CN 106, the Internet 110, and / or the other networks 112. By way of example, the base stations 114a, 114b can be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home NodeB, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b can include any number of interconnected base stations and / or network elements.

[0017] The base stations 114a can be part of a RAN 104 that also can 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 stations 114a and / or the base stations 114b can be configured to transmit and / or receive wireless signals on one or more carrier frequencies. The base stations 114a and / or 114b can be referred to as cells supporting a particular carrier frequency. The base stations 114a and / or 114b can utilize multiple carriers (e.g., in a Carrier Aggregation (CA) scheme). The base stations 114a and / or 114b can also support additional carriers (e.g., in a licensed-assisted access (LAA) scheme). The base stations 114a and / or 114b can be configured to transmit and receive wireless signals on the above-mentioned frequency bands, or other bands.

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

[0019] More specifically, as noted above, the communications system 100 can be a multiple access system and can 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 104 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). WCDMA can include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA can include High-Speed Downlink (DL) Packet Access (HSDPA) and / or High-Speed Uplink (UL) Packet Access (HSUPA).

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

[0021] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0022] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

[0023] In other embodiments, the base station 114a and the WTRUs 102a, 102b, 102c can implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., 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.

[0024] Figure 1AThe base station 114b in the embodiment can be, for example, a wireless router, Home Node B, Home eNode B, or access point, and can utilize any suitable RAT for facilitating wireless connectivity access by the WTRUs 102c, 102d within a local area. In one embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can 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 can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106. Figure 1A

[0025] The RAN 104 can be in communication with the CN 106, which can 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. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can 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 Figure 1A Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing 5G, GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0026] ​The CN 106 can also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or the other networks 112. The PSTN 108 can include circuit-switched telephone networks that provide infrastructure for the provision of voice telephony. The Internet 110 can 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 / or the internet protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 can include wired and / or wireless communications networks owned and / or operated by other service providers. For example, the networks 112 can include another CN connected to one or more RANs, which can employ the same RAT as the RAN 104 or a different RAT.

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

[0028] Figure 1B Figure 1 B is a system diagram illustrating an example WTRU 102. As shown in Figure 1B Figure 1 B, the WTRU 102 can 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 / or other peripherals 138, among others. It will be appreciated that the WTRU 102 can include any sub-combination of the foregoing elements while remaining consistent with an embodiment.

[0029] The processor 118 can 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), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can 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 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. WhileFigure 1B The processor 118 and the transceiver 120 are depicted as separate components, but it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

[0030] The transmit / receive element 122 can be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a) over the air interface 116. For example, in one embodiment, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. In an embodiment, the transmit / receive element 122 can 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 can be configured to transmit and / or receive both RF and light signals. It will be appreciated that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0031] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to enable MIMO technology. Thus, the WTRU 102 can

[0032] The transceiver 120 can 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 can have multi-mode capabilities. Thus, the transceiver 120 can include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11, for example.

[0033] The processor 118 of the WTRU 102 can be coupled to, and can 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 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. In addition, the processor 118 can 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 can include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 can 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 can 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).

[0034] The processor 118 can receive power from the power source 134 and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can 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.

[0035] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 can receive location information over the air interface 116 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 can acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0036] The processor 118 can further be coupled to other peripherals 138, which can 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 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® The peripheral device 138 can include one or more sensors. The sensors can be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a compass sensor, a proximity sensor, a temperature sensor, a time sensor; a geo-location sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0037] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or cross- interference by utilizing hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0038] Figure 1C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can be in communication with the WTRUs 102a, 102b, 102c over the air interface 116 and can include eNode-Bs 160a, 160b, 160c, although it will be appreciated that the RAN 104 can include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the eNode-Bs 160a, 160b, 160c can implement MIMO technology. Thus, the eNode-B 160a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a.

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

[0040] Each of the eNode-Bs 160a, 160b, 160c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, and the like. As shown, the eNode-Bs 160a, 160b, 160c can communicate with one another over an X2 interface. Figure 1C

[0041] Figure 1C The CN 106 can include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0042] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an SI interface and can serve as a control node. For example, the MME 162 can be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activations / deactivations, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 can provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and / or WCDMA.

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

[0044] The SGW 164 can be connected to the PGW 166, which can 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.

[0045] ​CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between CN 106 and PSTN 108, or be able to communicate with such an IP gateway. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0046] Despite WTRU in Figures 1A-1D While described as a wireless terminal, it is conceivable that in some representative implementations, such a terminal may (e.g., temporarily or permanently) use a wired communication interface with a communication network.

[0047] In a representative implementation, the other network 112 may be a WLAN.

[0048] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more sites (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or carries traffic out of the BSS. Traffic originating outside the BSS and destined for a STA can reach and be delivered to the STA via the AP. Traffic originating from a STA and destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as point-to-point traffic. Point-to-point traffic can be sent between source and destination STAs (e.g., directly between them) using Direct Link Establishment (DLS). In some representative implementations, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode may not have an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0049] When using an 802.11 ac infrastructure mode of operation or similar mode of operation, an AP can transmit beacons on a fixed channel, such as a primary channel. The primary channel can be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel can be the operating channel of the BSS and can be used by STAs to establish a connection with the AP. In certain representative embodiments, carrier sense multiple access / collision avoidance (CSMA / CA) can be implemented, for example, in 802.11 systems. For CSMA / CA, a STA (e.g., each STA), including the AP, can listen to the primary channel. If the primary channel is sensed / detected as busy by a particular STA, the particular STA can back off. Only one STA can transmit in a given BSS at any given time.

[0050] High Throughput (HT) STAs can use 40 MHz wide channels to communicate, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0051] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can be parsed by a segment parser that can divide the data into two streams. Each stream can be independently subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described operations for the 80+80 configuration can be reversed, and the combined data can be sent to the medium access control (MAC).

[0052] 802.11af and 802.11ah support sub-1 GHz modes of operation. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah relative to those used in 802.11η and 802.1 lac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the television white space (TVWS) spectrum, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support meter type control / machine type communication (MTC) such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, e.g., limited capabilities, including support for (e.g., only support for) certain bandwidths and / or limited bandwidth. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0053] WLAN systems that can support multiple channels and channel bandwidths such as 802.11η, 802.1 lac, 802.11af, and 802.11ah include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to the largest common operating bandwidth supported by all STAs in a BSS. The bandwidth of the primary channel can be set and / or limited by a STA from all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., MTC type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, e.g., due to a STA (only supporting a 1 MHz operating mode) transmitting to the AP, the entire available frequency band can be considered busy even if most of the available frequency band remains idle.

[0054] In the United States, the available frequency bands for 802.11ah to use are 902 MHz to 928 MHz. In Korea, the available frequency bands are 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are 916.5 MHz to 927.5 MHz. The total bandwidth available to 802.11ah is 6 MHz to 26 MHz depending on the country code.

[0055] Figure 1D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 can employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

[0056] The RAN 104 can include gNBs 180a, 180b, 180c, although it will be appreciated that the RAN 104 can include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c can each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c can implement MIMO technology. For example, gNBs 180a, 108b can utilize beamforming to transmit signals to and / or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, can use multiple antennas to transmit wireless signals to, and / or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c can implement carrier aggregation technology. For example, the gNB 180a can transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers can be on unlicensed spectrum while the remaining component carriers can be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNB 180a and gNB 180b (and / or gNB 180c).

[0057] The WTRUs 102a, 102b, 102c can use transmission associated with scalable numerology to communicate with gNBs 180a, 180b, 180c. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary from different transmissions, from different cells, and / or for different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c can communicate with gNBs 180a, 180b, 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing varying number of OFDM symbols and / or lasting varying lengths of absolute time).

[0058] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with one or more of the gNBs 180a, 180b, 180c without also accessing other RANs, such as eNode-Bs 160a, 160b, 160c. In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use signals

[0059] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As Figure 1D As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface.

[0060] Figure 1D The CN 106, as shown, can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0061] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating WTRUs 102a, 102b, 102c, supporting network slicing (e.g., handling different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, managing the registration area for the WTRUs 102a, 102b, 102c, terminating non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for WTRUs 102a, 102b, 102c based on the type of services utilized by a WTRU 102a, 102b, 102c. For example, different network slices can be established for different use cases such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b can provide a control plane function for switching between the RAN 104 and other RANs (not illustrated) that employ other radio technologies, such as LTE, LTE- A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0062] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.

[0063] The UPF 184a, 184b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which can provide 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 UPF 184, 184b can perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0064] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a DN 185a, 185b through the UPF 184a, 184b via the N3 interface between the UPF 184a, 184b and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0065] In view of Figures 1A-1D And Figures 1A-1D In view of the corresponding description of the above, one or more or all of the functions described herein with reference to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, gNBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). An emulation device can be one or more devices configured to emulate one or more or all of the functions described herein. For example, emulation devices can be used to test other devices and / or to simulate network and / or WTRU functionality.

[0066] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, the one or more simulation devices may perform one or more or all functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or use over-the-air wireless communication to perform tests.

[0067] The one or more emulation devices may perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the emulation devices may be used in test scenarios within a test laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to perform testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and / or receive data.

[0068] In one or more implementations, direct discovery based on proximity service (ProSe) can have two models: Model A (e.g., “I am here”) and Model B (“Who is there?” / “Are you there?”).

[0069] For ProSe-enabled WTRUs participating in ProSe direct discovery, Model A can have two roles: (1) announcing WTRUs, where a WTRU announces specific information that can be used by nearby WTRUs with discovery privileges; and (2) monitoring WTRUs, where a WTRU monitors specific information of interest in the vicinity of the announcing WTRU. In Model A, the announcing WTRU can broadcast one or more discovery messages within a predefined discovery interval. Monitoring WTRUs interested in these broadcast messages can read and process them. It should be noted that Model A can be described as "I am here" because the announcing WTRU can broadcast information about itself (e.g., the ProSe application identity, the ProSe WTRU identity, etc. in the discovery message).

[0070] For a ProSe-enabled WTRU participating in ProSe direct discovery, Model B can have two roles: (1) a discoverer WTRU, where the WTRU transmits a request containing specific information about the discovery of interest; and (2) a discoverer WTRU, where the WTRU receiving the request message can respond using some information related to the discoverer's request.

[0071] Figure 2 An example direct discovery procedure 200 is shown, which can be used in combination with any other embodiment described herein. In this example, the overall procedure for open direct discovery (e.g., Model A) can be shown. During service authorization at step 210, a WTRU 202 (e.g., UE) can obtain authorization to advertise or monitor in a specific PLMN (e.g., HPLMN or other PLMN) from a ProSe function 204, 206 via an Open Mobile Alliance (OMA) Device Management (DM) procedure. If the WTRU 202 obtains authorization to advertise, it can send a discovery advertisement request to the ProSe function 204 via the PC3 reference point at step 215. The discovery advertisement request can include the service that the WTRU wants to announce, for example, by ProSe Application ID. Upon authorization, the ProSe function 204 can provide the WTRU 202 with a ProSe Application Code to advertise. Once the WTRU 202 is provided with the ProSe Application Code, the WTRU 202 can start advertising on the PC5 interface at step 220. If the WTRU obtains authorization to monitor in a specific PLMN, the WTRU 202 can send a discovery monitoring request to the ProSe function 204 via the PC3 reference point at step 225, including the service that the WTRU 202 wants to discover / monitor in the request, for example, by ProSe Application ID. Upon authorization, the ProSe function can provide the WTRU with a ProSe Application Code for monitoring. Once the WTRU 202 is provided with the ProSe Application Code, the WTRU 202 can start monitoring for the ProSe Application Code on the PC5 interface at step 230. When the WTRU 202 detects one or more ProSe Application Codes that match the filter, the WTRU 202 can report the ProSe Application Code to the ProSe function 204 at step 235.

[0072] The ProSe function 204 can be a physical entity or logical function for network related actions required for ProSe. The PC5 interface is a reference point between ProSe-enabled WTRUs and user plane for ProSe direct discovery, ProSe direct communication, and ProSe WTRU-to-network relay for control.

[0073] In some cases, ProSe or D2D devices can need to discover each other to utilize ProSe services or to establish a direct communication connection between peer WTRUs. As mentioned above, the discovery procedure can be based on transmitting a ProSe discovery code, which can be received by an in-coverage WTRU by communicating with an entity in the core network that supports discovery functionality (e.g., a ProSe function). The ProSe discovery code can be sent to the WTRU by the network during the discovery procedure according to the ProSe service type. The service type can refer to a specific ProSe application or ProSe group. An application can be represented by an application ID, and a group can be referred to by a group ID. A WTRU attempting to discover a ProSe WTRU can also have to communicate with the network to receive filtering information to be able to receive or understand the ProSe code broadcast over the PC5 channel.

[0074] For WTRUs out of coverage and / or public safety WTRUs, ProSe code and filtering information can be pre-provisioned in the WTRU (e.g., in a mobile device and / or a universal integrated circuit card) on a per-service basis.

[0075] For a 5GS architecture, a dedicated discovery function in the core network (e.g., a ProSe function) can not be an option. In this case, a 5G WTRU can need to be able to perform PC5 discovery (e.g., a discovery procedure between WTRUs and a ProSe function) without interacting with the core network. Therefore, procedures and methods to enable ProSe discovery without a dedicated discovery function in the core network are needed. For example, a WTRU can need to perform ProSe direct discovery for a service without interacting with a core network discovery function. In another example, there can be privacy concerns with WTRUs exchanging messages during a discovery procedure. The use of a core network discovery function as described above can enable a WTRU to receive discovery codes as well as establish a discovery security context to protect the integrity, confidentiality, and replay protection of such codes during transmission. Therefore, a WTRU needs to ensure the privacy of a service or the identity of a target WTRU transmitted during a discovery procedure.

[0076] A service can refer to an application or service sought by a (SU)-WTRU from a service provided by a (SP)-WTRU. Both the SU-WTRU and the SP-WTRU can be ProSe-enabled WTRUs. In an example, a service can be a taxi application or service provided by a taxi company (i.e., a SP-WTRU) to SU-WTRUs in the vicinity of the SP-WTRU. In another example, a service can be a restaurant application or service that broadcasts the location / availability and menu of a restaurant (i.e., a SP-WTRU) to SU-WTRUs in the vicinity of the SP-WTRU. In this disclosure, the terms service and application can be used interchangeably.

[0077] In one or more embodiments, a per-service based discovery type (e.g., Model A or Model B) can be provisioned for a service provider-WTRU (SP-WTRU) and a service utilizing WTRU (SU-WTRU). As described above, examples of services can include, but are not limited to, taxi service, restaurant, social application, local market, public transportation, and infotainment. Each service can be associated with a discovery type (e.g., Model A or Model B). For example, a Model B discovery type can be provisioned for a SP-WTRU providing a taxi service and / or a SU-WTRU seeking a taxi service. In another example, a Model A discovery type can be provisioned for a SP-WTRU providing a restaurant service and / or a SU-WTRU seeking a restaurant service. In addition, the provisioned information can include security credentials (e.g., certificate, group key) for the service. The WTRU can receive the provisioning information from an appropriate entity in the core network (e.g., PCF or ProSe function). The provisioning information can also be received by the WTRU from a ProSe application server. In the latter case, each ProSe application server can provision a WTRU with a discovery type and security credentials for a service provided by the application server. Alternatively or additionally, the provisioning information can be pre-configured / pre-stored / pre-installed in the WTRU (e.g., in a SIM card). The provisioning information can include an indication of whether privacy protection is expected to be enabled for a given service during discovery.

[0078] When a SU-WTRU is triggered (e.g., from an application layer) to discover a service, the SU-WTRU can check the discovery type associated with the service. If the service type is using Model B (also referred to as a solicitation), the SU-WTRU can generate a broadcast solicitation message (i.e., discovery request message) and generate an integrity / replay protection element (e.g., signature, message authentication code (MAC)) referred to herein as a "security element" using the provisioned security credentials. If privacy protection is enabled based on the provisioned profile, the SU-WTRU can use (e.g., provisioned) security credentials to confidentially protect privacy sensitive unique identifiers (e.g., service ID, target WTRU application ID below). For example, these identifiers can be encrypted using a group key and a time based freshness counter. Alternatively or additionally, these identifiers can be randomized (e.g., salted) by a hash function using a random value (e.g., assuming the identifier and transmitted random value have a large enough space). In this disclosure, the terms broadcast message, solicitation message, broadcast solicitation message, discovery message, discovery request message, PC5 discovery message, request message, or any combination thereof can be used interchangeably.

[0079] The SU-WTRU can then send a broadcast message on the PC5 discovery channel. The PC5 discovery message can include a discovery type, which in this scenario can be set to "request." The broadcast message can include one or more of the following, but is not limited to: a service ID (e.g., an application ID or group ID), a SU-WTRU application layer WTRU ID, a SU-WTRU ID (e.g., a ProSe WTRU ID or L2 ID), a target WTRU application layer WTRU ID, a computed security element, and / or an additional random value used to protect privacy sensitive identifiers confidentially (e.g., if needed).

[0080] When the SP-WTRU receives the PC5 discovery request message, on the SP-WTRU side, it can check the security element in the received message. If the SP-WTRU is able to successfully verify the security element to check the integrity and freshness of the received message, then it can generate a PC5 discovery response message. In addition, if privacy protection is enabled for the service according to the provisioned profile, the SP-WTRU can decrypt the whole or part of the message (e.g., sensitive ID) (e.g., using a group key). Alternatively or additionally, the SP-WTRU can use the random value received in the request message to compute a hash of its application layer WTRU ID (e.g., service ID) and attempt to compare the result with the hashed application layer WTRU ID (e.g., service ID) received in the request message. The discovery response message can then be sent over the PC5 discovery channel. The PC5 response message can include a service ID, a SP-WTRU application layer user ID, a generated security element, and / or a SP-WTRU ID (e.g., a ProSe WTRU ID or L2 ID). In this disclosure, the terms discovery response message, request response message, response message, PC5 discovery response message, or any combination thereof can be used interchangeably.

[0081] The SU-WTRU can receive discovery / request responses from one or more SP-WTRUs. The PC5 discovery response can include a security element generated by the SP-WTRU. The SU-WTRU can have to use the provisioned information as described above to verify the received security element (e.g., a signature certificate / root certificate or group key) to identify / authenticate the PC5 discovery response sent by the SP-WTRU. As described above, if privacy protection is enabled for the service, the privacy sensitive ID can also be protected confidentially.

[0082] Once the SU-WTRU is able to verify the security element received in the PC5 response message, the discovery procedure can be completed.

[0083] After the SU-WTRU has discovered the SP-WTRU, the SU-WTRU can initiate a direct connection establishment procedure using a PC5 signaling message. For example, the SU-WTRU can receive the L2 ID of the SP-WTRU in the PC5 discovery response message to initiate the direct link establishment procedure. In some scenarios or for some services, the SU-WTRU can only request service related discovery metadata (e.g., restaurant menu, taxi fare, etc.) through the PC5 discovery channel. This procedure is further described herein.

[0084] Figure 3 An exemplary service oriented discovery procedure 300 for request (Model B) is shown, which can be used in conjunction with any other embodiments described herein. In this example, at steps 305a, 305b, the discovery type (e.g., Model A or Model B) for each service type (or each service) and the security credentials (e.g., certificate, group key) for each service type (or each service) can be provisioned for both the SP-WTRU 302b and the SU-WTRU 302a.

[0085] At step 310, the SU-WTRU 302a can generate a broadcast request message (e.g., described in step 315) and at step 305a, compute an integrity protection element / security element (e.g., or MAC) using the provisioned information. An example of the broadcast request message can be a PC5 discovery message. The integrity protection element / security element can also be computed based on the content of the broadcast request message.

[0086] At step 315, assuming the discovery type provisioned in the SU-WTRU 302a is Model B, the SU-WTRU 302a can send a PC5 discovery message, which can include the discovery type such as: "request", WTRU ID (e.g., ProSe WTRU ID, source L2 ID), service ID (e.g., application ID, application layer user ID, target application layer user ID, group ID, group member ID), and the security element computed in step 310.

[0087] At step 320, the SP-WTRU 302B monitoring the PC5 discovery channel can receive the broadcast request message (i.e., PC5 discovery message) from the SU-WTRU at step 315. The SP-WTRU 302b can check the security element in the PC5 discovery message against the provisioned security credentials to authenticate the SU-WTRU 302a identity and subsequently generate a discovery response message using the provisioned security information. The SP-WTRU 302b can compute the security element based on the security element provisioned at step 305b and include the security element in the response message generated at step 325.

[0088] At step 325, assuming the discovery type provisioned in the SP-WTRU 302b is Model B, the SP-WTRU 302b can send a PC5 discovery response message that can include the type of discovery message, such as: a request response, a WTRU ID (e.g., a ProSe WTRU ID, a source L2 ID), a service ID (e.g., an application ID, an application layer user ID, a target application layer user ID, a group ID, or a group member ID), and the security element computed at step 320.

[0089] At step 330, the SU-WTRU 302a can receive the discovery response message and verify the security element in the discovery response message using the security information provisioned for the service type (e.g., the security credentials provisioned at step 305a) to identify / authenticate the SP-WTRU 302b. Successful verification of the security element in the response message can indicate to the SU-WTRU 302a that the SP-WTRU 302b has been discovered for the service.

[0090] At step 335, once discovery is complete, the SU-WTRU 302a can decide to establish a PC5 communication link (e.g., a direct unicast link) with the SP-WTRU 302b using the information received in the discovery response message at step 330. As described herein, another possibility is that the SU-WTRU can request one-time or periodic metadata information related to the service from the SP-WTRU.

[0091] Figure 3 The example described in FIG. 3 is applicable to Model B discovery (e.g., a request type discovery procedure). The example method can also be extended to Model A discovery (e.g., Model A with restricted discovery, i.e., proper permissions are reserved for the WTRU to the application server). Based on the provisioning information at step 305a, Figure 3 If the discovery type of the service is "Model A", the SU-WTRU 302a can attempt to detect one or more PC5 discovery messages transmitted over the discovery channel from one or more SP-WTRUs (including the SP-WTRU 302b) based on the provisioning information at step 305a. The SU-WTRU 302a can then use the provisioned security information (e.g., the security credentials provisioned for the SU-WTRU 302a) to verify the broadcasted PC5 discovery messages sent from the SP-WTRUs and authorize the SP-WTRUs. The assumption based on Model A discovery can be that the SP-WTRU 302b is broadcasting a discovery message similar to Figure 3the discovery message at step 325. When the SU-WTRU 302a detects the discovery message from the SP-WTRU 302b, it can verify the security element in the discovery message to verify the integrity and authenticity of the identities (e.g., service ID, SP-WTRU ID) received in the message. Upon successful verification of the security element in the PC5 announcement message by the SU-WTRU 302a, the SU-WTRU 302a can determine that the discovery procedure has been completed. Then, as described above, the SU-WTRU 302a can proceed to Figure 3 step 335.

[0092] The discovery procedures described herein can also be used for WTRU-to- network relay and WTRU-to-WTRU relay discovery procedures. In these scenarios, one of the WTRUs (e.g., the SP-WTRU 302b) can be a relay WTRU and the peer WTRU (e.g., the SU-WTRU 302a) can be a remote WTRU. The PC5 discovery message can include an indication of the relay discovery, such as WTRU-to-network relay discovery or WTRU-to-WTRU relay discovery. Such an indication can be an explicit IE or reflected in the service ID or application layer user ID element broadcast in the discovery message. Relay discovery can use both Model A discovery procedures or Model B discovery procedures.

[0093] In another embodiment, to support privacy protection, the SU-WTRU 302a can trigger an anonymous PC5 discovery message that does not have the SU-WTRU ID and does not have the SU-WTRU L2 address. For example, the SU-WTRU 302a can set the source address to a broadcast L2 address or a groupcast L2 address; upon receiving the anonymous PC5 discovery message, if the SP-WTRU 302b accepts the request, the SP-WTRU 302b can broadcast a PC5 discovery response that can include the service ID.

[0094] In this embodiment, the procedure can be similar to Figure 3The illustrated example, except for the following: at steps 305a, 305b, the SU-WTRU / SP-WTRU can also be configured to allow for anonymous discoverer / discovered; at step 310, if the SU-WTRU 302a decides to use anonymous discovery, the SU-WTRU 302a can generate a broadcast request message and set the source L2 address to an anonymous L2 address (e.g. broadcast / multicast address); at step 315, the SU-WTRU can include the service ID, but not the WTRU ID, and in this message, the SU-WTRU can include the service ID with a random parameter as specified above or a hashed service ID; at step 320, if the SP-WTRU 302b does not accept anonymous discovery, the SP-WTRU 302b can ignore the request; at step 325, the SP-WTRU 302b can broadcast / multicast a PC5 discovery response message. In this message, the SP-WTRU 302b can include the service ID with a random parameter as specified above or a hashed service ID.

[0095] In one embodiment, the discovery procedure can include metadata request. As described herein, an SU-WTRU discovering a SP-WTRU can want to obtain metadata from the SP-WTRU without having to establish a unicast communication.

[0096] An SU-WTRU that wants to obtain metadata from a SP-WTRU (or multiple SP-WTRUs) can specify a "metadata" indication on the discovery request. An SP-WTRU that receives the discovery request and also supports the specified service ID can reply by sending a discovery response message that includes its application user ID, L2 ID, and the requested metadata. The security procedures described herein can be used to encrypt the metadata in the response message. The SP-WTRU can also send the metadata in different PC5 messages depending on the length of the data. In this case, an indication carried in the PC5 message can be that there is more metadata in the subsequent discovery message. The SP-WTRU can also inform the SU-WTRU that the metadata is dynamic, in which case the SU-WTRU can send a message back to the SP-WTRU to inform it that it should be notified when the metadata is updated. Alternatively or additionally, the SU-WTRU can continuously monitor the PC5 discovery channel to receive the updated metadata. In the case of dynamic metadata, an index or version can also be broadcast by the SP-WTRU to inform monitoring WTRUs which current version is being broadcast. If the index or version of the SU-WTRU does not match the broadcasted version, the SU-WTRU can request the latest version of the metadata.

[0097] In one embodiment, the SU-WTRU can already know the SP-WTRU's application user ID (e.g., from provisioning information or an earlier discovery). In this case, the SU-WTRU can include the SP-WTRU application user ID in the discovery request.

[0098] Figure 4 An exemplary service-oriented discovery procedure 400 using metadata (discovery type using Model B) is shown, which can be used in conjunction with any other embodiment described herein. In this example, at steps 405a, 405b, the SP-WTRU 402b and SU-WTRU 402a can be provisioned with a discovery type for each service type (or each service) and security credentials for each service type (or each service).

[0099] The SU-WTRU 402a can want to discover the SP-WTRU 402b for a particular service type (or particular service) and want to obtain metadata. At step 410, the SU-WTRU 402a can generate a broadcast discovery (or request) request message including a service ID, the SU-WTRU's application user ID, and a security element (e.g., compute integrity protection using provisioned information). The SU-WTRU 402a can also include a request type (e.g., request), the SP-WTRU application user ID, a metadata request indication, and a metadata type in the message. The metadata request indication can be specified if metadata information is requested in the discovery response message. The metadata type can indicate the type of metadata requested, such as summary / detailed information or short / medium / long. For example: if the SP-WTRU 402b is a restaurant, the metadata can include the restaurant menu; if the metadata type is summary, only a condensed version of the menu is sent; and / or if the metadata type is detailed information, the full menu with prices is sent.

[0100] At step 415, the SU-WTRU 402a can broadcast the discovery request message.

[0101] At step 420, the SP-WTRU 402b receiving the discovery request message can check the security element. If the SP-WTRU 402b successfully authenticates the security element, the SP-WTRU 402b can verify whether it supports the service ID. If the SP-WTRU 402b supports the service ID, the SP-WTRU 402b can look at the metadata indication and prepare the metadata to be returned according to the metadata type. The discovery response message can be prepared, including but not limited to the SP-WTRU application layer ID, L2 ID, and metadata. The security element of the SP-WTRU 402b is calculated based on the security credentials provisioned for the SP-WTRU 402b at step 405b, and the security element is added to the discovery response message.

[0102] At step 425, the SU-WTRU 402a can receive the discovery response message. At step 430, the SU-WTRU 402a can check the security element and read the metadata.

[0103] As an example use of the discovery procedure using metadata, the SU-WTRU 402a can request metadata with the type set to "overview" and no target SP-WTRU application user ID specified. Then, the SU-WTRU 402a can expect to receive multiple discovery response messages, such as responses from different SP-WTRUs, including the SP-WTRU 402b. Since an overview of the metadata is returned in the discovery response message, the user of the SU-WTRU 402a can quickly review the overview metadata and request detailed metadata from a particular SP-WTRU. This can be done by sending another discovery request message directly to the selected SP-WTRU (e.g., with the destination set to the L2 ID of the SP-WTRU), including the SP-WTRU application user ID and the metadata type set to "detailed information."

[0104] In one example, a WTRU can be provisioned with a discovery type (Model A or Model B) per service and one or more security credentials (e.g., a signature certificate and a root certificate or a group key) per service. When triggered by a higher layer for a particular service, the WTRU can generate a broadcast request discovery PC5 signaling message or a PC5 discovery message including a service ID, an application layer ID of the WTRU, and possibly an application ID of a target WTRU for discovering a particular WTRU. The WTRU can then compute an integrity protection element (e.g., a signature or a MAC) using the security credentials provisioned through the PC5 message. The PC5 message can then be sent along with the integrity protection element. The WTRU can receive one or more discovery response messages from one or more SP-WTRUs including a SP-WTRU ID and an application layer and possibly an application ID of a target WTRU. The WTRU can check the integrity protection element of the response message based on the provisioned security credentials (e.g., a root certificate or a group key) to verify the SP-WTRU identity / authorization. The WTRU can select a SP-WTRU and can decide to establish a unicast link with the SP-WTRU or the WTRU can request a one-time metadata related to the service from the service provider WTRU.

[0105] Figure 5 An example service-based discovery procedure 500 is shown that can be used in combination with any other embodiments described herein. At step 505, a WTRU (e.g., a SU-WTRU) can receive core network provisioning information or application server provisioning information from a base station (BS) including a discovery type per service and security credentials per service. As described above, the discovery type can be Model A or Model B. The discovery type (e.g., Model A or Model B) can be determined (in advance) or configured (in advance) per service. Different services (or service types) can have different discovery types. For example, a restaurant service (or service type) can be associated with Model A and a taxi service (or service type) can be associated with Model B. The security credentials can be a group key, a signature certificate, a root certificate, a symmetric private / public key pair, a shared secret, etc. The security credentials can be determined (in advance) per service. Similar to the discovery type, different services (or service types) can have different security credentials. For example, a restaurant service (or service type) can be associated with a group key and a taxi service (or service type) can be associated with a signature certificate. Alternatively or additionally, a WTRU can be provisioned with a discovery type per service and security credentials per service in the WTRU. For example, the discovery type per service and / or the security credentials per service can be pre-installed or pre-stored in a SIM card or a memory.

[0106] At step 510, the WTRU (e.g., SU-WTRU) can generate a first security element based on the provisioned security credential. The first security element can be different from the provisioned security credential. It can be a product generated using the security credential. For example, if the security credential is a group key, the generated security element can be a message authentication code (MAC). If the security credential uses public key cryptography, the WTRU can include a certificate as part of the security element, which has a signature that the WTRU can provide to other WTRUs. If the security credential is a secret key, the generated security element can be a MAC, and the receiving WTRU (e.g., SP-WTRU) can acquire the appropriate group key and verify whether the MAC is correct.

[0107] Assuming the discovery type is Model B (i.e., a request), at step 515, the WTRU can generate and broadcast a PC5 discovery message including the discovery type and the first security element. The PC5 discovery message can also include, but is not limited to, the SU-WTRU identity, the service identity (that the WTRU is seeking), the application identity, the metadata type, and the metadata request.

[0108] At step 520, the WTRU (e.g., SU-WTRU) can receive a PC5 discovery response message from another WTRU (e.g., SP-WTRU), which includes a second security element and a service identity associated with a service provided by the other WTRU (e.g., SP-WTRU). The second security element can be generated based on the security credential provisioned for the SP-WTRU. The second security element can be different from the security credential provisioned for the SP-WTRU. It can be a product generated using the security credential provisioned for the SP-WTRU. For example, if the security credential provisioned for the SP-WTRU is a group key, the generated second security element can be a message authentication code (MAC). If the security credential provisioned for the SP-WTRU uses public key cryptography, the SP-WTRU can include a certificate as part of the second security element, which has a signature that the SP-WTRU can provide to the SU-WTRU. If the security credential provisioned for the SP-WTRU is a secret key, the generated second security element can be a MAC, and the receiving WTRU (e.g., SU-WTRU) can acquire the appropriate group key and verify whether the MAC is correct. In addition, the PC5 discovery response message can include, but is not limited to, the SP-WTRU identity, the application identity, and the metadata associated with the service provided by the SP-WTRU. The PC5 discovery response message can be a broadcast message from the SP-WTRU.

[0109] At step 525, if the WTRU (e.g., SU-WTRU) verifies or authenticates the second security element based on the security credentials provisioned for the SU-WTRU, then at step 530, the SU-WTRU can initiate establishment of a PC5 direct communication link with the SP-WTRU. In embodiments, the SP-WTRU and the SU-WTRU can exchange metadata over the PC5 direct communication link. For example, a customer (i.e., SU-WTRU) discovering a restaurant service provider (i.e., SP-WTRU) can only want to receive the menu of the restaurant and not fully communicate with the restaurant service provider (i.e., SP-WTRU). However, at step 525, if the WTRU fails to verify or authenticate the second security element, then at step 520, the SU-WTRU can monitor for and receive another PC5 discovery response message from another SP-WTRU.

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

[0111] ***

Claims

1. A method for use in a Service Utilization-Wireless Transmit / Receive Unit (SU-WTRU), the method comprising: The SU-WTRU, which is configured with a discovery type and security credentials for each service, transmits a PC5 discovery message having the discovery type, metadata request, and a first security element generated by the SU-WTRU based on the configured security credentials; as well as Receive a PC5 discovery response message from the Service Provider-Wireless Transmitter / Receiver Unit (SP-WTRU), the PC5 discovery response message including a second security element, a service identity associated with the service provided by the SP-WTRU, an SP-WTRU application layer identity, an SP-WTRU identity, metadata associated with the service provided by the SP-WTRU, and an indication that the metadata is dynamic.

2. The method according to claim 1, further comprising: Under the condition that the second security element is verified based on the allocated security credentials, the SP-WTRU is authorized to establish a PC5 communication link.

3. The method according to claim 1, further comprising: Receive allocation information from the network server, including the discovery type and the security credentials.

4. The method according to claim 1, wherein, The discovery type for each service is a requirement.

5. The method according to claim 1, wherein, The security credentials for each service include at least one of a certificate, root certificate, group key, private key, or public key.

6. The method according to claim 1, wherein, The first security element includes at least one of a signature or a message authentication code (MAC), and the second security element is generated based on security credentials allocated for the SP-WTRU.

7. A service utilization-wireless transmit / receive unit (SU-WTRU), the SU-WTRU being configured with a discovery type based on each service and security credentials based on each service, the SU-WTRU comprising: Receiver; Transmitter; and processor, The transmitter and the processor are configured to: Transmit a PC5 discovery message having the discovery type, metadata request, and a first security element generated by the SU-WTRU based on the configured security credentials; and The receiver and the processor are configured to: Receive a PC5 discovery response message from the Service Provider-Wireless Transmitter / Receiver Unit (SP-WTRU), the PC5 discovery response message including a second security element, a service identity associated with the service provided by the SP-WTRU, an SP-WTRU application layer identity, an SP-WTRU identity, metadata associated with the service provided by the SP-WTRU, and an indication that the metadata is dynamic.

8. The SU-WTRU according to claim 7, wherein, The processor is further configured to authorize the SP-WTRU to establish a PC5 communication link upon verification of the second security element based on the assigned security credentials.

9. The SU-WTRU according to claim 7, wherein, The receiver and the processor are configured to receive dispatch information from the network server, including the discovery type and the security credentials.

10. The SU-WTRU according to claim 7, wherein, The discovery type for each service is a requirement, and the security credentials for each service include at least one of a certificate, a root certificate, a group key, a private key, or a public key.

11. The SU-WTRU according to claim 7, wherein, The first security element includes at least one of a signature or a message authentication code (MAC), and the second security element is generated based on security credentials allocated for the SP-WTRU.

Images