Device to Device contributions to

OAI

OAI workshop: 25-27/06/2019

Overview of this presentation

Background

Objectives

On/Off-net D2D extensions and RF testbed

UE to network Relay extensions and RF testbed

Next steps

(c) Eurecom 2018

Background

OAI sidelink work is done in the context of the DDPS project – USA NIST project framework program (PSISP)

– Aims to promote LTE technologies for public-safety network, including ProSe Sidelink (PC5) technology demonstrators

– Project coordinator: PerspectaLabs (New Jersey), Dr. Richard C. Lau

– Team members at PerspectaLabs

William Johnson

Heechang Kim

Stephanie Demers

James Hodge

Eric Beck

– Team members at EURECOM

Raymond Knopp

Jerome Haerri

Panagiotis Matzakos

Tien-Thinh Nguyen

Mohit Vyas

(c) Eurecom 2018

LTE D2D application scope

28/06/2019 - - p 4

2015

Rel-12

2016 2017

Rel-13

Rel-14

Proximity

services: LTE-

D2D

ProSE

Extensions:

D2D relaying

LTE-V2X

communication

extensions

Public safety: Group Communication + proximity services

Mode 1:

Resource allocation from

the eNB

Mode 2:

autonomous resource

allocation (preconf. resource pools)

Mode 1 (On-net UE)

+ Mode 2 (off-net UE)

• Replacing old technologies (e.g. TETRA) for public safety authorities

• Direct communication (multicast/unicast)

• Direct discovery supporting unicast • Objective: Availability when cellular

networks are not available or fail (e.g., disaster after earthquake)

• Finding friends nearby, local-advertising, e-health etc.)

• Direct communication + Discovery

Proximity commercial applications

OAI D2D Objectives

Interfaces for ProSe applications in UE

Integration of Rel 14 Sidelink procedures (L1/L2)

Extensions to support UE-Network relaying scenarios

Testing – ProSe application from Perspecta Labs (not public)

– Public D2D application available for individual testing of PC5 features: multicast traffic, discovery, 1-to-1 connection establishment and Unicast traffic, Relay traffic.

– Small field deployment with OAI-based UEs and Infrastructure

Off-network and relay coverage scenarios

(c) Eurecom 2018

Side link, SC-FMDA, FDDCellular LTE

in-networkProSe (PC5)

Off-networkProSe (PC5)

Partial-in-networkProSe (PC5) eNB

ProSe Function

EPCS1

PC3

Uu

UE-Network Relay

PC4PC2

ProSeAppl Server

D2D Scenarios

off-network coverage

– PC5 interface

on-network coverage

– Regular LTE Iu-interface communications

partial coverage.

– UE-to-network relay procedures

New Communication modes support

– one-to-one

– one-to-many direct communication.

(c) Eurecom 2018

ProSe Controller

UE ip . ko

Kernel Module

PDCP

RLC

MAC

L 1

PDCP

RLC

MAC

RRC

RRC

eNodeB PC

5 - U

PC

5 - S

RRC

Control socket

(including PC5-D)

drb

slrb

lcid lcid

slrb

drb - config , logical

channel config

rnti rnti

User Interface

OAI Architecture for ProSe Interfaces

PDCP

RLC

MAC

lcid

drb

rnti

Configuration files

slrb

PC

3

PC5-C

Remote UE

UE (in/out UTRAN)

PC5-D

PC5-D: Dedicated to direct discovery: • Discovery allows a UE to discover other UEs

that are in proximity. • The ProSe Protocol interacts directly with the

MAC layer.

PC5-S: Dedicated to control plane signaling • Establish, maintain, and

release a secure direct link between two UEs.

PC5-U: Dedicated to user plane direct traffic between two

UEs.

• UEs can establish multiple logical channels. A logical

channel ID (LCID) included uniquely identifies a

logical channel within the scope of one Source Layer-

2 ID and ProSe Layer-2 Group ID combination

• The IP tables are responsible for IP to sidelink radio

bearer (SLRB) mapping.

• UE_ip.ko kernel routing module uses the information

provided by the IP tables in order to route each ProSe

flow to the right SLRB.

