Manual_5020MGC_04_04

215 86877 EACK TR System DescriptionEd. 01, June 2005 Platform Architecture 54

Alcatel 5020 MGC

tolerance is provided by the two-layered ESWT approach by providing two independent (no inter-connection) planes.

Spanning tree

According the switching matrix principle no spanning tree protocol (IEEE 802.1d) needs to be provided in order to prevent looping packets in a network. This is according to the staged ESWT topology without loops

Addressing Capabilities

In order to be able to talk within the ITCE domain (UNIX/LINUX) the IP protocol is the standard communication protocol on top of MAC layer.

For the call engine domain legacy call engine message communication principles are still used while for inter-communication between both domains the MiddleWare communication layer and its mechanism is used. The Middleware layer uses UDP on top of IP/MAC as communication transport mechanism. Application or Service addressing is subject of the Middleware utilization.

The addressing capability enables to address a CE and the final receiver application inside a CE (e.g. a state machine process of a FMM). For call engine it is the msg_id. In ESWT environment it is the service port id. In Ethernet switch environment:

• Physical CE addressing is based on MAC address.

• Logical CE addressing is based on IP address.

• On top port service address is used to select the appropriate receiver application.

For the Dual Processor Board (CPCB) as well for the Jaluna Virtualisation approach the addressing scheme has been extended.

A PBA or blade may be composed of:

• one single processor only (CPCA)

• multiple processors. In Alcatel 5020 MGC dual-P is implemented on CPCB board.

• several virtual machines in the Jaluna approach running on (each) CPU. On each CPU there may run multiple call engine -CE instances. For alcatel 5020

215 86877 EACK TR System DescriptionEd. 01, June 2005 Platform Architecture Page 155

Alcatel 5020 MGC

MGC in maximum 4 are foreseen. In principle also several secondary LINUX instances may run in such an environment as well. The addressing scheme supports up to 16 VMs for the call engine domain as well for the LINUX domain.

Computing MAC-Addresses

The PCE-addresses of ITCEs and call engine-CEs or call engine-VMs must be unique. For the cPCI hardware release1 a dedicated rack clock distribution system had been invented with a cabling structure like a tree and SFI signal injection with dedicated numbering scheme in order to identify a processor blade inside the system. The processor blade position had been identified via the back panel.

For the cTCA hardware (cTCA from CCPU) this SFI signal and proprietary clock distribution cabling is not provided anymore. The location reference is retrieved from a chassis id, which has impact on the applied principles.

In order to guarantee a unique MAC address in the ESWT transmission media each PBA (CE) must evaluate its own MAC address value according to a defined rule.

In the cTCA environment CEs or VMs of ITCE-domain and call engine-domain will evaluate their MAC address from the programmable vendor Chassis Id (= chassis_id) stored in EEPROM on the backpanel plus the cPCI slot position_# extended by the CPU_id information and the virtual machine identity. The chassis-Id itself is retrieved via IPMI from the FlexManager. The slot position is retrieved via IPMI port interface reference. In addition with introduction of dual-Pentium boards the CPU-Id will be evaluated via IPMI-address.

Note: We have now to consider in addition the VM-Id which is needed to distinguish between various virtual machines running on the same processor.

Retrieval of the information is done in a boot-loader sequence and it specifies the correct own location ID that is then used to setup a configuration file name. Loading of this configuration file from OAM-CE to target-CE is then being requested.

Retrieved information is also used to compose a PCE_Id (pseudo NA - a 16-bit value compliant to the call engine Network Addresses range) which is clal engine-compliant in case of call engine-CEs (ITCE domain bit set in case of ITCE-domain).


Alcatel 5020 MGC

For call engine-CEs/VMs the call engine Network Address assigned at loading time must correspond to the data defined off-line. This input is used to compute an call engine compliant PCE_Id and from this value the final CE MAC_a address and the second MAC_b = MAC_a + 40h is assembled. The address composition principle is introduced in order not to jeopardise exiting data tools or application implementations relying on traditional number ranges. The principle is described in TRS-ESWT Communication.

The PCE_Id is usually treated as a Network address while that value represents a port address of a switching media. E.g. a processor blade has usually one physical board reference but may have several port addresses connected to a switching network. With the Virtualisation approach one port address of the board is used to enter the blade while each VM on the CPU running on that blade has an individual PCE_id. This PCE_id may act as an individual virtual Ethernet Switch address assigned to an (virtual) ESWT port.

The PCE_Id/NA is part of the lower two bytes of the composed MAC address value while the upper 3 bytes define the vendor id. The remaining byte is set = 2 according historical reason. In principle it is random. In effect the MAC address is always unique in an Ethernet network.

The domain distinction must be done within the lower two bytes of MAC because call engine tools and online software (kernel) allow only an 16 bit address value in range of an integer where only these lower two bytes are used in routing data. Therefore bit 12 (not used in real DSN environment) is set for ITCEs.


Alcatel 5020 MGC

In Alcatel 5020 MGC this results in following sequence of actions which is listed below and visualized in the two figures following afterwards:


Alcatel 5020 MGC

Figure 3. MAC Address composition for call engine-Domain / ITCE-Domain (except PLDA)

Figure 4. MAC Address composition for PLDA


Alcatel 5020 MGC

Physical CE Address and Physical Blade Reference

In the past the physical call engine control element identity was equivalent also to the physical location where an call engine blade was connected to the switch. Since only Ethernet connectivity existed this location reference could not be correlated to the (DSN) switching port address.

The location reference is now retrieved via IPMI / FlexManager interface (cTCA hardware).

One physical blade will have several physical addresses per individual VM/call engine-CE. From a maintenance point of view there must be a correlation done afterwards to identify a blade with a physical location reference in terms of a CCPU rack/chassis/blade location identity.

As described above the VM identity is subject of the computed MAC address for each individual VM running on a blade as a physical address.

The blade Ethernet port does not need to have an individual physical address like an individual MAC. It needs to be operated like an uplink port in a staged Ethernet switch topology accepting packets for several individual MAC addresses learned to be reachable in the next switch stage behind. The port has to be operated therefore in the promiscuous mode.


Alcatel 5020 MGC

Addressing aspects in the call engine-JALUNA context

Figure 5. MAC Address composition in the call engine-JALUNA context

Addressing aspects for the Dual Processor blade approach

