Sure Signal Premium - UK High Level Design v3.0

Sure Signal PremiumVESC-UK
High Level Design
Project No: N. 40000686502

PlanViewSeq-ID: N. 40000686698870
Document Reference Number: [Properties - Doc Ref #]
Version: 21.0
Date: 20 1114 Aug OctSep 20132
th th
Author: Balkishan Karwa / Anthony Masih/Mai Tran Le

Approval Status: For ApprovalIssued
Contents
1 Supporting Artefacts...................................................6
1.1 Source Artefacts...........................................................................................6
1.2 Referenced Artefacts....................................................................................6
2 Executive Summary....................................................7
2.1 Project Aim....................................................................................................7
2.2 Key Design Highlights...................................................................................7
3 Key Requirements Not Met.........................................8

4 Summary of Functionality.........................................10
4.1 Product Functionality..................................................................................10
4.2 Capability Functionality...............................................................................11
4.2.1 Dimension Model............................................................................11
4.2.2 WAN Dimensioning........................................................................12
4.2.3 IP Dimensioning.............................................................................12
4.3 Key Design Drivers.....................................................................................12
4.4 Out of Scope...............................................................................................13
5 Interactions with other designs.................................14

5.1 What does this solution depend on?..........................................................14
5.1.1 NSU Service Elements...................................................................14
5.1.2 Manual Commissioning & Provision...............................................14
5.1.3 VF Configuration for new Enterprise sites......................................14
5.2 What depends on this solution?.................................................................15
5.3 What impact will this solution have on implemented services? .................15
5.4 NewCo........................................................................................................15
6 Design Assumptions, Risks and Issues....................16

6.1 Assumptions...............................................................................................16
6.2 Risks...........................................................................................................16
6.3 Issues..........................................................................................................16
7 Static Design.............................................................18
7.1 Architecture Diagram..................................................................................18
7.2 Architecture Overview.................................................................................18
Technology
Sure Signal PremiumVESC-UK High Level Design
7.3 Radio Design..............................................................................................19
7.3.1 Frequency/Carrier...........................................................................20
7.3.2 Primary Scrambling Code (PSC) and Cell Reselection .................20
7.3.3 Maximum Transmit power..............................................................21
7.3.4 (Service Area Code) SAC and Cell ID...........................................21
7.3.5 Routing Area Code (RAC) / Location Area Code (LAC) ................21
7.3.6 Cell Name.......................................................................................21
7.3.7 Handover and cell reselection........................................................22
7.4 Impact on the NMS System........................................................................23
7.4.1 Performance Management.............................................................23
7.4.2 Fault Management..........................................................................24
7.4.3 Configuration Management............................................................25
7.5 IP Design....................................................................................................28
7.5.1 IP Transport....................................................................................28
7.5.2 Sigtran............................................................................................29
7.5.2.1 Iu-Flex..........................................................................................30
7.5.3 IuPS and IuCS................................................................................32
7.5.4 OAM................................................................................................32
7.5.5 Geo-Resiliency...............................................................................32
7.6 Enterprise LAN & Security..........................................................................33
7.6.1 Enterprise Cabling..........................................................................33
7.6.2 Radio Node Mains Power...............................................................33
7.6.3 Provision of a VLAN for the Small Cell Cluster ..............................33
7.6.4 Enterprise Firewall Ports................................................................34
7.6.5 DHCP..............................................................................................34
7.6.6 Enterprise Rack Space & Power....................................................34
7.6.7 UPS.................................................................................................34
7.7 Backup/Restoration....................................................................................34
7.8 BASNAC – Remote Access........................................................................35
7.9 Lawful Intercept..........................................................................................35
8 Dynamic Design........................................................36
8.1 Cell Reselection..........................................................................................36
8.1.1 User moves from 3G Macro Network to SCW Network .................36
8.1.3 User moves from SCW Network to 3G Macro Network.................38
8.1.5 User moves from No Macro Network to SCW Network.................40
8.1.6 User moves from SCW Network to No Macro Network.................40
8.1.7 User moves from SCW cell to SCW neighbour cell.......................41
8.1.8 User moves from SCW to LTE (4G) Network................................41
8.2 Voice Handover..........................................................................................42
8.2.1 Voice call in progress on 3G Macro Network, user moves to SCW
Network.......................................................................................................42
Version: 13.0 Document Classification: C3 Version Date:

114/1009/20132
Page 3 of 80
Technology
Network.......................................................................................................42
8.2.3 Voice call in progress on SCW Network, user moves to 3G Macro
Network.......................................................................................................42
Network.......................................................................................................43
8.2.5 Voice call in progress on SCW Network, user moves to no macro
network.......................................................................................................43
8.3 Packet Switched Handover........................................................................44
8.3.1 Data session in progress on SCW Network, user moves to 2G Macro
network.......................................................................................................44
9 Entity Summary.........................................................46
9.1 SC Radio Node...........................................................................................46
9.2 SC Services Node......................................................................................46
9.3 NSU (HNB-GW from NEC).........................................................................47
9.3.1 Security Gateway...........................................................................47
9.3.2 INC (Iu-Concentrator).....................................................................47
9.3.3 Load Balancer.................................................................................48
9.3.4 OAM Switch....................................................................................48
9.3.5 NMS................................................................................................48
9.4 UK Core Network........................................................................................48
9.4.1 Signalling Gateway (SGW).............................................................48
9.4.2 MSC................................................................................................48
9.4.3 SGSN..............................................................................................49
9.4.4 2G/3G Macro Cells.........................................................................49
9.5 UK IP Backhaul...........................................................................................49
9.6 UK NMS Network........................................................................................49
9.6.1 NetCool...........................................................................................49
9.6.2 ZenPM............................................................................................49
9.6.3 Evenflow.........................................................................................49
9.6.4 Cell Centroid...................................................................................49
9.6.5 Cramer............................................................................................49
10 Interface Summary....................................................51
10.1 Machine to Machine Interfaces..................................................................51
10.1.1 Interface between SCRN and SCSN...........................................51
10.1.2 Interface between SCSN and Se-GW..........................................52
10.2 Man Machine Interfaces.............................................................................53
11 Design Work Package Summary..............................54

12 Solution Check..........................................................55
114/1009/20132
Page 4 of 80
Technology
12.1 Technical Performance..............................................................................55
12.1.1 Latency and Jitter.........................................................................55
12.2 Business Performance...............................................................................55
12.3 Availability and Processing Integrity..........................................................55
12.4 Stability.......................................................................................................55
12.5 Scalability...................................................................................................56
12.6 Monitoring...................................................................................................58
12.7 Reporting....................................................................................................58
12.8 Finance.......................................................................................................59
12.9 Support.......................................................................................................59
12.10 Customer Care.........................................................................................59
12.11 System Decommission............................................................................60
12.12 Regulatory and Government Requirements............................................60
12.13 UKCR.......................................................................................................60
13 Security Dimensions.................................................66
14 Glossary....................................................................68
15 Document Control Information..................................70
15.1 Document Content History.........................................................................70
15.2 Key Reviewers...........................................................................................70
15.3 Approvals / Authorisations.........................................................................72
16 Template Version History..........................................74

1.............................................................................Supporting Artefacts6
1.1 Source Artefacts..................................................6

1.2 Referenced Artefacts...........................................6
2 Executive Summary....................................................7
2.1 Project Aim...........................................................7
2.2 Key Design Highlights..........................................7
3 Key Requirements Not Met.........................................8

114/1009/20132
Page 5 of 80
Technology
4 Summary of Functionality.........................................10
4.1 Product Functionality.........................................10
4.2 Capability Functionality......................................11
4.2.1 Dimension Model.......................................11
4.2.2 WAN Dimensioning....................................12
4.2.3 IP Dimensioning.........................................12
4.3 Key Design Drivers............................................12
4.4 Out of Scope......................................................13
5 Interactions with other designs.................................14
5.1 What does this solution depend on?..................14
5.1.1 NSU Service Elements..............................14
5.1.2 Manual Commissioning & Provision..........14
5.1.3 VF Configuration for new Enterprise sites. 14
5.2 What depends on this solution?.........................15
5.3 What impact will this solution have on
implemented services?....................................................15
5.4 NewCo...............................................................15
6 Design Assumptions, Risks and Issues....................16
6.1 Assumptions......................................................16
6.2 Risks..................................................................16
114/1009/20132
Page 6 of 80
Technology
6.3 Issues.................................................................16
7 Static Design.............................................................18
7.1 Architecture Diagram.........................................18
7.2 Architecture Overview........................................18
7.3 Radio Design.....................................................19
7.3.1 Frequency/Carrier......................................20
7.3.2 Primary Scrambling Code (PSC) and Cell
Reselection 20
7.3.3 Maximum Transmit power.........................21
7.3.4 (Service Area Code) SAC and Cell ID.......21
7.3.5 Routing Area Code (RAC) / Location Area
Code (LAC) 21
7.3.6 Cell Name..................................................21
7.3.7 Handover and cell reselection...................22
7.4 Impact on the NMS System...............................23
7.4.1 Performance Management........................23
7.4.2 Fault Management.....................................24
7.4.3 Configuration Management.......................25
7.5 IP Design...........................................................28
7.5.1 IP Transport...............................................28

114/1009/20132
Page 7 of 80
Technology
7.5.2 Sigtran.......................................................29
7.5.2.1 Iu-Flex......................................................30
7.5.3 IuPS and IuCS...........................................32
7.5.4 OAM...............................................................................................32
7.5.5 Geo-Resiliency...............................................................................32
7.6 Enterprise LAN & Security..........................................................................33
7.6.1 Enterprise Cabling..........................................................................33
7.6.2 Radio Node Mains Power..............................................................33
7.6.3 Provision of a VLAN for the Small Cell Cluster ..............................33
7.6.4 Enterprise Firewall Ports................................................................34
7.6.5 DHCP.............................................................................................34
7.6.6 Enterprise Rack Space & Power....................................................34
7.6.7 UPS................................................................................................34
7.7...........................................................................Backup/Restoration
....................................................................................................................34
7.8................................................................BASNAC – Remote Access
....................................................................................................................35
7.9 Lawful Intercept..........................................................................................35
8 Dynamic Design........................................................36
8.1 Cell Reselection..........................................................................................36
8.1.5 User moves from No Macro Network to SCW Network.................40
8.1.6 User moves from SCW Network to No Macro Network.................40
8.1.7 User moves from SCW cell to SCW neighbour cell.......................41
8.2................................................................................Voice Handover
....................................................................................................................41
Network.......................................................................................................41
Network.......................................................................................................41
Network.......................................................................................................42
Network.......................................................................................................42
8.2.5 Voice call in progress on SCW Network, user moves to no macro
network.......................................................................................................43
8.3................................................................Packet Switched Handover
....................................................................................................................43

114/1009/20132
Page 8 of 80
Technology
8.3.1 Data session in progress on SCW Network, user moves to 2G
Macro network............................................................................................44
9...................................................................................Entity Summary
....................................................................................................................45
9.1.................................................................................SC Radio Node
....................................................................................................................45
9.2.............................................................................SC Services Node
....................................................................................................................45
9.3.................................................................NSU (HNB-GW from NEC)
....................................................................................................................46
9.3.1 Security Gateway...........................................................................46
9.3.2 INC (Iu-Concentrator).....................................................................46
9.3.3 Load Balancer................................................................................47
9.3.4 OAM Switch....................................................................................47
9.3.5 NMS................................................................................................47
9.4..............................................................................UK Core Network
....................................................................................................................47
9.4.1 Signalling Gateway (SGW)............................................................47
9.4.2 MSC................................................................................................47
9.4.3 SGSN.............................................................................................48
9.4.4 2G/3G Macro Cells.........................................................................48
9.5.................................................................................UK IP Backhaul
....................................................................................................................48
9.6..............................................................................UK NMS Network
....................................................................................................................48
9.6.1 NetCool..........................................................................................48
9.6.2 ZenPM............................................................................................48
9.6.3 Evenflow.........................................................................................48
9.6.4 Cell Centroid...................................................................................48
9.6.5 Cramer............................................................................................48
10.............................................................................Interface Summary
....................................................................................................................50
10.1.........................................................Machine to Machine Interfaces
50
10.1.1 Interface between SCRN and SCSN...........................................50
10.1.2 Interface between SCSN and Se-GW.........................................51
10.2...................................................................Man Machine Interfaces
52
11.........................................................Design Work Package Summary
....................................................................................................................53
12..................................................................................Solution Check
....................................................................................................................54
12.1....................................................................Technical Performance
54
12.1.1 Latency and Jitter.........................................................................54
12.2.....................................................................Business Performance
54

114/1009/20132
Page 9 of 80
Technology
12.3..................................................Availability and Processing Integrity
54
12.4..........................................................................................Stability
54
12.5.......................................................................................Scalability
55
12.6......................................................................................Monitoring
57
12.7........................................................................................Reporting
57
12.8..........................................................................................Finance
58
12.9..........................................................................................Support
58
12.10..............................................................................Customer Care
58
12.11...................................................................System Decommission
59
12.12.....................................Regulatory and Government Requirements
59
12.13...........................................................................................UKCR
59
13...........................................................................Security Dimensions
....................................................................................................................65
14............................................................................................Glossary
....................................................................................................................67
15.............................................................Document Control Information
....................................................................................................................69
15.1...............................................................Document Content History
69
15.2................................................................................Key Reviewers
69
15.3................................................................Approvals / Authorisations
71
16....................................................................Template Version History
....................................................................................................................72

114/1009/20132
Page 10 of 80
Technology
1 Supporting Artefacts
1.1 Source Artefacts
[1] NEC HNB Gateway High Level Design, July 2012,
1.2 Referenced Artefacts
[1] The SCW OS (SCOS) Data Model Reference Guide, Release 2.0, June 2012
[2] SCW Administrator Guide Release 2.0, Feb 2012,
[3] SCW Deployment Planning Guide, May 2012
[4] Performance Measurements for SCW Small-Cell Clusters, Release 2.0.5, July
2012
[5] SCRN 200 Data Sheet, Jan 2012
[6] SCSN 8000 Data Sheet, Jan 2012
[7] DOC-SCOS-CLI-01 The SpiderCloud® OS (SCOS) CLI User Guide,

Release 2.0

114/1009/20132
Page 11 of 80
Technology
2 Executive Summary
2.1 Project Aim
This product category provides a means of offering high quality, capacity and reliability
wireless (UMTS) services to Enterprise customers using a new architectural approach
above and beyond that which is offered by current solutions such as picocells, DAS
systems and Femtocells (Vodafone Sure Signal).
This approach intendeds to allow in-building coverage and capacity solutions to be

delivered at a more cost effective level than existing methods, enabling both
CAPEX/OPEX savings for existing large scale enterprises or to reach new enterprises
which were not previously economic to cover. This service will address the Enterprise
size segment in-between that of the ALU based Vodafone Managed Sure Signal (MSS)
and conventional DAS systems.
This HLD defines the technical requirements and architecture for the deployment of
Spider Cloud Wireless in building Small Cell Cluster Systems throughout Vodafone UK.
Once a new site has been commissioned all Vodafone subscribers will be able to
access the system in an “Open Access” mode using Spider Cloud Radio Nodes (SCRN)
connected to a Services Node (SCSN), which is installed on the customer premises and
backhauled to Vodafone UK using a Committed Bit Rate (CBR) backhaul connection
from existing suppliers such as BT and Cable and Wireless (C&W).
2.2 Key Design Highlights

Each Spider Cloud deployment will consist of a single Services Node and multiple
Radio Nodes. These are located at the Enterprise premise requiring 3G service
enhancement. To meet lower deployment costs it is possible to deploy the Spider Cloud
equipment to run over an existing Enterprise LAN.
The Services Node connects to the Vodafone UK network over a dedicated backhaul
connection that is further secured using IPSec encryption. The IPSec connection will
terminate at a Security Gateway (SeGW) and the connection from the Services Node
will use Iu-h and terminate at an Iu-h concentrator/aggregator (Home NodeB Gateway).
NSU is hosting a new service based on NEC’s Home NodeB Gateway. There are
various new network elements in this Gateway including the Security Gateway (SeGW),
which terminates IPSec connections to individual SCSNs’, as well as the Iu-
Concentrator (INC). The Iu-concentrator connects to multiple SGSN’s and MSC’s via
Signalling Gateways to support core network requirements such as Iu-flex network
redundancy.
The Services node sends fault alarms to the Fault Management (FM) – Micromuse
Netcool and Performance Management (PM) data to ZenPM.
The backup for each enterprise configuration will be done manually through CLI
commands and store them at PM Mediation Server.
The initial service does not include a Spider Cloud network element manager and there
is no provisioning platform. Provisioning will take place during the on-site
commissioning, which is managed by VF.

114/1009/20132
Page 12 of 80
Technology
3 Key Requirements Not Met

The following requirements are met:-
 The business requires a solution that will deliver an in-building coverage

scheme at a target cost 80% of the existing pico deployments.
 The solution is to target the market segment between MSS and pico
deployments.
 The service offering is to be as similar to MSS as possible, given the variance

of 3rd party products used to support the service.
 The service is to comply with UK common requirements.
Other than these key requirements, There are no additional separate Business
Requirements defined for this project. To help understand the basis of the delivery this
chapter lists the key Business Requirements identified for MSS (which offers a very
similar service for smaller enterprises) SCW and provides a comparison against what is
provided forwith this Business Service.
Services that are the same:-.
The Spider Cloud solution and service is very similar to MSS. Elements and aspects
that are the same:-
 Femtocell operating in Open Mode access
 Femtocell to Femtocell handover
 Dedicated backhaul link to VF , protected by IPsec
 PM via ZenPM
 FM via NetCool
 Remote Access (via BASNAC)
The Elements and aspects that differ are:-
 Femtocells operating in Closed mode – Closed Modethis service is not offered

to the end customerprovided
 No ACLM – No provisioning platform. ACLM offers the following functions to

VMS:
- Co.uk public internet front end – not required for Enterprise customers
- Postcode/LAC/SAC management from NMS
- Femtocell ACL – Closed mode access is not offered
- Radio Profile use – No Requirements
- Active / Passive cell management – No Requirement
 No FMS – no SCW network element manager. FMS offers the following:-
- Remote SW Down Load – No Requirements
- Femtocell diagnostic interrogation

114/1009/20132
Page 13 of 80
Technology
- Femtocell remote management
 No AAA – no Product Authentication key as the supply channel is controlled my

Vodafone.
 No NTP Servers – there is no feed from NTP servers
NTP is not required for system operation (although recommended to maintain

synchronization of logs and management messages with Vodafone’s network
management systems. Spider Cloud supports NTPv4.2.
Following key requirements will not be available for initial launch due to product
limitation (see section 6.3 Issue)
 Backhaul Resiliency.
 SAC per Radio Node.
MTPAS is a UK Government requirement for Mobile Network operators aimed at

allowing Mobile services to continue in the event of widespread network calls. The
VESC-UK service provides an in-building service where users make calls via
a dedicated backhaul. At the time of writing it is not clear if MTPAS is applicable to this
type of service. See Section 4.4 Out of Scope.

114/1009/20132
Page 14 of 80
Technology
4 Summary of Functionality
4.1 Product Functionality
This Spider Cloud product provides a means of offering high quality, capacity and
reliability wireless services to Enterprise customers using a new architectural approach
above and beyond that which are currently offered by conventional solutions such as
picocells (DAS systems) or Femtocells.
The Spider Cloud product itself provides traditional UMTS network capabilities such as:
 Support of 15 active radio users per Radio Node
 Support of circuit switched voice
 Support of Packet Switched data
 Support of HSDPA Category 10 data rates
 Auto provisioning and auto optimisation of Radio Nodes
 Soft Handover between Radio Nodes
 Macro network reselect in and out
 Handover
 SMS and MMS
 Multiple terminal/dongle/mobile/smart phone/tablet testing
 Call features, voicemail, call divert, conference calling etc
 Emergency calling
The NEC Home Node B gateway solution provides aggregation for all of the Spider
Cloud deployments in the UK and the following key functions:
 HNB Access Network Control
o Management of the Iuh Interface using the HNBAP protocol
o Maintenance of the Iuh session for each HNB and for each UE attached
to the HNB
 Circuit Services Control
o Iu-CS interface signalling
o Per call signalling control to set up and release circuit bearers
o Direct transfer of Iu-CS Layer 3 messages between handsets and the

core network
 Packet Services Control
o Iu-PS interface signalling

114/1009/20132
Page 15 of 80
Technology
o Management of UMTS packet bearer channels
o Direct transfer of Iu-PS Layer 3 messages between handsets and the

SGSN
4.2 Capability Functionality

The Spider Cloud Small Cell Cluster system will be targeted at two types of deployment
models:
Existing Enterprise with IP based infrastructure sharing the Small Cell Cluster
equipment (similar to an Enterprise Wi-Fi deployment)
A deployment within an enterprise or venue where either no existing IP infrastructure

exists or parallel infrastructure must be deployed (for example a green field deployment)
Deployment Model 1 will use existing IT IP infrastructure and typical be assigned a

Layer 2 VLAN on the Enterprise Network and will be offered as this is a requirement for
some installations. Troubleshooting of the LAN infrastructure between the Services
Node and the Radio Nodes will be between Vodafone Approved installation contractors
and the IT Manager of the Enterprise.
Deployment Model 2 would require the installation of an IP based Infrastructure of

switches, routers and Ethernet cabling. Customer racks and power infrastructure will be
re-used if existing space and power are available.
4.2.1 Dimension Model

The proposition will be offered in one of three four sizes of scale, each with a single
backhaul connection and single SCSN.
Small Medium Large Very Large

Enterprise Size >101-300 301-500 501-1000 1001-2500
Max Users 300 500 1000 2500
Number of Radio Nodes (up to) 6 10 20 50
Number of Services Nodes 1 1 1 1
Backhaul Size (Mbps) 1-5 5-10 5-10 10-20
Area of Coverage ('000 sq. m.) 4.5 7.5 15 37.5
Calculated Average DL ( Mbps ) 0.18 0.29 0.58 1.46
Calculated Peak DL (Mbps) 2.70 4.49 8.99 22.46
Table 1 – Dimensions Model
Estimates on the approximate number of users and Radio Nodes are of course
dependent on the traffic profile of users as well as the in-building topography.
Architectures for each of the three deployment sizes are identical except for the size of
the CBR link.
Approximate Rules of thumb are for 50-100 users per Radio Node and 500-1,000 sq. m.
per Radio Node.
Dimension Backhaul aggregator supports 1GB. This would for example support a
minimum of 200 sites, each carrying 5MB of data, with no overloading.

114/1009/20132
Page 16 of 80
Technology
4.2.2 WAN Dimensioning

Dimensioning of the WAN connection itself will be made on a number of factors,
including:
 Number of voice subscribers

 Number of data subscribers
 Busy Hour usage (Erlangs) of voice users
 Usage of data subscribers
 Number of Visitors
 Required peak burst rate (14.4 Mbps per Radio Node)
 Future scope for the support of WiFi Radio Nodes
 Overhead (approximately 25%) of using a single IPSec tunnel.
The service will initially launch with a a single non-resilient 1Gig Ethernet IP backhaul
link, aggregating all of the individual SCSN backhaul links.
In any estimation of total throughput provision must be made for future capacity
increase due to:
 New devices types and applications

 Addition of extra Radio Nodes
 Increased UMTS Release support and associated throughputs
 Additional users or additional penetration into the Enterprise (including personal
devices)
 Multiple devices per user
 Support for dual UMTS and WiFi Radio Nodes
 Migration to 4G services
4.2.3 IP Dimensioning
A class C subnet is used for the Enterprise IP addressing and can support up to a
maximum of 256 services nodes.
4.3 Key Design Drivers

Each Spider Cloud deployment will consist of a single Services Node and multiple
Radio Nodes (see the Proposition section).
The Services Node connects back to the Vodafone UK IuCS & IuPS networks over a
dedicated backhaul connection that is further secured using IPSec encryption. The
IPSec connection will terminate at a Security Gateway (SeGW) and the connection from
the Services Node will use Iu-h and terminate at an Iu-h concentrator/aggregator.
The Iu-h concentrator will connect to multiple SGSN’s and MSC’s to support core
network requirements such as Iu-flex via Signalling Gateway. Note, that the terms Iu-h
concentrator, Iu-Concentrator, aggregator or gateway may be used interchangeably.

114/1009/20132
Page 17 of 80
Technology
The Services node is also connected to existing backend Fault Management (FM) –
Micromuse Netcool SNMP and Performance Management (PM) (ZenPM) systems.
This project builds on architecture that has been tested by Vodafone Group and UK in
Fountain House (interoperability testing), Faraday House (scaling testing) as well as
commercial pilots.
4.4 Out of Scope

The following points are out of scope for the initial commercial launch.
 Location Based Services.
 Incorporation of the SC network element manager.
 Closed Mode service offering.
 Future SCW product offerings, such as WiFi hybrid products.
 Data Offloading
 MTPAS: The SCSN’s SCW product transparently supports the MTPAS

regulatory requirement via the CLI. It is assumed that changes are needed for
the MapInfo service to support this requirement; but the need or otherwise for
an intermediate service entity to interface between MapInfo and the individual
SCSN’s is being clarified. Specific changes need for MapInfo & possible
inclusion of a vendor specific intermediate translation function will be clarified
further and are currently out of scope.

114/1009/20132
Page 18 of 80
Technology
5 Interactions with other designs

5.1 What does this solution depend on?
5.1.1 NSU Service Elements

The commissioning and acceptance of new Iu-Concentrator (Home NodeB Gateway) to
aggregate the traffic from multiple SCSN connections and SeGW to establish the IPSec
tunnel from multiple SCSN.
5.1.2 Manual Commissioning & Provision

Vodafone Approved Contractors to manually provision and perform site configuration
changes, as there is no automated provisioning system.
In general below points are follows for the deployment of each new customer:
 Identification Enterprise customer (and broad site metrics) that meets Business
Case
 Initiate Network Request via Evenflow
 Site Survey and Cost Estimate, usually by Vodafone Special Coverage Team or
3rd Party
 Build decision
 Legal access / acquisition
 Ordering of leased line by UK Transmission team
 Ordering of Enterprise LAN equipment
 Allocation of configuration parameters and issue of Work Order (via
Evenflow/Cramer)
 Installation of Enterprise on site Equipment (SCW + LAN)
 X.509 certificate being issued & managed for each IPsec
 Provisioning of VF network elements
 Commissioning of Enterprise Leased Line
 Commissioning of new site
 Acceptance of new site: (KPI, PM, FM)
 Handover of new site (Capital Assets to Property & customer support to SO).
 Ongoing monitoring, support and maintenance (via ZenPM, Netcool).
5.1.3 VF Configuration for new Enterprise sites

For each new Enterprise site the following VF configuration changes are needed:
 SAC / Cell Id (issued by Cramer)
 Enterprise IPsec address & IPsec certificate (issued by the SeGW)
 Enterprise (inner) IP addresses (issued by the SeGW) as used by VF

configurations.

114/1009/20132
Page 19 of 80
Technology
 Add Service Node IP address into NMS poll-device list and SCSN name
assigned within the NMS DNS Lookup.
 Configure new SACs into the Pool 1 MSCs.
 Create separate VLAN for the new enterprises on the backhaul where BT GigE
link terminates.
5.2 What depends on this solution?

There are no dependencies on this solution
5.3 What impact will this solution have on implemented services?

The SCW system will only use a single MSC POOL-1 regardless of geographical
location of the customer. This will cause an extra inter-pool signalling in case of
customer are located outside the coverage of POOL1 MSCs.
5.4 NewCo
There is no impact on the IT Network (NewCo) as this solution is to provide the better
radio coverage to the Enterprises customers.

114/1009/20132
Page 20 of 80
Technology
6 Design Assumptions, Risks and Issues

6.1 Assumptions
Customer sites are grouped into four sizes, Small, Medium Large and Very Large. The
details in terms of bandwidth required for each of these is assumed to be accurate.
50-100 users per radio node and 100-1000 sq metres per Radio node used for Spider
Cloud dimensioning.
As part of the engagement agreement, the Enterprise customer must provide a secure

rack within the customer site for the SCSN
The customer must also provide suitable mounting positions for Radio Nodes, these will
be in locations to provide direct line of sight to users and not positioned in cupboards or
above ceiling tiles which may impact RF performance.
Dedicated leased line with resilient connectivity to the local IPBB-NC.
6.2 Risks
The NSU centralised architecture means that all enterprise traffic will flow across the IP
Backbone twice. The current stats show we are still within NEC recommendations (250
ms) and target design to meet 150ms but still this is a risk until this is proven.
The SCW products and NEC Home NodeB Gateway are both new and are still
undergoing product approval.
6.3 Issues
NEC Iu-Concentrator is currently limited to 10 Iu Interfaces means that all of the UK
MSC elements (3x8) and SGSN (9) cannot be connected to. NEC has committed to
upgrade their product to support 17 Iu Interfaces which will address an 8 MSC (Pool1) +
9 SGSN configuration.
NEC Iu-Concentrator is currently support the default RTO.max (SCTP parameter) but
Vodafone UK wants this to be setup as configurable value between 200ms to 500ms.
NEC has to include this in future development.
At launch the service will only be connected to a single MSC Pool (Pool 1), which is
geographically linked to MSC serving the London SE of England. Longer term MSC
pool migration planning may affect existing VESC sites.
When a VF user leaves a VESC site that is located outside of the Pool 1 region, it will
be “deaf to paging” for up to 30 seconds, while a new MSC is assigned. During this
window incoming calls cannot be received. It is possible that an incoming text message,
sent within this window, will not be delivered for several hours.
VF customers entering and leaving VESC sites (from outside of this region) will
generate some additional signalling traffic as the VF network re-homes them to a
different MSC.

114/1009/20132
Page 21 of 80
Technology
NEC Security Gateway limitation: supports a maximum 1GB bandwidth (750 MB inside
IPsec) for all Enterprise sites. To service 160 Enterprise sites, each site (on average)
cannot generate more than 4.7MB actual data). Obviously, more that 160
Enterprises can be supported by the Backhaul aggregation link, if the average actual
data is lower.
The current SCW functionality supports the SAC per service node only and the
functionality will be modified to support the SAC per radio node which will be available
in Q4-2012.
The current SCW functionality does not support BGP routing so the backhaul resiliency
(GigE link between BT and VF) won’t be available for the initial launch. The SCW
solution will enhance the product in future to support BGP.
The current SCW functionality supports the preloaded keys for establishing the IPSec
tunnel but Vodafone UK want these keys to be issued by Vodafone CA for better
security and control. At the time of writing this document, this is under discussion with
SCW.

114/1009/20132
Page 22 of 80
Technology
7 Static Design
7.1 Architecture Diagram
Figure 1 – Architecture Overview
7.2 Architecture Overview

The proposed architecture for the solution consists of a number of network elements
which will each be given a brief description of functionality below. Each of the elements
can be seen in Figure 1 – Architecture Overview, see above.
Spider Cloud Radio Node (SCRN) – The SCRN, or Radio Node, is the active Radio
element of the system. Multiple Radio Nodes are deployed on the Enterprise site in a
manner similar to WiFi Access Points. They are powered over Ethernet and
communicate with the SCSN using IP over Ethernet. All traffic from the SCRN’s to the
SCSN is encrypted.
Spider Cloud Services Node (SCSN) – The SCSN, or Services Node (sometimes
referred to as a “controller”), is a single rack unit IP devices that is installed in the
comms room of an Enterprise customer. The SCSN is responsible for managing all of
the Radio Nodes as well as terminating the core connection back to Vodafone. The
SCSN also performs other tasks such as radio optimisation, performance and alarm
aggregation, IP routing, Iu-h, security and policy enforcement.

114/1009/20132
Page 23 of 80
Technology
IP backhaul – Each Services Node is connected back to Vodafone using IP based

backhaul. This is typically an Ethernet service from BT which is a minimum of 20Mbps
andsupports up to 100Mbps. The IP Backhaul will be aggregated by BT and delivered
to Vodafone in 1Gbps fibre connections.
Security Gateway (SeGW) – The Security Gateway is installed on Vodafone premises

and is responsible for terminating a secure IPSec tunnel from each of the Services
Nodes. This ensures that traffic from the enterprise cannot be intercepted at any point.
Iu Concentrator – The Iu Concentrator, which may also be referred to as an Iu-h

Concentrator, Iu-h Gateway is a network element that is responsible for aggregating all
of the Services Nodes and presenting them back to the core network. The Iu
concentrator uses a protocol called Iu-h to communicate with the Services Nodes and
uses standard Iu-CS and Iu-PS to communicate with the macro core network. The Iu
concentrator will communicate to MSC or SGSN pools. The Iu concentrator appears to
the macro network like an RNC and has an RNCID. Support for multiple LACs/RACs
per Iu concentrator is a considered option as well as Iu concentrator redundancy.
SGSN Pool and MSC Pool – For the initial launch the Iu-Concentrator will connect to all
of the MSC within UK MSC Pool 1 as well as to all 9 of the UKs SGSN.
Netcool – The Micromuse NetCool tool will be used to capture events and alarms form
thefthe Services Nodes. Each Services Node would be a separate object in the Netcool
system and event reporting is via SNMPV3.
ZenPM – ZenPM is the Performance Management (PM) system that will calculate
network KPIs for the Spider Cloud networks.
File Store (FS) – The FS is a server where the Services Nodes will send via SCP the
Performance Management raw data in the form of xml files for retrieval and processing
by the ZenPM system. This server will also used to store the software and configuration
backup for each enterprise site.
7.3 Radio Design

The Spider Cloud System will require a set of available PSC’s on the OTA frequency.
In addition, the 10 active PSC’s used for Enterprise femto cells will be used to enable
idle mode cell reselection from the macro network into the Spider Cloud Small Cell
Cluster.
Allocation of Radio Parameters by Vodafone UK is required. These parameters will be

assigned by Cramer:
- MNC/MCC (PLMNID) to be used - 23415
- LAC/RAC need to be provided for the Iu-h concentrator only (the LAC
and RAC must be unique for one site and different value for geo-resiliency site).
- SAC needs to be provided per cell level.
- RNC ID – assigned to the Iu-h concentrator (different RNC ID for the

geo-resiliency site)
- Cell ID’s need to be given – it is intended to assign unique Cell ID’s to ensure
compatibility with location based services.
- Primary Scrambling Codes – Passive PSC whole range except some

exceptions andexceptions and active PSC range 496-505
- ARFCN - 10687
- Emergency Area needs to be provided for each SAC

114/1009/20132
Page 24 of 80
Technology
7.3.1 Frequency/Carrier
The frequency 10687 (referred to as the 3rd carrier or Femto carrier) will be used for the
SCW solution deployment. .
7.3.2 Primary Scrambling Code (PSC) and Cell Reselection

The PSC allocation method proposed is designed to utilise previous work undertaken
for Open Access Femtos / Consumer Femtos.
Each Spider Cloud SCSN utilise a maximum of 75 Radio Nodes, so an allocation of 75

unused PSC’s or less depending on amount total Radio Nodes deployed per location
would be sufficient for the system to operate. At least 6-10 of these PSC’s must be the
active PSC’s used by Femtocells and these active PSC’s will be defined to the
neighbour lists of macro cells (Ncell). This will allow the Spider Cloud systems to
operate with minimal configuration changes to the macro network.
The Services Node will self organise all Radio Nodes using a list of PSC’s that we give
the Services Node as being available for use. For example, if only 20 passive PSC’s are
available to use then the Services Node with Self organise/optimise to give the best
possible system capacity based on 20 PSC’s by ensuring maximum PSC re-use
separation (Obviously the more a system has to re-use PSC’s then the more potential
mobility issues will be in the system). These passive PSC’s do not need to be
advertised on the macro in Ncell lists.
In deployment scenarios where macro coverage is particularly weak, there may be a

need to modify the sInterSearch and offset1sn/offset2sn values to make reselection to
the SCC more difficult. These criteria will be developed in conjunction with UK RF and
Special Coverage teams in addition to PSC allocation and any requirements for Ncell
provisioning.
Vodafone is looking to sub divide the 10 Active PSC between MSS and Spider Cloud, for
example
Active PSC Allocation

496 497 498 499 500 501 502 503 504 505
MSS SCW
Table 2 – Active PSC Allocations
The configurations to the MSS are not as per Spider Cloud recommendation. It should
be noted that where ever necessary the Vodafone default configuration as per below
table will be used, however these can be optimise to improve performance of the
network if necessary and default will be review for the duration, to ensure it is correct.
Parameter Vodafone Unit Spider Cloud Comments

Default Recommendation
Qrxlevmin -101 dBm -90
Qqualmin -15 dB -15
Qoffset,sn1 0 dB -20
Qoffset,sn2 N/A dB - Not Used
qHyst1 4 dB
qHyst2 4 dB
sInterSearch 12 dB

114/1009/20132
Page 25 of 80
Technology
sIntraSearch 12 dB
Table 3 – Radio Parameters
7.3.3 Maximum Transmit power

The Services Node, during RF optimisation, will adjust the output power of Radio Nodes
so that seamless coverage within the building is achieved with minimal overlap and thus
reducing interference impact to the surrounding macro network. The maximum transmit
power of any Radio Node will not exceed the default maximum of 100mW.
7.3.4 (Service Area Code) SAC and Cell ID

All Spider Cloud Radio Nodes will be assigned a cell ID and SAC in the same way as
macro 3G cells. The SAC and cell ID’s will be allocated by Cramer.
The Services node currently supports a maximum of 75 Radio Nodes, however a

suggested maximum of 100 Radio Nodes is recommended to be considered when
planning parameter allocation.
The SAC and Cell ID’s will be allocated uniquely for each Radio Node. It is
recommended that an allocation of 100 SAC and Cell IDs per Services Node is made.
As Cell ID can be a value from 1 to 65500 (within the LAC which is

assigned to the Iu-h gateway), a recommended approach for allocation
for Cell Id would be from highest to lowest shown in table below:
Services Node Radio Node SAC Cell ID
1 1-100 65401 to 65500 65401 to 65500
2 1-100 65301 to 65400 65301 to 65400
N 1-100 (65501-nx100) to (65501-nx100) to (65600-

(65600-nx100) nx100)
Table 4 – SAC and Cell ID allocations
NB: The current SCW functionality supports the SAC per service node only and the
functionality will be modified to support the SAC per radio node which will be available
in Q4-2012.
7.3.5 Routing Area Code (RAC) / Location Area Code (LAC)

The INC Concentrator, while based in Germany will have a single unique LAC/RAC
and RNC-ID assigned for Vodafone UK. The Geo-Resilience site in Spain will have
different but unique LAC/RAC and RNC-ID.
7.3.6 Cell Name

The Spider Cloud Services Nodes will be allocated a cell name as per other cells on the
network. The format of the cell name will be as follows:
Cell Name = <Identifier><Site ID><Cell instance><Carrier>
Where the <Identifier> allocated to Spider Cloud Services Nodes is V as per the
Enterprise Sure Signal Deployment.
<Site ID> is a 5 digit number assigned to the SCSN location.

114/1009/20132
Page 26 of 80
Technology
<Cell instance> identifies a Radio Node/Cell at a site. This takes the value 00 to 99.
<Carrier> identifies the carrier. Takes the values 1, 2 or 3.
e.g. cell name = V12345003
The cell name will be provided by the Services Node in performance management
counter files and in alarm events from the Services Node.
7.3.7 Handover and cell reselection

The Spider Cloud Small Cell Cluster system will perform in a similar manner to the
Vodafone Sure Signal Femtocells, with the exception that inter Radio Node soft handoff
is supported.
The UK Network does not currently The solution does not support SRNS Relocation,
so Hand-in, Hand-out and inter RAT handover will be similar to that currently delivered
by Vodafone Sure Signal and Open Access Femtocells. In the future Vodafone UK may
support SRNS relocation and the SCW product is enabled to support that feature when
deployed and so in this example the picture showing SRNS Relocation is not needed..
Figure 2 – Macro Handover setup

114/1009/20132
Page 27 of 80
Technology
7.4 Impact on the NMS System
7.4.1 Performance Management

Performance Management (PM) of the Enterprise sites is provided by the ZenPM
(System Mechanics) platform. ZenPM collects performance management counters of
existing vendor’s 3G equipment. KPI formulas are defined from a collection of counters
and allow KPI reporting to take place. A common Enterprise view will be presented for
the SCW Enterprises and the VMS Enterprises.
Figure 3 – Performance Management Overview
The Performance Measurements are collected on each Service Node according to the
3GPP TS 32.401 Performance Management Concepts and Requirements.
PM files are uploaded to a remote PM Server for mediation to the ZenPM platform.
Generation of the PM files is done in XML format in accordance with the 3GPP TS
32.435 XML File Format Definition. The SN “Upload Manager” sends these PM files
every 15 minutes.
The ZenPM platform requests all of the PM files on the PM Mediation Server (from all
UK Service Nodes) when they’re made available. These are then stored in the ZenPM
data base for manipulation into different type of PM reports.
The PM file names are different to avoid successive PM files overwriting existing data
before collection by ZenPM. They are also differentiated between different Service
Nodes to avoid one SN PM file overwriting a file from a different SN. The identification
of the end (reporting) device is defined within the context of each PM file (not by the File
name). The XML file formation definition is discussed in Section 4 of the TS 32.435
document and defined in Performance Measurements for SCW Small-Cell Clusters
document [ref-4].
PM files on the SN are deleted as soon as they have been pushed. A script running on
the Mediation Server will delete all PM files older that 1 week. Data retention on ZenPM
is 6 months of raw data, and 5 years of aggregated daily data.

114/1009/20132
Page 28 of 80
Technology
Transmission of PM files take place within the IPsec tunnel and are routed from the
NSU SEG/W, via Secure Copy Protocol (SCP). To support the PM XML file transfers,
the Mediation Server is configured for SSH and a username and password created for
use by the Services Nodes when transferring the files to the mediation server. This
username & password is entered into the Upload Manager configuration section on the
SN. Once the configuration is saved, the password is obfuscated from view.
The initial commercial launch does not use an integrated NTP Time-synchronisation
across the different SR’s, so the time-stamp of the PM data is set by the individual SN
Time-Of-Day function.
7.4.2 Fault Management

Netcool – The Micromuse NetCool tool is used to capture events and alarms form the
Services Nodes. Each Services Node is a separate object in the Netcool system and
event reporting is via SNMPV3
Alarms are transmitted within the IPsec and form part of the overall traffic through the
SeGW. Alarms are routed from the SeGW to the Netcool via IPBB.
The full lists of alarms for SCW Small-Cell Clusters are outlines in SCW admin guide
System Management [ref-2] section 9.2. The SCW system has capability to disable any
specific alarm if needs which also is details in sec 9.2.3
To enact a “Keep alive” function, NetCool polls each SCSN with a SNMP request. Each
service node will have multiple IP address and this list is maintained within the NetCool
List. The Netcool will check both the IP Address of the Service nodes before making
decision to that service node is down. The frequency of keep alive is yet to be agreed.
SNMP IP information:
Network Element Host Name IP Address Gateway
Spider Cloud Services Node X X x
Vodafone live NMS 1 dukngsdr 172.17.24.12 x
Vodafone live NMS 2 dukngsar 172.17.23.12 x
Table 5 – SNMP IP Information
NMS Firewall rules:
Rule Name Direction Port
SNMP Trap from SN to NMS UDP 162
SNMP Request from NMS to SN UDP 161
Table 6 – NMS F/W Rules

114/1009/20132
Page 29 of 80
Technology
7.4.3 Configuration Management

Cramer
Site Build and Transmission
The recording of transmission for Small Cell Cluster sites is required to be recorded in
Cramer. Most sites shall be Ethernet, but DSL, E1 and other forms of IP Based
transmission shall also be supported.
To build an SCW Site within Cramer the following procedure shall be followed:
 Build Site - Currently done automatically

 Build Transmission - Currently done by Transmission Team (VLAN id assigned
by BT and recorded in Cramer)
 Build Services Node at site - New manual action requires
 Complete transmission to Services Node and Vodafone Routers via BT GigE
link - New manual action requires
 Build Connectivity from NSU (SeGW/Home Node B G/W) Network to Vodafone
Core network - New manual action requires
 Build IPSec termination within to SeGW (hosted in Ratingen and Madrid (on
top of transmission) - New manual action requires
 Allocated IP Address to the Service Node from given range New manual action
requires
 Allocated Service Node name which can be used in the PM files generated from
Service Nodes
 Mark each Cell to be used as Active or Passive. The Active cells need to assign
PSC range to be used.
 Allocates Cell IDs and SAC for the Radio Nodes to the connected Services
Node
 Record Vodafone ID and Femto Serial Number for each Service Node and
Radio Nodes
 Records Radio Power Setting for each Radio Node.
 Add a free text field called “Enterprises LAN Details” to enter the relevant
LAN/Enterprises F/W details.
 Send information to respective team based on Delivery Engine
The Cramer will also have the capabilities to update the existing site in case
 Upgrading a site to have more Radio Nodes

 Remove Services Node cell site excluding transmission
 Upgrading Service and Radio Nodes to a new software releases

114/1009/20132
Page 30 of 80
Technology
Parameters Allocation
A Location Area Code (LAC), Routing Area Code (RAC) and RNCID shall be assigned
to each Home NodeB Gateway.
Cell ID allocation for the Small Cell Cluster shall be mastered from Cramer. Each SCW
cell is controlled by a single Services Node. All SCW cells (Radio Nodes) on each
Services Node shall be assigned a unique Cell ID and SAC within the Services Node.
As with existing 3G cell ID allocation Cell ID’s shall be assigned uniquely from 65500
descending (avoiding 2G allocations). This is to be per LAC.
It is not expected that the Home NodeB gateway will have more than 65500 Radio
Nodes (Cells) so clashes with other cell numbers are not anticipated.
The completed Small Cell Cluster cells shall be available to be viewed as part of the
existing Cell ID RECORD/Cell Centroid interface in the same way as 3G cells.
Each Services Node currently supports a maximum of 75 Radio Nodes, but provisioning
is made to extend this to at least 100 Radio Nodes in Cramer.
The below table will show the sample parameters in single site deployment scenario
RNCID LAC RAC SAC Cell ID

INC 1 2 3
Service Node - - -
Radio Node 1 - - - 65001 65001
Radio Node 2 - - - 65002 65002
Radio Node 3 - - - 65003 65003
Radio Node 4 - - - 65004 65004
Radio Node 5 - - - 65005 65005
…….
Table 7 – Individual SAC per Radio Node
Evenflow
The Evenflow tool will be amended in line with the following
 Enhancements to Cells screen to allow sectors up to 99 for Radio Nodes (The

current SCW product has a capacity for 75 nodes. 99 allows for future proofing)
 Amendments to non Femto sector list to have the range from 0 to 9. (to assist
with integration into Cornerstone)
 A new flag to show whether a femto or Radio Node is active or passive.
 Addition of new BO objects like Femto/Spider cloud status, Serial number under
cells class in Evenflow and Cornerstone BO universe.
Evenflow initiation of Ncell Mapping will use the same mechanism as used for the VMS
cells and no further changes are needed.
Working assumption: The Cramer database entry for the Enterprise site identifies all
Cell Ids, (active and Passive) and records the PSC value assigned for Active cells.

114/1009/20132
Page 31 of 80
Technology
Cell Centroid
Changes required in the Cell Centroid system to ensure that information on SCCs is
correctly provided. The following changes are common to all Cell Centroid interfaces.
 New interface to extract Cell name from Cramer for SCC cells
 Parsing changes to indicate whether SCC
 Generate site details for SCC cells
 Calculate Reserved LAC for SCCs
The following changes are specific to the interface indicated:
101 Feed:
 Process SCC cell information and feed to existing feed

Global Feed

Gov Feed

EDW - Site data Feed

VF-Group Feed

Ofcom Feed
 Include SCC site information to Ofcom interface

TEMS Feed
 Process SCC information and feed to existing feed

114/1009/20132
Page 32 of 80
Technology
7.5 IP Design
The diagram below shows a high level view of the connectivity between HNB G/W and
Vodafone UK network.
NMS F/W
SPE-F/W Common OAM

OAM VPN OAM Nodes
SGSN
backhaul VPN
IuPS IuPS IuPS
Sigtran INC Sigtran Sigtran SGW

Sigtran
IPBB IuCS IuCS MSC

IuCS
SeGW MGW
SPE IPBB VF-UK
Figure 4: IP Connectivity
There will be a dedicated Secure Gateway for VF-UK where IPSec tunnels terminate
from the Spider Cloud Services nodes, and protect the HNB gateway.
The INC node is responsible for managing subscriber access to circuit and packet
mobile services and sits on the control plane of the Iu-CS and Iu-PS interfaces into the
core network. The INC blades each supports multiple sigtran interfaces (currently 2, but
due to be increased), with 5 active blades and 5 standby blades, all control plane traffic
originates on these Sigtran addresses. The data plane traffic is routed using the actual
services node addressing and uses a class C subnet. The INC also supports Iu-flex
allowing connectivity from a single INC to a pool of MSCs and a pool of SGSNs
providing resilient connectivity.
The Sigtran, IuPS and IuCS traffic are carried in shared VPNs (shared between Opcos)
across the IPBB. The sigtran traffic uses the existing VPN used for RoamCo which is
dedicated sigtran signalling, IuPS and IuCS use new VPNs which will be common to all
OpCos using centralised mobile services.
HNB-G/W high availability is achieved through the use of paired appliances (such as the
secure gateways) and chassis based servers utilising redundant cards and power
supplies (such as the INCs).
HNB-G/W site resiliency is achieved by deploying the solution at two geographically

resilient siteslocations, one solution is deployed in an NSU Data Centre in Ratingen
(Germany), with a twin site in Madrid (Spain).
7.5.1 IP Transport
The IPBB carries the traffic to and from the HNB gateway in four different VPNs to
provide segregation for signalling, IuPS, IuCS and OAM.
Traffic VPN Comments

114/1009/20132
Page 33 of 80
Technology
Sigtran RoamCo The RoamCo VPN is full mesh across all

Opcos dedicated to Sigtran Traffic and
publically addressed.
IuPS IU_PS New VPN specifically for Packet switch traffic.

Addressing to be agreed with NSU
IuCS IU_CS New VPN specifically for Circuit switch traffic.

Addressing to be agreed with NSU.
OAM NSU OAM Existing administration Monitoring and

reporting VPN. Full mesh
Table 8 – VPN over IPBB
7.5.2 Sigtran
The INC is connected to the core network via a pair of Signalling Gateway and gives 2
key benefits
 SGw will provide the public sigtran IP address to connect the HNB-G/W. As per
NSU design the plan is to use the existing VPN used for RoamCo which is
dedicated sigtran signalling which will be common to all Opcos using centralised
mobile services. Signalling traffic must be publically addressed at the Opco as
the RoamCo VPN has mandatory public addressing.
 SGw will provide the full resiliency between sigtran red and blue within UK
network.
The figure below shows the high level of Sigtran connectivity between INC and SGw.
INC Super-LAC
Super RAC
RNC ID 1
M3UA mode ASP
Point Code 1 AS 1 Point Code 2 AS 2 Point Code 3 AS 3 Point Code 4 AS 4 Point Code 5 AS 5
ASP ID 3 ASP ID 4 ASP ID 5 ASP ID 6 ASP ID 9 ASP ID 10 ASP ID 11 ASP ID 12 ASP ID 13 ASP ID 14
(Active) (Standby) (Active) (Standby) (Active) (Standby) (Active) (Standby) (Active) (Standby)
Routing Routing Routing Routing Routing Routing Routing Routing Routing Routing
Key 1 key 2 Key 3 Key 4 Key 5 Key 1 key 2 Key 3 Key 4 Key 5
Signalling Gateway 1 Signalling Gateway 2

DPC based routing DPC based routing
MSCs & SGSNs

114/1009/20132
Page 34 of 80
Technology
Figure 5: Sigtran connectivity via SGw
The INC has space for 10 processing/interface blades, with blades paired to form
active/standby pairs as shown in above figure. Each blade can support up to 4 Sigtran
associations, giving a maximum of 20 active associations per INC. A pair of Ethernet
interface cards hosts the physical interfaces to allow traffic in and out.
Each blade has a single IP address with a port per association (four ports per blade pair
for the four associations). The ports can be replicated across blades but must be
unique on the individual blades. Each blade has a standby which is only active if the
primary blade fails, configuration is shared across the active/standby blades. Each
blade pair requires its own point code.
The INC blade pairs are not multi-homed as each blade has it own IP address so to
improve the resiliency each blade will connect to one SGw on Red and the other on
Blue interface.
The INC blade pairs work in ACT/SBY – switchover happens only when hardware fault,
a network related outage affecting the active blade will not cause a failover to the
standby blade.
 ACT blade has SCTP UP and M3UA ACTIVE.
 SBY blade has SCTP UP and M3UA INACTIVE.
7.5.2.1 Iu-Flex
The figure below shows the high level of Iu connectivity between INC and MSCs &
SGSNs The MSCs and SGSNs are connecting to the difference blade of an INC
instance which has difference point code so the configuration on each MSC and SGSN
would be different which is based on the Blade they are connecting. and they need to
defined the different point code for an INC.
Super-LAC
INC Super RAC
RNC ID 1
M3UA mode ASP
Blades 3/4 Blades 5/6 Blades 9/10 Blades 11/12 Blades 13/14
Point Code - 1 Point Code - 2 Point Code - 3 Point Code - 4 Point Code - 5
MSC#1 SGSN#1 MSC#3 SGSN#3 MSC#5 MSC#6 SGSN#6 SGSN#7 SGSN#8 SGSN#9
MSC#2 SGSN#2 MSC#4 SGSN#4 SGSN#5 MSC#7 MSC#8
Figure 6: Iu Connections

114/1009/20132
Page 35 of 80
Technology

114/1009/20132
Page 36 of 80
Technology
Iu-Flex Configuration for CS

The following parameters are required for Iu-Flex configuration. As Iu-Flex is already
operational in the Vodafone UK network for RNCs these parameters are generally those
which must be configured on the INC in order to support Iu-Flex.
Load Balance Mechanism Weighted round robin
Compliance 3GPP TS23.236 v6.3.0
iuflexLaiRaiSelect Femto LAI (value=1)
pagingResponseCorrelationTime (Default)
INC
Number of MSCs in pool 8
MSC Name NRI NRI Length Null NRI Global CN-ID Non- Pointcode
broadcast
LAI/RAI
Blackwater 34,35,36 7 0 123 277 2-4021
Beult 26,27,28,29,30 7 0 126 272 2-4005
Colne 3,4,5 7 0 120 270 2-4000
Croal 31,32,33 7 0 139 274 2-4019
Hamble 90,91,92 7 0 140 275 2-4012
Ouse 11,12,13,14,15 7 0 124 273 2-4003
Pang 95,96,97,98,99 7 0 130 276 2-4011
Regent 16,17,18,19,20 7 0 122 271 2-4002
Table 9 – Iu-Flex CS configuration
Iu-Flex Configuration for PS

The following parameters are required for Iu-Flex configuration, as agreed between INC
and SGSN.
Load Balance Mechanism Weighted round robin
Compliance 3GPP TS23.236 v6.3.0
iuflexLaiRaiSelect Femto LAI/RAI (off)
pagingResponseCorrelationTime 1000
INC
Number of SGSNs in pool 9
SGSN NRI NRI Length Null NRI Global CN-ID Non- Non- Pointcode
Name broadcast broadcast
RAC LAC
SGSNGR4 23 5 4 234152623 95 95 2-2623

114/1009/20132
Page 37 of 80
Technology
SGSNOM4 24 5 4 234152624 94 94 2-2624
SGSNRM4 25 5 4 234152625 96 96 2-2625
SGSNCY4 20 5 4 234152620 31 31 2-2620
SGSNEH4 21 5 4 234152621 105 105 2-2621
SGSNER4 22 5 4 234152622 26 26 2-2622
SGSNKS4 02 5 4 234152602 35 35 2-2602
SGSNSN4 26 5 4 234152626 108 108 2-2626
SGSNSY4 27 5 4 234152627 33 33 2-2627
Table 10 – Iu-Flex PS configurations
7.5.3 IuPS and IuCS

Whilst the control plane traffic will all appear to come from the INC sigtran interfaces,
the user plane traffic is routed direct from the services node addresses. In practice this
means that the SGSN and MGW must be able to route traffic back to the entire services
node address ranges allocated to the Vodafone UK.
Media Gateway
Since both the Iu interface and the core network is IP based there is no need to select
any specific MGWs for bearer conversion anymore and it is not mandatory to assign an
MGG to the RNC routes. In general approach Generally the MGWs are prioritize to located
in the same site as the RNC but here in this case thethe IuCS traffic is coming all the way from
Ratingen or Madrid so there is no plan need to prioritise any MGW hence call can be connected
through any MGW.
7.5.4 OAM
The OAM traffic such as alarm and performance/fault management files are directly
routed by NSU to the Vodafone UK network. The NSU HLD Section 7.6 O&M [ref-1]
outline these in more detail
7.5.5 Geo-Resiliency
The Home Node B gateway is selected by the Spider Cloud services node itself, the
services node is pre configured with the details of the SeGW of both HNB-GWs, and will
choose the pre-configured geographically closest HNB-GE as the primary choice. If a
configurable number of connection attempts to the primary fail, then a connection is
made to the secondary HNB-GW. There are definite performance benefits in using the
closest HNB-GW and it must used under all normal circumstances.
If the primary HNB-GW is unavailable and the services node connects to the secondary
HNB-GW there are no automated attempts to connect to the primary again unless the
secondary one fails. A manual process is needed to re-home the services nodes on the
primary HNB-GW.

114/1009/20132
Page 38 of 80
Technology
Both HNB-GWs have replicated deployments consisting of SeGWs, LBRs and INCs.
The services nodes request an internal tunnel address from the HNB Gateway at the
point of connection, the twoBoth HNB-GW allocate addresses from separate subnets
with the effect that the traffic address a service node uses (and therefore the address
used towards the Opco for IuPS, IuCS, and OAM traffic) will vary depending on the
HNB gateway used. The address used at each HNB-GW by each service node is
consistent allowing the Opco to map a pair of specific IPs to a specific customer site.
Both sites HNB-GW have active and standby sigtran associations from the INC to the
core network, again with each HNB gateway site having a separate Sigtran subnet. The
only difference between the two sitesHNB-GW being that the standby site will not be
sending any signalling traffic over the active associations.
Failovers are decided by the individual service nodes, if connection loss is detected
then the service node will first try to reconnect to the primary HNB gateway. If the
reconnection fails then it will try to connect to the standby siteHNB-GW. A failover will
involve complete loss of service to the customer site covered by the service node
performing the failover, and is expected to take a few minutes to recover. The services
nodes automatically shut the local RAN network down when connection to the core
network is lost, the RAN is brought back up again on connection recovery. All devices in
the RAN coverage will re-register on the core network when the RAN is enabled.
7.6 Enterprise LAN & Security
7.6.1 Enterprise Cabling

Radio Node installation will typically be installed by 3rd party organizations/
subcontractors or the Enterprise IT department themselves. The deployment
requirements are identical to those for Enterprise Wi-Fi access points.
This cabling shall be Cat 5/5e or better unshielded twisted pair, built to standard IEEE
802.3at specifications, with a maximum length restriction of 100 meters (328 feet)
between SN and RN. This restriction minimizes power loss between the PoE+ power
source and the Radio Node.
7.6.2 Radio Node Mains Power

Each Radio Node uses a single Ethernet cable for IP communications and power.
Specifically, the Radio Nodes use IEEE 802.3at Power over Ethernet Plus (PoE+).
Each mid-span injector takes an input of Ethernet from the switch, injects power from a
240V AC power supply, and outputs PoE+ over an Ethernet cable. This cable would
then be patched to each of the Radio Nodes.
PoE+ switches are available to be used during installations however, due to the
physical topology of the deployments, in some scenarios, such as where a particular
floor needs only one or two Radio Nodes, PoE+ switches are not a cost effective option.
The choice for the use of PoE+ switches or Power Injectors will be made by Vodafone
Approved installation contractor on a site to site basis.
7.6.3 Provision of a VLAN for the Small Cell Cluster

It is expected that Enterprise IT will request separation of the Small Cell Cluster traffic
from the rest of the network by using Layer 2 VLAN’s running over their current
switched gigabit Ethernet infrastructure.

114/1009/20132
Page 39 of 80
Technology
A SpiderCloud Wireless solution provided by Vodafone would typically use logically

separated Layer 2 VLANs running on existing Enterprise IT infrastructure in a manner
similar to that used for current enterprise Wi-Fi deployments.
Responsibility for the maintenance of the L2/3 remains with the Enterprise IT manager
when common Enterprise infrastructure is used.
7.6.4 Enterprise Firewall Ports

For deployments on shared IP infrastructure a Firewall may exist between the Services
Node and Radio Nodes. If this is the case then certain IP port numbers must be
opened in the firewall to allow the Radio Nodes to communicate with the Services Node.
The Deployment Guide [ref-2]and IT Administrator Guide [ref-3] outline these in detail.
7.6.5 DHCP
When Radio Nodes boot up, they look for the IP address of their parent Services Node
through DHCP. These are defined as DHCP vendor extensions as seen in the
Deployment Guide.
The Services Node can provide its own DHCP services, where the MAC address of
each Radio Node is listed and assigned an IP address, as well as defining the boot up
Services Node’s IP address. Use of the Enterprise’s DHCP server is also supported.
7.6.6 Enterprise Rack Space & Power

A Spider Cloud Services Node and backhaul terminating CPE are required to be placed
into a secure IT room on the enterprise premises. For the purposes of the first
deployments, equipment will be placed inside a locked cabinet, with Vodafone holding
the keys for security. The locked cabinet would be able to be powered off or disconnect
from the Enterprise LAN by the IT Manager.
The Spider Cloud Services Node is a 1 RU piece of equipment for a 19” rack.
7.6.7 UPS
The Services Node can optionally be installed on a UPS if required. It should be noted
that if the Services Node lose power or connectivity to the Vodafone UK core network
that all Radio Nodes would stop transmitting to eliminate the risk of coverage holes. The
default configuration does not include UPS.
7.7 Backup/Restoration
The spider cloud system configuration consists of a combination of system parameters
that are set during the commissioning phase by the administrator (e.g. IP interfaces,
HNB gateway address, etc) and a set of system parameters that are automatically
selected or learned by the system based on self-optimizing algorithms (e.g. PSCs, Tx
power, neighbour lists).
The administrator can perform two types of backups:
1 - Backup the system configuration (CLI> save config). The configured parameters are
saved into an ASCII file in the SN.
2 - Backup the entire SN database (CLI>request system database backup). This

creates a backup file of the database that includes all the configured and “learned”
parameters. It includes parameters that have been auto-assigned or optimized during
topology scans, UE measurements etc).

114/1009/20132
Page 40 of 80
Technology
The current Spider Cloud (release 2.0) SN database backups can be performed from
the CLI only and cannot be scheduled to run periodically.
The PM mediationFS server will store the backup for each Enterprise configurations.
The user will run the above backup command after logging to the system via BASNAC
and place the back files on the Mediation FS server using SCP file transfer command.
The restoration of Enterprise configuration data will be initiated via SO through CLI,
according to agreed SLA.
PS: NSU Backup/Restore details are to be covered in NSU HLD
7.8 BASNAC – Remote Access

BASNAC will be used for remote access to CLI based terminals to all the services
nodes.
Connectivity to the individual SCSNs O&M management functions is provided via the
IPsec tunnel and VF side of the SeGW.
Remote access to the Services node is provided via the IPSec tunnel. Service
Operations will have access to the Services Node via the CLI using secure access
methods such as SSH, SCP and SNMP.
Accounts are required to be created on BASNAC for anyone who requires remote
access, for support and temporarily customer management.
7.9 Lawful Intercept

As both Circuit Switched and Packet Switched sessions are terminated at MSC/MGWs
and SGSNs within the Vodafone UK core, Lawful Intercept warrants are implemented
as they are for existing Macro Cell Node B’s.

114/1009/20132
Page 41 of 80
Technology
8 Dynamic Design
The dynamic design for the SCW system covers the following areas:
 Cell Reselection
 Voice Handover
 Packet Switched Handover
8.1 Cell Reselection
8.1.1 User moves from 3G Macro Network to SCW Network

Description
A subscriber is in idle mode on the 3G macro network and enters the coverage zone of
a SCW network.
Pre Conditions
1. User is in idle mode on the 3G network
2. Macro network is provisioned with appropriate neighbour cell information for SCW
cell.
Post Conditions
1. User is in idle mode on the SCW
2. The user is registered with the LA/RA of the SCW cell.
Detail
The LAI must be different between the 3G macro cell and the SCW cell in order to
trigger the procedures, when the UE moves from the 3G macro cell to the SCW cell.
The procedure is shown below.
1. A 3G UE in idle mode moves from 3G Macro area to SCW area. The SCW cell uses
the same PLMN-Id as the 3G macro network.
2. UE performs Idle mode measurements to decide whether to reselect to the SCW

network. The UE will perform the cell reselection and will reselect the SCW cell
when it detects that the SCW cell becomes more suitable than the macro cell.
Reselection parameters of the macro cell should be set such that the UE camping in
the macro cell searches for a SCW cell and re-selects the SCW cell as soon as it
enters into the SCW coverage area independent of the quality of the macro cell.
This is achieved using a high value of Sintersearch in the SIB3 to start
measurements early, and a low value of Qoffset1/2 for the SCW neighbour cells in
the SIB11 of the macro cell to make the UE prefer the SCW cell. Qqualmin and
Qrxlevmin broadcast for the SCW neighbour cells in SIB 11 of the macro cell
determines the quality/receive level when cell reselection to the SCW cell is actually
performed, i.e. the UE reselects the SCW cell as soon as the cell selection criterion
is fulfilled with the given Qoffset1/2 values. To ensure the UE stays on the SCW
cell, a low value of Sintersearch in the SIB 3 and Qoffset1/2 = 0 for the macro
neighbour cell in the SIB11 of the SCW cell should be used.
3. The UE establishes the RRC connection with the SCW network.

114/1009/20132
Page 42 of 80
Technology
4. When moving from a macro cell to the SCW cell, the UE crosses a LAC boundary.
After performing cell reselection, the UE will read the SIB and know that the LAC
has changed which triggers a Location Update on the SCW cell.The UE sends a
Location Updating Request message which triggers the SCW network to perform
access control.
5. The SCW performs the Identification procedure with the UE in order to get the
user’s IMSI. The SCW forwards the NAS message to the CN (MSC or SGSN) in a
RANAP Initial UE Message.
6. The NAS procedure is performed normally either between the UE and the SGSN for
a PS connection or between the UE and the MSC for a CS connection. From a core
network perspective the procedures are identical to cell re-selection between two
macro network cells in different location areas. If the core network sends a
MM/GMM Information message, the SCW intercepts the message and replaces the
received Full and/or Short Network Name with the names provisioned in the SCW.
Since MM Information messages will not be sent by the VF core network, and the
sending of GMM Information messages is not reliable, the network names
configured in the SCW must be the same as sent by the core network, ie. the
names should not be changed by the SCW network.
7. When the CN releases the IuCS and IuPS connection, the SCW releases the RRC
connection.
8.1.2 User moves from 2G Macro Network to SCW Network

Description
A subscriber is in idle mode on the 2G macro network and enters the coverage zone of
a SCW network.
Pre Conditions
1. User is in idle mode on the 2G network
cell.
Post Conditions
1. User is in idle mode on the SCW network
2. The user is registered with the LA/RA of the SCW cell.
Detail
The LAI must be different between the 2G macro cell and the SCW cell in order to
trigger the procedures, when the UE moves from the 2G macro cell to the SCW cell.
1. A 2G/3G UE in idle mode moves from 2G Macro area to SCW area. The SCW cell
uses the same PLMN-Id as the 2G macro network.
2. UE performs idle mode measurements to decide whether to reselect to the SCW

network. The UE will perform IRAT measurements on the SCW cell for cell
reselection. The UE will reselect the SCW cell when the UE detects that the SCW
cell fulfils the 2G to 3G re-selection criteria for 5 sec. Reselection parameters of the
2G macro network should be set such that the UE camping in the 2G macro cell
searches for a SCW cell and re-selects the SCW cell as soon as it enters into the

114/1009/20132
Page 43 of 80
Technology
SCW coverage area independent of the quality of the 2G macro cell. This is
achieved by setting the GSM parameter values Qsearch_I/Qsearch_P to ‘search
always’ and favouring the SCW cell using very low FDDQoffset value (minus
infinite). The SCW cell shall fulfill a minimum quality and receive level before the UE
enters the SCW cell. The GSM network shall set the corresponding parameter
values for FDD_Qmin (e.g. -12 dB) and RSCP_min (e.g.-100 dBm) as appropriate.
The rest of the procedure is the same as steps 3-7 for the cell reselection from 3G
macro to SCW (see section 8.1.1)
8.1.3 User moves from SCW Network to 3G Macro Network

Description
A subscriber is in idle mode on a SCW and moves into stronger radio coverage of a 3G
macro network cell which triggers cell reselection from the SCW network to the 3G
macro network.
Pre Conditions
1. User is in idle mode on a SCW
cell.
Post Conditions
1. User is in idle mode on the 3G macro network
2. The user is registered with the LA/RA of the 3G macro cell.
Detail
1. A 3G UE in idle mode moves from SCW area to 3G macro area. The SCW CPE
2. The UE performs Idle mode measurements to decide whether to reselect to the

Macro cell. In doing so if the UE is coming from a SCW cell the UE is crossing a
LAC boundary. The UE will perform the cell reselection and will reselect the Macro
cell when the UE detects that it becomes a more suitable cell than the SCW cell.
Reselection parameters of the SCW cell should be set such that the UE camping in
the SCW cell delays searching for a 3G macro cell as long as possible and only re-
selects the 3G Macro cell on leaving SCW coverage area. This is achieved using a
low value of sInterSearch in the SIB3, to start measurements late, and Qoffset1/2=0
for the 3G Macro neighbour cells in the SIB11 of the SCW cell, to make the UE
remain the SCW cell until the Macro cell becomes better by Qhyst1/2 than the
serving SCW cell. The same Qqualmin and Qrxlevmin values are used for serving
cell and Macro neighbouring cells. To ensure the UE does not reselect the SCW cell
in the Macro cell again, the cell reselection criterion Qqualmin and Qrxlevmin of the
SCW cell broadcast in the macro cell are lower than the triggers for measuring the
macro cells in the SCW. Also a high value of Sintersearch in the SIB 3 and a high
negative value of Qoffset1/2 for the SCW neighbour cell in the SIB11 of the 3G
Macro cell should be used.
3. The UE establishes the RRC connection with the 3G RNC.

114/1009/20132
Page 44 of 80
Technology
4. When moving from the SCW cell to the 3G macro cell, the UE crosses a LAC
boundary. After performing cell reselection, the UE will read the SIB and know that
the LAC has changed which triggers a Location Update on the 3G macro cell. The
NAS procedure is performed normally either between the UE and the SGSN for a
PS connection or between the UE and the MSC for a CS connection. From a core
network perspective the procedures are identical to cell re-selection between two
macro network cells in different location areas.
5. When the CN releases the IuCS and IuPS connection, the 3G RNC releases the
RRC connection.
8.1.4 User moves from SCW Network to 2G Macro Network

Description
A subscriber is in idle mode on a SCW and moves into stronger radio coverage of a 2G
macro network cell which triggers cell reselection from the SCW to the 2G macro
network.
Pre Conditions
1. User is in idle mode on a SCW
cell.
Post Conditions
1. User is in idle mode on the 2G macro network
2. The user is registered with the LA/RA of the 2G macro cell.
Detail
1. A 3G/2G UE in idle mode moves from SCW area to 2G macro area. The SCW CPE
2. UE performs Idle mode measurements to decide whether to reselect to the Macro

cell. In doing so if the UE is coming from a SCW cell the UE is crossing a LAC or
RAC boundary. The UE will perform IRAT measurement for cell reselection and will
reselect the Macro cell when the UE detects that it becomes a more suitable cell
than the SCW cell. Reselection parameters of the SCW cell should be set such that
the UE camping in the SCW cell delays searching for a 2G macro cell as long as
possible and only re-selects the 2G Macro cell on leaving SCW coverage area,
independent of the quality of the 2G macro cell.This is achieved using a low value of
SsearchRAT in the SIB3, to start measurements late and a high Qoffset for the 2G
Macro neighbour cells in the SIB11 of the SCW cell, to make the UE remain on the
SCW cell. Qrxlevmin broadcast for the 2G Macro neighbour cells in SIB 11 of the
SCW cell determines the minimum receive level when a 2G Macro cell is suitable
for cell reselection. When the quality of the SCW cell drops below the sum of the
parameter values Qqualmin (for SCW cell) and SearchRAT the UE will start
measuring 2G neighbour cells. If a 2G neighbour cell is suitable and the measured
receive level of the 2G neighbour cells(RSSI) minus Qoffset is higher than the sum
of the measured CPICH RSCP and the parameter value Qhyst1 of the SCW cell for
the time Treselection , the UE will re-select to the 2G macro neighbour cell.
3. The UE establishes the RRC connection with the 2G BSC.

114/1009/20132
Page 45 of 80
Technology
4. When moving from theSCW cell to the 2G macro cell, the UE crosses a LAC
boundary.After performing cell reselection, the UE will read the 2G system
information and know that the LAC has changed which triggers a Location Update
on the 2G macro cell. The NAS procedure is performed normally either between the
UE and the SGSN for a PS connection or between the UE and the MSC for a CS
connection. From a core network perspective the procedures are identical to cell re-
selection between two macro network cells in different location areas.
5. When the CN releases the signaling connection, the 2G BSC releases the RRC
connection.
8.1.5 User moves from No Macro Network to SCW Network

Description
User has no macro network coverage and enters the coverage zone of a SCW that they
are allowed to use, which causes cell selection to the SCW
Pre Conditions
1. The user equipment is on and searching for a cell to camp on
2. User’s location has at most to be solely covered by SCW cell
3. User has no macro network coverage
Post Conditions
1. User is in idle mode on the SCW
2. The user is registered with the LA/RA of the SCW.
Detail
The LAI must be different between the 2G/3G macro cell that the UE was last registered
on and the SCW cell in order to trigger the procedures, when the UE moves into the
coverage of the SCW cell.
1. A 3G UE in Idle mode moves into SCW area.
2. 3G UE performs Idle mode measurements to decide whether to select the SCW

network. The UE will perform inter-frequency measurement for cell selection and it
will select the SCW cell when the UE detects that the SCW cell is suitable. To
ensure the UE stays on the SCW cell, a low value of Sintersearch in the SIB 3 and
a low negative value of Qoffset1/2 for the macro neighbour cell in the SIB11 of the
SCW cell should be used.
The rest of the procedure is the same as steps 3-7, for the cell reselection from 3G
macro to SCW (see section 8.1.1).
8.1.6 User moves from SCW Network to No Macro Network

Description
User is in idle mode on the SCW and moves out of SCW coverage to a location that has
no macro coverage.
Pre Conditions
1. User’s location has at most to be solely covered by SCW cell

114/1009/20132
Page 46 of 80
Technology
Post Conditions
1. User has no coverage
Detail
1. A 3G UE in idle mode moves from SCW area to an area where there is no SCW or
macro network coverage.
2. Any existing Iu and RRC connectivity is released.
8.1.7 User moves from SCW cell to SCW neighbour cell

Description
A subscriber is in idle mode on the SCW network and enters a stronger coverage zone
of a neighbouring SCW cell.
Pre Conditions
1. User is in idle mode on SCW network
2. SCW network is provisioned with appropriate neighbour cell information for SCW
cells.
Post Conditions
1. User is in idle mode on the SCW neighbour cell.
Detail
1. A UE in idle mode moves from SCW cell to neighbour SCW cell.
2. S criteria (SIB3) Squal AND Srxlev will drop below zero
3. UE performs Idle mode measurements to decide whether to reselect to the

neighbouring SCW cell. The UE will perform intra-frequency measurement for
cell reselection and will reselect the SCW neighbouring cell when it detects that
the SCW cell becomes more suitable than the serving SCW cell. To ensure the
UE stays on the SCW cells, a low value of Sintersearch in the SIB 3 and
Qoffset1/2 = 0 for the macro neighbour cell in the SIB11 of the SCW cell should
be used. In some cases additional preference for SCW is required Reselection
parameters of the internal cells can be set such that the UE camping in the SCW
network has a small preference to stick to the SCW network.

114/1009/20132
Page 47 of 80
Technology
8.1.8 User moves from SCW to LTE (4G) Network

Description
Re-selection from SCW to LTE (4G) serving cell, when enabled, allows an LTE (4G)
capable UE to perform cell reselection from SCW (WCDMA) to LTE.
The LTE (4G) frequencies and parameters for cell re-selection are broadcast on the
System Information Block type 19 (SIB19) broadcast channel of a 3G cell.
Cell reselection to LTE (4G) is supported by E-UTRAN capable UEs in Idle Mode or in
Cell_PCH.
The version of the software 2.0.5.39 of the SpiderCloud Wireless Release 2.0.5 ,
introduces the ability to configure a set of parameters for inter-RAT reselection to a LTE
(4G) cell.
Pre Conditions
1. User is in LTE (4G) Network and it makes or receives a voice call.
2. There is no Macro coverage (F1 or F2), only SCW cells.
3. SCW is configured with appropriate set of parameters for inter-RAT reselection

to a LTE (4G) cell.
Post Conditions
1. User CS Fall Back to SCW network.
2. User is in Idle Mode or Cell PCH.
Detail
1. A UE in idle mode moves from SCW cell to LTE (4G) Network.
2. Inter-RAT cell Reselection to a higher priority LTE frequency is performed by the

UE in WCDMA when the measured LTE cell RSRP is greater than
qRxLevMin+threshHigh during treSelection seconds.
3. Since no explicit neighbour list containing LTE cell information (physical cell
identities) is provided to the UE, LTE frequency information is used in order to
perform W2L cell reselection. The LTE frequency information is broadcast to the
UE in SIB19.
An LTE capable Rel-8 UE in WCDMA shall always perform measurements on
LTE frequencies with higher priority than the serving WCDMA cell. 3GPP
specifies two different measurement intensities for detecting LTE cells on the
configured LTE frequencies.
8.2 Voice Handover
8.2.1 Voice call in progress on 3G Macro Network, user moves to SCW Network
Description
User is in dedicated mode on the 3G macro network and moves into stronger radio
coverage of a SCW which causes a handover to the SCW.

114/1009/20132
Page 48 of 80
Technology
Detail
This scenario is not supported by the Vodafone UK implementation as SRNS relocation
is required on the core network and is not currently activated. The business case for the
project does not allow for activation of the feature.
8.2.2 Voice call in progress on 2G Macro Network, user moves to SCW Network
Description
User is in dedicated mode on the 2G macro network and moves into stronger radio
coverage of a SCW which causes a handover to the SCW.
Detail
The Vodafone UK doesn’t support the 2G to 3G voice handover hence this scenario is
not supported .The business case for the project does not allow for activation of the
feature.
8.2.3 Voice call in progress on SCW Network, user moves to 3G Macro Network
Description
Voice call in progress on SCW, handover to 3G Macro Network.
Detail
This scenario is not supported by the Vodafone UK implementation as SRNS relocation
is required on the core network and is not currently activated. The business case for the
project does not allow for activation of the feature.
8.2.4 Voice call in progress on SCW Network, user moves to 2G Macro Network
Description
Voice call in progress on SCW, handover to 2G Macro Network.
Pre Conditions
1. User’s location has to be additionally covered by a 2G macro cell.
2. Handover to GSM macro network is applicable on the SCW, ie. ensure parameter
settings on the SCW, that handover to 2G macro network is applicable on the SCW
(HO threshold parameter settings, 2G macro cell covering the SCW area is
available as target cell on the SCW, etc). Due to the scenarios supported by the
SCW solution the SCW CPE needs to be provisioned with preferences or mandates
to control the handover target as “GSM Only”
3. User is in dedicated mode on a SCW
4. On the SCW a 2G target cell is available for HO to macro network.
Post Conditions
1. User is in dedicated mode on the 2G macro network
Detail
1. User establishes a dedicated CS connection on the SCW
2. The SCW sets up measurement 2d/2F (quality of the active set on the used
frequency is below/above certain threshold) on the UE.
3. User moves out of SCW coverage area.
4. UE sends measurement report 2d to the SCW

114/1009/20132
Page 49 of 80
Technology
5. SCW decides whether handover to 2G is possible. This is true if a 2G Macro cell is

available for handover.
6. SCW triggers relocation preparation towards 3G-MSC (RANAP: Relocation
required).
7. On receipt of RANAP: Relocation Command from 3G CN the SCW sends handover
command from UTRAN including GSM HO command towards the UE.
8. The UE sends handover complete to GSM Base station controller.
9. On receipt of RANAP: Iu release command from 3G-MSC the resources of the
dedicated connection are deleted on the SCW network and SCW sends RANAP: Iu
release complete to the 3G-MSC.
User has a dedicated CS connection within the 2G macro network.
8.2.5 Voice call in progress on SCW Network, user moves to no macro network
Description
Due to unavailability of macro network, call is dropped when user leaves SCW
coverage.
Pre Conditions
1. User’s location is not covered by a 2G macro cell.
2. User is in dedicated mode on a SCW
Post Conditions
1. Call is dropped
Detail
1. User is making a call in the SCW coverage zone.
2. User is leaving the SCW coverage zone with ongoing call.
3. SCW is detecting radio link failure and releases call:
4. SCW looses synchronisation at the physical layer, and starts a timer (RL Failure
timer, default 3s, plus a re-establishment timer) to allow for re-establishment of the
connection. When the UE detects radio link failure, after T313 expiry it will attempt
Cell Update procedure for period T314. Default values of T313 and T314 as
broadcast by SCW are 3s and 0s.
5. When the SCW re-establishment timer T314 expires radio resources are released
and the Iu Release procedure is initiated towards the MSC. Cause value “Radio
Connection with UE lost” is used.
8.3 Packet Switched Handover

Packet Switched handover from SCW to Macro network and vice versa will follow the
following process for all scenarios:
1. UE decides to reselect another cell (due to moving into or out of SCW coverage)
2. Current radio connection is torn down but PDP context is maintained in the UE and
SGSN. This means that the PDP context remains active but payload is not
transferred while the handover is being performed.
3. UE performs idle mode reselection of new cell (see section 8.1 for details of
process).

114/1009/20132
Page 50 of 80
Technology
4. New cell has different routing area to old cell (all SCW cells use RAC=255 which is
not used by any Macro cells) so Routing Area Update procedure is performed.
5. PDP context is re-established on the SGSN to which the new cell is connected.
The different scenarios will not all be detailed here, as they are essentially the same,
but one example is detailed in section 8.3.1
8.3.1 Data session in progress on SCW Network, user moves to 2G Macro network
Description
A subscriber is in a dedicated PS call on the SCW cell. The subscriber leaves the SCW
cell and enters 2G Macro network coverage.
Pre Conditions
1. User location is covered by SCW cell and 2G Macro cell.
2. User has a PS data session active on the SCW
Post Conditions
1. Users location is not covered by SCW cell
2. User has a PS data session active on the 2G Macro cell
Detail
If the user leaves the coverage area of the SCW, the PS data session drops but both
the SGSN and UE preserve the PDP context. The UE will reselect to a 2G Macro cell,
and will perform the routing area update procedure because the cell will have a different
routing area to the Macro cell. The PDP and MM contexts of the UE are transferred
from the old SGSN, to which the SCW is connected, to the new SGSN, to which the
Macro cell BSC is connected.
1. The UE loses the connection with the SCW CPE

2. The SCW CPE triggers release of Iu connection
3. When the Iu release command is received from the SGSN, the SCW releases the
resources towards the UE.
4. The UE will enter idle mode and perform a cell re-selection to a 2G Macro cell.
5. The UE detects that the routing area on the Macro cell is different than the routing
area on the SCW cell, and sends a routing area update request to the new SGSN.
6. The new SGSN contacts the old SGSN to get information about the UE’s SRNS
context (MM Context, PDP Contexts).
7. The old SGSN provides the SRNS context information in the SGSN context
response message (including PDP context).
8. The new SGSN updates the PDP context on the GGSN (PDP context is now on
new SGSN).
9. The HLR is informed about the new GPRS location of the UE. HLR sends
subscriber data to the new SGSN.
10. The new SGSN accepts the routing area update procedure. The UE, after sending
routing area update complete to the SGSN, performs a service request via SCW
cell towards the new SGSN.
11. The PS data session is re-established on the Macro network.

114/1009/20132
Page 51 of 80
Technology
9 Entity Summary
9.1 SC Radio Node
UMTS Circuit Switched (CS) and Packet Switched (PS) will be provided using a single
UMTS channel, nominally the existing 3rd Carrier (10687) which is mainly used for
Consumer/Enterprise Femtocells and some limited macro deployments.
SpiderCloud Radio Node (SCRN) – The SCRN, or Radio Node, is the active Radio
element of the system. Multiple Radio Nodes are deployed on the Enterprise site and
are deployed in a manner similar to WiFi Access Points. They are powered over
Ethernet and communicate with the SCSN using IP over Ethernet. All traffic from the
SCRN’s to the SCSN is encrypted.
The frequency of deployment for the SpiderCloud system is proposed to be 10687, also
referred to as the 3rd carrier or Femto carrier.
The Services Node, during RF optimisation, will adjust the output power of Radio Nodes
so that seamless coverage within the building is achieved with minimal overlap and thus
reducing interference impact to the surrounding macro network. The maximum transmit
power of any Radio Node will not exceed default maximum of 100mW.
9.2 SC Services Node

SpiderCloud Services Node (SCSN) – The SCSN, or Services Node (sometimes
referred to as a “controller”), is a single rack unit IP devices that is installed in the
comms room of an Enterpirse customer. The SCSN is responsible for managing all of
the Radio Nodes as well as terminating the core connection back to Vodafone. The
SCSN also performs other tasks such as radio optimisation, performance and alarm
aggregation, IP routing, Iu-h, security and policy enforcement.

114/1009/20132
Page 52 of 80
Technology
9.3 NSU (HNB-GW from NEC)
9.3.1 Security Gateway

The Security Gateway is a GenBand S2, which provides two functions, the firewall
functionality prevents any unauthorised traffic from reaching the HNB gateway, and the
IPSec functionality provides secure transport between the HNB gateway and the
Services nodes. It is designed specifically for deployment of Femto cell solutions. The
initial deployment uses a 2 slot chassis, in the event of service growth requiring more
capacity a larger chassis can be substituted to allow more scalability.
There will be a dedicated Secure Gateway pair for VF-UK to provide the necessary
capacity and separation of traffic from other OpCos. Only one Security Gateway is
active at a time, with the standby node only carrying traffic if the active firewall fails
9.3.2 INC (Iu-Concentrator)

The INC is the “brain” of the HNB Gateway, it handles the control plane and provides
sigtran interfaces towards the core network. It is chassis based with redundant power
supplies and cards for both processing traffic and switching traffic in/out of the chassis.
 It provides a transparent transfer of the 3GPP standards Non Access Stratum

(NAS) protocols between the SCSN and the Core Network Mobile Switching
Centre (MSC) and Core Network SGSN. It provides relay of layer 3 NAS
messages from each UE to the Core Network.
 It supports Generic Access Network (GAN) discovery and default INC/UNC
assignment based on the evolved 3GPP TS 43.318 procedures.
 It provides management of the RAN GW bearer paths for Circuit Switched and
Packet Switched services between the SCSN (and each UE camped on the
SCSN) and the INC/UNC.
 It supports RAN GW registration and possible redirection to another serving
INC based on the evolved 3GPP TS 43.318 procedures. It provides UMTS
transaction layer support for services such as paging and handover.
 It provides soft-switch functionality for the control of Circuit Switched media,
interfacing with the MGW via H.248 interface. It provides MGW and Circuit
Switched/Packet Switched bearer path management.
 It interfaces with the MNO Core Network SIGTRAN.
 It interfaces with the Core Network SGSN over the 3GPP standard Iu-PS
interface, for the signalling control of Packet Switched services. Iu-PS uses IP
for the transport of signalling messages.
 It provides Up session management to every attached SCSN and UE (UE
management is by SCSN proxy). It provides separate contexts maintained for
each SCSN and UE served.
 It provides RAN GW registration and authorization services for each SCSN and
UE.
 It provides Iu-CS/PS Control Plane services for up to 17 Iu interfaces per INC
chassis
The INC supports use of Super Location Area and Super Routing Area. The INC will
map all HNBs to the same Super Location Code (S-LAC) and Super Routing Area Code
(S-RAC) for presentation to the MSC.

114/1009/20132
Page 53 of 80
Technology
Each INC is given a unique RNC ID, with unique Super LAC and unique Super RAC
where a second INC is needed for capacity reasons the second INC can either have the
same RNC ID, or a new unique ID. S-LAC and S-RAC are always unique to each INC
but for VF-UK a separate RNC-ID will be allocated when second INC is needed.
There will be a dedicated INC chassis for VF-UK to provide sufficient capacity and
separation of traffic from other OpCos.
9.3.3 Load Balancer

The load balancers are required to distribute the control plane traffic across the multiple
blades in the INC chassis. Cisco 7604 chassis are used with load balancing cards. Each
chassis has redundant power supplies, supervisor cards and Ethernet line cards, with
full resilience being provided by using two identical chassis. The load balancing
capability is shared across all Opco INCs using vlan separation to keep traffic
segregated.
It provides the following features and benefits:
 Virtualization of the IP address of the processing hardware in the chassis,

minimizing the number of IP addresses
 Load sharing (LSNAT) support for Up’ Session TCP/IP connections across all
the available Access-Core Network-Service modules
 IP Routing functions between the INC chassis and the Security Gateways, and
Signalling Gateways
 Additional IP filtering capabilities to protect the INC from network-based attacks
 Redundant operation in the IP transport infrastructure between the elements of
the INC to ensure non-stop communications
9.3.4 OAM Switch

The management connectivity is aggregated using two Cisco 3560 switches.
Connectivity to the hosting data centre for OAM is reduced to a pair of Ethernet ports
instead of multiple management ports from each individual element in the HNB gateway
solution.
9.3.5 NMS
NMS functionality is provided by a dedicated NEC deployed solution which collates
alarms from the HNB gateway infrastructure, and provides performance statistics.
9.4 UK Core Network
9.4.1 Signalling Gateway (SGW)

There is no functional changes requires in the SGW functionality. The routing
configuration to route the signalling messages to MSCs and SGSNs are already exist so
no changes would be required for this but some configuration changes would will be
required to connect the INC to the SGWs and route of siganllaingsignalling messages
back to the INC.

114/1009/20132
Page 54 of 80
Technology
9.4.2 MSC
There is no functional changes requires in the MSC functionality. MSC configuration is
required for implementation of IuCS over IP and Iu-Flex as described in section 7.5.2.
The configuration is not detailed in this document; scripts will need to be created by
Switching Support, with help from Switching Design if required
Note: The DTs will be created by RECORD for the new active cell definitions for new
enterprises deployment. This will be configured on the MSCs as for other new cells
deployment in the network.
9.4.3 SGSN
There is no functional changes requires in the SGSN functionality. SGSN configuration
is required for implementation of IuCS IuPS over IP and Iu-Flex as described in section
7.5.2. The configuration is not detailed in this document; scripts will need to be created
by Switching Support, with help from Switching Design if required.
9.4.4 2G/3G Macro Cells

The DTs will be created in RECORD for SCW neighbour cells as required. The
neighbour cells will be configured onto 2G and 3G macro cells as for other new cells in
the network. Apart from this configuration there is no change to the macro cells.
9.5 UK IP Backhaul
IP backhaul – Each Services Node is connected back to Vodafone using IP based
backhaul. This is typically an Ethernet service from BT which is a minimum of 20Mbps
andsupports up to 100 Mbps.
IP Connectivity to the Vodafone CPN takes place via PE Routers at Oldham MTX sites.
To address this backhaul from individual Enterprise sites is aggregated into a single
1Gig interface. The equipment already in place which can support 20x1GigE links. The
product can in the future be upgraded to support 2x10GigE; but this will not be in place
for the initial Service.
SCW system doesn’t support the BGP protocol so initial launch to of the service is
without backhaul resiliency. When SCW have supports to the BGP protocol the
backhaul aggregation is made resilient with a 2nd 1Gig link connected to a second
Ethernet backhaul router located in Gravelly Hill MTX site.
9.6 UK NMS Network
9.6.1 NetCool
NetCool tool needs to be configured to capture events and alarms form the Services
Nodes and details are in section 7.4.2
9.6.2 ZenPM
ZenPM will collect resource performance management data from each of the Service
node and generate the KPIs reports and details are in sections 7.4.1

114/1009/20132
Page 55 of 80
Technology
9.6.3 Evenflow
The Evenflow changes are detailed in section 7.4.3.
9.6.4 Cell Centroid

The Cell Centroid changes are detailed in section 7.4.3
9.6.5 Cramer
The Cramer changes are detailed in section 7.4.3

114/1009/20132
Page 56 of 80
Technology
10Interface Summary
10.1 Machine to Machine Interfaces
10.1.1 Interface between SCRN and SCSN

For deployments on shared IP infrastructure a Firewall may exist between the Services
Node and Radio Nodes. If this is the case then certain IP port numbers must be
opened in the firewall to allow the Radio Nodes to communicate with the Services Node.
The Deployment Guide and IT Administrator Guide outline these in detail, but are
outlined here:
 IP protocol ESP between RN and SCRN to send UDP broadcast packets from
port 68 (bootpc) to port 67 (bootps)
 RN to receive UDP unicast packets from port 67 (bootps) to port 68 (bootpc)
 RN to send UDP unicast packets to port 69 (tftp)
 RN to receive UDP unicast packets from ports 60100 through 60200 (tftpdata)
 SN to send UDP packets to port 60004 (nodemgr) on the RN
 RN to send UDP packets to port 60003 (sysmgr) on the SN
 RN to (Tx& Rx) UDP packets (Tx& Rx) port 319 (ptp-event) on the SN
 RN to send (and receive) UDP packets to (and from) port 320 (ptp-general) on
the SN
 RN to send UDP packets to port 4500 (ike-nat-traversal)
 RN to send and receive UDP packets to port 500 (ike)
 IP protocol ESP between RN and SN to send and receive ESP (IP protocol 50)
 RN to send (and receive) UDP packet to (and from) port 62000 on the SN
(Radio Node firmware upgrades)

114/1009/20132
Page 57 of 80
Technology
Figure 7 – Radio Node to Services Node Flow Diagram
10.1.2 Interface between SCSN and Se-GW

The IPSec tunnels between the services nodes and the SecGW are authenticated using
X.509 certificates (pre-shared keys are also supported, but certificates are the
requirement from VF-Group security). Each endpoint has a unique certificate which is
used to authenticate with the remote tunnel peer. Using root certificates can reduce the
management overhead on the SecGW but there will be an ongoing requirement for the
expiry of each service node certificate to be tracked and ensure they are updated prior
to expiry. A services node with an expired certificate is isolated from the Vodafone
network. The IPSec tunnels are configured in tunnel mode.
IPSec tunnels periodically renegotiate the Security Association parameters as the

longer a tunnel is active with the same SA parameters the more likely it is for the

114/1009/20132
Page 58 of 80
Technology
encryption to be compromised. The lifetime of the tunnel is defined both in terms of time
(seconds) and data transferred. When either upper limit is reached the tunnel
renegotiates the SA parameters, this is not noticeable to the traffic using the tunnel.
10.2 Man Machine Interfaces

Each SCSN can be accessed through a command line interface, via BASNAC remote
access servers.
Ref [2] SCW Administrator Guide Release 2.0 and [ref-7] SCW CLI User Guide,
Release 2.0 provides a full list of the commands available.

114/1009/20132
Page 59 of 80
Technology
11Design Work Package Summary

TBD

114/1009/20132
Page 60 of 80
Technology
12Solution Check
12.1 Technical Performance
The solution is initially dimensioned to handle the 200 sites for the first 2 years.
12.1.1 Latency and Jitter

The use of NSU centralised architecture is introducing the additional latency as all
enterprise traffic will have to flow across the IP Backbone twice. The target design to
meet 150ms but still this is a risk until this is proven.
12.2 Business Performance
12.3 Availability and Processing Integrity

Despite the relatively low numbers of customer sites expected in the first two years,
many of these customers will be large corporate and due to this the deployment benefits
from both local high availability and geo-resiliency.
The IPBB is a highly available network with fast recovery from any individual element
failures. Vodafone UK and SPE has multiple links to the IPBB with automated failover
under failure conditions. The Iu-Concentrator equipment on a single SPE site is highly
available with redundancy wherever feasible.
Should an entire SPE be taken out of service the standby SPE is a complete replica and
dimensioned to handle all traffic, the active and standby SPEs are in different countries
and provide total geo-resiliency. The services nodes are able to re-route traffic to the
standby SPE to resume service. An INC failover will cause an outage for all services
nodes using that INC, each service node will need to reconnect to the standby site to
recover service.
The data to/from the customer site is encrypted in an IPSec tunnel, and once on site the
traffic between the services node and the Radio nodes is also encrypted. Once on the
Vodafone core network the traffic is unencrypted between the HNB gateway and
Vodafone core networks.
12.4 Stability
Counters used for the calculation of KPI’s are recorded by the Services Node and
passed to ZenPM for processing. See reference-4 for the Performance Management
integration project document for details on the specific counters available.
The SpiderCloud Services Node itself does not calculate KPI’s on board.
Additional KPI’s will be based around 3GPP 32.410 and will fit into 4 categories for both
CS and PS:
 Accessibility – CSSR (target > 98%)
 Retainability – CDR (target <0.85%)
 Mobility – Inter-RAT and Soft Handover Failure Rates (or SRNS handover rate
when supported to the macro)

114/1009/20132
Page 61 of 80
Technology
 Utilisation – Daily CS voices and PS data sessions
KPI’s are calculated per Services node and Per cell basis.
The Performance Measurements for SCW Small-Cell Clusters [ref-4] outlines the full list
of counters and how to calculate the above KPIs from the available counters.
12.5 Scalability
Backhaul Aggregator link
Scaling to the Backhaul connectivity can be achieved by purchasing new 1GigE

aggregator link from the BT.
NSU (SeGW/INC/Load Balancer)
The NEC solution consists of a number of discrete elements, all of which have their own
limiting factors, the core elements and the limitations that will need to be taken into
account are shown below:
Element Limiting factors
SecGW 200K tunnels
1Gbps bandwidth
475 IPSec tunnels/sec

INC 17 Iu interfaces (Cs and
PS)
Busy Hour transaction

attempts 330K
Simultaneous Up Session
144K sessions
Up session setup rate

120 sessions/sec
Load balancer Supports up to 6 INCs
320Gbps total throughput

Table 11 - SeGW and INC scaling limitations
Based on current traffic dimensioning a fully populated solution based on a single LBR
pair can handle up to 1000 services nodes. The number of subscribers on each service
node has a direct impact on the number of INCs which in turn has a direct impact on the
number of load balancers. Using the original UK estimates for 120 services nodes in
total as an example, the following tables show the mapping of subscribers to services
nodes to INCs.
Density Subscribers per Number of Ratio of service node

service node services nodes sizes
Low 400 60 50%
Medium 800 48 40%
High 2000 12 10%

114/1009/20132
Page 62 of 80
Technology
Table 12: Service node utilisation
Mapping the number of subscribers to Busy Hour Transaction attempts which is the
figure used by NEC to dimension the INCs gives the following table:

114/1009/20132
Page 63 of 80
Technology
Density Number of subscribers Busy Hour Transaction

attempts
Low 24000 162000
Medium 38400 259200
High 24000 162000
Total number of 86400 583200

Table 13: subscribers Dimensioning
estimates
12.6 Monitoring
The monitoring of the overall system is addressed by multiple sub-systems, so as not to
be completely reliant on one source:
 Performance Measurements, which will be taken from the Enterprise sites
 Fault Management, which will be taken from the Enterprise sites, as well as a
implementing a Netcool Heartbeat (or keep alive) function
 Traffic Volume measurements, which will be taken from the Enterprise sites, the
UK Backhaul Aggregator & HNB-GW measurements
See also the Monitoring provided by the HNB-GW, detailed in NSU HLD Section 12.4
Monitoring [ref-1].
12.7 Reporting
The table below describes the reporting requirements which are met via ZenPM.
Description
Requirement
of delivery
The solution shall be able to report the total number of femto cells Yes
in active use per day, week and month. (Active = 1 or more voice
call or data session made using the femto cell in the last 3
months.)
The solution shall report on a daily and monthly basis the total Yes
number of voice calls made using Femto Cells
number of voice minutes used on femto cells
number of data sessions made using Femto Cells
volume of data traffic in Gb used on femto cells
The solution shall report on an hourly, daily and monthly basis the Yes
call setup success rate for voice calls broken down by individual
femto cell, femto cell group and all femto cells
dropped call rate for voice calls broken down by individual femto
cell, femto cell group and all femto cells.
The solution shall report on a monthly basis the number and Yes
percentage of femto cells with a dropped call rate greater than "X"

114/1009/20132
Page 64 of 80
Technology
where "X" is a configurable number

percentage of femto cells with a call set up success rate less than
"X" where "X" is a configurable number
connection setup success rate for data sessions broken down by
individual femto cell, femto cell group and all femto cells
percentage of femto cells with a connection set up success rate
less than "X" where "X" is a configurable number
Table 14 – Reporting Requirements
See also the Reporting provided by the HNB-GW, outlined in NSU HLD Section 12.5
Reporting [ref-1].
12.8 Finance
As per femto.
12.9 Support
The Support Model provides details on the support model to be used; but in summary:
 The UK SO group, which is already responsible for supporting the MSS

Enterprise in-building coverage, will have additional responsibility of ownership
and triage of VESC customers.
o Any enterprise site affecting activity (either remotely or with physical

site visits) will be managed by this group.
 All issues affecting the HNB-GW will be addressed by the NSU SO group. The
NSU solution is highly resilient and most issues will not be visible to enterprise
customers.
o All HNB-GW issues that might by visible at the enterprise site are
informed to the UK SO group.
 There is an ongoing project to provide SO Tool integration between NSU and

various OpCo (not within scope of this project).
o Any inter group communication needed before this tool coupling is in

place will be done via email.
12.10 Customer Care

All customer enquiries (be they from EBU or VGE) will initially be fronted by the
Corporate Customer Care Help Desk (Stoke 191).
The Help Desk initially confirms the status of contractual support by the UK SO
organisations.
These Help Desks are made aware of any network wide issues affecting customer
service.

114/1009/20132
Page 65 of 80
Technology
All possible service affecting customer raised issues are routed to the Network
Enterprises Support group (NETS). This group performs a filter function by qualifying
the nature of the reported issue.
After this qualification a ticket is raised on the UK Remedy system.
Further details of the Support Model will be available in the Support Guide - Support
Model.1
12.11 System Decommission

None
12.12 Regulatory and Government Requirements

Due to the sensitivity of the information, the regulatory and government requirements for
this project and solutions to them are not captured in this document. For more
information please contact Adam Hunter (Adam.Hunter@vodafone.com)
12.13 UKCR
The requirements are therefore as follows:
Requirement Requirement Compliance Statement

ID
BR-606 The solution shall ensure that users (including third parties) are Y – User Access will be
only granted the appropriate levels of access permissions to controlled via BASNAC
systems depending on their role and business processes needed
to fulfil their role. Please refer to non-functional requirements for
details of user roles and access privileges.
BR-607 The solution shall ensure that there is authentication on all user Y – User Access
access. authentication will be done
via BASNAC
BR-608 The solution shall provide a mechanism for identifying accounts Y

that have not been used for 90 days.
BR-609 Authorised users shall have the capability to disable and enable Y
user accounts.
BR-610 The solution shall allow all passwords to be changed or reset by Y

authorised users only
BR-611 The solution shall ensure that a single entity cannot be assigned Y
both administrator and user roles
BR-612 The solution must have a formal user registration and de- Y – Will be controlled via
registration process for granting access including steps to: BASNAC
1. Ensure that the User has authorisation from the service owner
and any other authorities as appropriate
2. Ensure that users are not given access until authorisation
procedures have been completed
3. Ensure that a user's access rights are removed or amended
immediately when they change jobs or leave the organisation
1
There is an alternative Support Model proposed by NEC which is under evaluation

114/1009/20132
Page 66 of 80
Technology
4. Ensure that redundant user accounts are removed monthly and

are not issued to other users
5. Ensure that users are given a statement of access rights in a
text format e.g. email
BR-613 The solution shall have the capability to provide information on all Y
user’s access privileges.
BR-614 The solution shall provide a facility to: Y – will be controlled via
1. Regularly review user permissions BASNAC
2. Identify and remove unauthorised permissions
3. Remove privileges no longer required.
BR-615 The solution shall maintain an audit trail of all user account activity Y
including creation, modification and deletion of user account. This
activity shall be traceable to a user's unique ID.
BR-616 The solution shall allow third parties to audit revenue data in order N/A – No billing information
to query and resolve any billing discrepancies is stored on the SCW
system.
BR-617 The solution shall ensure that the same user cannot access the TBD – Need to check does
same system from two separate locations simultaneously BASNAC allow this or not?
BR-618 The solution shall provide duly authorised personnel the ability to Y - Traffic to the Core
intercept communications securely to ensure that information only Network is over IPSec and
flows between authorised end points may be intercepted using
existing lawful intercept
mechanisms.
BR-619 The solution shall allow authorised Vodafone representatives the Y

ability to decrypt any encrypted data.
BR-620 The solution shall ensure that it is possible to intercept all services Y
(voice and data) to meet the legal requirements as required by the
UK Government
BR-621 All solutions which produce Call Data Records (CDR) or stored N/A – The CDRs for traffic
user content shall provide the ability for Police Liaison to retrieve routed to the CN and
the associated data for a duration as defined in the Framework associated Police Liaison
Document Management and Retention Policy. of this traffic will use
existing systems.
BR-622 The solution shall manage, store, transmit, protect and dispose of Y - No personal user data
all personal data in a secure manner in accordance with Vodafone are kept in the SCW
Limited's Framework Data Protection Policy. This personal data system for any purpose.
relates to Vodafone employees, contractors, agents as individuals,
as well as Vodafone customers. The data covered includes all
communications data that is generated as a result of a person
using our communications services like WAP, Vodafone websites,
data relating to telephone calls, text messages, e-mails.
BR-623 The solution shall provide the ability to remove any stored data Y - No personal user data
after the expiry of the minimum retention period. (The retention are kept in the SCW
period is different for different types of projects and needs to be system for any purpose.
defined as per non-functional requirements)
BR-624 The solution shall ensure that all management information N/A – Out of scope
required is made available to be loaded into the Enterprise Data
Warehouse (EDW)
BR-625 The solution shall support all customers including those that have Y - All Vodafone UK

114/1009/20132
Page 67 of 80
Technology
ported into VF UK after the product/service has been launched subscribers are supported
by the system.
BR-626 The solution shall provide the ability to enable interactive Y – SCW can provide audit
monitoring and after-the-fact auditing of activity at all levels of the logs of access over
platforms, systems and applications. After-the-fact auditing is console port and SSH.
based on investigation of an archived history of previously logged
events (for example file errors, keystrokes or system component
failures), providing traceability of activity.
BR-627 The solution shall make service logs available for Vodafone Y
monitoring. This includes Vodafone internal, third party hosted or
other managed services.
BR-628 The solution shall provide monitoring as defined in the NA

Infrastructure Impact Assessment (IIA). Insert link to the actual IIA
spreadsheet completed for the project
BR-629 The solution shall ensure that passwords are obscured on any Y
console or display whilst the user is logging in.
BR-630 The solution shall allow any personal data processing and access N/A – No personal data are
to be carried out only after ensuring that the stored on SCW system.
customer/employee/third party has explicitly granted consent
BR-631 The solution shall allow any sensitive data processing and access N/A – No sensitive data are
to be carried out only after ensuring that the stored on SCW system.
customer/employee/third party has explicitly granted consent
BR-632 The solution shall allow browsing behaviour monitoring only after N/A – This will be manager
ensuring that the customer/employee/third party has explicitly VF core network.
granted consent
BR-633 The solution shall ensure that the Log and Call Details Record N/A – The SCW system
(CDR) files are secured appropriately to prevent them from being CDRs are not being used
deleted or overwritten inadvertently for any billing disputes. The
CDRs for voice and data
traffic routed to the CN will
use existing systems.
BR-634 The solution shall provide the ability to bar/stop a customer from N/A – This will be managed
using a specific Service or Product without affecting other Service by existing CN network.
or Products available to that customer
BR-635 The solution shall provide the ability to remove any stored data N/A – There is no
after the expiry of the minimum retention period requirement for a minimum
retention period in this
project however SCW can
comply with Vodafone UK
Prescribed Data Retention
policies.
BR-636 There shall be the ability for authorised users to define the N/A – There is no
retention period for any personal data that is stored by the system. requirement for a minimum
retention period in this
project however SCW can
comply with Vodafone UK
Prescribed Data Retention

114/1009/20132
Page 68 of 80
Technology
policies.
BR-637 Where Services / Products could be deemed of adult content (as N/A – This will be managed
defined by the country of deployment), the Solution shall ensure by existing CN network.
that all of the following are met:
- Make use of adult content filtering bars
- Ensure children (under the age of 18) do not have access to
adult services (e.g. adult content or gambling)
- Provide an e-mail address on any website associated with the
service that can be used for complaints and issues
BR-638 The Solution shall ensure that where users access adult only sites N/A – This will be managed
a message will be displayed stating that any actions the user by existing CN network.
performs within the site will be traceable.
BR-639 The solution shall ensure that any data transfer between VF Y - All SCW interfaces are
systems and third parties is secure encrypted (IPSec & SSL)
BR-640 When a user logs on to the system the solution shall ensure that a Y
message is displayed informing them that only authorised users
are allowed access to the system in accordance with any legal
obligations (such as the UK Computer Misuse Act).
BR-641 The solution shall provide the ability to send an SMS to inform a N/A – This will be managed
customer of a new subscription order of a service / product, e.g. by existing CN network.
weather, lottery, horoscope in order to allow customer to contact
VF in case of incorrect service provisioning
BR-642 The solution shall include T&Cs to inform user of a Fair Use policy N/A – This will be managed
for each upload of content service, e.g. videos, photos, blogs etc. by existing CN network.
BR-643 The solution shall ensure that a customer cannot bypass the N/A – This will be managed
existing call bars or restrictions such as international or premium by existing CN network.
rate call bars.
BR-644 The solution shall ensure that all communication from Vodafone N/A – This will be managed
shall be clearly identifiable as such in order that it shall not be by existing CN network.
mistaken for spam or phishing.
BR-645 The solution shall ensure that critical/confidential data shall not be Y - The SCW system will
transmitted or stored anywhere where it could put it at risk (i.e. not cache any user data
caching). All data shall be protected as stated in the Data
Classification document.
BR-646 The solution shall ensure that necessary measures are Y - No personal user data
implemented to prevent any subsequent retrieval of personal data are kept in the SCW
and other information stored when any media used by the system
is to be disposed off or reused
BR-647 The solution shall allow end user passwords to be changed Y

directly by the users (provided the previous password is known).
BR-648 The solution shall not allow CLI / MSISDN to be used as a form of Y
identification in its own right in order to avoid spoofing
BR-649 The solution shall ensure that all services (voice and data) must N/A – This will be managed
be capable of recording transaction details of both called and by existing CN network.
calling party and stored in a manner where they can be retrieved if
required by a Law Enforcement Agency.
BR-650 The solution shall provide an emergency process for N/A – This will be managed

114/1009/20132
Page 69 of 80
Technology
disconnecting 3rd party content providers by existing CN network.
BR-651 The solution shall ensure that the following conditions are met N/A – This will be managed
before allowing users to upload content: by existing CN network.
- Users must be registered to use the service
- There must be separate T&Cs appropriate to this service, which
must be explicitly signed up to upon registration
- Content must be checked for illegal content and viruses before
being uploaded to the site
- Content must be moderated either prior to upload or by use of a
report abuse button
- There must be processes and procedures in place for dealing
with illegal content (as per Live!), where the content is reported
and handled appropriately. It cannot be simply deleted
- There must be processes and procedures in place for dealing
with abusive content etc.
- Vodafone must have a statement on the website saying that they
are not responsible for the content
- Logs and full audit trails must be available to show who
uploaded what, when. This must include, but is not limited to,
username, IP address, timestamp, type of content
- The site must comply with Vodafone's Data Retention Policy
- There must be an Acceptable Use Policy (possibly contained
within T&Cs)
- There must be a disclaimer protecting Vodafone for content that
is downloaded (viruses etc)
BR-652 Wherever data with a classification of C3 or over is to be stored on Y – SCW has put a plan in
a laptop, then the laptop shall be encrypted to be prevent place to encrypt all the
unauthorised access laptops to be used to
support this project.
BR-653 a)The solution shall ensure that users have unique usernames Y – as per BASNAC
b) Non-consumer users (e.g. Vodafone employees, contractors
and third party service provider staff) and administrators shall
require authorisation to have an account
c) The addition, deletion, and modification of user IDs, credentials,
and other identifier objects shall be controlled
d) The solution shall ensure that general and administrator users
are authorised according to company policy (FRS006 Account
Management Policy)
e) The solution shall ensure that each user ID request is made via
an authorisation form
f) The solution shall ensure that user IDs are implemented in
accordance with the authorisation form (including any privileges as
specified and all signatures obtained)
g) If a user requests an authentication reset, the users identity
shall be verified first
h) Upon termination of an employees contract, their account shall
be either made inactive or removed.
i) Inactive business user accounts over 90 days old shall be
removed unless appropriate justification (a legitimate business
reason) for keeping the account for longer than 90 days is
provided
j) Accounts used by vendors for support and maintenance shall be
kept inactive. These accounts shall only be enabled when needed
by the vendor to carry out a support or maintenance activity. While
in use these accounts shall be monitored,
k) Generic accounts shall be disabled or removed
l) The solution shall not implement shared accounts.
m) Procedures shall explicitly prohibit group and shared accounts

