The fundamental concept of LTE-U is to extend LTE radio frequency to a frequency band which is not specified by 3GPP (Not-licensed). The most common frequency that are targeted for this application is WLAN band.
The typical implementation being adopted as of now is to use WLAN band as the SCC (Secondary Carrier Component) in Carrier Aggregation mode.
For LTE-U, you can get pretty much detailed technical documents from various sources and even from 3GPP. The first thing I would recommend you to go for technical documents is LTE-U Forum.
This page follows an LTE-U secondary carrier from its band definition to the RRC message that adds it. The LTE Unlicensed page puts LTE-U next to LAA, LWA and the other unlicensed technologies, and explains the channel sensing methods they use.
Followings are the topics to be covered in this page.
- LTE-U Band Definition
- UE Capability Information
- Adding SCC in Unlicensed Band
- Can we use these band at any time ? No Regulation ?
- Possible challenges for LTE-U
- Reference
LTE-U Band Definition
LTE-U needs band numbers and EARFCNs, because RRC can only point a UE to a carrier by its EARFCN. The LTE-U Forum defined two downlink-only bands in the 5 GHz unlicensed spectrum for this, and the table below gives their numbering.
Following band/frquency mapping table is based on LTE-U Technical Report Coexistence Study for LTE-U SDL V1.3 (LTE Forum Documents). If you need to create LTE-U test (i.e, Carrier Aggragation) you woud need to use the channel number startimg from the number in column N_Offs-DL in RRC Connection Reconfiguration.
|
U-NII |
LTE Band |
F_DL_low [MHz] |
Spectrum (Mhz) |
N_Offs-DL |
Range of NDL |
|
U-NII-1 |
Band 252 |
5150 |
5150-5250 |
255144 |
255144-256143 |
|
U-NII-2 |
Band 253/254 |
|
5250-5720 |
|
|
|
U-NII-3 |
Band 255 |
5725 |
5725-5850 |
260894 |
260894-262143 |
|
Note 1 : U-NII stands for Unlicensed National Information Infrastructure Note 2 : U-NII-2 is reserved for future use Note 3 : Frequency step between one EARFCN and the next is 100 Khz, i.e 0.1 Mhz (Same as in LTE) |
|||||
As of now, the only a few DL EARFCN and corresponding frequencies are allowed as follows :
- Band 252 :
- DL EARFCN = {255244, 255444, 255644, 255844, 256044}
- Frequency (Mhz) = { 5160, 5180, 5200, 5220, 5240 }
- Band 255 :
- DL EARFCN = {261094, 261294, 261494, 261694, 261894}
- Frequency (Mhz) = { 5745, 5765, 5785, 5805, 5825 }
The EARFCNs follow the usual LTE formula, FDL = FDL_low + 0.1 (NDL - NOffs-DL). For band 252, EARFCN 255244 gives 5150 + 0.1 × 100 = 5160 MHz. For band 255, EARFCN 261494 gives 5725 + 0.1 × 600 = 5785 MHz, which is the carrier the RRC example further down adds.
Bands 252 and 255 do not appear in 36.101 v20.0.0, because 3GPP never specified LTE-U. 3GPP covers the same 5 GHz spectrum with band 46 instead, from 5150 MHz to 5925 MHz with NOffs-DL 46790, and uses it for LAA.
Band 252 is U-NII-1 : 5150 to 5250 MHz, EARFCN 255144 to 256143.Band 255 is U-NII-3 : 5725 to 5850 MHz, EARFCN 260894 to 262143.Both are downlink only : LTE-U uses the unlicensed carrier as a supplemental downlink.3GPP uses band 46 instead : the LAA band, 5150 to 5925 MHz.
UE Capability Information
How network knows if a UE support LTE-U or not ? As in most of other LTE features, UE is supposed to notify Network on its capability of LTE-U via UE Capability Information message. Following is an example.
The band numbers explain where the UE reports them. FreqBandIndicator in 36.331 v19.3.0 only covers bands 1 to 64. Bands 65 to 256 need FreqBandIndicator-v9e0, so bands 252 and 255 appear in the v9e0 and v1090 extensions, as the red lines in the capture below show.
Decoded UECapabilityInformation,
ueCapabilityInformation-r8
ue-CapabilityRAT-ContainerList: 1 item
Item 0
UE-CapabilityRAT-Container
rat-Type: eutra (0)
ueCapabilityRAT-Container: cd98003041bf7e0c1e03407e0fdf83762680086dc2a40000...
UE-EUTRA-Capability
...
nonCriticalExtension
nonCriticalExtension
rf-Parameters-v9e0
supportedBandListEUTRA-v9e0: 4 items
Item 0
SupportedBandEUTRA-v9e0
Item 1
SupportedBandEUTRA-v9e0
Item 2
SupportedBandEUTRA-v9e0
bandEUTRA-v9e0: 252
Item 3
SupportedBandEUTRA-v9e0
bandEUTRA-v9e0: 255
rf-Parameters-v1090
supportedBandCombination-v1090: 17 items
Item 0
BandCombinationParameters-v1090: 1 item
Item 0
BandParameters-v1090
Item 1
BandCombinationParameters-v1090: 1 item
Item 0
BandParameters-v1090
Item 2
BandCombinationParameters-v1090: 1 item
Item 0
BandParameters-v1090
bandEUTRA-v1090: 252
Item 3
BandCombinationParameters-v1090: 1 item
Item 0
BandParameters-v1090
bandEUTRA-v1090: 255
.....
Item 15
BandCombinationParameters-v1090: 2 items
Item 0
BandParameters-v1090
bandEUTRA-v1090: 255
Item 1
BandParameters-v1090
Item 16
BandCombinationParameters-v1090: 2 items
Item 0
BandParameters-v1090
bandEUTRA-v1090: 252
Item 1
BandParameters-v1090
bandEUTRA-v9e0: 252 and 255 : the single-band list, in the v9e0 extension.bandEUTRA-v1090: 252 and 255 : the band combinations, in the v1090 extension.Item 15 and Item 16 : combinations with two bands, one of which is an LTE-U band.
Adding SCC in Unlicensed Band
Adding SCC in the unlicensed band is almost same as in Carrier Aggregation between licensed bands except that LTE-U requires two IE (Information Element) as labeled (A), (B) in the following example.
In this case, (A) is always set to be max value of the IE and it is just working as an indicator that the IE (B) will be used.
Decoded RRCConnectionReconfiguration,
+-rrcConnectionReconfiguration ::= SEQUENCE +-rrc-TransactionIdentifier ::= INTEGER (0..3) [0] +-criticalExtensions ::= CHOICE [c1] +-c1 ::= CHOICE [rrcConnectionReconfiguration-r8] +-rrcConnectionReconfiguration-r8 ::= SEQUENCE [000101] +-measConfig ::= SEQUENCE OPTIONAL:Omit +-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit +-dedicatedInfoNASList ::= SEQUENCE OF OPTIONAL:Omit +-radioResourceConfigDedicated ::= SEQUENCE [000101] OPTIONAL:Exist | +-srb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit | +-drb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit | +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit | +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist | +-sps-Config ::= SEQUENCE OPTIONAL:Omit | +-physicalConfigDedicated ::= SEQUENCE [0010000000] OPTIONAL:Exist | | +-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit | | +-pucch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit | | +-pusch-ConfigDedicated ::= SEQUENCE OPTIONAL:Exist | | | +-betaOffset-ACK-Index ::= INTEGER (0..15) [10] | | | +-betaOffset-RI-Index ::= INTEGER (0..15) [12] | | | +-betaOffset-CQI-Index ::= INTEGER (0..15) [15] | | +-uplinkPowerControlDedicated ::= SEQUENCE OPTIONAL:Omit | | +-tpc-PDCCH-ConfigPUCCH ::= CHOICE OPTIONAL:Omit | | +-tpc-PDCCH-ConfigPUSCH ::= CHOICE OPTIONAL:Omit | | +-cqi-ReportConfig ::= SEQUENCE OPTIONAL:Omit | | +-soundingRS-UL-ConfigDedicated ::= CHOICE OPTIONAL:Omit | | +-antennaInfo ::= CHOICE OPTIONAL:Omit | | +-schedulingRequestConfig ::= CHOICE OPTIONAL:Omit | | +-EXTENSION ::= SEQUENCE [01000] | +-EXTENSION ::= SEQUENCE [000] | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS2 ::= SEQUENCE OPTIONAL:Omit | +-VERSION-BRACKETS3 ::= SEQUENCE OPTIONAL:Omit +-securityConfigHO ::= SEQUENCE OPTIONAL:Omit +-nonCriticalExtension ::= SEQUENCE [01] OPTIONAL:Exist +-lateNonCriticalExtension ::= OCTET STRING OPTIONAL:Omit +-nonCriticalExtension ::= SEQUENCE [001] OPTIONAL:Exist +-otherConfig-r9 ::= SEQUENCE OPTIONAL:Omit +-fullConfig-r9 ::= ENUMERATED OPTIONAL:Omit +-nonCriticalExtension ::= SEQUENCE [010] OPTIONAL:Exist +-sCellToReleaseList-r10 ::= SEQUENCE OF OPTIONAL:Omit +-sCellToAddModList-r10 ::= SEQUENCE OF SIZE(1..maxSCell-r10[4]) [1] OPTIONAL:Exist | +-SCellToAddMod-r10 ::= SEQUENCE [111] | +-sCellIndex-r10 ::= INTEGER (1..7) [1] | +-cellIdentification-r10 ::= SEQUENCE OPTIONAL:Exist | | +-physCellId-r10 ::= INTEGER (0..503) [0] | | +-dl-CarrierFreq-r10 ::= INTEGER (0..maxEARFCN[65535]) [65535] <== (A) | +-radioResourceConfigCommonSCell-r10 ::= SEQUENCE [0] OPTIONAL:Exist | | +-nonUL-Configuration-r10 ::= SEQUENCE [00] | | | +-dl-Bandwidth-r10 ::= ENUMERATED [n100] | | | +-antennaInfoCommon-r10 ::= SEQUENCE | | | | +-antennaPortsCount ::= ENUMERATED [an1] | | | +-mbsfn-SubframeConfigList-r10 ::= SEQUENCE OF OPTIONAL:Omit | | | +-phich-Config-r10 ::= SEQUENCE | | | | +-phich-Duration ::= ENUMERATED [normal] | | | | +-phich-Resource ::= ENUMERATED [one] | | | +-pdsch-ConfigCommon-r10 ::= SEQUENCE | | | | +-referenceSignalPower ::= INTEGER (-60..50) [18] | | | | +-p-b ::= INTEGER (0..3) [0] | | | +-tdd-Config-r10 ::= SEQUENCE OPTIONAL:Omit | | +-ul-Configuration-r10 ::= SEQUENCE OPTIONAL:Omit | | +-EXTENSION ::= SEQUENCE [00] | | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | | +-VERSION-BRACKETS2 ::= SEQUENCE OPTIONAL:Omit | +-radioResourceConfigDedicatedSCell-r10 ::= SEQUENCE [1] OPTIONAL:Exist | | +-physicalConfigDedicatedSCell-r10 ::= SEQUENCE [11] OPTIONAL:Exist | | | +-nonUL-Configuration-r10 ::= SEQUENCE [1001] OPTIONAL:Exist | | | +-ul-Configuration-r10 ::= SEQUENCE [0001000] OPTIONAL:Exist | | | +-EXTENSION ::= SEQUENCE [00] | | | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | | | +-VERSION-BRACKETS2 ::= SEQUENCE OPTIONAL:Omit | | +-EXTENSION ::= SEQUENCE [0] | | +-VERSION-BRACKETS1 ::= SEQUENCE OPTIONAL:Omit | +-EXTENSION ::= SEQUENCE [1] | +-VERSION-BRACKETS1 ::= SEQUENCE [1] OPTIONAL:Exist | +-dl-CarrierFreq-v1090 ::= (maxEARFCN-Plus1[65536]..maxEARFCN2[262143]) [261494] <== (B) +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
The reason for the two fields is the size of the original one. In 36.331 v19.3.0, dl-CarrierFreq-r10 is an ARFCN-ValueEUTRA with a maximum of maxEARFCN, which is 65535. The LTE-U EARFCNs are above 255000, so they do not fit. SCellToAddMod-r10 therefore carries dl-CarrierFreq-v1090, of type ARFCN-ValueEUTRA-v9e0, which runs from 65536 to 262143.
The field description makes (A) and (B) a pair. The field dl-CarrierFreq-v1090 is mandatory present if dl-CarrierFreq-r10 is included and set to maxEARFCN, and absent otherwise. So (A) = 65535 is not a real carrier. It only tells the UE to read the real EARFCN from (B), which is 261494 in this capture, or 5785 MHz in band 255.
(A) dl-CarrierFreq-r10 = 65535 : maxEARFCN, used as a flag.(B) dl-CarrierFreq-v1090 = 261494 : the real EARFCN of the LTE-U SCell.Only (B) fits the LTE-U range : ARFCN-ValueEUTRA-v9e0 covers 65536 to 262143.
Can we use these band at any time ? No Regulation ?
In some country like US, Korea, China, the answer is Yes, you (a cell) can use the allowed spectrum at anytime as long as it would not create serious Coexistance problem. But in some countries like EU and Japan, the answer is NO. The cell should perform a specific process called LBT (Listen Before Talk) using a special waveform.
The two groups of countries match the two technologies. LTE-U, with channel selection and CSAT, targets the markets without an LBT rule. LAA adds LBT and targets the markets with one. The LTE Unlicensed page describes CSAT, LBT and the 3GPP channel access procedure for LAA.
In the LBT markets the rule is concrete. 3GPP 37.213 v19.0.0 has the eNB sense the channel in slots of 9 µs, wait a defer duration, and then count down a random backoff before it transmits. After that, the eNB may keep the channel for at most 2, 3, 8 or 10 ms, depending on the channel access priority class. LTE-U has no such procedure, so an LTE-U cell cannot operate where the regulation requires one.
No LBT rule : US, Korea and China: LTE-U with channel selection and CSAT.LBT rule : EU and Japan: LAA with the 37.213 channel access procedure.The maximum occupancy is capped : at most 10 ms per channel access for LAA.
Possible challenges for LTE-U
There wouldn't be any serious technical challenges in implementing LTE-U technology itself, but we need to be prepared to meet various Coexistance issues with the existing WiFi when we deploy LTE-U. Another challenge you may think of would be that we would need a lot of small cells that can be deployed easily and anyware like WiFi AP(Access Point).
Of course, the first thing you have to worry about for this small cell installation is about handling interference with existing WiFi AP and interference with other small cells installed nearby.
The inference/coexistance is not the only problem. you may ask 'who is going to configure/optimize those small cells ?'. Would it be such an easy install like WiFi AP (almost plug and play) ? or would it require special configuration/optimization for each installation ? If we need to configure those small cells one by one for every install, who will be doing it ? Installtion engineer from carrier ? or can it be automated by SON (Self Organizing Network) ? Is SON mature enough to do this ?
3GPP answered the coexistence part of this question in LAA rather than in LTE-U. The channel access procedure of 37.213 v19.0.0 makes an LAA cell back off like a Wi-Fi station, with a contention window that grows from CWmin to CWmax. Even the discovery burst, which carries the PSS, SSS and CRS, has to pass a short 25 µs check before it goes on air. The small-cell configuration question is not specific to LTE-U, and the specifications do not answer it.
Coexistence : handled by CSAT in LTE-U, and by LBT with random backoff in LAA.Discovery signals also sense first : Type 2A access with a 25 µs check in 37.213.Deployment and SON : left open, as the questions above point out.
Reference
[1]
[2] 3GPP TS 36.101 v20.0.0 - band 46 in Table 5.5-1
[3] 3GPP TS 36.331 v19.3.0 - SCellToAddMod-r10, ARFCN-ValueEUTRA-v9e0 and FreqBandIndicator-v9e0
[4] 3GPP TS 37.213 v19.0.0 - clause 4.1 for downlink channel access