Contents

Event

Where prior notification of a network event, eg a 'phone-in' has taken place. Prior notification should be in line with operations and maintenance (O&M) Handbook standard and received at least two days prior to the event.

Prior notification would typically include the scale of the event, expected call volumes, anticipated call holding time, number of answering positions, method used to answer the calls (ie manual or automatic), etc.

Where the event is running as planned, with expected additional call volumes and no perceived threat to the integrity of the network.

Objective

To provide control where there is a known risk to either the operator's own network or to the network of another operator caused by the volume of calls to a target number.

Criteria

These would typically be evidenced by higher levels of congestion on a particular routeing to a specific number than would normally be expected at that particular time of day or night. Lower than expected ASR may also be experienced. Control levels should be based on the information provided by the customer hosting the event. This will typically include:

• the method to answer the calls, manual or automatic;
• the number of Operators or answering positions/lines etc; and
• the duration of the call – typically longer where financial pledging is involved.

Controls, generally in the form of ‘manual call gapping’ should be applied to the number string concerned.

Experience shows that typically the control should seek to deliver four times the answer handling capacity of the system used to receive the calls, based on the number of positions (if manual answering) and/or length of predicted call holding time.

For calls terminating in the network of another operator, control actions may need to be considered at gateway points of interconnect and potentially, for larger events, nearer to the source generating the call volumes eg the local exchange.

Controls should be designed to maintain levels of service as near to normal as possible in terms of the ASR received by other network users. The applied control should also seek to ensure that there is no risk to services delivered to the emergency organisations, etc.

Influencing factors

These criteria assume the following:

• prior notification is in line with O&M recommendations;
• the correct level and range of information has been provided in the notification, and it is accurate;
• call volumes remain as anticipated at the preplanning stage eg ASR and congestion in line with expectations;
• controls will seek to meet two objectives, i) protecting operators’ networks and ii) meeting the needs of the organisation running the event; and

• if the estimates of key traffic parameters provided by prior notification are not sufficiently accurate, this event shall be treated as a type two event (see below).

Event

This is the counter scenario to that described in event type one

In this instance, one or a combination of the following may apply:

• the event is not previously notified in line with the O&M standard;
• the applied control algorithm is incorrect or the event is not running to the anticipated level of the pre-planned notification material; and/or
• the situation is unexpected or is developing in an unexpected way.

Objective

The objective is to rapidly gain control of the situation whilst gaining a greater understanding of the event in order to implement more appropriate controls.

The difficulty will be gaining an understanding of what is happening and knowing at what point and at what level controls need to be applied.

Criteria

Events of this type would typically be evidenced by:

• higher levels of congestion; and
• lower ASR to a particular routeing to a specific destination or area code, than would normally be expected at that particular time of day or night.

Network alarm and fault data should also be considered.

Controls in this instance should be applied as follows:

• at a level to allow adequate network control to be gained, typically based on either time or call volume restriction;
• data gathering should continue and controls should be adjusted in line with new data; and
• to prevent the spread of congestion both to other network elements in the owning operator's network or to the network of other operators.

Controls may in the first instance be predominantly route based eg all calls carried by the route in question, with the exception of 999/112, until the target numbers are identified.

Influencing factors

Dependent on the situation presented, controls should be applied on a proportionate but ‘hit hard and rein back’ basis to gain initial control of the situation If applicable, automatic congestion controls would be driven by this type of scenario.

Controls should be applied for the shortest possible time, whilst investigating the root cause.

Exchanges in difficulty or overload may also bring into operation automatic call shedding controls to enable processors to continue to operate and ensure that at least some calls can be processed. In this instance operators’ peripheral equipment and terminals may also be subject to restricted access, which may in turn deny operators the ability to gain control.

Congestion and ASR levels should be monitored and the controls adjusted accordingly.

Close co-operation between operators is essential in these instances to minimise the impact in both networks.

Event

Network incidents, failure and disasters.

Incidents of this type would include:

Objective

The objective is to restrict traffic levels to the target exchange, platform or area of the network to aid a graceful recovery of the switch or platform concerned.

In the case of national or international disaster the objective is to restrict calls with minimal chance of completion whilst maintaining service to the remainder of the network.

Criteria

Events of this nature are evidenced by:

• higher levels of congestion than normal; and
• a lowered ASR.

Restrictive controls should be applied to the target number(s) or number group(s), or on a route basis at all exchanges feeding the target exchange.

Control types will be manual call gapping (destination or route) based typically on time intervals or call volumes and will be dependent on the level of granularity available to the operator applying the controls.

Control levels should be sufficient to offer graceful recovery and to gain control. Performance should continue to be monitored and controls adjusted accordingly.

Influencing factors

• Control levels should be determined through open discussion between the operators involved on a network manager to network manager basis, including operators abroad in the case of international problems. Influencing factors are the normal level of expected ASR;
• the normal levels of expected congestion;
• the impact on customer service; and
• interactions with other network elements and operators.

Event

Network planned works or upgrades, where a known engineering-based action is to take place.

This is a key element within network operations as networks continue to become more complex and interrelated in nature.

Objective

To maintain as near normal level of service as is reasonably possible under the conditions of the outage.

Criteria

Network outages should be planned taking the following factors into consideration:

• time of day that the outage is targeted – ‘peak’ or busy periods should be avoided;
• impact on customers;
• potential risk to life cases;
• the need to give prior notification to other operators that may be affected; and
• the need to give prior notification to customers where appropriate.

