Essential functions in rail telecommunication network modelling

Due to the advent of high capacity bandwidth technology, an innovative approach to mapping new age Synchronous Data Hierarchy (SDH) in rail networks is needed.

We have constructed a  network model to identify bottlenecks within the payload and to logically assess service failures. In this article, we will describe the functions of the model and demonstrate how the model is essentially a managerial tool, central to the responsible administration of payload, as applied to Rail utilities.

PDH, SDH topology recognizes neither start nor end points of termination. The SDH multiplexer, or Nodes as they are known, are multi-directional in design, their fibre interfaces facilitating 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 that can logically analyse service failures, consequential to the simulated multiple breakdowns of modelled infrastructure, would automatically realise the potential to improve, innovate and support rail telecommunication applications.

Literature review

PDH and SDH networks, their structures and main characteristics are well documented in literature. However, the functionality of rail telecommunication network models is  very rarely discussed.

In our previous article – “Rail telecommunication network documentation and modelling” (published by Rail Engineer.uk in November 2017), we described references applicable to this article that review basic literature relevant to modelling  rail telecommunication network modelling. In this article, we only describe the additional literature; however, all literature is listed at the end of this article.

Guidelines for implementation – synchronisation of the digital telecommunication network, synchronisation network architecture, control of jitter and wander within synchronisation networks, timing characteristics of slave clocks, operation and maintenance of synchronisation networks, planning of synchronisation networks, sec as node clock, synchronising the SDH/PDH traffic networks, synchronisation in packet networks and time/phase synchronisation in packet networks are discussed in [14].

The authors in [15] seek SDH network improvements discussing the role of ATM in 3G access networks, deploying a 3G access network, lightscape’s solution for 3G access networks, the XDM ASM card as A node B concentrator and an integration of 2G and 3G traffic. A very essential statement is made in [16] – “PDH and SDH technology have reached obsolescence”. That demonstrates how quickly the telecommunication technology is developing. The need for an improvement of the SDH network can be also seen on railways. The authors in [17] describe a mix and future blend of Time Domain Multiplexing and Internet Protocol network elements as well as looking for an insight into the future of the next phase of network and element monitoring practices.

Following the mention of network monitoring, there are two main categories distinguished from the literature: SDH network management [18]-[19] and SDH network configuration management [20]-[23]:

• The first category includes network monitoring, virtual containers [18], management functions, protocol stack, ECC interworking and operations interfaces. [19]
• SDH network configuration management is effectively managing information about the SDH network. There are specific languages designed to manage network configuration [20] and specific software packages commercially available to perform a variety of functions such as: network planning in different layers, traffic planning tool and document the routeing of PDH, SDH and Ethernet network. [21]-[23]

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 [22] mentioned a replacement of MS Access and MS Excel databases existing today with their tool, in order to document the routeing 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 that all the functionality using more available methods has been transferred into the offered software package.

Relevant telecommunication history

Rail Operators realised the potential in bolstering the reliability of communications to remote stations. Contingency paths would only be successful if they were not co-located in the same damaged cable, so in many cases the Rail networks invested in the broad band Microwave Radio medium to transport the contingency paths of bit streams of critical services.

The deployment of Microwave Radio systems provided yet another added benefit – the tower infrastructure was a means of establishing in-cabin two way radio communications between Central Rail Operations staff and locomotive drivers.

The notion of high reliability communication Networks began to take shape as the functionality available with digital communication services was realised.

On the rail systems application side, the power supply to an electric locomotive is controlled by a Serial Control and Data Acquisition (SCADA) system. This system also needs rail telecommunication to reliably collect the input data and control the outputs.

Railways invested quite heavily in all manner of electronic technologies to monitor rail infrastructure (points operation, bridges, flood levels, train condition and many more). All those system are usually independent and require data transmission to their central computers that conduct data analytics, including data trending. The results of those analytics are transmitted to the relevant engineering/operation departments. Reliable and fast transmission is absolutely essential.

Maintaining single line diagrams does not make any sense due to the dynamic character of the network. The introduction of network modelling with an option to automatically generate linear diagrams with the ability to quickly document the changes to the centralise documentation database is needed to support maintenance or upgrade works.

Functions of the network model

