External alarm supervision for Mx

Site EVOLIUM
 SAS
VELIZY
Originators SFD: External alarm supervision for Mx
G.Daël
Domain : Alcatel BSS

Division : Product Definition
Rubric : BSS
Type : System Feature Description
Distribution Codes Internal : External :
PREDISTRIBUTION :
P.Pelouas
All B8 interfaces
All O&M GSM team
ABSTRACT
This SFD describes the " External alarm box for Mx platform" feature.
Approvals
Name P.Y.COURTINE G.DAEL
App. PM OSY
Name B.CSILLAG
App. OMC
External alarm supervision for Mx

ED 02 Released
EVOLIUM 3BK 10204 0021 DTZZA Y 1/3

0021_02.doc
REVIEW
Ed. 01 Proposal 01 30/12/2004 Review report Id n° 205026 (SYT Chrono).
Ed. 01 Proposal 02 28/01/2005 Review report Id n° 205058 (SYT Chrono).
HISTORY
Ed. 01 Proposal 01 09/12/2004 First proposal
Ed. 01 Proposal 02 07/01/2005 Second proposal taking care of the review report, plus
some clarifications.
Ed. 01 Proposal 03 28/01/2005 Inclusions of clarifications according to review report
Inclusion of implementation in the OMC
Ed. 01 Proposal 04 13/04/2005 Inclusion of following modifications, in line with design:
- external alarm box can also be connected directly on
an IP network
- operator does not need to indicate the type of
supervised unit in the alarm friendly name as OMC
will concatenate the name of the supervised unit in
the alarm name
- no need to reinitialise SNMP manager to take into
account a new profile
- introduction of alarm n°49 ‘Loss of contact with
supervised unit’, alarm n°50 ‘SNMP manager down’.
- Introduction of EXT_ALM_UTIL
- Limitation of the number of alarms processed at each
polling by the IM
- Audits are driven by the IM
Ed. 01 Released 01/07/2005 Inclusion of some hints for customer:

Ports associated to the alarm collect shall be open in
customers fire walls.
Ed. 02 Proposal 01 21/06/2006 As implementation was not in line with specifications, it
was not working. Document (and implementation) need to
be modified.
Reference meeting minutes 15/06/2006:
Eventually the WAGO box does not use traps 50, 150 for
line 1 but traps 25 and 26 for line 1... and so on.
trap 25 means 'close loop' on line 1

trap 26 means 'open loop' on line 1
It is agreed to extend the SU-protocol field into

- WAGO direct (trap 25, close loop is 'alarm BEGIN')
- WAGO reverse (Trap 26, open loop is 'alarm BEGIN')
Modification will only apply for B9 MR4. For previous
release, close loop always means alarm.

ED 02 Released

0021_02.doc
Ed. 02 Released 12/07/2006 As edition 2p1 (except typing mistake in this history section
+ trap -> strap)
INTERNAL REFERENCED DOCUMENTS

Not applicable.
FOR INTERNAL USE ONLY

Not applicable.
END OF DOCUMENT

ED 02 Released

0021_02.doc
SYSTEM FEATURE DESCRIPTION
TABLE OF CONTENTS
REFERENCED DOCUMENTS .............................................................................................................. 2

PREFACE .............................................................................................................................................. 2
1 INTRODUCTION............................................................................................................................... 3
1.1 Scope ............................................................................................................................ 3
1.2 Document Structure .................................................................................................... 3
1.3 Definitions and Pre-requisite...................................................................................... 3
2 FEATURE DESCRIPTION................................................................................................................ 4
2.1 Functional Requirements ........................................................................................... 4
2.2 Compliance to the Marketing Requirements ............................................................ 4
2.3 Working Assumptions................................................................................................. 5
2.4 Dependencies .............................................................................................................. 5
2.5 HW Coverage and impact ........................................................................................... 5
2.6 Rationale....................................................................................................................... 6
3 SYSTEM IMPACTS .......................................................................................................................... 7
3.1 Overall description ...................................................................................................... 7
3.1.1 Modelisation................................................................................................................... 7
3.1.2 External alarm box......................................................................................................... 7
3.1.3 Extension to other supervised units............................................................................... 9
3.1.4 BSC / MFS impact: routing to /from the alarm box ........................................................ 9
3.1.5 OMC features .............................................................................................................. 10
3.1.6 Dimensioning ............................................................................................................... 10
3.1.7 OMC implementation choice ....................................................................................... 11
3.1.8 Operator’s view............................................................................................................ 12
3.2 Specification impacts................................................................................................ 12
3.2.1 Definition of supervised equipment ............................................................................. 13
3.2.2 Definition of a profile .................................................................................................... 13
3.3 Validation.................................................................................................................... 14
3.3.1 Tools ............................................................................................................................ 14
3.3.2 Validation strategy ....................................................................................................... 14
3.4 Engineering rules impacts........................................................................................ 14
3.5 Methods & Processes impacts................................................................................. 14
3.5.1 New documents needed.............................................................................................. 14
3.5.2 Impact on existing GCD documents: ........................................................................... 15
3.5.3 Impact on existing FPD documents............................................................................. 15
3.5.4 Impact on existing SED Engineering documents: ....................................................... 16
3.5.5 Impact on SW necessary for installation team: ........................................................... 16
3.5.6 Impact on OMC alarm dictionary: ................................................................................ 16
4 SUBSYSTEM IMPACTS................................................................................................................. 17
4.1 Hardware definition (OSG)........................................................................................ 17
4.2 BSC ............................................................................................................................. 17
4.3 MFS ............................................................................................................................. 17
4.4 OMC_R ........................................................................................................................ 17
4.4.1 UFM ............................................................................................................................. 17
4.4.2 SNMP manager/ EXT_ALM_UTIL............................................................................... 17
4.4.3 BSSIM/MFSIM ............................................................................................................. 18
4.4.4 RNIM/RNUSM ............................................................................................................. 19
ED 02 Released
EVOLIUM 3BK 10204 0021 DTZZA 1/21

