ETSI ETS 300 624 ed.1 (1996-08)

Digital cellular telecommunications system (Phase 2) (GSM); Interworking of GSM Network Management (NM) procedures and messages at the Base Station Controller (BSC) (GSM 12.22)

DE/SMG-061222P

Digitalni celični telekomunikacijski sistem (faza 2) ¬– Medsebojno delovanje postopkov za upravljanja omrežja GSM in sporočil (NM) pri krmilniku bazne postaje (BSC) (GSM 12.22)

General Information

• Status: Published
• Publication Date: 03-Sep-1996
• Technical Committee: SMG 6 - Operations & Maintenance
• Current Stage: 12 - Completion
• Due Date: 27-Jun-1996
• Completion Date: 04-Sep-1996
• Ref Project: SIST ETS 300 624 E1:2003 - Digital cellular telecommunications system (Phase 2) (GSM); Interworking of GSM Network Management (NM) procedures and messages at the Base Station Controller (BSC) (GSM 12.22)

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D¤±0HGVHERMQRGHORYDQMH
SRVWRSNRY]DXSUDYOMDQMDRPUHåMD*60LQVSRURþLO10SULNUPLOQLNXED]QH
SRVWDMH%6&*60
Digital cellular telecommunications system (Phase 2) (GSM); Interworking of GSM
Network Management (NM) procedures and messages at the Base Station Controller
(BSC) (GSM 12.22)
Ta slovenski standard je istoveten z: ETS 300 624 Edition 1
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 624
TELECOMMUNICATION August 1996
STANDARD
Source: ETSI TC-SMG Reference: DE/SMG-061222P
ICS: 33.060.50
Key words: Digital cellular telecommunications system, Global System for Mobile Communications (GSM)
Digital cellular telecommunication system (Phase 2);
Interworking of GSM Network Management (NM) procedures
and messages at the Base Station Controller (BSC)
(GSM 12.22)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1996. All rights reserved.

Page 2
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Contents
Foreword .7
Introduction.7
1 Scope .9
2 Normative references.9
3 Abbreviations.10
4 Common Interworking aspects.10
4.1 General considerations.10
4.1.1 Interworking tasks .10
4.1.2 Mapping between GSM 12.20 specified and GSM 12.21 specified Object
Classes.11
4.1.3 Addressing Objects at the BTS Site and handling different BTS
configurations.11
4.2 CMIP Operations .11
4.2.1 Creation of BTS related Object instances .11
4.2.2 Setting attributes of BTS related Objects .12
4.2.3 Getting attributes of BTS related Objects.13
4.2.4 Deletion of BTS related Objects.13
4.2.5 Actions on BTS related Objects .13
4.2.6 Event Reports sent by BTS related Objects.13
4.2.7 CMIS Parameters.14
4.3 Error handling .14
4.4 State management of BTS related objects.15
4.4.1 Initial states .15
4.4.2 Setting administrative state .15
4.4.2.1 Setting administrative state to Unlocked .16
4.4.2.2 Setting administrative state to Locked.16
4.4.2.3 Setting administrative state to Shutting Down .16
4.4.3 Getting state Attributes.16
4.4.4 Notifications about State Changes.16
4.5 Alarm reporting .18
5 Specific interworking aspects.21
5.1 BasebandTransceiver Object Class .21
5.1.1 Information Mapping between GSM 12.20 basebandTransceiver and
GSM 12.21 Baseband Transceiver .21
5.1.1.1 Mapping of Attributes.21
5.1.1.2 Mapping of GSM 12.21 Event Reports to GSM 12.20
Notifications .22
5.1.1.3 Mapping of GSM 12.20 Actions to GSM 12.21 procedures.23
5.1.2 The Specific Interworking Procedures of the basebandTransceiver Object
Class .23
5.1.2.1 Initialization Procedure for the basebandTransceiver
Object Class .23
5.1.2.2 M-DELETE.25
5.1.2.3 M-SET.25
5.1.2.4 M-GET .26
5.1.2.5 M-ACTION, forcedHO .26
5.2 BTS Object Class .26
5.2.1 Information Mapping between GSM 12.20 bts Object and GSM 12.21
BTS Object.26
5.2.1.1 Attribute Mapping.26

