LTE RRC Complexity Compared to UMTS

One of the good things about LTE is that especially in the radio network, it represents a fresh start so a lot of "optionality" that tends to bloat a specification over time is avoided in the general baseline. To see what I mean, let's compare the Radio Resource Control (RRC) specification of UMTS with LTE:

UMTS RRC

The original Release 99 UMTS RRC specification (3GPP TS 25.331 v 3.1.0) is about 865 pages long. In Release 8, the same specification document (v 8.1.0) now contains 1435 pages.

LTE RRC

The RRC specification for LTE can be found in 3GPP TS 36.331. The December 2009 version (v.8.8.0) contains 208 pages. That's only a fraction of even only the R99 UMTS specification.

I am a bit surprised the volume difference is this big. I compared chapter headings to see if there are things that the UMTS RRC spec contains which are not in the LTE RRC. However, it all looks pretty similar.

5 thoughts on “LTE RRC Complexity Compared to UMTS”

  1. The difference in volume is truly amazing if those page counts are correct. Any idea where the reduction came from? I’m sure a lot of it was simplified and omitted (didn’t LTE only have like two or three RRC states?)

  2. As another measure of complexity did you try comparing the size of the ASN.1 message definitions between the two specs? I suspect you’ll find a similar 4x difference between R’99 and LTE and it’s probably close to an order of magnitude difference between R’8 UMTS and LTE.

  3. I had noticed this, too. Some contributing factors that I had considered were a simplified RRC state machine, a simplified message set in which some messages serve multiple functions (I’m thinking RRC Connection Reconfiguration), and that the standard doesn’t seem to have been parameterized “to death”.

  4. Hi Martin,

    I think the LTE RRC specification is a major success, thanks to lessons learnt in 3GPP RAN2 during UMTS work.

    RAN2 found out that only the essential minimum required for interoperability should be specified, as more means more errors.

    In practise, this has meant:
    – do not specify network behaviour
    – do not specify error handling unless there is a very good reason
    – before introducing anything, make sure it is absolutely needed
    – think about what could be removed
    – never duplicate anything
    – specify signalling using ASN.1 only (no tabular) and use ASN.1 names in the procedure description

    Several delegates in 3GPP RAN2 largely contributed to this but we should say a big thank you to Himke Van der Velde who really wrote LTE RRC specification from scratch, and to Richard Burbidge who helped a lot when chairing the RRC sessions (and also bringing some good reorganization proposals).

    Personally, I was only involved in supporting the “no tabular” decision and removing a few useless procedures.

    David.

  5. Hi again,

    ooops, to be fair, we should also thank Gert-Jan Van Lieshout, he’s been also very helpful for LTE RRC (but clearly a lot more than only for LTE RRC), and he also chaired a number of the LTE RRC sessions.

    David.

Comments are closed.