For the CPCB blade (Dual Pentium) a 6 port Ethernet Switch (ASIC) is mounted while the up/downlink ports towards the board boundary are also operated in promiscuous mode. The onboard ESWT is configured in VLAN mode in order to compose a two layered switch approach with no interconnections amongst the grouped ports.

LCE_Id and IP address composition

For the hardware release 1 the IP addressing scheme was derived from the LCE-id split into two ranges. There was a range up to 1024 defined for the call engine domain while the range from 1024 upwards was reserved for ITCEs.

For Alcatel 5020 MGC a range for call engineCEs and one for ITCEs shall be reserved. The LCE id is used to calculate the IP address.


Alcatel 5020 MGC

Therefore a domain-bit (call engine or ITCE) is used to distinguish two sets of IP addresses. In addition some external Servers shall be connected with an IP address not conflicting each other. Therefore an extra indication bit is foreseen.

This allows in addition to support a multicast mechanism for loading call engine-CEs/VMs while not overloading LINUX based ITCEs. LINUX based Ethernet controller drivers are operated on interrupt driven mode on receipt of an Ethernet frame while call engine-OSN ALWAYS performs active polling principle in order to keep control in any situation. LINUX CEs would be flooded and unfortunately killed by the number of interrupts generated at loading time.

For the server domain and hardware management domain some IP addresses as a sub-range need to be reserved and shall be retrieved via DHCP service from OAMCE.

The IP address composed of the LCE_Id is defined as a private IP address in the range (172.16/17.x.x - according standard ) and therefore not routed to any public domain. If the external packet network is not a public domain but again a private customer network the used IP addresses must be out of the private IP address range and must not conflict with these private addresses and subnet address ranges (172.16/17/18.x.x).

The lowest 12 bits (1 1/2 bytes) are equivalent to the relevant 12 bits of the LCE_Id.

Note: the lowest 4 bits of the 16 bit LCE_Id cannot be used and were used in the beginning of call engine to identify child TCEs reachable via a DataLink.

Figure 6. Implementation of IP Address


Alcatel 5020 MGC

Intra-call engine-Communication

Transport Protocol Connectivity

The Transport Protocol Connectivity enables two CEs to transfer data (secured or not secured). Both CEs talk the same Transport protocol, e.g. TCP or only IP.

• Transport Protocol Stacks used in Alcatel 5020 MGC


Alcatel 5020 MGC

Figure 7. Transport Protocol Stacks


Alcatel 5020 MGC

The figure above shows a logical view of which PBA type is connected to which transmission media and which protocol stacks are applicable.

All call engine-PBAs have already Ethernet connectivity and are connected to an Ethernet switch only (two planes). This is used to reach ITCE and as well for fast communication between call engine-CEs

Ethernet transmission flow

For call engine message communication via ESWT there is a handling that deviates from the rule defined in chapter Ethernet transmission flow: in this case the Virtual Path (VP) protocol is used that provides flow control (handshake), overload control and windowing with re-sequencing. Current implementation supports/is configured for a window size of 1 and therefore no re-sequencing is required at receiver side.

This allows both ports to be used randomly and is toggled each time even for a distinct communication relationship of two CEs.

The window size set to 1 restricts the communication flow to a destination in terms of number of packets but shall be evaluated in combination with the transmission capacity of the switch as well with the processing capacity of the CE.

Effective windowing is important in case of high performant processor boards and slow transmission networks while the packets need a long time for transmission.

Inter-Domain Interfaces

Middleware (call engine CE ¤ ITCE)

A Middleware layer exists in call engine call control CEs and ITCEs and is used for the communication between the call engine domain and ITCE domain. For any communication within the call engine domain the existing message communication mechanism is used. For intra-ITCE-communication messages are sent via IP not making use of any middleware functionality.

Middleware provides location transparency and routing function for message delivery.

Communication between applications mapped on call engine CE and applications mapped on ITCE use UDP/IP protocol with a limited middleware layer on top. The middleware layer provides the following functions:


Alcatel 5020 MGC

• Dynamic Registration:

ITCEs become known to call engine-CEs middleware by pre-configuration IP addresses according ITCE-LCE-ids. A command handler is used to update this configuration data i.e. to add or remove ITCEs.

Each call engine-CE (middleware) uses this list of configured IP-addresses to register itself to all of these known ITCEs. The call engine-CE passes within the registration the information about its CE-type and the available (externally addressable) functions/services to the ITCEs.

ITCEs confirm the registration from call engine-CEs with the information about its ITCE-type and the already registered and thus addressable functions/services.

If a UNIX process is started at the ITCE-side, it registers with the function/service identification to the middleware. The middleware is responsible to propagate this function/service identification to all known/registered call engine-CEs.

• Path monitoring and re-registration:

Each call engine-CE monitors connectivity to all known ITCEs (i.e. to all known IP-addresses). If connectivity with a particular ITCE is lost the middleware on call engine-CE tries to reconnect to this ITCE.

ITCEs monitor in similar way connectivity with known call engine-CEs. If connectivity is lost, this call engine-CE is removed from the currently applicable routeing list until the call engine-CE re-registers again.

During periods of lost connectivity, the send-message service to an unreachable destination, i.e. when both active and standby CEs are not reachable, invocation by an application process is returned a result of unsuccessful service invocation.

• Active / Standby support:

Middleware on call engine-CE is responsible to duplicate traffic to both the active ITCE as well as to the related standby ITCE. Note that the support of multicast service is not yet provided by the Ethernet switching fabric and to be considered for further improvement.

• Active / Active support:

Middleware on call engine-CE supports also Active/Active configurations. While in an A/S configuration only one board handles real traffic for A/A both boards are processing traffic. Middleware provides message duplication at registration start up while the consecutive communication stream is passed only to the initial responding CE.


Alcatel 5020 MGC

Functional addressing

The sending middleware user shall be able to address the destination (i.e. the requested functionality/service) only via a functional Service ID. The sender shall neither need to know any individual service provider instance nor on which destination CE(s) such a service provider is located.

The destination CE shall be selected by the source CE based on registration information received from other CEs. If multiple instances have registered to provide the same service, then functional addressed messages shall be distributed to them (load sharing). Therefore there is no guarantee that subsequent functional addressed messages are delivered to the same service provider instance.

Note: This addressing principle (but not the semantic and syntax) corresponds to “call engine Basic Msg.” addressing. Functional addressing is expected to be used for simple one shot request-response queries or to establish a communication relation (i.e. a session) with one (of several possible) service provider instance. Further communication within a session is via instance addressing.

