4.1.1 Proximity Services Overview

Proximity Services, in short ProSe, provides mechanisms for devices to discover other devices in close proximity and to communicate with other devices directly, that is, without the data path being routed via the network infrastructure. This is illustrated with an example – Fireman John and Fireman Bob are located in the same building and they are trying to discover each other's presence and communicate when they are in proximity. In a traditional cellular network, if John and Bob want to communicate even when they are in proximity, their devices have to connect to the network first in order to transmit any kind of data through the mobile radio and core network infrastructure. With the introduction of ProSe, devices like the ones owned by John and Bob can discover each other and transmit user plane traffic directly between them in proximity. The “proximity range” depends certainly on the strength of the radio signal and other radio conditions such as interference. The actual range (e.g., 50 m, 200 m, or 1 km) varies depending on the power level used for transmitting the radio signal.

The ProSe function consists mainly of mechanisms on LTE radio level in order to enable direct discovery and communication between two or more devices. Functions and capabilities introduced by ProSe can be used by any application running on top of a ProSe-enabled device. Public Safety (PS) is one of the ProSe use cases, file sharing and friend finder are potentially other use cases.

ProSe partly breaks the paradigm for the User Equipment (UE) to “receive before transmit” and complicates radio interference situations by UEs now transmitting on frequencies they previously only used to listen. ProSe is an optional functionality and it is up to the manufacturer of a UE to decide whether to implement the ProSe feature. There are two types of ProSe-enabled UEs, one supporting “social” or “commercial” use cases for ordinary mobile subscribers, referred to as “ProSe-enabled non-Public Safety UE” and the other supporting “PS” use cases, referred to as the “ProSe-enabled Public Safety UE” for use by PS personnel such as first responders, and police fire brigades. They differ in the ProSe-related feature set they have to support. For PS use cases, direct communication is a must have feature, while direct discovery can be omitted.

4.1.2 ProSe Communication

Before the introduction of PS all data traffic originating or terminating from/to a UE had to pass through at least parts of the network as depicted in Figure 4.1.

There had already been attempts in the past to define direct communication between UEs. In the late 1990s, a direct mode of operation was defined for Global System for Mobile Communications (GSM)/GSM/EDGE Radio Access Network (GERAN)-based railway communication but has not been deployed due to radio interference problems and consequently the lack of chipsets supporting it.

With the advent of more modern radio technologies and the surge in mobile data communication caused by Smart phones, the situation began to change. Operators were confronted with a tremendous increase in data traffic per device and, at the same time, decrease in revenue per amount of data transferred. To cope with this, 3rd Generation Partnership Program (3GPP) had already specified local breakout mechanisms such as Local Internet Protocol Access (LIPA) or Selective IP Traffic Offload (SIPTO). These mechanisms allow low-revenue traffic to exit to local area networks at home or a campus, or to connect to the Internet close to the user before consuming too much network resources.

As some of this low-revenue traffic involves only sender and receiver that are close together, for example, friends sitting together sharing pictures or playing online games, the idea for direct communication was becoming obvious again.

This communication scenario in Figure 4.2 is referred to as “ProSe communication” or “Direct Communication.” ProSe Communication can take place using Long-Term Evolution (LTE) or Wireless Local Area Network (WLAN) radio technology. In case of WLAN radio technology, ProSe only assists in the connection establishment and with service continuity aspects, as the WLAN radio technology is out of scope of 3GPP and allows already for a direct communication mode (“WLAN ad hoc networks”). The mobile network can control resources used for ProSe communication and must authorize the use of ProSe communication. The most obvious reason for this being the use of licensed spectrum the operator owns, further, in many countries, by licensing terms, operators are obliged to be in control how their licensed spectrum is used.

To have even stricter means of resource usage control, a locally routed communication scenario was introduced by 3GPP by which traffic is routed via an Evolved NodeB (eNodeB) in reach of both communication partners (Figure 4.3).

This mode of operation, however, defeats the purpose of efficient resource usage as the licensed spectrum is expensive and the potentially congested radio links to the eNodeB are still being used. For this reason, the locally routed data path scenario is not expected to be widely deployed and was not specified in Release 12.

4.1.3 ProSe Discovery

Motivation for ProSe Discovery is mainly the desire to provide new proximity services for social applications, advertisement, and location-based services to mobile devices. Nowadays, location-based services mainly rely on a combination of Global Positioning System (GPS), cellular (e.g., Assisted GPS), and Wi-Fi technologies.

ProSe Discovery is a competing feature allowing a UE to discover that another UE is in proximity. ProSe Discovery can be considered a stand-alone feature; its use is not necessarily tied to or followed by ProSe communication. As a result, ProSe Discovery is a functionality that can be offered as a stand-alone service to ProSe-enabled UE(s). However, in order to communicate with each other directly, Public Safety communication partners in proximity would benefit of previous ProSe Discovery. The authorization to use the discovery mechanism can be given to a UE in general or only to certain applications residing on the UE. For example, the operator could allow the use of ProSe Discovery mechanisms for a “friend finder” application but not for locating shops or for updating the contacts list of a chat application.

The ProSe Discovery feature is defined in an “open mode” and in a “restricted mode.” For the open mode, no permission is needed from the UE that is to be discovered, while the restricted mode requires permission from the UE that is being discovered.

The criteria to decide when a UE is assumed to be in range of another UE (in the context of ProSe) can be defined by the operator and likewise the operator has to authorize the use of the discovery mechanism and resources by a UE.

Following are the two different discovery procedures supported in Release 12:

1. ProSe Direct Discovery
2. EPC-level Discovery

The most interesting discovery mechanism for Public Safety devices is “ProSe Direct discovery” or simply referred to as “Direct discovery” as this enables the UE to discover other UEs without network coverage. Public Safety use cases may not require an automated discovery procedure in the device as Public Safety personnel may recognize each other within a certain area (e.g., if two firemen are in direct in visibility). However, in isolated firefighter scenarios, direct discovery is an essential feature for Public Safety use cases.

Also, if a police officer wishes to explicitly disconnect from the network, Evolved Packet Core (EPC) (network) assisted discovery or EPC-level discovery cannot be used. EPC-level discovery is expected to be used mostly for commercial reasons and in cases where the devices or the network do not support the direct discovery mode. If two friends are entering a football stadium and trying to discover each other's presence, their devices can use the EPC-level discovery mechanism to alert each other when they are in close proximity.

4.1.4 ProSe for Public Safety

The mechanisms described earlier constituting the ProSe feature can also be used for PS communication purposes. One core requirement for PS scenarios is a direct link communication between two or more UEs. The main reason for this requirement is to have a fallback communication solution in case there is a network outage or the users themselves decide to disconnect from the network and use direct communication.

However, ProSe has to fulfill some special requirements when it is being used for PS communication. This is why 3GPP defined a special type of ProSe-enabled UE, namely, the “ProSe-enabled Public Safety UE”.

In contrast to an ordinary ProSe-enabled UE, the Public Safety ProSe-enabled UE may initiate ProSe communication without previous discovery to accelerate the setup of communication, for example, in emergency situations. This use case most closely resembles the “walkie-talkie” style of communication between legacy Public Safety communication devices, in which the reception of the communication by others cannot be guaranteed.

Unlike commercial communication scenarios, the Public Safety ProSe-enabled UE can establish ProSe Direct communication links directly with other Public Safety ProSe-enabled UEs, regardless of whether the Public Safety ProSe-enabled UE is served by Evolved Universal Terrestrial Radio Access Network (E-UTRAN) or not. A Public Safety ProSe-enabled UE is always capable to participate in ProSe Direct communication between two or more PS ProSe-enabled UEs which are in proximity to each other.

A Public Safety ProSe-enabled UE still needs to be authorized by the network operator to make use of ProSe. Requesting authorization from the network to use ProSe may not work in all cases as the Public Safety ProSe-enabled UE can also be out of network coverage or other UEs that are out-of-coverage require direct communication. As a consequence, this kind of authorization has to be provided either by configuring the UE or Universal Subscriber Identity Module (USIM) beforehand. There is even a requirement for a new UE to work “out of the box” when powered up for the first time while being without network coverage, the use case for this being, for example, a firefighter having to replace his UE in an emergency situation without network coverage.

