Pico GSM BTS Product Description

RadioFrame Networks

Nokia S-Series 1.0, ED1 Product Description

October 2007930-0006-02 Rev. A

For More Information 930-0006-02 Rev. A

Service Information This equipment complies with part 15 of the FCC Rules. Operation is subject to the two following conditions: This device may not cause harmful interference, and this device must accept any interference received, including interference that may cause undesired operation. This equipment has been tested and found to comply with the limits pursuant to part 90.691 of the FCC Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. Notices RadioFrame Networks reserves the right to revise this document for any reason, including, but not limited to, conformity with standards promulgated by various governmental or regulatory agencies, utilization of advances in the state of the technical arts, or to reflect changes in the design of equipment, techniques, or procedures described or referred to herein. Liability to anyone arising out of use or reliance upon any information set forth herein is expressly disclaimed, and no representation or warranties, expressed or implied, are made with respect to the accuracy or utility of any information set forth herein. Copyrights and Trademarks RadioFrame Networks is a trademark or service mark, and RadioFrame, RadioBlade and the RadioFrame Networks logo are registered trademarks of RadioFrame Networks, Inc. You may not use these or any other RadioFrame Networks trademarks or service marks without the written permission of RadioFrame Networks, Inc. All other trademarks and trade names are the property of their respective owners. Throughout this publication, the terms RadioFrame Networks, RadioFrame and RFN signify RadioFrame Networks, Inc. © Copyright 2007 RadioFrame Networks, Inc. All Rights Reserved.

ii CONFIDENTIAL AND PROPRIETARY RadioFrame Networks, Inc. FOR CUSTOMER AND END USER USE ONLY

For More Information Please contact: Brett Johnson RadioFrame Networks, Inc. 9461 Willows Road NE, Suite 100 Redmond, WA 98052 USA Tel +1 425.278.2602 Fax +1 425.278.2802 [email protected]

Corporate Office 9461 Willows Road NE, Suite 100 Redmond, WA 98052 USA Tel +1 425.278.2780 Fax +1 425.278.2781 www.radioframenetworks.com

930-0006-02 Rev. A Table of Contents

RadioFrame Networks, Inc. CONFIDENTIAL AND PROPRIETARY iii FOR CUSTOMER AND END USER USE ONLY

Table of Contents 1 Overview .......................................................................................................................7

1.1 Introduction ...........................................................................................................7 1.2 Applications...........................................................................................................8

2 System Overview ..........................................................................................................9 2.1 Architecture Description ........................................................................................9

2.1.1 Mobile Network Operator Customer-Premise Domain ......................................9 2.1.2 Backhaul Domain ............................................................................................10 2.1.3 Mobile Network Operator Infrastructure Domain.............................................10

2.2 System Deployment Scenarios ...........................................................................10 2.2.1 Small Medium Enterprise (SME) Deployment.................................................10 2.2.2 Home/SOHO Deployment ...............................................................................10

2.3 Software Architecture..........................................................................................11 2.4 Overview of S-Series GSM Service ....................................................................11

3 Functional Components ..............................................................................................12 3.1 S-Series Transceiver and S-Series Base Transceiver Station (S-BTS)..............12

3.1.1 GSM/GPRS/EDGE..........................................................................................12 3.1.2 RF Monitor.......................................................................................................13 3.1.3 Host CPU ........................................................................................................13 3.1.4 Baseband Functions, Router and Ethernet PHY.............................................13

3.2 S-Series Aggregation Gateway (S-AGW) ...........................................................13 3.2.1 Base Chassis Unit (BCU) ................................................................................14 3.2.2 Quality of Service (QoS) Tunnelling Appliance (QTA) ....................................14

3.3 S-Series Registration Server (S-RS)...................................................................14 3.4 S-Series Element Management Server (S-EMS) ................................................14

4 Release 1.0, ED1 System Features............................................................................15 4.1 GSM/GPRS BTS Features..................................................................................15 4.2 RF Features ........................................................................................................15

4.2.1 Frequency .......................................................................................................15 4.2.2 Output Power ..................................................................................................16 4.2.3 Power Control..................................................................................................16

4.3 Abis Support........................................................................................................16 4.4 IP Backhaul Features..........................................................................................16 4.5 S-Series System Capabilities..............................................................................17

5 System Planning and Deployment ..............................................................................18 5.1 Coverage and Capacity Planning........................................................................18

5.1.1 IP Backhaul Bandwidth Requirement..............................................................19 5.2 IP Backhaul Planning ..........................................................................................20

5.2.1 Last Mile Access .............................................................................................20 5.2.2 IP Backhaul Aggregation.................................................................................21 5.2.3 IP Backhaul End-to-End requirement..............................................................21

5.3 RF Planning ........................................................................................................21 5.4 RF Carrier Frequency Accuracy..........................................................................21 5.5 Emergency Call ...................................................................................................21

6 Security .......................................................................................................................23 6.1 Security Issues....................................................................................................23 6.2 Security Model ....................................................................................................23

6.2.1 Security Dimensions........................................................................................23 6.2.2 Security Threats ..............................................................................................23 6.2.3 Mapping of Dimensions and Threats...............................................................23

6.3 S-Series Security ................................................................................................24 6.3.1 Access Control ................................................................................................24

Figures 930-0006-02 Rev. A

iv CONFIDENTIAL AND PROPRIETARY RadioFrame Networks, Inc. FOR CUSTOMER AND END USER USE ONLY

6.3.2 Authentication and Authorization.....................................................................25 6.3.3 Non-Repudiation .............................................................................................25 6.3.4 Data Confidentiality .........................................................................................26 6.3.5 Communication Security .................................................................................26 6.3.6 Data Integrity ...................................................................................................26 6.3.7 Availability .......................................................................................................27 6.3.8 Privacy.............................................................................................................27

6.4 GSM Voice, Signalling and GPRS Security ........................................................27 6.4.1 Voice and GPRS Security ...............................................................................27 6.4.2 Signalling Security...........................................................................................29 6.4.3 RFN Internal Signalling Security .....................................................................30 6.4.4 RFN Network Management Security...............................................................30

6.5 Registration Server..............................................................................................31 6.5.1 S-RS Functional Components.........................................................................31 6.5.2 Schematic Overview........................................................................................31

7 Authentication and Registration ..................................................................................33 7.1 S-RS Start-up ......................................................................................................33 7.2 S-AGW Installation & Start-up.............................................................................34 7.3 S-BTS Installation & Start-up ..............................................................................34

8 Network Management .................................................................................................37 8.1 GSM System Management .................................................................................37

8.1.1 GSM Managed Object (MO) hierarchy............................................................38 8.2 RFN S-Series System Management ...................................................................38

8.2.1 Network Element Layer ...................................................................................39 8.2.2 Element Management Layer ...........................................................................39 8.2.3 NMS Functional Areas ....................................................................................40

8.3 Software Download / Software Upgrade .............................................................43 9 Fault Management ......................................................................................................44

9.1 GSM Fault Management .....................................................................................44 9.2 RFN S-Series Fault Management .......................................................................44

9.2.1 Component Hierarchy .....................................................................................44 9.2.2 Alarm Handling & Event Reporting..................................................................45

10 Software Maintenance ................................................................................................49 11 System Specifications .................................................................................................50

11.1 Power Requirements and Consumption..............................................................50 11.2 RF Specifications ................................................................................................51 11.3 Interfaces.............................................................................................................52 11.4 Dimensions..........................................................................................................52 11.5 Environmental .....................................................................................................52 11.6 Compliance .........................................................................................................53

Figures Figure 1 S-Series System High-Level Context ....................................................................7 Figure 2 GSM S-Series Three-Domain Architecture............................................................9 Figure 3 S-BTS Functional Block Diagram ........................................................................12 Figure 4 S-AGW Functional Block Diagram.......................................................................14 Figure 5 Case1 – 1 TRX from 1 S-BTS .............................................................................18 Figure 6 Case 2 – 2 BTS, Each with 1 TRX, Used in 2 S-BTS, Each with 1 S-1...............19 Figure 7 Secured GSM Abis Signalling Packets using SCTP and IPSec ..........................20

930-0006-02 Rev. A Tables

RadioFrame Networks, Inc. CONFIDENTIAL AND PROPRIETARY v FOR CUSTOMER AND END USER USE ONLY

Figure 8 Secured GSM Abis Voice/GPRS Packets using SRTP .......................................20 Figure 9 S-BTS Location Info Used to Track User during Emergency Call .......................22 Figure 10 Protocol Stacks used for GSM TRAU and GPRS PCU Frames........................28 Figure 11 Protocol Stacks Used for GSM Signalling Packets............................................29 Figure 12 Protocol Stacks Used for RFN Internal Signalling Packets ...............................30 Figure 13 Protocol Stacks Used for RFN Network Management Packets.........................31 Figure 14 Simplified S-Series Registration Process ..........................................................32 Figure 15 S-BTS Initialization Overview ............................................................................36 Figure 16 Network Management Delineation.....................................................................37 Figure 17 S-Series Deployment for Network Management ...............................................38 Figure 18 LME Components ..............................................................................................39

Tables Table 1 Transmit and Receive Frequency Ranges............................................................16 Table 2 Spacing for ARFCN Pairing ..................................................................................16 Table 3 Coverage, Capacity and Backhaul Requirement ..................................................19 Table 4 Security Threats to Security Measures Map .........................................................24 Table 5 Component Hierarchy ...........................................................................................44

References 930-0006-02 Rev. A

vi CONFIDENTIAL AND PROPRIETARY RadioFrame Networks, Inc. FOR CUSTOMER AND END USER USE ONLY

References [1] 3GPP TS 23.003: “Numbering, addressing and identification”. [2] 3GPP TS 23.008: “Organization of subscriber data”. [3] 3GPP TS 23.009: “Handover procedures”. [4] 3GPP TS 24.008: “Mobile radio interface Layer 3 specification; Core network protocols;

Stage 3”. [5] 3GPP TS 29.002: “Mobile Application Part (MAP) specification”. [6] 3GPP TS 44.060: “General Packet Radio Service (GPRS); Mobile Station (MS) - Base

Station System (BSS) interface; Radio Link Control / Medium Access Control (RLC/MAC) protocol”.

[7] 3GPP TS 48.008: “Mobile Switching Center - Base Station system (MSC-BSS) interface; Layer 3 specification”.

[8] 3GPP TS 48.018: “General Packet Radio Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS protocol (BSSGP)”.

[9] 930-0006-01, Rev A: “RadioFrame Networks Nokia S-Series 1.0 Product Description”.

930-0006-02 Rev. A Overview

RadioFrame Networks, Inc. CONFIDENTIAL AND PROPRIETARY 7 FOR CUSTOMER AND END USER USE ONLY

1 Overview 1.1 Introduction

The RadioFrame Networks (RFN) S-Series system is a modular pico-cellular radio solution that provides flexible and efficient software-driven base stations for Mobile Network Operators (MNO) that need to deploy cost-effective radio access in small, inexpensive increments.

Unlike traditional approaches from vendors offering proprietary, single-technology equipment, RadioFrame Networks offers an agile, multiple-technology, future-proof solution that integrates into the existing Radio Access Network (RAN) reducing capital expenditure.

The S-Series reduces operating costs associated with expensive, dedicated E1/T1 leased lines by making use of DSL and cable broadband packet switched networks for backhaul between the customer premises and the mobile operator network.

