General Network Architecture Requirements

jinkscabbageΔίκτυα και Επικοινωνίες

23 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

110 εμφανίσεις

FP6-IST-2003-506745 CAPANINA
Deliverable Number D13
General Network Architecture Requirements
Document Number CAP-D13-WP13-BT-PUB-01
Contractual Date of Delivery to the CEC 1
st
May 2005
Actual Date of Delivery to the CEC 28
th
April 2005
Author(s):
Milan Lalovic (BT), Ales Svigelj (JSI), Luong Dinh Dung
(BUTE), Michael Fitch (BT)
Participant(s) (partner short names):
BT, JSI, BUTE
Editor (Internal reviewer)
Paul Mitchell (UOY)
Workpackage:WP1.3
Estimated person months 11
Security (PUBlic, CONfidential, REStricted) PUB
Nature Report
CEC Version 1.1
Total number of pages (including cover):55
Abstract:
This technical document describes the general network architecture requirements for the CAPANINA
communications architecture(s) for use with the applications and services defined in deliverable D01,
Candidate Applications and Services for Broadband HAPS Delivery. The report describes network
topologies for both single and multiple HAPS architectures including the OSI reference model for each
network topology. The network layer requirements are also presented. The report defines the key
network elements of the CAPANINA system including the general payload architecture, backhaul
network and customer premise equipment architectures. The CAPANINA service management system
and operational supporting system and its subsystem components are also described in this document.
These systems will be used to support commercial aspects of CAPANINA service such as network
management, account management, system policy management, conditional access and security,
billing and usage tracking.
Keyword list: Network Architecture, Quality of Service, Network Layer, OSI reference model, Payload, Backhaul,
Customer Premise Equipment
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 2 of 55
DOCUMENT HISTORY
Date Revision Comment Author / Editor Affiliation
28/4/2005 01 First Issue Milan Lalovic BT
Document Approval (CEC Deliverables only)
Date of
approval
Revisio
n
Role of approver Approver Affiliation
28/04/2005 01 Editor (Internal reviewer) Paul Mitchell UOY
28/04/2005 01 On behalf of Scientific
Board
David Grace UOY
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 3 of 55
EXECUTIVE SUMMARY
This technical document describes the general network architecture requirements for
the CAPANINA communications architecture(s) for use with the applications and
services defined in deliverable D01, Candidate Applications and Services for
Broadband HAPS Delivery [1].
The broadband service providers of today face the challenge of connecting an
enormous number of diverse, relatively low-speed access services into their high-speed
backbones. Supporting a wide range of access interfaces is a potentially complex and
expensive undertaking but is necessary if all customers are to be served. HAPS offer
significant potential to play an active role in providing broadband services in four core
network segments: access network, content distribution, core network trunk and HAPS
private networks.
This report describes network topologies for all four selected CAPANINA network
scenarios, for both single and multiple HAPS architectures. The OSI reference model
for each network topology and network layer requirements are also presented here. The
CAPANINA OSI network reference model combines the multiple layers of terrestrial
network architecture with the payload and customer premise equipment architectures.
Convergence creates a unified network that operates cohesively to promote efficiency,
enhance service features, and offer cost savings; seen as key elements of today's
competitive marketplace for broadband service provision. The network layer
requirements describe IP unicast and multicast routing, and IP quality of service (QoS)
requirements for both data and voice service scenarios.
The report also defines the key network elements of the CAPANINA system including
the general payload architecture, backhaul network and customer premise equipment
architectures. The CAPANINA service management system and Operational
Supporting System (OSS) and its subsystem components are also described in this
document. These systems will be used to support commercial aspects of the
CAPANINA service such as network management, account management, system
policy management, conditional access and security, billing and usage tracking.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 4 of 55
TABLE OF CONTENTS
1.INTRODUCTION..............................................................................................................10
2.CAPANINA SERVICES AND APPLICATIONS OVERVIEW............................................10
2.1 Revisiting Candidate Services and Applications for HAPs from the Network Architecture’s Point
of View.............................................................................................................................11
2.2 Classifying Candidate Services According to the Network Requirements................................14
3.CAPANINA NETWORK SCENARIOS OVERVIEW.........................................................14
3.1 Network Topologies...........................................................................................................14
3.2 Single and Multiple HAPS Platfrom Case Scenarios............................................................15
3.2.1 Single HAPS Platform Scenario.......................................................................................16
3.2.2 Multiple Platform Scenario...............................................................................................16
3.3 Proposed Reference Model of Network Architecture.............................................................17
3.3.1 Reference model for a Single HAP Architecture.................................................................18
3.3.2 Reference model for a Multi HAPS Architecture.................................................................20
4.INTERWORKING REQUIREMENTS BETWEEN HAPS NETWORKS AND OTHER
NETWORKS.....................................................................................................................21
4.1 Mobility and Handover.......................................................................................................22
4.1.1 Mobility Within and Between HAPS Networks...................................................................22
4.1.2 Mobility Between HAPS and Other Networks....................................................................22
4.2 Quality of Service Requirements.........................................................................................22
4.2.1 IP QoS Requirements.....................................................................................................23
4.3 Additional Requirements for VoIP Services and Applications.................................................23
5.NETWORK LAYER REQUIREMENTS...........................................................................26
5.1 Interworking between Layer 2 and Layer 3...........................................................................26
5.2 Routing Requirements.......................................................................................................26
5.2.1 General Requirements for Routing....................................................................................26
5.2.2 Multicast Routing...........................................................................................................27
5.2.3 Techniques for Performance Improvement.........................................................................27
5.2.4 Optional Technologies.....................................................................................................27
5.3 Authentication, Authorisation and Accounting (AAA)............................................................28
6.SERVICE MANAGEMENT SYSTEMS (SMS)................................................................28
6.1 Assumptions....................................................................................................................28
6.2 Position and Role in the CAPANINA System.......................................................................29
6.3 Top Level Architecture.......................................................................................................29
6.4 Interfaces to Other CAPANINA Subsystems........................................................................30
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 5 of 55
6.4.1 Content Distribution Subsystem Interface.........................................................................31
6.4.2 Content Management Subsystem Interface.......................................................................31
6.4.3 Platform Portal Interface..................................................................................................31
6.4.4 OSS Interface................................................................................................................32
6.5 Internal Architecture..........................................................................................................32
6.5.1 Database.......................................................................................................................33
6.5.2 Account Management.....................................................................................................33
6.5.3 System Policy Management............................................................................................33
6.5.4 Usage Collection............................................................................................................34
6.5.5 Billing Collection.............................................................................................................34
6.6 Network Management System...........................................................................................35
6.6.1 Network Management Requirements................................................................................35
7.HAPS PAYLOAD GENERAL ARCHITECTURES...........................................................36
7.1 Transparent Payload Overview............................................................................................37
7.1.1 Specific Technical Issues with Transparent Payload..........................................................37
7.2 Processing Payload Overview.............................................................................................38
7.2.1 Specific Technical Issues with Processing Payloads.........................................................38
7.3 Queuing...........................................................................................................................38
7.4 Line of Sight Requirements................................................................................................39
7.5 Spectrum Allocation..........................................................................................................39
8.BACKHAUL NETWORK ARCHITECTURE....................................................................40
8.1 Backhaul Bandwidth Specification......................................................................................42
8.2 Additional Service Providers and Roles................................................................................43
9.CUSTOMER PREMISE EQUIPMENT ARCHITECTURE.............................................44
9.1.1 Dual RF demodulator option............................................................................................46
9.1.2 TCP Spoofing and Web Accelerators................................................................................46
9.1.3 Conditional Access Module Requirements........................................................................46
9.1.4 Control and Remote Monitoring Requirements...................................................................46
9.1.5 Potential Scenarios........................................................................................................46
9.1.6 CPE Technical Specifications Summary...........................................................................48
9.2 Antenna Dish and LNB Specification...................................................................................49
9.2.1 Tracking Requirements for Fixed Services at Higher Frequency Bands................................50
9.2.2 Fast Tracking Stabilised Antennas for In-motion Services...................................................50
9.2.3 Future Trends in Printed Antennas...................................................................................51
10.CONCLUSION..................................................................................................................52
REFERENCES.........................................................................................................................54

