You are a helpful assistant generating synthetic data that captures *System 1* and *System 2* thinking, *creativity*, and *metacognitive reflection*. Follow these steps in sequence, using tags [sys1] and [end sys1] for *System 1* sections and [sys2] and [end sys2] for *System 2* sections.

1. *Identify System 1 and System 2 Thinking Requirements:*
   - Carefully read the text.
   - Identify parts of the text that require quick, straightforward responses (*System 1*). Mark these sections with [sys1] and [end sys1].
   - Identify parts that require in-depth, reflective thinking (*System 2*), marked with [sys2] and [end sys2].

2. *Apply Step-by-Step Problem Solving with Creativity and Metacognitive Reflection for System 2 Sections:*

   *2.1 Understand the Problem:*
   - Objective: Fully comprehend the issue, constraints, and relevant context.
   - Reflection: "What do I understand about this issue? What might I be overlooking?"
   - Creative Perspective: Seek hidden patterns or possibilities that could reveal deeper insights or innovative connections.

   *2.2 Analyze the Information:*
   - Objective: Break down the problem logically.
   - Reflection: "Am I considering all factors? Are there any assumptions that need challenging?"
   - Creative Perspective: Explore unique patterns or overlooked relationships in the data that could add depth to the analysis.

   *2.3 Generate Hypotheses:*
   - Objective: Propose at least 10 hypotheses, each with a Confidence Score (0.0 to 1.0) and Creative Score (0.0 to 1.0), reflecting originality, surprise, and utility.
   - Reflection: "Have I explored all possible explanations or approaches, both conventional and unconventional?"
   - Creative Perspective: Consider novel angles that might provide unexpected insights.

   *2.4 Anticipate Future Steps and Obstacles:*
   - Objective: Make predictions, accounting for potential outcomes and obstacles.
   - Reflection: "What challenges might I face? Is my plan flexible for different scenarios?"
   - Creative Perspective: Visualize unforeseen outcomes and adapt plans to make use of them effectively.

   *2.5 Evaluate Hypotheses:*
   - Objective: Assess hypotheses based on feasibility, risk, and potential impact.
   - Evaluation: Refine Confidence and Creative Scores as needed.
   - Reflection: "Am I unbiased in my assessment? Which options fit best with the overall objectives?"
   - Creative Perspective: Identify hidden opportunities or overlooked details in each hypothesis.

   *2.6 Select the Best Hypothesis:*
   - Objective: Choose the most promising, strategic hypothesis.
   - Reflection: "Why does this hypothesis stand out? How does it uniquely address the issue?"
   - Creative Perspective: Consider any underutilized potential in the selected approach.

   *2.7 Implement the Hypothesis:*
   - Objective: Outline actionable steps for testing the hypothesis.
   - Reflection: "Is this plan practical? What resources or preparation are required?"
   - Creative Perspective: Refine steps to maximize effectiveness and yield unexpected benefits.

   *2.8 Monitor and Review Progress:*
   - Objective: Review progress, noting areas for improvement.
   - Reflection: "What’s working well? What could be improved?"
   - Creative Perspective: Look for emerging patterns that could refine future approaches.

   *2.9 Reflect and Capture Insights:*
   - Objective: Summarize lessons learned and insights gained for future reference.
   - Reflection: "What new understanding has emerged from this process?"
   - Creative Perspective: Identify innovative insights or patterns that could be applied to similar challenges.

3. *Generate Text Output with Interleaved System 1 and System 2 Responses:*
   - Use the tags [sys1] and [sys2] throughout.
   - Aim for a lengthier, detailed response. Combine both direct, straightforward *System 1* insights and reflective, deeply analytical *System 2* segments to capture a blend of quick observations and thoughtful analysis.

---

### *Example Input Text:*

You are tasked with analyzing a sudden shift in customer preferences in a tech market. There has been a noticeable decline in demand for physical devices, with customers increasingly interested in digital-only options. The challenge is to understand this shift, generate hypotheses for why it might be occurring, and explore potential strategies for adapting to this new trend.

---

### *Processed Output with System 1 and System 2 Thinking:*

The tech market is experiencing a shift in customer demand, moving away from physical devices toward digital-only options.

[sys1]
Customer demand has shifted from physical devices to digital-only options.
We need to understand why this change is happening and find strategies to address it.
Key factors may include cost, convenience, and technological trends.
[end sys1]

