Traditional drawing methods employed by rail owners to describe the Plesiochronous Data Hierarchy (PDH) networks are no longer applicable. In the long run, the issue will create major problems for rail owners seeking to document payloads and optimise their investment in Synchronous Data Hierarchy (SDH) networks.
Our belief is that the actions used to deploy services onto real world bandwidth should mimic those used to assign services onto the model’s payload.
We have constructed the network model to support engineering/construction processes and to identify bottlenecks within the payload and to logically assess
disruptions.
Literature review
PDH and SDH networks, their structures and main characteristics, are well documented in literature. PDH network basics, object classes definitions, attributes definitions, name bindings definitions, ASN.1 definitions, packages and behaviour definitions can be found in 1 and 2.
The authors in 3 describe an overview of the Virtual Circuit Transport System, Managed Object Class Definitions, packages, attributes, action definitions, parameter definitions, name bindings and Virtual Circuit Transmission System ASN.1 Module.
References 4-8 expose the limitations of PDH networks introducing SDH networks. In 4 and 5, the authors talk about PDH network limitations, migration to SDH/SONET, SDH/SONET network elements, frame structure, overhead structure, layers, network topology and advantages. SDH introduction, synchronisation of digital signals, advantages, PDH, PDH limitations, basic SDH signal, transmission hierarchies, synchronous versus asynchronous, synchronisation hierarchy, synchronising SDH, evolution of timing and synchronisation, SDH frame structure, SDH overhead, SDH anomalies, defects, failures and alarms, SDH pointers, SDH multiplexing and SDH tributary multiplexing are described in 6 and partially in 7.
Reference 8 details SDH bit rates, SDH multiplexing elements, Synchronous Transport Module STM-1 Frame Structure and Synchronous Transport Module STM-4
Frame Structure.
The evolution of the telecommunications transport architecture from PDH and SDH is explained in 9. The authors examine the changes that are taking place in
telecommunication transport networks, from a hierarchical digital architecture to the possibility of an all-optical network for meeting the ever-changing needs of a global multiservice communication system.
References 10-13 describe SDH transport networks, SDH basics, synchronous transmission system, network architecture and design, protection, network management, high-capacity networks, synchronisation, support data-centric and wavelength services, availability of SDH network, benefits of Ethernet over SONET/SDH and benefits of switched Ethernet over SDH.
While literature delivers substantial reference on the existence of SDH network configuration management technologies, the quality of information and the details seem to be kept secret by the software packages’ owners and developers. Also, the authors in 14 mentioned a replacement of MS Access and MS Excel databases existing today with their tool, in order to document the routing of PDH, SDH and Ethernet network. However, they haven’t documented the functions stored in MS Access and MS Excel databases, so it is not certain all the functionality using more available methods has been transferred into the offered software package.
In this paper, we are presenting an alternative method to document an SDH network and manage its configuration and auto-generate documentation necessary to conduct physical work.
Relevant telecommunication history
Telecommunications has always been an integral part of rail transport. The earliest manifestations of rail telecommunication were open copper wire telegraph pole routes installed along the rail corridor, providing a means of voice communication on a station to station basis. Supervising train departures and arrivals by way of conversation formed the earliest quintessential need for railway telecommunication.
As the ability to supervise train passages evolved, station to station verbal reporting gave way to controlling trackside points and signals remotely from a distant central location. Nonetheless, the interactions between central and remote electrically powered interlocking and signalling 15 equipment occurred using the existing open wire pole route. The electrically powered interlocking and signalling equipment at each station interfaced to the telegraph wire pairs, using electronic telemetry via a modem.
A key change to rail telecommunication happened upon the introduction of the electric locomotive. The arrival of the electric locomotive, with the high voltage overhead traction wires, created a problem for open wire pole routes. The electromagnetic field emanating from high tension traction wires would cause lethal voltages to appear on the copper wire pairs of open pole routes.
Electrified traction in rail corridors made redundant the open wire telegraph poles and marked the inception of fibre optic cable, which was impervious to the effect of induced electromagnetic interference.
Fibre optic technology became a catalyst to the rise of digital communication. In the digital communication, voice is converted into a digital bit stream by telecommunication equipment known as a multiplexer.
The digital bit stream is used to modulate laser light which is applied to the fibre optic medium for propagation along the optic fibre cable.
The advent of digital bit stream technology over a fibre optic medium as opposed to an open wire pole route realised an added benefit. Failure of a copper wire medium (e.g. storm damage) renders the whole party line service unusable due to induced earthing noise, whereas failure of the fibre optic medium (e.g.earthworks) occurs with controllable consequences. The bit streams on unbroken fibre optic cable remain intact and noise free, therefore communications to stations each side of a broken fibre optic cable are still possible provided there is a contingency path that will bypass the broken section of fibre optic cable.
Rail telecommunication began deploying multiplexing equipment to form the backbone of their network, and the digital revolution had begun. Initially, Plesiochronous Digital Hierarchy (PDH) was deployed (a technology used in telecommunications networks to transport large quantities of data over digital transport equipment such as fibre optic and microwave radio systems). PDH is now successively being upgraded to Synchronous Digital Hierarchy (SDH). SDH is the most frequent transport technology used in long-haul networks. A multitude of those streams can be transported simultaneously through the same fibre over dense wavelength-division multiplexing (DWDM) technology.
In the deployment of SDH network, many experienced the biggest hurdle of present telecommunication – the equipment is no longer endemically linear in design. A
completely different approach is needed to document the telecommunication network. Maintaining single line diagrams does not make any sense due to the dynamic
character of the network. An introduction of network modelling, with an option to automatically generate linear diagrams to support maintenance or upgrade,
works with the ability to quickly document the changes to the centralised documentation database.
Network documentation/modelling
The SDH multiplexer, or Nodes as they are known, are multi-directional in design; their fibre interfaces facilitate many avenues with which bandwidth may detour around a network. Ostensibly, the new technology has transformed the linear assemblage of bandwidth deficient PDH multiplexers into a homogenous mesh of interconnected SDH nodes, saturated in payload possibilities.
Having said that, an instrument (a model) that can logically analyse service failures, as a result of simulated multiple breakdowns to modelled infrastructure, would automatically realise the potential to improve, innovate and support rail telecommunication applications. Perhaps more importantly, the model intrinsically provides an enumerated account of spare capacity, which is beneficial to identifying payload bottlenecks or future opportunities for third party payload backhaul.
There is always an expectation from Rail Owners that the continuity of their telecommunication network is well administered. Being able to deliver on that expectation infers knowledge of how each service propagates through the telecommunication network.
Networks impacted by hardware failures are inundated by customer complaints of service loss. Impacts to hardware caused by unscheduled events may be unavoidable to some extent; under these circumstances the customer’s complaint occurs after the fact.
However, a pre-scheduled hardware disruption emphasises the expectation that the loss of service should have been foreseen by a well administered network, and advisements of service loss, heralded accordingly before the fact.
Due to the nature of modern telecommunications, infrastructure can carry a significant amount of customer service, thus the potential to cause widespread loss of service and detrimental damage to supplier reputation.
Paper-based documentation for the purposes of illustrating the technical components involved in the delivery of individual services are manifested as schematic diagrams or circuit diagrams. These diagrams tend to have a large amount of commonality because major technical components in a telecommunication network are shared by large amounts of customer services.
In a paper-based regime, the administrative effort applied to updating large amounts of customer service diagrams increases every time a common major technical component in the network is changed.
Managing the changes to every diagram affected by a major network component upgrade causes delays in their availability for use by technical staff.
We propose a data modelled approach that overcomes the repetitive handling effort of common components associated with large amounts of customer service diagrams.
The data model recognises the “one to many” relationship between hardware and customer services. It is able to modify a single alteration in the one and update the association of the many.
The model contains three layers of information presentation. The developer environment contains the coding functions to manipulate the information. The layers are as follows:
- map view (Geographic Information System – GIS – correlated)
- physical connection (connectivity view)
- payload configuration (data view).
Fig. 1 illustrates the static components of the Model and the navigational “drill” (in orange ribbon) between layers.
Layer – map view – used as an interface to drill into the Physical connection layer below. Navigational functions include search and zooming to site locations. Maps tend to offer a peripheral view and orientation that is easily understood by the casual eye.
Layer – physical connection – this view is used to ascertain the manner in which major equipment is connected to each other. Navigational functions in this layer provide searching and zooming to equipment hardware. This layer is used to auto collect data relating to the interconnectivity of components, for use by functions devoted to configurations and automated drawing routines.
Layer – payload configuration (not shown on Fig. 1) – this layer is driven by multiple data tables in the underlying database and allows the model user to view the logical connections of the virtual payload. Most remarkably, the model contains just one table that requires human entry; all other tables are automatically populated via functions within the graphic’s coding environment as the physical connection layer of the model is drawn. This important aspect reduces the risk of erroneous input often associated with alpha numerical data entry.
The static images of the physical connectivity layer are kept minimalistic and stylised to reduce the file size, yet provide the model user with an insight of the critical components of hardware that carry payload. An example of the physical connectivity of an imaginary rail telecommunication network model is presented on Fig. 2.
It shows such details as locations, distances between locations, component devices, nodes, optical units, port units and bit stream. Those details are essential to be able to document a rail telecommunication network.
The schematic above (Fig. 3) is a particular, 15.3km long, connection between Central Signalling Equipment Room (SER) and Northern Signalling Equipment Room (SER). The connection is made by means of a fibre optic cable. In the Central SER, the nodes optical unit CEN-SER- MSUC-01 has two cards. Card 1-11:1 provides ports for external interfacing to local equipment. Card 1-9:2 is physically attached to fibre optic cable on which the payload bearing bit stream propagates. In the Northern SER, the nodes optical unit NTH-SER- MSUC-01 also has one optical unit Card 1-8:1 with its associated bit streams, and card 1-11:1, is used for external interfacing physical ports to local equipment. Virtual configuration of cross connects and payload are not statically visualised in the connectivity layer. However, the auto generated drawings of payload configuration can be triggered from this layer.
Fig. 4 presents additional, documented components of the rail telecommunication network. The circles with arrows represent Cisco routers. STH-SER- NDM2-S2 is a Nokia 2Mbit terminal Multiplexer. 1-7ETH represents an Ethernet card. 1-7:E is an internal virtual payload unit.
Dimensions of model and network
The Model has been implemented to document a substantial, real Rail Utility Network (located in central Qld Australia) whose dimensions and statistics are as follows:
Network
Total number of Locations: 334
Total SDH Bit stream lengths: 6,289.72 km
Total number of SDH nodes: 367
Total number of PDH nodes: 542
Total number of Ethernet access ports: 1632
Total number of PDH access ports: 3696
SDH Topology depth: STM-4.(with expansion to STM-64)
Model
Files size of Model (unlimited licence)
.VSD component 20.0 Mb
.ACCDB component 43.6 Mb
The Model and Network are tracking 68,554 SDH cross connections.
The static components in the model contribute largely to the 20Mb file size; the dynamic automated drawing routines allow for a plethora of drawings and reports to be generated using coded routines in the Visio developer environment.
The model is distributed to the client’s Standard Operating Equipment (SOE) machines via a central server using a desktop launcher App. By using SOE common applications, the number of licences is unlimited.
Observations and conclusions
The following observation and conclusion remarks can be drawn from the paper:
- unlike their domestic cousins, rail utility networks exhibit payloads festooned with backup paths, in order to achieve an industrial level of resilience for service continuity.
- the rail network design philosophy makes it necessary to know where contingency services exist and where spare payload is available in order to provide complete confidence in managerial control.
- modelling network payload using common application has been thoroughly explored using the techniques described in this paper. The modelled techniques herein offer distinct advantages over commercial grade solutions by way of low cost, rapid implementation, easy access, unlimited licencing and customising flexibility.
- the model is able to auto generate a multitude of diagrams and reports from underlying data, and exhibit the information in a timely manner, most suitable for dissemination among engineering staff.
- the impact upon traditional drawing regimes is significant; the draftsman’s eye for detail has evolved into the coding domain of the telecommunication artisan developer.
– –
Acknowledgments
The authors acknowledge the generous assistance from Simon Lowe (Network Rail) in preparing the paper for publication.
Authors
Cliff Arnold
ADII
CQU
Rockhampton, Queensland, Australia
[email protected]
Dr JacekMocki, MIEAust MIRSE CPEng RPEQ
Innovation for cost reduction/Optimise asset usage/Infrastructure investment efficiency
MOTZKY Pty Ltd
PO BOX6401, Yatala QLD 4207, Australia
[email protected]
List of Figures
Fig. 1 Graphical layers of Model
Fig. 2 Physical connectivity layer of Rail telecommunication
model
Fig. 3 Modelled backbone components
Fig. 4 Modelled components devices
References
1 Pepe Caballero, presentation “The PDH hierarchy”, ICT electronics
2 European Telecommunications Standard Institute (ETSI), “Telecommunications Management Nework (TMN); Plesiochronous Digital Hierarchy (PDH) information model for the Network Element (NE) view”, Draft ETSI European Standard EN 300 371 V1.3.2, France, October 2000
3 European Telecommunications Standard Institude (ETSI), “Telecommunications Management Network (TMN); Information model for a VC transport system using a 34 Mbit/s PDH transmission system in accordance with ITU-T Recommendation G.832”, ETSI Standard ES 202 098 V1.1.1, France, May 1999
4 O. Dokun, A. Gift, “PDH (Plesiochronous Digital Hierarchy)/SDH-SONET (Synchronous Digital Hierarchy / Synchronous Optical Networking)”, International Journal of Mathematics and Engineering Research, Vol 3 (1), pp. 01-06, January 2015
5 O. Babatunde, S. Mbarouk, “A review of Plesiochronous Digital Hierarchy (PDH) and Synchronous Digital Hierarchy (SDH)”, International Journal of Scientific Research Engineering & Technology (IJSRET), ISSN 2278 – 0882, Vol 3, Issue 3, June 2014
6 Tektronix, “SDH Telecommunications Standard Primer”, Tetronix Inc., 2001
7 N. Siriwardena, presentation “Synchronous Digital Hierarchy SDH”, July 2006
8 P. P. Copeland, “Overview of the CCITT Recommendations for Synchronous Digital Hierarchy”, report number FEL-91- B329, TNO Physics and Electronics Laboratory, The Netherlands, October 1991
9 J. D. Ash and S. P. Ferguson, “The evolution of the telecommunications transport architecture: from megabit/s to terabit/s”, ELECTRONICS & COMMUNICATION ENGINEERING JOURNAL, February 2001
10 ABB Switzerland Ltd, “Synchronous Transmission Systems (SDH) – A guide to the SDH world”, Edition 5.2, ABB Switzerland, 2008
11 European Telecommunications Standard Institude (ETSI), “Transmission and Multiplexing (TM); Functional architecture of Synchronous Digital Hierarchy (SDH)
Transport networks”, ETSI TC-TM, November 1993
12 ECI Telecom, a white paper “Ethernet Services and Service Delivery Technologies in the Metro”, ECI Telecom, February 2007
13 M. Thulin, “Measuring Availability in Telecommunications Networks”, Royal Institute of Technology (KTH) in Stockholm, September 2004
14 RGOMAN, “NETx – Professional Transmission Planning & Provisioning Tool”, February 2015, available on the website www.ergoman.gr, website last accessed in March 2017
15 J. Mocki, “Railway Interlocking Process: A Formal Method for Documenting and Evaluating Railway Junction Signalling and Interlocking”, PhD Thesis, Griffith University, Brisbane, December 2015
The publication of this paper has been sponsored by Motzky