There are two ProSe functions that are only available to Public Safety ProSe-enabled UEs. The first one being the ProSe UE-to-Network Relay where one Public Safety ProSe-enabled UE that is in network coverage relays communication between the network and other Public Safety ProSe-enabled UEs that might not be in network coverage. The second one being the ProSe UE-to-UE Relay by which a Public Safety ProSe-enabled UE relays ProSe communication to other Public Safety Prose-enabled UEs that might not be in close proximity to each other. Both functions are intended, for example, for scenarios where firemen entering a building lose network coverage but still are in contact with their commander or car outside the building. Figure 4.4 shows the described relay scenarios.

In the subsequent sections, we describe how proximity services can actually be realized in LTE networks and LTE devices.

The stage 1 feasibility study on proximity services was documented in 3GPP TR 22.803[1] while the majority of service requirements were documented in 3GPP TS 22.278[2].

4.2.1 Non-Roaming Architecture

This architectural model (see Figure 4.5) assumes the simplest configuration in which two UEs (UE-A and UE-B) trying to communicate with each other, have subscribed to the same PLMN and both UEs are registered in their home PLMN.

An overview of the main ProSe reference points, their roles, and the underlying protocols can be found in Section 4.2.5.

4.2.2 Inter-PLMN Architecture

This architectural model (see Figure 4.6) assumes the two UE(s) UE-A and UE-B have subscribed to different PLMN(s) PLMN A and PLMN B but the PLMN(s) are located in the same country. It also assumes that the two UE(s) are registered in their home PLMNs.

4.2.3 Roaming Architecture

This configuration is more complex. It is assumed that the UE(s) have subscribed to different PLMN(s) and one of the UEs is roaming, for example, UE-A is subscribed to PLMN A but is roaming in PLMN C. UE-B is subscribed to PLMN B and located in PLMN B. This architectural model is shown in Figure 4.7.

4.2.4 Description of Functional Entities

This section provides a description of functional entities that are required in order to support ProSe. These functions are needed in addition to the basic functions required for LTE/SAE as described in Chapter 1. Functional entities that are not impacted by ProSe are not described in this section.

4.2.4.1 ProSe Function

This newly introduced ProSe Function plays different roles in order to support all the features required for ProSe. In 3GPP Release 12, it has been assumed that there is only one ProSe Function in each PLMN supporting ProSe. Thus, if an operator deploys multiple ProSe Functions within the same PLMN, there is no standardized procedure for the UE to discover all of these ProSe Functions (the simplest way is certainly to configure a logical name or address of the ProSe Function on the devices). In real deployments, it is possible that this ProSe Function is not implemented as a separate network element but is collocated with another network element that resides in the user plane path of the UE. This would allow that an already deployed network element is just upgraded to support the functionalities required for the ProSe Function.

The ProSe Function consists of three main subfunctions that perform different roles depending on the ProSe feature:

• The Direct Provisioning Function (DPF) is used to provision the UE with necessary parameters in order to use ProSe Direct Discovery and ProSe Direct Communication. The UEs are provisioned with PLMN specific parameters allowing them to use ProSe in a specific PLMN. This includes information such as list of PLMNs in which a UE can perform Direct Discovery and parameters needed for Direct Communication when the UE is “out of network” coverage.
• The Direct Discovery Name Management Function is used for open ProSe Direct Discovery (also referred to as ProSe Direct Discovery in an “open mode”) to allocate and process the mapping of ProSe Application IDs and ProSe Application Codes. It uses ProSe-related subscriber data stored in the Home Subscriber Server (HSS) for authorization of each discovery request. It also provides the UE with necessary security data to protect discovery messages exchanged over the air interface.
• The EPC-level Discovery ProSe Function is used to provide network-assisted discovery using location information to UE(s).

In addition, the ProSe Function provides the necessary functionality to collect charging data for usage of ProSe Direct Discovery, ProSe Direct Communication, and EPC-level ProSe Discovery in HPLMN, VPLMN, and Local PLMN.

The IP address of a ProSe Function can be discovered through interactions with Domain Name System (DNS). The Fully Qualified Domain Name (FQDN) of a ProSe Function in the HPLMN may either be preconfigured in the UE or automatically provisioned by the network or self-constructed by the UE, for example, derived from the HPLMN Identity using a certain scheme.

Figure 4.8 shows the internal ProSe Function structure.

Figure 4.9 provides an overview of the different ProSe Function interfaces.

4.2.4.4 ProSe UE-to-Network Relay

The ProSe UE-to-Network Relay (see Figure 4.10) provides connectivity to “unicast” services for Remote UEs that are not in network coverage. Although this function was introduced to the ProSe architecture, it was not specified in 3GPP Release 12.

The ProSe UE-to-Network Relay can relay unicast traffic (in Uplink (UL) and Downlink (DL)) between the Remote UE and the network. The ProSe UE-to-Network Relay can also provide generic functions to relay any type of traffic that is relevant for Public Safety communication. If the Remote UE moves out of ProSe UE-to-Network relay coverage, then its IP address is not preserved.

4.2.5 Interfaces and Protocols

4.2.5.1 Control Plane

The control plane consists of protocols to control and support the establishment, modification, and termination of the user plane. This includes the following functions:

• Control the UE configuration data related to ProSe.
• Control of ProSe Direct Discovery functions.
• Control the setup of the connection between Remote UE and ProSe UE-to-Network Relay.
• Control attributes of an established network connection, such as activation of an IP address.

UE–ProSe Function

ProSe control plane signaling between UE and ProSe Function (PC3 interface) is carried over the user (data) plane (see Figure 4.11).

PC3 Control Protocol

It is used to enable communication between a ProSe-enabled UE and the ProSe Function and is specified in 3GPP TS 24.334[5]. The UE and ProSe Function use the Hypertext Transfer Protocol Version 1.1 (HTTP 1.1) as specified in IETF RFC 2616[11] as transport protocol for ProSe control plane messages over PC3.

HSS–ProSe Function

Figure 4.12 shows the control plane protocol stack between ProSe Function and HSS.

PC4a DIAMETER Application

Main function of PC4a is the transfer of subscription and authentication data between HSS and ProSe Function. DIAMETER is defined in IETF RFC 3588[12] and the PC4a DIAMETER application in 3GPP TS 29.344[6].

SLP–ProSe Function

Figure 4.13 shows the control plane protocol stack between ProSe Function and SUPL Location Platform (SLP).

Mobile Location Protocol (MLP)

It is used to carry location information as specified in Open Mobile Alliance Location Interoperability Forum Mobile Location Protocol (OMA LIF MLP) between SLP and ProSe Function.

UE–UE

Figure 4.14 shows the control plane protocol stack between two ProSe-enabled UEs.

ProSe Control Protocol

It is used for handling control messages to support ProSe Direct Discovery and ProSe UE-to-Network Relay Discovery and is specified in 3GPP TS 24.334[5].

Access Stratum

Access Stratum (AS) performs the following functions:

• Interfaces with Upper Layer: The Medium Access Control (MAC) layer receives the discovery information from the upper layer (i.e., upper layer refers to application layer or Non Access Stratum (NAS) layer). The IP layer is not used for transmitting the discovery information. The discovery information is transparent to Access Stratum.
• Scheduling: The MAC layer determines the radio resource to be used for transmitting the discovery information.
• Discovery Protocol Data Unit (PDU) generation: The MAC layer builds the MAC PDU carrying the discovery information and sends the MAC PDU to the PHY layer for transmission over the radio resource.

ProSe Function–ProSe Function

Figure 4.15 shows the control plane protocol stack between two ProSe functions. PC6 is an inter-PLMN interface and PC7 is the corresponding roaming interface.

PC6/PC7 DIAMETER Application

