Discovery based on 5G ProSe service

Abstract

Methods and apparatus for discovery based on Proximity Service (ProSe) services are described herein. For example, a discovery type per service and security credentials per service may be deployed to a service (SU-WTRU) utilizing a wireless transmit / receive unit (SU-WTRU). The SU-WTRU may transmit (315) a PC5 discovery message having the discovery type and a first security element generated based on the security credential. The WTRU may then receive (325) a PC5 discovery response message from a service (SP-WTRU) providing a wireless transmit / receive unit, the PC5 discovery response message including the second secure element and a service identity associated with the service provided by the SP-WTRU. The SU-WTRU may authorize (330) the SP-WTRU to establish a PC5 communication link with the SP-WTRU under conditions that the second secure element is validated based on the deployed security credential.

Description

[0001] This application is a divisional application of patent application No. 202080083768.3, filed on November 6, 2020, entitled "Discovery Based on 5G ProSe Service". Cross-references 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 incorporated herein by reference. Background Technology

[0003] Proximity-based service (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 ProSe functions in the core network. For example, discovery codes are assigned to peer radio transmit / receive units (WTRUs) and translated into services or service names / IDs via ProSe functions. In 5G systems (5GS), such functions may not exist, and without ProSe functions in 5GS, WTRUs need to discover services of interest to them. Therefore, direct ProSe discovery that ensures service privacy without interacting with ProSe functions in the core network is required. Summary of the Invention

[0004] This document describes methods and apparatus for discovery based on Proximity-Based Services (ProSe). For example, a discovery type and security credentials based on each service may be assigned to a service utilizing a wireless transmitter / receiver unit (SU-WTRU). The SU-WTRU may transmit a PC5 discovery message having the discovery type and a first security element generated based on the security credentials. The SU-WTRU may receive a PC5 discovery response message from a service providing a wireless transmitter / receiver unit (SP-WTRU), the PC5 discovery response message including a second security element and a service identity associated with the service provided by the SP-WTRU. If the second security element is verified based on the assigned security credentials, the SU-WTRU may authorize the SP-WTRU to establish a PC5 communication link with the SP-WTRU for direct communication. Attached Figure Description

[0005] A more detailed understanding can be obtained from the following description given by way of example in conjunction with the accompanying drawings, wherein similar reference numerals in the drawings indicate similar elements, and wherein: Figure 1A This is a system diagram illustrating an exemplary communication system that can be implemented in one or more of the disclosed embodiments; Figure 1BThis illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown; Figure 1C This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of an exemplary radio access network (RAN) and an exemplary core network (CN) used within the communication system shown; Figure 1D This illustrates that, according to one implementation scheme, it is possible to Figure 1A A system diagram of another exemplary RAN and another exemplary CN used in the communication system shown; Figure 2 This is a diagram illustrating an exemplary direct discovery procedure; Figure 3 This is a diagram illustrating an exemplary service-oriented discovery procedure; Figure 4 This is a diagram illustrating an exemplary service-oriented discovery procedure that uses metadata; and Figure 5 This is a diagram illustrating an example of a service-based discovery procedure. Detailed Implementation

[0006] Figure 1A This is a schematic diagram illustrating an exemplary communication system 100 that can be implemented in one or more of the disclosed embodiments. Communication system 100 can be a multiple access system providing content such as voice, data, video, messaging, and broadcasting to multiple wireless users. Communication system 100 enables multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, communication 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), Zero-Tail Unique Word Discrete Fourier Transform Extended OFDM (ZT-UW-DFT-S-OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0007] like Figure 1AAs shown, the communication system 100 may 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. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d can be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a station (STA)) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile user units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

[0008] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106, Internet 110, and / or other networks 112. As examples, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, evolved Node Bs (eNBs), home Node Bs, home evolved Node Bs, next-generation NodeBs such as gNode Bs (gNBs), new radio (NR) NodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0009] Base station 114a may be part of RAN 104, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of radio services to a specific geographic area, which may be relatively fixed or changeable over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in desired spatial directions.

[0010] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via 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.). Any suitable radio access technology (RAT) can be used to establish air interface 116.