Describing the functionality of the model is essential. The modelled approach releases a wealth of flexibility found within the coding environment of common, affordable applications. The innovative future of our sons and daughters is linked with the skills of coding.  Commercially available products have limited functionality in relation to the implementation in a specific area. There are deficiencies that come from generalisation or standardisation of the commercial software: functionalities, nomenclature and lack of specific industry knowledge are just some. The Rail Operator finds they need to purchase more than one piece of commercial software to meet their basic functional requirements.

The innovative future of our sons and daughters is linked with the skills of coding.

Developing the model, it has been understood that flexibility of coding and specialist telecommunication knowledge is required to deliver the desired degree of functionality of the end user tool, in order to document telecommunication network. Below is some important information pertaining to high level functions which are necessary for the user.

The functions the rail telecommunication model needs to include.

• Ability to correlate and record the sequence of physical hardware connections.
• Routines to identify and distinguish different service types.
• Procedures to detect service protection in payload
• Functionality to display payload in hardware and on transmission mediums
• Capability to enumerate access points to payload (ports, POP)
• A method of rendering locations and transmission mediums against a GIS backdrop.

In general terms, the six bullet points listed above provide the user with a range of operations to perform the following tasks:

• Trace a service end to end, both physically and logically
• Logically analyse the impact of service disruption due to hardware failures
• Assess payload allocation along a series of network links
• Allocate service to spare payload containers.

The model embraces all the functionality, providing the user with an opportunity to succinctly comprehend payload deployment in the telecommunication network.

Fig. 2 shows our model auto-generated drawing that represents the service allocations that appear in the payload along a sequence of network hardware. Most importantly, the hardware sequence was created by the user via the graphical map interface; remember SDH topology is ostensibly a mesh without a start or end node. In a paper-based regime, the view would be spread across multiple schematic drawings, while in the model, the user “interactively tracks” the sequence along the mesh. Thereafter, the SDH payload for the tracked sequence is auto-generated “on the fly”, as required.

The mesh appears quite complex as the SDH network is much more sophisticated than that of a PDH network. The volume of SDH payload is far greater than can be delivered over a PDH structures

A magnified view of the top left corner of Fig. 2 displays SDH nomenclature, cross connections, hardware identification and service names.

On that view, the location names appear with the names of the associated nodes and cards along the top of the picture. On the left hand side, service names specific to the payload are adjacent to their allocated SDH container.

By way of example, the following applies inside Fig. 3: the 2Mbs trunk service known as – Trunk to Windah #1 is allocated to SDH container 1:1:2:3 at location ‘Rockhampton MWR’ on Node RKA-F06-MS54-01 on card 1-7:5. It arrives at location ‘Table Mountain MWR’ on Node TMT-MWR-MSUC-02 on card 1-9:2 and is cross-connected to card 1-8:2 onto container 1:1:1:3 and so on.

Once more, it is important to realise the left to right sequence across the page of Fig. 2  is a path chosen by the user interacting with the model’s static graphical interface.

In terms relating to service allocation, another auto-generated schematic (Fig. 4) shows a service’s association with hardware. The automated drawing of a service shows graphically the hardware components and the virtual payload applied to each link as text.

In this paper format, reading details of the services is impossible. However, in the network model the service drawing is generated to the readable paper format A4 or A3 as required.

To be able to describe the concept, we have presented a fragment of the service allocation with hardware in a magnified view on Fig. 5.

There are two types of transmission mediums depicted on the schematic – microwave and fibre optic cable. Also seen are hardware with SDH container allocations (with the node located below the hardware box). The identities of virtual containers used by the service are visible on the actual transmission medium; in this case the 10Mb/s service is allocated to 5 X VC12 containers between 1-9:2 card and 1-8:2 card 1:3:4:2, 1:3:4:3, 1:3:5:1, 1:3:5:2,1:3:5:3. The Location name is visible in the top of the picture as a straight line finished with dots to represent the span of the location. Remember, locations can accommodate more than one node. In this case ‘Table Mountain MWR’ encompasses two nodes: TMT-MWR-MSUC-03 and TMT-MWR-MSUC-02.

Let’s examine an amalgamated data service as reflected on Fig. 6. It too has been automatically generated from the model.

In this scenario more than one service is associated with an overall service. While the services are allocated to SDH payload, the Routers (in diagram shown as standard circle with 4 directional arrows) are not part of the SDH network as such, yet need to be drawn in order to create a manifestation understood by the viewer as an Multiprotocol Label Switching (MPLS) service schematic diagram.

