general network architecture requirements - · pdf filegeneral network architecture...

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 1st May 2005

Actual Date of Delivery to the CEC 28th 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 CAPANINAcommunications architecture(s) for use with the applications and services defined in deliverable D01,Candidate Applications and Services for Broadband HAPS Delivery. The report describes networktopologies for both single and multiple HAPS architectures including the OSI reference model for eachnetwork topology. The network layer requirements are also presented. The report defines the keynetwork elements of the CAPANINA system including the general payload architecture, backhaulnetwork and customer premise equipment architectures. The CAPANINA service management systemand 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 networkmanagement, 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 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 ofapproval

Revision

Role of approver Approver Affiliation

28/04/2005 01 Editor (Internal reviewer) Paul Mitchell UOY

28/04/2005 01 On behalf of ScientificBoard

David Grace UOY



EXECUTIVE SUMMARY

This technical document describes the general network architecture requirements forthe CAPANINA communications architecture(s) for use with the applications andservices defined in deliverable D01, Candidate Applications and Services forBroadband HAPS Delivery [1].

The broadband service providers of today face the challenge of connecting anenormous number of diverse, relatively low-speed access services into their high-speedbackbones. Supporting a wide range of access interfaces is a potentially complex andexpensive undertaking but is necessary if all customers are to be served. HAPS offersignificant potential to play an active role in providing broadband services in four corenetwork segments: access network, content distribution, core network trunk and HAPSprivate networks.

This report describes network topologies for all four selected CAPANINA networkscenarios, for both single and multiple HAPS architectures. The OSI reference modelfor each network topology and network layer requirements are also presented here. TheCAPANINA OSI network reference model combines the multiple layers of terrestrialnetwork 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'scompetitive marketplace for broadband service provision. The network layerrequirements 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 includingthe general payload architecture, backhaul network and customer premise equipmentarchitectures. The CAPANINA service management system and OperationalSupporting System (OSS) and its subsystem components are also described in thisdocument. These systems will be used to support commercial aspects of theCAPANINA service such as network management, account management, systempolicy management, conditional access and security, billing and usage tracking.



TABLE OF CONTENTS

1. INTRODUCTION..............................................................................................................10

2. CAPANINA SERVICES AND APPLICATIONS OVERVIEW............................................102.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.........................................................143.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 OTHERNETWORKS .....................................................................................................................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...........................................................................265.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) ................................................................286.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



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...........................................................367.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....................................................................408.1 Backhaul Bandwidth Specification ......................................................................................42

8.2 Additional Service Providers and Roles................................................................................43

9. CUSTOMER PREMISE EQUIPMENT ARCHITECTURE.............................................449.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



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



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



LIST OF ACRONYMS

BGP Border Gateway ProtocolCA Conditional AccessCPE Customer Premise EquipmentDSLAM Digital Subscriber Line Access MultiplexerDVB Digital Video BroadcastingETOM Enterprise Telecoms Operations ModelFAB Fulfilment, Assurance, BillingFCAPS Fault, Configuration, Accounting, Performance, SecurityFTP File Transfer ProtocolGGSN Gateway GPRS Support NodeGPRS General Packet Radio ServiceHAPS High Altitude Platform StationHAT HAP Access TerminationIP Internet ProtocolIPL Inter Platform LinksISDN Integrated Services Digital NetworkISP Internet Service ProviderITU-T International Telecommunications Union – Telecoms sectorIWF Inter Working FunctionMEGACO Media Gateway ControlMGCP Media Gateway Control ProtocolOSI Open Standard InterconnectOSPF Open Shortest Path FirstPID Packet IdentifierPSTN Public Switched Telephone NetworkQoS Quality of ServiceROI Return on InvestmentRSVP Resource ReSerVation ProtocolSGSN Serving GPRS Support NodeSLA Service level agreementsSU Subscriber UnitsTCP Transport Control ProtocolTMF Telemanagement ForumUDP User Datagram ProtocolUMTS Universal Mobile Telecommunication SystemUTRAN UMTS Terrestrial Radio Access NetworkVoD Video on DemandVoIP Voice over IP



1. Introduction

This technical document describes the general network architecture requirements forthe CAPANINA communications architecture(s) for use with the applications andservices defined in deliverable D01 Candidate Applications and Services forBroadband HAPS Delivery [1].

The report starts with the brief overview of the selected CAPANINA services andapplications from the network architecture point of view. The key point described here isthat broadband service providers face the challenge of connecting an enormousnumber of diverse, relatively low-speed access services into their high-speedbackbones. Supporting a wide range of access interfaces is a potentially complex andexpensive undertaking but is necessary if all customers are to be served. HAPS offerthe potential to play an active role in providing broadband services in four core networksegments: access network, content distribution, core network trunk and HAPS privatenetworks.

Section 3 describes network topologies for selected CAPANINA service scenarios, forboth single and multiple HAPS architectures. The OSI reference model for each networktopology is also presented here. The multi-service network reference model combinesthe multiple layers of terrestrial network architecture with the payload and customerpremise equipment architectures. Convergence creates a unified network that operatescohesively to promote efficiency, enhance service features, and offer cost savings; seenas key elements of today's competitive marketplace for broadband service provision.

Section 4 outlines the interworking requirements for connecting a HAPS networksegment with other network segments (i.e. backhaul to core network and also customerpremise equipment). The key issues described here include mobility, handover andalso Quality of Service (QoS) for IP services including VoIP.

Section 5 continues with the description of IP unicast and multicast routing requirementsat the network layer. The network layer is also a place where additional requirementswere 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 willbe used to support commercial aspects of CAPANINA service such as networkmanagement, account management, system policy management, conditional accessand security, billing and usage tracking.

Sections 7, 8 and 9 provide a detailed description of main network elements used inCAPANINA system, which are: payload, backhaul architecture and customer premiseequipment.

The report concludes with the main points in respect to general network requirementsfrom the service provision point of view.

2. CAPANINA Services and Applications Overview



The trend towards IP broadband access in the last two years has opened up newservice opportunities facilitated by the increase in bandwidth. High-quality streamingentertainment video, videoconferencing and interactive gaming are just some of thepossibilities where the removal of the access bottle-neck significantly improves thecustomer’s experience of the service.

In addition, broadband access facilitates the bundling of multiple servicessimultaneously through the same access ‘pipe’. This opportunity also brings with it newchallenges for IP and its supporting network infrastructure and systems. The ability toprioritise 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 thesimple ‘connect to an ISP to download information’ approach. Increased functionality atlocal access nodes (caching, switching, routing) may be required of some of the newbusiness models and applications.

The CAPANINA broadband access technology is set to compete with and/orcomplement other access technologies as operators race to build the ‘best integratedIP network’.

One of the most important advantages that CAPANINA technology has is themulticast/broadcast capability that the HAPS platform can natively support. The IPMulticast support has an especially important role, because most of the DigitalSubscriber Line (xDSL) network providers still do not permit IP Multicast traffic on thecore 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 sometime before we see IP Multicast services offered by xDSL service providers.

Broadcast capability of the HAPS platform will probably see its major role inbroadcasting HDTV.

2.1 Revisiting Candidate Services and Applications for HAPs from the NetworkArchitecture’s Point of View

In this subsection we summarize the proposed services used in HAP network, whichwere define in [4]. Table 1 summarises the services and applications that wereidentified as the potentially most suitable for HAPS.

BroadbandInternetAccess toResidential/SOHO

Special Eventsand DisasterrecoveryBroadbandconnection

WiFi ontrains andbus-coaches

WiFibackhauling

ContentDistribution

StreamingMedia and TV

Broadcast



Bus

ines

s re

leva

nce

ProvidingbroadbandInternet accesstoresidential/SOHO market

ProvidingbroadbandInternet accessto specialevents (e.g.road shows,concerts) anddisasteraffected areas(e.g. floods,earthquake,motorwayaccidents, etc.)

ProvidingbroadbandInternetaccess topassengersinside thetrains andbus-coaches

Providingbackhaullink to WiFiHotspotZones (e.g.airports,cafés, etc.)

ProvidingIP-Multicastbasedcontentdistributionservices toresidential/SOHOmarket

HDTVbroadcast,DAB Radiobroadcast,event audio-videocoverage(e.g. pay-per-view footballmatch,concerts,etc.)

Table 1. HAPS services and applications

According to deliverable D01 [1], services can be the classified as interactive ordistributed. Interactive services have a two-way exchange of information (other thancontrol signalling) between two subscribers or between a subscriber and a serviceprovider, and include the following categories:

• Conversational• Messaging• Retrieval services.

Distributed services are those in which information transfer is primarily one-way, fromservice provider to subscriber. They include broadcast services, where the user has nocontrol over the presentation of the information, and cyclical services, which allow theuser some measure of presentation control.

Table 2 illustrates a set of examples for potential services and applications; based onITU classification, and that could be offered by the CAPANINA broadband service:

• Interactive conversational



Type of information Moving pictures and soundBroadband services Video telephony, Videoconference, Video surveillance, Video/audio information

transmission service (DVB)Applications E-learning, E-advertising, Mobile video surveillance, TV broadcastingRequirements 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 DataBroadband services High-rate unrestricted information Tx. service, FTPApplications Wireless LAN´s interconnection, Data file transferRequirements Scheduling providing fairness, QoS: best-effort traffic class

Type of information MultimediaBroadband services High resolution image communication service, Mixed document

communications serviceApplications Desktop multimedia Mobile emergency services, Mobile tele workingRequirements QoS: High bandwidth, low delay and delay variation.

• Interactive messaging

Type of information Mixed documentsBroadband services Multimedia mailApplications Electronic mailbox service for multimediaRequirements QoS: Delay tolerant, best-effort

• Interactive retrieval

Type of information Tex, data, graphics, sound, still images, moving picturesBroadband services Data retrieval service, Multimedia retrieval serviceApplications E-commerce, Multimedia library, Tourist information, etc.Requirements QoS: Delay tolerant, best-effort

• Distributed Broadcast

Type of information Video, AudioBroadband services MPEG-2 or 4Applications HDTV programs distribution, DABRequirements 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 maindrivers 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 ofservices through the Internet, together with opportunities for access to companyIntranets, teleworking, etc. Broadband Corporate Intranets will also improve businessprospects in developing countries by connecting remote offices with the corporateheadquarter network.



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 isreasonable 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 dividethe proposed services in two main categories:

• Native IP based services: High-rate unrestricted information transmissionservice, FTP, High resolution image communication service, Mixed documentcommunications service, Data retrieval service, Multimedia retrieval service;

• Not native IP based services: Video telephony, ISDN videoconference, Videosurveillance, Video/audio information transmission service (DVB), MPEG-2 or 4,Voice;

For the first group of services, general network requirements apply, which are specifiedin the next chapter. The second group has higher Quality of Service (QoS) requirementsand also in some cases (e.g. DVB, MPEG-2 or 4, etc.) IP is not the most appropriatetechnology for providing such services, thus some adaptations and additionalarchitecture requirements are necessary, as for example is specified in Section 4.3 ofthis document.

3. CAPANINA Network Scenarios Overview

3.1 Network Topologies

Network architecture requirements depend also on the network topology targeted fordifferent market segments. A number of different network topologies [1] are foreseen forthe 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 formulticast/broadcast services to (low cost) user terminals.