[0011] More specifically, as noted above, the communication 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, etc. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 116. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High-Speed ​​Uplink (UL) Packet Access (HSUPA).

[0012] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or Advanced LTE (LTE-A) and / or Advanced LTE Pro (LTE-A Pro) to establish air interface 116.

[0013] In one implementation, base station 114a and WTRUs 102a, 102b, 102c can enable radio technologies such as NR radio access, which can use NR to establish air interface 116.

[0014] In one implementation, base station 114a and WTRUs 102a, 102b, and 102c can implement multiple radio access technologies. For example, base station 114a and WTRUs 102a, 102b, and 102c can, for instance, use a dual connectivity (DC) principle to implement both LTE and NR radio access together. Therefore, the air interface utilized by WTRUs 102a, 102b, and 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., eNBs and gNBs).

[0015] In other implementations, base station 114a and WTRUs 102a, 102b, and 102c can implement radio technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), GSM Enhanced Data Rate Evolution (EDGE), and GSM EDGE (GERAN).

[0016] Figure 1ABase station 114b can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in local areas such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., for use by drones), roads, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b may have a direct connection to Internet 110. Therefore, base station 114b may not need to access Internet 110 via CN106.

[0017] RAN 104 can communicate with CN 106, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data can have different Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not explicitly stated... Figure 1A As shown, but it should be understood that RAN 104 and / or CN 106 can communicate directly or indirectly with other RANs that use the same RAT as RAN 104 or a different RAT. For example, in addition to being connected to RAN 104 which can utilize NR radio technology, CN 106 can also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] CN 106 may also act as a gateway for WTRUs 102a, 102b, 102c, and 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 or a different RAT.

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

[0020] Figure 1B This is a system diagram illustrating an exemplary WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmitting / receiving element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It should be understood that, while remaining consistent with the implementation, WTRU 102 may include any sub-combination of the foregoing elements.

[0021] Processor 118 can be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), any other type of integrated circuit (IC), a state machine, etc. Processor 118 can perform signal encoding, data processing, power control, input / output processing, and / or any other functions that enable WTRU 102 to operate in a wireless environment. Processor 118 can be coupled to transceiver 120, which can be coupled to transmitting / receiving element 122. Although Figure 1B The processor 118 and transceiver 120 are depicted as separate components, but it should be understood that the processor 118 and transceiver 120 may be integrated together in an electronic package or chip.

[0022] Transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 116. For example, in one embodiment, transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It should be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0023] Although the transmitting / receiving element 122 is in Figure 1B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

[0024] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate via various RATs such as NR and IEEE 802.11.

[0025] The processor 118 of WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit) and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, keypad 126, and / or display / touchpad 128. Furthermore, the processor 118 may access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. 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. Removable memory 132 may include a user identity module (SIM) card, memory stick, secure digital storage (SD) card, etc. In other embodiments, the processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store data in that memory.

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

[0027] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 116 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0028] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include an accelerometer, electronic compass, satellite transceiver, digital camera (for photos and / or video), Universal Serial Bus (USB) port, vibration device, television transceiver, hands-free headset, Bluetooth® module, FM radio unit, digital music player, media player, video game player module, internet browser, virtual reality and / or augmented reality (VR / AR) device, activity tracker, etc. Peripheral device 138 may include one or more sensors. Sensors may be one or more of the following: gyroscope, accelerometer, Hall effect sensor, magnetometer, orientation sensor, proximity sensor, temperature sensor, time sensor; geolocation sensor, altimeter, light sensor, touch sensor, magnetometer, barometer, gesture sensor, biometric sensor, humidity sensor, etc.

[0029] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) and DL (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit for reducing and / or substantially eliminating self-interference through signal processing via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all signals (e.g., associated with specific subframes for UL (e.g., for transmission) or DL ​​(e.g., for reception)) are concurrent.

[0030] Figure 1C This is a system diagram illustrating RAN 104 and CN 106 according to one embodiment. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with CN 106.

[0031] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a.

[0032] Each of the evolved nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, and user scheduling in the UL and / or DL, etc. Figure 1C As shown, evolution nodes B 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0033] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (PGW) 166. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0034] The MME 162 can connect to each of the evolved nodes B 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0035] The SGW 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 typically routes and forwards user data packets to and from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions such as anchoring the user plane during inter-evolved Node B handovers, triggering paging when DL data is available for WTRUs 102a, 102b, and 102c, and managing and storing the context of WTRUs 102a, 102b, and 102c.

