o&m Communication Protocols

O&M Communications Protocols

DN987681 Issue 6-1


The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation. The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document. Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT. This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws. The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG. Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only. Copyright Nokia Siemens Networks 2010/11/16. All rights reserved

f

Important Notice on Product SafetyElevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures. Non-observance of these conditions and the safety instructions can result in personal injury or in property damage. Therefore, only trained and qualified personnel may install and maintain the system. The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German: Wichtiger Hinweis zur Produktsicherheit In elektrischen Anlagen stehen zwangslufig bestimmte Teile der Gerte unter Spannung. Einige Teile knnen auch eine hohe Betriebstemperatur aufweisen. Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Krperverletzungen und Sachschden fhren. Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet. Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Gerte mssen die zutreffenden Sicherheitsbestimmungen erfllen.

2

DN987681 Issue 6-1


Table of ContentsThis document has 39 pages. Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1 1.1 1.2 2 2.1 2.2 3 3.1 3.2 4 4.1 4.2 4.3 4.4 4.5 5 5.1 6 7 7.1 7.2 O&M communication protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Functional subclasses of O&M communication protocols . . . . . . . . . . . . 8 MML commands in O&M communication protocols. . . . . . . . . . . . . . . . . 9 Connection-oriented network services. . . . . . . . . . . . . . . . . . . . . . . . . . 10 Connection-oriented network service parameters . . . . . . . . . . . . . . . . . 11 Implementation of connection-oriented network services . . . . . . . . . . . 14 Connectionless network services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Restrictions of connectionless network services . . . . . . . . . . . . . . . . . . 17 Implementation of connectionless network services . . . . . . . . . . . . . . . 17 File transfer and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Session layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presentation layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ACSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementation of file transfer and management. . . . . . . . . . . . . . . . . . 21 23 23 24 25 25

Transaction services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Implementation of transaction services . . . . . . . . . . . . . . . . . . . . . . . . . 30 Asynchronous data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 OSI statistics services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 OSI counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Implementation of OSI statistics services . . . . . . . . . . . . . . . . . . . . . . . 38

DN987681 Issue 6-1

Id:0900d80580570366

3


List of FiguresFigure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 The OSI protocol stack of the DX 200 system . . . . . . . . . . . . . . . . . . . . . 7 Configurable parameters of X.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Program blocks which take part in realizing network services . . . . . . . . 15 Overview to OSI/LAN interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Program blocks implementing a connectionless network service . . . . . . 18 Program blocks which take part in realizing FTAM initiator . . . . . . . . . . 26 Program blocks which take part in realizing FTAM responder . . . . . . . . 27 Program blocks which take part in realizing CMISE . . . . . . . . . . . . . . . . 31 Parameters used by the PAD host function . . . . . . . . . . . . . . . . . . . . . . 33 Environment of the VTERMD as an MML terminal . . . . . . . . . . . . . . . . . 34 Environment of the VTERMD as an output device . . . . . . . . . . . . . . . . . 35 Program blocks which take part in realizing OSI statistics . . . . . . . . . . . 39

4

Id:0900d80580570366

DN987681 Issue 6-1


Summary of changes

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues. Changes made between issues 61 and 60 Editorial corrections. Changes made between issues 60 and 53 No content changes. The sections have been restructured.

DN987681 Issue 6-1

Id:0900d805803e421e

5

O&M communication protocols


1 O&M communication protocolsCommunication between different network elements and the operations systems (operation and maintenance centre or network management centre) is required for operation, maintenance, and administration. The network elements can be, for example: switching centres transmission equipment IN nodes base station systems

The communication is necessary to report alarms, to start tests, to update data base information, to display statistics, and so on. Standardization bodies (ISO, ITU-T, ETSI, and so on) have chosen the seven layer ISO OSI protocol model to be used for network management interfaces. However, in some cases only the three lowest layers are required. For the lower level protocols (layers 1, 2 and 3, also called subnetwork), X.25 or CLNS is used. The following protocols are used for the upper layers (layers above 3): Transport layer: ITU-T Rec. X.214 and X.224. Session layer: ITU-T Rec. X.215 and X.225. Presentation layer: ITU-T Rec. X.216 and X.226. Application layer: Association Control Service Element (ACSE): ITU-T Rec. X.217 and X.227. Remote Operations Service Element (ROSE): ITU-T Rec. X.219 and X.229. Common Management Information Service Element (CMISE): ISO 9595 and ISO 9596. File Transfer, Access and Management (FTAM): ISO 8571. The OSI protocol stack is mainly to be used by application software. Application programming interfaces are available for the use of FTAM and CMISE. Applications can copy files with FTAM, and transfer network management-related information with CMISE. FTAM can also be used via MML commands. Application programming interface is also available directly for the use of X.25, that is, the applications can transfer data via X.25 without using the upper layers. Remote terminal sessions and data transmission (printer output, for example) are possible via the Packet Assembly/Disassembly (PAD) facility. PAD is defined in ITUT Recs. X.3 and X.29. PAD uses the X.25 protocol without OSI upper layers. MML sessions can be established from remote computers to the DX 200 system via PAD. Any printer or magnetic tape output data from the DX 200 system can be directed to be transferred via PAD facility. g PAD is not considered a part of the OSI protocols or the OSI reference model.

6

Id:0900d805804687e3

DN987681 Issue 6-1



APPLICATION PROGRAMS

F I L E T R A N S F E R

FTAM ISO 8571

MANAGEMENT-SPECIFIC ASE

CMISE ISO 9595, 9596

T R A N S A C T I O N S

V I R T U A L T E R M I N A L

VT ISO 9040, 9041

ACSE X.217,227 ISO 8649, 8650

ROSE X.219,229 ISO 9072

ACSE X.217,227 ISO 8649, 8650

ACSE X.217,227 ISO 8649, 8650

OSI PRESENTATION LAYER

X.216, X.226, ISO 8822, 8823

OSI SESSION LAYER

X.215, X.225, ISO 8326, 8327

APPLICATIONS USING PAD (X.29)

OSI TRANSPORT LAYER

X.214, X.224, ISO 8072, 8073

PAD, X.29

APPLICATIONS USING NETWORK SERVICES

ISO 8878, 8208 CCITT X.25 PLP ISO 7776 CCITT X.25 LAPB PROCEDURES OF INDIVIDUAL TRANSMISS. LINKS V24,V35,X21,G703

ISO 8348/AD1 CLNS ISO 8473 ISO IP IEEE 802.2 LLC1 IEEE 802.3 MAC CSMA/CD PHYS. SIGNALLING INCOMING SUBNETWORK SERVICES

