|
4G/LTE - UE Capability |
||||||||||||||||
|
UE Capability Information
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.
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.
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 table. 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.
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.
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.
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.
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
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
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.
Followings are the UE capability information you can get from RRC Connection Request. This list would get longer as the technology evolves
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.
Example 1 : RRC Connection Setup Complete
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.
Example 1 : RRC Connection Setup Complete Example 2 : GSM Attach Request
Followings are not directly related to UE Capability, but sometimes we see various issues caused by these message correlation.
Message Correlation : WCDMA/TDSCDMA Message Correlation : LTE
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.
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
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
+-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
|
||||||||||||||||