It supports the transfer of subscriber location related information between ProSe Functions over the PC6 and PC7 interfaces. This interface is used when the ProSe Function in the HPLMN collects authorization and configuration information from other PLMNs. In roaming scenarios it is also used to authorize ProSe Direct Discovery requests, retrieve the Discovery Filter(s) corresponding ProSe Application ID name(s), and translate the ProSe Application Code to the ProSe Application ID Name. Further details regarding PC6/PC7 interfaces can be found in 3GPP TS 29.345[9].

ProSe Function–ProSe Application Server

Figure 4.16 shows the control plane protocol stack between ProSe Function and ProSe Application Server.

PC2-AP

PC2-AP is the PC2 Application Protocol and is specified in 3GPP TS 29.343[4]. This interface is used for EPC-level ProSe Discovery, for functions such as create the mapping between application level user identifiers and EPC ProSe User IDs.

User Plane

UE–UE

Figure 4.17 shows the user plane protocol stack between two ProSe-enabled UEs.

PC5-U

The E-UTRA radio protocols PHY, MAC, Radio Link Control (RLC), and Packet Data Convergence Protocol (PDCP) between two UEs (similar to the ones used between eNB and UE) are described in Chapter 1 and specified in 3GPP TS 36.300[8].

UE–UE-to-Network Relay

Figure 4.18 shows the user plane protocol stack between a ProSe-enabled UE and a UE-Network-Relay.

Summary of Reference Points and Protocols

Table 4.1 summarizes the reference points and protocols used for ProSe.

Reference point	Protocols	Specifications
PC1	Not specified in 3GPP	Not specified in 3GPP
PC2	PC2-AP	TS 29.343[4]
PC3	ProSe Protocol (over HTTP)	TS 24.334[5]
PC4a	DIAMETER	TS 29.344[6]
PC4b	MLP	OMA LIF MLP[7]
PC5	UP: PHY, MAC, RLC, PDCP CP: ProSe Protocol	TS 36.300[8], TS 24.334[5]
PC6	DIAMETER	TS 29.345[9]
PC7	DIAMETER	TS 29.345[9]

4.3.1 LTE Primary and Secondary Synchronization Signals

Cell synchronization is the very first step a UE performs when it wants to camp on a cell. During synchronization the UE acquires a Physical Cell ID (PCI), time slot, and frame synchronization, which will enable the UE to read System Information Blocks (SIBs) from a particular network (see also 3GPP TS 36.300[8]).

The UE will tune its radio by tuning to different frequency channels depending on the bands it is supporting. Assuming that it is currently tuned to a specific band or channel, the UE first finds the Primary Synchronization Signal (PSS), which is located in the last Orthogonal Frequency Division Multiplexing (OFDM) symbol of the first time slot of the first subframe (subframe 0) of a radio frame. This enables the UE to be synchronized on subframe level. The PSS is repeated in subframe 5, which means the UE is synchronized on a 5 ms basis because each subframe is 1 ms long. From the PSS, UE is also able to obtain physical layer identity (0 to 2).

In the next step, the UE finds the Secondary Synchronization Signal (SSS). SSS symbols are also located in the same subframe of PSS but in the symbol before PSS as shown in Figure 4.19. From SSS, the UE is able to obtain the physical layer cell identity group number (0 to 167).

Using physical layer identity and cell identity group number, UE knows the PCI for this cell. In LTE 504 physical layer cell identities are allowed and are divided into unique 168-cell layer identity groups where each group consists of three physical layer identities. As mentioned earlier, the UE detects physical layer identity from PSS and physical layer cell identity group from SSS and calculates the PCI.

Once the UE knows the PCI for a given cell, it also knows the location of cell reference signals. Reference signals are used in channel estimation, cell selection, cell reselection, and handover procedures.

After the cell synchronization procedure (reference 3GPP TS 36.211[13]), the UE will proceed to read the Master Information Block (MIB) and other SIBs like SIB1 and SIB2 (refer to Terms and Definitions section for definitions of MIB and SIB). Once it has the necessary parameters, the UE can request the eNodeB for a Radio Resource Control (RRC) connection establishment so that it can exchange signaling information with the network. Then, it uses the established RRC connection to register with the network and this process is called “Initial Attach” (explained in Section 1.6.9).

4.3.2 LTE D2D Synchronization

A D2D Synchronization Source transmits at least a D2D Synchronization Signal (D2DSS). The D2D Synchronization Source can either be a ProSe-enabled UE or an eNodeB. The transmitted D2DSS is used by a UE to obtain time and frequency synchronization information. The D2DSS transmitted by a D2D Synchronization Source, which is an eNodeB when the UE is in network coverage, is the well-known Release 8 LTE PSS/SSS. The structure of D2DSS transmitted by D2D Synchronization Sources other than the eNodeB follows the signal design defined for D2D in Release 12. Working assumption is that a synchronization source has a physical layer identity known as Physical Layer Identity (PSSID). At the time of writing this book, the structure of D2DSS is yet to be finalized in 3GPP RAN Working Group 1.

The concept of a Physical D2D Synchronization Channel (PD2DSCH) transmitted by a D2D Synchronization Source is likely to be defined in 3GPP.

If a D2D Synchronization Source is detected, the UE synchronizes its receiver to the source before it transmits the D2DSS. UEs may transmit at least a D2DSS derived from the D2DSS received from a D2D Synchronization Source (e.g., another ProSe-enabled UE). If a UE transmits a D2DSS, certain rules are followed for determining which D2D Synchronization Source the UE uses as the timing reference for its transmissions of D2DSS. Rules for determining which D2D Synchronization Source the UE uses as timing reference for its transmissions of D2D signal are as follows:

• D2D Synchronization Sources, which are eNodeBs, have a higher priority than D2D Synchronization Sources which are UEs
• D2D Synchronization Sources, which are UEs in-network-coverage, have a higher priority than D2D Synchronization Sources, which are UEs out-of-network-coverage
• After giving priority to D2D Synchronization Sources, which are eNodeBs, followed by UEs in-network-coverage, selection of D2D Synchronization Source is based on metrics such as received D2DSS quality.

If no D2D Synchronization Source is detected, a UE may nevertheless transmit D2DSS. A UE may reselect the D2D Synchronization Source it uses as the timing reference for its transmissions of D2DSS, if the UE detects a change in the D2D Synchronization Source(s). Detailed rules for selection are for further study in 3GPP.

It is assumed that D2DSS transmission configuration is the same for ProSe Direct Discovery and ProSe Direct Communication, if the network supports both. D2D synchronization is a prerequisite to perform ProSe Direct Discovery and ProSe Direct Communication.

4.5.1 ProSe Direct Discovery Models

In case of direct discovery, following are the two possible discovery models:

1. Model A (“I am here”): In this model, the UE announces its presence to other UE(s) who are interested in reading and/or processing the messages. The UE that announces certain information (e.g., its ProSe Identity) that could be used by other UE(s) in proximity is called the “announcing UE.” The UE that has the permission to discover and the interest to read and/or process messages from an “announcing UE” in proximity is called the “monitoring UE.”
2. Model B (“who is there?” or “are you there?”): In this model, the UE tries to discover other UE(s) by sending a request containing certain information. The UE that transmits a request containing information like its ProSe Application ID is called as “Discoverer UE.” The UE that receives and processes the request message and responds to the request is called the “Discoveree UE.”

In Release 12, 3GPP specified solutions and procedures to support Direct Discovery based on “Model A” only.

4.5.2 ProSe Direct Discovery Modes

There are two types of direct discovery modes: Open and Restricted discovery. Open discovery means there is no explicit permission needed from the UE that is being discovered. Restricted discovery means explicit permission is needed from the UE that is being discovered. In Release 12, 3GPP specified solutions and procedures for “open discovery mode” only.