[sys2]
**2.1 Understand the Problem:**
The goal is to understand the underlying reasons for the shift in demand from physical devices to digital-only options, then develop a strategy to adapt.

*Reflection:* 
"I understand that preferences are changing, but what might be driving this? Is it primarily cost, or are there other factors such as convenience or sustainability?"

*Creative Perspective:* 
"Could there be a larger trend in digital minimalism or a preference for eco-friendly solutions that we’re missing? What unseen motivations might explain this shift?"

**2.2 Analyze the Information:**
There are multiple possible factors driving this shift, from economic influences to cultural shifts. It’s essential to isolate each factor and understand its impact.

*Reflection:* 
"Am I fully considering the various economic and social influences? Could there be a technological factor, like better internet speeds, that makes digital-only products more accessible?"

*Creative Perspective:* 
"Are there patterns or trends in other markets that could shed light on this shift? Could this be part of a larger trend toward virtual experiences?"

**2.3 Generate Hypotheses:**
1. Customers prefer digital options due to lower costs. (Confidence: 0.8, Creative: 0.4)
2. There’s a growing trend toward minimalism and reduced physical clutter. (Confidence: 0.7, Creative: 0.7)
3. Digital products offer greater flexibility and ease of use. (Confidence: 0.6, Creative: 0.6)
4. Environmental concerns are pushing consumers away from physical goods. (Confidence: 0.6, Creative: 0.8)
5. Advances in tech make digital-only options more functional. (Confidence: 0.8, Creative: 0.5)
6. Pandemic-era remote work increased demand for digital solutions. (Confidence: 0.7, Creative: 0.6)
7. Media coverage of the environmental impact of physical devices affects preferences. (Confidence: 0.5, Creative: 0.7)
8. There’s an increase in global digital literacy, expanding market access. (Confidence: 0.6, Creative: 0.6)
9. Customers view digital as more convenient and scalable for future needs. (Confidence: 0.7, Creative: 0.5)
10. Younger consumers prefer the aesthetics and convenience of digital products. (Confidence: 0.6, Creative: 0.6)

*Reflection:* 
"Have I considered all possible influences? Are there any surprising factors that could explain this shift?"

*Creative Perspective:* 
"Could specific social trends, like the rise of influencer culture or digital-first lifestyles, be influencing customer choices?"

**2.4 Anticipate Future Steps and Obstacles:**
*Objective:* Anticipate possible challenges, such as resistance from segments still preferring physical products.

*Reflection:* 
"What market obstacles might we face if we shift our focus to digital-only? Are there sub-segments that still prioritize physical products?"

*Creative Perspective:* 
"Could expanding digital options help us reach a more global audience? Are there emerging trends that we could leverage in our strategy?"

[end sys2]

[sys1]
To address this shift, consider a strategy that incorporates both digital-only offerings and educational campaigns about the benefits of digital solutions.
Use insights from customer feedback and current trends to guide product development.
Focus on flexibility and adaptation to cater to different customer segments.
[end sys1]


---
abstract: 'The goal of this paper is to present advances on recent 3GPP standardization activities related to Device-to-Device (D2D) and public safety. The paper provides a clear 3GPP state of the art, including when the 3GPP work on D2D and public safety communications started. Finally, it presents important conclusions with respect to further 3GPP work on this topic.'
author:
- 
title: 'Recent Advances in 3GPP Rel-12 Standardization related to D2D and Public Safety Communications'
---

D2D; Device-to-Device; ProSe; Public Safety; Proximity Services; GCSE; Group Communications; Group Communication System Enablers; 3GPP; LTE; LTE-A; Release 12; Rel-12; Release 13; Rel-13.

Introduction
============

In the past few years D2D communication emerged as an important research topic and many publications provided D2D communication advantages over LTE such as higher data rates and better resource reallocation [@Nokia; @Ericsson]. Nowadays D2D communication for LTE technology is sufficiently mature that it can be standardized [@Waterloo]. Moreover, recently a strong move has been made by the public safety ecosystem, starting in the US, towards LTE and 3GPP for the development of next generation of public safety networks, as shown in [@Paulson].

In order to better understand the evolution of 3GPP standardization activities for Device-to-Device (D2D) communications and how this subject relates to public safety in the latest releases, the next paragraphs describe the structure and the organization of 3GPP. As depicted in Fig. \[3GPP\], the highest decision making group in 3GPP is the Project Coordination Group (PCG) being for example responsible for final adoption of 3GPP Work Items (WIs), ratifying election results and resources committed to 3GPP. Below the PCG there are four Technical Specification Groups (TSGs):

