D2D

D2D stands for 'Device to Device'. It implies 'Direct communication between Devices'. In current implementation (i.e, without D2D), every communication between devices has to go through the full path of the network. Conceptually, ideal goal of D2D would be to establish the communication path between them without any intermediate component (e.g, eNB etc). Probably Bluetooth can be regarded as the best example of D2D just in terms of concept (Of course, we don't take Bluetooth as a part of 3GPP D2D) and now you may hear a lot of Direct WiFi. However, in reality it seems likely that D2D would get at least a few of intermediate component (e.g, eNB) between the devices.

However in the context of LTE (or any other wide scale wireless communication), it is not that simple to achieve D2D. Probably followings would be the biggest hurdles to overcome.

How to make money (Business Model).
How to handle Security (Authentication, Ciphering)
What kind of radio protocol should be used. (You may refer to TR 36.843 for D2D Radio currently being researched).

With these factors being considered, the concept being formally proposed/investigated in 3GPP seems to assume that it would be difficult (almost impossible) to completely exclude network involvement but it would be possible to minimize it.

I will try to keep posting things being investigated/proposed by 3GPP rather than putting too much fancy stories.

Who will be the master ? Network or UE ?

In normal LTE and other celluar communication, Network is almost always the master and it controls everything. What about in D2D ? Will the situation still be the same ? or Will UE get more controling power ? The question is worth asking carefully, because the answer that arrived is two answers rather than one, together with a rule for choosing between them.

At least in current specification, it seems that Network still hold the controlling power. It means the control signaling (e.g, Initial access, authentication, connection control, resource reservation) is handled by the network.

One possible except would be the case for public safty area such as emergency/disaster case. In this situation, there might be the situation where the network is down. Even in this csae, communication between security forces should still be possible. Therefore, there is some possibility that the future specification would support an autonmous control by UEs or a hybrid approach with the distributed control between network and UEs. (Reference [3])

Release 12 settled the question, and it settled it as a pair of modes rather than as a single winner. 36.300 clause 23.10.3.0 gives a UE supporting sidelink communication exactly two ways to obtain transmission resources, and which of the two applies depends on whether the UE can see a cell at all.

Scheduled resource allocation leaves the network as master. The UE has to be in RRC_CONNECTED before it may transmit anything. It asks for resources with a scheduling request, either a D-SR or Random Access, and follows that with a Sidelink BSR. The eNB reads the Sidelink BSR, works out that the UE has sidelink data and how much of it there is, and schedules the resources using a configured SL-RNTI. That is the ordinary LTE scheduling loop, with a sidelink buffer report substituted for the uplink one and a different RNTI on the grant.

UE autonomous resource selection moves the decision into the handset. The UE picks resources out of a pool by itself and chooses its own transport format. Up to eight transmission pools are available, pre-configured for out of coverage operation or supplied by RRC signalling for in-coverage operation. Each pool carries one or more PPPP values, where PPPP stands for ProSe Per-Packet Priority, and the UE selects the pool whose associated PPPP matches the highest PPPP among the logical channels in the MAC PDU it is about to send. Once a pool is selected, the selection holds for the whole Sidelink Control period.

Coverage decides which mode is on offer, and the clause states the rule plainly. A UE that is out of coverage for sidelink communication can only use UE autonomous resource selection. A UE that is in coverage may use either mode as per eNB configuration, and it shall use only the mode the eNB configured unless one of the exceptional cases listed in 36.331 occurs. Even the exception is fenced: the UE may fall back to autonomous selection temporarily, and the pool it falls back to may itself have been provided by the eNB.

So the network stays master wherever it can reach, and gives the decision away only where it cannot. The guess above about public safety was the right one, and the mechanism is more conservative than the word autonomous suggests. Out of coverage the UE uses resources pre-configured in the UICC or the ME, which an operator wrote there in advance. The moment the UE detects an E-UTRA cell on the Public Safety ProSe Carrier, it stops using them.

One broadcast message carries most of the in-coverage half of this. SystemInformationBlockType18 is where a cell states that it supports sidelink communication and which pools a UE may use on it. A cell can also broadcast the block with commConfig left out, which says that sidelink communication is supported but that no transmission resources come for free, so a UE has to enter RRC_CONNECTED and ask.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType18-r12 ::= SEQUENCE {
    commConfig-r12                      SEQUENCE {
        commRxPool-r12                      SL-CommRxPoolList-r12,
        commTxPoolNormalCommon-r12          SL-CommTxPoolList-r12           OPTIONAL,   -- Need OR
        commTxPoolExceptional-r12           SL-CommTxPoolList-r12           OPTIONAL,   -- Need OR
        commSyncConfig-r12                  SL-SyncConfigList-r12       OPTIONAL    -- Need OR
    }                                                                       OPTIONAL,   -- Need OR
    lateNonCriticalExtension            OCTET STRING                        OPTIONAL,
    ...,
    [[  commTxPoolNormalCommonExt-r13           SL-CommTxPoolListExt-r13    OPTIONAL,   -- Need OR
        commTxResourceUC-ReqAllowed-r13         ENUMERATED {true}       OPTIONAL,   -- Need OR
        commTxAllowRelayCommon-r13              ENUMERATED {true}           OPTIONAL    -- Need OR
    ]]
}

The four fields inside commConfig divide the work between the two modes. commRxPool is what a UE listens on, in RRC_IDLE and in RRC_CONNECTED alike, and it is the only one of the four that is not optional once commConfig is present. commTxPoolNormalCommon is the pool a UE may transmit on autonomously while it is idle. commTxPoolExceptional is the narrow pool reserved for the exceptional cases mentioned above. commSyncConfig is what lets a UE receive and transmit synchronisation information, which matters once the cell is out of the picture.

In the other direction, a UE in RRC_CONNECTED that wants sidelink resources sends SidelinkUEInformation. Its fields are requests rather than reports: commRxInterestedFreq names the carrier the UE wants to receive on, and commTxResourceReq asks for transmission resources. The eNB checks the authorisation against the UE context it holds from the MME before answering.

Two modes, and only two : 36.300 clause 23.10.3.0 names scheduled resource allocation and UE autonomous resource selection, and nothing else.
Scheduled means connected : the UE cannot transmit until it reaches RRC_CONNECTED, and it asks with a scheduling request followed by a Sidelink BSR.
The grant is addressed to an SL-RNTI : the eNB schedules sidelink transmission resources against a configured SL-RNTI rather than the UE's ordinary C-RNTI.
Autonomous still means pools : up to eight of them, each tagged with one or more PPPP, and the choice holds for a whole Sidelink Control period.
Coverage picks the mode : out of coverage only autonomous selection is available, and in coverage the eNB decides which of the two the UE shall use.
Out of coverage still runs on operator resources : the pre-configured pools sit in the UICC or the ME, and the UE drops them as soon as it finds a cell on the carrier.

Data Path

Following is the possible configuration proposed by TR 22.803 Feasibility Study for Proximity Services (ProSe). The final requirement can be different as it moves forward to TS document. But this can be a good start for you to think of as many possibilities as possible.

The three rows below are worth reading as three guesses, because one of them is what the specification took and the other two are not. The question each row answers is how far into the network a packet has to travel before it can turn round.

Possible Configuration	Description
	In this configuration, Two UEs (or more than two) UEs takes separate path up to SGW/PGW and get directly connected at the level of SGW/PGW. In this case, considerable portions of data path is same as the current (non D2D) use mode. Then, what would be the advantage of D2D in this configuration as apposed to other kind of presense service ? (How about using RCS showing the presense and the location of the device ?)
	In this configuration, Two UEs exchange data directly with each other without going through any part of LTE network. Then, the question is "What kind of Radio they use for this communication since there is no direct communication among UEs at Radio level ?" (Probably LTE Direct ?) How Network operator can make money in this case ?
	In this configuration, two UEs belogn to same eNB and direct data exchange can be done at the level of eNB. It seems to be the most practical to me (personally) since it can still use LTE radio for communication and hops between the two UE is also very small. But how to handle those situations where two UEs are in proximity (near to each other) but belong to different eNB ?

The arrangement that became specification is the one drawn with the arrow straight between the two handsets. 36.300 clause 23.10.2.1 places PDCP, RLC and MAC for sidelink communication in the UE, and states in one parenthesis that they terminate at the other UE. Nothing in the sidelink user plane turns round inside an eNB.

That settles the row where both UEs sit on the same eNB as well. Doubling the path back at the eNB the two UEs share is the natural guess, and the reasoning above about hop count is sound, but the specification did not take it. The direct hop is called PC5, and it is a radio interface with its own protocol stack rather than a shortcut through Uu. The traffic on it rides a Sidelink Traffic Channel, which 36.300 defines as point-to-multipoint. Communication between exactly two UEs is realised on an STCH as well, as a special case of the same channel.

The sidelink user plane is also leaner than the uplink it borrows from, and 36.300 lists the differences rather than leaving them to be inferred. There is no HARQ feedback for sidelink communication, so a transmitter never learns whether anyone received the block. RLC runs in Unacknowledged Mode. A receiving UE keeps at least one RLC UM entity per transmitting peer, and that entity does not have to be configured before the first RLC UMD PDU arrives. Header compression is ROHC in Unidirectional Mode, for the same reason as the rest: there is no return path to carry feedback on.

Identity is scoped differently too. An LCID in a sidelink MAC subheader identifies a logical channel only within one combination of Source Layer-2 ID and Destination Layer-2 ID, so the same LCID value means different things between different pairs of UEs. Parameters for logical channel prioritization are not configured at all. Each logical channel carries a PPPP instead, which the higher layer supplies along with the packet.

The data path is the direct one : PDCP, RLC and MAC for sidelink terminate at the peer UE, so the user plane never enters an eNB.
PC5 is the name of that hop : it is a radio interface in its own right, not a turn made inside the Uu path.
No HARQ feedback : a sidelink transmitter is never acknowledged, which is why RLC uses Unacknowledged Mode and ROHC uses Unidirectional Mode.
LCID is scoped to a pair of UEs : it is unique only within one Source Layer-2 ID and Destination Layer-2 ID combination.
Priority arrives with the packet : logical channel prioritization is not configured, and a PPPP comes down from the higher layer on each protocol data unit.

Control Path

Possible Configuration	Description
	When multiple ProSe capable UEs are within the coverage of the same eNB, the system can perform ProSe Communication using control information exchange between the UE, eNB and EPC (e.g, session management, authorization, security)
	When multiple ProSe capable UEs are connected to different eNBs, the system still can perform ProSe Communication as indicated by solid lines and arrows. In this case, the multiple eNB can talk to each other ether via EPC or via direct communication as indicated in dotted arrow.
	Even when network coverage is not available, the control path can exist directly between Public Safety UEs. In this configuration, the Public Safety UEs can rely on pre-configured radio resources to establish and maintain the ProSe Communication. Alternatively, a Public Safety Radio Resource Management Function within UE can manage the allocation of radio resources for Public Safety ProSe Communication as shown with the dashed arrows

All three arrangements above survived, and the row with the cloud in it is the interesting case, because the specification kept it and then fenced it off. 36.300 clause 23.10.1 says sidelink communication is supported both when the UE is served by E-UTRAN and when the UE is outside E-UTRA coverage, which is exactly what that row draws. The same clause adds the restriction the drawing cannot show: only those UEs authorised to be used for public safety operation can perform sidelink communication.

That restriction is also the answer to the question asked further up this page about where an operator's money comes from. Direct communication is not the commercial product. Sidelink discovery is, and it is a separate feature with its own clause, its own resources in SIB19 and a much smaller protocol stack. 36.300 clause 23.11.1 restricts only the out of coverage use of discovery to public safety UEs, which leaves the in coverage use open. References [1] and [2] at the foot of this page are both about LTE Direct, and LTE Direct is the discovery half rather than the communication half.

Once the cell is out of the picture, something has to replace it as the timing reference, and a UE takes the job. A UE may act as a synchronisation source by transmitting SBCCH together with a synchronisation signal, on a fixed period of 40 ms. SBCCH is a logical channel, mapped to the SL-BCH transport channel and carried on the PSBCH physical channel, and it carries the smallest set of system information a receiver needs in order to receive the other sidelink channels. In coverage its contents come from what the eNB signalled. Out of coverage the UE either derives them from the SBCCH of whichever UE it chose as its reference, or falls back on pre-configured parameters. Two subframes every 40 ms are pre-configured for this, one to receive on and one to transmit on.

Uu still wins wherever the two compete for the same moment. 36.300 clause 23.10.1 gives the priority order a UE applies between Uu and PC5, and Uu transmission and reception sits at the top of it, above sidelink communication and above discovery. When a Sidelink Discovery Gap is configured the order is finer, and RACH on Uu moves to the top while non-RACH Uu traffic drops below discovery announcement. The network keeps first claim on the UE's radio even while that UE is talking directly to its neighbour.

Communication is public safety only : 36.300 clause 23.10.1 restricts sidelink communication to UEs authorised to be used for public safety operation.
Discovery is the commercial half : it has its own clause, its own system information block and its own resource rules, and LTE Direct is the name it was shown under.
A UE can become the clock : out of coverage a UE transmits SBCCH and a synchronisation signal every 40 ms so that its neighbours can receive the other sidelink channels.
Uu outranks PC5 : the priority list puts uplink and downlink traffic above both sidelink communication and sidelink discovery.

From the ProSe study to specified sidelink

This page was written while TR 22.803 and TR 36.843 were still open, and both of them landed. The result is called sidelink, and it occupies 36.300 clause 5.6 for its physical layer and clause 23.10 for its procedures. This section sets out what the study became, and reads it against the questions raised above while the answers were still open.

Three things travel over sidelink, and 36.300 clause 5.6.0 names all three in one sentence: sidelink discovery, sidelink communication and V2X sidelink communication. All three use uplink resources and a physical channel structure similar to uplink transmissions. That is the concrete form of the expectation set out at the top of this page, that some part of the LTE network would stay in the picture. The resources are uplink resources even when no eNB is listening to them.

The physical channels are new but derivative, and there are four worth knowing. PSCCH carries sidelink control information, which tells a receiver the resources and the transmission parameters used for PSSCH. PSSCH carries the data. PSDCH carries discovery messages. PSBCH carries the system and synchronisation information a UE sends when it acts as a synchronisation source. Sidelink is limited to single cluster transmissions on all of them, and it leaves a one symbol gap at the end of every sidelink subframe.

The modulation set is cut down, and 36.300 clause 5.6.2 states the cut as a difference from uplink rather than as a table. 256 QAM is not supported for sidelink, and 64 QAM is only supported for V2X sidelink communication. Sidelink communication between two handsets therefore runs at QPSK or 16QAM. The same clause notes that scrambling is not UE-specific for PSDCH and PSCCH, which is what lets a UE decode a transmission from a UE it has never heard of.

Measurement needed new quantities, because there is no cell to measure. 36.300 clause 5.6.6 lists S-RSRP for the sidelink, SD-RSRP for discovery, PSSCH-RSRP, and S-RSSI. A UE judges a peer with these in the same way it judges a cell with RSRP and RSSI.

The discovery stack is the smallest in LTE. 36.300 clause 23.11.2 gives it only MAC and PHY. The discovery message comes down from the ProSe Protocol straight into MAC, the IP layer is not used to carry it, and the MAC PDU that carries it has no MAC header at all. The content is transparent to the access stratum, which learns only whether the announcement is public safety related and whether it concerns a relay. Discovery also has range classes, three of them, and the maximum allowed transmission power for each is broadcast in SIB19.

One arrangement none of the drawings above shows closes the gap between the two coverage states. A ProSe UE-to-Network Relay is a UE that forwards IP traffic between a remote UE and the network, described in 36.300 clause 23.10.4. The relay is always in coverage of E-UTRAN, and it has to be in RRC_CONNECTED to carry relay traffic. The remote UE need not be in coverage at all. The remote UE measures the PC5 link, selects the relay with the best link quality among those that are suitable, and stops using relay resources once its own RSRP climbs back above a threshold the eNB broadcast.

Sidelink is the name the study took : 36.300 clause 5.6.0 covers sidelink discovery, sidelink communication and V2X sidelink communication together.
Uplink resources, uplink shape : the physical channel structure is similar to uplink transmission, and the resources are uplink resources.
Four physical channels to learn : PSCCH for control, PSSCH for data, PSDCH for discovery and PSBCH for the broadcast a synchronisation source sends.
The modulation set is cut : 256 QAM is not supported at all, and 64 QAM only for V2X sidelink communication.
Peers are measured, not cells : S-RSRP, SD-RSRP, PSSCH-RSRP and S-RSSI replace the cell measurements.
Discovery runs on MAC and PHY alone : the IP layer is not used, and the MAC PDU carrying an announcement has no MAC header.
A relay bridges the two coverage states : a ProSe UE-to-Network Relay is always in coverage and forwards IP traffic for a remote UE that is not.

Reference

[1] Proximate Discovery: LTE Direct
[2] LTE Direct: A New Way to Discover (Qualcomm Developer Network)
[3] 3GPP LTE-A Standardisation in Release 12 and Beyond (nomor WhitePaper)
[4] T Dev Forum. 10 LTE D2D Introduction and Application (Youtube, in Korean)
[5] 36.300 : 3GPP - E-UTRA and E-UTRAN; Overall description, v19.2.0. Clause 5.6 covers the sidelink physical layer, and clause 23.10 covers sidelink communication including the two resource allocation modes.
[6] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. SystemInformationBlockType18 carries the sidelink communication pools, and SidelinkUEInformation is how a UE asks for transmission resources.