General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 6 of 55
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 7 of 55
LIST OF FIGURES
Figure 1: HAPS Connectivity.......................................................................................................15
Figure 2. Multi platform scenario illustration..............................................................................17
Figure 3: Network architecture...................................................................................................18
Figure 4: Simplified reference models.......................................................................................19
Figure 5. Reference model of access network scenario.............................................................19
Figure 6: Proposed Multi HAP Network architecture...................................................................20
Figure 7: Reference model of a multi-HAP network scenario.....................................................21
Figure 8: VoIP architecture for HAP network..............................................................................25
Figure 9: SMS Top Level Functional Architecture......................................................................30
Figure 10. HAPS spectrum allocation.........................................................................................40
Figure 11. CAPANINA backhaul network architecture illustration...............................................41
Figure 12. CAAPANINA network architecture scenario...............................................................42
Figure 13. Network Requirements for multi-ISP case scenario...................................................44
Figure 14. CAPANINA Set-top-box architecture illustration.........................................................45
Figure 15. CPE Home Configuration Scenario............................................................................47
Figure 16. Corporate User Scenario CPE Configuration..............................................................48
Figure 17. In-motion antenna systems illustration.......................................................................51
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 8 of 55
LIST OF TABLES
Table 1. HAPS services and applications....................................................................................12
Table 2. Types of Information, Services and Application suitable for HAPs................................13
Table 3. Interfaces for HAPS access...........................................................................................19
Table 4. “BT Central” backhaul product specification illustration..............................................43
Table 5. CPE Technical Details Summary...................................................................................49
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 9 of 55
LIST OF ACRONYMS
BGP Border Gateway Protocol
CA Conditional Access
CPE Customer Premise Equipment
DSLAM Digital Subscriber Line Access Multiplexer
DVB Digital Video Broadcasting
ETOM Enterprise Telecoms Operations Model
FAB Fulfilment, Assurance, Billing
FCAPS Fault, Configuration, Accounting, Performance, Security
FTP File Transfer Protocol
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
HAPS High Altitude Platform Station
HAT HAP Access Termination
IP Internet Protocol
IPL Inter Platform Links
ISDN Integrated Services Digital Network
ISP Internet Service Provider
ITU-T International Telecommunications Union – Telecoms sector
IWF Inter Working Function
MEGACOMedia Gateway Control
MGCP Media Gateway Control Protocol
OSI Open Standard Interconnect
OSPF Open Shortest Path First
PID Packet Identifier
PSTN Public Switched Telephone Network
QoS Quality of Service
ROI Return on Investment
RSVP Resource ReSerVation Protocol
SGSN Serving GPRS Support Node
SLA Service level agreements
SU Subscriber Units
TCP Transport Control Protocol
TMF Telemanagement Forum
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunication System
UTRAN UMTS Terrestrial Radio Access Network
VoD Video on Demand
VoIP Voice over IP
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 10 of 55
1. Introduction
This technical document describes the general network architecture requirements for
the CAPANINA communications architecture(s) for use with the applications and
services defined in deliverable D01 Candidate Applications and Services for
Broadband HAPS Delivery [1].
The report starts with the brief overview of the selected CAPANINA services and
applications from the network architecture point of view. The key point described here is
that broadband service providers face the challenge of connecting an enormous
number of diverse, relatively low-speed access services into their high-speed
backbones. Supporting a wide range of access interfaces is a potentially complex and
expensive undertaking but is necessary if all customers are to be served. HAPS offer
the potential to play an active role in providing broadband services in four core network
segments: access network, content distribution, core network trunk and HAPS private
networks.
Section 3 describes network topologies for selected CAPANINA service scenarios, for
both single and multiple HAPS architectures. The OSI reference model for each network
topology is also presented here. The multi-service network reference model combines
the multiple layers of terrestrial network architecture with the payload and customer
premise equipment architectures. Convergence creates a unified network that operates
cohesively to promote efficiency, enhance service features, and offer cost savings; seen
as key elements of today's competitive marketplace for broadband service provision.
Section 4 outlines the interworking requirements for connecting a HAPS network
segment with other network segments (i.e. backhaul to core network and also customer
premise equipment). The key issues described here include mobility, handover and
also Quality of Service (QoS) for IP services including VoIP.
Section 5 continues with the description of IP unicast and multicast routing requirements
at the network layer. The network layer is also a place where additional requirements
were defined for Authentication, Authorisation and Accounting (AAA) tasks.
The CAPANINA service management system and Operational Supporting System
(OSS) and subsystem components are also described in Section 6. These systems will
be used to support commercial aspects of CAPANINA service such as network
management, account management, system policy management, conditional access
and security, billing and usage tracking.
Sections 7, 8 and 9 provide a detailed description of main network elements used in
CAPANINA system, which are: payload, backhaul architecture and customer premise
equipment.
The report concludes with the main points in respect to general network requirements
from the service provision point of view.
2. CAPANINA Services and Applications Overview
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 11 of 55
The trend towards IP broadband access in the last two years has opened up new
service opportunities facilitated by the increase in bandwidth. High-quality streaming
entertainment video, videoconferencing and interactive gaming are just some of the
possibilities where the removal of the access bottle-neck significantly improves the
customer’s experience of the service.
In addition, broadband access facilitates the bundling of multiple services
simultaneously through the same access ‘pipe’. This opportunity also brings with it new
challenges for IP and its supporting network infrastructure and systems. The ability to
prioritise certain traffic types over others and incorporate quality-of-service (QoS)
guarantees will be key network differentiators in the new competitive broadband era.
The Internet Service Provider (ISP) business models are rapidly evolving from the
simple ‘connect to an ISP to download information’ approach. Increased functionality at
local access nodes (caching, switching, routing) may be required of some of the new
business models and applications.
The CAPANINA broadband access technology is set to compete with and/or
complement other access technologies as operators race to build the ‘best integrated
IP network’.
One of the most important advantages that CAPANINA technology has is the
multicast/broadcast capability that the HAPS platform can natively support. The IP
Multicast support has an especially important role, because most of the Digital
Subscriber Line (xDSL) network providers still do not permit IP Multicast traffic on the
core and access networks. To enable DSLAMs at the broadband access network (i.e.
local exchanges) to support IP Multicast will be a costly task, hence it might take some
time before we see IP Multicast services offered by xDSL service providers.
Broadcast capability of the HAPS platform will probably see its major role in
broadcasting HDTV.
2.1 Revisiting Candidate Services and Applications for HAPs from the Network
Architecture’s Point of View
In this subsection we summarize the proposed services used in HAP network, which
were define in [4]. Table 1 summarises the services and applications that were
identified as the potentially most suitable for HAPS.
Broadband
Internet
Access to
Residential/SO
HO
Special Events
and Disaster
recovery
Broadband
connection
WiFi on
trains and
bus-
coaches
WiFi
backhauling
Content
Distribution
Streaming
Media and TV
Broadcast
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 12 of 55
Business relevance
Providing
broadband
Internet access
to
residential/SO
HO market
Providing
broadband
Internet access
to special
events (e.g.
road shows,
concerts) and
disaster
affected areas
(e.g. floods,
earthquake,
motorway
accidents, etc.)
Providing
broadband
Internet
access to
passengers
inside the
trains and
bus-
coaches
Providing
backhaul
link to WiFi
Hotspot
Zones (e.g.
airports,
cafés, etc.)
Providing
IP-Multicast
based
content
distribution
services to
residential/
SOHO
market
HDTV
broadcast,
DAB Radio
broadcast,
event audio-
video
coverage
(e.g. pay-per-
view football
match,
concerts,
etc.)
Table 1. HAPS services and applications
According to deliverable D01 [1], services can be the classified as interactive or
distributed. Interactive services have a two-way exchange of information (other than
control signalling) between two subscribers or between a subscriber and a service
provider, and include the following categories:
 Conversational
 Messaging
 Retrieval services.
