Carrying CBTC data over a public LTE network: fact or fiction?
Posted: 8 December 2015 | Carlos Rodríguez Sánchez & Juan Moreno García-Loygorri | 1 comment
For Intelligent Transport, Metro de Madrid colleagues Carlos Rodríguez Sánchez and Juan Moreno García-Loygorri, take a look at the feasibility of carrying Communications Based Train Control (CBTC) data over a Long-Term Evolution (LTE) network. CBTC data is mostly critical, but most of the services carried over mobile networks, like LTE, are absolutely not critical. This article1 provides an overview of the challenges that imply the CBTC communications subsystem, and the requirements for the mobile network, plus a description of LTE technology and railway-related aspects.
Metro de Madrid is one of the earliest adopters of both CBTC technology and train-to-wayside broadband communications, with three lines equipped with CBTC technology and more than 150km of track with broadband connectivity.
CBTC is a state-of-the-art signalling technology for mass transit lines which offers the best transport capacity with the highest level of safety2. It is a very complex technology, with many subsystems and, therefore, with many challenges that need to be properly addressed. One of the most significant is the radio subsystem, an aspect that traditionally relied on commercial-off-the-shelf devices, mostly based on the IEEE 802.11 standards family. CBTC technology has achieved great success in the last 10-15 years and has a great future ahead.
On the other hand, LTE is a fourth-generation mobile communications technology standardised by the 3GPP and widespread all over the world. Its own name, ‘Long-Term Evolution’, clearly states its purpose of being a durable technology. It has an open and flat architecture, intended to suppress bottlenecks and provide low end-to-end latencies. Recently, both technology vendors and railway operators have shown some interest on LTE for railway use3,4,5, and the UIC has identified LTE as the key technology for train-to-wayside communication6.
The key point of this paper is to discuss the feasibility of carrying CBTC data over an LTE network. The LTE network could be a public one (owned by a mobile operator) or entirely private (property of the transportation authority or the operator) and some technical, operational and even legal issues should be addressed here. We try to answer this question with the help of our expertise in this area and some field measurements carried out recently.
Metro de Madrid: case and experience
Metro de Madrid is the seventh largest mass transit network in the world with 12 lines, over 300km of double-track and 301 stations. Carrying almost 700 million passengers a year and up to 2.5 million in a single day, some of its lines reached their maximum capacity in 2007. Legacy signalling systems were unable to provide the needed headway, and (without prejudice to other measures) CBTC technology was chosen to upgrade both Lines 1 and 62. Bombardier’s Cityflo 650 was the chosen technology, and a few years later, Sirius, the former Invensys Dimetronic (currently Siemens RA) CBTC solution, was selected to upgrade the signalling system of Line 7B.
Metro de Madrid has CBTC technology on Lines 1, 6 and 7B, which means 131 trains (762 cars) and 56.13km of track are equipped with this technology. The total passenger figure for those three lines is close to 300 million a year. The commissioning of each was carried out with no disruption to passenger services and working during maintenance hours (from 2:30am to 5:30am). The availability of the whole system is above 99%, which gives a good idea of the technology maturity and the efficiency of the integration with the operational issues within Metro de Madrid.
Furthermore, Metro de Madrid has a state-of-the-art security technology network. Since 2003, a large CCTV system on every station and on almost every train has been deployed. This CCTV system allows the Operations Control Centre (OCC) to watch in real-time what happens inside its trains, and also permits on-demand CCTV-recording downloads. The required train-to-wayside radio technology to carry this data is similar to a Wi-Fi radio, adapted to railway use by the Spanish company InfoGlobal. This technology, whose brand name is TEBATREN7, started as a joint research and development (R&D) project between Metro de Madrid and InfoGlobal, occupies 50 MHz in the 685-735 MHz band, and also 20 MHz in the 1675-1695 MHz band (the latter is only deployed outdoors, and the former only within the tunnels), plus achieves a bit rate of 12 Mbps at the application layer. However, this radio is not intended for safety applications due to its limitations, and it is only used for non-critical services such as CCTV, remote maintenance, infotainment, etc. The launch of this technology in 2003 made Metro de Madrid a pioneer in train-to-wayside radio and, most importantly, in the field of the services carried over it. Even today, Metro de Madrid has one of the largest (if not the largest) broadband radio coverage in the world, with eight entire lines, which means 288 trains (1,369 cars) and 163.76km.
Narrowband radios should also be mentioned: TETRA and legacy PMR. TETRA is deployed in seven lines (3, 6, 7, 8, 10, 11 and 12), which means more than 172km, plus depots. Legacy analogue radiotelephony is deployed all over the network, but it acts only as a backup system in case that TETRA is not available. These two systems support voice communications between the OCC and train drivers, which makes them essential for the day-to-day operations.
On the R&D field, Metro de Madrid has participated, and continues to participate, in many European projects related to train-to-wayside communications, like Tecrail3 and Roll2Rail8 etc. Metro de Madrid is clearly on the cutting-edge of many technologies, and one of them is the train-to-wayside radio.
The formal definition of CBTC given by the IEEE9 is: ‘A continuous automatic train control system utilising high-resolution train location determination, independent of track circuits; continuous, high capacity, bidirectional train-to-wayside data communications; and train borne and wayside processors capable of implementing vital functions’. Regarding the radio subsystem, the requirements are clear: it has to be continuous, high capacity, and bidirectional. In this section we will put these requirements into a quantitative way, and we will also cover RAMS issues.
We assume that the coverage is complete (or ‘operationally’ complete), but this does not necessarily mean that the end-to-end quality of service (QoS) fulfils the requirements. Continuity should be checked in terms of delay and jitter, because larger delays will lead to service disruption.
Table 1: Ping latency and hops for Wi-Fi, LTE and UMTS
UMTS (public network)
LTE (public network)
10 – 13
Wi-Fi (enterprise network)
Here, capacity means not only bandwidth (or more precisely bitrate), but also being able to manage all the needed resources in order to provide the service – i.e. all the ‘magic’ related to radio resource management (RRM) functions, like scheduling, handovers, admission control, security, interference handling, etc. This ‘capacity’ is one of the main strengths of LTE, as we will see.
Finally, communications are required to be duplex, since the one-way communications systems have worse performance and generally worse CBTC capacity.
If we consider CBTC data traffic as a mere byte stream, we should take into account two figures: packet size and interdeparture time between packets. With these two variables (usually depicted as a distribution probability function) we should be able to properly study CBTC data on a communications network. However, from the service point-of-view, the requirements to be fulfilled by the network for a given service should be stated in terms of end-to-end delay, jitter and bitrate. Packet loss and time-to-connect may also be important, and will be explained later.
Among all the factors that have influence on headway and trip and schedules9, the only one that is directly related to the radio subsystem is the communications delay. Other factors that address issues like speed determination accuracy, location determination, etc., are not going to be considered here because they are not radio-related. IEEE specification9 provides a nominal delay of 0.5-2 seconds for both train-to-wayside and vice versa. This is quite a long time for such a step, but, even if it is fulfilled by the radio subsystem, it is not the same (in terms of headway) having an end-to-end delay of half a second or two whole seconds. Vendors should try to minimise this delay as much as possible.
Typically, communication delay depends on two different factors: transmission delay (depending on packet length and bitrate) and propagation delay (depending on the channel, on its length and number of hops). Moreover, in CBTC systems, since we have many trains in one zone, the interrogation cycle (time to sequentially interrogate every train) is linearly proportional to the number of trains in a given zone. Therefore, to properly dimension a CBTC zone, delays and number of trains should be considered.
In CBTC services typical packet size is very short (very few bytes). Packets are usually transmitted over UDP instead of the more robust TCP, due to timing limitations. This is a very common approach in real-time applications such as VoIP, but it is not mandatory at all.
Finally, a CBTC system has some MTBF figures for the whole system that should be taken into account in the design phase, since COTS equipment usually does not achieve requirements like these.
Long-Term Evolution is the latest cellular communications standard that has achieved global acceptance. It is standardised by the 3GPP, and on its 10th release (called LTE-A) it has been acknowledged by the ITU as a 4th generation (4G) mobile system. Among its most remarkable advantages are the flat architecture (which leads to shorter delays and cheaper equipment than those in 3G), more spectral efficiency and the ability to get the best performance from the radio interface (using media access techniques like OFDMA and SC-FDMA, and MIMO setups). It is also a full-IP packet-switching technology, intended to be very flexible and adapted to almost every possible scenario. This flexibility is king in LTE: it allows many different bandwidths, allows carrier aggregation, works under TDD (Time Division Duplex) and FDD (Frequency Domain Duplex) modes, has several MIMO setups (2×2, 4×4, etc.), plus admits broadcast and multicast, etc. Moreover, LTE has been standardised in many different bands for both TDD and FDD. Figure 4 shows LTE architecture, with two stratums: access and core.
The access or radio stratum is called E-UTRA. The element that handles the radio resource management functions like handovers, resource allocation, scheduling, etc., is the eNB. Interface X2 connects neighbouring eNBs, and it is mainly used to share interference and handover-related information. Interface S1 is the backhaul interface, and connects access and core stratums. The core stratum has three main components10:
- PDN Gateway (P-GW): is responsible for IP address allocation for the UE, as well as QoS enforcement and flow-based charging, plus it is where the PCRF (Policy Control and Charging Rules Function) can be found
- Serving Gateway (S-GW): is the local mobility anchor for the data bearers when the UE moves between eNodeBs and collects charging information
- MME (Mobile Management Entity): processes signalling information between core and user terminals, to establish connections, handle security issues, etc.
We can also find the HSS (Home Subscription Server) with the AuC (Authentication Centre), responsible of the users’ subscription data and authentication issues, respectively.
Of course, LTE standardises the minimum necessary to guarantee interoperability and performance, and much functionality is defined by the vendor (for instance, handover strategies). First-line LTE vendors, like Huawei or Alcatel-Lucent, have already launched their solutions, with macro or micro cores, distributed nodes, and small cells, etc. As of December 2014, LTE is widespread all over the world.
Due to the fact that LTE does not implement soft handovers, during the handover phase some data may be lost. Therefore, to implement safety-related services we should take this issue into account. Due to the flatness of LTE architecture, delays are significantly shorter than other mobile technologies.
Another important point in this case, is the availability of on-board LTE equipment. As in wayside equipment, both Huawei and Alcatel-Lucent are leaders in the field of on-board LTE devices, with both investing heavily in R&D projects.
The main drawback for LTE technology is its high cost (compared to other alternatives, like its IEEE 802.11 counterparts). Also, market and regulation issues may complicate the commissioning, since almost every single LTE band is licensed, and the subway operator must sign an agreement with a mobile operator to use this spectrum with some guarantees. However, there are two more possibilities: deploying LTE in an ISM band (where no agreement with an operator is needed) or being a regular user of a mobile operator. These two options imply many challenges.
In this section we highlight some of the challenges that should be addressed, either by the vendor or the subway operator, in order to provide a CBTC service over an LTE network. We consider two different cases: a public LTE network or a private one. Each one has its positive and negative points.
- Security against attacks
Subway operators must consider the risk of being hacked. Radio subsystems are obviously more exposed, especially in ISM bands. In 2012, the Shenzhen CBTC system in China was reportedly jammed and the railway authorities interrupted 3G services for a day11,16. As far as we know, no explanations were given by the CBTC vendor or by Shenzhen’s transport authorities. LTE’s cipher is more robust than IEEE 802.11 a/b/g (which forms the basis for almost every CBTC radio subsystem). Another security issue that should be addressed is the end-to-end encryption. LTE provides this functionality only for the air interface, but not for the backhaul. This could be a good scenario for a man-in-the-middle attack in S1 or X2 interfaces, and such a threat could be devastating for a CBTC system. The solution could be implementing IPsec12 in order to avoid CBTC data traveling through the network as plain text. Another possibility (very common in Asian mobile operators) is to implement an application-layer cipher (avoiding network-layer ciphers), but this solution could be costly for CBTC vendors. All this protection should introduce some extra latency, so its impact has to be considered carefully. Despite all this, there are no attack reports on S1 or X2 interfaces, but since a CBTC system is a critical infrastructure, a railway operator should address these threats before they become real.
Unlike IEEE 802.11 networks (that only need to be connected to an IP network), LTE needs a core which can imply extra cost. However, on-board devices have a similar cost in both technologies, but the whole CAPEX is quite higher in LTE. A possibility to overcome this is to reach an agreement with a mobile operator, in order to use its LTE network for the CBTC service. This can be done in several ways, but this way has a much lower cost than commissioning a whole LTE network by a railway operator. One of the ways is to segregate from the operator’s spectrum (typically 10 MHz) a 1.4 MHz channel for the CBTC radio (which is the smallest piece of LTE spectrum that can be ‘segregated’). Or even simpler, not reserving any spectrum and having CBTC radios as a regular customer in the air interface. This needs an extra analysis, because it could lead to an interruption of CBTC service in case of network saturation. Since the number of passengers in CBTC lines is usually huge, mobile operators could be willing to deploy its networks. This is both a technical and a business issue
Another issue that should be addressed is the new ‘CBTC over LTE’ system safety case. As far as we know, there is no experience in that scenario.
- Technology maturity
LTE is deployed worldwide for public communications, but it is somewhat immature for railway communications (there are only a few railway operators that have deployed LTE, Zhengzhou –with Huawei equipment– among them13). However, LTE ‘release 13’ is expected for 2016 and it will include some public-safety functionalities that could make this technology more attractive for railways.
- Quality of Service (QoS) and latencies
If a subway operator decides to carry CBTC data over a public LTE network, its first worry should be the security, but the second should possibly be the QoS. LTE provides a powerful framework for this task that could allow many services to be transported through the same network, but with different priorities and quality.
- GoA 3-GoA 4 upgrade
If a subway operator decides to upgrade from a GoA2 to a GoA3/GoA4 (DTO/UTO) system15, they should be able to remotely control various train systems (see previous point 5). Moreover, real-time CCTV should be available in the OCC, but if there is no broadband radio train-to-wayside deployed, commissioning a broadband radio communications system only for CCTV may increase the cost significantly. So, this subway operator should consider the CAPEX of a broadband radio for non-safety services.
- Interoperability between communication systems
The trend in train-to-wayside broadband radios is IEEE 802.11, even if it is with some minor modifications at the link or network layer that do not allow interoperability between manufacturers.. These proprietary solutions are costly and cause dependency on vendors. To avoid this, instead of signing an ‘escrow agreement’ or similar, other options are open standards like 3GPP LTE. This scenario ensures technological continuity in case there are problems with the technologist.
LTE is available in many frequency bands (both in TDD and FDD modes) and also in unlicensed ISM bands. However, the choice of the frequency band has implications both technically and in business. For many railway operators, the cost of the spectrum is unaffordable and must go hand-in-hand with a mobile operator. Besides, many countries may not allow a rail operator to own a license like this. Unlicensed LTE spectrum may sound interesting, but it has some drawbacks (i.e. unpredictable QoS) that could make it unsuitable for CBTC.
Finally, it is known that Huawei and Alstom are performing some tests to check LTE feasibility for CBTC at Alstom’s facilities in Valenciennes14. At the time of providing this article, no preliminary results have emerged, but there is a great expectation in the railway sector. Also, the aforementioned SYSTUF4 project should provide some interesting results on this field.
CBTC communication requirements are quite straightforward: a bitrate below 100 kbps, delays bound to some tens or hundreds of ms. Among these three, the most demanding one is the end-to-end delays, because LTE is able enough to fulfil the bitrate requirement even in harsh conditions. The point here is to compare end-to-end delays on a LTE and Wi-Fi-based networks.
Since there is no CBTC over LTE service anywhere, it was not possible to perform real tests, so there were compared a public access to Internet via LTE (operator’s) with a 3G access and a Wi-Fi-accessed enterprise network with access to the Internet in terms of latency (pinging www.google.es). The results are presented in Table 1.
As shown in Table 1, LTE network experiences a higher delay due to the extra hops in the entire path. This delay is below 50 ms, a bound considered suitable for some real-time services (such as online gaming), so it should be enough for CBTC. To properly benchmark these technologies, it should be considered any other delay within the chain (i.e. interlockings, on-board processing, etc.). But this is just a basic test, intended only to show that LTE has similar delays to its ‘domestic’ counterparts and legacy systems (like UMTS). This KPI depends heavily on many ambiguities, like technical decisions (i.e. using MPLS or not) made by mobile operators, or the distance between the mobile device and the base station, etc. However, it is coherent with some comparisons found in the literature14.
Another field where LTE overtakes legacy mobile networks is in the use of MIMO (Multiple Input Multiple Output) technology. From version ‘n’, IEEE 802.11 family of standards uses MIMO, but most CBTC deployments are based on former standards (a/b/g). Some measurements carried out two years ago by the Metro de Madrid Engineering Department, showed that MIMO is a suitable technology for train-to-wayside communications in tunnels. Figure 6 shows a comparison in terms of capacity between a 2×2 MIMO system and the baseline 1×1 SISO.
In this paper we have summarised the Metro de Madrid experience on CBTC technology and broadband radio communication systems. In the following paragraphs are summed up the most important CBTC requirements and provided a brief overview of LTE technology; then, it’s mentioned some challenges that should be addressed in order to carry CBTC data over a LTE network, to conclude with a discussion of this open issue.
This paper aims to start the debate on the feasibility of CBTC over LTE technology. The previous sections have described the main implications of carrying CBTC data over a LTE network. From the point-of-view of a cutting-edge subway operator, both technical and operational aspects have been discussed. More detailed tests should be carried out to properly answer the question, but the technology is very promising. Moreover, security and business issues should also be addressed.
However, for signalling services, there are many issues that should be addressed so it is not that simple. What’s intended here is nothing more than starting the debate on this interesting topic – thoughts and ideas of this topic are welcome18.
- From the point-of-view of Metro de Madrid
- Rodríguez, L .Simón, A. Muñoz, “The CBTC Line 1 & 6 Project. Metro de Madrid”, IRSE News, Issue 145, May 2009, pp. 5-10.
- http://tecrail.lcc.uma.es/ (Retrieved 15 May 2015)
- http://www2.alcatel-lucent.com/blogs/tracktalk/issue-7/automated-metro-technology-continues-to-evolve-with-alcatel-lucent/ (Retrieved 15 May 2015)
- ‘Huawei Future-Oriented LTE for Rail solution’, [online]: http://www.huawei.com/minisite/Innotrans/download/LTE%20Solution.pdf (Retrieved 15 May 2015)
- LTE / SAE – The Future Railway Mobile Radio System? Long-Term Visions on Railway Mobile Radio Technologies Technical Report. Paris, November 2009. A Future Railway Mobile Radio System, Version 1.1. V 1.1 – 20.11.2009.
- http://www.infoglobal.es/ES/pdf/Presen_Tebatren_v00_en.pdf (Retrieved 15 May 2015)
- ‘Kick-Off of three Shift2Rail projects: Roll2Rail, IT2Rail and In2Rail’ – http://www.unife.org/component/attachments/attachments.html?id=422 (Retrieved 15 May 2015)
- 1-2004 – IEEE Standard for Communications-Based Train Control (CBTC) Performance and Functional Requirements. IEEE Vehicular Technology Society. Reaffirmed: 2009.
- LTE Mobile Transport Evolution. Strategic White Paper. http://lte.alcatel-lucent.com/locale/en_us/downloads/Alcatel-Lucent_LTE_Transport_WhitePaper.pdf (Retrieved 15 May 2015)
- ‘Shenzhen Metro shuts 3G service a day after trains inexplicably stop’ – http://www.scmp.com/news/china/article/1084297/shenzhen-metro-shuts-3g-service-day-after-trains-inexplicably-stop (Retrieved 15 May 2015)
- An Illustrated Guide to IPsec: http://www.unixwiz.net/techtips/iguide-ipsec.html (Retrieved 15 May 2015)
- Huawei Launches First Urban Rail Transportation Solution Featuring Enterprise LTE Technology for Zhengzhou Metro in China: http://www.railway-technology.com/news/newshuawei-launches-first-urban-rail-transportation-solution-for-zhengzhou-metro-4140822/ (Retrieved 15 May 2015)
- Laner, P. Svoboda, P. Romirer-Maierhofer, N. Nikaein, F. Ricciato and M. Rupp, ‘A Comparison Between One-way Delays in Operating HSPA and LTE Networks”, Vienna University of Technology, Austria, FTW, Austria, EURECOM, France, WINMEE’12, May18, 2012, Paderborn, Germany: http://wi-opt.cs.upb.de/winmee/A%20Comparison%20Between%20One-way%20Delays%20in%20Operating%20HSPA%20and%20LTE%20Networks.pdf (Retrieved 15 May 2015)
- Railway applications. Urban Guided transport management and command/control systems. Part 1: system principles and fundamental concepts. (IEC 62290-1:2006), Part 2: Functional requirements specification (IEC 62290-2:2011).
- ‘Passenger Wi-Fi freezes third Shenzhen Metro train in a week’ – http://www.scmp.com/news/china/article/1078165/passenger-wi-fi-freezes-third-shenzhen-metro-train-week (Retrieved 15 May 2015)
- Moreno, L. de Haro, C. Rodríguez, L. Cuéllar and J. M. Riera., ‘Keyhole estimation of a MIMO-OFDM train-to-wayside communication system on subway tunnels,’ IEEE Antennas and Wireless Propagation Letters, vol.:14, 2015.
- The authors of this paper welcome contact about the topic of this article via email at [email protected] and [email protected].
Carlos Rodríguez Sánchez is currently both CTO and Head of the Engineering and R&D Department of Metro de Madrid. His industry experience includes several positions as Rolling Stock and Trackside Engineer in the railway industry – among them the leadership of CBTC projects in Madrid de Metro. He has a PhD in Electrical, Electronics and Control Systems Engineering, and also a PhD in Economics. Carlos’ research interests are related to railway signalling and safety in software development within industrial environments.
Juan Moreno García-Loygorri has been working in the railway industry for the last nine years, with a particular interest in radio communications and systems engineering, in both high-speed rail and subways. He currently works in the Engineering and R&D Department of Metro de Madrid. He participates in many R&D projects related to these issues, like TECRAIL or Roll2Rail. In October 2015 he presented his PhD Thesis on Communications Engineering.