ETWS (Earthquake and Tsunami Warning System)

ETWS is a kind of public warning system (PWS) to notify all the UEs in a specific area of emergency situation like Earthquake or Tsunami. The concept is very similar to Cell Broadcasting in WCDMA and GSM network.

In WCDMA, we used a special channel called CTCH (Common Traffic Channel) for this purpose, but in LTE we use a couple of SIB messages to periodically broadcast the warning information to all the UEs in a certain area simultaneouly. (I personally prefer this method than using CTCH). The SIBs that carry the information about ETWS is SIB10 and SIB11.

When an emergency situation happens, network broadcast the details of the emergency via SIB 10/SIB11 and inform UE to let decode SIB10/11 by sending special Paging message. When a UE receives this Paging message, it has to decode SIB10/11 and display the warning information on the screen.

Four questions follow from that. Which messages carry the warning ? How does it reach the UE from the place the emergency was declared ? What does a real capture of each one look like ? And where are the fields inside them defined ? The sections below take them in that order.

Which messages carry an ETWS warning ?

Three messages do the work, and only two of them carry a warning. The paging message says that a warning exists. The two system information blocks hold it, and 36.331 separates the two jobs on purpose.

In LTE, there are three main components getting involved in sending ETWS as follows.

i) Paging : ETWS Notification.

ii) SIB 10 : Primary Notification

iii) SIB 11 : Secondary Notification

36.331 clause 5.2.1.4 governs this, and it states the split plainly. An ETWS primary notification is contained in SystemInformationBlockType10, and an ETWS secondary notification is contained in SystemInformationBlockType11.

The two hold different things, which is why the order matters. SIB10 carries warningType, two octets that identify the kind of emergency and tell the UE whether to raise an emergency user alert and a popup. SIB11 carries the message text, as warningMessageSegment, and 36.331 lets that text be split across segments.

The paging message carries neither. Its etws-Indication is a single enumerated value. 36.331 adds what that value does: it triggers the UE to re-acquire schedulingInfoList in SystemInformationBlockType1, so a UE that was not reading SIB10 or SIB11 learns where to find them.

One rule in the same clause is easy to overlook. An ETWS capable UE in RRC_CONNECTED shall attempt to read paging at least once every defaultPagingCycle, to check whether a notification is present. Being connected does not excuse a UE from watching for warnings.

Figure 1. The order a UE picks the warning up in, from 36.331 clause 5.2.1.4. The paging indication carries no warning at all. It sends the UE back to SIB1 for the schedule, and the warning itself arrives in SIB10 and SIB11.

SIB10 arrives as one block. Its warningType is two octets and 36.331 applies no segmentation to it.
SIB11 may arrive in pieces. warningMessageSegmentNumber runs from 0 to 63, and warningMessageSegmentType flags the last one.
Figure 1 puts the primary notification on SIB10 and the secondary on SIB11, and the numbered list above now reads the same way. 36.331 clause 5.2.1.4 is the authority for both.

Paging announces, and the SIBs deliver : etws-Indication carries no warning text, and its only job is to send the UE back to SIB1 for the schedule.
SIB10 is the primary notification and SIB11 the secondary : 36.331 clause 5.2.1.4 states it in one sentence, and the two IE descriptions repeat it.
Only the secondary notification is segmented : the warning type fits in two octets, and the message text has no such limit.
A connected UE still reads paging : 36.331 requires an ETWS capable UE in RRC_CONNECTED to check at least once every defaultPagingCycle.

How does the warning reach the UE ?

The warning starts a long way from the radio. Two network elements sit in front of the MME, and the rest of this page never mentions them. The drawing below is the only place they appear.

Overall message flow for LTE ETWS from NTT DoCoMo Technology Report is as follows.

A sequence diagram over CBE, CBC, MME, eNB and Mobile terminal, numbered 1 to 11, running from an emergency at the CBE through Write-Replace Warning Request and Confirm to a Paging message and a system information broadcast, credited to an NTT DoCoMo Technology Report