The S-Series components, shown in Figure 1, include the S-Series Base Transceiver Station (S-BTS), which provides coverage in the customer premises, and the S-Series Aggregation Gateway (S-AGW), which presents the Base Transceiver Station (BTS) Nokia Abis interface to the Base Station Controller (BSC) and Packet Control Unit (PCU) in the Base Station System (BSS). Support network elements are the S-Series Registration Server (S-RS) and the S-Series Element Management System (S-EMS).

Figure 1 S-Series System High-Level Context

Overview 930-0006-02 Rev. A

8 CONFIDENTIAL AND PROPRIETARY RadioFrame Networks, Inc. FOR CUSTOMER AND END USER USE ONLY

Each S-BTS is a complete pico cell base station, serving existing mobile-devices and numbers. The small form-factor S-BTS is the only customer-premise component. This means the S-Series system is quick, easy and inexpensive to install, without the complications of space acquisition, build-out and HVAC. Low power, silent operation and attractive styling make the S-Series BTS ideal for discreet placement indoors, where there is a need to supplement coverage or increase capacity.

Auto discovery of S-BTSs limits installation to one visit, simplifies network integration and commissioning and reduces the lag time for receiving cash flow. Most operations are remote, which reduces downtime and support call-out costs.

RFN support nodes ensure that authentication and management of the S-BTSs is highly reliable and that the S-Series system integrates seamlessly into the existing RAN.

This document provides the technical product description for a specific configuration of the S-Series product line: the single-board S1 for GSM/GPRS.

1.2 Applications The S-Series product is a RadioFrame Networks turnkey solution that provides pico-cellular coverage in small areas up to approximately 6,500 sq m. Each S1 supports capacity up to 7 traffic channels (1 GSM/GPRS TRX).

Small-to-Medium Enterprise (SME) – Nominal coverage per S-BTS is 6,360 sq m (70,000 sq ft) or 4,050 sq m (45,000 sq ft.) for the largest square building inside the circular coverage area.

Macro Network Coverage Fill – provide coverage fill in the macro network where macro network sites are not able to be deployed for coverage or planning reasons

Reduce Congestion in the Macro Network – off-load capacity from the macro network to remove congestion by deploying dedicated in-building systems to service increasing in-building coverage / capacity requirements

Remote Location Coverage – the S-Series lends itself to an application for network coverage fill in remote locations using cheaper DSL transmission for backhaul

Small Office / Home Office (SOHO) – SOHO services rank as a high opportunity given the exploding interest in lower-tariff calling enabled over DSL or cable

930-0006-02 Rev. A System Overview


2 System Overview 2.1 Architecture Description

This section provides a more complete description of the S-Series system architecture.

The RFN GSM S-Series is a pico-cellular radio system that is designed for installation in small and medium enterprises (SME), hotspot and homes. It provides cost effective cellular access radio service to subscribers by reducing the costs of Customer Premise Equipment (CPE) and backhaul.

The S-Series system is designed to co-exist as a group of logical GSM/GPRS BTSs within the MNO’s macro-cellular environment.

The S-Series architecture can be described as comprising three domains: the Mobile Network Operator Customer-Premise Domain, the Backhaul Domain and the Mobile Network Operator Infrastructure Domain. This architecture scheme is shown in Figure 2.

Figure 2 GSM S-Series Three-Domain Architecture

2.1.1 Mobile Network Operator Customer-Premise Domain The Mobile Network Operator Customer-Premise Domain consists of small form factor S-BTSs with a DSL or cable modem/router connection to the Backhaul Domain. Each S-BTS is connected to the DSL/cable modem/router via an RJ-45 CAT5 Ethernet cable.

Connection to the Backhaul Domain may alternatively be provided through a customer-premise LAN.

S-BTSs are distributed in the customer premises to optimize coverage.

The S-Series Transceiver (S1) is the basic component of capacity and coverage. Each S1 can be configured as a full BCCH TRX.

System Overview 930-0006-02 Rev. A


2.1.2 Backhaul Domain The Backhaul Domain provides secure transport between the S-BTSs in the Customer Premises Domain and the S-AGW in the Infrastructure Domain. Each S-BTS has a unique secure IP tunnel to the S-AGW. The Backhaul IP Domain must also include a local DHCP server and access to a DNS server.

The backhaul domain link must meet minimum performance requirements. See “System Planning and Deployment”, section 5.

2.1.3 Mobile Network Operator Infrastructure Domain The Mobile Network Operator Infrastructure Domain consists of a mobility network / data network that provides access to the Internet. RFN network elements, referred to as the S-Series Aggregation Gateway (S-AGW), S-Series Registration Server (S-RS) and S-Series Element Management System (S-EMS) are deployed here.

The S-AGW manages system resources and multiplexes/de-multiplexes user traffic to multiple RFN customer-premise S-BTSs. One S-BTS can be configured to be a logical 1-TRX BTS from the BSC’s point of view.

The S-RS provides a mechanism for authenticating each S-BTS as it joins the service-provider (SP) network (during system start-up) and initial key exchange for protection of subsequent signalling communications between the S-BTS and the S-AGW. In essence, the S-RS serves as a “gatekeeper” – ensuring that only authenticated S-BTS equipment may reach the S-AGW via its backhaul IP address.

The S-EMS is used to manage the operation of the S-Series AGW and S-BTS network elements. The S-EMS performs typical Element Manager Layer (EML) services as defined by the Telecommunications Management Network (TMN) model. The S-EMS provides management functions in addition to the GSM management provided by the MNO’s existing OMC across the Abis interface.

Note: The Transcoder Rate Adaptation Unit (TRAU) function is required, as it is for an existing GSM BTS.

2.2 System Deployment Scenarios The S-Series product provides a basic IP backhauled BTS platform that is configured to meet different deployment scenarios. The main focus of the S-Series product is for SME and home applications.

A general description of the defined deployment scenarios are presented below:

2.2.1 Small Medium Enterprise (SME) Deployment An S-Series product SME deployment scenario typically consists of one pico-cell S-BTS which has one or more S1s deployed within the enterprise where the S-BTS can be backhauled to the PLMN over a single or multiple last mile IP access connections. One or more S1s can be used to provide both capacity and coverage requirement which typically are bigger than home applications.

2.2.2 Home/SOHO Deployment The S-Series product Home deployment scenario typically consists of one pico-cell S-BTS which has one S1 deployed in individual customer homes where the S-BTS can be backhauled to the PLMN over a single last mile IP access connection. The system represents a consumer based deployment providing GSM/GPRS service to the home.

930-0006-02 Rev. A System Overview


2.3 Software Architecture The S-Series is designed around a common platform for all targets.

The Application Support Package (ASP) for application software includes the following functions:

• Memory and Flash File System Management for non-volatile storage • Inter-task and Inter-component communications • Fault Reporting • Alarm and Event Management • System Diagnostics

2.4 Overview of S-Series GSM Service The manner in which a GSM mobile subscriber accesses the S-Series system is the same as for typical GSM systems.

When a subscriber enters an S-BTS coverage area, the S-BTS is preferentially chosen based on its signal strength in relation to the signal strength from surrounding macro-cells. By appropriate setting of the GSM cell-selection parameters for both the S-Series cells and neighboring macro cells, preference can be given to the S-Series cells. If the newly chosen S-Series cell is in a new location area, then the MS will perform a location update through the S-BTS to the mobility network.

If a subscriber powers on a mobile station (MS) within the S-Series cell, then it will register on the mobile network via the serving S-BTS control channels.

Terminating calls to an MS within an S-Series cell are initiated by paging for the mobile within the location area that contains the S-Series cell.

Originating calls are initiated within an S-BTS coverage area using the radio control channels associated with the S-BTS.

Other GSM/GPRS services and features, if supported by the MNO, operate in the same way as for the surrounding GSM/GPRS network.

Functional Components 930-0006-02 Rev. A


3 Functional Components 3.1 S-Series Transceiver and S-Series Base Transceiver

Station (S-BTS) By deploying in-building S-BTSs at the customer site, the MNO can improve radio-resource performance inexpensively, without eroding expensive macro-cellular capacity.

The S-BTS consists of a single board. The board contains the 1-TRX GSM/GPRS/EDGE-ready transceiver section, an RF receiver for neighbor-cell monitoring, antennas, and the baseband sections, including DSP, Ethernet connectivity and a routing function. These functions are shown in Figure 3 and described in the paragraphs that follow.

The S-BTS terminates IP tunnels from the S-AGW QoS Tunnelling Appliance (QTA), acting as an L2TP Network Server (LNS) to provide virtual-network sessions between the S-BTS and the S-AGW. Each S-BTS interfaces with a DSL modem or cable modem via a 100baseT Ethernet WAN connection.

Power to the S-BTS is supplied from an AC mains adaptor.

Figure 3 S-BTS Functional Block Diagram

3.1.1 GSM/GPRS/EDGE This block is the GSM/GPRS/EDGE radio transceiver. While the radio in the S-BTS is EDGE-ready, EDGE functionality will not be available in the 1.0, ED1 release (EDGE is a planned release 2.0 feature). The GSM/GPRS/EDGE block performs the radio functions required in a base station—digitization and modulation / demodulation for the air interface—as well as baseband processing of transmitted and received signals. Layer 1 DSP is performed on each transceiver, as are adjacent-channel rejection and EMI rejection. Though not strictly part of the transceiver, the SIM-card reader is included in this block as it interfaces directly to the FPGA. The transceiver section is fitted with separate omni-directional antennas, one for transmit and one for receive, connected via Sub-miniature Version A (SMA) connectors.

930-0006-02 Rev. A Functional Components


3.1.2 RF Monitor The RF monitor functional block, also known as S-BTS Scan Receiver, is a GSM receiver capable of receiving in the 900/1800 and 850/1900 bands. The purpose of this block is to monitor the radio environment and look for carriers from the macro network as well as carriers from other nearby S-BTS entities. Frequency and RSSI information is passed to the Host CPU block where the information is used for frequency planning and other system-management functions. The Scan Receiver functionality is available in Release 1.0, ED1.

3.1.3 Host CPU This block performs a variety of control and processing functions necessary for operation of the S-BTS. The router, GSM transceiver and RF monitoring sections interface to the host CPU.

3.1.4 Baseband Functions, Router and Ethernet PHY The baseband function of the S-BTS forms the link between the radio physical layer and the Ethernet physical layer.

The baseband function formats and decodes the bursts for radio communication and communicates TRAU frames and PCU frames to the S-AGW.

The baseband section contains a layer-2 Ethernet switch and an additional RJ-45 port for the WAN connection. It terminates IP tunnels from the S-AGW QoS Tunnelling Appliance (QTA), acting as an L2TP Network Server (LNS) to provide virtual-network sessions between the S-BTS and the S-AGW. The internal router makes it possible to prioritize S1 traffic over LAN traffic to meet the QoS requirement for voice.

The following BTS processing functions are carried out in the baseband section:

• LAPDm link management • BCCH (System info) buffering, segmentation • Paging subgroup management • Measurement reporting for Handover, Power Control, Time Alignment • Random Access procedure • Handover access detection • Filtering and routing of Abis layer-3 messages (RSL, OML, L2ML) • Processing of the non-transparent messages

The S-BTS also performs start-up provisioning, compression / decompression and ciphering.

