WIXLIB

a. Alert Origination Systems (AOS) at the local, state, and Federal levels generate emergencyalert messages for WEA using a data standard called the Common Alerting Protocol(CAP). These messages are transmitted to the Alert Aggregator via Interface A.b. The Alert Aggregator receives, authenticates, and aggregates emergency alerts from theAOS’s and forwards them to the Federal Alert Gateway.c.The Federal Alert Gateway generates a Commercial Mobile Alert Message (CMAM).d. Based on Commercial Mobile Service Provider (CMSP) profiles maintained in the FederalAlert Gateway, the Federal Alert Gateway delivers the CMAM over Interface C toGateways maintained by the appropriate CMSPs.e.The CMSP Gateway is responsible for formulating the alert in a manner consistent withthe individual CMSP’s available delivery technologies, and handling congestion within theCMSP infrastructure. WEA messages are mapped to an associated set of cell sitetransceivers and transmitted using Cell Broadcast Service (CBS) over the air interfaces.f.Lastly, the alert is received on a customer’s mobile device. The major functions of themobile device are to authenticate interactions with the CMSP infrastructure, monitor forWEA alerts, maintain customer options (such as the subscriber’s opt-out selections), andactivate the associated visual, audio, and mechanical (e.g., vibration) indicators that thesubscriber has chosen as alert options.The WEA Reference Architecture forms the basis of the computer model architectureexplained in Section 4.2-2

Section 3WEA MODELING AND SIMULATIONA public alert and warning system such as WEA must be able to operate continuously evenunder extreme conditions (e.g., massive infrastructure damage, heavy network traffic, cyber attacks).Because it is not possible to generate these conditions for testing in a controlled environment, a WEAcomputer model was developed. This model can simulate the transmission of alert messages fromAOS’s through delivery to a customer’s mobile device and estimate system performance when avariety of conditions are assumed. This includes scenarios with extreme conditions.There are several factors that can delay or prevent sending alerts to a portion of the targetpopulation.3 These factors include the availability of communication paths between WEAcomponents, transmission delays across various interfaces, and message processing and queuingdelays at WEA components. Availability of the WEA service at a given location is also an importantfactor; a handset cannot receive an alert if it is outside of the provider coverage area or WEA servicearea, if some infrastructure damage or system failure prevents WEA service at that location, or if thehandset is simply inside a poor reception area. Radio frequency (RF) interference can causetransmission errors in over-the-air broadcast and prevent reception of the alerts. Finally, handsetstatus (e.g., on/off, active call) will also affect whether a WEA broadcast can be received by ahandset. The WEA computer model was designed with capabilities to simulate the effects of thesefactors and is explained in detail in Section 4.3.1MODELING AND SIMULATION SOFTWAREThe project team evaluated several commercial modeling and simulation (M&S) tools suitablefor WEA model development. Based on evaluation criteria such as available features, ease ofdevelopment, ease of use, customer support, and cost, OPNET Modeler was selected to design anddevelop the WEA computer model. It includes built-in models for networking devices such as routersand switches, network protocols, wired and wireless communication links, servers, and networkclouds. It also allows for the development of custom models and customization of the built-in OPNETmodels. Built-in models and customization features of OPNET Modeler were used to simulate alertorigination, aggregation, Federal and CMSP Gateways, CMSP CBS infrastructure, handsets, andtheir connectivity.OPNET Modeler is a discrete event simulator that simulates the transmission of everynetwork packet from its source to its destination. This allows for highly accurate simulations of realsystems, but requires a lot of processing cycles and memory utilization for large and complexnetworked systems. The tool supports different levels of abstraction at the expense of simulationaccuracy as a workaround for modeling such complex systems.3In this document the term “target population” refers to the intended recipients of a public alert or warning.3-1

