This Annex presents an example how the Assistance Information can be designed to expedite WLAN direct discovery and communication. The Assistance Information content depends on the WLAN technology.

Wi-Fi Peer-to-Peer (P2P) specification [13] defines an architecture and set of protocols that facilitate direct discovery and communication using the IEEE 802.11 technology [14]. To assist WLAN direct discovery and communication as required by the Wi-Fi P2P technology [13] the EPC needs to supply some or all of the following items as part of the Assistance Information:

• SSID: The SSID to use for Wi-Fi P2P operation. To be compliant with the Wi-Fi P2P specification [13] the SSID should be in the form "DIRECT-ab" where a, b are two random characters.
• WLAN Secret Key: The pre-shared key to be used by UEs to secure their Wi-Fi P2P communication. This is used by UEs as the Pairwise Master Key (PMK).
• Group Owner indication: If set, the UE should implement the Group Owner (GO) functionality specified in the Wi-Fi P2P specification [13]. The UE implementing this functionality essentially becomes an AP that transmits Beacons with the P2P Information Element and accepts associations from other Wi-Fi P2P devices or from legacy Wi-Fi devices (those not implementing the Wi-Fi P2P functionality). If not set, the UE should behave as a Wi-Fi P2P client that attempts to discover and associate with a GO.
• P2P Device Address of self: This is the WLAN Link Layer ID to be used by a UE when participating in a Wi-Fi P2P group.
• P2P Device Address of peers: This is a list of WLAN Link Layer IDs provided to a UE implementing the Group Owner functionality in a Wi-Fi P2P group. Such UEs should accept WLAN association requests only from devices that are included in this list.
• Operation channel: The channel on which Wi-Fi P2P discovery and communication should take place.
• Validity time: The time period during which the content provided in the assistance information is valid.

The wildcard indicator, in the MNC or MCC part of the PLMN ID of the ProSe Application ID indicates whether this particular ProSe Application ID is PLMN specific (in which case neither MCC nor MNC will be wild carded) or countrywide (in which case the MNC part will be wild-carded) or global (in which case both the MCC and MNC parts will be wild-carded). Countrywide or global ProSe Application IDs belong in different data structures that are managed by "authorities" not associated with a specific PLMN. Notwithstanding the description in this annex, showing both PLMN specific and country-wide or global data structures, this does not preclude that in the future the country-wide or global data structures may supersede the PLMN specific data structures.

This arrangement between the PLMN and the "authority" that allocates these ProSe Application IDs is out of scope of 3GPP in this release of the specification.

The monitoring or announcing UE can request to monitor or announce a ProSe Application Code that has countrywide or global scope following the procedures defined in clause 5.3.3 by wildcarding accordingly the MNC element of the PLMN ID of the ProSe Application ID (for countrywide) or both the MCC and MNC (for global) elements of the PLMN ID of the ProSe Application ID. The monitoring UE will have to know whether to send a monitoring request for PLMN specific, or countrywide, or global ProSe Application ID, based on the configuration that applies to the particular data structure. If country-wide or global data structures are used then PC6 and PC7 interfaces are not used for monitoring requests. For example if the UE is interested to monitor or announce for restaurants that are registered in a configured PLMN specific data structure (e.g., local restaurants in a particular geographical area) it will send a monitoring request that contains only the following PLMN specific ProSe Application ID. If on the other hand the UE is interested to monitor or announce for restaurants that are registered in the configured global data structure (e.g., chain restaurants present in several countries/available all over the world) it will send a monitoring or announcing request that contains only the global ProSe Application ID. The monitoring UE can also send multiple ProSe Application IDs with different scope in the same request, but overall it should not be considered that one ProSe Application ID replaces the other.

This Annex provides examples of how the WLAN technologies can be used in ProSe Direct Discovery for transport of the ProSe Protocol messages and/or information elements. The WLAN-based transport depends on the underlying WLAN technology.

Wi-Fi Neighbor Awareness Networking (NAN) specification [38] defines an architecture and set of protocols that facilitate direct discovery and communication using the IEEE 802.11 [14] technology. Figure C.2-1 shows the high-level architecture of a NAN Device.

When a ProSe-enabled UE uses the Wi-Fi NAN technology in ProSe Direct Discovery, the ProSe Protocol layer acts as one of the applications shown in Figure C.2-1 and interacts with the underlying NAN Discovery Engine through a logical interface that is described in terms of method and event primitives in the NAN Wi-Fi Neighbor Awareness Networking (NAN) specification [38]. The PC5_DISCOVERY message, specified in TS 24.334, is passed by means of the "Publish" method from the ProSe Protocol layer to the NAN Discovery Engine and inserted in the Service Descriptor Attribute (see Wi-Fi Neighbor Awareness Networking (NAN) specification [38]). The content of the Service Descriptor Attribute is illustrated in Table C.2-1. The table also indicates how the individual fields of the Service Descriptor Attribute are used for transport of the PC5_DISCOVERY message.

The ProSe Protocol layer in the UE participating in the discovery process using the Wi-Fi NAN technology subscribes to the Service ID for the 3GPP-defined Service Category for ProSe. The NAN Discovery Engine accepts all the Service Discovery Frames received over the air with a matching Service ID, extracts the PC5_DISCOVERY messages and generates a "DiscoveryResult" event that conveys the PC5_DISCOVERY messages to the ProSe Protocol layer for further processing.