Distributed services are those in which information transfer is primarily one-way, from
service provider to subscriber. They include broadcast services, where the user has no
control over the presentation of the information, and cyclical services, which allow the
user some measure of presentation control.
Table 2 illustrates a set of examples for potential services and applications; based on
ITU classification, and that could be offered by the CAPANINA broadband service:
 Interactive conversational
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 13 of 55
Type of information Moving pictures and sound
Broadband services Video telephony, Videoconference, Video surveillance, Video/audio information
transmission service (DVB)
Applications E-learning, E-advertising, Mobile video surveillance, TV broadcasting
Requirements Multicast routing, restricted QoS: low delay and delay variation, loss tolerance,
variable bandwidth, media and signal gateway for not IP-based videoconference
(ISDN video), signal protocols (SIP, H.323).
Type of information Data
Broadband services High-rate unrestricted information Tx. service, FTP
Applications Wireless LAN´s interconnection, Data file transfer
Requirements Scheduling providing fairness, QoS: best-effort traffic class
Type of information Multimedia
Broadband services High resolution image communication service, Mixed document
communications service
Applications Desktop multimedia Mobile emergency services, Mobile tele working
Requirements QoS: High bandwidth, low delay and delay variation.
 Interactive messaging
Type of information Mixed documents
Broadband services Multimedia mail
Applications Electronic mailbox service for multimedia
Requirements QoS: Delay tolerant, best-effort
 Interactive retrieval
Type of information Tex, data, graphics, sound, still images, moving pictures
Broadband services Data retrieval service, Multimedia retrieval service
Applications E-commerce, Multimedia library, Tourist information, etc.
Requirements QoS: Delay tolerant, best-effort
 Distributed Broadcast
Type of information Video, Audio
Broadband services MPEG-2 or 4
Applications HDTV programs distribution, DAB
Requirements Multicast in 3 layer and 2 layer, mapping multicast address between these two
layers, caching to reduce network load.
Table 2. Types of Information, Services and Application suitable for HAPs
It is expected that Broadband Internet and Corporate Intranets are probably the main
drivers for HAPS with the broadband payload [4]. This requires that access to an ISP
(or ISPs) is provided for HAPS users. Broadband Internet gives access to a myriad of
services through the Internet, together with opportunities for access to company
Intranets, teleworking, etc. Broadband Corporate Intranets will also improve business
prospects in developing countries by connecting remote offices with the corporate
headquarter network.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 14 of 55
Many of the proposed candidate services for HAPS are native IP based (e.g. FTP,
email) or there exists an IP solution for the provision of the service (e.g. VoIP). Thus, it is
reasonable that the network architecture is based on IP solutions.
2.2 Classifying Candidate Services According to the Network Requirements
Different services demands different network architecture requirement. Thus we divide
the proposed services in two main categories:
 Native IP based services: High-rate unrestricted information transmission
service, FTP, High resolution image communication service, Mixed document
communications service, Data retrieval service, Multimedia retrieval service;
 Not native IP based services: Video telephony, ISDN videoconference, Video
surveillance, Video/audio information transmission service (DVB), MPEG-2 or 4,
Voice;
For the first group of services, general network requirements apply, which are specified
in the next chapter. The second group has higher Quality of Service (QoS) requirements
and also in some cases (e.g. DVB, MPEG-2 or 4, etc.) IP is not the most appropriate
technology for providing such services, thus some adaptations and additional
architecture requirements are necessary, as for example is specified in Section 4.3 of
this document.
3. CAPANINA Network Scenarios Overview
3.1 Network Topologies
Network architecture requirements depend also on the network topology targeted for
different market segments. A number of different network topologies [1] are foreseen for
the CAPANINA services as depicted in Figure 1 and include:
 Access Network – The HAPS connects the end user(s) to the core network edge.
This is the typical network configuration for broadband Internet/Intranet and for
multicast/broadcast services to (low cost) user terminals.
 Content Distribution – The HAPS is connected to content providers via the core
network (backhaul). The content is distributed via HAPS to end user terminals (e.g.
TV broadcast, Content Distribution Services via IP Multicast, VoD etc.). As above,
this configuration can be considered as an access network, but for content
distribution a high bandwidth is essential in the ground segment (content provider to
HAP).
 Core Network Trunk (Bearer Services) – The HAPS connects two points within
the core network. Point to point private circuits (bearer links) could form a part of the
core network perhaps as part of a core network overlay to provide network
resilience. The inter-HAPS connections were also considered here.
 HAP Private Network – The HAP connects two or more users to form a virtual
private network, with or without the direct connectivity to the core network. This is the
classic use of VSAT to provide a private data network, for example for point of sale
credit card authorisations, stock control, financial and insurance services.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 15 of 55
Figure 1: HAPS Connectivity
3.2 Single and Multiple HAPS Platfrom Case Scenarios
HAPS network architecture is best described as a Local Multipoint Distribution System
(LMDS). It is a radio technology that provides broadband network access to many
customers from a single or multiple HAPS platforms (base-station in the air).
Although LMDS specifically refers to a frequency allocation in the United States, the
term is generically used to refer to broadband, multi-service radio access systems.
These systems are also sometimes known by other terms, such as broadband wireless
access (BWA), broadband point-to-multipoint (PMP), or broadband wireless local loop
(B-WLL).
A major benefit of broadband radio access via HAPS is that once the HAPS platform is
in place, the remaining infrastructure required is only the customer units. Hence this
enables provision of high-bandwidth access in a very expedient manner.
The HAPS radio broadband system can be used to extend the coverage of terrestrial
broadband networks, such as fibre rings or ADSL, without the need to negotiate way-
leaves and build infrastructure, such as cable ducts (although it is usually necessary to
negotiate roof rights for both HAPS ground-station equipment and customer
equipment).
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 16 of 55
3.2.1 Single HAPS Platform Scenario
A single HAPS platform scenario (i.e. only one flying platform used) is envisaged for
providing an ad-hoc network for special events (e.g. Olympic games), disaster recovery
or rapid broadband employment over highly populated cities for either staged network
deployment whereby the large numbers of end users located in relatively small
geographical area might whish to access the broadband services.
Customers are connected within a ‘cell’ (i.e. HAPS footprint) that will typically have a
radius of around 40 km from the central base-station. The HAPS is usually connected to
the remainder of the network using fibre (tethered balloons) or point-to-point radio (for
airships). The ground-station acts as a hub for the network and provides service to
customers who are in direct line of sight with the HAPS antenna and within the cell
radius.
Generally, it is possible to further split the cell area into a number of sectors, which
allows the cell radius, and the capacity offered within a cell, to be increased. LMDS
allows flexibility in the way that capacity is allocated to customers, e.g. asymmetric
circuits can be allocated in addition to symmetric circuits and quality-of-service options
can be offered for data circuits. Many systems also allow bandwidth to be allocated on
demand.
The point-to-multipoint topology of an LMDS system is not dissimilar to that of a cable
modem in that the base-station sends information to all end customers within a radio
sector on a single radio link and the customer premises equipment selects the
information intended for it.
Typically single HAPS platform may provide an asymmetric capacity of say 200 Mbit/s
to be shared between the users in a cell, with the couple of Mbit/s capacity on the return
link, also shared (LMDS can outperform ADSL in terms of upstream data rates [11]).
The core network infrastructure used to connect to HAPS ground-stations is virtually the
same as that used to connect ADSL exchange units (DSLAMs) and hence the
technologies can be deployed in a complementary manner.
3.2.2 Multiple Platform Scenario
The main purpose of increasing the number of platforms is to provide national or
regional broadband coverage whereby inter-HAPS links form part of the overlay core
network with one or more gateway stations providing the backhaul connection to the
terrestrial core network.
Multiple HAPS platforms can also be deployed to serve a common coverage area in
order to increase the capacity provided per unit area (i.e. the bandwidth efficiency).
The other reasons for this platform configuration are to provide resilience (backup
systems) and also to provide spatial diversity to end users receiving antennas for
improved service availability (e.g. improved line-of-sight coverage).
Normally the coverage area is split into multiple cells to increase the capacity. This
technique can also be adopted with a multiple platform scenario. Multiple HAPS can
increase the capacity by exploiting the directionality of the fixed user antenna, which is
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 17 of 55
typically a dish with relatively narrow beamwidth. This narrow beamwidth is required to
provide sufficient gain to support the link budget, but additionally it can be exploited to
reduce levels of interference progressively from other HAPS arranged at an angle away
from the boresight of the user antenna.
HA
P
HAP 2 (core
connectivity)
HA
P
HAP 4
HA
P
HAP 3 (core
connectivity)
HA
P
HAP 1
Inter HAP optic links
HA
P
HAP 2 (core
connectivity)
HA
P
HAP 4
HA
P
HAP 3 (core
connectivity)
HA
P
HAP 1
Inter HAP optic links
Figure 2. Multi platform scenario illustration
3.3 Proposed Reference Model of Network Architecture
A HAP network may use either a non-regenerative or a regenerative HAP architecture:
 A non-regenerative architecture refers to a architecture, commonly called "bent-