[0036] SGW 164 can be connected to PGW 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0037] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (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) or be able to communicate with such an IP gateway, which serves as an interface between CN 106 and PSTN 108. 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.

[0038] Despite WTRU in Figures 1A to 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.

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

[0040] A WLAN in Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (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.

[0041] When operating in 802.11ac infrastructure mode or a similar mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a 20 MHz wide bandwidth) or dynamically configured. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative implementations, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) can be implemented, for example, in an 802.11 system. For CSMA / CA, each STA (including the AP) can listen to the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that STA can back off. A single STA (e.g., only one station) can transmit in a given BSS at any given time.

[0042] High-throughput (HT) STAs can communicate using a 40MHz wide channel, for example, by combining a primary 20MHz channel with adjacent or non-adjacent 20MHz channels to form a 40MHz wide channel.

[0043] Very High Throughput (VHT) STAs support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels, or by combining two non-consecutive 80MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data can be split into two streams by a segment parser. Each stream can be processed individually using Inverse Fast Fourier Transform (IFFT) and time-domain processing. These streams can be mapped to two 80MHz channels, and data can be transmitted via a transmitting STA. At the receiver of the receiving STA, the operations described above for the 80+80 configuration can be reversed, and the combined data can be sent to Media Access Control (MAC).

[0044] 802.11af and 802.11ah support operating modes below 1 GHz. Compared to those used in 802.11n and 802.11ac, 802.11af and 802.11ah reduce channel operating bandwidth and carrier. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative implementations, 802.11ah may support instrument-type control / machine-type communication (MTC), such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain bandwidths and / or limited bandwidths. MTC devices may include batteries with battery life above a threshold (e.g., to maintain a very long battery life).

[0045] WLAN systems supporting multiple channels, and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah, include channels that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by STAs operating in the BSS (each supporting a minimum bandwidth operating mode). In the 802.11ah example, for STAs supporting (e.g., only supporting) a 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Allocation Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (supporting only the 1MHz operating mode) is transmitting to the AP, all available frequency bands can be considered busy even if most available bands remain idle.

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

[0047] Figure 1D This is a system diagram illustrating RAN 104 and CN 106 according to one implementation scheme. As noted above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR radio technology. RAN 104 can also communicate with CN 106.

[0048] RAN 104 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 104 may include any number of gNBs while remaining consistent with the implementation. Each gNB 180a, 180b, and 180c may include one or more transceivers for communication with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one implementation, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one implementation, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0049] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with scalable parameter sets. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0050] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., evolved Node Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate or connect to gNBs 180a, 180b, and 180c, and also communicate or connect to other RANs (such as evolved Node Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate substantially simultaneously with one or more gNBs 180a, 180b, and 180c and one or more evolved Node Bs 160a, 160b, and 160c. In a non-standalone configuration, evolved Node Bs 160a, 160b, and 160c can be used as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

[0051] Each of gNBs 180a, 180b, and 180c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in UL and / or DL, network slicing support, interoperability between DC, NR, and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

[0052] Figure 1DThe CN 106 shown may 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. Although the foregoing elements are depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than a CN operator.

[0053] AMF 182a and 182b can connect to one or more of the gNBs 180a, 180b, and 180c in RAN 104 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different Protocol Data Unit (PDU) sessions with different requirements), selecting specific SMF 183a and 183b, managing registration areas, terminating Non-Access Stratum (NAS) signaling, mobility management, etc. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services that rely on Ultra-Reliable Low Latency (URLLC) access, services that rely on Enhanced Mobile Broadband (eMBB) access, and services for MTC access. AMF 182a and 182b can provide control plane functions for handover between RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies, such as WiFi.

[0054] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 106 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 106 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure traffic routing through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing DL data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0055] UPF 184a and 184b can connect via the N3 interface to one or more of the gNBs 180a, 180b, and 180c in RAN 104. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184 and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, and providing mobility anchoring.