3.2 S-Series Aggregation Gateway (S-AGW) The S-Series Aggregation Gateway (S-AGW) mirrors the assignment of resources by the BSC / PCU and manages distribution of the radio-link resources to the S-BTSs. It terminates the Nokia Abis interface. On the IP backhaul side, the S-AGW aggregates and disaggregates the voice, data and signalling, providing the functions necessary for management of all TCHs and PDCHs. Figure 1 shows the role of the S-AGW vis a vis the S-BTSs and the rest of the BSS.

As can be seen in Figure 4, the S-AGW consists of two physical units, the Base Chassis Unit (BCU) and the Quality of Service (QoS) Tunnelling Appliance (QTA). These S-AGW components, described in the following paragraphs, reside in a standard 19” rack occupying a rack space 5U in height.

Functional Components 930-0006-02 Rev. A


Figure 4 S-AGW Functional Block Diagram

BTS InterfaceSwitch

GSM / GPRS RSS Control

Interface AbisTunnelling

Appliance

DLC

BCUQTA

3.2.1 Base Chassis Unit (BCU) The Base Chassis Unit (BCU) is a 19” rack mount unit that carries out all the radio management under control of the BSC. This includes terminating the TDM-based Abis interface, dynamic channel allocation procedures for control and traffic channels, Layer 2 and Layer 3 processing, system timing and transceiver frequency control and element management.

3.2.2 Quality of Service (QoS) Tunnelling Appliance (QTA) The Quality of Service (QoS) Tunnelling Appliance (QTA) is a Linux 1U rack-mount server that operates as an L2TP Access Concentrator (LAC). The QTA sets up and tears down secure tunnels for each TRX to maintain the connection with the MS during the voice call or data session.

3.3 S-Series Registration Server (S-RS) The S-Series Registration Server (S-RS) provides a secure method for registering an S-BTS into an MNO’s network. Upon startup, the S-BTS contacts the S-RS, and after authenticating the S-BTS, the S-RS creates and distributes the session keys for data and signalling communication between the S-BTS and S-RS. The S-RS fulfils the following functions:

• The means for validating the authenticity of each S-BTS participating in the network.

• The conjugate validation by which each S-BTS can be sure it is connecting to an authentic S-RS operated by the carrier to which it belongs.

• A gateway by which S-BTS entities initially contact the operator network. This initial contact is performed using a “fully qualified domain name” (FQDN) – the standard directory mechanism used in IP networks.

• A central point of coordination by which S-BTS entities are assigned to a specific S-AGW, based upon its “place” in the GSM network.

• A key distribution mechanism to share session keys between the S-BTS and S-AGW.

3.4 S-Series Element Management Server (S-EMS) S-Series system management is largely performed by the MNO’s existing OMC across the Abis interface. The S-Series Element Management Server (S-EMS) provides additional management functions of the S-AGW, S-RS, and S-BTS network elements. The S-EMS performs typical Element Manager Layer (EML) services as defined by the Telecommunications Management Network (TMN) model.

930-0006-02 Rev. A Release 1.0, ED1 System Features


4 Release 1.0, ED1 System Features This section describes the features of the RFN S-Series.

4.1 GSM/GPRS BTS Features • GSM – 900/1800/850/1900 up to 6 sectors, 1 TRX per sector • DTX Uplink • FR/EFR calls – MS to MS, MS to PSTN & PSTN to MS • SDCCH4 and SDCCH8 configurations • Encryption A5/1 • Dynamic MS Power Control • Call Features – Call Forwarding, Call Waiting etc. when supported by

provider • GPRS (CS-1 & CS-2) • SMS • BSS S11.5 / S12 compatible • Logical channels supported • BCCH (FCCH + SCH + BCCH + PCH + AGCH) • Extended BCCH • Combined BCCH and SDCCH • TCH (TCH+FACCH+SACCH) • RACH • BS and MS Power Control • Dynamic Add and Delete of TRXs • Dynamic modification of TRX/BTS data fields after locking the TRX/BTS

from the BSC3 • Asynchronous Handover / IS Handover • Dynamic SDCCH • FACCH signaling • 16 / 32 / 64 kbps Signaling • Enhanced Alarm reporting to the BSC for various fault conditions in the BTS • SCTP/SRTP links with IPSec • CSD (9.6 kbps) • Router functionality

4.2 RF Features 4.2.1 Frequency

The S-BTS employs dual-band transceivers, which for the European (ETSI) market includes GSM900 (GSM) and GSM1800 (PCS) and for the North American (NA) market includes GSM850 and GSM1900. Table 1 provides a breakdown of the frequency ranges covered. Table 2 provides the channel and duplex spacing for Absolute Radio Frequency Channel Number (ARFCN) pairings.

Release 1.0, ED1 System Features 930-0006-02 Rev. A


Table 1 Transmit and Receive Frequency Ranges Band Receive Frequency (MHz) Transmit Frequency (MHz)

850 (ANSI) 824 to 849 869 to 894

900 (ETSI) 890 to 915 880 to 915 (E-GSM)

935 to 960, 925 to 960 (E-GSM)

1800 (ETSI) 1710 to 1785 1805 to 1880

1900 (ANSI) 1850 to 1910 1930 to 1990

Table 2 Spacing for ARFCN Pairing

Band Channel Spacing (kHz) No. of channels Duplex Spacing

(MHz) 850 (ANSI) 200 124 45

900 (ETSI) 200 124 174 (E-GSM)

45

1800 (ETSI) 200 374 95

1900 (ANSI) 200 299 80

4.2.2 Output Power The GSM S-BTS is configured for an output power of +20dBm delivering a coverage distance up to 45 m (150 ft), equivalent to a coverage area of up to 6,360 sq m (70,000 sq ft) or 4,050 sq m (45,000 sq ft.) for the largest square building inside the circular coverage area1.

4.2.3 Power Control Transmit power control is statically provisioned in 2 dB ± 1 dB steps according to GSM 05.05, sub clause 4.1.2.

4.3 Abis Support The RadioFrame S-Series inter-works with the Nokia BSC over the proprietary Abis Interface. This eliminates the need for additional BSC network nodes and vendors and enables the existing Network Management Systems (NMS) and Operation Support Systems (OSS) to be used for all GSM/GPRS O&M activities.

4.4 IP Backhaul Features Low-cost WAN access – DSL, cable, WiMax, Ethernet WAN

SRTP – Secure GSM voice and GPRS packet integrity and authentication using Secure Real-Time Protocol (SRTP)

SCTP/IPSec – Secure GSM/GPRS signalling, system management and control using IPSec for message authentication and integrity

Smart Cards – Isolate storage for all MNO-specific provisioning information and provide the MNO defined private key for S-BTS authentication key exactly as is done with GSM mobile phones

Auto Discovery – S-BTS sites are registered with the network using a plug-n-play auto discovery procedure (once the FQDN/IP address of the S-RS are known to the S-BTS).

1 Coverage will vary depending on operating band, configured output power, and deployment location. Figures shown here are estimates only, based on a popular in-building path loss model using an operating band of 1800MHz and an output power of +20dBm.

930-0006-02 Rev. A Release 1.0, ED1 System Features


4.5 S-Series System Capabilities As stated in the System Overview section, the RFN designed and supplied S-Series entities are the S-AGW, S-BTS, S-EMS, and S-RS.

The scalability of these S-Series entities is outlined as follows:

• Each S-BTS shall support a full TRX capacity and it can be configured as a BCCH TRX.

• One S-BTS can be used to form a logical 1-TRX BTS at an installation. Therefore, each S-BTS shall support up to 7 simultaneous EFR voice calls, depending on how many slots are used for GPRS.

• Each S-AGW shall have the capability of supporting up to 40 TRXs. Assume each TRX needs about 200kbps at the IP backhaul; the total bandwidth required at the S-AGW-Internet link is about 8Mbps.

• The number of S-AGWs required for each BSC is dependant upon the capability of the serving MNO infrastructure. If the Serving BSC can support 1000 TRXs (100 E1s/T1s), then there are up to 7 S-AGWs needed to support a single BSC.

• Total number of TRXs a BSC supports For each mobile switching office (MSO) (where all serving BSCs are co-located), 1 S-RS and 1 S-EMS are required. Each S-RS and S-EMS can support up to 100 S-AGWs in an MSO and all S-BTSs associated with these S-AGWs. S-RS and S-EMS are designed as independently executable software entities that can logically serve up to 100 fully provisioned S-AGWs.

• The number of E1s/T1s required for the S-AGW-BSC interface varies according to the chosen system configuration. Each S-AGW supports up to 4 E1s/T1s at the S-AGW-BSC Interface.

• The bandwidth required for a fully loaded S-AGW at the S-AGW – IP backhaul interface is about 200kbps (per TRX) * 40 = 8Mbps.

Section 5, “System Planning and Deployment”, provides more information on deployment strategies.

System Planning and Deployment 930-0006-02 Rev. A


5 System Planning and Deployment Traditionally, BSCs have been dimensioned to support a mobile network architecture based on the deployment of macro and micro cells. The introduction of pico cells into the mobile network has raised some new challenges to this model.

In addition to the challenges raised by the deployment of pico cells, the fact that the S-BTS is remotely located in the customer’s premises and backhauled through narrow band and possibly public IP networks, has also raised challenges as far as network planning and field deployment.

The following sections will discuss the challenges and focus on some of the features available in these areas.

5.1 Coverage and Capacity Planning The S-Series design is flexible enough to support different deployment cases as summarized in the following figures and tables.

Case 1 – 1 S-BTS with 1 full TRX is used at a home or small SME.

Figure 5 Case1 – 1 TRX from 1 S-BTS

Case 2 – 2 BTS, each with 1 full TRX is used at SME needing more coverage area and capacity.

930-0006-02 Rev. A System Planning and Deployment


Figure 6 Case 2 – 2 BTS, Each with 1 TRX, Used in 2 S-BTS, Each with 1 S-1

5.1.1 IP Backhaul Bandwidth Requirement Table 3 shows some of the possible deployment scenarios and their backhaul requirement with the following assumptions:

• Cell size: Approximately 45m (150ft) radius • Grade of Service: 2% • Erlangs per subscriber: 0.05 • Traffic type: FR, EFR Voice and GPRS CS-1 and CS-2 • Overhead: For voice, SRTP/UDP/IP; For signalling, SCTP/IPSec

The RFN layer-2 header is also included, and it is assumed that voice packets for the whole TRX are bundled as one IP packet.

Table 3 Coverage, Capacity and Backhaul Requirement

Scenarios # of TCH TS

# of S-1

Coverage (sq. ft.)

Coverage (sq. m)

Capacity (# of

users)

Calls at

Same Time

BKHL BW

(kbps)

Suggested DSL BW (kbps)

Case 1 7 1 30000 6500 50 7 182/182 256/256 Case 2 14 2 60000 13000 162 14 364/364 512/512

Figure 7 and Figure 8 show the calculation of backhaul bandwidth used in Table 3.



Figure 7 Secured GSM Abis Signalling Packets using SCTP and IPSec

Figure 8 Secured GSM Abis Voice/GPRS Packets using SRTP

For a TRX, which has the BCCH, there are up to 7 simultaneous calls and the BW required is 143 + 39 = 182 kbps. For 2 TRX, there are up to 15 simultaneous calls and the BW required is 143 + 39 + 143 + 39 = 364 kbps.

5.2 IP Backhaul Planning There are two segments in the IP backhaul – the first segment is from the customer premises to the CO through DSL, Cable Modem or other IP-based last mile access technologies, and the second segment is from the CO through a private or public IP network to the S-AGW. The S-AGW is then connected to the BSC over the circuit-switched Abis interface via TDM E1/T1.