4.4.5 AS ................................................................................................................................ 19
4.4.6 Logging / message retrieval ........................................................................................ 19
4.4.7 Access rights ............................................................................................................... 19
4.4.8 Routing within the OMC............................................................................................... 19
5 PERFORMANCE & SYSTEM DIMENSIONING............................................................................. 19
5.1 Traffic model .............................................................................................................. 19
5.2 Performance............................................................................................................... 20
5.3 Load constraints........................................................................................................ 20
6 OPEN POINTS................................................................................................................................ 20
7 IMPACTS SUMMARY .................................................................................................................... 20
8 GLOSSARY .................................................................................................................................... 21
8.1 Abbreviations ............................................................................................................. 21
REFERENCED DOCUMENTS
Alcatel references
[1] 3BK A55 CBR 143 239 RFD: External alarm box management for Mx platform
PREFACE
This document is the input paper for the feature “External alarm box for Mx platform” inside TD. It will
further on be used as reference for the development of that feature in each subsystem.

ED 02 Released

1 INTRODUCTION
1.1 Scope
The present document aims to be the basis for decision of a proposed change to be made on the BSS
system. Then it provides all necessary information related to functional description, gains, description
of the system impacts and subsystem impacts.
1.2 Document Structure

The section 2 of this document presents the functional requirements, the HW coverage and the
rationale of the feature addressed by the present SFD.
The section 3 identifies the system impacts : it gives the principles and presents the functional split of
the feature between subsystems. Impact on Step2 specifications is also given in this section.
The section 4 contains the description of impacts for each subsystem.
The section 5 addresses the performance and system dimensioning concerns.
The section 6 identifies and describes the open points.
The section 7 is a sum up of the system impacts.
The section 8 contains the glossary of the present document.
1.3 Definitions and Pre-requisite

X733 alarm: standardised alarm definition as managed by the AS module of the OMC and as sent on
Q3 interface towards NMC.

ED 02 Released

2 FEATURE DESCRIPTION
On BSC G2, there is a possibility to
- connect physically alarm lines on the BSC
- to customise these alarms on the OMC.
On AS 800, DS10 MFS, there is also the possibility to support external alarms but there is no possible
customisation.
In the design of the Mx HW platform, this facility has not been retained.
Instead, it has been proposed to support the connection of alarm lines using a separate alarm box,
connected on the Mx switch or connected directly on an Ethernet network.
This SFD describes the replacing solution.
The solution is based on the usage of an alarm box, to be bought from an external manufacturer.
The solution applies for both BSC and MFS.
2.1 Functional Requirements
Alarms detected by the alarm box shall be presented to operator in the AS, forwarded to the NMC,
and shall contribute to some alarm status /alarm synthesis in RNUSM view in order that the possibility
to supervise the network from RNUSM be not degraded by the introduction of this external box.
As for the other alarms, the view on the OMC shall correspond to the ‘on the field’ situation, and
therefore all usual means of resynchronisation shall be implemented.
2.2 Compliance to the Marketing Requirements
Feature Item Compliance Comments

RFD 143 239 External alarm box management Y See Nota
for Mx platform
Nota: The external alarms will not be anymore visible on BSC local terminal nor on MFS IMT but there
is the possibility to connect a PC on the external alarm box to get the current status.
If the external box is connected directly on the Mx machine, it is connected on the switch. In case of
failure of the switch, the access is lost. There is no redundancy.
In the future, this implementation could be used to supervise also other equipments. For example, the
operator could supervise a router, a satellite equipment, a transmission equipment as long as it
forwards SNMP traps and it is able to provide current status. See § 3 1 3.
As for the external box, association to a BSC or an MFS shall be foreseen.