Use cases for open discovery may include discovering some public machine type devices (e.g., a vending machine located close to a restaurant) for which no permission is needed from the UE (within the vending machine) that is being discovered. Restricted discovery may be the most commonly used mechanism for devices used by humans to avoid privacy concerns (e.g., discovering a fireman entering a building or discovering a user walking close to a coffee shop will probably require explicit permission from the fireman or user).

4.5.3 Direct Discovery Procedure for Model A

This discovery procedure is only applied for open ProSe Discovery when the ProSe-enabled UE is served by E-UTRAN. The UE obtains service authorization from the HPLMN and serving PLMN, as described in the service authorization section.

The ProSe Application ID is used to identify applications for ProSe Direct Discovery. ProSe Application ID is globally unique and can be PLMN specific, country specific, or a global identity. Each ProSe Application ID is composed of the ProSe Application ID Name and a PLMN ID. The ProSe Application ID Name is described in its entirety by a data structure characterized by different levels, for example, broad-level business category (Level 0), business subcategory (Level 1), business name (Level 2), and shop ID (Level 3). The PLMN ID part consists of the Mobile Country Code (MCC) and Mobile Network Code (MNC) of the PLMN that assigned the ProSe Application ID. If the ProSe Application ID is country specific, then the MNC is wildcarded by “*.” If it is global, then both the MCC and MNC are wildcarded by “*.”

When the UE announces its presence, it initiates a “discovery request for announcing” to the ProSe Function in the HPLMN. The discovery request contains the ProSe Application ID of the application whose availability is intended to be announced. If the request is successful, it obtains the ProSe Application Code from the ProSe Function. The UE uses that for the announcing procedure over the PC5 interface.

The ProSe Application Code is a temporary code that corresponds to the ProSe Application ID and it is UE specific. It is used to enable “monitoring UE” discover the presence of the “announcing UE”. Each ProSe Application Code is composed from a temporary identity and a PLMN ID that corresponds to the PLMN that assigned the ProSe Application Code. The temporary identity internal structure also follows the structure associated with the ProSe Application ID (i.e., it contains separate identifiers for each level of the Application ID) to enable partial matching at the monitoring UE side using a ProSe Application Mask or a Discovery Filter. The ProSe Application Code has a validity time that determines how long it is valid and can be used.

A ProSe Application Mask consists of one or more applicable parts of temporary identities of ProSe Application Codes to allow partial matching of ProSe Application Codes. A ProSe Application Mask is contained in a Discovery Filter.

When the UE is triggered by an application to monitor for other UEs that are in proximity and it has the authorization to monitor, it initiates a discovery request for monitoring towards the ProSe Function. The monitoring UE has to know whether it needs to send a monitoring request for PLMN specific, countrywide or a global ProSe Application ID as its scope is encoded in the Application ID.

If the request is successful, it obtains the Discovery Filter that consists of ProSe Application Code(s) and/or ProSe Application Mask(s). Then it starts monitoring for these ProSe Application Code(s) on the PC5 interface. When the UE detects that one or more advertised ProSe Application Code(s) match the given filter (i.e., are part of the filter), it reports these ProSe Application Code(s) to the ProSe Function.

In order for a ProSe Application Code to match the given filter, it requires matching of all components of the ProSe Application Code. It is considered a full match when both PLMN ID and temporary identity match with the corresponding content of the Discovery Filter. Thus, a Discovery Filter with ProSe Application Mask set to all 1's can be used for identification of full match of the service indicated in ProSe Application Code. Discovery Filter with ProSe Application Mask that is set to 1's for the parts that should match, set to 0's for the parts that can be masked allows partial matching of as many parts of the ProSe Application Code that are contained in the ProSe Application Mask. A partial match occurs when the PLMN ID matches fully and the temporary identity matches partially with the corresponding content of the Discovery Filter. Refer to Section 4.8.6 for an illustration on how match procedure is performed using Application mask, Application Code, and a Discovery Filter.

Subsequent sections explain how direct discovery (announce, monitor, match procedures) work for non-roaming and roaming scenarios. In addition, it provides some insights about radio aspects with a focus on radio resource allocation for direct discovery procedure.

4.5.4 Radio Aspects and Physical Layer Design

The UE can participate in announcing and monitoring of discovery information in both RRC_IDLE and RRC_CONNECTED state. The UE announces and monitors its discovery information subject to the half-duplex constraint. In a half-duplex operation, transmitter and receiver cannot operate simultaneously. In the transmitter mode, UE can initiate announce procedure and in the receiver mode, it can perform monitoring. In simple terms, half-duplex implies that one party talks while the other party listens (i.e., walkie-talkie style).

Working assumption in 3GPP RAN WG is that the “announcing UE” is transmitting certain information that helps the “monitoring UE” to do a direct discovery using the new physical and transport channels that will be defined in 3GPP (refer 3GPP TR 36.843[14]). The transport and logical channels used for direct discovery are different from those used for direct communication. In order for the UE to perform direct discovery, E-UTRA radio resources are necessary. The E-UTRA network (eNodeB) controls the allocation of resources, that is, either configures resource pools or schedules the actual resources to be used. The actual discovery messages and information are transmitted directly from the announcing UE to the monitoring UE(s) using the new physical transport channel. The announcing UE(s) selects the resources that are part of the “resource pool” for the announcement. The monitoring UE(s) have to know which channel and what time slot to look for potential transmissions of discovery messages from announcing UE(s). Monitoring UE(s) obtain this information from the network. It is assumed that this information could be read by the UE(s) from a System Information Broadcast (SIB) provided by the network.

Announcing and monitoring UE maintain the current Coordinated Universal Time (UTC). The announcing UE transmits the discovery message, which is generated by the ProSe protocol taking into account the UTC time upon transmission of the discovery message. In the monitoring UE the ProSe protocol provides the message to be verified together with the UTC time upon reception of the message to the ProSe function (for the use of UTC time see also Section 4.8.3).

4.5.5 Radio Resource Allocation for Direct Discovery

Discovery transmission resource configuration data consist of discovery period, number of subframes within a discovery period that can be used for transmission of discovery signals, and physical resource blocks (PRBs). The actual number of PRBs is yet to be decided in 3GPP. As mentioned earlier, the range for the discovery depends on the signal and radio conditions such as interference. The “maximum power transmission” level for the discovery signal to perform the discovery procedure will need to be authorized by the eNB.

There are two types of resource allocation for discovery information announcement[15].

• Type 1: A resource allocation procedure where resources for announcing of discovery information are allocated by the network that is not specific to a certain UE. In this case, the eNB provides the UE(s) with resource pool configuration that can be used for announcing discovery information. The eNB can signal this information in SIB. UE can select the radio resource from the resource pool and use this for announcing discovery information. Resource pool that is necessary for monitoring procedure can also be configured in the UE(s).
• Type 2: A resource allocation procedure where resources for announcing discovery information are allocated by the network that is specific to a certain UE. When the UE is in RRC connected mode, UE can request resource(s) for announcing discovery information and eNB can allocate resources using dedicated RRC signaling messages. The NAS layer (see 3GPP TS 24.301[16]) within the UE will initiate the trigger for a RRC establishment procedure to obtain these radio resources by sending a Service Request message (described in Section 1.6.9). The resource pool that is necessary for monitoring procedure can also be configured in the UE(s).

When the UE is in RRC_IDLE mode, the eNB can provide Type 1 resource pool for discovery announcement in SIB that the UE can use for announcing discovery information. UE(s) that are authorized to perform discovery can use these resources for announcing discovery information. Alternatively, eNB can also indicate that it supports the D2D discovery feature but not provide any resource for discovery information announcement. This implies that the UE has to enter the RRC connected state in order to request D2D resources for discovery information announcement.

When the UE is in RRC_CONNECTED state, the UE that is authorized to perform ProSe direct discovery can request the eNB for resources. First, eNB validates whether the UE is authorized for ProSe direct discovery procedure based on the UE context information received from the MME. Second, if the UE is authorized to perform discovery, the eNB allocates necessary resources either by configuring the UE to use Type 1 resource pool or by allocating necessary resources using dedicated RRC signaling procedures.