DDPS ProSe App & OAI Software Architecture

(c) Eurecom 2018

L1/L2 extensions in OAI for sidelink

28/06/2019 - - p 9

Sidelink

Control

Info

Implemented synchronization

channels and procedures of synch-

ref. UE and non-synch. Ref. UE in

off-net and relay scenarios

Carrying Control plane scheduling information

for SLSCH transmission opportunities in the

next SLSCH period. Indicate the format of the

subsequent SLSCH destined to other UEs

Carrying user-plane (PC5-U) and control-

plane (PC5-S) traffic from ProSe Application.

Carrying discovery information from ProSe

Application. Discovery signals are to be

transmitted in particular subframes

(periodically)

Resource allocation in OAI [Off-network]

Resource allocation based on preconfigured

resource pools – Communicated through SCI to the receiver UE(s).

– Static allocation; no scheduling intelligence integrated at this point.

First LCID (source-destination pair) with available traffic is scheduled, others

are postponed.

Future Extension: allowing for scheduling more than one source/destination

pairs AND to choose the right pair if there are more than one.

28/06/2019 - - p 10

Resource allocation in OAI [On-network]

Resource allocation provided by the eNB instead of using

preconfigured resource pools at the UEs as in the off-network case. – UE in RRC_IDLE state: List of Tx/Rx Resource pools (RPs) through SIB18 (for Direct

communication), SIB19 (for Discovery). UEs select the specific resources for Tx out of the list of Tx RPs.

– UE in RRC_CONNECTED state: RPs through RRCConnectionReconfiguration, Dedicated resource allocation for Sidelink through DCI Format 5 (for Direct communication),

28/06/2019 - - p 11

SIB18/19/21(V2X)

EUTRAN UE

RRCConnectionReconfiguration

SidelinkUEInformation

Sidelink Scheduling Request (PUCCH) +

Buffer Status Report (MAC Control Element, UL-SCH)

Scheduling grant through

DCI Format 5 (PDCCH)

RP indicator when the UE is in RRC Idle state.

UE indicates its interest in

Tx/Rx of sidelink communication.

RP indicator for UEs in RRC

Connected state; Providing Dedicated resource allocation for Direct

Discovery.

UE indicating to eNB it has data to

Tx on SL

Already integrated in OAI

Not yet integrated in OAI to support dedicated resource allocation in RRC_CONNECTED

state.

Specific resource allocation for the transmission of Sidelink Control Info

and Sidelink Data

Testing D2D off-net scenario in OAI RF testbed

Multicast and Unicast scenarios in Mode2 (off-net)

– UE node: NUC PC (8 CPU-core, 8GB RAM) connected with USRP B200-mini

– Operating at 763 MHz; 10 MHz Bandwidth

– USRPs currently connected with external signal generator or octoclock with

external frequency reference to get synchronized

Alternative: Use GPS-disciplined oscillator modules placed on top of USRP

B210 USRPs

– Current experiment with up to 3 nodes

28/06/2019 -

Extensions to support traffic relaying

Network level extensions and relay supporting configuration

– Modifications at the kernel network driver which is dedicated to the instantiation

of virtual IP interfaces for OAI and handling of incoming/outgoing sidelink and

uplink/downlink IP traffic.

Extensions in main OAI RAN stack and the interfaces with the RF USRP B210 devices

– Capability to handle SL and UL/DL control plane and data plane traffic

concurrently

Extensions at the UE NAS layer and the Core Network to integrate the

relay functionality signaling

– Work in progress…

(c) Eurecom 2018

Network level extensions and relay supporting

configuration

(c) Eurecom 2018

Route Internet traffic through the IP interface

dedicated to sidelink (PC5) of the remote UE

E.g. ping –I oip0 8.8.8.8

Forward the traffic from the sidelink to UL/DL dedicated IP interface and through the DRB

Remote UE’s traffic is masked as relay UE traffic at the relay UE, using its

own PDN connection to get routed through the core

network which is currently agnostic of the remote UE

Relay support: Extensions at the interfaces

with the USRP B210 devices and OAI RAN

Extensions at the interfacing level between OAI and the USRP devices

