1、 JOINT STANDARD J-STD-101 JOINT ATIS/TIA CMAS FEDERAL ALERT GATEWAY TO CMSP GATEWAY INTERFACE SPECIFICATION ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and commu
2、nications industry. More than 300 companies actively formulate standards in ATIS 20 Committees, covering issues including: IPTV, Service Oriented Networks, Home Networking, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support. In addition, numero
3、us Incubators, Focus and Exploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and
4、major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). The Telecommunications Industry Association (TIA) is the leading trade association representing the global informat
5、ion and communications technology (ICT) industries through standards development, government affairs, business opportunities, market intelligence, certification and world-wide environmental regulatory compliance. With support from its 600 members, TIA enhances the business environment for companies
6、involved in telecommunications, broadband, mobile wireless, information technology, networks, cable, satellite, unified communications, emergency communications and the greening of technology. TIA is accredited by ANSI. Notice of Disclaimer June 1999.1Ref 2 IETF RFC 3986, Uniform Resource Identifier
7、 (URI): Generic Syntax; January 2005.1Ref 3 IETF RFC 4301, Security Architecture for the Internet Protocol; December 2005.1Ref 4 Common Alerting Protocol, v. 1.1; OASIS Standard CAP-V1.1; October 2005.2Ref 5 Federal Information Processing Standards Publication 5-2, Codes for the Identification of th
8、e States, the District of Columbia and the Outlying Areas of the United States, and Associated Areas; National Institute of Standards and Technology (NIST); May 1987.3Ref 6 Federal Information Processing Standards Publication 6-4, Counties and Equivalent Entities of the United States, its Possession
9、s and Associated Areas; National Institute of Standards and Technology (NIST); August 1990.3Ref 7 Federal Information Processing Standards Publication 180-3, Secure Hash Standard; National Institute of Standards and Technology (NIST); October, 2008.3Ref 8 IETF RFC 2141, URN Syntax; May 1997.1Ref 9 F
10、CC 08-99, Federal Communications Commission First Report and Order In the Matter of The Commercial Mobile Alert System; April 9, 2008.4Ref 10 IETF RFC4303, IP Encapsulating Security Payload (ESP); December 2005.1 Ref 11 National Weather Service Instruction 10-1712, Operations and Services Disseminat
11、ion Policy NWSPD 10-17 NOAA Weather Radio (NWR) All Hazards Specific Area Message Encoding (SAME); February 12, 2007.5Ref 12 IETF RFC4306, Internet Key Exchange (IKEv2) Protocol; December 2005.1Ref 13 IETF4305, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (E
12、SP) and Authentication Header (AH); December 2005.1Ref 14 IETF RFC3715, IPsec-Network Address Translation (NAT) Compatibility Requirements; March 2004.1Ref 15 IETF RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building; September 2005.1Ref 16 IETF RFC3602, The AES-CBC Cipher
13、 Algorithm and Its Use with IPsec; September 2003.1Ref 17 IETF RFC2404, The Use of HMAC-SHA-1-96 within ESP and AH; November 1998.1Ref 18 IETF RFC 3447, Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1; February 2003.1Ref 19 IETF RFC 5280, Internet X.509 Publi
14、c Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile; May 2008.1Ref 20 WARN Act, Security and Accountability For Every Port Act of 2006 (SAFE Port Act), Pub.L. 109-347, Title VI-Commercial Mobile Service Alerts (WARN Act);61This document is available from the Internet Engin
15、eering Task Force (IETF). 2This document is available from the Organization for the Advancement of Structured Information Standards (OASIS). 3This document is available from the National Institute of Technology and Standards (NIST). 4This document is available from the Federal Communications Commiss
16、ion. 5This document is available from the National Weather Service J-STD-101 3 Ref 21 IETF RFC3275, (Extensible Markup Language) XML-Signature Syntax and Processing; March 2002.1Ref 22 FCC 08-164, Federal Communications Commission Second Report and Order and Further Notice of Proposed Rulemaking In
17、the Matter of The Commercial Mobile Alert System; July 8, 2008.4Ref 23 IETF RFC793, Transmission Control Protocol; September 1981.1Ref 24 FCC 08-184, Federal Communications Commission Third Report and Order and Further Notice of Proposed Rulemaking In the Matter of The Commercial Mobile Alert System
18、; August 7th, 2008.4 Ref 25 FCC 08-166, Federal Communications Commission Order on Reconsideration and Erratum In the Matter of The Commercial Mobile Alert System; July 15, 2008.4Ref 26 J-STD-100, Joint ATIS/TIA CMAS Mobile Device Behavior Specification; January 30, 2009.7Ref 27 IETF RFC1122, Requir
19、ements for Internet Hosts - Communication Layers; October 1989.1 Ref 28 IETF STD 5 (RFC 791), Internet Protocol (IPv4) Specification; September 1981.1Ref 29 IETF STD 5 (RFC 792), Internet Control Message Protocol; September 1981.1Ref 30 IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specificatio
20、n; December 1998.1Ref 31 IETF RFC 2464, Transmission of IPv6 Packets over Ethernet Networks; December 1998.1Ref 32 IETF RFC 4291, IP Version 6 Addressing Architecture, February; 2006.1Ref 33 IETF RFC 4443, Internet Control Message Protocol Version 6 (ICMPv6) for the Internet Protocol Version 6 (IPv6
21、) Specification; March 2006.1Ref 34 IETF RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP; June 1999.1 Ref 35 Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules; May 25, 2001.3 Ref 36 FCC 07-214; Feder
22、al Communications Commission Notice of Proposed Rulemaking in the Matter of the Commercial Mobile Alert System; December 14th, 2007.4Ref 37 IETF RFC 4718, IKEv2 Clarifications and Implementation Guidelines; October 2006.1 Ref 38 W3C Recommendation, XML Signature Syntax and Processing, Second Edition
23、; June 10, 2008.8Ref 39 NIST SP 800-77, Guide to IPsec VPNs; December 2005.3Ref 40 IETF RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPSec; May 2007.13 DEFINITIONS, ACRONYMS, or (b) to such classes of eligible users as to be effectively available to a substantial portion of the
24、public, as specified by regulation by the Federal Communications Commission. 3.1.5 County and County Equivalent. The terms County and County Equivalent are defined by Federal Information Processing Standards (FIPS) 6-4 Ref 6, which provides the names and codes that represent the counties and other e
25、ntities treated as equivalent legal and/or statistical subdivisions of the 50 States, the District of Columbia, and the possessions and freely associated areas of the United States. Counties are considered to be the “first-order subdivisions” of each State and statistically equivalent entity, regard
26、less of their local designations (county, parish, borough, etc.). Thus, the following entities are considered to be equivalent to counties for legal and/or statistical purposes: the parishes of Louisiana; the boroughs and census areas of Alaska; the District of Columbia; the independent cities of Ma
27、ryland, Missouri, Nevada, and Virginia; that part of Yellowstone National Park in Montana; and various entities in the possessions and associated areas. The FIPS codes and FIPS code documentation are available online at . 3.1.6 Participating Commercial Mobile Service Provider. A Participating Commer
28、cial Mobile Service Provider (or a Participating CMS Provider) is a Commercial Mobile Service Provider that has voluntarily elected to transmit Alert Messages. 3.1.7 CMSP Gateway. A CMSP administered system, identified by a unique IP address or Domain Name, interfacing to the Federal Alert Gateway a
29、nd exchanging information per this Standard. 3.1.8 CMSP Gateway Group. A CMSP Gateway Group is the set of CMSP Gateways whose IP addresses or Domain Names are visible to the Federal Alert Gateway across the Reference Point “C” interface. A CMSP Gateway Group will consist of one or two CMSP Gateways
30、3.2 Acronyms Procedures by which CMS Providers may elect to transmit emergency alerts and to withdraw such elections; A rule governing the provision of alert opt-out capabilities for subscribers; and A compliance timeline under which participating CMS Providers must begin CMAS deployment. The rule g
31、overning the provision of alert opt-out capabilities for subscribers specifies: CMS Providers may provide their subscribers with the option to opt out of both, or either, the “Child Abduction Emergency/AMBER Alert” and “Imminent Threat Alert” classes of Alert Messages. CMS Providers shall provide th
32、eir subscribers with a clear indication of what each option means, and provide examples of the types of messages the customer may not receive as a result of opting-out. Requirements and specifications for the subscribers right to opt out as defined in the Third Report and Order may be found in the J
33、oint ATIS/TIA CMAS Mobile Device Behavior Specification Ref 26. J-STD-101 10 4.3 Reference Diagram The following figure is the functional reference model diagram from Section III.B.10 of the FCC First Report and Order for the Commercial Mobile Alert System, FCC 08-99 Ref 9. Additional information on
34、 this functional reference model is contained in the CMSAAC Recommendations of the FCC Notice of Proposed Rulemaking for CMAS Ref 36. Figure 1: CMAS Reference Architecture 4.3.1 Reference Point “C” Reference Point “C” is the interface between the Federal Alert Gateway and the Commercial Mobile Servi
35、ce Provider (CMSP) Gateway. The Reference Point “C” interface: 1. Provides information for the authentication and validation of actions across this reference point. 2. Supports delivery of a new, updated, or cancelled wireless alert message by the Federal Alert Gateway in a format that is suitable f
36、or the mobile devices and the wireless alert delivery technology or technologies implemented by the CMSP. 3. Provides acknowledgement from the CMSP Gateway to the Federal Alert Gateway that the new, updated, or cancelled wireless alert message has been received by the CMSP Gateway. 4. Provides perio
37、dic Reference Point “C” interface testing. The CMSAAC discussed the choice of protocol over the Reference Point “C” interface and concluded that the Common Alerting Protocol (CAP), if used on the Reference Point “B” interface, should be terminated at the Federal Alert Gateway, and a new protocol be
38、defined across the “C” interface. One of the primary considerations for terminating the CAP protocol is that CAP is not sent to the mobile devices. The CAP protocol can contain hundreds if not thousands of characters of text; the technology to broadcast messages within the CMSP infrastructure can on
39、ly support a limited number of characters (which is dependent on the technology) and is well below the number of characters that would be J-STD-101 11 required to support CAP. The Reference Point “C” interface protocol is designed to support the CMAS requirements for the CMSP infrastructure. Additio
40、nal reasoning behind this decision included the following considerations: Every CMSP is to receive the identical 90 character CMAS alert message to send to the mobile devices. This CMAS message is not contained in the CAP protocol over the Reference Point “B” interface, as the CMAS message has to be
41、 generated by the Federal Alert Gateway from parameters in the CAP protocol. The Federal Alert Gateway has to terminate the CAP message to determine if the message severity, urgency and certainty are of the correct values to generate a CMAS message to send to the CMSP Gateway. It was made clear that
42、 alert originators did not want to add technology-dependent fields in the CAP protocol. The CAP protocol does not support all the functions envisioned over the Reference Point “C” interface, such as a “link test” message, or the ability to provide acknowledgments as defined in the Reference Point “C
43、” interface protocol. Given these considerations, the CMSAAC recommendation (which was also adopted by the FCC rules Refs 9, 22, in clause 5.4, Quality of Service Requirements; and in clause 5.5, Security Requirements. The Federal Alert Gateway is a functional entity that may be implemented across m
44、ultiple physical entities. 4.3.3 CMSP Gateway On the CMSP side of the Reference Point “C” interface is the CMSP Gateway. The functions and requirements to be performed by the CMSP Gateway are defined in clause 5.3, CMSP Gateway Requirements, and in clause 5.5, Security Requirements. The CMSP Gateway
45、 is a functional entity that may be implemented across multiple physical entities. 4.3.4 Reference Point C Interface via Digital Television Transmission Towers The FCC Second Report and Order Ref 22 states: “licensees and permittees of noncommercial educational broadcast television stations (NCE) or
46、 public broadcast television stations (to the extent such stations fall within the scope of those terms as defined in section 397(6) of the Communications Act of 1934 (47 U.S.C. 397(6) are required to install on, or as part of, any broadcast television digital signal transmitter, equipment to enable
47、 the distribution of geographically targeted alerts J-STD-101 12 by commercial mobile service providers that have elected to transmit CMAS alerts. Such equipment and technologies must have the capability of allowing licensees and permittees of NCE and public broadcast television stations to receive
48、CMAS alerts from the Alert Gateway over an alternate, secure interface and then to transmit such CMAS alerts to CMS Provider Gateways of participating CMS providers.” The FCC rules do not require a participating CMSP to support receiving alerts via digital television transmitters. All functions of t
49、he NCE/public broadcast television stations in the CMAS architecture are beyond the scope of this Standard. 5 REQUIREMENTS This clause defines the requirements for the interface between the Federal Alert Gateway and the CMSP Gateway. These requirements are grouped as follows: General Reference Point “C” system requirements Federal Alert Gateway requirements CMSP Gateway requirements Quality of Service requirements Security requirements RMT and Periodic Test