Qualified functional addressing

A qualified functional addressing allows a functional addressing of a service provider on a specific CE, by providing the Service ID and a LCE (or PCE) ID as address information.

Note: This addressing principle (but not the semantic and syntax) corresponds to “call engine Basic Into” or “call engine Basic Onto” addressing, depending if the given qualifier is a LCE-ID or PCE-ID.

In the call engine subsystem the LCE-IDs and PCE-IDs are provided by the OSN. In the Unix subsystem the LCE-IDs shall be configured as (middleware) configuration data. In order to guarantee system wide unique LCE-IDs a value range shall be used which is not used by call engine. The Unix PCE-IDs shall be generated from the physical board location, using the same algorithm as call engine.

Instance addressing

Instance addressing provides the addressing of a specific service provider instance on a specific CE. The instance addressing shall support both logical and physical addressing option.


Alcatel 5020 MGC

The logical instance addressing

The logical instance addressing allows addressing a specific service provider instance on the active CE, the standby CE or both CEs of an active/standby CE pair identified by a LCE ID. The physical instance addressing shall allow addressing a specific service provider instance on a dedicated physical CE identified by a PCE_ID.

Note: The addressing principle (but not the semantic and syntax) of physical instance addressing corresponds to “call engine directed to” addressing. The logical instance addressing has no correspondence on call engine. The aim of the logical instance addressing is to make an active/standby switchover within a LCE (active/standby CE pair) transparent to the sender.

EPG (call engine CE ¤ ITCE)

EPG is a gateway on top of the EPM socket API (default port: 44299) which supports sending of call engine messages into call engine, DB access in call engine and calling of some call engine kernel functions. It provides an interface to the MPTMON controller.

Special users of the EPG are HILTI-NT and the SQL engine. The EPG is requested for the establishment of TCP/IP connections from external nodes, i.e. it acts as server.

MPTMON supports due to resource problems EITHER 3 EPG and 1 serial ITF session OR 4 EPG sessions without serial ITF connection.

EPI (call engine CE ¤ EABS)

EPI is a gateway on top of the EPM socket API (default ports: 1001, 1002 - can be changed) via which provides a call engine message interface for the 2 messages EPI_ACCESS and EPI_RESPONSE. EPI allows up to 10 different users, sequentially or simultaneously.

The users of EPI are applications for billing (for detailed/immediate billing and division of revenue), for interception and for charging of N7.

The EPI initiates the establishment of TCP/IP connections to external nodes, i.e. it acts as client.


Alcatel 5020 MGC

EDOTCP (call engine CE ¤ EAxS)

EDOTCP is a gateway on top of the EPM socket API. Inside call engine legacy a normal call engine message is passed to the EDOTCP-Module. EDOTCP maps the information on top of TCP/IP and sends it out via the ethernet-interface. EDOTCP works as a kind of gateway.

The counterpart on EAxS-site is the module UDOTCP. TCAP like data are exchanged over this interface. The users of EDOTCP are applications for Routing, LSIF-tree and subscriber profile. The EDOTCP initiates the establishment of TCP/IP connections to external nodes.

ROMA (call engine CE ¤ CMC)

The Remote Operations and Maintenance Access Module (ROMA) provides a software interface between an external computer controlled system and System 12 for the transfer (reception and transmission) of binary and/or ASCII data over an X25 or TCP/IP connection.

In case of X25 the layer 3 connection can be established on the available layer 1 connections (S0, V11, V28).

In case of TCP/IP it uses the well-known port 7000. ROMA can act as client or server concerning the establishment of TCP/IP connections to external nodes.

The ROMA can act as a file handler to support virtual devices. It uses standard file oriented interface, which allows exchanging files between call engine and an external system.

Apart from the file handling, the ROMA can handle ASCII Operator Requested Jobs (ORJs) from the external system by sending them to the Session Handler FMM.

The ROMA FMM also allows "external management platform for call engine" to send and receive call engine-specific information via reserved data control block definitions.

In addition, the ROMA allows man-machine communication (MMC) dialogue between a Network Service Centre (NSC) and a connected exchange.

The ROMA allows also a pure ASCII interface without header byte overhead. In this ASCII mode it replaces the VDU-terminal connected via the RS232 interface.


Alcatel 5020 MGC

RegLib (ITCE ¤ FlexMgr)

The Flex managers operate in A/S mode, which is transparent to users. All FlexManager services are available via floating IP addresses that automatically move to the active FlexManager. The FlexManagers automatically synchronise the registry.

The RegLib interface provides a defined API to operate on the registry - a database that is arranged hierarchically, providing attributes that represent the state of the system - and is similar to a MIB somehow.

The RegLib is a simple interface that is used instead of SNMP. It provides access to the registry via some simple commands like GET and SET and specific search methods.

In addition async notification API is provided that triggers a callback for each (registered) attribute change.

IPPoE (call engine CE ¤ ITCE)

IPP is a well-known communication protocol for intra call engine communication via the legacy TDM switching network. There we had IPP over DSN

The new solution for N7 signalling termination in Alcatel 5020 MGC requires IPP for inter-domain communication - which means that IPP is used between a CE running call engine-OSN having well known call engine routing tables available and a CE running LINUX that has initially no call engine routing -table info.

This means that an additional translation-table is required in all CEs that might address the SLN7S that will assign the PCEID (and by that the MAC-address according to given algorithm) of the target SLN7S (which is an OBC from call engine N7-SW point of view) to a given LCEID of the related TCE.

Note: That the "related TCE" is no longer physically related to the "OBC" (as it was in legacy N7 solution with SLTAs where we had the HCCM which was 1 TCE board plus 8 SLTAs) but we have now a logical relation only.

In addition some specific link supervision mechanisms might be necessary to enable high-speed link-failure-detection.


Alcatel 5020 MGC

Hardware Management Software (ChassisCoordinator, ChassisManager, clients)

The hardware management architecture for the Alcatel 5020 MGC has several levels. On the lowest level we have some client functionality on each blade that has to be controlled. This is either an IPMI-client or some functions to handle PICMG 2.1 signals.

On the next level there is one pair of Chassis Managers (in the CCPU product called FlexManagers ) available for each chassis, which will provide chassis management functions.

On the third level there is in addition one pair of ChassisCoordinators (CHACO) existing once in the system located in the OAMCEs .

