System Release 7.

18
®
ASTRO 25
INTEGRATED VOICE AND DATA

Customer Network
Interface Design
Engineer Guide

SEPTEMBER 2018 MN005339A01-A

© 2018 Motorola Solutions, Inc. All rights reserved
MN005339A01-A
Copyrights

Copyrights
The Motorola Solutions products described in this document may include copyrighted Motorola
Solutions computer programs. Laws in the United States and other countries preserve for Motorola
Solutions certain exclusive rights for copyrighted computer programs. Accordingly, any copyrighted
Motorola Solutions computer programs contained in the Motorola Solutions products described in this
document may not be copied or reproduced in any manner without the express written permission of
Motorola Solutions.
© 2018 Motorola Solutions, Inc. All Rights Reserved
No part of this document may be reproduced, transmitted, stored in a retrieval system, or translated
into any language or computer language, in any form or by any means, without the prior written
permission of Motorola Solutions, Inc.
Furthermore, the purchase of Motorola Solutions products shall not be deemed to grant either directly
or by implication, estoppel or otherwise, any license under the copyrights, patents or patent
applications of Motorola Solutions, except for the normal non-exclusive, royalty-free license to use that
arises by operation of law in the sale of a product.

Disclaimer
Please note that certain features, facilities, and capabilities described in this document may not be
applicable to or licensed for use on a specific system, or may be dependent upon the characteristics of
a specific subscriber unit or configuration of certain parameters. Please refer to your Motorola
Solutions contact for further information.

Trademarks
MOTOROLA, MOTO, MOTOROLA SOLUTIONS, and the Stylized M Logo are trademarks or
registered trademarks of Motorola Trademark Holdings, LLC and are used under license. All other
trademarks are the property of their respective owners.

European Union (EU) Waste of Electrical and Electronic Equipment (WEEE)

directive

The European Union's WEEE directive requires that products sold into EU countries must have
the crossed out trash bin label on the product (or the package in some cases).
As defined by the WEEE directive, this cross-out trash bin label means that customers and end-users
in EU countries should not dispose of electronic and electrical equipment or accessories in household
waste.
Customers or end-users in EU countries should contact their local equipment supplier representative or
service centre for information about the waste collection system in their country.

2
 MN005339A01-A
Contact Us

Contact Us
Motorola Solutions Support Center
The Solutions Support Center (SSC) is the primary contact for technical support included in your
organization's service agreement with Motorola Solutions.
Service agreement customers should be sure to call the SSC in all situations listed under Customer
Responsibilities in their agreement, such as:
• Before reloading software.
• To confirm troubleshooting results and analysis before taking action.
Your organization received support phone numbers and other contact information appropriate for your
geographic region and service agreement. Use that contact information for the most efficient response.
However, if needed, you can also find general support contact information on the Motorola Solutions
website, by following these steps:
• Enter motorolasolutions.com in your browser.
• Ensure that your organization's country or region is displayed on the page. Clicking or tapping the
name of the region provides a way to change it.
• Select "Support" on the motorolasolutions.com page.

Comments
Send questions and comments regarding user documentation to
documentation@motorolasolutions.com.
Provide the following information when reporting a documentation error:
• The document title and part number.
• The page number or title of the section with the error.
• A description of the error.

3
MN005339A01-A
Document History

Document History
Version Description Date
MN005339A01-A Original release of the Customer Network Interface September 2018
Design Engineer Guide

4
 MN005339A01-A
Contents

Contents
Copyrights................................................................................................................... 2
Contact Us................................................................................................................... 3
Document History....................................................................................................... 4
List of Figures..............................................................................................................6
List of Tables............................................................................................................... 7
About Customer Network Interface Design Engineer Guide.................................. 8
Helpful Background Information.................................................................................................... 8
Related Information....................................................................................................................... 8
Chapter 1: Customer Network Interface Design Description..................................9
1.1 Customer Network Interface Design Introduction.................................................................... 9
1.2 CNI Path Components...........................................................................................................10
1.2.1 Border Router.......................................................................................................... 10
1.2.2 Service Access Architecture Considerations........................................................... 11
1.2.3 Dynamic Host Configuration Protocol...................................................................... 11
Chapter 2: Intersystem Packet Data Across Connected CENs............................ 12
2.1 Layer 2 Reference Design..................................................................................................... 13
2.2 Layer 3 Reference Design..................................................................................................... 13
2.3 Additional Topologies to Consider When Connecting CENs of Different Systems................15
2.4 Network Considerations of the Connecting CENs................................................................. 15

