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:
Interpretation of commands from the CBC.
Storage of messages from the CBC.
Scheduling of CBS messages on the CBCH.
Scheduling of CBS messages on the CBS related radio resources.
Providing an indication to the CBC when the desired repetition period cannot be achieved.
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.
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.
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).
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).
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.
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:
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 subclause 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);
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 or PLMN that is equivalent to HPLMN or EHPLMN.
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.
The MS/UE uses a common duplication detection function for all messages received in GSM, UMTS, E-UTRAN and NG-RAN.
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 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 as follows:
If MCC = 440 or MCC = 441 (Japan), duplication detection time shall be 1 hour;
For all other MCCs, duplication detection time shall be 24 hours.
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 subscriber and that are subject to the duplication detection.
Additionally, 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 is 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 wide the validity of the Serial Number may be considered as described in subclause 22.214.171.124.1.
For ETWS, duplicate message detection shall be performed independently for primary and secondary notifications.
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.
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.
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.