Five lifelines run across the top: CBE, CBC, MME, eNB and Mobile terminal. The Emergency starburst sits at the CBE, on the far left.
Steps 1 to 5 never leave the core. The CBE asks the CBC to distribute. The CBC then generates the message and specifies the area at step 2, exchanges Write-Replace Warning Request and Confirm with the MME, and replies to the CBE at step 5.
Steps 6 and 8 are shaded processing boxes rather than messages: Area confirmation at the MME, and Processing for distribution area setting at the eNB. Step 7 between them is the Write-Replace Warning Request to the eNB.
Only steps 9 and 10 cross the air. Paging message (ETWS) comes first, then Distribution through system information broadcast.
Step 11, Write-Replace Warning Response, runs back from the eNB to the MME after the broadcast has started rather than before it.
The bracket on the right of the drawing labels step 10 as SIB11 : Primary Notification and SIB10 : Secondary Notification. Those two are the wrong way round. Figure 1 above and 36.331 clause 5.2.1.4 both put the primary notification on SIB10, and the picture itself cannot be corrected here.

The boundary at step 7 matters. Everything to the left of the MME is the warning system, and everything to the right of it is the radio network. 36.331 describes the SIB fields as re-encodings of information elements defined in 36.413, which is the interface step 7 uses.

That explains why messageIdentifier and serialNumber do not sound like RRC field names. They come from cell broadcast. 36.331 defines each of them by pointing first at 36.413 and then at a clause of 23.041.

The radio sees only the last three steps : steps 1 to 8 happen between the CBE, the CBC, the MME and the eNB before any UE hears anything.
The eNB answers after it starts broadcasting : step 11 follows step 10 in the drawing, so the response reports that the broadcast began rather than that it finished.
The SIB fields are re-encoded S1AP information elements : 36.331 defines them by reference to 36.413, which is why their names belong to cell broadcast rather than to RRC.
The annotation in the picture is wrong : it labels SIB11 as primary and SIB10 as secondary, and the specification says the reverse.

What do the captures show ?

The three blocks below are decodes rather than specification text. They record one exchange, the values in them are zero where a live warning would carry something, and they are left here exactly as they were recorded.

Following is Paging, SIB10, SIB11 showing the field (IEs) related to ETWS. (For the details of ETWS, refer to 3GPP TS23.828 and TS22.268 and TS 36.523 section14 ETWS)

NOTE : If you want to get an example of full log for ETWS, check out this tutorial from Amarisoft TechAcademy

Capture : Paging on PCCH, shown as a decoder tree. The values come from one recorded exchange and not from the specification.

RRC_LTE:PCCH-Message
PCCH-Message ::= SEQUENCE
  +-message ::= CHOICE [c1]
    +-c1 ::= CHOICE [paging]
      +-paging ::= SEQUENCE [0110]
        +-pagingRecordList ::= SEQUENCE OF OPTIONAL:Omit
        +-systemInfoModification ::= ENUMERATED [true] OPTIONAL:Exist
        +-etws-Indication ::= ENUMERATED [true] OPTIONAL:Exist
        +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

etws-Indication ::= ENUMERATED [true] OPTIONAL:Exist is the whole of the trigger. One enumerated value is all the paging message contributes.
systemInfoModification is present and also true, which tells the UE that other system information changed at the same time.
pagingRecordList ::= SEQUENCE OF OPTIONAL:Omit is the interesting omission. Nothing here addresses a particular UE, which is what makes this a broadcast trigger rather than a page.

Capture : SIB10 inside a BCCH-DL-SCH system information message, shown as a decoder tree. Field values are from the same recorded exchange.

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 [sib10]
            |   +-sib10 ::= SEQUENCE [1]
            |     +-messageIdentifier ::= BIT STRING SIZE(16) [0000000000000000]
            |     +-serialNumber ::= BIT STRING SIZE(16) [0000000000000000]
            |     +-warningType ::= OCTET STRING SIZE(2) [0000]
            |     +-warningSecurityInfo ::= OCTET STRING SIZE(50) [0000000000000000000000000000
                                                                   0000000000000000000000000000
                                                                   0000000000000000000000000000
                                                                   0000000000000000] OPTIONAL:Exist
            +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