Page 4
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
5.2.1.2 Mapping of GSM 12.21 Event Reports to GSM 12.20
Notifications. 28
5.2.1.3 Mapping of GSM 12.20 actions to GSM 12.21 procedures 28
5.2.2 The specific interworking procedures of the bts Object Class. 28
5.2.2.1 Initialization procedure for the bts Object Class. 28
5.2.2.2 M-DELETE. 30
5.2.2.3 M-SET. 30
5.2.2.4 M-GET . 31
5.2.2.5 M-ACTION, forcedHO. 32
5.2.2.6 M-ACTION, channelConfigurationModification. 32
5.3 BTS SiteManager Object Class . 34
5.3.1 Information mapping between GSM 12.20 btsSiteManager and
GSM 12.21 Site Manager . 34
5.3.1.1 Mapping of attributes. 34
5.3.1.2 Mapping of GSM 12.21 Event Reports to GSM 12.20
Notifications. 34
5.3.2 The specific interworking procedures of the btsSiteManager Object Class . 35
5.3.2.1 Initialization procedure for the btsSiteManager Object
Class . 35
5.3.2.2 M-DELETE. 37
5.3.2.3 M-SET. 37
5.3.2.4 M-GET . 37
5.4 Channel Object Class . 37
5.4.1 Information mapping between GSM 12.20 channel and GSM 12.21
Channel . 37
5.4.2 Mapping of attributes . 37
5.4.2.1 Mapping of GSM 12.21 event reports to GSM 12.20
notifications . 38
5.4.3 The specific interworking procedures of the channel Object Class. 38
5.4.3.1 Initialization procedure for the channel Object Class. 38
5.4.3.2 M-DELETE. 40
5.4.3.3 M-SET. 40
5.4.3.4 M-GET . 41
5.5 FrequencyHoppingSystem Object Class. 41
5.5.1 Information mapping between GSM 12.20 frequencyHoppingSystem
attributes and GSM 12.21 Channel . 41
5.5.1.1 Mapping of Attributes . 41
5.5.2 The interworking procedures of the frequencyHoppingSystem Object
Class. 42
5.5.2.1 Initialization procedure for the frequencyHoppingSystem
Object Class. 42
5.5.2.2 M-DELETE. 42
5.5.2.3 M-SET. 42
5.5.2.4 M-GET . 43
5.6 LapdLink Object Class . 43
5.6.1 Information mapping between GSM 12.20 lapdLink and GSM 12.21
Objects. 43
5.6.1.1 Mapping of attributes. 43
5.6.2 Interworking procedures for the lapdLink Object Class. 44
5.6.2.1 Initialization procedure for the lapdLink Object Class . 44
5.6.2.2 M-DELETE. 44
5.6.2.3 M-SET. 44
5.6.2.4 M-GET . 44
5.7 radioCarrier Object Class. 45
5.7.1 Information mapping between GSM 12.20 radioCarrier and GSM 12.21
Radio Carrier . 45
5.7.1.1 Mapping of attributes. 45
5.7.1.2 Mapping of GSM 12.21 Event Reports to GSM 12.20
notifications . 45
5.7.2 The interworking procedures of the radioCarrier Object Class . 46
5.7.2.1 The Initialization procedure for the radioCarrier Object
Class . 46
5.7.2.2 M-DELETE. 47