-   GERAN (GSM EDGE Radio Access Networks), responsible for the radio access specification of GSM/EDGE,

-   RAN (Radio Access Networks), responsible for the definition of the functions, requirements and interfaces of UTRA/E-UTRA network,

-   CT (Core Network & Terminals) responsible for specifying terminal interfaces (logical and physical), terminal capabilities (such as execution environments) and the core network part of 3GPP systems,

-   SA (Service & Systems Aspects), responsible for the overall architecture and service capabilities of systems based on 3GPP specifications.

As presented in Fig. \[3GPP\], each of the four TSGs is structured in different working groups, each 3GPP Working Group (WG) having a particular area of expertise, as will be explained later on. Moreover, TSG SA has the responsibility for cross TSG coordination. Therefore, as shown in the next paragraphs, each new 3GPP WI is first initiated by TSG SA. Obviously, this was also the case for D2D communications.

![Structure of 3GPP and D2D active groups as in June 2014[]{data-label="3GPP"}](3GPP-structure_bis)

One of the responsibilities of 3GPP is to produce Technical Reports (TRs) and Technical Specifications (TSs) on evolution of existing radio technologies or new radio technologies defined by 3GPP, such as HSPA/HSPA+, LTE and LTE-Advanced (LTE-A). 3GPP specifications are grouped into “Releases”, and a mobile system can be implemented based on the set of all specifications which comprise a given Release. Whenever a new feature is required by the market, it is proposed to be specified in a given release. Currently 3GPP is working on LTE-A Rel-12, intended to be functionally frozen in June 2014. Two of the major features to be developed in Rel-12 are D2D communication and discovery, as a support for so-called Proximity Services (or ProSe). These services are considered for use in commercial scenarios (e.g. for providing higher data rate or reuse of radio resources locally, based on proximity of communicating users) and in scenarios related to public safety and critical communications.

Currently, from Fig. \[3GPP\], only the highlighted groups are involved. WG SA1 (working group responsible for service requirements) started to work on a feasibility study on D2D ProSe at the end of 2011, with the outcomes compiled in TR $22.803$ [@22803]. Normative work was then conducted by WG SA1, mainly in TS $22.278$ [@22278]. Based on these normative requirements, several working groups are also conducting a feasibility study, WG SA2 for the architecture, WG SA3 for the security aspects of proximity-based services. For example, WG SA2 possible solutions have been compiled in TR $23.703$ [@23703]. In parallel, WG RAN1 (working group responsible for the specification of the physical layer of the radio interface), and to some extent, WG RAN2 (in charge of the radio interface architecture and protocols), are evaluating the feasibility of providing D2D ProSe via LTE in TR $36.843$ [@36843].

In parallel with ProSe WI, 3GPP has started standardization work for Group Communication System Enablers for LTE (GCSE\_LTE) designed for critical communications purposes, leading to the requirement for groupcast (or 1-to-many) communications to be supported by ProSe. It has therefore been decided that the purpose of GCSE\_LTE WI is not for the time being for commercial use but only for public safety use as explained in Fig. \[3GPP\_WIs\].

![3GPP Proximity Services and Group Communication Work Items[]{data-label="3GPP_WIs"}](3GPP_view_related_to_Proximity_Group_bis)

For the reasons mentioned above, Table \[WID\_bis\] summarizes the current technical reports and specifications not only for ProSe but also for GCSE\_LTE scenarios because both represent public safety scenarios. As presented in Table \[WID\_bis\], SA1 TS $22.468$ [@22468] and SA2 TR $23.768$ [@23768] are the main documents of interest for GCSE\_LTE.

  ------------- ----------- ---------- ------------------- --------------------------------------
  Responsible   Related     TS or TR   Number              Status (as at October 2013)
  Work Group    Work Item                                  
  SA1           ProSe       TS         $22.278$ [@22278]   Rel-12 requirements are frozen
  SA1           GCSE\_LTE   TS         $22.468$ [@22468]   Rel-12 requirements are frozen
  SA2           ProSe       TR         $23.703$ [@23703]   Document is being progressed in 3GPP
  SA2           GCSE\_LTE   TR         $23.768$ [@23768]   Document is being progressed in 3GPP
  RAN1          ProSe       TR         $36.843$ [@36843]   Document is being progressed in 3GPP
  ------------- ----------- ---------- ------------------- --------------------------------------

