5G Interview Questions Answers Part-1

Q01. What is 5G NR? Why it’s need if we have 4G?
Q02. What are the limitations in 4G?
Q03. Explain 5G NR High Level Architecture?
Q04. Explain 5G NR Low Level Architecture?
Q05. What is Dual Connectivity?
Q06. What is MRDC?
Q07. What is ENDC?
Q08. What is NRDC?
Q09. Explain the Interfaces uses in 5G NR Architecture?
Q10. What is gNB? And what’s the use of gNB in 5G NR?
Q11. What is en-gNB? And How’s it different from gNB?
Q12. What is ng-eNB? And How’s it different from en-gnb?
Q13. What is EPC and 5G NRC?
Q14. What is NSA and SA? Name of the Deployment options available in NSA or SA as per 3gpp defined?
Q15. Explain frequency range define in 5G NR?
Q16. What is mmWave? Why it doesn’t it travels far from origin?
Q17. What’s are the Deployment option’s of RAN’s implementation availble in 5G NR.
Q18. What is CU, DU use in 5G NR?
Q19. Name of Interface use between CU and DU?
Q20. What is CU-CP and CU-UP?
Q21. Name of Interface use in CU-CP and CU-UP?
Q22. What do you mean by Class 1 and Class 2 messages?
Q23. Please tell me the Class 1 and Class 2 messages that’s are use in F1AP protocol?
Q24. Explain the protocol structure of 5G NR?
Q25. Please tell me the name of protocol use between UE and R(AN) in 5G NR?

Read More

ANR AND TAU

ANR (Automatic Neighbour Relation)

Actually before understand about ANR we have to clear little bit concept on neighbour cell scenario. What happened is every eNB attached the neighbour cell list inside SIBs. This is operator work to configure these details in system Info So There are two ways that network operator put this details inside the various cells.

1.    Manually configuration: Its done manually by the Operator but here are some issue with it:

a.    First operator need to provide special person to investigate it which is cost effective and also neighbour cells are changes time to time by shifting cells on demand

2.    Automatic configuration : This is technique the eNB are used  for automatic configuration of neighbour cell which is known as Automatic neighbour request. Its a easier way of configuration. Procedure is as follows:

a.    First N/W will send Measurement control Req to UE  for performing the measurement of cell around its geographical area and provide list to N/W that has sent Measurement control Req earlier.

b.    N/W will decode the measurement report and update the neighbouring list according to the received report from UE.

TAU(Tracking Area Update)

TAU is a kind of report which sent by UE to MME at a certain time, whenever the TAC(Tracking Area Code) is changedthan TAU is needed not only that time there is some more condition when its needed.
First the question is How UE get to know that TAC is changed? So our answer is this information is present in a SIB1.
Now second question is when TAU report has to send?
Actually we have something called TAI list which is already has provided by MME to UE at the time of registration. For more information Refer TAI.

       Below I have attached the flow of  TAU procedure:

TAU Procedure flow Diagram

TAU trigger conditions:

1.    Normal TAU is due to mobility i.e when UE enters in Tracking Area which is not included within the list of tracking areas with which the UE has registered.

2.    Periodic TAU after T3412 timer Expires.

3.    Reregistering the EPS after CSFB connection has been completed.

4.    MME load balancing. 

Note 1: It is triggered in both in IDLE and Connected mode, but Suppose UE in connected mode and try to to move to new location, In this UE known to the network and easily handed over to new cell but if UE found that its TAC isn’t part of TAI list now than it will triggered TAU procedure to the MME.

 

Note 2: It doesn’t means UE always be in Connected mode but it can be come again in IDLE mode.Than Suppose if N/W want to send some information to the UE than in this case MME need to know the exact location of UE because might be UE was is moving state in IDLE and doing its cell selection and reselection than here also only extreme procedure which we have is TAU procedure. But as in the above flow diagram we have seen that TAU is piggybacked on rrcconnectionsetupcomplete msg so its a connected mode msg so how this stuff work. So The perfect answer is UE can begin the TAU procedure in IDLE mode but UE must be in RRC Connected mode to actually complete the procedure.

 

Read More