Page 5
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
5.7.2.3 M-SET.47
5.7.2.4 M-GET .48
5.8 Software Objects .48
5.8.1 Introduction.48
5.8.2 Replaceable Software Unit Object Class .49
5.8.2.1 Information mapping between GSM 12.20
replaceableSoftwareUnit and GSM 12.21 objects.49
5.8.2.1.1 Mapping of attributes .49
5.8.2.2 Interworking procedures .50
5.8.2.2.1 M-CREATE .50
5.8.2.2.2 M-DELETE.50
5.8.2.2.3 M-SET.50
5.8.2.2.4 M-GET .50
5.8.3 Executable Software Unit Object Class.51
5.8.3.1 Information mapping between GSM 12.20
executableSoftwareUnit and GSM 12.21 objects .51
5.8.3.2 Interworking procedures .51
5.8.3.2.1 M-CREATE .51
5.8.3.2.2 M-DELETE.51
5.8.3.2.3 M-SET.51
5.8.3.2.4 M-GET .51
5.8.4 Operating Software Unit Object Class.51
5.8.4.1 Information Mapping between GSM 12.20
operatingSoftwareUnit and GSM 12.21 objects .51
5.8.4.2 Interworking procedures .52
5.8.4.2.1 M-CREATE .52
5.8.4.2.2 M-DELETE.52
5.8.4.2.3 M-SET.52
5.8.4.2.4 M-GET .54
6 Related A-Bis Structured Procedures .54
6.1 LAPD Link Connection.54
6.2 LAPD Link Disconnection .55
6.3 Software Downloading and Activation .55
6.3.1 Software Downloading.55
6.3.2 Software Activation.56
Annex A (informative): Some interworking issues .57
A.1 Structured procedures on Q3 Interface.57
Annex B (informative): Reconfiguration procedures .58
B.1 Assumptions.58
B.2 Implementation specific issues .58
B.3 Reconfiguration when BCCH is lost .59
B.4 Reconfiguration when SDCCH is lost.60
Annex C (informative): List of attributes .63
History.65

Page 6
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Blank page
Page 7
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Foreword
This European Telecommunication Standard (ETS) was produced by the Special Mobile Group (SMG)
Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS describes the BSC interworking within the Digital cellular telecommunications system. This ETS
corresponds to GSM technical specification, GSM 12.22, version 4.1.4.
The specification from which this ETS has been derived was originally based on GSM Phase 1
documentation, hence the presentation of this ETS is not entirely in accordance with the ETSI/PNE rules.
NOTE: TC-SMG has produced documents which give technical specifications for the
implementation of the Digital cellular telecommunications system. Historically, these
documents have been identified as GSM Technical Specifications (GSM-TSs). These
specifications may subsequently become I-ETSs (Phase 1), or European
Telecommunication Standards (ETSs)(Phase 2), whilst others may become ETSI
Technical Reports (ETRs). These ETSI-GSM Technical Specifications are, for editorial
reasons, still referred to in this ETS.
Transposition dates
Date of adoption of this ETS: 06 June 1996
Date of latest announcement of this ETS (doa): 26 September 1996
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 27 March 1997
Date of withdrawal of any conflicting National Standard (dow): 27 March 1997
Introduction
This ETS is structured as follows;
1) Scope;
2) Normative references;
3) Abbreviations;
4) Common interworking aspects;
5) Specific interworking aspects;
6) Related A-bis structured procedures;
Annex A (informative) Some interworking issues;
Annex B (informative) Reconfiguration procedures;
Annex C (informative) List of attributes.
Clause 4 describes the aspects common to all the managed object classes that cause interworking
between the Q3 and Qx interfaces. Objects and their naming and addressing on the OMC-BSC and A-bis
Qx interfaces are briefly described. General requirements for Q3/Qx interworking for CMIP operations
including error handling are given. Q3/Qx interworking of general functions, i.e. state management and
alarm reporting, are also specified.
Clause 5 specifies the aspects, specific to each object class, that cause interworking. This clause contains
the requirements on mapping between the GSM 12.20 specified and GSM 12.21 specified objects, their
attributes, and object specific interworking procedures for different CMIP operations.
Clause 6 defines the A-bis structured procedures used in clause 3.
Annex A describes the structured procedures at a high level which are used in managing the BTS from
the OMC. Annex B contains example procedures for BCCH and SDCCH reconfiguration. Annex C
contains the list of GSM 12.20 and GSM 12.21 attributes that are referenced in this specification.