[0056] CN 106 can facilitate communication with other networks. 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. In one embodiment, WTRUs 102a, 102b, and 102c can be connected to DNs 185a and 185b via UPFs 184a and 184b through their N3 interfaces and their N6 interfaces with local DNs 185a and 185b.

[0057] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding descriptions herein refer to one or more of the functions described below, which may be performed by one or more emulation devices (not shown): WTRU102a-d, base station 114a-b, evolved Node B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device may be one or more devices configured to mimic one or more of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

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

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

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

[0062] 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 it is interested in; and (2) a discoverer WTRU, where the WTRU receiving the request message can respond using some information related to the discoverer's request.

[0063] Figure 2 An exemplary direct discovery procedure 200 is illustrated, which can be used in conjunction with any other implementation described herein. In this example, a general procedure for open direct discovery (e.g., Model A) may be shown. During service authorization at step 210, WTRU 202 (e.g., UE) may obtain authorization to advertise or monitor in a specific PLMN (e.g., HPLMN or other PLMN) from ProSe functions 204, 206 via the Open Mobile Alliance (OMA) Device Management (DM) procedure. If WTRU 202 obtains authorization to advertise, it may send a discovery announcement request to ProSe function 204 via the PC3 reference point at step 215. The discovery announcement request may include services that WTRU wants to announce, for example, via a ProSe application ID. Upon authorization, ProSe function 204 may provide WTRU 202 with a ProSe application code for announcement. Once the ProSe application code is provided to WTRU 202, WTRU 202 may begin advertising on the PC5 interface at step 220. If the WTRU is authorized to monitor in a specific PLMN, the WTRU 202 may send a discovery monitoring request to the ProSe function 204 via the PC3 reference point at step 225, including the services that the WTRU 202 wants to discover / monitor in the request (e.g., via a ProSe application ID). Upon authorization, the ProSe function may provide the WTRU with a ProSe application code for monitoring. Once the ProSe application code is provided to the WTRU 202, the WTRU 202 may begin monitoring 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 may report the ProSe application code to the ProSe function 204 at step 235.

[0064] 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 the ProSe-enabled WTRU for control and the user plane for ProSe direct discovery, ProSe direct communication, and ProSe WTRU to network relay.

[0065] In some cases, ProSe or D2D devices may need to discover each other to utilize ProSe services or establish direct communication connections between peer WTRUs. As described above, the discovery process may be based on transmitting a ProSe discovery code, which can be received by WTRUs within coverage area through communication with entities in the core network that support discovery functionality (e.g., ProSe functions). The ProSe discovery code can be sent over the network to the WTRU during the discovery process, depending on the ProSe service type. The service type can refer to a specific ProSe application or a ProSe group. The application can be represented by an application ID, and the group can be identified by a group ID. WTRUs attempting to discover ProSe WTRUs may also need to communicate with the network to receive filtering information, thereby enabling them to receive or understand ProSe codes broadcast via the PC5 channel.

[0066] For WTRUs that are outside the coverage area and / or public safety WTRUs, ProSe codes and filtering information can be pre-configured in the WTRU (e.g., in mobile devices and / or general-purpose integrated circuit cards) based on each service.

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

[0068] A service can refer to an application or service that utilizes the services of a (SU)-WTRU to find services provided by a (SP)-WTRU. Both SU-WTRU and SP-WTRU can be ProSe-enabled WTRUs. In one example, a service could be a taxi application or service provided by a taxi company (i.e., SP-WTRU) to SU-WTRUs near the SP-WTRU. In another example, a service could be a restaurant application or service that broadcasts the location / availability and menu of a restaurant (i.e., SP-WTRU) to SU-WTRUs near the SP-WTRU. In this disclosure, the terms service and application are used interchangeably.