ED 02 Released

2.3 Working Assumptions
/
2.4 Dependencies
/
2.5 HW Coverage and impact
Network element:
In the following tables, indicate :
Xsw if feature supported by the NE with software impact,
Xhw if feature supported by the NE with hardware impact
Xsw+hw if feature supported by the NE with software and hardware impact.
X: The feature is supported on the NE without hardware or software impacts.
-: The feature is not supported by the NE or the NE is not concerned by the feature
Impact
BTS Generation: BTS MK2 with DRFU -
BTS G2 with DRFU -
A9100 (Evolium standard) -
A910 (micro Evolium (M4M, -
M5M)
BSC Generation: BSC G2 -

Mx BSC X
MFS: MFS with AS 800

MFS with DS10, shared disks
MFS with DS10, no shared
disks
Mx MFS X
Transmission: Alcatel TSC -
Transcoder: TRAU G2 with DT16 -

TRAU G2 with MT120
TRAU G2.5 (with MT120) -
MSC: MSC -

ED 02 Released

SGSN: SGSN -
Data IWF: Data IWF -
HLR: HLR -
O&M: OMC-R Xsw

POLO -
OEF -
LASER -
MPM/NPA -
RNO -
MSTS: MSTS -
2.6 Rationale
Without this feature, for Mx platform, there is no possibility to supervise external lines. This
supervision requires an extra equipment: the alarm box.

ED 02 Released

3 SYSTEM IMPACTS
3.1 Overall description
3.1.1 Modelisation
It is proposed to achieve same behaviour as for ‘classical’ BSC and MFS, ie to map those alarms on
BSC, or MFS.
3.1.2 External alarm box
3.1.2.1 Physical description

The company name is WAGO, already contacted in the scope of the RNC during RFQ for Orange
Sweden.
Its proposal consists in a set of small modules. Each module supports 4 external lines. They can be
assembled in series.
RJ45 connector is available for IP connection. There is also a serial itf to connect a PC.
Size for 4 such modules (= 16 inputs) is a cube of 100mm per 100mm per 100 mm.
Type of connectors for the external lines: insertion of the copper line.
Price of the configuration with 8 +4 inputs is around 800 Euros (before any price negotiation taking
into account the possible volumes…..)
Location of this external box

If it is connected directly on the Mx switch, if possible, this box shall be mounted near the DDF. Max
distance between the box and the Mx: 100m.
NB in case of replacement of BSC, MFS, alarms lines were arriving in the cabinet, and therefore, it will
be more natural to place the alarm box near the Mx cabinet.
If it is connected on Ethernet, there is no constraint.
Software fee to be clarified

SW used for configuring the alarm box ("Wago I/O Pro CAA") is licensed once for Alcatel.
Current SW fee is around 400 Euros (to be confirmed).
Support of the box + power supply:

Power supply voltage is 24 V DC .WAGO catalogue contains AC/DC 220/24 V. They also offer box
and mural support.
Electrical interface:
Definition of alarm ON/ OFF is configurable.

ED 02 Released

3.1.2.2 Functional aspects
This module supports SNMP but not DHCP.
IP address given to this module must be FIXED. No dynamic addressing supported.
It does not support tagged VLAN.
The SNMP agent is able:
- to report spontaneously change in the input status lines, through traps.
- to handle OMC synchronisation requests.
Internal supervision of the box? Can it detect its own failures? How will they be reported to OMC?
3.1.2.3 Connection
This alarm box can be directly connected on the Mx switch or can be anywhere in the IP network. The
localisation is linked to the IP address of the box:
- either the customer allocates to the external box, the pre-defined address in the BSC/MFS
sub-net. Then the box needs to be connected on the BSC/MFS switch, its address is fixed by
spec (port n°6), and this may have impact on the IP sub-net mask
- or, he allocates a public address and then the box can be connected anywhere, on the
BSC/MFS switch or not. Operator has to do more configuration on his routers.
For the BSC, it can be on any connector of the switch board except the one reserved for the BSC
terminal. It must be connected on switch n°1 (not on switch n°2).
For the MFS: it can be on any connector of the switch board.
For the rack shared configuration, it is preferable to connect it to the BSC SSW, in case the routing is
done via ML-PPP. This way, the connection to the box is independent of state of the MFS part.
NB this alarm box will be only used for pure external alarms. There is no device within the BSC/MFS
which needs to be connected to this alarm box; for example, there is no detector on the rack door
because the BSC/MFS Mx is always an Indoor product.
3.1.2.4 Configuration
For WAGO alarm box, software is available for configuring the MIB through a WEB interface. Usually
all the configuration shall be done locally. However WAGO states that part of the configuration can be
done remotely.
What has to be configured is as follows:
- OMC IP address
- Port used by the OMC SNMP manager
- Own IP address
Because WAGO uses traps till 24 for internal purposes, the used traps start from 25.
The mapping between trap and physical line status is as follows:
- traps for ‘close loop’: 25 assigned to line 1, then 27 assigned to line 2…
- traps for ‘open loop’: 26, assigned to line 1, then 28…
This mapping is hard coded in the WAGO firmware designed for Alcatel.
It must be stressed that for a certain alarm box, the alarm condition ‘ON’ will be attached only to one
physical status (open OR close). No possible mix for a certain box as the conversion will be done in
OMC, depending on the protocol parameter.
3.1.2.5 Supported protocols

For external alarm box of WAGO, the protocol is as follows:

ED 02 Released

- on the fly reporting of external lines status change: for each line, and for each change, there is
an associated trap number (so, 2 traps per external line, one for ‘close loop’, one for ‘open
loop’). All the traps are associated to same OID,
- on receipt of a special trap (which one?), the external box performs a resynchronisation by
sending back the list of traps corresponding to current status of external lines (one trap per
line, either the one corresponding to the ‘close loop’, or the one corresponding to the ‘ open
loop’, depending on the status of the line).
Transfers are done using UDP and therefore there is no end to end acknowledge.
3.1.3 Extension to other supervised units

The implementation shall be such that it will be easy, later on, to supervise other types of units.
This future proof aspect appears:
- In the architecture of the solution: future support of other units shall only impact UFM and
SNMP. There should be no impact on BSSIM, MFSIM,
- in the UFM aspects: usage of a general wording ‘supervised unit’, instead of using ‘external
alarm box’,
- In SNMP agent: implementation shall take care that the protocol (and so the MIB) can be
different for each type of supervised unit.
3.1.4 BSC / MFS impact: routing to /from the alarm box

BSC/MFS must route traffic from / to the alarm box.
Indeed it is foreseen to have only one single connection. If the switch on which the external box is
connected fails, the supervision of external alarms is lost: there is no redundancy. The product
accepts this limitation.
No extra configuration is needed. The idea is that the external alarm box gets an IP address that is
externally visible and routed using standard IP mechanisms. Basically, this is exactly the same case
as the OMCP board external IP address used by the OMC-R.
It is clarified that there will be no firewall feature (provided by the platform) against the external alarm
box. As it is not felt that the alarm box could impact the BSC/MFS behaviour, the product accepts this
point.
It has also to be mentioned that these alarms will not be visible from the BSC/MFS terminal. But a
local operator can access to the current status of the input lines, by connecting a PC on the serial link
of the external box. This access can be done on top of the IP connection.
NB: on the G2 BSC, there was neither full redundancy. Hereafter is information provided by S.Bellens:
For BSC, from a HW point of view, the alarm detection is redundant and done by both Sys-BCLA's.
They are both connected to the same scan points for the external alarms (10 available).
The same goes for the driving points (6 drive points).[not supported by the SW]
Sys-BCLA(1) is connected to DTC(1) (Netw Addr 20'h) and Sys-BCLA(2) is connected to DTC(9)
(Netw Addr 30'h).
This connection is used for monitoring and controlling the BCLA's.
However, from a SW point of view, it is only DTC(1) that will handle the alarm interface. DTC(9) is not
enabled for this.
So that means, when DTC(1) is dead ... no external alarms.

ED 02 Released

3.1.5 OMC features
OMC features can be classified as follows:
- preparation of the connection:
o declaration of the external alarm box: association with an IP address, with a certain
protocol, with a certain BSC or MFS, with a device type
o description of the mapping profiles (extension of today mechanism)
- on the fly handling of alarms:
o collect of the SNMP traps sent by the alarm box
o conversion of trap into alarm (traps for line 1 will lead to alarm 1, traps for line 2 will
lead to alarm 2….) taking care of the protocol (if the protocol is ‘WAGO-direct’, ‘close
loop’ is interpreted as alarm ‘ON’. If the protocol is ‘WAGO reverse’, ‘open loop’ is
interpreted as alarm ‘ON’),
o mapping of these alarms according to the selected profile and association to the
BSC/MFS.
o maintenance of the alarm status / alarm synthesis of the BSC/MFS
o forwarding to the Q3 itf
- special resynchronisation action:
o with the external alarm box
o between components implied by the ‘on the fly handling’.
- Supervision of the connection with the supervised device: to be done via periodic
resynchronisation between SNMP and the supervised device. In case the connection is not
possible, OMC will raise an alarm N°49 on the NE.
- Support of removal of a supervised unit. On such a removal, all active alarms associated to
this unit shall be autonomously cleared by the OMC.
- Support for evolution of profiles (change of the identity of the profile attached to a certain
supervised unit, change in the content of a profile)
- Automatic deletion of attached supervised units in case of deletion of BSC/MSC (eg in the
context of a Move operation towards another OMC)
- Supervision of the SNMP manager. In case it does not run anymore, OMC will raise an alarm
N°50 on the NE.
All configuration data entered by the operator shall be persisted across later OMC SW migration.
The feature is not optional.
3.1.6 Dimensioning
The relationship supervised unit <-> MFS, BSC is as follows:
Supervised unit N ---------------- 1 BSC or MFS.
There is no limitation on the number of units that can be associated to a certain BSC/MFS, but, if they
are too many, it will not be convenient for the operator to identify the real source and location of an
alarm.
Maximum number of external alarm boxes: 100
For WAGO box, granularity of each alarm module: 4 external alarm lines
Maximum number of alarms modules in an alarm box: 12
=> maximum 48 external lines per alarm box.

ED 02 Released

3.1.7 OMC implementation choice
AS
OMC RNIM/RNUSM
NMC
SNMP manager/ BSSIM/MFSIM

EXT_ALM_UTIL
UFM
Plain lines: alarms/ resynchronisation

Dotted lines: configuration data
External alarm
box
- The new component will be based on SNMP trap D, from SUN.

EXT_ALM_UTIL, using SNMP manager is in charge of
- the collection of the traps,
- the mapping to internal alarm format, taking care of the protocol: WAGO direct, WAGO
reverse,
- the supervision of the connection.
These alarms are stored in files dedicated per target BSC / MFS. The alarm number is equal to the
line number.
BSSIM/MFSIM get these alarms by polling of the files, convert them in X733 standardised alarm and
manages the list of alarms in force. MFSIM and BSSIM compute the BSC/MFS alarm status taking
these alarms into account. In turn, this status contributes to the BSC/MFS alarm synthesis. They also
compute the alarm acknowledgment status.
They send alarms towards AS (normal behaviour), towards Q3 (normal behaviour), the alarm status to
RNIM (normal behaviour).
RNUSM performs usual display of these status.
UFM supports the connection / disconnection of a certain alarm box to a certain BSC/MFS.

ED 02 Released

UFM supports the definition/modification of the mapping profiles. It updates accordingly the translation
file (specific problem <-> alarm userFriendlyName used by AS.)
New mapping profiles are taken into account after reinitialising AS. (ASCUR_USM has to be stopped /
started).
Audits, driven by the IM, allow keeping synchronised all these elements.
3.1.8 Operator’s view

Declaration/ Display of supervised units will be available in a new window of UFM.
Modification/ display of mapping profiles will be available in a new window of UFM.
On the OMC, the operator will see the alarms in a similar way as they were reported by classical BSC
(as long as he has initialized the profiles properly.).
OMC will insert the SU_friendlyname at the beginning of the alarm friendly name.
If he has not customised the profile, he will get the default value proposed by Alcatel, ie something like
external alarm n°x.
For the MFS, the situation will be improved, as the customisation was not supported for classical MFS.
Those alarms will not be visible from BSC or MFS IMT local terminal.
There will be the possibility to get the lines status (open / close loop) by connection to the alarm box
itself: a PC with the WAGO SW, connected to the serial link of the external box, can offer the status of
all the lines.
3.2 Specification impacts

Impacted specifications are:
- Network supervision (with definition of the interface between OMC and the external device).
- OMC/MFS HW domain,
- BSS O&M parameters data base
- OMC alarm dictionary
- HW catalog
- NMPP

ED 02 Released

3.2.1 Definition of supervised equipment
This supervised equipment is characterised by following parameters:
Parameter name Definition Sub- Category1 / Range / default

system OMC-R value
access2
SU_friendlyname Friendlyname of the supervised OMC CAE
unit – 30 ASCII characters /changeable
SU_IP_address IP address of the supervised OMC CAE
unit – 4 integers /changeable
OMC
Alarm profile Profile to be used to convert CAE / Profile N°1
(=device type) received trap into an X733 alarm Changeable
OMC
SU_protocol Protocol to be used with this CAE / ‘WAGO direct’
supervised unit: ‘WAGO direct’, Changeable
‘WAGO reverse’, xxx
OMC
Associated NE Name of the BSC or MFS. BSC CAE /
can be only Mx BSC. MFS can Changeable
be any.
The port on alarm box side is fixed. New protocols (eg CISCO, .. ) will be supported later-on only.
3.2.2 Definition of a profile

The profile allows converting an internal alarm into X733 alarm. It comprises a system part (the default
values), which cannot be modified by the customer and a customised part, which overwrites, when
present, the system definition (same strategy as for the existing alarm customisation in BSSIM).
It is independent of the protocol used with the supervised unit as it convert an alarm rank into a X733
alarm.
It is just an extension of the existing tables used to convert external alarm from BSC or BTS.
Five new types are defined (called profiles or device types). Same fields as available to day:
- for a certain alarm rank
- a specific problem. A specific problem range has to be defined eg from 3 000 000. (tbc)The
specific problem is fixed and linked to the rank of the row and to the profile id, eg specific
problem associated to the 4th alarm of the second profile is 3 000 054. This specific problem is
invisible for the operator.
- An alarm name. Comma (‘,’) sign shall not be used. UFM shall forbid it,
- An additional text,
- A severity: critical, major, minor, warning, [+ not reported],
- A probable cause among the standardized ones.
It will be possible to inhibit the production of alarm linked to a certain alarm. For this, the operator shall
force to ‘not_reported’ the severity field. (same way as for the BTS external alarms).
Operator can modify any field of the profile.
For the special alarms 49 (Loss of contact with SU), and 50 (SNMP manager down), the operator can
only modify the severity and the additional text.
1
The valid options are: Site (CAE), Network (CDE), System (CST), Not Used (NU)
2
The valid options are: changeable, set by create, displayed, OMC local display, Virtual – changeable,
Virtual – displayed.

ED 02 Released

The default profiles provided with the OMC are all identical and will contain:
- Specific problem as computed above
- Alarm name: ‘external alarm n°x’
- Additional text: ‘customisation is required’
- Severity: warning
- Probable cause : Undeterminate
3.3 Validation
This section describes the system validation aspects of the feature(s).
3.3.1 Tools
Such an external box is useful for the tests.
3.3.2 Validation strategy

Provide here a test strategy for the new features.
3.4 Engineering rules impacts

These rules shall clarify:
- where these boxes can be connected
- the advised IP addresses and the consequences on the configuration of the routers
- the OMC port to be used.
In case the box is part of the Mx sub-net, the port is fixed to: 6.
One shall take care to add the necessary ports to the list given to customer, documenting which ports
are used by the BSS.
3.5 Methods & Processes impacts
3.5.1 New documents needed

External alarm box installation and commissioning
This method should cover the following cases:
- EAB installation during NE commissioning; NE is not in the network
- EAB installation for a running NE
The following steps will be described:
- mechanical installation of the box
- run and connect the power cables
- run and connect the ethernet cables between NE and EAB
- powering up
- connect with the terminal and configure the EAB
- connect external alarms
- For a running NE: declare the EAB at OMC side
ED 02 Released

- Final checks: perform some checks in order to see that the alarms are correct reported
Maybe this document can contain a short Annex describing how to use the terminal for EAB, and
some useful commands for this terminal (Annex: EAB terminal User Guide).
The method shall clarify
- the protocol (direct or reverse) to be associated to the alarm box in order that it fits the
physical alarm detection (compatibility with BSC, MFS convention for external alarms)
- the way to cable the unused alarms (straps on the entries if the ‘open loop’ corresponds to
alarm situation, nothing in the other case).
Configuration of the alarm box
• The alarm box will need to know its own IP address
• The alarm box will need to know the IP address + port of the OMC-R to send spontaneous
events, and to have the proper security settings (ID/password/keys) so that remote operator
can possibly access it and set parameters.
The method shall also mention the profile customisation at OMC site.
3.5.2 Impact on existing GCD documents:

BSS Configuration Handbook
A new task must be defined for declaring the IP address of EAB to the OMC-R.
MX-MFS Maintenance Handbook

This document will cover the following situations when the EAB is connected to an MX-MFS:
- Box replacement, module replacement (in case of a faulty equipment)
- reconfiguration (extension/reduction)
MX-BSC Maintenance Handbook

This document will cover the following situations when the EAB is connected to an MX-BSC:
- Box replacement, module replacement (in case of a faulty equipment)
- reconfiguration (extension/reduction)
3.5.3 Impact on existing FPD documents

Move BSS Without MFS Same MSC Different OMC-R42/1
Move BSS Different MFS Same MSC Different OMC-R 42/2
Move BSS Different MFS Different MSC Different OMC-R 94/2
In these 3 methods the EAB attached to the MX-BSC must be declared on target OMC.
Move MX-MFS with Associated BSS, Different OMC-R 42/4

In this method the EABs attached to MX-MFS or to MX-BSCs must be declared on target OMC. (I
understand that the removal from source OMC-R is automatic)
Add a new BSS on OMC-R 115/1

ED 02 Released

The scope of this method is to perform the logical declaration of a BSS to OMC-R (the mechanical
installation is covered in another document).
This method will cover the MX-BSC declaration on an OMC-R, so if the EAB is attached to this MX-
BSC it will be necessary to declare it at OMC-R.
Replace G2 BSC by Mx BSC

This method should cover the moving of the external alarms from BSC G2 (if exists) to the EAB
connected to the new MX-BSC.
Operator shall take care that one profile is customised in the same way as the customisation was
done
UFM has also to support the modification of the profiles, in a similar manner to the customisation of for
the G2 BSC alarms.
Add Logically a BSS to an MFS 96/2

This method will cover the MX-MFS declaration at OMC-R, so if the EAB is attached to this MX-MFS it
will be necessary to declare it at OMC-R
Add a BSS by Moving Existing Links Through an MFS 96/1

This method will cover the MX-MFS declaration at OMC-R, so if the EAB is attached to this MX-MFS it
will be necessary to declare it at OMC-R
MX dismantling manual
Describe how to perform EAB mechanical dismantling.
MX installation manual (mechanical installation)

At least to precise, as an option, that the EAB can be installed during NE installation with reference to
EAB installation manual
3.5.4 Impact on existing SED Engineering documents:

None
3.5.5 Impact on SW necessary for installation team:

Special SW distributed by WAGO shall be made available on the terminal of the installation guys.
With this SW, they will be able to configure the external alarms box. This SW will be also useful to
check the current status of alarms.
3.5.6 Impact on OMC alarm dictionary:

On the alarm ‘Loss of contact with supervised unit’, it should be explained that this alarm can be the
consequence of a BSC/MFS switch failure.
On the alarm ‘SNMP manager down’, it should be explained how to re-launch it.
It is proposed not to document anymore the external alarms themselves in the alarm dictionary as the
description gives no added value.

ED 02 Released

4 SUBSYSTEM IMPACTS
4.1 Hardware definition (OSG)

Definition on the location of the box.
Definition of the possible cables for the connection on the switch (several lengths shall be foreseen)
Identification of the exact product.
Integration in HW catalog.
4.2 BSC
No impact .
4.3 MFS
No impact .
4.4 OMC_R
A new component must be introduced: SNMP manager and its associated EXT_ALM_UTIL.
Existing components must be modified. New profiles tables must be part of the OMC delivery.
4.4.1 UFM
This component is extended to support:
- creation/ display / modification /deletion of supervised external device.
For the connection with BSC or MFS, the OMC has to present all existing BSC (except G2 BSC) (or
MFS) sorted per alphabetic order of friendly name.
The creation of such device is taken into account immediately by the SNMP manager, which acquires
the current list of active alarms. Modification of such a supervised device is taken into account
immediately at SNMP manager/ EXT_ALM_UTIL level.
The handling of translation tables for BSS external alarms is extended. Five new device types are
supported. As for BSS, the system default values cannot be touched. For severity, probable cause,
OMC must present the list of possible values.
UFM prepares then the files, which will be used respectively by EXT_ALM_UTIL and by the AS
(extension of already existing file).
In case the operator associates a new profile or modifies a profile, UFM informs SNMP manager to
generate an end of alarm for all active alarms touched by this profile evolution and to perform an audit
with the supervised units.
In case of deletion of a supervised device, UFM informs SNMP/ EXT_ALM_UTIL manager to generate
an end of alarm for all active alarms.
In case of deletion of BSC/MFS(eg in the context of a MOVE BSC to another OMC), UFM performs
automatically the deletion of the associated supervised units.
4.4.2 SNMP manager/ EXT_ALM_UTIL

This is a new component. It has to use the definition of supervised unit to map received traps into
internal alarms.
These alarms are time stamped by SNMP manager with OMC local time.

ED 02 Released

For each alarm transition, SNMP manager adds a new line in a dedicated file corresponding
to the attached BSC/MFS. This line will comprise the internal alarm and the device type.
SNMP manager also maintains the list of active alarms. This list does not need to be persisted across
OMC migration or crash of SNMP manager.
On following events:
- SNMP manager start-up
- Declaration of a new supervised device
- BSSIM/MFSIM request (when they start-up)
SNMP manager performs an alarm resynchronisation with the supervised units (one or all) and
manages the resynchronisation with BSSIM/MFSIM (one or all).
Event Synchro with supervised unit Synchro with BSSIM/MFSIM
SNMP manager start-up Yes, with all Yes, with all
New supervised device Yes, with the new device
BSSIM/MFSIM request Yes, with the concerned IM
On modification of profile or association of a new profile, SNMP manager generates end of alarm and
performs an audit with the supervised units. This action is done on an unit basis (ie if operator
modifies only the definition of the 3rd alarm, the ‘end alarm’ is produced for all the active alarms of the
supervised units using this profile.)
On deletion of a supervised unit, SNMP manager has to clear all active alarms.
Periodic resynchronisation with the supervised unit.

The periodic audit is driven by the IM every 20’.
During this polling, the SNMP manager/EXT_ALM_UTIL will receive current status of all the lines: one
trap per line. It will compare them with its current view and will forward current status as alarms
BEGIN/END towards the right BSSIM/MFSIM. Detecting differences as this point in time will not be
notified as such to the operator. The IM will forward it to AS only if it differs from its own current status.
In case of confirmed no answer, production of an alarm: ‘SU_friendlyname/Loss of contact with
supervised unit. This alarm will contribute to the status of the NE. A confirmed ‘no answer’ is defined
by no answer on 2 successive requests spaced at least by 30”. Through the periodic audit, the OMC
shall detect the re-establishment of the dialogue with the unit and shall then clear the previous alarm.
In case of receipt of unknown event:
- event from an unknown IP address
- undefined trap
these events will be traced for possible debugging.
4.4.3 BSSIM/MFSIM
They have to retrieve the alarms by reading the interface file (polling every N seconds, N being
configurable; default value: 30”).
To avoid possible overload of the IM, maximum EXT_ALM_POLL_MAX alarms are treated at each
polling periods. EXT_ALM_POLL_MAX is configurable; default value: 50.
Then BSSIM/MFSIM convert this internal info into X733 alarm.
Alarms shall not be subject to short end filtering.

ED 02 Released

Alarms are integrated to the list of BSC/MFS active alarms. They contribute to the BSC/MFS alarm
status .
BSSIM and MFSIM shall request audit to SNMP manager when they start-up.
BSSIM and MFSIM shall request audit to SNMP manager when the operator requests an alarm audit.
There is no requirement in case of audit triggered by the system itself.
For BSSIM, in case it receives a BSC reset alarm, it clears all alarms relative to the SBL of the BSC
but not relative to the NE itself: so in this situation, there is no impact on the active external alarms
associated to the NE.
4.4.4 RNIM/RNUSM
There is no impact. External alarms are mapped and displayed as any other BSC/MFS alarm.
4.4.5 AS
There is no impact. The list of specific problem will be a little bit longer but this is not significant.
4.4.6 Logging / message retrieval

Following events will be logged for further message retrieval:
- definition / modification / removal of a supervised unit.
Following events will be stored as traces for debug purpose:
- all received traps, even the undefined,
- all messages coming from unknown IP address and addressed to the SNMP manager.
4.4.7 Access rights

For the new commands, the access rights will be:
- for display command: no restriction
- for modify commands, new FAD: Supervised_Unit FAD.
4.4.8 Routing within the OMC

To allow routing of IP packets to the SNMP manager, it is necessary to allocate it a dedicated port
(value 50777).
! Take care that there is already another SNMP manager for the supervision of the MFS and an
SNMP agent for the OMC supervision. They shall get different port numbers.
NB port on the WAGO box to get full current status is: 162.
5 PERFORMANCE & SYSTEM DIMENSIONING
5.1 Traffic model

The flow of external alarms shall be the same as the one already supported to-day.
Dimensioning:
ED 02 Released

- 100 possible external boxes
5.2 Performance
Due to the polling done by BSSIM/MFSIM to get the alarm, there will be an average delay of 10-15”
between the transition of the alarm on the field and the display in AS (except in case there are more
than EXT_ALM_POLL_MAX alarms in the file. But as the default value of this configurable parameter
is 50, the probability to be above this number is very low).
5.3 Load constraints

{To be filled in by impacted DCs}.
6 OPEN POINTS
WAGO open points

1. Debouncing period applied by the external alarm box
2. § 3 1 2 1 Software fees
3. §3 1 2 4 possibility of not used external lines
4. trap id to be used for resynchronisation.
5. Internal supervision of the box? Can it detect its own failures? How will they be reported to
OMC?
7 IMPACTS SUMMARY
Equipments:
BTS BSC MFS TC OMC-R LASER MPM/ RNO OEF Polo

NPA
X
Interfaces:
Telecom
Radio Abis A Ater BTS-TC MFS-BTS MFS-BSC Gb
O&M
Abis-O&M BSC-O&M TC-O&M MFS-O&M Q3
New interface OMC <-> external device.

ED 02 Released

8 GLOSSARY
8.1 Abbreviations
END OF DOCUMENT

ED 02 Released

External alarm supervision for Mx

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

External alarm supervision for Mx

Uploaded by

Copyright:

Available Formats

Site EVOLIUM

Domain : Alcatel BSS