Figure 1

The OSI protocol stack of the DX 200 system

The O&M communications protocols function class provides other function classes with communication capabilities via OSI networks. Currently, the following services are provided: Common Network Management Communications Service (CMISE) File Transfer and Management Service (FTAM) Virtual Terminal (ISO VT) Asynchronous Data Transfer Service (PAD)

DN987681 Issue 6-1

Id:0900d805804687e3

7



Direct interface to connection-oriented network service (X.213/X.25) and to connectionless network service (ISO IP) Performance measurements of operation and maintenance network (OSI Statistics Program Block O7STAT)

Functional class interaction in O&M communication protocols The O&M communications protocols function class uses services of the following function classes: Operating system Man-machine interface I/O system File system services

The functions provided by the function class are available via the message interfaces.

1.1

Functional subclasses of O&M communication protocolsThe services provided by the OSI Protocols service block can be divided into the following subclasses: Connection-oriented network services: Physical layer: X.21, V.35, V.36, V.24, G.703 Link layer: LAPB Network layer: X.25 For more information, see Connection-oriented network services. Connectionless network services: Physical layer: IEEE 802.3 MAC, CSMA/CD Link layer: LLC1 Network layer: ISO IP For more information, see Connectionless network services. File transfer and management services (FTAM) Transport layer Session layer Presentation layer ACSE FTAM initiator FTAM responder For more information, see File transfer and management. Transaction type network management communications services (CMISE) Transport layer Session layer Presentation layer ACSE ROSE CMISE Virtual terminal service (VT): Transport layer Session layer Presentation layer

8

Id:0900d805804687e3

DN987681 Issue 6-1



ACSE VT service element For more information, see Transaction services. Asynchronous data transfer services (PAD) For more information, see Asynchronous data transfer. OSI statistics, performance management service of operation and maintenance network. For more information, see OSI statistics services.

The above services use the management services of the OSI stack which are used by the application processes as well. These services can each be included, either separately or together with one another, in the OSI services of the DX 200 Platform.

1.2

MML commands in O&M communication protocolsThere are MML commands for the management of the OSI protocols. MML commands are divided into the following groups: OSI application data handling physical channel data handling virtual file system management physical channel group data handling OSI address state data handling OSI address data handling physical channel state handling terminal equipment handling

The virtual file system management handling commands also include commands for copying and deleting files with FTAM protocol. In addition to these, there are commands for creating, starting, and stopping OSI measurements for the performance management of the operation and maintenance network (OSI statistics).

DN987681 Issue 6-1

Id:0900d805804687e3

9

Connection-oriented network services


2 Connection-oriented network servicesNetwork services provide OSI connection-oriented network layer services to upper layers or applications according to ITU-T Recommendation X.213. Network services provide communications over Packet Switched Public Data Networks or analogue and digital leased lines. The protocol for the communications is defined in ITU-T Recommendation X.25. Physical layer The following physical interfaces are supported: V.24 (RS-232) V.35 V.36 X.21 G.703

The V.24 interface can be used with bit rates less than 20 Kbits/s. According to the specification the maximum cable length is 17 meters and the maximum bit rate is 19,2 Kbits/s. V.24 interface can be connected to synchronous carrier frequency or base band modems, synchronous data circuit terminating equipment DCE-V (recommendation X.21 bis), or synchronous data terminal equipped with V.24 interface. The V.35 interface is used with higher bit rates than V.24, otherwise their functionality is similar. Nominal bit rate of V.35 is 48 Kbits/s, but in practice bit rates up to 2 Mbits/s are used. Timing and data circuits (five circuits) are two-wire balanced circuits. Other circuits are single-wire circuits with electrical characteristics according to recommendation V.28. The V.35 interface can be connected to modems, synchronous data circuit terminating equipment DCE-V (recommendation X.21 bis) or synchronous data terminal equipped with V.35 interface. The V.36 interface uses differential circuits (apart from circuits 140 and 141) according to recommendation V.11. Compared to the ITU-T recommendation V.36, the implementation has the following differences: Circuits 140 and 141 should be in accordance with the recommendation V.10. Instead, circuits 140 and 141 are realized with V.28 circuits, which have a higher output voltage than V.10 circuits (7,3V and -6,5V in V.28, 6,0V and -6,0V in V.10). The implementation includes circuit 108, which is not included in the recommendation V.36.

The implemented V.36 interface is similar to the V.11 interface of Nokia modem DS60100. The X.21 interface is implemented mechanically and electrically according to the recommendation X.21, but it does not provide functions defined in X.21, that is, it is in accordance with what X.25 defines about the usage of X.21. The G.703 interface is connected to a 64 Kbits/s PCM timeslot, which in turn is connected to an external PCM via the switching matrix (GSW or SWM) and the exchange terminal (ET). Link layer The link layer protocol is LAPB as defined in recommendation X.25.

10

Id:0900d80580324128

DN987681 Issue 6-1



Network layer X.25 packet layer protocol is used as network layer protocol. X.25 can be configured to act in the role of either DTE or DCE. The implementation supports the following optional facilities: Flow control parameter negotiation (X.25 section 6.12) Throughput class negotiation (X.25 section 6.13) Closed user group (X.25 section 6.14.1) Closed user group selection (X.25 section 16.4.6)

The size of user data in the data packets is 128 bytes (can be changed). Larger logical messages can be sent using the More bit mechanism. The implementation supports the use of Q-bit, which is needed for Packet Assembler/Disassembler (PAD). The implementation supports both Switched Virtual Circuits (SVCs) and Permanent Virtual Circuits (PVCs). Network layer services are in accordance with the recommendation X.213. Theoretically, it is possible to define 255 virtual circuits for the packet layer. Virtual circuits can be configured to function as switched virtual circuits (SVC) or as permanent virtual circuits (PVC), depending on the requirements. However, in practice it is not possible to have as many as 255 virtual circuits. The amount of buffer memory available limits the maximum number of virtual circuits. The size of the buffer memory is about 100 Kbytes. At the most, one virtual circuit requires about 4 Kbytes of buffer memory (for example, FTAM); therefore, in practice about 25 heavily loaded virtual circuits can be used.

2.1

Connection-oriented network service parametersConfigurable parameters and their possible values are listed in the following table.

DN987681 Issue 6-1

Id:0900d80580324128

11