Page 8
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Blank page
Page 9
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
1 Scope
To ensure management of different manufacturers' BTSs from the OMC through the BSC in a
standardized way, this BSC interworking ETS relates the OMC-BSC interface (Q3) as specified in
GSM 12.20 and the BSC-BTS interface (A-bis Qx) as specified in GSM 12.21. In GSM 12.01 it is required
that the BSC performs the Mediation Function between the OMC and the BTS. This ETS defines the
requirements for this Mediation Function.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references, the
latest edition of the publication referred to applies.
[1] CCITT Recommendation X.710: "Information technology - Open Systems
Interconnection - Common Management Information Service Definition for
CCITT Applications".
[2] CCITT Recommendation X.711: "Information technology - Open Systems
Interconnection - Common Management Information Protocol specification for
CCITT Applications".
[3] CCITT Recommendation X.721 (ISO 10165-2): "Information technology - Open
Systems Interconnection - Structure of management information: Definition Of
Management Information".
[4] CCITT Recommendation X.731 (ISO 10164-2): "Information technology - Open
Systems Interconnection - Systems Management: State Management".
[5] CCITT Recommendation X.733 (ISO 10164-4): "Information technology - Open
Systems Interconnection - Systems Management: Alarm Reporting".
[6] CCITT Recommendation X.734 (ISO 10164-5): "Information technology - Open
Systems Interconnection - Systems Management: Event Report Management
Function".
[7] CCITT Recommendation X.735 (ISO 10164-6): "Information technology - Open
Systems Interconnection - Systems Management: Log Control Function".
[8] GSM 04.08 (ETS 300 557): "Digital cellular telecommunication system
(Phase 2); Mobile radio interface layer 3 specification".
[9] GSM 08.56 (ETS 300 595): "Digital cellular telecommunication system
(Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS)
interface Layer 2 specification".
[10] GSM 08.58 (ETS 300 596): "Digital cellular telecommunication system
(Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS)
interface Layer 3 specification".
[11] GSM 12.00 (ETS 300 612-1): "Digital cellular telecommunication system
(Phase 2); Objectives and structure of Network Management (NM)".
[12] GSM 12.01 (ETS 300 612-2): "Digital cellular telecommunication system
(Phase 2); Common aspects of GSM Network Management (NM)".
[13] GSM 12.20 (ETS 300 622): "Digital cellular telecommunication system
(Phase 2); Base Station System (BSS) Management Information".

Page 10
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
[14] GSM 12.21 (ETS 300 623): "Digital cellular telecommunication system
(Phase 2); Network Management (NM) procedures and message on the A-bis
interface".
3 Abbreviations
Abbreviations used in this ETS are listed in GSM 01.04.
4 Common Interworking aspects
4.1 General considerations
4.1.1 Interworking tasks
Figure 1 illustrates differences between Q3 and A-bis Qx interfaces and the object models in the BSC and
the BTS.
info-model
info-model
OMC BSC BTS
BTS
BSC
MIB MIB
'sees'
'sees'
M A MA
CMIS CMIS
CMIP
12.21 elementary 12.21 elementary
procedures
procedures
Resource
Resource
A-bis O&M
Resource
Resource
M: Manager
A: Agent
Figure 1: Mapping of information models
In the A-bis interface, layers 1 and 2 are common with telecommunication signalling specified in
GSM 08.5X. Network management messages and procedures on the A-bis interface are based on the
layer 3 transport mechanism specified in GSM 12.21 and are consistent with the telecommunications
signalling on layers 3 as specified in GSM 08.58.
The protocol profiles for the Q3 interface are specified in GSM 12.01.
For network management purposes, the BSC is responsible for the following interworking tasks:
- bi-directional protocol conversion so as to provide mapping between Q3 and A-bis Qx interfaces
which consists of mapping of GSM 12.20 objects onto GSM 12.21 objects, mapping of CMIS
services onto GSM 12.21 procedures and association of GSM 12.20 attributes to GSM 12.21
attributes;
- management of interworking functions activated by the OMC and terminated within the BTS and
vice versa;
- handling of interworking errors, i.e., reporting errors in case of failure in interworking procedures.
NOTE: The functions activated by the OMC and terminated within the BSC or functions
activated by the BTS and terminated within the BSC are not specified here. This
applies also to the vice versa situations.