sib-TypeAndInfo holds one entry and the CHOICE resolves to sib10. A system information message can carry several SIBs, and this one carries a single SIB.
warningType ::= OCTET STRING SIZE(2) is the primary notification itself, and two octets is its whole size.
warningSecurityInfo ::= OCTET STRING SIZE(50) runs across four lines of zeroes. That field has since been renamed, and the last section on this page gives the new name.
Every value in this capture is zero. It records the shape of the message rather than a live warning, which is worth remembering before reading anything into the numbers.

Capture : SIB11 inside a BCCH-DL-SCH system information message, shown as a decoder tree. Field values are from the same recorded exchange.

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 [sib11]
            |   +-sib11 ::= SEQUENCE [1]
            |     +-messageIdentifier ::= BIT STRING SIZE(16) [0000000000000000]
            |     +-serialNumber ::= BIT STRING SIZE(16) [0000000000000000]
            |     +-warningMessageSegmentType ::= ENUMERATED [notLastSegment]
            |     +-warningMessageSegmentNumber ::= INTEGER (0..63) [0]
            |     +-warningMessageSegment ::= OCTET STRING SIZE(ALIGNED)
            |     +-dataCodingScheme ::= OCTET STRING SIZE(1) [00] OPTIONAL:Exist
            +-nonCriticalExtension ::= SEQUENCE OPTIONAL:Omit

warningMessageSegmentType ::= ENUMERATED [notLastSegment] and warningMessageSegmentNumber ::= INTEGER (0..63) [0] together say this is the first of at least two segments.
dataCodingScheme ... OPTIONAL:Exist is present, and that is not an accident. 36.331 marks the field Cond Segment1, which it explains as mandatory in the first segment of SIB11 and absent otherwise. Segment number 0 is the first segment.
warningMessageSegment ::= OCTET STRING SIZE(ALIGNED) has no value printed beside it. That octet string is where the warning text would sit.
The two SIBs share messageIdentifier and serialNumber. A UE uses that pair to tell one warning from another, and to recognise a repeat of one it already showed.

A paging trigger names no UE : pagingRecordList is omitted, which is what separates a broadcast indication from an ordinary page.
The capture is consistent with the conditional rule : dataCodingScheme is present exactly where 36.331 requires it, in segment number 0.
Zeroes are shape, not content : every value in these decodes is zero, so the blocks show the structure of a warning rather than a warning.
messageIdentifier and serialNumber tie the two SIBs together : the same pair appears in both, which is how a UE matches a secondary notification to its primary one.

Where are these fields defined ?

The field names in those captures come from three specifications rather than one. 36.331 gives the radio encoding, and it then defines almost every field by pointing somewhere else.

You can find the defailed description of each of these information elements in the following specification. (Refer to 36.331 for framework specification).

sib10.messageIdentifier : 23.041-9.4.1.2.2 Message Identifier
sib10.serialNumber : 23.041-9.4.1.2.1 Serial Number
sib10.warningType : 23.041-9.3.24 Warning-Type
sib10.warningSecurityInfo : 23.041-9.3.25 Warning-Security-Information

sib11.messageIdentifier : 23.041-9.4.1.2.2 Message Identifier
sib11.serialNumber : 23.041-9.4.1.2.1 Serial Number
sib11.swarningMessageSegment : 23.041-9.4.2.2.5 CB Data
sib11.dataCodingScheme : 23.038 - 5. CBS Data Coding Scheme

Two of those definitions have moved since the captures above were taken. The current text of both blocks is short enough to read in full.

Following is based on 36.331 v19.3.0 (Release 19)

