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.

QWB 1237

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

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.

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.

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.

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.

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

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.

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).

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.

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