pipe architecture". This architecture does not terminate any layers of the air
interface protocol stack in the HAPS - the HAPS simply transfers the signals
from the user links to the feeder links transparently. The implementation is easier
but the functionality is reduced
 A regenerative architecture is the range of architectures that provide additional
functionality in the HAPS. In these architectures, the HAPS functions terminate
one or more layers of the air interface protocol stack in the HAPS station. In
addition, the protocol stack can be terminated at higher layer thus enabling
additional functionality. For example, HAPS can be used as the router (network
layer termination), on-board packet switching for multiple HAP architectures,
signal regeneration, content buffer, etc. In addition the Mobility Anchor Point
(MAP) can be put on the HAPS in the case of supporting Mobile IP.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 18 of 55
3.3.1 Reference model for a Single HAP Architecture
A typical network architecture for providing IP based services to fixed users and fast
trains is depicted in Figure 3. It consists of a single HAPS platform, which is connected
via a backhaul link to a gateway (GW) station which connects to the Internet . Users are
connected via fixed or wireless LANs to a HAP Access Termination (HAT) node. The
main functionality of HAT is the interworking between the user terminal, via a common
interface (e.g. Ethernet adapter), on the user side and HAPS, via a radio interface (e.g.
adapted 802.16 SC), on the other side.
IP
backhaul link
user link
HAP
PDA
PDA
WLAN
WLAN
Gateway
user link
ER
HAT
HAT
Figure 3: Network architecture
However, from the network topologies and scenarios foreseen for the HAPS network,
the different simplified reference models can be derived and they are depicted in
Figure 4. Also the main interfaces are identified and summarised Table 3.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 19 of 55
Core / Content distribution scenario
HAP
Gateway
function
Access
function
I.HG
I.HT
I.HATU
I.HN
HAP
Gateway
function #2
Gateway
function #1
I.HG
I.HG
I.HN
I.HN
Access network scenario
HAP
Access
function
Access
function
I.HG
I.HT
I.HATU
Private network scenario
I.HATU
Figure 4: Simplified reference models
Interface Description
I.HN External interface between HAP Gateway function and terrestrial network
I.HG Internal Air Interface between Gateway and HAP (Backhaul link)
I.HT Internal Air Interface between Gateway and HAP
I.HATU External interface between HAP Access Termination Function and customer premises
/ "train" network.
Table 3. Interfaces for HAPS access
The Access Network scenario detailed reference architecture is depicted in Figure 5.
IP IWF
GW
802.16
SC
conver.
sublayer
PHY
DLL
HAP
802.16
SC
IP NETWORK
PHY
DLL
802.16
SC
conver.
sublayer
conver.
sublayer
IP / switch
IP IWF
HAP access
termination
conver.
sublayer
DLL
802.16
SC
PHY
IP
User
terminal
DLL
IP
Upper
layers
PHY
I.HT
I.HG
I.HN
I.HATU
Figure 5. Reference model of access network scenario
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 20 of 55
The Inter Working Function (IWF) occurs at both ends of the network. One type of the
IWF is required to translate the internal HAP interfaces (I.HN) to external network e.g. IP
network, while the other IWF is required to translate internal HAP interfaces (I.HATU) to
external interfaces of premises network e.g. W-LAN.
3.3.2 Reference model for a Multi HAPS Architecture
In the case of multi HAPS network there is an Inter-Platform Link (IPL) between two
HAPS, which represents an additional Network Interface I.HH as depicted in Figure 6.
I.HH is Internal air Interface between two HAPS. IPLs can be radio or optical. In the case
of multiple HAPS scenario only the regenerative architecture applies, as there is a need
for additional functionality (e.g. routing), which can fully exploit the capabilities of a multi-
HAP network. In the case of multi-HAP network a HAPS is not necessary connected to
a gateway, but can access the terrestrial network via neighbouring HAPS.
IP
IPL
IPL
Gateway
backhaul link
user link
HAP
HAP
HAP
PDA
PDA
WLAN
WLAN
Gateway
ER
ER
I.HH
I.HH
I.HT
I.HT
I.HT
I.HG
I.HG
I.HN
I.HN
HAT
HAT
HAT
Figure 6: Proposed Multi HAP Network architecture
Figure 7 depicts the reference model of a multi-HAP network scenario. It is worth noting
that each HAPS platform can be connected to one or more other HAPS. Thus, different
network topologies would apply (e.g. mesh).
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 21 of 55
HAP
radio /
optical
radio /
optical
conver.
sublayer
conver.
sublayer
IP / switch
I.HH
I.HH
I.HG / I.HT
HAP
radio /
optical
802.16
SC
conver.
sublayer
conver.
sublayer
IP / switch
HAP
802.16
SC
radio /
optical
conver.
sublayer
conver.
sublayer
IP / switch
I.HG / I.HT
Figure 7: Reference model of a multi-HAP network scenario
4. Interworking Requirements Between HAPS Networks and
Other Networks
Interworking with other networks is one of the main requirements of any communication
system. In general there are two primary ways of solving the interworking issues (i)
loose interworking and (ii) tight interworking [6].
Loose interworking is defined as the utilization of a HAPS network as an access
network complementary to current access networks. There are no common network
elements with other networks (i.e. avoiding the common SGSN, GGSN nodes, etc.). In
the case of loose interworking the HAPS network is more independent and flexible. In
order to provide IP compatibility, security, mobility, and QoS need to be addressed
using IETF schemes.
In the tight interworking case, a HAPS network is connected to some other network as a
sub-component. For example, a HAPS network can be connected to the UMTS network
(the core network) (HeliNET scenario) in the same manner as other UMTS radio access
technologies (UTRAN, GERAN). In this way, the mobility, QoS and security mechanisms
in the UMTS core network can be reused. In addition the GGSN is the interface
between the UMTS core network and the Internet. Similar requirements would apply to
satellite networks whereby the multi-HAPS platform might need to communicate with
each other via a satellite backhaul channel.
However, in either case, the ability to seamlessly integrate with different core networks
is seen as an essential requirement of the CAPANINA system. Of course, the long-term
vision of the New Generation Networks (NGN) in general is that all network components
will be complementary parts of fully integrated multi-platform multi-service global
network (e.g. definitions of 4G, 5G, etc.).
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 22 of 55
4.1 Mobility and Handover
The requirements for mobility and handover differ depending upon the type of networks
involved. Several different mobility options can be considered.
4.1.1 Mobility Within and Between HAPS Networks
 Mobility shall be supported between HAP networks belonging to different