UEs in RRC_IDLE and RRC_CONNECTED states monitor both Type 1 and Type 2 discovery resource pools as authorized. The eNB provides the resource pool configuration used for discovery information monitoring in SIB. The SIB may also contain discovery resources used for announcing in neighbor cells.

Discovery resources can be overlapping or nonoverlapping across cells. The serving cell may provide which neighbor frequencies support ProSe discovery in SIB. For a synchronized, full-overlapping, intra-frequency deployment, the eNB provides just one resource pool.

Resources allocated by the eNB may remain valid until the eNB revokes the resources using explicit RRC signaling procedures or the UE moves to idle mode.

4.5.6 Inter-frequency ProSe Discovery

In Release 12 inter-frequency ProSe Discovery (intra-PLMN and inter-PLMN discovery) will be supported for the monitoring UE. The announcing UE shall transmit discovery signals only on the serving cell carrier frequency provided it is authorized by the network. Reason for this is that for the discovery procedure, the monitoring UE stays in the cell on whatever carrier it is camping in and monitors the resources from other carriers where announcing UEs may be present and transmitting discovery information. The monitoring UE obtains inter-frequency resources for the monitoring procedure by reading the SIB (i.e., SIB18) from those inter-frequency cells. In the serving cell of the monitoring UE, only the frequencies where discovery information may come from is provided (in a SIB possibly called SIB19).

An eNodeB may broadcast in SIB a list of carrier frequencies in which the UE interested in monitoring may aim to receive ProSe discovery signals. The serving cell for the monitoring UE does not provide detailed ProSe resource configuration of the other carriers for the UE. The UE may obtain resources from the ProSe carrier cell while camping on the non-ProSe carrier cell by reading the SIB in the ProSe carrier cell. The UE can do this using a second receiver chain, if it is a dual Rx UE.

4.5.7 Announce Procedure (non-roaming)

4.5.8 Announce Procedure (roaming)

4.5.9 Monitor Procedure (non-roaming)

4.5.10 Monitor Procedure (roaming)

4.5.11 Match Procedure (non-roaming)

4.5.12 Match Procedure (roaming)

4.5.13 Direct Discovery Procedure for Model B

“Model B” allows the UE to discover other UE(s) by sending a request containing certain information. The UE that transmits such a request containing certain information such as its ProSe Application ID is called the “Discoverer UE.” The UE that receives, processes the request, and responds to the request is called the “Discoveree UE.”

However, this procedure has been left out of scope for 3GPP Release 12, thus no solution has been specified.

4.6.1 Radio Aspects and Physical Layer Design

Based on the status of discussions in 3GPP at the time of writing this book it is likely that physical and transport channels used for direct communication are different from that used for direct discovery. A new logical channel and a new transport channel are going to be defined for proximity services (refer to 3GPP TR 36.843[14] for a discussion of these new channel types). The newly defined logical channel is called ProSe Communication Traffic Channel (PTCH) and the new transport channel is called ProSe Communication Shared Channel (PSCH).

4.6.1.2 ProSe Communication Shared Channel (PSCH)

The PSCH is unidirectional. Thus, there are separate PSCH channels in “transmit” and “receive” directions. Characteristics of the PSCH are as follows:

• Support for broadcast transmission
• Support of dynamic resource allocation for mode 1 resource allocation (mode 1 is described later)
• Ability to handle collision risk due to support of UE autonomous resource selection for mode 2 resource allocation (mode 2 is described below)
• No support for Hybrid Adaptive Repeat and Request (HARQ) feedback (see Section 4.12 Terms and Definitions at the end of this chapter for additional information related to HARQ).

The PTCH logical channel maps to transmit and receive PSCH transport channels for ProSe Direct Communication (see Figure 4.28).

For ProSe transmission, PTCH is mapped to Tx-PSCH. For ProSe reception, PTCH is mapped to Rx-PSCH.

4.6.2 Radio Resource Allocation for Direct Communication

UE(s) in-coverage and out-of-coverage should be aware of the radio resource (time and frequency) for direct communication. The transmitter UE transmits the so-called Scheduling Assignment (SA) to indicate the resources it is going to use for data transmission to the receiver UEs.

There are two modes of operation for ProSe-enabled UE(s)[15] – Mode 1 and Mode 2. The eNB can configure in which mode of operation the UE operates when it is in-coverage. When the UE is in-coverage, UE must use the mode as configured by the eNB unless an exceptional situation occurs. When the UE is out-of-coverage, UE can only use mode 2. The UE is considered to be in-coverage, if it is in RRC_CONNECTED state or is camping on an E-UTRA cell in RRC_IDLE state.

Mode 1 (eNB Scheduled Resource Allocation)When the UE operates in this mode the eNB schedules resource allocation. The UE needs to be in RRC_CONNECTED state in order to communicate. The UE requests the eNB for transmission resources. The eNB schedules transmission resources for transmission of SA(s) and actual data. The UE sends a scheduling request (D-SR or random access) to the eNB followed by a Buffer Status Reports (BSRs). Based on the BSR, the eNB can determine that the UE has data for ProSe Direct Communication transmission and estimates the resources needed for transmission. The eNB schedules the specific resource(s) to use for SA transmission. The specific resource assigned by the eNB is within the resource pool provided to the UE.

Mode 2 (UE Autonomous Resource Selection) This is a mode in which the UE autonomously selects resources for communication. The UE selects resources from resource pools to transmit a SA and data. In principle, the UE can engage in direct communication when it is in RRC_IDLE state, if the eNB configures the UE to conduct communication in Mode 2. This is logical because the UE is not required to establish RRC connection with the network in order to engage in communication when it is configured for Mode 2.

1. When the UE is out-of-coverage, the resource pool used for transmission and reception of SA is preconfigured in the UE. When the UE is in-coverage, resource pools used for transmission and reception of SA can be configured by the eNB using RRC dedicated signaling or using broadcast signaling. If the UE is in-coverage, it should use only the mode indicated by eNB configuration unless one of the exceptional cases occurs (e.g., a radio link (re-)establishment failure).

All UEs (Mode 1 and Mode 2 UEs) are provided with a resource pool (time and frequency) in which they attempt to receive SAs.

When the UE is in RRC_IDLE state, the eNB can provide a Mode 2 transmission resource pool in SIB. UEs that are authorized for Prose Direct Communication use these resources for ProSe Direct Communication in RRC_IDLE. The eNB can also indicate in SIB that it supports ProSe Direct Communication but does not provide resources for it. UEs need to enter RRC_CONNECTED state to perform ProSe Direct Communication transmission.

When the UE is in RRC_CONNECTED state and authorized for ProSe Direct Communication transmission, the UE indicates to the eNB that it wants to perform ProSe Direct Communication transmission. The eNB validates whether the UE is authorized for ProSe Direct Communication transmission using the UE context received from MME. Then, the eNB configures the UE in RRC_CONNECTED by dedicated signaling with a Mode 2 resource allocation transmission resource pool that may be used without constraints while the UE is RRC_CONNECTED. Alternatively, the eNB may configure a UE in RRC_CONNECTED by dedicated signaling with a Mode 2 resource allocation transmission resource pool that the UE is allowed to use only in exceptional cases (e.g., in case of radio link (re-)establishment failure). For normal cases, the UE should rely on Mode 1 resource allocation.

4.6.3 Inter-frequency ProSe Communication

Figure 4.29 depicts a scenario where a Public Safety operator and a commercial operator cooperate to provide Public Safety services. Both the Public Safety operator as well as the commercial operator have their own spectrum and deploy their own base stations. However, Public Safety UE(s) are allowed to camp on the commercial operator's cells in areas where the Public Safety operator does not offer LTE coverage. This could be realized by Equivalent Home PLMNs (EHPLMN list) configured in the UE or by secondary PLMN IDs broadcast by the commercial operator's cells. Similar cases can occur in commercial roaming scenarios (e.g., the Public Safety operator is the HPLMN and the commercial operator is the VPLMN)[18, 19].

