5G Stuff: LAA and eLAA

LAA is in 3GPP SI and WI since 2013. Though it is not absolutely a 5G topic, it is expected to see improvements in LAA when 5G is rolled out. 

Spectrum is limited resource. Hence to support growing high speed data rate demands operators purchase Frequency spectrum. Since most of the frequencies up to 6 GHz are licensed and already occupied (2G/CDMA/3G/4G), operators/academics are looking at unlicensed spectrum. As most of you know WiFi devices operate around 2.4 GHz unlicensed (free) bands and also operating in 5 GHz bands. 

In LTE, as you know, carrier aggregation comprises of one Pcell and one or more Scells in the same band or different bands. In normal LTE CA case, Scell is operated in licensed spectrum. In LAA (Licensed Assisted Access), Scell(s) is operated in unlicensed bands. 

In LAA operation, eNBs send data on Scell(s) and UE acknowledges in Pcell UL only. Since WiFi devices operate in 5 GHz band fair co-existence between LAA DL transmissions on Scell and WiFi is expected. One concept called LBT (Listen Before Talk) is adopted in LAA implementation, where the channel is monitored for some time before transmit and send data when it is idle by the eNB. LBT is not mandatory in some countries.  

To provide assistance to UEs to detect the LAA cells PSS/SSS and for measurement purpose reference signals (DRS Discovery Reference Signals) are sent by the eNB. DRS transmission should also follow LBT. DRS can transmitted periodically in DMTC frame (DRS Measurement Timing Configuration) windows. DRS is of 6 ms duration and DMTC is configurable at 40/80/160 ms. Since LAA Scell data transmission can happen anytime, new frame structure Type 3 is proposed. 

UE measures LAA Scell average RSSI to reflect the channel occupancy/interference instead of LTE style. 

The extension of LAA is called eLAA or Evolved LAA or UL LAA (Uplink LAA). In LAA, supplemental DL is supported from WiFi unlicensed spectrum where as in eLAA, supplemental UL is supported in the same WiFi unlicensed spectrum. It is part of 3GPP Rel-14 specifications. More details of eLAA and challenges are nicely explained in https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7925553

5G Stuff: FD-MIMO (Rel13)

As the need for higher data rates increases, industry often looks for new ways to increase the utilization of limited spectrum available by adding complexities to other areas like antennas, more baseband power etc. Even though MIMO concepts are not new, this has been in focus to meet the user demands. Here, one attempt is to increase the number of Tx and Rx antennas (aka MIMO) by achieving the various diversity gains. 

In 3GPP release 12, up to 8 Tx antenna ports, arranged horizontally, supported in DL-MIMO. 

Full Dimensional - MIMO (FD-MIMO) is in 3GPP since release 13 towards LTE-Advanced feature. One can place the antennas linearly or in 2 Dimensional  active array form. Depends on the need, one can decide to selectively enable/disable these antennas which makes 3D beam-forming by controlling the vertical elevation) and horizontal (azimuth) of the antenna array system. Since 4x4 MIMO systems are already available in LTE legacy, one can think of 8x8 or 4x16 or 2x32  active antenna array systems depends on the space available to place this array at the top of base station.

        Fig: From 3GPP TR 36.897, Antenna array model represented by (M, N, P) 

M- No of antennas in vertical (1,2,4...)

N- No of antennas in horizontal (1,2,4...)

P- Antenna Polarization (P=2 for cross polarization and 1 for Co-polarization)

As you doubt, how would UE will know what kind of antenna pattern that base stations are using? Like in earlier LTE legacy concepts, here also planned to inform the UE first via System info, pilot channel transmission and later get  the feedback (in the form of CSI reports etc) from UE to understand in which direction the reception quality is better and ways to improve it. It is essentially done by switching the antennas based on the feedback feedback from UE.