5
MN005339A01-A
List of Figures

List of Figures
Figure 1: Simple Layer 2 Deployment Reference Design...................................................................... 13
Figure 2: Simple Layer 3 Deployment Reference Design...................................................................... 14
Figure 3: Example of CEN Isolation When Connecting the ISSI 8000 ASTRO Systems.......................15

6
 MN005339A01-A
List of Tables

List of Tables
Table 1: OSPF Parameter Settings on the Border Router..................................................................... 11
Table 2: Network Specifications for Interconnecting CENs.................................................................... 16

7
 MN005339A01-A
About Customer Network Interface Design Engineer Guide

About Customer Network Interface

Design Engineer Guide
This manual describes how to connect to a customer network interface for ASTRO® 25 systems. The
manual provides a description of the Customer Enterprise Network (CEN), the details of connecting to
CENs, reference topology designs within the CEN, technology recommendations for a Customer
Network Interface, and IP space coordination and separation across the ASTRO® 25 system and the
customer network.

Helpful Background Information

Motorola Solutions offers various courses designed to assist in learning about the system. For
information, go to http://www.motorolasolutions.com/training to view the current course offerings and
technology paths.

Related Information

Related Information Purpose

Standards and Guidelines for Communi-
cation Sites
System Overview and Recovery Refer-
ence Guide
Provides standards and guidelines that should be followed when
setting up a Motorola Solutions communications site. Also known as
R56 manual. This document may be purchased by calling the North
America Parts Organization at 800-422-4210 (or the international
number: 302-444-9842).
Provides an overview of the new system features, technical illustra-
tions, and system-level disaster recovery that support the ASTRO®
25 radio communication system with Juniper SRX routers.

8
 MN005339A01-A
Customer Network Interface Design Description

Chapter 1

Customer Network Interface Design

Description
This chapter provides background information on connecting external customer networks to ASTRO®
25 network.

1.1
Customer Network Interface Design Introduction
The Customer Network Interface (CNI) is the common access point between the ASTRO® 25 radio
network and the Customer Enterprise Networks (CENs) at the physical and logical layers. The CNI
design includes the physical LAN and/or WAN links that provide the connectivity, the routing and IP
addressing involved, and the application interaction across the interfaces.
Implementing any of the following services in an ASTRO® 25 system may require that one or more
networks external to the ASTRO® 25 system are connected to the ASTRO® 25 system IP network:
• Computer Aided Dispatch Interface (CADI)
• Air Traffic Information Access (ATIA)
• Elite Application Programming Interface (API)
• Text Messaging Service (TMS) for Consoles
• Over-the-Ethernet Keying (OTEK)
• MKM 7000 Console Alias Manager API
• Manager of Managers (Simple Network Management Protocol (SNMP) forwarding)
• Charging Gateway for Data User Statistics
• Packet Data Applications for Trunked Data services (classic data and enhanced data),
Conventional IV&D, and High Performance Data
- CAD Radio Services
- Cloud Connector
- Intelligent Middleware
- ASTRO® 25 Advanced Messaging Solution
- Subscriber Over-the-Air-Rekeying (OTAR)
- POP25
- Premier Mobile Data Communications (MDC)
- Text Messaging (Premier One and TMS)
- Radio User Location and Status Tracking applications such as Premier One Responder
Location, Global Navigation Satellite System (GNSS), and so on
- Automatic Vehicle Location
- Broadcast Data messaging for AMBER alerting, Global Navigation Satellite System (GNSS) co-
ordination of fleet members, and so on
• Multi-Solution Subsystem for a Converged CEN configuration

9
MN005339A01-A
Chapter 1: Customer Network Interface Design Description