5G PUCCH and 5G PUSCH

5G PUCCH and 5G PUSCH

PUCCH is used to carry Uplink Control Information (UCI), and following types of UCI are supported in NR:

·         Hybrid automatic repeat request acknowledgement (HARQ-ACK): information to report whether the DL transmission of a TB is successful or not

·         Scheduling request (SR): signal to request UL grant to gNB

·         Channel state information (CSI): information represents channel condition between gNB and UE

The UCI can be carried by PUCCH or PUSCH. The channel coding schemes for different UCI sizes are shown in Table.

Channel coding for uplink control information (UCI)

UCI size including CRC, if present	Channel code
1	Repetition code
2	Simplex code
3-11	Reed Muller code
>11	Polar code

1. For HARQ-ACK feedback of PDSCH with corresponding DCI, PUCCH resource set(s) containing one or more PUCCH resources are configured.
2. One PUCCH resource is determined based on the UCI payload size and the PUCCH resource indicator field in the DL assignment. For HARQ-ACK feedback of PDSCH without corresponding DCI, SR, and CSI report, a PUCCH resource is configured for each.
3. When multiple PUCCHs are overlapped fully or partially in time, the UCIs are multiplexed in a PUCCH.
4. When a PUCCH is overlapped with a PUSCH fully or partially in time, the UCI is multiplexed (i.e. piggybacked) on the PUSCH.
5. Each PUCCH resource is configured with a PUCCH format. Various PUCCH formats are specified as in Figure.
6. Each PUCCH format supports either durations of 1 to 2 symbols, or durations of 4 to 14 symbols.
7. PUCCH formats 0/2 are called as short-PUCCH, which can deliver UCI by 1 or 2 symbols. PUCCH formats 0/2 are beneficial to reduce latency.
8. PUCCH formats 1/3/4 are called as long-PUCCH, which can deliver UCI with any of 4 to 14 symbols. PUCCH formats 1/3/4 are adopted to improve coverage.
9. The frequency/time-domain resources for PUCCH transmissions in NR are flexibly configurable.
10. In PUCCH format 0/1/4, multiple PUCCH resources can be CDMed on the same time/frequency resource.
11. A short-PUCCH can be TDMed with a long-PUCCH or a short PUCCH within a slot.

NR PUCCH formats

PUSCH is used to transmit one TB. A DCI in a PDCCH can schedule a PUSCH transmission with DM-RS (and other RS if any). The PUSCH is transmitted based on the information in the PDCCH, for example, time/frequency-domain resource including frequency-hopping, modulation, and layer. The number of layers for PDSCH transmissions is 4. HARQ re-transmission is supported for PUSCH transmissions as mentioned in Section

Read More

5G PDCCH 5G PDSCH

5G PDCCH and 5G PDSCH

5G PDCCH is used to carry Downlink Control Information (DCI), and following types of DCI are supported in NR.

*  PDSCH assignments to convey TB(s) to a certain UE, including time/frequency-domain resource information

*  PUSCH grants for a certain UE to transmit a TB, including time/frequency-domain resource information

*  Slot format indication, where how each of symbols within a slot is indicated

*  Pre-emption indication, which is used to inform UEs that there is no DL transmission on the informed time/frequency-domain resources

*  UL transmit power control (TPC)

*  Each device monitors a number of PDCCHs, typically once per slot although it is possible to configure more frequent monitoring to support traffic requiring very low latency. Upon detection of a valid PDCCH, the device follows downlink control information contained in the PDCCH, e.g., the scheduling decision so that the device receives PDSCH (or transmits PUSCH) accordingly.

*  The PDCCHs are transmitted in one or more control resource sets (CORESETs). A CORESET spans overdone, two or three OFDM symbol(s) in time domain and over a configurable bandwidth in the frequency domain. This is needed in order to handle devices with different bandwidth capabilities and also beneficial from a forward-compatibility perspective. One control channel element (CCE) is defined as 6 resource element groups (REGs), where 1 REG is composed of 12 resource elements (REs). In a CORESET, a PDCCH with DM-RS can be mapped on one or more CCEs as shown in Figure. Different number of CCEs (aggregation level) provides different coding rate for the control channels.