CRS, CSI-RS, DM-RS, ... continues to beam-formed CSI-RS in FD-MIMO:

    Traditionally CRS and CSI-RS are sent by the eNBs so that UE can measure the channel and feedback the CSI feedback info (PMI, RI and CQI). For TDD case, SRS based (Sounding RS from the UE to base station) method is used to estimate the CSI at the base station itself. Since these are common to all UEs in Idle and un-precoded,  DM-RS was introduced for those in connected to the base station (data call). 

For FD-MIMO, beam-formed CSI-RS is introduced where UE selects the best weight and feedback its index to the eNB. This method seems having more advantages in terms of less uplink feedback overhead, less downlink pilot overhead, higher quality in RS. For more details, please read "Overview of Full-Dimension MIMO in LTE-Advanced Pro" and also refer 3GPP TR 36.897 Study on elevation beamforming / Full-Dimension (FD)  Multiple Input Multiple Output (MIMO) for LTE (Release 13).

In release 13, FD-MIMO was introduced with TM 9 and TM 10 configurations and UE indicates its capability per-TM sub-features and optionally it can send per-BoBC (Band of a bandcombo) basis. 

Per-TM capabilities are transferred by RRC via PhyLayerParameters-v1320 and it may be part of UE-EUTRA-Capability-v1320-IEs and UE-EUTRA-CapabilityAddXDD-Mode-v1320

Per-BoBC capabilities are indicated by RRC via BandCombinationParameters-v1320 and it may be part of RF-Parameters-v1320, via SupportedBandCombination-v1320, SupportedBandCombinationAdd-v1320, or SupportedBandCombinationReduced-v1320

Some of the sub-features are below:

1. Class A CSI reporting: It comes with 
a) increased number of CSI-RS ports from minimum of 8 to 16 which increases the maximum precoding matrix size. For 12 ports, 3 CSI-RS configs for 4 ports are selected. Similarly, for 16 ports, 2 CSI-RS configs for 8 ports are selected.  
b) 2D code book and 
c) 3 pre-coding matrix indicators (i1,1), (i1,2) and i2 (against 2 in legacy i1 and i2)

Here (i1,1), (i1,2) represents a grid of beam directions in first and second dimension and i2 represents selection of beams at a beam grid and phase of beams. In this method, non-precoded CSIRSs are sent by the base station and the UE derives the precoder. 

Here, CSI-RS overhead increases in proportion to the number of antenna ports.

2. Class B CSI reporting: To reduce the CSI-RS overhead, beam formed CSI-RS introduced. Here, CSI-RS beams are denoted by NB. If NB=1, CSI info PMI/RI/CQI are reported back however with UE specific beam formed CSI-RS reduces the overload. If NB>1, base station transmits multiple CSI-RS with different beams. UE measures the suitable one and reports back the CSI Resource Index (CRI) along with the PMI/RI/CQI. 3GPP release 13 supports up to 8 NB. This seems to be promising method for 5G systems and operators opr vendors might prefer this one.

3. CSI-RS in DwPTS: In this, CSI-RS allowed to transmit in DwPTS for Special Subframe config 1,2,3,4,6,7 or 8 for normal cyclic prefix and Special Subframe config 1,2,3,5 or 6 for extended cyclic prefix.

4. DMRS improvements: It introduces OCC (Orthogonal cover code). It supports of MU-MIMO with antenna ports 7,8,11,13 with OCC length of 4.

5. SRS improvements: With more number of UEs transmitting SRS in UL, Channel estimation info becomes worse, also added interference due to the UEs in the neighboring cells. In Rel-13, this is overcome either by extending the SRS bits, precoded SRS, 4Tx antenna switching for SRS transmission, transmitting SRS on unused PUSCH DMRS resources, transmitting SRS on PUSCH resources.

In my next blog, I will give more details on this feature in 5G NR perspective and how it will be developed. 

5G Stuff: Network Slicing (Part 1)

As part of 5G System architecture, 3GPP has come up with another concept, from the networks or operators p.o.v, called Network slicing based on the Services or Features to be served in the whole PLMN. This concept looks similar to filtering the services based on the QoS profiles so far being used in 2G/3G/4G systems. This time a specific name being used. This allows operators virtually create networks to cater the different needs based on functionality, performance, specific users etc.