114/1009/20132
Page 70 of 80
Technology
n) System administrators shall not give out group and shared

account credentials even if requested
BR-654 The solution shall formally assign the responsibility for Y

administering user account and authentication management to an
authorised function
Table 15 – UK CR compliance matrix

114/1009/20132
Page 71 of 80
Technology
13Security Dimensions
Dimension Compliance
Customer
Authentication
“Provide proof of identity” Customer will be authenticated via standard GSM
authentication triplet.
Authentication of a user or service makes them prove their
identity, after which the correct applications and privileges Service Nodes
can be provided to them.
User access to the services nodes will be
authenticated via BASNAC user accounts/passwords.
Service Nodes / SeGW IPSec Tunnel
X.509 certificates
HNB-G/W
Availability
“Ensuring services are available” HNB-G/W on a single site is highly available with
redundancy wherever feasible. The Geo-resiliency is
Availability ensures that the effect of a disaster or provided via standby site which is a complete replica.
unplanned outage is planned for through Business
Continuity ensuring speedy recovery of a service. IP Backhaul
There is no resiliency for IP Backhaul between BT

and Vodafone routers. The BGP protocol is currently
not supported by SCW system but this is included in
SCW roadmap.
Data Classification is C3, access to the data is
Data Confidentiality password protected and restricted by named
“Keep secrets secret” individual user accounts
Data Confidentiality ensures that data can only be viewed Service Node
or accessed by authorised users or services. SCW has put a plan in place to encrypt all the laptops
to be used to access the service nodes.
The Individual user access will be controlled via
Access Control BASNAC.
“Limit and control access”
User accounts will be created/amended following the
Access Control constrains the user or service's activity by authorisation/approval as per the operational process
granting specific access to a role that a user or service can
use to perform specific actions.
The traffic between the Service Nodes and HNB-G/W

