7
LLC Service – Proximity Communications
7.1. Introduction
The proximity service (ProSe) enables a new type of link, the sidelink (SL), between mobiles, in addition to the downlink (DL) and uplink (UL) between a mobile and an evolved node base station (eNB).
The proximity service implements two types of communication:
- – device-to-device (D2D) communication;
- – vehicle-to-everything (V2X) communication.
The D2D communication comes in two applications:
- – communication between mobiles related to public safety (e.g. firefighters);
- – communication between mobiles for commercial purposes.
The mobile communication between mobiles related to public security allows the service to be maintained when the eNB entity fails, for example, in a large-scale disaster or when mobiles are no longer covered by the eNB entity.
The distribution of information to nearby terminals is a function introduced for mobile communication for commercial purposes.
In the coverage scenario, the radio access network controls the resources used for the D2D communication. It can assign to a mobile-specific resource or a pool of resources from which the mobile selects. In this way, interference with cellular traffic is avoided.
In the case of the mobile being out of coverage, control over the radio access network is not possible. The mobile uses preconfigured resources, either on the equipment or in the universal subscriber identity module (USIM) of the universal integrated circuit card (UICC).
A special case is partial coverage. The out-of-coverage mobile uses preconfigured values, while in coverage case, the mobile obtains its resources from the eNB entity. The coordination between the radio access network and the preconfigured values is necessary to allow communication and to limit interference to mobiles at the edge of the cell.
Figure 7.1 summarizes the various scenarios for deploying D2D communications:
- – both mobiles (UE A and UE B) are not covered by the eNB entity;
- – a single mobile (UE A) is under the coverage of the eNB entity;
- – the two mobiles (UE A and UE B) are under the coverage of a single eNB entity;
- – the two mobiles (UE A and UE B) are under the coverage of two eNB entities (eNB A and eNB B).
Figure 7.1. Deployment scenarios for D2D communications
The four types of deployment are applicable to the mobile communication related to public safety. Deployment is restricted for mobile-to-commercial communications, with mobiles being under eNB coverage.
The V2X communication is divided into four types of communication depending on the different devices with which the vehicle connects (Figure 7.2):
- – vehicle-to-vehicle (V2V) communication;
- – vehicle-to-infrastructure (V2I) communication;
- – vehicle-to-pedestrian (V2P) communication;
- – vehicle-to-network (V2N) communication.
Figure 7.2. Different types of V2X communication
V2V and V2P communications use the sidelink communication defined for the D2D communication with the following enhancements:
- – taking into account the Doppler effect linked to high relative speeds up to 500 km/h and the synchronization outside the coverage of the eNB entity;
- – taking into account the densification with better allocation of resources and congestion control.
V2N communications use the radio interface LTE-Uu.
V2I communications use either the radio interface LTE-Uu or the sidelink communication.
7.2. Functional architecture
7.2.1. D2D communication
The functional architecture (Figure 7.3) introduces, as the central entity for D2D communications, the ProSe function that communicates with the following elements:
- – the user equipment (UE) for authorization and configuration;
- – the home subscriber server (HSS) to retrieve authentication and subscription data from the service;
- – the SUPL (Secure User Plane Location) location platform (SLP) to retrieve the location data of the mobile;
- – the ProSe application server (AS) to register applications.
Figure 7.3. Functional architecture: D2D communications
7.2.1.1. ProSe function
The ProSe function includes direct provisioning, direct discovery name management and EPC-level discovery sub-features.
The direct provisioning sub-function is used to configure the mobile with the necessary parameters for using direct discovery and sidelink communication functions.
The direct discovery name management sub-function is used for the unrestricted direct discovery function to process the mapping of ProSe application credentials and ProSe application codes.
If the mobile is authorized to transmit the ProSe application identifier in the Discovery Request message, the network will allocate the corresponding ProSe application code via a Discovery Response message including a validity timer.
The ProSe application identifier has two parts:
- – the operator identifier, consisting of the mobile country code (MCC) and the mobile network code (MNC);
- – the application identifier, consisting of several tags separated by a dot, the first tag being always named ProSe App.
The ProSe application code consists of two parts:
- – the identifier of the operator, completed by the Scope field and the E bit;
- – a temporary identifier to replace the identifier of the application.
The Scope field indicates whether the operator identifier has a global scope, whether it is country-specific or operator-specific identifier.
The E bit determines whether or not the identifier of the operator who assigned this particular code is included in the ProSe application code.
The direct discovery name management sub-function uses ProSe service-related subscriber data stored in the HSS entity to obtain authorization for each discovery request.
The direct discovery name management sub-function also provides the mobile with the necessary security materials to protect discovery messages.
The direct discovery name management sub-function is used for the restricted direct discovery to obtain authorization for discovery requests from the ProSe application server.
The EPC-level discovery sub-function has a reference point to the ProSe application server (PC2), other ProSe functions (PC6 or PC7), the HSS entity (PC4a), the SLP entity (PC4b) and the mobile (PC3).
The EPC-level Discovery sub-function provides the following:
- – the storage of subscriber data related to the ProSe service and/or the retrieval of subscriber data from the HSS entity;
- – the authorization and the configuration of the mobile for direct discovery and sidelink communication;
- – the storage of a list of applications allowed to be used for direct discovery and sidelink communication;
- – the agent to the SLP location entity to enable the direct discovery;
- – the exchange of signaling with application servers for the registration of applications;
- – the exchange of signaling with ProSe functions located in other networks for sending proximity requests, proximity alerts and location reports;
- – the optional support for the mobile location request via the HSS entity.
7.2.1.2. Protocol architecture
The PC1 interface is the reference point between the ProSe application hosted on the mobile and the ProSe application server. This interface is not defined as part of the mobile network architecture.
The PC2 interface is the reference point between the ProSe application server and the ProSe function. This interface supports the DIAMETER protocol for recording ProSe applications.
The PC3 interface is the reference point between the mobile and the ProSe function. This interface supports the hypertext transfer protocol (HTTP) that transports data in XML (eXtensible Markup Language) format for mobile authorization and configuration.
The IP (Internet Protocol) packet containing the HTTP/XML message is transported in the following bearers (Figure 7.4):
- – the radio bearer built on the LTE-Uu interface between the mobile and the eNB entity;
- – the S1-U bearer built between the eNB and SGW (Serving Gateway) entities;
- – the S5 bearer built between SGW and PGW (PDN [Packet Data Network] Gateway) entities.
Figure 7.4. Transport of the HTTP/XML message
The PC4a interface is the reference point between the ProSe function and the HSS entity. This interface supports the DIAMETER signaling for the transfer of authentication and subscription data to the service.
The PC4b interface is the reference point between the ProSe function and the SLP entity. This interface supports the mobile location protocol (MLP) for mobile location.
The PC5 interface is the reference point between mobiles A and B. This interface supports the discovery protocol, the signaling and the traffic data. The transmission on the PC5 interface can be in the unicast or broadcast mode.
The PC6 interface is the reference point between the ProSe functions of networks A and B. This interface is used when mobiles A and B are respectively connected to networks A and B.
The PC7 interface is the reference point between the ProSe function of the home and the visited network. This interface is used in the case of roaming.
The PC6 and PC7 interfaces support the DIAMETER protocol for the transfer of mobile location data.
7.2.2. V2X communication
The functional architecture (Figure 7.5) introduces, as the central entity for V2X communications, the V2X control function which informs the mobile with the parameters necessary to use the V2X communication and which communicates with the HSS entity and the V2X application servers.
Figure 7.5. Functional architecture: V2X communications
The road side unit (RSU) is a fixed infrastructure entity capable of receiving and sending V2X messages. Two types of RSUs are defined (Figure 7.6):
- – the eNB-type RSU: the fixed infrastructure, ensuring the transmission of V2X messages to mobiles via the LTE-Uu reference point, is associated with the eNB entity;
- – the UE-type RSU: the fixed infrastructure, ensuring the transmission of V2X messages to mobiles via the PC5 reference point, is associated with a fixed UE, itself connected via the LTE-Uu reference point to an eNB entity.
The V1 interface is the reference point between the V2X application server hosted in the mobile (vehicle, pedestrians and infrastructure) and the V2X application server. This interface is not defined as part of the mobile network architecture.
The V2 interface is the reference point between the V2X application server and the V2X control function. The V2X application server uses this interface to provide its information to the network.
The V3 interface is the reference point between the mobile and the V2X control function. The V2X control function in the home network is the entity that grants the mobile with the authorization to use the V2X communication service.
The V4 interface is the reference point between the V2X control function and the HSS entity. The V2X control function uses the HSS entity to obtain general information about the mobile subscription.
The V5 interface is the reference point between the V2X applications of mobiles A and B. This interface is not defined as part of the mobile network architecture.
The V6 interface is the reference point between the V2X control function of the home and the visited network. This interface is used in the case of roaming.
Figure 7.6. eNB-type and UE-type RSU
7.3. Direct discovery
The network is informed during the attachment procedure if the mobile supports proximity services. Direct discovery and direct communication are autonomous services:
- – direct discovery is not necessarily followed by direct communication;
- – direct communication does not require direct discovery as a precondition.
The discovery is divided into open discovery and restricted discovery. In the latter case, an explicit authorization is required for the mobile being discovered.
The direct discovery is commercially enabled only for the radio coverage scenario and is therefore entirely under the control of the network.
Two modes are defined for using the discovery:
- – the mobile broadcasts information about itself;
- – the mobile sends a request containing certain information on what interests it.
For a mobile intended to be used for public safety, the required service authorization may be stored in the device itself or in the USIM of the UICC.
After authorization, the next step is to send a Discovery Request message to the network. This request is processed by the ProSe function.
The ProSe function contacts the HSS entity to verify that the application is allowed for direct discovery. The ProSe function checks whether the mobile is allowed to use the ProSe application code for announcing or monitoring and prepares a Discovery Response message for the mobile.
For the announcement, the ProSe function returns the ProSe application code and a validity timer. When the timer expires, the mobile must request a new code from the network.
For the monitoring, the Discovery Response message contains one (or more) discovery filter and associated filter identifiers.
If the mobile configured for the monitoring receives a ProSe application code that matches the assigned discovery filter, but does not have a corresponding ProSe application identifier, it is required to send a matching report to the ProSe function.
In this correspondence report, the mobile must indicate whether it wishes to receive data regarding the associated ProSe application identifier. The ProSe function uses the information provided for validation and verification. If this operation succeeds, it sends an acknowledgment to the mobile.
7.4. Radio interface
7.4.1. Radio interface structure
The PC5 radio interface introduces new types of channels and signals (Figure 7.7):
- – the logical channels which constitute the interface between the RLC (Radio Link Control) and MAC (Medium Access Control) layers;
- – the transport channels which constitute the interface between the MAC layer and the physical layer;
- – the physical channels which constitute the internal interface to the physical layer, between, on the one hand, the coding functions of the channel, and, on the other hand, the modulation and multiplexing functions;
- – the physical synchronization signals.
Figure 7.7. Radio interface structure
The sidelink traffic channel (STCH) is used for exchanging user plane data and is mapped to the sidelink shared channel (SL-SCH). The SL-SCH transport channel is then mapped to the Physical Sidelink Shared Channel (PSSCH).
In order for the mobile reception chain to process the PSSCH, the sidelink control information (SCI) is mapped to the physical sidelink control channel (PSCCH).
The radio resources for the sidelink communication can be selected autonomously by the mobile or configured by the network.
The mobile can know the resource blocks allocated to the sidelink communication via the system information block 18 (SIB18) broadcasted by the network.
If this information is not available, the mobile must connect to the network to receive the downlink control information 5 (DCI-5) in the physical downlink control channel (PDCCH) containing the characteristics of the resource blocks allocated to the sidelink communication.
The sidelink discovery channel (SL-DCH) is used by the direct discovery procedure and is mapped to the physical sidelink discovery channel (PSDCH). The discovery function is not used for V2X communications.
The SIB19 provides information on the radio resource pool, on which the mobile is authorized to broadcast (announcing) or receive (monitoring) discovery messages.
The sidelink synchronization signal (SLSS) comprises the primary sidelink synchronization signal (PSSS) and the secondary sidelink synchronization signal (SSSS).
In the case of the D2D communication, the SLSS defines a sidelink identifier (SLI) indicating whether the SLSS is synchronized by the network (value between 0 and 167) or not (value between 168 and 335).
In the case of the V2X communication, the values 0, 168 and 169 of the SLI indicate that the mobile obtains its synchronization from a global navigation satellite system (GNSS).
The sidelink broadcast control channel (SBCCH) contains the sidelink master information block (SL-MIB) containing the technical characteristics of the radio channel assigned to the sidelink.
The SBCCH is mapped to the sidelink broadcast channel (SL-BCH). The SL-BCH is then mapped to the physical sidelink broadcast channel (PSBCH).
The demodulation reference signal (DMRS) is associated with the PSSCH, PSCCH, PSDCH and PSBCH. It is transmitted as the reference signal associated with the physical uplink shared channel (PUSCH) of cellular traffic.
Data transmission over sidelink channels has the same characteristics as the PUSCH of cellular traffic.
The transmission uses single-carrier frequency-division multiple access (SC-FDMA) and applies a quadrature phase-shift keying (QPSK) or a quadrature amplitude modulation (16-QAM) with 16 states.
The QPSK is applied to transmit the control information data on the PSCCH, PSBCH and PSDCH. On the other hand, the user data transmitted on the PSSCH exploits the QPSK and 16-QAM.
7.4.2. Physical resources
7.4.2.1. D2D communication
A resource pool (RP) is a set of resources assigned to the sidelink. It consists of sub-frames and, within the sub-frames, physical resource blocks (PRBs) (Figure 7.8).
Figure 7.8. Resources allocated to the sidelink
There are two resource allocation modes:
- – in mode 1 (D2D communication) or mode 3 (V2X communication), the eNB entity indicates the resources to be used for the sidelink;
- – in mode 2 (D2D communication) or mode 4 (V2X communication), the mobile selects the resources from a set of allocated pools.
For modes 1 and 3, the mobile must be in the RRC_CONNECTED state, while for modes 2 and 4, the mobile may be in the RRC_IDLE state or even outside the radio coverage of the eNB entity.
In a sub-frame, the resources used are in two bands, identified by the physical resource blocks occupied by the sidelink. The first band starts at PRB-Start and the second band ends at PRB-End, each having a resource block width PRB-Num. This arrangement makes it possible to nest several resource pools in a sub-frame and to use the remaining resource blocks for cellular traffic.
Sub-frames allocated to cellular and sidelink communications are indicated in a sub-frame bitmap, whose sidelink control (SC) periodicity is configurable from 40 ms to 320 ms.
The PSSS and SSSS occupy 62 resource elements in the frequency domain and two adjacent OFDM symbols in the time domain. The PSSS and SSSS are identical to the primary synchronization signal (PSS) and the secondary synchronization signal (SSS) of the cellular traffic and are transmitted in a frame every 40 ms.
For a normal cyclic prefix, the PSSS is transmitted in the OFDM symbols 1 and 2 of the first slot and the SSSS in the OFDM symbols 4 and 5 of the second time slot of the same sub-frame (Figure 7.9).
The PSBCH is transmitted in the same sub-frame as the PSSS and SSSS (Figure 7.9). The PSBCH occupies 72 resource elements (six PRBs) in the frequency domain and the remaining OFDM symbols in the time domain, except for those assigned to the DMRS or the guard time.
Figure 7.9. Resources allocated to SLSS and PSBCH
For mode 1, sub-frames assigned to the PSCCH are indicated in a SubframeBitmapSL bitmap transmitted in the SCI. The region assigned to the traffic starts after the last bit ONE of the bitmap. It consists of a time repetition pattern (TRP) of bitmaps, which indicates the sub-frames assigned to the PSSCH. This bitmap is repeated until the end of the SC period, where the last occurrence can be truncated.
For mode 2, this structure is quite similar. The main difference is that the start of the traffic portion does not depend on the content of the SubframeBitmapSL bitmap, but has a fixed offset from the beginning of the SC period.
The resources allocated to the PSDCH for discovery are similar to those assigned to the PSCCH and PSSCH.
7.4.2.2. V2X communication
As with the D2D communication, the vehicle, which uses PC5 sidelink communications, allocates specific time and frequency resources in the form of PRBs for transporting control and user data.
As for the D2D communication, PC5 sidelink communications are allowed in PRBs configured via control messages provided by the eNB entity or preconfigured in the mobile. All sub-frames providing PRBs for PC5 sidelink communications constitute the sub-frame pool.
PRBs are allocated to the sidelink communication in adjacent or non-adjacent manner.
The control plane or user plane data are transmitted in a sub-channel (SCH). The sub-channel division is defined by the network.
In the case of using adjacent PRBs (Figure 7.10):
- – the parameter StartRBSubChannel defines the first resource block PRBs of the SCH;
- – the parameter SizeSubChannel defines the number of blocks of PRBs resources in an SCH;
- – the parameter Number of SubChannels defines the number of SCH established in the sub-frame.
Figure 7.10. Resources allocated to the sidelink: adjacent resource blocks
In the case of non-adjacent PRBs (Figure 7.11):
- – the parameter StartRBPSCCHPool defines the first PRB allocated to the PSCCH;
- – the parameter StartRBSubChannel defines the first PRB of the sub-channel assigned to the PSSCH.
The PRB assigned to the PSCCH for transmitting an SCI message occupy four blocks of contiguous PRBs.
The SLSS and the PBSCH are transmitted with a periodicity of 160 ms.
When the transmission is for the PSCCH and PSSCH, two additional DMRS are inserted into the sub-frames to compensate for interference caused by Doppler shifts (Figure 7.12).
Figure 7.11. Resources allocated to the sidelink: non-adjacent resource blocks
Figure 7.12. DMRS associated with PSCCH and PSSCH
When the transmission concerns the SLSS and the PSBCH, three DMRS are conveyed in the symbols 4 and 6 of the first slot and in the symbol 2 of the second slot of the sub-frame (Figure 7.13).
Figure 7.13. DMRS associated with SLSS and PSBCH