Before continuing with GSM/GERAN System Information Message Types, thanks for the enquiries regarding LTE and requests for an example of a systeminformationblocktype(SIB). It would appear there is a requirement to explore LTE and UMTS SIBs some more before moving on to GSM/GERAN. I will do my best to answer some of the enquiries.
For educational purposes only, followingthe masterinformationblock(MIB) having been decoded by the UE a useful example of content for systeminformationblocktype1 was illustrated by Ralf Kreher and Karsten Gaenger (c)2011 using Tektronix K2Air as an example when conducting a LTE investigation into signalling troubleshooting and optimisation.
+-------------------------------------------------------+---------------------------------------------+
|ID Name |Comment or Value |
+-------------------------------------------------------+---------------------------------------------+
|56 05:43:34,555,032 RRC-UU K2AIR-PHY PDSCH
LTE-RLC/MAC MAC-TM-PDU (DL) LTE-RRC_BCCH_DL_SCH
systemInformationBlockType1 |
|Tektronix K2Air LTE PHY Data Message Header
(K2AIR-PHY) PDSCH (= PDSCH Message) |
|1 PDSCH Message |
|1.1 Common Message Header |
|Protocol Version |0 |
|Transport Channel Type |DL-SCH |
|Physical Channel Type |PDSCH |
|System Frame Number |454 |
|Direction |Downlink |
|Radio Mode |FDD |
|Internal use |0 |
|Status |Original data |
|Reserved |0 |
|Physical Cell ID |0 |
|UE ID/RNTI Type |SI-RNTI |
|Subframe Number |5 |
|UE ID/RNTI Value |'ffff'H |
|1.2 PDSCH Header |
|CRC report |CRC ok |
|HARQ process number |0 |
|Reserved |0 |
|Transport Block Indicator |single TB info |
|Reserved |0 |
|1.2.1 Transport Block#1 Information |
|Transport Block#1 Size |144 |
|Modulation Order DL 1 |QPSK |
|New Data Indicator DL 1 |new data |
|Redundancy Version DL 1 |1 |
|Reserved |0 |
|Modulation Scheme Index DL 1 |5 |
|Reserved |0 |
|1.2.2 Transport Block Data |
|TB1 Mac-PDU Data |40 51 00 21 00 00 20 00 10 0c 14 01
10
21 00 68 22 b6 |
|Padding |'0068'H |
|1.3 Additional Call related Info |
|Number Of Logical Channel Informations |1 |
|1.3.1 Logical Channel Information |
|LCID |0 |
|RLC Mode |Transparent Mode |
|Radio Bearer ID |0 |
|Radio Bearer Type |Control Plane (Signalling) |
|Spare |0 |
|Spare |0 |
|Logical Channel Type |BCCH |
|Call ID |'fffffff5'H |
|3GPP LTE-RLC/MAC Rel.8 (MAC TS 36.321 V8.5.0,
2009-03, RLC TS 36.322 V8.5.0, 2009-03) (LTE-RLC/
MAC) MAC-TM-PDU (DL) (= MAC PDU (Transparent Content
Downlink)) |
|1 MAC PDU (Transparent Content Downlink) |
|MAC Transparent Data |40 51 00 21 00 00 20 00 10 0c 14
01 10
21 00 68 22 b6 |
|RRC (BCCH DL SCH) 3GPP TS 36.331 V8.5.0 (2009-03)
(LTE-RRC_BCCH_DL_SCH)
systemInformationBlockType1 (=
systemInformationBlockType1) |
|bCCH-DL-SCH-Message |
|1 message |
|1.1 Standard |
|1.1.1 systemInformationBlockType1 |
|1.1.1.1 cellAccessRelatedInfo |
|1.1.1.1.1 plmn-IdentityList |
|1.1.1.1.1.1 pLMN-IdentityInfo |
|1.1.1.1.1.1.1 plmn-Identity |
|1.1.1.1.1.1.1.1 mcc |
|1.1.1.1.1.1.1.1.1 mCC-MNC-Digit |2 |
|1.1.1.1.1.1.1.1.2 mCC-MNC-Digit |9 |
|1.1.1.1.1.1.1.1.3 mCC-MNC-Digit |9 |
|1.1.1.1.1.1.1.2 mnc |
|1.1.1.1.1.1.1.2.1 mCC-MNC-Digit |0 |
|1.1.1.1.1.1.1.2.2 mCC-MNC-Digit |0 |
|1.1.1.1.1.1.2 cellReservedForOperatorUse |notReserved |
|1.1.1.1.2 trackingAreaCode |'0000'H |
|1.1.1.1.3 cellIdentity |'2000100'H |
|1.1.1.1.4 cellBarred |notBarred |
|1.1.1.1.5 intraFreqReselection |notAllowed |
|1.1.1.1.6 csg-Indication |false |
|1.1.1.2 cellSelectionInfo |
|1.1.1.2.1 q-RxLevMin |-65 |
|1.1.1.3 freqBandIndicator |1 |
|1.1.1.4 schedulingInfoList |
|1.1.1.4.1 schedulingInfo |
|1.1.1.4.1.1 si-Periodicity |rf16 |
|1.1.1.4.1.2 sib-MappingInfo |
|1.1.1.4.2 schedulingInfo |
|1.1.1.4.2.1 si-Periodicity |rf32 |
|1.1.1.4.2.2 sib-MappingInfo |
|1.1.1.4.2.2.1 sIB-Type |sibType3 |
|1.1.1.4.2.2.2 sIB-Type |sibType6 |
|1.1.1.4.3 schedulingInfo |
|1.1.1.4.3.1 si-Periodicity |rf32 |
|1.1.1.4.3.2 sib-MappingInfo |
|1.1.1.4.3.2.1 sIB-Type |sibType5 |
|1.1.1.5 si-WindowLength |ms20 |
|1.1.1.6 systemInfoValueTag |22 |
This form of analysis provides an excellent grounding when conducting ICCSA.Why would that be so? Familiarisation with this education content enables knowledge to be gleaned from the real-world SIBs detected by the UE at particular locations. Importantly information that informs the UE about varying cells benefits an investigation. For instance, we know that when the UE has successfully received and decoded MIB and SIBs type 1 and 2 etc during its travels SIB type9 might identify (H)eNobeB that is available. To be clear that latter information provides two unique pieces of information. (1) The identity of the radio source (2) it is location specific to tens of metres in an area thus refines location identification where the UE would have dwelt (dwell time - slow moving UE).
It also refines the location for the investigation and even where SIB1 and SIB2 provide a wider location area the UE detection (SIB type9) of the (H)eNobeB coverage would have the effect of demonstrating pre-requisite requirement of proximity to an area. Now readers could point out how would the person conducting the ICCSA know about the (H)eNobeB in the first place if call/data records are not available. For those situations where immediate is important aspect of current bandit surveillance the UE stores relevant information of the radio resources in an area for up to 3-hours after which old data are discarded. For a live UE acquisition this time frame could be useful. For a UE switched off (e.g. at the target site area) retains that information and requires extraction and harvest without invoking UE power up and network detection and registration.
