Content for TS 23.041 Word version: 18.6.0

1… 2 3… 4… 6… 9… 9.1.3.3 9.1.3.4… 9.1.3.5… 9.1.4… 9.2… 9.2.10… 9.2.21… 9.3… 9.3.20… 9.3.40… 9.4… 9.4.2… 9.5 9A… 10… B…

8.1 General MS/UE Functionality 8.2 Duplication Detection Function 8.3 ePWS functionality
...

6 BSC/RNC/MME/AMF Functionality p. 16

The BSC/RNC shall interface to only one CBC. A BSC may interface to several BTSs as indicated by TS 48.052. An RNC may interface to several Node Bs.

The MME may interface to one CBC or multiple CBCs (i.e. the MME is allowed to have SCTP transport associations established with one or multiple CBCs). An MME may interface to several eNodeBs.

The AMF may interface to one CBCF or multiple CBCFs (i.e. the AMF is allowed to have HTTP/2 application layer associations with one or multiple CBCFs). An AMF may interface to several NG-RAN nodes.

The BSC/RNC/MME/AMF shall be responsible for:

BSC	RNC	MME	AMF
Interpretation of commands from the CBC.
Storage of messages from the CBC.		Not applicable
Scheduling of CBS messages on the CBCH.	Scheduling of CBS messages on the CBS related radio resources.	Not applicable	Not applicable
Providing an indication to the CBC when the desired repetition period cannot be achieved.		Not applicable
Providing to the CBC acknowledgement of successful execution/forwarding of commands received from the CBC.
Reporting to the CBC failure when a command received from the CBC is not understood or cannot be executed.
Not applicable.	Not applicable.	Report the Broadcast Completed Area List, the Broadcast Cancelled Area List, PWS Restart Indication and the PWS Failure Indication received from eNB(s) to all CBCs that the MME interfaces with.	Report the Broadcast Completed Area List, the Broadcast Cancelled Area List, PWS Restart Indication and the PWS Failure Indication received from NG-RAN nodes to all CBCFs and PWS-IWFs that the AMF interfaces with.
Routing of CBS messages to the appropriate BTSs.	Routing of CBS messages to the appropriate Node Bs.	Routing of warning messages to the appropriate eNodeBs in the indicated Tracking Area.	Routing of warning messages to the appropriate NG-RAN nodes in the indicated Tracking Area.
Transferring CBS information to each appropriate BTS via a sequence of 4 SMS BROADCAST REQUEST messages or 1 SMS BROADCAST COMMAND message (see TS 48.058), indicating the channel which shall be used.	The Node B has no functionality regarding CBS. This implies that CBS messages do not have to be transmitted explicitly to the Node Bs for further processing.	Not applicable.	Not applicable.
Optionally generating Schedule Messages, indicating the intended schedule of transmissions (see TS 44.012).	Generating Schedule Messages, indicating the intended schedule of transmissions (see TS 25.324). The conversion of GSM related CB DRX Information is a function of the RNC (TS 25.401).	Not applicable.	Not applicable.
Optionally receiving CBCH Load Indication messages and reacting by broadcasting a burst of scheduled CBS messages or by suspending the broadcast for a period indicated by BTS (see TS 48.058).	Not applicable.	Not applicable.	Not applicable.
Broadcasting the ETWS Primary Notification message upon receipt of the WRITE-REPLACE message including the Paging-ETWS-Indicator. The ETWS Primary Notification message is broadcasted according to the Warning Period parameter.	Sending ETWS messages to mobile terminals upon receiving CBS transmission request from CBC including the Paging-ETWS-Indicator. Emergency indication can be included in the paging messages, based on the warning type information conveyed from CBC.	Sending the Write-Replace Warning Request message to the appropriate eNodeBs upon receiving warning message transmission request from CBC.	Sending the Write-Replace Warning Request message to the appropriate NG-RAN nodes upon receiving warning message transmission request from CBCF or PWS-IWFs.

To work efficiently on the interfaces, the BSC/RNC should forward CB related messages to the CBC using cell lists as far as applicable.

7 BTS Functionality p. 18

Only GSM [The BTS is responsible for conveying CBS information received via SMS BROADCAST REQUEST or SMS BROADCAST COMMAND messages over the radio path to the MS.

optionally generating CBCH Load Indication messages, indicating an underflow or overflow situation on the CBCH (see TS 48.058).]

8 MS/UE Functionality p. 18

8.1 General MS/UE Functionality |R11| p. 18

Only GSM [The MS is responsible for recombination of the blocks received via the radio path to reconstitute the CBS message.]

The precise method of display of CBS messages is outside the scope of 3GPP specifications, however it is assumed that an MS/UE will:

