Professional Documents
Culture Documents
NMC/9153 Omc-R Q3 Information
NMC/9153 Omc-R Q3 Information
TABLE OF CONTENTS
1. INTRODUCTION...............................................................................................6
1.1 The requirements...................................................................................6
1.2 Presentation of the 9153 OMC-R external interfaces..........................6
1.3 Scope of the document .........................................................................7
1.4 Common Conventions...........................................................................8
1.5 Configuration Parameters.....................................................................8
4. SUPPORTED SERVICES...............................................................................23
4.1 Configuration Management ................................................................23
4.1.1 Services supported at the NMC/9153 OMC-R interface ..............23
4.1.2 Services supported at other 9153 OMC-R external interfaces.....24
4.1.3 Date and time management ........................................................24
4.2 Fault management ...............................................................................25
4.2.1 Introduction..................................................................................25
4.2.2 State Management ......................................................................25
4.2.3 Alarm Reporting & Acknowledgement .........................................25
4.2.3.1 Introduction.....................................................................................................25
4.2.3.2 Main fields of an alarm message.....................................................................26
4.2.3.3 Relationship attributes.....................................................................................28
4.3 Event Report Management and Log Control .....................................28
4.3.1 Introduction..................................................................................28
Profile for the NMC/9153 OMC-R Q3 Interface
ED 02 RELEASED
9654l2re.doc
05/08/2008 3BK 09654 LAAA PBZZA 1/35
4.3.2 Event Report Management..........................................................28
4.3.3 Log Control ..................................................................................29
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
6. ACRONYMS ...................................................................................................35
Figure 3: The 9153 OMC-R instance and the sub-network managed by it............................11
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Figure 4: General Naming Tree for the NMC/9153 OMC-R Q3 Interface Information Model18
Figure 5: Complement to the Naming Tree for GPRS Alarms Reporting ..............................19
Figure 6: Inheritance hierarchy (X.721-related part)..............................................................19
Figure 7: Inheritance hierarchy (M.3100-related part) ...........................................................20
Figure 8: Inheritance hierarchy (Q.751.1-related part) ..........................................................20
Figure 9: Inheritance hierarchy (GSM 12.00-related part) .....................................................20
Figure 10: Inheritance hierarchy (GSM 12.20-related part) ...................................................21
Ed. 02
− 18/07/2008:
• The name of the OMC-R is changed: “A1353-RA” is replaced by “9153 OMC-R”.
− 05/08/2008: No technical changes.
REFERENCED DOCUMENTS
Standards
Management:
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Alcatel-Lucent documents
Statements
3BK 09709 LAAA PBZZA
Part of these requirements lead to choose an interface based on a normalised model and
the Q3 protocol.
• Export whole (or part for an external application other than a NMC) of the 9153
OMC-R (externally accessible) configuration data either at Network Level or for a
given BSS-NE.
In addition, the corresponding export sessions can be requested and the
associated file transfer controlled through the NMC/9153 OMC-R Q3 interface.
This interface is specified in:
• [ACIE-gene] for the issues that are not release-dependent,
• dedicated documents for the (release-dependent) supplementary information,
notably [ACIE-si].
9153 OMC-R
Import files
transfer
Radio Network Level
File-based
Export files
External
transfer
Interfaces
NMCs
File upload
control
− [ANOIcs-gene] for an overview of the information model and the related Conformance
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Statements, i.e. peculiarities with respect to the GDMO Formal Specification that apply
to the objects of the instantiable Managed Object Classes. In particular, it describes, for
each instantiable Managed Object Classes, which of the applicable packages are
actually instantiated and the corresponding list of attributes/actions/notifications with
noticeable issues with respect to the latter.
CONVENTION SEMANTICS
Light grey is used to highlight items that are conditionally
instantiated, conditionally present or conditionally relevant
Dark grey is used to highlight items that are never
instantiated, never present, not supported or not
applicable
Table 1: Common conventions
supported.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
Supervision
Supervision
Configuration
N.B.: The GDMO label used for the resulting proprietary part of the NMC/9153 OMC-R
Q3 information model is “ANOI”. Besides, the names of GDMO definitions that
have a standard counterpart are prefixed with “anoi” so as to avoid any potential
name clashes for post-processing tools that do not take into account GDMO labels.
2.2.1 Introduction
All rights reserved. Passing on and copying of this
document, use and communication of its contents
"
"
#$
#$
− The common part made of the components supporting a number of common functions,
notably Event Report management, Log control, Object Management and File Transfer
Control.
− The core part made of core BSS-NEs, a core BSS-NE (sometimes called BSS-NE for
short) consisting of a BSC equipment and the sub-network managed by that
equipment).
For this part, the services to be supported are:
• A complete supervision view on equipment (down to board).
• A traffic supervision and a possibility of 2Mbits topology discovery
• A traffic supervision independent from the equipment maintenance.
This part being not yet standardized, supporting the same level of supervision as for the
All rights reserved. Passing on and copying of this
document, use and communication of its contents
core part would have lead to add fully proprietary features in the model, which is not in
line with the aforementioned information model policy. As a consequence, only overall
supervision of the corresponding alarms is supported.
This leads to an information model that can be splitted into the following fragments:
− A common fragment based on [X.721] and [GSM12.00] to model the common part.
− A transmission fragment based on [M.3100] and [Q.751.1] which supports Managed
Object Classes to represent the different types of connections and termination points.
− An equipment fragment based on [M.3100] which supports Managed Object Classes
to represent the equipments.
This is in conformance with [GSM12.20], which refers to [M.3100] for equipment
management.
− A bssFunction fragment based on [GSM12.20] which supports Managed Object
Classes to model the functionalities of the corresponding equipments.
This fragment supports QoS alarms and enables traffic surveillance independently from
equipment supervision.
Given that only overall supervision is supported for the GPRS-specific part, the last three
fragments only concern the core part.
N.B.: In what follows, the expression 'Abstract Class' is used to qualify a Managed
Object Class that is used for inheritance purposes only.
In addition, the "ANOI":anoiPlmnNetwork MOC is used to serve as naming sub-root for the
GSM-related managed object instances.
The latter contains:
an 9153 OMC-R managed sub-network, i.e. all the alarms emitted by managed object
All rights reserved. Passing on and copying of this
document, use and communication of its contents
instances at the 9153 OMC-R/9130 BSC/MFS Evolution internal interface are mapped
onto alarms emitted by the corresponding "ANOI":anoiGPRSManagedElement
managed object instance at the NMC/9153 OMC-R Q3 interface.
− "ANOI":anoiTerminationPointBidirectional
Managed object instances of this MOC are used to represent 2Mb termination points
• of an Alcatel BTS equipment
• of a BSC at the Abis, Ater or AterMux interface
• of a transcoder at the AterMux or A interface.
In particular, this MOC is instantiated:
• to represent the two termination points with which an instance of
"M.3100":connectionR1 is in relation
• for each Ater and A PCM Circuit. This makes it possible to supervise the Ater and
A interface.
This modelling enables, in case of failure, to precisely determinate which side of the 2 Mb
links is concerned.
In addition, the following Managed Object Classes are supported for Signalling System No.7
management:
− "Q.751.1":mtpSignPoint
− "ANOI":anoiSignLinkSetTp
− "ANOI":anoiSignLinkTp
− " ANOI ":anoiBssFunction is instantiated for each core BSS-NE to model its O&M
functionality.
− "ANOI":anoiBsc allows to supervise the overall BSC telecom activity and to report the
state of the 9153 OMC-R/BSC interface. A managed object instance of this MOC has
an "M.3100":alarmStatus attribute and sends (notably) "X.721":qualityofServiceAlarm
notifications.
− "ANOI":anoiBts is instantiated for each BTS sector. An instance of this MOC controls
the telecom activity of a cell referenced by its cell identity (CI) and the location area
code (LAC). Its sends (notably) "X.721":qualityofServiceAlarm notifications whenever
the operational state or the availability status of the corresponding cell is affected due to
faulty BTS hardware resource (e.g. frame unit, carrier unit). The 9153 OMC-R is able to
support threshold formula associated with "X.721":qualityofServiceAlarm notifications.
2.3.1 Conventions
In the Naming Trees below, the following conventions are used:
Properly speaking, the corresponding MOIs are not instantiated at the NMC/9153 OMC-R Q3
Interface. They only serve to model corresponding internal MOIs for Alarm Reporting and
Acknowledgement purposes (in case ALARM_ACKNOWLEDGEMENT = 1).
Idem but the corresponding internal MOIs are present only for Naming purposes (i.e. they
cannot send alarms).
root
"ANOI":
anoiPlmnNetwork "X.721": system
"X.721":
eventForwardingDiscriminator "X.721":log
"X.721": "X.721":
objectDeletionRecord stateChangeRecord
"ANOI": "ANOI":
anoiCoreManagedElement anoiGPRSManagedElement
"M.3100": "ANOI":anoiFunction
"ANOI":
equipmentHolder (Shelf) anoiSignLinkTp
"ANOI":anoiCircuitPack
"GSM 12.00":
"ANOI":anoiBssFunction generalDataTransferControlFunction
"ANOI":anoiBts
"ANOI":anoiBasebandTransceiver
Figure 4: General Naming Tree for the NMC/9153 OMC-R Q3 Interface Information
Model
"NMD":neGroup
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
"NMD":networkElement
"ABSS":aGprs "NMD":neSupervision
BssFunction "AMFSME":aGprs2MbTTP Coordinator "AGVC":aGprsNse
"ABSS":aGprs "AGFR":aGprs
BtsSiteManager BearerChannel "AGVC":aGprsLapdLink "AGVC":aGprsNsvc
"ABSS":aGprsBts "AGFR":aGprsPvc
"M.3100":equipment
"AGVC":aGprsSgsnIpEndPoint
Holder (rack)
"M.3100":equipment
Holder (shelf)
"LAPF":nectarCircuitPack
"X.721":top
"X.721":eventLogRecord "X.721":eventForwardingDiscriminator
"X.721": "X.721":
"X.721":alarmRecord attributeValueChangeRecord objectCreationRecord
"X.721":top
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
"M.3100": "ANOI":anoiTerminationPoint
connectionR1 Bidirectional
"ANOI": "ANOI":
anoiCircuitPack anoiEquipmentR1 "M.3100":equipmentHolder
"X.721":top
"X.721":top
"X.721":logRecord "ANOI":anoiPlmnNetwork
"X.721":eventLogRecord
"X.721":alarmRecord
"X.721":top
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
"GSM 12.20":gsmManagedFunction
"ANOI":anoiBtsSiteManager
The NMC/9153 OMC-R Q3 interface complies with [Q.811] for the lower layers and [Q.812]
All rights reserved. Passing on and copying of this
document, use and communication of its contents
for the upper layers of the Q3 Protocol. The corresponding Conformance Statements are
specified in [ANOIcs-Q3P].
In particular,
− The following lower layer protocol profiles defined in [Q.811] are supported:
• CONS1: A connection-mode packet interface using X.25
• CLNS1: A connectionless-mode interface using [ISO/IEC 8802-2] type
LANs using Carrier Sense Multiple Access with Collision
Detection (CSMA/CD)
• RFC1006/TCP/IP: OSI Transport class 0 over Internet TCP.
− Only the upper layer protocol profile for Interactive Class services defined in [Q.812] is
relevant for the NMC/9153 OMC-R Q3 Interface (Session and Presentation layers,
ACSE, ROSE and CMISE).
− Network Discovery:
Network discovery consists in requesting the list of BSS-NEs which compose the 9153
OMC-R managed sub-network.
This can be performed using the following GET request:
BOC: "ANOI":anoiPlmnNetwork MOC
scope: firstLevelOnly
which makes it possible to know all the "ANOI":anoiCoreManagedElement and
"ANOI":anoiGPRSManagedElement managed object instances, i.e. all the
corresponding BSS-NEs.
• If, for a given managed object instance, the value of a GET or GET-REPLACE
attribute that is not a state or status attribute changes, then the
"X.721":attributeValueChange notification is sent by this managed object instance.
Only exceptions to this (standard) general rule are stated in [ANOIcs-gene].
possible so as not to overflow the external Q3 links. For example, only one
“X.721”:objectDeletion notification is sent when a core BSS-NE is deleted since
this undoubtedly implies that all the managed object instances named under it
have been deleted. See also section 5.3.1.3.
4.2.1 Introduction
All rights reserved. Passing on and copying of this
document, use and communication of its contents
4.2.3.1 Introduction
The Alarm Management function is supported as defined in [X.733].
In addition, if ALARM_ACKNOWLEDGEMENT = 1:
not permitted without written authorization from Alcatel.
− A NMC can request the acknowledgement of a given set of alarms concerning either a
All rights reserved. Passing on and copying of this
document, use and communication of its contents
The table below indicates the main fields that can be present and a short description of the
latter:
FIELD/SUB-FIELD NAME COMMENTS
managedObjectClass This field identifies the Managed Object Class to which
the object instance emitting the notification belongs.
managedObjectInstance This field identifies the object instance emitting the
notification.
eventTime This field contains a BSS time-stamp
eventType This field indicates the category of the alarm
(communication, environmental, equipment,
processingError or qualityofService alarm).
eventInfo
− probableCause This sub-field indicates the probable cause of the alarm
as an OID value.
The set of probableCause values that can be used are
defined in [ANOIgdmo]. These values are all standard
ones.
− specificProblems This sub-field is a list of integers that are such that an
alarm emitted by a given object instance with a
perceivedSeverity field equal to 'cleared' can safely clear
the alarms for that managed object instance that have
the same eventType, probableCause and
specificProblems field values.
For more information, see [ANOIcs-gene].
− perceivedSeverity This sub-field indicates the perceived severity of the
alarm (indeterminate, critical, major, minor, warning or
cleared).
− thresholdInfo This sub-field may only be present for a
qualityofServiceAlarm notification. . If present, it
indicates corresponding threshold information.
For more information, see [ANOIcs-gene].
knowing that an object of the transmission or equipment fragment is in alarm, to reach easily
the concerned object in the bssFunction fragment.
4.3.1 Introduction
A number of events emanate from the radio sub-system or are generated internally in the
9153 OMC-R. They can be reported to the NMCs as a notification corresponding to the type
of event emitted by an appropriate object according to the definition of the Managed Object
Class to which the object belongs. The main possible notifications are:
− “X.721”:stateChange to report changes in the value of state and status attributes
− “X.721”:attributeValueChange to report changes in the value of the other attributes
− alarm notifications (see above)
− “X.721”:objectCreation to report object creations.
− “X.721”:objectDeletion to report object deletions.
Concerning the actual forwarding and the logging of these potential event reports, the
following functions are supported:
− Event Report Management through “X.721”:eventForwardingDiscriminator (EFD)
objects.
− Log Control through “X.721”:log and logRecord objects.
log objects can be used to select the potential event reports that are to be logged in the
form of appropriate logRecords.
Setting this attribute again to the ‘unlocked’ value enables to resume the EFD
All rights reserved. Passing on and copying of this
document, use and communication of its contents
activity.
• “X.721”:discriminatorConstruct
• “X.721”:destination
A NMC can find out all the existing “X.721”:eventForwardingDiscriminator object instances
by an M-GET request of the following form:
BOC: “X.721”:system MOC
BOI see [ANOIcs-gene]
scope: firstLevelOnly
filter: see [ANOIcs-gene]
A NMC can perform M-GET requests with a BOC argument equal to the
“X.721”:eventForwardingDiscriminator MOC. In this case, there is no restriction on the
allowed filter argument.
EFDs are persistent and support the possibility to forward events to several destinations.
Logs are global to the sub-network managed by the 9153 OMC-R and are in wrap mode.
A NMC can create “X.721”:log objects. These objects can be deleted either by a NMC or by
a 9153 OMC-R operator.
The other requests that are allowed for a NMC are as follows:
− M-GET on all attributes
− M-SET on:
• “X.721”:administrativeState,
Setting this attribute to the ‘locked’ value enables to suspend the log activity. In this
state, M-SET requests on the modifiable log attributes are allowed.
Setting this attribute again to the ‘unlocked’ value enables to resume the log
activity.
• “X.721”:capacityAlarmThreshold (provided this attribute is present, see [ANOIcs-
gene]),
• “X.721”:discriminatorConstruct,
• "X.721":logFullAction
Profile for the NMC/9153 OMC-R Q3 Interface
ED 02 RELEASED
9654l2re.doc
05/08/2008 3BK 09654 LAAA PBZZA 29/35
• “X.721”:maxLogSize (provided this attribute is present, see [ANOIcs-gene]).
A NMC can find out all the existing “X.721”:log object instances by a M-GET request of the
not permitted without written authorization from Alcatel.
following form:
All rights reserved. Passing on and copying of this
document, use and communication of its contents
This part describes the relationships concerning the NMC/9153 OMC-R system.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
• The BSS-NE radio configuration is aligned on 9153 OMC-R values. The 9153
OMC-R databases are regarded as containing the correct values in terms of radio
configuration. The 9153 OMC-R updates the BSS-NE database without warning
the NMCs because all changes done in the 9153 OMC-R databases are
propagated to the NMCs.
• The 9153 OMC-R hardware and transmission configuration is aligned on the BSS-
NE values. The BSS-NE database is regarded as the reference concerning
hardware and transmission configuration. The 9153 OMC-R updates its own
databases and warns the NMCs against changes by sending the corresponding
notification.
• Concerning alarms, the 9153 OMC-R alarm situation is aligned on the BSS-NE
one. The 9153 OMC-R updates its view of the alarm situation and informs the
NMCs of the changes by sending alarm notifications.
When an audit is performed for a given BSS-NE, the NMCs are warned via a
"X.721":stateChange notification sent by the corresponding
“ANOI”:anoiCoreManagedElement or “ANOI”:anoiGPRSManagedElement MOI with
'reporting' as old “X.721”:proceduralStatus attribute value.
During a BSS-NE audit phase, a NMC is allowed to perform M-GET requests but it is
warned that these requests may return consistent but not accurate (since not updated)
values thanks to this "X.721":stateChange notification.
Profile for the NMC/9153 OMC-R Q3 Interface
ED 02 RELEASED
9654l2re.doc
05/08/2008 3BK 09654 LAAA PBZZA 31/35
When the audit phase is terminated, the NMCs are warned via a "X.721":stateChange
notification sent by the same MOI with 'reporting' as new “X.721”:proceduralStatus
attribute value.
not permitted without written authorization from Alcatel.
All rights reserved. Passing on and copying of this
document, use and communication of its contents
3) NMC resynchronisation
The previous mechanisms do not guarantee that the database of a NMC is consistent
with the 9153 OMC-R databases in case of a Q3 link failure with that NMC or a 9153
OMC-R system failure (detected as described in section 5.2).
To handle these cases, the NMC resynchonisation mechanism is supported (see
section 5.3).
− Then, for each BSS-NE, the steps described in section 5.3.1.3 are performed.
Then the BSS-NE is initialized. A NMC is warned that the BSS-NE has been correctly
initialized via a "X.721":stateChange notification sent by the corresponding
“ANOI”:anoiCoreManagedElement or “ANOI”:anoiGPRSManagedElement managed object
instance with 'reporting' as new “X.721”:proceduralStatus attribute value.
When this initialization phase of the BSS-NE is completed, a NMC should perform a
configuration resynchronization (only for core BSS-NEs) then an alarm resynchronization for
that BSS-NE. In particular, during this initialization phase,
− for a core BSS-NE, the notifications that are sent by the corresponding
“ANOI”:anoiCoreManagedElement MOI or a MOI named under it
− for a GPRS BSS-NE, the notifications that are sent by the corresponding
“ANOI”:anoiGPRSManagedElement MOI
(if any) shall not be relied upon together with the attribute values of those MOIs.
object instance.
END OF DOCUMENT