By The FirstNet CTO Devices Team

This blog describes FirstNet’s vision for the Vehicle Network System (VNS) role in incident deployment and coverage extension options.  It updates a past blog about the mobile communications unit (MCU) and aims to clarify both the nomenclature and the differences between the VNS and traditional deployables.   It’s anticipated that the VNS and other alternatives will play a role as coverage extension tools within the wider nationwide public safety broadband network (NPSBN) deployment.

Since FirstNet was established, it has been recognized that providing more network coverage for the states and territories than commercial operators currently provide presents unique challenges that require innovative solutions, including support for remote areas and wilderness.  While there are many alternatives or coverage extensions, such as High Power User Equipment (HP-UE), each has its limitations.  The VNS is a new product concept meant to address the communication needs of remote first responders immediately when they respond to incidents that are outside of terrestrial coverage, or if traditional coverage has become unavailable due to a natural or man made disaster.

 A VNS (previously referred to as an MCU) is a set of radio access and other technologies that enable a first responder’s vehicle to act as a virtual cell site for Band 14 Long Term Evolution (LTE) devices. It can be equipped with satellite connectivity for remote locations and provides network features from within the vehicle when the VNS cannot reach FirstNet’s terrestrial network. Alternatively, it can use HP-UE radios and/or LTE Relay to extend the reach back to the terrestrial network.  In essence, the VNS offers a remote low-capacity temporary extension of regular network coverage.

There are a wide variety of deployable technologies that can be used for remote incidents as well.  All of them have different characteristics and deployment delays.   The following table shows how the VNS relates to other alternatives, including cells on light trucks (COLTS), cells on wheels (COWs), system on wheels (SOWs), or the potential deployable aerial communications architecture (DACA) such as balloons or drones:

To clarify the differences, there are two features that are key to the VNS.  First, VNS  would be built into first responder vehicles that they use every day, so VNS is there when first responders need it, without calling for a conventional deployable to be sent to the incident.  (Note that the vast majority of incidents last less than an hour.) Second, the VNS would support local and remote communications when first responders are outside of terrestrial coverage.  VNS can provide the full set of local communications if the size of the incident expands and additional first responders are needed – giving it the flexibility to transition to support longer incident periods if required. (This is also called the standalone mode.)  The VNS can also hook up to the remote terrestrial network and function as a range extension for it to support the site of the incident.   The following table shows how the VNS relates to other alternatives with respect to response time and incident duration:

A typical installation for a VNS is fixed in the vehicle with antennas on the roof, but another proposed implementation can be via elements small enough to fit in a backpack that’s kept in the vehicle and used on an ad-hoc basis.  That approach requires more research, training and effort, while the vehicle installation is meant to operate automatically for a first responder arriving at an incident.

VNS Technology Elements

The VNS concept is already being addressed by industry players and has been demonstrated or field trialed by some of them, including some of FirstNet’s early adopter community.  Since there will be wide variations in configurations and prices, it will be modular and expandable.  It would likely comprise functional technologies such as:

• In-Vehicle Router (IVR) – when the VNS is within terrestrial network coverage, it acts like every other IVR, using the terrestrial LTE network as a wide area network connection for broadband communications (it  may have Land Mobile Radio (LMR) modems too).  It can support either regular modems or the new HP-UE for longer range and performance.  In IVR mode, it appears as a regular mobile device to the terrestrial network.
• Satellite modem and antenna – once the VNS is fully outside of terrestrial network coverage, it can automatically switch over to the satellite modem.  New satellite technologies can improve some of the performance, physical installation, and cost(s) of including a satellite option.  A rugged low profile antenna design that can withstand extreme environmental conditions will be key to the VNS platform.  Satellite services may support mobile or stationary usage.
• Local eNodeB and antenna – when the VNS is outside of LTE coverage or when additional local coverage is needed, the VNS can automatically act like a remote base station to other users.  It can also function as an LTE repeater to extend terrestrial coverage.  In the range extension mode, it may require additional antennas to broadcast as an eNodeB.  Advanced algorithms (such as self optimization and configuration to optimize transmit power (based on network listen modules, for examples), idle mode cell selection/reselection and connected mode handover parameters) will be crucial for this standalone mode to work effectively and reduce any negative impact to the existing terrestrial network.
• Local Evolved Packet Core (EPC) elements and applications –the level of EPC functionality and application content will vary depending on its modular design, costs, and use cases to be supported.  The goal is for the VNS to provide standalone core capabilities to the first responder’s devices it’s supporting.  New technologies in the area of compact EPC platforms and local application servers will impact the evolution of the VNS roadmap.

Note that there are minimal, if any, UE implications.  In ideal scenarios, the UE sees the VNS as just the regular network, and the arriving first responders to an incident operate their devices as they would normally.  Connection managers in the UE will help support a better user experience and minimize service disruption as the VNS switches modes.

It’s critical that appropriate network operations and radio access network (RAN) planning be used to manage any interference with the terrestrial network when a VNS switches modes or transits through areas with terrestrial connectivity.Similarly, It should be in constant touch with the network and only switch to alternative connectivity like satellites or high power modes when necessary, automatically turning them off when it finds the regular network again.

Potential Functional Architecture

Putting these elements together, a functional architecture might look like the following:

Figure 1 – VNS Diagram

FirstNet is currently coordinating with organizations researching and demonstrating such platforms and working to ensure that the VNS is prioritized as appropriate to support commercial availability of this critical platform.  A number of vendors have already demonstrated initial offers or prototypes that meet many of the goals of a VNS.  In addition, there are relevant standards efforts within 3GPP that, in our opinion, could be relevant to the VNS concept.  These include:

• Support for switching in a standalone eNodeB configuration – formally called Isolated E-UTRAN Operations for Public Safety (IOPS, 3GPP TS 22.346) of Release 13
• Support for device to device (D2D) communication mode (commonly called direct mode) - Proximity-based Services (ProSe, 3GPP TS 23.303 and TS 23.703) of Release 12 and 13
• Support for an LTE Relay Node – (TR 36.826 Relay radio transmission and reception)
• Support for heterogenous networks – (enhanced intercell interference coordination, or ICIC of Release 8 and 10)

These critical 3GPP development activities will be monitored closely to determine when they can be made available for use to support a VNS platform.