The CADI provides a server function that allows a CAD server to receive status information from, and
send commands to, the trunked radio system. The ATIA function outputs system status information to
a customer server. CADI and ATIA services are hosted on the Zone Manager subnet, however ATIA
functionality is fed through the Air Traffic Router (ATR). An Elite API, which resides on an Elite operator
position, provides an application connection allowing a separate host to exercise system dispatch
functions.
The client hosts for these services typically reside on networks separate from the ASTRO® 25
networks. These separate networks, referred to as CENs, are independently administered. This
arrangement means that just like the ASTRO® 25 network, they use IP address space allocated for
their specific requirements.
TMS allows clients installed on subscribers and consoles in the radio network to send and receive text
messages to servers in the CEN. OTEK enables Key Management Facilities (KMF) in the CEN to
distribute and manage encryption keys for consoles in the ASTRO® 25 system.
The MKM 7000 Console Alias Manager API provides an interface to the MKM 7000 server in the Radio
Network Infrastructure (RNI) from a CAD system or other third-party application designed to
automatically feed Unit ID-User Alias mappings into the MKM 7000 server. This API also provides the
ability to read the Unit ID-User Alias mappings from the MKM 7000 server for CAD or third-party
applications that use the aliases assigned to Unit IDs in the system.
Applications that communicate using an ASTRO® 25 radio may send and receive data to hosts that
reside in the CEN using either the ASTRO® 25 data services or data services offered by other public or
private networks. The ASTRO® 25 network can also connect to a Multi-Solution Subsystem (MSS)
CEN to provide shared access to the CEN data hosts (Converged CEN solution with LTE).

1.2
CNI Path Components
Several different ASTRO® 25 components make up the Customer Network Interface (CNI) path. The
focus of the manual is primarily on the ASTRO® 25 Border Router which is the end-point component of
the CNI Path at the Customer Enterprise Network (CEN).

1.2.1
Border Router
The Border Router has the following functions:
• Provides an IP domain “isolation” between the De-Militarized Zone (DMZ) and a customer
Customer Enterprise Network (CEN).
• Provides an access point for CEN nodes to the Radio Network.
• Hosts the Data Subscriber Home Network for data traffic.
• Optionally provides Dynamic Host Configuration Protocol (DHCP) services for data subscribers.
Border Routers support both T1/E1 and IPv4 or IPv6 Ethernet WAN backhaul options, dictated by
customer-available transport options between the DMZ and each CEN.
The Border Router can interface with an external network in multiple ways. Static routes can be added
to the Border Router manually, which requires static routes in the attached network as well, or Open
Shortest Path First (OSPF) routes can be exchanged. The following table lists the OSPF parameters

10
 MN005339A01-A
Chapter 1: Customer Network Interface Design Description

configured in the Border Router and are provided to allow interoperability with routers from other
networks.

Table 1: OSPF Parameter Settings on the Border Router

Parameter Setting
Area ID 0
Area Type Transit
Hello Time 1 second
Router Dead Interval 4 intervals
MD5 Authentication Parameters If configure

NOTICE: If a connecting system deploys a converged CEN topology, additional parameters

may need to be configured.
The CEN could have redundant Border Routers for specific Radio Network Infrastructure (RNI)
redundancy configurations. In each Master Site in a system with High Availability (HA) and/or Dynamic
System Resilience (DSR) redundancy, the master site connects to both Border Routers in the CEN.
With redundant Border Routers, hosts on the directly connected CEN subnet can be configured with a
single gateway address. Virtual Router Redundancy Protocol (VRRP) provides router redundancy. A
router from an attached network can point its static route at the VRRP address and benefits from the
re-routing when a Border Router fails or recovers. An alternative approach is to have the router from
the other network participate in the OSPF with the Border Routers. In this configuration, OSPF handles
rerouting when a Border Router fails or recovers.

1.2.2
Service Access Architecture Considerations
The Service Access Architecture (SAA) feature allows a Service Laptop in the Customer Enterprise
Network (CEN) to establish a Virtual Private Network (VPN) with the Radio Network Infrastructure
(RNI), and operate the Private Network Management (PNM) Client via Remote Desktop. If the
Customer Network Interface (CNI) path is being used for CEN VPN connections, see the “On-Demand
VPN Connection to the RNI-DMZ Firewall from the CEN” section in the Service Access Architecture
Feature Guide for the current limitations and potential configuration changes that may be required.

1.2.3
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol (DHCP) allows subscribers to obtain IP address assignments
from a network. The Border Router can be configured to provide DHCP services, or the customer may
supply a DHCP server residing in the Customer Enterprise Network (CEN) that provides dynamic IP
address assignment from the customer-configured IP address pool. This method is in addition to the
static IP address allocation that the network operator can configure for each radio user. The reason for
this stance is two-fold:
• The customer is responsible for IP addresses assigned to their hosts.
• Motorola Solutions is not required to be the ISP, providing and managing customer IP address
space.