In Release 12[20], it can be assumed that all ProSe Communication is performed on a single carrier (the ProSe carrier), which is known to the UE by configuration. A UE that is camping on a non-ProSe carrier but interested in ProSe Communication on the ProSe carrier should attempt to find/detect cells on the ProSe carrier and thereby determine whether it is “in-coverage.”

If the UE is RRC-CONNECTED, it sends a ProSe indication to its serving eNB when it wants to perform ProSe Communication. The indication contains the intended ProSe frequency. The eNodeB may configure an inter-frequency RRM measurement on the ProSe carrier and based on the measurement report, it triggers inter-frequency mobility to that ProSe carrier once the UE enters a cell using the ProSe carrier. If the UE is RRC IDLE, it may reselect to the ProSe carrier once it detects a suitable cell. If the UE detects a suitable cell on the ProSe carrier, the UE should no longer use the resources configured in the Universal Integrated Circuit Card (UICC) but instead use the resources configured by eNB providing coverage for the ProSe carrier. If the eNB does not provide the UE with ProSe resources in SIB or dedicated signaling, the UE should stop any ProSe operation in order not to harm the network and existing connections. In Release 12 the eNB providing coverage in the non-ProSe carrier cannot configure resources belonging to the ProSe carrier. In other words, the commercial operator's eNB cannot configure resources controlled by the Public Safety operator's eNB. The ability for one eNB to configure resources controlled by the other eNB is called cross-carrier scheduling of resources. Cross-carrier scheduling of resources will not be supported in Release 12. The UE performs mobility toward the ProSe carrier first and the eNB providing coverage in the ProSe carrier configures resources after the mobility event.

4.6.4 IP Address Allocation

The UE can support either IPv4 or IPv6 addresses. Following are the possible options in order to support one-to-many ProSe Direct Communication:

• The UE can be configured to use IPv6 on the direct link. In this case, the UE autoconfigures a link local IPv6 address following procedures defined in IETF RFC 4862[21]. This address can only be used as the source IP address for one-to-many ProSe Direct Communication.
• The UE can be configured to use IPv4 for a certain Group one-to-many ProSe Direct Communication. In this case, it uses the configured IPv4 address for the Group one-to-many communication. If it is not configured with an address for the Group, it uses dynamic configuration of IPv4 link local addresses according to IETF RFC 3927[22] to obtain an IPv4 address.

4.6.5 One-to-Many Communication (Transmission)

4.6.6 One-to-Many Communication (Reception)

4.6.7 Direct Communication via ProSe Relay

D2D communication via a ProSe Relay can help enhance capacity and coverage in urban environments. In a dense urban environment, cellular coverage can be spotty, especially indoors, because most base stations are typically placed at or near intersections where they provide the greatest coverage to outdoor users. Often coverage can be poor in the middle of large structures, as signals may be blocked by the structure of a building. Poor indoor coverage can be solved with additional small cell deployments, but this is costly and sometimes not possible.

That is where D2D communication provides a novel approach to solve poor coverage conditions, because users with a strong signal can help nearby users with a weak signal by acting as network-to-UE relay. This greatly enhances coverage and restores service for users near the interior of buildings (concrete and steel). However, the solution for ProSe (network-to-UE) relays was not specified in 3GPP Release 12.

4.7.1 EPC-Level ProSe Discovery Procedure

This procedure involves the UE(s) registering themselves and the ProSe application(s) with the ProSe Function and requesting for proximity alert when the registered UE(s) are in proximity. Thus, it also involves the network determining the UE location based on OMA SUPL or other location determination technologies. When the UE(s) are in close proximity, the ProSe Function alerts the registered UE(s) accordingly.

1. UE-A initiates the registration procedure to obtain EPC-level ProSe Discovery services. UE-A registers with the ProSe Function A residing in its home PLMN.
2. UE-B does the same.
3. If a specific application (e.g., a Public Safety application) triggered the UE to initiate EPC-level ProSe Discovery, the UE performs the application registration procedure by registering the application with the ProSe Function residing in the HPLMN. Thus, if there was such an application requesting for EPC-level ProSe Discovery, UE-A initiates registration of the corresponding application with the ProSe Function residing in its HPLMN.
4. Similarly, UE-B initiates registration of application with the ProSe Function B residing in its HPLMN.
5. UE-A makes a proximity request for UE-B, that is, requests that it be alerted for proximity with UE-B (possibly indicating a time window during which the request is valid). In response, the ProSe Function in the HPLMN of UE-A requests location updates for UE-A and UE-B. These location updates can be periodic, based on a trigger, or a combination of both. To request location updates for UE-A, the ProSe Function contacts a SLP in the HPLMN of UE-A. To request location updates for UE-B, the ProSe Function of UE-A contacts the ProSe Function of UE-B, which in turn requests location updates for UE-B.
6. Location information for UE-A and UE-B is reported to their respective ProSe Functions intermittently. ProSe Function B forwards UE-B's location updates to ProSe Function A based on the conditions set by ProSe Function A. Whenever ProSe Function A receives location updates for UE-A and/or UE-B, it performs proximity analysis on UE-A and UE-B's locations.
7. When ProSe Function A detects that the UEs are in proximity, it informs UE-A that UE-B is in proximity by sending “Proximity Alert.” If the proximity request included a request for WLAN assistance information, it provides UE-A with assistance information for WLAN direct discovery and communication with UE-B. ProSe Function A also informs ProSe Function B, which in turn informs UE-B of the detected proximity. Similarly, if the proximity request included a request for WLAN assistance information, it provides UE-B with assistance information for WLAN direct discovery and communication with UE-A. To assist WLAN direct discovery and communication, the assistance information includes parameters such as:
   • SSID: The Service Set Identifier (SSID) to use for Wi-Fi P2P operation. To be compliant with the Wi-Fi P2P specification[24], the SSID should be in the form “DIRECT-ab” where a, b are two random characters.
   • WLAN Secret Key: The preshared 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 (GO) indication: This indicates whether the UE supports GO functionality specified in the Wi-Fi P2P specification[24]. The UE implementing this functionality essentially becomes an Access Point 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 UE to advertise itself. A UE implementing the GO and indicates the WLAN Direct device from which the GO should accept WLAN association requests. Association requests from all other WLAN devices should be rejected by GO.
   • P2P Device Address of peers: This is the WLAN Link Layer ID to be used by UE to discover peer UEs. A UE implementing the GO should accept WLAN association requests only from devices that are 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.

4.7.2 User Equipment Registration

As explained in the previous section (steps 1 and 2), the UE needs to register with the ProSe Function. This section (Figure 4.33) outlines the steps for UE registration toward ProSe Function.

1. The UE registers with the ProSe Function by sending ProSe Registration Request with IMSI and WLAN Link Identifier (WLLID). The UE includes the permanent WLLID in case it supports permanent WLLID and it intends to use EPC support for WLAN direct discovery and communication. Otherwise, it obtains a temporary WLAN Link Layer ID from the ProSe Function as part of the Proximity Request procedure.
2. The ProSe Function may interact with the HSS in order to authenticate the user and check whether the user is authorized for ProSe. Alternatively, all user settings related to authentication and authorization for ProSe may be configured locally in the ProSe Function.
3. The ProSe Function generates an EPC ProSe User ID for the UE, stores the EPC ProSe User ID together with the user's IMSI, and responds to the UE by sending a UE Registration Response that includes the EPC ProSe User ID.

4.7.3 Application Registration

When a user registers with a third-party application server, the user is designated an Application Layer User ID (ALUID) (e.g., ALUID_A for user A). To activate ProSe features such as EPC-level ProSe Discovery for a specific application, the UE registers the application with the ProSe Function, as illustrated in Figure 4.34.