It should be noted that this type of service involving multiple data traffic paths are vulnerable to co-locations. The model has functionality to detect these co-locations and display the errant pathways in an automated schematic diagram. This feature is unique to the model and is not readily available in commercial solutions.

The interconnecting lines between routers in (Fig. 6) also have a built-in access menu which allows the user to instigate a tracing function along any of the blue lines. This feature is unique to the model, allowing the user to automatically -> draw, drill, and draw again. Ostensibly, a diagram similar to Fig. 4 can be precipitated from any of the blue links in (Fig. 6) using this feature.

The zoomed in view in Fig. 7 shows the interconnections of router devices and SDH port identifiers. Also note the automatically generated naming convention for services, revealing a unique data sourced number, a location to location delivery identifier and traffic size, e.g. (2521 WAY-CAH 4Mb). The text of the router port identities (IM1 P03), the SDH model is able to “data mine” external data sources to extract extra information, providing the user with a complete end to end interpretation of the service. Physical information and logical information are assembled and displayed within the diagram. The degree of completeness of information (seen in Fig. 7) is rare in commercial grade solutions.

A variety of Visual Basic for Applications Computing (VBA) functions were used to create the image above, including the following:

• code to extract hardware identity
• code to extract location GIS identity
• code to extract service associations to other services (MPLS)
• code to extract service allocation to payload containers, and port identities.

Fig. 8 displays an automatically produced drawing of the timeslot configuration associated with a PDH omnibus bearer.

This view is critical because it allows the model to display the PDH payload allocations as a configurational view of the PDH bearer, yet all the while, the information is controlled within the relational table structure of the underlying database in the network model. The model allows the user to interrogate the network from a geospatial view and retrieve knowledge of which PDH services are impacted by bit stream failures.

The model manipulates the lines to indicate the branching nature of each timeslot symbolically. Alphanumeric displays on the diagram show node identity, in addition to timeslot and channel identities.

The lines have an access menu which allows the user to instigate a tracing function along any of the blue lines. This feature is unique to the model allowing the user to rapidly interact with underlying back end data.  Note this diagram is able to be electronically audited against imported branching table information.

By comparison, Fig. 2 is a SDH payload usage diagram while Fig. 8 is the PDH equivalent. The differences seen are subtle, but nonetheless, important.

The PDH diagram does not show identities of cards within its Nodes (multiplexers), because the PDH deployment of multiplexers is linear. The interfaces which attach to bitstreams are known as directional interfaces, of which there are direction 1, direction 2 and direction 3 (to local channels). In the PDH usage (diagram Fig. 8), direction 1 is toward the left-hand side and direction 2 is toward the right-hand side. It is common to see a daisy chain of PDH multiplexers, with direction 2 of one multiplexer facing direction 1 of the next in sequence.

The SDH network is not constrained by a limited number of directional bit streams emmanating from a Node. In a SDH network, the nodes may accommodate multiple cards interfacing to bit streams; therefore, the card identity is required, as seen in Fig. 2.

Also consider that each cross connecting line seen in Fig. 2 can carry the entire payload you see in Fig. 8. In terms of scale and detail, the vastness of information controlled by the Model is staggering.

Fig. 9 describes, in part, the PDH configuration of the Nokia Dynanet product. On the Fig. 9, the PDH node identifiers across the top with their bus and unique address (e.g. TIK-CER-NDB2-01 6:076) can be seen. Below, there are the 30 x timeslots emblazoned in blue line work (Fig. 9 – only six of them are shown). Each blue line represents a 64 Kbps service used for voice traffic. The service names allocated to each PDH timeslot is to the left and right side of the line work. The type of branch is indicated by the angular extensions to the blue linework. In the example shown in Fig. 9, the following description applies: the service known as ‘ROK Control Blackwater West’ appears on channel 1, on timeslot 1, on multiplexer RNG-CER-NDM2-S1. The service transits to multiplexer TIK-CER-NDB2 on its direction 1 interface, in timeslot 1, where it is used in a 3 way summation branch to appear on channel 1 at TIK-CER-NDB2-01, where it is using timeslot 8, on direction 3 interface, and transits to the next multiplexer via timeslot 1, on direction 2 interface and so on.

Every stroke of line work and every alphanumeric are automatically drawn from the modelled data. The ability to autogenerate Nokia branching timelsot usage drawings is rare in commercial solutions. A variety of VBA Functions were used to create the image above, including the following.