The MNO is responsible for providing the last mile access (e.g., DSL or cable modem access) and the IP backhaul facilities used to support the S-Series. This section provides functional requirements for the S-BTS and a set of guidelines and recommendations that should be followed to enable the intended operational characteristics of the S-Series system.

5.2.1 Last Mile Access This segment is from the customer premise to the CO of the last mile access provider.

• The S-BTS is connected to the DSL/Cable modem directly or through a router and is powered by an AC/DC adaptor.

• The S-BTS supports static or dynamic assigned private or public IP addresses.

930-0006-02 Rev. A System Planning and Deployment


• At power up, the S-BTS finds the serving S-AGW through DNS lookup and registers its IP address through the secured registration procedure.

5.2.2 IP Backhaul Aggregation This segment is from the CO through the public or private packet data network (PDN) to the S-AGW. The S-Series has been designed to operate through a public IP network (like the Internet) during the time when minimum delay and jitter requirements are met. The S-Series can also be deployed using a private IP network as a backhaul. Using a private network with a desired SLA as backhaul can ensure higher levels of QoS than using the public Internet.

5.2.3 IP Backhaul End-to-End requirement The S-Series is designed to operate in an environment characterized by the following parameters values. These parameters values are specified for the IP backhaul connection between the S-BTS and the S-AGW, i.e. including the access segment:

• Maximum round-trip delay: 80 ms • Maximum jitter: 60 ms • Maximum packet drop rate: < 1% • Minimum BW: see Table 3

5.3 RF Planning RF planning techniques currently in use in the mobile network for in-building deployments may be employed for the S-BTS without any additional requirement from the S-BTS.

5.4 RF Carrier Frequency Accuracy Control of the TDMA frame counter and the frequency reference are handled by the S-AGW through a proprietary RadioFrame packet-timing mechanism. Frequency accuracy of 10-7 (0.1 ppm) is achieved, in line with the GSM pico class BTS frequency accuracy requirement.

5.5 Emergency Call The S-BTS is compliant with mechanisms currently in use by the MNO to identify the location of a user making an emergency call.

As shown in Figure 9, during S-BTS activation, the user’s address (SOHO or SME) where the S-BTS will be located is registered to the MNO, e.g. through help-desk or either web access. The user address is translated into S-BTS geographic coordinates and stored in the Location DB at the Serving Mobile Location Centre (SMLC).

As the S-BTS covers a significantly smaller coverage area (as noted in Section 4.2) in comparison to a micro or macro cell, a user making an emergency call can be determined to be within the 45m radius of the serving S-BTS location.



Figure 9 S-BTS Location Info Used to Track User during Emergency Call

It is the customer’s responsibility to make sure the S-BTS is not moved without the new location of the S-BTS being registered.

930-0006-02 Rev. A Security


6 Security 6.1 Security Issues

The S-Series provides GSM-level security over the air interface as mentioned in section 4.1. Additional security measures are required due to the following:

• Typical BTS sites have restricted physical access. The degree of restrictiveness for the S-Series site may not be all that high.

• Typical BTS sites have dedicated communication links between the BTS site and the Mobile Switching Office (MSO). In the case of the S-Series, this connection may be over DSL/Cable and IP, even public Internet in some cases.

This section concentrates on the S-Series security measures that deal with these issues.

6.2 Security Model The S-Series security model is based on security dimensions and threats outlined in ITU-T recommendation X.805. This offers a framework for comprehending the security requirements for different S-Series deployment scenarios.

6.2.1 Security Dimensions According to X.805, a security dimension is a set of security measures designed to address a particular aspect of the network security. The following security dimensions are outlined in X.805.

• Access control • Authentication • Non-Repudiation • Data Confidentiality • Communication Security • Data Integrity • Availability • Privacy

6.2.2 Security Threats The following security threats are identified in X.805.

• Destruction of information and/or other resources • Corruption or modification of information • Theft, removal or loss of information and/or other resources • Disclosure of information • Interruption of services

6.2.3 Mapping of Dimensions and Threats Security dimensions are applied in the network for counteracting the threats. Table 4, adapted from X.805, illustrates the mapping between the dimensions and the threats. A ‘Y’ in a column indicates that application of the particular security dimension can counteract the particular threat and mitigate the impact of an attack based on that threat. For example, the application of the privacy dimension can protect against the disclosure of information threat. However, it does not provide protection for the other

Security 930-0006-02 Rev. A


threats. Conversely, if corruption or modification of information is a major threat then the security dimensions to concentrate on are access control, non-repudiation, and data integrity.

Table 4 Security Threats to Security Measures Map

Threats

Measures

Destruction of

Information and Other Resources

Corruption or Modification

of Information

Theft, Removal, or Loss of

Information & Other Resources

Disclosure of Information

Interruption of Services

Access Control Y Y Y Y –

Authentication – – Y Y –

Non-Repudiation Y Y Y Y Y

Data Confidentiality – – Y Y –

Communication Security – – Y Y –

Data Integrity Y Y – – –

Availability Y – – – Y

Privacy – – – Y –

6.3 S-Series Security The nature and degree of threats faced by the S-Series are deployment-situation specific. This section gives a high level overview of the security dimensions provided by the S-Series. Further details are present in subsequent S-Series documents.

6.3.1 Access Control The access control security dimension protects against unauthorized use of network resources. In the case of the S-Series, the objective is to ensure that only MNO personnel, or non-MNO persons authorized by the MNO (such as the S-BTS owner), can access the S-Series system. The S-Series provides this security in the following ways.

• Physical Access Control – Since the front end of the S-Series is installed at the customer premises, device theft is a real threat. The S-Series uses a smart card to counteract this threat. As with GSM mobile phones, the device can be disabled (if stolen) by blacklisting its identification number. Since this is not a mobile phone, the Ethernet MAC address of the S-BTS backplane is used as its identification number. Forging this number is of no benefit, as the number by itself does not grant access to the core network and its services. Only when the S-BTS identification number is presented in conjunction with the presence (and cryptographically secure authentication protocol) of the smart card is it possible for the S-BTS to function. At the core network side, all physical entities (e.g., S-RS, S-AGW, etc.) are kept physically secure by the operator. Consequently, conventional account/password access control is deemed sufficient.

• Management Access Control – The management of the S-Series is provided by the RFN EMS. The feature of access control is built into the EMS. By default, user access control is implemented with traditional operating system account/password authentication methods.



6.3.2 Authentication and Authorization The authentication security dimension serves to confirm the identities of communicating entities. In case of the S-Series, the objective is to ensure that only authentic and authorized RFN devices may interconnect across the backhaul network, with the operator under control of determining authenticity and authorization at all times.

Note: It is assumed that the operator maintains adequate physical security over the S-RS and S-AGW components, so that authentication and authorization among these components is unnecessary. At the customer’s request, additional security mechanisms may be incorporated into the S-Series product to meet such needs, should they be present. It should also be noted that the S-RS and S-AGW elements require a secure communications channel by which they interact. In a secure physical setting, this can be by simple interconnection of the elements via a private Ethernet LAN. In the event that these elements are not collocated, it may be necessary to implement a secure network among these units. This could be done with a private wide area network, as well as with Internet-based Virtual Private Networking (VPN). It would be possible within the MNO Infrastructure Domain for the customer to add IPsec based VPN capabilities for this purpose.

An application-layer-based protocol, tailored to the unique requirements for the S-Series product, is used for mutual authentication. The S-BTS and S-RS use the privacy afforded by the network layer to facilitate the exchange of authentication data in both directions.

In this authentication method, the S-RS uses a challenge/response protocol to validate the identity of the S-BTS. The same protocol is then used in the reverse direction so that the S-BTS may validate the identity of the S-RS. Once the two entities satisfy the mutual authentication tests, the S-RS uses this session to provide the IP address of the S-AGW with which the S-BTS subsequently associates, as well as providing key material to the S-BTS for use in these communications with the S-AGW . The S-RS also provides this key material and the IP address of the S-BTS to the S-AGW with which it is paired via a separate communications channel (see section 6.5.2 for a description of this communications channel).

The S-BTS uses a smart card to store secret information needed to establish the identity of the S-BTS, as well as for the S-BTS to establish the identity of any S-RS with which it registers. An identical copy of this secret information is stored with the S-RS. The mechanism used for identity verification is analogous to that used by GSM for mobile user authentication. However the implementation of this method does not involve interaction with any existing GSM authentication devices; while analogous, the S-Series authentication system is implemented completely separate from the operator’s GSM equipment and practices.

The S-BTS and S-AGW exchange signalling traffic using the authentication function of IPsec. There is no specific need for authentication at the transport layer between these entities; IPsec suffices for this purpose.

Likewise, the S-BTS and S-AGW exchange bearer traffic using Secure RTP, which is a transport-layer security method. S-RTP verifies the authenticity of all traffic it carries.

6.3.3 Non-Repudiation The non-repudiation security dimension provides means for preventing an individual or entity from denying having performed a particular action related to data by making available proof of various network-related actions. S-Series provides this security via the S-EMS.



6.3.4 Data Confidentiality The data confidentiality security dimension protects data from unauthorized disclosure. In case of the S-Series, its objective is to ensure that only the S-AGW and S-BTS can understand data content. S-Series provides this security in the following ways.

Communications between the S-BTS and the S-RS are encrypted with a application-layer mechanism (based on AES and an official “mode” recommended by NIST). Since all sensitive information is encrypted at the application layer, encryption specifically at the network layer is not needed.

The S-BTS and S-AGW encrypt all signalling traffic with IPsec using ESP.

The S-BTS and S-AGW encrypt all bearer traffic with Secure RTP. Because all bearer traffic must be delivered using SRTP, there is no specific need for a network-layer-based bearer traffic encryption.

Once mutual-authentication is complete and the one of the entities participating in communications across the IP backhaul network employ application-layer encryption, as all such exchanges are adequately protected at the network or transport layers.

6.3.5 Communication Security The communication security dimension ensures that information flows only between the authorized end points. In the case of the S-Series, its objective is to ensure that the information is not diverted or intercepted as it flows between the S-AGW and the S-BTS.

Because the S-Series deployment model includes an IP-backhaul network, and this network may be exposed to third parties, it is imperative that all communications be secured against eavesdropping or alteration while in transit. Public networks (e.g., the Internet) are difficult or impossible to fully protect from diversion or interception, as the traffic may pass through many spans and nodes, which are outside the control of the S-Series system or its owner/operator.

However, it is also true that proper use of strong encryption renders both diversion and interception useless to anyone who would attempt to compromise the system’s security. The S-Series design uses industry-accepted and trusted encryption and security protocols to ensure that all communications between its endpoints that use the IP backhaul network are safe from eavesdropping and malicious modification.

As described in the previous section, all of the benefits of industry-trusted encryption and security protocols accrue to protection at the transport layer as well. More specifically, SRTP is in fact a transport-layer protocol. and IPsec adequately protects signalling traffic between the S-BTS and S-AGW such that no specific protection is needed at the transport layer.

6.3.6 Data Integrity The data integrity security dimension ensures the correctness or accuracy of data. In the case of the S-Series, its objective is to protect data from modifications as it moves between the S-AGW and S-BTS and provide an indication in case modification does take place.