Parameter Physical level: Number of controller Type of controller Interface type Timeslot Bit rate Source of clock Link level: L2 window (= counter k) L2 timer T1 L2 timer T2 L2 timer T3 L2 counter N1 L2 counter N2 L2 mode L2 connection mode L2 modulo L2 protocol Packet level: L3 NSAP L3 mode L3 max packet size L3 PVC L3 SVC one way incoming L3 SVC two way L3 SVC one way outgoing L3 send window size L3 receive window size L3 modulo L3 timer T20 L3 timer T21 L3 timer T22 L3 timer T23 L3 reset max L3 clear max

Default

Range of Values

1

1..8 AS7U, AC25S Digital on AS7U V24, V35, V36, X21 on AC25S 1 - 32 on AS7U 64 Kbit/s on AS7U selectable on AC25S Line, internal

7 6 sec (L3 packet max size)*8 10 DTE wait_sabm, sabm_on_cr 8 lapb

1..127 50 ms .. 12 sec

1..255 DTE, DCE wait_sabm, sabm_on_cr poll_sabm 2..128 lapb

DTE 128 0, 0 0, 0 0, 0 0, 0 2 2 8 180 sec 200 sec 180 sec 180 sec 5 5

NSAP-address DTE, DCE (same as L2 mode) 16..4096 1..255, 1..255 1..255, 1..255 1..255, 1..255 1..255, 1..255 1..127 1..127 8, 128 1..4096 1..4096 1..4096 1..4096 1..127 1..127

Figure 2

Configurable parameters of X.25

Parameter descriptions: physical level Number of controller: There can be from 1 to 8 line controlling units (AS7U or AC25S plug-in units) in one computer unit (Data Communication Unit, for example). Type of controller: There are two types of line controllers: AS7U for digital connections and AS25S for analogue connections. Interface type: Type of the physical interface. The AS7U controller uses a time slot of PCM-line. On the AC25S controller the interface type is selected with jumpers on the controller board.

12

Id:0900d80580324128

DN987681 Issue 6-1



Timeslot: When using the AS7U controller, link level frames are transferred in a timeslot of a PCM-connection. Bit rate: When the AC25S controller is used, bit rate can be selected. Source of clock: If the source of the clock signal is line, then the value of the parameters L2 mode and L3 mode must be DTE, and if the source of the clock is internal the value must be DCE. On the AS7U controller this parameter has no meaning. On the AC25S controller the source of the clock is selected with jumpers on the controller board. Parameter descriptions: link level L2 window (= counter k): Specifies the maximum number of frames that can be in transit without acknowledgement. The valid range is 0..7 for modulo 8 numbering, and 0..127 for modulo 128 numbering. See ITU-T Red Book X.25 2.4.8.6. L2 timer T1: Specifies the time limit in which the remote side of the connection must acknowledge the receipt of the frame. If this timer expires the frame will be retransmitted. See ITU-T Red Book X.25 2.4.8.1. L2 timer T2: The amount of time available before the acknowledging frame must be initiated to ensure its receipt in time. T2 is calculated from T1 and cannot be configured from outside. See ITU-T Red Book X.25 2.4.8.2. L2 timer T3: The amount of time that is regarded as an excessively long idle channel state condition. T3 is calculated from T1 and cannot be configured from outside. See ITU-T Red Book X.25 2.4.8.3. L2 counter N1: Maximum number of bits in an I frame. The value of N1 is calculated from the maximum packet size of packet level. See ITU-T Red Book 2.4.8.5. L2 counter N2: Specifies the maximum number of times a frame is retransmitted before the software gives up retransmitting. See ITU-T Red Book 2.4.8.4. L2 mode: Specifies the operating mode of the line. This parameter should be DTE for a line connected to PSN. If a direct line and modem eliminator is used, one side must be configured as a DTE and the other as a DCE. L2 connection mode: Specifies the point when the link level connection is initialized. WAIT_SABM is a passive connection mode, where the software waits SABM from line. POLL_SABM is an active connection mode, where software sends SABM to line immediately after start up. SABM_ON_CR is a mode where the SABM is sent to line when the first packet level connection is requested by user and the link level is not running. L2 modulo: Specifies the frame level numbering modulo used by the N(r) and P(s) values of the frame for ordering purposes. See ITU-T Red Book X.25 2.3.2.2.1. L2 protocol: Specifies the link level communication protocol. In the present version only the LAPB is supported. Parameter descriptions: packet level L3 NSAP: Defines the address (that is, DTE-number) of the connection. L3 mode: Specifies the operating mode of the connection. Must have the same value as the L2 mode. L3 max packet size: Specifies the maximum packet size in bytes. See ITU-T Red Book X.25 4.3.2. L3 PVC: Specifies the logical channel numbers of the permanent virtual circuits. See ITU-T Red Book X.25 Annex A.

DN987681 Issue 6-1

Id:0900d80580324128

13



L3 SVC one way incoming: Specifies the logical channel numbers of the incoming logical switched virtual circuits. See ITU-T Red Book X.25 Annex A. NOT SUPPORTED IN THE PRESENT VERSION. L3 SVC two way: Specifies the logical channel numbers of the two-way switched virtual circuits. L3 SVC one way outgoing: Specifies the logical channel numbers of the incoming logical switched virtual circuits. See ITU-T Red Book X.25 Annex A. NOT SUPPORTED IN THE PRESENT VERSION. L3 send window size: Specifies the maximum number of packets allowed to be transmitted on the line without confirmation. See ITU-T Red Book 4.4.1.2. L3 receive window size: Specifies the maximum number of packets allowed to be received on the line without confirmation. See ITU-T Red Book 4.4.1.2. L3 modulo: Specifies the packet level numbering modulo. See ITU-T Red Book X.25 4.4.1.2. L3 timer T20: Started when PLP issues a RESTART REQUEST. See ITU-T Red Book X.25 Annex D table D-2X/25. L3 timer T21: Started when PLP issues a CALL REQUEST. See ITU-T Red Book X.25 Annex D table D-2/X25. L3 timer T22: Started when PLP issues a RESET REQUEST. See ITU-T Red Book X.25 Annex D table D-2/X25. L3 timer T23: Started when PLP issues a CLEAR REQUEST. See ITU-T Red Book X.25 Annex D table D-2/X25. L3 reset max: Specifies the maximum number of RESET packets that X.25 can transmit before the line is considered to have failed. See ITU-T Red Book X.25 4.4.3.4. L3 clear max: Specifies the maximum number of CLEAR packets that X.25 can transmit before the line is considered to have failed. See ITU-T Red Book X.25 4.1.8. For more information, see O&M communication protocols.

2.2

