7 BSS specific fault management functions

12.113GPPFault management of the Base Station System (BSS)TS

While many of the objectives and requirements for Fault Management of the BSS can be regarded as common to several network elements, some may be specific to the BSS. The reason may be due to the BSS being a system supporting radio‑based communications or because the BSS is, itself, a distributed network element.

Thus, in addition to the general requirements for fault management capabilities specified in the previous clauses, there are some BSS specific requirements that shall be supported. These are specified in the following subclauses.

7.1 BSS specific alarm surveillance functions

There is no functionality for alarm surveillance removed from or added to the BSS compared to what is identified in the previous clauses. It is expected that additional BSS specific functions will be addressed in a future GSM Phase 2+ version of the present document.

BSS specific probable cause values in table 4 of Annex A should be used as far as possible for all types of BSS alarm reports. For more details regarding the probable causes, please refer to Annex A.2.

7.2 BSS specific fault localisation functions

Alarm and/or test failure notifications shall contain information localising the failure to at least the BSC, BTS, TRX, Channel, TRAU, or Abis connection resource that has failed.

7.3 BSS specific fault correction functions

The recovery actions related to software faults are covered by software management functions defined in GSM 12.06 [21] and GSM 12.20 [22].

In the case of a BCCH or SDCCH failure, the BSS should attempt to automatically recover the lost broadcast channel(s), even in the event that there are no backup facilities. This automatic recovery should cover the loss of the specific timeslot and, in the case of BCCH, the loss of another timeslot on the same frequency (for frequency hopping systems). The automatic recovery should avoid utilisation of active traffic channels if possible. If it is not possible to avoid loss of these active traffic channels, an attempt may be made to handover these calls. For SDCCH recovery it should not be the case that the result is the loss of all traffic channels. Some sets of traffic channels shall be preserved for such recovery to be useful.

If the BSS takes any automatic recovery action, the BSS shall notify the OS of the changes that were made.

If automatic recovery has been configured and enabled by the OS, it will take place even if communication with the OS has failed when the recovery is required.

Automatic recovery mechanisms may take system optimisation into account. For example, terrestrial circuits may be blocked to account for failed air interfaces.

The BSS shall support a request from the OS to initiate handover for fault management reasons. The request indicates which device (radio channel, carrier) is affected. The request could optionally indicate the preferred handover destination on the indicated device: the same BSS or preferred BSS. Calls in the clearing phase will have the clearing completed. If a preferred handover destination is indicated by the operator, this information is also given to the MSC together with the necessary parameters given by the MS. This maintenance initiated handover is similar to the normal handover procedure, but with the possible difference that a worse destination is accepted, since the call otherwise would be lost. If the maintenance initiated handover is impossible, the OS will be informed.

Under some failure conditions, the BSC may send the RESET message to the MSC in order to clear all calls. All internal system references have to be released (for more information, see GSM 08.08 [17]).

In order to have a resource in a well-defined state, the operator shall be able to shut down and lock the resource before any fault management action is taken upon it. The OS sends a request to the BSS indicating the BSS resources to be shut down. The BSS locks the indicated resource immediately if no traffic is on it. If there is traffic on the specified resource, then the lock is delayed until all traffic is released or until a lock is requested by the OS.

The circuits of the BSS-MSC interface are locked by a request sent from the OS either to the BSS or MSC, which then performs the blocking of circuits described in GSM 08.08.

After successful repair/replacement actions have been taken on a resource, it shall be restored to service. If the service personnel is able to request this locally at the BSS, the BSS shall inform the OS indicating the status of the resource concerned.

7.4 BSS specific testing function

It is expected that BSS specific testing functions will be addressed in a future GSM phase 2+ version of the present document.

7.5 BSS-OS communication failure

A temporary buffering capability shall be provided by the BSS. This decreases the negative effects of communication failures between the NE and OS and peaks of message flow occurring during normal operation of the NE. For these reasons, the following recommendations and requirements apply to the BSS:

– During OS-NE communication link disruption, the BSS should continue to provide the telecommunication services as far as possible. This implies that failures on the BSS shall be recovered autonomously by the BSS itself, without any support from the OS. During this time, alarm reports, state change reports and any other event reports shall be temporarily stored and automatically forwarded to the managing OS later, when the communication link is restored.

– When the communication is restored, the BSS shall provide all the information necessary to the managing OS to regain control of the BSS. This means that the BSS shall provide general information about lost messages.

– It is expected that the management aspects of handling the BSS-OS communications link failure will be addressed in a future GSM phase 2+ version of the present document.

Annex A (normative):
Management Information Model