[0069] In one or more implementations, a discovery type (e.g., Model A or Model B) based on each service can be provisioned to service provider-WTRUs (SP-WTRUs) and services utilizing WTRUs (SU-WTRUs). As described above, examples of services may include, but are not limited to, taxi services, restaurants, social applications, local marketplaces, public transportation, and infotainment. Each service may be associated with a discovery type (e.g., Model A or Model B). For example, Model B discovery type can be provisioned to an SP-WTRU providing a taxi service and / or an SU-WTRU seeking a taxi service. In another example, Model A discovery type can be provisioned to an SP-WTRU providing a restaurant service and / or an SU-WTRU seeking a restaurant service. Additionally, the provisioned information may include security credentials for the service (e.g., certificates, group keys). WTRUs may receive provisioning information from appropriate entities in the core network (e.g., PCF or ProSe functions). WTRUs may also receive provisioning information from ProSe application servers. In the latter case, each ProSe application server can provision a WTRU with a discovery type and security credentials for the service provided by the application server. Alternatively or otherwise, the provisioning information may be pre-configured / pre-stored / pre-installed in the WTRU (e.g., in the SIM card). The provisioning information may include an indication of whether privacy protections are expected to be enabled for a given service during discovery.

[0070] When a SU-WTRU is triggered (e.g., from the application layer) to discover a service, the SU-WTRU may examine the discovery type associated with that service. If the service type is using Model B (also known as a request), the SU-WTRU may generate a broadcast request message (i.e., a discovery request message) and generate integrity / replay protection elements (e.g., signature, Message Authentication Code (MAC)) referred to herein as “security elements” using the configured security credentials. If privacy protection is enabled based on the configured profile, the SU-WTRU may use (e.g., the configured) security credentials to confidentially protect privacy-sensitive unique identifiers (e.g., the service ID below, the target WTRU application ID). For example, these identifiers may be encrypted using a group key and a time-based freshness counter. Alternatively or otherwise, these identifiers may be randomized (e.g., salted) by using a hash function with random values ​​(e.g., assuming the identifier and the transmitted random value have a sufficiently large space). In this disclosure, the terms broadcast message, request message, broadcast request message, discovery message, discovery request message, PC5 discovery message, request message, or any combination thereof are used interchangeably.

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

[0072] When the SP-WTRU receives a PC5 discovery request message, it can inspect the security elements in the received message. If the SP-WTRU successfully verifies the security elements to check the integrity and freshness of the received message, it can then generate a PC5 discovery response message. Furthermore, if privacy protection is enabled for the service according to the configured profile, the SP-WTRU can decrypt the message (e.g., a sensitive ID) in whole or in part (e.g., using a group key). Alternatively or otherwise, the SP-WTRU can use the random value received in the request message to calculate a hash of its application-layer WTRU ID (e.g., a service ID) and attempt to compare the result with the hash of the application-layer WTRU ID (e.g., the service ID) received in the request message. A discovery response message can then be sent via the PC5 discovery channel. The PC5 response message may include the service ID, the SP-WTRU application-layer user ID, the generated security elements, and / or the 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 are used interchangeably.

[0073] The SU-WTRU can receive discovery / request responses from one or more SP-WTRUs. The PC5 discovery response may include security elements generated by the SP-WTRU. The SU-WTRU may need to use the configured information as described above to verify the received security elements (e.g., signing certificate / root certificate or group key) to identify / authorize the PC5 discovery response sent by the SP-WTRU. As mentioned above, if privacy protection is enabled for the service, privacy-sensitive IDs may also be protected.

[0074] Once the SU-WTRU can verify the security element received in the PC5 response message, the discovery process is complete.

[0075] After the SU-WTRU has discovered the SP-WTRU, the SU-WTRU can initiate a direct connection establishment procedure using PC5 signaling messages. For example, the SU-WTRU can receive the SP-WTRU's L2 ID in a PC5 discovery response message to initiate a direct link establishment procedure. In some scenarios or for certain services, the SU-WTRU can request service-related discovery metadata (e.g., restaurant menus, taxi fares, etc.) simply through the PC5 discovery channel. This procedure is described further in this document.

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

[0077] At step 310, SU-WTRU 302a may generate a broadcast request message (e.g., as described in step 315), and in step 305a, an integrity protection element / security element (e.g., or MAC) is calculated using the allocated information. An example of a broadcast request message could be a PC5 discovery message. The integrity protection element / security element may also be calculated based on the content of the broadcast request message.