The S-BTS to S-RS mutual authentication protocol uses application-layer encryption that includes message integrity protection (i.e., the CCM mode of AES). Messages that are part of this protocol are transported using UDP; the protocol is protected from message loss, duplication, replay and forged messages via CCM-based message authentication and unique per-message serial-number identification.



The S-BTS and S-AGW exchange signalling traffic using IPsec with ESP. In addition, a hash-based Message Authentication Code (H-MAC) is used to ensure that the payload of all IP datagrams has not been corrupted or tampered with during transmission.

The S-BTS and S-AGW exchange bearer traffic using Secure RTP. RTP (and consequently SRTP) includes sequencing information in packet headers that permits detection and handling of lost, duplicate or out-of-sequence delivery. However, due to the real time nature of the payload carried by SRTP, it is not possible to ensure reliable delivery of each and every unit of data. SRTP does ensure that data that is delivered will not be out of sequence or if “late”, is dropped silently.

6.3.7 Availability The availability security dimension ensures that there is no denial of authorized access to network elements. Because the connection between the S-AGW and S-BTS may have to go over a public network, such as the Internet, protection against attacks such as Denial of Service (DoS) is an important consideration. S-Series provides availability security via its fault-tolerance features, by IP address protection and by the mutual authentication algorithm.

The only IP address exposed to public networks in the clear is that of the S-RS. This is the primary reason the S-RS is deployed as its own node: The IP address of the serving S-AGW is only passed to the S-BTS after successful authentication and through a secure connection. Because the S-RS IP address can be known, there are measures taken to foil DoS attacks against the S-RS. The S-RS immediately drops and does not respond to all attempts to contact it that do not contain “self-authenticating” code generated by an S-RS. “Man-in-the-middle” replay attacks fail do to message serialization, similar to that used in UMTS. The S-RS also has an intentionally light work load to further ensure that it does not present a bottleneck. Its primary task is to establish secure communication; once communication between the S-BTS and S-AGW is set up, the S-RS is no longer involved.

6.3.8 Privacy The privacy security dimension provides for the protection of information that might be derived from the observation of network activities.

Given that the S-Series may use a public IP backhaul network (e.g., the Internet), privacy is a more sensitive matter than for a traditional GSM BTS. Consequently, the S-Series product is implemented with substantial privacy enhancing technologies (IPsec, AES, SRTP) to ensure that interception of IP backhaul traffic cannot compromise subscribers’ privacy.

6.4 GSM Voice, Signalling and GPRS Security 6.4.1 Voice and GPRS Security

GSM TRAU frames and GPRS PCU frames are protected for privacy. All the packets belonging to the same TRX are bundled together to reduce the overhead. Here is the summary of the security measures for the voice and GPRS frames:

• RFN proprietary message headers are used to enhance the data integrity. • S-AGW converts between IP tunnelling traffic and E1/T1 Abis traffic and filters

out the invalid packets without sending them to BSC. • Secure RTP (SRTP) is used for providing confidentiality and integrity.



• GSM TRAU frames and GPRS PCU frames (whole TRX) together with the RFN headers are encrypted with 128-bit AES encryption.

• HMAC-SHA1 is used for authentication of each voice and GPRS IP packet. Figure 10 shows the protocol stacks used for voice and data packets.

Figure 10 Protocol Stacks used for GSM TRAU and GPRS PCU Frames

S-BTS IWF S-AGW IWF

RF and L1

HMAC-SHA1UDP

Ethernet

UDP

IP

EthernetT1/E1

MS S-BTS S-AGW TRAU/PCU

T1/E1

HMAC-SHA1

TRAU/PCU Frames

RTP

RF and L1

GSM Voiceor

GPRS data

128bit AES

RTP

IP

TRAU’/PCU’ frames

128bit AES

TRAU’/PCU’ Frames

TRAU/PCU Frames

GSM Voice/GPRS Data

IP Backhaul



6.4.2 Signalling Security GSM signalling packets are protected for privacy and reliable delivery. Here is the summary of the security measures for the signalling packets:

• RFN proprietary BTSM’ enhances the data integrity. • S-AGW converts between IP tunnelling traffic and E1/T1 Abis traffic and filters

out the invalid packets without sending them to BSC. • SCTP, which is resistant to flooding attacks and reduces the risk of blind

masquerade attacks, is used as the transport layer. • IPSec ESP (RFC 2406) in transport mode is used for providing confidentiality

and integrity. • The BTSM’ signalling message together with the SCTP header are encrypted

with 128-bit AES encryption. • The HMAC-SHA1 is used for authentication of each signalling IP packet.

Figure 11 shows the protocol stacks used for GSM signalling packets.

Figure 11 Protocol Stacks Used for GSM Signalling Packets



6.4.3 RFN Internal Signalling Security RFN Internal signalling packets are protected for confidentiality and reliable delivery. Here is the summary of the security measures for the RFN internal signalling packets:

• SCTP, which is resistant to flooding attacks and reduces the risk of blind masquerade attacks, is used as the transport layer.

• IPSec ESP (RFC 2406) in transport mode is used for providing confidentiality and integrity.

• The RFN internal signalling message together with the SCTP header are encrypted with 128-bit AES encryption.

• The HMAC-SHA1 is used for authentication of each signalling IP packet. Figure 12 shows the protocol stacks used for internal signalling packets.

Figure 12 Protocol Stacks Used for RFN Internal Signalling Packets

6.4.4 RFN Network Management Security RFN network management packets are protected for confidentiality and integrity. Here is the summary of the security measures for the NM packets:

• IPSec ESP (RFC 2406) in transport mode is used for providing confidentiality and integrity.

• The RFN network management messages are encrypted with 128-bit AES encryption.

• The HMAC-SHA1 is used for authentication of each signalling IP packet. Figure 13 shows the protocol stacks used for RFN NM packets.



Figure 13 Protocol Stacks Used for RFN Network Management Packets

UDP

IP

Ethernet

S-BTS S-AGW

UDP

IP

Ethernet

TCP

IP

HTTP

Ethernet

IP Backhaul

SNMP

SNMPAgent

SNMP

System Manager & Agent

128-bit AES 128-bit AES

HMAC-SHA1

HMAC-SHA1

6.5 Registration Server Section 3.3 presents an overview of the functions of the S-Series Registration Server (S-RS). The means by which these functions are fulfilled is outlined below.

6.5.1 S-RS Functional Components The S-RS may be thought of as a set of functional components, which may, or may not, be implemented as separate physical components. This section describes each component based on the function it performs.

In order to describe the functional components of the S-RS, it is first necessary to introduce a security component of the S-BTS—the S-BTS Equipment Identity Module (EIM). The EIM is physically implemented as a smart card with a form factor identical to the GSM SIM card, but whose internals differ somewhat in implementation. Though differing in implementation, the EIM serves a similar purpose to the SIM, except that it identifies the S-BTS equipment and not a subscriber.

The major components of the S-RS include:

S-BTS Identity Register – The S-BIR identifies a specific S-BTS by a unique hardware identification number. To identify a particular S-BTS, the Ethernet MAC address of the S-BTS backplane is used. The S-BIR contains a list of all S-BTS units, which exist in the operator’s S-Series network.

S-BTS Equipment Identity Register – The S-EIR identifies a specific EIM by the EIM’s unique serial number. Along with the EIM serial number, its current status is recorded (e.g., un-issued, issued and operational, issued and revoked, etc.). The S-EIR also includes an encrypted copy of the private key also stored in the EIM (smart card), which is used for S-BTS ↔ S-RS mutual authentication.

Cryptographic Random Number Generator – This random number generator produces high quality numbers for use in key generation.

6.5.2 Schematic Overview Figure 14 depicts an S-Series system with one of each S-Series entity. This is done for simplicity; actual networks will most likely contain multiples of each entity type.



Figure 14 Simplified S-Series Registration Process Notes: 1 S-BTS / DSL modem allocated IP address by DHCP server upon power up. 2 S-BTS gets S-RS function IP address from DNS. 3 S-BTS establishes secure session with S-RS. 4 S-BTS registers with S-RS; S-BTS and S-RS authenticate each other; S-RS delivers serving S-AGW’s IP address and Security session keys to S-BTS; S-RS delivers S-BTS information to serving S-AGW; then secure session ends. 5 S-BTS and S-AGW establish security links to pass signalling and traffic.

Note: The S-BTS communicates with both the S-RS and the S-AGW via the IP-backhaul network. As depicted here, however, the S-RS and the S-AGW communicate via a private communications channel. This channel is also an IP network, but as depicted, does not traverse the IP-backhaul network. It is therefore assumed that the IP network interconnecting the S-RS and the S-AGW is private (i.e., protected from eavesdropping).

930-0006-02 Rev. A Authentication and Registration


7 Authentication and Registration The S-Series architecture separates S-BTS authentication from steady-state operation by the use of two different network elements – one for each function. The S-RS (Registration Server) performs the authentication process when an S-BTS presents itself to the network. The S-AGW performs all steady-state operational functions needed to support the interconnection of the S-BTS with the rest of the carrier’s system.

The registration process is physically separated from steady-state operation in order to enhance system security and robustness. This is mostly needed for the case where an operator chooses to use the public Internet for IP backhaul. Having the S-BTS and the S-AGW on the public Internet mandates the use of strong privacy, authentication, and resistance to service disruption by acts of malice. Separation of registration from steady-state operation enhances the overall robustness and cost effectiveness of the S-Series system in ways explained below.

1 The S-RS needs to be accessible and visible to potentially any host on the Internet, as the operator has no way to know, a-priori, what IP addresses will be assigned to the S-BTS units in the field. The S-AGW, however, need only accept traffic from authentic S-BTS units – all other traffic into the S-AGW may be discarded. This greatly reduces the vulnerability of the S-AGW to malicious attacks, as well as undesired “probing” and other activities. To all but authentic S-BTS units, the S-AGW is essentially non-existent.

2 The S-RS performs administrative duties unrelated to the real-time tasks performed by the S-AGW. By dividing these functions, overall system stability is improved. The S-RS can be optimized for its administrative duties, and likewise the S-AGW can focus on its time-critical functions.

3 Registration services and aggregation gateway services may scale at different rates. One or two S-RS units may suffice to serve a large S-Series deployment that may require dozens of S-AGW units. By separating the functions, each may grow as needed without (necessarily) being encumbered by the cost of growing the other.

4 In the unfortunate event of a successful attack on either type of server, other servers and functions are isolated from the damage done. For instance, having two S-RS units in a network provides redundancy; if one is compromised, the other will continue to service registration requests in the interim until the compromised server is restored.

The S-BTS Equipment Identity Module (EIM) stores all information needed to identify and provision the S-BTS. This EIM card is provided by the operator, and is formatted according to RFN specifications. By default, the EIM card will use the A3/A8 sample algorithms provided by the 3GPP, as documented in Reference [9]. An operator may select a different algorithm, and in collaboration with RFN, arrange for this algorithm to be implemented in the S-RS in place of the default algorithm.

7.1 S-RS Start-up The S-RS would normally be the first component to start up in the system of its sub-tending S-AGW(s) and S-BTSs. The S-RS has an internal secure database that contains the authentication keys for authenticating the other system components. Upon S-RS start-up, a secure IP connection to the S-EMS is established (either using a VPN and/or separate private network connection). The S-RS secure network connection to the S-EMS is used to authenticate the S-EMS and establish its

Authentication and Registration 930-0006-02 Rev. A


configuration. After authentication and configuration, the S-RS waits for its sub-tending S-AGW(s) and S-BTSs to register.