3.2MODELING CONSTRAINTSA number of constraints shaped the development of M&S capabilities for WEA. First, the verylarge number of cell towers and cellular devices that can potentially receive an alert makes itimpractical to run simulations at full accuracy. Certain simplifications were used to develop feasiblesimulations, such as more abstract models of cellular transmission and scaling down the number ofcell towers and cellular devices.Limited information was available about the internal architecture and performance attributesof the AOS’s, IPAWS-OPEN, and CMSP network components. For example, IPAWS-OPEN usesAkamai services over Interface A for load balancing and failover switching between two data centers.However, detailed information about these services is sensitive and subsequently restricted.Validation of the WEA computer model requires WEA performance data, such as processingand transmission delays, network capacity, and cell broadcast reception statistics, obtained bysystem testing or field measurements. However, the only performance data available to JHU/APL atthe time of this study were the results of an IPAWS-OPEN performance test.4 The test consisted ofposting 1000 alert messages to IPAWS-OPEN and retrieving messages from the system while thealerts were being posted. This operation took 17 minutes to complete. These data were used toconfigure the alert processing capacity of the IPAWS Aggregator model. Other components of thecomputer model were configured using other sources of information, including relevant systemperformance requirements.Generic models of Universal Mobile Telecommunications System (UMTS) and Long-TermEvolution (LTE) technologies were available in OPNET Modeler and some other commercialsoftware tools, but research uncovered no available commercial or open-source models for CBSdelivery over Global System for Mobile Communications (GSM), UMTS, or LTE. Furthermore,existing equipment models generally supported simulating equipment failure, but very few modelssupported realistic recovery behavior.Lastly, timelines are required for simulation scenarios, but there is no body of agreed-uponemergency alerting timelines for incidents where WEA might be involved.3.3MODELING APPROACHGiven the absence of detailed information about IPAWS-OPEN elements and internal CMSPequipment, the decision was made to use the standard OPNET Modeler network, server, andprotocol models. WEA- and CBS-specific extensions were added to these standard models, and theywere used to represent alert origination, aggregation, Federal and CMSP Gateways, Cell BroadcastEntity (CBE), and Cell Broadcast Controller (CBC) functions, and their connectivity including theAkamai services. These models have been used successfully by many network analysts to representgeneral processing and network routing in situations where specific data are lacking. They areconfigurable by setting equipment attributes so that they can reflect specific knowledge of theseelements, should these data become available in the future. Without specific design data, the WEAcomponents were modeled using a “black-box” approach which does not include detailed modeling of4“FEMA IPAWS-OPEN Active-Active Release 3.02 Quality Assurance Independent Validation and VerificationPerformance Test and Evaluation Report,” Version 1.0, 29 August 2012.3-2

their internal dynamics. This approach captured the external behavior of WEA components in themodel, without internal details.It is not feasible to simulate tens of thousands of cellular devices directly in OPNET Modeleror any other discrete event simulator. For this reason, the numbers of cell towers and cellulardevices have to be scaled down during the simulation runs. In this case the results should beextrapolated to reflect the actual system performance.The simulation of each scenario requires a schedule of WEA alerts relevant for that scenario todrive the model. Furthermore, each scenario may contain various external events that could beexamined as part of the model. Therefore, events such as changes in equipment characteristics (e.g.,being non-operational) or network characteristics (e.g., delays across Interface A or Interface C) arealso inputs to a simulation analysis. To make the simulation configuration easy for the analyst tocreate and easy for the alert community of interest to review, all these events were expressed in asimple text scenario file ingested by the model.The ability to examine the effects of equipment outages is a key element in the assessment ofthe effectiveness of WEA in response to certain types of events. This was accomplished by disablingthe nodes and links that represent the failed equipment in OPNET Modeler. When re-enabled, mostof these equipment models continue from the internal state they were in before being disabled. Theydo not support a more realistic recovery that represents the behavior of equipment in the process ofcoming back online. This was not a significant issue for the simulation scenarios selected in thisstudy because the scenarios had durations that were too short to see any recovery after failure. Forthis reason, the disable feature was used without any need for creating custom code for recovery.After an initial examination of the cellular system models available with OPNET Modeler, itwas decided to customize two of them with the addition of CBS modeling:a. A basic GSM model formerly developed for the Department of Defense (DoD)b. The built-in LTE model in OPNET ModelerThe models of these two cellular systems were different enough that rather than trying to create acommon capability used in both, a distinct, custom CBS model was made for each one.OPNET Modeler also has a built-in UMTS network model. Adding CBS support to this modelwas considered as an option in the early stages of WEA model design, but because cell broadcast overUMTS networks is expected to show similar performance to cell broadcast over GSM networks, itwas decided that the GSM and LTE models would be sufficient for the purpose of this work. If thereis specific need to simulate UMTS cell broadcast, this can be accomplished by using a genericwireless broadcast model based on the built-in Worldwide Interoperability for Microwave Accessmodel with radio characteristics made similar to UMTS. Future addition of CBS support to the builtin UMTS model is also possible, if desired.Table 3-1 lists all WEA functional components and networks that have been modeled.Communication link models and models used for simulation configuration are not listed. The tablealso shows the base model used for each WEA component and added functionality to the base modelto simulate the WEA system. A detailed description of each model is provided in Section 4.3-3

