The Private Mobile Network GSM solution is an amalgamation of both hardware and software technologies that allow the deployment of a private and secure GSM.

1. QWB 1237
Technical Note
PMN Connectivity
Introduction
The Private Mobile Network GSM solution is an amalgamation of both hardware and software technologies
that allow the deployment of a private and secure GSM network.
This document outlines the IP network architecture behind the GSM network and the various methods of
connectivity and backhaul available as well as considerations that must be taken when designing a new or
deploying onto an existing IP network infrastructure. It is assumed that the reader has an understanding of
basic IP networking principles.
A GSM network must consist of a number of core components:
A Mobile Switching Centre (MSC) is the core intelligence within the network and is responsible for call
routing/switching, both internally on the network and also for outbound communication, and network and
subscriber authorisation and registration. It also must coordinate signalling between other key components
on the GSM network and other externally connected devices (PABX/Gateways etc).
The MSC works in conjunction with its Home Location Register (HLR) which is effectively a database of
subscriber information. Within PMN the HLR can act as a register for “home” subscribers or it can have a
dual role as a Visitor Location Register (VLR) which, when connected to another GSM network, can hold
information for other network subscribers that are allowed to transiently “roam” onto the private GSM
network.
Also present in the network is the Base Station Subsystem (BSS). In the case of a private GSM solution this
generally consists of two parts; hardware GSM cells (base stations) that physically transmit the GSM signal
to the handset and a separate software Base Station Controller (BSC) application that controls and
coordinates those cells. As private GSM networks tend to be deployed in localised environments typically a
single BSC is required however, as the size of the cell network increases, there may the need for a number
of separate BSC entities to each control a specific cell groups.
GSM network functionality, such as SMS and GPRS data, require other network components in order to be
available.
The Short Message Service Centre (SMSC) works alongside the MSC to provide SMS delivery across the
network for local network subscribers and the ability to transmit data across the GSM network requires the
use of a GPRS Support Node (GSN). Connectivity of both will be discussed later in this document.

2. QWB 1237

3. QWB 1237
Internal IP configuration
The network routing of a private GSM network is based around standard IP principles regardless of whether
the network is operating as a standalone island GSM network, extended to form part of a larger telephony
infrastructure or simply connected to the PSTN for external connectivity.
Regardless of connectivity the use of static IP addressing for some GSM components is necessary. The
MSC and BSC(s) must have a unique static IP address; this is necessary to create a fixed GSM and IP
network structure. The use of DHCP across the GSM network would create a network where the IP identity
of components would constantly fluctuate and would result in total confusion from a routing and signalling
perspective. The BTS, under certain circumstances, can utilise DHCP however, where possible, a static
scheme for BTS should be adopted for ease.
Although the MSC and BSC are both delivered in software they actually reside on different operating
systems; the MSC is a Windows application and the BSC sits in Linux. On smaller systems the BSC will run,
using VMWare, in a virtual machine on the MSC Windows based server with larger systems separated into
distinct machines for each role.
Communication between components is port based. The MSC uses ports alongside its IP address, typically
port 5060 for inbound and outbound SIP traffic and port 5000 to connect to the Linux BSC over the GSM “A”
interface. Multiple components may reside on the same server so there must be a way of differentiating
traffic between components so specific ports may be assigned to route traffic accordingly based on
component or traffic type.
For instance, the SMSC typically sits alongside the MSC on the Windows machine but in order to ensure
that traffic for the SMSC hits the intended target it is specifically configured in the MSC as a gateway that
utilises a different port (5080) to the standard SIP port (5060).
GPRS Connectivity
Although typically GPRS would not be used in an island network, as there would be no means of connecting
to external sources, it could be used to connect to internal applications that utilise data over GSM.
The software that delivers GPRS functionality within the GSM network is called the GPRS Support Node
(GSN) and consists of two elements:
The GGSN (Gateway GPRS Support Node) is the main element of the GSN and effectively acts a router
between the IP network and the SGSN. The SGSN (Serving GPRS Support Node) works behind the GGSN
and is responsible for mobile handset location management, internal packet routing and session
maintenance.
When a handset requests a data connection it must first be authenticated against its SIM credentials and the
Access Point Name (APN) requested. If successful is will be allocated a dynamic private IP address,
separate to the addressing range on the local IP network, and a Packet Data Protocol (PDP) context session