7.2 S-AGW Installation & Start-up The S-AGW has two primary interfaces, one towards the MNO BSC and the other towards the IP backhaul network. The interface to the BSC consists of a group of E1/T1 RJ-48 jacks. The IP backhaul interface is connected to the 100BaseT Ethernet RJ-45 jack. The interface to the S-RS and S-EMS may either be via an MNO provided Virtual Private Network (VPN) over the IP backhaul interface or by a separate, private network interface.

An S-AGW must be fully initialized and be configured before any sub-tending S-BTSs can register with the S-RS (see section 7.3). Upon S-AGW start-up, a secure IP connection to the S-RS is established (either using a VPN and/or separate private network). The S-RS secure network connection is used to authenticate and register the S-AGW with the S-RS. After authentication and registration, the S-RS then provisions the S-AGW with the IP address of its S-EMS. The S-AGW then establishes another secure network connection with the S-EMS and is configured with its management database. The S-RS is informed that the S-AGW is active. The S-RS is then able to accept S-BTS registrations.

7.3 S-BTS Installation & Start-up The S-Series is primarily designed for installations where an access link with a consistent throughput (e.g., DSL access) is dedicated to an S-BTS. This facilitates control in prioritization of outbound traffic types by the S-BTS and also allows for a greater level of security. An S-BTS is connected to the access network CPE device using a 100BaseT Ethernet interface.

The following list describes the processes that occur (also shown in Figure 15):

1 Local configuration:

• A table of provisioning records is read from Flash into the local memory of the S-BTS. Provisioning information read from Flash includes:

a) Fully Qualified Domain Name (FQDN) of the carrier’s S-BTS Registration Server

b) Unit serial number (assigned by operator)

c) Encrypted key

2 DHCP Configuration:

• Once the provisioning information has been retrieved, the S-BTS proceeds with network configuration and registration.

• The S-BTS issues a DHCP “DISCOVER” message to its Ethernet interface; using the IP protocol broadcast address (255.255.255.255). If properly connected to a broadband router (DSL, cable modem, etc.), the router will respond to the DISCOVER message with several items of information needed for operation:

a) The IP address which the S-BTS is to use for its IP communications

b) The network mask associated with the IP address

c) The IP address of the router’s “default gateway”

d) The IP addresses of one or more DNS servers

930-0006-02 Rev. A Authentication and Registration


• Other information may be included in the DHCP response; however these are the only items needed by the S-BTS.

Note: The IP address obtained using DHCP may be private or public. If private, it may be that the broadband router is performing Network Address Translation (NAT) to map the (provided) private IP address to a public address. Such NAT behavior is transparent to the S-BTS operation, provided the technical requirements for the broadband router behavior are adequately met.

3 Ethernet Address Resolution:

• The S-BTS uses Address Resolution Protocol (ARP) to determine the Ethernet MAC addresses of those devices to which it must directly communicate at Layer 2. If the connection to the IP wide area network is via a router, then only the MAC address of the collocated broadband access device is needed, as all other IP communications must traverse this device. If the connection to the IP wide area network is via a bridge, then the collocated broadband access device has no MAC address, but rather forwards traffic to the core network transparently. One or more Ethernet MAC addresses may be needed from the core network side; ARP automatically handles discovery and caching of any such addresses needed.

4 Registration:

• The S-BTS performs a DNS query to one or more of the DNS servers (identified by IP addresses obtained in the DHCP procedure) using the FQDN of the operator’s S-Series Registration Server (which was previously read from Flash).

• Using the IP address obtained from this DNS query, the S-BTS initiates a secure session with the S-RS. During session start-up, the S-RS tests the authenticity of the S-BTS requesting registration, using a cryptographic challenge. If the S-BTS can correctly answer the challenge, the S-RS will accept the S-BTS as authentic; otherwise the S-RS does not establish communication.

• Likewise, the S-BTS validates the authenticity of the S-RS. This is done with the same cryptographic challenge protocol used by the S-RS in authenticating the S-BTS, but in reverse order (i.e., the S-BTS challenges the S-RS using its private key as a secret, which the S-RS must know to prove its authenticity).

• Once mutual authentication is complete (and successful in both directions), the S-BTS and the S-RS may proceed with provisioning and preparation for operation.

5 Provisioning and Session Start-up:

• The S-RS provides information to the S-BTS with which it may establish communication with an S-AGW. This information includes:

a) IP address of the S-AGW with which it is to be associated

b) Session keys for encryption of all communications with the S-AGW. This includes a session key for the signalling session (using SCTP encrypted with IPsec), and may include one or more session keys for future traffic sessions (using SRTP).

• Once this information has been shared with the S-BTS, the S-RS contacts the chosen S-AGW and provides it with the IP address of the S-BTS and the keys.

Authentication and Registration 930-0006-02 Rev. A


• The S-AGW adds this IP address to its list of “authorized” S-BTS endpoints, permitting the S-BTS traffic to pass the S-AGW firewall.

6 System Synchronization:

• At this point the operational tunnelling between the S-BTS sub-systems and S-AGW begins using AES for encryption. The S-BTS synchronizes its system clock with the S-AGW using a RadioFrame proprietary packet-timing algorithm. After the system clock is adjusted, then the mobile-assisted macro-cell slot synchronization procedure is started.

7 GSM, GPRS Start-up/Initialization:

At this point the Abis interface is active and the GSM system management and GPRS time alignment procedures occur.

Figure 15 S-BTS Initialization Overview

930-0006-02 Rev. A Network Management


8 Network Management S-Series network management is performed by the following two functions:

• GSM System Management manages the GSM/GPRS aspects of the system. This level of management is specified within the GSM specifications and by the Nokia BSS implementation. The Nokia OMC manages the GSM/GPRS aspects of the S-BTS in the same way as for an existing Nokia BTS.

The Nokia Abis interface is implemented in an Abis gateway on the S-AGW node. The OML and RSL channels on the Abis interface enable the S-BTS to be seen by the Nokia network as another Nokia BTS.

The OMC is used to configure the S-BTS site and cellular network environment, to monitor the status of the managed objects, to make configuration changes and to perform administrative actions e.g. lock/unlock, in the same way as for any Nokia BTS.

• RFN S-Series System Management manages the proprietary aspects of the RFN S-Series system components, i.e. network elements (NEs), reports to the network level of management and is defined by RadioFrame Networks. The S-EMS manages the S-Series specific aspects of the S-BTS, S-AGW and S-RS.

The S-EMS is used to configure the S-BTS elements during commissioning, to perform software download and for fault and performance management of non-Abis related features.

The S-EMS supports standard protocols for communication with the OMC and that data can be extracted from the EMS using standard methods (e.g. FTP, XML).

Figure 16 illustrates the management delineation between the GSM system management and S-Series system management.

Figure 16 Network Management Delineation

8.1 GSM System Management GSM system management is an integral part of the Nokia Abis interface. The GSM Managed Object (MO) hierarchy for the RFN side of the Abis interface is described below.

S-BTS

S-AGW BSC

Nokia OMC

S-EMS

IP IP Backhaul

Nokia BTS Functions

SNMP GSM Apps SNMP

Nokia Abis

Nokia O&M

PCM

Network Management 930-0006-02 Rev. A


8.1.1 GSM Managed Object (MO) hierarchy The RFN S-Series is connected to the BSC via the Nokia Abis interface. There is no standard naming convention for the MOs on the logical BTS. The S-Series system adopts the MO hierarchy of BTS/Sector/Cell for the management system. The logical BTS MO is composed of sectors. Each sector is composed of 1 or more TRXs. In the S-Series product, each sector will correspond to an S-BTS of one TRX. The terms cell and sector are used interchangeably. Multiple E1/T1 connections to the S-AGW may be added in order to increase capacity (number of S-Series S-BTSs).

This strategy makes BTS management available over the Abis interface as expected by the Nokia BSC. For GSM system management functions, the S-Series system is seen as a collection of recognized Nokia BTSs.

8.2 RFN S-Series System Management The RFN S-Series Network Management system (NMS) addresses the requirements and architecture of the lower two layers of the Telecommunications Management Network (TMN) model, that is the Network Element Layer (NEL) and the Element Manager Layer (EML). See Figure 17 for an illustration of the TMN model and the scope of RFN’s domain. Any higher layer falls outside of the scope of defining the management of a specific network element.

Figure 17 S-Series Deployment for Network Management

The Network Management (NM) Architecture for the GSM S-Series includes three applications at the Element Manager Layer (EML), namely the Element Management Systems (EMS) for the S-AGW, S-BTS and S-RS. While they differ in the type of their target Network Elements, the three EMSs share a common infrastructure and fulfill a similar role in the overall NM environment. Together the three EMSs are referred to in this document as the S-Series EMS (S-EMS).

The NM functions at each of the NEs (S-AGW, S-BTS and S-RS) are provided first and foremost by SNMP Agent implementations. Additionally, each of the NEs is



equipped with a Local Management Entity (LME) that allows direct management access without having to go through the Element Layer.

As shown in Figure 18, the LME includes one or both of two separate Local Maintenance Terminal (LMT) facilities, running on the S-AGW platform: Command Line Interface (CLI) LMT and Web-based LMT.

Figure 18 LME Components

8.2.1 Network Element Layer The RFN NMS includes facilities at the Network Element Layer (NEL). These facilities allow the monitoring and control of the S-AGW and S-BTS NEL components.

These NEL management facilities are implemented in accordance to the SNMP standard, i.e., they:

• Define the set of managed objects using SNMP’s Structure of Management Information (SMI) and Management Information Base (MIB)

• Allow access to managed objects from management applications using the SNMP protocol operations

• Deliver notification events to management applications using the SNMP protocol operations

8.2.2 Element Management Layer The RFN NMS includes Element Management Layer (EML) applications running on the RFN S-Series Element Management System (S-EMS) perform the monitoring and control of the NEL components (S-AGWs, S-BTS and S-RS).

The EML applications operate in accordance to the SNMP standard; i.e., they:



• Identify the set of managed objects using SNMP’s Structure of Management Information (SMI) and Management Information Base (MIB)

• Access the managed objects at the NE level using the SNMP protocol operations

• Accept notification events from the NE level using the SNMP protocol operations The EML applications are based upon a commonly used network management platform. The platform provides generic management functionality, including:

• Graphical user interface • Network map facilities • Database management facilities • Customizable menus • Event log facilities • Application programming interfaces (API) • System security

The EML applications will be extensions of the common platform and provide the specific monitoring and control mechanisms for the NE components.

The monitor and control capabilities are available directly to users, via the platform user interfaces (graphical and text based), and to higher layer applications.

8.2.3 NMS Functional Areas In addition to the TMN layer decomposition, the scope of the network management requirements can be described using the standard OSI Management Functional Areas: Fault, Configuration, Accounting, Performance and Security (FCAPS).

8.2.3.1 Fault Management The RFN NMS has facilities to enable the detection, isolation and correction of abnormal conditions.

NE Layer A set of managed objects identifies the current status of each NE component and subcomponent. These objects are available for polling from the EML application.

Each NE maintains a log of significant events and errors and makes the log available to the EML application.

Thresholds are established and each NE will report, via trap, when a monitored variable crosses a threshold. NE’s will also report, via trap, when the status of an NE component or subcomponent has changed.

Each NE supports the execution of fault-isolation and self-diagnosis tests, upon request from the EML application.

EML Application The EML application has the ability to display the status of each NE component and subcomponent.