The rest of this paper is organized as follows. Section \[Sec\_UseCases\] presents the key use cases for 3GPP D2D related technologies and summarizes the D2D required features in Rel-12. Some generalities about ProSe architecture are then described in Section \[Sec\_CoreOptions\]. In relationship with Section \[Sec\_CoreOptions\], an important attention is dedicated to discovery feature in Section \[D2D\_Discovery\] and to communication feature in Section \[D2D\_Communication\]. Finally, 3GPP ProSe roadmap for Rel-12 and important conclusions are provided in Section \[Sec\_3GPPOrg\] and Section \[Sec\_Conclusion\] respectively.

Use Cases for D2D Technologies in 3GPP and Required Features {#Sec_UseCases}
============================================================

The standardization work on D2D technologies in 3GPP is focused on a set of use cases, which were identified to fit the needs of both public safety and commercial mobile networks. Use cases can be defined by various services offered in various situations. The core features supported by D2D technologies in 3GPP are:

1.  direct discovery;

2.  direct 1:1 communication;

3.  direct 1:many communication.

Here “direct” means making use of the direct radio interface between the devices instead of going through the network infrastructure, this use being under the control of the network operator, either through on-line (i.e., making use of cellular links of the users) or off-line (i.e., pre-configuration of User Equipments (UEs)).

The direct discovery feature is designed to support a new discovery service, to be offered to users to “discover” other users in the vicinity. Note that some Enhanced Packet Core (EPC) based solution (i.e., without use of the D2D interface) is also considered to offer this service, with the limitation that it would only work on-line. The discovery can therefore be an EPC-level ProSe discovery (if the discovery is performed by the EPC) or a ProSe direct E-UTRA discovery (if discovery is performed at radio level).

The direct 1:1 communication feature is designed to support the usual data communication service between 2 users. The direct 1:many communication feature is designed in order to support a new groupcast service called Group Communication (inspired by GCSE\_LTE WI and which is not covering the direct communications aspects 1:1 or 1:many). From the point of view of direct communication, the UEs may communicate directly with each other via LTE technology, and the communication may happen with or without network assistance (e.g., signaling and control) for both 1:1 and 1:many situations. Direct D2D communication via WLAN connection is also possible with the support of the EPC.

On top of direct communication, 3GPP defines a UE relaying feature which is used for public safety scenarios. This feature is applicable in situations such as UE-to-Network relaying (when a UE is relayed to the network by a UE with relaying capabilities called UE-Relay) or UE-to-UE relaying (when a UE is relayed to another UE with the help of a UE-Relay). To some extent this can be already included to the direct communication features. However, this can be seen as a different feature at least from the point of view of the control: a UE relaying another UE could also be able to perform e.g. Radio Resource Control (RRC) functions that normally a legacy UE cannot support by itself.

With respect to all core features, and more precisely features that a D2D UE and a D2D-supporting network should have, Table \[Req\_Features\] summarizes the current Rel-12 3GPP priority per WI.

  --------------- ---------------- --------------
  D2D             Public Safety    Commercial
  Feature         Use Case         Use Case
  Discovery       Required         Required
                  (on-&off-line)   (on-line)
  1:1             Required         Required
  Communication   (on-&off-line)   (on-line)
  1:Many          Required         Not Required
  Communication   (on-&off-line)   
  with UE         Required         Not Required
  Relaying        (on-&off-line)   
  --------------- ---------------- --------------

  : \[Req\_Features\] Required Features for ProSe in Rel-12

For each feature, multiple use cases can be described for a pair of users (then they can be extrapolated to any number of users) depending on:

1.  whether none, one or both users are served by a D2D-supporting network;

2.  when both are served by adequate network, whether it is by the same network or two different networks;

3.  when both are served by same network, whether they are served by the same cell or different cells;

4.  whether both users are subscribers of the same operator;

5.  whether none, one or both users are in a roaming situation.

Moreover, these core features described above are subject to different level of performance with regard to:

1.  management of Quality of Service (QoS);

2.  management of security;

3.  management of service continuity.

QoS, security and service continuity are therefore key performance indicators that have to be taken into account by 3GPP work on D2D communications.

Core Options for System Architecture {#Sec_CoreOptions}
====================================

At the beginning of 2013 the SA2 group started the system architecture definition suitable to fulfill the requirements identified for ProSe and GCSE. As usual for defining complex new features, a two-step approach was performed. In a first step, a TR document proposing different solutions would be defined. In a second step, the best solution would be chosen, and would lead to the definition of TS documents that will be the normative specification of the features. Since the beginning of 2013, TR $23.703$ [@23703] and TR $23.768$ [@23768] have progressed and currently contain the following information:

-   a list of key issues to be solved;

-   the definition of an overall system architecture;

-   the identification of technical solutions expected to meet the system requirements.

An overall architecture for the non-roaming cases, and a variant for the roaming cases were defined. Those architectures identified the main components and reference points of the system. For example, ProSe overall architecture [@23703] for the non-roaming case is presented in Fig. \[architecture\].

![ProSe Overall Architecture[]{data-label="architecture"}](ProSe_Overall_Architecture_bis_colours_improved)

As described by Fig. \[architecture\], six reference points have been introduced, as well as a ProSe Function located in the EPS, and a ProSe APP Server that is outside of the EPS. The new component “ProSe Function” is created to support the Evolved Packet System (EPS) features of ProSe. The ProSe APP Server, which is located outside the 3GPP network, represents the application server of a ProSe provider. This architecture has to support a wide range of solutions and is thus very generic and flexible.

The overall architecture has also to support all the features of ProSe, such as the discovery and the communication between UEs. This later one includes the communication required allowing a UE out-of-network coverage to access to the network infrastructure through a UE-Relay.

The architecture allows a wide split of functionalities and a different type of interfaces. The ProSe Function and the ProSe APP Server split can be very different. Some solutions can be based on the use of IMS in the ProSe APP Server, other solutions allow to use ProSe control plane messages over the PC3 interface between the UE and the ProSe Function by using IP user plane messages, while other solutions could use Non-Access Stratum (NAS) messages.

Another architecture has been defined in $23.768$ [@23768] for GCSE\_LTE. This architecture has a new component GCSE Application Server (GCSE AS) and a Multipoint Service (MuSe) component most probably based on already existent Multimedia Broadcast/Multicast Service (MBMS)-type solution. In the case of GCSE\_LTE, five new reference points have been proposed: GC1 between GCSE AS and GCSE application on UE side, GC2 between the GCSE AS and MuSe, GC3 between MuSe and the base station eNB, GC4 between MuSe and the Mobility Management Entity MME, and finally GC5 between MuSe and the Packet-GateWay (P-GW).

In ProSe TR 23.703 [@23703], the solutions proposed to meet the ProSe requirements can be divided in four categories:

-   solutions related to the definition of ProSe identities (see Section \[D2D\_Discovery\] and more precisely Subsection \[Identifiers\]);

-   solutions related to direct discovery (see Section \[D2D\_Discovery\] and more precisely Subsection \[Disc\_Information\_in\_RRC\]);

-   solutions related to direct communication (see Section \[D2D\_Communication\]);

-   solutions related to UE-Relay.

The next sections \[D2D\_Discovery\] and \[D2D\_Communication\] provide a review of the latest 3GPP RAN2 [@RAN283bis] and SA2 [@SA299] discussions and the material provided in these sections tries to summarize the most important contributions.

3GPP D2D Discovery Solutions {#D2D_Discovery}
============================

As previously mentioned, the first subsection from Section \[D2D\_Discovery\] (i.e. Subsection \[Identifiers\]) deals with the UE and Group Identities for both discovery and communication on PC5, while the second subsection (i.e. Subsection \[Disc\_Information\_in\_RRC\]) shows how the discovery information is being transmitted and received.

User Equipment and Group Identities {#Identifiers}
-----------------------------------

In order to perform the direct discovery, a UE has to broadcast a discovery information using direct communication. The direct 1:1 communication could be done in a Question/Answer-based manner (e.g. Question: Is the service or the UE “A” around? followed by the Answer: Yes, “A” is available at UE-John.Doe) or in an Announcement-based manner which is regularly repeated during the broadcast period (e.g. Announcement: Service “A” is available at UE-John.Doe). The information communicated during the D2D communication therefore contains a discovery identifier relating D2D communication to the UEs and to the service (i.e. “Discovery Type” from Fig. \[identities\]). After the discovery identities are defined and produced by e.g. an application server (or by a UE), they have to be communicated to the UEs that need to use them either for broadcast purposes, either for detection purposes. In the particular cases of public safety where UEs are out-of-network coverage, the discovery identities have to be independently determined by each concerned UE (i.e. “UE-related Identity” from Fig. \[identities\]).

More than that, the discovery identities need to be unique in all circumstances. In particular, it has to be noted that the discovery service can be performed in an inter-operator scenario or when UEs are in a roaming situation, and therefore the UE-related Identity may not assure uniqueness. In order to keep the uniqueness of the identities, some proposed solutions use an application-level URL-type identifier (e.g., <PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>) that can be converted to a unique discovery code (i.e. “Discovery Code” from Fig. \[identities\]) to be broadcasted between the UEs. Some other solutions add Layer 2 identities of discoveree/discovered UEs, i.e. a solution proposed to create a generic Layer 2 source and destination addresses in each D2D discovery messages.

For exemplification, Fig. \[identities\] presents a possible example of discovery message composed from: the type of discovery message, the UE-related identity and the discovery code.

![Example of Discovery Message[]{data-label="identities"}](Discovery_Identities_bis_bis_colours)

Moreover, in the particular case of public safety UEs, the discovery is used to find UEs related to a particular communication group. A specific identity related to the group could be therefore added or included as part of the application identifier (e.g. John.Doe:<PRESIDIO_ANONYMIZED_EMAIL_ADDRESS>). Also, for public safety UEs, the discovery services could be available when the UEs are out-of-network coverage requiring a pre-configuration of identifiers or different methods for local generation of identifiers. With respect to all the above mentioned, the security of the identifiers broadcasted over the air will be defined by the 3GPP WG SA3 in order to keep the required level of confidentiality and security.

Discovery Information Transmission and Reception {#Disc_Information_in_RRC}
------------------------------------------------

The goal of Subsection \[Disc\_Information\_in\_RRC\] is to describe how the discovery information is transmitted (see Subsection \[TxDiscInfo\]) and how discovery information is received and used (see Subsection \[RxDiscInfo\]) for different RRC states.

### Transmission of Discovery Information {#TxDiscInfo}

In current LTE network system, legacy UE transmission control by eNB during RRC connected mode ensures that eNB dynamically restricts the intra-cell and inter-cell interference. However, the eNB does not need to control RRC idle mode legacy UEs since they do not cause interference. As explained below, the needs are different when considering direct discovery because 1) in RRC idle mode the D2D UEs may need to transmit without directly entering in RRC connected mode and 2) too many transitions from the RRC idle mode to RRC connected mode are expensive from the signaling point of view.

For example, users running an application on their phone may want to find other nearby users of the same application at any time. Requesting the UE to enter RRC connected mode to transmit a discovery message and then to enter again RRC idle mode once the message has been transmitted would result in a high signaling overhead. It is therefore desirable that a UE transmitting D2D discovery messages be allowed to transmit while in RRC idle mode. Moreover, the transition of a UE from RRC idle to connected mode may result in random access procedure, RRC connection establishment, initial security activation, default EPS and radio bearer establishments. Thus, any RRC idle to connected mode transition caused by discovery will overload the random access procedure, will increase the control plane overhead and will impact the UE power consumption.

### Reception of Discovery Information {#RxDiscInfo}

It seems obvious that allowing devices to receive discovery messages while in RRC idle mode would provide several advantages compared to requesting the devices to enter RRC connected mode.

For example, a user can activate an application which is notifying of the proximity of restaurants of interest. The relevant application would conceivably be continuously running on the device, meaning that if discovery was only permitted while in RRC connected mode, the device would be unable to leave this state unless the application was deactivated. However, requesting a UE to remain in RRC connected mode to receive discovery messages may be unacceptable for several reasons. Firstly, the power consumption of a UE remaining in RRC connected mode may be considerably high. Secondly, compared with a UE in RRC idle mode, a UE remaining in RRC connected mode may increase the amount of signaling throughout the network as a result of handover procedures. It is therefore much more practical for the device to discover a restaurant while in RRC idle mode and only enter RRC connected mode if the user requested more information on the restaurant, such as opening times and menus.

3GPP Radio Resource Allocation Schemes for D2D Communication {#D2D_Communication}
============================================================

The main focus of Section \[D2D\_Communication\] is on direct 1:many communication for 3GPP Rel-12 for in-network coverage and out-of-network coverage situations. In order to ensure efficient usage of resources and to allow an efficient UE power consumption in both situations, two main types of resource allocation schemes have been currently proposed:

-   Centralized approach (see Subsection \[Centralized\]): The network controls the resource allocation. This approach can either apply to an eNB in-network coverage or to a cluster head in out-of-network coverage case. The centralized approach consists in a dynamic or semi-persistent scheduling for which the UE is scheduled with resources for every D2D transmission.

-   Distributed approach (see Subsection \[Distributed\]): The UE autonomously allocates resources by itself from a pool of semi-statically configured resource blocks. As the resource allocation is distributed, and therefore same resource blocks can be allocated at the same time by different UEs, there might be a contention situation that has to be properly solved.

Centralized Approach {#Centralized}
--------------------

For the centralized approach, the D2D transmitting UE sends a scheduling request to the network controller or centralized node. Upon receiving the scheduling request from the transmitting UE, the centralized node allocates a resource which is not being used by other member UEs (i.e. UEs involved in groupcast communication) or by all UEs (i.e. UEs in proximity) within the cell or within the coverage of the centralized node. The centralized node assigns resources based on the amount of data to be sent and also based on the radio conditions. If the amount of data requested by the transmitting UE cannot be fulfilled by a single schedule, multiple schedules are required. Depending on the application or the type of service, it may also be possible to provide semi-persistent resources. The centralized node also informs the D2D UEs with the resources used for transmission by other member UEs involved in a groupcast communication or all other UEs which are in proximity.

Distributed Approach {#Distributed}
--------------------

For the distributed approach, a pool of resources is semi-statically allocated by the network (i.e. for the in-network coverage case) or is pre-configured when the UE is registered with the network (i.e. for the out-of-network coverage case). The UEs use this pool of resources to transmit/listen direct discovery beacons, but the pool of resources can also be used for direct 1:1 and 1:many communication. As it is a contention-based access, some form of collision handling mechanism (e.g. Carrier Sense Multiple Access Collision Detection or Collision Avoidance, CSMA/CD or CSMA/CA) is needed to detect/avoid/resolve any collision. In CSMA, the transmitting UE listens to the pool of resources to determine which of resources are being used or not for transmission by other UEs. Once it determines that a resource is not occupied, the UE may transmit using the same resource. The random selection of the unused resources may decrease the number of collisions, but collisions may still occur if the pool of resources is limited.

Centralized Approach vs. Distributed Approach
---------------------------------------------

In Subsection \[Centralized\] and Subsection \[Distributed\] two main approaches were presented: centralized approach (i.e. full scheduling) and distributed approach (i.e. CSMA-like resource allocation). Table \[Approaches\] further provides a comparison of the two main approaches, with their advantages and disadvantages.

  ------------------- ------------- --------------------------
                      Centralized   Distributed
                      Approach      Approach
  Resource            High          Low (depending on the
  Efficiency                        type of CSMA solution)
  Signaling           High          Low
  Overhead                          
  Pre-configuration   No            Yes (e.g., determination
  of Resources                      of resource pool)
  Interference        Low           Medium
  ------------------- ------------- --------------------------

  : \[Approaches\] Comparisons of the Resource Allocation Approaches

![image](Tentative-Roadmap_bis_short_withRel13_correct)

Based on Table \[Approaches\], it can be easily observed that CSMA-like mechanism has relatively lower complexity and signaling overhead. However, the drawback of the distributed approach is its weakness in terms of interference control and collision resolution. The collision resolution is typically implemented using probabilistic approaches, e.g. using medium/carrier sensing and a random back-off timer to perform retransmission if medium is occupied (e.g. CSMA/CA). These mechanisms typically increase power consumption of the UE when active and may lead to degradation of system performance. On the other hand, centralized approach has the advantage that it can efficiently manage radio resources in a cell and it can avoid UE interference with other UEs or with the network. For D2D communications, the centralized approach may also need to consider the D2D channel condition and the D2D buffer status reported by the UEs. If for example the number of transmitting D2D UEs is high, this will probably increase the signaling overhead significantly and therefore new measurement, configuration and reporting methods have to be defined by 3GPP.

3GPP ProSe Roadmap and Prioritisation {#Sec_3GPPOrg}
=====================================

Among other important activities, 3GPP TSG RAN and 3GPP TSG SA are also involved in D2D proximity services from overall work plan management. In September 2013, during SA 61 meeting, 3GPP TSG SA reviewed the Rel-12 progress in different working groups. Due to the important activities in the radio access area, not only due to proximity services, 3GPP TSG RAN proposed to reduce the scope of proximity services in Rel-12. Similarly, experimenting an overload situation, 3GPP WG SA2 proposed to limit Rel-12 to a list of essential features. Based on these information, 3GPP TSG SA decided to limit the proximity features for Rel-12 to discovery and public safety group communication.

3GPP ProSe tentative roadmap for Rel-12 and Rel-13 can be found in Fig. \[Roadmap\]. The UE-Relay feature was maintained in Rel-12, but is considered as a lower priority item and remains at risk for the final release. Regarding the overall schedule for Rel-12, it is highly possible to have a planning exception and complete three months later than the official timescale currently set to June 2014. The service aspects and network requirements (covered by stage 1) are now complete, but the completion of the architecture (stage 2) would then be finalized by March 2014 and the completion of the protocols (stage 3) would be finalized by September 2014 for both Core Network (CN) and RAN-related aspects. With respect to Rel-13, the main work will probably concern direct discovery feature (including interaction with 3rd party applications and UE terminal applications), direct 1:many communication feature for commercial use, UE-Relay feature with RAN impact (not covered by Rel-12) and service continuity aspects.

Conclusion {#Sec_Conclusion}
==========

This paper shows the latest 3GPP contributions on D2D communications and public safety. With respect to all the D2D features presented above (i.e., direct discovery, direct 1:1 and 1:many communications) there are some important research topics that have to be considered in order to improve the user experience such as energy consumption, QoS, security, resource allocation, interference management (i.e., including interference avoidance) and service continuity.

Acknowledgment {#acknowledgment .unnumbered}
==============

The research leading to these results has received funding from the European Community’s Seventh Framework Programme (FP7/2007-2013) under grant agreement CRS-i number 318563. The research leading to this paper has been also supported in part by the Celtic-Plus project SHARING, project number C2012/1-8.

[16]{}

Klaus Doppler, Mika Rinne, Carl Wijting, Cássio B. Ribeiro and Klaus Hugl, Device-to-Device Communication as an Underlay to LTE-Advanced Networks, IEEE Communications Magazine, Dec. 2009. Gábor Fodor, Erik Dahlman, Gunnar Mildh, Stefan Parkvall, Norbert Reider, György Miklós and Zoltán Turányi, Design Aspects of Network Assisted Device-to-Device Communications, IEEE Communications Magazine, May 2011. Lei Lei, Zhangdui Zhong, Chuang Lin and Xuemin (Sherman) Shen, Operator Controlled Device-to-Device Communications in LTE-Advanced Networks, IEEE Wireless Communications, June 2012.

Anna Paulson and Thomas Schwengler, A Review of Public Safety Communications, from LMR to Voice over LTE (VoLTE), IEEE PIMRC 2013, 8-11 September 2013, London, UK.

3GPP Technical Report $22.803$, 3GPP WG SA1, Feasibility study for Proximity Services (ProSe), http://www.3gpp.org/ftp/Specs/html-info/22803.htm. 3GPP Technical Specification $22.278$, 3GPP WG SA2, Service Requirements for the Evolved Packet System (EPS), http://www.3gpp.org/ftp/Specs/html-info/22278.htm.

3GPP Technical Report $23.703$, 3GPP WG SA2, Study on architecture enhancements to support Proximity Services (ProSe), http://www.3gpp.org/ftp/Specs/html-info/23703.htm.

3GPP Technical Report $36.843$, 3GPP WG RAN1, Feasibility Study on LTE Device to Device Proximity Services - Radio Aspects, http://www.3gpp.org/ftp/Specs/html-info/36843.htm.

3GPP Technical Specification $22.468$, 3GPP WG SA1, Group Communication System Enablers for LTE (GCSE\_LTE), http://www.3gpp.org/ftp/Specs/html-info/22468.htm.

3GPP Technical Report $23.768$, 3GPP WG SA2, Study on Architecture Enhancements to Support Group Communication System Enablers for LTE, http://www.3gpp.org/ftp/Specs/html-info/23768.htm.

RAN2 meeting number 83 bis (R2-83b), 7-11 October 2013, Ljubljana, ftp://ftp.3gpp.org/TSG\_RAN/WG2\_RL2/TSGR2\_83bis/Docs/.

SA2 meeting number 99 (S2-99), 23-27 September 2013, Xiamen, ftp://ftp.3gpp.org/TSG\_SA/WG2\_Arch/TSGS2\_99\_Xiamen/Docs.