Implementation of connection-oriented network servicesOSI Services (OO7SEB) The program blocks which take part in realizing network services are presented in Figure, Program blocks which take part in realizing network services. Network services are implemented in a dedicated plug-in unit (preprocessor unit). There are two types of plug-in units, depending on the type of physical interface used. AS7U plug-in unit is used for G.703 interface and AC25S plug-in unit is used for the other physical interfaces (V.24, V.35, V.36, or X.21). However, the software for both plug-in unit types is the same. LABP and X.25 packet layer protocols are implemented using CVOPS development and run-time environment. Both LAPB and X.25 packet layer protocols are realized as virtual tasks in a single CVOPS process, O23LRS. In the main processor side there are two program blocks which transfer data between the main processor of the computer unit and the network services preprocessor unit (AS7U or AC25S). These program blocks also provide message interface for network service users. The Program Block for Writing in Dual Port Memory in DCU/OMU (ONSEND) transfers messages from the main processor to the preprocessor, and the

14

Id:0900d80580324128

DN987681 Issue 6-1



Program Block for Reading from Dual Port Memory in DCU/OMU (ONRECE) does the same to the other direction. The ONSEND and the ONRECE have counterparts in the preprocessor side, the OAWRIT and the OAREAD, respectively. The Implementation of Link and Network Layers (X.25) of OSI Stack (O23LRS) uses services of the OSI Stack Addressing and Routing Program Block (O7AMAN) for address inquiries. The OSI Plug-in Unit Supervision Program Block (ODCMAN) takes care of initialization, supervision, and state administration of AS7U and AC25S plug-in units. The OACMAN is the supervision program block of the AS7U and AC25S plug-in units.OO7SEB

NETWORK SERVICES USER

O7AMAN

ODCMAN

ONSEND

ONRECE

OAWRIT

OAREAD

O23LRS

OACMAN

O1RECE

AC25S or AS7U

physical connection

Figure 3

Program blocks which take part in realizing network services

For more information, see O&M communication protocols.

DN987681 Issue 6-1

Id:0900d80580324128

15

Connectionless network services


3 Connectionless network servicesConnectionless network services are provided according to ISO IP protocol. Interfaces via coaxial, twisted pair, and attachment unit interface are offered. The following picture presents the possibilities of OSI/LAN interfaces: interfaces for OMC and SMSC connections, charging data transfer, and subscriber management. Connectionless LAN interface can be used alone or parallel with connection-oriented X.25 interface.MSC Applications using OSI services

OSI applications CMISE/FTAM

Connectionless network service LAN IF ! to OMC ! OMC LAN IF ! to SMSC ! SMSC LAN IF for ! subscriber ! management AdC LAN I/F for ! Charging Data ! transfer BC

Figure 4

Overview to OSI/LAN interface

The speed of the physical LAN interface is 10 Mb/sec (=1.25 MB/sec). The size of these local networks is anyway limited to a few hundred meters. With commercial router networks it is, however, possible to build long-distance LAN connections. The speed of these links are typically 2 Mb/sec (=250 kB/sec). According to performance tests, the throughput of the connectionless network service is about 150 kB/sec. This indicates that when LAN is used, the subnetwork does not limit the overall capacity of communication services. Compared to a typical X.25 interface (64000 bits/sec. = 7.8 kB/sec), the speed is about 19 times faster. If the connectionless service is located to BDCU unit as X.25, this feature does not have remarkable effects on the processing time of the computer units. With the connectionless service, more intelligent transport layer service (class 4 instead of class 0 used on the top of X.25) must be used, but the effect is insignificant. The second possibility is to locate the connectionless service and the COCEN plug-in units to the same computer units with OSI applications. In this case some extra memory is of course needed, because in these units, there has been no network service software so far. This increases also the load of these computer units, but decreases the load of the BDCU unit. Also the load of the message bus decreases, because data is not transferred via the Message Bus (MB). When the amount of transferred data is very large, for example, the charging information, the latter configuration is more effective.

16

Id:0900d8058041f0b8

DN987681 Issue 6-1



g Note that the BDCU unit is not in use in BSC.

3.1

Restrictions of connectionless network servicesIf you want to install the OSI/LAN interface in the STU or CHU units, at least the MCVRS subrack version must be used; thus the COCEN is available. Via LAN it is not possible to take Packet Assembler/Disassembler (PAD) terminal connections, because PAD uses services of the X.25 network. Anyway, it is possible to have X.25 connections parallel with LAN. This enables the PAD connections and the X.25 can be a spare link between network elements. If the X.25 is not used, VTP, that is, the Virtual Terminal Protocol can be used for terminal sessions. The VTP is an optional feature. There are three choices for a physical interface. The transfer speed of these interfaces is 10 Mbit/s. Each medium has its own limits to the size of the local area network. However, if needed, a network can be extended with bridges, routers, and commercial router networks. AUI (Attachment Unit Interface) The maximum length of AUI-medium (10BASE5) between COCEN plug-in unit and the transceiver is 50 meters. With optical fiber adaptor the maximum length grows to 10002000 meters. COAX (Coaxial interface) The maximum length of coaxial cable (10BASE2) is 185 meters. The total size of a network without bridges and routers reaches about 2500 meters. TPI (Twisted Pair Interface) The maximum length of twisted pair cable is 100 meters. The total size of network without bridges and routers reaches about 500 meters. For more information, see O&M communication protocols.

3.2

Implementation of connectionless network servicesThe following picture presents the parts of software needed in a network element when implementing OSI services via LAN interface. The OSI protocol software is implemented by OO7SEB service block of Basic Computer Services of DX 200 (BCSSYB). The OSI applications, such as CMISE and FTAM, must be located in the same computer unit as the applications using the OSI services. The lower layers of OSI stack (O54LRS and the COCEN plug-in unit) can be located in that same unit or they can be centralized in the BDCU unit as they are when X.25 connections are used.

g Note that the BDCU unit is not in use in BSC.

DN987681 Issue 6-1

Id:0900d8058041f0b8

17



OO7SEB

OSI applications CMISE/FTAM/VT

O54LRS

O7AMAN

ODCMAN

ONSEND

ONRECE

OAREAD

OAWRIT

OISOIP

OACMAN

COCEN OERECE

physical connection

Figure 5

Program blocks implementing a connectionless network service

Program blocks The program blocks involved in the implementation of the connectionless service are presented below with short descriptions of their tasks. O54LRS The Implementation of OSI Stack Transport (class 4) and Session Layer (O54LRS) implements transport class 4, and it uses the connectionless network service.

18

Id:0900d8058041f0b8

DN987681 Issue 6-1