Functionality can be categorized as priority, charging, policy control, security and mobility.

Performance is related to latency, mobility,  availability, reliability, data rates etc.

Users are MPS (Multimedia Priority Service) users, Public safety, corporate customers, roamers, hosting an MVNO (Mobile Virtual Network Operator)

From this concept, network slice may be defined as piece of network to service some set of services. Below diagram explain the rest of the concept easily. Based on this, some of the core network elements may be common to some slices and some may be specific to each slice. Network creates instances of the required elements for each slice in the core network.

As mentioned in my earlier post (5G Identifiers (SUPI, PEI, GUTI...), S-NSSAI, NSSAI, SST, SD etc are the terms being used to explain the Network slicing concept and how UE is addressed.  

An S-NSSAI is comprised of SST and SD (optional) fields. An SST can be standardised (no SD) or non-standardised (either standardised SSD + non-standardised SD or non-standardised SST + no SD). Non-standardised S-NSSAI shall not be used in other PLMNs.  

Below table shows the Standardised SST values in a way for establishing the global interoperability for slicing (which recalls me a familiar triangle which explains 5G use cases)

Slice/Service type	SST value	Characteristics.
eMBB	1	Slice suitable for the handling of 5G enhanced Mobile Broadband.
URLLC	2	Slice suitable for the handling of ultra- reliable low latency communications.
MIoT	3	Slice suitable for the handling of massive IoT.

During the initial access to the network, below NSSAIs are defined which is mentioned in one logical order (as I understood).

1. Configured S-NSSAI - NSSAI provisioned in the UE applicable to one or more PLMNs. 

2. Requested S-NSSAI - NSSAI provided by the UE to the Serving PLMN during registration. Here the serving AMF, Network slice (s), Network Slice instances (s) are selected. 5G RAN use this information in AS signaling until 5GC issues the Allowed S-NSSAI (see below). When the UE provides 5G-GUTI, RAN will NOT use this Requested S-NSSAI for routing.

3. Allowed S-NSSAI - NSSAI provided by the Serving PLMN during e.g. a Registration procedure, indicating the S-NSSAIs values the UE could use in the Serving PLMN for the current registration area. 5GC will inform RAN and issue this Id after successful registration and is responsible for selection of the Network Slice Instance. 

There can be at most 8 S-NSSAIs in Allowed and Requested NSSAIs sent in signaling messages between the UE and the network.

As per the operator need or plan one Network Slice Instance can provide one or more S-NSSAIs and one S-NSSAI can be mapped to one or more Network Slice Instances. 

Further, to look from the tracking areas p.o.v, multiple Network Slice Instances mapped to one S-NSSAI may be available in one or more tracking areas. In one tracking area case, the AMF instance which is serving the UE is common to one or more Network Slice Instances.

This slicing concept itself will require more details, which will be continued in my next blogs.

Sources: 
3GPP TS 23501, sec 5.15
3GPP TS 22261, sec 6.1

5G Stuff: NR SUL - Supplementary Uplink

To put in simple terms addition of another Uplink to the existing one. As  mentioned in my earlier posts about Sub6 and mmW that operating frequencies for 5G runs until 60 GHz. From the earlier literature, path loss increases with frequency which will cause the Uplink to be lost completely even when closer to the base stations. Hence, to increase the UL coverage another frequency in the lower bands is needed. From the FR1 operating bands table, n80 to n84 are supporting SUL. Based on some studies, as mentioned in 3GPP TR 37872, SUL bands may find their place in reality. Below are the band combos of SUL bands with the normal Bands.

SUL_Band n78_Band n80

SUL Band combination	NR Band	Uplink (UL) band			Downlink (DL) band			Duplex mode
		BS receive / UE transmit			BS transmit / UE receive
		FUL_low – FUL_high			FDL_low – FDL_high
SUL_n78-n80	n78	3300 MHz	–	3800 MHz	3300 MHz	–	3800 MHz	TDD
	n80	1710 MHz	–	1785 MHz				SUL

SUL band combination

SUL Configuration	NR Band	Subcarrier spacing [kHz]	5 MHz	10 MHz	15 MHz	20 MHz	[40 MHz]	50 MHz	[60 MHz]	80 MHz	100 MHz
SUL_n78A-n80A	n78	15		Yes	Yes	Yes	Yes	Yes
		30		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
		60		Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
	n80	15	Yes	Yes	Yes	Yes

Supported bandwidths per SUL band combination

SUL_Band n79_Band n80

SUL Band combination	NR Band	Uplink (UL) band			Downlink (DL) band			Duplex mode
		BS receive / UE transmit			BS transmit / UE receive
		FUL_low – FUL_high			FDL_low – FDL_high
SUL_n79-n80	n79	4400 MHz	–	5000 MHz	4400 MHz	–	5000 MHz	TDD
	n80	1710 MHz	–	1785 MHz				SUL

SUL band combination

SUL Configuration

NR Band

Subcarrier spacing [kHz]

5 MHz

10 MHz

15 MHz

20 MHz

25 MHz

30 MHz

40 MHz

50 MHz

60 MHz

80 MHz

100 MHz

SUL_n79A-n80A

n79

15

Yes

Yes

30

Yes

Yes

Yes

Yes

Yes

60

Yes

Yes

Yes

Yes

Yes

n80

15

Yes

Yes

Yes

Yes

Yes

Yes

Supported bandwidths per SUL band combination

SUL_Band n78_Band n84

SUL Band combination	NR Band	Uplink (UL) band			Downlink (DL) band			Duplex mode
		BS receive / UE transmit			BS transmit / UE receive
		FUL_low – FUL_high			FDL_low – FDL_high
SUL_n78-n84	n78	3300 MHz	–	3800 MHz	3300 MHz	–	3800 MHz	TDD
	n84	1920 MHz	–	1980 MHz	N/A			SUL

SUL band combination

SUL Configuration

NR Band

Subcarrier spacing [kHz]

5 MHz

10 MHz

15 MHz

20 MHz

25 MHz

30 MHz

40 MHz

50 MHz

60 MHz

80 MHz

100 MHz

SUL_n78A-n84A

n78

15

Yes

Yes

Yes

Yes

30

Yes

Yes

Yes

Yes

Yes

Yes

Yes

60

Yes

Yes

Yes

Yes

Yes

Yes

Yes

n84

15

Yes

Yes

Yes

Yes

Supported bandwidths per SUL band combination

SUL_Band n78_Band n82

SUL Band combination	NR Band	Uplink (UL) band			Downlink (DL) band			Duplex mode
		BS receive / UE transmit			BS transmit / UE receive
		FUL_low – FUL_high			FDL_low – FDL_high
SUL_n78-n82	n78	3300 MHz	–	3800 MHz	3300 MHz	–	3800 MHz	TDD
	n82	832 MHz	–	862 MHz	N/A			SUL

SUL band combination

SUL Configuration

NR Band

Subcarrier spacing [kHz]

5 MHz

10 MHz

15 MHz

20 MHz

25 MHz

30 MHz

40 MHz

50 MHz

60 MHz

80 MHz

100 MHz

SUL_n78A-n82A

n78

15

Yes

Yes

Yes

Yes

30

Yes

Yes

Yes

Yes

Yes

Yes

Yes

60

Yes

Yes

Yes

Yes

Yes

Yes

Yes

n82

15

Yes

Yes

Yes

Yes

Supported bandwidths per SUL band combination

I assume further studies are in progress for other SUL bands which were not covered above and are these 5 SUL bands expected to work with all other TDD bands (n38/n41/n50/n51 and n77-79). It is my FFS to see why FDD bands are not taken here in SUL case. Stay tuned!