18 PWS

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

18.1 CMAS on LTE

18.1.1 PWS reception in RRC_IDLE state / Duplicate detection

18.1.1.1 Test Purpose (TP)

(1)

with { UE in RRC_IDLE state }

ensure that {

when { the UE receives a Paging message with cmas-Indication }

then { the UE is able to retrieve all the PWS message segments being broadcast, re assemble the message and alert the user }

}

(2)

With { UE in RRC_IDLE state and pc_PWS_UpperLayer set to ‘TRUE’ }

ensure that {

when  { the UE receives a PWS message which is a duplicate of an already received message }

then { the UE discards the message and does not alert the user }

}

18.1.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clauses 5.2.2.4, 5.2.2.19, 5.2.2.20, 5.3.2.3; TS 23.041 clause 9.1.3.4.2.

[TS 36.331, clause 5.2.2.4]

The UE shall:

1> if the UE is CMAS capable:

2> upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> discard any previously buffered warningMessageSegment;

3> clear, if any, stored values of messageIdentifier and serialNumber for SystemInformationBlockType12 associated with the discarded warningMessageSegment ;

2> when the UE acquires SystemInformationBlockType1 following CMAS indication, upon entering a cell during RRC_IDLE, following successful handover and upon connection re-establishment:

3> if schedulingInfoList indicates that SystemInformationBlockType12 is present:

4> acquire SystemInformationBlockType12;

NOTE 3: UEs shall start acquiring SystemInformationBlockType12 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

1> if the UE is interested to receive MBMS services; and

1> if schedulingInfoList indicates that SystemInformationBlockType13 is present and the UE does not have stored a valid version of this system information block:

2> acquire SystemInformationBlockType13;

The UE may apply the received SIBs immediately, i.e. the UE does not need to delay using a SIB until all SI messages have been received. The UE may delay applying the received SIBs until completing lower layer procedures associated with a received or a UE originated RRC message, e.g. an ongoing random access procedure.

NOTE 4: While attempting to acquire a particular SIB, if the UE detects from schedulingInfoList that it is no longer present, the UE should stop trying to acquire the particular SIB.

[TS 36.331, clause 5.2.2.19]

Upon receiving SystemInformationBlockType12, the UE shall:

1> if the SystemInformationBlockType12 contains a complete warning message:

2> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

2> continue reception of SystemInformationBlockType12;

1> else:

2> if the received values of messageIdentifier and serialNumber are the same (each value is the same) as a pair for which a warning message is currently being assembled:

3> store the received warningMessageSegment;

3> if all segments of a warning message have been received:

4> assemble the warning message from the received warningMessageSegment;

4> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

4> stop assembling a warning message for this messageIdentifier and serialNumber and delete all stored information held for it;

3> continue reception of SystemInformationBlockType12;

2> else if the received values of messageIdentifier and/or serialNumber are not the same as any of the pairs for which a warning message is currently being assembled:

3> start assembling a warning message for this messageIdentifier and serialNumber pair;

3> store the received warningMessageSegment;

3> continue reception of SystemInformationBlockType12;

The UE should discard warningMessageSegment and the associated values of messageIdentifier and serialNumber for SystemInformationBlockType12 if the complete warning message has not been assembled within a period of 3 hours.

NOTE: The number of warning messages that a UE can re-assemble simultaneously is a function of UE implementation.

[TS 36.331, clause 5.2.2.20]

No UE requirements related to the contents of this SystemInformationBlock apply other than those specified elsewhere e.g. within procedures using the concerned system information, and/ or within the corresponding field descriptions.

[TS 36.331, clause 5.3.2.3]

Upon receiving the Paging message, the UE shall:

1> if the cmas-Indication is included and the UE is CMAS capable:

2> re-acquire SystemInformationBlockType1 immediately, i.e., without waiting until the next system information modification period boundary as specified in 5.2.1.5;

2> if the schedulingInfoList indicates that SystemInformationBlockType12 is present:

3> acquire SystemInformationBlockType12;

[TS 23.041, clause 9.1.3.4.2]

The warning message to be broadcast is delivered via MMEs to multiple eNodeBs. The eNodeB(s) are responsible for scheduling the broadcast of the new message and the repetitions in each cell.

The overall warning message delivery procedure is presented in figure 9.1.3.4.2-1:

Figure 9.1.3.4.2-1: Warning message delivery procedure in E-UTRAN