administrative domains.
 Handover shall be provided within a HAP network belonging to the same
administrative domain. Handover might be performed based on a link layer
network handover procedure with the possible addition of higher layer mobility
protocols. In light of the All-IP concept, Mobile IP and all is variants are
recommended. The mobility issues will be addressed in WP 2.5.
 Handover should be supported within a HAP network belonging to different
administrative domains.
4.1.2 Mobility Between HAPS and Other Networks
 Full association and authentication will be needed within the respective network.
 Terminals shall support mobility between different HAP and other networks.
 Mobility between administrative domains shall be supported.
4.2 Quality of Service Requirements
When defining the HAPS Quality of Service (QoS) requirements, the restrictions and
limitations of the radio interface should be considered. Although it could be a very
complex task to define QoS mechanisms that include the air interface, the QoS
mechanisms provided in a HAPS network have to be robust and capable of providing
reasonable QoS solutions. The requirements are based on those specified for
Broadband Radio Access Networks [ETSI TR 101 957 [6], ETSI TR 101 031 [12], ETSI
TR 101 856 [3]].
The following capabilities should be supported in the overall QoS requirements for a
HAPS system
 QoS provisioning in HAP networks should be subject to user's subscription.
 It should be possible for a HAP network operator to monitor the QoS provided to
the users.
 It should be possible to charge a user based on the level of QoS provided and
on the QoS subscribed.
 The provisioning of QoS in HAP networks should have a minimum impact on the
provisioning of QoS in other networks.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 23 of 55
 It should be possible for applications to request QoS treatment for their
communications through one mechanism independently of the access network
used
 It should be possible to prevent unauthorized users to send (upstream)
inadmissible data through the network.
 Within HAP networks, QoS mechanisms towards external networks should be