Page 11
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
4.1.2 Mapping between GSM 12.20 specified and GSM 12.21 specified Object Classes
Q3 and A-bis Qx interfaces use different object models. The specification of the interworking procedures
between these interfaces requires mapping the object classes and instances between the Q3 interface
and the A-bis Qx interface and vice versa. The following table contains BTS related object classes
specified in GSM 12.20 and the corresponding object classes specified in GSM 12.21.
Table 1: BTS related object classes in GSM 12.20 and GSM 12.21.
GSM 12.20 BTS related object classes GSM 12.21 object classes
btsSiteManager Site Manager
bts BTS
basebandTransceiver Baseband Transceiver
radioCarrier Radio Carrier
1)
frequencyHoppingSystem Channel
channel Channel
lapdLink 2)
NOTE 1: GSM 12.21 does not specify the frequency hopping system as an object class. The
corresponding information is included in the attributes of the channel class.
NOTE 2: The information about the signalling links of the BTS side (PCM port numbers and
timeslots in the BTS) is included in the attributes of Site Manager, BTS and Baseband
Transceiver classes. In GSM 12.20 the corresponding object classes have references
to LAPD links which are either O&M links (in Site Manager, bts or
basebandTransceiver) or telecom signalling links (only to basebandTransceiver).
4.1.3 Addressing Objects at the BTS Site and handling different BTS configurations
The BCF (Base Control Function) mentioned in GSM 08.52 and GSM 08.56 is the agent at the BTS end of
the A-bis Qx interface. There could be one or more of these agents at the site and the GSM 12.21 objects
and attributes that each agent can manage depend on the implementation. Each agent is connected to
the manager at the BSC via a LAPD link which is identified by a physical link address (i.e. PCM circuit and
(sub)timeslot), TEI (Terminal Endpoint Identifier) and SAPI (Service Access Point Identifier). In order to
address the various BTS objects over the A-bis Qx interface it is required that the BSC contain
associations between BTS related objects defined in GSM 12.20 and the agents (i.e. O&M links) that
manage the corresponding GSM 12.21 objects at the BTS site.
The procedures that relate to the A-bis interface management are optional in GSM 12.21 and therefore
not all the BTSs have to support them. However, it is required that these are implemented in the BSC so
that it can support all the BTS implementations that are made according to GSM 12.21. In this case the
BSC must have the information per each BTS whether the A-bis interface management option is
supported or not.
4.2 CMIP Operations
4.2.1 Creation of BTS related Object instances
The M-CREATE service is used by the OMC to request a peer CMISE-service-user (i.e., the agent) at the
BSC to create an object instance, complete with its identification. The corresponding physical resource
may or may not exist at the BTS site.
Normally the initialization of the physical resource via A-bis Qx interface will be started immediately after
the creation if the corresponding physical resource at the BTS site has been installed. Initialization might
include several steps, such as, setting up O&M (and telecommunications) signalling links, downloading
and activation of the software, setting various O&M attributes by GSM 12.21 messages and setting the
system information to be broadcasted from the BTS by GSM 08.58 procedures. Some of these steps are
not relevant for some object classes.