Table 3-1 List of WEA ModelsModeled FunctionalComponentBase ModelModificationAlert OriginationAOSBuilt-in workstation modelAdded AOS functionalityIPAWS-OPENAlert AggregatorBuilt-in server modelAdded alert AggregatorfunctionalityFederal Alert GatewayBuilt-in server modelAdded Federal Alert GatewayfunctionalityNetworksInternetBuilt-in Internet Protocol(IP) cloud modelNoneCMSP Backbone NetworkBuilt-in IP cloud modelNoneCMSP (all)CMSP Gateway and CBEBuilt-in Gateway modelAdded CMSP Gateway and CBEfunctionalityCBCBuilt-in Ethernet servermodelAdded CBC functionalityCMSP (GSM)Base Station Controller (BSC)DoD GSM modelAdded CBS functionalityBase Transceiver Station (BTS)DoD GSM modelAdded CBS functionalityMobile Station (MS)DoD GSM modelAdded CBS functionalityCMSP (LTE)Evolved Packet Core (EPC)Built-in LTE modelNoneEnhanced Node B (eNodeB)Built-in LTE modelAdded CBS functionalityUser Equipment (UE)Built-in LTE modelAdded CBS functionality3-4

Section 4COMPUTER MODEL ARCHITECTUREThe WEA computer model uses the same architecture as the WEA network architecture.Figure 4-1 shows representative models for AOS’s (labeled as Emergency Operations Center (EOC)),Aggregator and Federal Alert Gateway functionality at two data centers, connections to multipleCMSP networks, and the Internet.Figure 4-1 WEA Computer Model ArchitectureAlthough only three EOCs and three provider networks are shown in the figure for simplicity,the model supports much larger numbers of instances for each. The Master Node is responsible forthe scenario configuration. It reads a text file that describes all events in a scenario—such as alertgeneration and equipment failure—and orchestrates these events using the appropriate OPNETModeler methods. Each of the three Provider Network nodes in Figure 4-1 is actually a full CMSPinfrastructure, hidden from view for simplicity. Each of these nodes can be a GSM network model or4-1

an LTE network model, based on the scenario being analyzed. These representative elements areexplained in subsequent sections of this document.4.1SIMULATING NETWORK CONNECTIONSThree kinds of connections were modeled for the WEA simulation studies: simple wiredconnections, IP cloud connections, and cell phone RF connections.4.1.1WIRED CONNECTIONSSimple wired connections are used between the Aggregators and Federal Alert Gateways andfor connections within the CMSP domain between the CMSP core network and cell towers. They areassigned a capacity and a level of background (non-WEA) traffic. These connections can model pointto-point communication between two nodes with various transmission effects, such as delay andpacket loss. They can also model logical interfaces between two functional entities without anytransmission delay or loss.4.1.2IP CLOUD CONNECTIONSThe Internet connectivity between AOS’s, IPAWS data centers, and the CMSP networks wasmodeled using a single IP cloud. This model supports associating capacity, delay, and packet losscharacteristics with multiple interfaces. These characteristics can be adjusted to meet specificscenario conditions. The model also supports simulating network congestion caused by highbackground traffic, and has the ability to disable interfaces into the cloud for a period of time. Theconnectivity between AOS’s and IPAWS data centers through the cloud model (Interface A) usesTransport Layer Security (TLS) and Hypertext Transfer Protocol Secure (HTTPS). The connectivitybetween IPAWS data centers and CMSP networks through the cloud model (Interface C) usesInternet Protocol Security (IPSec). The IP backbone inside the CMSP networks was also modeled bya single IP cloud model, but with attributes different from the Internet cloud model.4.1.3HANDSET RF CONNECTIONSThe over-the-air connection between the CMSP network (i.e., cell towers) and the handsets is acritical element of the WEA simulation capability. OPNET Modeler uses a series of code modulescalled pipeline stages to model the transmission and reception of RF signals. Some are associatedwith the radio transmitter in an OPNET model and some are associated with the radio receiver.Each pipeline stage receives certain inputs from the simulation framework and from the previouspipeline stage, and must set values for the next pipeline stage. There are default radio pipelinestages as well as those customized for specialize

This document describes work undertaken as part of the Wireless Emergency Alerts (WEA) Program, formerly known as Commercial Mobile Alert Service (CMAS), at The Johns Hopkins . dependent on phone call volume because alerts are not received by mobile handsets during active phone calls. High levels of phone call volume can cause a significant .