Any restriction of access to the network based on a planned network outage should be kept to the minimum necessary consistent with carrying out the required upgrade or maintenance activity.

Influencing factors

In some cases end users may be temporarily denied access to the network due to necessary engineering based outages. Due consideration should be given to the criteria specified above to minimise customer impact.

Restrictive controls may be necessary within an operator’s network to prevent calls routeing to equipment that has been taken out of service.

The need to maintain service at near normal levels wherever practicable.

Event

SS7 protocol error, where the network restriction affects a connected operator.

The following is an example of such an event.

The incorrect implementation of SS7 protocol on an interconnect link can cause calls to ‘black hole’ (fail to route) or cause damage to the receiving network. On receipt of ‘transfer prohibited’ (TFP) from a signalling transfer point (STP) in a pair (maybe due to link outage on the destination network) An originating network should respond by sending further messages to the other STP of the pair. It should then periodically send ‘route set test’ (RST) message to the unavailable STP until such time as the previously unavailable STP sends ‘transfer allowed’ (TFA) indicating that it is ready for service again.

If the originating switch has an incorrect protocol implementation causing it to ignore TFP and to continue to attempt call set-ups, then the calls will black hole. The receiving network also risks message overload and element failure.

Objective

Minimise the potential for damage to the receiving network. This may lead to disconnection of the ‘offending’ link or linkset.

Prevent calls from failing to route and thereby reducing QoS performance and causing customer complaints in the originating network.

Fix the protocol error and restore service.

Criteria

Specific to this example: Where STP working is used on an interconnect link, compliance with BSI PD6639:2001 message transfer part (MTP) protocols is crucial. To qualify for interdiction, the receiving network must be in a position to prove that the protocol failure has occurred. Proof may be obtained, for instance, by use of stand-alone protocol analysers or SS7 probes.

Generically: There are a number of situations where incorrect use of SS7 protocol can cause a network to fail. An operator wishing to disconnect from an ‘offending’ interconnect link must be in a position to provide proof of the protocol violation, both to justify the disconnection and to aid recovery of the situation

Wherever practicable, the first step will be to attempt dialogue between the interconnected parties. If a solution is not readily achievable and the network is at significant risk, immediate temporary disconnection may be considered, even without prior dialogue. Following disconnection, urgent steps should be taken to initiate dialogue.

Influencing factors

Where disconnection of a link or linkset is undertaken as an action, the duration of disconnection will be the minimum necessary to restore or maintain service.

Event

Operator denies service to end users on grounds of network security or integrity.

Objective

To prevent end users adversely affecting network integrity or security, or from causing other related adverse effects for fellow end users.

Criteria

Operator has previously notified end users that behaviour adversely affecting network integrity or security, or causing other related adverse effects for fellow end users may result in disconnection. It is recognised that it may be inadvisable to give specific details of such behaviour in advance.

Operator has objective evidence that the end user is responsible for jeopardising network security or integrity to a material extent, and is likely to continue to do so in the future unless steps to deny service are taken. Evidence may be in the form of, for example:

• switch records;
• call trace details;
• call logs;
• customer complaints, etc.

Operator has attempted to open a dialogue with the end user, and if possible has encouraged the end user to voluntarily cease problematic behaviour.

Operator has attempted to give the end user notice of impending denial of service and has attempted to explain what the end user could do to prevent this happening. Best efforts have been made to give an opportunity to respond.

Operator has considered any mitigating circumstances of which it is aware before taking the decision to deny service.

Operator would take similar steps in similar situations with other end users on a non-discriminatory basis.

Influencing factors

Due to the overall impact on the network and the risks to security or service to others, it may not always be possible or desirable to proceed through the above in a sequential, stepped order. However all of the above steps should at least be considered as part of the overall process before denial of service is implemented.

Event

Network physical security is jeopardised by another operator or a service provider, and operator seeks to restrict physical access to its network by the responsible party/ies as a result.

Objective

To ensure network physical security is not materially adversely affected.

Criteria

Operator has previously informed all relevant operators or service providers of behaviour likely to jeopardise the physical security of the network. It is recognised that it may not always be advisable to give details of all such behaviours.

Operator has objective evidence that network physical security has been jeopardised by the other operator or service provider ('the responsible party/ies') in the past, and is judged likely to be on an on-going basis. There is a pattern of systematic failure to respect the physical security of the network.

Operator has attempted to open dialogue with the responsible party/ies, and has given the party/ies the opportunity to respond.

Operator has given notice of its intention to restrict physical access to the network, and has indicated to the other party/ies what assurances are required to prevent this.

Operator's action in restricting access to the network is proportionate to the risk being caused by the responsible party/ies.

Operator would take similar steps in similar situations with other responsible party/ies on a non-discriminatory basis.

Influencing factors

Due to the overall impact on the network and the risks to security or service to others, it may not always be possible or desirable to proceed through the above in a sequential, stepped order. However all of the above steps should at least be considered as part of the overall process before denial of service is implemented.

Particular consideration should be given to the potential impact and risk where local loop unbundling (LLU) is deployed. Similarly the impact of the access network facilities agreement should be considered.

Issue

Date

Notes

Draft

December 2001

For inclusion in consultation document.

Issue 1.0

October 2002

Incorporates comments received during consultation.