[0078] At step 315, assuming the discovery type allocated in SU-WTRU 302a is Model B, SU-WTRU 302a may send a PC5 discovery message, which may include the discovery type, such as "request", WTRU ID (e.g., ProSeWTRU 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 calculated in step 310.

[0079] At step 320, the SP-WTRU 302B monitoring the PC5 discovery channel may receive a broadcast request message (i.e., a PC5 discovery message) from the SU-WTRU at step 315. The SP-WTRU 302b may examine the security elements in the PC5 discovery message against the allocated security credentials to verify the identity of the SU-WTRU 302a and subsequently generate a discovery response message using the allocated security information. The SP-WTRU 302b may calculate security elements based on the security elements allocated at step 305b and include the security elements from the response message generated at step 325.

[0080] At step 325, assuming the discovery type allocated in SP-WTRU 302b is Model B, SP-WTRU 302b may send a PC5 discovery response message, which may include the type of discovery message, such as: request response, WTRUID (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 or group member ID), and security elements calculated at step 320.

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

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

[0083] Figure 3 The example described applies to model B discovery (e.g., requiring a type discoverer). This exemplary method can also be extended to model A discovery (e.g., model A with restricted discovery, i.e., preserving appropriate permissions for the application server for WTRU). Based on Figure 3 In step 305a, regarding the allocation information, if the service discovery type is "Model A," then SU-WTRU 302a may attempt to detect one or more PC5 discovery messages transmitted via the discovery channel from one or more SP-WTRUs (including SP-WTRU 302b). SU-WTRU 302a can then use the allocated security information (e.g., security credentials allocated for SU-WTRU 302a) to verify the broadcast PC5 discovery message sent from the SP-WTRU and authorize the SP-WTRU. The assumption for Model A-based discovery could be that SP-WTRU 302b is broadcasting a discovery message without request, which is similar to... Figure 3The discovery message described in step 325. When SU-WTRU 302a detects a discovery message from SP-WTRU 302b, it verifies the security elements in the discovery message to verify the integrity and authenticity of the identity (e.g., service ID, SP-WTRUID) received in the message. When SU-WTRU 302a successfully verifies the security elements in the PC5 announcement message, SU-WTRU 302a determines that the discovery process has been completed. Then, as described above, SU-WTRU 302a can proceed to... Figure 3 Step 335.

[0084] 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., SP-WTRU 302b) can be a relay WTRU, and the peer WTRU (e.g., SU-WTRU 302a) can be a remote WTRU. PC5 discovery messages can include indications regarding relay discovery, such as WTRU-to-network relay discovery or WTRU-to-WTRU relay discovery. Such indications can be explicit IEs or reflected in the service ID or application-layer user ID element broadcast in the discovery message. Relay discovery can use either the Model A discovery procedure or the Model B discovery procedure.

[0085] In another implementation, to support privacy protection, SU-WTRU 302a may trigger anonymous PC5 discovery messages, such as those without a SU-WTRU ID and without a SU-WTRU L2 address. For example, SU-WTRU 302a may set the source address to a broadcast L2 address or a multicast L2 address; after receiving an anonymous PC5 discovery message, if SP-WTRU 302b accepts the request, SP-WTRU 302b may broadcast a PC5 discovery response, which may include a service ID.

[0086] In this implementation scheme, the procedure may be similar to Figure 3In the example shown, in addition to the following: at steps 305a and 305b, the SU-WTRU / SP-WTRU can also be configured to allow anonymous discoverers / discoverers; at step 310, if SU-WTRU 302a decides to use anonymous discovery, SU-WTRU 302a can generate a broadcast request message and set the source L2 address to the anonymous L2 address (e.g., broadcast address / multicast address); at step 315, the SU-WTRU may include a service ID, but not a WTRU ID, and in this message, the SU-WTRU may include a service ID with the random parameters specified above or a hashed service ID; at step 320, if SP-WTRU 302b does not accept anonymous discovery, SP-WTRU 302b may ignore the request; at step 325, SP-WTRU 302b may broadcast / multicast a PC5 discovery response message. In this message, SP-WTRU 302b may include a service ID with the random parameters specified above or a hashed service ID.