The function provided by the Chassis Manager (CCPU's FlexManager ) is...

• in charge of CCPU and outside of ALCATEL's responsibility

• Translating a set of actions given from outside (e.g. via operator ITF) into a set of (standard) commands for hardware management according to PICMG 2.9 or 2.1 (IPMI or hot swap signals)

• Hardware supervision incl. trigger of notifications for all objects on which a user has registered

• API ( RegLib library functions ) to be used by any higher level management SW

• High availability provided by duplication of FlexManagers (act/stby-configuration) and appropriate failure detection and switchover mechanisms

The ChassisCoordinator (CHACO) is...

• an ALCATEL software product

• using the API provided by FlexManager

• providing the "intelligence" of the hardware management system; in this module we will make the decisions and define the actions to be taken.

• implemented as a part of the server platform; providing high availability by act/stby configuration


Alcatel 5020 MGC

• providing the system level of hardware management functions and will address the chassis-related FlexManagers according to required actions

• the interface for all hardware-related actions / reporting which will all go via the Chassis-Controller

The figures below will show...

• The relation of FlexManagers to ChassisCoordinator in the system (system-overview)

• The layering of the hardware-management software including the domain aspects (management level view)

• The SW environment of the ChassisCoordinator (CHACO) - software structure view


Alcatel 5020 MGC

Figure 8. Chassis Management Configuration - System Overview


Alcatel 5020 MGC

Chassis Management Configuration - Domain View

Figure 9. Chassis Controller Software environment

System Maintenance

The ALCATEL 5020 MGC consists of several domains, which are all implemented on the same hardware-platform.

• the legacy call engine-domain

• the ITCE-domain

• the server-domain

• the hardware-management-domain

This is also reflected in the System Maintenance. For the customer some of the differences are combined and unified in the CMC view. This means, that we have internally different system maintenance parts. For details see the chapters below:


Alcatel 5020 MGC

call engine-domain

The principles of system maintenance functionality of the call engine legacy domain are still valid although we have no longer call engine legacy hardware - but some hardware related alarms will now come from the ITCE-domain via IPMI / FlexManager / CHACO. This is possible because these slots are visible for CHACO due to some hardware-CAE data provisioning.

The call engine legacy domain is beside their other functionality, still responsible for the master alarm panel function (there is no physical Master Alarm Panel any more - see chapter Master Alarm Panel indication for x-domain alarms below).

With Alcatel 5020 MGC we introduce a Virtualisation concept for call engine-CEs. For the call engine Maintenance handling there is no difference between a virtual CE and a CE running exclusive on one CPU. To avoid too many individual alarm reports for virtualised CEs in case of a failing hardware a correlation is done on base of a CPU.

In rare cases where some virtualised CEs cannot be handled/accessed by call engine Maintenance Commands anymore a “Hard Reset” command is provided . It will trigger via CHACO a hard reset of the related CPU (see chapter hardware Reset API). The command consists of the following actions:

• disable all CEs of the CPU

• trigger the HW reset via CHACO

• wait for reply from OAMCE (completion code)

• initialise the CEs of the CPU, (if successful reload of the Jaluna platform was performed)

ITCE-domain

As the call engine domain, the ITCE domain provides supervision and alarming for their hardware and software. The related alarm reports are sent from the OAM towards CMC. The alarming via the "master alarm panel" is done via the call engine domain.

Server-domainThere is an alarming via the "master alarm panel" which is done via the call engine domain for some specific events. The call engine domain passes these events to the CMC, additionally.


Alcatel 5020 MGC

For the EAxSs except EABS these events are visible over the WBEM interface. For EABS the events are only visible locally on an X-Window layout.

For EABS:

The above-mentioned standard alarming chain can be switched (during installation) to a direct alarming to CMC via SNMP (except HW related alarms which come from the ITCE-domain via IPMI / FlexManager / CHACO - This is possible because these slots are visible for CHACO due to some hadrware-CAE data provisioning).

For other “servers”:

Additionally to the standard alarming chain, the complete Server Platform software is available in order to manage the hardware.

hardware-management-domainThe FlexManagers are supervised by the ITCE-domain. Single or double faults will be reported by the CHACO (see chapter System Maintenance)


Alcatel 5020 MGC

Figure 10. System Maintenance View for the Customer

Master Alarm Panel indication for x-domain alarmsA Master Alarm Panel in the sense of an independent alarm chain will be not available anymore. In case the connection to the CMC is broken, nobody can be informed anymore in case of urgent alarms.

Errors and Alarms detected by the system management of the ITCE domain will be reported to the CMC. The related alarming is routed over to the call engine legacy domain. The OAM will send these indications to the PLCE. The receiving part within the PLCE is the EPG-FMM. This routes the events via CADI-FMM to the alarm management of call engine.

This mechanism is used to indicate alarm severity (critical, major, minor) to the CMC.


Alcatel 5020 MGC

To replace the master alarm panel the following approach is now selected:

• Errors of the call engine domain are send directly to CMC as standard call engine alarms using the ROMA interface towards CMC.

• Errors and Alarms detected by the system management of the ITCE domain will be reported to the CMC via SNMP events.

• Alarms of the call engine domain and the ITCE domain can be displayed via the Alarm view application. Accessing this application via GoGlobal from the OWP the alarms and their severity can be looked at the OWP.

• Audible indication of alarms on the OWP is provided by the A1359 application. The IOO part runs on the CMC and receives all alarms. Depending on the configuration it triggers the IAP part on the OWP to give audible indications.

Rack Alarm handling

For Alcatel 5020 MGC the rack alarm handling for cTCA racks is located in the ITCE-domain.

For each cTCA chassis a pair of FlexManagers controls all hardware events, which are generated and detected within this chassis. These events will be collected in a Chassis Controller (ChaCo). ChaCo is responsible for all chassis. It connects itself to all FlexManagers for this purpose.

ChaCo supervises the following alarm conditions:

• power failures (blades, Ethernet switches,…)

• fans

• temperature

• FlexManager alarms

If Chaco detects, that the temperature within a chassis rises over a predefined threshold, system maintenance will trigger a power down of all PBAs like blades, FlexManagers, Ethernet switches,.. .

The other rack alarm events will not lead to an automatic system reaction. All rack alarm events will be reported via Alarm / Report Manager.


Alcatel 5020 MGC

For more info w.r.t. hardware-management see as well chapter System Maintenance.

Ethernet Link Maintenance

The access from a processor to the Ethernet Switch will be supervised. Access failures are reported to the central maintenance software of the call engine legacy domain, to perform error correlation. The Ethernet Switch is set to faulty, if more than 2 of the links from the processors to the Ethernet Switch are faulty. Otherwise the affected links will be set to faulty.

Also the communication capability from one 1st stage Ethernet Switch box to another 1st stage Ethernet switch box is supervised. In case of communication problems an alarm will be raised. But it is not possible to locate the problem in detail (e.g. which one of the uplinks of the 1st stage switches is faulty etc.).

For more info w.r.t. ELM see as well chapter Ethernet Link Maintenance (ELM).

hardware Reset API

The FlexManager has the ability to reset each blade (cTCA processor board) via an IPMI reset signal.

This mechanism will be used by CHACO for the ITCE-domain. The system management sends a request to the responsible FlexManager, which itself triggers the IPMI chip on the required blade to reset the board.

The call engine-domain can trigger this mechanism via CHACO for call engine-CEs (CPUs) (see also chapter call engine-domain)

For EAxSs, under control of the Server Platform, this mechanism is also available (see ITCE-domain). An exception is the EABS.


Alcatel 5020 MGC


Alcatel 5020 MGC

Figure 11. Numbering scheme in OAM-presentation

New TOD synchronization

ALCATEL 5020 MGC has to be ported onto cTCA hardware. The new cTCA-hardware does not support all functions of the legacy hardware, mainly a high accurate time source is missing that is required for call handling applications (e.g. charging).

Therefore we use the Network Time Protocol (NTP) described in RFC1305 for the MGC part:

• The OAMCEs are synchronized with external NTP servers in the customer IP network.

• All diskless ITCEs are synchronized with the OAMCEs that work as relay server.

The PLDAs of the call engine part are synchronized with the OAMCEs using the Simple Network Protocol (SNTP) as described in RFC2030, based on the standard NTP protocol.

The local time is calculated from the received UTC time inside the active PLDA and broadcasted to all other call engine control elements via a propriety protocol called "Local Day Time Protocol" (LDTP) periodically and on call engine control element request.

As the call engine part is no longer the master of the time no MMC commands are provided to display, modify or adjust the time and date.

N.B. As the OAMCEs do not have an accurate time source as well, they act as relay server which themselves are synchronized with high accurate NTP servers


Alcatel 5020 MGC

in the customer network. Due to this no GUI is provided on OAMCE to set the date or time information.

Figure 12. TOD distribution in Alcatel 5020 MGC

Backup and Data Restore Strategy

Server domain

EABS:

The EABS is autonomously performing its BACKUP and RESTORE operations. The EABS writes its BACKUP onto an own partition on the local OWP and expects in case of a RESTORE its data there. For initial installations the DVD from the local OWP is used.

Other “servers”:

The rest of the EAxSs use the mechanism available for the ITCE domain.


Alcatel 5020 MGC

ITCE domain

For the ITCE domain there exist rudimentary mechanisms only.

complete BACKUP / RESTORE

The complete BACKUP / RESTORE was a 1 to 1 copy of the magnetic disc to tape in release 1. During this task the OAMCE must run in maintenance mode (e.g. ORACLE database inactive). For Alcatel 5020 MGC we use the disk of the collocated local OWP as backup medium, which replaces the tape from a functional point of view.

Backup can not be taken from running OAM (OS/DB Restrictions) but only from OAM in maintenance mode.

Therefore to avoid maintenace mode as far as possible...

• Full Backup will be taken once after Installation before Startup of OAM

• Backup will be put to OWP disc and then further to DVD if required

• copy to CD/DVD at local OWP requires SW to write more than one CD/DVD because of size of Backup.

• Backup has to be taken from OAM A and OAM B

• Data-Backup has to be taken periodically via “partial backup” method (no maintenance mode required)

Restore of original status after OAM crash...

• USB stick needed to run Linux

• copy Backup from OWP disc to OAM A resp. OAM B (restore from DVDs/CDs to OWP disc to be done locally at OWP, if Backup is not available on disc already)

• put actual FRB on top (FRBs available on CD, loaded at OWP, copied to OAM A and OAM B in Maintenance Mode (via SCRIPTs)

• Restore of Data as described with Partial Backup

Partial BACKUP / RESTORE

A partial BACKUP saves data to magnetic disc (at collocated local OWP) or DVD (no automtaic process; to be done by explicit actions). It uses the ORACLE export function for data in the ORACLE database and copies configuration files.


Alcatel 5020 MGC

RESTORE uses the ORACLE import function and copies configuration data onto the OAMCE's magnetic disc.

Partial BACKUP is allowed during normal operation.

Partial RESTORE is done via SCRIPTs to both OAMs in maintenance mode.

Call engine domain

The basic handling is kept for Alcatel 5020 MGC - but there is a change w.r.t. the media that are used for BACKUP / RESTORE in Alcatel 5020 MGC.

The PLDA RTM contains two HDs and is equipped in both OAM chassis’s. The first disk is used as PLDA system disk, the second one is used instead of ODK as backup/restore medium.

No method is foreseen to physically remove the backup created by standard mechanisms from the system.

A new GUI on OAMCE is provided instead that retrieves all files of a partition of the backup disk. In a second step it compresses these files into an archive and stores it on the local OWP HD (mounted via NFS).

These backups can afterwards be transferred to a remote location or written onto DVD.

As long as the PLDA is operational a RESTORE of backups from the local OWP to the backup disk can be done via reverse to the BACKUP described before.

In case a PLDA is not operational and cannot boot from either the system disk or the backup disk a USB stick is used to copy a dummy build onto the system disk. Loading this dummy build the PLDA is able to format the backup disk and to serve FTP requests in order to restore a backup onto the backup disk.


Alcatel 5020 MGC

The figures below will show the storage media in Alcatel 5020 MGC and their assignment to CEs. In addition there is a description of the SCSI connectivity of the storage media:

Figure 13. Assignment of storage media to processors in Alcatel 5020 MGC

Loading

Principles

In Alcatel 5020 MGC There are the following parts that are to be loaded:

• Server domain (currently EABS only) loading independent from other domains

• hardware-management domain loading independent from other domains

• ITCE-domain loading independent from other domains


Alcatel 5020 MGC

• call engine domain loading depending on ITCE domain

• call engine domain (JALUNA-Virtualisation) loading depending on ITCE domain and Virtualisation layer

For the call engine- and ITCE-domain there is a common first loading step now. In a second step the call engine-part and the UNIX-part are loaded independently from each other.

Note: That the diskless instances of the server-domain are considered like ITCEs from the platform point of view. Loading of server-domain instances that have their own disk is totally independent from the rest of the system and is considered as “server-domain” loading.

Note: That the call engine-part can only be loaded when the OAM-agent is working.

Loading of the HW-manager is totally independent from the rest of the system.

Out of scope for this Release is:

– An automatic process for simultaneous SW replacement on all domains to introduce context dependent packages (not supported). A manual procedure describes the sequence of tasks to be done for the update of single and multiple domains.

– Package replacement (not required). Package Replacement will be required for follow-on projects based on this release.

• Remote SW upgrades from CMC or an ALCATEL Service Centre is not required.

Disk-Boot and Network-Boot for ITCE- and call engine-Domain

The following figures will give an overview on the loading of the different domains. Note that call engine-Domain and ITCE-domain have a common first step in a


Alcatel 5020 MGC

two-step network-loading concept. The other domains' loading is totally decoupled from the call engine- and ITCE-domain.

Figure 14. Disk-node loading and First step of ITCE/call engine network-loading


Alcatel 5020 MGC

Figure 15. Second step of ITCE/call engine network-loading

The initial network-loading of call engine- and ITCE-domain requires that OAMCE is loaded and operational. BIOS of PLDA ensures that for these initial steps there is the same behaviour than for any other call engine-CE on cTCA.

This means that the attempt to start from colocated HD (which comes first in the boot-sequence) will fail due to file contents on PLDA-disk will be invalid. BIOS will continue in its boot-sequence and will end at network-boot.

In the first step of the network-boot sequence (which is common for all diskless nodes of the call engine include JALUNA-type and all diskless nodes of the ITCE-domain include diskless server-nodes) we have the following sequence:

• cTCA board powers up and BIOS will …

– initialize hardware (chip set, I/O devices, etc)


Alcatel 5020 MGC

– do some Board Diagnosis (hardware test, memory tests, debug interface, etc)

– start Board initialization (here PXE)

• PXE (= Pre-boot Execution Environment) will …

– send DHCP load request to OAMCE (by Broadcast)

– load an additional piece of code (= CE Loader)

• CE Loader will …

– execute board firmware upgrade if required (in flash memory)

– perform the "geographical location identification" i.e. physical location (shelf/slot) with IPMI commands

– builds the MAC address according to predefined assignment/algorithm (related to position)

– setup a configuration files name according to evaluated geographical location

– read the configuration file from OAMCE

—if there is no configuration file for the request it is assumed implicitly that the request comes from an call engine-CE for which no individual configuration-files have been created per slot; therefore the default configuration file for call engine-CEs will be selected in this case which defines call engine bootstrapping; this will trigger …

—if the request identifies a configuration file for a valid LINUX position, then …

In the second step of the network-boot sequence (which is different for the nodes of the call engine- and ITCE-domain) we have the following sequence:

• ITCE-domain [covers as well diskless server-nodes]:

– loading of the Linux image

– starting LINUX...

• call engine-domain [non-JALUNA]:

– loading of call engine boot image into memory (with TFTP protocol) which includes call engine HdS software

– call engine HdS …

—provides hardware abstraction


Alcatel 5020 MGC

—remains in memory to support loading, initialization and online software (call engine Kernel)

—initializes the hardware and software configuration (init GDT, LDT, IDT, TLB, etc; execute fast test (CD40 pattern), init ROM Data area)

—Initiates Bootstrap

• Loading procedure depends on position of call engine-CE (Note: HdS remains in memory to support loading and later the online software (call engine Kernel) )

– If position is related to PCE 0xC or PCE 0xD (=PLDA position)

—If load mode (ROM data) == NETLOAD then send LoadBID to mate PLDA and receive load packets; else (after TO), continue with load mode = DISK

—If load mode == Disk then load DISK-loader from PLDA disk loader slave executes (DISKLOADER)

– In any other position

—Send LoadBID to PCE 0xC and PCE 0xD (with resp. MAC address)

—Receive load packets (= a loader agent)

—In case of a system start-up (STUP) or partial STUP, the STUP slave loader will be loaded into the memory; loader slave executes (STUP)

—In case of a single CE loading (CE INIT), the CE INIT slave loader will be loaded into the memory; loader slave executes (CE INIT)

• Call engine-domain (JALUNA-based):

– Loading of JALUNA’s image into memory (with TFTP protocol) which includes a primary LINUX, OSware, NK2OSN and adapted call engine HdS software.

– Starting JALUNA’s software-package (OSware/primary LINUX, which includes that in the LINUX command line some parameters are passed which indicate number of call engine-VMs, the required memory space per VM, time slice quantum per VM, etc.); from OAMCE’s point of view this software is like loading call engine-HdS into a standard call engine-CE which means that OAMCE does not expect any feedback from that CE.

– JALUNA’s SW-package will setup and start each call engine-VM that was requested (in the LINUX command line, see above) which finally passes control to the adapted HdS of the VMs to execute the loading procedure


Alcatel 5020 MGC

– Valid NAs for this loading procedure are non-PLDA-NAs only; for them adapted HdS performs the well known call engine-loading procedure which covers

—Send LoadBID to PCE 0xC and PCE 0xD (with resp. MAC address)

—Receive load packets (= a loader agent)

—In case of a system start-up (STUP) or partial STUP, the STUP slave loader will be loaded into the memory; loader slave executes (STUP)

—In case of a single CE loading (CE INIT), the CE INIT slave loader will be loaded into the memory; loader slave executes (CE INIT)

The following three figures show the two loading packages that we have to consider for the JALUNA-based approach and a comparison to the non-JALUNA approach:


Alcatel 5020 MGC

Figure 16. Call Engine - JALUNA based approach Load-item 1

Figure 17. Call Engine - JALUNA based approach Load-item 2

Figure 18. Call Engine-JALUNA based approach - related to pure call engine approach

The following two figures will show a scenario of the first step of network-boot and an overview of possible branches in the two-step network-boot scenario.


Alcatel 5020 MGC

Figure 19. First step Loading scenario

Figure 20. Two step network-boot Overview


Alcatel 5020 MGC

Initial disk preparation for OAMCEs

For the initial A5020 MGC 12 installation OAMCE disks are prepared at ALCATEL site and delivered to the customer.

Follow-on disk preparations (e.g. in case of disk damage) are done as described below:

• OAMCE is booted from an USB stick (this stick contains a LINUX operating system, and disk preparation scripts)

• The preparation scripts control formatting and partitioning of the HD and copying of a backup located on local OWP onto OAMCE HD (via NFS mount)

• The USB stick is removed now and the OAMCE boots up.

Disk preparation for PLDAs

If neither the system disk nor the backup disk is prepared the PLDAs cannot be loaded. The procedure to build PLDA disks is the same for initial disk preparation and for follow-on software upgrades.

A DVD is delivered to the customer. This DVDs contains the call engine build.

PLDA disk preparation consists of the following steps:

• Insert call engine-DVD into local OWP’s drive

• Boot one (isolated) PLDA from an USB stick (this stick contains a LINUX operating system, and disk preparation scripts)

• The preparation scripts control copying of image on DVD onto PLDA’s backup-HD - which is replacing the “ODK” function - via NFS mount

• The USB stick is removed now and the PLDA will boot now (according to mechanisms defined in chapter Loading )

• When executing its loaded HdS PLDA will ask the operator for load-medium (which has to be backup-HD in this case!)

• Now the system proceeds as well known from standard call engine-mechanisms.


Alcatel 5020 MGC

Error correction loading for call engine-domain

One DVD contains the new call engine GLS/PLS files and a script. This DVD is inserted into the OWP’s DVD drive. The script can be executed on the OAMCE after the device is mounted. This script copies all call engine files via FTP to partition 1 of both PLDA’s system disk. Afterwards Error Correction loading is started on PLDAs.

A further step could be to transfer the call engine files to the OAMCE via FTP directly.

Server-Domain

EABS:

For initial disk preparations and follow-on deliveries DVDs are delivered to the customer. These DVDs contain the SW to be loaded.

The procedure to be followed is the similar to the OAMCE follow-on disk preparation activities:

• The DVD is mounted in local OWP DVD drive

• Server is booted from an USB stick (this stick contains a LINUX operating system, and disk preparation scripts)

• The preparation scripts control formatting and partitioning of the HD and copying of the SW from local OWP onto server HD (via NFS mount)

• The USB is removed now and the server boots up.

Other “servers”:

The other EAxSs have the same handling as diskless nodes of the ITCE-domain.

hardware-management-Domain

The HW-management-domain (FlexManager) is loaded independently from local Flash Disk. A procedure to upgrade the Flash Disk of FlexManager is described inside the documentation of the chassis supplier


Alcatel 5020 MGC

Specific Loading-Features and Restrictions

ITCE-domain:

The ITCE-domain provides means for major and minor software upgrades. A major software upgrade results in isolating the standby OAMCE, pre-paring its disk with the new package and fast loading of the diskless ITCEs via SIPL in order to meet the maximum 3 minutes outage time. Note that the previously active OAMCE running the old package is isolated when SIPL starts loading of the diskless ITCEs.

A smooth upgrade is supported for a minor software upgrade (no change of interfaces or data structures) of the diskless ITCEs. Sequential loading is controlled from a GUI.

Firmware upgrade (BIOS) of processor boards is supported within this domain.

Call engine-domain:

The call engine domain is loaded from the system loader. It supports the following procedures

• cold start-up

• warm start-up (pre-loading of a new package while the old package still provides call handling) in order to meet maximum 3 minutes outage time requirement. No first step loading is done in this task.

• error correction loading with pre-loading in order to meet maximum 3 minutes outage time requirement. No first step loading is done in this task.

Firmware upgrade (BIOS or IPMI) of processor boards is NOT supported within this domain.

Note: In some markets the RAPTOR application is used for remote operations (loading, backups, maintenance). The RAPTOR Application is out of scope for this release.

Server-domain (EABS only)

The server-domain is loaded from its own SCSI device and therefore independent of the call handling and protocol-domain.


Alcatel 5020 MGC

Package Replacement / Context Dependent Loading

A package replacement procedure within this release is not supported.

• Because of a context dependency between all domains, it could be required to reload all domains at 'once'. A manual procedure is necessary to update the affected domain in the right sequence.

• The server-domain (e.g. EABS) must be able to handle an old and a new package in parallel.

OA&M

This chapter deals with the OA&M concept for the ALCATEL 5020 MGC. There will be other NEs besides this one in the NGN that have to operated – but they are out of scope of the description below.

This chapter deals with OA&M as it is provided for the multiple domains that are available inside the ALCATEL 5020 MGC.

The ALCATEL 5020 MGCNE consists of four domains (OAM point of view - see figure below):

1. call engine domain

2. ITCE domain

3. Server domain (EABS)

4. hardware-management (ChassisManager)


Alcatel 5020 MGC

Figure 21. ALCATEL 5020 MGC OAM concept

1. call engine domain: The CMC can access the call engine-domain via OAMCEs only. LINUX kernel functionality provides address of the internal IP addresses known by the PLDAs to the external IP addresses known by CMC.

– to be operated remote from CMC

– to be operated from OWP as remote CMC terminal

– the features are handled via TOFs and TPs

2. ITCE domain: The ITCE-domain is operated via the WEBEM interface on the OAMCEs.

– ITCEs can only be addressed via the OAM agent (cTCA rack)

– for the operator's interface GUIs have been developed

– the Web interface of the OAM agent can be addressed by OWP (via the integrated Browser) or by CMC


Alcatel 5020 MGC

3. Server domain: Access to the server-domain (EABS) is done directly via their RTM.

– EABS: Access to the EABS from CMC is done directly via their RTM.

—to be operated remote from CMC

—to be operated locally from OWP via EXCEED to EABS

—The Ethernet ports at the own RTM of the EABS are also used for handling of the CDRs.

—For EABS an X-Window surface (EXCEED) is used

– others: Access to other servers is done like to the MGC in general via the ‘OAM-Network’.

—for the other servers the WEBM surface is used

4. hardware-management domain:

– to be operated remote via TELNET session (also from OWP)

The local OWP is directly connected to the ALCATEL 5020 MGC via

– 2 Ethernet interfaces (one to each plane of the internal fabric switch - different chassis)

Note: A third Ethernet interface is directly connected to the customer IP network to access applications on the CMC. This interface can as well be used to access OAMCEs via their RTM ethernet interface.

As COM3 of both OAMCEs is connected to the FlexConsole software installation can be controlled without serial interfaces. The Ethernet interfaces directly connected to the ALCATEL 5020 MGC are used for:

• Maintenance and installation activities on the ALCATEL 5020 MGC

• BACKUP server functionality on local OWP for call engine and MGC part.

The figure below shows the connectivity of local OWP and CMC to ALCATEL 5020 MGC.


Alcatel 5020 MGC

Figure 22. Access of CMC and OWP to ALCATEL 5020 MGC - cabling

OAM-features

Mixed mode TPs

There are some tasks, which require OA&M activities on call engine - and ITCE-domain. However inside TPs CMC cannot trigger GUIs in the ITCE domain.

Consistency of data provisioned via ORJs

• synchronization is controlled by the operator or by co-operative management application running at CMC level.


Alcatel 5020 MGC

• There is no synchronisation of system data except for ELM- and some configuration-data. Input files for ELM are by the off-line tool. Later changes have to be done by data patches.

Customer Documentation

• The eDoc of the Alcatel 5020 MGC is an integrated part of the OAM agent. It describes the ITCE part only.

• The customer documentation for call engine is available as OD and can be loaded at a local OWP in the exchange.

What software on local OWP is used to view on-site documentation of call engine part.

Feature continuity

• OAM interfaces

The CMC will support ROMA over TCP/IP to communicate with Alcatel 5020 MGC (OAMCE).

• TOF / TP package

The call engine part of the MGC is operated via TOFs and TPs remote from CMC only. The local OWP accesses the CMC application via "GoGlobal". The CMC is able to handle several call engine releases in parallel..

• CMC functionality

The CMC inherits the functionality of the A1360 SMC. Several applications as (e.g. Alarm view, network element) were enhanced to deal with NGN network elements.

Software management and remote backup is very close related to a customers network and therefore not part of the generic Alcatel 5020 MGC.

Platform-aspects of N7-solution

The following figure shows the principle hardware-configuration of the N7-solution in Alcatel 5020 MGC. Note that it is possible to connect up to 4 E1-links where - in total - up to 32 N7-signalling-links can be handled according to actual requirements.


Alcatel 5020 MGC

More details w.r.t. hardware-items can be found in chapterhardware-components used in the Flex21 Chassis.

Figure 23. hardware-configuration for N7-solution in Alcatel 5020 MGC

The grouping of functions related to hardware-parts can be found in the figure below. Note that MTP1 and MTP2 are coming with the PMC from ADAX (firmware) while MTP3 functionality is ported from the MCCM module (call engine high speed N7 hardware-module running VxWorks) onto LINUX based SLN7S.


Alcatel 5020 MGC

Figure 24. Functional grouping related to hardware-components for N7-solution

This software is considered as OBC-software from call engine-software point of view, which means that SLN7S will have an application-part for loading and data-synchronisation.

Initially the SLN7S uses standard loading procedure for LINUX-CEs as defined in Loading. Afterwards SLN7S will be contacted by an call engine-CE (which is logically the "TCE" in the legacy world - but now implemented simply as a function on any call engine-processor) that will give him additional data (the other way round compared with call engine legacy OBC-loading).

The call engine-CE will have a new data-table that indicates the OBCs via its addresses. This table (which is independent from call engine-routing-tables) translates the LCE-ID of the target "TCE" (whose function may be mapped into any of the new call engine-processor-types) into the PCE-ID of the logically


Alcatel 5020 MGC

co-located OBC. The "TCE" will see from this table's contents which OBCs he has to care about (see following figure for abstraction):

Figure 25. TCE-OBC view - comparison of traditional legacy and new configuration

The new translation-table is to be used as well for specific IPPoE communication that is used between MTP3 part on SLN7S and the logical "TCE"-part that represents the communication partner. For more details on IPPoE see chapterIPPoE (call engine CE ¤ ITCE)

Debugging

The call engine and ITCE-domains do not interfere each other. No common tool to be foreseen.

Access to the softswitch for ALCATEL stuff is granted locally via the local OWP and from remote via MODEM lines (attached to the local OWP) or via WAN to the local OWP.


Alcatel 5020 MGC

If two sessions in parallel are necessary an additional access is possible via a MODEM attachable to the Flexmanager directly or via WAN (OAM-network) directly to the OAM or EABS.

Caution the MODEM at the Flexmanager works only at the active one.

From the local OWP, OAM or EABS the chassis manager (Flexmanager) of the OAM chassis can be accessed via a Telnet-Session (see picture).

Figure 26. Remote debugging concept in Alcatel 5020 MGC

For the call engine domain the following tools are available in this project:

• MPTMON

Note: A new variant of this manual will be created to reflect the commands that are no longer applicable (e.g. treatment of legacy HW)

• Environment Capture Facility

For the MGC domain the following debugging means are available:


Alcatel 5020 MGC

• Server Platform Trace Subsystem Tool: This tool enables tracing on RM, COCO and IPACC nodes. The output is written into Log files on OAM.

Detailed tracing has to be enabled first by setting the trace level per node and process of interest. The executable resides on the OAM.

• tcpdump: This tool allows the tracing of IP-packages on Linux CEs (OAMCEs and diskless ITCEs)

• Ethereal Tool: This tool allows the tracing of IP-packages on the IP network and has to be installed on the local OWP or OAM.

• Totalview: This commercial tool can be used for debugging on application on LINUX CEs.

• GDB (GNU debugging tool)

Measurement data retrieval

Measurement data retrieval from Alcatel 5020 MGC is initiated from CMC. Access to measurement data is different for both domains of the softswitch.

Measurement data for the UNIX domain are extracted each 30 minutes out of the ORACLE database where the measurement subsystem dumps them in.

The extract is written into files that can be retrieved via FTP from CMC. The file format is CSV (comma separated value).

Measurement data on the call engine domain is accessible each 15 minutes from the measurement subsystem.

CMC accesses the measurement subsystem of the call engine domain via FTAM subsystem. The FTAM subsystem is located on RCDS-CEs. As the RCDS-CEs do not provide an external IP interface to the OAM network any FTAM file transfer is routed through the OAMCE. NAT server functionality as part of the LINUX


Alcatel 5020 MGC

operating system (‘iptables’) does the address translation from external IP address of OAMCE with port 102 to internal RCDS IP address., port 102

Figure 27. Alcatel 5020 MGC measurement data retrieval

Alcatel 5020 MGC

Manual_5020MGC_04_04

Documents

Transcript of Manual_5020MGC_04_04