Each O54LRS program block can handle several transport and session connections simultaneously. Each O54LRS program block is related to one or more network service access points (NSAP), that is, the transport layer is the user of a certain group of NSAPs. The OSI management uses this information for routing of incoming connection to the correct O54LRS. ONSEND The Program Block for Writing in Dual Port Memory in a computer unit. The ONSEND transfers messages from upper layers to the network layer, which is implemented in a separate plug-in unit. There is one ONSEND program block in each computer unit, which contains terminal equipment plug-in units. ONRECE The Program Block for Reading from Dual Port Memory in a computer unit. The ONRECE transfers messages from the network layer to upper layers. Network layer is implemented in a separate plug-in unit. OAWRIT The Program Block for Writing in Dual Port Memory in the COCEN. The program block is located in the plug-in unit, which is used for the implementation of network services. The OAWRIT sends messages to the main processor side. OAREAD The Program Block for Reading from Dual Port Memory in the COCEN. The program block is located in the plug-in unit, which implements the network services. The OAREAD receives messages from the main processor side. OERECE The Ethernet Packet Receiver Program Block is located in the COCEN plug-in unit. The OERECE receives the messages of the physical layer and sends them as Pectus messages to the OISOIP. OISOIP The Internet Protocol Program Block of OSI Model. The protocol is ISO IP for the network layer and LLC1 (Logical Link Control, Class 1) for the link layer. The OISOIP is located in the COCEN plug-in unit. O7AMAN The OSI program blocks communicate with the OSI Stack Addressing and Routing Program Block in the connection establishment. The O7AMAN has the following tasks: routing of outgoing connection requests to the correct computer unit and plug-in unit routing of incoming connection requests to the correct application via appropriate service elements connecting OSI addresses to OSI and application program blocks state management of OSI program blocks

O7AMAN is always located in the CM unit. ODCMAN Each computer with OSI plug-in units has a Supervision Program Block, which supervises the plug-in units in its own computer unit and informs the O7AMAN of the states of the plug-in units. The ODCMAN also initializes the plug-in units.

DN987681 Issue 6-1

Id:0900d8058041f0b8

19



OACMAN The Supervision Program Block of Network and Link Layers of OSI Stack is the supervision program block located in the plug-in units. The OACMAN answers supervision messages from the main processor side and initializes the parameters of the program block (OISOIP, O23LRS) realizing the network connection. For more information, see O&M communication protocols.

20

Id:0900d8058041f0b8

DN987681 Issue 6-1


File transfer and management

4 File transfer and managementThis function provides (a subset of) OSI file services defined in ISO IS 8571. The implementation complies with FTAM profile A/111. Capabilities for transferring whole files are thus provided. Both initiator and responder sides of FTAM are implemented. The initiator allows a local user to access remote filestores. The responder allows a remote FTAM user to access the DX 200 file system (provided that access rights are granted). FTAM uses network services and the following services above network services: Transport layer services, X.214, and protocol, X.224 Session layer services, X.215, and protocol, X.225 Presentation layer services, X.216, and protocol, X.226 Association control services, X.217, and protocol, X.227

Functions provided to local user The following file services are provided to a user via MML commands or message interface: Copy, which copies a file from the local filestore to a remote filestore, or vice versa. The FTAM creates the destination file, if it does not exist. Delete, which deletes a file in a local or remote filestore.

The following functions for the management of the local filestore are provided via MML commands: file creation file deletion display and modify attributes display file directory

There is also a service - local copy - which copies data from a buffer to a disk file in the local filestore, or vice versa. The FTAM can copy either a disk file or a RAM file in the DX 200 system. However, there are some limitations for the handling of RAM files, for example, the FTAM can not create a local RAM file. FTAM functions defined in the standard FTAM is a file service based upon the concept of the virtual file store. The virtual file store is an abstract description or model of real filestores existing in the local system environment. The file services and protocols are described in terms of file characteristics and data of the virtual filestore. Mapping the virtual filestore descriptors and operations into files and operations of the local file management system requires special attention. The file service is divided in two different levels: External File Service: at this level, transfer and file management operations are considered error-free. Internal File Service: at this level, mechanisms of error recovery and checkpointing are provided.

The FTAM user is provided with the external file service.

DN987681 Issue 6-1

Id:0900d80580264a57

21



The following services are provided to the user by the external file service: FTAM regime control. These services control application associations. FTAM regime establishment FTAM regime termination FTAM regime abort FTAM selection regime control. These services control the regime which binds an identified file to an FTAM regime: file selection file deselection file creation file deletion File management. This service provides file management capabilities to the file service user: read attributes File open regime control. These services establish or release the file open regime within which data can be transferred: file open file close Grouping control. The grouping control mechanisms allow a number of regimes to be established or released on one interaction: beginning of grouping end of grouping Bulk data transfer. These services perform the transfer of bulk data: read bulk data write bulk data data unit transfer end of data transfer cancel data transfer Control of actions: the actions which can be performed on a file are defined by the virtual file store. Access control: Mechanisms of control over the file actions in terms of correctness, authorization, and exlusive access. Concurrency control: These mechanisms are provided to ensure the correct execution of concurrent activities regarding actions on the filestore that might interfere.

The following functions are associated with the file service:

A file is specified in the virtual filestore by a name and a few sets of attributes. Each file is an unstructured type file with one FADU (File Access Data Unit) and each FADU contains only a Data Unit (DU). FTAM services are grouped into functional units: kernel read write file access (not supported) limited file management enhanced file management (not supported)

22

Id:0900d80580264a57

DN987681 Issue 6-1



grouping recovery (not supported) restart (not supported) FADU locking (not supported)

Use of each functional unit, except the kernel, is negotiated during the regime establishment.

4.1

Transport LayerThe transport layer establishes, controls, and releases transport connections and provides end-to-end integrity between the message source and the message sink. The functions supported by the transport layer can be summarized as follows: connection service to session layer independently of the used communication network selection of the network service optimization of the data unit size mapping of addresses regulation of the flow between end points segmentation and reassembly concatenation and separation error detection and recovery multiplexing and demultiplexing

Following protocol classes are supported: Class 0 Class 0 is the simplest type of transport connection. It requires a highly reliable network. Negotiated connection establishment Data transfer with segmentation of TPDUs Signalling of protocol errors Implicit variant release

Class 2 Class 2 is the multiplexing class, allowing several transport connections into a single network connection. It also requires a highly reliable network. Multiplexing Optional flow control Explicit variant release


4.2

Session layerThe session layer requires the use of a connection-oriented transport service. Services provided by the session layer can be divided into: session connection establishment service data transfer service (normal, expedited, and so on) session connection release service (orderly release, abort, and so on)

