You can use this section as a kind of dictionary explaining fundamental concept of various signaling components. Topics described here are as follows and more topics will be added.
- Fundamental Information
- Initialization Sequence
- Primary and Secondary Secondary Sync
- Time Sync Process
- Cell ID Detection
- System Informations
- Random Access
- Uplink Data Transmission Scheduling - Persistent Scheduling
Fundamental Information
UE Capability : UE Category, Frequency Band, Sync Signal Sequence, General Radio Resource Info, General MIMO Parameter, Duplex Mode, Preamble sequence generation algorithm
SIM : Network Operator's PLMN list, Subscription Information
Stored Information : Most recently used frequency band, PLMN, Tracking Area Code, Cell ID, S-TMSI, InterRAT Frequency Band
Information that UE needs to get: Frequency and Timing Synchronization info, System Bandwidth, Number of MIMO Antennas, Identities (C-RNTI, Physical Cell ID, Tracking Area Code), Network PLMN, Signaling & Traffic Radio Resouce, RACH_ROOT_SEQUENCE & PRACH Config.
Initialization Sequence
i) Power-Up Test
ii) Frequency & Time and Frame Synchronization
iii) Decode System Information Message
iv) Select Prefered Network
v) Perform RACH Process
vi) RRC Connection Setup
Frequency Aquisition
i) Search the center frequency by searching DC part
ii) Decode BCH which occupies 62 subcarriers (6 RBs) at the center frequency.
iii) BCH tells the frequency information of the system (eg. System Frequency Bandwidth)
Primary and Secondary Secondary Sync
i) Each cell transmit one of 162 unique sequences on its secondary sync channel (each bit sequence is 62 bit sequence)
ii) The seconday Sync code is one of three unique sequence (62 bit Zadd-off chu sequence) which is carried by Primay Sync
iii) So total number of ID become 162 x 3 = 504
Time Sync Process
i) UE decode Primary sync with three different Primary Sync Sequence and figure out which sequence is assigned for the cell and abtain the primary time sync as well.
ii) Apply the primary sync sequence with the Secondary Sync code and figure out which sequence is assigned for the cell.
This Sync detection is done every 5 ms. (You will understand this time interval if you look at the LTE Downlink frame structure explained at http://jaekuryu.blogspot.com/2010/01/first-thing-you-have-to-be-familiar.html)
As I mentioned in previous section, three different sequences are used as the primary sync signal and there is a one-to-one mapping between each of the three sequences and the cell ID within the cell identity group. After a UE detect this cell-identity group, it can determine the frame timing. From this cell identity group, the UE also figure out which pseudo-random sequence is used for generating the reference signal in the cell.
Cell ID Detection and System Information Detection
i) Frequency Aquisition
ii) Primary Sync Signal Aquisition (Slot Timing Aquired, Secondary Sync Signal Scrambling Code Aquired)
iii) Secondary Sync Signal Aquisition (Frame timing Aquired, Cell Group ID sequence aquired)
iv) with PSS and SSS, Cell ID can be calculated
v) with Cell ID, Reference Signal Location is detected
vi) If Reference Signal Location is properly decoded, PBCH (MIB) can be detected
vii) From MIB, SFN and System BW can be detected
viii) Decode PCFICH and detect how many symbols are allocated for PDCCH.
ix) Decode DCI for SIB1 from PDCCH
x) Decode SIB1 and get the scheduling information for other SIBs
xi) Decode SIBs (other than SIB1)
One of the most important step for testing/troubleshooting around the initial registration is to check whether UE successfully complete the time-sync (step i) and ii)), but it is very hard to check this step with any kind of equipment. One way to easily check whether UE succeeded in time-sync or not is to check from UE log whether UE successfuly decoded Cell ID or not. If UE successfully detected Cell ID, it means UE successfully completed the time-sync.
System Information
MIB
i) DL Bandwidth, Number of Transmit Antenna, Reference Signal Transmit Power
ii) System Frame Number (SFN)
iii) PHICH Configurationiv) Transmit every 40 ms , repeat every 10 ms
MasterInformationBlock ::= SEQUENCE {
dl-Bandwidth ENUMERATED { n6, n15, n25, n50, n75, n100},
phich-Config PHICH-Config,
systemFrameNumber BIT STRING (SIZE (8)),
spare BIT STRING (SIZE (10))
}
SIB 1
i) Cell Access Related Information - PLMN Identity List, PLMN Identity, TA Code, Cell identity & Cell Status
ii) Cell Selection Information - Minimum Receiver Level
iii) Scheduling Information - SI message type & Periodicity, SIB mapping Info, SI Window length
SIB 2
i) Access Barring Information - Access Probability factor, Access Class Baring List, Access Class Baring Time
ii) Semi static Common Channel Configuration - Random Access Parameter, PRACH Configuration
iii) UL frequency Information - UL EARFCN, UL Bandwidth, additional emmission
Random Access
Random Access process plays two main roles - establishment of uplink synchronization and establishment of a unique UE ID (C-RNTI) known to both the network and the UE.So Random Access is used not only for initial access, but also after periods of uplink inactivity when uplink sync got lost in LTE_ACTIVE states.
i) UE initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH).(The location of RACH in the frequency/time resource grid the RACH is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity)
ii) Network sends a Random Access Response Message(RARM) at a time and location on the Physical Downlink Shared Channel (PDSCH) (The time and location of RARM on PDSCH can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment)
iii) The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network
Only the step i) uses physical-layer processing specifically designed for random access. The remaining steps utilizes the same physical layer processing as used for normal uplink and downlink data transmission.
For further details of Random Access process, refer to http://jaekuryu.blogspot.com/2010/01/understand-rach.html
Uplink Data Transmission Scheduling - Persistent Scheduling
There are a couple of Data Transmission Scheduling Scheme in LTE. The most simple in terms of algorithm would be the persisent scheduling. In this scheduling mode, Network send 'Grant' in DCI Format 0 for every one subframe.
i) Network send the first data on DL PDSCH and PDCCH which has DCI format 1 for DL Data Decoding and DCI format 0 for UL Grant. (If there is no downlink data to be transmitted, network transmits only DPCCH with DCI format 0 without any DPSCH data)
ii) UE decode PCFICH to figure CFI value.
iii) UE decode PDCCH and get the information on DCI format 1
iv) Based on DCI format 1, UE decode DL data.
v) UE decode the information on DCI format 0 from PDCCH
vi) UE send ACK/NAK for DL data through UCI (UCI will be carried by PUCCH)
vii) UE check the Grant field.
viii) If Grant is allowed, UE transmit the uplink data through PUSCH
ix) Network decode PUSCH data and send ACK/NACK via PHICH
x) UE decode PHICH and retransmit the data if PHICH carries NACK
For detailed data structure of DCI Format 0, refer to TS 36.212 section "5.3.3.1.1 Format 0"
The process listed above is in reality a pretty complicated process and need a lot of troubleshoot and debugging. So in case of development and testing phase, we normally break down this process into multiple simple/small procedure and verifies it step by step.
Step 1 : DL data reception and no ACK/NACK transmission ==
a) Network send PDCCH and PDSCH data
b) See if UE properly decode PDSCH data
This would seem to be very simple two step process, but to make this happen UE is capable of doing step ii), iii), iv) described above.
Step 2 : DCI format 0 reception ==
a) Network send DCI Format 0(UL Grant) without PDSCH transmission
b) See if UE properly decode DCI Format 0 (You need to make it sure that Resource allocation that UE decoded matches with DCI format 0 sent by network.)
Step 3 : PUSCH transmission based on DCI format 0 ==
a) Network send DCI Format 0(UL Grant) without PDSCH transmission
b) UE transmit UL Data on PUSCH
c) Network decode PUSCH data
d) see if the data decoded at Network side maches what UE transmit
To make this happen, UL DMRS for PUSCH should have been properly implemented and you have to make it sure that UE transmit the PUSCH data on the RBs that DCI format 0 specified.
Step 4 : DL data reception and ACK/NACK transmission ==
a) Network send PDCCH and PDSCH data
b) UE decode PDSCH data
c) UE has to transmit ACK/NACK accordingly
Step 5 : UL data transmission and ACK/NACK reception ==
a) Network send DCI Format 0(UL Grant) without PDSCH transmission
b) UE transmit UL Data on PUSCH
c) Network decode PUSCH data
d) Network send ACK/NACK on PHICH
e) UE has to decode ACK/NACK properly
f) UE has to retransmit the data if it gets NACK
Decoding Uplink Signal
'Decoding Uplink Singal' means 'decoding PUCCH and PUSCH'. But eNode be normally get Uplink signal from multiple UEs and each of the UE may be in different distance and under different channel condition. So docoding uplink channel would not be easy. To help eNode be decode these uplink channel, UE transmit a reference signal.
There are a few different uplink signal as listed below.
i) DMRS (DeModulation Reference Signal) for PUCCH
ii) DMRS (DeModulation Reference Signal) for PUSCH
iii) Sounding Reference Signal.
Item iii) would not be a mandatory component, but UE must send item i) and ii). Otherwise, eNodeB fail to decode PUCCH or PUSCH even though UE transmit it in proper format.
Detailed implementation of UL reference signal is described in TS 36.211 section 5.5 and TS 36.213. You will notice a lot of parameters are involved in UL reference signal generation and the following is brief list of these parameters.
* n_1_pucch : N(1)PUCCH described in 3GPP TS36.213
* GroupHopping : 5.5.1.3 in TS36.211
* Cell ID :
* Pucch format : 5.5 in TS36.211
* N_1_CS :
* N_2_RB :
* delta Pucch shift :
* RNTI :
* UL CP Configuration :
* systemBW :
* u_even : sequence-group number even slot (TS36.211 5.5.1.3)
* u_odd : sequence-group number odd slot (TS36.211 5.5.1.3)
* n_cs_even#0~#6 : Cyclic Shift for even slot in a subframe (TS36.211 5.4.1, 5.5.2.2.1)
* n_cs_odd#0~#6 : Cyclic Shift for odd slot in a subframe (TS36.211 5.4.1, 5.5.2.2.1)
* n_oc_bar_even : orthogonal sequence for even slot in a subframe (TS36.211 5.5.2.2.1)
* n_oc_bar_odd : orthogonal sequence for odd slot in a subframe (TS36.211 5.5.2.2.1)
* n_oc_even : orthogonal sequence for even slot in a subframe (TS36.211 5.4.1)
* n_oc_odd : orthogonal sequence for odd slot in a subframe (TS36.211 5.4.1)
* n_PRB_even : Physical resource block number for even slot in a subframe (TS36.211 5.4.3)
* n_PRB_odd : Physical resource block number for odd slot in a subframe (TS36.211 5.4.3)
As you notice, quite a lot of parameters are involved and it is not easy to understand all of these in detail, but at the initial phase of chipset development or when you try to duplicate live network environment with network simulator you have to make it sure that all of these parameters are properly setup not only in UE but also in network simulator.
Can UE set these parameters arbitrarily whatever it likes to do ? No.. in that case eNode B would not know how to detect the reference signal and in result eNode B would not be able to decode PUCCH/PUSCH. Then how UE can know which value it has to use for Uplink Reference Signal Creation ?
The most critical information on UL Reference Signal is tranmitted by SIB2 message as follows :
* radioResourceConfigCommon.pucch_ConfigCommon.deltaPUCCH_Shift
* radioResourceConfigCommon.pucch_ConfigCommon.nRB_CQI
* radioResourceConfigCommon.pucch_ConfigCommon.nCS_AN
* radioResourceConfigCommon.pucch_ConfigCommon.n1PUCCH_AN