There are different formats for DCI transmitted on a PDCCH as shown in DCI Table. A UE monitors one or more PDCCH candidates for DCI with CRC scrambled by a certain RNTI in PDCCH common search space (CSS) set and/or UE-specific search space (USS) set. DCI format is distinguished by the PDCCH payload size and the RNTI scrambling the CRC.

General description of NR PDCCH

NR DCI formats

DCI format	RNTI	Notes
DCI format 0_0	RA-RNTI, TC-RNTI, C-RNTI, CS-RNTI	Monitored on CSS or USS Scheduling PUSCH
DCI format 0_1	C-RNTI, CS-RNTI	Monitored in USS Scheduling PUSCH
DCI format 1_0	SI-RNTI, RA-RNTI, P-RNTI, C-RNTI, CS-RNTI	Monitored in CSS or USS Scheduling PDSCH
DCI format 1_1	C-RNTI, CS-RNTI	Monitored in USS Scheduling PDSCH
DCI format 2_0	SFI-RNTI	Monitored in CSS Indicating slot format for slot(s)
DCI format 2_1	INT-RNTI	Monitored in CSS Indicating pre-emption of DL resource
DCI format 2_2	TPC-PUSCH-RNTI, TPC-PUCCH-RNTI	Monitored in CSS Group-TPC command for PUSCH/PUCCH
DCI format 2_3	TPC-SRS-RNTI	Monitored in CSS Group-command for SRS

PDSCH is used to transmit one or two transport blocks (TBs). A DCI in a PDCCH can assign a PDSCH transmission with DM-RS (and other RS if any). The PDSCH is decoded based on the information in the PDCCH, for example, time/frequency-domain resource, modulation, and layer. PDSCH transmissions are processed with durations from 2 to 14 symbols. The number of layers for PDSCH transmissions is 8. HARQ feedback/retransmission is supported for PDSCH transmissions as mentioned in HARQ Post.

Read More

LTE RANDOM ACCESS PROCEDURE

RAP(Random Access Procedure)

Random Access procedure is essential part of for LTE protocol communication and used for getting the grant of Uplink resources for sending RRC message first time so that UE will attached to Network. So Here I tried to provide you RAP step wise step.

RA Procedure Messages with Timers

1.     UE MAC(refer Ans 1) select a preamble out of the available 64 preamble randomly(0-64) either contention based or Non contention Based.

2.     UE MAC gives this preamble to UE physical for dispatch.

3.     UE MAC tells UE physical about which PRACH resource(refer Ans 23) should be used for preamble sending.

4.     UE Phy transmit the preamble on the selected PRACH resources.

5.     Before Transmission UE physical calculate RA-RNTI (refer Ans 36).

6.     eNB physical received preamble on PRACH resource and calculate RA-RNTI first.

7.     eNB phy forward the preamble to eNB MAC.

8.     eNB MAC allocate UL resource for the UE and this information forwarded to UE.

9.     eNB MAC prepares a message called RAR(Random Access Response) with the following detail:

a.     Preamble ID

b.     PUSCH PRB

c.     T-C-RNTI

d.     Timing Advance

RNTIs

10.  This RAR must be sent to UE on PDSCH channel by reserving PRB.

11.  eNB MAC allocate a PRB for the UE on PDSCH and gives these details [RAR+PDSCH PRB] to eNB physical.

12.  First eNB phy have to send the PDSCH PRB reservation detail to UE on the PDCCH channel against RA-RNTI.

13.   eNB PHY pack RAR info on PDSCH PRB and transmit it.

14.  UE PHY always listening to PDCCH to get to know that there is any PRB allocates against his RA-RNTI on PDSCH.

15.  UE PHY download the specified PRB and decode the info and send it to UE MAC.

16.  UE MAC received RAR which contain many detail .

17.  UE MAC verify the preamble id if matched than UE MAC decided to send “msg3”.

18.  “msg3” is nothing but a RRC connection request message.

19.  UE MAC send msg3 to UE PHY along with PUSCH PRB used for transmit.

20.  Also MAC tells physical layer about how much timing advance must be applied before Tx.