DN987681 Issue 6-1

Id:0900d80580264a57

23



The logical grouping of related services are called functional units. A subset is the combination of the kernel functional unit together with any other (set of) functional units. Session services are requested using session service primitives, which are transferred in session service data units (SSDU). Data exchange between two session service users is done via session protocol data units (SPDU). The selected functional units are: kernel duplex expedited data (FTAM does not use this) minor synchronize resynchronize

FTAM can negotiate the use of minor synchronize and resynchronize functional units. For more information, see O&M communication protocols.

4.3

Presentation layerEach layer in the OSI model, in performing its specific function, passes data from the application program block transparently - without change to its syntactic and semantic content. However, if the syntax of the information being transferred cannot be understood by the destination, meaningful communication is not possible. The presentation layer is responsible for the selection of the syntax to be used for information transfer. The transfer syntax serves as a common point of reference, which can then be used directly or converted by either application program block or by both application program blocks. The presentation protocol establishes rules about how information is to be represented and exchanged in a common language (that is, the transfer syntax). The presentation layer generates this transfer syntax, which is in fact a neutral form of data. In other words, components of various manufacturers can read the transfer syntax. The information to be exchanged between the partners (passed on to the communication system in their own language) is translated into this neutral language of the communication system. If a communication partner understands the neutral language, conversion on its side is not necessary. The main functions of the presentation service are: negotiation of transfer syntaxes: The presentation service user provides the name of an abstract syntax for which a transfer syntax is required. The result of a successful negotiation is a presentation context. transformation to and from transfer syntax. connection establishment information transfer coordination of syntax context management (coordination, conversion of the presentation profile) syntax conversion connection termination. data/syntax conversion

The following tasks are carried out by the presentation layer:

Services provided for the application layer are:

24

Id:0900d80580264a57

DN987681 Issue 6-1



data formatting selection of syntax (selection of mutually acceptable transfer syntaxes that preserve the information content of presentation data values)

Functional Units The model of the presentation layer comprises the following functional units (that is, logical grouping of related functions): Kernel: It supports the basic protocol elements of procedure required for connection establishment, connection termination, and information transfer. Context management: It is responsible for the addition or deletion of the context services (management of Defined Context Set). This functional unit is optional, with negotiable use. Context restoration: It adds further functions to presentation layer when session activity management functional unit is selected, or when session synchronization (minor or major), and resynchronization functional units are selected. This functional unit is optional, with negotiable use, and available only when context management functional unit is selected.

g The current implementation only provides the kernel functional unit.For more information, see O&M communication protocols.

4.4

ACSEThe task of ACSE is to provide the following services for the control of a single association: Establishment of association between two application entities via the A_ASSOCIATE service. Normal termination of the association via the A_RELEASE service. Abnormal termination of association via A_ABORT and A_P_ABORT services.

The ACSE services will operate in normal mode, which is a mode of operation resulting in the transfer of ACSE semantics using the presentation service. The other mode of operation (not supported) is the X.410.1984 in which the ACSE service provider does not transfer any semantics of its own but uses the X.410.1984 mode of the presentation service (no ACSE APDUs are used). ACSE requires the following services of the presentation layer: P_CONNECT, P_RELEASE, P_U_ABORT, P_P_ABORT. There exists a one-to-one correspondence between an application association and a presentation connection. The A_ASSOCIATE parameters will be set to define the mode and the presentation context facility (default presentation context, and so on). For more information, see O&M communication protocols.

4.5

Implementation of file transfer and managementOSI Services (OO7SEB) The FTAM implementation consists of two CVOPS processes and another program block; FTAM initiator and responder are implemented as the OOFTAM and the O7FRSP, respectively. Both the OOFTAM and the O7FRSP also contain virtual tasks, which realize the presentation layer and ACSE.

DN987681 Issue 6-1

Id:0900d80580264a57

25



The virtual file store of FTAM is implemented as a separate program block, the Implementation of FTAM Virtual File Store (OVFSRP). The OVFSRP acts as an interface between the virtual file store and the DX 200 file system. The MML interface is provided by an MML program, the OFTMML. The transport layer, session layer, presentation layer and ACSE also belong to the OSI Services Service Block, OO7SEB. They are all implemented as virtual tasks of the CVOPS. Virtual tasks, which realize transport and session layers, are included in one CVOPS process, the O45LRS. The presentation layer and ACSE are realized as virtual tasks, which are included in the same CVOPS process with the application service element using them, that is, FTAM. The program blocks involved in the realization of FTAM use services of the O7AMAN program block for address inquiries. I/O Services (IOESEB) In the implementation of FTAM, the I/O Manager Program Block (IOMANA) is used to execute disk operations.IOESEB IOMANA

OO7SEB

OFTMML

OVFSRP

OOFTAM

FILE SERVICES USER

O7AMAN

O45LRS

NETWORK SERVICES

Figure 6

Program blocks which take part in realizing FTAM initiator

26

Id:0900d80580264a57

DN987681 Issue 6-1



IOESEB IOMANA

OO7SEB

OVFSRP

O7FRSP

O7AMAN

O45LRS

NETWORK SERVICES

Figure 7

Program blocks which take part in realizing FTAM responder


DN987681 Issue 6-1

Id:0900d80580264a57

27

Transaction services


5 Transaction servicesCommon Management Service Element (CMISE) provides services defined in ISO IS 9595-2. These services are used by network management applications. The CMISE provides event/action-oriented and data manipulation services to its users. It also issues a series of linked replies to an action or a data manipulation service. The protocol used by CMISE (CMIP) is defined in ISO IS 9596-2. CMISE uses network services and the following services above network services: Transport layer services, X.214, and protocol, X.224 Session layer services, X.215, and protocol, X.225 Presentation layer services, X.216, and protocol, X.226 Association control services, X.217, and protocol, X.227 Remote operations services, X.219, and protocol, X.229 trigger an action (for example, activate test) event reporting (for example, alarm report) get attributes (for example, get error counters) set attributes (for example, modify parameters) create object (for example, create measurement) delete object (for example, delete measurement)

The general functions of CMISE are:

The implementation also provides ASN.1 encoding and decoding of a predefined set of user data definitions (that is, attribute values, event arguments, action arguments, and action results). CMISE uses lower layers in the same way as FTAM. CMISE uses two general application layer service elements: ACSE, and Remote Operations Service Element (ROSE). Services defined in the standard Association services: ACSE services are used for association establishment and termination. Management notification services: M-EVENT-REPORT. Management operation services: M-GET: retrieval of management information. M-SET: modification of management information. M-ACTION: request to perform an action. M-CREATE: request to create an instance of a managed object. M-DELETE: request to delete an instance of a managed object. M-CANCEL-GET: request to cancel a previously requested and currently outstanding invocation of the M-GET service.