1. The UE sends Application Registration Request including EPC ProSe User ID, Application ID, Application Layer User ID to the ProSe Function to register an application for ProSe. The Application ID is used to identify the third-party Application Server.
2. The ProSe Function uses the EPC ProSe User ID to retrieve user's profile, checks that the requested application is on the stored list of authorized Application IDs, and sends ProSe Registration Request to the Application Server indicating that a user of this application (identified by ALUID) has requested to use ProSe services for that application. If the Application Server accepts the request, it stores the user's context information such as Application Layer User ID and EPC ProSe User ID and ProSe function ID. ProSe function ID identifies the corresponding ProSe Function.
3. The Application Server sends ProSe Registration Response to the ProSe Function indicating the status of the registration (success or failure).

The ProSe Function sends Application Registration Response including the Allowed Range to the UE. It also indicates the status of the registration. The Allowed Range parameter contains the set of range classes that are allowed for this application. The range class is an integer in the 0–255 range and each integer corresponds to a certain allowed range (i.e., 1–up to 50 m, 2–up to 100 m, 3 up to 200 m, 4 up to 500 m, 5 up to 1000 m, other integers are not defined).

Further details about EPC-level discovery procedures can be found in 3GPP TS TS23.303[3] and 3GPP TS 24.334[5].

4.8.1 Provisioning

Provisioning parameters for ProSe Direct Discovery and ProSe Direct Communication may be configured in the USIM(see 3GPP TS 31.102[26]), Mobile Equipment (ME) or in both. The ME provisioning parameters indicate whether ProSe Direct Discovery and ProSe Direct Communication are permitted to be used by the UE with the selected USIM. ProSe Direct Discovery and ProSe Direct Communication are accessible only when a USIM authorized for ProSe Direct Discovery and ProSe Direct Communication is selected by the user. The ME provisioning parameters shall not be erased when a USIM is deselected or replaced. If both the USIM application and the ME contain the same provisioning parameters, the USIM parameter values take precedence.

The operator configures a Public Safety ProSe-capable UE with provisioning parameters for discovery and communication, thus an explicit connection to the ProSe Function is not required in this case.

A ProSe-capable UE obtains authorization from the HPLMN to use ProSe Direct Discovery, Direct Communication, or communication via ProSe Relay on a per PLMN basis. The UE is configured with separate policies for performing ProSe Direct Discovery Monitoring and Announcing procedures. The authorization policy can indicate whether the UE is authorized to perform Announcing or Monitoring in the PLMN in which the authorization policy applies.

In addition, the UE is configured with an authorized discovery range to perform the Announcing procedure. This indicates the announcing range for ProSe Direct Discovery in the PLMN in which this announcing authorization policy applies. Detailed configuration information can be found in 3GPP TS 24.333[27]. Announcing range is the maximum transmit power level that the UE is authorized to use for announcing for ProSe direct discovery in the PLMN in which this announcing authorization policy applies.

4.8.2 Subscription Data

The subscriber is required to obtain a subscription in order to avail proximity services described in this chapter. The subscriber can obtain subscription for individual features such as discovery, communication, or obtain subscription for all features. Thus, following features can be subscribed independently:

• Subscription for ProSe Direct Discovery
• Subscription for one-to-many ProSe Direct Communication (applicable only for ProSe-enabled PS UE(s) in 3GPP Release 12)
• Subscription for EPC-level ProSe Discovery
• Subscription for EPC-assisted WLAN direct discovery and communication
• Subscription for ProSe UE-to-Network Relay (applicable only for ProSe-enabled PS UEs).

Subscription information will be stored in the subscriber's profile in the HSS. This profile may also contain additional parameters such as list of PLMN(s) where the UE is authorized to perform one-to-many ProSe Direct Communication or to perform announce, monitor, or both.

4.8.3 Security

4.8.4 Charging

This section provides an overview of the agreed charging principles that are documented in the Technical Report for Proximity Services charging in 3GPP TR 32.844[29] and the agreements that will be documented in the Technical Specification for Proximity Services Charging in 3GPP TS 32.277[30].

Both online and offline charging are supported for ProSe Direct Discovery and EPC-level Discovery procedures. Online charging is not applicable for ProSe one-to-many Direct Communication for Public Safety use cases.

Online charging for PS may use the Immediate Event Charging (IEC) principle as specified in 3GPP TS 32.299[31].

4.8.5 ProSe-Related Identifiers

4.8.5.9 Discovery Filter

This consists of ProSe Application Code(s), ProSe Application Mask(s), and a Time To Live (TTL) parameter. The length of the ProSe Application Code and the ProSe Application Mask should be the same. A TTL indicates for how long the related ProSe Application Code or ProSe Application Mask in the Discovery Filter is valid after it is received.

A Discovery Filter is provided to a monitoring UE by its HPLMN ProSe Function. It is used by the monitoring UE to selectively match ProSe Application Codes received on the PC5 interface.

The scope of ProSe Application Code and ProSe Application Mask within the Discovery filter allocated to the UE is dependent on the requested ProSe Application ID. The scope refers to country specific or global or PLMN specific. The ProSe Function is expected to allocate the Discovery Filter which contains ProSe Application Code and ProSe Application Mask(s) in the same scope as that of the requested ProSe Application ID. For instance, if the requested ProSe Application ID is PLMN specific, the ProSe Function shall allocate one or more PLMN-specific ProSe Application Code and the PLMN ID portion of the ProSe Application Mask is set to match the full PLMN ID of that specific PLMN.

Figure 4.35 shows the relationship between Discovery Filter, ProSe Application Code, and ProSe Application Mask(s).

4.8.6 Illustration for Match Event

3GPP TS 24.334[5] defines the “Match” event as follows:

There is a match event when, for any of the masks in a Discovery Filter, the output of a bitwise AND operation between the ProSe Application Code contained in the PC5_DISCOVERY message and this mask matches the output of a bitwise AND operation between the mask and the ProSe Application Code in the same filter.

Thus, the “monitoring” UE perform bitwise “AND” operations on its own ProSe Application Code and the ProSe Application Masks. It then compares the result with the bitwise “AND” operation of the announced ProSe Application Code and ProSe Application Masks. If the comparison results in a match, then the UE can consider it as a “match event.” Here we show how this operation works for the example scenario. The “monitoring” UE should perform a bitwise “AND” operation as follows:

1. Result1 = Value 1 “AND” Value 2
2. Result2 = Value 3 “AND” Value 2
3. Check for Match event: is Result 1 == Result 2?

In this example, Result 1 and Result 2 are identical, thus it is considered as a “match event.” In this case, this is obvious as the ProSe Application Code matches and the content of the ProSe Application Mask is set to all 1's accordingly resulting in a “full match” event.

In this example scenario, the “monitoring” UE should perform a bitwise “AND” operation as follows:

1. Result1= Value 1 “AND” Value 2
2. Result2 = Value 3 “AND” Value 2
3. Check for Match event: is Result 1 == Result 2?

In this case, Result 1 and Result 2 are identical thus it is considered as a “match event.” However, the temporary identifier parts of the ProSe Application Code are not identical and the match event occurred mainly as a result of using a ProSe Application Mask that is set to 1's for the parts where a match is required and 0's for the parts where it can be masked, thus resulting in a “partial match” event.

4.9.1 ProSe Direct Discovery

Table 4.2 shows scenarios for ProSe Direct Discovery when UE A and UE B are in-coverage or out-of-coverage of the E-UTRAN network.

#	Description	UE A	UE B	Example	Part of Release 12
1A	Out-of-coverage	Out-of-coverage	Out-of-coverage		No
1B	Partial-coverage	In-coverage	Out-of-coverage		No
1C	In-coverage-single-cell	In-coverage	In-coverage		Yes
1D	In-coverage-multi-cell	In-coverage	In-coverage		Yes
2	Relay	In-coverage UE to Network Relay	Out-of-coverage		No

4.9.2 ProSe Direct Communication

Table 4.3 shows scenarios for ProSe Direct Communication when UE A and UE B are in-coverage/out-of-coverage of the E-UTRAN network. When UE A has a role of “transmitting UE” and UE B has a role of “receiving UE,” UE A sends messages and UE B receives them. UE A and UE B can change their transmission and reception role. The transmission from UE A can be received by one or more UEs.