aligned with the IP mechanisms (in order to simplify interworking with the
operator's ISP platform). Additionally it should be possible to easily integrate, in
the future, the IP Multimedia Subsystem QoS requirements.
4.2.1 IP QoS Requirements
By using existing or emerging IETF protocols (e.g. RSVP [17], etc.), the HAPS
networks and other networks can interwork without extensive modification. For the IP
service users the HAP network should provide a transparent service in terms of QoS
and mobility management.
4.3 Additional Requirements for VoIP Services and Applications
Although voice over IP (VoIP) has been in existence for many years, it is becoming
more and more popular and represents a viable alternative to traditional public switched
telephone networks (PSTN). In addition, VoIP promises to deliver a number of
additional and attractive features such as advanced call routing, computer integration,
unified messaging, integrated information services, long-distance toll bypass, and
encryption [7].
Because of the common network infrastructure, it is also possible to integrate other real
time and non-real time media services, which are particularly well suited for broadband
access networks (e.g. HAPS). In order to identify the requirements for VoIP services in
HAP networks we will first describe the VoIP features.
The basic VoIP functions are [7]:
 Signalling; Different signalling protocols are used in VoIP (e.g. SIP, H.323)
 Database services; Database services are used to locate an endpoint and
translate the addressing that two (usually heterogeneous) networks use. A call
control database contains these mappings and translations. Another important
feature is the generation of transaction reports for billing purposes.
 Call connect and disconnect (bearer control); In a VoIP implementation, the
connection is a multimedia stream (audio, video, or both) transported in real
time. This connection is the bearer channel and represents the voice or video
content being delivered. When communication is complete, the IP sessions are
released and network resources are optionally freed.
 CODEC operations Signalling; The process of converting analogue waveforms
to digital information is done with a coder-decoder. There are many ways an
analogue voice signal can be transformed, all of which are governed by various
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 24 of 55
standards. Each encoding scheme has its particular bandwidth needs. The
output from the CODECs is a data stream that is put into IP packets and
transported across the network to an endpoint. These endpoints must use the
standards, as well as a common set of CODEC parameters.
These functions have to be compatible with PSTN network. The major components of a
VoIP network, while different in approach, deliver very similar functionality to that of a
PSTN and enable VoIP networks to perform all of the same tasks that the PSTN does.
The one additional requirement is that VoIP networks must contain a gateway
component that enables VoIP calls to be sent to a PSTN, and visa versa.
There are four major components of a VoIP network [15]:
 Call Processing Server/IP PBX (Soft Switch)
 User End-Devices
 Media/VOIP Gateways
 IP network
The Call Processing Server / IP PBX (Soft Switch) is the main part of a VoIP phone
system as it manages all VoIP control connections. Call processing servers are usually
software-based and can be deployed as a single server, cluster of servers, or a server
farm with distributed functionality. It is worth noting that call processing servers do not
handle VoIP payload (which is the RTP stream carrying voice itself) traffic, but only
manages the VoIP control traffic follows. VoIP payload flows in a peer-to-peer fashion –
from every VoIP terminal to every other VoIP terminal. In this case, the VoIP terminals
determine traffic flows and the call processing servers negotiate those flows within the
control messages.
The user end-devices consist of VoIP phones and desktop-based devices. VoIP
phones maybe software based (“softphones”) or hardware based (“hard phones” or
“handsets”, like traditional phones) [7]. VoIP phones use the TCP/IP stack to
communicate with the IP network, and are therefore allocated an IP address for the
subnet on which they are installed. Softphones are software applications running on
notebook computers, usually targeted towards mobile users, which are particular
interesting in the case of the HAP network scenario, where users are travelling on high-
speed trains. They have the same basic features as VoIP phones.
The major function of media / VoIP gateways is analogue-to-digital conversion of voice
and creation of voice IP packets (CODEC functions) [7]. In addition, media gateways
have optional features, such as voice (analogue and/or digital) compression, echo
cancellation, silence suppression, and statistics gathering. The media gateway forms
the interface that the voice content uses so it can be transported over the IP network.
Media gateways are the sources of bearer traffic. Typically, each conversation (call) is a
single IP session transported by a Real-time Transport Protocol (RTP) that runs over the
User Datagram Protocol (UDP) or TCP.
The IP network must ensure smooth delivery of the voice and signalling packets to the
VoIP elements. Due to their dissimilarities, the IP network must treat voice and data
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 25 of 55
traffic differently. If an IP network is to carry both voice and data traffic, it must be able to
prioritise the different traffic types, as VoIP traffic is extremely sensitive to latency.
An example of a suitable VoIP architecture for a HAPS scenario is depicted in Figure
8. In general the VoIP users within the HAP network can communicate with VoIP users
connected to the IP network or to users which are connected to PSTN network (ISDN or
analogue) via Media and Signalling gateways. As the HAP network fully supports IP
there are no additional network elements required within the HAP network to support
VoIP. However, as there are more stringent requirements for the delay in VoIP
networks, the HAP network should provide differentiation of classes in order to fulfil the
delay requirements.
IP
backhaul link
user link
HAP
PDA
PDA
WLAN
WLAN
Gateway
user link
ER
HAT
HAT
Media
Gateway
PSTN
Signaling
Gateway
VoIP
VoIP
VoIP
Analog
ISDN
IP PBX
VoIP
VoIP
Figure 8: VoIP architecture for HAP network
In addition, the HAP network should support signalling protocols (e.g. SIP, H.323,
H.248/MEGACO, MGCP), which are used for call connect / disconnect and
management procedures.
The HAP network should also allow a common architecture for all real-time services and
it should envisage also the future services. The quality, reliability and availability of VoIP
services should be comparable to that of PSTN network.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 26 of 55
5. Network Layer Requirements
The network layer is the most critical part of the network architecture. Defining a network
layer in the user, control and management plane requires consideration of the trade-off
between the weight of the on-board payload, energy consumption and the number of
networking facilities. That is, any increase of the number and complexity of
functionalities in the network layer will increase the weight of the payload on-board and
the energy consumption at the same time.
5.1 Interworking between Layer 2 and Layer 3
The underlying wireless access technologies applied in HAP networks such as IEEE
802.16 have their own mechanisms to ensure QoS in the link-layer. To provide end-to-
end QoS, architectures such as Diff-Serv [18], Int-Serv [19] should be considered.
Mapping the link-layer QoS to IP layer QoS architecture is the primary task of the
adaptation sub layer.
Another important task of the convergence sub-layer is the mapping between IP
address and link-layer address or session id.
To enhance the performance of TCP, link-layer ARQ (Automated Repeat Request) can
be applied to hide the random losses from upper layers. ARQ is a link layer mechanism
to retransmit lost radio packets (link-layer data blocks). Without ARQ, any random loss
will be evaluated as the congestion loss by TCP. ARQ is one of the most effective
methods to enhance the performance of TCP.
For VoIP applications using UDP, delay is more important than the loss rate. ARQ
improves the loss rate but at the same time, increases the delay. This is the reason that
ARQ may not be required for VoIP. The decision whether to apply ARQ according to the
upper layer protocols or traffic classes is also the task of adaptation layer.
The convergence sub layer should be defined independently from the underlying link-
layer protocols. To this end, some assumptions about the link-layer should be selected
such as addressing, QoS, multicast and broadcast mechanisms. The assumptions
should be general in order to cover all candidate wireless standards for a HAP system.
Another important function of the convergence layer is the mapping of class D multicast
IP address into the Layer 2 multicast address. This will be discussed further in the next
subsection.
5.2 Routing Requirements
5.2.1 General Requirements for Routing
Inter-working in terms of routing is mandatory, which implies that the Border Gateway
Protocol (BGP) should be implemented at the border router between HAPS and other
IP network.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 27 of 55
The possible frequent link failures between HAPS or between HAP and the backhaul
network due to bad weather conditions such as rain and fog require quick link failure
detection and rerouting mechanisms with short repair time. The total repair time is the
service interruption time that is actually spent by a rerouting mechanism to restore a
communication after a link has failed.
Forwarding packets in an appropriate way to achieve a more balanced traffic load
(good traffic engineering) is an important factor to be taken into account in routing.
A scoring system (e.g. pros and cons) could be created in order to select the most
suitable routing protocol for HAPS.
5.2.2 Multicast Routing
The IP multicast protocols should be considered, especially the BGMP (Border
Gateway Multicast Protocol) should be implemented to enable co-operation with other
networks, e.g. back-haul terrestrial networks. The most important part of multicast
routing is the mapping of IP multicast addresses into link-layer addresses or sessions
to avoid data flooding (an intelligent CPE can filter out unwanted multicast packets at
Layer 2, minimizing interruption of the end system CPU).
Another important mechanism to be implemented in the HAP system for supporting
multicasting is dynamic address registration by the IGMP- Internet Group Management
Protocols). Periodic scanning is also required to detect finished groups and avoid
unnecessary data transferring for groups in which all member already finished their
multicast sessions.
5.2.3 Techniques for Performance Improvement
Some services may distribute repeated data in time, e.g. Video on Demand would
assemble the popular films into several parts and broadcast them periodically over the
network. Another example is that web users may request the same pages several
times. Mechanisms can be incorporated to detect and cache repeated content to
decrease the loading condition of the links and make the service available even in link
failure conditions.
Techniques for improving performance would increase the on-board payload complexity
and energy consumption. Methods need to be specified to balance the trade-off
between them.
5.2.4 Optional Technologies
One of the primary goals of HAPS is to provide broadband network access and QoS
support. Then additional technologies complementing IP such as ATM, MPLS that
comprises effective traffic engineering, VPN and QoS support should be analysed to
determine the advantages and disadvantages. Suggestions should be outlined to help
HAP network designers when or when not to apply these optional technologies.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 28 of 55
5.3 Authentication, Authorisation and Accounting (AAA)
A centralised AAA server is required to manage and control user access. Every HAPS
will act as NAS (Network Access Server), to forward user’s authentication information to
the centralised AAA server.
Selecting AAA architecture for may require modification in protocol structure, which
basically has an important implication on the implementation complexity of the protocol
stack in CPE as well as in the on-board base station.
The AAA architecture must support other functionalities of HAPS networks, such as
mobile roaming which will require authentication from the AAA server and updated
location information to the server.
6. Service Management Systems (SMS)
The CAPANINA service management system (SMS) will be responsible for handling
the functions of the HAPS platform that are required to support correct platform
operation but do not play a part in the delivery of services or content to the end user.
The CAPANINA SMS system is defined based on the TMF’s eTOM models for
technical OSS.
The standards bodies that are most active in OSS developments are the ITU-T, IETF,
Telecommunications Information Networking Architecture (TINA), The Parlay Group and
the Telemanagement Forum (TMF). The Telemanagement Forum (TMF) has
constructed a business and technical OSS framework called the Telecoms Operations
Map (TOM) and a second generation of this called the enterprise TOM (eTOM).
The support functions performed by the SMS will include user account management,
usage statistics collection and presentation, system policy management and billing
information collection and presentation.
6.1 Assumptions
The architecture of the CAPANINA SMS makes assumptions about the operation of the
CAPANINA system and the role of other parts of the system. These assumptions are:
 Usage statistics are collected somewhere on the CAPANINA platform (e.g. end
user’s devices, etc.) and passed to the SMS to be stored and reports generated.
 Billing information is collected somewhere on the CAPANINA platform (e.g.
based on usage statistics, etc.) and passed to the SMS to be stored and made
available to the OSS system.
 End-user, content provider and management access to the CAPANINA platform
is controlled by user accounts. These accounts are defined by the OSS system
and managed by the SMS.
 The SMS must link user account information to billing information.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 29 of 55
 The SMS controls access to the stored system policies and makes these
policies available to control the service or content provision (e.g. content
distribution and management systems).
6.2 Position and Role in the CAPANINA System
The CAPANINA SMS holds the responsibility for providing the support functions
necessary in order to enable service delivery. This effectively means that the SMS is an
overlay to the system providing services to the other subsystems and allows
communication with the external OSS. The SMS must provide the ability to store
important operational data such as billing and usage data as well as providing a
repository for system policy information and user accounts. The major architectural
components of the CAPANINA system must all be able to communicate with the SMS.
The SMS’ position in the CAPANINA platform is one of a central service, it must be
able to communicate with the other CAPANINA components and also requires external
interfaces in order to communicate with the OSS. Communication with the other
subsystems will require these subsystems to prepare data in the correct format and
submit it to the SMS for appropriate processing and storage.
6.3 Top Level Architecture
The top-level architecture of the CAPANINA SMS is shown as a functional diagram in
Figure 9.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 30 of 55
Figure 9: SMS Top Level Functional Architecture
6.4 Interfaces to Other CAPANINA Subsystems
The potential services and applications are detailed in deliverable D01 [1]. The
examples of SMS’s subsystems that would support a set of defined services could
include (this list is not exhaustive):
 Internet provision subsystem for broadband Internet access
 Content Distribution (CDS) and Content Management Subsystems (CMS) for