Management information may be viewed as a collection of managed objects, each of which has attributes and may also have defined events and actions. Names of instances of managed objects are arranged hierarchically in a management information tree. The operations (set, get, action, delete) on managed objects involve the selection of managed object instances. Managed object selection has two phases: scoping and filtering. Scoping entails the identification of the managed objects to which a filter is to be applied. Four specifications of scoping level are defined: the base object alone

28

Id:0900d805802cfa78

DN987681 Issue 6-1



the nth level subordinates of the base object the base object and all of its subordinates down to and including the nth level the base object and all of its subordinates (whole subtree).

A filter is a set of one or more assertions about the presence or values of attributes in a scoped managed object. Functional Units The general service capabilities are designated as functional units: Kernel: All the CMISE services are included in the kernel functional unit. Filter: Enables the use of filter parameters in the services of the kernel functional unit. Multiple reply: Enables the use of linked identification parameter in the services of the kernel functional unit. Extended service: Enables the presentation layer services. Not implemented. Cancel get: Enables the use of the M-CANCEL-GET service. Not implemented.

Services available to CMISE user The services mentioned above are available to a CMISE user (an application program block) via the OCEAPI library interface. Data types, which are related to managed objects (attribute types, event arguments, action arguments, action results), must be known by the CMISE service provider. That is so because the CMISE implementation performs ASN.1 coding/encoding of the user defined data types. A CMISE user has either a manager or an agent role. However, these roles are not visible to the CMISE service provider. A CMISE user uses the CMISE services as a sequence: First the initiating CMISE user calls the OCE_SEND function of OCEAPI. The NMCOMM receives the CMISE primitive and establishes an association with a receiving NMCOMM. When the primitive has been transferred to the receiving NMCOMM, the CMISE user calls the OCE_RECEIVE function. A CMISE user in the manager role can use the management operation services once an association is established. A CMISE user in the agent role receives the management operation services and possibly sends responses. A CMISE user in the agent role can use the management notification services. A CMISE user in the manager role receives the management notification services and possibly sends responses. One of the two NMCOMM processes terminates the association.

There is also a service which includes, in a single service request to the CMISE service provider, an association establishment, one service transaction (request and a possible reply), and an association termination. The service is visible only for the initiating CMISE user. Remote Operations Service Element Remote Operations Service Element (ROSE) provides services for remotely invoking operations and then receiving correlated replies to those operations. Following services are defined:

DN987681 Issue 6-1

Id:0900d805802cfa78

29



INVOKE: RESULT: ERROR: REJECT:

Specifies the type of operation to be performed. Returns the result of a successful operation. Carries the error code and parameters in case of an unsuccessful operation. Rejects badly performed or unrecognised operation. This may be invoked by the user of ROSE or by ROSE itself.

The above services are of non-confirmed type. Control of the application association (establishment, release, abort) is performed by the services provided by ACSE. The ROSE protocol needs the presentation transfer service (P_DATA) to pass information in the form of ROSE APDUs between peer application entities.

5.1

Implementation of transaction servicesOSI Services (OO7SEB) The implementation consists of two program blocks, the OCMISE and the NMCOMM, and the OCEAPI library process. The OCMISE is a CVOPS process, which contains CMISE, ACSE and ROSE virtual tasks. The OCMISE provides CMISE service interface for the NMCOMM program block. The NMCOMM acts as an interface between the applications and CMISE. It takes care of the management of applications associations, ASN.1 decoding, and encoding of user data (that is, attribute values, event arguments, action arguments and action results). The OCEAPI offers functions to applications for sending and receiving CMISE primitives. Transport layer, session layer, presentation layer, ACSE, and ROSE also belong to OSI Services Service Block, OO7SEB. They are all implemented as virtual tasks of CVOPS. The virtual tasks which realize transport and session layers, are included in one CVOPS process, O45LRS. The presentation layer, ACSE and ROSE are each realized as virtual tasks, which are included in the same CVOPS process with the application service element using them, that is, CMISE. The program blocks involved in the realization of CMISE use the services of the O7AMAN for address inquiries.

30

Id:0900d805802cfa78

DN987681 Issue 6-1



CMISE USER

OO7SEB

NMCOMM

OCMISE

O7AMAN

O45LRS

NETWORK SERVICES

Figure 8

Program blocks which take part in realizing CMISE


DN987681 Issue 6-1

Id:0900d805802cfa78

31

Asynchronous data transfer


6 Asynchronous data transferTwo functions based on the use of Packet Assembler/Disassembler (PAD) facility over X.25 connection are provided: Remote MML terminal Data output channel

It is possible to give MML commands to the DX 200 system from a remote PAD facility via X.25 connection. The PAD function can act as a device driver in the DX 200 system, which enables the writing of, for example, printer or magnetic tape outputs to a PAD port. PAD facility is defined in ITU-T Recommendation X.3. The protocol between PADs is defined in ITU-T Recommendation X.29. In case of an incoming call to a PAD port, which is assigned to the MML terminal, the function in the DX 200 system accepts the call, provided that the resources are available. Then, the remote user has to provide a user name and a password in order to start an MML session. The applications in the DX 200 system can write data in logical files. The I/O system connects a logical file to a real I/O device, such as a disk or a printer. The logical file connections to devices can easily be modified. The I/O system sees the PAD ports also as output devices. When an application writes data to a logical file, which is connected to a PAD port, the I/O system gives a write task to the PAD function. The PAD function opens a connection to a predefined remote PAD facility (if the connection is not open already) and sends the data. The PAD function has a set of parameters indicating remote PAD addresses, connection release time-outs, and so on. In case of a remote MML terminal, the PAD function of the DX 200 system acts as a PAD host. In the case of a data output channel, the PAD function of the DX 200 system acts as a PAD client. Asynchronous data transfer parameters Incoming calls from X.25 network with SPI-field set to value 01, are directed to the PAD host function of the DX 200 system. Subsequent Protocol Identifier (SPI) is coded into the first byte of the user data field of the incoming call packet. The call will be directed to the MMI system, which will start the MML session with the remote PAD user. After the call has been accepted on the X25 level, the PAD host function will read the PAD parameters of the remote PAD device by sending 'read PAD parameters' message to the remote PAD device. The remote PAD should respond by transmitting a 'parameter indication PAD message'. See ITU-T Red Book X.29, 3.1. PAD host function of the DX 200 will set the values of the parameters 2, 3, 4, 7, 8, 9, 10, 13, and 14 if the values of the received parameters from the PAD device are not proper. Other values remain unchanged.