Communications Security is secured using IPSec encryption. The encryption
“Ensure data flows only from source to key is unique to each Enterprise site
destination”
The traffic between the services node and the Radio
Communication security ensures that data flows between nodes is also encrypted.
the source and the destination cannot be intercepted or Traffic over the VF IP Backbone (between the HNB
interfered with. gateway and the Vodafone UK core networks) is
unencrypted.

114/1009/20132
Page 72 of 80
Technology
Dimension Compliance
All amendments will be audited including user name
Data Integrity and date/time.
“Prevent unauthorised changes ”
Data Integrity ensures that data has not been tampered
with or modified without authorisation.
Privacy Customer Sensitive data are not stored on SCW

system.
“Protect personally identifiable data”
Privacy provides protection against the gathering of
information about customers, partners or service providers
who connect to or use Vodafone’s’ network.
Link to security coding standards:

https://sharepoint.vodafone.com/vfuk/IPS/ServiceDelivery/_layouts/xlviewer.aspx?
id=/vfuk/IPS/ServiceDelivery/Shared%20Documents/Security%20Coding%20Stds%20Requirements
%20Summary%20v0%202b.xlsx

114/1009/20132
Page 73 of 80
Technology
14Glossary
Acronym Description
ACL Access Control List
BGP Border Gateway Protocol
CAPEX Capital Expenditure
CDR Call Data Records
CLI Command Line Interface
CM Configuration Management
CPE Customer Premises Environment
CRB Committed Bit Rate
CS Circuit Switched
DAS Distributed Antenna Server
DNS Domain Name Server
FM Fault Management
HO Handover
HNB Home NodeB
INC Iu-Concentrator
IPBB IP Back Bone
IRAT Inter-Radio Access Technology
KPI Key Performance Indicator
LAC Location Area Code
LAN Local Area Network
MCC Mobile Country Code
MNC Mobile Network Code
MSC Mobile Switching Center
MSS Managed Sure Signal
MTX Mobile Telephone Exchange
NMS Network Management System (also known as OSS, Operation

Support System)
NTP Network Timing Protocol Server, used by the Femto solution