Page 12
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Object creation to the BSC should be possible before any resources are installed at the BTS site. If the
resource for the object to be created has not been installed at the BTS site, the agent at the BTS site will
not respond or it will respond with a NACK message with the NACK cause set to "Resource not available".
In these cases the object shall be created to the BSC MIB but the operational state shall be set to
Disabled. If the needed resource is installed later the corresponding GSM 12.21 object will send a
Changed State Event Report (reference. subclause 4.4) or a SW Activate Request and the initialization
will be tried again. Also setting the administrative state of a disabled object to Unlocked state may trigger
the initialization.
There is one exception to the rule stated above and it is the creation of the channel objects.
Eight instances of the channel are automatically created when a basebandTransceiver is created. These
channel instances have initially NULL values in some of their attributes. These initial NULL values of the
channels shall not be automatically set to the corresponding GSM 12.21 Channels. In this case the BSC
has to wait the OMC manager to set the correct values to the channels and then unlock them before the
attributes are set by the GSM 12.21 procedures (see channel initialization procedure in subclause 5.4.2).
4.2.2 Setting attributes of BTS related Objects
The M-SET service is used by the OMC to request a peer CMISE-service-user to modify attribute values
of an object instance. In the GSM 12.20 context, only the attributes defined as GET-REPLACE can be
modified using the M-SET service.
Normally the corresponding GSM 12.21 object at the BTS site is immediately modified by interworking
procedure defined in clause 5 for the M-SET service. In the interworking procedures, the BSC database
shall be updated before any GSM 12.21 procedures are invoked, and, if the M-SET service is used in the
confirmed mode, a response to M-SET shall also be sent to the OMC before any GSM 12.21 procedures
are invoked. Errors in the GSM 12.21 procedures shall be handled as specified in subclause 4.3.
OMC BSC BTS
M-SET req/ind
(confirmed)
M-SET rsp/conf
(confirmed)
GSM 12.21 procedures
Figure 2: General M-SET interworking
The following attributes defined in GSM 12.20 require that the administrative state of the object instance
has to be Locked before the attribute can be modified:
− bsic (bts);
− channelCombination (channel);
− tsc (channel).
In these cases the administrative state of the object shall be checked and if the administrative state is not
Locked a CMIS error shall be sent and the interworking procedure shall not be executed.

Page 13
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
4.2.3 Getting attributes of BTS related Objects
The M-GET service is used by the OMC to retrieve the values of attributes of an object instance from a
peer CMISE-service-user located in the BSC. The requested attribute values are communicated to the
OMC in the response.
M-GET does not normally cause any interworking procedures because it is assumed that the BSC is
responsible for its database consistency.
GSM 12.21 defines the Get Attributes procedure. Its use is not required in response to an M-GET
operation. However it may be used. If this option is implemented the best-effort synchronization shall be
used. It means that the BSC tries to read all the attributes listed in the M-GET request regardless errors in
some parameters. If a NACK message is received from the BTS CMIS error response shall be sent with a
list of the parameters which had errors and a list of the parameters which could be read.
OMC BSC BTS
req/ind
M-GET
Get Attributes
ACK/NACK
M-GET rsp/conf
Figure 3: Optional M-GET interworking
4.2.4 Deletion of BTS related Objects
The M-DELETE service is used by the OMC to request a peer CMISE-service-user to delete an object
and to deregister its identification in the BSC.
Rules for deletion of contained or related objects are specified in GSM 12.20.
M-DELETE does not normally cause any interworking procedures. However in some cases disconnecting
of links is required. In these cases interworking is described in clause 5.
4.2.5 Actions on BTS related Objects
The M-ACTION service is used by the OMC to request a peer CMISE-service-user to perform an action at
the BSC. The service may be requested in a confirmed or a non-confirmed mode. In confirmed mode a
reply is expected.
Actions are specific to the object classes and therefore a general rule how the interworking procedure is
executed cannot be defined. The interworking procedures for actions are described within the relevant
object classes in clause 5.
4.2.6 Event Reports sent by BTS related Objects
The M-EVENT-REPORT service is invoked by a CMISE-service user (the BSC in this case) to report an
event about a managed object to a peer CMISE-service-user (the OMC). The service may be requested in
a confirmed or a non-confirmed mode. In confirmed mode a reply is expected.
All GSM 12.21 event reports sent by the BTS will generate local notifications at the BSC. These
notifications are then subject to logging (reference. CCITT Recommendation. X.735) and event forwarding
discrimination (reference. CCITT Recommendation. X.734) processes. Those notifications that pass the
discriminators can be forwarded to the OMC as event reports. Potentially any GSM 12.21 event report can
generate an event report from the BSC to the OMC.