[0087] In one implementation, the discovery process may include a metadata request. As described herein, a SU-WTRU discovering an SP-WTRU may want to obtain metadata from the SP-WTRU without having to establish unicast communication.

[0088] A SU-WTRU that wants to obtain metadata from an 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 specifying a service ID can reply by sending a discovery response message including 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 metadata in different PC5 messages depending on the length of the data. In this case, the indication carried in the PC5 message could be that more metadata exists in subsequent discovery messages. The SP-WTRU can also inform the SU-WTRU that the metadata is dynamic; in this 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 otherwise, the SU-WTRU can continuously monitor the PC5 discovery channel to receive updated metadata. In the case of dynamic metadata, the index or version can also be broadcast by the SP-WTRU to inform the monitoring WTRU which current version is being broadcast. If the SU-WTRU's index or version does not match the broadcast version, the SU-WTRU can request the latest version of the metadata.

[0089] In one implementation, the SU-WTRU may already know the SP-WTRU's application user ID (e.g., from deployment information or earlier discovery). In this case, the SU-WTRU may enable the discovery request to include the SP-WTRU's application user ID.

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

[0091] SU-WTRU 402a may want to discover SP-WTRU 402b for a specific service type (or a specific service) and want to obtain metadata. At step 410, SU-WTRU 402a may generate a broadcast discovery (or request) request message that includes the service ID, the SU-WTRU's application user ID, and a security element (e.g., calculating integrity protection using the apportioned information). SU-WTRU 402a may also include a request type (e.g., request), the SP-WTRU's application user ID, a metadata request indication, and a metadata type in the message. If metadata information is requested in the discovery response message, a metadata request indication can be specified. The metadata type can indicate the type of metadata requested, such as overview / details or short / medium / large. For example: if SP-WTRU 402b is a restaurant, the metadata may include the restaurant menu; if the metadata type is overview, only a simplified version of the menu is sent; and / or, if the metadata type is details, the full menu with prices is sent.

[0092] At step 415, SU-WTRU 402a may broadcast a discovery request message.

[0093] At step 420, the SP-WTRU 402b that receives the discovery request message can inspect the security element. If the SP-WTRU 402b successfully authenticates the security element, it can verify whether it supports the service ID. If the SP-WTRU 402b supports the service ID, it can view the metadata indication and prepare the metadata to be returned based on the metadata type. A 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.

[0094] At step 425, the SU-WTRU 402a may receive a discovery response message. At step 430, the SU-WTRU 402a may verify the security element and read the metadata.

[0095] As an example of the use of metadata in a discovery process, the SU-WTRU 402a can request metadata of type "Overview" without specifying the target SP-WTRU application user ID. The SU-WTRU 402a may then expect to receive multiple discovery response messages, such as responses from different SP-WTRUs (including SP-WTRU 402b). Because an overview of the metadata is returned in the discovery response message, the user of the SU-WTRU 402a can quickly view the overview metadata and request detailed metadata from a specific SP-WTRU. This can be accomplished by sending another discovery request message directly to the selected SP-WTRU (e.g., a destination with an L2 ID set to the SP-WTRU), including the SP-WTRU application user ID and the metadata type set to "Details".

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

[0097] Figure 5 An exemplary service-based discovery procedure 500 is illustrated, which can be used in conjunction with any other implementation described herein. At step 505, the WTRU (e.g., SU-WTRU) may receive core network deployment information or application server deployment information from a base station (BS), which includes a discovery type and security credentials for each 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 (pre-)determined or (pre-)configured for each service. Different services (or service types) may have different discovery types. For example, a restaurant service (or service type) may be associated with Model A, and a taxi service (or service type) may be associated with Model B. Security credentials can be a group key, a signing certificate, a root certificate, a symmetric private / public key pair, a shared secret, etc. Security credentials can be (pre-)determined for each service. Similar to the discovery type, different services (or service types) may have different security credentials. For example, a restaurant service (or service type) may be associated with a group key, and a taxi service (or service type) may be associated with a signing certificate. Alternatively or otherwise, a service-based discovery type and service-based security credentials in the WTRU can be configured for the WTRU. For example, the service-based discovery type and / or service-based security credentials can be pre-installed or pre-stored in the SIM card or memory.