for frequency synchronisation on the radio interface.
OAM Operational and Maintenance

114/1009/20132
Page 74 of 80
Technology
OPEX Operational Expenditure
OTA Over The Air
PM Performance Management
PS Packet Switched
PSC Primary Scrambling Code
RAC Routing Area Code
RAN Radio Access Network
RNC Radio Network Controller
SAC Service Area Code
SCC Spider Cloud Cell
SCP Secure Copy Protocol
SCRN Spider Cloud Radio Node
SCSN Spider Cloud Services Node
SCTP Stream Control Transmission Protocol, IP transport layer for

Sigtran
SCW Spider Cloud
SGSN Serving GPRS Support Node
SMS Short Message Service
SNMP Simple Network Management Protocol
UE User Equipment, also known as a device or handset
UMTS Universal Mobile Telecommunications System
WAN Wider Area Network
Table 16 – Glossary

114/1009/20132
Page 75 of 80
Technology
15Document Control Information

15.1 Document Content History
Version Date Author Change Summary
0.1 07 June 2012 Balkishan Initial Draft

Karwa
0.2 28 July 2012 Balkishan Review comments incorporated.

Karwa SGw included in the design.
UKCR compliance statements added.
0.3 20 August Balkishan Further Review comments

2012 Karwa incorporated.
0.4 11 Sep 2012 Balkishan Minor Review comments incorporated

