3GPP TS V (). 2. Release 8. Keywords. UMTS, radio. 3GPP. Postal address. 3GPP support office address. Route des. Radio Resource Control (RRC); Protocol specification (3GPP TS version Release 11) Ocr ABBYY FineReader Ppi Release 8. 2. 3GPP TS V (). Keywords UMTS, radio. 3GPP Postal address 3GPP support office address Route des Lucioles – Sophia.
|Published (Last):||14 October 2007|
|PDF File Size:||2.96 Mb|
|ePub File Size:||6.19 Mb|
|Price:||Free* [*Free Regsitration Required]|
I want to show how this message has expanded as LTE evolves in following table. Another possible solution seemingly better solution would be to limit the scope of the information that UE report in UE Capability Information message. But the size increase by FGI was minor.
3GPP TS (1 of 18) – E-UTRA RRC
With this, Network can force UE to send the only capability information that are necessary to the current Network. How long the message can be?
Why we need to worry about the size limitation of RRC message? As a result, interpreting the contents of the message has become pretty complicated. It informs on all the details of its capabilities. So I recommend you to check before troubleshoot especially for radio stack issue. The real explosion of the size came out releasr the 63.331 of Carrier Aggregation.
Feature Group Indicators (FGI bits) in LTE – Rel. 8, Rel. 9 and Rel. 10 – Techplayon
As a result, I see much more issues related to ‘lack of capability’ or ‘mismatch between UE capability report and real implementation’. The process is very simple as shown below. The current several hundred different combination is not with 3CC CA.
Sometimes UE information does not mention something ‘supported’ but seems to work. Network request UE to send capability information.
So I would split the message into a couple of categories as shown below and post separate pages for each of the categories. Followings are some of the complete message example for UE Capability Information message.
What would be the solution for handling this kind of too over-sized message? This list would get longer as the technology evolves. The Enquiry item is configured very simple. The root cause was a kind reelase message buffer overflow, meaning that the size of the incoming signaling message hit the size of memory allocated to store the message.
Feature Group Indicators (FGI bits) in LTE – Rel. 8, Rel. 9 and Rel. 10
Reelase high level view of UE Capability Information message structure is shown below. If the UE support full capability of Rel 13 and a lot of band combination. 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.
Sometimes UE information says ‘Supported’ but in reality does not working correct.
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.
The more you know of the contents the repease you can understand about the UE and the better position you are at for troubleshooting.
In some case, we spend pretty much time and effort to troubleshoot something which is not supported by UE. However, as higher carrier aggregation i. Followings are some of common items you’d better check. Take this as a guideline but don’t trust too much. Following is how UE Capability Enquiry works.
UE reports the information to NW as requested. Since the message is too long and too complicated, it would be tricky to describe all of the contents in the single page. Also it would be a good idea to check these information first before you test anything on Measurement, InterRAT. Followings are not directly related to UE Capability, but sometimes we see various issues caused by these message correlation.
But I would suggest you to understand at least on how to interprete the contents of the highlighted items. When LTE first came out, this process was very simple, but as LTE evolves the information that are required gets larger and complicated. I am not aware if there is any explicit size limit for any RRC 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.