through USB 3.0 buses, using the corresponding UHD APIs from ETTUS

Extensions at OAI RAN stack to harmonize co-existence of UL, DL and SL

in RF mode, using the existing UE threads in OAI implementation.

(c) Eurecom 2018

Extensions at the UE NAS layer and the Core

Network

(c) Eurecom 2018

Rel.14

24.301,

29.274,

36.413

Code availability and target extensions

Code available at LTE-sidelink branch of public OAI-RAN repository

Public testing application available here – https://gitlab.eurecom.fr/tien-thinh.nguyen/d2d-l3-stub

Shorter term – Merge with develop branch

– Apply power control at the UE sidelink side to avoid interference with UL when operating in relay mode

– Finalize extensions required at UE NAS and core network to support relaying operations properly (according to 3gpp Rel.14)

– Extend publicly available application: Unify individual PC5 testing procedures, more user friendly (GUI etc.)

Longer term – Integrate dedicated resource allocation procedures for Mode 1

– RAN extensions to support modes 3 and 4 (LTE-V2X)

PHY extensions, scheduling algorithms

– Implementation of V2X application similar to ProSe App.

(c) Eurecom 2018

THANK YOU!

28/06/2019 - - p 18

Backup slides

(c) Eurecom 2018

Testing D2D in OAI [emulation]

In parallel with the sidelink integration activities, OAI was

extended with new emulation capabilities for both sidelink and

UL/DL scopes

– MAC-to-MAC emulation mode bypassing completely PHY procedures

– Emulation mode which simulates PHY sidelink procedures

Objectives:

– Facilitate parallel work in different layers (PHY vs MAC,RRC,RLC,

PDCP)

– Facilitate testing by isolating PHY problems from the rest of the stack

Tested scenarios in emulation

– Off-net multicast/Unicast

– First relay scenarios

28/06/2019 - - p 20

Overall L2 emulation architecture for UE<->UE

eNB<->UE scopes

28/06/2019 - - p 21

MAC-to-MAC emulations: UE<->UE emulation

mode 2

28/06/2019 - - p 22

SL

PHY

Stub

UE

SL

PHY

Stub

UE

UE

Sidelink

MAC

UE

Sidelink

MAC

Unicast/Multicast

PC5-U (data plane),

PC5-D (Discovery),

PC5-S (Signaling)

Unicast/Multicast

PC5-U (data plane),

PC5-D (Discovery),

PC5-S (Signaling)

SCI Rx

SLSCH/ SLDCH payloads

SLSCH/ SLDCH payloads

SCI Tx timings

Transmitting UE Receiving UE

PHY emulation procedures

Rx Channel

simulation

Determine the right timings for transmission

of SCI and SLSCH

Emulate PHY for reception of SCI and

based on SCI determine the subframes for

SLSCH/SLDCH reception

Socket

Interface

over

Ethernet

Testing D2D in OAI [RF testbed (prototype)]

First Relay scenarios (on-net [Mode1] + off-net UE [Mode2 ]) to

be launched by beginning of December

– On-net UE: NUC PC connected with 2xB200 USRPs (one dedicated to

LTE-Uu interface with eNB and the other dedicated to sidelink PC5

interface)

– Off-net UE: NUC PC connected with USRP B200-mini RF front-end

– eNB: NUC PC connected with USRP B200-mini RF front-end

– OAI-CN entities (HSS, MME, SPGW) in a separate machine

28/06/2019 - - p 23

L1 features

PC5 Synchronization

– Implementation of SynchRef UE (SPSS,SSSS,PSBCH)

– Implementation of synchronization and tracking procedures for

off-network UEs

PC5

– Implementation of TX/RX procedures for PSSCH/PSCCH

(c) Eurecom 2018

Integration Testbed

(c) Eurecom 2018

Overview of L1 implementation

Synchronization channels and procedures

Sidelink Discovery Channel and procedures

Sidelink Shared Channel / Control Channel and

procedures

Section 14 36.211, XX 212, XX 213

(c) Eurecom 2018

Threading model

Top-level threads in – targets/RT/USER/lte-ue.c