SystemInformationBlockType10 ::=	SEQUENCE {
	messageIdentifier					BIT STRING (SIZE (16)),
	serialNumber						BIT STRING (SIZE (16)),
	warningType							OCTET STRING (SIZE (2)),
	dummy								OCTET STRING (SIZE (50))	OPTIONAL,		-- Need OP
	...,
	lateNonCriticalExtension			OCTET STRING				OPTIONAL,
	[[
	warningAreaCoordinates-r19			OCTET STRING			OPTIONAL		-- Need OR
	]]
}

SystemInformationBlockType11 ::=	SEQUENCE {
	messageIdentifier					BIT STRING (SIZE (16)),
	serialNumber						BIT STRING (SIZE (16)),
	warningMessageSegmentType			ENUMERATED {notLastSegment, lastSegment},
	warningMessageSegmentNumber			INTEGER (0..63),
	warningMessageSegment				OCTET STRING,
	dataCodingScheme					OCTET STRING (SIZE (1))		OPTIONAL,	-- Cond Segment1
	...,
	lateNonCriticalExtension				OCTET STRING				OPTIONAL,
	[[
	warningAreaCoordinatesSegment-r19	OCTET STRING				OPTIONAL		-- Need OR
	]]
}

warningSecurityInfo is gone. The field in that position is now called dummy, and 36.331 says it is not used in the specification and shall be ignored by the UE if received. The capture above predates that change.
Two fields arrived in Release 19. SIB10 gained warningAreaCoordinates-r19 and SIB11 gained warningAreaCoordinatesSegment-r19, both optional, both carrying the geographical area a notification is valid for.
dataCodingScheme carries the comment Cond Segment1, which is the conditional rule the SIB11 capture above satisfies.
Everything else matches the captures field for field, including the order.

The Paging message has not moved at all in the part that matters.

Following is based on 36.331 v19.3.0 (Release 19)

Paging ::=					SEQUENCE {
	pagingRecordList				PagingRecordList					OPTIONAL,	-- Need ON
	systemInfoModification			ENUMERATED {true}					OPTIONAL,	-- Need ON
	etws-Indication					ENUMERATED {true}					OPTIONAL,	-- Need ON
	nonCriticalExtension			Paging-v890-IEs						OPTIONAL
}

etws-Indication is still a single optional ENUMERATED {true}, exactly as the capture shows it.
pagingRecordList and systemInfoModification are both optional too, so all three fields of a paging message can be absent.

36.331 defines almost none of these fields itself. Each description maps its field onto an information element of 36.413, and then onto a clause of 23.041. messageIdentifier, serialNumber, warningType and dataCodingScheme all work that way. warningMessageSegment carries a segment of the Warning Message Contents IE, which 23.041 calls the CB data IE.

23.038 sits at the end of one of those chains. It defines the CBS Data Coding Scheme as indicating the intended handling of the message, the character set and coding, and the language where one applies. Bits 7 to 4 of that single octet pick the coding group.

One more block belongs beside these two. 36.331 clause 5.2.1.5 gives CMAS the same treatment in SystemInformationBlockType12, and a UE watching for ETWS is normally watching for CMAS on the same paging occasion.

36.331 encodes, and other specifications define : almost every field description points first at 36.413 and then at 23.041.
One field in SIB10 has been retired : warningSecurityInfo is now dummy, unused, and to be ignored on receipt.
Release 19 added warning area coordinates : both SIBs gained an optional field carrying the geography a notification applies to.
CMAS uses the same mechanism : 36.331 clause 5.2.1.5 puts it in SystemInformationBlockType12, reached by the same kind of paging indication.

Reference

[1] 36.331 : 3GPP - E-UTRA; Radio Resource Control; Protocol specification, v19.3.0. Clause 5.2.1.4 covers the ETWS indication and the primary and secondary split, clause 5.2.1.5 covers CMAS, and the SystemInformationBlockType10, SystemInformationBlockType11 and Paging definitions carry the field descriptions quoted above.

[2] 23.038 : 3GPP - Alphabets and language-specific information, v20.0.0. Clause 5 defines the CBS Data Coding Scheme that dataCodingScheme carries.