4. QWB 1237
will be activated. It is the responsibility of the GGSN to take the data from the PDP context and ensure that it
is in the correct format for passing to and from the external IP network.
The diagram below outlines typical IP network connectivity for an island GSM network. Actual port numbers
and IP addresses may differ.
Extending the PMN network
To move from an island GSM network to one that can extend and connect to other telephony infrastructures
is a relatively straightforward task with the primary considerations being the IP/LAN configuration and the
end telephony infrastructure/device that the GSM network will ultimately be connecting to.
LAN configuration and backhaul
As previously stated, each of the main GSM components, the MSC, BSC and BTS, need to be allocated
static IP addresses to maintain a fixed signalling and routing structure internally within the GSM network.
Generally it could be assumed that the PMN network would be separated from other connected IP networks
for security purposes however if PMN is added into an existing network within the incumbent IP addressing
scheme then, aside from the possible reallocation of alternative static IP addresses to the GSM components,
the configuration from a network perspective would be minimal. Appropriate routing within PMN would still
need to apply to pass calls to switches or gateways.

5. QWB 1237
When PMN is deployed on a subnet from an existing network then correct router configuration is required to
allow signalling and RTP to pass to and from the appropriate GSM components. If the components are not
directly addressable across the network and NAT is used then the router would have two IP addresses - a
network facing address and, in this case, an internal PMN address. The externally facing router address can
either be static, if a suitable address is allocated by the network, or determined over DHCP. The internal
PMN address always needs to be static.
For single BTS deployments the router would need to be configured for port forwarding with the following:
RTP and CSD (all UDP) over ports 4000-4031: IP address of the BTS
SIP (UDP) over port 5060 (if configured as the SIP port): IP address of the MSC.
For multiple BTS deployments, if NAT is an issue, then you could utilise the MTP component as an RTP
proxy.
MTP is a Windows based PMN licensed software component that primarily offers a means of transcoding FR
GSM into G.729 or G.711 using SIP. It can also act as point of distribution for RTP when connecting from an
external network to a multi-BTS internal structure. It would typically reside on the Windows server for smaller
installations but could be separated should the volume of transcoding required necessitate a dedicated
server.

6. QWB 1237
The MSC routes all audio from the BTS through MTP and port forwarding will direct audio inbound from the
router to the MTP, which will distribute the audio to the appropriate BTS. Instead of using the default port
range of 4000-4031, which is the default for a single BTS, an MTP port range must be configured - for
example 4000-4999. Currently CSD is not supported over NAT for multiple BTS deployments. This must
then match in the router port forwarding settings:
RTP (UDP) over ports 4000-4999: IP address of MTP (usually Windows machine/MSC address)
SIP (UDP) over port 5060 (if configured as the SIP port): IP address of the MSC
For both single and multiple BTS deployments ensure that the default gateway address is set as the internal
router address for all GSM components.
When breaking out to connect to a device or infrastructure over the Internet then it is necessary to configure,
within PMN, the public internet address of the network. This is necessary so that the MSC can present to the
device the outbound SIP so that it appears to be sent from the public IP address. As the port forwarding
configuration would also be implemented on devices at the edge of the network any inbound SIP returned
from the Internet would be routed accordingly back into PMN. Alternative technologies could be utilised to
work around public address NAT issues, such as a Session Border Controllers, Application Layer Gateways
or the use of Virtual Private Networks.
Switches and Gateways
Although PMN is built upon an open standards model and delivers all outbound traffic in SIP, in order to
interconnect with other telephony platforms it may be necessary to transcode the RTP audio from the Full
Rate GSM codec to a VoIP codec such as G.729, G.711 or potentially to another digital telephony protocol
such as Q.Sig or DPNSS.