The EML application periodically polls the NE for status information and for any updates to the log of significant events and errors.

The EML application listens for and accepts reports from the NE (traps) indicating status changes and threshold crossing conditions.



The EML application has the ability to request that the NE execute test procedures, either upon a direct user request or automatically as a result of user-defined conditions. The application logs and displays the results of test procedures.

8.2.3.2 Configuration and Name Management The RFN NMS has facilities to identify and control the status and behavior of its components.

NE Layer A set of managed objects identifies each NE component and subcomponent, their relative topology (or containment relationship) and their administrative and operational status. These objects are available for retrieval and setting from the EML application.

While some NE components may be statically configured, the product also allows for the creation, reconfiguration and deletion of dynamically defined components or subcomponents.

NE’s will report, via trap, when the status or the topology configuration of an NE component or subcomponent has changed.

EML Application The EML application displays the configuration of NE components and subcomponents, indicating their nature, identity and status. The display identifies the topology configuration, including any hierarchical relationships.

The EML application periodically polls the NE for status information and for any updates to the topology configuration.

The EML application listens for and accepts reports from the NE (traps) indicating status and topology changes.

The EML application requests the NE to alter the status or the topology configuration of any NE component, either upon a direct user request or automatically as a result of user-defined conditions. The application logs and displays the results of the reconfiguration actions.

8.2.3.3 Accounting management The RFN NMS has facilities to enable the establishment, activation and collection of usage records.

NE Layer A set of managed objects identifies accounting measurement points and relates the usage of system resources with external or internal users. These objects include an indication of whether the measurement point is active and will define its collection and summarization schedule.

The measured values will be available for retrieval and setting from the EML application.

The measurement point status and configuration parameters are available for retrieval and setting from the EML application.

Accounting thresholds are set up and each NE will report, via trap, when a monitored variable crosses a threshold.

EML Application The EML application displays the identity, status and configuration parameters of any defined accounting measurement points.



The EML application periodically collects the measured values from the NE and makes them available for distribution to external applications.

The EML application listens for and accepts reports from the NE (traps) indicating threshold-crossing events.

The EML application requests the NE to alter the status or the configuration parameters of any accounting measurement point, either upon a direct user request or automatically as a result of user-defined conditions. The application logs and displays the results of reconfiguration actions.

8.2.3.4 Performance management The RFN NMS has facilities to measure and evaluate the behavior and effectiveness of its components.

NE Layer A set of managed objects identifies performance measurement points. These objects include an indication of whether the measurement point is active and will define its collection and summarization schedule.

The measured values are available for retrieval and setting from the EML application.

The measurement point status and configuration parameters are available for retrieval and setting from the EML application.

Performance thresholds are set up and each NE reports, via trap, when a monitored variable crosses a threshold.

EML Application The EML application displays the identity, status and configuration parameters of any defined performance measurement points.

The EML application periodically collects the measured values from the NE and makes them available for distribution to external applications.

The EML application listens for and accepts reports from the NE (traps) indicating threshold-crossing events.

The EML application requests the NE to alter the status or the configuration parameters of any performance measurement point, either upon a direct user request or automatically as a result of user-defined conditions. The application logs and displays the results of reconfiguration actions.

8.2.3.5 Security management The RFN NMS has facilities to enforce access policies and manage information protection.

NE Layer Access policies are implemented so that management requests can be subject to authentication and authorization checks.

The information flow to and from the EML application is subject to encryption to provide a minimal level of information protection.

Each NE maintains security logs, containing an audit trail of access attempts. The status of the security logging facility (enabled/disabled) is available for retrieval and setting from the EML application.

EML Application



The EML application is subject to the authentication and authorization checks defined as part of the access policies implemented by the NE layer.

The information flow to and from the NE layer is subject to encryption to provides a minimal level of information protection

The EML application has the ability to make requests the NE to alter the status (enabled/disabled) of the security logging facility, either upon a direct user request or automatically as a result of user-defined conditions. The EML application logs and displays the results of reconfiguration actions.

8.3 Software Download / Software Upgrade S-AGW – The S-AGW comes pre-loaded with the initial software version from the factory. For software upgrades, the new S-AGW software is loaded locally.

S-BTS – The S-BTS comes pre-loaded with the initial software version from the factory. For software upgrades, the S-BTS software is downloaded from the S-AGW using File Transfer Protocol (FTP) over the backhaul network, employing a secure IPSec tunnel. The software upgrade procedure is managed by the S-Series EMS.

Fault Management 930-0006-02 Rev. A


9 Fault Management Two types of fault management co-exist within the S-Series system.

• GSM Fault Management manages events and alarms for the GSM/GPRS aspects of the system. This level of management is specified within the GSM specifications and by the Nokia BSS Abis specification.

• RFN S-Series Fault Management manages events and alarms for the proprietary aspects of the RFN S-Series system components and is defined by RadioFrame Networks

9.1 GSM Fault Management GSM fault management is an integral part of the Nokia Abis interface. Events and alarms for the GSM/GPRS aspects of the system are mapped onto existing events and alarms in use by the Nokia BSS and are therefore seen in this way as events and alarms from recognized Nokia BTSs. This mapping is performed by the Abis gateway in the S-AGW.

9.2 RFN S-Series Fault Management The RFN S-Series Fault Management Strategy is based on the identification of events and alarms at each of the system components (S-BTS, S-AGW, S-RS and S-EMS) and their propagation for handling beyond each local component. The handling (both local and remote) of alarms plays a big role in supporting a redundancy scheme and thus providing an acceptable level of fault tolerance.

9.2.1 Component Hierarchy An individual strategy for Alarm Monitoring, Event Reporting and System Recovery is defined for each of the system components: S-BTS, S-AGW, S-RS and S-EMS. In addition to local event/alarm management, each component may also report events/alarms and initiate actions towards other components, both peers and non-peers.

The component hierarchy is represented in Table 5.

Table 5 Component Hierarchy Component Type Parent(s) Peers Children S-BTS S-AGW, S-EMS S-BTS None S-AGW S-EMS S-AGW, S-RS S-BTS S-RS S-EMS S-RS, S-AGW None S-EMS e.g., NMS e.g., other EMS S-RS, S-AGW, S-BTS

9.2.1.1 Parent Relationships In general, a ‘Parent’ relationship indicates a case where local events/alarms may be forwarded to another component for further remote actions. In particular:

• A given S-BTS, once registered, has a parent S-AGW (as assigned during the registration procedure): local S-BTS events/alarms (such as subcomponent failure or degradation) may be forwarded to the parent S-AGW, which can then perform actions (such as requesting an S-BTS reset).

• A given S-BTS also has a parent S-EMS, to which it can forward events/alarms for presentation via the EMS Status and Alarm Monitoring facilities. The S-EMS can also be equipped with the ability to take actions towards the reporting S-BTS, either manually (user-driven commands) or via automated procedures.

930-0006-02 Rev. A Fault Management


• A given S-AGW has a parent S-EMS, to which it can forward events/alarms for presentation via the EMS Status and Alarm Monitoring facilities. As with the S-BTS, the S-EMS can also be equipped with the ability to take actions towards the reporting S-AGW, either manually (user-driven commands) or via automated procedures.

• A given S-RS has a parent S-EMS, to which it can forward events/alarms for presentation via the EMS Status and Alarm Monitoring facilities. As with the S-AGW, the S-EMS can also be equipped with the ability to take actions towards the reporting S-AGW, either manually (user-driven commands) or via automated procedures.

9.2.1.2 Child Relationships In general, a ‘Child’ relationship indicates a case where a parent component may initiate actions toward another (subtending) component, as a result of handling a local event/alarm. In particular:

• A given S-AGW has zero, one or many subtending S-BTSs, which can be affected as result of the S-AGW handling a given local event/alarm. E.g., if the S-AGW detects a failure of its own system or of one its external interfaces, it may request a system reset of all its subtending S-BTSs.

• A given S-EMS has a number of subtending components (S-AGWs, S-RSs and S-BTSs). An S-EMS local failure should not result in an automated recovery action on its subtending components, since they do not require the S-EMS to perform their basic service. On the other hand, the S-EMS can be equipped with the ability to take manual actions (i.e., as result of user commands) towards any of its subtending components.

9.2.2 Alarm Handling & Event Reporting All S-Series alarm and event reporting is based on the ITU-T X.733 alarm reporting standard. The alarms and events associated with the system components (S-AGW, S-BTS, & S-RS) are defined as objects within the Management Information Base (MIB) for each system component. These alarms/events are reported to the S-EMS via SNMP. A network operator at the S-EMS may take action to correct/alleviate error conditions associated with the reported alarm or event but certain error conditions also require corrective action that is enacted autonomously by the components of the S-Series system.

This section outlines the system-level events and alarms that are detected and handled by the S-Series components.

A system level error condition is an error condition that is associated with the system as whole and/or associated with the interfaces between the defined system-level components.

9.2.2.1 S-BTS Alarms & Events Following is an outline of events and alarm conditions that are detected and handled by the S-BTS component.

Status Transitions The S-Series supports standard operational state definitions as defined by ITU-T X.731. The different S-BTS operational states are described below:

• Initializing – The S-BTS has just started up (or restarted) and is in the process of initializing its local resources, including the network interface towards the Internet



• Registering – The S-BTS has found the DNS and is contacting the S-RS, going through the registration procedure

• Registered – The S-BTS has successfully completed the registration procedure and is contacting the assigned S-AGW, going through the activation procedure

• Active – The S-BTS has completed the activation procedure with the S-AGW and is available to process user traffic

• Inactive – The S-BTS has detected a fatal failure (while in the Initializing, Registering, Registered or Active status) and is going through a cleanup procedure prior to restarting and returning to the Initializing status

The S-BTS generates an event every time it transitions to a new Operational Status. Such event can either set or clear a ‘System Unavailable for Service’ alarm. Such alarm condition is ‘on’ as long as the S-BTS’ Operational Status is not Active. The ‘Unavailable’ alarm condition is cleared once the S-BTS becomes Active.

The Status Transition events (and the ‘Unavailable’ alarm condition) are reported to the S-BTS Local Management Entity (including a local event log and a local event display). The event is also forwarded to the serving S-AGW and to the controlling S-EMS, where it can be used to update the current information about the availability and status of the MNO’s S-BTSs.

Events/Alarms while System is Unavailable for Service A series of events are detected and reported while the S-BTS is not yet available for service, i.e., while the S-BTS has not yet completed the activation procedure with its serving S-AGW. The main effect of this condition is that events and alarms can only be handled through the Local Management Entity (local log and display) and cannot be forwarded to the remote S-AGW and S-EMS for further handling. In general these events cause the S-BTS restart the initialization/registration/activation procedure (after a configurable delay and for a configured number of retries).

Examples of such events are:

• Initialization Failures – A problem has been detected during the initialization procedure, such as the failed start-up of a local component or interface point or software entity, the inability to get an IP address or to reach the configured DNS or to obtain the identity of an S-RS from the DNS.

• Registration Failures – A problem has been detected during the registration procedure, such as the inability to obtain the identity of a serving S-AGW from the S-RS.

• Activation Failures – A problem has been detected during the activation procedure, such as the inability to reach the assigned S-AGW or to the inability to establish and maintain a secure connection with the S-AGW or to obtain provisioning information from the S-AGW.

