This page follows one LTE call from the moment the UE finds a cell to the moment it carries data on a dedicated bearer. Every step below is a real message, decoded from a live log and printed in full rather than summarised. Treat it as a reference to come back to rather than as something to read through in one sitting.
The sequence runs twice, and the repetition is deliberate. The first pass is the initial attach, where the UE registers, authenticates, and ends up with a default EPS bearer. The second pass starts again from RACH and carries a Service Request. That is the shorter path a UE already known to the network takes when it needs to move data again. Several steps in the second pass differ from the first in one field only, and those sections name the field rather than repeating the whole message.
Followings are the topics :
- Typical Packet Call
- MIB
- SIB 1
- SIB 2
- RRC : PRACH Preamble / RRC : RACH Response
- Interim Comments
- RRC : RRC Connection Request
- RRC : RRC Connection Setup
- RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request
- RRC : DL Information Transfer + NAS : Authentication Request
- RRC : UL Information Transfer + NAS : Authentication Response
- RRC : DL Information Transfer + NAS : Security Mode Command
- RRC : UL Information Transfer + NAS : Security Mode Complete
- RRC : Security Mode Command
- RRC : Security Mode Complete
- RRC : UE Capability Enquiry
- RRC : UE Capability Information
- RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Request
- RRC : RRC Connection Reconfiguration Complete + NAS : AttachComplete + ESM : Activate Default EPS Bearer Context Accept
- RRC : RRC Connection Request
- RRC : RRC Connection Setup
- RRC : RRC Connection Setup Complete + NAS : Service Request
- RRC : Security Mode Command
- RRC : Security Mode Complete
- RRC : RRC Connection Reconfiguration + NAS : Activate Dedicated EPS Bearer Context Request
- RRC : RRC Connection Reconfiguration Complete + NAS : Activate Dedicated EPS Bearer Context Accept
Typical Packet Call
Following is the over protocal sequence being exchanged between UE and Network. Actually understanding all the details of these steps would be the goal of your whole LTE career.
1) <Cell Search and Detection>
2) MIB
3) SIB 1
4) <Check Cell Selection Criteria>
8) RRC : RRC Connection Request
10) RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request
11) RRC : DL Information Transfer + NAS : Authentication Request
12) RRC : UL Information Transfer + NAS : Authentication Response
13) RRC : DL Information Transfer + NAS : Security Mode Command
14) RRC : UL Information Transfer + NAS : Security Mode Complete
15) RRC : Security M ode Command
16) RRC : Security Mode Complete
O1) RRC : UE Capability Enquiry
O2) RRC : UE Capability Information
O3) ESM : ESM Information Request
O4) ESM : ESM Information Response
O5) EMM : EMM Identity Request
O6) EMM : EMM Identity Response
O7) EMM : EMM Information
19) RRC : RRC Connection Release
20) <Perform Neibourcell Measurement>
21) <Check Cell Reselection Criteria >
22) < MO or MT call > : In MT call, Paging should be sent.
25) RRC : RRC Connection Request
26) RRC : RRC Connection Setup
27) RRC : RRC Connection Setup Complete + NAS : Service Request
28) RRC : Security Mode Command
29) RRC : Security Mode Complete
30) RRC : RRC Connection Reconfiguration + NAS : Activate Dedicated EPS Bearer Context Request
31) RRC : RRC Connection Reconfiguration Complete + NAS : Activate Dedicated EPS Bearer Context Accept
32) RRC : RRC Connection Release
MIB
The MIB is the first thing a UE decodes once it has found the cell, and everything after it depends on what it says. It rides on PBCH rather than on a shared channel, so nothing has to be decoded first in order to find it, and it cannot be made larger. That constraint is what keeps its contents so small.
MIB in LTE has very minimal information (This is a big difference from WCDMA MIB) . The only information it carries are
- i) BandWidth
- ii) PHICH
- iii) SystemFrameNumber
Of course the most important information is "BandWidth".
According to 36.331 section 5.2.1.2, the MIB scheduling is as follows :
The MIB uses a fixed schedule with a periodicity of 40 ms and repetitions made within 40 ms. The first transmission ofthe MIB is scheduled in subframe #0 of radio frames for which the SFN mod 4 = 0, and repetitions are scheduled insubframe #0 of all other radio frames.
Two things are worth adding to that list. The first is what the bandwidth field actually says. 36.331 codes dl-Bandwidth as an enumeration of n6, n15, n25, n50, n75 and n100, and those are resource blocks rather than megahertz. A UE reading n25 has learned that the carrier is 25 resource blocks wide, and it works out the 5 MHz for itself.
The second is the frame number. 36.331 defines systemFrameNumber as a BIT STRING of size 8, and says it carries the 8 most significant bits of the SFN. The SFN counts to 1023, so two bits are missing. The UE recovers them from position. The MIB repeats four times inside its 40 ms period, and which repetition the UE decoded supplies the remaining two bits. That is one reason the schedule has to be fixed rather than signalled.
The three-field list is also a Release 8 list. Later releases added schedulingInfoSIB1-BR for bandwidth-reduced UEs, systemInfoUnchanged-BR, and partEARFCN, all fitted into the spare bits the original design left. A MIB decoded from a modern eNB can therefore show more than three fields.
The MIB has to be readable before anything else : it rides on PBCH with a fixed schedule, so nothing needs decoding first in order to find it.dl-Bandwidth counts resource blocks, not megahertz : 36.331 enumerates n6 to n100, and the UE converts that to a channel bandwidth itself.Two bits of the SFN are never transmitted : the field carries the 8 most significant bits, and the repetition the UE decoded supplies the other two.Three fields is the Release 8 answer : schedulingInfoSIB1-BR, systemInfoUnchanged-BR and partEARFCN were added later into the spare bits.
SIB 1
SIB1 is the second thing the UE reads, and it answers two unrelated questions at once. It says whether the UE may camp on this cell at all, and it says where every other SIB is scheduled. The scheduling job is why nothing else can be read until SIB1 has been.
SIB 1 in LTE contains the information like the ones in WCDMA MIB & SIB1 & SIB3. The important information on SIB 1 is
- i) PLMN
- ii) Tracking Area Code
- iii) Cell Selection Info
- iv) Frequency Band Indicator
- v) Scheduling information (periodicity) of other SIBs
You may notice that LTE SIB1 is very similar to WCDMA MIB.
Especially at initial test case development, you have to be very careful about item v). If you set this value incorrectly, all the other SIBs will not be decoded by UE. And as a result, UE would not recognize the cell and show "No Service" message.
According to 36.331 section 5.2.1.2, the SIB1 scheduling is as follows :
The SystemInformationBlockType1 uses a fixed schedule with a periodicity of 80 ms and repetitions made within 80 ms.The first transmission of SystemInformationBlockType1 is scheduled in subframe #5 of radio frames for which the SFNmod 8 = 0, and repetitions are scheduled in subframe #5 of all other radio frames for which SFN mod 2 = 0.
This means that even though SIB1 periodicity is 80 ms, different copies (Redudancy version : RV) of the SIB1 is transmitted every 20ms. Meaning that at L3 you will see the SIB1 every 80 ms, but at PHY layer you will see it every 20ms. For the detailed RV assignment for each transmission, refer to 36.321 section 5.3.1 (the last part of the section)
One example of LTE SIB1 is as follows :
< BCCH-DL-SCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
RRC_LTE:BCCH-DL-SCH-Message
BCCH-DL-SCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [systemInformationBlockType1]
+-systemInformationBlockType1 ::= SEQUENCE [000]
+-cellAccessRelatedInfo ::= SEQUENCE [0]
| +-plmn-IdentityList ::= SEQUENCE OF SIZE(1..6) [1]
| | +-PLMN-IdentityInfo ::= SEQUENCE
| | +-plmn-Identity ::= SEQUENCE [1]
| | | +-mcc ::= SEQUENCE OF SIZE(3) OPTIONAL:Exist
| | | | +-MCC-MNC-Digit ::= INTEGER (0..9) [0]
| | | | +-MCC-MNC-Digit ::= INTEGER (0..9) [0]
| | | | +-MCC-MNC-Digit ::= INTEGER (0..9) [1]
| | | +-mnc ::= SEQUENCE OF SIZE(2..3) [2]
| | | +-MCC-MNC-Digit ::= INTEGER (0..9) [0]
| | | +-MCC-MNC-Digit ::= INTEGER (0..9) [1]
| | +-cellReservedForOperatorUse ::= ENUMERATED [notReserved]
| +-trackingAreaCode ::= BIT STRING SIZE(16) [0000000000000001]
| +-cellIdentity ::= BIT STRING SIZE(28) [0000000000000000000100000000]
| +-cellBarred ::= ENUMERATED [notBarred]
| +-intraFreqReselection ::= ENUMERATED [notAllowed]
| +-csg-Indication ::= BOOLEAN [FALSE]
| +-csg-Identity ::= BIT STRING OPTIONAL:Omit
+-cellSelectionInfo ::= SEQUENCE [0]
| +-q-RxLevMin ::= INTEGER (-70..-22) [-53]
| +-q-RxLevMinOffset ::= INTEGER OPTIONAL:Omit
+-p-Max ::= INTEGER OPTIONAL:Omit
+-freqBandIndicator ::= INTEGER (1..64) [7]
+-schedulingInfoList ::= SEQUENCE OF SIZE(1..maxSI-Message[32]) [2]
| +-SchedulingInfo ::= SEQUENCE
| | +-si-Periodicity ::= ENUMERATED [rf8]
| | +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [0]
| +-SchedulingInfo ::= SEQUENCE
| +-si-Periodicity ::= ENUMERATED [rf8]
| +-sib-MappingInfo ::= SEQUENCE OF SIZE(0..maxSIB-1[31]) [1]
| +-SIB-Type ::= ENUMERATED [sibType3]
+-tdd-Config ::= SEQUENCE OPTIONAL:Omit
+-si-WindowLength ::= ENUMERATED [ms20]
+-systemInfoValueTag ::= INTEGER (0..31) [0]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
SIB 2
SIB2 is where the cell stops describing itself and starts telling the UE how to transmit. Every common channel the UE needs before it has a dedicated configuration is parameterised here. That is why a mistake in SIB2 usually appears as a RACH that never completes, rather than as anything that names SIB2.
The important information on SIB2 is
- i) RACH Configuration
- ii) bcch, pcch, pdsch, pusch, pucch configuration
- iii) sounding RS Configuration
- iv) UE Timers
I would say SIB2 is the most important SIB in LTE and you will look into this SIB most frequently when you are implementing protocol stack and troubleshooting, since it defines the characteristics of the most physical channels.
If you have some issues at registration process especially before 'RRC Connection Reconfiguration'. The first part you have to check is SIB2 and check if UE properly decoded this and properly configure UE according to SIB2. Sometimes only one parameter mismatch of SIB2 between Network and UE can make difference between success and failure of the whole registration process.
Following is one example of SIB2. I looks to me that LTE SIB2 is similar to WCDMA SIB5 configuring various common channel.
< BCCH-DL-SCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
RRC_LTE:BCCH-DL-SCH-Message
BCCH-DL-SCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [systemInformation]
+-systemInformation ::= SEQUENCE
+-criticalExtensions ::= CHOICE [systemInformation-r8]
+-systemInformation-r8 ::= SEQUENCE [0]
+-sib-TypeAndInfo ::= SEQUENCE OF SIZE(1..maxSIB[32]) [1]
| +- ::= CHOICE [sib2]
| +-sib2 ::= SEQUENCE [00]
| +-ac-BarringInfo ::= SEQUENCE OPTIONAL:Omit
| +-radioResourceConfigCommon ::= SEQUENCE
| | +-rach-Config ::= SEQUENCE
| | | +-preambleInfo ::= SEQUENCE [0]
| | | | +-numberOfRA-Preambles ::= ENUMERATED [n52]
| | | | +-preamblesGroupAConfig ::= SEQUENCE OPTIONAL:Omit
| | | +-powerRampingParameters ::= SEQUENCE
| | | | +-powerRampingStep ::= ENUMERATED [dB2]
| | | | +-preambleInitialReceivedTargetPower ::= ENUMERATED [dBm-104]
| | | +-ra-SupervisionInfo ::= SEQUENCE
| | | | +-preambleTransMax ::= ENUMERATED [n6]
| | | | +-ra-ResponseWindowSize ::= ENUMERATED [sf10]
| | | | +-mac-ContentionResolutionTimer ::= ENUMERATED [sf48]
| | | +-maxHARQ-Msg3Tx ::= INTEGER (1..8) [4]
| | +-bcch-Config ::= SEQUENCE
| | | +-modificationPeriodCoeff ::= ENUMERATED [n4]
| | +-pcch-Config ::= SEQUENCE
| | | +-defaultPagingCycle ::= ENUMERATED [rf128]
| | | +-nB ::= ENUMERATED [oneT]
| | +-prach-Config ::= SEQUENCE
| | | +-rootSequenceIndex ::= INTEGER (0..837) [22]
| | | +-prach-ConfigInfo ::= SEQUENCE
| | | +-prach-ConfigIndex ::= INTEGER (0..63) [3]
| | | +-highSpeedFlag ::= BOOLEAN [FALSE]
| | | +-zeroCorrelationZoneConfig ::= INTEGER (0..15) [5]
| | | +-prach-FreqOffset ::= INTEGER (0..94) [2]
| | +-pdsch-Config ::= SEQUENCE
| | | +-referenceSignalPower ::= INTEGER (-60..50) [18]
| | | +-p-b ::= INTEGER (0..3) [0]
| | +-pusch-Config ::= SEQUENCE
| | | +-pusch-ConfigBasic ::= SEQUENCE
| | | | +-n-SB ::= INTEGER (1..4) [1]
| | | | +-hoppingMode ::= ENUMERATED [interSubFrame]
| | | | +-pusch-HoppingOffset ::= INTEGER (0..98) [4]
| | | | +-enable64QAM ::= BOOLEAN [FALSE]
| | | +-ul-ReferenceSignalsPUSCH ::= SEQUENCE
| | | +-groupHoppingEnabled ::= BOOLEAN [TRUE]
| | | +-groupAssignmentPUSCH ::= INTEGER (0..29) [0]
| | | +-sequenceHoppingEnabled ::= BOOLEAN [FALSE]
| | | +-cyclicShift ::= INTEGER (0..7) [0]
| | +-pucch-Config ::= SEQUENCE
| | | +-deltaPUCCH-Shift ::= ENUMERATED [ds2]
| | | +-nRB-CQI ::= INTEGER (0..98) [2]
| | | +-nCS-AN ::= INTEGER (0..7) [6]
| | | +-n1PUCCH-AN ::= INTEGER (0..2047) [0]
| | +-soundingRS-UL-Config ::= CHOICE [setup]
| | | +-setup ::= SEQUENCE [0]
| | | +-srs-BandwidthConfig ::= ENUMERATED [bw3]
| | | +-srs-SubframeConfig ::= ENUMERATED [sc0]
| | | +-ackNackSRS-SimultaneousTransmission ::= BOOLEAN [TRUE]
| | | +-srs-MaxUpPts ::= ENUMERATED OPTIONAL:Omit
| | +-uplinkPowerControl ::= SEQUENCE
| | | +-p0-NominalPUSCH ::= INTEGER (-126..24) [-85]
| | | +-alpha ::= ENUMERATED [al08]
| | | +-p0-NominalPUCCH ::= INTEGER (-127..-96) [-117]
| | | +-deltaFList-PUCCH ::= SEQUENCE
| | | | +-deltaF-PUCCH-Format1 ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format1b ::= ENUMERATED [deltaF3]
| | | | +-deltaF-PUCCH-Format2 ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format2a ::= ENUMERATED [deltaF0]
| | | | +-deltaF-PUCCH-Format2b ::= ENUMERATED [deltaF0]
| | | +-deltaPreambleMsg3 ::= INTEGER (-1..6) [4]
| | +-ul-CyclicPrefixLength ::= ENUMERATED [len1]
| +-ue-TimersAndConstants ::= SEQUENCE
| | +-t300 ::= ENUMERATED [ms1000]
| | +-t301 ::= ENUMERATED [ms1000]
| | +-t310 ::= ENUMERATED [ms1000]
| | +-n310 ::= ENUMERATED [n1]
| | +-t311 ::= ENUMERATED [ms1000]
| | +-n311 ::= ENUMERATED [n1]
| +-freqInfo ::= SEQUENCE [00]
| | +-ul-CarrierFreq ::= INTEGER OPTIONAL:Omit
| | +-ul-Bandwidth ::= ENUMERATED OPTIONAL:Omit
| | +-additionalSpectrumEmission ::= INTEGER (1..32) [1]
| +-mbsfn-SubframeConfigList ::= SEQUENCE OF OPTIONAL:Omit
| +-timeAlignmentTimerCommon ::= ENUMERATED [sf750]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
RRC : PRACH Preamble / RRC : RACH Response
These two steps are the first time the UE transmits anything at all. Until now it has only listened, so the network does not know it exists and the UE has no uplink timing. RACH settles both at once, and the diagram below traces one exchange from preamble to response.
I think this two steps can be best summerized by the following diagram. For the details, refer to RACH_LTE
The two decodes on the right of the diagram are worth following field by field, because together they show the one check that makes the response usable. In the upper box the UE has sent PreambleIndex 15. In the lower box the Random Access Response carries RAPID 15, and the drawing links the two with a dashed line.
That match is the whole of the check. A Random Access Response is addressed to the RA-RNTI, which the drawing derives from the preamble's time and frequency slot, so every UE that used that slot reads the same message. Each one compares the RAPID against the preamble it sent, and only the UE that finds its own index treats the grant as its own. The T field set to 1 just above it is what marks the subheader as carrying a RAPID rather than a backoff value.
The rest of the lower box is the grant itself. RARGrant holds the uplink resource for the UE's next transmission, with RIV 250 and Truncated-MCS 8 in this capture. T-C-RNTI FFF2 is the temporary identity the UE uses until contention resolution has finished.
RAPID has to equal the preamble the UE sent : the capture shows PreambleIndex 15 answered by RAPID 15, and that is how a UE knows the response is its own.One response can be read by many UEs : the RAR is addressed to the RA-RNTI rather than to a UE, so the RAPID check is what separates them.The response carries a grant and a temporary identity : RARGrant gives the uplink resource and T-C-RNTI gives the identity used until contention resolution ends.
Interim Comments
From this point on, the L3 message carries both RRC and NAS messages. So you need to have overall understanding of NAS messages as well as RRC messages.
You need to understand all the details of TS 29.274 to handle to handle data traffic related IEs in NAS message. Of course it would be impossible to understand all those details within a day.. my approach is to go through following tables as often as possible until I get some big picture in my mind. You may have to go back and forth between 36.331 and 29.274.
- Table 7.2.2-1: Information Elements in a Create Session Response
- Table 7.2.3-1: Information Elements in a Create Bearer Request
- Table 7.2.3-2: Bearer Context within Create Bearer Request
- Table 7.2.5-1: Information Elements in a Bearer Resource Command
- Table 7.2.7-1: Information Elements in a Modify Bearer Request
- Table 7.2.8-1: Information Elements in a Modify Bearer Response
- Table 7.2.9.1-1: Information Elements in a Delete Session Request
- Table 7.2.9.2-1: Information Elements in a Delete Bearer Request
- Table 7.2.10.2-1: Information Elements in Delete Bearer Response
- Table 7.3.5-1: Information Elements in a Context Request
- Table 7.3.6-2: MME/SGSN UE EPS PDN Connections within Context Response
- Table 7.3.8-1: Information Elements in an Identification Request
RRC : RRC Connection Request
'RRC Connection Request' and 'RRC Connection Setup' procedure can be summerized as in following diagram. For the details, refer to RACH_LTE.html (The message contents shown in the box is only an example. The HEX arrays you would see on your device and network would be different from what you see here. But overall structure should be similar to this)
The lower decode in the diagram is where contention resolution happens, and the detail that shows it is small. Look at the first six bytes of the RRC Connection Setup message, 53 01 E0 E6 D3 D6. Those are the same six bytes that open the RRC Connection Request above it, and the callout in the drawing names them as the UE ID for contention resolution.
That echo is the mechanism. Two UEs can choose the same preamble in the same slot, read the same Random Access Response, and send their own RRC Connection Request on the same grant. Only one of them survives, and the network settles it by repeating one of those requests back word for word. A UE that does not see its own bits returned knows it lost, and starts the procedure again.
The identity in this capture is a randomValue rather than an S-TMSI, which is what a UE with nothing stored has to use. The establishmentCause is mo-Signalling here, and the second pass further down this page shows the same field carrying mo-Data or mt-Access instead.
Contention resolution echoes the request : the six bytes 53 01 E0 E6 D3 D6 that open the Connection Request come back at the head of the Setup.Losing is silent : a UE that does not see its own identity returned simply starts the procedure again.ue-Identity is a random value when nothing is stored : a registered UE sends its S-TMSI instead, which the second pass shows.
RRC : RRC Connection Setup
As you see in the following diagram, the most important IE (infomration element) in RRC Connection Setup message is "RadioResourceConfigDedicated" under which you can setup SRB, DRB, MAC and PHY config. Even thouth there is IEs related to DRB, in most case we setup only SRBs in RRC Connection Setup. It is similar to WCDMA RRC Connection setup message in which you usually setup only SRB (Control Channel Part) even though there is IEs for RB(Data Traffic).
One thing you have to notice is that you will find "RadioResourceCondigDedicated" IE not only in RRC Connection Setup message but also in RRC Connection Reconfiguration message. In that case, you have to be careful so that the one you set in RRC Connection Reconfig message properly match the one you set in RRC Connection Setup message. It means that you have to understand the correlation very clearly between RRC Connection Setup message and RRC Connection Reconfig message. This is also very similar to WCDMA case.
One example of RRC Connection Setup is as follows. As you see the contents below, main purpose of RRC Connection Setup message is to specify the MAC/RLC/PHY setup for SRB 0 and SRB 1 bearer. So if you make any mistake in this message, Network or UE will fail to decode messages that comes after this message.
Especially you have to be very careful about PhysicalConfigDedicated part. If you see one of the following issues after 'RRC Connection Setup', the first thing you have to check is PhysicalConfigDedicated. (You have to check all the detailed parameter and make it sure that UE properly decoded those information and properly configure itself according to the contents).
- i) CRC Error for PUSCH
- ii) UE log shows it transmit PUSCH, but Network log shows no PUSCH, not even CRC error
< DL-CCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
DL-CCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionSetup]
+-rrcConnectionSetup ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionSetup-r8]
+-rrcConnectionSetup-r8 ::= SEQUENCE [0]
+-radioResourceConfigDedicated ::= SEQUENCE [100101]
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| | +-SRB-ToAddMod ::= SEQUENCE [11]
| | +-srb-Identity ::= INTEGER (1..2) [1]
| | +-rlc-Config ::= CHOICE [defaultValue] OPTIONAL:Exist
| | | +-defaultValue ::= NULL
| | +-logicalChannelConfig ::= CHOICE [defaultValue] OPTIONAL:Exist
| | +-defaultValue ::= NULL
| +-drb-ToAddModList ::= SEQUENCE OF OPTIONAL:Omit
| +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit
| +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist
| | +-explicitValue ::= SEQUENCE [111]
| | +-ul-SCH-Config ::= SEQUENCE [11] OPTIONAL:Exist
| | | +-maxHARQ-Tx ::= ENUMERATED [n5] OPTIONAL:Exist
| | | +-periodicBSR-Timer ::= ENUMERATED [sf20] OPTIONAL:Exist
| | | +-retxBSR-Timer ::= ENUMERATED [sf320]
| | | +-ttiBundling ::= BOOLEAN [FALSE]
| | +-drx-Config ::= CHOICE [release] OPTIONAL:Exist
| | | +-release ::= NULL
| | +-timeAlignmentTimerDedicated ::= ENUMERATED [infinity]
| | +-phr-Config ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-periodicPHR-Timer ::= ENUMERATED [sf500]
| | +-prohibitPHR-Timer ::= ENUMERATED [sf200]
| | +-dl-PathlossChange ::= ENUMERATED [dB3]
| +-sps-Config ::= SEQUENCE OPTIONAL:Omit
| +-physicalConfigDedicated ::= SEQUENCE [1111001011] OPTIONAL:Exist
| +-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Exist
| | +-p-a ::= ENUMERATED [dB-3]
| +-pucch-ConfigDedicated ::= SEQUENCE [0] OPTIONAL:Exist
| | +-ackNackRepetition ::= CHOICE [release]
| | | +-release ::= NULL
| | +-tdd-AckNackFeedbackMode ::= ENUMERATED OPTIONAL:Omit
| +-pusch-ConfigDedicated ::= SEQUENCE OPTIONAL:Exist
| | +-betaOffset-ACK-Index ::= INTEGER (0..15) [9]
| | +-betaOffset-RI-Index ::= INTEGER (0..15) [6]
| | +-betaOffset-CQI-Index ::= INTEGER (0..15) [6]
| +-uplinkPowerControlDedicated ::= SEQUENCE [1] OPTIONAL:Exist
| | +-p0-UE-PUSCH ::= INTEGER (-8..7) [0]
| | +-deltaMCS-Enabled ::= ENUMERATED [en0]
| | +-accumulationEnabled ::= BOOLEAN [TRUE]
| | +-p0-UE-PUCCH ::= INTEGER (-8..7) [0]
| | +-pSRS-Offset ::= INTEGER (0..15) [3]
| | +-filterCoefficient ::= ENUMERATED [fc4] OPTIONAL:Exist
| +-tpc-PDCCH-ConfigPUCCH ::= CHOICE OPTIONAL:Omit
| +-tpc-PDCCH-ConfigPUSCH ::= CHOICE OPTIONAL:Omit
| +-cqi-ReportConfig ::= SEQUENCE [10] OPTIONAL:Exist
| | +-cqi-ReportModeAperiodic ::= ENUMERATED [rm30] OPTIONAL:Exist
| | +-nomPDSCH-RS-EPRE-Offset ::= INTEGER (-1..6) [0]
| | +-cqi-ReportPeriodic ::= CHOICE OPTIONAL:Omit
| +-soundingRS-UL-ConfigDedicated ::= CHOICE OPTIONAL:Omit
| +-antennaInfo ::= CHOICE [defaultValue] OPTIONAL:Exist
| | +-defaultValue ::= NULL
| +-schedulingRequestConfig ::= CHOICE [setup] OPTIONAL:Exist
| +-setup ::= SEQUENCE
| +-sr-PUCCH-ResourceIndex ::= INTEGER (0..2047) [20]
| +-sr-ConfigIndex ::= INTEGER (0..155) [30]
| +-dsr-TransMax ::= ENUMERATED [n4]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
+-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Exist
| +-p-a ::= ENUMERATED [dB-3]
: transmission power is calculated according to Section 5.2 of 3GPP TS36.213 from the reference signal power and the values of the P_A and P_B parameters specified for this procedure. These parameters set the PDSCH transmission power differences between symbols with and without RS.
Unproper settings for this value would cause large amount of CRC errors on PDSCH reception on UE side, resulting in a lot of HARQ NACK from UE.
If you see SRB-ToAddMod IE, you would see a couple of Default Value. What does this mean ?
Following two sections of 36.331 will give you the answer.
- 9.1.2 SRB configurations
- 9.2 Default radio configurations
RRC : RRC Connection Setup Complete + NAS : Attach Request + ESM : PDN Connectivity Request
This step would be one of very important steps during the initial registration process mainly because UE send a lot of it's capability information (especailly NAS layer capability information) to the core network.
As you see this step carries two important NAS message as follows.
< Attach request > decoded message capture. Field values come from a live capture, not from the specification.
Attach request ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Attach request message identity ::= V
| +-Message type ::= MSG [41]
+-NAS key set identifier ::= V
| +-TSC ::= CHOICE [native security context (for KSI ASME)]
| +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 1]
+-EPS attach type ::= V
| +-Spare ::= FIX [0]
| +-EPS attach type value ::= CHOICE [EPS attach]
+-Old GUTI or IMSI ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of EPS mobile identity contents ::= LEN (0..255) [11]
| +-Octet2 ::= DIVISION
| | +-Spare ::= FIX [F]
| | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the GUTI is used]
| | +-Type of identity ::= CHOICE [GUTI]
| +-Octet3 ::= DIVISION
| | +-MCC digit 2 ::= INT (0..15) [0]
| | +-MCC digit 1 ::= INT (0..15) [0]
| +-Octet4 ::= DIVISION
| | +-MNC digit 3 ::= INT (0..15) [15]
| | +-MCC digit 3 ::= INT (0..15) [1]
| +-Octet5 ::= DIVISION
| | +-MNC digit 2 ::= INT (0..15) [1]
| | +-MNC digit 1 ::= INT (0..15) [0]
| +-Octet6 ::= DIVISION
| | +-MME Group ID ::= INT (0..255) [0]
| +-Octet7 ::= DIVISION
| | +-MME Group ID(continued) ::= INT (0..255) [1]
| +-Octet8 ::= DIVISION
| | +-MME Code ::= INT (0..255) [1]
| +-Octet9 ::= DIVISION
| | +-M-TMSI ::= INT (0..255) [18]
| +-Octet10 ::= DIVISION
| | +-M-TMSI(continued) ::= INT (0..255) [52]
| +-Octet11 ::= DIVISION
| | +-M-TMSI(continued) ::= INT (0..255) [86]
| +-Octet12 ::= DIVISION
| +-M-TMSI(continued) ::= INT (0..255) [120]
+-UE network capability ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of UE network capability contents ::= LEN (0..255) [2]
| +-Octet2 ::= DIVISION
| | +-EEA0 ::= CHOICE [EPS encryption algorithm EEA0 supported]
| | +-128-EEA1 ::= CHOICE [EPS encryption algorithm 128-EEA1 supported]
| | +-128-EEA2 ::= CHOICE [EPS encryption algorithm 128-EEA2 supported]
| | +-EEA3 ::= CHOICE [EPS encryption algorithm EEA3 not supported]
| | +-EEA4 ::= CHOICE [EPS encryption algorithm EEA4 not supported]
| | +-EEA5 ::= CHOICE [EPS encryption algorithm EEA5 not supported]
| | +-EEA6 ::= CHOICE [EPS encryption algorithm EEA6 not supported]
| | +-EEA7 ::= CHOICE [EPS encryption algorithm EEA7 not supported]
| +-Octet3 ::= DIVISION
| | +-spare ::= FIX [0]
| | +-128-EIA1 ::= CHOICE [EPS integrity algorithm 128-EIA1 supported]
| | +-128-EIA2 ::= CHOICE [EPS integrity algorithm 128-EIA2 supported]
| | +-EIA3 ::= CHOICE [EPS integrity algorithm EIA3 not supported]
| | +-EIA4 ::= CHOICE [EPS integrity algorithm EIA4 not supported]
| | +-EIA5 ::= CHOICE [EPS integrity algorithm EIA5 not supported]
| | +-EIA6 ::= CHOICE [EPS integrity algorithm EIA6 not supported]
| | +-EIA7 ::= CHOICE [EPS integrity algorithm EIA7 not supported]
| +-Octet4 ::= DIVISION
| | +-UEA0 ::= CHOICE [UMTS encryption algorithm UEA0 not supported]
| | +-UEA1 ::= CHOICE [UMTS encryption algorithm UEA1 not supported]
| | +-UEA2 ::= CHOICE [UMTS encryption algorithm UEA2 not supported]
| | +-UEA3 ::= CHOICE [UMTS encryption algorithm UEA3 not supported]
| | +-UEA4 ::= CHOICE [UMTS encryption algorithm UEA4 not supported]
| | +-UEA5 ::= CHOICE [UMTS encryption algorithm UEA5 not supported]
| | +-UEA6 ::= CHOICE [UMTS encryption algorithm UEA6 not supported]
| | +-UEA7 ::= CHOICE [UMTS encryption algorithm UEA7 not supported]
| +-Octet5 ::= DIVISION
| | +-UCS2 ::= CHOICE [The UE has a preference for the default alphabet (defined in 3GPP TS 23.038 [3]) over UCS2 (see ISO/IEC 10646 [29])]
| | +-UIA1 ::= CHOICE [UMTS integrity algorithm UIA1 not supported]
| | +-UIA2 ::= CHOICE [UMTS integrity algorithm UIA2 not supported]
| | +-UIA3 ::= CHOICE [UMTS integrity algorithm UIA3 not supported]
| | +-UIA4 ::= CHOICE [UMTS integrity algorithm UIA4 not supported]
| | +-UIA5 ::= CHOICE [UMTS integrity algorithm UIA5 not supported]
| | +-UIA6 ::= CHOICE [UMTS integrity algorithm UIA6 not supported]
| | +-UIA7 ::= CHOICE [UMTS integrity algorithm UIA7 not supported]
| +-Octet6 ::= DIVISION
| | +-spare ::= FIX [0]
| | +-1xSRVCC ::= CHOICE [SRVCC from E-UTRAN to cdma2000 1xCS not supported]
| | +-spare ::= FIX [0]
| +-Octet7-14 ::= DIVISION
| +-Spare ::= OCTETARRAY SIZE(0..8) [00]
+-ESM message container ::= LV-E
| +-Octet1-Octet2 ::= DIVISION
| | +-Length of ESM message container ::= LEN (0..65535) [23]
| +-Octet3- ::= DIVISION
| +-ESM message container contents ::= OCTETARRAY SIZE(0..65535)
[0201D031D1271080000100000300000A00000C00000D00]
+-Old P-TMSI signature ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-P-TMSI signature IEI ::= IEI [19]
| +-Octet2-4 ::= DIVISION
| +-P-TMSI signature value ::= INT (0..16777215) [0]
+-Additional GUTI ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-EPS mobile identity IEI ::= IEI [50]
| +-Octet2 ::= DIVISION
| | +-Length of mobile identity IEI ::= LEN (0..255) [1]
| +-Octet3 ::= DIVISION
| | +-Identity digit 1 ::= INT (0..15) [0]
| | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the GUTI is used]
| | +-Type of identity ::= CHOICE [IMSI]
| +-Octet4 ::= DIVISION
| +-Identity digit p ::= OCTETARRAY SIZE(0..10)
+-Last visited registered TAI ::= TV OPTIONAL:Exist
| +-Octet1 ::= DIVISION
| | +-Tracking area identity IEI ::= IEI [52]
| +-Octet2 ::= DIVISION
| | +-MCC digit 2 ::= INT (0..15) [1]
| | +-MCC digit 1 ::= INT (0..15) [3]
| +-Octet3 ::= DIVISION
| | +-MNC digit 3 ::= INT (0..15) [0]
| | +-MCC digit 3 ::= INT (0..15) [1]
| +-Octet4 ::= DIVISION
| | +-MNC digit 2 ::= INT (0..15) [8]
| | +-MNC digit 1 ::= INT (0..15) [4]
| +-Octet5 ::= DIVISION
| | +-TAC ::= INT (0..255) [0]
| +-Octet6 ::= DIVISION
| +-TAC(continued) ::= INT (0..255) [1]
+-DRX parameter ::= TV OPTIONAL:Omit
+-MS network capability ::= TLV OPTIONAL:Omit
+-Old location area identification ::= TV OPTIONAL:Omit
+-TMSI status ::= TV OPTIONAL:Omit
+-Mobile Station Classmark 2 ::= TLV OPTIONAL:Omit
+-Mobile Station Classmark 3 ::= TLV OPTIONAL:Omit
+-Supported Codecs ::= TLV OPTIONAL:Omit
If you decode the ESM message container contents part, you will get the following contents.
< PDN connectivity request > decoded message capture. Field values come from a live capture, not from the specification.
NAS_LTE:ESM,PDN connectivity request
PDN connectivity request ::= DIVISION
+-EPS bearer identity ::= V
| +-EPS bearer identity value ::= CHOICE [No EPS bearer identity assigned]
+-EPS session management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [2]
+-Procedure transaction identity ::= V
| +-Procedure transaction identity ::= CHOICE [Procedure transaction identity value 1]
+-PDN connectivity request message identity ::= V
| +-Message type ::= MSG [D0]
+-PDN type ::= V
| +-spare ::= FIX [0]
| +-PDN type value ::= CHOICE [IPv4v6]
+-Request type ::= V
| +-Spare ::= FIX [0]
| +-Request type value ::= CHOICE [initial request]
+-ESM information transfer flag ::= TV OPTIONAL:Exist
| +-Octet1 ::= DIVISION
| +-ESM information transfer flag IEI ::= IEI [D-]
| +-spare ::= FIX [0]
| +-EIT value ::= CHOICE [security protected ESM information transfer required]
+-Access point name ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Access point name IEI ::= IEI [28]
| +-Octet2 ::= DIVISION
| | +-Length of access point name contents ::= LEN (0..255) [0]
| +-Octet3-Octet102 ::= DIVISION
| +-Access point name value ::= OCTETARRAY SIZE(0..100)
+-Protocol configuration options ::= TLV OPTIONAL:Exist
+-Octet1 ::= DIVISION
| +-Protocol configuration options IEI ::= IEI [27]
+-Octet2 ::= DIVISION
| +-Length of protocol config options contents ::= LEN (0..255) [16]
+-Octet3 ::= DIVISION
| +-ext ::= EXT1 [1]
| +-spare ::= FIX [0]
| +-Configuration protocol ::= CHOICE [PPP for use with IP PDP type]
+-Octet4-Octet253 ::= DIVISION
+-protocol config options contents ::= OCTETARRAY SIZE(0..250) [000100000300000A00000C00000D00]
There are couple of important information in this message as described below.
IF the UE sets the ESM information transfer flag in the last PDN CONNECTIVITY REQUEST message THEN the SS transmits an ESM INFORMATION REQUEST message to initiate exchange of protocol configuration options and/or APN
- i) UE does not specify any APN here and accept whatever Network specifies in Activate Default EPS Bearer Context Request.
- ii) UE specify a specific APN here, but it accept whatever Network specifies in Activate Default EPS Bearer Context Request.
- iii) UE specify a specific APN here, but it reject the APN that Network specifies in Activate Default EPS Bearer Context Request if it is different from what UE specified here.
This is a pretty complicated topic. So I will describe this on a separate post here.
RRC : DL Information Transfer + NAS : Authentication Request
This step is the first time the network challenges the UE. Everything up to here has been configuration, and either side could have been anyone. The Authentication Request ends that. The message itself is small, because almost all of the work happens inside the USIM after it arrives.
It travels as a NAS payload inside an RRC DL Information Transfer, which is the pattern every NAS message follows once a connection exists. RRC carries the bytes and never reads them.
Three values matter in it. RAND is the random challenge. AUTN is the authentication token the UE checks before it answers, and it is what makes the authentication mutual rather than one-sided. KSI_ASME is a short label for the security context this run will produce, so a later procedure can name that context without repeating the exchange.
The UE does not answer straight away. It hands RAND and AUTN to the USIM, which verifies AUTN before it computes anything, and only a valid AUTN produces the RES that the next step carries back. Authentication covers the check in full, and Authentication Failure covers what the UE sends when it fails.
NAS rides inside RRC : DL Information Transfer carries the bytes, and RRC never interprets them.RAND and AUTN travel together : the challenge and the token the UE uses to check the network arrive in the same message.The UE verifies before it answers : the USIM checks AUTN first, so a failed check produces a failure message rather than a RES.
RRC : UL Information Transfer + NAS : Authentication Response
"Authentication" process is a process similar to 'log in' process when you use a computer. In C2K and GSM, this authentication process is 'uni-directional', meaning that only Network authenticate UE and UE does not authenticate the network. As you may easily guess, this would cause a serious security problem. If I make a fake network which accept any UE, I can cheat a UE to camp on the fake network rather than the one the UE is supposed to camp on to. (But this kind of 'uni directional' authentication would make it so easy to test a UE using network simulator -:)
To improve this security issues, in LTE (in WCDMA as well) they do 'bi-directional' authentication, meaning that UE has to pass the authentication process and Newtork also has to pass the process as well.
The overall authentication process is as follows.
There are three main components of this authentication process :
- i) Input Parameters
- ii) Authentication Algorithm
- iii) Output Values (calcuated by Authentication Algorithm using the Input Parameters).
Both UE and Network uses the same Input Parameters and the same Authentication Algorithms, so they both should produce the same Output Values, otherwise Authentication fails.
One thing you have to keep in mind is that UE and Network exchange only Input Parameters and Output values, not the authentication Algorithm. Authentication Algorithm on UE side is stored in USIM and Authentication Algorithm on NW side is stored in Authentication Center. Both UE and NW just assume that they would use the identical algorithms.
Normally use use diffent Authentication Algorithm for testing and for live network. The most commonly used algorithm for testing is what we often call "Dummy XOR" algorithm which is defined in 36.508 section 4.9 Common test USIM parameters for LTE and 34.408 section 8 Test USIM Parameters for WCDMA.
The most common used algorithm in live network (as far as I know) is Milenage algorithm.
One example of Authentication Request and Authentication Response is as follows. You would notice that RAND, AUTN are carried by Authentication Request message and RES value is carried by Authentication Response.
NAS_LTE:EMM,Authentication request
< Authentication request > decoded message capture. Field values come from a live capture, not from the specification.
Authentication request ::= DIVISION +-Security header type ::= V | +-Security header type ::= CHOICE [Plain NAS message, not security protected] +-EPS mobility management protocol discriminator ::= V | +-Protocol discriminator ::= PD [7] +-Authentication request message type ::= V | +-Message type ::= MSG [52] +-Spare half octet ::= V | +-Spare half octet ::= FIX [0] +-NAS key set identifier ASME ::= V | +-TSC ::= CHOICE [native security context (for KSI ASME)] | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0] +-Authentication parameter RAND ::= V | +-Octet1-Octet16 ::= DIVISION | +-RAND value ::= OCTETARRAY SIZE(16..16) [A3DE0C6D363E30C364A4078F1BF8D577] +-Authentication parameter AUTN ::= LV +-Octet1 ::= DIVISION | +-Length of AUTN contents ::= LEN (0..255) [16] +-Octet2-Octet17 ::= DIVISION +-AUTN ::= OCTETARRAY SIZE(0..16) [5E726B56B4EC9001A3CF2E5E726BC6B5]
NAS_LTE:EMM,Authentication response
< Authentication response > decoded message capture. Field values come from a live capture, not from the specification.
Authentication response ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Authentication response message identity ::= V
| +-Message type ::= MSG [53]
+-Authentication response parameter ::= LV
+-Octet1 ::= DIVISION
| +-Length of Authentication response parameter contents ::= LEN (0..255) [8]
+-Octet2-17 ::= DIVISION
+-RES ::= OCTETARRAY SIZE(0..16) [A3CF2E5E726B56B4]
RRC : DL Information Transfer + NAS : Security Mode Command
Authentication proved who each side is. It did not turn any protection on, and every message so far has travelled in the clear. This step is where that changes for NAS, and the command names the algorithms rather than negotiating them.
Security Mode Command message to inform the UE of the following information (instructions).
- i) I (Newtork) am capable of these kinds of ciphering (encryption) algorithms
- ii) I (Newtork) am capable of these kinds of integrity algorithms
- iii) Among those ciphering algorithm which I am capable of, I will be using "this specific algorithm" for the communication with you (UE).
- iv) Among those integrity algorithm which I am capable of, I will be using "this specific algorithm" for the communication with you (UE)
In LTE, they are using separate Security Mode process for NAS and RRC, whereas in WCDMA only one security mode process (RRC only) was used (NAS is indirectly protected since NAS message was embedded in RRC and protected as a part of RRC message). The part marked in blue is for item i) and ii) listed above and the part marked in red is for item iii) and iv).
NAS_LTE:EMM,Security mode command
< Security mode command > decoded message capture. Field values come from a live capture, not from the specification.
Security mode command ::= DIVISION +-Security header type ::= V | +-Security header type ::= CHOICE [Plain NAS message, not security protected] +-EPS mobility management protocol discriminator ::= V | +-Protocol discriminator ::= PD [7] +-Security mode command message identity ::= V | +-Message type ::= MSG [5D] +-Selected NAS security algorithms ::= V | +-Octet1 ::= DIVISION | +-spare ::= FIX [0] | +-Type of ciphering algorithm ::= CHOICE [EPS encryption algorithm EEA0(ciphering not used)] | +-spare ::= FIX [0] | +-Type of integrity protection algorithm ::= CHOICE [Reserved 0] +-Spare half octet ::= V | +-Spare half octet ::= FIX [0] +-NAS key set identifier ::= V | +-TSC ::= CHOICE [native security context (for KSI ASME)] | +-NAS key set identifier ::= CHOICE [possible values for the NAS key set identifier 0] +-Replayed UE security capabilities ::= LV | +-Octet1 ::= DIVISION | | +-Length of UE security capability contents ::= LEN (0..255) [2] | +-Octet2 ::= DIVISION | | +-EEA0 ::= CHOICE [EPS encryption algorithm EEA0 supported] | | +-128-EEA1 ::= CHOICE [EPS encryption algorithm 128-EEA1 supported] | | +-128-EEA2 ::= CHOICE [EPS encryption algorithm 128-EEA2 supported] | | +-EEA3 ::= CHOICE [EPS encryption algorithm EEA3 not supported] | | +-EEA4 ::= CHOICE [EPS encryption algorithm EEA4 not supported] | | +-EEA5 ::= CHOICE [EPS encryption algorithm EEA5 not supported] | | +-EEA6 ::= CHOICE [EPS encryption algorithm EEA6 not supported] | | +-EEA7 ::= CHOICE [EPS encryption algorithm EEA7 not supported] | +-Octet3 ::= DIVISION | | +-spare ::= FIX [1] | | +-128-EIA1 ::= CHOICE [EPS integrity algorithm 128-EIA1 supported] | | +-128-EIA2 ::= CHOICE [EPS integrity algorithm 128-EIA2 supported] | | +-EIA3 ::= CHOICE [EPS integrity algorithm EIA3 not supported] | | +-EIA4 ::= CHOICE [EPS integrity algorithm EIA4 not supported] | | +-EIA5 ::= CHOICE [EPS integrity algorithm EIA5 not supported] | | +-EIA6 ::= CHOICE [EPS integrity algorithm EIA6 not supported] | | +-EIA7 ::= CHOICE [EPS integrity algorithm EIA7 not supported] | +-Octet4 ::= DIVISION | | +-UEA0 ::= CHOICE [UMTS encryption algorithm UEA0 not supported] | | +-UEA1 ::= CHOICE [UMTS encryption algorithm UEA1 not supported] | | +-UEA2 ::= CHOICE [UMTS encryption algorithm UEA2 not supported] | | +-UEA3 ::= CHOICE [UMTS encryption algorithm UEA3 not supported] | | +-UEA4 ::= CHOICE [UMTS encryption algorithm UEA4 not supported] | | +-UEA5 ::= CHOICE [UMTS encryption algorithm UEA5 not supported] | | +-UEA6 ::= CHOICE [UMTS encryption algorithm UEA6 not supported] | | +-UEA7 ::= CHOICE [UMTS encryption algorithm UEA7 not supported] | +-Octet5 ::= DIVISION | | +-spare ::= FIX [0] | | +-UIA1 ::= CHOICE [UMTS integrity algorithm UIA1 not supported] | | +-UIA2 ::= CHOICE [UMTS integrity algorithm UIA2 not supported] | | +-UIA3 ::= CHOICE [UMTS integrity algorithm UIA3 not supported] | | +-UIA4 ::= CHOICE [UMTS integrity algorithm UIA4 not supported] | | +-UIA5 ::= CHOICE [UMTS integrity algorithm UIA5 not supported] | | +-UIA6 ::= CHOICE [UMTS integrity algorithm UIA6 not supported] | | +-UIA7 ::= CHOICE [UMTS integrity algorithm UIA7 not supported] | +-Octet6 ::= DIVISION | +-spare ::= FIX [0] | +-GEA1 ::= CHOICE [GPRS encryption algorithm GEA1 not supported] | +-GEA2 ::= CHOICE [GPRS encryption algorithm GEA2 not supported] | +-GEA3 ::= CHOICE [GPRS encryption algorithm GEA3 not supported] | +-GEA4 ::= CHOICE [GPRS encryption algorithm GEA4 not supported] | +-GEA5 ::= CHOICE [GPRS encryption algorithm GEA5 not supported] | +-GEA6 ::= CHOICE [GPRS encryption algorithm GEA6 not supported] | +-GEA7 ::= CHOICE [GPRS encryption algorithm GEA7 not supported] +-IMEISV request ::= TV OPTIONAL:Omit | +-Octet1 ::= DIVISION | +-IMEISV request IEI ::= IEI [C-] | +-spare ::= FIX [0] | +-IMEISV request value ::= CHOICE [IMEISV not requested] +-Replayed nonce UE ::= TV OPTIONAL:Omit | +-Octet1 ::= DIVISION | | +-Nonce IEI ::= IEI [55] | +-Octet2-Octet5 ::= DIVISION | +-Nonce value ::= OCTETARRAY SIZE(4..4) [00000000] +-Nonce MME ::= TV OPTIONAL:Omit +-Octet1 ::= DIVISION | +-Nonce IEI ::= IEI [56] +-Octet2-Octet5 ::= DIVISION +-Nonce value ::= OCTETARRAY SIZE(4..4) [00000000]
RRC : UL Information Transfer + NAS : Security Mode Complete
Security Mode Complete is the answer to "Security Mode Command" message, so it is simple. If UE is also capable of the Integrity, Security algorithm that NW want to use, it send 'Security Mode Complete', if UE is not capable of them, it send 'Security Mode Failure'.
NAS_LTE:EMM,Security mode complete
< Security mode complete > decoded message capture. Field values come from a live capture, not from the specification.
Security mode complete ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Security mode complete message identity ::= V
| +-Message type ::= MSG [5E]
+-IMEISV ::= TLV OPTIONAL:Omit
+-Octet1 ::= DIVISION
| +-Mobile Identity IEI ::= IEI [23]
+-Octet2 ::= DIVISION
| +-Length of mobile identity contents ::= LEN (0..255) [0]
+-Octet3 ::= DIVISION
| +-Identity digit 1 ::= INT (0..15) [0]
| +-Odd/even indication ::= CHOICE [even number of identity digits and also when the TMSI/P-TMSI is used]
| +-Type of identity ::= CHOICE [No Identity]
+-Octet4-Octet11 ::= DIVISION
+-Identity digit p ::= OCTETARRAY SIZE(0..8)
Two details in the capture are worth noticing. The message is short because it agrees rather than negotiates, so the UE either accepts the algorithms the command named or answers with a Security Mode Reject instead. And this is the first NAS message on the uplink that is integrity protected, using the key the command has just brought into use. A UE that derived the wrong key therefore fails here, rather than continuing quietly.
The complete message agrees, it does not negotiate : the UE accepts the algorithms the command named, or rejects them outright.It is the first protected NAS message from the UE : it is integrity protected with the key the command activated, so a key mismatch shows up at this step.
RRC : Security Mode Command
LTE runs security twice, and this is the second run. The NAS exchange above protects signalling between the UE and the MME. This one protects signalling between the UE and the eNB, and it uses a different key even though the algorithm names look much the same.
This is the same step as NAS:Security Mode Command, the only difference is that this is only for RRC message.
RRC_LTE:DL-DCCH-Message
< DL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [securityModeCommand]
+-securityModeCommand ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [securityModeCommand-r8]
+-securityModeCommand-r8 ::= SEQUENCE [0]
+-securityConfigSMC ::= SEQUENCE
| +-securityAlgorithmConfig ::= SEQUENCE
| +-cipheringAlgorithm ::= ENUMERATED [eea1]
| +-integrityProtAlgorithm ::= ENUMERATED [eia1]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
- For Ciphering Algorithm Paramter, refer to EEA page.
- For Integrity Algorithm Paramter, refer to EIA page.
The keys are what separate the two procedures. The NAS keys come straight from K_ASME and stay with the MME. The RRC keys come from K_eNB, which is derived from K_ASME and handed to the eNB. The eNB can therefore protect the air interface without ever holding the key the MME uses. WCDMA had one security mode procedure because one node terminated both. LTE splits the nodes, so it splits the procedure.
Two procedures because there are two nodes : NAS security terminates at the MME and RRC security at the eNB.Different keys behind similar names : the NAS keys come from K_ASME and the RRC keys from K_eNB, which is derived from it.
RRC : Security Mode Complete
Security Mode Complete is the answer to "Security Mode Command" message, so it is simple. If UE is also capable of the Integrity, Security algorithm that NW want to use, it send 'Security Mode Complete', if UE is not capable of them, it send 'Security Mode Failure'.
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [securityModeComplete]
+-securityModeComplete ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [securityModeComplete-r8]
+-securityModeComplete-r8 ::= SEQUENCE [0]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
From this message onward the air interface signalling is protected. The eNB now has confirmation that the UE derived the same K_eNB it did, and every later RRC message on this connection is integrity protected with it. That matters when reading a log. A Security Mode Complete that never arrives usually means the two sides disagree about the key, rather than about the message.
This is where protection starts : every RRC message after it on this connection is integrity protected.A missing complete points at the key : the two sides usually disagree about K_eNB rather than about the message itself.
There is a failure counterpart, and it is worth knowing what it does rather than only that it exists. 36.331 has the UE answer a command it cannot apply with a SecurityModeFailure. The specification is explicit about what follows. The UE continues using the configuration it had before the SecurityModeCommand arrived. The connection therefore survives the failure, unprotected, which is why a failure here shows up as a call that runs on and then stalls rather than as one that drops immediately.
RRC : UE Capability Enquiry
As the diversity of mobile services gets wider, Network needs to know exact capability of a UE to provide proper services for each UE. For example, what if network triggers an interRAT handover to a UE which does not support that capability ? It would lead to communication drop.
In case of WCDMA, Network can figure out all the details of UE capability during RRC Connection Setup Complete message since UE report all the details of its capability in RRC Connection Setup Complete message. However, LTE RRC Connection Setup Complete message does not carry this kind of information. In stead, LTE designed a new message dedicated for investigating UE capability. This is the role of UE Capability Enquiry and UE Capability Information message.
Strictly speaking, this is a kind of optional step.. but it is becoming more and more critical steps as LTE service evolves.
Following is one example of ue-CapabilityRequest message and this is saying "Report all of your LTE capability and UTRA capability".
< DL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
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]) [2]
| +-RAT-Type ::= ENUMERATED [eutra ]
| +-RAT-Type ::= ENUMERATED [utra ]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
RRC : UE Capability Information
This message is the response to UE Capability Request message and it carries all the details of UE capability. Since this is very complicated message which has wide variety, I made a separate page for UE Capability Information.
The message is long for a reason worth knowing even if you never read it in full. It is the only place the UE states what it can do, and the network has no other source for that. Band support, UE category, carrier aggregation combinations and feature group indicators all arrive here, and any configuration the network sends later has to stay inside what this message allowed.
That makes it the first place to look when a UE refuses a configuration that appears perfectly legal. If the network configures something this message never claimed, the UE is entitled to ignore it, and the failure then surfaces a long way from its cause. UE Capability covers the contents.
It is the network's only source : nothing else tells the eNB what this UE supports.Later configuration has to stay inside it : a feature the UE never claimed can be ignored, and the failure surfaces well after the cause.
One detail explains why two captures of this message can look so different. The enquiry above selects which radio access technologies it wants, and 36.331 lists eutra, utra, geran-cs, geran-ps and cdma2000-1XRTT among the choices. The response carries one container per requested technology in ue-CapabilityRAT-ContainerList. A UE that answers with an EUTRA container alone has not left anything out; it was asked for nothing else.
RRC : RRC Connection Reconfiguration + NAS : Attach Accept + NAS : Activate Default EPS Bearer Context Request
This is the step where the call becomes useful. Everything before it built a signalling connection. This message adds the radio bearer that will carry data, and it brings the network's answer to the attach at the same time. That is why it is the largest message on this page.
An important procedure done in this step is "ESM : Activate Default EPS Bearer Context Request".
One thing you notice here is that in LTE Packet call is initiated by Network where as in UMST most of the packet call is initiated by UE. Network specifies an IP for the UE here.
If you have any experience with WCDMA protocol, you may take this message to be similar to 'Radio Bearer Setup' + 'Attach Accept' + Activate PDP Context Accept.
At this step, UE gets an IP from the network and this IP does not get returned to Network even after 'RRC connection Release' and UE gets into IDLE mode.
An example of RRC Connection Reconfiguration is as follows. The example shown in this page is from very early LTE UE, so it may be oversimplified comparing to more recent device. I will keep posting more examples of this message from various different conditions.
- Example with IPv4 only-RRC Connection Reconfiguration+Attach Complete+Activate Default EPS Bearer Req
- Example with IPv6 only-RRC Connection Reconfiguration+Activate Default EPS Bearer Req
- Example with IPv4v6 only-RRC Connection Reconfiguration+Activate Default EPS Bearer Req
Don't try to look into all the details since this message is one of the most complicated message in LTE. Just try to understand overall structure and compare the tree map shown above and the real messages shown below.
Probably it will take several month to understand all the details of these elements, so don't be so hurry.
Whenever you study a little bit further details of the topics in the tree diagram shown above, open up this section and see the details under the topics you studied. If you fully understand all the information elements shown below, you can say you mastered the LTE. Again don't try to understand all of these at once. It will just raise your blood pressure. Just look through these items as often as possible and get familiar with the overall structure first.
< DL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfiguration]
+-rrcConnectionReconfiguration ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfiguration-r8]
+-rrcConnectionReconfiguration-r8 ::= SEQUENCE [001100]
+-measConfig ::= SEQUENCE OPTIONAL:Omit
+-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
+-dedicatedInfoNASList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist
| +-DedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [074201E0060000F1100001002C5201C101091003777777
07616E726974737503636F6D05010A012037270E808021
0A0300000A81060A000001500BF600F11080010100000001]
+-radioResourceConfigDedicated ::= SEQUENCE [110101] OPTIONAL:Exist
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| | +-SRB-ToAddMod ::= SEQUENCE [11]
| | +-srb-Identity ::= INTEGER (1..2) [2]
| | +-rlc-Config ::= CHOICE [defaultValue] OPTIONAL:Exist
| | | +-defaultValue ::= NULL
| | +-logicalChannelConfig ::= CHOICE [defaultValue] OPTIONAL:Exist
| | +-defaultValue ::= NULL
| +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist
| | +-DRB-ToAddMod ::= SEQUENCE [11111]
| | +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist
| | +-drb-Identity ::= INTEGER (1..32) [1]
| | +-pdcp-Config ::= SEQUENCE [101] OPTIONAL:Exist
| | | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist
| | | +-rlc-AM ::= SEQUENCE OPTIONAL:Omit
| | | +-rlc-UM ::= SEQUENCE OPTIONAL:Exist
| | | | +-pdcp-SN-Size ::= ENUMERATED [len12bits]
| | | +-headerCompression ::= CHOICE [notUsed]
| | | +-notUsed ::= NULL
| | +-rlc-Config ::= CHOICE [um-Bi-Directional] OPTIONAL:Exist
| | | +-um-Bi-Directional ::= SEQUENCE
| | | +-ul-UM-RLC ::= SEQUENCE
| | | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | +-dl-UM-RLC ::= SEQUENCE
| | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | +-t-Reordering ::= ENUMERATED [ms50]
| | +-logicalChannelIdentity ::= INTEGER (3..10) [3] OPTIONAL:Exist
| | +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist
| | +-ul-SpecificParameters ::= SEQUENCE [1] OPTIONAL:Exist
| | +-priority ::= INTEGER (1..16) [13]
| | +-prioritisedBitRate ::= ENUMERATED [infinity]
| | +-bucketSizeDuration ::= ENUMERATED [ms100]
| | +-logicalChannelGroup ::= INTEGER (0..3) [2] OPTIONAL:Exist
| +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit
| +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist
| | +-explicitValue ::= SEQUENCE [111]
| | +-ul-SCH-Config ::= SEQUENCE [11] OPTIONAL:Exist
| | | +-maxHARQ-Tx ::= ENUMERATED [n5] OPTIONAL:Exist
| | | +-periodicBSR-Timer ::= ENUMERATED [sf20] OPTIONAL:Exist
| | | +-retxBSR-Timer ::= ENUMERATED [sf320]
| | | +-ttiBundling ::= BOOLEAN [FALSE]
| | +-drx-Config ::= CHOICE [release] OPTIONAL:Exist
| | | +-release ::= NULL
| | +-timeAlignmentTimerDedicated ::= ENUMERATED [infinity]
| | +-phr-Config ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-periodicPHR-Timer ::= ENUMERATED [sf500]
| | +-prohibitPHR-Timer ::= ENUMERATED [sf200]
| | +-dl-PathlossChange ::= ENUMERATED [dB3]
| +-sps-Config ::= SEQUENCE OPTIONAL:Omit
| +-physicalConfigDedicated ::= SEQUENCE [0000110010] OPTIONAL:Exist
| +-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-pucch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-pusch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-uplinkPowerControlDedicated ::= SEQUENCE OPTIONAL:Omit
| +-tpc-PDCCH-ConfigPUCCH ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-tpc-RNTI ::= BIT STRING SIZE(16) [0000001111111111]
| | +-tpc-Index ::= CHOICE [indexOfFormat3]
| | +-indexOfFormat3 ::= INTEGER (1..15) [1]
| +-tpc-PDCCH-ConfigPUSCH ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-tpc-RNTI ::= BIT STRING SIZE(16) [0000000111111010]
| | +-tpc-Index ::= CHOICE [indexOfFormat3]
| | +-indexOfFormat3 ::= INTEGER (1..15) [1]
| +-cqi-ReportConfig ::= SEQUENCE OPTIONAL:Omit
| +-soundingRS-UL-ConfigDedicated ::= CHOICE OPTIONAL:Omit
| +-antennaInfo ::= CHOICE [explicitValue] OPTIONAL:Exist
| | +-explicitValue ::= SEQUENCE [0]
| | +-transmissionMode ::= ENUMERATED [tm1]
| | +-codebookSubsetRestriction ::= CHOICE OPTIONAL:Omit
| | +-ue-TransmitAntennaSelection ::= CHOICE [release]
| | +-release ::= NULL
| +-schedulingRequestConfig ::= CHOICE OPTIONAL:Omit
+-securityConfigHO ::= SEQUENCE OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
Even though the decoded message shown above looks very complicated already, it is not fully decoded. It shows only RRC part decode. If you decode the NAS part in this message, you will get the following contents.
One very important thing you have to keep in mind is that you have to carefully populate this message so that I can properly handles/matches the information sent from UE via Attach Request, otherwise this would lead to registration failure.
AS_LTE:EMM,Attach accept
< Attach accept > decoded message capture. Field values come from a live capture, not from the specification.
Attach accept ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Attach accept message identity ::= V
| +-Message type ::= MSG [42]
+-Spare half octet ::= V
| +-Spare half octet ::= FIX [0]
+-EPS attach result ::= V
| +-Spare ::= FIX [0]
| +-EPS attach result value ::= CHOICE [EPS only]
+-T3412 value ::= V
| +-Octet1 ::= DIVISION
| +-Unit ::= CHOICE [value indicates that the timer is deactivated]
| +-Timer value ::= INT (0..31) [0]
+-TAI list ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of tracking area identity list contents ::= LEN (0..255) [6]
| +-Octet2-97 ::= DIVISION
| +-tracking area identity list contents ::= OCTETARRAY SIZE(0..96) [0000F1100001]
+-ESM message container ::= LV-E
| +-Octet1-Octet2 ::= DIVISION
| | +-Length of ESM message container ::= LEN (0..65535) [44]
| +-Octet3- ::= DIVISION
| +-ESM message container contents ::= OCTETARRAY SIZE(0..65535) [5201C10109100377777707616E726974737503636F6D
05010A012037270E8080210A0300000A81060A000001]
+-GUTI ::= TLV OPTIONAL:Exist
| +-Octet1 ::= DIVISION
| | +-EPS mobile identity IEI ::= IEI [50]
| +-Octet2 ::= DIVISION
| | +-Length of EPS mobile identity contents ::= LEN (0..255) [11]
| +-Octet3 ::= DIVISION
| | +-Spare ::= FIX [F]
| | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the GUTI is used]
| | +-Type of identity ::= CHOICE [GUTI]
| +-Octet4 ::= DIVISION
| | +-MCC digit 2 ::= INT (0..15) [0]
| | +-MCC digit 1 ::= INT (0..15) [0]
| +-Octet5 ::= DIVISION
| | +-MNC digit 3 ::= INT (0..15) [15]
| | +-MCC digit 3 ::= INT (0..15) [1]
| +-Octet6 ::= DIVISION
| | +-MNC digit 2 ::= INT (0..15) [1]
| | +-MNC digit 1 ::= INT (0..15) [0]
| +-Octet7 ::= DIVISION
| | +-MME Group ID ::= INT (0..255) [128]
| +-Octet8 ::= DIVISION
| | +-MME Group ID(continued) ::= INT (0..255) [1]
| +-Octet9 ::= DIVISION
| | +-MME Code ::= INT (0..255) [1]
| +-Octet10 ::= DIVISION
| | +-M-TMSI ::= INT (0..255) [0]
| +-Octet11 ::= DIVISION
| | +-M-TMSI(continued) ::= INT (0..255) [0]
| +-Octet12 ::= DIVISION
| | +-M-TMSI(continued) ::= INT (0..255) [0]
| +-Octet13 ::= DIVISION
| +-M-TMSI(continued) ::= INT (0..255) [1]
+-Location area identification ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Location Area Identification IEI ::= IEI [13]
| +-Octet2 ::= DIVISION
| | +-MCC digit 2 ::= INT (0..15) [0]
| | +-MCC digit 1 ::= INT (0..15) [0]
| +-Octet3 ::= DIVISION
| | +-MNC digit 3 ::= INT (0..15) [0]
| | +-MCC digit 3 ::= INT (0..15) [0]
| +-Octet4 ::= DIVISION
| | +-MNC digit 2 ::= INT (0..15) [0]
| | +-MNC digit 1 ::= INT (0..15) [0]
| +-Octet5 ::= DIVISION
| | +-LAC ::= INT (0..255) [0]
| +-Octet6 ::= DIVISION
| +-LAC (continued) ::= INT (0..255) [0]
+-MS identity ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Mobile Identity IEI ::= IEI [23]
| +-Octet2 ::= DIVISION
| | +-Length of mobile identity contents ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| | +-Identity digit 1 ::= INT (0..15) [0]
| | +-Odd/even indication ::= CHOICE [even number of identity digits and also when the TMSI/P-TMSI is used]
| | +-Type of identity ::= CHOICE [No Identity]
| +-Octet4-Octet10 ::= DIVISION
| +-Identity digit p ::= OCTETARRAY SIZE(0..7)
+-EMM cause ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-EMM cause IEI ::= IEI [53]
| +-Octet2 ::= DIVISION
| +-Cause value ::= CHOICE [#2:IMSI unknown in HSS]
+-T3402 value ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-GPRS Timer IEI ::= IEI [17]
| +-Octet2 ::= DIVISION
| +-Unit ::= CHOICE [value is incremented in multiples of 2 seconds]
| +-Timer value ::= INT (0..31) [0]
+-T3423 value ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-GPRS Timer IEI ::= IEI [59]
| +-Octet2 ::= DIVISION
| +-Unit ::= CHOICE [value is incremented in multiples of 2 seconds]
| +-Timer value ::= INT (0..31) [0]
+-Equivalent PLMNs ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-PLMN List IEI ::= IEI [4A]
| +-Octet2 ::= DIVISION
| | +-Length of PLMN List contents ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| | +-MCC digit 2 PLMN 1 ::= INT (0..15) [0]
| | +-MCC digit 1 PLMN 1 ::= INT (0..15) [0]
..... Octet 4 - Octet 45 .....
| +-Octet46 ::= DIVISION
| | +-MNC digit 3 PLMN 15 ::= INT (0..15) [0]
| | +-MCC digit 3 PLMN 15 ::= INT (0..15) [0]
| +-Octet47 ::= DIVISION
| +-MNC digit 2 PLMN 15 ::= INT (0..15) [0]
| +-MNC digit 1 PLMN 15 ::= INT (0..15) [0]
+-Emergency Number List ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Emergency Number List IEI ::= IEI [34]
| +-Octet2 ::= DIVISION
| | +-Length of Emergency Number List IE contents ::= LEN (0..255) [0]
| +-Octet3-50 ::= DIVISION
| +-Emergency Number List IE contents ::= OCTETARRAY SIZE(0..48)
+-EPS network feature support ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-EPS network feature support IEI ::= IEI [64]
| +-Octet2 ::= DIVISION
| | +-Length of EPS network feature support contents ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| +-Spare ::= FIX [0]
| +-IMS VoPS ::= CHOICE [IMS voice over PS session in S1 mode not supported]
+-Additional update result ::= TV OPTIONAL:Omit
+-Octet1 ::= DIVISION
+-Additional update result IEI ::= IEI [F-]
+-Spare ::= FIX [0]
+-Additional update result value ::= CHOICE [no additional information]
If you see the contents shown above, you would see "ESM message container contents", which can be further decoded as below. The IE (information element) marked in blue would be the most important IEs for UE connection to data service application.
NAS_LTE:ESM,Activate default EPS bearer context request
< Activate default EPS bearer context request > decoded message capture. Field values come from a live capture, not from the specification.
Activate default EPS bearer context request ::= DIVISION
+-EPS bearer identity ::= V
| +-EPS bearer identity value ::= CHOICE [EPS bearer identity value 5]
+-EPS session management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [2]
+-Procedure transaction identity ::= V
| +-Procedure transaction identity ::= CHOICE [Procedure transaction identity value 1]
+-Activate default EPS bearer context request message identity ::= V
| +-Message type ::= MSG [C1]
+-EPS QoS ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of EPS quality of service contents ::= LEN (0..255) [1]
| +-Octet2 ::= DIVISION
| | +-QCI ::= CHOICE [QCI 9]
| +-Octet3 ::= DIVISION
| | +-Maximum bit rate for uplink ::= CHOICE [Reserved(network to UE direction)/Subscribed maximum bit rate
for
uplink(UE to network direction)]
| +-Octet4 ::= DIVISION
| | +-Maximum bit rate for downlink ::= CHOICE [Reserved(network to UE direction)/Subscribed maximum bit rate
for
uplink(UE to network direction)]
| +-Octet5 ::= DIVISION
| | +-Guaranteed bit rate for uplink ::= CHOICE [Reserved(network to UE direction)/Subscribed maximum bit rate
for
uplink(UE to network direction)]
| +-Octet6 ::= DIVISION
| | +-Guaranteed bit rate for downlink ::= CHOICE [Reserved(network to UE direction)/Subscribed maximum bit rate
for
uplink(UE to network direction)]
| +-Octet7 ::= DIVISION
| | +-Maximum bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the maximum bit rate
for
uplink in octet 4]
| +-Octet8 ::= DIVISION
| | +-Maximum bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the maximum bit rate
for
uplink in octet 4]
| +-Octet9 ::= DIVISION
| | +-Guaranteed bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the guaranteed bit rate
for uplink
in octet 6]
| +-Octet10 ::= DIVISION
| +-Guaranteed bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the guaranteed bit rate
for uplink in
octet 6]
+-Access point name ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of access point name contents ::= LEN (0..255) [16]
| +-Octet2-Octet101 ::= DIVISION
| +-Access point name value ::= OCTETARRAY SIZE(0..100) [0377777707616E726974737503636F6D]
+-PDN address ::= LV
| +-Octet1 ::= DIVISION
| | +-Length of PDN address contents ::= LEN (0..255) [5]
| +-Octet2 ::= DIVISION
| | +-spare ::= FIX [0]
| | +-PDN type value ::= CHOICE [IPv4]
| +-Octet3-14 ::= DIVISION
| +-PDN address information ::= OCTETARRAY SIZE(0..12) [0A012037]
+-Transaction identifier ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Transaction identifier IEI ::= IEI [5D]
| +-Octet2 ::= DIVISION
| | +-Length of Transaction identifier contents ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| | +-TI flag ::= CHOICE [The message is sent from the side that originates the TI]
| | +-TIO ::= CHOICE [TI value 0]
| | +-Spare ::= FIX [0]
| +-Octet4 ::= DIVISION
| +-ext ::= EXT (0..1) [1]
| +-TIE ::= CHOICE [Reserved]
+-Negotiated QoS ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Quality of service IEI ::= IEI [30]
| +-Octet2 ::= DIVISION
| | +-Length of quality of service IE ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| | +-spare ::= FIX [0]
| | +-Delay class ::= CHOICE [Subscribed delay class(MS to network direction)/Reserved(network to MS direction)]
| | +-Reliability class ::= CHOICE [Subscribed reliability class(MS to network direction)/Reserved(network
to MS direction)]
| +-Octet4 ::= DIVISION
| | +-Peak throughput ::= CHOICE [Subscribed peak throughput(MS to network direction)/Reserved(network
to MS direction)]
| | +-spare ::= FIX [0]
| | +-Precedence class ::= CHOICE [Subscribed precedence(MS to network direction)/Reserved(network
to MS direction)]
| +-Octet5 ::= DIVISION
| | +-spare ::= FIX [0]
| | +-Mean throughput ::= CHOICE [Subscribed mean throughput(MS to network direction)/Reserved(network
to MS direction)]
| +-Octet6 ::= DIVISION
| | +-Traffic Class ::= CHOICE [Subscribed traffic class(MS to network direction)/Reserved(network to MS direction)]
| | +-Delivery order ::= CHOICE [Subscribed delivery order(MS to network direction)/Reserved(network
to MS direction)]
| | +-Delivery of erroneous SDUs ::= CHOICE [Subscribed delivery of erroneous SDUs(MS to network direction)
/Reserved(network to MS direction)]
| +-Octet7 ::= DIVISION
| | +-Maximum SDU size ::= CHOICE [Subscribed maximum SDU size(MS to network direction)
/Reserved(network to MS direction)]
| +-Octet8 ::= DIVISION
| | +-Maximum bit rate for uplink ::= CHOICE [Subscribed maximum bit rate for uplink(MS to network direction)
/Reserved(network to MS direction)]
| +-Octet9 ::= DIVISION
| | +-Maximum bit rate for downlink ::= CHOICE [Subscribed maximum bit rate for uplink(MS to network direction
)/Reserved(network to MS direction)]
| +-Octet10 ::= DIVISION
| | +-Residual BER ::= CHOICE [Subscribed residual BER(MS to network direction)/Reserved(network
to MS direction)]
| | +-SDU error ratio ::= CHOICE [Subscribed SDU error ratio(MS to network direction)/Reserved(network
to MS direction)]
| +-Octet11 ::= DIVISION
| | +-Transfer delay ::= CHOICE [Subscribed transfer delay(MS to network direction)/Reserved(network
to MS direction)]
| | +-Traffic Handling priority ::= CHOICE [Subscribed traffic handling priority(MS to network direction)
/Reserved(network to MS direction)]
| +-Octet12 ::= DIVISION
| | +-Guaranteed bit rate for uplink ::= INT (0..255) [0]
| +-Octet13 ::= DIVISION
| | +-Guaranteed bit rate for downlink ::= INT (0..255) [0]
| +-Octet14 ::= DIVISION
| | +-Spare ::= FIX [0]
| | +-Signalling Indication ::= CHOICE [Not optimised for signalling traffic]
| | +-Source Statistics Descriptor ::= CHOICE [unknown]
| +-Octet15 ::= DIVISION
| | +-Maximum bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate
for downlink in octet 9.]
| +-Octet16 ::= DIVISION
| | +-Guaranteed bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate
for downlink in octet 9.]
| +-Octet17 ::= DIVISION
| | +-Maximum bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate
for downlink in octet 9.]
| +-Octet18 ::= DIVISION
| +-Guaranteed bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate
for downlink in octet 9.]
+-Negotiated LLC SAPI ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-LLC SAPI IEI ::= IEI [32]
| +-Octet2 ::= DIVISION
| +-Spare ::= FIX [0]
| +-LLC SAPI value ::= CHOICE [LLC SAPI not assigned]
+-Radio priority ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| +-Radio priority IEI ::= IEI [8-]
| +-spare ::= FIX [0]
| +-Radio priority level value ::= CHOICE [priority level 1 (highest)]
+-Packet flow identifier ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-Packet Flow Identifier IEI ::= IEI [34]
| +-Octet2 ::= DIVISION
| | +-Length of Packet Flow Identifier IE ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| +-spare ::= FIX [0]
| +-Packet Flow Identifier value ::= CHOICE [Best Effort]
+-APN-AMBR ::= TLV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-APN aggregate maximum bit rate IEI ::= IEI [5E]
| +-Octet2 ::= DIVISION
| | +-Length of APN aggregate maximum bit rate contents ::= LEN (0..255) [0]
| +-Octet3 ::= DIVISION
| | +-APN-AMBR for downlink ::= CHOICE [1kbps]
| +-Octet4 ::= DIVISION
| | +-APN-AMBR for uplink ::= CHOICE [1kbps]
| +-Octet5 ::= DIVISION
| | +-APN-AMBR for downlink (extended) ::= CHOICE [Use the value indicated by the APN-AMBR
for downlink in octet 3]
| +-Octet6 ::= DIVISION
| | +-APN-AMBR for uplink (extended) ::= CHOICE [8700kbps]
| +-Octet7 ::= DIVISION
| | +-APN-AMBR for downlink (extended-2) ::= CHOICE [Use the value indicated by the APN-AMBR
for downlink and APN-AMBR for downlink (extended) in octets 3 and 5 0]
| +-Octet8 ::= DIVISION
| +-APN-AMBR for uplink (extended-2) ::= CHOICE [Use the value indicated by the APN-AMBR
for downlink and APN-AMBR for downlink (extended) in octets 3 and 5 0]
+-ESM cause ::= TV OPTIONAL:Omit
| +-Octet1 ::= DIVISION
| | +-ESM cause IEI ::= IEI [58]
| +-Octet2 ::= DIVISION
| +-Cause value ::= CHOICE [#8:Operator Determined Barring]
+-Protocol configuration options ::= TLV OPTIONAL:Exist
+-Octet1 ::= DIVISION
| +-Protocol configuration options IEI ::= IEI [27]
+-Octet2 ::= DIVISION
| +-Length of protocol config options contents ::= LEN (0..255) [14]
+-Octet3 ::= DIVISION
| +-ext ::= EXT1 [1]
| +-spare ::= FIX [0]
| +-Configuration protocol ::= CHOICE [PPP for use with IP PDP type]
+-Octet4-Octet253 ::= DIVISION
+-protocol config options contents ::= OCTETARRAY SIZE(0..250) [80210A0300000A81060A000001]
There is one important thing you have to know at this point. It is about how to specify PDN address. Following three examples can be self sufficient (I hope -:). For a little bit further details for IPv6, refer to IPv6 page.
< PDN address > decoded message capture. Field values come from a live capture, not from the specification.
+-PDN address ::= LV | +-Octet1 ::= DIVISION | | +-Length of PDN address contents ::= LEN (0..255) [5] | +-Octet2 ::= DIVISION | | +-spare ::= FIX [0] | | +-PDN type value ::= CHOICE [IPv4] | +-Octet3-14 ::= DIVISION | +-PDN address information ::= OCTETARRAY SIZE(0..12) [0A012037]
: Specify the link local address of IPv6 address.
< PDN address > decoded message capture. Field values come from a live capture, not from the specification.
+-PDN address ::= LV | +-Octet1 ::= DIVISION | | +-Length of PDN address contents ::= LEN (0..255) [9] | +-Octet2 ::= DIVISION | | +-spare ::= FIX [0] | | +-PDN type value ::= CHOICE [IPv6] | +-Octet3-14 ::= DIVISION | +-PDN address information ::= OCTETARRAY SIZE(0..12) [0000000001010002]
: Specify the link local address of IPv6 address followed by IPv4 address.
< PDN address > decoded message capture. Field values come from a live capture, not from the specification.
+-PDN address ::= LV | +-Octet1 ::= DIVISION | | +-Length of PDN address contents ::= LEN (0..255) [13] | +-Octet2 ::= DIVISION | | +-spare ::= FIX [0] | | +-PDN type value ::= CHOICE [IPv4v6] | +-Octet3-14 ::= DIVISION | +-PDN address information ::= OCTETARRAY SIZE(0..12) [00000000010100020A0A0A0A]
This is a pretty complicated topic. So I will describe this on a separate post here.
RRC : RRC Connection Reconfiguration Complete + NAS : AttachComplete + ESM : Activate Default EPS Bearer Context Accept
Three separate acknowledgements travel inside this one message, one from each layer that was configured a moment ago. Reading it as three replies rather than as one message is what makes its nesting easy to follow.
An important procedure done in this step is "ESM : Activate Default EPS Bearer Context Accept".
RRC Connection Reconfiguration Complete part is very simple as follows.
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
RRC_LTE:UL-DCCH-Message
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfigurationComplete]
+-rrcConnectionReconfigurationComplete ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [rrcConnectionReconfigurationComplete-r8]
+-rrcConnectionReconfigurationComplete-r8 ::= SEQUENCE [0]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
NAS part has pretty complicated structure since it is Piggybacked multiple times.
RRC_LTE:UL-DCCH-Message
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [ulInformationTransfer]
+-ulInformationTransfer ::= SEQUENCE
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ulInformationTransfer-r8]
+-ulInformationTransfer-r8 ::= SEQUENCE [0]
+-dedicatedInfoType ::= CHOICE [dedicatedInfoNAS]
| +-dedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [074300035200C2]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
If you decode
NAS_LTE:EMM,Attach complete
< Attach complete > decoded message capture. Field values come from a live capture, not from the specification.
Attach complete ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Plain NAS message, not security protected]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-Attach complete message identity ::= V
| +-Message type ::= MSG [43]
+-ESM message container ::= LV-E
+-Octet1-Octet2 ::= DIVISION
| +-Length of ESM message container ::= LEN (0..65535) [3]
+-Octet3- ::= DIVISION
+-ESM message container contents ::= OCTETARRAY SIZE(0..65535) [5200C2]
If you decode ESM message container contents ::= OCTETARRAY SIZE(0..65535) [5200C2] part, you will get the following message (Activate default EPS bearer context accept).
NAS_LTE:ESM,Activate default EPS bearer context accept
< Activate default EPS bearer context accept > decoded message capture. Field values come from a live capture, not from the specification.
Activate default EPS bearer context accept ::= DIVISION
+-EPS bearer identity ::= V
| +-EPS bearer identity value ::= CHOICE [EPS bearer identity value 5]
+-EPS session management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [2]
+-Procedure transaction identity ::= V
| +-Procedure transaction identity ::= CHOICE [No procedure transaction identity assigned]
+-Activate default EPS bearer context accept message identity ::= V
| +-Message type ::= MSG [C2]
+-Protocol configuration options ::= TLV OPTIONAL:Omit
+-Octet1 ::= DIVISION
| +-Protocol configuration options IEI ::= IEI [27]
+-Octet2 ::= DIVISION
| +-Length of protocol config options contents ::= LEN (0..255) [0]
+-Octet3 ::= DIVISION
| +-ext ::= EXT1 [1]
| +-spare ::= FIX [0]
| +-Configuration protocol ::= CHOICE [PPP for use with IP PDP type]
+-Octet4-Octet253 ::= DIVISION
+-protocol config options contents ::= OCTETARRAY SIZE(0..250)
RRC : RRC Connection Request
Same as step 6, but establishment cause gets different as shown below. It will be mt-Access or mo-Data depending on whether it is MT call or MO call.
RRC_LTE:UL-CCCH-Message
< UL-CCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
UL-CCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionRequest]
+-rrcConnectionRequest ::= SEQUENCE
+-criticalExtensions ::= CHOICE [rrcConnectionRequest-r8]
+-rrcConnectionRequest-r8 ::= SEQUENCE
+-ue-Identity ::= CHOICE [s-TMSI]
| +-s-TMSI ::= SEQUENCE
| +-mmec ::= BIT STRING SIZE(8) [00000001]
| +-m-TMSI ::= BIT STRING SIZE(32) [00000000000000000000000000000001]
+-establishmentCause ::= ENUMERATED [mt-Access]
+-spare ::= BIT STRING SIZE(1) [0]
The establishment cause is the field to read, and on this pass it is the only real difference. The first pass had the UE registering, so the cause was mo-Signalling. Here the UE is already registered and wants to move data, so the cause is mo-Data for a mobile originated call, or mt-Access when the UE is answering a page.
The identity changes for the same reason. A UE that has attached holds an S-TMSI, so ue-Identity carries that rather than the random value the first pass used. The network can therefore recognise the UE from the very first message of the second pass.
Only the establishment cause really differs : mo-Signalling on the first pass, and mo-Data or mt-Access on the second.The identity is no longer random : a registered UE sends its S-TMSI, so the network knows who is asking straight away.
RRC : RRC Connection Setup
The RRC Connection Setup does not change between the two passes, and that deserves a sentence rather than only a pointer. The message configures SRB1 and the dedicated physical layer, and neither of those depends on whether the UE is attaching or resuming.
Refer to RRC Connection Setup
What differs is the reply rather than this message. On the first pass the UE answers with an Attach Request. Here it answers with a Service Request, which is a far shorter NAS message, and that is the step immediately below.
The setup message itself is unchanged : it configures SRB1 and the dedicated physical layer either way.The difference is in what comes back : an Attach Request on the first pass, and a Service Request on the second.
One thing does change, even though the message does not. Nothing of the previous connection survived the idle period, so every dedicated parameter in this message is being set up from scratch rather than restored. SRB1 is re-established, and the physical configuration is fresh. The UE moves from IDLE to CONNECTED here exactly as it did on the first pass, and the eNB has no memory of the configuration it used last time.
Nothing survives the idle period at the eNB : the dedicated configuration is built again from scratch rather than restored.
RRC : RRC Connection Setup Complete + NAS : Service Request
The Service Request is the shortest NAS message on this page, and its size is the point. The network already holds the UE's context from the attach, so nothing needs describing again. The message only has to identify the UE and prove it is the same one.
RRC_LTE:UL-DCCH-Message
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionSetupComplete]
+-rrcConnectionSetupComplete ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionSetupComplete-r8]
+-rrcConnectionSetupComplete-r8 ::= SEQUENCE [00]
+-selectedPLMN-Identity ::= INTEGER (1..6) [1]
+-registeredMME ::= SEQUENCE OPTIONAL:Omit
+-dedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [C7E00000]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
If you decode
NAS_LTE:EMM,Service request
< Service request > decoded message capture. Field values come from a live capture, not from the specification.
Service request ::= DIVISION
+-Security header type ::= V
| +-Security header type ::= CHOICE [Security header for the SERVICE REQUEST message]
+-EPS mobility management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [7]
+-KSI and sequence number ::= V
| +-Octet1 ::= DIVISION
| +-KSI ::= CHOICE [no key is available]
| +-Sequence number(short) ::= INT (0..31) [0]
+-Message authentication code (short) ::= V
+-Octet1 ::= DIVISION
| +-Short MAC value ::= INT (0..255) [0]
+-Octet2 ::= DIVISION
+-Short MAC value(continued) ::= INT (0..255) [0]
RRC : Security Mode Command
Security has to be set up again on the second pass, even though the UE authenticated during the attach. The reason is the key rather than the identity. The UE went idle, the eNB released its context, and K_eNB has to be established again for the new connection.
Refer to RRC : Security Mode Command
Authentication does not repeat : the UE is already authenticated, and K_ASME survives the idle period.K_eNB does repeat : the eNB released its context when the UE went idle, so the access stratum key is derived again.
It is worth being precise about which half of the security state survived. The NAS context did. K_ASME was established during the attach and the UE kept it through idle. That is why no authentication runs on this pass, and why the Service Request above could be integrity protected at all.
The access stratum context did not. The eNB released everything when the UE went idle, so K_eNB has to be produced again. 33.401 derives it from K_ASME and the uplink NAS COUNT. That ties the new access stratum keys to the NAS context the UE still holds, and it stops an old K_eNB being reused on the new connection.
RRC : Security Mode Complete
The reply is the same message as on the first pass, and it marks the same point. From here the RRC signalling on this connection is protected. The pointer below goes to the fuller description rather than repeating it.
Refer to RRC : Security Mode Complete
The same diagnostic applies here as on the first pass. A Security Mode Complete that never arrives usually means the UE and the eNB derived different K_eNB values. That points at the NAS COUNT used in the derivation rather than at anything in this message.
Once it does arrive, the connection is ready for the step below. The eNB will not send a reconfiguration that adds a bearer until access stratum security is running. This short message is therefore the gate between a signalling connection and one that can carry data.
The NAS context survives idle and the access stratum context does not : K_ASME is kept, while K_eNB is derived again from it and the uplink NAS COUNT.This message is the gate to the bearer : the eNB adds a dedicated bearer only after access stratum security is running.
Notice also what is missing from this second pass. The step list at the top of this page numbers a UE Capability Enquiry and a UE Capability Information as O1 and O2. Both appear only in the first run. The eNB does not ask again, because the capabilities were established during the attach and the network keeps them for the UE. That absence is part of why the second pass is so much shorter than the first.
RRC : RRC Connection Reconfiguration + NAS : Activate Dedicated EPS Bearer Context Request
This step adds a bearer rather than creating one from nothing, and nearly every difference from the first pass follows from that. The UE already has an IP address and a default bearer, so this message carries neither of them.
This is another 'RRC Connection Reconfiguration' message. But you would see some difference between this message and the message at step 15.
You don't see any 'Attach Accept' part because you already went through 'attach' process during the registration. And now you created only 'Dedicated EPS Bearer'. Does this mean that you cannot use the 'Default EPS Bearer' you created at step 15) ? No.. the default Bearer is still alive once it is created during the registration. That's why you don't have to recreate the default EPS bearer at this step.
One think you would notice would be that 'Activate Dedicated EPS Bearer Context Request' does not have IP address setting. This is because Dedicated EPS is using the same IP configuration specified by Default EPS Bearer. The purpose of Default EPS bearer is to create a data pipe with a different QoS from Default EPS QoS. It means Dedicated EPS Bearer is linked to a specific Default EPS bearer.
Then, how do we know which default EPS bearer is linked to which Dedicated EPS Bearer ?
This link is specified by 'Linked EPS Bearer Identity'. For example, if 'Linked EPS Bearer Identity' is set to be 5. It means this 'Dedicated EPS Bearer' is linked to the Default EPS Bearer with Bearer ID = 5 and use the same IP configuration as defined in the default EPS bearer.
< DL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
DL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfiguration]
+-rrcConnectionReconfiguration ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfiguration-r8]
+-rrcConnectionReconfiguration-r8 ::= SEQUENCE [001100]
+-measConfig ::= SEQUENCE OPTIONAL:Omit
+-mobilityControlInfo ::= SEQUENCE OPTIONAL:Omit
+-dedicatedInfoNASList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist
| +-DedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED)
[1700000000036200C5050904686848480000000006213100023011]
+-radioResourceConfigDedicated ::= SEQUENCE [110101] OPTIONAL:Exist
| +-srb-ToAddModList ::= SEQUENCE OF SIZE(1..2) [1] OPTIONAL:Exist
| | +-SRB-ToAddMod ::= SEQUENCE [11]
| | +-srb-Identity ::= INTEGER (1..2) [2]
| | +-rlc-Config ::= CHOICE [defaultValue] OPTIONAL:Exist
| | | +-defaultValue ::= NULL
| | +-logicalChannelConfig ::= CHOICE [defaultValue] OPTIONAL:Exist
| | +-defaultValue ::= NULL
| +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [2] OPTIONAL:Exist
| | +-DRB-ToAddMod ::= SEQUENCE [11111]
| | | +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist
| | | +-drb-Identity ::= INTEGER (1..32) [1]
| | | +-pdcp-Config ::= SEQUENCE [101] OPTIONAL:Exist
| | | | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist
| | | | +-rlc-AM ::= SEQUENCE OPTIONAL:Omit
| | | | +-rlc-UM ::= SEQUENCE OPTIONAL:Exist
| | | | | +-pdcp-SN-Size ::= ENUMERATED [len12bits]
| | | | +-headerCompression ::= CHOICE [notUsed]
| | | | +-notUsed ::= NULL
| | | +-rlc-Config ::= CHOICE [um-Bi-Directional] OPTIONAL:Exist
| | | | +-um-Bi-Directional ::= SEQUENCE
| | | | +-ul-UM-RLC ::= SEQUENCE
| | | | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | | +-dl-UM-RLC ::= SEQUENCE
| | | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | | +-t-Reordering ::= ENUMERATED [ms50]
| | | +-logicalChannelIdentity ::= INTEGER (3..10) [3] OPTIONAL:Exist
| | | +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist
| | | +-ul-SpecificParameters ::= SEQUENCE [1] OPTIONAL:Exist
| | | +-priority ::= INTEGER (1..16) [13]
| | | +-prioritisedBitRate ::= ENUMERATED [infinity]
| | | +-bucketSizeDuration ::= ENUMERATED [ms100]
| | | +-logicalChannelGroup ::= INTEGER (0..3) [2] OPTIONAL:Exist
| | +-DRB-ToAddMod ::= SEQUENCE [11111]
| | +-eps-BearerIdentity ::= INTEGER (0..15) [6] OPTIONAL:Exist
| | +-drb-Identity ::= INTEGER (1..32) [2]
| | +-pdcp-Config ::= SEQUENCE [101] OPTIONAL:Exist
| | | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist
| | | +-rlc-AM ::= SEQUENCE OPTIONAL:Omit
| | | +-rlc-UM ::= SEQUENCE OPTIONAL:Exist
| | | | +-pdcp-SN-Size ::= ENUMERATED [len12bits]
| | | +-headerCompression ::= CHOICE [notUsed]
| | | +-notUsed ::= NULL
| | +-rlc-Config ::= CHOICE [um-Bi-Directional] OPTIONAL:Exist
| | | +-um-Bi-Directional ::= SEQUENCE
| | | +-ul-UM-RLC ::= SEQUENCE
| | | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | +-dl-UM-RLC ::= SEQUENCE
| | | +-sn-FieldLength ::= ENUMERATED [size10]
| | | +-t-Reordering ::= ENUMERATED [ms50]
| | +-logicalChannelIdentity ::= INTEGER (3..10) [4] OPTIONAL:Exist
| | +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist
| | +-ul-SpecificParameters ::= SEQUENCE [1] OPTIONAL:Exist
| | +-priority ::= INTEGER (1..16) [13]
| | +-prioritisedBitRate ::= ENUMERATED [infinity]
| | +-bucketSizeDuration ::= ENUMERATED [ms100]
| | +-logicalChannelGroup ::= INTEGER (0..3) [3] OPTIONAL:Exist
| +-drb-ToReleaseList ::= SEQUENCE OF OPTIONAL:Omit
| +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist
| | +-explicitValue ::= SEQUENCE [111]
| | +-ul-SCH-Config ::= SEQUENCE [11] OPTIONAL:Exist
| | | +-maxHARQ-Tx ::= ENUMERATED [n5] OPTIONAL:Exist
| | | +-periodicBSR-Timer ::= ENUMERATED [sf20] OPTIONAL:Exist
| | | +-retxBSR-Timer ::= ENUMERATED [sf320]
| | | +-ttiBundling ::= BOOLEAN [FALSE]
| | +-drx-Config ::= CHOICE [release] OPTIONAL:Exist
| | | +-release ::= NULL
| | +-timeAlignmentTimerDedicated ::= ENUMERATED [infinity]
| | +-phr-Config ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-periodicPHR-Timer ::= ENUMERATED [sf500]
| | +-prohibitPHR-Timer ::= ENUMERATED [sf200]
| | +-dl-PathlossChange ::= ENUMERATED [dB3]
| +-sps-Config ::= SEQUENCE OPTIONAL:Omit
| +-physicalConfigDedicated ::= SEQUENCE [0000110010] OPTIONAL:Exist
| +-pdsch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-pucch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-pusch-ConfigDedicated ::= SEQUENCE OPTIONAL:Omit
| +-uplinkPowerControlDedicated ::= SEQUENCE OPTIONAL:Omit
| +-tpc-PDCCH-ConfigPUCCH ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-tpc-RNTI ::= BIT STRING SIZE(16) [0000001111111111]
| | +-tpc-Index ::= CHOICE [indexOfFormat3]
| | +-indexOfFormat3 ::= INTEGER (1..15) [1]
| +-tpc-PDCCH-ConfigPUSCH ::= CHOICE [setup] OPTIONAL:Exist
| | +-setup ::= SEQUENCE
| | +-tpc-RNTI ::= BIT STRING SIZE(16) [0000000111111010]
| | +-tpc-Index ::= CHOICE [indexOfFormat3]
| | +-indexOfFormat3 ::= INTEGER (1..15) [1]
| +-cqi-ReportConfig ::= SEQUENCE OPTIONAL:Omit
| +-soundingRS-UL-ConfigDedicated ::= CHOICE OPTIONAL:Omit
| +-antennaInfo ::= CHOICE [defaultValue] OPTIONAL:Exist
| | +-defaultValue ::= NULL
| +-schedulingRequestConfig ::= CHOICE OPTIONAL:Omit
+-securityConfigHO ::= SEQUENCE OPTIONAL:Omit
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
If you decode
< Activate dedicated EPS bearer context request > decoded message capture. Field values come from a live capture, not from the specification.
Activate dedicated EPS bearer context request ::= DIVISION +-EPS bearer identity ::= V | +-EPS bearer identity value ::= CHOICE [EPS bearer identity value 6] +-EPS session management protocol discriminator ::= V | +-Protocol discriminator ::= PD [2] +-Procedure transaction identity ::= V | +-Procedure transaction identity ::= CHOICE [No procedure transaction identity assigned] +-Activate dedicated EPS bearer context request message identity ::= V | +-Message type ::= MSG [C5] +-Spare half octet ::= V | +-Spare half octet ::= FIX [0] +-Linked EPS bearer identity ::= V | +-Linked EPS bearer identity value ::= CHOICE [EPS bearer identity value 5] +-EPS QoS ::= LV | +-Octet1 ::= DIVISION | | +-Length of EPS quality of service contents ::= LEN (0..255) [9] | +-Octet2 ::= DIVISION | | +-QCI ::= CHOICE [QCI 4] | +-Octet3 ::= DIVISION | | +-Maximum bit rate for uplink ::= CHOICE [384kbps] | +-Octet4 ::= DIVISION | | +-Maximum bit rate for downlink ::= CHOICE [384kbps] | +-Octet5 ::= DIVISION | | +-Guaranteed bit rate for uplink ::= CHOICE [128kbps] | +-Octet6 ::= DIVISION | | +-Guaranteed bit rate for downlink ::= CHOICE [128kbps] | +-Octet7 ::= DIVISION | | +-Maximum bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the maximum bit rate for uplink in octet 4] | +-Octet8 ::= DIVISION | | +-Maximum bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the maximum bit rate for uplink in octet 4] | +-Octet9 ::= DIVISION | | +-Guaranteed bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the guaranteed bit rate for uplink in octet 6] | +-Octet10 ::= DIVISION | +-Guaranteed bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the guaranteed bit rate for uplink in octet 6] +-TFT ::= LV | +-Octet1 ::= DIVISION | | +-Length of traffic flow template IE ::= LEN (0..255) [6] | +-Octet2 ::= DIVISION | | +-TFT operation code ::= CHOICE [Create new TFT] | | +-E bit ::= CHOICE [parameters list is not included] | | +-Number of packet filters ::= INT (0..15) [1] | +-Octet3-Octet256 ::= DIVISION | +-Packet filter list/Parameters list ::= OCTETARRAY SIZE(0..254) [3100023011] +-Transaction identifier ::= TLV OPTIONAL:Omit | +-Octet1 ::= DIVISION | | +-Transaction identifier IEI ::= IEI [5D] | +-Octet2 ::= DIVISION | | +-Length of Transaction identifier contents ::= LEN (0..255) [0] | +-Octet3 ::= DIVISION | | +-TI flag ::= CHOICE [The message is sent from the side that originates the TI] | | +-TIO ::= CHOICE [TI value 0] | | +-Spare ::= FIX [0] | +-Octet4 ::= DIVISION | +-ext ::= EXT (0..1) [1] | +-TIE ::= CHOICE [Reserved] +-Negotiated QoS ::= TLV OPTIONAL:Omit | +-Octet1 ::= DIVISION | | +-Quality of service IEI ::= IEI [30] | +-Octet2 ::= DIVISION | | +-Length of quality of service IE ::= LEN (0..255) [0] | +-Octet3 ::= DIVISION | | +-spare ::= FIX [0] | | +-Delay class ::= CHOICE [Subscribed delay class(MS to network direction)/Reserved(network to MS direction)] | | +-Reliability class ::= CHOICE [Subscribed reliability class(MS to network direction)/Reserved(network to MS direction)] | +-Octet4 ::= DIVISION | | +-Peak throughput ::= CHOICE [Subscribed peak throughput(MS to network direction)/Reserved(network to MS direction)] | | +-spare ::= FIX [0] | | +-Precedence class ::= CHOICE [Subscribed precedence(MS to network direction)/Reserved(network to MS direction)] | +-Octet5 ::= DIVISION | | +-spare ::= FIX [0] | | +-Mean throughput ::= CHOICE [Subscribed mean throughput(MS to network direction)/Reserved(network to MS direction)] | +-Octet6 ::= DIVISION | | +-Traffic Class ::= CHOICE [Subscribed traffic class(MS to network direction)/Reserved(network to MS direction)] | | +-Delivery order ::= CHOICE [Subscribed delivery order(MS to network direction)/Reserved(network to MS direction)] | | +-Delivery of erroneous SDUs ::= CHOICE [Subscribed delivery of erroneous SDUs(MS to network direction)/Reserved(network to MS direction)] | +-Octet7 ::= DIVISION | | +-Maximum SDU size ::= CHOICE [Subscribed maximum SDU size(MS to network direction)/Reserved(network to MS direction)] | +-Octet8 ::= DIVISION | | +-Maximum bit rate for uplink ::= CHOICE [Subscribed maximum bit rate for uplink(MS to network direction)/Reserved(network to MS direction)] | +-Octet9 ::= DIVISION | | +-Maximum bit rate for downlink ::= CHOICE [Subscribed maximum bit rate for uplink(MS to network direction)/Reserved(network to MS direction)] | +-Octet10 ::= DIVISION | | +-Residual BER ::= CHOICE [Subscribed residual BER(MS to network direction)/Reserved(network to MS direction)] | | +-SDU error ratio ::= CHOICE [Subscribed SDU error ratio(MS to network direction)/Reserved(network to MS direction)] | +-Octet11 ::= DIVISION | | +-Transfer delay ::= CHOICE [Subscribed transfer delay(MS to network direction)/Reserved(network to MS direction)] | | +-Traffic Handling priority ::= CHOICE [Subscribed traffic handling priority(MS to network direction)/Reserved(network to MS direction)] | +-Octet12 ::= DIVISION | | +-Guaranteed bit rate for uplink ::= INT (0..255) [0] | +-Octet13 ::= DIVISION | | +-Guaranteed bit rate for downlink ::= INT (0..255) [0] | +-Octet14 ::= DIVISION | | +-Spare ::= FIX [0] | | +-Signalling Indication ::= CHOICE [Not optimised for signalling traffic] | | +-Source Statistics Descriptor ::= CHOICE [unknown] | +-Octet15 ::= DIVISION | | +-Maximum bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate for downlink in octet 9.] | +-Octet16 ::= DIVISION | | +-Guaranteed bit rate for downlink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate for downlink in octet 9.] | +-Octet17 ::= DIVISION | | +-Maximum bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate for downlink in octet 9.] | +-Octet18 ::= DIVISION | +-Guaranteed bit rate for uplink (extended) ::= CHOICE [Use the value indicated by the Maximum bit rate for downlink in octet 9.] +-Negotiated LLC SAPI ::= TV OPTIONAL:Omit | +-Octet1 ::= DIVISION | | +-LLC SAPI IEI ::= IEI [32] | +-Octet2 ::= DIVISION | +-Spare ::= FIX [0] | +-LLC SAPI value ::= CHOICE [LLC SAPI not assigned] +-Radio priority ::= TV OPTIONAL:Omit | +-Octet1 ::= DIVISION | +-Radio priority IEI ::= IEI [8-] | +-spare ::= FIX [0] | +-Radio priority level value ::= CHOICE [priority level 1 (highest)] +-Packet flow identifier ::= TLV OPTIONAL:Omit | +-Octet1 ::= DIVISION | | +-Packet Flow Identifier IEI ::= IEI [34] | +-Octet2 ::= DIVISION | | +-Length of Packet Flow Identifier IE ::= LEN (0..255) [0] | +-Octet3 ::= DIVISION | +-spare ::= FIX [0] | +-Packet Flow Identifier value ::= CHOICE [Best Effort] +-Protocol configuration options ::= TLV OPTIONAL:Omit +-Octet1 ::= DIVISION | +-Protocol configuration options IEI ::= IEI [27] +-Octet2 ::= DIVISION | +-Length of protocol config options contents ::= LEN (0..255) [0] +-Octet3 ::= DIVISION | +-ext ::= EXT1 [1] | +-spare ::= FIX [0] | +-Configuration protocol ::= CHOICE [PPP for use with IP PDP type] +-Octet4-253 ::= DIVISION +-protocol config options contents ::= OCTETARRAY SIZE(0..250)
RRC : RRC Connection Reconfiguration Complete + NAS : Activate Dedicated EPS Bearer Context Accept
The last step of the call is an acknowledgement at two layers, and both parts are short. The RRC part confirms the reconfiguration and the NAS part accepts the dedicated bearer. Neither needs to repeat anything the request already carried.
RRC Connection Reconfiguration Complete part is very simple as shown below.
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
RRC_LTE:UL-DCCH-Message
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [rrcConnectionReconfigurationComplete]
+-rrcConnectionReconfigurationComplete ::= SEQUENCE
+-rrc-TransactionIdentifier ::= INTEGER (0..3) [0]
+-criticalExtensions ::= CHOICE [rrcConnectionReconfigurationComplete-r8]
+-rrcConnectionReconfigurationComplete-r8 ::= SEQUENCE [0]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
ESM,Activate dedicated EPS bearer context accept part is carried by UL information transfer message as follows.
< UL-DCCH-Message > decoded message capture. Field values come from a live capture, not from the specification.
RRC_LTE:UL-DCCH-Message
UL-DCCH-Message ::= SEQUENCE
+-message ::= CHOICE [c1]
+-c1 ::= CHOICE [ulInformationTransfer]
+-ulInformationTransfer ::= SEQUENCE
+-criticalExtensions ::= CHOICE [c1]
+-c1 ::= CHOICE [ulInformationTransfer-r8]
+-ulInformationTransfer-r8 ::= SEQUENCE [0]
+-dedicatedInfoType ::= CHOICE [dedicatedInfoNAS]
| +-dedicatedInfoNAS ::= OCTET STRING SIZE(ALIGNED) [6200C6]
+-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit
If you decode
NAS_LTE:ESM,Activate dedicated EPS bearer context accept
< Activate dedicated EPS bearer context accept > decoded message capture. Field values come from a live capture, not from the specification.
Activate dedicated EPS bearer context accept ::= DIVISION
+-EPS bearer identity ::= V
| +-EPS bearer identity value ::= CHOICE [EPS bearer identity value 6]
+-EPS session management protocol discriminator ::= V
| +-Protocol discriminator ::= PD [2]
+-Procedure transaction identity ::= V
| +-Procedure transaction identity ::= CHOICE [No procedure transaction identity assigned]
+-Activate dedicated EPS bearer context accept message identity ::= V
| +-Message type ::= MSG [C6]
+-Protocol configuration options ::= TLV OPTIONAL:Omit
+-Octet1 ::= DIVISION
| +-Protocol configuration options IEI ::= IEI [27]
+-Octet2 ::= DIVISION
| +-Length of protocol config options contents ::= LEN (0..255) [0]
+-Octet3 ::= DIVISION
| +-ext ::= EXT1 [1]
| +-spare ::= FIX [0]
| +-Configuration protocol ::= CHOICE [PPP for use with IP PDP type]
+-Octet4-Octet253 ::= DIVISION
+-protocol config options contents ::= OCTETARRAY SIZE(0..250)