7. QWB 1237
This can be done either through a hardware gateway, such as the Vegastream family of telephony
gateways, or, where transcoding only is concerned, through software.
Transcoding is not always required, for instance, when connected to Asterisk or other IP switch platform that
directly accepts the Full Rate GSM codec.
PMN utilise a standard SIP stack (Radvision RFC 3261) and therefore should be able to connect to other
compliant SIP platforms for call distribution however care should be taken, through testing, to ensure that all
systems are compatible.
In order to route any calls from PMN to another location there must be a gateway and route defined the
within PMN Administration portal. Although a gateway may refer to a physical gateway, which allows a
transcoded SIP call to be passed to section of network infrastructure, it could also refer to a direct
connection to a SIP enabled PBX.
Internal traffic characteristics
While the above diagrams shows the IP connectivity of each component and the greater IP network it does
not identify the actual traffic on the network generated by the components. Purely from a GSM standpoint
there are only two types of traffic generated on the network: RTP traffic (audio) and signalling.
Signalling
Although it generates much less in terms of bandwidth per second on an IP network the amount of
bandwidth usage over time could potentially amount to much more than the total RTP audio generated.
Obviously this will be relative to total call volumes however consideration should always be taken when
sizing the network for GSM.
Although Signalling is generated between all of the GSM software components on the network on smaller
deployments where components are installed on a single Windows server, with a Linux virtual machine,
almost all of this signalling is kept locally. The only non-local signalling exception is between the BSC and
the BTS units. This is known as the “Abis Interface” and generates bursts of traffic of <8kb/s of TCP, usually
on port 3003, and only applies when the BTS is not in a multiplexed mode.
Only when Windows and Linux components are split does signalling become more apparent on the network
with the “A Interface” between the MSC and BSC. This is the primary GSM signalling stream between the
two components and, like the BSC/BTS interface, it delivers TCP bursts of <8kb/s usually on port 5000.
On the rare occasion that the MSC and SMSC would be separated there would be signalling between the
two components and consideration should be taken if large volumes of SMS traffic are being delivered. This
takes the form of proprietary SIP messaging typically on port 5080.

8. QWB 1237
GPRS data usage
When a GSM network is configured for GPRS/EDGE there is an overhead as connections are made from
the handset to the GSN. The signalling itself to setup the connection is negligible however the data rate
available is dependant on the GPRS coding scheme adopted by the handset. This determined by a number
of factors, the type of BTS (GPRS/EDGE), the power rating of the BTS (Normal/High power) and the actual
power being delivered.
If all the conditions above were favourable then the only other deciding factor would be the distance from the
handset from the cell. The further from the cell the lower the available bit rate per timeslot however the lower
bit rates, <8kb/s for GPRS and <23kb/s for EDGE, are available over 98% of a cells coverage area and they
have higher error correction and provide a more stable connection. Whereas the higher rates, <20kb/s for
GPRS and <60kb/s for EDGE, are only available in less then 25% of the coverage area and contain less
error correction.
Typically, a handset that has un-contended access to available GPRS timeslots will utilise a maximum of
four slots to quadruple the available data rate however as more handsets register and demand GPRS
resources, from the same BTS, the available data resources may eventually be split to the point of handsets
sharing individual timeslot resources.
The data rate available to the user is generally related to the actual bandwidth utilisation on the network, at
least from the GGSN outward onto the IP network. Internally, when handsets are connected, the SGSN uses
the full allocation of timeslot bandwidth to the BTS however depending on the actual data rate achieved by
the user this bandwidth may be more error correction than actual application data.
RTP
Although signalling is constantly being delivered between components it is the RTP traffic that generates the
highest bandwidth on the network. RTP traffic, wherever possible, is delivered point-to-point which means
that on a multi-BTS platform, when callers are connected to different BTS, the RTP audio traffic is sent from
one BTS directly across to the other BTS regardless of the IP routing of the signalling.
A GSM full rate call (FR) will generate approximately 34kb/s over Ethernet however if the network is
configured to work in Adaptive Multi-Rate (AMR) or half rate (HR), the network overhead for a fully loaded
BTS at would be slightly higher due to the increase in IP headers.
The only exceptions, on an island network, where RTP would not be routed point-to-point is where, for
diagnostic purposes, RTP would be routed through PMN MTP software which would allow maintainers of a
single BTS system to analyse RTP traffic between handsets.
The other exception is where multiplexing it utilised. Multiplexing from a BTS standpoint is where all call
timeslots are amalgamated into one stream and instead of RTP being delivered directly to the appropriate
BTS they are routed through the BSC which dissects the multiplexed stream and routes the traffic
accordingly. Although multiplexing has definite advantages with regard to overall network bandwidth usage
per fully loaded BTS it does incur an increased overhead for single calls. A single call in a multiplexed

