Is this a realistic time period, segments every 512ms feels slow
I'm very sorry for this long reply.
The two basic information blocks (Master Information Block - MIB, and SIB1) have a fixed transmit interval defined by the LTE spec. And data transmission for LTE can be broken down into radio frames of length 10ms, with 1ms subframes within each radio frame, and each subframe having two 0.5ms slots.
The MIB is retransmitted on every 4th radio frame (so every 40 ms) with
identical duplicates on every radio frame between (meaning the MIB is effectively broadcast on every frame), while the SIB1 is transmitted on every 8th frame with
non-identical duplicates on every
other subframe for redundancy on the frames in between those 8 (effectively it's retransmitted every 20ms with an incrementing redundancy counter, but will only change every 80ms).
The SIB1 then defines which periodic SI messages are being transmitted by that specific LTE cell, and how often. The SI messages can contain multiple blocks (so you could transmit two SIBs together within one SI message). Within those periodic SIBs is SIB12 where emergency alert messages are sent, as well as other SIBs like SIB5 which defines other LTE frequencies and conditions for the phone to reselect a one of those to connect to.
Each network can pick the periodicity of their SI messages themselves, defined in the SIB1 as an interval of radio frames. Typically most messages will be set to something between 8 and 64 frames. Some networks bunch up their SIBs into one big SI message, while others will send them all out individually. There's no real rhyme or reason and both have their benefits and drawbacks.
There's some leeway built in with another parameter called si-WindowLength which defines a time window in ms which the network must start transmitting the system information message after it has reached the radio frame where it has told a device to listen from.
Within the defined si-WindowLength, the same SI message containing the SIBs can be transmitted multiple times in case a device failed to read it the first time and so that the device doesn't need to wait for the entire si-Periodicity cycle to try again. The SI message and SIB content doesn't necessarily need to be identical, so in the case of a broadcast the cell can send out multiple message segments within the once SI window to improve overall distribution speed. Additionally, as different SIs can have the same periodicity, there's also an offset applied to each message within the list defined in SIB1. For a given si-Periodicity (P) and si-WindowLength (W), the start of the SI window for the n-th message in the list is offset by (n-1)*W.
By combining the periodicity (frequency) and the window length (time slot) you can put together a delivery window, and then the sib-MappingInfo within the SIB1 will tell you what will arrive within that window.
Devices won't actually seek out new SIB1 data on a regular basis. It will whenever a device performs an initial cell search, when returning from out of coverage, or when a device is in "idle mode" (not actually in a data session, call, etc.). Since when a network isn't transmitting a cell broadcast no SIB12 will be defined as broadcasting in the SIB1, devices won't look for it and won't know there is a broadcast occurring.
You might wonder in that case how a device gets the alert then. Well, there's a another message which is sent explicitly to devices rather than as a broadcast called paging messages. These typically carry information like new time-limited authentication credentials to the network (TMSI), but they also were extended in LTE version 9 to add a "cmas-Indication-r9" flag. This flag is present and set to true whenever a commercial mobile alert system (CMAS) broadcast is occurring, and will result in the networking sending Paging messages to devices at effectively every possible opportunity. This lets the device know to check for an updated SIB1 message so it can find the SIB12 message segments so it can piece them all together and so that it can be displayed to a user.
Paging messages are only sent to devices which have attached to the network, and their communication is configured within SIB2.The network tells a device that it should operate with a discontinuous reception cycle of a specified radio frame interval "defaultPagingCycle" (typically rf64). Another field, "nB", dictates how many paging groups exist within the cell. The device can calcuate which group they are part of through their device's identifier for that connection to the network, and can also calculate their "paging opportunity". These two values can be combined so a device can calculate exactly which radio frame to listen for paging in, and even which subframe to listen within, effectively meaning a phone only needs to listen to the network for 1ms every 640ms while in idle mode.
An example of EE's SIB1 during the 2023 test shows they used rf32, so every 320ms. In reality, you might get multiple SIB12 messages within the 10ms radio frame.
Code:
TickTime : 512.949
Exy LTE RRC OTA Packet
Direction : Downlink
bcch-dl-sch
message -> c1 -> systemInformationBlockType1
cellAccessRelatedInfo
plmn-IdentityList
[0]
plmn-Identity
mcc
[0] : 2
[1] : 3
[2] : 4
mnc
[0] : 3
[1] : 0
cellReservedForOperatorUse : notReserved
[1]
plmn-Identity
mcc
[0] : 2
[1] : 3
[2] : 4
mnc
[0] : 3
[1] : 2
cellReservedForOperatorUse : notReserved
trackingAreaCode : '00101100 01011000'B(11352)
cellIdentity : '00000101 00000001 01100000 0001'B(5248513)
cellBarred : notBarred
intraFreqReselection : allowed
csg-Indication : false
cellSelectionInfo
q-RxLevMin : -64
p-Max : 23
freqBandIndicator : 3
schedulingInfoList
[0]
si-Periodicity : rf16
sib-MappingInfo
[1]
si-Periodicity : rf16
sib-MappingInfo
[0] : sibType3
[2]
si-Periodicity : rf16
sib-MappingInfo
[0] : sibType4
[3]
si-Periodicity : rf32
sib-MappingInfo
[0] : sibType5
[4]
si-Periodicity : rf32
sib-MappingInfo
[0] : sibType6
[5]
si-Periodicity : rf32
sib-MappingInfo
[0] : sibType7
[6]
si-Periodicity : rf32
sib-MappingInfo
[0] : sibType12-v920
si-WindowLength : ms20
systemInfoValueTag : 0
nonCriticalExtension
nonCriticalExtension
ims-EmergencySupport-r9 : true
The first SI has no SIBs for some reason. Please don't ask me why.
Periodicity 160 ms schedule:
| SI Message | schedulingInfoList Index (n) | SIBs Contained | Window Start Time (relative) |
|---|
| SI Message 1 | 0 | None | (0 x 20 ms) = 0 ms |
| SI Message 2 | 1 | SIB3 | (1 x 20 ms) = 20 ms |
| SI Message 3 | 2 | SIB4 | (2 x 20 ms) = 40 ms |
Periodicity 320 ms schedule:
| SI Message | schedulingInfoList Index (n) | SIBs Contained | Window Start Time (relative) |
|---|
| SI Message 4 | 3 | SIB5 | (3 x 20 ms) = 60 ms |
| SI Message 5 | 4 | SIB6 | (4 x 20 ms) = 80 ms |
| SI Message 6 | 5 | SIB7 | (5 x 20 ms) = 100 ms |
| SI Message 7 | 6 | SIB12 | (6 x 20 ms) = 120 ms |
As you might be able to tell, the two periodicities and their windows will overlap as they are always a multiple of each other, which is why the si-WindowLength exists so that the network can schedule the SIs appropriately.
For the 2023 test on EE, the alert was distributed across 25 segments. The device must receive all segments in order to display the alert, but these don't have to be received in order. The device can piece together the message from all the segments, and knows the total count of segments when it detects a SIB12 with the warningMessageSegment-r9 field set as lastSegment.
As multiple messages could be broadcast at the same time, the messages also have a serialNumber-r9 field to ensure segments from different messages don't get combined. The messageIdentifier-r9 field isn't really an identifier as such, but rather more of a "alert type", and is where the Severe vs Extreme vs "Presidential" distinction is made.
If we assume a phone is in idle mode and has just missed the paging indication, we could end up waiting 640ms for the next cmas-Indication-r9 flag. Paging success rate is somewhere around 92% in most cases, so we can average out that success rate with the periodicity to be about 696ms.
Then, since SIB1 is broadcast every 20ms, we have another ~20ms of latency on top of that.
In a "worst-case" scenario, assuming only one SIB12 was received per period, and a successful delivery/decoding rate of 75% including the network's ability to actually schedule the SI message successfully every 32 frames, we can calculate that the message could take:
320ms * 25 / 0.75 ≈ 10,666ms
Add it all together for about 11.4 seconds.
So yes, it could take up to maybe 12 seconds to successfully receive a full cell broadcast, even at the best of times. It's even worse in Wales where the message is bilingual and uses different message encoding to cater for the Welsh characters. Maybe up to 55 message segments for those, so maybe up to 24 seconds there!
This latency is one of the reasons that the Earthquake and Tsunami Warning System was developed as well with time-critical alerts in mind. In comparison, it is broken down into a primary and secondary notification, with the same paging-based alert system (but called etws-Indication) being used. The type of ETWS alert is sent in a SIB10 primary notification (i.e. Earthquake or Tsunami) which is extremely small and allows for the alert to immediately be triggered on devices, while SIB11 secondary notification contains the textual message which will be shown as an alert and read out by a device when fully received which may take some time.
Separate LTE features allow locking down of a cell for specific types of customer, such as emergency services. These amusingly rely on the end device being compliant and revoking its own access to features of the network if the SIM card does not have the correct access control flag set. This is also automatically used when a site becomes congested during major events.