void *UE_thread(void *arg) => main thread for

DL/UL

void *UE_threadSL(void *arg) => main thread for

SL

void *UE_thread_rxn_txnp4() => main L1 thread,

woken up by both threads (above)

Void *UE_thread_synch(void *arg) => L1 DL synch

thread

void *UE_thread_synchSL(void *arg) => L1 SL

synch thread (non SynchRef UE)

(c) Eurecom 2018

Basic states of UE

Not synched

Synched to DL (found an eNodeB)

Synched to SL (found a SynchRef UE)

DL/UL steady-state (in steady-state RX/TX mode for

DL/UL)

SL Steady-state (in steady-state RX/TX mode for SL)

Some SL-related configuration variables

– UE->sidelink_active : indicator that sidelink is active

– UE->is_synch_ref : indicator that UE is a synchRef UE

– UE->SLonly : indicator that UE does SL only (i.e. doesn’t look for

eNodeB)

– UE = PHY_VARS_UE context structure (c) Eurecom 2018

Flow in UE_threadSL

1. If not synchronized (from DL or SL) and not a SynchRef UE

• If (sidelink_only) do SL synchronization

• Loop

• acquire 40 ms of signal

• If not busy, wake up UE_thread_synchSL, else skip

2. Else if synchronized

– If not yet steady-state

Read N samples, N derived from initial synchronization

Go to steady state mode

– Else we are steady-state

Loop over subframes

If (subframe == 9) do timing adjustments if needed (drift)

Read 10ms+-drift of signal from RF device for subframe n

Write 10ms+-drfit of signal to RF device for subframe n+2

Wakeup rxtx thread (via cond_rxtx)

(c) Eurecom 2018

Flow in UE_thread_synchSL

loop

1. Wait on cond_synchSL

2. Call initial_syncSL(UE)

found in openair1/PHY/LTE_TRANSPORT/initial_syncSL.c

Details later

3. If synch is found

Change state of UE, store timing offset

Other protocol aspects handled in initial_synchSL

Calling the RRC to initialize

=> calling MAC to configure the SL

information

(c) Eurecom 2018

Flow in UE_thread_rxn_txnp4

Loop

– Wait for cond_rxtx

– If UE->SLonly ==0

Do regular LTE DL/UL procedures (not described here)

– If UE->SLactive ==1

Call phy_procedures_UE_SL_RX(UE,proc)

Entry level routine for SL reception procedures (detailed later)

If UE->SLonly ==1

call ue_scheduler()

Entry level routine for L2 TX protocol stack (generate SL

information flows), for connected mode, it is called with the

UL component earlier.

Call phy_procedures_UE_SL_TX(UE,proc)

Entry level routine for SL transmission procedures (detailed

later)

(c) Eurecom 2018

Sidelink Transmission procedures

phy_procedures_UE_SL_TX(UE,proc) – In openair1/SCHED/phy_procedures_lte_ue.c 1. Initialize TX signal to zero

2. if (ue->is_SynchRef == 1)

check for SLBCH (MIB) from stack ue_get_slss()

Entry level routine for L2 stack, get MIB information from RRC

Returns configuration and payload for SLBCH/SLSSS/SLPSS

check_and_generate_slss()

Checks if synchronization signals are to be transmitted or not

3. If SLDCH is not active Check SLDCH from stack ue_get_sldch()

Entry level routine for L2 stack, get SLDCH information from ProSe Application

Returns configuration and payload for SLDCH

4. If SLDCH is active (i.e. received a packet/config) Check and generate SLDCH

Call check_and_generate_psdch(ue,frame_tx,subframe_tx)