9. QWB 1237
stream would generate around 39kb/s, which is a slight increase on the traffic generated by a single point-to-
point stream, however for seven concurrent calls the total overhead is only around 140kb/s compared to 244
kb/s for seven individual calls. It would not be a routing method typically adopted on a network built upon a
standard IP LAN architecture where bandwidth is not so much a consideration or where call traffic is low
however it would suit deployments where BTS are remote and a large volume of outgoing calls are being
delivered across a bandwidth sensitive medium – satellite for instance. It can also be configured on a per
BTS basis which would cater for a mixed IP LAN network with some remotely deployed BTS.
It does have its disadvantages however in that larger numbers of multiplexed BTS routed through the BSC
may present potential local bandwidth issues at the BSC and increased processing overhead to handle both
the required signalling and RTP traffic. In addition it could cause higher latency between handsets on slower
links.
CSD
For customers that require secure, encrypted communication PMN supports the use of handsets that encrypt
and distribute calls over Circuit Switched Data (CSD). This effectively changes the voice call into a modem
call and each call is encrypted and decrypted at the handset by the exchanging of secure keys. The use of
CSD does generate an increase in RTP overhead compared to a normal voice call, utilising around 88kb/s
per call over Ethernet.
Transcoding bandwidth
When transcoding to another voice protocol to connect to gateway or SIP enabled PBX the bandwidth
requirements can suddenly differ. If the gateway can support the GSM FR codec then the bandwidth
requirements per call, at least to the gateway or PBX, are no different to those of an island network when
delivered over Ethernet. However at the point of transcoding, either through MTP or at the gateway, the
overhead changes.
Typically, when discussing audio payloads it is the pure audio bandwidth that is generally discussed
however this should only be the starting point for determining bandwidth. For example, the audio payload for
a single full rate GSM call will generate approximately 13kbps however, over Ethernet, this would increase to
34kbps at layer 4 with the additional overhead being purely the required headers and framing.
Transcoding would typically be to one of the “usual” IP voice codecs – G.729 or G.711.
G.729 is a very efficient codec and is generally used where bandwidth is at a premium. More efficient than
FR GSM it compresses the audio to a payload of 8kb/s which, with the additional IP overhead, would
increase to 31.2kb/s over Ethernet.
G.711, although encoded at 64kb/s and with overhead it sits a 87.2kb/s per call over Ethernet, it does offer
much higher voice quality and is extensively used on internal VoIP platform where network bandwidth is not
so much of an issue.
All of the above refers to voice delivery over an Ethernet network. However, at some point there will be a
requirement to extend the PMN network over some other backhaul medium.