Events/Alarms while System is Available for Service A series of events are detected and reported while the S-BTS is active, i.e., available for processing user traffic. As such, the S-BTS has access to its serving S-AGW and to its controlling S-EMS, so that locally detected events/alarms can be forwarded to the S-AGW and/or the S-EMS for further handling.


• Loss of Communication with the S-AGW – This could be detected as a result of the two-way Keep-Alive-Ping procedure between the S-BTS and its serving S-AGW. A configured timeout and number of retries are used before declaring a Loss of Communication event, upon which the S-BTS sends an alarm message to the S-EMS (as a best-effort) and transitions to the Inactive status in order to

930-0006-02 Rev. A Fault Management


set up a system restart. Note that the S-AGW is able to detect a Loss of Communication with any of its served S-BTSs and reports such events to its own Local Management Entity and to the S-EMS.

• Local Component Failure – This can be detected as the failure of a local software entity (task) or a local interface point (Ethernet, SIM card). In case of a fatal failure, the S-BTS sends an alarm message to the S-AGW and to S-EMS (as best-efforts) and transitions to the Inactive status in order to set up a system restart.

• Degradation of Service – This includes conditions such as excessive delay and excessive jitter that can be detected as part of the user traffic transport infrastructure (RTP). A set of configurable thresholds is used to define levels of severity and thus control the actions taken in response to a degraded service condition (report to the Local Management Entity, report to the serving S-AGW and the controlling S-EMS, transition to Inactive status and initiate a system restart).

9.2.2.2 S-AGW Alarms & Events The following is an outline of events and alarm conditions that are detected and handled by the S-AGW component.

Status Transitions The S-Series supports standard operational state definitions as defined by ITU-T X.731. Examples of S-AGW operational states are listed below:

• Initializing – The S-AGW has just started up (or restarted) and is in the process of initializing its local resources, including the network interface towards the IP Backhaul, the Abis Layers 1 and 2 towards the BSC and the secure interface towards the S-RS

• Registering – The S-AGW is contacting the S-RS and is going through the authentication and registration procedures

• Registered – The S-AGW has successfully completed the authentication and registration procedures with S-RS and it is up to S-EMS to put this S-AGW into Active state

• Active – The S-AGW has been activated by S-EMS and is waiting for S-BTSs to activate

Note: The S-AGW is notified when the S-BTSs activate. As each S-BTS becomes active, the S-AGW performs the OML Abis activation procedure with the BSC and the S-BTS become available to process user traffic.

• Inactive – The S-AGW has detected a fatal failure (while in the Initializing, Registering, Registered or Active status) and is going through a cleanup procedure prior to restarting and returning to the Initializing status

The S-AGW generates an event every time it transitions to a new Operational Status. Such event can either set or clear a ‘System Unavailable for Service’ alarm. Such alarm condition is ‘on’ as long as the S-AGW’ Operational Status is not Active. The ‘Unavailable’ alarm condition is cleared once the S-AGW becomes Active.

The Status Transition events (and the ‘unavailable’ alarm condition) are reported to the S-AGW Local Management Entity (including a local event log and a local event display). The event is also forwarded to the controlling S-EMS, where it can be used to update the current information about the availability and status of the MNO’s S-AGWs.

Events/Alarms while System is Unavailable for Service



The following events are detected and reported while the S-AGW is not yet available for service, i.e., while the S-AGW has not yet completed the registration procedure with its serving S-RS. The main effect of this condition is that events and alarms can only be handled through the Local Management Entity (local log and display) and cannot be forwarded to the remote S-EMS for further handling.


• Initialization Failures – A problem has been detected during the initialization procedure, such as the failed start-up of a local component or interface point or software entity.

• Registration Failures – A problem has been detected during the registration procedure.

Events/Alarms while System is Available for Service The following events are detected and reported while the S-AGW is Active, i.e., available for processing user traffic. As such, the S-AGW has access to its serving BSC and to its controlling S-EMS, so that locally detected events/alarms can be forwarded to the S-EMS for further handling.


• Loss of Communication with the BSC or one of the active S-BTSs – This could be detected as a result of the two-way Keep-Alive-Ping procedure between the S-AGW and its subtending S-BTSs. A configured timeout and number of retries are used before declaring a Loss of Communication event.

• Local Component Failure – This can be detected as the failure of a local software entity (task) or a local interface point such as the Abis line card. In case of a fatal failure, the S-BTS sends an alarm message to the S-EMS (as best-efforts) and transitions to the Inactive status in order to set up a system restart.

• Degradation of Service – This includes conditions such as excessive delay and excessive jitter that can be detected as part of the user traffic transport infrastructure (RTP). A set of configurable thresholds is used to define levels of severity and thus control the actions taken in response to a degraded service condition (report to the Local Management Entity, report to the serving controlling S-EMS, transition to Inactive status and initiate a system restart).

9.2.2.3 S-RS Alarms & Events The alarms and events associated with the S-RS are defined as objects within the Management Information Base (MIB) for each S-Series network element. These alarms/events are reported to the S-EMS via the SNMP protocol.

930-0006-02 Rev. A Software Maintenance


10 Software Maintenance Because the architecture of the RadioFrame S-Series inter-works with the PLMN BSC and PCU over the proprietary Nokia Abis Interface, the S-Series must be compliant with each new software release from Nokia. RadioFrame manages this compliance in close co-operation with Nokia. The process requires prior notification from Nokia for each new release, all technical data required by RFN to implement the relevant features and functionality and support from Nokia during development and testing.

System Specifications 930-0006-02 Rev. A


11 System Specifications Note: In the specifications for S-BTS, a single S-1 is assumed.

11.1 Power Requirements and Consumption Power Supply Power Consumption

Unit Voltage Phase Frequency Peak Watts Avg

Watts Input: 90-264 VAC single 47 – 63 Hz

S-BTS Output: +12 VDC NA NA

20 18

Total (CPE) 18

S-AGW QTA 100-240 VAC single 50 – 60 Hz 750 200

S-AGW BCU -48 VDC NA NA 110 90

S-RS 100-240 VAC single 50 – 60 Hz 750 200

S-EMS 100-240 VAC single 50 – 60 Hz 750 200

Total (MNO) 690

930-0006-02 Rev. A System Specifications


11.2 RF Specifications The S-BTS complies to “essential conformance2,” as defined in 3GPP TS 11.21 [ETSI TS 101 087 V8.5.0 (2000-11)], pico-BTS (P1) power class. The table below outlines the RF specifications the S-BTS complies with. For a list of RF performance characteristics supported by the S-BTS, please refer to section 5.5 of the RadioFrame Networks S-Series Implementation Guide for Nokia Abis document (RFN document number 998-1017-01).

Parameter GSM Reference Results

Modulation Accuracy 11.21, subclause 6.2 (NOTE i) Compliant

Mean Transmitted RF Carrier Power 11.21, subclause 6.3 (NOTE ii) Compliant

Transmit RF Carrier Power vs. Time 11.21, subclause 6.4 (NOTE i) N/A*

Adjacent Channel Power- Spectrum due to Modulation & Wideband noise 11.21, subclause 6.5.1 (NOTE i) Compliant

Adjacent Channel Power-Switching Transients 11.21, subclause 6.5.2 (NOTE i) Compliant *

Spurious Emissions from Transmitter Antenna Connector 11.21, subclause 6.6 (NOTE i) Compliant

Intermodulation Attenuation 11.21, subclause 6.7 (NOTE i) Compliant

Intra-BTS Intermodulation Attenutation 11.21, subclause 6.8 (NOTE i) N/A*

Static Reference Sensitivity Level 11.21, subclause 7.3 (NOTE i) Compliant

Multipath Reference Sensitivity Level 11.21, subclause 7.4 (NOTE i) Compliant

Reference Interference Level 11.21, subclause 7.5 (NOTE i) Compliant

Blocking Characteristics 11.21, subclause 7.6 (NOTE i) Compliant

Intermodulation Characteristics 11.21, subclause 7.7 (NOTE i) Compliant

AM Suppression 11.21, subclause 7.8 (NOTE i) Compliant

Spurious Emissions From the Receiver Antenna Connector 11.21, subclause 7.9 (NOTE i) Compliant

Radiated Spurious Emissions 11.21, clause 8 Compliant

NOTE i: For pico Class BTS. Compliant * = Complies at P0 and P6, as a single BCCH TRX this clause is not normally tested N/A* = Not Applicable – Single TRX BTS

2 Essential conformance is defined on page 9 of 3GPP TS 11.21 version 8.10.0 Release 99.

System Specifications 930-0006-02 Rev. A


11.3 Interfaces Connector Cable Interface

INTERNAL ANTENNA ( x 3) SMA-type RG-58C Antenna / 50 Ohm Coax Um

S-AGW (WAN side) RJ-45 CAT5 Ethernet 10/100BASE-T

S-AGW (BSC side) RJ-48C CAT5 Ethernet 10/100BASE-T

G.703 Balun RJ-48C 120 Ohm CAT5 Abis / (E1/T1)

BNC TX / BNC RX 75 Ohm Coax Abis / (E1/T1)

11.4 Dimensions Building

Units Metric (w x h x d) Imperial (w x h x d) Weight (lbs./kg)

S-BTS — 26.7 cm x 18.9 cm x 4.4 cm 10.6” x 7.5” x 1.8” 2.2 / 1

S-AGW

BCU 4U high 17.78 cm x 48.26 cm x 38 cm 7” x 19” x 13” 25 / 11.4

QTA 1U high 4.45 cm x 48.26 cm x less than 65 cm

1.75” x 19” x less than 25”

Less than 75 / 34.1

S-RS 1U high 4.45 cm x 48.26 cm x less than 65 cm

1.75” x 19” x less than 25”

Less than 75 / 34.1

S-EMS 1U high 4.45 cm x 48.26 cm x less than 65 cm

1.75” x 19” x less than 25”

Less than 75 / 34.1

11.5 Environmental Value Parameter Condition

Min Typ Max Unit

Normal operation 0 27 40 °C Ambient Temperature Storage –40 70 °C

Normal operation relative, non-condensing 10 90 % Humidity

Storage, non-condensing 5 90 %

Altitude Relative to mean sea level. –60 1800 m

Shock 40 G

Vibration Level 4 earthquake; meets or exceeds GR-63-CORE Earthquake Environment NEBS requirements

99.9 % pass

Storage ETSI ETS 300 019-1-1 Class 1.3E

Transport ETSI ETS 300 019-1-2 Class 2.3

Operation ETSI ETS 300 019-1-2 Class 3.1

UL Pollution Degree 3 99.9 % pass

Transport Vibration NSTA, ISTA compliant 99.9 % pass

930-0006-02 Rev. A System Specifications


11.6 Compliance The S-Series system will meet the following safety and compliance specifications.

Parameter Applicable Standard

CE / R&TTE

TS 101 087 V8.5.0 ETSI EN 301 502 V8.1.2 (2001-07) (Requested parts only) – Radio ETSI EN 301 489-1 V1.5.1 (2004-11) – EMC ETSI EN 301 489-8 V1.2.1 (2002-08) – EMC for GSM 900/1800 and 850/1900 pico Class BTS ETS 300 019 – Parts met by test or design (TBD) EN 60950 and IEC 60950

FCC Parts 15, 22, & 24

UL UL60950

IP Rating IP 10 (Intended for indoor use)

RoHS The S1 is designed to meet the RoHS directive

WEEE The S1 is designed to meet the WEEE directive

Pico GSM BTS Product Description

Documents

Transcript of Pico GSM BTS Product Description