WO2005022829A1 - Architecture de systeme optimisee destinee a la variabilite dimensionnelle - Google Patents

Architecture de systeme optimisee destinee a la variabilite dimensionnelle Download PDF

Info

Publication number
WO2005022829A1
WO2005022829A1 PCT/NO2004/000259 NO2004000259W WO2005022829A1 WO 2005022829 A1 WO2005022829 A1 WO 2005022829A1 NO 2004000259 W NO2004000259 W NO 2004000259W WO 2005022829 A1 WO2005022829 A1 WO 2005022829A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
software
npu
traffic
board
Prior art date
Application number
PCT/NO2004/000259
Other languages
English (en)
Inventor
Reidar Schumann-Olsen
Pål Longva HELLUM
Per Erik Moldskred Nissen
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to EP04775043A priority Critical patent/EP1661306A1/fr
Publication of WO2005022829A1 publication Critical patent/WO2005022829A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
    • H04J3/1605—Fixed allocated frame structures
    • H04J3/1623—Plesiochronous digital hierarchy [PDH]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/16—Time-division multiplex systems in which the time allocation to individual channels within a transmission cycle is variable, e.g. to accommodate varying complexity of signals, to vary number of channels transmitted
    • H04J3/1605—Fixed allocated frame structures
    • H04J3/1611—Synchronous digital hierarchy [SDH] or SONET
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
    • H04J2203/0028—Local loop
    • H04J2203/003—Medium of transmission, e.g. fibre, cable, radio
    • H04J2203/0035—Radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J2203/00—Aspects of optical multiplex systems other than those covered by H04J14/05 and H04J14/07
    • H04J2203/0001—Provisions for broadband connections in integrated services digital network using frames of the Optical Transport Network [OTN] or using synchronous transfer mode [STM], e.g. SONET, SDH
    • H04J2203/0057—Operations, administration and maintenance [OAM]