Karwa
1.0 14 Sep 2012 Balkishan Issue as approved with key approvals

Karwa embedded.
15.2 Key Reviewers
Role Name
VF UK Technology Security Ian Bennett
VF UK FRS Adam Hunter
VF UK SO Readiness Andrew ClarkRichard Evans
UK Programme manager Steve Downing
UK Delivery Manager Gary Rawcliffe
NSU Delivery Manager NicolaBertoni

Overall Technical Authority Anthony Masih
Small Cells Service Owner Dan Raine
Network Authority David Sanderson
VESC SO Owner Peter Toms
VF SCW Product Owner Carmen deLacourZumalacarregui
Radio Network Authority David Parker
NMS Configuration Manager Howard Atkins / Elwyn Coulson
NMS PM / FM Damian Fairholme

114/1009/20132
Page 76 of 80
Technology
Role Name
NetCool Henri Kaye / Steve Stubbs
Cellular Asset Management (CAM) Danielle Hurd
IP Network Authority / IP Design William Follows
Capacity & Planning Adrian White
Capacity & Planning Simon Wavell
Special Coverage James Grayling
Transmission Design John Harris
Switching Design Dave Coventry
Packet Design Azhar Meo
UK Signalling Design Dave Hodgkinson
NSU Network Authority (INC+SeGW) Yolanda Fernandez
NSU SO Owner Robert McKeown
UK SO Switching Support Simon Jackson
UK SO SGSN Support Tom Hearn
Design Review Jamie Page
UK SO IP Operations Karl Blackmore-Squires
SCW Integration Chris Baldwin
Aricent Test Manager Komal Sandhu
Aricent Solutions Architect Balkishan Karwa
VF Group FRS Ned Finn
VF Group Security Peter Howard

