The valid Management-application-layer-protocols for 3GPP are:
CORBA IIOP (see references [8] and [52]);
NETCONF (see reference [118]);
SNMP (see reference [6]);
SOAP (see references [108] and [109]).
The valid Management-application-layer-protocols for bulk and file transfer are:
FTAM (see references [13] - [19]);
ftp (see reference [4]);
tftp (see reference [5]);
sftp (secure ftp).
The valid Management-application-layer-protocol for Home NodeB Management Interface Type 1 and Home eNodeB Management Interface Type 1 is:
TR-069 (see reference [115])
The valid Management-application-layer-protocols for bulk and file transfer for Home NodeB Management Interface Type 1 and Home eNodeB Management Interface Type 1 are defined in TR-069 [115].
QoS Management, from an OAM&P perspective, in 3GPP systems primarily consists of two functional areas: QoS policy provisioning and QoS monitoring. QoS Policy Provisioning is the process of configuring and maintaining selected Network Elements with QoS policies that are created based upon customer SLAs and observed network performance. QoS Monitoring is the process of collecting QoS performance statistics and alarms; this data is then used to generate analysis reports for making changes/upgrades to the network. The detailed relationship between SLA Management and QoS Provisioning and Monitoring is for future study. A conceptual breakdown of QoS Management is shown in Figure D.1.
The following clauses provide descriptions of QoS Provisioning and Monitoring.
It should be noted that the same descriptions could apply to other Policy Management instantiations, e.g. Security and Service Provisioning.
In the 3GPP systems, multiple network domains must inter-work in order to provide the end-to-end quality of service required by end-user applications. To add to this complexity, there are many classes of Network Elements from many network infrastructure suppliers, each of which require configuration in a consistent manner in order to the network operator's QoS objectives. Within each Network Element, there are many QoS functions (such as Admission Control, Policers, Shapers, Queue Manager and Scheduler), which must be configured.
In order to configure these heterogeneous networks so that they can deliver the desired QoS, the operator needs a management solution that meets the following high-level requirements:
Automation of management tasks.
Centralized management with fewer classes of management interface.
Abstracted (or simplified) management data.
End-to-End provisioning of the network.
Consistent and uniform provisioning across all Network Elements.
Standards-based solution in order to allow inter-operability at Network Element and OSS level.
Scalable solution for large networks.
The IETF Policy Management Framework has been designed with these requirements in mind
The various standards that apply to QoS Policy Provisioning as described in the following clauses are listed in D.4.1. At time of publication of the present document there are also a significant amount of IETF Drafts available on the subject at http://www.ietf.org,
The architectural components identified in Figure D.2 are described in the following clauses.
The Itf N interface is specified in the 32 series.
The Itf Po, between the Policy Repository and the Policy Decision Point is to be defined. The protocols under consideration includes: LDAP, LDUP, SNMP and COPS-PR.
The reference point Go is defined in TS 23.207 (see D.4 QoS Management Reference [22]) and the interface implementing the reference point is defined in TS 29.207 (see D.4 QoS Management Reference [23]).
This is a network-level operational support function that serves as the policy administration point for the entire network.
The NML QoS Policy Provisioning provides the following functions:
Network policy administration user interface
Master network policy repository for storage of all network policies for all domains
Policy distribution capability to distribute policy data to the EML Policy servers.
Global policy conflict detection
The policy repositories will use an LDAP-based directory to store the policy information.
This is an element management function that serves as the policy administration point for a network domain. A domain is an area of the network that contains equipment that performs a logically related function. Examples of network domains are: access network, core network and transport network, or supplier specific sub-networks within these networks.
The EML QoS Policy Provisioning provides the following functions:
An optional EML-level policy administration user interface.
EML-specific policy repository.
Policy distribution capability to distribute policy data to the Policy Decision Points.
Local policy conflict detection
It is envisioned that the optional EML-level policy administration user interface will be required in small networks that do not have a network-level policy provisioning OSS.
Note that EML-specific policy repositories contain policies that apply only to that domain as well as general network policies that apply across domains.
The Policy Decision Point is the point in the network at which policy decisions are made for the Policy Enforcement Points under its scope of control. Whereas the Policy Enforcement Point is a function within a network node, the Policy Decision Point is separate functional entity that may reside within a separate Policy Server, for example, on an application server. The Policy Decision Point will make decisions based on the policy information held within the Policy Repository.
The Policy Decision Point provides the following functions:
Retrieval of Policy Information from the policy repository
Evaluates the policy information retrieved and decides what actions needs to taken.
Distributes policy data to the Policy Enforcement Points. This distribution can either be sent to the PEP by the Policy Decision Point or the Policy Decision Point can wait for the PEP to request the information.
Translation from QoS policy schema employed by the policy servers to Policy Information Base (PIB) format employed by the Policy Enforcement Points.
The optional real-time policy decision-making function may be required when dynamic policy decisions must be made in response to current network conditions.
TS 23.207 describes the End-to-end Quality of Service (QoS) concept and architecture, and TS 29.207 describes Policy control over Go interface (see D.4 QoS Management Reference [22]) and TS 29.207 (see D.4 QoS Management Reference [23]). If there are any inconsistencies then the definitions in 23.207 [] and 29.207 [] take precedence.
The Policy Enforcement Point is a function that is part of a Network Element that must implement the policies defined by the policy administration system(s).
The Policy Enforcement Point provides the following functions:
Storage of policy-related data locally.
Execution of policies as network conditions dictate.
Support for the Differentiated Services QoS mechanism (diffserv).
On initialization, the Policy Enforcement Point will contact its parent Policy Decision Point and request download of any policy data that it requires for operation. Note that information such as the address of the parent Policy Decision Point function must be provisioned in the Policy Enforcement Point MIB as part of normal network provisioning.
TS 23.207 describes the End-to-end Quality of Service (QoS) concept and architecture, and TS 29.207 describes Policy control over Go interface (see D.4 QoS Management Reference [22]) and TS 29.207 (see D.4 QoS Management Reference [23]). If there are any inconsistencies then the definitions in 23.207 [] and 29.207 [] take precedence.
QoS Monitoring in 3GPP systems consists of collecting/processing performance statistics, usage data and QoS related faults. In order to obtain end-to-end quality of service monitoring, the Network Elements, the Element Management Layer and Network Management Layer must all be involved with the QoS Monitoring process. Alarm and performance collection is done at the Network Element layer and alarm/performance aggregation, report generation, and analysis is done at the Element Management and Network Management layers.
The following functions summarize the QoS Monitoring process:
Manage QoS fault conditions received from Network Elements.
Retrieve QoS Performance data from Network Elements.
Collect and process usage data.
Generate QoS Reports - trend analysis of key QoS parameters.
Audit/Analyse collected QoS parameters against expected values.
References that apply to QoS Monitoring and the following clauses are listed in clause D.4.2.
The Network Element component is responsible for collecting performance measurements, usage data and generating alarms. The Network Element component can contain the Policy Enforcement Point or the Policy Decision Point functions.
The Network Element component provides the following functions:
Collect performance data according to the definition of the measurements and to return results to the EML.
Collect usage data and forward the data to mediation
Perform the following fault management functions: Fault detection, Generation of alarms, Clearing of alarms, Alarm forwarding and filtering, Storage and retrieval of alarms in/from the NE, Fault recovery, Configuration of alarms.
The Element Management Layer is responsible for aggregating and transferring the collected performance measurements and generated alarms/events.
The Element Management Layer provides the following functions:
Performance Management
Measurement data collection
Measurement types. Corresponds to the measurements as defined in TS 52.402, TS 32.405, TS 32.406, TS 32.407, TS 32.408 and TS 32.409 (see clause D.4 of the present document on QoS Management Reference),
i.e. measurement types specified in the present document, defined by other standards bodies, or manufacturer defined measurement types;
Measured network resources. The resource(s) to which the measurement types shall be applied have to be specified
Measurement recording, consisting of periods of time at which the NE is collecting (that is, making available in the NE) measurement data.
Measurement reporting
Measurement Report File Format Definition
The measurement related information to be reported has to be specified as part of the measurement. The frequency at which scheduled result reports shall be generated has to be defined.
Measurement result transfer
Measurement results can be transferred from the NE to the EM according to the measurement parameters, and/or they are stored locally in the NE and can be retrieved when required;
Measurement results can be stored in the network (NEs or EM) for retrieval by the NM when required.
Fault Management
Management of alarm event reports
Mapping of alarm and related state change event reports
Real-time forwarding of event reports
Alarm clearing
Retrieval of alarm information
Retrieval of current alarm information on NM request
Logging and retrieval of alarm history information on NM request
From a QoS Monitoring perspective, the NML is responsible for the collection and processing of performance, fault, and usage data.
The NML QoS Monitoring layer provides the following functions:
Service Quality Management: responsible for the overall quality of a service as it interacts with other functional areas to access monitored information, process that information to determine quality metrics, and initiate corrective action when quality level is considered unsatisfactory. Inputs to SQM include both performance and fault data.
Customer QoS Management: includes monitoring, managing, and reporting the Quality of Service customers receive against what has been promised to the customer in Service Level Agreements and any other service related documents. Inputs to CQM include data from SQM and usage data.
RFC 2940: "Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients" ,. A. Smith, D. Partain, J. Seligson. October 2000. http://www.ietf.org/rfc/rfc2940.txt
RFC 3084: "COPS Usage for Policy Provisioning (COPS-PR)"; K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. March 2001. http://www.ietf.org/rfc/rfc3084.txt
RFC 2748: "The COPS (Common Open Policy Service) Protocol", J. Boyle, R.Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry. January 2000, http://www.ietf.org/rfc/rfc2748.txt
RFC 1901: "Simple Network Management Protocol, v2", J.Case, K. McCloghrie, M. Rose, S. Waldbusser. January 1996. http://www.ietf.org/rfc/rfc1901.txt?number=1901
RFC 1907: "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", SNMPv2 Working Group, J. Case, K.McCloghrie, M. Rose, S. Waldbusser. January 1996. http://www.ietf.org/rfc/rfc1907.txt?number=1907
TelemanagementForum (TMF) TOM Application Note, Mobile Services: Performance Management and Mobile Network Fraud and Roaming Agreement Management, GB910B, Public Evaluation Version 1.1, September 2000. http://www.tmforum.org/
The 3GPP management detailed specification has defined protocols and information model (network resource model) for use across Itf-N, i.e. the Type 2 management interface. Some, not all, of these protocols and network resource model are applicable for use across the Itf-P2P, i.e. theType 4a management interface.
The following lists identify the Itf-N protocols and information model relevant for use across Itf-P2P. When certain part of a specific Interface IRP specification (e.g. a particular operation) is not applicable for Itf-P2P, that certain part shall be identified as Exception here.
List of Interface IRP :
[Names of Interface IRP, with possible Exception (see above), are included here. These are to be determined.]
List of NRM IRP :
[Names of NRM IRP included here. The names are to be determined.]
A particular NRM IRP may have defined IOCs that are visible across the Itf-P2P but not visible across Itf-N. In such case, a note "This IOC is visible across Itf-P2P only." should be part of the subject IOC description.
The standard does not specify which NRM IRP or which IOCs would be invisible across Itf-P2P. That "invisibility" is determined by the two involved peer DMs and is outside the scope of standardization.
At present, the standard does not expect the need to define NRM IRP(s) that are exclusively used by Itf-P2P. In the possible event that the need is required, the standard will specify a convention how to document those NRM IRP(s).