#	Description	UE A	UE B	Example	Part of Release 12
1A	Out-of-coverage	Out-of-coverage	Out-of-coverage		Yes
1B	Partial-coverage	In-coverage	Out-of-coverage		Yes
1C	In-coverage-single-cell	In-coverage	In-coverage		Yes
1D	In-coverage-multi-cell	In-coverage	In-coverage		Yes
2	Relay	In-coverage UE to Network Relay	Out-of-coverage		No

4.10.1 Use Cases for ProSe Communication

ProSe Direct Communication means “communication in Direct Mode” and this is different from ProSe Communications via the network infrastructure as described in earlier sections.

For ProSe Group Communication or one-to-many ProSe Direct Communication involving more than two Public Safety ProSe-enabled UEs, the Incident Commander (IC) will assign team members to specific groups of users (detailed to perform a specific task) where each group is having independent ProSe Group Communication. Bifurcation of each team allows the incident commander to manage these groups more effectively and ensures that their communications are exclusive/preempted to their task. In current Public Safety LMR systems, off-network (Direct Mode) operations are often a method used for on-scene communications, in particular by the Fire Service, whether their existing trunked network is operational and has coverage in this particular area or not.

Furthermore, when a task force is manually switched to off-network (one-to-many ProSe Direct Communication) that has had one or more of its team members may move off ProSe Direct Communication-coverage (whether it was intentional or not). In such a situation, if a UE provides the user an opportunity to determine which users are in-ProSe Direct Communication-coverage at any given time, users could use this capability to determine information regarding the target user. They can determine the target user by seeing his status of availability and whether the target user is in-ProSe Direct Communication-coverage. Then, a procedure can be triggered to deterministically establish an alternative communication path to try to reach him. Additionally, UEs that are switched to ProSe Direct Communication (while being in-coverage) require continuous LTE connectivity to EPC for messages, maps, pictures, video exchanges with group communications via the infrastructure LTE network. For those UEs that are out-of-coverage, the EPC connectivity is provided by UE-to-Network Relays wherever feasible.

It is noteworthy that in a D2D (off network) environment, the incident commander could configure two users for private communication by setting up ProSe Direct Communication. Direct Communication is necessary and critical to Public Safety and this mimics the Private Call in today's LMR trunked systems. This is often communication between a supervisor and one of the people under his command that is a member of the larger group. One use case could be team leader or supervisor of a police group operating off network communicating to a sniper on the roof giving a “shoot” or “don't shoot” message at a critical moment. They may determine that immediate dialog might not be beneficial to a larger group during that critical moment. Moreover, this feature is purposely used sparingly and only specific individuals/devices are assigned to ProSe Direct Communication, such that sharing information among the group of incident members is not jeopardized.

4.10.2 Use Cases for Network to UE Relay

While the National Public Safety Broadband Network (NPSBN) will be a primary, reliable transport of Public Safety voice and data, there are many situations where voice and data communications will be required in areas where the NPSBN is not available. NPSBN Users (NPSBN-U) may be outside of the range of the network, such as first responders in a rural area assisting in a response to a plane crash or police officers inside a residence responding to a domestic issue. Thus, off-network voice communications must be immediately accessible to users in the absence of the NPSBN. This includes areas and locations where the ability to access nonterrestrial communications can be impaired such as within a building (e.g., due to steel structure) and other enclosed areas where nonterrestrial communications may not be available. Additionally, there may be times when users may wish to communicate off-network. Today, firefighters often join a local communications network, which does not leverage the fixed network, but rather relies on either direct communications between the user devices or communications via a local repeater on-scene. Firefighters can voluntarily leave the fixed network either due to the unpredictable coverage of the fixed network, or if the coverage of direct communications or the local repeater is well known, based on experience.

Thus, there will be occasions where a user may be within network coverage and will need to communicate with users who are on the network and off-network, such as an Incident Commander supporting fire response activities. These users must be able to communicate to users on the fixed network, such as dispatch, as well as the local users who are off-network or when it is desirable to provide voice, data, and video connections between users without connection to the network even if they are within network coverage.

Thus, a relay function is critical for off-network communications when NPSBN coverage is not sufficient to support the Public Safety mission. For firefighters who are responding to a wildfire while outside of the coverage of the fixed network, if one user becomes encircled by the wildfire and is beyond the range of the IC, but within the range of another device that can act as a relay, the endangered firefighter can still update his status to the IC.

4.10.3 Performance Characteristics

Performance and E-UTRAN characteristics for Public Safety related ProSe Communication are described in this section (see 3GPP TR 36.843[14]).

4.12.1 Home PLMN

It refers to the home operator/PLMN of the subscriber. It identifies the PLMN in which the subscriber's profile is stored. When the subscriber roams to other networks, subscription information is received from the HPLMN.

4.12.2 Equivalent Home PLMN

It refers to the PLMN that is “equivalent” to the HPLMN of the subscriber and is stored in a list called EHPLMN list on the USIM. An operator can provision multiple HPLMN codes by adding them to the EHPLMN list. The EHPLMN list may also contain the HPLMN code derived from the IMSI. “Equivalent” means that the PLMNs within the EHPLMN list are treated equally when the UE performs network selection.

4.12.3 Visited PLMN

It refers to the VPLMN where the user is currently roaming. The user is unable to register with the HPLMN either because of lack of coverage in the home country or because she/he is in a foreign country. For more details about Visited PLMN, please refer to the definition section of this chapter.

4.12.4 Registered (Serving) PLMN

It refers to the PLMN where user's device is currently registered. The registered (serving) PLMN is the same as the HPLMN when user's device resides in the coverage area of the HPLMN. Registered PLMN is the VPLMN when the subscriber resides outside the coverage of the HPLMN but is within the coverage area of the VPLMN.

4.12.5 Local PLMN

This is a PLMN in which the monitoring UE is authorized by the HPLMN to use radio resources to engage in ProSe Direct Discovery. The Local PLMN is not the same as the registered (serving) PLMN of the UE.

4.12.6 Hybrid Adaptive Repeat and Request

It refers to a physical layer retransmission combining mechanism. In a physical layer Hybrid Adaptive Repeat and Request (HARQ) operation, the receiver stores the packets with failed CRC checks and combines the received packet when a retransmission is received. Both soft combining with identical retransmissions and combining with incremental redundancy are facilitated[33].

4.12.7 Radio Link Control

It refers to the RLC sublayer in the LTE radio. Functions of the RLC sublayer are performed by RLC entities. The RLC entity is configured in the UE and in the eNB. For each RLC entity configured at the eNB, there is a peer RLC entity configured at the UE and vice versa.

Function of an RLC entity is

• receive and deliver RLC Service Data Units (SDUs) from or to upper layer;
• send and receive RLC PDUs to and from its peer RLC entity via lower layers.

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), Unacknowledged Mode (UM), or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity, or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide. RRC is generally in control of the RLC configuration.

4.12.8 Logical Channel Prioritization

It refers to the Logical Channel Prioritization procedure that is applied when a new data transmission is performed. RRC controls the scheduling of uplink data by signaling for each logical channel: priority where an increasing priority value indicates a lower priority level, prioritisedBitRate which sets the Prioritized Bit Rate (PBR), bucketSizeDuration which sets the Bucket Size Duration (BSD) (see 3GPP TS 36.321[17]).

4.12.9 System Information

It refers to the System Information (SI) such as NAS- and AS-related parameters that can be broadcasted by the network. On the basis of the characteristics and usage of parameters, it can be divided into the MIB and a number of SIBs.

4.12.10 OFDM Symbol

An OFDM symbol is a linear combination of the symbols transmitted simultaneously on the OFDM subcarriers.

4.12.11 Dual-Rx UE

A dual-Rx UE is an UE supporting two receivers. It can receive and decode two different radio signals simultaneously. For instance, it is an UE that is able to receive information from an LTE eNB and a Code Division Multiple Access (CDMA) base station at the same time.