ETSI TS 102 672 V1.1.1 (2009-11)

Technical Specification
Satellite Earth Stations and Systems (SES);
Broadband Satellite Multimedia (BSM);
Management Functional Architecture

2 ETSI TS 102 672 V1.1.1 (2009-11)

Reference
DTS/SES-00289
Keywords
architecture, broadband, management,
multimedia, satellite
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2009.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 672 V1.1.1 (2009-11)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 10
4 Overview and Background . 12
4.1 Existing Solutions and Standards . 12
4.2 Availability of NMS/OSS solutions . 13
5 BSM network management functional requirements . 14
5.1 Management Functions . 14
5.2 Management logical layered model . 14
5.3 Management Plane . 16
5.4 Security . 16
5.5 BSM Recommendations . 16
6 BSM Network Management Scenarios . 16
6.1 Management Relationships between BSM Network Actors . 17
6.2 Scenarios of relationships between network actors . 18
6.3 Global Network Management Architecture. 20
6.4 BSM Service Management Scenarios . 20
6.4.1 Residential Internet Access Scenario . 20
6.4.2 Enterprise Office-LAN Interconnect Scenario A . 21
6.4.3 LAN Interconnect Scenario B . 22
7 BSM Management Architecture . 23
7.1 BSM Management Architecture Fundamentals . 23
7.2 BSM Management Functional Architecture . 24
7.2.1 Internal Interfaces . 26
7.2.2 External Interface . 26
7.2.3 Evolution to Web-based Network Management Architectures . 27
7.2.3.1 Browser-Based Management of SNMP-based BSM . 27
7.2.3.2 Browser-Based Management with modified SNMP Elements . 27
7.2.3.3 Multiple http/IP/SNMP management protocols . 28
7.3 BSM Management Data Models . 29
7.3.1 Data Model Structure . 29
Annex A (informative): Overview of Existing Network Management Architectures . 30
A.1 Overview . . 30
A.1.1 Network Management Architecture Classification . 30
A.1.2 Data Model . 30
A.1.3 Organisational Model . 31
A.2 SNMP (IETF) . 31
A.2.1 SNMP Versions . 32
A.2.2 SNMP architecture . 32
A.2.3 MIBs . 33
A.2.3.1 DVB-RCS . 34
A.2.3.2 MIB Views. 35
ETSI
4 ETSI TS 102 672 V1.1.1 (2009-11)
A.2.3.3 SNMP Traps/Notifications . 35
A.2.3.4 RMON . 36
A.3 TMN (ITU) . 37
A.3.1 FCAPS Model . 37
A.3.2 CMIP (ISO) . 37
A.3.3 NGN Network Management. 38
A.4 NGOSS, OSS/J and TOM/eTOM (TMF) . 38
A.4.1 OSS/J . 38
A.4.2 TOM . 39
A.4.3 eTOM business process framework . 39
A.5 CORBA and OMA (OMG) . 41
A.6 CIM and WBEM (DMTF) . 41
A.7 TISPAN (ETSI) . 41
A.8 Java/RMI . 42
History . 44