0. Network registration and security (e.g. mutual authentication) procedures are performed. The UE stores a flag that indicates whether or not it has authenticated the network.

NOTE 1: This step is performed each time a UE is attached to a network (e.g. after each power on).

1. CBE (e.g. Information Source such as PSAP or Regulator) sends emergency information (e.g. "warning type", "warning message", "impacted area", "time period") to the CBC. The CBC shall authenticate this request.

2. Using the "impacted area" information, the CBC identifies which MMEs need to be contacted and determines the information to be place into the Warning Area Information Element. The CBC sends a Write-Replace Warning Request message containing the warning message to be broadcast and the delivery attributes (Message identifier, Serial Number, Tracking Area ID list, Warning Area, OMC ID, CWM Indicator) to MMEs.

The warning messages use the coding scheme for CBS data specified in 3GPP TS 23.038 [3].

The Tracking Area ID list is only used by the MME. The MME uses it for selecting which eNodeBs to forward the Write-Replace Warning Request message to.

The Warning Area shall be a list of Cell IDs and/or a list of TAIs and/or one or more Emergency Area IDs. The Warning Area is only used by the eNodeB. The eNodeB is configured with the TAI(s) and Cell ID(s) it serves and the Emergency Area ID(s) that it belongs to. The eNodeB checks for any match of the contents of the Warning Area with these IDs to identify the cells where to distribute the warning message. The Warning Area is an optional information element. If the Warning Area is absent, it shall be interpreted as "all cells on the eNodeB". The number of cell IDs will be limited by the message size on SBc and S1-MME. An Emergency Area ID is unique within the PLMN.

The message may include an OMC ID. If present, it indicates the OMC to which the Trace record generated in step 8 is destined. Co-location of that OMC with the CBC is an operator option.

CBC shall set the Concurrent Warning Message (CWM) indicator in all Write-Replace Warning Request messages, if the PLMN supports concurrent warning message broadcasts.

NOTE 2: Due to requirements in earlier versions of the specification, it is possible that "digital signature" and "timestamp" information are transmitted within the "warning message".

3. The MME sends a Write-Replace Warning Confirm message that indicates to the CBC that the MME has started to distribute the warning message to eNodeBs.

If this message is not received by the CBC within an appropriate time period, the CBC can attempt to deliver the warning message via another MME in the same pool area.

4. Upon reception of the Write-Replace Confirm messages from the MMEs, the CBC may confirm to the CBE that it has started to distribute the warning message.

5. The MME forwards Write-Replace Warning Message Request to eNodeBs. The MME shall use the Tracking Area ID list to determine the eNodeBs in the delivery area. If the Tracking Area ID list is empty the message is forwarded to all eNodeBs that are connected to the MME.

6. When S1-flex is used the eNodeB may receive same message from multiple MMEs. The eNodeB detects duplicate messages by checking the message identifier and serial number fields within the warning message. If any redundant messages are detected only the first one received will be broadcasted by the cells. The eNodeB shall use the Warning Area information to determine the cell(s) in which the message is to be broadcast. The eNodeBs return a Distribute Warning Message Response to the MME, even if it was a duplicate.

If there is a warning broadcast message already ongoing and the CWM Indicator is included in the Write-Replace Warning Message Request, the eNodeB does not stop existing broadcast message but start broadcasting the new message concurrently. Otherwise the eNodeB shall immediately replace the existing broadcast message with the newer one.

NOTE 3: If concurrent warning messages are not supported, this requires the CBE/CBC to take care that ‘lower’ priority warnings are not sent while a higher priority warning is still being sent.

The eNodeB broadcasts the message frequently according to the attributes set by the CBC that originated the warning message distribution.

7. If the UE has been configured to receive warning messages , and the UE has authenticated the core network of the eNodeB it is camped on, then the UE proceeds as follows:

The UE can use "warning type" values, ‘earthquake’, ‘tsunami’ or ‘earthquake and tsunami’, immediately to alert the user. When "warning type" is ‘test’, the UE silently discards the primary notification, but the UE specially designed for testing purposes may proceed with the following procedures.

The UE activates reception of the broadcast messages containing the "warning message".

The UE indicates the contents of the "warning message" to the user.

8. From the Write-Replace Warning Response messages returned by eNodeB’s the MME determines the success or failure of the delivery and creates a trace record. Any OMC ID received in step 2 is written to the trace record to permit the O&M system to deliver them to the desired destination.