Page 14
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
4.2.7 CMIS Parameters
The following parameters could be used in M-SET, M-GET and M-DELETE services to handle multiple
objects at the same time (if multiple object selection and filter functional units of CMIS are used):
− Scope parameter identifies a subtree rooted in (i.e. starting from) the object indicated by the Base
object class and Base object instance parameters.
− Filter parameter specifies the conditions to be checked on the managed objects within the Scope in
order to identify which ones are to be selected.
− Synchronization parameter controls the way for modifying objects (either none or as many as
possible) in the subtree when at least one unsuccessful setting occurs.
If multiple object instances are selected with Scope and Filter parameters BSC has to execute separate
interworking procedures for each object instance.
Error handling is determined with Synchronization parameter as follows:
− If best-effort synchronization is used and an error occurs each interworking procedure shall be
executed to the end. The possible attribute value modifications shall be left as they are.
− If atomic synchronization is used and an error occurs each interworking procedure shall be stopped
and the operations executed so far shall be rolled back (no attribute value modifications are
accepted) in the BSC and in the BTS.
4.3 Error handling
Errors in the interworking procedures can be divided to two categories:
1) General errors detected in the Q3 interface (see CMIS errors in CCITT Recommendation. X.711:
access denied, invalid object class etc.)
Handling of general errors will not be specified in this ETS.
2) Errors detected in the A-bis Qx interface
An interworking procedure in the A-bis Qx interface includes a sequence of elementary procedures. If the
BTS agent detects an error in a GSM 12.21 procedure a NACK message will be returned to the BSC
manager. Another kind of error is that BTS agent does not respond within layer 3 time-out which will be
detected by the BSC manager. These errors have to be mapped to the Q3 interface. Handling of the A-bis
errors in the interworking procedures has the following general principles:
− If a GSM 12.21 elementary procedure fails, the current interworking procedure between the BSC
manager and the BTS agent shall be stopped.
− If the procedure fails due to a received NACK message a processingErrorAlarm notification shall be
generated by the object that was going to be initialized.
The probableCause attribute of the processingErrorAlarm notification shall be set to the value that
indicates the type of the error (e.g. Configuration or customization error, Underlying resource
unavailable, Software error. Reference. CCITT Recommendation. X.733). The additionalText
attribute contains an error message which may be displayed to the OMC operator. The message
has to be filled with the information about the NACK message.
− If the procedure fails due to a LAPD link failure (i.e., if a timeout occurs) a communicationsAlarm
notification shall be generated by the lapdLink object that represents the link that was going to be
used in the interworking procedure.
The probableCause attribute of the communicationsAlarm notification shall be set to the value that
indicates the type of the error.
If there exist some object class specific error handling mechanisms these will be specified in clause 5.