11
MN005339A01-A
Chapter 2: Intersystem Packet Data Across Connected CENs

Chapter 2

Intersystem Packet Data Across

Connected CENs
Trunked IV&D Unicast Packet Data Traffic can traverse across different customer system Customer
Enterprise Networks (CENs) for roaming subscribers at other ISSI 8000-connected ASTRO® 25
systems. Subscribers receive voice services with the automatic ISSI 8000 roaming, and can be
configured to exchange packet data with their home system CEN application servers. Customers
seeking packet data services for roaming subscribers at other ASTRO® 25 systems should co-ordinate
for interconnecting the CENs to enable packet data traffic flow. Packet data traffic from the home
system CEN host is delivered through the foreign system CEN and the foreign system ASTRO® 25
system to the roaming subscriber. The IP address space of the connecting CENs of the ISSI 8000-
connected systems requires careful coordination for uniqueness of the following:
• Network Address Translation (NAT) IP space for each zone core connected to each CEN in the
connected Customer Network Interface (CNI) infrastructure.
• Subscriber IP space for each Access Point Name (APN) in the connected CNI infrastructure.
• Unique CEN (and CNI, if different from CEN) LAN IP space for each CEN when Layer 3 is used for
the connected CNI backhaul. When Layer 2 is used, the CEN/CNI LAN IP space for each CEN
must be the same.
This section documents two reference designs for the inter-CEN transport network connections. Open
Shortest Path First (OSPF) protocol is used in the reference designs to propagate the necessary
routing information. The decision to use OSPF is primarily based on the connected CEN CNI backhaul
interfacing with the CNI LAN of each connected CEN. Within each customer system, OSPF protocol is
used to connect the ASTRO® 25 system CNI LAN with a CEN and to share routing information about
the system RNI. The CNI LAN IP space is used for Motorola Solutions networking equipment and
applications. The CEN LAN IP space is where additional customer-specific applications may reside.
The reference designs are also based on the ASTRO® 25 defined IP addressing scheme which is
reused for every customer system. When interconnecting CENs of two different systems, avoid sharing
the duplicate IP space in the connected CNI backhaul which otherwise results in routing conflicts.
Network Address Translation cannot be used at the CENs when connecting them together. The IP
addressing scheme must be changed/coordinated to ensure uniqueness in the connecting CENs.
The scaling and performance of the connected CNIs depend on a number of parameters such as
bandwidth, latency, number of segments, number of areas, routers/area, and so on. The reference
designs account for the other parameters necessary for its deployment. For larger deployments,
standard network engineering practices can be used to assess the overall interconnect design for other
network parameters. For instance, depending on these parameters, it is possible that a Layer 2
deployment must be segmented and broken out into a Layer 3 deployment to meet a certain scaling,
performance, or management requirement.
This section includes the design for one Layer 2 and one Layer 3 network deployment. System
planning and field engineering can deploy the applicable reference design, or use the information from
these designs to customize the transport network of the connecting CENs.
The following acronyms refer to LTE network design terminology. They are noted here as references to
the Layer 2 and Layer 3 designs.
• PNR: Primary Northbound Router
• RNR: Redundant Northbound Router
• PSR: Primary Southbound Router

12
 MN005339A01-A
Chapter 2: Intersystem Packet Data Across Connected CENs

• RSR: Redundant Southbound Router

• LTE MSS: LTE Multi-Solution Subsystem

2.1
Layer 2 Reference Design
The Simple Layer 2 reference design shown in the figure has all border routers of the interconnected
Customer Enterprise Networks (CENs) configured on the same Customer Network Interface (CNI)
LAN. Open Shortest Path First (OSPF) communication occurs directly between the connected border
routers. As a single common CNI LAN is deployed, all connecting CEN application host IP addresses
must be planned and coordinated to avoid IP address conflicts. Also, take care to avoid introducing a
Layer 2 loop when connecting the switches across the connected CENs. If a loop is unavoidable, the
CNI backhaul must be provisioned or set up with a loop detection mechanism such as the spanning
tree protocol. The switches in the CNI backhaul are optional. The design could be such that the CEN
LAN switches are connected, thus eliminating the need for additional switches.
Figure 1: Simple Layer 2 Deployment Reference Design

