Version 1
July 25, 2016
1 Fields on the Notification Form.. 2
2 Fields on the Initial and Final Report Forms. 8
3 Fields on the Withdraw Report Form.. 17
4 Descriptions of Root Cause, Direct Cause and Contributing Factors. 18
Company – This lists the name of the company filing the outage report. It is the name of the company that the outage inputter used when he/she applied for a Username. The Commission requires providers of wireline, wireless, cable circuit-switched telephony, satellite, paging, and Signaling System 7 (SS7) communications services to submit outage reports regarding disruptions to communication when disruptions meet the reporting thresholds as defined in Part 4 of the Commission’s Rules on any facilities provided for a fee to one or more unaffiliated entities by radio, wire, cable, satellite, and/or lightguide: two-way voice and/or paging service, and/or SS7 communications.
Select the company name from the scroll down menu. Typing a letter in the field will highlight the first company starting with that letter in the list.
Type of Reporting Entity– Pick from the scroll down menu the type of entity your company is relative to the incident being reported. The choices are:
Wireline Carrier
Wireless Carrier
Cable telephony provider
Paging provider
Satellite provider
SS7 network provider
E911 service provider
Facility owner or operator
VoIP provider
A carrier that provides SS7 service, E911 service and is a facility owner should identify itself as a wireline carrier. The designation “SS7 network provider” is intended for companies that only provide SS7 service. Similarly the designation “E911 service provider” is for companies that only provide all or some portion of E911 service. The designation “Facility owner or operator” is for companies that are not carriers but own, operate and lease facilities for use in telecommunications. A carrier which provides both wireline and wireless services should choose the designation which most closely relates to the incident being reported.
Incident Date – Provide the month, day and year at the commencement of the outage. NORS will bring up a calendar with today’s date highlighted; click on the date to be entered. Alternately, the data may be entered by typing the date in the field using the format mm/dd/yyyy.
Incident Time – Provide the local time at the location of the outage (not the reporting location) at commencement of the outage. In most cases both the physical location of the outage and the majority of the effects are in the same time zone. However, some outages have wide-ranging impacts, which may not be at the physical location of the outage, such as a cut undersea cable. In that case, please provide the time at the end of the undersea cable closest to the US or the local time of the physical outage. You should include more detailed explanations in the Initial or Final report.
NORS will bring up a scroll down menu of half-hour times (e.g., 1:30 AM) for entry. For times between 1:00 AM and 9:59 AM, and for times between 1:00 PM and 9:59 PM; the format should be h:mm AM/PM. For other times, the format should be hh:mm AM/PM. The time may be entered via the menu and then edited if desired or the time may be entered directly into the input field.
Time Zone – Pick from the scroll down menu one of the following:
Alaskan
Atlantic
Central
Eastern
Greenwich Mean Time (GMT)
Guam
Hawaii-Aleutian
Mountain
Other
Pacific
Puerto Rico and the Virgin Islands are in the Atlantic time zone.
Date Determined Reportable – Date on which a company determines that an outage has occurred and meets one or more of the reportable thresholds. This field is voluntary.
NORS will bring up a calendar with today’s date highlighted; click on the date to be entered. Alternately, the data may be entered by typing the date in the field using the format mm/dd/yyyy.
NORS will bring up a scroll down menu of half-hour times (e.g., 1:30 AM) for entry. For times between 1:00 AM and 9:59 AM, and for times between 1:00 PM and 9:59 PM; the format should be h:mm AM/PM. For other times, the format should be hh:mm AM/PM. The time may be entered via the menu and then edited if desired or the time may be entered directly into the input field.
Time Determined Reportable – Time at which a company determines that an outage has occurred and meets one or more of the reportable thresholds. Provide the local time of outage determined reportable. This field is voluntary.
NORS will bring up a scroll down menu of half-hour times (e.g., 1:30 AM) for entry. For times between 1:00 AM and 9:59 AM, and for times between 1:00 PM and 9:59 PM; the format should be h:mm AM/PM. For other times, the format should be hh:mm AM/PM. The time may be entered via the menu and then edited if desired or the time may be entered directly into the input field.
Reason Reportable – Provide the threshold that was crossed to determine that this outage was reportable. If more than one threshold was crossed, please choose the primary reason. Pick one of the following from the scroll down menu:
Wireline – 900,000 user-minutes
Wireless – 900,000 user-minutes
Cable telephony – 900,000 user-minutes
MSC
E911
Blocked Calls
1350 DS3s minutes
DS3-Simplex greater than 5 Days
SS7 – MTP Messages
Airport
Other Special Facilities – (Military, nuclear, etc.)
Paging
Satellite
Other
VoIP – E911
VoIP – 900,000 user-minutes
E911 Outage– For non-E911 outages, leave this field blank. For E911 outages, select one of the following from the scroll down menu:
ALI Only Affected – for wireline carriers when location of the caller could not be provided, but the call could be routed to a public-safety answering point (PSAP).
Phase II Only Affected – for wireless outages when Phase II location information could not be provided, but the call could be routed to a PSAP.
Phase I and Phase II Only Affected – for wireless outages when neither Phase I nor Phase II could be provided, but the call could be routed to a PSAP.
More than Location Affected – for wireline and wireless carriers when the call could not be routed to the appropriate PSAP.
Failure in Other Company– Check “Yes” if the failure occurred in another company’s network. Otherwise, check “No”.
Wireline Users Affected – Provide the sum of the number of assigned telephone numbers potentially affected by the outage and the number of administrative numbers potentially affected. If this outage did not affect wireline users, please leave this blank.
“Assigned numbers” are defined as the telephone numbers working in the Public Switched Telephone Network under an agreement such as a contract or tariff at the request of specific end users or customers for their use and include DID numbers. This excludes numbers that are not yet working but have a service order pending.
“Administrative numbers” are defined as the telephone numbers used by communications providers to perform internal administrative or operational functions necessary to maintain reasonable quality of service standards.
Wireless Users Affected – Provide the number of potentially affected wireless users. In determining the number of users potentially affected by a failure of a switch, a concentration ratio of 8 shall be applied. If this outage did not affect wireless users, please leave this blank.
VoIP Users Affected – Provide the number of potentially affected VoIP users. If this outage did not affect VoIP users, please leave this blank.
Paging Users Affected – Provide the number of assigned telephone numbers for those paging networks in which each individual user is assigned a telephone number. If this outage did not affect paging users, please leave this blank.
Cable Telephone Users Affected – Provide the number of assigned telephone numbers. If this outage did not affect cable telephony users, please leave this blank.
Satellite Users Affected – Provide the number of satellite users affected (if known).
DS3s – Provide the number of previously operating DS3s that were affected by the outage and were out of service for 30 or more minutes, regardless of the services carried on the DS3s or the utilization of the DS3s.
DS3s restored to service in fewer than 30 minutes should not be included in the count of the number of DS3s affected. For example, if an outage initially took 576 DS3s out of service, but 384 were restored to service in less than 30 minutes, then only 192 were out of service for 30 minutes or longer; consequently, the number of affected DS3s should be recorded as “192”.
If some failed DS3s were initially knocked out of service but restored in fewer than 30 minutes, the rapid restoration of those DS3s can be noted in the “Description of Incident” field, but they should not be included in the count of the number of DS3s affected.
Count any failed STS3c as 3 DS3s, a failed STS12c as 12 DS3s, etc.
Number of Blocked Calls – Provide the number of blocked calls.
If no calls were blocked, please leave the field blank or enter “0”.
If blocked call information is available in only one direction for interoffice facilities that handle traffic in both directions, the total number of blocked calls shall be estimated as twice the number of blocked calls determined for the available direction.
If real time information is not available, providers may provide data for the same day(s) of the week and the same time(s) of day as the outage, covering a time interval not older than 90 days preceding the onset of the outage in an effort to estimate blocked calls. In this case, the number of blocked calls reported should be 3 times the historic carried load.
If, for whatever reason, real-time and historic carried call load data are unavailable to the provider, even after a detailed investigation, the provider must estimate the carried call load based on data obtained in the time interval between the repair of the outage and the due date for the Final report; this data must cover the same day of the week, the same time of day, and the same duration as the outage. Justification that such data accurately estimates the traffic that would have been carried at the time of the outage must be available on request. In this case, the estimate of the number of blocked calls reported should be 3 times carried load.
The number of blocked calls, if known, should be filled out even if it is not the trigger for an outage being reportable.
Real Time or Historic Blocked Calls – These check boxes appear when the Number of Blocked Calls field is completed. Check whether the number of Blocked Calls came from real-time data or was based on historic carried loads the same day(s) of the week and the same time(s) of day as the outage.
Number of Lost SS7 MTP Messages – In cases of an SS7 outage and where an SS7 provider cannot directly estimate the number of blocked calls, provide the number of real-time lost SS7 Message Transfer Part (MTP) messages or the number of SS7 MTP messages carried on a historical basis. Historic carried SS7 MTP messages should be for the same day(s) of the week and the same time(s) of day as the outage. The historic information should not be older than 90 days preceding the onset of the outage. If the outage does not affect an SS7 network, please leave this field blank.
Real Time or Historic Lost SS7 MTP Messages –Check boxes appear when the Number of Lost SS7 MTP Messages field is completed. Check whether the number of Lost SS7 MTP Messages came from real-time data or was based on historic carried traffic the same day(s) of the week and the same time(s) of day as the outage.
State Affected – Choose the (primary) state affected by the outage from the scroll down menu. All 50 states along with the District of Columbia, Virgin Islands, and Puerto Rico are listed. Outages affecting major parts of more than one state should be listed as “MULTI STATES.” If an outage occurred outside the 50 states, the District of Columbia, Virgin Islands, and Puerto Rico, please choose “OTHER: OUTSIDE 50 STATE.” Entering a letter in the field will highlight the first state starting with that letter in the list.
City Affected – Provide the (primary) city affected. Please do NOT enter the state in this box.
Description of Incident – Provide a narrative that describes the sequence of events leading up to the incident, the steps taken to try and resolve the incident once it had occurred, and the action(s) that finally resolved the incident. This is for the reader to better understand what happened. Include any factors that may have contributed to the duration of the incident, “quick fix” actions that may have resolved or at least mitigated the immediate problem but were not the final, long-term solution, and any other contributing factors. At the Notification stage, it is anticipated that many of the details will not be known.
Primary Contact
Primary Contact information is prepopulated with information from the profile of the person entering the information. This can be changed to another user by clicking the “+” sign next to Select User to Prepopulate their Contact Information and selecting the appropriate user name. Alternatively, the information can be provided manually in each field.
Name – Provide the full name of the primary contact person.
Phone Number – Provide the phone number of the primary contact person in the format NXX-NXX-XXXX or NPANXXXXXX. That is, 201-444-5656 would mean that the area code or NPA is 201, the central office code is 444, and the line number is 5656.
Extension – Provide an extension number if needed.
Email Address – Provide the e-mail address of the primary contact person.
Note that all of the data previously filled in are carried forward when updating a report. All fields can be changed to reflect new information except the Outage Number and Company,
Outage Number – The Outage Number appears in parentheses at the top of the report input form. It is the unique identifying number for the report. This field is automatically filled in from the Notification.
Report Date-Time – Each Outage Number can have four report dates and times:
Notification Creation Date-Time when the Notification report was created
Initial Report Submitted Date-Time when the latest Initial report was submitted
Final Report Submitted Date-Time when the latest Final report was submitted
Withdrawn Date-Time when the outage report was withdraw.
Report date-times are generated automatically by NORS. They do not appear on the report input forms, but they are displayed on a timeline at the top of the record or report for an individual outage.
Report Type – The report type is selected at the bottom of the report input form by clicking the “Submit Initial Report” button or the “Submit Final Report” button. An Initial Report on an outage is due no later than 72 hours after the reporting entity discovered that the outage was reportable, and the Final report on an outage is due no later than 30 days after the reporting entity discovered that the outage was reportable. A Final report is due in 30 days even in the event that the outage has not yet been cleared by that time. The Initial report shall contain all available pertinent information on the outage and shall be submitted in good faith. The Final report shall contain all pertinent information on the outage, including any information that was not contained in or that has changed from the Initial report.
There are two additional Report Types for reports that were re-opened after being finalized or withdrawn. Initial (Final) and Initial (Withdrawn) reports are those reports finalized or withdrawn respectively after being re-opened.
Company – Lists the name of the company filing the outage report, which is automatically filled in from the Notification. Outage reports must be filed with the FCC by any cable communications provider, wireless service provider, satellite operator, SS7 provider, wireline communications provider, paging provider, E911 service provider, or facility owner and on any facilities which it owns, operates or leases that experiences an outage that meets the reporting thresholds as defined in Part 4 of the Commission’s Rules and Regulations.
Type of Reporting Entity – Lists company type. This entry is automatically filled with the information taken from the Notification, but can be changed. The possible entries are:
Wireline Carrier
Wireless Carrier
Cable telephony provider
Paging provider
Satellite provider
SS7 network provider
E911 service provider
Facility owner or operator
VoIP provider
Incident Date – Provide the month, day and year at the commencement of the outage. NORS will bring up a calendar with the latest date provided highlighted; click on the date to be entered. Alternately, the data may be entered by typing the date in the field using the format mm/dd/yyyy.
Incident Time – Provide the local time at the location of the outage (not the reporting location) of commencement of the outage. In most cases, both the physical location of the outage and the majority of the effects are in the same time zone. However, some outages have wide-ranging impacts that may not be at the physical location of the outage, such as a cut undersea cable. In that case, please provide the time at the end of the undersea cable closest to the US or the local time of the physical outage.
NORS will bring up a scroll down menu of half-hour times (e.g., 1:30 AM) for entry. For times between 1:00 AM and 9:59 AM, and for times between 1:00 PM and 9:59 PM; the format should be h:mm AM/PM. For other times, the format should be hh:mm AM/PM. The time may be entered via the menu and then edited if desired or the time may be entered directly into the input field.
Date Determined Reportable – Date on which a company determines that an outage has occurred and meets one or more of the reportable thresholds. This field is voluntary. NORS will bring up a calendar with the latest date provided highlighted; click on the date to be entered. Alternately, the data may be entered by typing the date in the field using the format mm/dd/yyyy.
Time Determined Reportable – Time at which a company determines that an outage has occurred and meets one or more of the reportable thresholds. Provide the local time the outage was determined reportable. This field is voluntary.
NORS will bring up a scroll down menu of half-hour times (e.g., 1:30 AM) for entry. For times between 1:00 AM and 9:59 AM, and for times between 1:00 PM and 9:59 PM; the format should be h:mm AM/PM. For other times, the format should be hh:mm AM/PM. The time may be entered via the menu and then edited if desired or the time may be entered directly into the input field.
Time Zone – Pick one of the following from the scroll down menu:
Alaskan
Atlantic
Central
Eastern
Greenwich Mean Time (GMT)
Guam
Hawaii-Aleutian
Mountain
Other
Pacific
Puerto Rico and the Virgin Islands are in the Atlantic time zone. “Other” should be used for some place like American Samoa.
Reason Reportable – Provide the threshold that was crossed that determined that this outage was reportable. If more than one threshold was crossed, please choose the primary reason. Pick from the scroll down menu one of the following:
Wireline – 900,000 user-minutes
Wireless – 900,000 user-minutes
Cable Telephony – 900,000 user-minutes
MSC
E911
Blocked Calls
1350 DS3s minutes
DS3-Simplex greater than 5 Days
SS7 – MTP Messages
Airport
Other Special Facilities – (Military, nuclear, etc.)
Paging
Satellite
Other
VoIP – E911
VoIP – 900,000 user-minutes
Outage Duration – Provide the total elapsed time (hours and minutes) from the commencement of the outage as provided in the preceding data fields until restoration of fu1l service. For example, if the outage duration is 10 hours and 42 minutes, place 10 in the Outage Duration (Hours) field and 42 in the Outage Duration (Minutes) field.
Full service restoration includes the restoration of all services to all customers impacted by the outage, even if the restoral is over temporary facilities. If the customers’ locations are destroyed such as by a hurricane, flood, tornado, or wildfire, the duration continues until the reporting carrier is capable of again providing service to those locations. If an outage is ongoing at the time the Final report is filed, report the outage duration as the total time between the commencement of the outage and the time the Final report is filed.
Explanation of Outage Duration (for incidents with partial restoration times) – Describe the stages of restoration if different blocks of users were restored at different times. Often times significant blocks of users may be restored to service prior to full restoration of service. If this is the case, provide information on the number of users in each block restored to service and the elapsed time to partial so that an accurate assessment of the outage impact may be made. In addition, it is important to report when some services, e.g., E911, are restored if different than other services. In addition, for outages that last an unusually long time, an explanation should be provided in this field.
Inside Building Indicator – Select “Yes” if the outage occurred inside a building owned, leased, or otherwise controlled by the reporting entity. Otherwise, select “No.” A building is a structure that is temperature controlled.
E911 Outage– For non-E911 outages, leave this field blank. For E911 outages, select one of the following from the scroll down menu:
ALI Only Affected – for wireline carriers, when location of the caller could not be provided but the call could be routed to a PSAP.
Phase II Only Affected – for wireless outages, when Phase II location information could not be provided but the call could be routed to a PSAP.
Phase I and Phase II Only Affected – for wireless outages, when neither Phase I nor Phase II could be provided but the call could be routed to a PSAP.
More than Location Affected – for wireline and wireless carriers, when the call could not be routed to the appropriate PSAP.
Failure in Other Company– Check ”Yes” if the failure occurred in another company’s network. Otherwise, check “No”.
Cable Telephone – Check the box if cable telephony users were affected.
Wireless (not paging) – Check the box if wireless users were affected.
VoIP – Check the box if VoIP users were affected.
E911 – Check the box if E911 service or some aspect of E911 service was affected.
Paging – Check the box if paging users were affected by the outage.
Satellite – Check the box if satellite facilities were affected by the outage.
Signaling (SS7) – Check the box if SS7 service was affected by the outage.
Wireline – Check the box if wireline users were affected by the outage. This includes outages where only intraLATA service or only interLATA service was affected.
Special Facilities – Check the box if some special facility lost telecommunication service (airport, government, etc.).
Other
Other Service Affected – Describe any other services affected if the “Other” box is checked.
Wireline Users Affected – Provide the sum of the number of assigned telephone numbers potentially affected by the outage and the number of administrative numbers potentially affected. If this outage did not affect wireline users, please leave this blank.
“Assigned numbers” are defined as the telephone numbers working in the Public Switched Telephone Network under an agreement such as a contract or tariff at the request of specific end users or customers for their use and include DID numbers. This excludes numbers that are not yet working but have a service order pending.
“Administrative numbers” are defined as the telephone numbers used by communications providers to perform internal administrative or operational functions necessary to maintain reasonable quality of service standards.
Wireless Users Affected – Provide the number of potentially affected wireless users. In determining the number of users potentially affected by a failure of a switch, a concentration ratio of 8 shall be applied. If this outage did not affect wireless users, please leave this blank.
VoIP Users Affected – Provide the number of potentially affected VoIP users. If this outage did not affect VoIP users, please leave this blank.
Paging Users Affected – Provide the number of assigned telephone numbers for those paging networks in which each individual user is assigned a telephone number. If this outage did not affect paging users, please leave this blank.
Cable Telephone Users Affected – Provide the number of assigned telephone numbers. If this outage did not affect cable telephony users, please leave this blank.
Satellite Users Affected – Provide the number of satellite users affected (if known).
DS3s – Provide the number of previously operating DS3s that were affected by the outage and were out of service for 30 or more minutes, regardless of the services carried on the DS3s or the utilization of the DS3s. DS3s restored to service in fewer than 30 minutes should not be recorded in the box for the number of DS3s. For example, if an outage initially took 576 DS3s out of service, but 384 were restored to service in less than 30 minutes, and only 192 were out of service for 30 minutes or longer; the number of affected DS3s should be recorded as “192.” If some failed DS3s were initially knocked out of service but restored in fewer than 30 minutes, the rapid restoration of those DS3s can be noted in the “Description of Incident” field, but they should not be counted in the field for number of DS3s affected.
Count any failed STS3c as 3 DS3s, a failed STS12c as 12 DS3s, etc.
Number of Blocked Calls – Provide the number of blocked calls.
If no calls were blocked, please leave the field blank or put 0 down.
If blocked call information is available in only one direction for interoffice facilities which handle traffic in both directions, the total number of blocked calls shall be estimated as twice the number of blocked calls determined for the available direction.
If real time information is not available, providers may provide data for the same day(s) of the week and the same time(s) of day as the outage, covering a time interval not older than 90 days preceding the onset of the outage in an effort to estimate blocked calls. In this case, the number of blocked calls reported should be 3 times the historic carried load.
If, for whatever reason, real-time and historic carried call load data are unavailable to the provider, even after a detailed investigation, the provider must estimate the carried call load based on data obtained in the time interval between the repair of the outage and the due date for the Final report; this data must cover the same day of the week, the same time of day, and the same duration as the outage. Justification that such data accurately estimates the traffic that would have been carried at the time of the outage must be available on request. In this case, the estimate of the number of blocked calls reported should be 3 times carried load.
The number of blocked calls, if known, must be filled out even if it is not the trigger for an outage being reportable.
Real-Time, Historic Check Box – Check whether the number of Blocked Calls came from real-time data or was based on historic loads carried the same day(s) of the week and the same time(s) of day as the outage.
Number of Lost SS7 MTP Messages – In cases of an SS7 outage and where an SS7 provider cannot directly estimate the number of blocked calls, provide the number of real-time lost SS7 MTP messages or the number SS7 MTP messages carried on a historical basis. Historic carried SS7 MTP messages should be for the same day(s) of the week and the same time(s) of day as the outage. The information should not be older than 90 days preceding the onset of the outage. If the outage does not affect an SS7 network, please leave this field blank.
Mobile Switching Center (MSC) Failed – Check “Yes” if the outage included an MSC failure. Check “No” if the outage did not include an MSC failure. Check “N/A” if your network does not have MSCs.
State Affected – Choose the (primary) state affected by the outage from the scroll down menu. All 50 states along with the District of Columbia, Virgin Islands, and Puerto Rico are listed. Outages affecting major parts of more than one state should be listed as “MULTI STATES.” If an outage occurred outside the 50 states, the District of Columbia, Virgin Islands, and Puerto Rico, please choose “OTHER: OUTSIDE 50 STATE.” Entering a letter in the field will highlight the first state starting with that letter in the list.
City Affected – Provide the (primary) city affected. Please do NOT enter the state in this box.
More Complete Description of Geographic Area Affected – Provide a more complete description of the geographical area of the outage. In particular, for “MULTI STATES” outages, it is important to list the states affected. For outages affecting more than one community, it is important to describe actual communities affected. Include CLLI codes if applicable.
Description of Incident – Provide a narrative that describes the sequence of events leading up to the incident, the steps taken to try and resolve the incident once it had occurred, and the action(s) that finally resolved the incident. This is for the reader to better understand what happened. Include any factors that may have contributed to the duration of the incident, “quick fix” actions that may have resolved or at least mitigated the immediate problem but were not the final, long-term solution, and any other contributing factors. The description should be sufficiently detailed to allow the reader to reach the same conclusions as the writer as to the Direct Cause and Root Cause of the incident.
Description of the Cause(s) of the Outage – Provide a text description of all the causes of the outage. This text should be in the inputter’s own words and should not use the words in the pull-down menus for Direct Cause or Root Cause.
Direct Cause: The direct cause is the immediate event that results in an outage – Scroll down the menu and choose the direct cause that is the most accurate. The direct cause is the event, action, or procedure that triggered the outage. Section 4 provides a complete description of each of the direct causes. For example, a cable cut could be the triggering event or direct cause of an outage whose root cause is lack of diversity.
Root Cause: The root cause is the underlying reason why the outage occurred or why the outage was reportable – Scroll down the menu and choose the root cause that best fits. Root Cause is the key problem which once identified and corrected will prevent the same or a similar problem from recurring. With today’s technology, two or more problems may be closely linked and require detailed investigation. However, in any single incident there should be only one primary cause – the Root Cause. Section 4 provides a complete description of each root cause. For example, a cable cut from improper marking could be the triggering event or direct cause but the real cause (root cause) may be lack of diversity.
Contributing Factors – Scroll down the menu and choose the contributing factors that best fit, if applicable. Contributing factors are problems or causes that are closely linked to the outage. Often if a contributing factor was addressed beforehand, the outage could have been prevented or the effect of the outage would have been reduced or eliminated. The form allows two contributing factors, for which there are complete descriptions in Section 4.
Lack of Diversity– Check “Yes” if lack of diversity contributed to or caused the outage. Otherwise, check “No.” If Best Practices related to diversity are discussed in any of the Best Practice fields, or if the lack of diversity is listed as a root cause or contributing factor to the outage, then this field should be marked “Yes”. In general, determine whether engineering standards for diversity are being followed.
Malicious Activity – Indicate whether you believe that malicious activity might be involved in the outage. Malicious activity could be the product of terrorists.
If yes – please explain Malicious Activity – Provide an explanation of why you believe the activity is malicious or what is suspicious about the activity if “Yes – Cyber” or “Yes – Physical” is selected in the Malicious Activity field.
Name and Type of Failed Equipment – Provide the vendor name and the specific equipment (including software release if applicable) involved in the outage. For example, if a relay in a power plant fails that subsequently causes a switch to go out of service due to lack of power, then report the make and model of the relay, not the power plant or switch.
Specific Part of Network Involved – Provide the part of the network involved with the incident. Examples are local switch, tandem switch, signaling network, central office power plant, digital cross-connect system, outside plant cable, ALI database, etc.
Method(s) Used to Restore Service – Provide a complete, chronological narrative of the methods used to restore service, both “quick fix” and final.
Was Telecommunications Service Priority Involved in Service Restoration? – Check “Yes” if TSP was involved during service restoration. Otherwise, check “No.”
Steps Taken to Prevent Recurrence – Provide the steps already taken and to be taken to prevent reoccurrence. Typically, the corrective actions are identified through a Root Cause Analysis of the incident and the steps for prevention can be at both this location and throughout the network(s) if appropriate. If a time frame for implementation exists, it should be provided. If no further action is required or planned, the service provider should so indicate.
Applicable Best Practices that might have prevented the Outage or reduced its effects – Provide the number(s) of the Best Practices that could have prevented the outage or reduced its effects. The Network Reliability and Interoperability Council (NRIC) and Communications Security, Reliability, and Interoperability Council (CSRIC) have developed a list of Best Practices. They can be accessed via https://www.fcc.gov/nors/outage/bestpractice/BestPractice.cfm. You can find relevant Best Practices by using keywords. Alternatively, Best Practices can also be sourced from the ATIS Best Practices website: http://www.atis.org/bestpractices. The Best Practices can also be accessed by clicking on “Click here” under “To view the NORS Best Practice Page:” in the Help Center section of the NORS Homepage.
Best Practices used to mitigate effects of Outage – Provide the number(s) and also possibly descriptions of the most important Best Practices that were actually used to lessen the effects of the outage. These chosen Best Practices helped shorten the outage, reduced the restoration times, prevented the outage from affecting more customers, and/or reduced the effects on customers (e.g., ensured that E911 was not affected). If none were used, please leave blank. Best Practices can be sourced from the https://www.fcc.gov/nors/outage/bestpractice/BestPractice.cfm or http://www.atis.org/bestpractices. The Best Practices can also be accessed by clicking on “Click here” under “To view the NORS Best Practice Page:” in the Help Center section of the NORS Homepage.
Analysis of Best Practice – Provide an evaluation of the relevance, applicability and usefulness of the current Best Practices for the outage. If a new Best Practice is needed or an existing Best Practice needs to be modified, please indicate.
Remarks – Provide any additional information that you believe is relevant, but did not fit anyplace else on the form.
Primary Contact
Primary Contact information is prepopulated with information from the latest report. This can be changed to another user by clicking the “+” sign next to Select User to Prepopulate their Primary Contact Information and selecting the appropriate user name. Alternatively, the information can be provided manually in each field.
Name – Provide the full name of the primary contact person.
Phone Number – Provide the phone number of the primary contact person in the format NPA-NXX-XXXX or NPANXXXXXX. That is, 201-444-5656 would mean that the area code or NPA is 201, the central office code is 444, and the line number is 5656. Automatically completed from the Notification report.
Extension – Provide an extension number if needed.
U.S. Postal Service Address – Provide the address of the primary contact person using the fields Address Line 1, Address Line 2, and Address Line 3.
Email Address – Provide the e-mail address of the primary contact person. Automatically completed from the Notification report
Secondary Contact
Secondary Contact information is prepopulated with information from the latest report if entered. This can be changed to another user by clicking the “+” sign next to Select User to Prepopulate their Secondary Contact Information and selecting the appropriate user name. Alternatively, the information can be provided manually in each field.
Name – Provide the full name of the secondary contact person.
Phone Number – Provide the phone number of the secondary contact person in the format NPA-NXX-XXXX or NPANXXXXXX. That is, 201-444-5656 would mean that the area code or NPA is 201, the central office code is 444, and the line number is 5656.
Extension – Provide an extension number if needed.
U.S. Postal Service Address – Provide the address of the secondary contact person using the fields Address Line 1, Address Line 2, and Address Line 3.
Email Address – Provide the e-mail address of the secondary contact person.
Company Name – The name of the company filing the outage report, which is automatically provided from the latest report submission
Type of Reporting Entity – Lists company type. This entry is automatically filled with the information taken from the latest report submission
Reason for Withdrawal – State the reason that the report is being withdrawn.
Primary Contact
Primary Contact information is prepopulated with information from the latest report. This can be changed to another user by clicking the “+” sign next to Select User to Prepopulate their Primary Contact Information and selecting the appropriate user name. Alternatively, the information can be provided manually in each field.
Name – Provide the full name of the primary contact person
Phone Number – Provide the phone number of the primary contact person in the format NPA-NXX-XXXX or NPANXXXXXX. That is, 201-444-5656 would mean that the area code or NPA is 201, the central office code is 444, and the line number is 5656.
Extension – Provide an extension number if needed.
Email Address – Provide the email address of the primary contact person.
U.S. Postal Service Address – Provide the address of the primary contact person using the fields Address Line 1, Address Line 2, and Address Line 3.
Secondary Contact
Secondary Contact information is prepopulated with information from the latest report if entered. This can be changed to another user by clicking the “+” sign next to Select User to Prepopulate their Secondary Contact Information and selecting the appropriate user name. Alternatively, the information can be provided manually in each field.
Name – Provide the full name of the secondary contact person.
Phone Number – Provide the phone number of the secondary contact person in the format NPA-NXX-XXXX or NPANXXXXXX. That is, 201-444-5656 would mean that the area code or NPA is 201, the central office code is 444, and the line number is 5656.
Extension – Provide an extension number if needed.
Email Address – Provide the email address of the secondary contact person.
U.S. Postal Service Address – Provide the address of the secondary contact person using the fields Address Line 1, Address Line 2, and Address Line 3.
Cable Damage
Cable Unlocated
This is considered a procedural error. Prior notification of action was provided by the excavator, but the facility owner or locating company failed to establish the presence of a cable, which was then eventually damaged.
Digging Error
Excavator error during digging (contractor provided accurate notification, route was accurately located and marked, and cable was buried at a proper depth with sufficient clearance from other sub-surface structures).
Inaccurate/ Incomplete Cable Locate
This is considered a procedural error. The cable’s presence was determined, but its location was inaccurately and/or partially identified.
Inadequate/No Notification
Excavator failed to provide sufficient or any notification prior to digging, did not accurately describe the location of the digging work to be performed, or did not wait the required time for locate completion.
Other
Shallow Cable
The cable was at too shallow a depth (notification was adequate, locate was accurate, excavator followed standard procedures).
Cable Damage/Malfunction
Aerial/Non-Buried
Aerial/non-buried cable was damaged or ceased to function (e.g., power transformer fire, tension on span, automobile collision, etc.).
Cable Malfunction
Cable ceased to function (e.g., loss of transmission due to aging, connector failure, etc.).
Design – Firmware
Ineffective Fault Recovery or Re-Initialization Action
Failure to reset/restore following general/system restoral/initialization.
Insufficient Software State Indications
Failure to communicate or display out-of-service firmware states; failure to identify, communicate or display indolent or “sleepy” firmware states.
Other
Design – Hardware
Inadequate Grounding Strategy
Insufficient component grounding design; duplex components/systems sharing common power feeds/fusing.
Other
Poor Backplane or Pin Arrangement
Non-standard/confusing pin arrangements or pin numbering schemes; insufficient room or clearance between pins; backplane/pin crowding.
Poor card/frame mechanisms (latches, slots, jacks, etc.)
Mechanical/physical design problems.
Design – Software
Faulty Software Load – Office Data
Inaccurate/mismatched office configuration data used/applied; wrong/defective office load supplied.
Faulty Software Load – Program Data
Bad program code/instructions; logical errors/incompatibility between features/sets; software quality control failure; wrong/defective program load supplied; software vulnerability to virus infection.
Inadequate Defensive Checks
Changes to critical or protected memory were allowed without system challenge; contradictory or ambiguous system input commands were interpreted/responded to without system challenge. Failure of system to recognize or communicate query/warning in response to commands with obvious major system/network impact.
Ineffective Fault Recovery or Re-initialization Action
Simple, single-point failure resulting in total system outage; failure of system diagnostics resulting from the removal of a good unit with restoral of faulty mate; failure to switch/protect the switch to standby/spare/mate component(s).
Other
Diversity Failure
External
Failure to provide or maintain the diversity of links or circuits among external network components which results in a single-point-of-failure configuration.
Internal (Other)
Failure to provide or maintain diversity of equipment internal to a building. This is excluding power equipment and timing equipment.
Links
SS7 communication paths were not physically and logically diverse.
Power
Failure to diversify links, circuits, or equipment among redundant power system components, including AC rectifiers/chargers, battery power plants, DC distribution facilities, etc.
Timing Equipment
Failure to diversify critical equipment across timing supplies (e.g., BITS clocks).
Environment – External (for limited use when applicable root causes caused by a service provider or vendor cannot be identified; it can also be listed as a contributing factor).
Animal Damage
Component destruction associated with damage caused by animals (e.g., squirrel/rodent chewing of cables, insect infestation, bird droppings, bird nests, etc.).
Earthquake
Component destruction or fault associated directly or indirectly with seismic shock. However, if damage was the result of inadequate earthquake bracing, consider the root cause to be Design – Hardware.
Fire
Component destruction or fault associated with a fire occurring/starting outside the service provider plant. This includes brush fires, pole fires, etc.
Ice/Storm
Lightning/Transient Voltage
Component destruction or fault associated with surges and over-voltages caused by (electrical) atmospheric disturbances.
Other
Storm – Water/Ice
Component destruction or fault associated with fog, rain, hail, sleet, snow, or the accumulation of water/ice (flooding, collapse under weight of snow, etc.).
Storm – Wind/Trees
Component destruction or fault associated with wind-borne debris or falling trees/limbs.
Vandalism/Theft
Component loss, destruction, or fault associated with larceny, mischief, or other malicious acts.
Vehicular Accident
Component destruction or fault associated with vehicle (car, truck, train, etc.) collision.
Cable Pressurization Failure
Component destruction or fault associated with cable damage resulting from cable pressurization failure.
Dirt, Dust Contamination
Component loss or fault associated with dirt or dust, typically resulting in component overheating, or loss of connectivity.
Environmental System Failure (heat/humidity)
Component loss or fault associated with extreme temperature, rapid temperature changes, or high humidity due to loss/malfunction of environmental control(s). If the failure was the result of inadequate/lack of response to (alarmed/un-alarmed) environmental failures, or due to incorrect manual control of environmental systems, consider the root cause to be a Procedural failure.
Fire Suppression (water, chemicals) Damage
Component loss or fault associated with corrosion (electrolytic or other) caused by fire suppression activities; this root cause assumes that no substantial failure was directly associated with the smoke/fire that triggered suppression.
Fire, Arcing, Smoke Damage
Component loss or fault associated with damage directly related to central office or equipment fires (open flame or smoldering), corrosive smoke emissions, or electrical arcing (whether or not ignition of surrounding material occurs).
Manhole/Cable Vault Leak
Component destruction or fault associated with water entering manholes, cable vaults, CEVs, etc.
Other
Roof/Air Conditioning Leak
Component destruction or fault associated with water damage (direct or electrolytic) caused by roof or environmental systems leaks into/in central office environment.
Circuit Pack/Card Failure-Other
Circuit pack or card, other than within a processor or memory unit, failed (e.g., component failure, pin edge connector failure, firmware failure, etc.).
Circuit Pack/Card Failure-Processor
Circuit pack or card within the processor failed (e.g. component failure, pin edge connector failure , firmware failure, etc.).
Memory Unit Failure
Other
Passive Devices
Equipment, hardware or devices that contain no electronics (e.g., demarcation points, cross connect panels, splitters, attenuators, etc.).
Processor Community Failure
Self-contained Device Failure
Equipment or hardware that contains electronics, but does not contain replaceable components.
Shelf/Slot Failure
Failure of entire equipment shelf/chassis, connectors, or backplane (e.g., physical damage, corrosion, contamination, wear, etc.).
Software Storage Media Failure
Hardware failure resulting in corruption of office data, program data, routing data,
etc.
Insufficient Data (no additional modifier)
There is not enough information from the failure report (and subsequent investigation, if any) to determine cause(s) of failure.
Cleared While Testing
Service restored before the cause could be determined.
Non-Service Provider Personnel
Failure is caused by non-service provider personnel (e.g., contractors, building maintenance personnel, tenant of telco hotel, etc.).
Outside Owned Network
Failure occurred in another company’s network (e.g., leased transport capacity, contracted signaling service, etc.).
Under Investigation
Root cause analysis pending.
Other/Unknown
The cause of the outage cannot be determined, or the cause does not match any of the classifications above. Excludes cases where outage data were insufficient or missing, or where root cause is still under investigation. When root cause cannot be proven, it is usually still possible to determine the probable cause, which falls under the heading “Unknown.” When classifications provided do not match the cause, the approximate match is preferred to be “Other.”
To Upgrade the System
Outage occurred during scheduled maintenance to upgrade the system or network element. The system or network element upgrade was completed successfully within expected times; however, FCC outage reporting thresholds were met.
To Fix Known Problems
Outage occurred during scheduled maintenance to fix known problems. The known problems were resolved successfully; however, FCC outage reporting thresholds were met.
Failed
Unexpected condition caused the planned maintenance activity to fail and FCC outage reporting thresholds were met.
Went Longer or Was Worse than Expected
The planned maintenance activity was completed successfully; however, due to unexpected conditions, planned maintenance took longer or had a greater impact than expected.
Power Failure (Commercial and/or Back-up) (does not include failures of DC/DC converters or fuses embedded in switches and transmission equipment, which should be reported as a Hardware Failure, unless the problem was caused by the power plant.)
Battery Failure
Batteries did not function as designed.
Breaker Tripped/Blown Fuses
Equipment failure associated with tripped breaker or blown fuse.
Extended Commercial Power Failure
System failure due to commercial power failure that extends beyond the design of back-up capabilities.
Generator Failure
Generator did not function as designed or ran out of fuel.
Inadequate Site-Specific Power Contingency Plans
System failure due to the insufficiency of the emergency operating procedures and contingency plans available and the resulting outage is prolonged because of lack of site-specific information. This includes equipment engineering data, portable engine hook-up hardware/procedures, load shedding plans, etc.
Inadequate Back-up Power Equipment Located on Customer Premise
Customer premise power equipment unable to support communications equipment due to extended loss of commercial or back-up power.
Inadequate/Missing Power Alarm
System failure associated with an un-alarmed (or under-alarmed) power failure, an alarm not provided initially due to inadequate standards, failure to implement standards or an alarm/alarm system failure (broken or modified). Because of the success in avoiding severe, battery-depletion failure where power alarms are effective and effectively responded to, system failures directly associated with power alarms should be classified as such, instead of as Procedural failures.
Insufficient Response to Power Alarm
System failure associated response to power failure: alarm system worked, but support personnel did not respond properly. Consider this a procedural fault.
Lack of Power Redundancy
Failure directly associated with insufficient redundancy of power system components, including AC rectifiers/chargers, battery power plan, DC distribution facilities, etc.
Lack of Routine Maintenance/Testing
System failure resulting from infrequent power system testing, maintenance and/or detailed inspection. Consider this a procedural fault.
Other
Overloaded/Undersized Power Equipment
System failure attributable to insufficient sizing/design of power configuration.
Rectifier Failure
System failure resulting from rectifier malfunction.
Scheduled Activity-Software Upgrade
Scheduled Maintenance-Hardware Replacement
Unidentified Power Surge
Equipment failure associated with unidentified power surge.
Ad hoc Activities, Outside Scope of MOP
Unapproved, unauthorized work, or changes in agreed-to procedures.
Documentation/Procedures Out-of-Date, Unusable, Impractical
Lack of updated documentation/procedures, the correction/update is available but not incorporated locally, or the document is unwieldy. Some examples are: the use of inadequate indexing or cross-referencing, bits and pieces of information being too difficult to integrate, ineffective delivery vehicle, etc.
Documentation/Procedures Unavailable, Incomplete
Documentation or procedures (vendor or service provider) are not published; published, but not distributed; distributed, but not available on-site; or that some documentation is obscure/oblique, too general (lack of practical detail); too detailed/technical for practical use, etc.
Insufficient Staffing/Support
Unexpected conditions depleted available resources; predictable but unavoidable shortage (unreasonable demand); ineffective/inadequate roll-down or centralization arrangement; resource-intensive (new) technology outside scope/reach of existing automatic/remote administration systems, etc.
Insufficient Supervision/Control or Employee Error
Resulting from insufficient leadership, ineffective administration, and/or maintenance strategies (process or communication failures, conflicting priorities, etc.). This sub-category should be used when multiple procedural causes are indicated, and also when the service interruption results purely from an unintentional action by the employee.
Insufficient Training
Training not available from vendor; training not available from service provider; training available but not attended; training attended but provides inadequate or out-of-date information; training adequate but insufficient application followed; training need never identified, etc.
Other
Documentation/Procedures Out-of-Date, Unusable or Impractical
Documentation/procedures are not updated; correction/update available, but not incorporated locally. Documentation/procedures are unwieldy; inadequate indexing or cross-referencing; bits and pieces of information difficult to integrate; ineffective delivery vehicle, etc.
Documentation/Procedures Unavailable/Unclear/Incomplete
Documentation or procedures (vendor or service provider) are not published; published, but not distributed; distributed, but not available on-site, etc. Documentation/procedures are obscure/oblique; too general – insufficient specificity; too detailed/technical for practical use, etc.
Inadequate Routine Maintenance/Memory Back-Up
Failure could have been prevented/minimized by simple maintenance routines. The resulting recovery action was delayed/complicated by old or missing program/office data tapes or disk, etc.
Insufficient Staffing/ Support
Unexpected conditions depleted available resources; predictable but unavoidable shortage (unreasonable demand); ineffective/inadequate roll-down or centralization arrangement; resource-intensive (new) technology outside scope/reach of existing automatic/remote administration systems, etc.
Insufficient Supervision/Control or Employee Error
Resulting from insufficient leadership, ineffective administration, and/or maintenance strategies (process or communication failures, conflicting priorities, etc.). This sub-category should be used when multiple procedural causes are indicated, and also when the service interruption results purely from an unintentional action by the employee.
Insufficient Training
Training not available from vendor; training not available from service provider; training available but not attended; training attended but provides inadequate or out-of-date information; training adequate but insufficient application followed; training need never identified, etc.
Other
Ad hoc Activities, Outside Scope of MOP
Unapproved, unauthorized work or changes in agreed-to procedures. Documentation/Procedures Out-of-Date Unusable or Impractical
Documentation/procedures are not updated; correction/update available, but not incorporated locally. Documentation/procedures are unwieldy; inadequate indexing or cross-referencing; bits and pieces of information difficult to integrate; ineffective delivery vehicle, etc.
Documentation/Procedures Unavailable/Unclear/Incomplete
Documentation or procedures (vendor or service provider) are not published; published, but not distributed; distributed, but not available on-site, etc. Documentation/procedures are obscure/oblique; too general – insufficient specificity; too detailed/technical for practical use, etc.
Insufficient Staffing/ Support
Unexpected conditions depleted available resources; predictable but unavoidable shortage (unreasonable demand); ineffective/inadequate roll-down or centralization arrangement; resource-intensive (new) technology outside scope/reach of existing automatic/remote administration systems, etc.
Insufficient Supervision/Control or Employee Error
Resulting from insufficient leadership, ineffective administration, and/or maintenance strategies (process or communication failures, conflicting priorities, etc.). This sub-category should be used when multiple procedural causes are indicated, and also when the service interruption results purely from an unintentional action by the employee.
Insufficient Training
Training not available from vendor; training not available from service provider; training available but not attended; training attended but provides inadequate or out-of-date information; training adequate but insufficient application followed; training need never identified, etc.
Other
Non-service Affecting
Occurs when there is a failure of one side of a duplexed system such as a SONET ring yet an unprotected simplex service will still provide service for the duration of the outage. Do not use this root cause for the complete failure of a duplexed system or in cases where any of the circuits in the duplexed system are provided under Service Level Agreements (SLAs) which require protection.
Service Affecting
Failure of one side of a duplexed system such as a SONET ring where an unprotected simplex service was provided for a period of time but was not repaired during the usual maintenance window or in cases where any of the circuits in the duplexed system are provided under SLAs that require protection.
Spare Not Available – Sparing processes did not result in an available replacement (e.g., service provider inventory inaccuracies, transportation of spare located at centralized facility, etc.).
Spare On Hand – Failed
Sparing processes provided an available replacement; however, the replacement malfunctioned (e.g., out-of-box failure of spare, incompatible software versions, etc.).
Spare On Hand – Manufacturer Discontinued (MD)
Obtaining spare made difficult or complicated by MD status (e.g., service provider unaware of MD status, scarcity of MD spares, etc.).
Common Channel Signaling Network Overload
SS7 system/network overload associated with (true) high traffic loads congesting signaling network elements or the SS7 link network. If the overload was associated with signaling traffic handling congestion, false or reactivated link congestion, inappropriate or incorrect SS7 network management message(s), protocol errors, etc., then consider the problem to be a Design – Software fault.
Inappropriate/Insufficient Network Management (NM) Control(s)
System/network overload or congestion associated with an ineffective NM system/switch response resulting due to the lack of either effective NM control, that the system/switch response to control was inappropriate, or that its implementation was flawed. If failure was related to inappropriate control strategy or execution by NM organization, consider it a Procedural failure.
Ineffective Engineering/Engineering Tools
System/network overload or congestion directly associated with under-engineering of the system/network due to rapidly changing network demand, or introduction of new network components and/or technologies. If failure was associated with simple under-engineering (absent changing environment), consider it a Procedural failure.
Mass Calling – Focused/Diffuse Network Overload
System/network overload or congestion directly associated with unplanned, external trigger(s) causing a significant, unmanageable traffic load.
Media-Stimulated Calling – Insufficient Notification
System/network overload or congestion directly associated with a media-stimulated calling event where the event sponsor/generator failed to provide adequate advance notice, or provided inaccurate (underestimated) notification.
Glossary of Fields in Network Outage Reporting System – Download [Optimized PDF]
Glossary of Fields in Network Outage Reporting System – Download
Federal Highway Administration GVWR Class Identification Find your vehicle's GVWR by decoding the vin. Class…
China CMIIT ID is required for all wireless devices (cellular phones, modems, routers, etc.) imported…
Singapore Radio Type Approval (IMDA) is a technical specification and compliance process for radio communications…
Waioder Definition is not a meaningful term in any of the languages, and it isn't…
MNPI stands for Material Non-Public Information. Material information is accurate information that is not commonly…