device to device contributions to oai€¦ · oai d2d objectives interfaces for prose applications...
TRANSCRIPT
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.
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
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
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