2.2
Layer 3 Reference Design
In the deployment of the Layer 3 reference design, shown in the figure, each connecting Customer
Network Interface (CNI) LAN (in addition to the subscriber and Network Address Translation (NAT) IP
space) is unique in IP space, and must be routed through the connected CNI backhaul. While the CNI
LANs are separated at Layer 3, the connected CNI backhaul must learn and propagate routing
information from each Border router via OSPF to enable correct routing of the Packet Data traffic. The

13
MN005339A01-A
Chapter 2: Intersystem Packet Data Across Connected CENs

backhaul router interface with Open Shortest Path First (OSPF) running must have the settings
documented in Border Router on page 10 on the Border Router to be able to communicate and learn
routing information from the border routers.
Figure 2: Simple Layer 3 Deployment Reference Design

In the deployment of the Layer 3 reference design shown in the figure, each connecting CNI LAN (in
addition to the subscriber and Network Address Translation (NAT) IP space) is unique in IP space, and
must be routed through the connected CNI backhaul. While the CNI LANs are separated at Layer 3,
the connected CNI backhaul must learn and propagate routing information from each Border router
through OSPF to enable correct routing of the Packet Data traffic. The backhaul router interface with
OSPF running must have the settings documented in Border Router on page 10 on the Border Router
to be able to communicate and learn routing information from the border routers.
After the connected CNI infrastructure learns the routing information from the border routers, it must
determine how to propagate the information through its own network. The connected CNI infrastructure
may extend OSPF backbone (Area 0) through its network, or may choose to have a specific routing
protocol domain within its network. If a separate routing protocol domain is used, all destinations from
OSPF must be redistributed.
If the connected CNI infrastructure is not capable of OSPF communication with the ASTRO® 25 border
routers, static routing is an alternative. The border routers require a static route for each network with
CEN applications, and a separate static route for each set of subscriber IP addresses (besides its own
connected interfaces) that are part of the connected CNI backhaul. If multiple backhaul interfaces exist
on the CNI LAN, a router redundancy protocol such as VRRP should be used. The next hop gateway
of the static routes should apply the shared IP address of the redundancy protocol configured by the
connected CNI infrastructure so the static routes need not be updated upon failure of a physical
backhaul interface.

14
 MN005339A01-A
Chapter 2: Intersystem Packet Data Across Connected CENs

2.3
Additional Topologies to Consider When Connecting CENs of
Different Systems
Possibly only one Customer Enterprise Network (CEN) of an ISSI 8000 ASTRO® 25 system must be
connected to the other ISSI 8000 system, thus enabling partitioning of CEN applications between
roaming and non-roaming subscribers. A CEN can be isolated and not be a participating CEN in the
connected CEN topology. Such an isolated CEN of the ASTRO® 25 system can be dedicated to
hosting Radio Network Infrastructure (RNI) and other data applications which do not have to be
available for roaming subscribers at other systems. Partitioning the CEN topology in such a manner
results in simplification and reduction of the number of errors in planning when connecting the systems.
The following figure represents one such configuration.
Figure 3: Example of CEN Isolation When Connecting the ISSI 8000 ASTRO Systems

2.4
Network Considerations of the Connecting CENs
The network specifications for interconnecting the Customer Enterprise Networks (CENs) documented
in this section are based on the ASTRO® 25 ISSI 8000 Voice profile. The bandwidth is based on the
following assumptions:
• Each user generates 25 message/hour with up to 1472 byte message size, and up to 80% could be
in one direction (IB or OB).
• Each user generates location updates at a 30-second cadence.

15
MN005339A01-A
Chapter 2: Intersystem Packet Data Across Connected CENs

NOTICE: The recommended minimum bandwidth setup for any one direction should be
687,929 bps, equivalent to 11 DS0.

Table 2: Network Specifications for Interconnecting CENs

Number of ISSI Users IPv4 Clear (Kbps) IPv4 Encrypted (Kbps)

250 33 37
500 66 73
750 99 110
1000 131 146
1250 164 183
1500 197 219
1750 230 256
2000 263 292
2250 296 329
2500 329 365
2750 361 402
3000 394 439
3250 427 475
3500 460 512
3750 493 548
4000 526 585
4250 558 621
4500 591 658
4750 624 694
5000 657 731
5250 690 767
5500 723 804
5750 756 840
6000 788 877
6250 821 914
6500 854 950
6750 887 987
7000 920 1023
7250 953 1060
7500 986 1096
7750 1018 1133
8000 1051 1169

16