[0098] At step 510, the WTRU (e.g., SU-WTRU) may generate a first security element based on the assigned security credentials. The first security element may differ from the assigned security credentials. It may be an output generated using the security credentials. For example, if the security credentials are a group key, the generated security element may be a Message Authentication Code (MAC). If the security credentials use public-key cryptography, the WTRU may include a certificate as part of the security element, which has a signature that the WTRU can provide to other WTRUs. If the security credentials are a secret key, the generated security element may be a MAC, and the receiving WTRU (e.g., SP-WTRU) can obtain the appropriate group key and verify that the MAC is correct.

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

[0100] At step 520, a WTRU (e.g., SU-WTRU) may 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 may be generated based on security credentials configured for the SP-WTRU. The second security element may differ from the security credentials configured for the SP-WTRU. It may be an output generated using the security credentials configured for the SP-WTRU. For example, if the security credentials configured for the SP-WTRU are a group key, the generated second security element may be a Message Authentication Code (MAC). If the security credentials configured for the SP-WTRU use public-key cryptography, the SP-WTRU may 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 credentials configured for the SP-WTRU are a secret key, the generated second security element may be a MAC, and the receiving WTRU (e.g., SU-WTRU) can obtain the appropriate group key and verify that the MAC is correct. Additionally, PC5 discovery response messages may include, but are not limited to, SP-WTRU identity, application identity, and metadata associated with services provided by the SP-WTRU. PC5 discovery response messages can also be broadcast messages from the SP-WTRU.

[0101] At step 525, if the WTRU (e.g., SU-WTRU) verifies or authenticates the second security element based on the security credentials assigned to the SU-WTRU, then at step 530, the SU-WTRU may initiate the establishment of a PC5 direct communication link with the SP-WTRU. In an implementation, the SP-WTRU and SU-WTRU may exchange metadata via the PC5 direct communication link. For example, a customer (i.e., the SU-WTRU) who discovers a restaurant service provider (i.e., the SP-WTRU) may only want to receive the restaurant's menu and not engage in full communication with the restaurant service provider (i.e., the SP-WTRU). However, if at step 525, the WTRU fails to verify or authenticate the second security element, then at step 520, the SU-WTRU may monitor and receive another PC5 discovery response message from another SP-WTRU.

[0102] Although features and elements have been described above in specific combinations of embodiments, those skilled in the art will understand that each feature or element may be used alone or in any combination with other features and elements. In other words, it is intended to combine features and elements from different embodiments. Furthermore, the methods described herein may be implemented in a computer program, software, or firmware incorporated into 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, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as internal hard disks and removable disks), magneto-optical media, and optical media (such as CD-ROM disks and digital versatile optical discs (DVDs)). A processor associated with the software may be used to implement a radio frequency transceiver for a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for use in a service utilizing a wireless transmit / receive unit (SU-WTRU), the method comprising: The SU-WTRU, configured with a discovery type and security credentials for each service, transmits a PC5 discovery message having the discovery type and a first security element generated based on the security credentials; Receive a PC5 discovery response message from the Service Providing Wireless Transmit / Receive Unit (SP-WTRU), the PC5 discovery response message including a second security element and a service identity identifier associated with the service provided by the SP-WTRU.

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 2, further comprising: Transmit a metadata request message to the SP-WTRU via the PC5 communication link; And receive metadata response messages from the SP-WTRU, the metadata response messages including metadata associated with the service provided by the SP-WTRU through the PC5 communication link.

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

5. The method according to claim 1, wherein, The PC5 discovery message also includes WTRU identity, service identity, application identity, and metadata request.

6. The method according to claim 1, wherein, The PC discovery response message also includes the WTRU identity, the application identity, and metadata associated with the service provided by the SP-WTRU.

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

8. 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.

9. The method according to claim 1, wherein, The first security element includes at least one of a signature or a Message Authentication Code (MAC).

10. The method according to claim 1, wherein, The second security element is generated based on the security credentials configured for the SP-WTRU.

Images