Content Distribution Service including Streaming Video and Audio applications
 Platform Front-end subsystem (including CPE)
The interface to the CDS provides the ability for the SMS to pass system policy
information to the CDS to indicate constraints and defaults that the CDS must use. The
CMS interface provides the ability to configure the CMS with system policies, but also
provides the ability to receive billing and usage tracking information. The interface to
the platform front end provides the ability for content providers to access information
and policies relating to their content and to view information about the usage of their
SMS
Account Management
Usage
Collection
OSS Interface
System Policy
Management
CDS Interface
Database
OSS Interface
CMS Interface
Information from CPE
Front End
Management
Billing
Collection
Billing Data
Data Sources
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 31 of 55
content. The front-end interface also provides the ability for end users to view or adjust
information about their account and bill status.
The SMS also provides an interface to an OSS system. The OSS interface provides
the ability for account and access management and for the provision of billing data to
the OSS.
6.4.1 Content Distribution Subsystem Interface
The CDS interface is used by the SMS to ensure that the CDS is provided with the
latest set of platform policies. The CDS will contain a scheduler that requires a set of
system policies in order that its operation appropriately reflects the current system
management goals. The scheduler will make use of this interface to contact the SMS
policy management function. The policy manager will retrieve policies appropriate to
the CDS and return them on this interface.
6.4.2 Content Management Subsystem Interface
The CMS interface is used for three purposes. This interface will allow policy
information to be supplied to the CMS, the CMS will also be able to return billing
information and usage tracking information to the SMS.
In order to operate effectively, the CMS will require information from the SMS on the
current set of system policies that are relevant to content management. The CMS will
access the SMS in order to retrieve system policies that reflect how the CMS should
meet the system management goals.
In order for the CAPANINA operator to have a workable business model appropriate
charges for content will be required. The CMS will collect the billing information from
charging of content providers or charging of end users for access to DRM licenses. In
order for billing information to be properly used and shared with the OSS it must be
handled by the SMS. The billing information will be transferred to the SMS via the CMS
interface. The SMS will then assemble this information appropriately and store it in the
database.
An important function of the CAPANINA system management is to enable the operator
to understand what content is of interest to the end user population. Usage tracking
information relating to which items of content are being used by end users will be
returned from the CPE via the CMS. This usage tracking information will be transferred
from the CMS to the SMS on the CMS interface. The SMS will then marshal this
information appropriately (e.g. advertising hit-page scores statistics, etc.) and store it in
the database.
6.4.3 Platform Portal Interface
The platform portal is used by end users and content providers to access features that
the CAPANINA platform provides for external control and configuration. In terms of the
SMS these features vary according to the access granted to the portal user. However
the complete feature list exposed is read-only access to usage statistics, read and write
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 32 of 55
access to content management policies, read and partial write access to end user
account information and read only access to billing information.
Read only access to usage statistics is provided to content providers relating to their
content via the platform portal. When this information is requested the portal retrieves a
report of usage via this interface.
Read and write access to content policies is provided to a content provider relating to
their content via the platform portal. When this information is requested or updated the
platform portal takes action via this interface. The interface must provide the ability to
retrieve data as well as update stored information.
Read and partial write access is provided for end users to view the information the
platform holds about them and update certain parts of this data. When data is
accessed or updated via the platform portal this interface is used. The interface
provides the ability for the portal to retrieve data records and update stored information
.
Read only access to billing information is provided so that any third party likely to be
billed by the platform can access the data about the bill they have generated so far.
When billing information is requested via the portal this interface is used. The interface
provides the ability for the portal to request retrieval of billing data going back variable
lengths of time and appropriate data is returned.
6.4.4 OSS Interface
The CAPANINA platform does not contain an OSS and will therefore require support
from a separate system. This separate OSS will provide the ability to manage user
accounts and deal with billing information. The first capability of this interface therefore
provides access to the SMS such that the OSS can send commands and data.
Commands will be taken from a set of user management actions including tasks such
as create user and cease user. The data associated with these commands will relate to
the user account including items such as user name and account status. The second
capability of this interface is for the OSS to request the latest billing information. The
interface will allow the SMS to track what information the OSS has confirmed reception
of and will pass unsent billing data when requested. This mechanism provides basic
billing integrity, but more robust methods may be implemented during solution design.
Other OSS functions will include configuration, alarms, topology tracking and updates,
SLA policing and fault detection and recovery work-flow algorithms, etc.
6.5 Internal Architecture
The Internal architecture of the SMS reflects those functions it must carry out. The SMS
must manage system policies, usage and billing information and expose those
appropriately to other platform components. The architecture is considered at a top
level and each functional component is considered separately.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 33 of 55
6.5.1 Database
The database is used by the SMS to store all records and data required for
management of the CAPANINA platform and to enable this information to be provided
to other systems or end users. These records include, billing records, usage
information, customer account information, end user authentication credentials and
system policies relating to the CDS and CMS. Other subsystems will not have the
ability to connect directly to this database, as access will be solely via the SMS in order
to maintain proper data integrity.
This database will take the form of a relational database and since much of the data
held is key to system operation a reasonably high level of availability will be sought. The
SMS will access this database using SQL queries via an appropriate API.
6.5.2 Account Management
The account management function of the SMS covers two types of account. Some
accounts relate to service providers or content providers while others relate to end-
users. For each type of account the SMS must maintain details of the access rights of
the account holder and information relating to the “real-world” identity of the account
holder. For end user accounts the records must also contain links to their billing history
and methods of payment.
For a service provider or content provider the major function of the account manager is
to control the level of access the provider in question has to control system policies and
retrieve data. For example, one provider may not have the right to retrieve usage
information and must not be allowed to see second provider’s policies. Access control
for provider accounts will therefore consist of a stored list of authorisations relating to
the policy manager, the usage and billing systems and the CMS to manage content.
Alongside this access control data, the account manager must hold data on the identity
of the service provider and who to contact within that provider.
For an end user, the account manager will hold details of the level of subscription and
therefore which CAPANINA services the user may access. This system will also hold
details of which parts of the CAPANINA customer front end a particular user may
access. This will control access to the DRM licensing system for license requests and
visibility of the end user’s billing data. It is expected that by default all end users will be
able to modify some of their account details on the platform. Alongside this access
control, the account manager must hold details of the “real” identity of the end user and
details of how to bill them.
6.5.3 System Policy Management
The system policy manager provides access for the platform administrator to modify the
policies stored in the database and provides a controlled access point for other
CAPANINA subsystems to receive the most current platform policies in order that the
platform can be effectively managed. Platform administrators include CAPANINA
operators and content providers updating policies relating to their content.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 34 of 55
Access for platform administrators to update policies will be a defined interface placing
constraints on the manner in which policies are defined. This interface must be easily
accessible and is therefore likely to be provided via java servlets provided from a web
server. The policy manager will ensure that no policies contradict and that policies input
are valid before storing them in the database such that the other CAPANINA
subsystems may access them.
The policy manager manages access for other systems to retrieve policy information,
but other systems are expected to pull this information when they require it. As a result,
this aspect of the policy manager simply requires a defined command set to retrieve
relevant policies.
6.5.4 Usage Collection
The usage collection is an important functional requirement of the CAPANINA service
provision aimed for providing information regarding the applications and/or content
which are most popular among the end users. For example, the usage tracking
information could be used for electronic advertising hit-page scoring.
The usage collection agent must provide a mechanism for correctly formatting and
storing usage tracking information passed to it and this must be coupled to a retrieval
method such that administrators, including external providers, can retrieve information
about usage.
The usage storage mechanism is expected to be relatively simple, an interface will be
exposed and records will be passed to it. These records will be formatted
appropriately and stored in the database.
Retrieval access will allow administrators to use a web-based interface via the platform
portal to view usage statistics. The account manager will control access rights to this
interface so that providers can only view statistics relating to their own content while the
platform operator has full access.
6.5.5 Billing Collection
The billing collection agent must provide a mechanism for correctly formatting and
storing billing information passed to it and this must be coupled to a retrieval method
such that administrators, including external providers and end users, can retrieve
information about billing. Further to this the billing store must also provide access for
the OSS to retrieve billing data.
The billing storage mechanism is expected to be relatively simple, an interface will be
exposed and records will be passed to it. These records will be formatted
appropriately and stored in the database.
Retrieval access will allow administrators to use a web-based interface via the platform
portal to view billing statistics. The account manager will control access rights to this
interface so that providers can only view statistics relating to their own content while the
platform operator has full access. End users will gain access via the platform portal in
order to view summary information about the status of their bill.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 35 of 55
The OSS will require the ability to download billing data in order to generate end users
bills. An interface to the OSS will be provided and the billing collection agent will
manage access to the records in the database. The key feature of this managed
access is a confirmation mechanism so that the integrity of the records sent to the OSS
is guaranteed and those records received by the OSS are strongly defined. This will
mean that it is always perfectly clear which billing records the OSS has received to
prevent duplication or omission.
6.6 Network Management System
In order to support the commercial broadband service, the CAPANINA network must be
managed from the CAPANINA Customer Service Centre (CCSC). From here the
operations staff will have access to the CAPANINA network components (e.g.
equipment and interfaces to backhaul connections, equipment and interfaces to HAPS
platform, OSS interfaces (as described in Section 6.4.4), customer premise
equipment, etc.) from a centralised management system and will be able to administer
fault management remotely.
Most of the centralised management systems utilise the HP OpenView application. This
application uses the Simple Network Management Protocol (SNMP) in order to collect
data on the status of the network. The live network status is then represented on the
operator’s terminal.
Should a fault be detected in the network, the remote devise will generate an error
message and report this back to management system. Should the device itself become
unable to communicate, its neighbouring network elements will report the event. This
method relies on the network element being SNMP compliant. If a network element is
not SMNP compliant, an SNMP agent device is used to convert between the proprietary
protocol and SNMP. The complexity of these devices will differ dependant upon the
proprietary protocol.
The depth of the SNMP management is dependant upon the information provided by
the customer-sited equipment. All SNMP managed equipment will come with a
standard management information base (MIB) that will be integrated into the HP
OpenView management platform. Note that this will encompass element management
only.
6.6.1 Network Management Requirements
The CAPANINA Network Management System has to enable the following
management aspects typically used in IP networks [3].
 Fault and Performance management The protocols must enable fault and