5. If SLSCH data is available from L2 (non-NULL return from ue_get_slsch() Check for SLCCH

(check_and_generate_pscch(ue,frame_tx,subframe_tx)) Check for SLSCH

(check_and_generate_pssch(ue,frame_tx,subframe_tx)) 6. If UE->SLonly == 1, do common procedures (OFDM/SC-FDMA modulation and 7.5 kHz

frequency offset)

(c) Eurecom 2018

Sidelink Reception Procedures

phy_procedures_UE_SL_RX(UE,proc)

– In openair1/SCHED/phy_procedures_lte_ue.c

1. Set proc->sl_fep_done to zero => indicates that Sidelink front-end processing (7.5 kHz freq offset and FFTs) is not done. This will get set to 1 by the first successful call to a physical channel reception below (i.e. PSBCH,PSDCH,PSCCH,PSSCH)

2. If UE is not synchRef and this is a PSBCH subframe, call rx_psbch (in openair1/PHY/LTE_TRANSPORT/slbch.c, later) => note, for the moment the PSBCH is assumed to be in frame%40 = 0, subframe = 0

3. Call rx_psdch (in openair1/PHY/LTE_TRANSPORT/sldch.c). Note that this routine checks internally if the subframe is a PSDCH subframe and returns otherwise

4. Lock slsch_rx_mutex. Current UE RX procedure is running in two parallel threads (two subframes in parallel), this lock prevents two threads from accessing slsch structures concurrently which will not work for SLSCH. In regular LTE, adjacent subframes are for different HARQ processes and have mutually exclusive contexts. Adjacent subframes are repetitions of the same SLSCH and cannot be executed concurrently.

5. call rx_pscch (in openair1/PHY/LTE_TRANSPORT/slsch.c). This executes SLCCH processing if the frame/subframe is in the PSCCH period. Otherwise it just returns. This function returns the configuration of SLSCH allocations.

6. Call rx_pssch (in openair1/PHY/LTE_TRANSPORT/slsch.c). If the PSSCH reception was programmed during the PSCCH period (i.e. we received an SCI which allocated this) or (later) if a format 5 DCI was received to schedule the SL transmissions.

7. Unlock slsch_rx_mutex

(c) Eurecom 2018

Generation of Synchronization Channels

(SynchRef UE)

Generation of – PSS : primary synchronization signal

– SSS : secondary synchronization signal – SLBCH : Sidelink broadcast channel

– DMRS for SLBCH : demodulation reference signal for SLBCH

All generation in – openair1/PHY/LTE_TRANSPORT/slss.c

– void check_and_generate_slss(PHY_VARS_UE *ue,int frame_tx,int subframe_tx) is responsible for checking if the synchronization signals are to be transmitted in a particular subframe and sequentially generates the 4 signals

generate_slpss : generates one symbol of PSS (called twice)

generate_slsss : generates one symbol of SSS (called twice)

generate_slbch : generates the SLBCH

generate_drs_pusch : generates the DMRS for SLBCH

(c) Eurecom 2018

Generation of Synchronization Channels

(SynchRef UE)

SLSS descriptor : SLSS_t

– From openair1/PHY/TRANSPORT/defs.h

– typedef struct {

/// SL-OffsetIndicator (0-10239)

uint32_t SL_OffsetIndicator;

uint16_t slss_id;

uint8_t slmib_length;

uint8_t slmib[5];

} SLSS_t;

(c) Eurecom 2018

Reception of SLSS (unsynchronized)

int initial_syncSL(PHY_VARS_UE *ue) – lte_sync_timeSL

in PHY/LTE_ESTIMATION/lte_sync_time.c

Returns non-negative timing offset if non-coherent correlation with PSS sequence is above threshold

– rx_slsss

in PHY/LTE_TRANSPORT/slsss.c

Channel estimation based on PSS

Quasi-Coherent demodulation (residual frequency offset compensation) of SSS sequence

Output is hypothesized SLSS_id – rx_psbch

in PHY/LTE_TRANSPORT/slbch.c

Channel estimation based on DMRS

Coherent demodulation/decoding/CRC-check of PSBCH

If CRC is positive => Transmission of MIB-SL to higher-layers ue_decode_si

Returns configuration of SLSS parameters Frame/subframe of SLBCH

(c) Eurecom 2018

Transmission of SLDCH

SLDCH = Sidelink Discovery Channel – SLDCH : holds discovery information from ProSe Application

– DMRS for SLDCH : demodulation reference signal for SLDCH

All generation in – openair1/PHY/LTE_TRANSPORT/sldch.c

– void check_and_generate_psdch(PHY_VARS_UE

*ue,int frame_tx,int subframe_tx) is responsible for checking if the discovery signal is to be transmitted in a particular subframe

Computes physical resources to be used (based on SLDCH_t data structure received from MAC)

calls sldch_codingmodulation()which performs

dlsch_encoding (regular LTE DL coding chain)

ulsch_modulation (regular LTE UL modulation chain)

generate_drs_pusch : generates the DMRS for SLDCH

(c) Eurecom 2018

SLDCH Generation

SLDCH descriptor : SLDCH_t typedef struct { // SL Discovery Configuration

/// Discovery Type

SLD_t type;

/// Number of SL resource blocks (1-100)

uint32_t N_SL_RB;

/// prb-start (0-99)

uint32_t prb_Start;

/// prb-End (0-99)

uint32_t prb_End;

/// SL-OffsetIndicator (0-10239)

uint32_t offsetIndicator;

/// SL-Discovery Period

uint32_t discPeriod;

/// Number of Repetitions (N_R)

uint32_t numRepetitions;

/// Number of retransmissions (numRetx-r12)

uint32_t numRetx;

(c) Eurecom 2018

SLDCH Generation

SLDCH descriptor : SLDCH_t /// PSDCH subframe bitmap (up to 100 bits, first 64)

uint64_t bitmap1;

/// PSDCH subframe bitmap (up to 100 bits, second 36)

uint64_t bitmap2;

/// Bitmap length (N_B) (valid values (4,8,12,16,30,40,42) Rel12, (16,20,100) Rel14

uint32_t bitmap_length;

/// N1_PSDCH (a-r12)

uint32_t N1;

/// N1_PSDCH (b-r12)

uint32_t N2;

/// N1_PSDCH (c-r12)

uint32_t N3;

/// a10 (discPRB-Index)

uint32_t a10;

/// b10 (discSF-Index)

uint32_t b10;

/// transmission index (j)

uint32_t j;

/// Discovery resource

uint32_t n_psdch;

/// payload length

int payload_length;

uint8_t payload[100];

} SLDCH_t;

(c) Eurecom 2018

SLDCH Reception

void rx_sldch(PHY_VARS_UE *ue,UE_rxtx_proc_t *proc, int frame_rx,int subframe_rx)

– Top-level routine for receiving SLDCH

Checks if SLDCH is potentially active in this subframe

Loops over all possible SLDCH resources Attempts demodulation and decoding

sldch_decoding()which performs

ulsch demodulation ofdm demodulation (if not done for another channel)

Resource element extraction from candidate PRBs Channel estimation based on DMRS

Frequency-domain equalization (MMSE) Inverse Fourier transform

LLR generation Unscrambling + deinterleaving

dlsch decoding Upon positive CRC

ue_send_sl_sdu

Send discovery channel payload to Layer 2

(c) Eurecom 2018

SLSCH/SLCCH Generation

SLSCH = Sidelink Shared Channel – SLSCH : holds user-plane (PC5-U) and control-plane (PC5-S) information from ProSe

Application It receives its configuration either from the SLCCH preceding it (if generated for off-

network self-scheduled transmission) or from format 5/5A DCI generated by the eNodeB

– SLCCH : holds control plane scheduling information for SLSCH transmission opportunities in the next SLSCH period. Used only for off-network traffic scheduling to indicate the format of the subsequent SLSCH destined to other UEs

– DMRS for SLCCH/SLSCH : demodulation reference signal for SLCCH/SLSCH

Recall Entry level to Layer 2 is call to ue_get_slsch() – In openair2/LAYER2/MAC/ue_procedures.c

– This invokes the MAC layer to look for a new transmission opportunity on the sidelink either Self-scheduled Scheduled by eNodeB on DCI5/5A

– ue_get_slsch() operations (off-network case only for now)

1. Check if this is the first subframe of PSCCH period, check for data and generate SCI For each possible LCID (source/destination pair) call mac_rlc_status_ind to check

for backlogged data in RLC queues for the logical channel

the first LCID with available traffic is scheduled, others are postponed. This will have to be changed to allow for scheduling more than one source/destination pair AND to choose the right pair if there are more than one. This will be when we enhance the D2D scheduling algorithm.

generate SLSCH_t descriptor for SLSCH period

(c) Eurecom 2018

SLSCH/SLCCH Generation

Current (simple) scheduling slsch->ljmod10 = 9; // note this will cause ljmod10 to be reset for

first transmission of SLSCH

slsch->rvidx = 1;

slsch->RB_start = RB_start;

slsch->L_CRBs = L_CRBs;

// fill in SCI fields

slsch->n_pscch = ue->sourceL2Id;

slsch->format = 0;

slsch->freq_hopping_flag = 0;

slsch->resource_block_coding = computeRIV(slsch->N_SL_RB_data,

RB_start,

L_CRBs);

slsch->time_resource_pattern = 106; // all subframes for Nrp=8

slsch->mcs = mcs;

slsch->timing_advance_indication = 0;

slsch->group_destination_id = ue->destinationL2Id&0xff;

slsch->payload_length = 0;

(c) Eurecom 2018

SLSCH/SLCCH Generation

2. If SLSCH is active and we are no longer in the SLCCH period

• If subframe is not allocated to SLSCH return • Increment lj modulo 10. This is a counter used for scrambling

and DMRS generation (every subsequent Sidelink subframe modulo 10 has a different seed)

• Increment rv_idx according to 3GPP sequence (0,2,3,1,0,2,3,1 …). SLSCH SDU is repeated 4 times by Layer 1 using a different redundancy version each time.

• If rv_idx is not 0 (i.e. first transmission of a new transport block) and TX is active return (i.e. retransmission so just return with new rv_idx)

• rv_idx is 0 so check if we have data • Compute TBS: int TBS = get_TBS_UL(mcs,L_CRBs);

• Ask RLC for TBS bytes : sdu_length = mac_rlc_data_req(…)

• If sdu_length > 0

• Build MAC header according to length (greater or smaller than 128 bytes)

• Return non-null pointer to SLSCH descriptor

(c) Eurecom 2018

SLSCH/SLCCH Generation

Upon positive return from ue_get_slsch (i.e. non-NULL pointer) all generation in – openair1/PHY/LTE_TRANSPORT/slsch.c

– void check_and_generate_pscch(PHY_VARS_UE *ue,int frame_tx,int subframe_tx) is responsible for checking if the PSCCH signal is to be transmitted in a particular subframe

Computes physical resources to be used (based on SLSCH_t data structure received from MAC)

Compute time/frequency position of PSCCH signal components based on subframe_tx and slsch->n_pscch (parameters a1,a2,b1,b2 from 36.213)

If subframe has a PSCCH component call pscch_codingmodulation()which performs

dci_encoding (regular LTE DL PDCCH coding chain) for the first of 2 PSCCH components (flag to indicate this is ue->pscch_coded).

Interleaving for PUSCH transmission PUSCH transmission is specific to 1 PRB case here

QPSK modulation 12-point DFT precoding (regular LTE UL modulation chain) Call to generate_drs_pusch : generates the DMRS for SLCCH

(specific DMRS parameters for PSCCH) At this point the Frequency-domain signal is generated for the subframe

(c) Eurecom 2018

SLSCH/SLCCH Generation

– void check_and_generate_pssch(PHY_VARS_UE

*ue,UE_rxtx_proc_t *proc,int frame_tx,int

subframe_tx) is responsible for checking if the PSSCH signal is to be transmitted in a particular subframe

if subframe doesn’t hold SLSCH return

else call slsch_codingmodulation(ue,proc,frame_tx,subfr

ame_tx,slsch->ljmod10);

Program DLSCH coding chain (filling dlsch->harq_processes[0] structure with mcs/N_PRBs/etc)

call LTE dlsch_encoding0()

Do PUSCH interleaving and scrambling

Case without PUSCH control information (i.e. no ACK/NAK, no RI, no CSI information))

Program ulsch->harq_processes[0] structure

Call LTE ulsch_modulation()

(c) Eurecom 2018

SLCCH/PSCCH Reception

(c) Eurecom 2018

SLSCH/PSSCH Reception

(c) Eurecom 2018