UE Capability Information is an RRC message that UE sents to Network (in most case during initial registration process). It informs on all the details of its capabilities. As LTE release goes higher and more features are added, UE Capability Information has become the longest and most complicated Radio Message.
When I frist start writing this page around 2011, I didn't expect it to become such a complicated and long page, but as LTE evolves this part has gets longer and I think this part would grow even further as it start include 5G/NR features. Followings are list of topics that will be dealt with in this page or a few other pages that are related to UE capability Information.
- UE Capability Enquiry
- High Level Structure of UE Capability Information
- UE-Category
- FGI(FeatureGroupIndicators)
- Carrier Aggregation Band Combination
- LTE
- NR
- WCDMA/TDSCDMA
- GSM
- Other Factors
- How long the message can be ?
- Reference
UE Capability Enquiry
Following is how UE Capability Enquiry works. The process is very simple as shown below. Just one ping-pong. Network sends UECapabilityEnquiry and UE replied with UECapabilityInformation.
|
Direction |
Message |
Comments |
|
UE <-- NW |
UECapabilityEnquiry |
Network request UE to send capability information |
|
UE --> NW |
UECapabilityInformation |
UE reports the information to NW as requested |
When LTE first came out, this process was very simple, but as LTE evolves the information that are required gets larger and complicated. As a result, interpreting the contents of the message has become pretty complicated. I want to show how this message has expanded as LTE evolves in following listings. Refer to 36.331 5.6.3.3 Reception of the UECapabilityEnquiry by the UE in the latest spec if you want to know on the details of the information in the message.
Following is based on
UECapabilityEnquiry-r8-IEs ::= SEQUENCE {
ue-CapabilityRequest UE-CapabilityRequest,
nonCriticalExtension UECapabilityEnquiry-v8a0-IEs OPTIONAL -- Need OP
}
UECapabilityEnquiry-v8a0-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL, -- Need OP
nonCriticalExtension SEQUENCE {} OPTIONAL
}
Following is based on
UECapabilityEnquiry-r8-IEs ::= SEQUENCE {
ue-CapabilityRequest UE-CapabilityRequest,
nonCriticalExtension UECapabilityEnquiry-v8a0-IEs OPTIONAL
}
UECapabilityEnquiry-v1180-IEs ::= SEQUENCE {
requestedFrequencyBands-r11 SEQUENCE (SIZE (1..16)) OF FreqBandIndicator-r11 OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1310-IEs OPTIONAL
}
UECapabilityEnquiry-v1310-IEs ::= SEQUENCE {
requestReducedFormat-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestSkipFallbackComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestedMaxCCsDL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestedMaxCCsUL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestReducedIntNonContComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v14xy-IEs OPTIONAL
}
UECapabilityEnquiry-v14xy-IEs ::= SEQUENCE {
requestDiffFallbackCombList-r14 BandCombinationList-r14 OPTIONAL, -- Need ON
nonCriticalExtension SEQUENCE {} OPTIONAL
}
Following is based on
UECapabilityEnquiry-r8-IEs ::= SEQUENCE {
ue-CapabilityRequest UE-CapabilityRequest,
nonCriticalExtension UECapabilityEnquiry-v8a0-IEs OPTIONAL
}
UECapabilityEnquiry-v8a0-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1180-IEs OPTIONAL
}
UECapabilityEnquiry-v1180-IEs ::= SEQUENCE {
requestedFrequencyBands-r11 SEQUENCE (SIZE (1..16)) OF FreqBandIndicator-r11 OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1310-IEs OPTIONAL
}
UECapabilityEnquiry-v1310-IEs ::= SEQUENCE {
requestReducedFormat-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestSkipFallbackComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestedMaxCCsDL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestedMaxCCsUL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestReducedIntNonContComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v1430-IEs OPTIONAL
}
UECapabilityEnquiry-v1430-IEs ::= SEQUENCE {
requestDiffFallbackCombList-r14 BandCombinationList-r14 OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v1510-IEs OPTIONAL
}
UECapabilityEnquiry-v1510-IEs ::= SEQUENCE {
requestedFreqBandsNR-MRDC-r15 OCTET STRING OPTIONAL, // This IE carries FreqBandList
nonCriticalExtension SEQUENCE {} OPTIONAL
}
Following is based on
// Followings are from 38.331 FreqBandList ::= SEQUENCE (SIZE (1..maxBandsMRDC)) OF FreqBandInformation FreqBandInformation ::= CHOICE { bandInformationEUTRA FreqBandInformationEUTRA, bandInformationNR FreqBandInformationNR } FreqBandInformationEUTRA ::= SEQUENCE { bandEUTRA FreqBandIndicatorEUTRA, ca-BandwidthClassDL-EUTRA CA-BandwidthClassEUTRA OPTIONAL, -- Need N ca-BandwidthClassUL-EUTRA CA-BandwidthClassEUTRA OPTIONAL -- Need N } FreqBandInformationNR ::= SEQUENCE { bandNR FreqBandIndicatorNR, maxBandwidthRequestedDL AggregatedBandwidth OPTIONAL, -- Need N maxBandwidthRequestedUL AggregatedBandwidth OPTIONAL, -- Need N maxCarriersRequestedDL INTEGER (1..maxNrofServingCells) OPTIONAL, -- Need N maxCarriersRequestedUL INTEGER (1..maxNrofServingCells) OPTIONAL -- Need N } AggregatedBandwidth ::= ENUMERATED {mhz50, mhz100, mhz150, mhz200, mhz250, mhz300, mhz350, mhz400, mhz450, mhz500, mhz550, mhz600, mhz650, mhz700, mhz750, mhz800} UE-CapabilityRequest ::= SEQUENCE (SIZE (1..maxRAT-Capabilities)) OF RAT-Type
Let's compare the listings above with the current release. The chain keeps its shape. Each release adds one -vXXXX-IEs block at the end, and the nonCriticalExtension of the previous block points to it. After Release 15 the chain grew by six more blocks. The current 36.331 v19.3.0 text is below.
Following is based on
UECapabilityEnquiry-r8-IEs ::= SEQUENCE {
ue-CapabilityRequest UE-CapabilityRequest,
nonCriticalExtension UECapabilityEnquiry-v8a0-IEs OPTIONAL
}
UECapabilityEnquiry-v8a0-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1180-IEs OPTIONAL
}
UECapabilityEnquiry-v1180-IEs ::= SEQUENCE {
requestedFrequencyBands-r11 SEQUENCE (SIZE (1..16)) OF FreqBandIndicator-r11 OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1310-IEs OPTIONAL
}
UECapabilityEnquiry-v1310-IEs ::= SEQUENCE {
requestReducedFormat-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestSkipFallbackComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
requestedMaxCCsDL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestedMaxCCsUL-r13 INTEGER (2..32) OPTIONAL, -- Need ON
requestReducedIntNonContComb-r13 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v1430-IEs OPTIONAL
}
UECapabilityEnquiry-v1430-IEs ::= SEQUENCE {
requestDiffFallbackCombList-r14 BandCombinationList-r14 OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v1510-IEs OPTIONAL
}
UECapabilityEnquiry-v1510-IEs ::= SEQUENCE {
requestedFreqBandsNR-MRDC-r15 OCTET STRING OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1530-IEs OPTIONAL
}
UECapabilityEnquiry-v1530-IEs ::= SEQUENCE {
requestSTTI-SPT-Capability-r15 ENUMERATED {true} OPTIONAL,
eutra-nr-only-r15 ENUMERATED {true} OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1550-IEs OPTIONAL
}
UECapabilityEnquiry-v1550-IEs ::= SEQUENCE {
requestedCapabilityNR-r15 OCTET STRING OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1560-IEs OPTIONAL
}
UECapabilityEnquiry-v1560-IEs ::= SEQUENCE {
requestedCapabilityCommon-r15 OCTET STRING OPTIONAL,
nonCriticalExtension UECapabilityEnquiry-v1610-IEs OPTIONAL
}
UECapabilityEnquiry-v1610-IEs ::= SEQUENCE {
rrc-SegAllowed-r16 ENUMERATED {enabled} OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v1710-IEs OPTIONAL
}
UECapabilityEnquiry-v1710-IEs ::= SEQUENCE {
sidelinkRequest-r17 ENUMERATED {true} OPTIONAL, -- Need ON
nonCriticalExtension UECapabilityEnquiry-v17b0-IEs OPTIONAL
}
UECapabilityEnquiry-v17b0-IEs ::= SEQUENCE {
rrc-MaxCapaSegAllowed-r17 INTEGER (2..16) OPTIONAL, -- Need ON
nonCriticalExtension SEQUENCE {} OPTIONAL
}
UE-CapabilityRequest ::= SEQUENCE (SIZE (1..maxRAT-Capabilities)) OF RAT-Type
RAT-Type ::= ENUMERATED {
eutra, utra, geran-cs, geran-ps, cdma2000-1XRTT,
nr, eutra-nr, spare1, ...}
The fields added after Release 15 fall into three groups. The first group narrows the report further. The field requestSTTI-SPT-Capability-r15 asks for the short TTI and SPT capabilities of each reported band combination. The field eutra-nr-only-r15 asks only for the capabilities related to (NG)EN-DC. The fields requestedCapabilityNR-r15 and requestedCapabilityCommon-r15 carry the NR and MR-DC filters of 38.331 as octet strings. The second group is sidelinkRequest-r17. It asks for the partial sensing capabilities of the V2X sidelink band combinations.
The third group deals with size. The fields rrc-SegAllowed-r16 and rrc-MaxCapaSegAllowed-r17 allow the UE to send UECapabilityInformation in several segments. The last section of this page explains how that works. Note also the RAT-Type list at the bottom. Besides eutra, utra, geran-cs, geran-ps and cdma2000-1XRTT, it now has nr and eutra-nr, which request the NR and the MR-DC capability containers.
The enquiry grows as a chain of extensions : every release adds a -vXXXX-IEs block at the end, and the Release 8 part never changes.Most new fields are filters : they tell the UE which bands, how many CCs and which features to report, so the reply stays smaller.RAT-Type decides which containers come back : nr and eutra-nr ask for the NR and MR-DC containers in addition to eutra.Two fields enable segmentation : rrc-SegAllowed-r16 or rrc-MaxCapaSegAllowed-r17, and never both.
High Level Structure of UE Capability Information
Very high level view of UE Capability Information message structure is shown below. The more you know of the contents the more you can understand about the UE and the better position you are at for troubleshooting. But I would suggest you to understand at least on how to interprete the contents of the highlighted items.
The two trees come from one Release 11 UE, which reports accessStratumRelease rel11 and ue-Category 4. Read them from the top. The Release 8 fields sit at the first level, and every later release hangs one level deeper under nonCriticalExtension. So the Release 10 and Release 11 fields in the lower tree are several levels down, although they are just as important.
rf-Parameters lists the bands for a single carrier : supportedBandListEUTRA says which LTE bands the UE supports without CA.featureGroupIndicators is the Release 8 FGI : it is a 32 bit string, and each bit says whether a group of features is tested and supported.interRAT-Parameters lists the other RATs : it carries the supported UMTS, GSM and CDMA2000 bands.featureGroupIndRel9Add-r9 and featureGroupIndRel10-r10 add more FGI bits : they sit inside the Release 9 and Release 10 extensions.rf-Parameters-v1020 carries the CA band combinations : this is the part that makes the message long, as the last section of this page shows.
Since the message is too long and too complicated, it would be tricky to describe all of the contents in the single page. So I would split the message into a couple of categories as shown below and post separate pages for each of the categories. Try to get the high level understandings of UE capability information message and refer to following pages for the details.
- UE-Category
- FGI(FeatureGroupIndicators)
- Carrier Aggregation Band Combination
- LTE
- NR
- WCDMA/TDSCDMA
- GSM
- Other Factors
- How long the message can be ?
In some case, we spend pretty much time and effort to troubleshoot something which is not supported by UE. So I recommend you to check before troubleshoot (especially for radio stack issue). Followings are some of the RRC message and IEs you can get UE capability information.
Note 1 : Take this as a guideline but don't trust too much. Sometimes UE information says 'Supported' but in reality does not working correct. Sometimes UE information does not mention something 'supported' but seems to work.
LTE
Release 8 FDD LTE, I see most of features are pretty mature and most of functions would work as expected, but Rel 8 TDD LTE and Rel 9 or higher both FDD and TDD I strongly recommend you to check on all these information before you test. Also it would be a good idea to check these information first before you test anything on Measurement, InterRAT.
RRC : UE Capability Information
- Intra-subframe freq hopping for PUSCH scheduled by UL grant; DCI format 3a; Aperiodic CQI/PMI/RI report on PUSCH: Mode 2-0 & 2-2
- Simultaneous CQI & ACK/NACK on PUCCH (format 2a/2b); Absolute TPC command for PUSCH; Resource alloc type 1 for PDSCH; Periodic CQI/PMI/RI report on PUCCH: Mode 2-0 & 2-1
- 5bit RLC UM SN; 7bit PDCP SN
- Short DRX cycle
- Long DRX cycle; DRX command MAC control element
- Prioritised bit rate
- RLC UM
- EUTRA RRC_CONNECTED to UTRA CELL_DCH PS handover
- EUTRA RRC_CONNECTED to GERAN GSM_Dedicated handover
- EUTRA RRC_CONNECTED to GERAN (Packet_) Idle by Cell Change Order; EUTRA RRC_CONNECTED to GERAN (Packet_) Idle by Cell Change Order with NACC
- EUTRA RRC_CONNECTED to CDMA2000 1xRTT CS Active handover
- EUTRA RRC_CONNECTED to CDMA2000 HRPD Active handover
- Inter-frequency handover (within FDD or TDD)
- Measurement reporting event: Event A4 - Neighbour > threshold; Measurement reporting event: Event A5 - Serving < threshold1 & Neighbour > threshold2
- Measurement reporting event: Event B1 - Neighbour > threshold
- non-ANR related periodical measurement reporting
- ANR related intra-frequency measurement reporting events
- ANR related inter-frequency measurement reporting events
- ANR related inter-RAT measurement reporting events
- SRB1 and SRB2 for DCCH + 8x AM DRB; SRB1 and SRB2 for DCCH + 5x AM DRB + 3x UM DRB (if indicator 7 is supported)
- Predefined intra- and inter-subframe frequency hopping for PUSCH with N_sb > 1; Predefined inter-subframe frequency hopping for PUSCH with N_sb > 1
- UTRAN measurements, reporting and measurement reporting event B2 in E-UTRA connected mode
- GERAN measurements, reporting and measurement reporting event B2 in E-UTRA connected mode
- 1xRTT measurements, reporting and measurement reporting event B2 in E-UTRA connected mode
- Inter-frequency measurements and reporting in E-UTRA connected mode
- HRPD measurements, reporting and measurement reporting event B2 in E-UTRA connected mode
- EUTRA RRC_CONNECTED to UTRA CELL_DCH CS handover
- TTI bundling
- Semi-Persistent Scheduling
- Handover between FDD and TDD
- Mechanisms defined for cells broadcasting multi band information
- Inter-RAT ANR features for UTRAN FDD
- Inter-RAT ANR features for GERAN
- Inter-RAT ANR features for 1xRTT
- Inter-RAT ANR features for HRPD
- Inter-RAT ANR features for UTRAN TDD
- EUTRA RRC_CONNECTED to UTRA TDD CELL_DCH PS handover
- UTRAN TDD measurements, reporting and measurement reporting event B2 in E-UTRA connected mode
- EUTRA RRC_CONNECTED to UTRA TDD CELL_DCH CS handover
- Measurement reporting event: Event B1 - Neighbour > threshold for UTRAN FDD
UE-EUTRA-Capability.accessStratumRelease
UE-EUTRA-Capability.ue-Category
UE-EUTRA-Capability.pdcp-Parameters.supportedROHC-Profiles
UE-EUTRA-Capability.rf-Parameters.supportedBandListEUTRA
UE-EUTRA-Capability.measParameters
UE-EUTRA-Capability.interRAT-Parameters
UE-EUTRA-Capability.featureGroupIndicators
UE-EUTRA-Capability...nonCriticalExtension...featureGroupIndRel9Add-r9
Followings are some of the complete message example for UE Capability Information message.
Example 1 : UE Capability Information
WCDMA/TDSCDMA
An LTE UE that also supports WCDMA or TDSCDMA reports only a summary of that support in UE-EUTRA-Capability, mostly the supported UTRA bands in interRAT-Parameters. The full UTRA capability travels in the UTRA RRC messages, so this part lists what to check in those messages.
Regarding WCDMA,
since WCDMA is pretty mature now, most of basic features are supported and works OK, but if you try to some recent feature (e.g, DRX, CPC, e-dch, F_DPCH, enhanced Cell FACH) and interRAT (e.g, with LTE or TDSCDMA or GSM) it is highly recommended to check on this.
Regarding TDSCDMA,
Even thought TDSCDMA has been in the market for several years, but it doesn't seem to be as mature and stable as WCDMA. As a result, I see much more issues related to 'lack of capability' or 'mismatch between UE capability report and real implementation'.
You may get some high level WCDMA/TDSCDMA capability from LTE UE Capability Information message, but if you want to have full details of UE capability I would suggest you to look into WCDMA/TDSCDMA RRC Message as shown below.
RRC : RRC Connection Request
Followings are the UE capability information you can get from RRC Connection Request. This list would get longer as the technology evolves
- rrcConnectionRequest-v4b0ext.accessStratumReleaseIndicator
- rrcConnectionRequest-v690ext.ueCapabilityIndication
- rrcConnectionRequest-v6e0ext.supportForFDPCH
- rrcConnectionRequest-v770ext.hspdschReception-CellFach
- rrcConnectionRequest-v770ext.mac-ehsSupport
- rrcConnectionRequest-v770ext.discontinuousDpcchTransmission
- rrcConnectionRequest-v7b0ext.supportForE-FDPCH
- rrcConnectionRequest-v860ext.supportOfCommonEDCH
- rrcConnectionRequest-v860ext.multiCellSupport
- rrcConnectionRequest-v860ext.pre-redirectionInfo.supportEUTRA-FDD
- rrcConnectionRequest-v860ext.pre-redirectionInfo.supportEUTRA-TDD
- rrcConnectionRequest-v860ext.supportOfMACiis
- rrcConnectionRequest-v860ext.supportOfSPSOperation
Example 1 : RRC Connection Request
RRC : RRC Connection Setup Complete
Followings are some of common items you'd better check. Some of them are TDSCDMA sepcific.
- ue-MultiModeRAT-Capability.multiRAT-CapabilityList.supportOfGSM
- ue-MultiModeRAT-Capability.multiRAT-CapabilityList.supportOfMulticarrier
- ue-MultiModeRAT-Capability.multiModeCapability
- rrcConnectionSetupComplete-v7e0ext.ue-RadioAccessCapability.supportForTwoDRXSchemesInPCH
- rrcConnectionSetupComplete-v7e0ext.ue-RadioAccessCapability.supportEDPDCHPowerInterpolation
- ue-RadioAccessCapability-v4b0ext.accessStratumReleaseIndicator
- ue-RadioAccessCapability-v590ext.physicalChannelCapability.fdd-hspdsch.hsdsch-physical-layer-category
- ue-RadioAccessCapability-v590ext.physicalChannelCapability.tdd128-hspdsch
- ue-RadioAccessCapability-v690ext.physicalchannelcapability-edch.fdd-edch.edch-PhysicalLayerCategory
- v6b0NonCriticalExtensions.v6e0NonCriticalExtensions.ue-RadioAccessCapability-v6e0ext.supportForFDPCH
- ue-RadioAccessCapability-v770ext.physicalChannelCapability.fddPhysChCapability.downlinkPhysChCapability.hsdsch-physical-layer-category-ext
- ue-RadioAccessCapability-v860ext.physicalChannelCapability.fddPhysChCapability.downlinkPhysChCapability.hsdsch-physical-layer-category-ext2
- ue-RadioAccessCapability-v860ext.physicalChannelCapability.fddPhysChCapability.downlinkPhysChCapability.supportOfHsdschDrxOperation
- ue-RadioAccessCapability-v770ext.physicalChannelCapability.fddPhysChCapability.downlinkPhysChCapability.enhancedFdpch
- ue-RadioAccessCapability-v770ext.physicalChannelCapability.fddPhysChCapability.uplinkPhysChCapability.discontinuousDpcchTransmission
- ue-RadioAccessCapability-v770ext.physicalChannelCapability.fddPhysChCapability.uplinkPhysChCapability.slotFormat4
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.supportOfEUTRAFDD
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.supportOfInterRATHOToEUTRAFDD
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.supportOfEUTRATDD
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.supportOfInterRATHOToEUTRATDD
- ue-RadioAccessCapability-v770ext.mac-ehsSupport
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.supportOfEUTRAFDD
- ue-RadioAccessCapability-v860ext.multiModeRAT-Capability.eutraFeatureGroupIndicators
- ue-RadioAccessCapability-v880ext.supportForPriorityReselectionInUTRAN
- ue-RadioAccessCapability.rf-Capability.tddRF-Capability.chipRateCapability
- ue-RadioAccessCapability.rf-Capability.multiRAT-CapabilityList.supportOfGSM
- ue-RadioAccessCapability.rf-Capability.multiRAT-CapabilityList.supportOfMulticarrier
- ue-RadioAccessCapability.rf-Capability.multiModeCapability
- ue-RadioAccessCapability-v4b0ext.tdd-CapabilityExt.physicalChannelCapability-LCR.tdd128-PhysChCapability.downlinkPhysChCapability.supportOfPDSCH
- ue-RadioAccessCapability-v4b0ext.tdd-CapabilityExt.physicalChannelCapability-LCR.tdd128-PhysChCapability.uplinkPhysChCapability.supportOfPUSCH
- ue-RadioAccessCapability-v590ext.physicalChannelCapability.tdd128-hspdsch
- ue-RadioAccessCapability-v590ext.physicalChannelCapability.multiModeRAT-Capability-v590ext.supportOfUTRAN-ToGERAN-NACC
- ue-RadioAccessCapability-v770ext.physicalChannelCapability.tddPhysChCapability-128.uplinkPhysChCapability.tdd128-edch
Example 1 : RRC Connection Setup Complete
GSM
UE Capability for GSM is specified in gsm-Classmark(gsm-Classmark2, gsm-Classmark3). This IE is usually carried by WCDMA RRC Connection Setup Complete message and by GSM Attach Request message.
gsm-Classmark
- PS capability (pseudo-synchronization capability)
- SM capability (MT SMS pt to pt capability)
- FC Frequency Capability
- UCS2 treatment
- Multiband supported field.GSM 1800 Supported
- Multiband supported field.E-GSM or R-GSM Supported
- Multiband supported field.P-GSM Supported
- Extended Measurement Capability
- MS measurement capability
- GSM 400 Band Information present
- GSM 850 Associated Radio Capability present
- GSM 1900 Associated Radio Capability present
- UMTS FDD Radio Access Technology Capability
- CDMA 2000 Radio Access Technology Capability
- DTM E/GPRS Multi Slot Information present
- Single Band Support
- GSM 750 Associated Radio Capability present
- UMTS 1.28 Mcps TDD Radio Access Technology Capability
- T-GSM 400 Band Information present
- T-GSM 900 Associated Radio Capability present
- DTM Enhancements Capability
Example 1 : RRC Connection Setup Complete
Example 2 : GSM Attach Request
Other Factors
Followings are not directly related to UE Capability, but sometimes we see various issues caused by these message correlation. A capability report can be correct and still lead to a failure, because another message contradicts it. For example, the network may configure a measurement on a band that the UE never listed in supportedBandListEUTRA.
Message Correlation : WCDMA/TDSCDMA
Message Correlation : LTE
How long the message can be ?
I am not aware if there is any explicit size limit for any RRC message. Why we need to worry about the size limitation of RRC message ? We haven't even thought of this for most of the case, but we start worrying about size limitation of RRC message as UE Capability Information message gets almost exploded in terms of message length (size).
When LTE first got deployed with Release 8 specification, the UE Capability Information message was just like any other RRC messages in terms of the length. However, As LTE Release goes higher, the size gets larger as each release add its own FGI (Feature Group Indicator). But the size increase by FGI was minor. The real explosion of the size came out with the support of Carrier Aggregation. At the early phase of Carrier Aggregation (Early Release 10), only 2 CC CA(Component Carrier Carrier Aggregation) was supported and the supported band combination was not so complicated. However, as higher carrier aggregation (i.e, 2CC CA, 3CC CA, 4CC CA) is supported and more band combinations are supported, the size of UE Capability Information message got exploded. As of Release 13, we have almost several hundreds possible band combinations. As you MAY noticed, UE Category 17 in Release 13 support 32 CC CA (I hope this would not be really deployed :) and I am pretty sure that it will not be deployed in real network). The current several hundred different combination is not with 3CC CA.
In my personal experience, I think I had experience with Software Crash on a Network Simulator for almost every new 3GPP Release. The root cause was a kind of message buffer overflow, meaning that the size of the incoming signaling message hit the size of memory allocated to store the message.
What would be the solution for handling this kind of too over-sized message ? One brutal solution would be to reserve super-large message buffer size and ensure that your ASN decoder works properly for such a super large tree structure.
Another possible solution (seemingly better solution) would be to limit the scope of the information that UE report in UE Capability Information message.
Until the early phase of Carrier Aggregation, we normally used to use UE Capability Enquiry message as in [Case 1]. The Enquiry item is configured very simple. It just says 'Tell me everything about your capability on 'EUTRA'. If the UE support full capability of Rel 13 and a lot of band combination.. be careful of system crash :)
In recent release, 3GPP support additional Information Elements as in Case 2 by which Network can specify (limit) the scope of UE capability report. With this, Network can force UE to send the only capability information that are necessary to the current Network.
The three captures below show that progression. Case 1 asks for everything. Case 2 and Case 3 use the filters of the UECapabilityEnquiry listings above to shrink the reply.
Case 1
Case 1 is the classic request. The network lists only eutra in ue-CapabilityRequest and adds no filter. So the UE reports every band and every band combination it supports, and nonCriticalExtension is omitted.
Decoded message from a tester log. The values are what one network actually sent, not specification text.
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry]
+-ueCapabilityEnquiry ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry-r8]
+-ueCapabilityEnquiry-r8 ::= SEQUENCE [0]
+-ue-CapabilityRequest ::= SEQUENCE OF SIZE(1..maxRAT-Capabilities[8]) [1]
| +-RAT-Type ::= ENUMERATED [eutra]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
Case 2
Case 2 is the same request with the Release 11 and Release 13 filters added, highlighted in red. The network asks only about bands 1, 3, 17 and 28, and it limits the report to 2 DL CCs and 2 UL CCs. It also asks for the reduced format and for no fallback combinations.
Decoded message from a tester log. The values are what one network actually sent, not specification text.
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry]
+-ueCapabilityEnquiry ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry-r8]
+-ueCapabilityEnquiry-r8 ::= SEQUENCE [1]
+-ue-CapabilityRequest ::= SEQUENCE OF SIZE(1..maxRAT-Capabilities[8]) [1]
| +-RAT-Type ::= ENUMERATED [eutra]
+-nonCriticalExtension ::= SEQUENCE [11] OPTIONAL:Exist
+-lateNonCriticalExtension ::= OCTET STRING SIZE(ALIGNED) OPTIONAL:Exist
+-nonCriticalExtension ::= SEQUENCE [11] OPTIONAL:Exist
+-requestedFrequencyBands-r11 ::= SEQUENCE OF SIZE(1..16) [4] OPTIONAL:Exist
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [1]
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [3]
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [17]
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [28]
+-nonCriticalExtension ::= SEQUENCE [11111] OPTIONAL:Exist
+-requestReducedFormat-r13 ::= ENUMERATED [true] OPTIONAL:Exist
+-skipFallbackCombinations-r13 ::= ENUMERATED [true] OPTIONAL:Exist
+-requestedMaxCCsDL-r13 ::= INTEGER (2..32) [2] OPTIONAL:Exist
+-requestedMaxCCsUL-r13 ::= INTEGER (2..32) [2] OPTIONAL:Exist
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Exist
Look at the name of the second Release 13 field. The decoder shows skipFallbackCombinations-r13, while 36.331 names the field requestSkipFallbackComb-r13, as in Case 3. The capture is left as the tester printed it.
Case 3
Case 3 adds the Release 13, 14 and 15 filters on top of Case 2. The request covers bands 1, 4 and 7. It adds requestReducedIntNonContComb-r13, a requestDiffFallbackCombList-r14 with one band combination, and requestedFreqBandsNR-MRDC-r15.
Decoded message from a tester log. The values are what one network actually sent, not specification text.
+-c1 ::= CHOICE [ueCapabilityEnquiry]
+-ueCapabilityEnquiry ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ueCapabilityEnquiry-r8]
+-ueCapabilityEnquiry-r8 ::= SEQUENCE [1]
+-ue-CapabilityRequest ::= SEQUENCE OF SIZE(1..maxRAT-Capabilities[8]) [1]
| +-RAT-Type ::= ENUMERATED [eutra]
+-nonCriticalExtension ::= SEQUENCE [01] OPTIONAL:Exist
+-lateNonCriticalExtension ::= OCTET STRING OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE [11] OPTIONAL:Exist
+-requestedFrequencyBands-r11 ::= SEQUENCE OF SIZE(1..16) [3] OPTIONAL:Exist
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [1]
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [4]
| +-FreqBandIndicator-r11 ::= INTEGER (1..maxFBI2[256]) [7]
+-nonCriticalExtension ::= SEQUENCE [111111] OPTIONAL:Exist
+-requestReducedFormat-r13 ::= ENUMERATED [true] OPTIONAL:Exist
+-requestSkipFallbackComb-r13 ::= ENUMERATED [true] OPTIONAL:Exist
+-requestedMaxCCsDL-r13 ::= INTEGER (2..32) [2] OPTIONAL:Exist
+-requestedMaxCCsUL-r13 ::= INTEGER (2..32) [2] OPTIONAL:Exist
+-requestReducedIntNonContComb-r13 ::= ENUMERATED [true] OPTIONAL:Exist
+-nonCriticalExtension ::= SEQUENCE [11] OPTIONAL:Exist
+-requestDiffFallbackCombList-r14 ::= SEQUENCE OF SIZE(1..maxBandComb-r13[384]) [1]
| +-BandCombination-r14 ::= SEQUENCE OF SIZE(1..maxSimultaneousBands-r10[64]) [1]
| +-BandIndication-r14 ::= SEQUENCE [0]
| +-bandEUTRA-r14 ::= INTEGER (1..maxFBI2[256]) [1]
| +-ca-BandwidthClassDL-r14 ::= ENUMERATED [a]
| +-ca-BandwidthClassUL-r14 ::= ENUMERATED OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE [11] OPTIONAL:Exist
+-requestedFreqBandsNR-MRDC-r15 ::= OCTET STRING SIZE(ALIGNED) OPTIONAL:Exist
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Exist
This capture starts at c1, so the first two lines of the tree are not shown. Unlike Case 2, it omits lateNonCriticalExtension, and the v8a0 bit string reads 01. The single entry in requestDiffFallbackCombList-r14 is band 1 with DL bandwidth class a. The UE should therefore report the fallback combinations of that combination only where their capabilities differ.
Segmented UECapabilityInformation - Release 16 and 17
Filters make the reply smaller, but they do not guarantee that it fits. So the question at the top of this section still needs a direct answer. Is there a size limit, and what does the UE do when the message exceeds it?
There is a limit, and it comes from PDCP rather than from RRC. The maximum supported size of a PDCP SDU is 8188 octets (36.323 clause 4.3.1), so one RRC message on a signalling radio bearer cannot be longer than that. A full capability report with hundreds of band combinations can reach this size.
Release 16 added UL message segmentation for this case. The network puts rrc-SegAllowed-r16 in UECapabilityEnquiry. If the encoded UECapabilityInformation is then larger than the maximum PDCP SDU size, the UE cuts it into a series of ULDedicatedMessageSegment messages (36.331 clause 5.6.22). Each segment carries a segmentNumber, a part of the encoded message and a flag that marks the last segment. The UE uses as few segments as possible and sends them in ascending segmentNumber order. The network joins them again before it decodes the message.
Following is based on
ULDedicatedMessageSegment-r16-IEs ::= SEQUENCE {
segmentNumber-r16 INTEGER (0..15),
rrc-MessageSegmentContainer-r16 OCTET STRING,
rrc-MessageSegmentType-r16 ENUMERATED {notLastSegment, lastSegment},
lateNonCriticalExtension OCTET STRING OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}
The field segmentNumber runs from 0 to 15, so a message can have at most 16 segments. Release 17 lets the network set a smaller limit. With rrc-MaxCapaSegAllowed-r17 it allows between 2 and 16 segments. Both fields are one-shot fields, and the network includes only one of the two. In the current release, segmentation applies only to UECapabilityInformation.
The real size limit is the PDCP SDU size : 8188 octets for LTE, and 1600 octets for NB-IoT.Filters come first : requestedFrequencyBands-r11, requestedMaxCCsDL-r13 and the other filters keep the reply small.Segmentation is the fallback : with rrc-SegAllowed-r16 the UE splits an oversized reply into ULDedicatedMessageSegment messages.The network controls the number of segments : up to 16 with rrc-SegAllowed-r16, or 2 to 16 with rrc-MaxCapaSegAllowed-r17.
Reference
- 3GPP TS 36.331 v19.3.0 - clause 5.6.3 UE capability transfer, clause 5.6.22 UL message segment transfer, UECapabilityEnquiry and ULDedicatedMessageSegment; v11.5.0, v14.2.2 and v15.3.0 for the older listings
- 3GPP TS 38.331 v19.3.0 - FreqBandList, FreqBandInformation, AggregatedBandwidth
- 3GPP TS 36.323 v19.0.0 - clause 4.3.1, maximum supported size of a PDCP SDU