10. QWB 1237
Backhaul
The use of PMN in a vehicle or rapid deployment unit will usually require some form of backhaul of network
traffic to a network operations centre or head office infrastructure. As far a PMN are concerned however, as
long as IP is supported, then the type of backhaul becomes almost irrelevant. Of course, there may be
network or bandwidth considerations that must be taken into account when determining the services and
functionality that will be delivered over backhaul but the actual delivery of signalling and RTP should be
exactly the same as over a standard wired Ethernet network.
Satellite, for example, is a global method of backhauling IP traffic and is the preferred method for many PMN
deployments due to its flexibility, ease of setup and relative cost. Terminals can range from large scale fixed
installations to notebook sized BGAN terminals with varying levels of frequencies and bandwidth available.
The military for instance will have both dedicated frequency bands and satellites to route secure traffic
through whereas anyone can now hire a small terminal and purchase a SIM to provide consumer grade
services.
The network configuration will typically be the same as that of a wired network where the terminal could be
placed at any point across the network to provide connectivity. It may be that the PMN network is completely
unaware of the traffic being routed by satellite if the terminal is placed in the middle of the routing chain. This
could apply for instance in military situations, for instance, where the network is private and secure from end
to end. In consumer situations however the likelihood is that the terminal would be directly connected to the
satellite network for internet access and it would either be acting as an edge of network device on an
extended network or it would be directly connected to the PMN server.
Some terminals have inbuilt functionality to act as a telephony interface, where the user can connect a
standard IP phone, and the SIM that is purchased for satellite airtime will generally have a dialable number
associated with it.
When connected to PMN however the terminal must be in “router” mode to create a data connection through
the satellite network to the internet, assuming that there is some form of public facing voice gateway that
PMN will ultimately be connecting to. An example scenario is shown below.
The same IP configuration rules apply when PMN connects either to a router or to a satellite terminal. The
terminal must be assigned a static internal address to maintain the network structure. As it will be connecting
over the internet to a voice gateway (in the example above) there would be a requirement for the pubic
facing address of the terminal to also be static as this will allow the terminal address to then be added to any
access lists/firewall settings on the voice gateway network to allow stable connection.
Again, if NAT is an issue, then port forwarding must also be set with the terminal router mode configuration.
Again, the routing address for the RTP will depend on the whether the PMN system is single (BTS IP
address) or multiple BTS (MTP address).

11. QWB 1237
In addition to the IP configuration it is important to consider the bandwidth limitations that may be in place,
when backhauling over smaller terminals and the additional overheads that satellite transmission in general
incurs.
For instance, when delivering IP over satellite, there will additional overhead required for each call which is
for IP/Satellite translation - this may be an additional 20% increase in kbps required. The total true value for
bandwidth will also be determined by the equipment deployed to backhaul, its configuration and whether
additional network technologies are adopted such as header compression etc.
In addition to the increased IP overhead for backhaul there are other factors to consider. With long range
backhaul an obvious consideration is latency. Typically satellite communication introduces 280ms of delay
per leg to a conversation however this can increase dependant on the complexity of the network. If the BTS
and BSC are remotely connected across the backhaul link then this latency would cause an increase in call
setup time.
Jitter can also affect voice quality – this is when the sending equipment sends packets at regular intervals
but network delays cause the packets to be received in irregular intervals. This can be managed by the use
of jitter buffers either within the network equipment or the end device however for higher voice quality is
necessary to ensure that packets are sent and received with equal interval timing.
Since all audio traffic is sent over UDP/IP which does not have a mechanism for retransmitting packet it is
essential that the potential for packet loss is reduced. A backhaul link should have the lowest possible BER
(Bit Error Rate) and where possible voice QoS and prioritisation should take place to ensure that network
congestion does not unduly affect voice traffic.

12. QWB 1237
tnpmn101201
This document is provided for information only. In line with company policy of continued improvement of products and services,
TeleWare reserves the right to alter product specification without notice. Private Mobile Networks is a registered trademark. Copyright ©
2010 TeleWare plc.
Private Mobile Networks
York Road, Thirsk,
North Yorkshire, YO7 3BX, UK
Registered in England No 5614745
T: +44 (0) 1845 52 10 52
E: info@privatemobilenetworks.com
W: www.privatemobilenetworks.com