ETSI
5 ETSI TS 102 672 V1.1.1 (2009-11)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and
Systems (SES).
Introduction
The focus of the present document is on the functional architecture of network management for BSM systems,
including the management of IP-based services.
Network Management of IP-based broadband satellite multimedia (BSM) systems may be chosen to be similar in many
ways to that of terrestrial networks. However there are important differences in emphasis, for example in that the
management traffic overhead across a satellite system should be minimised. Also the scalability of satellite networks
interconnecting potential many terminals must be considered. Furthermore, integrated management of satellite and
terrestrial IP networks has not been widely implemented and a standardised approach is considered desirable.
The BSM network management system (BNMS) should also be designed to cope with the latency and bandwidth
asymmetry that are characteristic of satellite links. However the timescale of management operations is usually of an
order that does not impose tight time constraints or high data rates.
ETSI
6 ETSI TS 102 672 V1.1.1 (2009-11)
1 Scope
The present document defines an open specification dealing with scenarios and functional network architectures for the
management plane (M-plane) of Broadband Satellite Multimedia (BSM) systems, including any potential interfaces
with external or higher level network management functions. The BSM management functions should include, for
example, performance management, security management and QoS management, including the associated management
functions of Service Level Agreements (SLAs) and Policies.
The BSM management functional architecture will take into account requirements for emerging IP-centric (Internet
Protocol) broadband multi-service satellite-based networks, integrated with fixed and wireless (broadband) access
networks on one side, and backbone networks on the other. This internetworking and service interoperability scenario is
generally within the scope of Next Generation Networks.
The boundaries of the BNMS will be defined as well as the interfaces, protocols and message types on the internal and
external interfaces. The specification will include, where appropriate, the BSM SI-SAP protocol stack interface
including its interactions with higher and lower layers.
The architecture specified will be concerned mainly with the lower layers of the management functional layers,
particularly the service management, network layer management and network element management, which will allow
maximum flexibility for compatibility and mediation with OSS equipment as well as for Operators in building
functionality as they see fit.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] IETF RFC 1213: "Management Information Base for Network Management of TCP/IP-based
internets: MIB-II".
[2] IETF RFC 1445: "Administrative Model for version 2 of the Simple Network Management
Protocol (SNMPv2)".
[3] IETF RFC 2578: "Structure of Management Information Version 2 (SMIv2)".
ETSI
7 ETSI TS 102 672 V1.1.1 (2009-11)
[4] IETF RFC 3411: "An Architecture for Describing SNMP Management Frameworks".
[5] ITU-T Recommendation M.3010: "Principles for a telecommunications management network".
[6] ITU-T Recommendation M.3400: "TMN management functions".
2.2 Informative references
The following referenced documents are not essential to the use of the ETSI deliverable but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1] ETSI TR 101 984: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Services and architectures".
[i.2] ETSI TS 102 429-4: "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia
(BSM); Regenerative Satellite Mesh - B (RSM-B); DVB-S/DVB-RCS family for regenerative
satellites; Part 4 : Specific Management Information Base".
[i.3] ETSI TS 188 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Management; Operations Support Systems Architecture".
[i.4] "Web-based Management of IP Networks and Systems". J-P Martin-Flatin, Wiley.
[i.5] "On the Evolution of Management Approaches, Frameworks and Protocols: A Historical
Perspective". George Pavlou, J. Netw Syst Manage (2007) 15:425-445, Springer
Science+Business Media, LLC 2007.
[i.6] IETF RFC 1155: "Structure and Identification of Management Information for TCP/IP-based
internets".
[i.7] IETF RFC 1156: "Management information base for network management of TCP/IP-based
internets".
[i.8] IETF RFC 1157: "Simple Network Management Protocol".
[i.9] IETF RFC 1451: "Manager-To-Manager MIB".
[i.10] IETF RFC 1901: "Introduction to Community-based SNMPv2".
[i.11] IETF RFC 1902: "Structure of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)".
[i.12] IETF RFC 2741: "Agent Extensibility (AgentX) Protocol Version 1".
[i.13] IETF RFC 3415: "View-based Access Control Model".
[i.14] IETF RFC 3418: "Management Information Base (MIB) for the Simple Network Management
Protocol (SNMP)".
[i.15] IETF RFC 3444: "On the Difference between Information Models and Data Models".
[i.16] IETF RFC 3584: "Coexistence between Version 1, Version 2, and Version 3 of the
Internet-standard Network Management Framework".
[i.17] IETF RFC 4741: "NETCONF Configuration Protocol".
[i.18] ETSI TR 101 790: "Digital Video Broadcasting (DVB); Interaction channel for Satellite
Distribution Systems; Guidelines for the use of EN 301 790".
[i.19] draft-combes-ipdvb-mib-rcs-05.txt: "DVB-RCS MIB".
ETSI
8 ETSI TS 102 672 V1.1.1 (2009-11)
[i.20] SatLabs System Recommendations Part 3:"Management & Control Planes Specifications v2".
[i.21] ITU-T Recommendation M.3000: "Overview of TMN Recommendations".
[i.22] ITU-T Recommendation M.3050.0: "Enhanced Telecom Operations Map - Introduction".
[i.23] ITU-T Recommendation M.3060: "Principles for the Management of the Next Generation
Networks".
[i.24] ITU-T Recommendation X.901-X.904: "Reference Model of Open Distributed Processing:
Overview".
[i.25] TeleManagement Forum TMF 053: "NGOSS Technology Neutral Architecture".
[i.26] Telemanagement Forum document number GB921: "eTOM, The Business Process Framework for
the Information and Communications Services Industry".
[i.27] ISO/IEC 9595: "Information technology - Open Systems Interconnection - Common management
information service definition".
[i.28] ISO/IEC 9596-1: "Information technology - Open Systems Interconnection - Common
management information protocol".
[i.29] Distributed Management Task Force: "Common Information Model (CIM) Infrastructure
Specification, DSP0004".
[i.30] The Object Management Group (OMG): "MDA Specifications".
NOTE: See http://www.omg.org/mda/specs.htm
[i.31] ITU-T Recommendation Y.2001: "General overview of NGN".
[i.32] IETF RFC 4022: "Management Information Base for the Transmission Control Protocol (TCP)".
[i.33] IETF RFC 4113: "Management Information Base for the User Datagram Protocol (UDP)".
[i.34] IETF RFC 4293: "Management Information Base for the Internet Protocol (IP)".
[i.35] IETF RFC 2863: "The Interfaces Group MIB".
[i.36] IETF RFC 4133: "Entity MIB (Version 3)".
[i.37] IETF RFC 4268: "Entity State MIB".
[i.38] IETF RFC 3877: "Alarm Management Information Base (MIB)".
[i.39] IETF RFC 1441: "Introduction to version 2 of the Internet-standard Network Management
Framework".
[i.40] IETF RFC 1452: "Coexistence between version 1 and version 2 of the Internet-standard Network
Management Framework".
ETSI
9 ETSI TS 102 672 V1.1.1 (2009-11)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
agent: entity that acts in a managed role
architecture: abstract representation of a communications system
NOTE: Three complementary types of architecture are defined:
functional architecture: discrete functional elements of the system and the associated logical
interfaces
network architecture: discrete physical (network) elements of the system and the associated
physical interfaces
protocol architecture: protocol stacks involved in the operation of the system and the associated
peering relationships
control plane: layered structure that performs the call control and connection control functions; it deals with the
signalling necessary to set up, supervise and release calls and connections
Customer Premise Network (CPN): customer's private network
NOTE: In the simplest case, the CPN is just a single end-host or TE.
data link layer: second layer of the OSI model it provides connectivity between segments of the network (bridging); in
addition the data link may perform session control and some configuration
data model: description of a specific data structure, with the way the data elements (in the structure) are defined and
the relationship to each other
NOTE: It is normally used in software engineering to describe how data is represented and accessed (see also
RFC 3444 [i.15]).
eTOM: business process model or framework that has the objective of describing and classifying the business
processes required for a Service Provider; it analyses the processes to different levels of detail according to their
significance and priority for the business
NOTE: eTOM uses hierarchical decomposition to structure the business processes according to which all of the
processes of the enterprise are successively decomposed. Process elements are formalized by means of a
name, a description, inputs/outputs, etc.
flow: flow of packets is the traffic associated with a given connection or connectionless stream having the same source
host, destination host, class of service, and session identification
information model: formal representation of real-world objects and concepts, with associated relationships,
constraints, rules, and operations, used to specify semantics in a given domain
NOTE: It includes things of interest (entities), relationships between these entities (associations), and
details/characteristics of these entities (attributes). An information model provides formalism to the
description of a problem domain without constraining how that description is mapped to an actual
implementation in software. The possible mappings of the information model are the data models (see
also RFC 3444 [i.15]).
ETSI
10 ETSI TS 102 672 V1.1.1 (2009-11)
management plane: provides two types of functions, namely layer management and plane management functions:
• plane management functions: performs management functions related to a system as a whole and provides
co-ordination between all the planes. Plane management has no layered structure.
• layer management functions: performs management functions (e.g. meta-signalling) relating to resources
and parameters residing in its protocol entities. Layer Management handles the Operation And Maintenance
(OAM) of information flows specific to the layer concerned.
Management Information Base (MIB): virtual information store containing managed objects
NOTE: Objects in the MIB (identified by their OIDs) are essentially variables, and are typically defined using
Abstract Syntax Notation One format (ASN.1).
Manager: entity that acts in a managing role
Network Control Centre (NCC): equipment that controls the access of terminals at the lower protocol layers (OSI
Layer 2 and below) to a BSM network
Network Management Centre (NMC: equipment that manages the lower protocol layers (OSI Layer 2 and below) of
a BSM network
Network Management System (NMS): equipment that manages a network at several or all protocol layers
Next Generation Network (NGN): (from ITU-T Recommendation Y.2001 [i.31]) packet-based network able to
provide telecommunication services and able to make use of multiple broadband, QoS-enabled transport technologies
and in which service-related functions are independent from underlying transport-related technologies
NOTE: It offers unrestricted access by users to different service providers. It enables unfettered access for users
to networks and to competing service providers and/or services of their choice. It supports generalized
mobility which will allow consistent and ubiquitous provision of services to users.
Next Generation Operations Support System (NGOSS): Telecommunications Management Forum's (TMF's) core
framework for developing, procuring and deploying operational and business support systems and software
NOTE: The term is also used elsewhere e.g. as the basis for TISPAN OSS standards.
Operations Support System (OSS): generic term for a suite of management functions that enable an enterprise to
monitor, analyse and manage systems, resources and services
Service Level Agreement (SLA) (SP and ANO): SLA between a Service Provider and an Access Network Operator is
usually characterized by a forward link guaranteed capacity for SP aggregated traffic expressed in kb/s and a return link
guaranteed capacity for SP aggregated traffic expressed in kb/s
NOTE: It can also include other elements related to traffic policy and availability.
Service Level Agreement (SLA) (Subscriber and Service Provider): SLA between a SP and its subscriber is
characterised by the choice of one data transfer capability and the allocation attribute related to this transfer capability
NOTE: The SLA is agreed upon by the subscriber at the initiation of the contract with the SP and will remain the
same for all the contract duration.
Service-Oriented Architecture (SOA): (ITU-T) Service-Oriented Architecture (SOA) is a software architecture of
services, policies, practices and frameworks in which components can be reused and repurposed rapidly in order to
achieve shared and new functionality
NOTE: This enables rapid and economical implementation in response to new requirements thus ensuring that
services respond to perceived user needs. SOA uses the object-oriented principle of encapsulation in
which entities are accessible only through interfaces and where those entities are connected by
well-defined interface agreements or contracts.
user: entity that uses the network services requested by the subscriber
user plane: layered structure and provides user information transfer, along with associated controls (e.g. flow control,
recovery from errors, etc.)
ETSI
11 ETSI TS 102 672 V1.1.1 (2009-11)
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Partnership Project
ANO Access Network Operator
API Application Program Interfaces
BNMS BSM Network Management System
BSM Broadband Satellite Multimedia
CIM Common Information Model
CLI Command Line Interface
CMIP Common Management Information Protocol
CMIS Common Management Information Service
CORBA Common Object Request Broker Architecture
COTS Commercial Off The Shelf
CPE Customer Premise Equipment
CPN Customer Premise Network
DEN Directory Enabled Networks
DMTF Distributed Management Task Force
DTD Document Type Definition
eTOM enhanced Telecom Operations Map
FAB Fulfilment, Assurance and Billing
FCAPS Fault, Configuration, Accounting, Performance and Security
HTTP HyperText Transfer Protocol
IDL Interface Definition Language
IETF Internet Engineering Task Force
IP Internet Protocol
ISO International Organisation for Standardization
ISP Internet Service Provider
ITU International Telecommunications Union
JRMI Java Remote Method Invocation
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
LLA Logical Layered Architecture
MIB Management Information Base
NAP Network Access Providers
NCC Network Control Centre
NGN Next Generation Network
NGOSS Next Generation Operations Support System
NM Network Management
NMC Network Management Centre
NMS Network Management System
NNI Network to Network Interface
NOC Network Operations Centre
OAM Operation And Maintenance
OBP On Board Processing
OID Object Identifier
OMA Object Management Architecture
OMG Object Management Group
OSI Open Standards Interconnection
OSS Operations Support System
OSS/J OSS through Java initiative
QID Queue IDentifier
QoS Quality of Service
RFC Request For Comments
RMI Remote Method Invocation
RM-ODP Reference Model of Open Distributed Processing
RMON Remote Monitoring
RSVP Resource ReserVation Protocol
SD Satellite Dependent
SI Satellite Independent
ETSI
12 ETSI TS 102 672 V1.1.1 (2009-11)
SI-SAP Satellite Independent-Service Access Point
SLA Service Level Agreement
SMI Structure of Management Information
SMIv2 Structure of Management Information version 2
SNMP Simple Network Management Protocol
SNO Satellite Network Operators
SO Satellite Operator
SOA Service-Oriented Architecture
SP Service Provider
ST Satellite Terminal
TCP Transmission Control Protocol
TMF Telecommunications Management Forum
TMN Telecommunications Management Network
TOM Telecom Operations Map
TR Technical Report
TS Technical Specification
UDP User Datagram Protocol
UML Universal Modelling Language
WBEM Web-Based Enterprise Management
XML eXtensible Markup Language
4 Overview and Background
Network Management should be seen as a means of enabling operators to configure their networks easily, quickly and
cost-effectively, in order to provide users with flexible and efficient services which can be adapted to their needs in the
latest service environments (e.g. compatible with a Service-Oriented Architecture (SOA)). This should include fast
addition and deletion of users, monitoring and management of QoS, network topology management, fault diagnosis and
billing.
Network Management is taken to mean all layers of the management stack, from element layer at the bottom to business
layer at the top, whether the network being managed is a sub network or a complete end-to-end network. This is distinct
from the network layer protocol (in the user and control plane) which is concerned with end-to-end communications.
Operational Support Systems (OSS) is the term usually given to the suite of management application functions that
provide the manager with high level support and control interface to lower level management data from network
elements. In practice an OSS is often a complex and heterogeneous assembly of equipment and implementations due to
the number of functions they must support, and due to their potential incremental historical implementation and
organisation in hardware and software, owing to legacy and business constraints.
There is a range of alternative potential NM standards and solutions as described in annex B. The choice of approach
depends on for example:
• cost -effectiveness;
• flexibility (scalability, ease of update, modularity for additional functions);
• reliability (redundancy, reconfigurability);
• security;
• transmission bandwidth;
• legacy entity compatibility.
The present document focuses on the network management system outside the OSS and is concerned with extraction
and configuration of management data.
ETSI
13 ETSI TS 102 672 V1.1.1 (2009-11)
4.1 Existing Solutions and Standards
State There is a range of potential solutions for BSM network management architecture (e.g. centralised or distributed)
which offer different advantages and disadvantages. In addition, the type of management information representation
and communication protocol often dictates a type of architecture; SNMP is probably the best known of these protocols
and it imposes a centralised architecture and certain other constraints such as the need for polling of MIBs, which
results in repetition of retrieved data even if no changes in MIB data have occurred.
However Web-based network management is one alternative which is becoming more common as owing its lower cost
and technical advantages. A common arrangement is to use SNMP for fault event management (such as alarms) and
use XML for configuration, performance, security and accounting functions.
In the world of telecommunications networking there are currently several approaches to defining and standardising
network management architectures.
The main technological approaches that have been, or are being, standardised are:
1) The SNMP architecture defined by the RFC 3411 [4].
2) The TMN (Telecommunications Management Network) [i.21] defined by the ITU and ISO, and based on the
CMIP protocol and CMIS architecture.
3) The NGOSS (Next Generation Operations Support System) [i.24] OSS/J (OSS through Java Initiative) and
enhanced Telecom Operations Map (eTOM) defined by the Telecommunications Management Forum (TMF).
4) The Object Management Architecture (OMA) based on CORBA from the Object Management Group (OMG).
5) COPS-PR (IETF) for configuration (e.g. as a complement to SNMP).
6) The Common Information Model (CIM) [i.29] and Web-Based Enterprise Management (WBEM) defined by
the Distributed Management Task Force (DMTF).
7) The NGN Operations Support Systems Architecture defined by ETSI TISPAN [i.3].
Other initiatives include, for example, Java/RMI from Sun, the Model-Driven Architecture (MDA) as a development of
the OMA [i.30], and several web-based designs using Java.
An overview of the main approaches is given in Annex A. In spite of the efforts over recent years in defining the above
approaches, there is still no universally accepted solution for all aspects of network management, but typically a
collection of separate complementary solutions are employed depending on their strengths (e.g. SNMP for network
monitoring, NETCONF [i.17] for configuration, and vendor-specific solutions for large-scale network monitoring
e.g. traffic engineering and data collection.
The approach to BSM management should take into account as many of the above approaches as possible, focussing on
those in use today and on the most likely candidates for the future.
Of the above approaches, SNMP is widely adopted, but mainly for relatively simple tasks, like Fault Management and
read-only type operations, e.g. to obtain the current configuration and to retrieve performance data. Although designed
for IP networks, SNMP has many disadvantages in today's OSS environments, such as that it:
• does not scale well due to reliance on polling, which generates redundant traffic even in the absence of faults
or alarms;
• has a limited instruction set and is not suited to management above element layer;
• is not object-orientated and does not suit distributed managers and agents;
• uses UDP, the unreliability of which is a factor especially for network configuration;
• has security mechanisms that are only available if SNMPv3 is implemented.
The TMN/CMIP manager-agent protocol paradigm has proven too complicated and expensive for most applications
(even if the overall TMN requirements e.g. FCAPS are still valid).
ETSI
14 ETSI TS 102 672 V1.1.1 (2009-11)
The Web-Based Enterprise Management (WBEM) standard has not yet "taken off" even if the CIM is implemented on
Windows platforms (amongst others). The enterprise management frameworks seem to be too expensive, complex to
implement and the return-on-investment is not proven.
The TMF's efforts on NGOSS seem promising. The next steps are to agree on the "Shared Information Model" and to
implement a process engine.
The trend today is towards use of http to allow OSS servers and clients to communicate in order to support distributed
services that also use the Web. This represents convergence in that both the services and their OSS are tending to use
distributed software components that communicate using the Web.
4.2 Availability of NMS/OSS solutions
There are commercial and freeware (including open source) network management systems (e.g. Xymon [previously
hobbit], OpenNMS, zenoss, Nagios.) available which usually employ the term OSS for these products. However while
vendors claim to offer complete OSS solutions, they are often adapted for a specific type of operator and aim at an
off-the-shelf solution to suit a particular need. Therefore, such a readily available OSS may pose a number of
disadvantages:
• Single-vendor OSS's often have unique implementations and do not perform all required tasks equally well.
• Multi-vendor support i.e. the freedom to select network equipment from other supplier may be restricted.
• Flexibility for future adaptation to services and networks is not always adequate.
A general definition of OSS requirements and architecture is considered necessary in order to provide a sound basis for
a BSM operator to define his overall requirements.
5 BSM network management functional requirements
This clause clarifies the functions required for the overall management process.
The overall requirements of NMS's for terrestrial networks (see clause 5.2) are generally applicable to satellite
networks.
However, satellite networks have some specific constraints compared with terrestrial networks, for example:
• the management traffic overhead across a satellite system should be minimised;
• the scalability of satellite networks interconnecting potentially many terminals must be considered;
• Latency and possible bandwidth asymmetry.
The first of these constraints is justified by the valuable satellite resources and thus the need to reduce management
overhead. A protocol such as SNMP is not bandwidth-efficient since the manager relies on regular polling (pull model)
of remote network elements (e.g. BSM STs) to obtain management status information, and this generates repeated data
and redundant traffic. Also SNMP data is not compressed. Furthermore as the number of STs may become very large in
a practical network, the SNMP polling of STs generates an increasing amount of traffic which has to be budgeted for in
always-on satellite management channels.
Functions and protocols which generate management messages only when new data is present, and which can compress
data, are therefore preferred. This requires agents to be more intelligent in order to react when necessary and to generate
adapted messages (i.e. push model). SNMP Traps are an example of such messages.
ETSI
15 ETSI TS 102 672 V1.1.1 (2009-11)
5.1 Management Functions
The overall management requirements adopted by NMS's and OSS's today fall into the following main categories:
• FCAPS defined for the TMN by the ITU [6].
• The TOM from the TMF, which is a development of FCAPS.
• The eTOM from the TMF in which FCAPS has been re-classified as Operations Support, Fulfilment,
Assurance and Billing.
Annex A describes these models in more detail.
The FCAPS Model has been defined for DVB-RCS systems by Satlabs in [i.20].
5.2 Management logical layered model
The concept of hierarchical 'horizontal' logical layers in TMN [5] is usually shown in the pyramid form of figure 1. The
Logical Layered Architecture (LLA) structures the management functions and describes the relationships between
layers. A logical layer reflects particular aspects of management arranged by different levels of abstraction.
Business
OSS
Service management
Network management
F    C    A     P     S
BNMS
F    C    A     P     S
Network element management
F     C      A     P       S
Network elements
F        C      A      P       S

Figure 1: TMN NM Logical Layered Architecture (LLA) showing BSM-specific layers
The eTOM model retains this concept of layering and develops it further in [i.22].
As indicated in figure 1 the BSM Network Management System (BNMS) described herein is concerned with part of
service management and the layers below. The service layer may be split into BSM-service-related functions and
end-to-end network service functions. Higher layers are considered to be more generic and not specific to the BSM.
These layers may be provided by readily available and configurable off-the-shelf software management
systems (OSSs), as far as the BSM system is concerned.
In this model each layer is dependent on the services provided by the underlying layer.
At the lowest level, the BSM physical network is clearly a set of network elements (satellite terminals, hub stations,
gateways, routers, servers, etc) as represented in the lowest level of figure 1, each of which should monitor its own fault
status (F), be capable of reconfiguration (C), hold local user accounting data (ISP number, user account number) (A),
report performance data (P) and possess password and link encryption data (S). Otherwise functions at this level have
minimal management plane involvement in that they react to or control real time events, and are mainly involved in
Control Plane or User Plane functions. For example, call management in a telecommunications switch would be
performed at this level, where the switch would route a call in response to signalling.
ETSI
16 ETSI TS 102 672 V1.1.1 (2009-11)
Above this is the Network Element Management (device management) layer which manages the communications
path. At this layer (containing the management functions required to operate single pieces of equipment), the BSM
should be capable of autonomous reconfiguration in response to a number of fault states (F and C). It should be capable
of responding to performance requirements, for example, uplink power control (P). In the case of Accounting, it should
be capable of holding several user accounts per multi-user terminal.
The next higher layer is the Network Management layer, co
...