32

Id:0900d805803c7252

DN987681 Issue 6-1



PAD parameter 2, Echo 3, Data forwarding signal 4, Idle timer delay 7, Selection of operation of PAD on receipt of break 8, Discard output 9, Padding after CR 10, Line folding 13, LF insertion 14, Padding after LF

Value set by PAD host function 1, set to echo. 126, all characters in columns 0 and 1 and character 7/15 (DEL) of International Alphabet No.5. 0, no time out. 21, CCITT Red Book X.29 3.3.1. 0, normal data delivery. 0, no padding after CR. 0, no line folding In some networks parameter 10 defines the length of a line. 0, no linefeed insertion. 0, no padding after LF.

Figure 9

Parameters used by the PAD host function

Operator of the DX 200 system can change the above profile with MML commands. Implementation of asynchronous data transfer OSI Services (OO7SEB) Asynchronous data services are realized by two program blocks, the Implementation of PAD (OOPADI) and the Virtual Terminal Driver (VTERMD). The OOPADI realizes a PAD protocol (X.29) and provides a PAD port to other program blocks via a message interface. I/O Services (IOESEB) The I/O Manager Program Block (IOMANA) controls the logical file through which the input and output commands are executed. In this case, the logical file has been connected to the 'PAD device'. MMI System (MMSSEB) The MMI Manager (MMIMAN) reserves the Dialogue Driver (DIALOG) for the session. The DIALOG then takes care of the session. The MML programs run under the control of the DIALOG. Administrative Computer Interface (ADCSEB) The Virtual Terminal Driver (VTERMD) utilizes PAD in connecting the PAD port to the MMI system for remote MML sessions and to I/O system for data output. The environment of VTERMD, when it acts as an MML terminal, is presented in figure, Environment of the VTERMD as an MML terminal. The VTERMD accepts an incoming call request from the OOPADI, establishes an MML session with the MMIMAN and communicates with a MML program via a logical file of the I/O manager. The environment of VTERMD, when it acts as an output device, is shown in figure, Environment of the VTERMD as an output device. An application writes data to a logical file of the I/O manager, which in turn writes it to the device represented by the VTERMD as device driver. When the VTERMD receives a task from the I/O manager, it opens a connection to a remote PAD, which is defined in parameter file (VT1FIL), and sends the data to the connection.

DN987681 Issue 6-1

Id:0900d805803c7252

33



DX 200 IOESEB IOMANA DIALOG LF

MMIMAN MMSSEB ADCSEB R VTERMD VT1FIL

OO7SEB

OOPADI

NETWORK SERVICES

X.25

Figure 10

Environment of the VTERMD as an MML terminal

34

Id:0900d805803c7252

DN987681 Issue 6-1



DX 200 IOESEB IOMANA LF APPLIC. e.g. TEXTPR

ADCSEB

R VTERMD VT1FIL

OO7SEB

OOPADI

O7AMAN

NETWORK SERVICES

X.25

Figure 11

Environment of the VTERMD as an output device


DN987681 Issue 6-1

Id:0900d805803c7252

35

OSI statistics services


7 OSI statistics servicesOSI statistics services are used for the performance management of a communication network. It is possible to collect statistical information from OSI layers 1 to 4. Counters are collected from physical channels. With a single OSI measurement, information can be collected from one or several physical channels, as well as from one or several OSI layers. The monitored information can be used for analyzing and adjusting the following properties: Load level of communication network Quality of service of communication network

The OSI measurements are managed by MML commands, and the results are output to logical files according to a measurement timetable given by the user. The OSI Statistics Handling MML program provides the following commands: create OSI measurement modify OSI measurement data interrogate OSI measurement data delete OSI measurement start OSI measurement stop OSI measurement

When the measurement is created, the user gives the measurement a logical name, the physical channels and OSI levels to be measured, and the measurement timetable. The measurement state is now PASSIVE. In this state the OSI measurement data can be modified or deleted. When the start command is given, the state of the measurement is changed to ACTIVE and the collecting of the counters begins. The state of the measurement can be changed back to passive again with the stop command, or the stop date and moment can be included in the start command.

7.1

OSI countersThe following OSI counters are collected from the four lowest OSI stack levels: PHYSICAL LAYER: Frames received less than 32 bits in length Frames received with CRC error Frames received whose transmission was aborted Received frames rejected, caused by excessive length of the frame Physical layer down notifications Information Frames transmitted Information Frames received REJ Frames transmitted (Reject Frames) REJ Frames received RNR Frames transmitted (Receiver Not Ready) RNR Frames received FRMR Frames transmitted (type 1) FRMR Frames transmitted (type 2)

DATA LINK LAYER

36

Id:0900d8058031fc9e

DN987681 Issue 6-1


OSI statistics services

FRMR Frames transmitted (type 3) FRMR Frames transmitted (type 4) FRMR Frames received (type 1) FRMR Frames received (type 2) FRMR Frames received (type 3) FRMR Frames received (type 4) FRMR: Frame Reject, indicates the cause of rejection: 1. type 1: Invalid Control field 2. type 2: Invalid I-field 3. type 3: I-field too large 4. type 4: invalid N(R) (Receive Sequence Number) Information Frames retransmitted Data Link Layer resets T1 expirations Timer T1 specifies the time limit in which the remote end of the connection must acknowledge receiving the frame. If the time expires, the frame will be retransmitted. Received Reset Packets (cause = 0) Received Reset Packets (cause > 0) Received Clear Packets (cause = 0) Received Clear Packets (cause > 0) Received Restart Packets Received RNR Packets Transmitted Reset Packets Transmitted Clear Packets Transmitted Restart Packets Transmitted RNR Packets T20 Timeouts - Timer T20 is started when PLP issues RESTART REQUEST T21 Timeouts - Timer T21 is started when PLP issues CALL REQUEST T22 Timeouts - Timer T22 is started when PLP issues RESET REQUEST T23 Timeouts - Timer T23 is started when PLP issues CLEAR REQUEST Received Data Packets Received Data Packets Discarded Received Data Segments Transmitted Data Packets Transmitted Data Segments Successful incoming calls Successful outgoing calls Unsuccessful incoming calls Unsuccessful outgoing calls Number of calls with duration 'A' (0

o&m Communication Protocols

Documents

Transcript of o&m Communication Protocols