SCW Project Manager Matt Cliffe
SCW Technical Architecture Kieren Ashlee

114/1009/20132
Page 77 of 80
Technology
15.3 Approvals / Authorisations

Key Approvals
Name Role Date

Daniel Raine UK Service Owner
Steve Downing UK Programme Manager
Gary Rawcliffe Project Manager

HLD - set as
v1.0_GaryR.msg
Dave Sanderson Technical Architecture

RE VESC-UK (Spider
Cloud) HLD for review_DaveS.msg
Other Approval statements
Name Role Date
Ian Bennett VF UK Technology Security

RE HLD
Approval_Ian.msg
Adam Hunter VF UK FRS

RE VESC-UK (Spider
Cloud) HLD for review_Adam.msg
Peter Toms VF UK SO Service Owner

HLD - set as
v1.0_PeterT.msg
Anthony Masih Technical Authority

SpiderCloud
HLD_AnthonyM.msg
Azhar Meo Packet Design

RE VESC-UK (Spider
Cloud) HLD for review_AzharMeo.msg
David Coventry Switching Design

RE HLD
Review_DaveC.msg

114/1009/20132
Page 78 of 80
Technology
Dave Hodgkinson UK Signalling Design

RE VESC-UK (Spider
Cloud) HLD for review_DaveH.msg
William Follow IP Network Authority / IP Design
Jamie Page VF UK IP SO
RE VESC-UK (Spider
Cloud) HLD for review_JamieP.msg