• code to extract hardware identity
• code to extract node branching configuration.

The model uses VBA functionality to automatically draw the hardware the Rail Operator will see in their telecommunication centre. It has been reflected in Fig. 10.

Fig. 11 shows a fragment of the big picture from Fig. 10 in a zoomed view detailing patching in the high resolution vector driven image. Note all patching detail, image placement and orientation is controlled using VBA coding.

The model provides a graphic vector driven environment to automatically draw data racks, their components and patching detail from underlying data. The routed devices in this aspect of the model do not have structured payload containers on bitstreams as seen in the SDH topology.

In general terms, the ability to model a service path configuration in a routed network is impossible, because active tables associated with routers dynamically alter payload paths around network impacts. Therefore, traceability of the service may only be achieved knowing the tangible connectivity between routers. This model (part of which is seen in Fig. 11) is able to generate images that depict these tangible components,  patch leads and fibre core connections as seen in an actual routed network.

Nonetheless, the off back-bone devices are represented by high resolution stencils as opposed to a stylised static view. Again the power within the coding environment delivers all the functionality needed to manifest a network model at a fraction of the cost of commercial solutions.

The next feature that should be an integral part of a telecommunication network model is reporting. Reports in the model are automatically generated. An extracted report view of the model is presented in Fig. 12.

The report is a “textual trace” of a service.  The depth of information in the trace list details not only the logical payload containers in sequential order, but also the patching details, port number, card indentity, node and location name. In essence the model is able to trace across a crowded network and across a crowded room.

… the model is able to trace across a crowded network and across a crowded room.

The operative word here is “crowded”, as the intensity of service delivery is deployed into the network infrastructure and its payload increases, so too is the need to provide good housekeeping tools such as modelling, in order to keep track of that deployment and maximise the effective use of the asset.

Philosophically, the number of CADD based diagrams required to document a Telecommunication network is almost zero. As demonstrated by this model, sufficient technical information can be stored in data tables to extract key details by which to auto-generate the diagrams from pure data, on an asrequired basis.

Observations and conclusions

The following observation and conclusion remarks can be drawn from the paper:

• 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 Jacek Mocki, 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]

References

1. Pepe Caballero, presentation “The PDH hierarchy”, ICT electronics
2. European Telecommunications Standard Institude (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. “Guidelines for implementation – Synchronization of the digital telecommunication network”, ITU-T recommendations, GFI 9501 edition 5, x.y.2011
15. ECI Telecom Ltd, a white paper “Integrating SDH and ATM in UMTS (3G) Access Networks”, ECI Telecom, 2003
16. M. D’Cruz, D. Lim, “Do We Have the Backbone to Support Emerging Technologies?”, IRSE Australasia National Convention, Sydney, March 2017
17. K. Schubert, S. Andrews, “Maintaining the momentum telecommunications monitoring in a heavy haul railway”, Conference on Railway Excellence – CORE2016, Melbourne, May 2016
18. The International Engineering Consortium, “Synchronous Digital Hierarchy (SDH)”, first published as an article in the IEE Electronics & Communication Engineering Journal, June 1994, available on the Web ProForum Tutorials www.iec.org, last accessed in March 2017
19. International Telecommunication Union, SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS, Digital transmission systems – Terminal equipments – Principal characteristics of multiplexing equipment for the synchronous digital hierarchy, “Synchronous Digital Hierarchy (SDH) management”, Telecommunication standarization sector of ITU, ITU-T Recommendation G.784, June 1999
20. ENG and Technical Publications – Turin Networks, Inc., “TransNav Management System SONET/SDH Documentation – TL1 Interface Reference Guide”, Release TN3.1/TR2.1/TE3.0, Document Number 800-0009-TR21 Rev. A, Turin NETWORKS, March 2007
21. W. Ghazy, “sunvizion – Integrated Telecommunications Network Management For Energy Companies – Case Study”, SIWE 2015, 26th November 2015
22. RGOMAN, “NETx – Professional Transmission Planning & Provisioning Tool”, February 2015, available on the website www.ergoman.gr, website last accessed in March 2017
23. J. Ponchon, a white paper “Use & Maintenance of Optical Networks – Specific Needs of Access Networks”, March 2006, available on the website www.jdsu.com, website last accesses in March 2017

The publication of this paper has been sponsored by Motzky