Definitions

  • the invention relates to communication nodes comprising a number of plug-in units for operation in PDH/SDH microwave transport network and more particularly to highly scalable plug-in units, and a method for operation of the same.
  • the present invention provides a modular and scalable/flexible communication node comprising a number of plug-in units an associated bus architecture and associated functional software adapted to operate in the microwave transport network, where the plug-in units, the associated bus architecture and the associated functional software is adapted for operation as a distributed switching architecture or a centralized switching architecture.
  • a method for configuring a modular and scalable/flexible communication node comprising a number of plug-in units an associated bus architecture and associated functional software adapted to operate in the microwave transport network, where the plug-in units, the associated bus architecture and the associated functional software is configured for either a distributed switching architecture or a centralized switching architecture.
  • Figure 1 shows a simple system illustrating the separation principle
  • figure 2 shows temperature management vs. time/temperature
  • figure 3 shows a simplified view of the passive and active bank
  • figure 13 The TN AMM 2Op Backplane, figure 14 TN BNS ,
  • figure 23 example of a bi-directional 3*64Kbs cross- connection between the two APUs
  • figure 30 ASIC block structure, figure 31 TDM bus redundancy,
  • FIG. 56 Illustration of the various contents of the APU/NPU memory banks
  • figure 60 TN reference network topology.
  • the present invention discloses a versatile highly reliable traffic node with an outstanding availability.
  • Several features of the traffic node will be described separately so as to ease the understanding and readability.
  • the principle behind the software management, the principles behind the temperature control and the principles behind the hardware architecture of the node will be described in separate parts of the description so as to fully point out the advantages of the traffic node according to the present invention.
  • One of the basic ideas behind the invention is to clearly distinguish between traffic and control signals within the node, both on an interboard and on an intraboard basis. Some really advantageous features will be evident due to this separation.
  • a major advantage with the distinct separation between traffic and control is that one will be able to operate traffic independently of the operation of the control part, this is essential for availability, upgrade, temperature control service and maintenance etc.
  • figure 1 a simple system is depicted illustrating this separation and the advantages caused by this separation.
  • the separation implies that in case of too high temperature one can reduce the power drain consumption by disabling the control part/function. Due to the separation of traffic and control this will not affect the traffic. Further, to improve the temperature management the present invention discloses not only the separation of traffic and control, but also stepwise shutdown of the equipment. With reference to figure 2, a two steps' shutdown and recover scenario is depicted, however the principle may be implemented with more than two steps. With reference to the two step shutdown/recover scenario the following cyclic description applies :
  • HTT High Temp
  • OAM operation and management system
  • the system may operate at a higher temperature, thus implying an increased capacity, and a reduced fan dependency
  • the temperature management system may use redundant fans, hence making the only single point of failure the controller board for the fans.
  • redundant fans hence making the only single point of failure the controller board for the fans.
  • the bifurcated architecture described above is to be found on intraboard level as well as on interboard level, further it is to be found within the memory management of the Traffic node according to the present invention.
  • one has two banks, one active and one passive (cf. figure 3), where both are operating with software/hardware versions which are tested and proofed, e.g. called version n.
  • Upgrading from version n to n+1 one will download a version n+1 to the passive bank.
  • a test-run will be executed on this new version n+1 if the test-run does not show any sign of fatal failure with the upgrade software, e.g. may cause loss of contact with the program, a pointer is written to the passive bank making the passive bank the active one and consequently the previous active the passive.
  • a pointer is written to the passive bank making the passive bank the active one and consequently the previous active the passive.
  • TN Traffic Node's
  • the Traffic Node and its environment.
  • the microwave network is the microwave network
  • the TN is among others targeted to work in the PDH/SDH microwave transport network for the LRAN 2G and 3G mobile networks, as shown in figure 5 / however the TN is a versatile node capable of operating both data and telecommunication traffic. It may also operate in IP networks or within Ethernet (cf figure 8).
  • End-to-end connectivity in the TRAFFIC NODE microwave network is based on El network connections, i.e. 2Mbit/s These El network connections are transported over the Traffic Node microwave links.
  • the capacity of these microwave links can be the following: • 2 El, i.e. 2x2Mbit/s • lxE2, i.e. lx8Mbit/s • 2xE2, i.e. 2x8Mbit/s • 1XE3+1XE1, i.e. 34Mbit/s+2Mbit/s • lxSTM-l, i.e. 155Mbit/s
  • the microwave network consists of the following network elements : • Traffic Node E according to the present invention providing: • Medium Capacity Radio, 2x2-34+2Mbit/s PDH access on El, E2 and E3 levels Traffic Node High Capacity providing: High Capacity Radio, 155Mbit/s Optical/electrical STM-1 access • Traffic Node comprising: El cross-connect Generic network interfaces: PDH access on El level SDH access through optical/electrical STM-1 • Traffic Node E compatible Medium Capacity Radio • Traffic Node E co-siting solution
  • FIG. 7 shows that the Traffic node according to the present invention can be managed by: • A Local Craft Tool (EEM) . This is computer with a web browser that connects with the Embedded Element Manager (EEM) . • Remotely by Traffic Node Manager, using a combination of both EEM and SNMP interface. • Remotely by an operator specific Operations Support System (OSS) or Network Management System (NMS) .
  • EEM Embedded Element Manager
  • OSS Operations Support System
  • NMS Network Management System
  • DCN Communications Network
  • PGP Point to Point Protocol
  • OSPF is used as a routing protocol.
  • Ethernet-based site-LAN connection to the TN the TN DCN can be connected to any existing IP infrastructure as shown in figure 8.
  • TN communicates with the following services:
  • DHCP for assignment of IP addresses to equipment on the site-LAN, e.g. the EEM.
  • the TN provides DHCP relay functionality for this.
  • the TN uses NTP for accurate time keeping
  • the EEM is a PC that communicates HTML pages containing JavaScript over HTTP with the Embedded Element Manager (EEM) in the TN by means of a web browser.
  • EEM Embedded Element Manager
  • the TN is based on a modular principle where HW and SW application can be added to the system through the use of uniform mechanisms refer to figure 9.
  • the TN Basic Node provides re-usable HW and SW components and services for use by application designers.
  • Software of the TN BN and various applications, like MCR and STM-1, are integrated by the well defined interfaces. These interfaces are software function calls, file structures, hardware busses or common hardware and software building blocks .
  • the well defined interfaces enable the application flexibility in design. As long as they conform to the interfaces there is a high level of freedom in how both software and hardware are implemented.
  • the distributed switching hardware architecture allows for the size of the node to scale from large node (20 APUs) down to small nodes (1 or 2 APUs) .
  • the alternative centralised switching architecture allows for scaling up to higher capacity where the distributed architecture doesn't allow for capacity increase.
  • a principle used to improve robustness is to separate the control and traffic system of the TN.
  • the control system configures and monitors the traffic system whilst the traffic system routes the traffic through the TN. Failure and restarts of the control system will not influence the traffic system.
  • a principle that provides robustness to the TN is "no single point of failure" in the traffic system. This means that the traffic is not disturbed as long as one failure occurs in the system. This is realised by redundant traffic busses, optional redundant power and traffic protection mechanisms. More details on the redundancy of the various system components can be found in the following architecture sections.
  • the architecture allows for application to implement redundancy, like MSP 1+1 for the STM1- application or 1+1 protection for the MCR link.
  • the principle of in-service upgrade, i.e. upgrade without disturbance of traffic, of both software and hardware functionality in the Traffic Node is applicable for: Upgrade of all software in the Traffic Node to a new System Release Hot-insertion of PIUs that are automatically upgraded to software matching the existing System Release of the Traffic Node. Hot-swap of PIUs where a new PIU inherits the configuration of the old PIU.
  • Every APU in the traffic node are handled by one application.
  • One application can however handle several APUs, even of a different type.
  • Basic Node provides: • Generic/standard network interfaces • PDH Networking • PDH multiplexing • Fault Propagation (network level) • Cross-connection • Network protection, i.e. SNCP • Network layer diagnostics like loops and BERT • DCN handling, i.e. IP and its services like routing, FTP etc. • Equipment Handling on node and PIU levels • Maintaining consistent configuration of the node, e.g. a System Release. • Means to an application to communicate with /control its APUs.
  • Figure 10 shows a complete overview of the TN architecture.
  • TN BN In a TN there will be one component called TN BN and several different instances of the TN Application component. Both kind of components can consist of both hardware and software.
  • the TN -software consists of three major software component types :
  • BNS Basic Node Software
  • ADS Application Device Processor Software
  • TN BNS and the various applications communicate through the Basic Node Functions (BNF) interface.
  • BNF Basic Node Functions
  • This interface consists of two protocols: • AgentX that together with its SNMP master and SNMP sub-agents acts as an object request broker used for realising an extensible SNMP agent.
  • the SNMP sub- agents subscribe with the SNMP-master in the BNS to receive the SNMP requests that the applications wants to handle.
  • the SNMP master in its turn acts as a postmaster that routes SNMP requests to the SNMP sub- agents in the applications.
  • CLI based on the same principles as AgentX, but then for the CLI protocol. This interface is used for CLI requests, collection of configuration data for persistent storage and configuration at start-up.
  • BNF Basic Node Functions
  • AIM Application Interface Module
  • the Traffic Node's hardware architecture consists of Basic -Nqde Hardware (BNH) in which Application Plug-in-Units (PIU) e.g. APU can be placed.
  • BNH Basic -Nqde Hardware
  • PIU Application Plug-in-Units
  • the BNH provides various communication busses and a power distribution bus between the various PIUs in the TN.
  • the busses them selves are part of the backplane, i.e. TN BN, whilst PIUs interface to these busses through TN BNH Building Block (BB) as shown in figure 12.
  • BB BNH Building Block
  • FIG 13 shows the busses and their location on the AMM 20p backplane.
  • SPI is a low speed synchronous serial interface used for equipment handling and control of: • APU cold and warm resets • status LEDs and block received signals (BRS) • Inventory data, like product number, serial number, asset identifier etc. • Temperature supervision • Power supervision • BPI disable/enable • PCI fault handling • General purpose ports The SPI BB is implemented in a Complex Programmable Logic Device (CPLD) . The SPI bus and BBs are part of TN' s control system.
  • CPLD Complex Programmable Logic Device
  • PCI Bus is a multiplexed address/data bus for high bandwidth applications and is the main control and management bus in the TN-Node. Its main use is ⁇ communication between NP Software (NPS) and Application DP Software (ADS), TDM BB and ASH like Line Interface Units . (LIU).
  • NPS NP Software
  • ADS Application DP Software
  • TDM BB ASH like Line Interface Units .
  • LIU Line Interface Units .
  • the PCI bus is part of the control system.
  • the PCI BB is implemented in a Field Programmable Gate Array (FPGA) .
  • TDM Bus is a multiplexed address/data bus for high bandwidth applications and is the main control and management bus in the TN-Node. Its main use is ⁇ communication between NP Software (NPS) and Application DP Software (ADS), TDM BB and ASH like Line Interface Units . (LIU).
  • the PCI bus is part of the control system.
  • the PCI BB is
  • the TDM bus implements the cross-connect' s functionality in the TN. Its BB is implemented in an Application Specific Integrated Circuit (ASIC). Typical characteristics are: • 32 port per ASIC, where each port can have a capacity of 8kBit/s to 45MBit/s • The bus with TDM BBs provides a non-blocking switching capacity of -400 El ports (800Mbit/s), i.e. 200 bidirectional cross-connects. • Redundant switching function • Cross connection • Routing DCN to the IP router on the NPU. • Support for PDH synchronization hierarchy.
  • ASIC Application Specific Integrated Circuit
  • TDM bus and its BBs are part of the traffic system.
  • the power distribution system may or may not be redundant, this will depend on the specification wanted, however one has to install two PFUs, as being part of the traffic system. DC/DC conversion is distributed and present at every PIU.
  • the PDH synchronisation bus provides propagation of synchronisation clock between PIUs as well distributes the local clock.
  • the SDH synchronisation bus provides propagation of synchronisation clock between PIUs .
  • BPI-2 and BPI-4 can be used for application specific inter- APU communication.
  • the communicating APUs must then be located in the same group of 2 respectively 4 slots, i.e. located in specific neighbouring slots in the TN rack.
  • the BPI busses are controlled by the application.
  • the Point-to-Point (PtP) bus is meant for future central switching of high-capacity traffic.
  • the programming bus is intended as JTAG bus for programming the FPGAs in the node .
  • the TN BN can be divided into the two components, TN BNS, (TN Basic Node Software) and TN BNH (TN Basic Node Hardware) .
  • the TN EEM is not a part of the TN BN in the product structure, in practice it is a necessary part when building TN Applications that needs to be managed by the EEM. That is why in the rest of this description the TN EEM is regarded as a part of TN BN.
  • the TN BNS realises control and management of the TN BN and its TN BNH BB that reside on the various APUs. Therefore it is part of TN' s control system, and delivers its services to the TN Applications. It is part of the TN control system and not of the traffic system.
  • the main Basic Node architectural concept is its distributed nature.
  • Each sub-agent handles its part of the SNMP object tree or its sub-set of the CLI commando's.
  • the TN BNS provides the following external interfaces:
  • HTML/HTTPS the embedded manager, TN EEM, sends HTML pages to a browser on the operator's computer.
  • HTTPS is used for providing encryption especially on the username and password of the HT pages.
  • DCN Services various IP protocols such as: • DNS • NTP for synchronisation of the real-time clock • FTP for software upgrade and configuration up/download • Telnet for CLI configuration • DHCP for TN acting as an DHCP relay agent
  • the TN can be managed through either the SNMP interface or a WEB based embedded manager.
  • This embedded manager consists of two parts:
  • TN EEM A WEB-server located in the TN BNS able to execute PHP script • HT pages with embedded PHP script, denoted as TN EEM. These pages can be divided into three categories: • Framework, generic pieces of HTML/PHP code part of the TN BN • Basic Node management, part of TN BN • Application management, AWEB, part of the TN application
  • the WEB server receives an URL from the EEM and retrieves the page. Before sending the page to the EEM it interprets the PHP code, which is replaced with the return values of the PHP call.
  • the WEB-server interfaces to the SNMP-master in the TN BNS by executing the PHP SNMP function calls.
  • the TN EEM is part of the TN control system.
  • the TN EEM interfaces to the WEB-server in the TN BNS through HTML with embedded PHP script.
  • the TN BNH consists of (refer figure 16) :
  • the NPU also provides:
  • PFU Power Filter Unit providing power to the other PIUs.
  • FAU although not a real PIU in the sense that it is not coupled directly to the busses in the backplane.
  • the BNS-BNH interface is register and interrupt based.
  • Figure 17 shows the internal components of a TN Application that will be discussed in the following sections:
  • Application Node Software is the software needed for the application running on the NPU, i.e. on Linux OS.
  • ADS Application Device Software is the software running on the processor on the APU, in case a processor is present.
  • APU Application Plug-in Unit
  • APU Application Plug-in Unit
  • the application software consists of (cf. fig. 18):
  • ADS is located on the APU if the APU houses one or more processors. -
  • Figure 19 shows the internal ANS architecture, where the AIM, Application Interface Management module, houses SNMP and CLI sub-agents that are responsible for the application specific SNMP objects/CLI commands.
  • the ADD, Application Device Driver contains application specific device drivers and real-time ANS functions.
  • the architecture of the ADS is very application specific and interfaces only to the ANS and not to any part of the TN BNS directly.
  • the BNF Basic Node Function
  • ANS ANS and BNS. It comprises 3 sub-interfaces:
  • CLI protocol for the AIM for CLI sub-agent to CLI- master communications. Used for e.g. persistent configuration storage.
  • AgentX protocol for the AIM for SNMP sub-agent to SNMP master communications. Used for SNMP configuration and alarms etc.
  • BNF Signals for message based communication between AIM and BNS. This can in principle also be used between other processes.
  • the application specific WEB pages are located on the NPU. These pages contain HTML and PHP script that is executed by the WEB-server in the TN BNS.
  • the WEB-server executes the PHP SNMP function calls and talks to the SNMP master, which its turn delegates 'the request to the SNMP sub-agent residing in the AIM of the respective ANS. Interface towards TN EEM
  • the AWEB interfaces to the rest of the TN EEM through a naming convention for the respective HTML/PHP files.
  • the hardware of the application is called an APU,
  • the application specific hardware uses the TN BNH BBs, for interfacing to the TN BNH and so to the other PIUs in the TN as shown in figure 21.
  • Figure 22 shows how and APU is build-up from Application Specific Hardware (ASH) and the TN BNH BBs. Mechanically The APU interfaces mechanically with the TN BNH rack and backplane.
  • ASH Application Specific Hardware
  • Equipment comprises of: • Installation and repair • Restart • Supervision • Inventory and status • Node Configuration Handling
  • the SPI bus is used for scanning the TN for PIUs
  • Hardware inventory data of these PIUs is retrieved from the SPI BB by the TN BNS EHM, through a SPI device driver.
  • This data is represented in both the ENTITY-MIB as well as the TN- MODULE-MIB handled by the EHM.
  • Inventory data on the software on the various APUs is handled by the corresponding ANS that holds its part of inventory table in the TN-SOFTWARE-MIB.
  • Equipment status on the TN and PIUs is partly controlled through the SPI BB for faults like high temperature, restart and board type.
  • Other possible faults on equipment are communicated from ANS to EHM in the BNS. These faults will often be communicated over PCI from an ADS to its ANS.
  • Installation of a new TN is regarded as part of equipment handling, but is actually a set of sub-functionalities like DCN configuration, software upgrade password setting (SNMP Module) and configuration download under direction of the Equipment Module.
  • SNMP Module software upgrade password setting
  • Hot-swap is supported to enable plug & play on all PIUs except NPU. It uses both SPI and PCI busses and is the responsibility of the Equipment Module in the BNS. Plug & play for PIUs that have to be repaired is realised by saving the PIUs configuration for ⁇ s period of time after it has been removed. A new PIU of the same type can then inherit this con iguration when inserted within ⁇ 6 after removal .
  • the node and APUs can be cold and warm restarted as a consequence of external management requests or software/hardware errors. Warm restarts will only affect the control system whilst a cold restart also affects the traffic system. Cold and warm restarts of APU are communicated using the SPI. Node configuration persistence
  • Running configuration is stored persistent in the TN' s start-up configuration file in flash memory.
  • the CLI master in the TN BNS invites all TN BNS modules and the AIMs in the ANS to submit their running configuration to the startup configuration file.
  • Saving the running configuration will also lead to saving the new start-up configuration file to an FTP server using the FTP client in the TN BNS.
  • the following sub-systems are supervised for software/hardware errors: • NPU Processes by a watchdog reporting errors in an error log available to management. • ANS supervision; • the Equipment Module will poll the AIM to check whether it is alive, using a BNF call • the AIM monitors its ANS internal processes • the ANS is responsible for supervision of the ADS processes and DP-NP communication links (SPI & PCI) • PCI bus • SPI bus • APU supervision of power and temperature is supervised by the BNS using the SPI. • FAN Supervision through SPI by the BNS.
  • Traffic handling functionality deals with traffic handling services offered by the TN BN to the TN Applications.
  • the following sections describe sub-functions of traffic handling.
  • Cross-connections between interfaces, offered by applications to the TN BN, are realised in TN BNH by the TDM bus and the TDM BBs, under software control by the traffic handler in the TN BNS.
  • Applications register their TDM ports indicating the speed. After this TN BN can provide cross-connections with independent timing of the registered ports.
  • Bit pipes offered by applications on TDM ports are chopped in 64Kbps timeslots which are sent on the TDM bus and received by another TDM BB on the bus and compiled into the original bit-pipe.
  • Figure 23 shows an example of a cross- connection.
  • SNCP provides 1+1 protection of connections in the network, offered by the TN Applications on TDM ports, over subnetworks. Outgoing traffic is transmitted in two different directions, i.e. TDM ports, and received from one of these directions. Faults detected on the receiving line cause the TN BNS to switch to the TDM port from the other direction. As with cross-connections, SNCP is implemented in TN BNH by the TDM bus and TDM BBs. TN BNS traffic handler controls management of the SNCPs .
  • Equipment protection is provided by TN BN in the form of the TDM bus, the TDM BBs and BNS. It provides protection between two APUs based on equipment failures. An application can order this service between to APUs from BNS. BNS will then set-up the TDM BBs on both APUs and switch from one TDM BB to the other upon an equipment failure .
  • the BNS and more precise the ASIC DD, collects performance report on TDM ports every ⁇ ⁇ , from either the TN Application, the ADD in the ANS, or from the TDM BB. This data is reported further to the Performance management in the traffic module of TN BNS.
  • the TN BNS offers the service to update current and history performance records of the TDM port based on the ⁇ ⁇ reports. These performance records are available to the ANS to be presented to management in an application specific SNMP MIB. To have synchronised PM intervals applications will collect their application specific PM data based on the same ti signal as the BNS.
  • the TN BNS or more specific the traffic module, also keeps track of performance threshold crossings in case of TDM BBs.
  • the TN BNS provides a BERT service to applications.
  • a PRBS can be sent on one port per ASIC per APU concurrently and a BER measurement is performed in the receiving direction.
  • the TN BNS also realises connections loops on the TDM bus by programming the TDM BB to receive the same time-slot as transmitted.
  • FIG. 25 An overview of the alarm handling is illustrated in figure 25.
  • Defects in the TN that need to be communicated over the SNMP interface to a manager, are detected by the corresponding resource handler.
  • the resource handler e.g. an ANS or BNS process
  • the defect will be reflected in the SNMP status objects hold by the ANS.
  • Alarm suppression is performed in the TN in order to prevent alarm storms and simplify fault location. For this purpose defects for various sources are correlated. An application can do this for its own defects but can also forward a defect indication to the BNS in order to suppress BNS alarms.
  • a general rule is that equipment alarms suppress signal failure alarms who in their turn suppress performance alarms. Also lower layer (closer to the physical layer) alarms will suppress higher layer alarms.
  • the AIM will report an alarm for the defect to the Alarm handler functionality in the SNMP module in the BNS. Alarms will be stored in a current alarm list and a notification log. It is then up to the manager to subscribe on these notifications that are sent a SNMP traps in IRP format.
  • the software upgrade functionality allows the operator to download a new System Release, which consists of a NPU Load module and several DP load modules, on a node per node basis. Topology and available DCN bandwidth may allow for several nodes to be upgraded concurrently. However, which upgrade strategy is used is up to the NMS .
  • the TN BNS upgrades its self plus all ANS. The ANS are responsible for upgrading the corresponding DPs using the TN BNS's FTP client and RAM disk as temporary storage medium before transporting the load module to all the APUs over PCI to be stored into the APU passive flash memory. This happens while the software in the active flash memory is executed.
  • the software upgrade process is fail-safe in that respect that after a software upgrade the operator has to commit the new software after a test run. If a commit is not received by the node, it will fall back to the old software. It is also possible for the node to self execute a rudimentary test without the need for the operator to commit .
  • the reliability calculation for the TN connections are based on the following prerequisites:
  • correction factor is based on actual experience data and compensates for the difference in use of a commercial and a military system.
  • a military system is normally used for a short interval with long periods of storage whereas a commercial system is in constant use.
  • connections are bi-directional connections on one interface type (fig. 26) .
  • the calculations are related to a 40 °C ambient component temperature.
  • the TN-E estimates are all done at 40 °C and the correction factor may include, temperature compensation if the actual temperature is different from this. Therefore the TN estimates are set at the same temperature.
  • the correction of the temperature at some units is related to the specific cases where the units are consuming little power and thus have a relative temperature difference with respect to the other units. PIU function blocks
  • the control part represents any component whose failure does not affect the traffic.
  • the traffic part is components whose failure only affects the traffic.
  • the common part is components that may affect both the traffic and the control.
  • control block and the traffic block are repaired individually through separate restarts.
  • figure 30 shows ASIC block structure.
  • the failure rate of an El connection through the ASIC is not the same as the MTBF of the circuit.
  • the ASIC is divided into a port dependant part and the redundant cross- connect.
  • the failure rate of one port (including scheduler) is 20% of the ASIC MTBF and the TDM bus (cross- connect) is 30% of the ASIC MTBF.
  • the model for the redundant cross-connect can be seen in figure 31.
  • the TDM bus redundancy improves the failure rate by a factor of more than 50000. This makes the TDM bus interface insignificant and it is therefore omitted from the calculations.
  • the ASIC contribution to the El failure rate is then 20% of the ASIC MTBF. This contribution is the port reference in the general availability model.
  • the AMM 20p can be equipped with or without redundant PFUs .
  • the two models for this are shown in the two figures 32 and 33 ( Figure 32 AMM 20p with redundant power distribution, figure 33 AMM 20p without redundant power distribution) .
  • the fan (FAUl) consists of one fan control board (FCB) and 3 fans. If one of the 3 fans fail a notification will be sent and the two remaining fans will maintain cooling in the repair interval.
  • FCB powers all 3 fans and is therefore a common dependency.
  • the power distribution in the AMM20p is redundant but the node may be equipped without redundant PFUs if so desired.
  • the power distribution has-a>very high reliability even without the redundancy. This option is therefore generally viewed as a protection against failure of the external power supply rather than the node power distribution.
  • U 2/3 Ui 2 (3 - 2U ⁇ ) where O ⁇ is the unavailability of one branch.
  • the model for the AMM 6p is shown in figure 34.
  • the fan (FAU2) consists of one PCB with 2 fans. If one of the 2 fans fail a notification will be sent and the remaining fan shall maintain cooling in the repair interval. There is no dependency to a control function for the switchover between the redundant parts for the fans.
  • the level of redundancy in the basic node depends on the type of basic node.
  • The- cross-connect is redundant. This is always • in operation and may not be turned off.
  • the line and equipment protection schemes vary from application to application. Generally the line protection is much quicker and is intended to maintain connectivity during line faults. The requirement is therefore that the traffical disruption as a consequence of line faults shall be less than ⁇ 4 , typical msec range . The equipment protection is allowed to be slower ( ⁇ 5 typical a few sec.) as the MTBF of the protected parts are much better. Note that the line protection will repair many equipment faults as well.
  • Figure 36 shows a simplified model, which is used for the calculations described in the following.
  • This model is used as the basis for the actual calculations as the separation of the blocks in the general model may be difficult.
  • This model is used as the basis for the actual calculations as the separation of the blocks in the general model may be difficult.
  • This model is used as the basis for the actual calculations as the separation of the blocks in the general model may be difficult.
  • a board that has the SDH multiplexers and the SOH termination in the same circuit.
  • the line protection and the equipment protection availability are difficult to calculate as the circuits combine the functions. This is the case even though the implementation is clearly separated.
  • the redundant cross-connect is omitted from the calculations.
  • the APU port is 20% of the ASIC -The traffic functions of an APU is then used with 20% of the ASIC as the basis for the calculations.
  • Figure 37 shows the model for unprotected interfaces:
  • This model is the series connection of the Basic Node and the traffic part of an APU. Note that for unprotected interfaces the Basic Node is assumed to have non-redundant power.
  • the MMU2 MTBF calculation is divided not only with respect to control and traffic but also with respect to the use of the PIU.
  • the ASIC and Ella are not in use. Faults will then not be discovered in these components and the components are therefore not included in the calculation.
  • the SMU2 MTBF calculation is divided not only with respect to control and traffic but also with respect to the use of the PIU.
  • the SMU2 is used as a protection unit then the line interfaces are not in use. Faults will then not be discovered in these components and the components are therefore not included in the calculation.
  • STM-1 models are the same as the generic TN models. They are therefore not repeated here. In the following it is referenced to two STM-1 models, each of them shown in separate figures
  • LTU 16x2 models are the same as the generic TN models. They are therefore not repeated here. In the following it is referenced to two E-l terminal models, each of them shown in separate figures. • El terminal 1+1 (SNCP), figure 44.
  • the TN equipment handling is based on a few important principles :
  • the traffic system is required to be redundant configurable. It shall withstand one failure. It is assumed that the failure will be corrected before a second failure occurs. The fault identification is therefore required to be extensive. If a fault cannot be discovered it cannot be corrected.
  • the system is required to have the control system separated from the traffic system.
  • the reason for this is that:
  • the control system can be non-redundant. A failure in the control system will not influence the network connectivity. This greatly reduces cost and complexity. • It simplifies in service upgrade. The control system can be taken out of service to be upgraded without any traffic impact.
  • the control system may be reset and any kind of self-test (within the control system) may be performed. This allows for self-test that have a high likelihood of providing a correct fault localisation to be executed.
  • the system shall be in service upgradeable. This means that without disturbing the established traffic it shall be possible to:
  • the TN is prepared for NPU redundancy. This is to allow for:
  • the power supply is a prerequisite for operation of the node. Redundant power inlet and distribution is vital in order to withstand one failure.
  • the two power systems shall both be active sharing the load.
  • a failure in the power system shall not result in any disturbance of traffic or control and management systems.
  • Double power inlet enables power redundancy in the site installation.
  • Redundant PFU remove all possible single point of failure in the unit. • Redundant PFU enables replacement of a PFU without any disturbance.
  • the equipment handling in TN uses the SPI bus in the node as a central component therefore some of the main SPI functionality is described here.
  • the SPI bus is a low speed (approx. 1 Mbit) serial synchronous bus that is mandatory on all TN boards.
  • the bus is controlled by the NPU. It is a single master bus over which the NPU may execute a set of functions towards the PIUs. These functions are:
  • the BNS will at start-up pass on to the applications the information found on the APUs SPI block. I.e.: the BNS will receive the temperature thresholds and will need to check them for validity, if incorrect change them to default values. The BNS will need to handle the NPU and PFU in a similar manner.
  • the SPI interrupts will result in a trap to the ANS.
  • the ANS may in addition read and write to the SPI functions. This may serve as a means for a very low speed communication between the ANS and the APU (use of APORT) .
  • the ANS can give the APU access to the SPI EEPROM by enabling bypass. This functionality is intended to be used for the redundant NPU solution. It may cause problems for the BN if this function is used by an application as the NPU looses the EEPROM access.
  • the node has the following types of restarts:
  • Restarts may be used for repair.
  • a self-test that fails in a warm restart shall never result in a cold restart. This would lead to a situation where a control system failure could result in a traffic disturbance.
  • PCI access to the ASIC will lead to a cold repair.
  • a restart that affects the NPU shall not change the state of any LEDs on any other boards.
  • An APU with a service LED on shall not have the LED turned off by an NPU restart.
  • the board removal interval is likely to become longer but the state of the LEDs shall not change.
  • a restart that affects the NPU shall give a PCI reset.
  • the PCI reset shall be given both before and after the NPU executes the restart.
  • the node warm/cold and NPU cold restart restores the configuration file.
  • the LED will stay lit for a first period of ⁇ 2 (e.g. 60 sec), board removal interval/timer. During this time the board may be safely removed.
  • ⁇ 2 e.g. 60 sec
  • an APU If an APU is removed it may be replaced during a second interval of ⁇ 6 (e.g. 15 min), board replacement interval/timer. If a new board of the same type is inserted into the same slot during this interval it will be configured as the previous board and will be taken into service automatically.
  • ⁇ 6 e.g. 15 min
  • the procedure for removing a board shall thus be:
  • the board can be removed within a period ⁇ 2 and then if desired it could be replaced within a period ⁇ 6 .
  • the NPU does not have a HW warm reset signal asserted, but it is in a passive equivalent state.
  • the NPU When the NPU enters the board removal interval it will execute a PCI reset. This is done so as to ensure that if the NPU is replaced the NPU cold restart will be done without a lot of PCI bus activity. It is also done to ensure that the link layer protection mechanisms are in operation during the NPU unavailability. If the APUs where placed in warm reset the MSP 1+1 of an LTU 155 board would become inactivated.
  • TN NE can be installed with or without power redundancy. Loss of power result in the following notifications:
  • the NE operational status shall be set to: major/power failure
  • the PFU operational status shall be set to: critical/hardware error
  • TN NE can be installed with or without FAN unit.
  • the BNS When the BR in the front of the board is pressed, the BNS will inform the application (ANS) that the board should be taken out of service.
  • ANS application
  • the application When the application is ready, it will report to the platform that the board can now be removed.
  • the BN will then deallocate the PCI device drivers for the board and light the board's yellow LED.
  • the BNS shall then place the APU in cold reset so as to avoid signals from a board which is now unavailable to the ANS.
  • Running Configuration of a board under repair will be lost if: The node powers down.
  • the node/NPU restarts.
  • the board is not replaced within the board repair interval.
  • Another type of board is inserted in the slot.
  • the board repair timer expires the board will be removed from running configuration and running configuration will be saved in the start-up configuration, i.e. the board can no longer be replaced without loss of the configuration.
  • the applications are responsible for the BPI handling.
  • the BPI interfaces can be enabled by the applications if required.
  • the BPI bus shall be used by the ANS as follows:
  • an ANS has 2 boards connected to the 2BPI it may be enabled. If the application with an enabled 2BPI bus has less than two boards on the bus it shall be disabled at the expiration of the board removal timer.
  • an ANS has at least 3 boards connected to the 4BPI it may be enabled. If the application with an enabled 4BPI bus has less than two boards on the bus it shall be disabled at the expiration of the board removal timer.
  • PtP BPI shall be disabled.
  • the BPI busses are disabled as a consequence of a node or APU cold reset.
  • Node installation Installation of a new node (Node installation) .
  • the node doesn't have DCN links up and/or DCN configuration is wrong. I.e. the node is not accessible from a remote management site.
  • node installation mode There are two ways to enter node installation mode: a. through pressing the BR button after node power-up (Use cases 1 to 3 above) . During this period the red and yellow LED on the NPU are on. b. in case there is no configuration file present at restart . Node installation mode has priority over NPU installation mode. That is to say that if a condition for node installation mode occurs, even when NPU installation mode was active, the former mode will be entered.
  • NPU installation mode As there are four ways to enter NPU installation mode: a. Pressing the BR in the installation mode entry interval after NPU power-up (Use case 4). During this period the red and yellow LED on the NPU are on. b. There is no configuration start-up file present on the NPU (Use case 4) . c. The software on the NPU doesn't match the System Release described in the configuration file and the node fails to upgrade. d. There is incompatibility between a SR (Software Release) and the Backplane type (Use case 4) .
  • SR Software Release
  • Use case 4 Backplane type
  • Both installation modes can always be left by pressing the BR.
  • a automatic save of the running configuration to the start-up configuration is always performed.
  • LCT shall always be directly connected whilst a NPU or a node is in installation mode.
  • the node has a default first IP address.
  • a DHCP server is' running that provides the LCT with a second IP address. • Default passwords are valid
  • IP router function is disabled • Operational status of the node shall be set to operational status "reduced service” and node equipment status "installation mode” and the yellow LED on the NPU shall be flashing (1 Hz) . • No 'save' time-out and manual 'save' not possible through the LCT.
  • IP-address of the FTP as specified in the MIBs is ignored and the second IP address is always used.
  • the operator Since the configuration stored on the NPU may be unknown the operator is offered to delete the configuration, if one exists and return to factory settings. This means that the operator will have to perform a software upgrade in order to get the SRDF in the node. In the case where a node is installed traffic disturbance is not an issue. A node power-up followed by an installation mode entry can therefore do a hardware scan to detect all APUs. The NE can then enable MSM/LCT access to the MCR application.
  • the TN NE is connected to the IPv4 based DCN through either PPP links running over PDH/SDH/MCR links or Ethernet.
  • the SDH STM-1 links have a default capacity PPP link on both the RS and the MS layer, no configuration is needed for that.
  • For DCN over El and MCR configuration is needed.
  • a PPP link needs to be setup over an El.
  • MCR For MCR however frequencies have to be configured and antennas need to be aligned on both side of a hop. The latter requires installation personnel to climb in the mast, which due to logistics needs to be performed directly after hardware installation. For the MCR set-up the MSM must be launched. After MCR set-up is performed minimally required DCN, security and Software upgrade set-up can be either configured through the download of a configuration file or manually.
  • the configuration file indicated in the automatic set-up is appended to the running configuration in order to keep the previous MCR set-up.
  • the node will perform a save of the configuration and enter normal operation.
  • the operator can replace the NPU without disturbing traffic, except for traffic on the NPU.
  • he has to be on site with a configuration file of the defect NPU.
  • This configuration file can be obtained from a remote FTP server where the node has stored its configuration before. Or he can get it from the defect NPU in case this is still possible.
  • the operator Since the node will be in installation mode while downloading the configuration file, i.e. has the first IP address, the operator has to move the old configuration file from the directory named by the IP address of the old NPU to the directory named by the first IP address.
  • the NPU repair use case is illustrated in figure 47. After the old NPU is removed and the new one is plugged in, the operator has to press the BR to enter installation mode.
  • NPU installation mode will be entered. Wrong NPU Software will automatically lead to entering the NPU installation mode.
  • the configuration file Since traffic is not to be disturbed the configuration file is not loaded nor is a hardware scan performed. Since the username and password for the FTP server are set to default the user is asked to enter the username and password he wants to use. This prevents the operator of having to define a new 'anonymous' user on the FTP server. After the operator has specified the name of the configuration file the node will fetch the file from the FTP server on the locally connected LCT laptop. The SNMP object xfConfigStatus is used to check if the transfer was successful .
  • the node After that the installation mode is left and the node is warm restarted . Upon start-up the node will, if necessary automatically update the software according to the downloaded configuration file.
  • the node will perform a hardware scan and load the start-up configuration file. Subsequently the operator can change ' the passwords and leave installation mo ' de.
  • This alternative is used when the user wants to force a NPU SW rollback to the previous SW installation. This alternative shall only be used if a SW upgrade has been done to a SW version, which in turn has a fault in the SW upgrade that prevents further upgrades.
  • Hardware of the new node must match the old one exactly. Only APUs placed in the same location will be able to get the previous configuration from the configuration file.
  • the procedure for board removal is as follows (cf. figure 50) :
  • the remove board request will time out and the board will be activated with the running configuration.
  • the BN will inform the application about the new APUs.
  • the APU shall be given a default configuration. For a new inserted board notifications are only enabled for board related notifications, not traffic related notifications .
  • the node will hold the running configuration for a board for a period ⁇ 6 after this the board has been removed from the slot. This includes that all alarms will stay active until either the board is completely removed or the new board clears the alarms .
  • the installation personal then have a period ⁇ 6 for exchanging the board with another of the same type.
  • SW upgrade can then be carried out from a file server or from the LCT.
  • the NMS is notified when the fan is removed / inserted.
  • the TN NE has been prepared for PCI FPGA reprogramming.
  • the PCI bus has a programming bus associated with it. This bus is a serial bus that may be used by the NPU to reprogram the PCI FPGAs on all the PIUs in the node. This bus is included as an emergency backup if the PCI FPGAs must be corrected after shipment.
  • the board When a new board is entered into the node, the board shall be activated and brought into service. A notification will be sent to the management system if a new board is detected.
  • Activation of a board implies: • Activation of DCN channels Generation of entity MIB' s
  • Operational status in TN is supported on the node, replaceable units and on interfaces (ifTable) .
  • This section describes the equipment (node and replaceable units) operational status.
  • An equipment failure is the cause for an update of the operational status.
  • the relation between equipment status severity and operational status is:
  • the replaceable units in TN comprises all boards (PIUs) and the fan (s) .
  • Reduced Service This status indicates that the traffic functionality in the backplane is available but that the management functionality (result of a minor equipment alarm) or a redundant function in the node is reduced/unavailable for which a further reduction will have impact on traffic. (result of a major equipment alarm) .
  • Equipment status in TN is supported on the node and replaceable units. This status gives more detailed information as background to the operational status.
  • the status of a replaceable unit is independent of that of the node and vice-versa.
  • a change in the equipment status leads to an update of the operational status and a possible alarm notification with the equipment status as specific problem.
  • the node supports equipment status on replaceable units.
  • the equipment status may be one or more of the following:
  • the node supports equipment status on the node.
  • the equipment status may be one or more the following values:
  • a PFU or FAU that is set to 'out of service' is regarded as not present, i.e. no redundancy in case of PFU, and not taken into account for the node operational state.
  • the PFU is shown as administrative status 'in service' whilst operational status is out of service.
  • At least one PFU in the node must have administrative status 'in service' .
  • NODE CONFIGURATION HANDLING- The node stores the configuration in one start-up configuration file.
  • the file consists of ASCII command lines .
  • Each application has their chapter in the configuration file.
  • the order of the application in the configuration file must represent the protocol layers. (SDH must come before El etc) .
  • Each application is must specify its order in the start-up configuration file.
  • the start-up configuration is housed on the NPU, but the node is also able to up/down load start-up con iguration from an FTP site.
  • the node When the node is configured from the "SNMP / WEB / Telnet" it will enter an un-saved state. Only running configuration is updated, i.e. running is not equal to start-up configuration anymore. Entering this state will start a period ⁇ timer, successive configurations will restart the timer. The running configuration is saved when a save command is received before the timer expires. If the timer expires the node will do an warm restart and revert to the latest start-up configuration.
  • the node is also able to backup the start-up configuration file to an FTP server. This is done for each save command, however not more frequently than a period ⁇ 5 .
  • the save command handling is illustrated in figure 52.
  • the node updates the start-up configuration in the case of board removal (after " ⁇ 6 ' timeout ) .
  • the node is only updated in case of saved state.
  • the configuration file shall include information about the AMM type for which the configuration is made. Configuration files should not be exchanged between different backplane type. However in case e.g. an AMM 6p configuration file is used for a AMM 20p a kind of best effort will be done in configuring boards and node.
  • This section describes equipment errors in the node.
  • the node handles single errors, double error is not handled.
  • Faults shall be located to replaceable units. Faults that cannot be located to one replaceable unit shall result in a fault indication of all suspect units.
  • the figure 51 shows general principle of TN fault handling of hardware and software errors.
  • Fault handling includes handling of software and hardware faults. Other faults like temperature violation is not handled according to the state diagram above. Node error handling
  • the figure 53 shows how the TN handles Node errors.
  • the Node fault mode is entered after 3 warm/cold fault restart within a period ⁇ 6 .
  • this mode is the NPU isolated from the APUs and fault information can be read on the LCT.
  • the figure 54 shows how the TN handles APU errors.
  • the ANS shall set the temperature tolerance of the board, default 70/75 °C for highexcessive.
  • the BNS shall set the high and excessive temperature threshold as ordered by the ANS.
  • the BNS shall accept and set values in the range 50 - 95 °C. Incorrect values shall result in default values and the operation shall be logged in the sys log.
  • BNS shall do the equivalent for the NPU and PFU boards.
  • Temperature will be measured on all boards in the node. Two levels of alarms shall be supported, excessive and high temperatures. The temperature sensor in the SPI BB will do this .
  • the PIU operational status shall be set to: minor/high temperature critical/high temperature
  • the high temperature threshold crossing shall lead to a power save mode on the APU (set the board in warm reset) .
  • the PIU shall after this be taken in service again if the temperature on the board is below the high temperature threshold continuously for a period of ⁇ 2 .
  • Excessive temperature on the PFU shall shut off power to the node. This function shall be latching, i.e. the power to the node shall be turned off before the power comes on again.
  • node fault mode Isolated NPU, no access to other board.
  • the mode will be released when the high temperature indication is removed.
  • the fan status is signalled on the SPI bus from the PFU.
  • the signals only indicate OK/NOK.
  • the individual fans are supervised and a failure is indicated if one fan fails.
  • a fan cable removal shall be detected as a fan failure.
  • the fan operational status shall be set to: critical/hw error.
  • the fault LED on the fan shall be lit.
  • the fault may in addition result in temperature supervision handling.
  • the SPI indicates that the NPU SW does not support a board type.
  • the SPI inventory information displays a board not supported by the NP SW.
  • the APU operational status shall be set to: critical/unsupported type.
  • the APU fault LED shall be lit.
  • the basic node shall supervise that the APUs has a correct local power. This is supervised through the use of local power sensors. A power sensor fault will normally indicate that the APU has had a power dip.
  • the power LED shall be turned off and if possible the fault LED shall be turned of during the time that the power is faulty.
  • the APU operational status shall be set to: critical/hw error
  • the PFU will detect loss of incoming power or PFU defect with loss of incoming power as a consequence. This can of course only be detected when redundant power is used.
  • the NE operational status shall be set to: major/power failure
  • the PFU operational status shall be set to: critical/hardware error
  • This section describes the software upgrade functionality offered by the TN. It specifies the functionality for upgrading one TN, not the functionality offered by external management to upgrade a whole network, like how to upgrade from network extremities back to the BSC or how to upgrade several TNs in parallel.
  • RSU Remote Software Upgrade
  • LSU Local Software Upgrade
  • a SR is a package of all software that can be replaced by a SU of the software for:
  • ADS Application DP Software
  • the TN uses FTP for both RSU and LSU.
  • a TN is always upgraded to a SR.
  • a SR contains always all BNS, ANS and ADS for that specific release. When performing a RSU or LSU, it is always from one SR to another.
  • FTP server
  • BNS has an FTP client that can download files from an FTP server.
  • the server is either on the DCN or in a locally attached PC, there is no difference between RSU and LSU except for speed.
  • a TN System Release (SR) consists of load modules for each type of processor software in the TN, and a System Release File (SRDF) describing the contents of the SR.
  • SR System Release File
  • the SR must be backward compatible at least two major customer releases. That is a release "n+3" is at least backward compatible with release "n+1" and "n+2". This to limit testing of software upgrade/downgrade, e.g. when R6 is released it will have tested against R4 and R5.
  • SRDF file name and ftp-server location are given as MO's, see XF-SOFTWARE-MIB. Nodes can be given different SRDF files and thereby run different Software, i.e. contain different load modules.
  • SRDF is a CLI script file that is transcribed into the XF- SOFTWARE-MIB when downloaded and thus read-only. It is the only way to get information about load modules to the TN.
  • the syntax and semantics of the SRDF shall be revision controlled. It shall be possible to add comments to the SRDF. This can for example be used to indicate the APUs a certain DP software module belongs to.
  • Each TN System Release will be represented by a directory on the ftp-server named by the product number and version of that release and contained by a tn_system_release directory. All load modules plus a srdf.tn file reside within one System Release directory. Product number and revision will denote each individual load module. For example : tn_system_release/ ⁇ name_of_release> directory srdf.tn SRDF-file CXP901584_1_R1A NPU load module file CXCR102004_1_R1B LTU 155 load module file ⁇ number_MMU>_R2A load module file ⁇ number_MMU_RAU>_RlA • load module file
  • Figure 55 shows an example of TN System Release structure.
  • An optional header can include e.g. revision, hardware- version, and checksums, to enable BNS to control that it is the correct load module that has been loaded. Some of this information shall be included in the SRDF file as well.
  • the TN Basic Node shall provide a RAM-disk of 6 MBytes for software upgrade of DP's.
  • the active SR shows the current SR running on the TN and is a reference for new boards as to what software should run on the board in order to be compatible with the rest of the node .
  • the passive SR describes the previous SR the node was upgraded to whilst in normal operation. During the software upgrade process the passive SR will describe the software the TN is currently upgraded to.
  • the XF-SOFTWARE-MIB Software shows the product number and revision of current running software in the active memory bank for each APU and those for the software in both active and passive of the NPU.
  • Each APU/NPU with a DP contains two flash memory banks, an active and a passive one.
  • the flashes are used to contain the current and previous software for the corresponding APU/NPU.
  • the software in the active bank is the one running.
  • the one in the passive bank is used to perform a fallback to a previous System Release for that APU/NPU whilst a new software upgrade is being tested.
  • the software in the passive bank can also be used to perform a manual switch to previous software for the NPU. This is not a normal situation procedure and can only be performed in installation mode. It should only be used in emergencies and is against the policy that a node only runs a tested SR.
  • the software modules described in the active SR will always be present in the active memory bank of the respective NPU or APUs.
  • the passive memory bank can contain the following software:
  • the main software upgrade sequence is the one performed remote or local, i.e. from an EM or EEM, for a whole node. Special cases are described in the following sections.
  • the software upgrade sequence is started with the EM/LCT changing objects in the TN describing the product number and revision of the SR to upgrade to.
  • the EM/EEM starts the upgrade process the TN will ask for the SRDF- file via its FTP client on location:
  • the tn_system_release is the directory under which all SRs for TN are available. This is not configurable by the EM/LCT:
  • the TN When the SRDF-file has been downloaded, evaluated and represented in the XF-SOFTWARE-MIB, the TN will download the necessary load modules via its FTP client to its RAM- Disk.
  • the FTP server For the software upgrade process to proceed fast enough, the FTP server is assumed to have a limited number of client connections open at a given time. So in case of an upgrade of a whole network, few high-speed connections are preferred over many low-speed connections. The whole process is illustrated in figure Slett
  • a load module downloaded to the RAM-disk on the NPU must be marked read-only until the respective controlling program, i.e. ANS, has finished the download to the target FLASH.
  • the new software is now marked to be used after a warm- restart of the TN and the EM/LCT orders a warm-restart directly or scheduled at a given date and time.
  • the warm-restart at a specified date and time will be used if many nodes are upgraded and have to be restarted at approximate the same time to have the OSPF routing tables update as soon as possible.
  • a node initiated commit will be default when executing a scheduled S ⁇ .
  • the progress of the LSU/RSU process shall be available through status MO' s in the XF-SOFTWARE-MIB.
  • a board inserted during the software upgrade process will be checked/upgraded according to the active SR. It will not be upgraded as part f the upgrade to the new System release but as part of the test phase of the new system release. No load module for APU
  • the TN After a switch to the new SR, i.e. an TN warm-restart, the TN goes into a test phase.
  • the test phase will end when the COMMIT order is received from external management. After the COMMIT order is received, there will be no fallback possible. Situations that will initiate a fallback are: • COMMIT order not received, within a period ⁇ 6 after the switch • Warm/cold node restart during the test phase.
  • the NPU will switch SR (fallback) . Then the APUs will be ordered to switch software according to the previous SR. Manual/ forced fallback is not supported in the TN. SU not finished before scheduled time
  • a restart of a APU can be caused by:
  • Figure 58 shows software upgrade of a single APU due to an APU restart and figure 59 discloses a hot swap software upgrade. New board type inserted
  • the TN will be notified and the whole upgrade process is aborted.
  • the equipment status (hardware status) of the faulty board will be set to hardware error (critical), i.e. Out of Service, this will light the red led on the APU.
  • the ANS must handle Flash located on the APU. Special NPU cases
  • the NPU software does not handle the upgrade, e.g. in the MCR Linkl case, the NPU software will only be aware of the hardware through the equipment handling of the board. No SRDF available
  • the SU configuration command saved in the configuration file must be backward compatible.
  • a MCR branch can have four (512/128) sub-branches without adding to the download time, i.e. software to a TN in each of the branches can be performed in parallel.
  • downloads must be serialised at 128 Kbits/second.
  • the download time is:
  • Each SDH NE plus its 4 branch, depth 3 sub-network RSU will require 3250 seconds, about one hour, longer.
  • Every 4 extra branches for a SDH NE will require 1000 seconds per TN in a branch. Say roughly one hour, assuming a depth of 3 to 4, per 14 TNs.
  • a typical requirement for a maximum time for a commercial system may typically be 8 hours, which is fulfilled for the assumed reference network when programming and downloading are two parallel processes. However an extra hour is required for each new branch, of depth 3 to 4. Which means that requirements will be fulfilled for TJSI sub-networks with up to
  • the maximum time for RSU of a TN from EM is ⁇ 8 (typical 30 minutes) .
  • Fault identification The process of identifying which replaceable unit that has failed.
  • Fault notification The process of notifying the operator of the fault.
  • Fault repair The process of taking corrective action as a response to a fault.
  • Warm reset This is a signal on all boards. When pulsed it takes the board through a warm reset (reset of the control and management logic) . While asserted the unit is in warm reset state. The PCI FPGA will be reloaded during warm reset.
  • Cold reset This is a signal on all boards. When pulsed it takes the board through a cold reset (reset of all logic on the board). While asserted the unit is in cold reset state. The cold reset can be monitored.
  • Warm restarts A restart of the control and management system. Traffic is not disturbed by this restart.
  • the type of restart defines the scope of the restart, but it is always limited to the control and management parts. During the restart the hardware within the scope of the restart will be tested.
  • Cold restart A restart of the control and management - and the traffic - system This type of restart will disable all traffic within -the scope of the restart. The type of restart defines the scope of the restart. During the restart the hardware within the scope of the restart will be tested. Temperature definitions:
  • High temperature threshold The threshold indicates when the thermal shutdown should start. The crossing of the threshold will give an SPI interrupt to the NPU.
  • the threshold indicates when critical temperature of the board has been reached. The crossing of the threshold will give a cold reset by HW and an SPI status indication to the NPU.
  • High temperature supervision "hysteresis”: The high temperature supervision will make sure that the board has been in the normal temperature area continuously for at least a period ⁇ 2 before the warm reset is turned off.
  • Normal temperature
  • the boards are held in warm reset. This is done in order to protect the system from damage.
  • the shutdown also serves as a means for graceful degradation as the NP will deallocate the PCI resources and place the APU in warm reset thus avoiding any problem associated with an abrupt shutdown of the PCI bus.
  • Administrative Status This is used by the management system to set the desired states of the PIUs. It is a -set of commands that sets the equipment in defined states. Operational Status:
  • This information describes the status of the equipment. Management can read this. Operational status is split into status and the cause of the status.
  • the service LED on the NPU will also be lit during the period after a node or NPU power-up in which the board may be placed in installation mode. When the node is in installation mode the yellow LED on the NPU will flash.
  • the term yellow LED and service LED is in this document equivalent .
  • the mode is used to enable access during installation or after failures.
  • the mode is used when a new NPU is installed in an existing node.
  • Node Fault mode The Node fault mode is entered after 3 warm / cold fault restart within a period of ⁇ 6 . In this mode is the NPU isolated from the APUs and fault information can be read on the LCT.
  • Board repair interval This is the interval during which an APU and PFU may be replaced with an automatic inheritance of the configuration of the previous APU.
  • This timer defines the board repair interval. It has the value ⁇ 6 .
  • This timer defines the board removal interval. It has the value ⁇ 2 . Save interval
  • Save timer This timer defines the save interval. It has the value X ⁇ .
  • IME timer This timer defines the Installation mode entry interval. The specific value of this timer will not be exact but it shall be minimum of x 3 (depends on boot time) .
  • AIM Application Interface Module Part of the ANS that handles the application functionality
  • NP Node Processor the processor on the NPU
  • PCI-SIG Peripheral Component Interconnect Special Interest Group PDH Plesio-synchronous Digital Hierarchy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne une unité enfichable conçue en vue de fonctionner dans un noeud de communication, ce noeud comprenant une architecture de bus et un logiciel fonctionnel. Ce noeud est conçu de manière à fonctionner dans un réseau de transport à micro-ondes PDH/SDH, dans lequel l'unité enfichable comporte au moins une fonction de commutation (de trafic) incorporée. Cette unité enfichable est, en outre, conçue de manière à supporter une fonctionnalité de commutation de trafic 'non incorporée'. La fonctionnalité de commutation incorporée peut généralement supportée un TDM, alors que la fonctionnalité de commutation 'non incorporée' consiste en un commutateur ATM haute capacité.
PCT/NO2004/000259 2003-09-03 2004-09-02 Architecture de systeme optimisee destinee a la variabilite dimensionnelle WO2005022829A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04775043A EP1661306A1 (fr) 2003-09-03 2004-09-02 Architecture de systeme optimisee destinee a la variabilite dimensionnelle

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
NO20033896 2003-09-03
NO20033896A NO20033896D0 (no) 2003-09-03 2003-09-03 Systemarkitektur optimert for skalerbarhet

Publications (1)

Publication Number Publication Date
WO2005022829A1 true WO2005022829A1 (fr) 2005-03-10

Family

ID=28787015

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/NO2004/000259 WO2005022829A1 (fr) 2003-09-03 2004-09-02 Architecture de systeme optimisee destinee a la variabilite dimensionnelle

Country Status (3)

Country Link
EP (1) EP1661306A1 (fr)
NO (1) NO20033896D0 (fr)
WO (1) WO2005022829A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008071076A1 (fr) * 2006-12-12 2008-06-19 Comba Telecom Technology (Guangzhou) Ltd. Système relais à hyperfréquences numériques et procédé d'application

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001045345A2 (fr) * 1999-12-15 2001-06-21 Nortel Networks Limited Architecture de reseau dynamique bimode sans fil avec protocole de couche 2 separee
WO2002003594A2 (fr) * 2000-06-30 2002-01-10 Sycamore Networks, Inc. Procede de gestion de circuits dans un repartiteur multi-etages
US6339600B1 (en) * 1998-06-01 2002-01-15 Fujitsu Limited Information transfer equipment
US6563835B1 (en) * 1998-02-20 2003-05-13 Lucent Technologies Inc. Call processing arrangement for ATM switches

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6563835B1 (en) * 1998-02-20 2003-05-13 Lucent Technologies Inc. Call processing arrangement for ATM switches
US6339600B1 (en) * 1998-06-01 2002-01-15 Fujitsu Limited Information transfer equipment
WO2001045345A2 (fr) * 1999-12-15 2001-06-21 Nortel Networks Limited Architecture de reseau dynamique bimode sans fil avec protocole de couche 2 separee
WO2002003594A2 (fr) * 2000-06-30 2002-01-10 Sycamore Networks, Inc. Procede de gestion de circuits dans un repartiteur multi-etages

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
SOMERS F ED - INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS: "HYBRID: UNIFYING CENTRALISED AND DISTRIBUTED NETWORK MANAGEMENT USING INTELLIGENT AGENS", 1996 IEEE NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM (NOMS). KYOTO, APR. 15 - 19, 1996, IEEE NETWORK OPERATIONS AND MANAGEMENT SYMPOSIUM (NOMS), NEW YORK, IEEE, US, vol. VOL. 1 SYMP. 5, 15 April 1996 (1996-04-15), pages 34 - 43, XP000641076, ISBN: 0-7803-2519-2 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008071076A1 (fr) * 2006-12-12 2008-06-19 Comba Telecom Technology (Guangzhou) Ltd. Système relais à hyperfréquences numériques et procédé d'application

Also Published As

Publication number Publication date
EP1661306A1 (fr) 2006-05-31
NO20033896D0 (no) 2003-09-03

Similar Documents

Publication Publication Date Title
US7293090B1 (en) Resource management protocol for a configurable network router
US20050089027A1 (en) Intelligent optical data switching system
WO2002069104A2 (fr) Architecture nodale et systeme de gestion pour reseaux optiques
US20070291727A1 (en) High Availability System Based on Separated Control and Traffic System
EP1661306A1 (fr) Architecture de systeme optimisee destinee a la variabilite dimensionnelle
Cisco Release Notes for Cisco MGX 8240 Release 3.0.1.10 PSM
US20020167896A1 (en) Methods and apparatus for configuration information recovery
Cisco Command Reference
Cisco 9.2.23 Version Software Release Notes Cisco WAN Switching System Software
Cisco Operation, Administration, and Maintenance
Cisco Operation, Administration, and Maintenance
Cisco 9.2.10 Version Software Release Notes Cisco WAN Switching System Software
Cisco Cisco 12012 Gigabit Switch Router
Cisco Cisco 12012 Gigabit Switch Router
Cisco Cisco 12012 Gigabit Switch Router
Cisco Command Reference
Cisco 9.2.38 Version Software Release Notes Cisco WAN Switching System Software
Cisco 9.2.30 Version Software Release Notes Cisco WAN Switching System Software
Cisco Overview of Interface Configuration
Cisco Cisco ONS 15104 Feature Module
Cisco Release Notes for LS2020 Software Release 2.1.01
Cisco Release Notes for LS2020 Software Release 2.1.01
Cisco Release Notes for LS2020 Software Release 2.1.01
Cisco Release Notes for LS2020 Software Release 2.1.01
Cisco 9.2.37 Version Software Release Notes Cisco WAN Switching System Software

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004775043

Country of ref document: EP

DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWP Wipo information: published in national office

Ref document number: 2004775043

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2004775043

Country of ref document: EP