21.  UE PHY Tx “msg3” by coding into PUSCH PRB indicated.

22.  eNB PHY received this and send to eNB MAC.

23.  eNB MAC will perform the below task:

a.     Send ACK in the name of CRI(refer Ans 19) to UE that I have received msg3.

b.     Send msg3 to higher layer.

24.  eNB reserve a PRB for the UE on the PDSCH against T-C-RNTI to send CRI and send it.

25.  UE MAC compare the CRI received with Tx msg3, if equal than RAP is successful otherwise failed.

Read More

5GC Architecture

The 5G SA Core architecture is describe in the following figure.

The SA Architecture

* The SA architecture can be seen as the "full 5G deployment", not needing any part of a 4G network to operate.

* The NR base station (logical node "gNB") connects with each other via the Xn interface, and the Access Network (called the "NG-RAN for SA architecture") connects to the 5GC network using the NG interface.

* The continuation of this section refers to the SA architecture, the NSA being addressed in a subsequent, dedicated, section.

Overview of the Core Network

* In the SA deployment option, the 5G System (5GS) is composed of the User Equipment, the Access Network (including the "New Radio" or NR) and the Core Network (5GC or 5GCN).

* The service requirements, as presented in the previous clause, were used as a basis to define the architecture. The architecture specification (also called, Stage 2) started with a preliminary study in TR 23.799, also called "NextGen TR", before being fully specified in TS 23.501, TS 23.502 and TS 23.503.

* The 5GC architecture relies on a so-called "Service-Based Architecture" (SBA) framework, where the architecture elements are defined in terms of "Network Functions" (NFs) rather than by "traditional" Network Entities. Via interfaces of a common framework, any given NF offers its services to all the other authorized NFs and/or to any "consumers" that are permitted to make use of these provided services. Such an SBA approach offers modularity and reusability.

* The basic (SA, non-roaming) 5G System architecture is shown below (figure introduced by the editor):

Overview of the 5G System architecture

At this stage, only the following essential Network Functions and elements are highlighted here:

-    The User Equipment (UE);

-    The (Radio) Access Network [(R)AN];

-    The User Plane Function (UPF), handling the user data;

-    The (external) Data Network (DN);

-    Some remarkable Network Functions (NFs):

-    The Application Function (AF), handling the application(s);

-    The Access and Mobility management Function (AMF), that accesses the UE and the (R)AN;

-    The Session Management Function (SMF) that accesses the UPF.

The other NFs are introduced later.

* The SBA (Service Based Architecture) approach enables a virtualized deployment. Indeed, a Network Function instance can be deployed as fully distributed, fully redundant, stateless and/or fully scalable. Several Network Function instances can be present within a same NF set. Conversely, the services can be provided from several locations.

* In other words, when the services of a specific NF are invoked, this virtualization enables to route the UE's messages to any capable entity (within a pre-defined set of equivalent NFs).

* This provides resiliency: any specific instance of the NF can e.g. be turned off for planned maintenance, and there will be auto-recovery without any service disruption.

Overview of the Access Network

As a first approach, the architecture of the 5G AN is extremely simple since it consists in one single entity, the gNB, which connects to the 5G CN via the NG interface. It may also connect to another gNB via the Xn interface and/or to the 4G's eNB via the X2 interface, as shown below in the editor-proposed picture inspired from TS 38.401 and TS 38.420. It also connects to the UE via the NR interface, not shown on the figure. Note that this AN architecture is rather similar in its principle to what was developed for LTE with the eNB, as can be seen in TS 36.401.

Overview of the AN interfaces

References for 5GS

The main specifications for the 5G System are:

[1]     TS 23.501, "System Architecture for the 5G System"

[2]     TS 23.502, "Procedures for the 5G System"

[3]     TS 23.503, "Policy and Charging Control Framework for the 5G System"

[4]     TR 23.799 "Study on Architecture for Next Generation System"

[5]     TS 38.401 " NG-RAN; Architecture description"

[6]     TS 38.420 " NG-RAN; Xn general aspects and principles"

[7]     TS 36.401 "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture description"

Read More