18.1.1.3 Test description

18.1.1.3.1 Pre-test conditions

System Simulator:

  • Cell 1

UE:

None.

Preamble:

– The UE is in state Registered, Idle mode (state 2) according to [18].

18.1.1.3.2 Test procedure sequence

Table 18.1.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS include a CMAS message with new messageIdentifier and serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

2

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

1

P

EXCEPTION: Steps 3a1 to 3a3 describe behaviour that depends on UE configuration; the "lower case letter" identifies a step sequence that take place if the pc_PWS_UpperLayer is set to TRUE.

3 a1

The SS waits for 10s.

3a2

The SS include a CMAS message with same messageIdentifier and serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

3a3

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

2

F

NOTE 1: SystemInformationBlockType12 contain 3 segments.

NOTE 2: The data indication and user alerting are the UE implementation issues.

18.1.1.3.3 Specific message contents

Table 18.1.1.3.3-1: SystemInformationBlockType1 for Cell 1 (step 1, Table 18.1.1.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.1.3.3-1A: SystemInformationBlockType1-BR-r13 for Cell 1 (step 1 when UE under test is CAT M1, Table 18.1.1.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3A

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1-BR-r13 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.1.3.3-2: Paging (step 1 and step 3a2, Table 18.1.1.3.2-1)

Derivation Path: 36.508 Table 4.6.1-7

Information Element

Value/remark

Comment

Condition

Paging ::= SEQUENCE {

  pagingRecordList

Not present

  systemInfoModification

Not present

  etws-Indication

Not Present

  nonCriticalExtension SEQUENCE {}

lateNonCriticalExtension

Not present

nonCriticalExtension SEQUENCE {

cmas-Indication-r9

true

nonCriticalExtension

Not present

}

}

}

18.1.2 PWS reception in RRC_CONNECTED state / Duplicate detection

18.1.2.1 Test Purpose (TP)

(1)

with { UE in RRC_CONNECTED state }

ensure that {

when { the UE receives a Paging message with cmas-Indication }

then { the UE is able to retrieve all the PWS message segments being broadcast, re assemble the message and alert the user }

(2)

With { UE in RRC_CONNECTED state and pc_PWS_UpperLayer set to ‘TRUE’ }

ensure that {

when  { the UE receives a PWS message which is a duplicate of an already received message }

then { the UE discards the message and does not alert the user }

18.1.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clauses 5.2.2.4, 5.2.2.19, 5.3.2.3; TS 23.041 clause 9.1.3.4.2.

[TS 36.331, clause 5.2.2.4]

The UE shall:

1> if the UE is CMAS capable:

2> upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> discard any previously buffered warningMessageSegment;

3> clear, if any, stored values of messageIdentifier and serialNumber for SystemInformationBlockType12 associated with the discarded warningMessageSegment ;

2> when the UE acquires SystemInformationBlockType1 following CMAS indication, upon entering a cell during RRC_IDLE, following successful handover and upon connection re-establishment:

3> if schedulingInfoList indicates that SystemInformationBlockType12 is present:

4> acquire SystemInformationBlockType12;

NOTE 3: UEs shall start acquiring SystemInformationBlockType12 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

[TS 36.331, clause 5.2.2.19]

Upon receiving SystemInformationBlockType12, the UE shall:

1> if the SystemInformationBlockType12 contains a complete warning message:

2> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

2> continue reception of SystemInformationBlockType12;

1> else:

2> if the received values of messageIdentifier and serialNumber are the same (each value is the same) as a pair for which a warning message is currently being assembled:

3> store the received warningMessageSegment;

3> if all segments of a warning message have been received:

4> assemble the warning message from the received warningMessageSegment;

4> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

4> stop assembling a warning message for this messageIdentifier and serialNumber and delete all stored information held for it;

3> continue reception of SystemInformationBlockType12;

2> else if the received values of messageIdentifier and/or serialNumber are not the same as any of the pairs for which a warning message is currently being assembled:

3> start assembling a warning message for this messageIdentifier and serialNumber pair;

3> store the received warningMessageSegment;

3> continue reception of SystemInformationBlockType12;

The UE should discard warningMessageSegment and the associated values of messageIdentifier and serialNumber for SystemInformationBlockType12 if the complete warning message has not been assembled within a period of 3 hours.

NOTE: The number of warning messages that a UE can re-assemble simultaneously is a function of UE implementation.

[TS 36.331, clause 5.3.2.3]

Upon receiving the Paging message, the UE shall:

1> if the cmas-Indication is included and the UE is CMAS capable:

2> re-acquire SystemInformationBlockType1 immediately, i.e., without waiting until the next system information modification period boundary as specified in 5.2.1.5;

2> if the schedulingInfoList indicates that SystemInformationBlockType12 is present:

3> acquire SystemInformationBlockType12;

[TS 23.041, clause 9.1.3.4.2]

The warning message to be broadcast is delivered via MMEs to multiple eNodeBs. The eNodeB(s) are responsible for scheduling the broadcast of the new message and the repetitions in each cell.

The overall warning message delivery procedure is presented in figure 9.1.3.4.2-1:

Figure 9.1.3.4.2-1: Warning message delivery procedure in E-UTRAN

0. Network registration and security (e.g. mutual authentication) procedures are performed. The UE stores a flag that indicates whether or not it has authenticated the network.

NOTE 1: This step is performed each time a UE is attached to a network (e.g. after each power on).

1. CBE (e.g. Information Source such as PSAP or Regulator) sends emergency information (e.g. "warning type", "warning message", "impacted area", "time period") to the CBC. The CBC shall authenticate this request.

2. Using the "impacted area" information, the CBC identifies which MMEs need to be contacted and determines the information to be place into the Warning Area Information Element. The CBC sends a Write-Replace Warning Request message containing the warning message to be broadcast and the delivery attributes (Message identifier, Serial Number, Tracking Area ID list, Warning Area, OMC ID, CWM Indicator) to MMEs.

The warning messages use the coding scheme for CBS data specified in 3GPP TS 23.038 [3].

The Tracking Area ID list is only used by the MME. The MME uses it for selecting which eNodeBs to forward the Write-Replace Warning Request message to.

The Warning Area shall be a list of Cell IDs and/or a list of TAIs and/or one or more Emergency Area IDs. The Warning Area is only used by the eNodeB. The eNodeB is configured with the TAI(s) and Cell ID(s) it serves and the Emergency Area ID(s) that it belongs to. The eNodeB checks for any match of the contents of the Warning Area with these IDs to identify the cells where to distribute the warning message. The Warning Area is an optional information element. If the Warning Area is absent, it shall be interpreted as "all cells on the eNodeB". The number of cell IDs will be limited by the message size on SBc and S1-MME. An Emergency Area ID is unique within the PLMN.

The message may include an OMC ID. If present, it indicates the OMC to which the Trace record generated in step 8 is destined. Co-location of that OMC with the CBC is an operator option.

CBC shall set the Concurrent Warning Message (CWM) indicator in all Write-Replace Warning Request messages, if the PLMN supports concurrent warning message broadcasts.

NOTE 2: Due to requirements in earlier versions of the specification, it is possible that "digital signature" and "timestamp" information are transmitted within the "warning message".

3. The MME sends a Write-Replace Warning Confirm message that indicates to the CBC that the MME has started to distribute the warning message to eNodeBs.

If this message is not received by the CBC within an appropriate time period, the CBC can attempt to deliver the warning message via another MME in the same pool area.

4. Upon reception of the Write-Replace Confirm messages from the MMEs, the CBC may confirm to the CBE that it has started to distribute the warning message.

5. The MME forwards Write-Replace Warning Message Request to eNodeBs. The MME shall use the Tracking Area ID list to determine the eNodeBs in the delivery area. If the Tracking Area ID list is empty the message is forwarded to all eNodeBs that are connected to the MME.

6. When S1-flex is used the eNodeB may receive same message from multiple MMEs. The eNodeB detects duplicate messages by checking the message identifier and serial number fields within the warning message. If any redundant messages are detected only the first one received will be broadcasted by the cells. The eNodeB shall use the Warning Area information to determine the cell(s) in which the message is to be broadcast. The eNodeBs return a Distribute Warning Message Response to the MME, even if it was a duplicate.

If there is a warning broadcast message already ongoing and the CWM Indicator is included in the Write-Replace Warning Message Request, the eNodeB does not stop existing broadcast message but start broadcasting the new message concurrently. Otherwise the eNodeB shall immediately replace the existing broadcast message with the newer one.

NOTE 3: If concurrent warning messages are not supported, this requires the CBE/CBC to take care that ‘lower’ priority warnings are not sent while a higher priority warning is still being sent.

The eNodeB broadcasts the message frequently according to the attributes set by the CBC that originated the warning message distribution.

7. If the UE has been configured to receive warning messages and the UE has authenticated the core network of the eNodeB it is camped on, then the UE proceeds as follows:

The UE can use "warning type" values, ‘earthquake’, ‘tsunami’ or ‘earthquake and tsunami’, immediately to alert the user. When "warning type" is ‘test’, the UE silently discards the primary notification, but the UE specially designed for testing purposes may proceed with the following procedures.

The UE activates reception of the broadcast messages containing the "warning message".

The UE indicates the contents of the "warning message" to the user

UE shall consider a message duplicated if the combination of "message identifier" and "serial number" matches with those of the previous message that was received from the same PLMN. The UE shall ignore the message detected as a duplicated.

For ETWS, the UE shall perform duplicate message detection independently for primary and secondary notifications.

8. From the Write-Replace Warning Response messages returned by eNodeBs the MME determines the success or failure of the delivery and creates a trace record. Any OMC ID received in step 2 is written to the trace record to permit the O&M system to deliver them to the desired destination.

18.1.2.3 Test description

18.1.2.3.1 Pre-test conditions

System Simulator:

– Cell 1

– System information combination 1 as defined in TS 36.508[18] clause 4.4.3.1 is used in E-UTRA cell

UE:

None.

Preamble:

– The UE is in state Generic RB Established (state 3) according to [18].

18.1.2.3.2 Test procedure sequence

Table 18.1.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS include a CMAS message with new messageIdentifier and serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

2

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

1

P

EXCEPTION: Steps 3a1 to 3a3 describe behaviour that depends on UE configuration; the "lower case letter" identifies a step sequence that take place if the pc_PWS_UpperLayer is set to TRUE.

3a1

The SS waits for 10s.

3a2

The SS include a CMAS message with same messageIdentifier and serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

3a3

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

2

F

NOTE 1: SystemInformationBlockType12 contains 3 segments.

NOTE 2: The data indication and user alerting are the UE implementation issues.

18.1.2.3.3 Specific message contents

Table 18.1.2.3.3-1: SystemInformationBlockType1 for Cell 1 (step 1, Table 18.1.2.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.2.3.3-1A: SystemInformationBlockType1-BR-r13 for Cell 1 (step 1 when UE under test is CAT M1, Table 18.1.2.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3A

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1-BR-r13 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.2.3.3-2: Paging (step 1 and step 3a2, Table 18.1.2.3.2-1)

Derivation Path: 36.508 Table 4.6.1-7

Information Element

Value/remark

Comment

Condition

Paging ::= SEQUENCE {

pagingRecordList

Not present

systemInfoModification

Not present

etws-Indication

Not present

nonCriticalExtension SEQUENCE {

lateNonCriticalExtension

Not present

nonCriticalExtension SEQUENCE {

cmas-Indication-r9

true

nonCriticalExtension

Not present

}

}

}

18.1.3 PWS reception in RRC_CONNECTED State/Power On

18.1.3.1 Test Purpose (TP)

(1)

with { UE being powered down }

ensure that {

when { UE is powered up while CMAS notification is present }

then { UE successfully receives the PWS message and alerts the user accordingly }

}

(2)

with { UE in RRC_CONNECTED state }

ensure that {

when { the network transmits two consecutive different PWS messages and pages the UE, one paging message per a defaultPagingCycle, to indicate the presence of each PWS message }

then { the UE successfully receives each of the messages and alerts the user accordingly }

}

18.1.3.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clauses 5.2.2.2, 5.2.2.4, 5.2.2.19, 5.2.1.3, 5.3.2.3; TS 23.041 clause 9.1.3.4.

[TS 36.331, clause 5.2.2.2]

The UE shall apply the system information acquisition procedure upon selecting (e.g. upon power on) and upon re-selecting a cell, after handover completion, after entering E-UTRA from another RAT, upon return from out of coverage, upon receiving a notification that the system information has changed, upon receiving an indication about the presence of an ETWS notification, upon receiving an indication about the presence of a CMAS notification, upon receiving a request from CDMA2000 upper layers and upon exceeding the maximum validity duration. Unless explicitly stated otherwise in the procedural specification, the system information acquisition procedure overwrites any stored system information, i.e. delta configuration is not applicable for system information and the UE discontinues using a field if it is absent in system information unless explicitly specified otherwise.

[TS 36.331, clause 5.2.2.4]

The UE shall:

1> if the UE is CMAS capable:

2> upon entering a cell during RRC_IDLE, following successful handover or upon connection re-establishment:

3> discard any previously buffered warningMessageSegment;

3> clear, if any, stored values of messageIdentifier and serialNumber for SystemInformationBlockType12 associated with the discarded warningMessageSegment ;

2> when the UE acquires SystemInformationBlockType1 following CMAS indication, upon entering a cell during RRC_IDLE, following successful handover and upon connection re-establishment:

3> if schedulingInfoList indicates that SystemInformationBlockType12 is present:

4> acquire SystemInformationBlockType12;

NOTE 1: UEs shall start acquiring SystemInformationBlockType12 as described above even when systemInfoValueTag in SystemInformationBlockType1 has not changed.

The UE may apply the received SIBs immediately, i.e. the UE does not need to delay using a SIB until all SI messages have been received. The UE may delay applying the received SIBs until completing lower layer procedures associated with a received or a UE originated RRC message, e.g. an ongoing random access procedure.

NOTE 2: While attempting to acquire a particular SIB, if the UE detects from schedulingInfoList that it is no longer present, the UE should stop trying to acquire the particular SIB.

[TS 36.331, clause 5.2.2.19]

Upon receiving SystemInformationBlockType12, the UE shall:

1> if the SystemInformationBlockType12 contains a complete warning message:

2> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

2> continue reception of SystemInformationBlockType12;

1> else:

2> if the received values of messageIdentifier and serialNumber are the same (each value is the same) as a pair for which a warning message is currently being assembled:

3> store the received warningMessageSegment;

3> if all segments of a warning message have been received:

4> assemble the warning message from the received warningMessageSegment;

4> forward the received warning message, messageIdentifier, serialNumber and dataCodingScheme to upper layers;

4> stop assembling a warning message for this messageIdentifier and serialNumber and delete all stored information held for it;

3> continue reception of SystemInformationBlockType12;

2> else if the received values of messageIdentifier and/or serialNumber are not the same as any of the pairs for which a warning message is currently being assembled:

3> start assembling a warning message for this messageIdentifier and serialNumber pair;

3> store the received warningMessageSegment;

3> continue reception of SystemInformationBlockType12;

The UE should discard warningMessageSegment and the associated values of messageIdentifier and serialNumber for SystemInformationBlockType12 if the complete warning message has not been assembled within a period of 3 hours.

NOTE 3: The number of warning messages that a UE can re-assemble simultaneously is a function of UE implementation.

[TS 36.331, clause 5.2.1.3]

E-UTRAN may not update systemInfoValueTag upon change of some system information e.g. ETWS information, CMAS information, regularly changing parameters like CDMA2000 system time (see 6.3). Similarly, E-UTRAN may not include the systemInfoModification within the Paging message upon change of some system information.

The UE verifies that stored system information remains valid by either checking systemInfoValueTag in SystemInformationBlockType1 after the modification period boundary, or attempting to find the systemInfoModification indication at least modificationPeriodCoeff times during the modification period in case no paging is received, in every modification period. If no paging message is received by the UE during a modification period, the UE may assume that no change of system information will occur at the next modification period boundary. If UE in RRC_CONNECTED, during a modification period, receives one paging message, it may deduce from the presence/ absence of systemInfoModification whether a change of system information other than ETWS and CMAS information will occur in the next modification period or not.

ETWS and/or CMAS capable UEs in RRC_CONNECTED shall attempt to read paging at least once every defaultPagingCycle to check whether ETWS and/or CMAS notification is present or not.

[TS 36.331, clause 5.3.2.3]

Upon receiving the Paging message, the UE shall:

1> if the cmas-Indication is included and the UE is CMAS capable:

2> re-acquire SystemInformationBlockType1 immediately, i.e., without waiting until the next system information modification period boundary as specified in 5.2.1.5;

2> if the schedulingInfoList indicates that SystemInformationBlockType12 is present:

3> acquire SystemInformationBlockType12;

[TS 23.041, clause 9.1.3.4]

The warning message to be broadcast is delivered via MMEs to multiple eNodeBs. The eNodeB(s) are responsible for scheduling the broadcast of the new message and the repetitions in each cell.

The overall warning message delivery procedure is presented in figure 9.1.3.4.2-1:

Figure 9.1.3.4.2-1: Warning message delivery procedure in E-UTRAN

0. Network registration and security (e.g. mutual authentication) procedures are performed. The UE stores a flag that indicates whether or not it has authenticated the network.

NOTE 1: This step is performed each time a UE is attached to a network (e.g. after each power on).

1. CBE (e.g. Information Source such as PSAP or Regulator) sends emergency information (e.g. "warning type", "warning message", "impacted area", "time period") to the CBC. The CBC shall authenticate this request.

2. Using the "impacted area" information, the CBC identifies which MMEs need to be contacted and determines the information to be place into the Warning Area Information Element. The CBC sends a Write-Replace Warning Request message containing the warning message to be broadcast and the delivery attributes (Message identifier, Serial Number, Tracking Area ID list, Warning Area, OMC ID, CWM Indicator) to MMEs.

The warning messages use the coding scheme for CBS data specified in 3GPP TS 23.038 [3].

The Tracking Area ID list is only used by the MME. The MME uses it for selecting which eNodeBs to forward the Write-Replace Warning Request message to.

The Warning Area shall be a list of Cell IDs and/or a list of TAIs and/or one or more Emergency Area IDs. The Warning Area is only used by the eNodeB. The eNodeB is configured with the TAI(s) and Cell ID(s) it serves and the Emergency Area ID(s) that it belongs to. The eNodeB checks for any match of the contents of the Warning Area with these IDs to identify the cells where to distribute the warning message. The Warning Area is an optional information element. If the Warning Area is absent, it shall be interpreted as "all cells on the eNodeB". The number of cell IDs will be limited by the message size on SBc and S1-MME. An Emergency Area ID is unique within the PLMN.

The message may include an OMC ID. If present, it indicates the OMC to which the Trace record generated in step 8 is destined. Co-location of that OMC with the CBC is an operator option.

CBC shall set the Concurrent Warning Message (CWM) indicator in all Write-Replace Warning Request messages, if the PLMN supports concurrent warning message broadcasts.

NOTE 2: Due to requirements in earlier versions of the specification, it is possible that "digital signature" and "timestamp" information are transmitted within the "warning message".

3. The MME sends a Write-Replace Warning Confirm message that indicates to the CBC that the MME has started to distribute the warning message to eNodeBs.

If this message is not received by the CBC within an appropriate time period, the CBC can attempt to deliver the warning message via another MME in the same pool area.

4. Upon reception of the Write-Replace Confirm messages from the MMEs, the CBC may confirm to the CBE that it has started to distribute the warning message.

5. The MME forwards Write-Replace Warning Message Request to eNodeBs. The MME shall use the Tracking Area ID list to determine the eNodeBs in the delivery area. If the Tracking Area ID list is empty the message is forwarded to all eNodeBs that are connected to the MME.

6. When S1-flex is used the eNodeB may receive same message from multiple MMEs. The eNodeB detects duplicate messages by checking the message identifier and serial number fields within the warning message. If any redundant messages are detected only the first one received will be broadcasted by the cells. The eNodeB shall use the Warning Area information to determine the cell(s) in which the message is to be broadcast. The eNodeBs return a Distribute Warning Message Response to the MME, even if it was a duplicate.

If there is a warning broadcast message already ongoing and the CWM Indicator is included in the Write-Replace Warning Message Request, the eNodeB does not stop existing broadcast message but start broadcasting the new message concurrently. Otherwise the eNodeB shall immediately replace the existing broadcast message with the newer one.

NOTE 3: If concurrent warning messages are not supported, this requires the CBE/CBC to take care that ‘lower’ priority warnings are not sent while a higher priority warning is still being sent.

The eNodeB broadcasts the message frequently according to the attributes set by the CBC that originated the warning message distribution.

7. If the UE has been configured to receive warning messages , and the UE has authenticated the core network of the eNodeB it is camped on, then the UE proceeds as follows:

The UE can use "warning type" values, ‘earthquake’, ‘tsunami’ or ‘earthquake and tsunami’, immediately to alert the user. When "warning type" is ‘test’, the UE silently discards the primary notification, but the UE specially designed for testing purposes may proceed with the following procedures.

The UE activates reception of the broadcast messages containing the "warning message".

The UE indicates the contents of the "warning message" to the user.

8. From the Write-Replace Warning Response messages returned by eNodeB’s the MME determines the success or failure of the delivery and creates a trace record. Any OMC ID received in step 2 is written to the trace record to permit the O&M system to deliver them to the desired destination.

18.1.3.3 Test description

18.1.3.3.1 Pre-test conditions

System Simulator:

  • Cell 1
  • System information combination 17 as defined in TS 36.508[18] clause 4.4.3.1 is used in E-UTRA cell.

UE:

None.

Preamble:

– The UE is SWITCHED OFF according to [18].

18.1.3.3.2 Test procedure sequence

Table 18.1.3.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS include a CMAS message with new messageIdentifier and serialNumber in SystemInformationBlockType12 (NOTE 1).

2

Power/Switch On the UE.

3-7

The authentication procedure is performed by executing steps 2 to 6 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3

EXCEPTION: the behaviour in Table 18.1.3.3.2-2 runs in parallel with steps 8 to 17 below.

8-17

The attach procedure is performed by executing steps 7 to 16 of the UE registration procedure in TS 36.508 sub clause 4.5.2.3

18

The SS include a CMAS message with different serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

19

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

2

P

20

The SS waits for 10s.

21

The SS include a CMAS message with different serialNumber in SystemInformationBlockType12 and transmit a Paging message including cmas-Indication on Cell 1 (NOTE 1).

<–

Paging

22

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

2

P

23-25

IF MULTI_PDN = TRUE (NOTE 3) THEN steps 10-12 of the generic procedure for network initiated release of additional PDN connectivity specified in TS 36.508 subclause 4.5A.18.3 are performed for the non-IMS PDN

NOTE 1: SystemInformationBlockType12 contains CMAS notification and the PWS message may be segmented in 3 segments.

NOTE 2: The data indication and user alerting are the UE implementation issues.

NOTE 3: MULTI_PDN as defined in TS 36.508 subclause 4.5.2.

Table 18.1.3.3.2-2: Parallel behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE indicate the contents of the "warning message" to the user (NOTE 2)?

1

P

18.1.3.3.3 Specific message contents

Table 18.1.3.3.3-1: SystemInformationBlockType1 for Cell 1 (all steps, Table 18.1.3.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.3.3.3-1A: SystemInformationBlockType1-BR-r13 for Cell 1 (all steps when UE under test is CAT M1, Table 18.1.3.3.2-1)

Derivation Path: 36.508 table 4.4.3.2-3A

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType1-BR-r13 ::= SEQUENCE {

schedulingInformation ::= SEQUENCE (SIZE (1..maxSI-Message)) OF SEQUENCE {}

Combination 17 in TS 36.508 section 4.4.3.1

}

Table 18.1.3.3.3-2: SystemInformationBlockType12 (step 18 and 21, Table 18.1.3.3.2-1)

Derivation Path: 36.331 clause 6.3.1

Information Element

Value/remark

Comment

Condition

SystemInformationBlockType12 ::= SEQUENCE {

messageIdentifier-r9

‘0001 0001 0001 0010’B

CMAS Message Identifier for CMAS Presidential Level Alerts (see TS 23.041])

serialNumber-r9

Value different for each step

warningMessageSegmentType

LastSegment

warningMessageSegmentNumber

0

warningMessageSegment

Octetstring different for each step

Provided as PIXITs

dataCodingScheme

Bitstring (8) ID of the alphabet/coding and the applied language [see TS 23.041]

Provided as PIXITs [see TS 36.523-3 [20] cl. 9]

lateNonCriticalExtension

Not present

}

Table 18.1.3.3.3-3: Paging (step 14 and step 17, Table 18.1.3.3.2-1)

Derivation Path: 36.508 Table 4.6.1-7

Information Element

Value/remark

Comment

Condition

Paging ::= SEQUENCE {

pagingRecordList

Not present

systemInfoModification

Not present

etws-Indication

Not present

nonCriticalExtension ::= SEQUENCE {

Not present

lateNonCriticalExtension

Not present

nonCriticalExtension ::= SEQUENCE {

cmas-Indication-r9

true

nonCriticalExtension

Not present

}

}

}