• Content Distribution – The HAPS is connected to content providers via the corenetwork (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 contentdistribution a high bandwidth is essential in the ground segment (content provider toHAP).

• Core Network Trunk (Bearer Services) – The HAPS connects two points withinthe core network. Point to point private circuits (bearer links) could form a part of thecore network perhaps as part of a core network overlay to provide networkresilience. The inter-HAPS connections were also considered here.

• HAP Private Network – The HAP connects two or more users to form a virtualprivate network, with or without the direct connectivity to the core network. This is theclassic use of VSAT to provide a private data network, for example for point of salecredit card authorisations, stock control, financial and insurance services.



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 manycustomers from a single or multiple HAPS platforms (base-station in the air).

Although LMDS specifically refers to a frequency allocation in the United States, theterm is generically used to refer to broadband, multi-service radio access systems.These systems are also sometimes known by other terms, such as broadband wirelessaccess (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 isin place, the remaining infrastructure required is only the customer units. Hence thisenables provision of high-bandwidth access in a very expedient manner.

The HAPS radio broadband system can be used to extend the coverage of terrestrialbroadband 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 tonegotiate roof rights for both HAPS ground-station equipment and customerequipment).



3.2.1 Single HAPS Platform Scenario

A single HAPS platform scenario (i.e. only one flying platform used) is envisaged forproviding an ad-hoc network for special events (e.g. Olympic games), disaster recoveryor rapid broadband employment over highly populated cities for either staged networkdeployment whereby the large numbers of end users located in relatively smallgeographical area might whish to access the broadband services.

Customers are connected within a ‘cell’ (i.e. HAPS footprint) that will typically have aradius of around 40 km from the central base-station. The HAPS is usually connected tothe remainder of the network using fibre (tethered balloons) or point-to-point radio (forairships). The ground-station acts as a hub for the network and provides service tocustomers who are in direct line of sight with the HAPS antenna and within the cellradius.

Generally, it is possible to further split the cell area into a number of sectors, whichallows the cell radius, and the capacity offered within a cell, to be increased. LMDSallows flexibility in the way that capacity is allocated to customers, e.g. asymmetriccircuits can be allocated in addition to symmetric circuits and quality-of-service optionscan be offered for data circuits. Many systems also allow bandwidth to be allocated ondemand.

The point-to-multipoint topology of an LMDS system is not dissimilar to that of a cablemodem in that the base-station sends information to all end customers within a radiosector on a single radio link and the customer premises equipment selects theinformation intended for it.

Typically single HAPS platform may provide an asymmetric capacity of say 200 Mbit/sto be shared between the users in a cell, with the couple of Mbit/s capacity on the returnlink, 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 thesame as that used to connect ADSL exchange units (DSLAMs) and hence thetechnologies 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 orregional broadband coverage whereby inter-HAPS links form part of the overlay corenetwork with one or more gateway stations providing the backhaul connection to theterrestrial core network.

Multiple HAPS platforms can also be deployed to serve a common coverage area inorder to increase the capacity provided per unit area (i.e. the bandwidth efficiency).The other reasons for this platform configuration are to provide resilience (backupsystems) and also to provide spatial diversity to end users receiving antennas forimproved service availability (e.g. improved line-of-sight coverage).

Normally the coverage area is split into multiple cells to increase the capacity. Thistechnique can also be adopted with a multiple platform scenario. Multiple HAPS canincrease the capacity by exploiting the directionality of the fixed user antenna, which is



typically a dish with relatively narrow beamwidth. This narrow beamwidth is required toprovide sufficient gain to support the link budget, but additionally it can be exploited toreduce levels of interference progressively from other HAPS arranged at an angle awayfrom the boresight of the user antenna.

HAP

HAP 2 (core connectivity)

HAPHAP 4

HAPHAP 3 (core

connectivity)

HAPHAP 1

Inter HAP optic links

HAP

HAP 2 (core connectivity)

HAPHAP 4

HAPHAP 3 (core

connectivity)

HAPHAP 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 airinterface protocol stack in the HAPS - the HAPS simply transfers the signalsfrom the user links to the feeder links transparently. The implementation is easierbut the functionality is reduced

• A regenerative architecture is the range of architectures that provide additionalfunctionality in the HAPS. In these architectures, the HAPS functions terminateone or more layers of the air interface protocol stack in the HAPS station. Inaddition, the protocol stack can be terminated at higher layer thus enablingadditional functionality. For example, HAPS can be used as the router (networklayer 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.



3.3.1 Reference model for a Single HAP Architecture

A typical network architecture for providing IP based services to fixed users and fasttrains is depicted in Figure 3. It consists of a single HAPS platform, which is connectedvia a backhaul link to a gateway (GW) station which connects to the Internet . Users areconnected via fixed or wireless LANs to a HAP Access Termination (HAT) node. Themain functionality of HAT is the interworking between the user terminal, via a commoninterface (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

PDAWLAN

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 inFigure 4. Also the main interfaces are identified and summarised Table 3.



Core / Content distribution scenario

HAPGatewayfunction

Accessfunction

I.HGI.HTI.HATU I.HN

HAP Gatewayfunction #2

Gatewayfunction #1

I.HGI.HGI.HN I.HN

Access network scenario

HAPAccessfunction

Accessfunction

I.HGI.HTI.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.16SC

conver.sublayer

PHY

DLL

HAP

802.16SC

IP NETWORK

PHY

DLL802.16SC

conver.sublayer

conver.sublayer

IP / switchIP IWF

HAP accesstermination

conver.sublayer

DLL 802.16SCPHY

IP

Userterminal

DLL

IP

Upperlayers

PHY

I.HT I.HG I.HNI.HATU

Figure 5. Reference model of access network scenario



The Inter Working Function (IWF) occurs at both ends of the network. One type of theIWF is required to translate the internal HAP interfaces (I.HN) to external network e.g. IPnetwork, while the other IWF is required to translate internal HAP interfaces (I.HATU) toexternal 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 twoHAPS, 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 caseof multiple HAPS scenario only the regenerative architecture applies, as there is a needfor 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 toa gateway, but can access the terrestrial network via neighbouring HAPS.

IP

IPLIPL

Gateway

back

haul

link us

er li

nk

HAP

HAP

HAP

PDA

PDAWLAN

WLAN

Gateway

ER

ER

I.HHI.HH

I.HT

I.HT

I.HT

I.HG

I.HG

I.HNI.HN

HATHAT

HAT

Figure 6: Proposed Multi HAP Network architecture

Figure 7 depicts the reference model of a multi-HAP network scenario. It is worth notingthat each HAPS platform can be connected to one or more other HAPS. Thus, differentnetwork topologies would apply (e.g. mesh).



HAP

radio /optical

radio /optical

conver.sublayer

conver.sublayer

IP / switch

I.HH I.HH I.HG / I.HT

HAP

radio /optical

802.16SC

conver.sublayer

conver.sublayer

IP / switch

HAP

802.16SC

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 andOther Networks

Interworking with other networks is one of the main requirements of any communicationsystem. 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 accessnetwork complementary to current access networks. There are no common networkelements with other networks (i.e. avoiding the common SGSN, GGSN nodes, etc.). Inthe case of loose interworking the HAPS network is more independent and flexible. Inorder to provide IP compatibility, security, mobility, and QoS need to be addressedusing IETF schemes.

In the tight interworking case, a HAPS network is connected to some other network as asub-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 accesstechnologies (UTRAN, GERAN). In this way, the mobility, QoS and security mechanismsin the UMTS core network can be reused. In addition the GGSN is the interfacebetween the UMTS core network and the Internet. Similar requirements would apply tosatellite networks whereby the multi-HAPS platform might need to communicate witheach other via a satellite backhaul channel.

However, in either case, the ability to seamlessly integrate with different core networksis seen as an essential requirement of the CAPANINA system. Of course, the long-termvision of the New Generation Networks (NGN) in general is that all network componentswill be complementary parts of fully integrated multi-platform multi-service globalnetwork (e.g. definitions of 4G, 5G, etc.).



4.1 Mobility and Handover

The requirements for mobility and handover differ depending upon the type of networksinvolved. 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 differentadministrative domains.

• Handover shall be provided within a HAP network belonging to the sameadministrative domain. Handover might be performed based on a link layernetwork handover procedure with the possible addition of higher layer mobilityprotocols. In light of the All-IP concept, Mobile IP and all is variants arerecommended. The mobility issues will be addressed in WP 2.5.

• Handover should be supported within a HAP network belonging to differentadministrative 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 andlimitations of the radio interface should be considered. Although it could be a verycomplex task to define QoS mechanisms that include the air interface, the QoSmechanisms provided in a HAPS network have to be robust and capable of providingreasonable QoS solutions. The requirements are based on those specified forBroadband Radio Access Networks [ETSI TR 101 957 [6], ETSI TR 101 031 [12], ETSITR 101 856 [3]].

The following capabilities should be supported in the overall QoS requirements for aHAPS 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 tothe users.

• It should be possible to charge a user based on the level of QoS provided andon the QoS subscribed.

• The provisioning of QoS in HAP networks should have a minimum impact on theprovisioning of QoS in other networks.



• It should be possible for applications to request QoS treatment for theircommunications through one mechanism independently of the access networkused

• 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 bealigned with the IP mechanisms (in order to simplify interworking with theoperator's ISP platform). Additionally it should be possible to easily integrate, inthe 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 HAPSnetworks and other networks can interwork without extensive modification. For the IPservice users the HAP network should provide a transparent service in terms of QoSand 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 becomingmore and more popular and represents a viable alternative to traditional public switchedtelephone networks (PSTN). In addition, VoIP promises to deliver a number ofadditional and attractive features such as advanced call routing, computer integration,unified messaging, integrated information services, long-distance toll bypass, andencryption [7].

Because of the common network infrastructure, it is also possible to integrate other realtime and non-real time media services, which are particularly well suited for broadbandaccess networks (e.g. HAPS). In order to identify the requirements for VoIP services inHAP 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 andtranslate the addressing that two (usually heterogeneous) networks use. A callcontrol database contains these mappings and translations. Another importantfeature is the generation of transaction reports for billing purposes.

• Call connect and disconnect (bearer control); In a VoIP implementation, theconnection is a multimedia stream (audio, video, or both) transported in realtime. This connection is the bearer channel and represents the voice or videocontent being delivered. When communication is complete, the IP sessions arereleased and network resources are optionally freed.

• CODEC operations Signalling; The process of converting analogue waveformsto digital information is done with a coder-decoder. There are many ways ananalogue voice signal can be transformed, all of which are governed by various



standards. Each encoding scheme has its particular bandwidth needs. Theoutput from the CODECs is a data stream that is put into IP packets andtransported across the network to an endpoint. These endpoints must use thestandards, as well as a common set of CODEC parameters.

These functions have to be compatible with PSTN network. The major components of aVoIP network, while different in approach, deliver very similar functionality to that of aPSTN 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 gatewaycomponent 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 phonesystem as it manages all VoIP control connections. Call processing servers are usuallysoftware-based and can be deployed as a single server, cluster of servers, or a serverfarm with distributed functionality. It is worth noting that call processing servers do nothandle VoIP payload (which is the RTP stream carrying voice itself) traffic, but onlymanages 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 terminalsdetermine traffic flows and the call processing servers negotiate those flows within thecontrol messages.

The user end-devices consist of VoIP phones and desktop-based devices. VoIPphones maybe software based (“softphones”) or hardware based (“hard phones” or“handsets”, like traditional phones) [7]. VoIP phones use the TCP/IP stack tocommunicate with the IP network, and are therefore allocated an IP address for thesubnet on which they are installed. Softphones are software applications running onnotebook computers, usually targeted towards mobile users, which are particularinteresting 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 voiceand creation of voice IP packets (CODEC functions) [7]. In addition, media gatewayshave optional features, such as voice (analogue and/or digital) compression, echocancellation, silence suppression, and statistics gathering. The media gateway formsthe 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 asingle IP session transported by a Real-time Transport Protocol (RTP) that runs over theUser Datagram Protocol (UDP) or TCP.

The IP network must ensure smooth delivery of the voice and signalling packets to theVoIP elements. Due to their dissimilarities, the IP network must treat voice and data



traffic differently. If an IP network is to carry both voice and data traffic, it must be able toprioritise 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 Figure8. In general the VoIP users within the HAP network can communicate with VoIP usersconnected to the IP network or to users which are connected to PSTN network (ISDN oranalogue) via Media and Signalling gateways. As the HAP network fully supports IPthere are no additional network elements required within the HAP network to supportVoIP. However, as there are more stringent requirements for the delay in VoIPnetworks, the HAP network should provide differentiation of classes in order to fulfil thedelay requirements.

IP

backh

aul lin

k

user link

HAP

PDA

PDAWLAN

WLAN

Gateway

user

link

ER

HAT

HAT

MediaGateway

PSTN

SignalingGateway

VoIP

VoIP

VoIP

AnalogISDN

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 andmanagement procedures.

The HAP network should also allow a common architecture for all real-time services andit should envisage also the future services. The quality, reliability and availability of VoIPservices should be comparable to that of PSTN network.



5. Network Layer Requirements

The network layer is the most critical part of the network architecture. Defining a networklayer in the user, control and management plane requires consideration of the trade-offbetween the weight of the on-board payload, energy consumption and the number ofnetworking facilities. That is, any increase of the number and complexity offunctionalities in the network layer will increase the weight of the payload on-board andthe 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 IEEE802.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 theadaptation sub layer.

Another important task of the convergence sub-layer is the mapping between IPaddress and link-layer address or session id.

To enhance the performance of TCP, link-layer ARQ (Automated Repeat Request) canbe applied to hide the random losses from upper layers. ARQ is a link layer mechanismto retransmit lost radio packets (link-layer data blocks). Without ARQ, any random losswill be evaluated as the congestion loss by TCP. ARQ is one of the most effectivemethods to enhance the performance of TCP.

For VoIP applications using UDP, delay is more important than the loss rate. ARQimproves the loss rate but at the same time, increases the delay. This is the reason thatARQ may not be required for VoIP. The decision whether to apply ARQ according to theupper 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 selectedsuch as addressing, QoS, multicast and broadcast mechanisms. The assumptionsshould 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 multicastIP address into the Layer 2 multicast address. This will be discussed further in the nextsubsection.

5.2 Routing Requirements

5.2.1 General Requirements for Routing

Inter-working in terms of routing is mandatory, which implies that the Border GatewayProtocol (BGP) should be implemented at the border router between HAPS and otherIP network.



The possible frequent link failures between HAPS or between HAP and the backhaulnetwork due to bad weather conditions such as rain and fog require quick link failuredetection and rerouting mechanisms with short repair time. The total repair time is theservice interruption time that is actually spent by a rerouting mechanism to restore acommunication 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 mostsuitable routing protocol for HAPS.

5.2.2 Multicast Routing

The IP multicast protocols should be considered, especially the BGMP (BorderGateway Multicast Protocol) should be implemented to enable co-operation with othernetworks, e.g. back-haul terrestrial networks. The most important part of multicastrouting is the mapping of IP multicast addresses into link-layer addresses or sessionsto avoid data flooding (an intelligent CPE can filter out unwanted multicast packets atLayer 2, minimizing interruption of the end system CPU).

Another important mechanism to be implemented in the HAP system for supportingmulticasting is dynamic address registration by the IGMP- Internet Group ManagementProtocols). Periodic scanning is also required to detect finished groups and avoidunnecessary data transferring for groups in which all member already finished theirmulticast sessions.

5.2.3 Techniques for Performance Improvement

Some services may distribute repeated data in time, e.g. Video on Demand wouldassemble the popular films into several parts and broadcast them periodically over thenetwork. Another example is that web users may request the same pages severaltimes. Mechanisms can be incorporated to detect and cache repeated content todecrease the loading condition of the links and make the service available even in linkfailure conditions.

Techniques for improving performance would increase the on-board payload complexityand energy consumption. Methods need to be specified to balance the trade-offbetween them.

5.2.4 Optional Technologies

One of the primary goals of HAPS is to provide broadband network access and QoSsupport. Then additional technologies complementing IP such as ATM, MPLS thatcomprises effective traffic engineering, VPN and QoS support should be analysed todetermine the advantages and disadvantages. Suggestions should be outlined to helpHAP network designers when or when not to apply these optional technologies.



5.3 Authentication, Authorisation and Accounting (AAA)

A centralised AAA server is required to manage and control user access. Every HAPSwill act as NAS (Network Access Server), to forward user’s authentication information tothe centralised AAA server.

Selecting AAA architecture for may require modification in protocol structure, whichbasically has an important implication on the implementation complexity of the protocolstack in CPE as well as in the on-board base station.

The AAA architecture must support other functionalities of HAPS networks, such asmobile roaming which will require authentication from the AAA server and updatedlocation information to the server.

6. Service Management Systems (SMS)

The CAPANINA service management system (SMS) will be responsible for handlingthe functions of the HAPS platform that are required to support correct platformoperation 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 fortechnical OSS.

The standards bodies that are most active in OSS developments are the ITU-T, IETF,Telecommunications Information Networking Architecture (TINA), The Parlay Group andthe Telemanagement Forum (TMF). The Telemanagement Forum (TMF) hasconstructed a business and technical OSS framework called the Telecoms OperationsMap (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 billinginformation collection and presentation.

6.1 Assumptions

The architecture of the CAPANINA SMS makes assumptions about the operation of theCAPANINA system and the role of other parts of the system. These assumptions are:

• Usage statistics are collected somewhere on the CAPANINA platform (e.g. enduser’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 madeavailable to the OSS system.

• End-user, content provider and management access to the CAPANINA platformis controlled by user accounts. These accounts are defined by the OSS systemand managed by the SMS.

• The SMS must link user account information to billing information.



• The SMS controls access to the stored system policies and makes thesepolicies available to control the service or content provision (e.g. contentdistribution and management systems).

6.2 Position and Role in the CAPANINA System

The CAPANINA SMS holds the responsibility for providing the support functionsnecessary in order to enable service delivery. This effectively means that the SMS is anoverlay to the system providing services to the other subsystems and allowscommunication with the external OSS. The SMS must provide the ability to storeimportant operational data such as billing and usage data as well as providing arepository for system policy information and user accounts. The major architecturalcomponents 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 beable to communicate with the other CAPANINA components and also requires externalinterfaces in order to communicate with the OSS. Communication with the othersubsystems will require these subsystems to prepare data in the correct format andsubmit 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 inFigure 9.



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]. Theexamples of SMS’s subsystems that would support a set of defined services couldinclude (this list is not exhaustive):

• Internet provision subsystem for broadband Internet access

• Content Distribution (CDS) and Content Management Subsystems (CMS) forContent 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 policyinformation to the CDS to indicate constraints and defaults that the CDS must use. TheCMS interface provides the ability to configure the CMS with system policies, but alsoprovides the ability to receive billing and usage tracking information. The interface tothe platform front end provides the ability for content providers to access informationand policies relating to their content and to view information about the usage of their

SMS

Account Management

UsageCollection

OSS Interface

System PolicyManagement

CD

S In

terfa

ce

Database

OSS Interface

CMS Interface

Info

rmat

ion

from

CP

E

Front EndManagement

BillingCollection

Bill

ing

Dat

a

Data Sources



content. The front-end interface also provides the ability for end users to view or adjustinformation about their account and bill status.

The SMS also provides an interface to an OSS system. The OSS interface providesthe ability for account and access management and for the provision of billing data tothe OSS.

6.4.1 Content Distribution Subsystem Interface

The CDS interface is used by the SMS to ensure that the CDS is provided with thelatest set of platform policies. The CDS will contain a scheduler that requires a set ofsystem policies in order that its operation appropriately reflects the current systemmanagement goals. The scheduler will make use of this interface to contact the SMSpolicy management function. The policy manager will retrieve policies appropriate tothe 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 policyinformation to be supplied to the CMS, the CMS will also be able to return billinginformation and usage tracking information to the SMS.

In order to operate effectively, the CMS will require information from the SMS on thecurrent set of system policies that are relevant to content management. The CMS willaccess the SMS in order to retrieve system policies that reflect how the CMS shouldmeet the system management goals.

In order for the CAPANINA operator to have a workable business model appropriatecharges for content will be required. The CMS will collect the billing information fromcharging of content providers or charging of end users for access to DRM licenses. Inorder for billing information to be properly used and shared with the OSS it must behandled by the SMS. The billing information will be transferred to the SMS via the CMSinterface. The SMS will then assemble this information appropriately and store it in thedatabase.

An important function of the CAPANINA system management is to enable the operatorto understand what content is of interest to the end user population. Usage trackinginformation relating to which items of content are being used by end users will bereturned from the CPE via the CMS. This usage tracking information will be transferredfrom the CMS to the SMS on the CMS interface. The SMS will then marshal thisinformation appropriately (e.g. advertising hit-page scores statistics, etc.) and store it inthe database.

6.4.3 Platform Portal Interface

The platform portal is used by end users and content providers to access features thatthe CAPANINA platform provides for external control and configuration. In terms of theSMS these features vary according to the access granted to the portal user. Howeverthe complete feature list exposed is read-only access to usage statistics, read and write



access to content management policies, read and partial write access to end useraccount information and read only access to billing information.

Read only access to usage statistics is provided to content providers relating to theircontent via the platform portal. When this information is requested the portal retrieves areport of usage via this interface.

Read and write access to content policies is provided to a content provider relating totheir content via the platform portal. When this information is requested or updated theplatform portal takes action via this interface. The interface must provide the ability toretrieve data as well as update stored information.

Read and partial write access is provided for end users to view the information theplatform holds about them and update certain parts of this data. When data isaccessed or updated via the platform portal this interface is used. The interfaceprovides 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 bebilled 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 interfaceprovides the ability for the portal to request retrieval of billing data going back variablelengths of time and appropriate data is returned.

6.4.4 OSS Interface

The CAPANINA platform does not contain an OSS and will therefore require supportfrom a separate system. This separate OSS will provide the ability to manage useraccounts and deal with billing information. The first capability of this interface thereforeprovides 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 suchas create user and cease user. The data associated with these commands will relate tothe user account including items such as user name and account status. The secondcapability of this interface is for the OSS to request the latest billing information. Theinterface will allow the SMS to track what information the OSS has confirmed receptionof and will pass unsent billing data when requested. This mechanism provides basicbilling 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 SMSmust manage system policies, usage and billing information and expose thoseappropriately to other platform components. The architecture is considered at a toplevel and each functional component is considered separately.



6.5.1 Database

The database is used by the SMS to store all records and data required formanagement of the CAPANINA platform and to enable this information to be providedto other systems or end users. These records include, billing records, usageinformation, customer account information, end user authentication credentials andsystem policies relating to the CDS and CMS. Other subsystems will not have theability to connect directly to this database, as access will be solely via the SMS in orderto maintain proper data integrity.

This database will take the form of a relational database and since much of the dataheld is key to system operation a reasonably high level of availability will be sought. TheSMS 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. Someaccounts 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 ofthe account holder and information relating to the “real-world” identity of the accountholder. For end user accounts the records must also contain links to their billing historyand methods of payment.

For a service provider or content provider the major function of the account manager isto control the level of access the provider in question has to control system policies andretrieve data. For example, one provider may not have the right to retrieve usageinformation and must not be allowed to see second provider’s policies. Access controlfor provider accounts will therefore consist of a stored list of authorisations relating tothe 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 identityof 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 andtherefore which CAPANINA services the user may access. This system will also holddetails of which parts of the CAPANINA customer front end a particular user mayaccess. This will control access to the DRM licensing system for license requests andvisibility of the end user’s billing data. It is expected that by default all end users will beable to modify some of their account details on the platform. Alongside this accesscontrol, the account manager must hold details of the “real” identity of the end user anddetails of how to bill them.

6.5.3 System Policy Management

The system policy manager provides access for the platform administrator to modify thepolicies stored in the database and provides a controlled access point for otherCAPANINA subsystems to receive the most current platform policies in order that theplatform can be effectively managed. Platform administrators include CAPANINAoperators and content providers updating policies relating to their content.



Access for platform administrators to update policies will be a defined interface placingconstraints on the manner in which policies are defined. This interface must be easilyaccessible and is therefore likely to be provided via java servlets provided from a webserver. The policy manager will ensure that no policies contradict and that policies inputare valid before storing them in the database such that the other CAPANINAsubsystems 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 retrieverelevant policies.

6.5.4 Usage Collection

The usage collection is an important functional requirement of the CAPANINA serviceprovision aimed for providing information regarding the applications and/or contentwhich are most popular among the end users. For example, the usage trackinginformation could be used for electronic advertising hit-page scoring.

The usage collection agent must provide a mechanism for correctly formatting andstoring usage tracking information passed to it and this must be coupled to a retrievalmethod such that administrators, including external providers, can retrieve informationabout usage.

The usage storage mechanism is expected to be relatively simple, an interface will beexposed and records will be passed to it. These records will be formattedappropriately and stored in the database.

Retrieval access will allow administrators to use a web-based interface via the platformportal to view usage statistics. The account manager will control access rights to thisinterface so that providers can only view statistics relating to their own content while theplatform operator has full access.

6.5.5 Billing Collection

The billing collection agent must provide a mechanism for correctly formatting andstoring billing information passed to it and this must be coupled to a retrieval methodsuch that administrators, including external providers and end users, can retrieveinformation about billing. Further to this the billing store must also provide access forthe OSS to retrieve billing data.

The billing storage mechanism is expected to be relatively simple, an interface will beexposed and records will be passed to it. These records will be formattedappropriately and stored in the database.

Retrieval access will allow administrators to use a web-based interface via the platformportal to view billing statistics. The account manager will control access rights to thisinterface so that providers can only view statistics relating to their own content while theplatform operator has full access. End users will gain access via the platform portal inorder to view summary information about the status of their bill.



The OSS will require the ability to download billing data in order to generate end usersbills. An interface to the OSS will be provided and the billing collection agent willmanage access to the records in the database. The key feature of this managedaccess is a confirmation mechanism so that the integrity of the records sent to the OSSis guaranteed and those records received by the OSS are strongly defined. This willmean that it is always perfectly clear which billing records the OSS has received toprevent duplication or omission.

6.6 Network Management System

In order to support the commercial broadband service, the CAPANINA network must bemanaged from the CAPANINA Customer Service Centre (CCSC). From here theoperations staff will have access to the CAPANINA network components (e.g.equipment and interfaces to backhaul connections, equipment and interfaces to HAPSplatform, OSS interfaces (as described in Section 6.4.4), customer premiseequipment, etc.) from a centralised management system and will be able to administerfault management remotely.

Most of the centralised management systems utilise the HP OpenView application. Thisapplication uses the Simple Network Management Protocol (SNMP) in order to collectdata on the status of the network. The live network status is then represented on theoperator’s terminal.

Should a fault be detected in the network, the remote devise will generate an errormessage and report this back to management system. Should the device itself becomeunable to communicate, its neighbouring network elements will report the event. Thismethod relies on the network element being SNMP compliant. If a network element isnot SMNP compliant, an SNMP agent device is used to convert between the proprietaryprotocol and SNMP. The complexity of these devices will differ dependant upon theproprietary protocol.

The depth of the SNMP management is dependant upon the information provided bythe customer-sited equipment. All SNMP managed equipment will come with astandard management information base (MIB) that will be integrated into the HPOpenView management platform. Note that this will encompass element managementonly.

6.6.1 Network Management Requirements

The CAPANINA Network Management System has to enable the followingmanagement aspects typically used in IP networks [3].

• Fault and Performance management The protocols must enable fault andperformance monitoring, as well as provide a means for local and remotetesting. The management functionality must include reboot, reactivation andshutdown capabilities.

• Configuration and software upgrade management The protocols must enableboth local and remote configuration including the updating of software in anydevice in the network without service interruption.



• Security The system shall enable centralized authentication and authorizationservices.

• Service management The protocols must permit operators to enforce servicelevel agreements (SLAs) with subscribers by restricting access to the link,discarding data, dynamically controlling the bandwidth available to a user orother appropriate techniques. The protocols must permit the subscriber tomonitor the performance at the subscriber units (SU).

• Interoperability The network management system shall enable provisioning andoperation 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 effectivelyadminister accounting and auditing, by making available the relevant informationto an external billing system. An operator must be able to account for time- andbandwidth utilization (i.e. throughput) and the various QoS parameters for eachsubscriber.

7. HAPS Payload General Architectures

In general terms, the HAPS payload can be processing or transparent. A processingpayload is defined here as one that demodulates the signal and makes decisions aboutswitching or routing based on the contents of packet headers. A transparent payload isone that re-transmits the received signal without demodulation. It is immaterial whetheranalogue or digital channel filters are used or whether the carriers are switchedbetween beams according to a schedule.

It is assumed that satellites in geostationary orbits are the only type of platform that willincorporate a transparent payload. This is because non-geostationary satellites andHAPS will use steerable beams with cross-polarisation correction and the benefit ofthese cannot be realised with transparent transponders.

HAPS systems offering 3G services would need to offer interoperability with standard3G handsets used today, although the spectrum allocation to HAPS systems mightprevent this. The Ka and V-band capacity could be utilised to provide a fat-pipebackbone channel between the platform and terrestrial gateway station.

The network integration requirements (i.e. backhaul to terrestrial gateways, end-userCPE equipment, inter HAPS links, etc.) bring some complexity-load on payloadconfiguration. For example, the carrier signals would need to be terminated(demodulated, decoded, decrypted, etc.), switched and routed towards the appropriatespot-beam or backbone link. Therefore the HAPS platforms for mobile communicationstend to use on-board processing (OBP) payloads.

An overview of both types of payload is given in this section and the trade-offsidentified.



7.1 Transparent Payload Overview

The transparent payloads are typically used by GEO satellites for applications whereDoppler translation and re-transmission of up-link noise is less a problem and wheremultiple 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, thesecan be re-programmed from the ground

2. Easy separation of service provider traffic (i.e. separately leased bandwidth atLayer 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 ofretrieval.

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 payloadsand can make the overall (uplink plus downlink) Doppler shift worse or betterdepending on frequencies and orbit types.

• Correlation of fades. The earth station receiving the downlink will suffer outagesdue 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 manynarrow band signals pass through one quasi-linear transponder, on-board filtering and alevel control on each uplink could be advantageous in giving a constant downlink EIRPfor each uplink. Without automatic level control (ALC) the uplink fade reduction of uplinksignal will automatically appear as the same reduction of EIRP on the correspondingdownlink signal. Although the on-board level control will not prevent degradation ofuplink C/N, the overall end-to-end C/N degradation with ALC will be less than withoutALC. The implementation of filtering and ALC is probably most easily achieved bymeans of sampling/ digital filtering techniques, especially if many simultaneous uplinksare present.

For processing payload the ALC is typically provided by the on-board demodulationprocess.



7.2 Processing Payload Overview

This type of payload performs switching or routing of packets, based on informationdemodulated from the packet headers. If switching, the address will be read from thelink-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 switchingtypes (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 probabilityof failure and shortened lifetime. However, this is not a problem for HAPS technologysince 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

3. Multi-beam operation is efficient.

The benefit of fade de-correlation can be enhanced by the use of on-board cachingalthough this would increase the complexity and restrict the flexibility of use.

7.2.1 Specific Technical Issues with Processing Payloads

The specific technical issues considered with the respect to processing payloads are:

• Mesh networks are an objective of processing payloads

• Overhead of managing queues is higher in order to tolerate fades

• Signalling reliability of resource management needs to be higher in order totolerate fades

7.3 Queuing

The management of queues is a principal overhead on the processor; there will typicallybe at least one queue per uplink beam and one per downlink spot-beam. Thereforeeach packet will need to be processed by at least two queues and they are notindependent, therefore the theory underlying the overall delay is not trivial. Packets haveto be ordered and removed from queues to comply with delay and delay variationrequirements and to co-operate with mechanisms such as early packet discard2.

1 This may be counter-intuitive, but for transparent transponders that are spectrum-inverting which means that the uplink Dopplershift is subtracted from the downlink Doppler shift when considering the whole link. If the two are de-correlated the amount ofDoppler shift on the downlink can be increased.2 When ATM cells packets are discarded by a network node, the PDU that contains them is rendered useless andEPD discards the remainder of the cells in the PDU to save transmission energy.



If packets are switched, the processor has to read the addresses and consult a look-uptable for the correct beam number. If packets are additionally routed, there will berequirement to consult a routing table and to accommodate routing table updateprotocols such as OSPF. The queue will also contain packets of varying priority, whichwill mean additional re-ordering, and possible discarding.

The overhead with managing queues will be higher when the payload is operating athigher frequency bands, e.g. V-band, because of interruptions to the link. This will causepackets to arrive incomplete and result in an increase in useless cells in the queues andincomplete packets at any layer 3 processes. The payload would have to make adecision on whether to search out and discard these cells from within queues or waituntil they reach the head of the queue before discarding them.

The amount by which the overhead is increased is proposed as a subject to further work(i.e. exploration work).

7.4 Line of Sight Requirements

One of the key limitations with LMDS is the requirement for a line-of-sight path betweenthe customer and the base-station. In the case of HAPS, this limitation is not as critical(as it is the case with terrestrial LMDS systems) mainly because of the higher elevationangles between the HAPS platform and the customer equipment antenna.

Of course, non-line of sight technologies such as OFDM type of carriers (e.g. WiMAX),will open a door to a mass market, hence HAPS technology will become an even moreviable solution to ISPs.

Millimetre wave systems are affected by rain and snow as these cause the signal to beattenuated leading to an increased bit error rate on a link. However, the impact of thesepropagation impairments is well understood and can be accounted for by appropriatelink margins in the network design.

7.5 Spectrum Allocation

One of the factors that have the greatest impact on whether an operator can deployHAPS is the availability of radio spectrum. Since radio spectrum is generally licensedby government agencies, an operator will have to bid for a licence before being able touse the technology.

The ITU designated the 37.2-GHz to 47.5-GHz and 47.9-GHz to 48.2-GHz bands (socalled V-band) for use by HAPS systems globally and also called for the study offrequency use in the 18-GHz to 32-GHz bands (so called Ka-band), used by point-to-point, fixed satellite systems (FSS) to distribute national and international services suchas voice, data and television programming to cable TV systems. Figure 10 illustratesthe spectrum allocation for HAPS systems.



Figure 10. HAPS spectrum allocation

The cost of the licences could affect the viability of using HAPS in some countries. Inaddition, the customer units need to match equivalent DSL or cable modem units.Therefore, the use of HAPS will be focused on broadcast and content distributionapplications because they can be used in a way of sharing the common costs among anumber of users to reduce the cost per customer.

8. Backhaul Network Architecture

The CAPANINA SMS provides an interface to the backhaul network connection. Thebackhaul pipe capacity will be tailored to provide an agreed service quality (e.g. serviceavailability, etc.) based on the typical service conditions, such as contention ratio,typical data rate per end-user, services and applications offered, etc.

Figure 11 illustrates the CAPANINA backhaul network architecture.



Figure 11. CAPANINA backhaul network architecture illustration

The backhaul network will provide interfaces to following two network segments:

1. A single aggregating connection between the CAPANINA SMS and the ISPnetwork and backhauling this to the Internet. For example, this can be a leasedline. The bandwidth of this aggregated pipe is governed by the CAPANINAservice requirements.

2. A network of private ADSL broadband connections between Content Providersand CAPANINA SMS (for example “BT IP Stream” product offered by BritishTelecom in UK [4]). The proposed solution is to provide content publishers’(remote locations) with a standard broadband ADSL access (e.g. 2 Mbit/s) to aprivate IP infrastructure. This means that although the physical connections areprovided via the same core network (i.e. standard broadband ADSL network),this CAPANINA sub-network (for connecting to the content publishers) will have adesignated and un-contended network capacity, including the data security at theIP level. The CAPANINA NMS and OSS subsystems could also use privateADSL connections (if are based remotely from the CAPANINA SMS).Alternatively, these can be ordinary public ADSL broadband connections, but theavailable bandwidth will not be guaranteed and will be subject to conditions onthe public network in this case.

3. A single aggregating connection between the CAPANINA SMS and the ADSLnetwork which backhauls to the content servers located at the designatedlocation at Content Providers offices. This is additional part to basic ADSL



access network to reserve the adequate bandwidth in the core network segmentfor enabling virtual private network with guaranteed bandwidth. For example, inUK this can be “BT Central” product offered by British Telecom [4]. Thebandwidth of this aggregated pipe is governed by the CAPANINA servicerequirements.

It is envisaged, however, that the CAPANINA broadband services will be offered by anInternet Service Provider (ISP) and HAPS provider working in partnership ascomplementary parts of the overall network architecture.

One possible scenario for such integrated network architecture is illustrated in Figure12.

Figure 12. CAPANINA network architecture scenario

8.1 Backhaul Bandwidth Specification

Each of these network segments, including the backhaul aggregation pipe, can betailored to meet the CAPANINA service requirements in terms of data capacity and IPthroughput requirements.

For example, in the UK, the backhaul solution for providing a VPN network between thecontent providers and the CAPANINA SMS would include two products, BT IP Stream(private ADSL connections) and BT Central (aggregated backhaul) as already



described. The typical connection details of the BT Central product [are described inTable 4.

BT Central InterfacePresentation

Number ofHomeGateways

Maximumsimultaneoussessionssupported

Typical MaximumIP ThroughputUpstream

TypicalMaximum IPThroughputDownstream

2 Mbit/s 10 BaseTEthernet

1 250 1.4 Mbit/s 2.1 Mbit/s

10 Mbit/s 100 BaseTEthernet

1 1600 7.6 Mbit/s 11.4 Mbit/s

Table 4. “BT Central” backhaul product specification illustration

It can be noted that the key issue for tailoring the backhaul pipe would be the “Maximumsimultaneous sessions supported” as this number directly affects the number of content-providers allowed, assuming the agreed service quality is maintained.

The backhaul connection pipe between the ISP and CAPANINA SMS can be a leasedline or any other similar product for providing a bandwidth tailored point-to-pointconnection. The bandwidth requirements of this backhaul pipe will depend on type ofservices offered, service level agreements, QoS required, etc. It is envisaged, however,that gradual bandwidth provision will be made in accordance to CAPANINA broadbandservice roll out.

8.2 Additional Service Providers and Roles

The network requirements for Wireless hotspot Internet access services, such as WiFiInternet access in trains or at coffee shops, might include additional network integrationto include the private networks installed on trains. Although a technically viable solution,it might require an additional stage in service provision, such as user authentication andconditional access. This scenario is illustrated in Figure 13.



Figure 13. Network Requirements for multi-ISP case scenario

In addition, the CAPANINA SMS might use an ISP’s secured private network segment(e.g. server) for data hosting that is accessed via a firewall. This would typically be usedin case the DRM is the integrated part of the services and applications offered.

9. Customer Premise Equipment Architecture

The CAPANINA broadband services are aimed to support all ADSL-like applications(e.g. Internet access, home shopping, on-line banking, etc). In addition, as value-addservices, the broadcast applications for entertainment (e.g. HDTV) and education (e.g.BTV), VPN for corporate markets, etc. will also be supported.

In the long term, the CAPANINA system is intended to become a fully integrated dataservice provision platform supporting multimedia applications including Voice over IP,Internet access and TV, so called “triple-play” services.

The customer premises equipment (CPE) will need to support multiple simultaneousapplications. Therefore, the Set Top Box (STB) unit is required to perform intelligentoperations (e.g. IP routing, IGMP support for IP Multicast, etc.) and support interfacesfor multimedia applicants including IP, TV and voice (e.g. USB).

The list of potential interfaces that are required for a STB include:

• RF input interface (F-type, L-band input frequency range)



• LAN interface options (e.g. 100BaseT, Wireless 802.11, USB etc.)

• Audio/Video output (e.g. composite A/V, SCART, etc.)

• PSTN/ISDN modem built-in for return channel (optional)

• Conditional Access (CA) module

• HDD with software applications (e.g. IP routing, IGMP, Internetbrowser, digital video recording, GUI, cache, etc.)

• VoIP interface card

• Front-end setting buttons

Figure 14 illustrates the potential STB architecture for the enabling multimedia-richbroadband services.

Figure 14. CAPANINA Set-top-box architecture illustration

The specialised customer markets or application specific markets might require CPEto support only few of these interfaces depending on the targeted services. Forexample, BTV applications might require CPE to have audio/video output only; Internetaccess for residential market will probably utilise plug-in PC card or USB enabled settop box, business customer will need virtual-LAN applications that require a set top boxwith LAN output, etc.



9.1.1 Dual RF demodulator option

A dual RF demodulator card is required for multi-transponder based services to enableusers to simultaneously receive signals from two multiplexes or transponders, that couldbe transmitted from one or multiple HAPS (e.g. simultaneous reception of HDTVchannel from one multiplex and Internet data from another multiplex).

9.1.2 TCP Spoofing and Web Accelerators

Although it is seen as a value-add service, it is recommended that the STB systemconfiguration for CAPANINA broadband TCP-based services supports built-in softwarefor TCP spoofing and Web accelerators.

The advantages of using TCP spoofing are based on possibility to offer TCP throughputat very high speeds. This would provide a commercial advantage of HAPS broadbandservices over terrestrial competitors.

Web accelerators are often used to overwrite a Windows registry file in order to openMWS to maximum of 64 Kbytes. They also use web object aggregation before sendingthe Web page to end-user over satellite in one go.

9.1.3 Conditional Access Module Requirements

The set-top unit will ideally support the common CA interface. This provides flexibility toimplement any CA module (e.g. Irdeto, VideoCript, etc.) chosen for the broadcastservice (i.e. DTT and HDTV). However, it is often the case that for the reason ofreducing cost, the CA interface is embedded into the set top box, design for a specificservice (e.g. SkyDigital receivers).

9.1.4 Control and Remote Monitoring Requirements

The set-top unit will support a user-interface for configuring the unit. However, it isrecommended that a restricted (e.g. minimum) set of functions are made available forusers to set or alter.

It is also recommended that the set-top box does support SNMP for early fault detectionand system monitoring.

For example, in case when a customer reports the system failure, the ability to remotelyinspect the set-top box for a basic set of parameters (e.g. RF frequencies, PIDs, etc.)could save service providers money, otherwise spent on technical support at thecustomer’s premises (e.g. an engineer visit to customer’s home).

9.1.5 Potential Scenarios

This section provides a number of potential scenarios for HAPS-based servicestargeting various markets (e.g. residential, professional-corporate, etc.).



• The Residential User Scenario

It is thought that in the first instance, the most realistic scenario for residential customersis to use a set-top box (STB) placed next to the TV (e.g. in a living room). A PC, usuallyplaced in a separate room (e.g. home office) would be connected to the set-top unit viaa home-distribution network (e.g. Ethernet LAN or Wireless LAN).

In respect to software required, the set-top box would need to provide only the basic IProuting functions required for TV-based Internet applications (run locally from the set-topbox). A TV-based Internet browser would be pre-loaded into the HDD or Flash memory.A CA module would also be included.

Figure 15 illustrates this scenario.

Figure 15. CPE Home Configuration Scenario

• Corporate User Scenario

The typical corporate-user scenario includes a building with several offices. A numberof PCs would be connected through the LAN.

The potential HAPS broadband applications are Virtual Private LAN (e.g. securedconnection to other geographically dispersed offices), High-speed Internet access andBTV. Figure 16 illustrates this scenario.



Figure 16. Corporate User Scenario CPE Configuration

9.1.6 CPE Technical Specifications Summary

Table 5 provides summary details of the set-top box requirements and specifications.

Features and Functionality’s Description

TV based applications Satellite TV channels, BTV, Interactive TV applications(e.g. e-mail, TV shopping, TV banking, etc.)

IP based applications High-speed internet access (ADSL equivalent), IPMulticast based applications (e.g. audio/videostreaming, file transfer, Web fetching and broadcast,etc), Secure E-mail, etc.

Dual RF simultaneous input/output The applications are likely to be supported throughdifferent multiplexes, transponders or even satellites.Hence, the set-top box must cope with minimum two RFfeeds simultaneously

TCP Spoofing To be decided (e.g. Mentat solution)

CA Module Common CA Interface

Management Features SNMP support, restricted user-interface

HDD or Flash memory Supported



Specifications

RF Interfaces RF (one or dual) input interface, L-band, F-type

Audio/Video Interfaces Video Outputs: S-video and RCA composite video (4:3and 16:9)

Audio Outputs: Left/Right stereo RCA connectors

RF Output (F-type connector) to standard TV (both

PAL and NTSC supported)

TV Antenna Input (F-type connector)

SCART (e.g. to connect to a video-recorder or hi-fi).

LAN Interface 10/100 BaseT, WiFi, USB

Return Channel Interface PSTN V.90 modem (optional)

Software

IP Routing IGMP, NAT, RIP, OSPF, etc. (optional)

Web Browser PC and TV-based application

EPG TV-based application

Table 5. CPE Technical Details Summary

9.2 Antenna Dish and LNB Specification

The antenna and Low Noise Block (LNB) are the user interface to HAPS basedbroadband services. In the case of multi-transponder HAP services (e.g. TV signalstransmitted from one multiplex and a data feed transmitted from a different multiplex ortransponder), a multi-feed LNB assembly would be required.

It is probably safe to assume that the most commonly used antenna for HAPS serviceswill be a parabolic off-set dish (i.e. satellite dish antenna). The antenna dish size andspecifications for Ka-band and V-band operation depends on the HAPS payload usedfor the service and transmitted power (footprint).

The existing and emerging radio broadband technologies, including Ka-band and V-band, consumer two-way systems (such as HAPS, LEO, MEO and GEO-basedsystems, and GPS) have had a significant impact on user terminal antenna technologyevolution. Higher payload transmit powers combined with digital technology give spaceto considerable improvements in fade margin, which in turn can allowed user terminalantennas to become smaller.

Multi-band, multi-beam, fast tracking, remotely steerable, dielectric lens and printedantennas are becoming more widely available for new satellite based services at Ka-band. However, there are not many manufacturers of LNBs for V-band services at thecurrent time. One example of such product is produced by United Monolithic



Semiconductors (UMS), a French-based independent Joint-Venture of THALES andEADS Deutschland GmbH [20].

9.2.1 Tracking Requirements for Fixed Services at Higher Frequency Bands

Parabolic dish antennas at V-band frequencies have highly directive radiation patterncharacteristics. This might cause problems even with fixed radio services (i.e.residential users) as even small movement of an antenna would cause a severe drop inthe signal level. The tracking, therefore, might be an important requirement for theantenna design of CAPANINA broadband services at V-band.

9.2.2 Fast Tracking Stabilised Antennas for In-motion Services

Digital TV and high-speed broadband data communications (e.g. voice, fax, Internetand video multi-conferencing links) are required not just for people at home or in theoffice but also when on the move. Trains and buses are good examples of where thereis a huge potential market for such services.

Historically, in-motion stabilised satellite antennas for use on ships or land-lockedvehicles were generally very expensive. In most cases the only solution was to use anexpensive gyrocompass. Tracking speed was the major challenge for such antennas.However, recent stabilised-antenna designers often use less expensive two-axis servodriven systems. These new antennas are claimed to have fast tracking capability thatenables uninterrupted satellite services (at Ku band) while on the move.

Many competing companies already offer such services in the US at Ku band. On theother hand the European market is still not fully exploited, mainly for the reasons ofbetter cellular and terrestrial networks and lower investment than in the US.

The in-motion fast tracking antennas (e.g. a small parabolic dish with radome cover) areusually guided by a servo system (2 or 3 axis system) and a small internal computer witha tracking algorithm to lock on to a communications satellite despite the twists and turnsof the road. Such systems are claimed to dynamically measure and compensate for themotion of the vehicle, which enables antennas to maintain accurate satellite pointingwith 1° accuracy and to actively track satellite signals at rates in excess of 30° to 60°per second. This is adequate for uninterrupted in-motion reception of TV channels anddata communications.

The in-motion antenna systems for marine satellite communications are moresophisticated and use gyroscopic tracking technology, to cater for the more rapid boatmovements.

Figure 17 illustrates the KHV in-motion fast tracking antenna for satellite TV broadcastservices.



Figure 17. In-motion antenna systems illustration

The examples of satellite in-motion fast tracking antenna system manufacturers include:KVH Industries, SkyGate, MotoSat, MediaCom, etc.

9.2.3 Future Trends in Printed Antennas

The trend in RF and microwave mobile communications is to integrate the various RFmodules into a single chip solution. This technology is called Monolithic MicrowaveIntegrated Circuit (MMIC). Printed circuit antennas are important to telecommunicationsbecause of advantages such as low cost, low weight, low power consumption, low costfor mass production and the potential for integration with active solid-state devices.

Also, the growth in satellite television service provision indicates that the number ofsatellites will be growing year after year, thus generating a need for reception of signalsfrom different directions using the same antenna. The phased array antenna that uses aprinted-circuit board as a radiating curtain and p-i-n diode based microstrip phase,used to permit user-friendly modes of operation, such as automatic search of satellitesfollowed by memorising their co-ordinates in the receiver unit in order to switch over tothe desired satellite.

The phased array antennas capability of high speed of beam switching make themattractive solution for use in DBS systems (for Ku band) installed on movable objectssuch as coaches, trucks and ships. Also, the possibility of using electronic beamsteering makes phased array antennas excellent candidate for satellite mobilecommunications via MEO and LEO satellites.

Active phased array antennas are required for broadband services at high frequencybands (e.g. up to and beyond 100GHz). As such, phased array antennas may containmany hundreds of transmit/receive modules. The implementation of MMIC technology istherefore mandatory for the reduction of antenna size, weight and cost [10].



10. Conclusion

This technical document describes the general network architecture requirements forthe CAPANINA communications architecture(s) for use with the applications andservices defined in deliverable D01, Candidate Applications and Services forBroadband HAPS Delivery [1].

The broadband service providers of today face the challenge of connecting anenormous number of diverse, relatively low-speed access services into their high-speedbackbones. Supporting a wide range of access interfaces is a potentially complex andexpensive undertaking but is necessary if all customers are to be served. HAPS offerthe potential to play an active role in providing broadband services in four core networksegments: access network, content distribution, core network trunk and HAPS privatenetworks.

The report describes network topologies for all four selected CAPANINA networkscenarios, for both single and multiple HAPS architectures. The OSI reference modelfor each network topology and network layer requirements are also presented here. TheCAPANINA OSI network reference model combines the multiple layers of terrestrialnetwork 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'scompetitive marketplace for broadband service provision. The network layerrequirements describe IP unicast and multicast routing, IP QoS requirements for bothdata and voice (VoIP) service scenarios.

The report also defines the key network elements of the CAPANINA system includingthe general payload architecture, backhaul network and customer premise equipmentarchitectures. The CAPANINA service management system and OperationalSupporting System (OSS) and its subsystem components are also described in thisdocument. These systems will be used to support commercial aspects of CAPANINAservice such as network management, account management, system policymanagement, conditional access and security, billing and usage tracking.

The main points in respect to general network requirements from the service provisionpoint of view are:

• The general network architecture for supporting the selected services andapplications must be based on open industry standards such as IP, DVB, etc.

• CAPANINA network integration with other networks must provide transparentand seamless service provision as seen from the ISP point of view

• The CAPANINA service management system must include the OSS subsystemcomponents in order to support commercial service provision; this can be basedon eTOM FAB model in providing Fulfilment Assurance and Billing.

• The HAPS payload will be based on On-Board Processing (OBP) architecture.In these architectures, the HAPS functions terminate one or more layers of the airinterface protocol stack in the HAPS station. In addition, the protocol stack canbe terminated at a higher layer thus enabling additional functionality. For



example, HAPS can be used as the router (network layer termination), to provideon-board packet switching for multiple HAP architectures, signal regeneration,content buffering, etc. In addition the Mobility Anchor Point (MAP) can be put onthe HAPS in order to support Mobile IP.

• One of the factors that has the greatest impact on whether an operator candeploy HAPS is the availability and cost of the radio spectrum.

• The backhaul aggregation pipe will be tailored to meet the CAPANINA servicerequirements in terms of data capacity and IP throughput requirements.

• The Customer Premises Equipment (CPE) will need to support multiplesimultaneous applications. Therefore, the Set Top Box (STB) unit is required toperform intelligent operations (e.g. IP routing, IGMP support for IP Multicast, etc.)and support interfaces for multimedia applicants including IP, TV and voice (i.e.VoIP).



References

[1] Ken Fowler, January 2004, Applications and Services for Broadband HAP Delivery, CAPANINAD01 Deliverable Technical Document

[2] BT/MSc Module 12, Operating a Telecommunications Business, 2003 Lecture Courseware, J.A.Barria, Imperial College London

[3] ETSI TR 101 856, Broadband Radio Access Networks (BRAN); Functional Requirements forFixed Wireless Access systems below 11 GHz: HIPERMAN, Technical Report available fromhttp://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp

[4] BT Electronic Pricing Manual, Section 44, BT Wholesale Broadband Services, available fromhttp://primawebliv.prima.bt.co.uk/manual/current/docs/Wholesale_Broadband_Services.boo/sectoc.htm

[5] Tim Tozer, John Thornton, David Grace and Candida Spillard, July 2003, The Application of V-band for Satellite and HAP Broadband Service Development, Working Package 1.4 CapacityEnhancement using Multiple Platforms, BNSC Study

[6] ETSI TR 101 957, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Requirementsand Architectures for Interworking between HIPERLAN/2 and 3rd Generation Cellular systems, TechnicalReport available from http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp

[7] S. Brunner, A. A. Ali Voice Over IP 101 Understanding VoIP Networks (White Paper) JuniperNetworks, www.Juniper.net, Part Number: 200087-001, Aug 2004

[8] Hughes Spaceway Web site:http://www.hns.com/HNS/Rooms/DisplayPages/LayoutInitial?pageid=SPACEWAY_home&Container=com.webridge.entity.Entity[OID[1F25CC9CF1479743B2C83A5CF6F811F0]]

[9] EuroSkyWay Web site: http://www.euroskyway.it/website/html_eng/index.html

[10] Ultrafast Systems PBG Antenna Research, Web site:http://www.elec.gla.ac.uk/groups/nano/UFS/pbg.html

[11] “What is LMDS”, April 1998, by Roger Marks, Web article available fromhttp://nwest.nist.gov/lmds.html

[12] ETSI TR 101 031, Broadband Radio Access Networks (BRAN); High Performance Radio Local AreaNetwork (HIPERLAN) Type 2; Requirements and architectures for wireless broadband access,available from: http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp

[13] ETSI TR 101 177, Broadband Radio Access Networks (BRAN); Requirements and architecturesfor broadband fixed radio access networks (HIPERACCESS), available from:http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp

[14] ETSI TR 101 615, Network Aspects (NA); Services and networks architecture evolution fortelecommunications, available from: http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp

[15] VoIP101, S. Brunner, A. A. Ali Voice Over IP 101 Understanding VoIP Networks (White Paper)Juniper Networks, www.Juniper.net, Part Number: 200087-001, Aug 2004

[16] VoIP_ATT, AT&T Point of View /VoIP, URL: http://www.att.com/business April, 2005.

[17] RCF2205, R. Braden, Resource ReSerVation Protocol (RSVP) -- Version 1 FunctionalSpecification, September 1997.



[18] RFC 2475, “An Architecture for Differentiated Services”, Dec. 1998

[19] RFC 2215, "General Characterization Parameters for Integrated Service Network Elements", Sep.1997

[20] United Monolithic Semiconductors (UMS), a French-based independent Joint-Venture of THALESand EADS Deutschland GmbH, Web site http://www.ums-gaas.com/

End of document

general network architecture requirements - · pdf filegeneral network architecture...

Documents