114/1009/20132
Page 79 of 80
Technology
16Template Version History

Version Date Author Role Summary
of
Change
3.0 16/08/11 Silvana IT Process New HLD Template to
Minto Improvement conform to VF Standards
and to bring the HLD up to
date
3.0 06/09/11 Andy Technical Design Changes to existing

Haveron Authority template so that it
conforms to VF Standards
and to bring the HLD up to
date
3.0 06/09/11 Paul Senior Manager Approval to publish

Weeks Product Design
Architecture and
Design Team
4.0 19/10/11 Leanne Product Design Updated template

Baldwin Authority following Product Design
team review of the
template with input from
other Technology teams.

Architecture and
Design Team
4.1 08/03/12 John Cole Principal Architect Needed to bring more

focus of solution
Resilience / Recovery in
section 12.3 of Design

Architecture and
Design Team

114/1009/20132
Page 80 of 80

Sure Signal Premium - UK High Level Design v3.0

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sure Signal Premium - UK High Level Design v3.0

Caricato da

Copyright:

Formati disponibili

Sure Signal PremiumVESC-UK

High Level Design

Project No: N. 40000686502

Author: Balkishan Karwa / Anthony Masih/Mai Tran Le

3 Key Requirements Not Met.........................................8

5 Interactions with other designs.................................14