MS	UE
Discard sequences transferred via the radio path (see TS 44.012) which do not consist of consecutive blocks.	Discard corrupt CBS messages received on the radio interface.
Have the ability to discard CBS information which is not in a suitable data coding scheme.
Have the ability to discard a CBS message which has a message identifier indicating that it is of subject matter which is not of interest to the MS/UE.
Have the ability to detect duplicate messages as specified in clause 8.2;
Have the ability to transfer a CBS message to an external device, when supported;
Optionally enter CBS DRX mode based upon received Schedule Messages (see TS 44.012);	Enter CBS DRX mode based upon received Schedule Messages (see TS 25.324).
Optionally skip reception of the remaining block(s) of a CBS message which do(es) not contain cell broadcast information (see TS 44.012);	Not applicable.
Optionally read the extended channel.	Not applicable for UMTS, E-UTRAN, and NG-RAN.
Enable the user to activate/deactivate CBS through MMI
Enable the user to maintain a "search list" and receive CBS messages with a Message Identifier in the list while discarding CBS messages with a Message Identifier not in the list.
Discard CBS messages in Message Identifier value range "A000hex-AFFFhex" unless received from HPLMN, EHPLMN, PLMN that is equivalent to HPLMN or EHPLMN, the subscribed SNPN, or an SNPN equivalent to the subscribed SNPN.
Allow the user to enter the Message Identifier via MMI only for the 1000 lowest codes.
Be capable of receiving CBS messages consisting of up to 15 pages.	Be capable of receiving CBS messages consisting of up to 1230 octets in UTRAN or warning messages of up to 9600 octets in E-UTRAN, or NG-RAN.
When emergency indication is included in the received paging and/or CBS/warning message, behave as specified in TS 22.268. If the emergency indication includes the value for "test", mobile terminals which are not used for testing purpose silently discard the paging message and do not receive the corresponding CBS/warning message.

8.2 Duplication Detection Function |R11| p. 19

The MS/UE uses a common duplication detection function for all messages received in GSM, UMTS, E-UTRAN and NG-RAN.

In a PLMN or SNPN, upon reception of a new message, the MS/UE shall perform duplication detection on the messages. Those messages that are received from the same PLMN or SNPN, in the certain time period specified by the duplication detection time are subject to duplication detection. The MS/UE shall not perform duplication detection on messages whose duplication detection time has elapsed. The value of the duplication detection time to be used by the MS/UE shall be derived from the MCC of the current PLMN or SNPN as follows:

If the message was received from a PLMN and the MCC of the PLMN = 440 or = 441 (Japan), duplication detection time shall be 1 hour;
For all other cases, duplication detection time shall be 24 hours.

If the messages are received from the same PLMN or SNPN, then:

the MS/UE shall check whether the Serial Number associated with the Message Identifier of the new message matches the Serial Number of any of those messages with the same Message Identifier that have been received and displayed to the user and that are subject to the duplication detection; and
the MS/UE may check other criteria for detecting duplicates. An example of such a criterion is whether the actual contents of the two messages are the same.

If criterion 1 is fulfilled and any implemented additional checks (as described in criterion 2) are also met, then the MS/UE shall consider the new message as duplicated and shall ignore it. If the Geographical Scope is not PLMN/SNPN wide the validity of the Serial Number may be considered as described in clause 9.4.1.2.1.

If the messages are received from different PLMNs or SNPNs, then (as described in clause 9.4.1.2.1) "the CBS message is only relevant to the PLMN or SNPN in which it is broadcast, so any change of PLMN (including a change to another PLMN which is an ePLMN) or SNPN means the CBS message is "new"". Therefore, the MS/UE is not required to conduct duplication detection on messages received from different PLMNs/SNPNs.

For ETWS, duplicate message detection shall be performed independently for primary and secondary notifications.

8.3 ePWS functionality |R16| p. 19

The ePWS functionality consists of the ePWS language-independent content functionality and the ePWS disaster characteristics functionality as follows:

UEs with user interface which support the ePWS language-independent content functionality and which are capable of displaying text-based warning messages should be capable of displaying the language-independent content mapped to an event or a disaster (e.g. character such as Unicode based pictogram mapping to a disaster) that is part of user information contained in the content of a warning message transparently passed from CBC to UEs.

NOTE 1:
Language-independent contents mapped to disasters need to be formatted to be suitable to be included in a warning message. It could be unicode symbol or symbol based on GSM 7 bit default alphabet. It is desirable that standardised symbols mapped to disasters are applied in all countries that provide warning messages for public safety. This will make it possible for foreigners to intuitively understand the meaning of language-independent contents displayed to their devices.

Editor's note:
[WI: ePWS, CR#202] FFS on what character(s) such as Unicode based pictogram(s) are the language-independent content mapped to an event or a disaster.
UEs with user interface which support the ePWS language-independent content functionality and which are incapable of displaying text-based warning messages should be capable of mapping message identifiers of received warning messages to language-independent contents stored in those UEs. When a warning message is received, such a UE should be capable of displaying of a language-independent content stored in the UE mapped from the message identifier of the received warning message.

NOTE 2:
This ePWS functionality is not applied for such UEs if they are not capable of storing any language-independent content.
UEs with no user interface which support the ePWS disaster characteristics functionality should be capable of identifying the characteristics of a disaster derived from the message identifier of a received warning message in order to take appropriate action.