performance monitoring, as well as provide a means for local and remote
testing. The management functionality must include reboot, reactivation and
shutdown capabilities.
 Configuration and software upgrade management The protocols must enable
both local and remote configuration including the updating of software in any
device in the network without service interruption.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 36 of 55
 Security The system shall enable centralized authentication and authorization
services.
 Service management The protocols must permit operators to enforce service
level agreements (SLAs) with subscribers by restricting access to the link,
discarding data, dynamically controlling the bandwidth available to a user or
other appropriate techniques. The protocols must permit the subscriber to
monitor the performance at the subscriber units (SU).
 Interoperability The network management system shall enable provisioning and
operation of a number of different SU provided by several suppliers.
 Accounting and Auditing The system management framework, architecture,
protocols, and managed objects must allow for operators to effectively
administer accounting and auditing, by making available the relevant information
to an external billing system. An operator must be able to account for time- and
bandwidth utilization (i.e. throughput) and the various QoS parameters for each
subscriber.
7. HAPS Payload General Architectures
In general terms, the HAPS payload can be processing or transparent. A processing
payload is defined here as one that demodulates the signal and makes decisions about
switching or routing based on the contents of packet headers. A transparent payload is
one that re-transmits the received signal without demodulation. It is immaterial whether
analogue or digital channel filters are used or whether the carriers are switched
between beams according to a schedule.
It is assumed that satellites in geostationary orbits are the only type of platform that will
incorporate a transparent payload. This is because non-geostationary satellites and
HAPS will use steerable beams with cross-polarisation correction and the benefit of
these cannot be realised with transparent transponders.
HAPS systems offering 3G services would need to offer interoperability with standard
3G handsets used today, although the spectrum allocation to HAPS systems might
prevent this. The Ka and V-band capacity could be utilised to provide a fat-pipe
backbone channel between the platform and terrestrial gateway station.
The network integration requirements (i.e. backhaul to terrestrial gateways, end-user
CPE equipment, inter HAPS links, etc.) bring some complexity-load on payload
configuration. For example, the carrier signals would need to be terminated
(demodulated, decoded, decrypted, etc.), switched and routed towards the appropriate
spot-beam or backbone link. Therefore the HAPS platforms for mobile communications
tend to use on-board processing (OBP) payloads.
An overview of both types of payload is given in this section and the trade-offs
identified.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 37 of 55
7.1 Transparent Payload Overview
The transparent payloads are typically used by GEO satellites for applications where
Doppler translation and re-transmission of up-link noise is less a problem and where
multiple spot-beams are not required.
The benefits of a transparent payload for a satellite are:
1. High flexibility, since even if digital filtering or scheduled switching is used, these
can be re-programmed from the ground
2. Easy separation of service provider traffic (i.e. separately leased bandwidth at
Layer 1)
3. Long life since the technology is not so inclined to be superseded
4. Relatively low cost (comparing to a processing payload cost)
These benefits are not as important for a HAPS system because of their ease of
retrieval.
7.1.1 Specific Technical Issues with Transparent Payload
The specific technical issues considered in respect to transparent payloads are:
 Doppler shift, which is translated from uplink to downlink for transparent payloads
and can make the overall (uplink plus downlink) Doppler shift worse or better
depending on frequencies and orbit types.
 Correlation of fades. The earth station receiving the downlink will suffer outages
due to fades on the uplink and downlink, but these may not be correlated.
 Transponder resource is either power or bandwidth limited
For an example, in case of an FDMA scenario with a transparent payload, where many
narrow band signals pass through one quasi-linear transponder, on-board filtering and a
level control on each uplink could be advantageous in giving a constant downlink EIRP
for each uplink. Without automatic level control (ALC) the uplink fade reduction of uplink
signal will automatically appear as the same reduction of EIRP on the corresponding
downlink signal. Although the on-board level control will not prevent degradation of
uplink C/N, the overall end-to-end C/N degradation with ALC will be less than without
ALC. The implementation of filtering and ALC is probably most easily achieved by
means of sampling/ digital filtering techniques, especially if many simultaneous uplinks
are present.
For processing payload the ALC is typically provided by the on-board demodulation
process.
General Network Architecture Requirements CAP-D13-WP13-BT-PUB-01
28th April 2005 FP6-IST-2003-506745 CAPANINA Page 38 of 55
7.2 Processing Payload Overview
This type of payload performs switching or routing of packets, based on information
demodulated from the packet headers. If switching, the address will be read from the
link-layer (Layer 2) header and if routing, it is necessary also to read the network layer
(Layer 3) header. Most of the processing payloads on satellite platforms are switching
types (Layer 2 only) that use short fixed length cells, for example the Hughes Spaceway
[8] and EuroSkyWay [9].
Routers flown on payloads are more complicated and could result in higher probability
of failure and shortened lifetime. However, this is not a problem for HAPS technology
since the platform may be brought down for maintenance and payload upgrade.
The benefits of processing payloads for V-band deployments are:
1. Doppler is not transferred (although this may make Doppler worse for V-band –
V band links)
1
2. Uplink and downlink fades can be de-correlated