6 Design Assumptions, Risks and Issues....................16

Version: 13.0 Document Classification: C3 Version Date:

11 Design Work Package Summary..............................54

16 Template Version History..........................................74

1.1 Source Artefacts..................................................6

Version: 13.0 Document Classification: C3 Version Date:

Version: 13.0 Document Classification: C3 Version Date:

Version: 13.0 Document Classification: C3 Version Date:

Version: 13.0 Document Classification: C3 Version Date:

Version: 13.0 Document Classification: C3 Version Date:

[1] NEC HNB Gateway High Level Design, July 2012,

1.2 Referenced Artefacts

[6] SCSN 8000 Data Sheet, Jan 2012

[7] DOC-SCOS-CLI-01 The SpiderCloud® OS (SCOS) CLI User Guide,

Version: 13.0 Document Classification: C3 Version Date:

This approach intendeds to allow in-building coverage and capacity solutions to be

2.2 Key Design Highlights

Version: 13.0 Document Classification: C3 Version Date:

3 Key Requirements Not Met

 The business requires a solution that will deliver an in-building coverage

 The service offering is to be as similar to MSS as possible, given the variance

 The service is to comply with UK common requirements.

Services that are the same:-.

 Femtocell operating in Open Mode access

 Femtocell to Femtocell handover

 Dedicated backhaul link to VF , protected by IPsec

 Remote Access (via BASNAC)

The Elements and aspects that differ are:-

 Femtocells operating in Closed mode – Closed Modethis service is not offered

 No ACLM – No provisioning platform. ACLM offers the following functions to

- Postcode/LAC/SAC management from NMS

- Femtocell ACL – Closed mode access is not offered

- Radio Profile use – No Requirements

- Active / Passive cell management – No Requirement

 No FMS – no SCW network element manager. FMS offers the following:-

- Remote SW Down Load – No Requirements

- Femtocell diagnostic interrogation

Version: 13.0 Document Classification: C3 Version Date:

- Femtocell remote management

 No AAA – no Product Authentication key as the supply channel is controlled my

 No NTP Servers – there is no feed from NTP servers

NTP is not required for system operation (although recommended to maintain

 SAC per Radio Node.

MTPAS is a UK Government requirement for Mobile Network operators aimed at

Version: 13.0 Document Classification: C3 Version Date:

 Support of 15 active radio users per Radio Node

 Support of circuit switched voice

 Support of Packet Switched data

 Support of HSDPA Category 10 data rates

 Auto provisioning and auto optimisation of Radio Nodes

 Soft Handover between Radio Nodes

 Macro network reselect in and out

 SMS and MMS

 Multiple terminal/dongle/mobile/smart phone/tablet testing

 Call features, voicemail, call divert, conference calling etc

 HNB Access Network Control

o Management of the Iuh Interface using the HNBAP protocol

 Circuit Services Control