Page 15
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
4.4 State management of BTS related objects
This subclause describes the interworking related to the state management (reference. GSM 12.20 and
CCITT Recommendation. X.731). Management of the state is an important aspect in the interworking
procedures because execution of the interworking procedures depends on the state of the BTS related
objects. The interworking of the state management concerns only the administrativeState and
operationalState attributes.
The state management of BTS related objects is specified partly in the behaviour definitions of
GSM 12.20. This ETS defines only the interworking aspect of the state management.
Table 2: State management attributes in X.721 and GSM 12.21
GSM 12.20/CCITT Rec. GSM 12.21 attributes
X.731 state attributes
administrativeState Administrative State
operationalState Operational State
4.4.1 Initial states
When a BTS related object instance is created its administrative state shall be by default Locked. No
traffic is allowed through the resource that the object instance represents. The initial operational state
shall be Disabled. After a successful initialization the operational state of the object will become Enabled.
4.4.2 Setting administrative state
The administrative state attribute of an object instance is changed, e.g. when the resource presented by
an object instance is put available or unavailable for use. The administrative state attribute can be
modified with the M-SET service invoked remotely from the OMC or locally from the BTS or BSC site.
The changes in the administrative state attributes of contained object instances shall be done
independently, i.e. setting the administrative state of an object instance to Locked shall not cause any
changes in the administrative states of the contained objects.
The effects of the different values of the administrative states of each BTS related object class are
specified in more detail in GSM 12.20.
The general interworking procedure for setting the administrativeState attribute with M-SET is presented
in the following figure.
OMC BSC BTS
M-SET req/ind
(confirmed)
M-SET rsp/conf
Change Administrative
(confirmed)
State(Administrative State)
ACK/NACK
Figure 4: M-SET administrativeState

Page 16
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
4.4.2.1 Setting administrative state to Unlocked
When a resource is put available for use the administrative state of the related object instance(s) is set to
Unlocked. If the operational state of the object instance is Disabled the full initialization procedure of that
object instance shall be tried. Failure in this initialization procedure shall not prevent the object becoming
Unlocked but the operational state will remain Disabled. The initialization may be tried again with locking
and then unlocking the object. The initialization procedures for each BTS related object class are
described in clause 5.
4.4.2.2 Setting administrative state to Locked
All the traffic from the resources represented by the object instance to be locked is disconnected and no
new traffic is accepted through the resources.
4.4.2.3 Setting administrative state to Shutting Down
If the object has no traffic the administrative state is immediately set to Locked.
If the object has traffic the BSC will have to wait until the last user has quitted before locking the object. No
new traffic shall be accepted through the resources.
4.4.3 Getting state Attributes
Normally M-GET doe not cause any interworking. The implementation of this interworking procedure is an
option as specified in subclause 4.2.3.
4.4.4 Notifications about State Changes
When the operational state of a BTS related object instance changes a Changed State Event Report is
generated by the BTS. Then the operational state of the corresponding GSM 12.20 object shall be
appropriately modified and, if applicable, a stateChange notification shall be generated by the
corresponding GSM 12.20 object. This notification can result in an event report to be sent to the OMC
(see Figure 5). If the Changed State Event Report indicates a BCCH or SDCCH failure (i.e. a Baseband
Transceiver, a Radio Carrier or a Channel that is related to BCCH or SDCCH fails) automatic recovery
shall be attempted by the BSC on the following conditions:
− The attributes in the Changed State Event Report have the following values:
Operational state = Disabled, Availability status = Failed.
− The object sending the Changed State Event Report is unlocked.
− The objects containing the failed objects are Enabled and Unlocked.
− Automatic recovery has not been disabled by the operator.
Example procedures are described in annex B.
The administrative state can be requested to be set from the BTS via local MMI commands. In this case
the BTS requests the BSC to make the state change. If the state change request is accepted then the
administrative state change scenario will follow. The interworking procedure for this case is described in
Figure 6.
Page 17
ETS 300 624: August 1996 (GSM 12.22 version 4.1.4)
Table 3: Mapping of the GSM 12.21 Changed State Event Report attributes to the GSM 12.20
stateChange notification
The attributes of the The attributes of the M(andatory)/
GSM 12.21 Changed GSM 12.20/CCITT Rec. O(ptional)
State Event Report X.721 stateChange
notification
1)
sourceIndicator O
1)
attributeIdentifierList O
2)
Operational State stateChangeDefinition M
1)
notificationIdentifier O
1)
correlatedNotifications O
1)
additionalText O
1)
add
...