New Horizons in Mobile and Wireless Communications: Networks, Services and Applications (Artech House Universal Personal Communications)

New Horizons in Mobile and Wireless Communications Volume 2 Networks, Services, and Applications

For a listing of recent titles in the Artech House Universal Communications Series, turn to the back of this book

New Horizons in Mobile and Wireless Communications Volume 2 Networks, Services, and Applications Ramjee Prasad Albena Mihovska

artechhouse.com

Library of Congress Cataloging-in-Publication Data A catalog record of this book is available from the Library of Congress.

British Library Cataloguing in Publication Data A catalogue record of this book is available from the British Library.

ISBN

978-1-60783-969-9

Cover design by Igor Valdman ©European Commission 2009 ARTECH HOUSE 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

10 9 8 7 6 5 4 3 2 1

Contents Preface

ix

Acknowledgments

xi

CHAPTER 1 Introduction

1

1.1 Heterogeneity of Networks 1.1.1 Evolution of the Radio Access Network 1.1.2 Evolution of the Core Network 1.1.3 Cooperation Mechanisms 1.1.4 Network Security Requirements 1.1.5 Quality of Service 1.2 Service Platforms 1.2.1 Service Adaptation 1.2.2 Cross-Domain Service Access 1.2.3 Applications 1.2.4 Summary 1.3 Preview of This Book References

2 4 8 15 29 31 32 35 35 38 40 40 42

CHAPTER 2 Network and Mobility Management

47

2.1 Introduction 2.1.1 System Architectures for Support of Multiple Access 2.1.2 Cooperation Architectures 2.2 Mobility Management 2.2.1 Triggers 2.2.2 Framework for Hybrid Handover 2.2.3 Architecture for Multiple Access 2.2.4 Mobility Management Service Access Points (SAPs) 2.2.5 Evaluation of Mobility Management Schemes 2.2.6 Summary 2.3 Location-Based Mobility Management 2.3.1 Elements of the HIS 2.3.2 Intrasystem Handover Assisted by HIS 2.4 Conclusions

48 48 48 54 55 58 66 94 100 115 116 118 120 128

v

vi

Contents

References CHAPTER 3 Quality of Service

129

133

3.1 Introduction 133 3.1.1 Performance Metrics 134 3.1.2 QoS Provision in IP Networks 142 3.2 QoS Architectures 166 3.2.1 Policy-Based Architectures 166 3.2.2 Dynamic Internetworking 176 3.3 QoS Testing 190 3.3.1 Virtual Distributed Testbed for Optimization and Coexistence of 3.3.1 Heterogeneous Systems 191 3.3.2 Practical Implementation of RRM Mechanisms in 3.3.2 Support of QoS 209 3.4 Conclusions 222 References 223 CHAPTER 4 Satellite Networks 4.1 Introduction 4.1.1 Broadcast and Multicast for Fixed and Mobile Networks 4.1.2 The Digital Dividend 4.1.3 High Altitude Platforms (HAPs) 4.1.4 Emerging Standards 4.2 Functional Layers, Protocols, and Segments of Satellite Systems 4.2.1 Functional Layers 4.2.2 Protocols 4.2.3 Ground Segment 4.2.4 Common Equipment 4.2.5 Convergent Satellite Platform 4.2.6 Satellite Payload 4.2.7 Network Topologies for HAP-Based Systems 4.2.8 Networking Topologies for Converged Satellite Systems 4.3 Interworking Between Satellite and Other Systems 4.3.1 Mobility and Handover 4.3.2 QoS 4.3.3 Interworking Between Layer 2 and Layer 3 in an 4.3.3 HAPS-Based System 4.3.4 Security 4.4 Conclusions References

227 228 229 230 230 239 253 254 254 255 259 259 261 265 270 275 275 276 281 282 283 285

CHAPTER 5 Broadband Access Networks and Services

287

5.1 Introduction 5.1.1 Optical Access Solutions

288 289

Contents

vii

5.1.2 Fixed Wireless Access Based on Radio over Fiber (RoF) 5.2 Broadband over Powerline 5.2.1 Cognitive BPL 5.2.2 Integration of Wireless Technologies with PLC 5.3 Next Generation Broadband Access Platforms 5.3.1 Business Roles 5.3.2 Architectural and Protocol Reference Models 5.3.3 Small and Medium Enterprises Support 5.3.4 Service Enablers 5.3.5 Authentication, Authorization, and Accounting 5.3.6 Quality of Service and Connection Admission Control 5.3.7 Quality of Experience 5.3.8 Fixed Mobile Convergence 5.3.9 The Residential Network and Gateway 5.4 Conclusions References

295 297 297 298 322 322 323 328 330 335 339 345 346 352 356 357

CHAPTER 6 Services and Service Platforms

361

6.1 Introduction 6.1.1 Pervasive Service Platform 6.1.2 Middleware 6.1.3 Business Impact 6.2 Architectural Concepts for Pervasive Services Platform 6.2.1 Pervasive Service Management 6.2.2 Personalization and Learning System 6.2.3 Context Management 6.2.4 Security and Privacy 6.2.5 Deployment and Run-Time Environment 6.2.6 Tools and Support for Third-Party Service Development 6.2.6 and Provisioning 6.3 Service Platforms and Service Provisioning in Personal Networks 6.3.1 Solutions for Securing the MSMP Operations 6.3.2 Context Management Framework 6.3.3 Interaction Between MSMP and SCMF 6.4 Conclusions References

362 363 368 372 374 374 378 380 382 384 386 388 392 394 397 405 406

CHAPTER 7 Applications and Application Environments

409

7.1 Introduction 7.1.1 Enabling Technologies for Services and Applications 7.1.2 Middleware and Enablers 7.2 Resource-Aware Programming for Adaptive Services 7.2.1 Development Environment 7.2.2 Validation Environment 7.2.3 Middleware Environment

410 410 414 417 419 420 420

viii

Contents

7.2.4 Developing and Provisioning Services and Applications 7.2.5 Example Applications 7.3 Conclusions References

421 422 425 426

About the Editors

429

Index

433

Preface

Knowledge, the object of knowledge, and the knower are the three factors that motivate action; the senses, the work, and the doer are the three constituents of action. The Bhagavad Gita (18.18) European Research Framework Programs are public policy instruments designed to strengthen European competitiveness through cooperation. Although they have a fixed time frame, determined research themes, and a specific expected impact, the achievements in research and development (R&D) made by these funded projects pave the way for a research continuum. The Information Society Technologies (IST) research program was launched in 1999 as a successor to the Advanced Communications Technologies and Services (ACTS) research framework. Within this program, two consecutive frameworks were focused on advancements in the state of the art in the area of mobile and personal communications and systems: FP5, Satellite-Based Systems and Services, and FP6, Mobile and Wireless Systems Beyond 3G and Broadband for All. Under FP6, the European Union has been funding collaborative R&D activities in the field of telecommunications with a financial allocation of more than €370 million and the objective to make significant progress towards advanced communication technologies, systems, and services. The FP6 IST research and development effort was a primary initiative that launched large Integrated Projects (IPs) alongside the smaller Specific Targeted Research Projects (STREPs), Specific Support Actions (SSAs), and Networks of Excellences (NoEs). The enormous research effort concentrated in the various R&D project activities required a special supporting initiative that would span the entire domain of projects, promote structure, and disseminate information about the research effort and results. This was the main idea behind the European FP6 IST project titled “SIDEMIRROR.” This book is part of a series of books that has resulted from the

ix

x

Preface

project effort supported by the European Union under FP6 in the areas of Mobile and Wireless Systems Beyond 3G and Broadband for All. The final research results of the numerous projects in the above-mentioned R&D European initiatives were collected and integrated with the objective of creating a permanent record of their achievements in four books. In particular, this book is about the advancements made under the FP6 umbrella in the area of networks, services, and applications. At the end of FP6, emphasis was put on issues such as mobility, the anticipated changes in scale of connected devices, increases in bandwidth, increases in digitized media, increases in the importance of security and evolution of services to more adaptability, and awareness of user context and preferences. These were also identified as the drivers to define and develop the network and service infrastructures of the future. The objective of FP6 was to create an opportunity for generating new economic and market growth with new classes of user-centric network and service architectures and application platforms. At the end of FP5 the concept of the mobile service platform and enabling middleware had not been addressed. The information technology (IT) and the telecommunication areas were viewed as separate. A number of FP6 projects focused their efforts on providing a set of functionalities that could be used by a user-centric mobile service platform to support or enrich a service. The projects made a considerable impact on the development of standards and the product business potential. The achieved results put the basis for the follow up EU-funded project work under the Framework Program 7 (FP7) umbrella. The FP6 projects achieved significant results in the area of broadband access. The projects worked on the development of low-cost broadband technologies for affordable broadband services for everyone, including rural communities. The FP6 funding initiative brought together projects involved in a range of technologies, namely, optics, powerline, DSL, satellite, and wireless. The projects contributed to solutions for the reduction of the digital divide and the deployment of next generation networks. The ICT industry is one of Europe’s largest economic sectors, and was strengthened by the FP6 projects. In the field of transport networks, European competitiveness was enhanced with the development of flexible and intelligent core and metro-optical networks. The projects demonstrated architectures and solutions for a mass-market adoption of optical connectivity for low-cost optical technologies, and contributed to the work of standardization bodies and fora (ITU, OIF, IETF) in the area of optical internetworking. The material collected in this book was edited to provide useful reading material to senior and junior engineers, undergraduate and postgraduate students, and anyone else interested in the development of current and future mobile communications. It was impossible to include all project achievements; however, the book provides a useful tool in terms of R&D methodology that can be applied to the development of new concepts. We hope all readers will experience the benefits and power of this knowledge.

Acknowledgments First, the editors would like to acknowledge Ms. Dua Idris from CTIF at Aalborg University for her big effort towards the completion of this book. Dua was involved in the FP6 IST project SIDEMIRROR as a research engineer. Her consistent hard work and passionate effort toward improving the quality of the content are very commendable. Further, this book would not have been possible without the strong support of the European Union project officers from the Directorate General Information Society (DG INFSO) of the European Commission in Brussels, namely, Dr. Jorge M. Pereira, Dr. Manuel Monteiro, and Dr. Francisco Guirao Moya, who guided the project work and ensured strong cooperation with the rest of the FP6 IST projects in the area. Their effort was an essential prerequisite for the successful editing of the available research results. The material in this book was collected and structured with the support of the European Commission within the framework of the IST supporting project SIDEMIRROR, in an effort that spanned a period of five years. It originated from the technical reports and documentation of the projects involved in the FP6 IST R&D initiatives Mobile and Wireless Systems Beyond 3G and Broadband for All. The project SIDEMIRROR consisted of two member organizations, Aalborg University and Artech House Publishers. The editors would like to acknowledge the support of their colleagues from Artech House toward the completion of this manuscript. Finally, the editors would like to thank the administrative and IT staff from Aalborg University for providing the required administrative and IT project support. Ramjee Prasad Albena Mihovska Aalborg, Denmark May 2009

xi

CHAPTER 1

Introduction New breakthroughs in information and communication technologies (ICT) will continue over the next decades to bring even more wide-ranging applications that will continue to drive growth and innovation and ensure sustainability in both economies and societies [1]. Services and software are essential for the efficient operation of an economy, facilitating commercial transactions and enabling the production and delivery of goods and other services. Next generation systems support services and applications that conform to open standards and protocols. This allows applications including, but not limited to, video, full graphical Web browsing, e-mail, file uploading and downloading without size limitations (e.g., FTP), streaming video and streaming audio, IP Multicast, location-based services, virtual private networks (VPN) connections, VoIP, instant messaging, and online multiplayer gaming. Such developments imply heterogeneity in technology and ownership, leading to complex systems requiring interworking of the technologies in order to establish and maintain connections with required quality, in fault detection and location, in resource allocation and in charging of the usage of the network’s resources. It is also expected that legacy systems will continue to serve users [2]. Further, networked services and applications gain new importance for the next generation systems. As another trend, it is expected that the traditional split into software and hardware and their respective businesses will disappear. Software will be increasingly delivered as a service, blurring the frontier between the computer, the network and the application [3]. Security, privacy, and trust gain new momentum in the context of an open and heterogeneous infrastructure. This chapter introduces into the topics of networks, services, and applications for next generation systems. It provides a comprehensive overview of the topics and puts the into a perspective of the European research and development efforts carried out within the frames of the Framework Program (FP) 6 targeting specifically the areas mobile and wireless beyond third generation (3G) and broadband for all. This chapter is organized as follows. Section 1.1 describes the trend towards heterogeneous networks and the implications for the evolution of the radio access network and overall radio and network resource management. Section 1.2 describes the trends in the development and evolution of the service architectures and platforms. Requirements generated by the overall trend towards personalization of services are described together with the implications for the overall research and development effort undertaken by both standardization bodies and by EU-funded research. Sec-

1

2

Introduction

tion 1.2 describes further the trends and requirements for the emerging application platforms. Section 1.3 gives a preview of the book.

1.1

Heterogeneity of Networks Heterogeneity of networks means that connections span over several networks that deploy different transport technologies and that the networks are owned and operated by separate organizations. When, for example, a customer subscribes to an Internet connection or a virtual private network (VPN) service with specified quality, it is almost impossible for the customer to make sure that the promised quality is fulfilled. On the other hand, it is also difficult for the Internet service provider (ISP) to guarantee the promised quality in a multitechnology and multioperator environment. In case the service does not meet the promised quality, it is equally difficult to identify the cause for that. Heterogeneous systems must be capable of forwarding data streams and session context among each other and a (vertical) handover should happen seamlessly. Quality of service (QoS) and the way to provide the requested QoS to the expecting applications has become a key topic and a wide field of study worldwide [4]. In order to reach a user-centric vision for QoS, the paradigms of mobile networking have to be reconsidered [5]. The enormous progress in wireless communications has created a constantly growing plethora of wireless and mobile access options. Although terminals and devices are increasingly capable of physically communicating using different access technologies, interconnectivity and cooperation between them is still a largely untapped resource because procedures and protocols are either incompatible or their use is stifled by business-related barriers. An effortless and secure network and service access over every network according to user preferences could radically change this picture. Such an approach enables openings for new cooperating actors at the edge of big backbones providing specialized access in geographically confined areas. Cooperation in the context of heterogeneous networks requires suitable radio resource management mechanisms with respect to support of vertical handover, authorization, authentication, and accounting (AAA), and common radio resource management (RRM). Existing radio access networks (RANs) can at this moment be modified or updated for cooperation only at higher layers of the mobile network, which translates into routing at the radio network controllers (RNC) or an equivalent network element. Even in the case of a single transport network, there may be difficulties in managing service level agreements (SLAs). The operator business has confronted fundamental changes during the recent years to such an extent that new business opportunities and roles have emerged. Transition from the traditional vertical business model towards a horizontal one means, for example, that the operator that runs the transport network does no longer provide all the services to its customers [6]. On the other hand, a company that provides end-user services does not provide all the facilities for that service. There usually is a group of cooperating parties, such as a carrier service provider, an access provider, a virtual operator, a transport capacity

1.1 Heterogeneity of Networks

3

retailer, and an end-user service provider, that make up the provided service. Therefore, it is a complex task to guarantee end-to-end quality. Through cooperation leading to efficient strategies for radio resource use, the full potential of user-owned networks could be fully realized. Competition and effective resource utilization would bring prices for access down. This vision was undertaken in a number of FP6 IST projects, namely, the projects Ambient Networks [7], EVEREST [8], WINNER and WINNER II [9], AROMA [10], DAIDALOS and DAIDALOS II [11], ENABLE [12], and some others [13]. Standardization organizations such as the Third Generation Partnership Project (3GPP) [2], the International Engineering Task Force (IETF) [14] and the Open Mobile Alliance (OMA) [15] address the issues around multiaccess wireless networks. Ubiquitous IP connectivity is only the starting point for reaching a consensus on how to overcome the current hurdles, revitalizing the market with new business opportunities, and letting ambient networking become a reality [7]. Mobile and wireless telecommunication networks have enabled widespread usage of mobile and smart phones. Access to a number of services, such as telephony and messaging, is now truly ubiquitous and available to the majority of users. Usage of mobile Internet services is also on the rise. On the other hand, there is an increase in the use of smart spaces (also called smart or intelligent spaces, environment, or ambient) [11]. Smart spaces are combinations of digital and physical artifacts and sensors that attempt to implement natural and calm interaction with technology and surroundings. Smart spaces provide a number of new value propositions, which require but are not limited to a higher degree of context awareness, and better usage of resources and devices. Local area network (LAN) systems are the heart of modern networked environments. They are the basis of locally autonomous services, and universally, the point of connection to external infrastructure. The elements of modern, high-capacity LAN connectivity were also included in the IST research effort under the scope of the Broadband for All initiative. The wide area network (WAN) infrastructure has traditionally been the exclusive domain of the telephone industry, with their long-standing preference for synchronous technology and ATM. IP-oriented developments using nontraditional core technology (e.g., wireless, cable TV plant, power distribution networks) are making serious inroads into the domain of the mainstream telecommunications carriers. The issues related to WANs are related to the provision of bandwidth-on-demand and how to overcome the limitations of traditional networks, packet switching, in-band versus out-of-band control, congestion control, virtual paths and traffic shaping, how to converge ATM and IP, the planning and design of a fiber-optic WAN infrastructure, satellite systems, and so forth. Some of the IST projects that worked in this direction under the FP6 umbrella are the projects NOBEL [16], which focuses on the design of a next generation optical broadband network; LASAGNE [17], which focuses on the use of all-optical logic gates and optical flip-flops based on commercially available technologies; TRIUMPH [18], which focuses on a transparent ring interconnection using multiwavelength photonic switches for increased network functionality and capacity; VIVALDI [19], which focuses on the architecture, technologies, and protocols ensuring that the sat-

4

Introduction

ellite segment interoperates transparently and efficiently with the end-to-end IP networks at large; and others [20]. The previously unimaginable scale of Internet development and success has led to a wide-ranging initiative to convert all network-related services to this model—a process referred to as convergence. The elements of this core subject, combined with emerging applications, were the focus of projects such as CODMUCA [21],which concentrates on broadband convergence of services on standard Internet Protocols (IP); SATSIX [22], which focuses on satellite systems that offer attractive solutions to the access segment of wider networks in several main scenarios; MIDAS [23], which focuses on a middleware platform design on order to simplify and speed up the task of developing and deploying mobile services; COMET [24], which focuses on a converged messaging service beyond 3G; and others [13, 20]. 1.1.1

Evolution of the Radio Access Network

Following the preliminary trends in the 3GPP architecture evolution [2], note that RAN is moving towards an open distributed topology. This is relevant for the underlying radio level activation of the resource management regime [25, 26]. Figure 1.1 shows an example of the functional split of the present radio network control (RNC) functionality into different functional entities and the classification of the resulting entities in the control or user plane according to their scope. Based on this, a set of two evolutionary paths for the UTRAN architecture were proposed in 3GPP [2]. The first architecture is shown in Figure 1.2. The radio network controller (RNC) functions are decomposed and mapped onto two new types of network entities that complement the RNCs currently available: 1. Radio control servers (RCSs); 2. User plane servers (UPSs). A second architecture was also considered in Release 6 for the enhancement of the Node B to a new node called Node-B+. This architecture is shown in Figure 1.3.

Multicell scope

Control plane

Multicell RRM

Paging

Broadcast distribution

User plane

Figure 1.1

Decomposition of traditional RNC functions.

Cell scope

User scope

Cell control

Mobile control

Common channels processing

Dedicated channels processing

1.1 Heterogeneity of Networks

5

Radio control servers (RCSs)

To other RNS

To other RNS

Core network

User plane servers (UPSs)

Figure 1.2

Distributed architecture proposed in 3GPP for 3G evolution [2].

Here, the functions of a monolithic RNC have been distributed down to a node B+. There is, therefore, no longer an Iub interface in this evolved architecture. Instead, there is a radio network gateway (RNG) acting as an interworking unit to the RANs and the core networks (CNs) of the earlier releases. The RNG hides the bigger number of node B+ to the conventional CN over the Iu and to the conventional RNC over Iur. Furthermore, the RNG acts as a mobility anchor, hiding the service radio network subsystem (SRNS) relocations between the node B+ to the CN [27]. The Iur interface between the Node B+s and the Iu interface ensures the communication between the Node B+s and RNGs. There is a many-to-many relationship between the node B+ and the RNGs. There is also an Iur interface between the Node B+ and the RNG for the interworking with the RAN from earlier releases in case of a drift situation. The Iu and Iur interfaces in the evolved architecture have some enhancements themselves compared to existing interfaces. A long-term OPEN RAN architecture has been discussed by the Mobile Wireless Internet Forum (MWIF) [28] as a part of the activities outlining the new and innovative mapping functions for both the 3GPP UTRAN and the 3GPP2 CDMA2000 RAN architectures. The MWIF has defined the MWIF OpenRAN Reference Architecture. This architecture interacts with MWIF’s core network reference architecture via the access gateway and is shown in Figure 1.4. The home subscriber server (HSS) is one of the most important subsystems in the 3GPP architecture frozen as Release 7. It is the master database for a given user, containing the subscription-related information to support the network entities actually handling calls/sessions. The HSS also generates user security information for mutual authentication, communication integrity check, and ciphering. The HSS

6

Introduction

Figure 1.3

Distributed architecture proposed for Release 6 in 3GPP.

Figure 1.4

OPEN RAN architecture proposed in 3GPP [28].

assumes the functionality of AuC and the home location register (HLR) that appeared as separated entities up to Release 4 [2]. A new subsystem appeared in R7 that encompassed the harmonization of these functional entities, namely, the policy and charging control (PCC) subsystem. This subsystem is in charge of two key areas for a public land mobile network (PLMN) operator: flow-based charging (including charging control and online credit control) and policy control (including gating control, QoS control, etc.). The RAN architecture adopted for LTE and evolving from UTRAN (i.e., E-UTRAN) and described by [29] is shown in Figure 1.5. The E-UTRAN consists of set of eNBs connected to an evolved packet core network (EPC) through the S1 logical interface. An e-node B (eNB) can support fre-

1.1 Heterogeneity of Networks

7

EPC S1

S1 X2

EUTRAN eNB

Figure 1.5

eNB

Overall E-UTRAN architecture specified by 3GPP [29].

quency division duplex (FDD) mode, time division duplex (TDD) mode, or dualmode operation. The eNBs can be interconnected through the X2 logical interface. The E-UTRAN is layered into a radio network layer (RNL) and a transport network layer (TNL). The E-UTRAN architecture (i.e., the E-UTRAN logical nodes and interfaces between them) is defined as part of the RNL. In a research effort towards radio systems beyond LTE (i.e., IMT-advanced candidates), the FP6 IST project WINNER designed a new radio concept that incorporates the RAN architecture shown in Figure 1.6. The WINNER radio access network (WRAN) is connected to an external packet data network (e.g., Internet) via the IG interface. The WRAN provides the IWU interface that is a radio interface to connect the WINNER terminals (“UT”). Strictly speaking, the WRAN also contains functionalities that are more related to the core network rather than the radio network, such as gateway functionalities [32]. In summary, the flat and open architectures adopted for next generation systems allow for the use of distributed mechanisms for RAN management. Some of the arising challenges relate to the question of how to match the fast data delivery rates achievable on the air interface links to the speed of the upper layers.

Internet, operator services, etc. IG

WINNER Access Network Interface Logical node

Figure 1.6

WINNER RAN architecture [9].

I WU UTLN

8

Introduction

1.1.2

Evolution of the Core Network

Recommendations by standardization and other bodies show that next generation core networks should be compatible with existing networks and can result either from the evolution of the existing core networks or be a new network [33]. The core system should have similar cost-efficiency and performance characteristics to its contemporary IP core systems deployed in the wireline infrastructure. 3GPP has specified the flat, IP-based network architecture as part of the system architecture evolution (SAE) effort. The aim and design of the LTE-SAE architecture and concepts were to efficiently support mass-market usage of any IP-based service. The architecture is based on, and evolved from, existing GSM/WCDMA core networks to facilitate simplified operations [34]. In a flat architecture, the number of nodes involved in data processing and transport is reduced, which improves the data latency and provides support for delay-sensitive, interactive, real-time communications. The next-generation network (NGN) enables the deployment of access independent services over converged fixed and mobile networks. It is packet-based and uses IP to transport the various types of traffic (voice, video, data, and signaling) [35]. Wishing to further exploit the arisen awareness of users about new multimedia communication services and expand the possibilities for new profits in the new fixed and wireless network domains, the industry of communications has set a new target, that of creating ubiquity in service delivery along with seamlessness in keeping steady the user experience in terms of service tariffing and QoS satisfaction. Triple-play services (voice, Internet, and TV) are already available via cable and xDSL. The NGN brings mobility and the opportunity for further bundling of high revenue services for customers. At the core of the harmonized All-IP NGN network is the IP Multimedia Subsystem (IMS), which provides an access-independent platform for a variety of access technologies (GSM, 3G, WIFI, Cable, and xDSL). The IMS appeared first in 3GPP Release 5 [2] and is a key control subsystem developed for the provision of advanced IP multimedia services. IP Multimedia services are based on an IETF-defined session control capability, which, along with multimedia bearers, utilizes the IP-connectivity access network (IP-CAN). The IP multimedia core network (IM CN) subsystem “enables PLMN operators to offer their subscribers multimedia services based on and built upon Internet applications, services, and protocols. There was no intention in 3GPP to standardize such services within the IM CN subsystem, the intention was that such services would be developed by the PLMN operators and other third party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IM CN subsystem. The IM CN subsystem should enable the convergence of, and access to, voice, video, messaging, data, and Web-based technologies for the wireless user, and combine the growth of the Internet with the growth in telecommunications” [36]. The focus of SAE development was to define a framework for an evolution or migration of the 3GPP system to a higher data-rate, lower-latency, packet-optimized system that supports, multiple RATs. The focus of this work was under the assumption that voice services are supported in the packet switched domain. The main objectives of SAE can be summarized as follows:

1.1 Heterogeneity of Networks

• • •

9

Impact on overall architecture resulting from RAN’s LTE work; Impact on overall architecture resulting from SA1’s AIPN work; Overall architectural aspects resulting from the need to support mobility between heterogeneous access networks.

The ETSI Technical Committee on Telecommunication and Internet Converged Services and Protocols for Advanced Networking (TISPAN) has adopted the 3GPP core IMS specifications using Internet (e.g., SIP) protocols to allow features such as presence, IPTV, messaging, and conferencing to be delivered irrespective of the network in use. A NGN is a packet-based network able to provide services including telecommunication services and able to make use of multiple broadband, QoSenabled transport technologies, and in which service-related functions are independent from underlying transport-related technologies. The NGN approach aims to offer unrestricted access by users to different service providers and to support nomadic services, to allow for consistent and ubiquitous provision of services to users. TISPAN has defined an extensible subsystems-based architecture whose main objectives are to deliver 3GPP IMS multimedia services to fixed broadband lines and to replace, at least partially, the PSTN/ISDN services through the emulation and the simulation of the PSTN/ISDN services, even though the legacy PSTN/ISDN and switched-circuit networks still can be supported. New subsystems as well as new services can be incorporated into the TISPAN architecture that covers two layers: service layer and transport layer [38]. Moreover, subsystems from other standardization bodies may be imported and adapted with limited impact on the other subsystems. The ETSI NGN standards also use WLAN/3G interworking concepts, further expanding the network potential for broadband services. Figure 1.7 shows the transformations possible with the use of IMS. In the ITU-T Recommendation Y.2001, the NGN is defined as a packet-based network, able to provide telecommunication services over a multitude of broadband, QoS-enabled transport technologies, and in which service-related functions are independent from the underlying transport-related technologies. The main driver of this concept is the requirement for enabling nonproblematic access for users to networks and to enable competition of service providers, which must offer their services with generalized mobility, allowing consistent and ubiquitous provision to users. The IMS architecture is already largely access independent, but mobile network specific behavior still exists. TISPAN works together with 3GPP using liaison statements and change requests to ensure that the remaining (mobile) access network specific references are removed from the IMS specification and when necessary the TISPAN IMS adds a functionality to ensure the interworking with both fixed and mobile access networks. This interworking is assured in the core network through the PSTN/ISDN Emulation Subsystem (PES), which supports the emulation of the PSTN/ISDN services for legacy terminals connected to the TISPAN NGN. Even if it is access network independent, the TISPAN architecture is focused mainly on fixed broadband technologies and switched circuit networks [38]. But, DAIDALOS does not consider simulation, emulation, and interworking with legacy ISDN/PSTN services. As an answer, the FP6 projects DAIDALOS and DAIDALOS

10

Introduction

Figure 1.7

Towards multiservice networks with IMS [37].

II [11] developed an architecture that provides advanced features in term of mobility, multihoming, L2 QoS management, virtual identity, service provisioning and pervasiveness, and federation, many features that are not or lightly considered in TISPAN. The IMS system at the core network may be a convergence point of the two architectures [38]. 1.1.2.1

The DAIDALOS Architecture

The proposed DAIDALOS architecture [11, 38] splits the mobility management in two levels: the local domain and the global domain, and the management of the mobility in these two levels is kept completely independent. This independency is a key characteristic of the architecture, absent in the traditional hierarchical mobility management approaches; because it is what allows different access providers to manage the mobility inside their domains according to their requirements without being conditioned by needs of other operators. This brings a lot of flexibility to operators. To allow terminals to interact with different local mobility management (LMM) schemes without adding complexity in the terminal architecture, the LMM solutions should be network-based. Different network-based LMM solutions can be used within the Daidalos II architecture. A particular layer three solution was proposed in DAIDALOS II and the case of a layer 2 approach was analyzed. A common interface for triggers, based on IEEE 802.21, between the terminals and the network was proposed in the DAIDALOS II architecture. These triggers could be used by the LMM solutions to manage the mobility of the terminals, considering also QoS requirements. The architecture allows for easy integration of legacy networks that are running their own mobility management schemes, such as the 3GPP LTE Architecture and the WiMAX Forum mobile architecture [39]. A terminal that supports a DAIDALOS II functionality plus 3GPP/WiMAX would be able to interoperate in our architecture, with 3GPP/WiMAX acting as local domains,

1.1 Heterogeneity of Networks

11

without requiring any further modification [38]. Although there are already proposals in standardization bodies for network-based local mobility management, the DAIDALOS approach is innovative in several aspects, namely the following: •

•

•

The architecture builds on a network-based LMM approach, but mobility is only an aspect of the problems that an operator-driven network, has to consider. QoS support, seamless handovers, multitechnology environments, multicast integration, multihoming, scalability issues, and A4C/security/privacy are other aspects integrated in the DAIDALOS solution. IEEE 802.21 is used as a common framework for the terminal architecture and the triggers between the terminals and the network, both for mobility and for QoS purposes. This provides a solution that elegantly integrates mobility and QoS functionalities in the architecture. Local domains based in layer 2 (802) technologies were studied with particular attention to QoS, mobility, and multicast traffic requirements.

The proposed in DAIDALOS II mobility architecture is shown in Figure 1.8. One of the five key concepts proposed in DAIDALOS was the virtual identity model (VID). The VID model is a vertical aspect that impacts all levels of the architecture, and mobility is no exception. One objective of the platform regarding mobility was the seamless integration of identity into the overall architecture. A terminal running several identities was presented to the network as different terminals, providing a separate network stack for each running identity. The integration is achieved by using novel identifiers for identity, and by integrating them with the mobility protocols.

Figure 1.8

DAIDALOS general mobility architecture [38].

12

Introduction

This part of the architecture is in fact identity-based because there is a very close interaction between the identity and the mobility architecture due to the impact virtual identities have on terminal addresses. Depending on the level of multihoming used, a flow may be bound to one or more VIDs. These VIDs must be selected based on information retrieved from context, preferences, connection availability, and privacy impact. This, the paradigm for mobility evolved from terminal mobility to flow mobility in the DAIDALOS specification. Because the mobile terminals are multihomed, flows can be distributed through several interfaces of the terminal. How the flows are distributed depends on interface and network attachment availability, and most important, on preferences set by the virtual identities. With the mobility granularity scaled to the flow level, it is possible to obtain a very detailed and elaborate distribution of flows across the interfaces of a terminal. Also, due to the available granularity, mobility becomes more flexible. It is possible for the mobility management system, coupled with the identity system, to move one or more flows of an identity, a whole identity or even several identities that reside in the same device. Mobility decisions become more evolved because physical factors are no longer the main drive of point of the attachment selection. Since the integration between identity and mobility is possible, selecting a point of attachment for each flow takes into account several factors, of which the most relevant is identity-related information. A handover or point of attachment selection can be performed entirely due to user preferences, such as cost, provider, or simply user taste. The DAIDALOS architecture integrates high-level user preferences, stored on an identity basis, with the entire network stack, in order to provide the best connectivity to the user, on his or her own terms. The registration of a VIDid with a network available through an interface results in the availability of a Care of Address (CoA). The use of the CoA may reveal information concerning the VID to any party, which is able to map between CoA and VIDid. In the extreme case, if the VIDid is included in the CoA, all parties able to read a packet with the CoA are able to map it to a VIDid. However, not all parties will be able to access meaningful information from a VID through its VIDid, and thus, this impact is reduced. The CoA is then used in the global identifier registration or the home address. The home address itself is bound to a VIDid. The use of a distinct VIDid for the network access (CoA) and for the identifier (HoA) will allow entities such as the home agent and any of the correspondent nodes involved in “route optimization” to correlate both. 1.1.2.2

Multihoming

Multihoming was another aspect in DAIDALOS, defined as when an entity has several available IP ingress/egress points. The term entity is used to highlight the fact that such an entity can be considered both a physical device and a virtual device. Figure 1.9 shows an example of an example of a multisystem terminal accessing Internet and IMS services using different access networks: WLAN and Evolved-UTRAN (this is the name of the evolved access network in SAE).

1.1 Heterogeneity of Networks

13

Figure 1.9 Multisystem, multihomed terminal accessing Internet and IMS concurrently through different access networks (as defined by 3GPP) [38].

Depending on the traffic needed, the terminal will choose one access system or the other. The terminal is also multihomed, so different IP addresses are used for each PDN. 1.1.2.3

Seamless Integration of Broadcast

An NGN architecture must also successfully implement the seamless integration of broadcast (SIB). This includes two aspects: the integration of different broadcast technologies in the overall architecture [multicast/broadcast (MBMS) among them] and the efficient delivery of one-to-many network services based on multicast IPv6 [38]. For example, in order for the architecture shown in Figure 1.8 to integrate MBMS, the 3GPP network nodes from the core network (RNC, SGSN, GGSN, BM-SC) are replaced by a single node, the so-called access router (AR), receiving directly the IPv6 multicast packets and routing them towards the access network (i.e., UMTS-OFDMA). The lower radio layers of the UMTS subsystem, which is compliant with the 3GPP standard (radio interface protocols), are modified according to the MBMS specification [38]. A simplified version of this adaptation is shown in Figure 1.10. The p-t-m radio link is almost identical to its description in the standards. The cell is controlled by the UMTS AR, which establishes on request an MBMS bearer; it also establishes an interactive return channel that can be used to carry bidirectional signaling A point to remember in the scenario of Figure 1.10 is that the UMTS is not a broadcast-dedicated technology (e.g., unlike DVB). The mobile terminal is supposed to be able to support simultaneous services (e.g., the user can originate or receive a call), while receiving MBMS video content. This means that the mobile terminal resources (battery, processing power, and so forth) must be shared with unicast traffic (same resources bandwidth in the cell), and so the MBMS radio

14

Introduction

Figure 1.10

Integration of MBMS [38].

bearer should be allocated only when needed. The reception at the MT must also start only when (and if) needed. Some prioritization of services must be performed based on its capabilities, between MBMS and non-MBMS bearer services. Because the radio channels must be established dynamically, the multicast service activation requires that the entities controlling the activation of the MBMS bearer interface with the upper layer entities at the service level. This impacts the full flow for resource activation, from QoS broker to the base station. 1.1.2.4

Summary of NGN Characteristics

Combining all the above principles, next generation networks can be identified by the following common characteristics: •

•

• •

• • •

Convergence of various data communication types over the IP (i.e., data, multimedia, voice, video, fixed, wireless, and mobile network convergence); Access to a common set of services that can be provided over multiple access network types (e.g., ADSL, UTRAN, WiFi, WiMAX, IMT-A) with features such as user handover and roaming; IP-based core transport networks; Possibility for using any terminal type (PC, PDA, mobile telephone, set-top boxes, etc.); Seamless terminal, user and personal mobility; User-driven service creation environments; Common set of services, admission policies, authentication type, always available network accessibility regardless of the user connection type to the network.

The above ideas are summarized in Figure 1.11.

1.1 Heterogeneity of Networks

Figure 1.11

15

Overview of next generation network characteristics and technologies [40].

According to the definition given by the ITU, next generation networks are structured according to a transport layer and a service layer. The transport layer is IP-based, while the service layer is also IP-based but operates using the principles of sessions in order to implement control over the requested service it and, therefore, makes use of the higher layer session initiation protocol (SIP). 1.1.3

Cooperation Mechanisms

The heterogeneity of scenarios makes solutions in support of systems interactions (e.g., radio resource management) complex and multiple, meaning significant delays to execute them, degradation of QoS for mobile users, reduced throughput, unnecessary load increase in the networks, and so forth. It is therefore burdensome and inefficient to optimize traditional RRM mechanisms for a vast majority of specific scenarios. A generic type of cooperation framework can be very beneficial in this respect [41]. Work performed in standardization groups and in various IST projects on architecture for cooperation schemes between heterogeneous RANs essentially focused on cooperation between UMTS and WLAN or between UMTS and GSM/ GPRS networks since these systems are already (or currently) deployed [42–44]. Efficient interworking between UMTS and 2G networks is essential for operators to ensure continuity of service, benefit at most from previous GSM investments, and enhance networks capacity. Moreover, cellular operators want to benefit from the rapidly evolved WLAN technology and offer high-speed data services to their subscribers with one subscription, one bill, one set of services, and so on. WLAN networks could also improve their security mechanisms through interworking with cellular networks. For these reasons, there is currently a strong need for interworking mechanisms between cellular data networks, WLANs, and broadband wireless networks. Different activities have been initiated to stimulate this research further within the frames of FP6 EU-funded research [8–10]. 1.1.3.1

Interworking Mechanisms

Interworking between WLAN and UMTS networks has been driven primarily by ETSI / BRAN [45] and is going on within the 3GPP. The feasibility of UMTS and

16

Introduction

WLAN interworking was drafted in the recommendation 3GPP TR 22.934 [46], where not only different levels of interworking but also different environments were defined. Broadly, it has been classified as loose coupling and tight coupling. From a macro point of view the main difference is how and where the WLAN is coupled to the UMTS network. The choice is mainly a trade-off between the required degree of modifications to standards, the seamless degree of interworking and the complexity of the common infrastructure. Different coupling scenarios have also been investigated in the scope of the FP5 IST projects SCOUT and MIND [47]. The different coupling scenarios are shown in Figure 1.12. In the scenario open coupling there is no real integration effort between the access technologies. Namely, the following are valid: •

• • •

The current session in use will always have to be terminated as the UT enters to a new RAT; Seamless handover will never be possible; WLAN and UMTS networks are considered as two independent systems; Separate authentication procedures are used (i.e., SIM-based authentication for UMTS and simple user name and password for WLAN).

In the scenario of loose coupling, there is a common customer database and an authentication procedure. The operator will still be able to use the same subscriber database for existing 3G clients and new RATs (WLANs) clients. However, the employed loose coupling does not allow vertical handover. It allows centralized billing and maintenance for different technologies. Here, loose coupling is defined as use of a generic RAT (e.g., WLAN) as an access network complementary to current 3G access networks. Loose coupling avoids the use of the SGSN, GGSN nodes (i.e., the Iu interface). However, the new link AAA-home location register (HLR) requires further standardization. This was one solution that was regarded by many as the most attractive solution for achieving trade-off between network complexity and performance. The key characteristic of the tight coupling scenario are the following: •

Possibility of a seamless handover between UMTS and WLAN (HIPERLAN-2). This is the key difference with the loose coupling architecture.

Internet Node B

RNC

Integration

Figure 1.12

SGSN

Tight coupling

GGSN

Loose coupling

Degree of coupling in function of WLAN attachment point [45].

Open coupling

1.1 Heterogeneity of Networks

•

•

17

The additional RAT networks are connected to the rest of the UMTS network (the core network) in the same manner as other UMTS RATs (UTRAN, GERAN), via the SGSN, using the Iu interfaces by means of an interworking unit (IWU). The interconnection with GGSN as an extension to the packet-switched domain and as an alternative to the interconnection to the SGSN is not defined. Corresponding to the Iu interface the very similar new Iuhl2 interface is used to connect to the HIPERLAN-2 (see Figure 1.13.)

The very tight coupling or integration scenario is similar to the previously described method regarding the seamless handover. However, in this case, a WLAN can be viewed as a cell-managed architecture at the RNC level. This concept is not widespread because robust network planning is not applicable for WLANs yet; interference levels are not considered because in common scenarios geographical spreading of access points (AP) ensures lack of interference from neighboring cells. However, it should be noted that this method would be the ideal case from the end user’s perspective. 1.1.3.2

Cooperation Approaches

Combined RRM is a cooperation approach where the resources are managed centrally for all the involved RATs by a single functional entity. The concept is shown in Figure 1.14.

GGSN

SGSN

SGSN

SGSN

Iuhl2

Iu

Iurhl2

IWU

Iubhl2

AP

Iurhl2/utr

IWU

Iubhl2

AP

Iub

AP

NODE B

AP

Uuhl2

Uu dual mode mobile

Figure 1.13

RNC

Tight coupling interworking architecture.

NODE B

18

Introduction

Location server

GSM

GPRS

IMU IMU

RMU

UMTS IMU

RMU

WLAN

IMU

RMU

IMU

RMU

IEEE 802.16

B3G RAN

IMU IMU

IMU

RMU

RMU

Common Common Management Management Unit (CMU)

Session Manager

Figure 1.14

Combined RRM.

Figure 1.14 shows a multielement system that monitors traffic, predicts and recognizes shortcomings, and reacts to cellular network congestion situations in overloaded sectors of cellular networks [47]. The presented system is introducing new network units, namely, the interface monitoring unit (IMU) and the resource management unit (RMU). The IMU monitors the available and used resources in all the system interfaces. This data is then forwarded to the RMU, which consists of a traffic load scenario tracker to find the correct scenario for the congested situation and a decision-making tool to apply the appropriate management technique. Based on this mechanism, a capacity management architecture was designed for a general cellular network architecture, with additional components for traffic monitoring and decision execution [48, 49] able to support system management between different RANs belonging to different operators. The core of RRM activation is the real-time key performance indicators (KPI) monitoring. Once a technique has been selected to deal with a congestion event, the parameters necessary to instantiate the technique can be either obtained by similar application cases stored in the database, or can be computed with a fine-tuning model-based approach, which optimizes the resource management technique (RMT) to meet the network operator goals for the

1.1 Heterogeneity of Networks

19

current scenario. The knowledge gained through experience is stored in the RMU database, and will be reused to enhance future decision-making. Moreover, the database information is also processed to obtain hints on the quality of the basic knowledge provided by the operator, and suggestions for possible modifications and updates. An example of an RMT is dynamic signaling channel allocation, cell-breathing, modification of the BCCH list, and so forth. All RMU decisions and the consequent results can be recorded by the knowledge base manager into its internal database, which is used as a source of information for the tuning over time of the RMU operation. 1.1.3.3

Common RRM

Common RRM (CRRM) is a solution developed within the 3GPP UTRAN and GERAN groups to make UMTS and GSM/GPRS networks cooperate. CRRM is a mechanism for intelligent distribution of traffic among these systems, offering the possibility to increase the overall network capacity and user perceived QoS, thereby reducing network costs. In Release 99 [50] procedures for intersystem handover were defined, but they could result in a failure due to the high load in the target cell. The Release 5 [51] work resulted in the introduction in GSM and UMTS of the possibility to exchange cell load information between the RNC and BSC. In 3GPP, the whole set of radio resources for an operator has been partitioned into “radio resource pools.” A CRRM server was introduced as a new logical node in UTRAN and GERAN. These radio resource pools are controlled by two different types of functional entities: 1. An RRM entity, which is responsible for RRM inside one radio resource pool (one pool may include one RAT, or one/more cell layers or one/more operating frequencies); 2. A CRRM entity, which is responsible for coordinating a certain number of RRM entities, to balance the traffic between the overlapping/neighbor radio resources pools. CRRM should direct users in idle and connected mode to the most suitable the cell and resource pool. Suitability may depend on, for example, on the user service and network constraints, such as minimizing interference, load balancing, and so forth. The CRRM entity is introduced to allow some kind of coordination among different radio resource pools whose radio resources are linked to the same geographic area in the network. The principle of coordination of different radio resource pools by means of CRRM is shown in Figure 1.15. There, rc-i/f is the message exchange between the RRM and CRRM entities, and cc-i/f - between two CRRM entities. The functional relationships between the entities of the functional model are based on two types of functions: 1. Reporting information; 2. RRM decision support.

20

Introduction

cc-i/f CRRM

rc-i/f

RRM

CRRM

rc-i/f

RRM

rc-i/f

RRM

Reporting information RRM decision support Configuration information exchange (O&M) Figure 1.15

Coordination of radio resource pools by CRRM.

While rc-i/f supports both types of functions, cc-i/f only supports reporting information and can thus be regarded as a subset of the rc-i/f. In the 3GPP specifications, the two functions of these interfaces are described in more detail in [52]. Different architectures are possible to enable CRRM and several solutions for the mapping of functional entities into physical entities have been proposed in 3GPP and literature. A “CRRM server” approach implements RRM and CRRM entities into separate nodes, while CRRM is a stand-alone server. All the interfaces among RRMs and CRRMs are open. A CRRM server first gathers measurements from cells under its coverage. Then, for each specific operation (handover, cell change order, etc.), the RNC/BSC sends to the CRRM server the list of candidate cells, including the mobile measurements for these cells and information about the QoS required by the user. The CRRM server, after applying some algorithms, returns the prioritized list of candidate cells. The load of each cell can be considered in the prioritization process, but other aspects (to be defined) can be included. The integrated CRRM approach integrates the CRRM functionality into the existing UTRAN/GERAN nodes. The Iur and the proposed Iur-g (between the BSC and the RNC) interfaces already include almost all the required ingredients to support the CRRM functionality. The main benefit of this integrated CRRM solution is that with limited changes and already existing functionality it is possible to achieve optimal system performance. Finally, 3GPP considers that the RRM algorithms cannot be completely moved to an external CRRM. Some part of the functionality will always reside in the other entities. This means that all three systems need to be tuned to achieve optimal performance, making the system tuning more cumbersome. The authors of [53] proposed to 3GPP a policy-based CRRM approach for Release 6 as an attempt to standardize an open interface between the RRM and CRRM entities. This would allow a centralized CRRM entity to provide policies to the RRM entities, thus enabling the traffic situation to be dynamically adjusted in the network on the basis of a common strategy.

1.1 Heterogeneity of Networks

21

The CRRM server can act as a policy manager for the access to the cells and the radio bearer resources within UTRAN and GERAN, by performing the RRM algorithms that are based on dynamic status information per cell from all the cells in the system. The CRRM server can also be connected to other RANs than UTRAN/ GERAN in the future, allowing dynamic intersystem RRM. With the introduction and integration of several systems with several modes and several layers, resource management becomes a more and more complicated task. For example, handover and load sharing algorithms must not only maintain the connection at a reasonable quality, they should also consider whether it would be beneficial to move the connection to another system/layer/mode. This decision is not solely based on changing radio propagation, but also on system load, operator priorities, and service quality parameters. Many CRRM functionalities, such as intra-RAT/interfrequency handover, directed retry, service handover, are already supported in the current standards. The Iur and the proposed Iur-g interfaces already include almost all the required ingredients to support the CRRM functionality. Therefore, a natural approach for next generation systems is to continue this path and improve the existing CRRM functionality. The main benefit of the integrated CRRM is that optimal system performance can be achieved with limited changes and already existing functionalities. Most importantly, this is achieved without introducing additional delay, which will deteriorate the delay sensitive procedures at call setup, handover, and channel switching. Furthermore, the additional delay will have adverse impact on the trunking gain, especially for the bursty traffic, which will cause reduced radio resource use. In addition, delayed handover decision and execution will have negative impact on power control and thus reduced system capacity. The delay requirement on the channel switching would, in practice, limits the possibility to interrogate the external CRMS, thus reducing the possibility to achieve an optimal system performance. With integrated CRRM, the SRNC or BSC, based on its intra and intersystem knowledge and the capacity, makes decision on whether to perform channel switching, interlayer, interfrequency or inter-RAT handover. In 3GPP two main approaches were considered to support CRRM in UTRAN and GERAN: tight (integrated) CRRM (TR 25.881) and loose RRM (TR 25.891). Loose architectures are based in a CRRM server linked by open interfaces to the RNC for UMTS and the base station controller (BSC) for GERAN. The CRRM server establishes CRRM policies and each RAT executes RRM algorithms according to the CRRM server policies. Within this approach, CRRM may contain updated and ordered information from the different RATs. Tight CRRM incorporates the RRM functions into the existing UTRAN nodes; therefore, proprietary interfaces are needed and nonradio dependent messages get through to each RAT air interface. So far, no standard RRM entity exists to manage WLAN access. Loose coupling, however, is a preferred solution for managing WLAN and 3GPP (TS 23.234) CRRM requires deeper investigations, from standardization and suppliers, to define more precisely what information can be exchanged and how, to define the impact of CRRM on RRM entities, and to determine an architecture to support this functionality.

22

Introduction

1.1.3.4

Joint RRM (JRRM)

Joint RRM was proposed in [54] for intelligent interworking between different RATs using a central controller to manage the overall capacity of the subnetworks. The architecture of the JRRM is quite similar to the one of CRRM, except that JRRM is not restricted to UMTS and GSM only. Moreover, JRRM complements the CRRM approach by several modifications and additional features. A very tight coupling allows for joint managing of traffic streams between the networks and the terminals. Joint radio resource scheduling and admission control are therefore required to optimize spectral efficiency, handle various traffic types, and QoS constraints and schedule traffic adaptively. In particular, optimal QoS can be achieved with traffic splitting supported by adaptive radio multihoming, which provides multiple radio access for a single terminal in order to allow the terminal to maintain simultaneous links over RATs. The major features of JRRM are: •

•

•

Traffic prioritization and splitting, whereby the incoming traffic is split over two or more substreams. The important information goes through a reliable RAT, the rest through other RATs. Synchronization, whereby packets belonging to a substream are multiplexed back to original traffic stream in the receiver based on proposed synchronization schemes. Buffer management, whereby jitter and average delay parameters are controlled by the buffer size and synchronization approaches. The static terminal and user profiles stored on the network side will be retrieved by the RNC to determine the calculation power and buffer size of the terminal, and to evaluate the user preference and cost. The synchronization methods are used mainly to compensate average delay, whereas buffers are used to compensate for jitter.

The JRRM architecture is based on the assumption of coexisting of different RATs with different profiles and is shown in Figure 1.16. Each RAT needs an efficient interworking between the traffic volume, measurement function, traffic scheduler, load control, and admission control function. The traffic estimation module (TREST) informs the administrative entity session/call admission control (SAC) in every subnetwork on the predicted traffic and planned traffic information in order to update the priority information of each connection and the admission decision within the network. The main JRRM functionalities are the following: •

•

Load controller in charge of evaluating the traffic carried at a given moment considering its characteristics (real/nonreal time). To do this, the statistics are updated considering a long-term and a short-term value. The long-term value represents the mean value considering a long period of time whereas the short-term value represents the current situation. The combinations of these give a good evaluation of the system performance for a given load. The computation of the intersystem handover success probability so as to avoid the triggering of unnecessary handover, which will degrade the system performance of the hosting RAN. To obtain this value, two components are

1.1 Heterogeneity of Networks

Figure 1.16

•

23

Functional architecture of JRRM and delay factors [55].

considered. First, the probability that the user performing an intersystem handover will receive the expected QoS has to be maximized. Second, the impact of this intersystem handover on the hosting system performance has to be minimized: that means that no degradation has to be observed. In particular, the triggering of an intersystem handover could be initiated by the fact that a user is not receiving the desired or expected QoS and no further solution is available in the current RAN or the RAT is overloaded. The KPIs that should be monitored are the load of each RAT, the performance of each RAN under the present load depending on the blocking probability, the dropping probability, poor packet error rate (PER) probability, or bad quality call (BQC). After computing all these values the JRRM will notify the user and the concerned RANs of its decision of accepting or refusing the intersystem handover. A joint call admission controller (JOSAC) to direct immediately a new user/application to the most adapted RAN related to his request (most adapted meaning in terms of offered QoS, load conditions, current performance). Without such an entity, the probability that the user would have to perform an intersystem handover is not minimized. The JOSAC takes the neighboring RAN system load into account. JOSAC is one JRRM approach. It does not offer detailed traffic splitting to subnetworks, but only alternatively diverts traffic into different subradio-networks. The traffic stream is routed through the cooperating systems according to the restrictions and advantages of each system. From the service point of view, different levels of

24

Introduction

•

•

service calibration can be identified to meet the user’s satisfaction. In particular, the reasons to split the traffic through subnetworks are: to reduce the traffic load over individual networks and to provide higher QoS to the user according to his profile, demands, and network architecture. For joint admission control, the traffic and the session/messages cannot be split over different networks, but can be admitted alternatively to a different one in a packetswitched scenario. A traffic optimizer, which would be responsible for finding a solution to specific big issues taking into account the global radio network. Those issues could be for instance a mass upgrade scenario, or an increasing demand for video during a sport event. A joint scheduler in order to keep the same QoS in individual RATs as well as the synchronization to ease the higher layer multiplexer/decoder. The joint resource scheduler (JOSCH) is important for terminals working with simultaneous connections to different networks. JOSCH is responsible for scheduling traffic streams being split over more than one RAN. It helps to optimize the use of radio resources in the whole system. It also synchronizes the stream being split, (e.g., video stream with basic layer and enhancement layer being transmitted over different air interfaces individually or separated main object and inline objects of HTTP service belonging to the same session). This approach is supported by the adaptive radio multi-homing (ARMH) protocols.

Adaptive Radio Multihoming (ARMH)

The ARMH concept is a term extended from the multihoming concept. It provides multiple radio access for a single terminal in order to allow the terminal to maintain simultaneous links with the radio network. From the radio resource point of view, traffic splitting supported by joint scheduling under the concept of adaptive radio multihoming will increase the system capacity and provide better user QoS. The multihoming concept manages IP traffic that is being routed through different RATs. From the radio resources point of view, traffic splitting will increase the system capacity and provide better QoS to users. Besides that, there is further advantage of having parallel streams. If one bearer service has a high availability in the network (low data rate bearer services result in high coverage, e.g., a 16-Kkbps service is available in 99% of the cases), this link would be used for transferring important information to the terminal, but it cannot fulfill the requirements for multimedia traffic. A higher QoS for the user is obtained if the traffic is intelligently split into rudimentary and optional information streams. For example, for the case of a UMTS and a WLAN RATs, the video traffic can be split into base and enhancement layers, where the base layer consists of the most important low frequency information. HTML traffic can be split into main and inline objects of an HTML page; control signaling and highly required security information could be transmitted through UMTS and the normal user data through WLAN. The user combines both streams whenever this is possible in order to achieve a higher QoS. Due to the higher availability of a lower data service in UMTS, a minimal QoS can be fulfilled to the user otherwise.

1.1 Heterogeneity of Networks

25

Suppose that a user with a reconfigurable terminal demands a scalable video service from a remote server through tightly coupled subnetworks (UMTS, WLAN), which are controlled by one RNC. The procedure that will be followed is: 1. The RNC receives an application from the UT. After estimating the available radio resource in the controlled subnetwork, the RNC will apply to the remote server for traffic splitting indicating the average rate in each sublink. 2. Traffic is split and sent to the RNC. The substreams are labeled differently. 3. The RNC receives traffic with labeled packets to further map to tightly coupled subnetworks. Possible services are video and audio, HTTP, scalable video traffic, real-time traffic, and its control signals. 4. The synchronization mechanism in the RNC remedies the delays generated by radio subnetworks due to the different TTI value for the bearer services, ARQ actions due to different connection qualities, and different processing power of the different base stations. Due to the heterogeneity of the coexisting networks the performance of a joint scheduling algorithm will be highly dependent on the synchronization. In nonsynchronized traffic from different layers, if the delay difference overrides a certain threshold, the user/terminal will not wait until all the information from different sublayers is received. Also, the target of scheduling is to reduce the individual system load in subsystems. The synchronization mechanism is very important for JRRM, especially for the joint scheduling algorithm, which deals with traffic splitting over the radio networks. 1.1.3.5

Concurrent RRM

Concurrent radio resource management (ConRRM) is another mechanism for the efficient management of radio resources across different RANs. Contrary to the centralized entity of the JRRM concept, a local entity allocates the resources within each RAN. These entities have to cooperate in a distributed manner to come up with an efficient resource use. It can be expected that the different RANs are connected via the Internet, which will be based on TCP/IP [31]. Consequently, it is expected that RRM, (i.e., mobility management and QoS control) should be addressed using IETF schemes. For example, for the case the technical specification produced by ETSI/BRAN (i.e., HIPERLAN/2) the functionality in the control plane of the AP and the respective interface between the AP and core network would allow for cooperation with the IETF schemes [45]. The functions that have to be supported in the control plane of the AP comprise the network management, AAA, admission control to ensure QoS across the core and access network, user data forwarding, mobility support (handover and roaming between networks), and location management for location-based services. For network management the task can be split between a network manager located in the core network and a management agent that resides in the RAN APs. The information maintained by the management agent could include the QoS provided to the active traffic flows. This information could be stored in a management information base (MIB) [46]. For the network handover,

26

Introduction

(e.g., between WLAN and UMTS), mobile IP can be used. In addition, respective functions can be foreseen for fast handover, (e.g., context transfer). The context transfer may occur before, during, or after the handover to avoid transferring information on the radio link between UTs and APs [56]. ConRRM fits quite well to the loose-coupling architecture as above. Loose coupling allows for flexibility and rapid deployment, which in turn demands a distributed RRM mechanism. 1.1.3.6

Layered RRM

A wireless network can be formed not only of multiple technologies, but also of multiple domains. This indicates four specific cases of interaction, namely, single technology–single domain, single technology–multidomain, multitechnology–single domain, multitechnology–multidomain. Current RRM solutions consider the first case, where radio resources are managed solely at the link layer (L2). With a single technology but multiple domains it is also possible to have a L2 solution. On the other hand in “native-IP” environment this could cause conflicts with the network layer (L3) interactions that will be taking place. Therefore communication with L3 entities is very important. When multiple technologies are introduced, different link layers (L2) will interact with each other and there should be a layer, which will be the bridge between the technologies. This layer could be the IP layer (L3) through the IP2W interface. At L3 a decision can be made for the best resource management across the multiple technologies. In the multitechnology-multi domain case, L3 decisions are needed not only in order to allow for cross-technology RRM, but also to remove any inter-domain management conflicts at L3. Figure 1.17 shows a framework for the multilayered approach. Entities related to RRM are found at both L2 and L3 whereas a convergence layer, namely, IP2W, provides the generic interface between L2 and L3. The multilayered approach has a manager function that manages interactions between RAT (A-T)-specific RRM entities, such as coordinating handover. In [25] and [59], the location of the RRM functions is divided between the link layer and the network layer, considering the information requirements and functions that are available at other layers. The division of the RRM architecture on each layer is based on the “target object” or “environment” that will need the RRM function. However, there are some cases, where the RRM entity is relevant in both layers (L2 and L3). In these cases, the function is divided across both layers with different aspects of the function resident in different places coinciding with different target objects or environment. For functions of that kind (that split between two layers) there must be close cooperation between layers to ensure efficient RRM control. One approach is to use the resource controller function as gateway between layers. This is shown in Figure 1.18. The scheduler on the network layer side guarantees that all flows receive the desired service. The scheduler and its queue in L3 should be aware of the link layer conditions and receive the information about the current state of the L2 scheduler from the resource management entity, (e.g., condition of L2 buffers/queues). The L3 queues and scheduler send their current state to the L3 resource management entity.

1.1 Heterogeneity of Networks

27

Manager function

A-T specific RRM entity (RAT 2, domain 2)

A-T specific RRM entity (RAT 1, domain 1)

IP2W

IP2W

IP2W

L2 RMM entity

L2 RMM entity

L2 RMM entity Rat2 L2 techniques

Rat1 L2 techniques

Figure 1.17

A-T specific RRM entity (RAT 1, domain 3)

Rat1 L2 techniques

Layered RRM.

Intersystem HO Mgmt End-to-end QoS Mgmt

g

plin

Cou

Scheduler-1 at BS/relay

Scheduler-2 at RRM controller Predictive component: RAN aspects

Predictive component: user/cell aspects Enhancements to the physical layer

Radio access part-air interface link

Radio access part-link to L3 and above side

Figure 1.18 Layering of RRM functions for efficient resource distribution between all layers and handover management between different RANs.

The L2 queues and scheduler send their state to the L2 resource management entity (e.g., current PHY mode allocation, PER, load of the system, error correction/checking mechanisms). This information is used to decide on when the channels can be used.

28

Introduction

It is clear that queuing and scheduling has L2 and L3 aspects and it should be present in both layers, but a very close coordination is required between these functions. The signaling protocol may be possible to piggyback RRM information into existing L3 signaling protocols in the network, but it is difficult to guarantee that all the nodes in the network, where the RRM information is required, will process these messages. Otherwise, a dedicated protocol may be developed, with the desirable characteristics for distributing the RRM information to the relevant nodes in the network. 1.1.3.7

Cooperation for Next Generation Systems

A solution for multilink, multinetwork radio resource provisioning and control was proposed in [49, 57–59] for the WINNER radio system and its successful coexistence with legacy or yet to be developed systems. The proposed framework was based on the tight coupling scenario and the CRRM approach. As an additional feature and in support of intrasystem interworking, a solution was proposed based on a JRRM approach. The resulting architecture supports a centralized and distributed approach to RRM [57]. The main decision-making point is a CoopRRM entity located outside of the RANs. One requirement of the cooperation architecture was to provide some inter-RAN services such as admission control, handover, scheduling, and QoS-based management, and other services, such as billing, authentication, authorization. A specific RRM entity (SRRM) implementing the RAN-specific RRM mechanisms is located within each RAN. In a situation, when a local RRM approach is not sufficient to ensure seamless user mobility, the decision center would be shifted to the CoopRRM that would execute and appropriate algorithm to resolve the occurred problem. Thus, the proposed implementation is of generic nature that does not require major changes in the individual RAN architectures, and allows for easy inclusion of any newly designed RAN. The SRRM module located in the legacy RAN (hereafter referred to as SRRML) implements two types of functionalities and interfaces, one for traffic monitoring and reporting of physical legacy nodes and the other devoted to the direct actuation of the RRM algorithms in the legacy RAN nodes. In other words, it translates the CoopRRM commands to the legacy RAN. The SRRM in the IMT-Advanced reference RAN (hereafter referred to as SRRMW) implements the monitoring and actuation functionalities and also the support of the functionalities related to the inter-RAN cooperation and the internal RRM coordination functionality (i.e., SRRMW is distributed in the RRM server, GW and BS, respectively). This two-way communication is for transferring monitoring information, but also for executing global RRM techniques. For the congestion case, the CoopRRM will not be able to change any of the parameters of a legacy RAN, but for handover cases the CoopRRM could change some RRM parameters in the legacy RANs. The reference protocol architecture is shown in Figure 1.19. The proposed protocol architecture was aligned with the concepts developed by the FP6 IST project Ambient Networks [5], as well as the projects E2R and MobiLife [55] as part of the proposed World Wireless Initiative (WWI) concept.

1.1 Heterogeneity of Networks

29 CoopRRM

Inter -RAN cooperation mechanisms

Legacy system

B3G RAN

(UMTS) SRRM

SRRM

Actuation

Monitor

Monitor

Actuation

Iu

RRC (C plane)

RNC

(C plane) plane

L3

(U plane) plane

L2

U /C Planes

NAS

IPCL

RLC MAC L1

Figure 1.19

1.1.4

Transport Network

Transport Network

PHY

Reference protocol architecture for cooperative RRM.

Network Security Requirements

Network security in next generation systems is needed to protect the service provider from theft of service, to protect the user’s privacy, and to mitigate denial of service (DoA) attacks. Next generation systems (e.g., IMT-advanced) will need provisions for authentication of both BS and UT, for privacy, and for data integrity. Link layer security should be part of an end-to-end security mechanism that includes higher layers such as transport layer security (TLS), secure sockets layer (SSL), and IPSec [31]. Protection of user data traffic and signaling messages across the air interface should also be supported. In addition, next generation systems should provide protection from unauthorized disclosure of the device permanent identity to passive attackers. The Internet Protocol (IP)-based technologies of a next generation system architecture should enable secure communications with an identity on every packet, or, at a minimum, an identity within the domain name service (DNS), with which to identify the communicating parties with the host identity tag in the domain name system (DNS) resource record. Independent identification of equipment and user for authentication purposes should be enabled. The identity of the equipment may be obtained from a certificate, smart card, subscriber identity module (SIM), universal SIM (USIM), user identity module (UIM), password, and so forth. The identity of the user may be obtained from a smart card or an authenticated identity source

30

Introduction

and translated to a packet identity that is included the network packets (e.g., IPSec ESP field). The provision of emergency services should also be supported. In summary the security aspects identified for next generation systems include [31]: •

•

•

•

•

•

• •

Support of network and UT mutual entity authentication and session key agreement protocols. After authentication of the UT the network may perform authorization before providing service. Allow for flexible UT and/or user credentials for authentication to be specified by the authentication server. Enable data confidentiality on the air interface for user and control plane traffic. Enable message integrity and origin authentication across the air interface to protect user data traffic and signaling messages from unauthorized modification. Layer 2 mobility needed to support crossing network boundaries without losing the connection or the security association. Providing a method to ensure messages are fresh to protect against replay attacks. Protection of both user and control plane data over nonsecure backhaul links. Inform the network that the physical security of the cryptographic module has been compromised.

1.1.4.1

Privacy

Next generation systems will include privacy and authentication functions, which provide the necessary means to achieve the following: •

•

•

•

•

Protection for the integrity of the system (e.g., system access, stability, and availability); System access via certificate, smart card, SIM, USIM, UIM, password, and so forth; Protection and confidentiality of user-generated traffic and user-related data (e.g., location privacy, user identity); Secure access to, secure provisioning and availability of services provided by the system; Secure operations, administration, maintenance and provisioning (OAM&P) of system components.

Example procedures that can be used to achieve the above-stated goals include user/device authentication, integrity protection of control and management messages, enhanced key management, and encryption/integrity protection of user generated and user-related data. The impact of these procedures on the performance of other system procedures, such as handover procedures, must be minimized.

1.1 Heterogeneity of Networks

1.1.5

31

Quality of Service

Multimedia applications rely upon the transmission of audio and video data elements at guaranteed rates and with bounded latencies. Such streams differ substantially from the message-based type of traffic, for which packet transmission is designed. Video and audio streaming require larger bandwidth. For example, the transmission of a video stream for display in real time requires a bandwidth of about 1.5 Mbps if the data is compressed, or 120 Mbps if uncompressed. In addition, the flow is continuous. An important parameter here is the play time. The play time of a multimedia element is the time at which it must be displayed (for a video element) or converted to sound (for an audio element). The play time (i.e., download time) is calculated by dividing the number of a frame by the frame rate. For example, if the frame rate is 24 frames per second, frame N will have a play time of N/24 seconds after the start of a stream’s time. Packets arriving after that time are no longer useful and will be dropped by the receiving process. The timely delivery of such data streams depends upon the availability of connections with guaranteed quality of service (QoS) (i.e., bandwidth, latency, reliability must all be guaranteed). What is needed is the ability to establish a channel from the source to the destination of a multimedia stream, with a predefined route through the network and a reserved set of resources at each node through which it travels and buffering where appropriate to smooth any irregularities in the flow of data through the channel. To provide QoS guarantees means that we need to make sure resources are preallocated and enforced. The evaluation of the QoS provided over a digital communication link is most commonly given by an estimation of the bit error rate (BER). It characterizes the ability of the channel coding and signal processing algorithms to mitigate the noise or the interference encountered during the transmission by measuring the ratio of correctly received bits. Such investigations and evaluation results were described in [60]. In a user-centric approach, however, and in particular, for packet data-based systems, the BER does not allow to derive directly the QoS perceived by the user. Also the frame error rate (FER) (or packet error rate-PER) is only an intermediate measure [61]. The most relevant performance metric that can be derived within the RAN for the QoS perceived by the user is the user throughput. It is defined as the ratio of correctly received information bits on layer 2 (radio link control layer) of one link to the total time elapsed. It thus includes all the redundancy and control overhead needed for the transmission and the different retransmission strategies in case of erroneous frames. Various link adaptation algorithm and retransmission strategies (e.g., hybrid automatic request or HARQ) can be thus compared with one clearly defined performance metric. Furthermore the cumulative distribution function (CDF) of the user throughput values of all users is an important measure for user satisfaction and coverage [61]. Furthermore, packet delay minimum requirements should also be used in order to address short-term latency aspects.

32

Introduction

The packet data service capability should still be included and there should be separate values for the different environments because different services required in the different environment can be assumed. No specific figures have been proposed for the moment but a general idea is that the values should be tougher than the ones mentioned in [31]. Overheads are also important to include in a QoS evaluation: the transmission of an application-level message via a protocol stack with N layers typically involves N transfers of control and N copies of encapsulation. This leads to overheads. Overheads cause lower data transfer rates between application processes than the available network bandwidth. Overheads will be affected also by implementing security solutions. Another challenge is the difference between Internet applications versus streaming applications. It is difficult to distinguish Internet applications because the Internet’s implementation does not follow the OSI model. For example, application and presentation layers are implemented as a single middleware layer or separately within each application. Messages are divided and reassembled into packets at the transport layer. Packets consist of a header and data field. The data field is variable in length; the maximum length is the maximum transfer unit (MTU). If the length of a message exceeds the MTU of the underlying network layer, it must be fragmented into chunks of appropriate sizes and transmitted in multiple packets. Table 1.1 gives a summary of applications to be delivered through next generation systems and their security and QoS requirements.

1.2

Service Platforms The development of new ICT devices and network-based services has generated numerous configuration procedures, access technologies, and protocols [62]. New areas of research, such as pervasive computing, will further increase the diversity of the devices and services with which they have to deal. The result is increased complexity for nontechnical users, service providers, and network operators. Excessive complexity creates obstacles to effective exploitation and acceptance of next generation systems such as ambient intelligence, context-aware services, and novel access technologies. For nontechnical users, excessive complexity can become an obstacle to accept already deployed new technologies. Personalization of services is another of the observed trends for next generation systems. The personalization concept is based on the concept of a “user profile.” Each user is provided with a personalized profile, providing access to different services, perhaps using different classes of terminals [63]. Creating and maintaining a user profile involves the automatic processing of behavioral information (though the user will be able to switch off automatic storage and/or delete specific information). More refined policies on how to handle specific types of personal information can be part of the user profile and could be controlled by the user. Full control of personal data, security of information, and user privacy are key issues for the personalization approach.

1.2 Service Platforms Table 1.1

33

Applications for Next Generation Mobile Users and Security Requirements

Applications

Security Concerns

Security Requirements

File transfer

Need for trusted communication Need for secure communication link

Secure attachment Secure link layer Authorized access to network Protection of wireless traffic Security of operations related to device reconfigurability Authentication of user, equipment, usability User-friendliness Protection of context

Audio/video conference requests via voice commands

Trust status information Identity verifications Secure environments (no eavesdroppers)

Privacy protection; Visualization of trust relations Security for mobility Secure network discovery; Secure network attachment

Remote access

Authentication process Trusted channel Trusted operation

Monitoring of user, equipment, applications, and service trust status Trusted execution environment Trusted implementation of interfaces and application and service access Recovery from network failure Authorized network access Monitoring and handling of trust status and profile

Personalization based on user profiles is already an important issue, and context information (such as network status, location, device profiles, etc.) is increasingly being incorporated in order to adapt services to achieve the best user experience. Context and knowledge management is a way to make service provision seamless to end users. It is a very important feature of a service platform, particularly where services are expected to behave intelligently, learn, exhibit awareness of their surroundings and react to changes. Context generally refers to all types of information pertaining to a service and or the user of the service. Knowledge typically refers to more general information, of which context is a specific type. Knowledge would typically include information about users and their preferences, and also information that can be inferred from other sources. The user profile can be quite complex and is highly dynamic [67]. It contains static parts describing the user’s identity as well as several user preferences covering general user preferences, context- or application-specific user preferences, security and privacy preferences, and so forth. The user profile represents a separate entity, which always follows the user. It is not part of the context information, but when a user is present in a specific context, the user profile must be applied to this context together with the available context information to find the best compromise for

34

Introduction

adapting the service. If the service is only weakly dependent on context information, the user profile alone may be used to adapt the service. A number of FP6 IST projects [13, 20] worked on the development of tools, techniques, and architectures to remove this complexity, enabling users to customize devices and services with minimal effort. The composition and handling of the user profiles as well as the development of context-aware service architectures was the subject of intense research in the FP6 IST projects SIMPLICITY [62], MOBILIFE [64], DAIDALOS [11], and SPICE [65], MAGNET and MAGNET Beyond [66]. The latter focused on the above issues in the context of the personal network (PN), as a personal, secure, and trusted network environment, and that of the PN Federation, where users (temporarily) form a trusted relationship and share resources to accomplish certain tasks. Users are expected to frequently need to access “the outside world” and use foreign or external mobile 3G and Web-based services, and the PN must also provide the proper interface and security to handle such actions [67]. In order to deliver personalized services the following capabilities are required from a service platform: • •

• •

•

Store user profiles and cache context information; Provide external profile information, for example from an identity provider or an operator, who may already be managing user data, (e.g., through a generic user profile (GUP) server [68]; Provide additional input by the user; Manage local context information (e.g., from sensors or network management nodes); Manage remote context information from other cluster of a PN or from external sources.

The GUP provides a means of supporting access to data for ranges of services and functions (e.g., mobile multimedia service (MMS), presence). The support of user services and personalization data may result in manipulating data in a structured manner and a standardized way of describing and accessing these data structures, utilizing a data description method based on an XML scheme. The administrator/suppliers and consumers of the data can be divided into the following groups of applications: applications in the home network, third party applications, OAM, and subscription management applications. The goal is to minimize the need for user interaction and to provide intelligent or proactive support for the users by making use of all available and relevant information. Different options exist, namely the following: •

•

•

The framework may be contained within the user’s client device, if the device has enough storage and processing capability; The framework is distributed within the network, making use of more powerful nodes and connections outside of the network; The framework is managed by—or interacts with—external identity and personalization providers or even operators, who may provide the personalized services as an add-on to their basic services.

1.2 Service Platforms

1.2.1

35

Service Adaptation

Adaptation of a service is based on processing and filtering to extract/identify the relevant parts of the user profile and the context information. This processing can be done within a service context management framework (SCMF) [66], by an application logic of the particular service, and so forth. Services may be invoked by the users (“pull” type), or external service providers may want to target the user (e.g., the “push” type of service). In both cases, the SCMF will hold access rules for the services. Services can have a list of associated personalizable parameters such as volume or QoS. During service instantiation, personalization returns the preferred values for requested personalizable parameters to the instantiated service allowing it to personalize itself. Services may need to re-personalize due to context changes. When these occur, personalization will notify any updated preference outcomes to the appropriate services allowing them to repersonalize at runtime, dynamically changing to meet the user’s needs. Such context changes may also affect the architecture of a running service. Composite services, made from two or more services may need to be recomposed due to a context change. For example, if a composite service includes display service X, a change in context may mean the user now prefers to use display service Y. In this way, personalization may trigger a service recomposition (to replace X with Y) to provide the user with dynamic services, which update to meet his or her current needs. In general, the problem is of how to match a user’s profile and privacy policies with the service policy or requirements set by the other actors involved. An external service provider may for example request information about the user’s location, but the user may have set a policy that he or she does not allow the location to be disclosed. If a conflict like this cannot be resolved, the service cannot be delivered to the user. A possible solution to this problem may exist in the current standards. The FP6 project SIMPLICITY [62] reduced this inherent complexity by designing an architectural framework that has the following capabilities: • • •

Automatic customization of user access to services and the network; Automatically adapts services to terminal characteristics and user preferences; Orchestrated network capabilities.

The SIMPLICTY user profile is an implementation of the GUP extended to a simplified user profile (SUP) by adding a broker (mediator) architecture, a user profile stored on the SIMPLICITY device (SD) [69], policy framework, and SIMPLICITY personal assistant. The access to the SUP is more distributed (trend towards ambient intelligence and ubiquitous computing) compared to the 3GPP GUP. This is shown in Figure 1.20. 1.2.2

Cross-Domain Service Access

Traditional service platforms do not address cross-domain issues (from an application or service point of view) because they lack an application management view across operator borders, countries, information, administrative, and cultural barri-

36

Introduction

Applications

Rg

GUP Server

Applications

Rp ??? RAF GUP Data Repository

Figure 1.20

É

RAF

É

GUP Data Repository

Terminal Broker Simplicity Device

Rg like

Network Broker(s)

SIMPLICITY and GUP comparison [67].

ers. Moreover, legacy regulatory and legal environments do not facilitate the enabling of cross-domain personalization services. In turn, the traditional service creation environment is a closed environment that can be used on a single vertical platform. Creation of services in a multiplatform environment and their integration was one goal of the EU-funded research. The FP6 project SPICE designed and implemented an architecture that defined a service platform enabling cross-domain service access with service roaming support [65]. In addition, it combined several key technologies such as a semantic component-based middleware, service brokering and mediation mechanisms, lifecycle management, context-awareness, and multimodality. Building on the significant advances in IT technologies, the SPICE overlay structure enables large-scale service introduction through its support of multiple heterogeneous execution platforms. This means that new and existing services can be spread in a very short time across different operator domains, over different countries, and supporting a large variety of business models. Such an approach allows multiple terminals to cooperate with the service platform. Furthermore, it supports intelligent service enablers that allow for easy provisioning of intelligent and personalized services, and for efficient and managed distribution of multimedia content. The SPICE platform capabilities can be described as follows: • • • • • • •

A flexible overlay architecture for service creation, deployment and execution; Open and controlled service access; Intelligent services for service personalization and adaptation; Loosely-coupled semantically described services; Distributed communication sphere management; Multimodal content delivery; Service roaming.

Figure 1.21 Shows an overview of the SPICE service platform. The capabilities and enablers layer is responsible for providing the various support functions of the service platform. The support functions play a major part in

1.2 Service Platforms

Figure 1.21

37

SPICE architecture layered design [70].

enabling the core functions of the service execution environment (SEE). The support functions are external to the platform. The component services layer provides facilities for component-based development, deployment, and lifecycle management. This layer includes the basic components, and various middleware components. The knowledge layer provides service platform solutions for intelligent service behavior, user profile management, and proactive service adaptation. These solutions are grouped in different enabler families in the platform shown in Figure 1.21 that are all built on top of a common framework. The value added services (VAS) layer facilitates the creation of composed components from the basic platform components. A composite component is needed, for example, for personalized ticket booking or for finding nearby restaurants that match the user’s preferences. Semantic composition is needed to achieve value added services. Semantic metadata of the components is in machine-processing format and knowledge discovery is used to find suitable components for composition. The orchestration engines in this layer are responsible for ensuring that the components of a composite component network are properly synchronized and the interactions follow the predefined rules. In order to invoke component services seamlessly, component metadata and interface semantics must be developed and published in a heterogeneous environment. Novelty of the methodology is that it leverages best-practice architecture of the service-oriented architecture (SOA) [71] to support IP-based multimedia services [72] on networking architectures, such as the IMS. It allows the various stakeholders taking part in service life cycle to have a uniform understanding of diverse service execution platforms [73].

38

Introduction

A number of components are exposed to the outside world through the virtual exposure layer. These components can then be used and combined in a multiplatform environment to create composite services. Enablers on this layer include the policy enforcement point (PEP) that grants access to the platform, the security gateway (SEG) that enables interplatform communication and controls until what extent the platform is opened up for a trusted third party platform, and the SLA service, that creates and enforces service level agreements. 1.2.3

Applications

It is argued that the extreme sophistication of ICTs and emerging technologies may create a future environment, where computing will be literally everywhere, so that we won’t even realize when we use it. Such an environment has been for some time now referred to as ambient intelligence (AmI). An application is an implementation of a related set of functions that perform useful/specific work, often enabling one or more services. It may consist of software and/or hardware elements. An application can be also a program or a group of programs (i.e., function implementation by software) designed to perform specific task(s). Applications can use other components in the system and provide some functionalities for users. Services can provide functionalities for other components. A persistent set of data, describing the properties, settings, and capabilities of an application/service is referred to as an application profile. Applications that are built by reusing logic from two or more existing applications to form a new application without having to start from scratch are referred to as composite applications. A composite application consists of a functionality drawn from several different sources within an SOA. The components may be individual Web services, selected functions from within other applications, or entire systems whose outputs have been packaged as Web services (often legacy systems). Figure 1.22 shows the role of the application profile in the overall context and profile information composition. Next generation user applications (including personal agents) must consider the increased user mobility of the user (i.e., roaming, disconnected situations, unavailability of resources, or central servers). This includes adapting the environment to the needs of the user and user preferences by searching for the resources demanded by the applications, and the discovery of any available services useful for the user. Several discovery protocols exist (e.g., Sun Microsystem’s Jini and JXTA, Salutation Consortium, Microsoft UPnP SSDP, Bluetooth SDP, and IETF Service Location Protocol WG SLP), but some research effort is needed to address heterogeneous networks with special emphasis on the proactive and ad hoc scenario, the limited nature of mobile devices, and the requirement for context-awareness [74]. When moving across networks, mobile devices do not currently obtain transparently and flexibly information about the context in which computing takes place, and thus cannot adapt to the current needs and preferences of the user and applications. The only way to currently accommodate the needs and possibilities of changing environments is to let the users manually control and configure the applications while on the move. This was also the main goal of the FP6 IST project UBISEC [75].

1.2 Service Platforms

39

User profile

Network AP ID Terminal profile

Network AP name Signal strength

Profile information Application/ service profile

Network profile

Network AP AddrType Network AP address

type

Authentication

name

Bearer type

password

Carrier frequency Frequency hopping

Tarrif class

Cell ID

Max bitrate

Bearer service

Guaranteed bitrate Transfer delay

Figure 1.22

Profile information composition [74].

UBISEC adopted a semiautomatic approach by providing context-awareness to the users and applications, going beyond simple device awareness and proposing a system, in which components of the applications, move towards the communication source through a smart deployment strategy in order to reduce battery consumption. Additionally, ubiquitous computing has some constraints in terms of connectivity and computational power that differ from the general security requirements in distributed systems. Ubiquitous computing brings into play a security service that is required to support the ubiquitous network. Whereas access to the Web is more or less secured through traditional methods, secured access to the global network is more complex. Multiple access rights must be created for every object, and the authorization service becomes essential. This is all the more critical with the massive adoption of RFID technology worldwide, which brings in challenges such as concerns over possible eavesdropping over the air interface or over the potential danger of privacy abuses as a result of the ubiquitous, silent, and invisible character of the technology [76]. Thus, access and management of private user profiles and data, in the domain of large-scale mobility when moving across heterogeneous networks, requires a dedicated security infrastructure with highly advanced access control and authorization. Authorization in nomadic computing is a state-of-the-art topic. Scalability problems of access control lists (ACLs) and public key infrastructure (PKIs) necessitate the development of new techniques. On the other hand, attribute certificates will play a major role in globally addressing the complex security issues of access control and authorization. They are a standardized mechanism for defining user access privileges in a multivendor and multiapplication environment. Privilege management infrastructures (PMIs) issuers of attribute certificates were introduced in

40

Introduction

last version of ITU X.509 recommendation. The PKIX Working Group of IETF is also actively contributing in this area. Still, delegation of privileges is insufficiently addressed and a neutral way for specification of privilege policies is needed. An open business model for value-added services and content providers requires a framework for handling security and the adaptation to new computation environments. Such a framework should offer an open interface for third parties with solutions for security, location, and service discovery and provisioning, while incorporating existing technologies to the new scenario [75]. Advanced personalization and localization technologies with high security are needed in order to keep privacy and to protect computing devices, software components, and personal user data, including user profiles. Automatic customization can be provided through situation-dependent (context-aware) secure management and access control evolving user, device, and application profiles. Automatic SmartCard-based access control and authentication can be preserved by advanced distributed network services, which guarantee personalized content delivery through efficient prefetching and caching based on emerging standards for microand macromobility. Flexible service announcement (directory services), discovery, provisioning, and delivery can support the mobile user while moving across heterogeneous networks [75]. 1.2.4

Summary

The achievements of the FP6 IST projects paved the current trend for towards service-aware services. Service awareness itself has many aspects, including the delivery of content and service logic, fulfillment of business, and other service characteristics such as QoS and SLA and the optimization of the network resources during the service delivery. Thus the design of networks, services, and applications is moving forward to include higher levels of automation, autonomy, including self-management [77]. Conversely, services themselves are becoming network-aware. Networking-awareness means that services are executed and managed within network execution environments and that both services and network resources can be managed uniformly in an integrated way.

1.3

Preview of This Book This book is organized as follows. In order to achieve converged communication architecture, coexistence and interoperability are essential. At present, the existing models and classical cellular network architectures are incapable of handling a number of possible scenarios that might require radio resource management strategies to support mobility or quality of service. Chapter 2 describes the research and development activities and resulting achievements of the European (EU)-funded projects under the Framework Program 6 (FP6) in the area of next generation system scenarios, architectures, roadmaps, and social-economics implications, solutions for IP support in networks such as cellular, broadcast, wireless local area networks (WLAN), and satellite networks, requirements of the IP-based convergence and integration of wired and wireless,

1.3 Preview of This Book

41

fixed, and mobile networks, evaluation strategies for the performance, functional, interlayer interaction, security, and management enhancement of IP networking technologies to enable seamless mobile networking over existing and emerging, wired, and wireless networks. Next generation systems impose new requirements and scenarios for the provision of quality of service (QoS), which in turn demand novel or modifications to existing solutions. QoS features in IPv6, namely Differentiated Services and Integrated Services provide means for application to reserve network resources using IP signaling between the application and the network layers. The issues around QoS provision have many aspects depending on the adopted scenario. Chapter 3 focuses on some of the solutions proposed for QoS delivery in the scope of the scenarios adopted by a number of FP6 IST projects within the areas of mobile and wireless beyond 3G [1] and broadband for all [2]. Next generation services at millimeter wave (Ka-band and above) have been slow to progress towards the market. Low earth orbit (LEO) systems have been hampered by excessive cost and complexity. Chapter 4 describes the achievements made by the projects funded within the frames of the EU Framework Program 6 (FP6) [1], [2] to assist the adoption of services delivered by satellite and to provide easy interoperable solutions that allow for fully exploiting the potential of satellite access technologies and networks for delivering low-cost broadband technology, for enhancing the performance of next generation terrestrial technologies, and for the delivery of emergency and similar services in the scope of a converged communications scenario. There is a proven correlation between broadband deployment and GDP; therefore, part of the European-funded research was aimed at enabling broadband access at speeds of 100 Mbps and above towards 1 Gbps, at the development of components and systems and their integration in an end-to-end converged communication infrastructure. Research spanned from the physical to the service and applications layer, in the whole range of technologies from optics, powerline, DSL, satellite, and wireless. Chapter 5 is primarily focused on the research and development achievements [1] in relation to fixed broadband access and services and the development of a new broadband component towards next generation communication networks. The success of next generation networks depends on appropriate service infrastructures supporting secure, personalized, and ubiquitous services. The rapid development of the Internet, both in speed and in capabilities, is an enabler of new and innovative market of services and provides a new experience to the users. The convergence of services is another trend observed in parallel with the trend of convergence of technologies and networks. The challenges of service delivery that providers and creators face, are how to enable the capability to offer a wide variety of IP services (mobile office, audio/video conferencing, push2talk, rich call, etc.), with the required quality for each of the delivered services. Chapter 6 describes the research and development activities and resulting achievements of the European (EU)-funded projects under the Framework Program 6 (FP6) in the area of services, service enablers, and service platforms. The activities spanned the definition, creation, and delivery of services, and the provision of environments supporting their execution. In particular, it focuses on the provision and evaluation of pervasive services and the required platform to enable services offering security, privacy, person-

42

Introduction

alization, context-awareness, and service management capabilities to mobile user services. Further, it focuses on aspects such as middleware and open service platforms, and the role of the IP multimedia system (IMS) for the provision of services in a future scenario. Next generation user applications (including personal agents) must consider the increased user mobility of the user (i.e., roaming, disconnected situations, unavailability of resources, or central servers). This includes adapting the environment to the needs of the user and user preferences by searching for the resources demanded by the applications, and the discovery of any available services useful for the user and brings advances in mobile applications and services within the reach of users in their everyday life by innovating and deploying new applications and services based on the evolving capabilities of the 3G systems and beyond. Chapter 7 addresses the user-centric problems related to different end-user devices, available communication networks, interaction modes, applications, and services. It gives a comprehensive representation of the market place dynamics, and the fundamental technological issues required for the creation of user-centered and manageable communication infrastructures for the future. Chapter 8 concludes the book.

References [1] [2] [3] [4]

[5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

ICT Program, FP7, “Working Program, 2008-2010,” available at www.cordis.eu/fp7. Third Generation Partnership Project, 3GPP at http://www.3gpp.org. FP7, NESSI, “A NESSI Position Paper: European Software Strategy,” at http://www.nessi-europe.eu. Hays T., “Achieving QoS in IP Networks,” in Quality of Service over Next Generation Data Networks, M., Atiquazzam, M., Hassan (Eds.), Proceedings of SPIE, August 2001, Vol. 4524, pp. 109–116. FP6 IST Project Ambient Networks (AN), “Ambient Networks Project, Description and Dissemination Plan,” July 2001, at www.ambient-networks.org. Report on The World Dialogue on Regulation for Network Economies (WDR), ITU 2003, www.itu.int. FP6 IST Project Ambient Networks (AN), at www.ambient-networks.org. FP6 IST Project EVEREST, at http://www.everest-ist.upc.es/. FP6 IST Project WINNER and WINNER II, at www.ist-winner.org. FP6 IST Project AROMA, at http://www.aroma-ist.upc.edu/. FP6 IST Project DAIDALOS and DAIDALOS II, at www.ist-daidalos.org. FP6 IST Project ENABLE at http://www.ist-enable.org/. FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. International Engineering Task Force, at http://www.ietf.org/. Open Mobile Alliance (OMA), at www.openmobilealliance.org/. FP6 IST Project NOBEL, at www.ist-nobel.org. FP6 IST Project LASAGNE, at www.ist-lasagne.org/. FP6 IST Project TRIUMPH, at http://www.ihq.uni-karlsruhe.de/research/projects/TRIUMPH/. FP6 IST Project VIVALDI, at http://newton.ee.auth.gr/vivaldi/. FP6 IST projects in Broadband for All, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm.

1.3 Preview of This Book [21] [22] [23] [24] [25] [26] [27] [28] [29]

[30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45]

[46] [47] [48]

43

FP6 IST project CODMUCA at https://www.ist-codmuca.org/. FP6 IST Project SATSIX at http://www.ist-satsix.org/. FP6 IST Project MIDAS at http://www.ist-midas.org. FP6 IST Project COMET, at https://www.comet-consortium.org/. Mihovska, A., et al., “A Novel Flexible Technology for Intelligent Base Station Architecture Support for 4G Systems,” in Proceedings of WPMC’02, October 2002, Honolulu, Hawaii. Mino, E., et al., “Scalable and Hybrid Radio Resource Management for Future Wireless Networks,” in Proceedings of IST Mobile Summit 07, July 2007, Budapest, Hungary. RP-020386, “Proposed Work Item by NOKIA: SRNS Relocation Enhancements,” RAN Plenary Meeting #16, June 2002, Marco Island, USA. OpenRAN Architecture in Third Generation Mobile Systems MTR-007, Mobile Wireless Internet Forum (mWIF) technical report, at www.mwif.org. 3GPP Specification TR36.401, “Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Architecture Description,” at http://www.3gpp.org/ftp/Specs/html-info/ 36401.htm. International Telecommunications Union, ITU, at www.itu.int. Recommendation ITU-R M.1645, “Framework and Overall Objectives of the Future Development of IMT 2000 and Systems Beyond IMT 2000,” at www.itu.int. FP6 IST project WINNER II, Deliverable 6.13.4, “WINNER System Concept Description,” November 2007, at www.ist-winner.org. Next Generation Mobile Network (NGMN) Alliance, “Next Generation Mobile Networks Beyond HSPA and EVDO: A White Paper,” December 2006, at www.ngmn.org. Beming, P., “LTE-SAE Architecture and Performance,” White Paper, Ericsson Review No. 3, 2007. European Telecommunications Standards Institute (ETSI), at www.etsi.org. 3GPP Technical Specification, TS 23.228, “IP Multimedia Subsystem,” at www.3gpp.org. FP6 IST Project VITAL, at www.ist-vital.eu/. FP6 Project DAIDALOS II, “Daidalos Transition and Interworking Based on 3GPP and TISPAN,” October 2008, at www.ist-daidalos.org. WiMAX Forum, at http://www.wimaxforum.org. FP6 IST project VITAL, White Paper “NGN networks; A New Enabling Technology or Just a Network Integration Solution?,” at www.ist-vital.eu/. Mihovska, A., “Cooperative Radio Resource Management for Next Generation Systems,” PhD Dissertation, December 2008, Aalborg, Denmark. Smart User-Centric Communication Environment, IST Project SCOUT, at http://www.ist-scout.org/. Advanced Radio Resource Management for Wireless Services, IST Project ARROWS, at http://www.arrows-ist.upc.es/. Capacity Utilization in Cellular Networks of Present and Future Generation, IST Project CAUTION, at www.telecom.ece.ntua.gr/CautionPlus/. ETSI TR 101 957: “Broadband Radio Access Networks (BRAN); HIPERLAN Type2; Requirements and Architectures for Interworking between HIPERLAN/2 and 3rd Generation Cellular Systems,” V1.1.1 (2001-08). 3GPP TR 22.934, V1.0.0 Feasibility Study on 3GPP System to Wireless Local Area Network (WLAN) Interworking Rel-6. Prasad, R. (ed.), Towards the Wireless Information Society, Volumes I and II, Norwood, MA: Artech House, 2005. Kyriazakos, S., A., Mihovska, and J. M., Pereira, “Adaptability Issues in Reconfigurable Environments,” IST Proceedings of ANWIRE Workshop on Reconfigurability, Mykonos, Greece, September 2003.

44

Introduction [49] Mihovska, A., et al., “QoS Management in Heterogeneous Environments,” Proceedings of ISWS’05, Aalborg, Denmark, September 2005. [50] 3GPP Release 99, www.3gpp.org/Releases/3GPP_R99-contents.doc. [51] UTRAN Radio Interface Protocol Architecture, Release 5, TS 25.301, V 5.2.0, www.3gpp.org, September 2002. [52] www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_26/Docs/PDF/SP-040900.pdf. [53] Meago, F., “Common Radio Resource Management (CRRM) ,” COST273, May 2002. [54] Luo, J., et al., “Investigation of Radio Resource Scheduling in WLANs Coupled with 3G Cellular Network,” in IEE Communications Magazine, June 2003, pp. 108–115. [55] FP6 IST project E2R, at FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/ mob-wireless.htm. [56] Hugo, D., Siebert, M., and M., Lott, “Handover Issues in Integration of Next Generation Mobile Systems and Wireless IP Networks,” in Proceedings of EURESCOM Summit 2002, October 2002, Heidelberg, Germany. [57] Mihovska, A., et al., “Requirements and Algorithms for Cooperation of Heterogeneous Networks,” in Springer International Journal On Wireless Personal Communications, DOI: 10.1007/s11277-008-9586-y, September 2008. [58] Sdralia, V., et al., “Cooperation of Radio Access Networks: The IST FP6 WINNER Project Approach,” in Proceedings of Wireless World Research Forum (WWRF), 11th meeting, Oslo, Norway, June 2004. [59] Lott, M., et al., “Cooperation Mechanisms for Efficient Resource Management Between 4G and Legacy RANs,” in Proceedings of Wireless World Research Forum (WWRF), 13th meeting, Seoul, Korea, March 2005. [60] Prasad, R., and A., Mihovska (eds.), Series: New Horizons in Mobile and Wireless Communications: Radio Interfaces, Artech House, Norwood, Ma: 2009. [61] FP6 IST Project WINNER II, Deliverable 6.13.1, “WINNER II Test Scenarios and Calibration Cases Issue 1,” June 2006, at ww.ist-winner.org. [62] FP6 IST Project SIMPLICITY, at http://www.ist-simplicity.org/. [63] FP6 IST Project SIMPLICITY, Deliverable 1001, “Project Presentation,” December 2005, at http://www.ist-simplicity.org/. [64] FP6 IST project MOBILIFE, at www.ist-mobilife.org. [65] FP6 IST Project SPICE, at www.ist-spice.org. [66] FP6 IST Projects MAGNET and MAGNET Beyond, at www.ist-magnet.org. [67] FP6 IST project MAGNET Beyond, Deliverable 1.2.1, “The Conceptual Structure of User Profiles,” September 2006, at www.ist-magnet.org. [68] 3GPP Technical Specification TS 22.240, “Service Requirement for the 3GPP Generic User Profile (GUP); Stage 1, (Release 6),” January 2005, at www.3gpp.org. [69] FP6 IST project SIMPLICITY, Deliverable 3301, “Design of the SIMPLICITY Device,” December 2005, at www.ist-simplicity.org. [70] FP6 IST Project SPICE, Deliverable 1.8, “Final Reference Architecture,” June 2008, at www.ist-spice.org. [71] Ferguson, D., F., and M., L., Stockton, “Service-Oriented Architecture: Programming Model and Product Architecture,” IBM Systems Journal, Vol. 44, No. 4, 2005. [72] Kampmann, M., et al., “Multimedia Delivery Framework for Ambient Networks,” in Proceedings of Wireless World Research Forum Meeting 15, Paris, France, 2006. [73] Bhushan, B., et al., “Development and Publication of Generic Middleware Components for the Next Generation Mobile Service Platform,” In Proceedings of IEEE SAINT 2007 Workshop on Next Generation Service Platforms for Future Mobile Systems (SPMS 2007), January 2007, Hiroshima, Japan. [74] FP6 Mobile Service Platforms Cluster, White Paper, “Context and Knowledge Management,” June 2008, at https://www.comet-consortium.org.

1.3 Preview of This Book

45

[75] FP6 IST Project UBISEC, at http://jerry.c-lab.de/ubisec/. [76] Lieshout, M., Van, et al., “RFID Technologies: Emerging Issues, Challenges and Policy Options,” JRC Scientific and Technical Report, European Commission, 2007. [77] FP7 ICT Research on the Future of Internet, Management and Services Group, “Position Paper: Management and Service-aware Networking Architectures (MANA) for Future Internets,” December 2008, at http://cordis.europa.eu/fp7/ict/.

CHAPTER 2

Network and Mobility Management On the background of a converging communication infrastructure, the requirements and approaches towards network and mobility management are changing. The existing models, including internetworking principles and classical cellular networks architectures are no longer capable of handling a vast majority of possible scenarios that might require radio resource management (RRM) strategies in support of mobility or quality of service (QoS). The FP6 IST projects active in the area have substantially contributed to devise open and concrete architectures for converged systems based on the IP protocols and founded on internetworking principles. To answer the demand of next generation communications, it was acknowledged [1] that an evolutionary system was necessary that progressively incorporates heterogeneous wireless access technologies and supports seamless IP-based mobile multiparty multimedia services for the transparent support of both mobile/wireless and fixed access environments. Coexistence and interoperability are the building blocks towards a converged communication infrastructure. This trend creates a number of open research and standardization issues making the necessity of scalable system design and testing an important key enabler towards the migration of existing wireless networks to the next generation ones. The FP6 projects contributed to this topic with achievements in the area of next generation system scenarios, architectures, roadmaps, and socio-economics implications, solutions for IP support in networks such as cellular, broadcast, wireless local area networks (WLAN), and satellite networks, requirements of the IP-based convergence and integration of wired and wireless, fixed, and mobile networks, evaluation strategies for the performance, functional, interlayer interaction, security, and management enhancement of IP networking technologies to enable seamless mobile networking over existing and emerging, wired, and wireless networks. Some of the FP6 IST projects contributing to this area were Ambient Networks [2], WINNER and WINNER II [3], EVEREST [4], AROMA [5], PHOENIX [6], ENABLE [7], CAPANINA [8], and some others [9]. This chapter is organized as follows. Section 2.1 describes the state of the art and main challenges for network and mobility management in the scope of next generation communications. Section 2.2 describes the advances in the area of mobility management and access selection achieved by the FP6 IST projects and related to management of heterogeneous access technologies both in single operator and multioperator scenarios. Section 2.3 describes the benefits of use of location information in support of hand-

47

48

Network and Mobility Management

over in next generation systems. An architecture for integrating location techniques into a mobility management architecture is also presented. Section 2.4 concludes the chapter.

2.1 Introduction Today there are many different heterogeneous wireless communication technologies that differ in their support of data rates, mobility, coverage, quality of service, and possible business models. In the future, additional technologies are expected with other characteristics supporting new challenging networking scenarios, but most likely not replacing the existing technologies. Coordinated use of different radio access technologies, so called multiradio access, can potentially yield significant gains for both providers and end users of wireless networks. Improvements are expected for example in total effective capacity, total coverage, radio resource usage efficiency, robustness, mobility support, service availability, flexibility in deployment alternatives, and cost. Technologies such as broadcast and multicast in broadband access networks increase spectrum efficiency and facilitate the information based broadband community. Since larger bandwidth always cost more, particularly in the access network, effective implementation of broadcast and multicast have a direct impact in providing every citizen with affordable broadband access. An active engaged population will use technology for peer-to-peer broadband communications, and it will presumably increase in the future. Broadcasting networks develop towards a higher degree of interactivity with satisfactory high capacity return channels, thus providing coverage everywhere as well as two-way communication means. A number of research challenges have been identified such as routing, QoS, security, and reliability. Solutions also need to be implemented in coherent system architectures provided with scalability and allowing for the implementation of yet-to-be developed solutions. 2.1.1

System Architectures for Support of Multiple Access

A specific issue when considering multiaccess systems is managing the radio resources, especially in a multioperator environment. This requires that an RRM framework should also span the higher layers of the systems, and preferably, should be foreseen by an entity residing outside of the radio access networks (RANs) [10, 11]. Cooperation is required at vertical level as well as horizontal (i.e., across architectures and providers) to allow for the internet service provider (ISP) to guarantee the promised quality in a multitechnology and multioperator environment. 2.1.2

Cooperation Architectures

Chapter 1 described a novel approach to cooperation in a multiple-access system scenario at RAN and above level and adopting the above principle. Figure 2.1 shows this architecture again, including entities in support of mobility across systems, such as the hybrid information system (HIS) for information exchange during system

2.1 Introduction

Figure 2.1

49

Cooperation framework for intrasystem interworking [3].

access and the home subscriber server (HSS) implementing a variety of policy-based functions. The SRRM module (see also Figure 1.24) implements two types of functionalities and interfaces, one for traffic monitoring and reporting of physical legacy nodes and the other devoted to the direct actuation of the intrasystem RRM algorithms in the RAN nodes. In other words, it translates the CoopRRM commands to the RAN level. A new RAN might implement an enhanced functionality of the SRRM entity, namely, monitoring and actuation functionalities and the internal RRM coordination functionality. This two-way communication is for transferring monitoring information, but also for executing global RRM techniques. In Figure 1.24, the arrow pointing to the SRRM of the legacy RAN shows the indirect interaction as a result from the shift (handover) of users from the IMT-A reference RAN to the legacy RAN. For example, when the CoopRRM decides for intersystem handover of one user to UMTS, after having checked its status, the user will request a radio resource control (RRC) session establishment, which is, in this case, the indirect interaction of the CoopRRM with the UMTS SRRM. The CoopRRM will also have interfaces with other CoopRRM of the same or different operators. There are two possibilities for the intersystem cooperation. For example, in the case of mobility management, the CoopRRM either can advise the SRRM entities only before the decision, or the CoopRRM decisions are binding for the SRRM entities. This means that intersystem cooperation may be realized also at lower layers of the RAN. Normally, the SRRM will implement the functionality to translate RRM messages between the CoopRRM and the UT. The B3G monitor set of the SRRMW will

50

Network and Mobility Management

include the legacy RANs cells, and the legacy RAN monitor set of the SRRML will include the cells for the B3G RAN. The monitoring functionality will initiate a request of actuation to the CoopRRM entity, when a trigger is activated by a measurement that shows that a threshold is surpassed. The cooperative RRM framework presented in this thesis adopts for intersystem interworking the CRRM model (i.e., a central entity is in charge of RRM decisions) and for intrasystem interworking, the JRRM model (i.e., a central and internal to the RAN entity manages the overall capacity of the basic physical nodes in situations of high loads and joint management of traffic streams between entities). Some strategies adopted by the Concurrent RRM [26] approach have also been considered for a totally distributed RRM execution. The main benefits of evolving the existing approaches are that optimal system performance can be achieved with limited changes and already existing functionalities. The location of the RRM functions can be divided between the link layer and the network layer, considering the information requirements and functions that are available at other layers. The division of the RRM architecture on each layer is based on the “target object” or “environment” that will need the RRM function. However, there are some cases, where the RRM entity is relevant in both layers (L2 and L3). In these cases, the function is divided across both layers with different aspects of the function resident in different places coinciding with different target objects or environment. For functions of that kind (that split between two layers) there must be close cooperation between layers to ensure efficient RRM control. Benefits of a centralized RRM are achieved at the expense of a higher computational complexity since a larger interchange of information among network agents increases the signaling. Delay in signaling is higher than in the distributed approach, but the reaction time is not as critical because of the vertical handover and because the legacy RAN functionalities are slower than the radio functionalities envisioned for IMT-Advanced candidate systems. References [14–16] proposed that the following entities are implemented to realize functionalities for mobility management, congestion, admission and load control, and for QoS management: •

•

•

•

•

•

Handover decision entity for making the final decision regarding the target RAT for the UT to handover. Triggers entity for collecting/comparing triggers and deciding whether a handover process has to be initiated. Measurements entity for collecting measurements from the current and/or other RATs/modes (periodically) and calculating extra values. RATs monitoring and filtering entity to keep track of the available RATs/modes as well as keeping a list on the available RATs/modes that each UT can access based on user preferences, network operator restrictions, and UT capabilities. User preferences entity for keeping track of the user context information such as cost, RAT preferences, QoS classes. A central admission control entity, which will be responsible for the final decision and located in the CoopRRM or RRM server.

2.1 Introduction

•

•

•

•

51

A local admission control entity (in each SRRM) cooperating with the measurement entity in each RAN, and checking the different network admission criteria, cooperating with the admission control entity in the CoopRRM (receiving/sending information) for selecting the ongoing sessions that will perform intersystem handover or will degrade their QoS in order to gain the needed resource for admitting the target session and for cooperating with other possible entities located in the SRRM (i.e., handover entity or QoS management entity). Entity responsible for maintaining the handover queue for maintaining a queue for the handover sessions that cannot be completed immediately and must remain in the queue until the needed resources become available. A network and session manager located at the CoopRRM for prioritizing the sessions according to their service class and for decisions for assigning them to a network that would maintain the QoS requirements of the users. The main function of this entity is to build up and maintain an active set of candidate RANs available based on the user request and the relevant user profile. A multi-RAN scheduler located at the GW and RRM server to forward the packets within the cooperative RAN cluster to one or a set of candidate RANs depending on the bearer/service attributes. Further, tight coupling is used to map the output of the scheduler in charge of link adaptation to the multi-RAN scheduler.

2.1.2.1

Hybrid Information System

In a homogeneous system the scanning of other possible connections is triggered by the condition of the link, since an ongoing connection with good performance makes such a procedure dispensable. For a vertical handover, presupposed by the options for multiple access, continuous surveillance is mandatory [12]. When no entity exists for the integration and information exchange of the different networks, this should be handled by the terminal itself, which would scan all other possible access systems. The autonomous gathering of information by means of scanning may impact both the own and other transmissions. Therefore, it makes sense to look for alternative ways of gaining respective measurement results. Because it is advisable to reduce the need for its own measurements as much as possible, another way of gathering the relevant information is to employ measurement reports, which have been collected by other active mobile terminals, within the same or within other systems. Information gathering within the same system thereby is required for horizontal handover preparation, whereas for vertical handover, information gathering between different types of systems is needed. However, information may also be used to control other mechanisms such as appropriate physical mode selection for link adaptation or joint RMM (JRRM, see Chapter 1). In all cases, a location-based intersystem handover in combination with the HIS (see Figure 2.1) offers a great economic potential since participating devices can minimize or even avoid self-driven scanning procedures. The principle of the HIS presumes that each system collects data about the current link state within the covered cell and provides this information on request to mobiles that are willing to change their connection within the same system or different systems.

52

Network and Mobility Management

Figure 2.2

HIS [17].

In a more complex scenario (e.g., legacy systems and the WINNER system [3]) all systems are equivalent partners, grouped around the HIS, which can reside in the core network. The flow of information is routed through this center, as shown in Figure 2.2. The operator can offer the user the best possible service since it can compare all available RANs. The function of the HIS then is to evaluate the incoming data and establish an internal representation, which can be used by other networks. The storing of information in the HIS leads to the problem of matching it to the respective information available from other systems. If the data is location-specific, (e.g., the interference level or the pathloss) the position must be appended to the stored values to compare it with the corresponding entries of other networks. Even if it is not location-specific, like the idle time in an 802.11 WLAN basic service set (BSS), the positioning is mandatory because the area of coverage must be known for handover procedures between the different networks. By storing the information of the monitored networks a map of the observed environment is drawn up. If a user in another network needs information about the situation in adjacent networks it can get the information by determining its own position and requesting the appropriate data. The interface of the (centralized) information system must be constructed flexibly because it gets data from a lot of completely different networks and it needs to be open for future RAN technologies [17]. To meet these requirements all entries consist of a common part with the type of system, the location, and a time stamp and a network specific part with information on the link and system status. The data can be processed in a short- or long-term manner depending on how relevant the values are. If the information changes rapidly and is not predictable in time, only current entries are usable. But for monitoring position-fixed data, a long term averaging can make a good prognosis of the up-to-date situation. One example therefore is the pathloss of a scenario where even the effects of fading can be cleaned out. As an additional advantage, the stored information is useful for further network management. Areas of bad coverage can be identified more precisely and demand prediction is easier. Hence, the interface must manage requests of terminals and replies with a report about the situation in the other systems. It can be distinguished between a terminal and a HIS triggered report. In the first case, data about all other systems must be

2.1 Introduction

53

transmitted, since the terminal decides about a handover and, therefore, needs all necessary information, in the case when a handover is initiated by the network, the HIS can decide, which information is necessary or useless as a form of preselection. Networks without any better performance do not contribute to the handover decision and can be neglected. Due to the fact that all networks need to be connected to the HIS one common core network is essential [17]. 2.1.2.2

Key Architectural Principles

The envisioned ambient network of the future will be based on a federation of multiple operators of various kinds and of various access technologies, at the same time requiring simple operation of existing and new services. This approach achieves affordability (the user has full freedom to select technology and service offering) and flexibility (minimizing investment needs for new networks). The optimization of various air interfaces, including the necessary adaptation of services, is required for the realization. The key enabling technology is reconfigurability within the network. A general trend observable in many modern network architectures is a horizontally layered structure adopting the principles proven successful in the design of telecommunication protocols [2, 3]. A layered structure ensures a decoupling of functional areas and allows the reuse of components as well as a shared usage. While a layered structure is generally acknowledged to be an appropriate design choice, the number of layers and their scope is an important decision to be made for a network reference model [18]. The consortium known as World Wireless Initiative (WWI) [19] has agreed on four distinct functional layers complemented by a vertical reconfiguration plane. In fact, these four elements were also main topics of research within the FP6 IST projects MOBILIFE [20], Ambient Networks [2], WINNER [3], and E2R [9]. The WWI model is restricted to a scenario, which assumes the presence of all functions of the above projects that are defining these four layers. The WWI vision is shown in Figure 2.3. The multiaccess is a key component in the architecture enabling the cooperation between heterogeneous access technologies. The global RRM entity is responsible for the RRM decisions, the RAN selection, the load balancing, and so forth. The common control layer provides a unified interface and an adaptation to the underlying RANs and support for intersystem handover. The context information is needed in a structured and organized manner by all the layers. Further, support of the storage and maintenance of context information, as well as its sharing between different system components and applications is required. The following main novel architectural components were proposed by [9] as part of the next generation system architectures [1]: • •

•

Methods for flexible spectrum access and reconfiguration management; RRM involving multiple radio access technologies and enabling continuous multiaccess; Flexible mobility solutions for seamless mobility across accesses with cross-layer optimizations;

54

Network and Mobility Management

Figure 2.3

•

•

•

•

•

•

•

WWI architecture model in support of intersystem mobility [2, 3].

Network context gathering, management and delivery of network state information to service platforms; Enabling new business models in future networks by offering embedded support for network composition as a business-oriented extension and generalization of roaming as we know it today in mobile networks; Development of a self-adaptive and service-aware media distribution architecture including the integration of broadcast and multicast in next generation multiaccess networks; Security domains that allow the establishment of end-to-end trust relationships mapped on networking mechanisms; A novel internetworking architecture addressing the deficiencies of today’s BGP-based solutions; Split of locator and identity and use of digital (virtual) identities in next generation networks; Building advanced B3G testing environments.

Further, [1] reported the vision that future mobile devices would enable their automated configuration for optimal operation and reconfiguration in a way that would be transparent to the user. In this framework, reconfiguration aspects that involve the contextual dynamic adaptation of operating network elements and proposes solutions on all levels of the communication system can be beneficial.

2.2

Mobility Management State-of-the-art mobility management solutions could handle only user terminal handovers between two wireless access points in an operator-controlled infrastruc-

2.2 Mobility Management

55

ture; these handovers were predominantly initiated by physical relocation [21]. In emerging network scenarios as introduced in this book, the term mobility has a wider sense and involves system responses to any changes in the user and network environments, including changes in radio and network resources as well as commercial conditions. Furthermore, mobility solutions need to support a larger variety of mobile entities. Mobile devices are capable of running demanding network applications, may have multiple network interfaces and, thus, many connectivity options. The state-of-the-art mobile protocol stacks can only handle a small set of event notifications, typically related to RAN connectivity, user mobility, and load balancing. For example, signal strength deterioration generally leads to a base station handover (HO) in cellular voice; 2G/3G mobile phones typically opt for 3G connectivity when the user moves into a new area; and, sustained high data traffic loads may force the Universal Terrestrial Radio Access (UTRA) transport function to reallocate resources (and even perform a handover) in the WCDMA 3G/UMTS networks. Accordingly, it is no longer possible to envisage a single mobility paradigm that can address this diverse set of requirements. Under the EU-funded research, the FP6 project Ambient Networks [2], introduced the concept of a set of solutions that can be flexibly combined and integrated on demand. 2.2.1

Triggers

In the context of next generation systems, event that require the execution of RRM mechanisms in support of user mobility may originate from various number of sources at different levels of the communication system. Normally, such events are signaled by the so-called alarms and triggers, in response to exceeding a predefined threshold for a key performance indicator (KPI). In the context of mobility, these are just symbolizing changes related to a current state of mobility. In the context of the cooperation architecture in Figure 2.1, such changes will be observed by the CoopRRM, SRRM, and even the BS (at RAN level). In the context of the reference architecture in Figure 2.3, changes will be observed by at the common control layer, normally by an entity referred to as access router in Figure 2.1, as well as by entities located at the service and application layers (see Figure 2.3). Because of the majority of possible triggers, [21] proposed a trigger management system, which is shown in Figure 2.4. The trigger management system comprises (a) event sources (i.e., trigger producers), which feed triggers with relatively fast-changing information; (b) trigger consumers, which receive notifications in the form of standardized triggers about events they are interested in; and (c) triggers with associated data stores and internal logic. The trigger management system processes the events received from the producers, generating triggers based on consumer-provided (filtering) rules, and making sure that all network policies are enforced. Given the stringent time constraints that such processes place, triggers must be delivered expeditiously, using standardized application program interfaces (APIs) based on well-defined and versatile, yet compact data structures suitable for handover management. All triggers coming out of the trigger management system are in a single standard format. Such a system can be placed as a building block of an information service infrastructure [21].

56

Network and Mobility Management

Figure 2.4

High-level architecture of a trigger management system [21].

Any entity of the infrastructure interested in receiving a specific kind of trigger has to subscribe with the trigger management system as a consumer through a TRG/consumer interface. This implies that a protocol to be used in the communication between the consumer and the trigger management system needs to be defined to allow the former to specify its filtering rules; this protocol has to include, at least, a set of primitives (structures) to deliver the requirements that the consumer may have. This set of requirements may be taken into consideration when the trigger management system emits a relevant trigger. The primitives used by the consumer cover, for example, the following: • • •

The notification of a threshold of an indicator (e.g., a signal becomes too low); The notification of reaching a certain state (e.g. a client is connected); The notification of “logical event” (e.g., a “beep”).

An important consumer of mobility triggers can be, for example, a handover and locator management (HOLM) entity managing an IP layer connectivity and locator changes during handover events. Such an entity would contain protocols and mechanisms for handling mobility management. For example, in the FP6 IST project Ambient Networks, such an entity addressed mobility support within and between network domains and maintained IP connectivity, while the access specific mechanisms such as network discovery, access selection, and so forth were handled by a multi-RRM entity [21]. Therefore, the HOLM entity needs to be involved for the following types of handovers: •

•

Locator change: If the locator changes for the mobile endpoint, the entity would ensure that this change is propagated to directories (e.g., Domain Name Server (DNS)) and the correspondent nodes where needed. Change of forwarding path: In some situations this is achieved when propagating the change of the locator. There are other mobility schemes, as well, where the forward path changes while the locator of the mobile endpoint can remain the same (e.g., mobile IP [23] and localized mobility schemes such as [24, 25].

2.2 Mobility Management

57

For handover execution the HOLM entity interacts with the MRRM entity, which handles all radio protocols and mechanisms, (e.g., the setup and release of the radio connectivity. The proposal for the structure of the HOLM entity and all containing modules are shown in Figure 2.5. The interfaces and the external modules (e.g., MRRM, policy server) are not shown. The HOLM entity is constituted by a coordinating module called handover tool selection and execution control (HOSEC) and protocols/mechanisms for mobility management [21]. The entity integrates a set of protocols (e.g., MIPv6), and an interface towards the HOSEC module. Those protocols are shown with dotted lines in Figure 2.5. It might be that additional protocols/protocol extensions (e.g., based on the MIPv6 and HIP protocol) are also needed, in order to satisfy a larger number of scenarios. The HOLM entity is not a monolithic set of protocols or modules, which is available at every node with all proposed functionality, but instead the appropriate modules are used based on the specific node requirements [21]. For example, a user terminal may require a different set of modules/protocols compared to a core network node. The novelty of the proposed HOLM entity is that it allows for a number of different protocols to coexist in parallel [21]. It is essential to decide, which of those is (are) the most suitable one(s) to control and execute a handover. Further, coordination between the different tools might be necessary to avoid any inconsistency (e.g., the MIP daemon may ignore a router advertisement message because the handover is done by the SCTP protocol). Such issues would be handled by the HOSEC module.

Figure 2.5

Structure of a handover and locator entity [21].

58

Network and Mobility Management

2.2.2 2.2.2.1

Framework for Hybrid Handover Mobile IP

The mobility support in IP networks (e.g., MIP) is an official proposed standard, which has been designed by the Internet Engineering Task Force (IETF) to support host mobility. It was developed for both IPv4 and IPv6. MIP enables mobile nodes to be connected to the Internet during their movement across network domains and regardless to any (geographical or administrative) changes to their location. This is accomplished by using routing tables in the appropriate places within the IP network. Therefore, one could refer to MIP as a specialized routing protocol. MIP was designed to provide macromobility for mobile nodes. A macro handoff occurs whenever there is a need to register a new care-of address (CoA) to the home agent (HA). Similarly, the term micromobility is referred when the mobile node (MN) moves within a subnet or an administrate domain. Registration requests are either unnecessary or terminated inside the administrative domain to update the location of the MN locally. The main source of the need of frequent handovers in MIP is the latency and packet loss that is induced by lengthy registration processes: Registration messages must traverse all the way to the HA and back. Besides, the MIP network layer movement detection mechanism is slow. This delays the initiation of the registration process even more. With real-time requirements of current mobile applications, the MIP network layer handoff procedure is insufficient. MIP can be considered as a sublayer that provides additional services between the network and transport layers. It introduces two-tier addressing as the solution to the conflicting dual semantic and use of IP addresses. Two-tier addressing associates a mobile node with two distinct addresses, a permanent home address, and a temporary CoA. There is an address translation mechanism that makes sure that the connections of the mobile node are not disrupted due to the mobility and thus it offers IP transparency to upper layers and ensures backward compatibility with transport protocols. This gives a solution to the problem of mobility in IP networks without changing the mobile nodes’ IP address. Operating at the network layer, MIP does not care about the media type that runs over it. It allows a mobile device to move between different media types while retaining its connectivity. This ability is called heterogeneous mobility. In the home network there is a link that provides the mobile node the home address. This home address serves as a location invariant node identifier and is configured with the home prefix. The same happens with the home network; in the foreign network (visited network) there is another link that provides the mobile node the CoA. This CoA serves as a location identifier (a routing directive), which reflects the current point of attachment to the Internet. The CoA is configured with the foreign prefix. Between the home address and the CoA, there is a relationship that shows that the two IP addresses refer to the same mobile node. This relationship is a binding and it is stored within the HA. The HA is a special router able to intercept packets intended to the MN. A correspondent node (CN) willing to communicate with a mobile node first calls the DNS, which returns the home address of the mobile node. Packets are then routed to the home link where they are intercepted and encapsulated by the HA to the CoA. Mobile IPv6 has enormous IP address spaces and does not have the IPv4 limitations. In MIPv4 a foreign agent (FA) eliminates the need to assign a unique collo-

2.2 Mobility Management

59

cated CoA to each MN, thus saving a lot of addresses. There is no more need for the FA service and the FA CoA type. A MN can have more than one CoA (e.g., to support smooth handover), though only the primary CoA will be advertised to the HA. The router on the foreign link, which serves the visiting MN is the access router (AR, see Figure 2.6). To obtain a collocated CoA for a MN, the following two methods exist: 1. Stateful address autoconfiguration includes a server, which selects an address from its database for the MN. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is an example of such a stateful address assignment. 2. Stateless address autoconfiguration ,in which the address is formed automatically from an interface identifier (e.g., the MN’s link layer address) and a valid foreign subnet prefix, both derived from the foreign link, to which the MN is connected. MIP can provide a solution for handover between different types of accesses but specific extensions to MIP are needed for the support of network mobility [28]) and localized mobility management [25, 26]. The hierarchical MIPv6 extends the MIPv6 and separates local area mobility from wide area mobility. The main benefit of this proposal is to render local area mobility transparent to CNs and to limit the MIPv6 signaling in the backbone. This protocol introduces a new entity, the mobility anchor point (MAP), which is an enhanced HA. A MAP is servicing a domain and receives all packets intended for mobile nodes located in its area of administration. The IETF specification [26] proposes two modes of operation, the basic mode and the extended mode. A MN that performs basic mode has two CoAs. The regional CoA (RCoA) is received from the MAP (i.e., the RCoA is a forwarding address on the MAP’s subnet; and not a topo-

Mobile node

Link B

Home link Link A

Access router Internet

Link C

Router Router Home agent

Correspondent node Figure 2.6

MIPv6 architecture and entities.

60

Network and Mobility Management

logically correct address for the MN), and is kept as long as the MN remains located in the same administrative domain. The MN also gets a local CoA (LCoA) on each visited link. The MN establishes the binding between the current RCoA and the LCoA with the MAP, which acts as a kind of local HA. The MN also registers the binding between its home address and the RCoA with its HA and CNs. All packets intended to the MN are therefore sent to the RCoA using a routing extension header. Packets get to the MAP subnet for encapsulation by the MAP to the current LCoA. Local area mobility within the site is transparent to the HA and CNs. It is only perceived by the MAP, which keeps and up-to-date entry between the RCoA and the current LCoA. As in MIPv6, binding updates must be sent periodically to the HA to refresh the binding between its home address and its RCoA. The functions that support the mobility of the mobile node are the following: •

•

Agent Discovery: The availability of the mobility agents on each link is broadcasted to where these can provide service. These messages are called agent advertisements. Agent advertisements are ICMP router advertisements with a mobility agent advertisement extension. The extension defines the type of the mobility agent (home or foreign agent), several capabilities of the mobility agent, and available CoAs (in case of FA). Two optional extensions are defined: A prefix-lengths extension for network prefixes of the router addresses listed in the ICMP router advertisement portion of the agent advertisement and a one-byte padding extension to make the length of the ICMP message an even number of bytes, required by some IP protocol implementations. Other extensions may be defined in the future. When the mobile node receives an agent advertisement from its HA, it should register and start to act as a stationary Internet host. No authentication is required for the agent advertisement and agent solicitation messages. A MN can also advertise its arrival to a new link with an agent solicitation message to which available mobility agents would reply. Registration: When the MN is visiting foreign links, it registers its CoA with its HA, so that the HA knows where to forward packets destined to the MN. Depending on the network configuration, the registration can occur directly with the HA or indirectly via the FA. The mobile node exchanges registration messages with the home agent, and optionally with foreign agents, to form mobility bindings (i.e., to register its CoAs). If the registration is done via a foreign agent, it processes and relays the registration request to the home agent. Similarly, when the foreign agent receives an authenticated Registration Reply, it forwards the reply to the mobile node after updating it’s visitor list. To renew the mobility binding, the mobile node repeats the registration process. Each mobile node and home agent maintains a mobility security association for authentication of the registration messages. They are indexed by security parameter indexes (SPIs) and the home addresses of the MNs. Messages between the MN and the HA are authenticated with a mobile home authentication extension. Optionally, security associations may also exist between the MN and the FA, or between the FA and the HA. MIP does not provide any data encryption, only authentication for the control messages. To

2.2 Mobility Management

•

•

61

achieve privacy for user traffic IP security (IPsec) can be employed on top of MIP. Encapsulation: An IP datagram is enclosed within another IP header, thus forming a new IP packet. The IP destination address of the wrapping header is set to CoA of the MN. The original IP datagram remains untouched throughout the enclosing process. Decapsulation: The outermost IP header is removed from the incoming packet and the enclosed datagram is delivered to the proper destination. Decapsulation is the reverse process of encapsulation.

HIP may be seen as alternative approach to MIP even though the support for mobility in HIP has been specified recently [27] and there are still several problems in HIP, which are not yet solved sufficiently. 2.2.2.2

Radio and IP Handover

In the following, the above mobility protocols are applied in the context of microand macromobility (i.e., radio and IP handover, respectively). All the traffic inside the next generation RAN is meant to be IP-based, without transcoding delays with other protocols (e.g., ATM to IP in UMTS), and with a reduced number of nodes to decrease inter-node user plane (UP) signaling [3, 29]. The communication between consecutive protocol layers and sublayers for is carried out through serving access points (SAPs). The SAPs allow for service offering from lower layers to the upper layers [30]. The respective protocol architecture is subdivided in user plane (UP), composed of protocols devoted to data transfer services of the user and control plane (CP) composed of the protocols created to control data transfer, user and network operation. This is in line with the separation of the functionalities as proposed by 3GPP and ITU [31, 32]. The protocol architecture shown in Figure 2.7 was adopted for the next generation radio system concept as developed by the FP6 IST project WINNER. In the UP, layer 2 is split into three (sub) layers: IP convergence layer (IPCL), the radio link control (RLC), and the medium access control (MAC). The function split is valid both for the downlink and uplink. The IPCL protocol exists only for the UP and it ends at the gateway (GW), while the radio link specific protocols terminate at the network side of the base station (BS). The IPCL layer functions are classified in two groups: the ones related to the transfer of UP data between two IPCL layers in different nodes (e.g. in the terminal and the gateway) and the IPCL functions for handover [30]. In the case of transfer of user data, the IPCL layer adapts the higher-layers data flows (e.g., IP packets) to the transmission modes of the RLC layer, establishing the transfer data protocol with a peer IPCL entity, compressing the long IP headers and ciphering the IP payload. In the CP, there is a nonaccess stratum (NAS) protocol over the radio access protocols. The NAS control protocol is important in reference to a number of functions related to radio access (e.g., paging). Radio resource control (RRC) protocols and services are terminated at the network side at the BS and the NAS protocols end

62

Network and Mobility Management UT

BS

IPCL

GW

UT

IPCL

BS

NAS

NAS

RRC

RRC

RLC

RLC

RLC

RLC

MAC

MAC

MAC

MAC

PHY

PHY

PHY

PHY

Figure 2.7

GW

Protocol architecture for a next generation RAN with split into UP and CP [3].

at the GW but continue in the core network (i.e., HSS) as security and ciphering protocols. The architecture of Figure 2.7 is suitable for a network-controlled policy mechanism for support of RRM. This is partially shown in Figure 2.1. The control functions related to the policies are scaled into different levels, namely the core network, the GW, the BS, the RN and the UT. The core network determines the policy for the UT based on its service level agreement (SLA) with its operator. The GW comprises the UP and CP functionalities. The GW provides the IP point of attachment for the UT, and comprises functions related to IP-flow-based policy enforcement. Mobility in the RAN with architecture shown in Figure 2.7 is supported by traffic and control signaling from the UT to the BS that the UT is connected to, and also by the BS-to-BS control signaling. To ensure flexibility of the architecture, logical functionalities of the physical entities can be grouped according to the situation. This is detailed in [33] and provides a good advantage to operation of the system in multioperator environment and reduction of the need for IP handover. For example, in a cellular deployment, fast handover without service interruption is needed. For this purpose, the GW functionality is introduced and a layer 2 tunneling protocol provides fast handover. A RAN specific physical node is needed in this case [34]. To enable efficient signaling and management between the network and the UT, all profiles are captured in the home operator domain for all the registered UTs. The RAN is responsible for enforcement of the policy determined by the core network. The policy management is distributed between the HSS and the GW. The RRM functions are based on the policy defined or previously agreed between the end subscriber and the RAN operator and applied to execute the following actions: • • • • • •

Radio access technology association; Flow establishment and QoS class setting; Handover priority setting; Context transfer in the UP; Location determination; Deployment priority.

Based on a logical architecture design [33] allowing for flexibility by implementing a larger number of functionalities into a decreased number of physical entities, which allows for a logical association between the UT and GW, which is independ-

2.2 Mobility Management

63

ent of the BSs, and, hence, the set of GWs can be seen as a pool of resources. This is shown in Figure 2.8. Radio handover then would take place when the UT, changing its attached radio access point, which could be a relay node (RN) in the case of a multihop system or a BS, maintains the same IP address after the completion of the handover. This seamless handover is based only on a switching process in the BS/GW. Because the UT has the same IP address after the handover process, the application does not see any changes and the data flow is not interrupted. Only the routing of the packets to the destination BS/RN is changed. This is the most common and simple type of handover, performed in the legacy networks such as GSM/GPRS and UMTS and even WLAN, when the source and the target access points belong to the same network domain. IP handover takes place when the UT changes its IP address after the completion of the handover process. This normally happens when the UT changes the GW it is attached to: in this case, it enters a different IP domain and it changes its IP address. To implement IP handover (without interrupting or dropping data flows), it is necessary to utilize protocols as MIP. Hybrid handover is a process where both radio and IP handover are performed, for example, for GW load balancing. In reality, the IP handover cannot be separated from the layer 2 handover. On one hand, an IP handover is triggered by a layer 2 trigger, on the other hand, there is frequently at the same time a layer 2 link down with an old BS and a new linkup with a new BS. Therefore, most IP handovers require an implicit radio handover. The concept of grouping a number of GWs into pools decouples the physical relation between a GW and a number of BSs associated to it. Instead, each GW may be associated to each BS in the pool area. Such an association avoids handover between GWs in the given pool area, which is defined as an area in which the UT roams without the need to change the GW. The GW capacity of a pool area can be scaled simply by adding more GWs. To preserve the scalability of the GWs, a shift in the user context is necessary from the highly loaded GWs to the less loaded GWs. This is shown in Figure 2.9.

Figure 2.8

Logical association of a GW entity as a pool of resources [33].

64

Network and Mobility Management

HO

UP data

moving

Figure 2.9

CP dataHO signaling

Integrated radio and IP handover into a next generation RAN [35].

The traditional approach is a hierarchical structure where each GW is associated with a set of BSs serving their own location area and providing a direct mapping between a GW and the area covered by associated BS. By choosing to have the set of GWs as a pool of resources, the requirements for macro mobility can be reduced because the GW is an anchor point for external routing. Finally, the single point of failures is avoided, which means, that should a GW malfunction, the users can be handed over to any other GWs, and at the same time load balancing can easily be achieved. If a mixture of GW pools and BSs is added, the handover between the BSs would require radio handover if the involved BSs are under the control of a single pool of the GW. The concept of multiple associations (see Figure 2.8) allows for broad- and unicast traffic to be transmitted in a single frequency network by multiple BS logical associations in the same frequency band so that the logical associations of the UTs are able to use the multiple signals. In this case the broad- and/or unicast traffic is transmitted from the logical association of the GW to the serving BS (which is the one that also handles unicast traffic) [33]. The logical architecture approach also supports simultaneous transmissions from multiple BSs to one UT as support for overlay networks. As an example, it enables that low data rate but delay and jitter sensitive flows (e.g., VoIP) are transmitted by an overlay wide area cell to avoid frequent handover situations, while the delay and jitter insensitive high data rate flows are transmitted by a local area cell. The traffic is distributed by the GW logical node to the BS logical nodes. It also provides gains in load and admission control [33]. Such an approach allows for the two types of handover to be incorporated into a hybrid handover framework [36]. It allows for a combined centralized and distrib-

2.2 Mobility Management

65

uted approach to mobility management depending on the scenario. The associations related to the execution of the hybrid handover are shown in Figure 2.10. An optional entity (i.e., the RRM server) would communicate with the BSs that it controls to get the real time measurement reports (RTTMs). The current BS would communicate also with its neighboring BSs to obtain their RTTMs. It would also communicate with the RRM server and would forward handover triggers required to execute the RRM algorithms. A candidate set of target BSs would be proposed to the current BS. The current BS is the entity that decides about the handover, the RRM server provides an assistance. As another option, the current BS would delegate full authority to the RRM server to execute the handover. This is usually required in situations of medium to high network loads. The trigger for the handover can come from the UT, the current BS, the HIS, or the RRM server. 2.2.2.3

Intersystem Handover

An intersystem handover would take place when a UT connected to a next generation RAN of the type described in Section 2.2.2.2 is performing a handover to a legacy type of network (e.g., UMTS, WLAN). It is assumed that a UT camped in the new RAN could handover to a legacy RAN when it loses the coverage, because of system congestion, or due to possible user preferences (especially in terms of cost) [35]. The two different systems belong to different domains. These domains are IP domains, so when a user moves from a BS serving the new RAN to a legacy BS, it would have to change its associated IP address. This means that this type of handover is an IP handover and MIP can be used for the execution of the handover pro-

Triggering HOconsulting BS1 for targetBS

UP data CP dataHO signaling

HO decision

moving

Figure 2.10

Associations during hybrid handover [35].

66

Network and Mobility Management

cess in order to provide a seamless handover without reinitiating the user’s session. Figure 2.11 shows the associations during this type of IP handover and the involvement of entities, such as the MRRM (see Section 2.2.1). In this case the decision is taken by the CoopRRM/MRRM entity and the handover is performed according to a centralized approach. 2.2.3

Architecture for Multiple Access

The concepts described above are related to the mobility management at RAN level. These concepts were integrated with multiple access solutions at the level of MRRM and above towards the vision for the deployment of ambient networks. The integrated framework for multiple access is shown in Figure 2.12. The MRRM is the key control entity in the multiaccess. It monitors the available access flows and access resources for a user terminal and allocates one or more of these to a bearer or an end-to-end flow. The MRRM performs an access selection decision (typically leading to a handover execution) based on different input parameters, for example, the performance and quality of access flows, the resource costs, and current resource availability, the operator and user policies, and the service requirements and user terminal behavior, and the extent to which these can be handled efficiently by different access flows. The MRRM functionality will be distributed among multiple MRRM entities that may take on different roles in their joint operation [37]. The generic link layer-interface and context transfer (GLL-ICT) entity provides a generic interface and support functionality for the transmission of user and control data over an access link. It embeds access specific transmission methods and protocols; hence, there are different entities for different types of accesses.

after HO

HO decision

Pool of GWs #2

UP data

moving

Figure 2.11

Associations during intersystem handover [35].

CP dataHO signaling

2.2 Mobility Management

Figure 2.12

67

Integrated framework for multiple access [37].

The GLL-ICT monitors the performance of the access link and the QoS that is perceived by an access flow. It also observes the resource costs and availability (including load or residual capacity) of the access links. Based on certain rules and thresholds (event filtering and classifications), the GLL-ICT reports link events (triggers) to the MRRM, (e.g., when the performance of the access link changes, when a new access link is detected or lost, when a QoS requirement of a flow cannot be met any more, and, when the resource costs for an access link passes a threshold or resources become scarce). The GLL-ICT receives configuration information from the MRRM. It can also receive measurement queries to report on access link and resource status. In the case that a flow is handed over between different GLL-ICT entities, the GLL-ICT can support context transfer and provide the corresponding link specific context. The GLL-ICT is also involved in detection of new accesses. The forwarding point (FP) is a routing decision point that maps higher level flows to access flows, (i.e., point of handover execution). The FP is an anchor for the access flows. Each FP entity needs to store the active mapping of access flows for higher-level flows. There can be multiple FPs, which are then typically structured in a hierarchical manner. This forwarding state in the FP is controlled via the HOLM entity [21]. In addition the FP may be combined with a GLL context anchor (GLL-CA) functionality to support another form of link layer context transfers. The context anchor keeps copies of the data packets until the GLL-ICT/GLL-UP entities signal that the packets have been successfully transmitted over the access links. The GLL-CA may also exercise flow control to minimize queued data at the access link endpoints.

68

Network and Mobility Management

Similar to the logical split envisioned for the GW entity at the RAN level, the MRRM functionality can be distributed among multiple MRRM entities that may take on different roles in their joint operation [37]. It must be noted that this is a split into multiple physical entities located in different nodes. MRRM entities with different functionality can also be defined, as shown in Figure 2.13. Typically there is always a master MRRM entity, which coordinates the roles of different entities. Figure 2.13 includes the following MRRM entities: •

•

•

MRRM-ANF: MRRM access network control function, which monitors access network related parameters; MRRM-CMF: MRRM connection management function, which monitors the access flow quality for the user terminal AN; MRRM-ASF: MRRM access selection function, which is the master MRRM entity responsible for deciding on the best-suited access for a bearer.

Such an approach is useful, especially in the case when the multiaccess anchor and the MRRM access selection function are high up in the network hierarchy, and there is a need to manage a very large number of users and radio cells. For scalability

Figure 2.13

Distributed MRRM with different types of MRRM functions [37].

2.2 Mobility Management

69

reasons, it is then advantageous if the MRRM ASF function receives only limited information. For example, the MRRM ASF does not need to know the exact link quality for every access link of all networks, but would only be informed by the MRRM CMF if a link quality becomes critical or a new link is discovered. The distribution of roles is negotiated between the different MRRM entities. The best distribution of functionality can be adapted to the network state of operation and also changes in policies. The MRRM-ASF can thus also be located in the user network. As an example, in unloaded networks the MRRM functionality can be largely distributed with largely autonomous access selection of MRRM entities, whereas in high-load situations a more centralized coordination of access selection for multiple user ANs is performed. 2.2.3.1

Access Resources

An access resource (AR) is a resource on which an access link can be established [37]. In wireless networks, an access resource corresponds to the radio resources of a radio cell, which are allocated to active radio links. The allocation of resources based on the proposed in the FP6 IST project Ambient Networks [2] architecture for multiple access (see Figure 2.12) is explained for a scenario involving three types of ambient networks (ANs): 1. An access ambient network (A-AN) that provides connectivity for a user ambient network (U-AN); 2. U-AN, which can be, for example, a single AN terminal or AN personal area network (PAN); 3. Peer AN (P-AN) communicating with a U-AN. An access link is the connectivity provided by an access resource to an access flow (AF). The AF can span further than the access link, (e.g., up to an anchor node in the network). In order to establish an access link, it is required that the identifier for that flow is registered at the access resource so that (parts of) the access resources can be allocated to the flow. Such an identifier can be a temporary identifier out of a pool of identifiers of the access resource, or it can be a permanent identifier of an access interface (e.g., a permanent MAC address). The establishment of an access link is denoted as link attachment, it happens during the network attachment. For example, this would happen when the U-AN wants to communicate with the A-AN and establish a GLL signaling connection (i.e., network attachment completed). The network attachment process comprises an authentication, authorizing, and accounting (AAA) process, which authorizes the establishment of an access link; it can also comprise a reservation of a portion of the access resources to the access link. An access resource belongs to the resource owner. As part of the network attachment, an agreement between the resource owner and the resource user is established, which permits the usage of access resources for the access link. Resources are required for the setup and maintenance of an access link. During the link attachment process some signaling over the access link is required, as well as in the backhaul link (e.g., AAA procedures). In case that resource reservation is

70

Network and Mobility Management

part of the link attachment, some resources are prohibited for usage by other access links and/or can block new links from being established. Also local resources are required for maintaining a link state (e.g., security keys). When the access link is established even a passive user has to closely observe traffic on the access resource to determine if it is part of the own access link—thus processing and battery resources are also used when idle. Further, the maintenance of an access link can also require signaling, (e.g., for maintaining sufficient link quality). In summary, an access resource is the enabler for providing an access link; however, prior to establishing the link by the link attachment, it is not guaranteed that the resources can actually be accessed by a user. On the other hand, establishing an access link (and thus an access flow) uses up some of the system resources, as well as local resources such as processing, memory, and battery. Therefore, a reflected decision is required before establishing an access link. 2.2.3.2

Access Flows

In [38] the flow abstraction is defined to allow for hierarchical flows (level-1, level-2, …) and flows that are connected with each other via flow transit (FT) points. A critical aspect of the definition is that flows are defined by their end-point locators (e.g., an IP address), so in the (typical) case of a bearer traversing a locator domain, at least two flows are necessary to transport the bearer (one in each direction). The scope of the MRRM operation is clearly limited to those parts of a flow that concern access links and cannot control the parts that are outside of the access domain, which can be defined as a set of networks that jointly provide access. An entity, such as the MRRM will typically only monitor and control a subset of the end-to-end structure of flows used to transport the bearers. There may, for example, be a single level-1 flow end-to-end with MRRM controlling a subset defined by a level-2 flow, or there may be a sequence of flows end-to-end connected via a number of FTs with MRRM controlling one (or more) of them. From an MRRM perspective it is only important to identify the access flows. The following two terms can be defined [37]: 1. Regardless of the configuration, the flow part that is controlled by the MRRM is called an access flow (AF); 2. The rest of the flow structure are called end-to-end flows (EFs). Figure 2.14 shows an example with access resources, access flows, and end-to-end flows. The AF is the connectivity that allows communication between the ACS FEs in the U-AN and the ACS FEs in the A-AN, as well as between the U-AN and other peers beyond the A-AN (P-AN). An AF is determined by the AF locators (e.g., a GTP tunnel endpoint identifier (TEID)) and by optional AF discriminators. An AF requires that some flow-related state is established in the U-AN and A-AN. At least one access flow is required for an U-AN to be reached from the outside. An AF is a flow in the domain managed by a set of cooperating MRRM entities. There can be multiple parallel AFs, which can be based on different communication technologies and can thus be defined by different types of locators.

2.2 Mobility Management

71

Level 1 Flow abstraction end-to-end flow

End-to-end flow (EF) Access flows (AFs) Active access flow (AAF)

Level 2 Flow abstraction access flow Access resources (ARs)

A-AN

Controller

P-AN Application server

U-AN

Router visible in the ACS

FE: End-to-end flow AF: Access flow

Figure 2.14

Internet

Connectivity

AAF: Active access flow FEP: Flow end point FT: Flow transit FP: Forwarding point U-AN: User-AN AR: Access resources

Router not visible in the ACS

A-AN: Access-AN P-AN: Peer-AN

Connectivity abstractions [37].

An AF does not require that data transfer is currently ongoing. It is rather the prerequisite for data to be transmitted. An example of establishing an AF is when a local locator (e.g., address) is received and registered (bound) in a forwarding point (e.g., HA, MAP). Another example is the MIP registration of a CoA in a HA / MAP. The AF establishment involves both the MRRM and HOLM operation. The EF is the data transfer of an active data session (i.e., AN bearer) going through the access domain. The requirements (e.g., QoS) desired for the session are associated to it. The task of an entity, such as the MRRM is to provide the best AFs to transport the end-to-end flow. The EF flow is the flow entering the domain managed by the MRRM and, on which the MRRM operates, (i.e., it provides the best connectivity for it). The end-to-end flow term is only used here for simplicity to denote the nonaccess parts of the end-to-end structure of flows (where other AN functions are mainly in control). 2.2.3.3

QoS Models and Access Flows

Application-level QoS requirements are carried by the bearers. In the abstraction of Figure 2.14, the ACS selects EFs to transport the required bearers for meeting the QoS requirements. The multiaccess resource management functionalities operate in turn on the AFs, which are always subsets (or parts) of EFs. For efficient multiaccess operation some application related QoS requirements are especially important, in particular, those that relate directly to the access (link) performance. 2.2.3.3.1 Transmission Errors, Error Control, and Application Requirements

In general, a data stream can be corrupted when being transmitted. In wireless transmission channels it is common that transmission errors occur [37]. Link layer

72

Network and Mobility Management

technologies can apply a number of methods to reduce the amount of transmission errors that are introduced: (1) error detection (e.g., using cyclic redundancy check (CRC) or checksum); (2) forward error correction (FEC) to encode a datagram that corrects a certain amount of bit errors during decoding; (3) backward error correction, or automatic repeat request (ARQ) to correct errors by (partly) retransmitting corrupted datagrams. Typically a link layer performs all three operations, error detection and forward and/or backward error correction. From a service requirement point of view, applications can be grouped into two categories: 1. Error-tolerant applications: Error-tolerant applications can handle a certain amount of corruption of the transmitted data. The errors can, for example, be residual bit errors within transmitted data packets or packet errors from lost data packets. Typical examples of error-tolerant applications are speech, audio and video applications. Residual bit errors in datagrams or lost datagrams lead to some signal distortion, which introduces some noise. Different portions of the original data have different sensitivity towards errors. For example, class A bits in speech frames or I-frames in video streams are more sensitive to errors than class C bits or P-frames [39]. Several error concealment techniques exist to reduce the amount of distortion that is perceived. The most common error-tolerant application is the speech communication in cellular networks. 2. Error-sensitive applications: Error-sensitive applications cannot tolerate any transmission errors in the data and require lossless data transmission. A single error event already causes a substantial degradation of the data quality. An example is a large file that becomes invalid because of a single bit error. The communication protocols used would influence the sensitivity of the data application. A certain communication protocol can turn a bit-error tolerant application into an error-sensitive application. This is in particular the case for the data centric type of packet-oriented transmission used in all-IP networks [37]. For example, consider a bit-error tolerant application, where the application decoder can accept bit errors (e.g., VoIP or video). If the application flow is encrypted and/or integrity protected with a protocol like IPsec, any bit error that is now introduced into the data stream would disable the decryption of the data stream at the receiver. In a simple scenario without any “advanced” functionality, such as encryption this problem would normally occur. In general, protocol data units of one protocol are encapsulated within protocol data units of another protocol. For a typical VoIP application, a speech frame is encapsulated within an RTP packet, which is encapsulated in a UDP packet, which is encapsulated within an IP packet. If a bit error occurs, there is a certain probability that it affects a protocol header, which would cause the protocol to malfunction (e.g., the datagram would be delivered to the wrong port number). To avoid this kind of malfunctioning, the UDP protects its datagrams with a checksum. Even if a bit error occurs within a portion of the speech frame and could be in principle concealed by the speech decoder, this bit error will cause the UDP checksum to fail and the complete IP packet will be discarded. There-

2.2 Mobility Management

73

fore, a bit-error tolerant speech application turns into an error-sensitive application when it is used as VoIP with the IP protocol suite. Within the IP protocol suite, the lightweight user datagram protocol (UDP-Lite) [40] is the only protocol that allows transport of error-sensitive data. It protects only a predetermined part of the IP packet with a partial checksum [41]. In summary, error-sensitive applications constitute the most significant class of applications to be used in IP networks. An application has a certain requirement in the data rate that it expects from a flow. All applications have a minimum requirement on the average rate, which is larger than zero. If no explicit minimum rate is given, a certain fixed value should be assumed, in order to avoid that the session time exceeds the battery life, the life expectancy of the user (or his/her device), and so forth. Applications can be grouped into the following two categories [37–39]: 1. Discrete-rate applications: These applications typically require data rates centered on one or more discrete service rates. Examples are speech applications, which have a more or less constant service rate. A flow with a persistently lower data rate leads to insufficient service quality; a flow with higher data rate is not used. Other examples are audio or video applications. These can be constant-rate or variable-rate encoded, which largely influences the variance of the service rate. Even variable-rate encoded streams, however, are centered on long-time average service rates, depending on the resolution and encoding quality. 2. Elastic applications: these applications have no discrete rate requirement once a minimum data rate is provided. With increasing the data rates the service performance also improves. When high data rates are provided they can be used by the application. An example application is file transfer. An application can have a requirement on the tolerable transmission delay. Similarly, there is always an upper bound to a maximum acceptable delay, depending on the battery lifetime, and other similar categories. Applications can be grouped into the following two categories according to their delay requirements: 1. Delay-sensitive applications: A delay-sensitive application requires that a datagram is transmitted from transmitter to receiver within a certain delay bound. Delay-sensitive applications are interactive media sessions like (voice/video) telephony. The delay is determined by the interactive behavior of the users, it is typically upper-bounded by approximately 200 ms [39]. Other delay-sensitive applications are multiplayer online games. Streaming applications are also delay-sensitive, however, with more relaxed delay requirements. In streaming applications the delay limit is determined by the playout-buffer size at the receiver and the amount of prebuffering. The delay bound is typically in the range of several seconds. 2. Delay-insensitive applications: Delay-insensitive applications have a delay bound that is orders of magnitude larger than the typical transmission delays. These bounds are given by the battery lifetime, and so forth.

74

Network and Mobility Management

Generally, the application performance increases with smaller transmission delays, but long delays are acceptable. An example is the file download. When the focus is limited to packet-based IP services, error sensitivity may be neglected, because only error-sensitive applications exist. The three sets of application related QoS requirements should be visible at the access flow level of the abstraction in Figure 2.14 to enable efficient MRRM operation. 2.2.3.3.2 Access Selection

The relationship of access resources and access flows, including the QoS requirements, are shown in Figure 2.15 for the example scenario of the three ANs. The access flow needs to be established at the latest when an access resource is selected and included in the MRRM active set (AS). The elements of this set are a subset of the access resources provided in a candidate set (CS) that have been selected by the MRRM through dynamic access selection to handle the EF. There is one AS per EF. The AF, which is the access part of the EF, will be mapped on the elements of this AS. In case that no AF is yet established when the AR is selected, the access flow setup, prior to transmitting data via the AR, needs to be anticipated in the access selection procedure and thus adds some additional delay to this procedure. It also includes a risk that the access flow setup fails (e.g., due to a shortage of access resources or for policy reasons) [37]. Therefore, it is a design trade-off to

Figure 2.15

UML model of access resource and access flow [37].

2.2 Mobility Management

75

establish AFs at an early stage, at the cost of increased signaling and higher resource consumption, (e.g., in terms of device battery). This design trade-off can be based on the following considerations: •

•

•

Access flow setup delay.The MRRM decides to establish AFs before adding the AR to the CS, if dynamic access selection algorithms are used or system parameters influencing access selection change quickly, and if the EF requires a low handover delay. Resource consumption of an established AF. If system resources are scarce (in the network or in the terminal, e.g., battery) and depending on the overhead required for maintaining an AF, the MRRM decides to establish AFs when an AR is selected from the MRRM CS. Precision/reliability of the information that is available for an AR prior to establishing an AF: If policy, resource, and performance information for an access resource is unreliable or insufficient for the access selection decision, the MRRM decides to establish an AF before admitting the AR into the MRRM CS. Some information for an access resource can be retrieved before an AF is established. For example, if the user network is already connected to another access (possibly provided by another network), the user network can request additional information related to an access network (e.g., the network policies) via this existing connection. If this is the case, the MRRM can decide to obtain the information in this alternative way and avoid that an access needs to perform network attachment to obtain further information.

The access resource management entity is typically not aware that its AR is considered for access selection before an AF is established. When a large number of user ANs consider an AR for access selection (the AR is included in one or more CS), while no AFs have been established, there is an increased risk of rejected AF setup requests during the access selection procedure. This can be avoided, by MRRM limiting the number of ANs that may contain an AR without established AF into the MRRM CS. Some prereservation of resources can be performed by the AR management entity if MRRM indicates the increased probability of ANs selecting the AR. An example for the MRRM sets maintained for a U-AN is shown in Figure 2.16. An AN can use multiple accesses in parallel. For each EF the access can be selected individually according to the specific requirements. Further, an EF can be transmitted via multiple AFs, when the AS contains multiple elements. The resources of the multiple flows are then pooled. Typically, the AS contains only one element [37]. The management of the different sets of the MRRM during flow setup is shown in Figure 2.17. When the U-AN wants to establish a data flow, it first activates the default AF that would serve to transport the U-AN signaling to the A-AN. This signaling aims at negotiating the application characteristics with the other end point and at checking that the network supports such an application. The application characteristics are translated to EF requirements by the flow management FE. The establishment of the AF would proceed as follows:

76

Network and Mobility Management

Figure 2.16

Sets maintained for a U-AN during access selection [37].

Figure 2.17

Management of different MRRM sets [37].

•

The MRRM in the U-AN receives from flow management a request to setup the AF according to certain requirements.

2.2 Mobility Management

•

•

•

•

•

•

77

The MRRM in the U-AN sends this request to the A-AN to request the establishment of the AF. The requirements of this AF are specified. The MRRM A-AN asks the U-AN to provide the validation set (VS) already determined during the attachment procedure. The MRRM A-AN builds the CS by determining, which ARs in the VS are suitable to support the requested AF. To do that, it uses measurements provided by the GLL. It may be required that another search for more candidates needs to be performed; this search can be terminated when sufficient candidates have been found. MRRM A-AN performs admission control for the AF on the CS. The result of admission control procedures is used to build the AS. The MRRM A-AN reserves the ARs in the AS and communicates the content of the AS to the MRRM U-AN. The MRRM U-AN asks for the establishment of the ARs in the AS.

2.2.3.4

Abstractions for RAT Specific Measurements

Efficient RRM requires measurements of link performance and resource availability. For CoopRRM or MRRM operation it is critical to have an abstraction model of these measurements so that the different RAT-specific link performance and load measurements can be compared with each other in a generic way. The abstraction is encoded in the specification of the multi-access parts of the interface towards the CoopRRM/MRRM. 2.2.3.4.1 Link Performance and Capability Abstraction

The abstract link information should match the access flow related application QoS requirements. This is shown in Figure 2.18.

Figure 2.18

Link performance and capability abstraction [37].

78

Network and Mobility Management

A suitable abstraction is the following: •

• • •

Link rate (instantaneous value, expected average, minimum, maximum, expected variation); Delay (minimum, maximum, expected average, expected variation); Residual BER (minimum, maximum, expected average, expected variation); Residual PER (minimum, maximum, expected average, expected variation).

The abstracted link quality values are derived from access specific measured values, such as the following: • • • •

Received signal strength indicator (RSSI); Signal to interference and noise ratio (SINR); Channel quality indicator (CQI); Raw bit error rate (bit error rate before channel decoding).

For different RATs different access specific measures can be used. The GLL maps the RAT-specific values into the abstract values. This mapping function can also consider implementation specific variations. For example, a simple and a complex receiver of the same access technology may be able to achieve different link performance in terms of data rate for the same received signal strength. Therefore, the mapping function needs an abstraction that meets the QoS requirements as expressed by the application. A suitable abstraction can be given at the IP-packet level. This means that the aforementioned capabilities of an access link will be expressed in terms of IP packet attributes including the throughput/goodput, packet delay, and packet loss. 2.2.3.4.2 Resource Abstraction

Different RATs have widely different mechanisms for using and sharing its available resources among users, for example, division into time/frequency slots or codes or shared statistically using contention-based schemes. The notions of the amount of total resource occupied (the load level), and the amount of resource that a particular user session occupies are therefore quite different for different RATs. The latter also depends on the quality requirements of the session/application. Different RATs may further be deployed with full or only spotty/hotspot coverage. For an entity, such as the CoopRRM or MRRM to exploit radio resource information from heterogeneous RATs in its operation, it is necessary to have a mechanism that can derive comparable, relevant measures. The GLL would abstract and compute the resource levels in each access resource area (ARA) according to a relative resource level [37]. Depending on what is the limiting resource(s) in the RAT, it can be computed as, for example, the relative number of (time) slots or codes, the relative amount of (downlink) power, the relative occupied bandwidth, the average collision ratio, or combinations thereof such as power and slots (chunks). The computation is done on-demand from the CoopRRM/MRRM, for example during an admission control process or to get up-to-date information prior to a load management decision. The computation can also be performed continuously or

2.2 Mobility Management

79

when the RAT-specific events occur; in this case the values could optionally be communicated only when certain thresholds have been reached in order to reduce the signaling load. The following resource levels are computed per ARA [37]: •

•

•

rmin = The current minimum required amount of resources for all active users/sessions in the ARA. rocc = The current occupied amount of resources for all active users/sessions in the ARA. This can be larger than rmin whenever extra, “elastic” resources are provided for users/sessions that can benefit from it. It is assumed that all of the extra resources (rocc–rmin) can (either instantaneously or after some delay) be reclaimed and used for other users. rmax = The current maximum amount that can be used in the ARA. The “headroom” 1-rmax is the margin required to cope with changing resource usage of active users in the ARA due to, for example, user mobility. If the time to free up extra, elastic resources is very small or zero, rocc resources (but not rmin) could be allowed to grow beyond the rmax limit as these can be freed up to give room for increasing resource usage of active users.

The following resource levels are derived from the above [37]: •

•

δmin = rmax − rmin = Relative amount of currently available resources, including resources that can be (instantaneously) freed up if they are currently used to provide extra quality for some (or all) users. δocc = rmax − rocc = Relative amount of currently free resources.

Figure 2.19 shows the relative resource levels in each ARA. A multiaccess control decision (e.g., admission control, load management) will be executed for a user/session i requesting quality Qi,req in an area covered by at least one ARA. Qi,req can be defined in different ways; typically it contains requirements on minimum bit rate and maximum delay, as well as how much additional quality

Figure 2.19

Average resource levels in each ARA [37].

80

Network and Mobility Management

(i.e., typically extra bit rate), if possible to provide, is beneficial (for example for file transfers). For example, for each relevant ARA, the MRRM entity transmits Qi,req to the associated GLL and requests it to do a RAT-specific mapping of Qi,req and compute the MRRM resource measures [37]. The GLL retrieves resource information from the underlying RAT-specific entities, computes the resource levels rmin, rocc, and rmax, and, finally, computes the following generic MRRM resource measures per user/session: •

•

•

•

•

Qi,offered = Offered quality such as offered bit rate, maximum delay and additional quality (typically extra bit rate). This is typically only reported back to the MRRM when Qi,offered differs from Qi,req. qi,min = Relative RAT-specific (instantaneous) resource usage if user/session i would be “served” in the ARA with minimum quality requirements. For example, if there are 10 slots in the ARA and one slot is required, then qi,min =0,1. If qi,min > 1 then it is not possible to meet the minimum quality requirements in the ARA because the minimum amount of requested resources exceeds the available resources and such request is typically rejected. qi,extra = As above, but where user/session i is given as much extra quality as it benefits from or can be currently given. So qi,extra >= qi,min as it contains additional spare resources. = qi,min / δmin = Relative resource efficiency/impact of serving user/session i in i,min the ARA with minimum quality requirements. For example, if min = 0.4 and qi,min =0,1 then i,min = 0,25. If σi,min > 1 then the amount of resources requested exceeds the available resources and such request is typically rejected. σi,extra = qi,extra / δocc = As above, but where user/session i is given as much extra quality it benefits from or can be currently given.

All measures apart from Qi,req and Qi,offered in the above example are given as relative measures. The (absolute) service request Qi,req is received at the MRRM from a higher level. MRRM forwards Qi,req to one or more GLLs, which would convert it into access-specific relative resource requirements qi. Further, the other relative measures are calculated and reported back to the MRRM. Once computed the MRRM resource measures (and possibly the resource levels) are signaled from the GLL to the MRRM, which then uses the values for the multiaccess control decision. Some examples of MRRM decisions can be given as follows: For admission control a first step is to check whether σi,min = 1 for the ARA; if not then the user/session i cannot be admitted there. • Initial access selection or load management can be based on many different algorithms. Examples can be: Choosing the RAT/ARA with maximum amount of available resources δmin: ARA selected for user/session i = argminj { δmin (ARAj) }. •

2.2 Mobility Management

81

Choosing the RAT/ARA with maximum amount of free resources δocc: ARA selected for user/session i = argminj { δocc (ARAj) }. Choosing the RAT / ARA with minimum resource usage efficiency σi,min, that is: ARA selected for user/session i = argminj { σi,min (ARAj) }. Choosing the RAT / ARA with minimum resource usage efficiency si,extra, that is: ARA selected for user/session i = argminj { σi,extra(ARAj) }. If the current load is high in all ARAs, i.e. σi,xtra > 1 for all RATs, then alternatively the RAT / ARA could be selected minimizing σi,min instead. Many other MRRM decision algorithms can be considered based on the MRRM resource measures above. The key purpose of the measures is to provide sufficient, comparable radio information on the current radio resource state and resource usage efficiency for various heterogeneous RATs for effective MRRM operation. In some cases additional interactive negotiation between GLL(s) and MRRM can be performed, when the GLLs provide additional information about the best service performance that can be provided (without guarantees). For this a translation from relative measures back to an absolute measure Qi,offered is required. This is explained with the following example: •

•

•

•

The MRRM gets a request for (absolute) resources Qi,req, (e.g., Qi,req is a request for 150 kbps service). The MRRM passes the request Qi,req on to the GLLs, where it is translated to relative resources qi,min. The GLLs reply to MRRM the relative load values for load balancing, to determine the relative resource costs of qi,min (i.e. qi,min). If spare access resources are available, it would maybe be beneficial to know what absolute service level Qi,offered could be provided to the service by the access (i.e., what maximum Q can be provided by qi,extra > qi,min). This requires that GLL would not only make a translation Qi,req qi,min but also qi,extra Qi,offered. The MRRM would get the following information from the GLL: “Your request Qi,req can be handled, it costs the relative resources qi,min Access could even support the service request at level Qi,offered, but this would then cost the resources qi,extra” [37].

2.2.3.4.2 Weighted Metrics

In a realistic scenario, the resource abstractions can be weighted in the MRRM access selection decision [37]. For example, different RATs/ARAs may have different priority weights assigned. This requires that the generic resource metrics is adapted by a weight factor according to the RAT/ARA priorities. The priorities can be set according to the following criteria: • •

• •

To reflect the operator or terminal priorities of RAT/ARA usage; Identifying the additional roaming/cooperation charges for the usage of the RATs/ARAs; Depending on the required signaling for handover or AAA; Security provision.

82

Network and Mobility Management

2.2.3.5

Access Selection Procedure

Access selection is the process by which an AS is chosen from the DS (see Section 2.2.3.2). It comprises the steps of building the VS and the CS. Access selection consequently considers both static and dynamic parameters. Static parameters are taken into account when building the VS and the CS. This part of the access selection process is called access control. The AS is built based on information from dynamic parameters provided with the CS. 2.2.3.5.1 Triggering of Access Selection

Access selection can be triggered by different events. The most straightforward reason is the request for a new session implying a request for a new end-to-end flow, modification or release. It may also come from a modification of existing sets, which would require an update of the AS as follows: •

•

•

Modification of the DS: a new access resource becomes available, or an access resource gets unavailable, for example, from radio signal strength point of view [37]. Modification of the VS: policy change, (e.g., security change in trust, such as an expired certificate, accounting, such as pre-paid/micropayment account expired, and so forth. Modification of the CS: the required access resources becomes unavailable because one network gets overloaded, or can no longer provide a given QoS for a given service type.

Access selection may also be triggered following dynamic modifications of the different criteria that are considered for selecting the best access and that would be included in the triggering set. The process is then performed by an access selection algorithm, which can be distributed between different network elements, (e.g., the terminal handles idle-state access selection, while the access network performs access selection in the connected-state). The decision is then based on input from different entities communicating with the global RRM entity. In dynamic access selection, the dynamic parameters are obtained following the abstraction of the RAT-specific values, such as the link rate, delay, residual BER, and residual PER. The input information for the access selection algorithm should be signaled either via the backhaul fixed network (on the network side) or transmitted by the network or the terminals over the air. This generates new requirements for the signaling exchange, which needs to be restricted [37]. The following issues should be noted: •

In order to measure and report the input information for the RA selection algorithms the current standards of the various wireless access networks might need to be extended with new measurement procedures, information elements (IEs), signaling bearers, etc. In the example architecture in Figure 2.12, the GLL functions are responsible for collecting the necessary RA related measurements and translate them into the link performance and RAs. These mea-

2.2 Mobility Management

•

•

83

surements are then further processed by the MRRM access selection function in deciding, which access flow should be selected. Recent input information is necessary in order to achieve as high gains as possible from “optimized” access selection algorithms. This is due to the sensitivity of the access selection algorithms to the aging of the input information. In order to avoid rather frequent measurements reports, it is advisable to filter measurements and to trigger measurement reports only if important performance thresholds are exceeded. In this case, the GLL functions have an important responsibility in providing these triggers, for the individual access flows, to the MRRM functions. The requirement to have an updated input information and the high time variability of the dynamic parameters (e.g., instantaneous radio link characteristics) results in frequent measurementsand signaling of these measurement reports. This signaling also consumes capacity either in the fixed backhaul network or in the radio interface.

Furthermore, the dynamic parameters described above require measurement procedures. The signaling amount and delay is related to the location where the access selection algorithm takes place with respect to the location where the measurement information is collected. The following examples can be summarized [37]: •

•

•

The access selection algorithm is executed in the terminal. The terminal has access to radio information such as signal strengths, interference levels from measurements. However, information about the access congestion level, resource consumption and cost, etc. have to be signaled to the terminal if the access selection is based on this information as well. The network must be able to support when the candidate set (out of the detected set) is chosen, so that congested RAs are not included. The access selection algorithm is executed in the multiradio access point. This means that the access selection is done physically close to the radio accesses and in turn implies that radio link quality estimates can be made available for the access selection decision with small signaling delay. The terminal measures the radio link quality and reports it to the multiradio access point on the radio feedback channel. Hence, it is possible to react to short-term radio channel variations, which speeds up the selection process. If a new multiradio access point, which is not physically close to the location where the access selection algorithm is executed is added or selected in the AS then longer signaling delays are introduced. This prevents the fast access selection to be executed also towards the newly added “remote” access point. The signaling from the remote access point could be either done via a fixed backhaul network, if such an infrastructure exists, or via a wireless link. The access selection algorithm is executed in some other node. In this case the access selection is executed further away from the multiradio access points. The location of the other node could also be outside the operator’s network. Here, the access selection is constrained by the longer signaling delays and input information availability.

84

Network and Mobility Management

2.2.3.5.2 Implementation of Access Selection Algorithms

The access selection algorithms can be implemented by the optimization of a utility function [37]. The utility function can be derived from one performance metric or a weighted combination of several performance metrics, such as the achievable user throughput, blocking or dropping probability, communication costs (in terms of resource consumption and/or price), and resource utilization (load balancing). A higher “importance” of a performance metric in the overall objective results in a higher weight for this particular metric in the combined utility function. If the weight is zero then the performance metric is nonexisting in the overall objective (i.e., irrelevant metric). The algorithms can also be used in prioritized order, according to which accesses can be added to/dismissed from the access selection. The prioritized order or weight factors can vary according to the service type, (e.g., real-time services may prioritize service QoS), whereas best-effort services prioritize resource cost. For estimating the performance metrics, the access selection algorithm uses the input information described above. To calculate the achievable throughput per user the access selection algorithm can use the radio link characteristics and congestion level per radio access. Then this input should be mapped onto the abstracted resource values (e.g., effective link rate, delay, BER, and PER) for each element of the CS. The following are examples of selection criteria for the access selection algorithm: •

•

•

Select the radio access flow with the highest effective link rate. The motivation here is to select a radio path with the best radio link conditions leading to high-quality communications. There are several problems with this algorithm: first, the communication quality also depends on the congestion level of the particular RA, and second, this algorithm does not consider the requirements of the service. Select the radio access flow with the lowest congestion level. The motivation here is to evenly distribute the load in the available RAs (i.e., load balancing). However, because the link rate is not considered in the selection the user might end up with a bad link rate and consequently low communication quality. Select the radio access flow based on QoS requirements, (i.e., in order to assign an access, which is able/most fit to meet the requested service quality). The drawback here is that this approach requires more complex processing to assess the attainability of the QoS targets and the associated resource efficiency, and also it does not include cost-related information.

Other examples of access selection objectives, and triggering sources, can be the following: •

•

User specific predefined priority list for preferred RATs and/or network operators; Service type and QoS requirements specific predefined priority list for preferred RATs;

2.2 Mobility Management

• • •

85

Congestion in the ongoing session; Changes in service requirements (i.e., bearer/flow management); Cost of active access too high.

Functions

For every access that can be selected for an ongoing communication session, a certain utility can be determined. This utility describes the value of the selected access for different subsystems of the multiaccess system. Different types of utility can be differentiated [42]. A service utility uS represents the value of an access as seen by the service. In other words it describes the perceived performance of the access. The value for the service depends largely on the service requirements. Two basic classes of services can be distinguished: 1. Elastic services have the characteristics that they can use any capacity that is given to them. The higher the data rate that is provided to such a service, the higher is the perceived performance or service utility. Examples of elastic services are Web browsing, e-mail synchronization, the upload or download of photos, and audio and video files. 2. Discrete services have connectivity requirements given in discrete steps. For example, audio/video/speech conferencing or streaming services have data encoded with certain average rates and typically have certain delay requirements. An access that provides appropriate data rates and delays can support the service. If the data rate provided by the access increases further, it only brings additional value to the service if the next discrete step is reached (e.g., when the video conference can switch to a video signal with higher resolution). A speech service has typically a binary requirement, it is supported if a sufficient data rate is achieved and a tolerable delay is not exceeded. A higher data rate does not add additional value for the service. For discrete services the service utility is a stepwise function. The service utility can be affected by handover events if the service performance is affected, (e.g., due to delay or packet loss). Each handover event introduces a handover penalty, which depends on the sensitivity of the service and the efficiency of the handover procedure of the access system. This handover penalty is scaled by the handover rate, which depends on the user mobility and the cell sizes. The user utility uU designates the user satisfaction, which is specified as user policies. These policies can require that only an access with sufficient security mechanisms can be selected. Another typical user policy is to reduce the costs of the service. So uU decreases with increasing the costs of the access. The user network utility uUN characterizes the efficient usage of resources in the user terminal or user network for each access system. As an example, two access systems may require different transmission power to provide the same performance. The access network utility uAN is the equivalent to the uUN within the access network. It describes the value accumulated by the allocation of resources to services. One difference to the uUN is that a large number of users are connected to the same access network. So the access allocation also comprises the selection, for which

86

Network and Mobility Management

users, which resources are allocated. One descriptor for the user network utility can be the total revenue generated for the access network. This revenue can be described in the total access network capacity given in aggregated data rate, or it can be given in number of users supported in the system. The network utility uN represents the preferences of the network. These preferences are described as network policies, which specify the priorities for different users. The policy can prioritize users depending on the type of subscription, the user’s loyalty as a customer, or the amount of usage. Algorithms

For every communication session there is a set of available RATs. The objective of an access selection function is to evaluate the available RATs and determine the one that is best suited. In mathematical terms, this can be expressed as an optimization function, where the allocation of RATs for N sessions (belonging to a number of users) is selected to maximize a global utility u: ρ selected access = j

⎧ ⎛ρ⎞ ⎫ arg max ⎨u ⎜ ⎟ ⎬ ⎩ ⎝ i⎠⎭ ρ ∈ DS N i

(2.1)

The possible allocations are determined by a DS of RATs for every session, and ρ ρ , denote the allocation vectors of the RATs to sessions. The global utility is a j i combination of the described previously different utility functions: u = f (u s ; uU ; uUN ; u AN ; u N )

(2.2)

The access selection is ideally realized as multi-stage process as shown in Figure 2.20. During access control, for every session a CS is determined out of the VS of the access resources, which is itself determined out of the DS. During the dynamic access selection, the active access is dynamically determined out of the CS. This separation is motivated by the different time scales, at which system parameters and utilities change. If during any phase of the selection process there is only one detected access left fulfilling the access selection criteria, that access can be selected into the active set directly without further iterations. The policies, which determine the user and network utility are typically static for longer time periods. For example, the security requirements of the user or the tariffs for charging access use change only infrequently. The preselection is based on constraints and policies provided to the global RRM (e.g., MRRM) by other functional entities. In contrast, the parameters, which govern the dynamic part of access selection change frequently. These dynamic parameters are the performance of the radio links and the availability of resources for the different RATs, which change constantly due to user mobility, radio channel fluctuation, and variations in the traffic load in the system. Two general classes of dynamic access selection algorithms can be distinguished. The first one is the rate-based access selection and it depends only on the

2.2 Mobility Management

87

Figure 2.20 Access selection as a two-stage process, a (slow) policy-based preselection and a (fast) dynamic selection [37].

link performance as a function of the radio link quality of the different user terminals. As a result, the global utility according to (2.2) only depends on the service utility but not on user network or access network utilities. Access selection then depends on the rates R, delay D, error rate E, and handover performance H perceived by the sessions in the system as shown in (2.3): (2.3)

The second class of algorithms are the resource-based access selection, which also considers the load and resource situation in the different RATs. Consequently, also the access network and user network utilities are considered in the access selection process. These depend on the system load ρ, the available resources δ, and the resource efficiency σ:(2.4)

(2.4)

88

Network and Mobility Management

Rate-based access selection can easily be implemented in a distributed manner, (e.g., the access selection function is located in the user terminals). For resourcebased access selection, the system load information needs to be collected and distributed to all access selection decision points. A terminal-based realization thus requires frequent distribution of load information over the radio links. It further has the risk of synchronization effects, when multiple terminals react simultaneously in the same way on changes in load. Consequently, a network-based realization is preferred. Besides, a network-based realization enables to add network strategies to the access selection algorithm. The user utility maximization strategies may lead to a selfish behavior [37]. For example, the rate-based access selection does not take into account the access network utility and is not socially efficient, as it may lead to users requesting too much power, generating too much interference, and consequently triggering a general network overload. The social behavior, however, can be obtained by taking into account the access network status on load and available resources. Another method could be to add pricing in the access selection strategy. It consists in maximizing a utility function that takes into account both the user satisfaction level and the cost of satisfying the user for the access network. This cost may be expressed in terms of throughput, or of resource consumption (power, time slots, codes, subcarriers, etc., depending on the PHY layer characteristics of the access network). It may also be dynamically modified depending on the radio conditions: for example, a higher cost per bits/s will be requested when the radio access is overloaded. Although network-based realization is preferred, terminal-based realization remains feasible, at the expense of additional signaling [37]. Selection of Access Flows

The problem of selecting one (or more) access flows for a particular end-to-end flow/bearer relate to how the characteristics (static and dynamic) of the access flows match to the requirements of the end-to-end flow/bearer and how other policy constraints apply to prefer a particular available access over another [37]. There may, however, also be constraints for the selection arising from other end-to-end flows that are associated with the end-to-end flow/bearer under consideration. Because flows in the connectivity abstraction are unidirectional an obvious constraint arises when a bidirectional service, for example, VoIP, is being mapped to (at least) two flows. There are also other cases when the access allocation of one flow should influence the allocation of other flows. For example, an access flow is selected for a first “downlink” end-to-end flow to a user terminal. The access flow is then subsequently mapped to a particular access configuration (e.g., the radio bearer in 3G) that also includes (some) resources for a corresponding “uplink” flow. This access configuration mapping may not be under the control of the global RRM functionality. An access flow is selected for a first end-to-end flow, which is mapped to an access configuration that has elastic capacity (e.g., a best-effort bearer). Again this mapping is not controlled by the global RRM functionality.

2.2 Mobility Management

89

In another example, an access flow is selected for a first end-to-end flow, and this access is not preferably used simultaneously with some other access that is available for the user terminal. For example, the two accesses may interfere in a negative way with each other so that simultaneous usage is inefficient. Two examples to further demonstrate this correlation between access flows are the following: •

•

A terminal (WLAN+3G) has a VoIP session. For a terminal both accesses perform well enough, but they have different traffic load. 3G has a very asymmetric load with high load in the downlink. The standard access selection would select the WLAN access flow for the VoIP DL flow and the 3G access flow for the VoIP UL flow. The allocation of VoIP UL to 3G, however, already requires that also in 3G the DL channels are set up for control signaling. Due to that, the “additional” resource to also allocate the data flow to the 3G DL may not be so relevant. Similarly, from a terminal side the allocation of both flows to the same access may be feasible. The usage of the 3G radio modem requires a certain amount of resources, as does the WLAN radio modem. If a single flow is allocated to either, the access should be selected according to the required resources, the link performance, and the policies. But once a flow has already been allocated (and one radio modem is active), for a new flow it should be considered that the additional load on the active radio modem may be more efficient than starting another radio modem. A terminal (3G+WLAN) has a VoIP session and a video session. For the VoIP session 3G is chosen. When the video session starts, the WLAN system is selected as the best access. After the allocation of the video session to the WLAN, it should be reevaluated if the VoIP should stay on the 3G, because the WLAN module is active anyway.

The dependence between the access selection decisions for different end-to end flows can be expressed as the constraints for the access selection that relate to groups, or bundles, of end-to-end flows [37]. An issue is that the access selection decisions for the flows in these bundles may be spread over time, that is, they may not be synchronous. Flows may come and go, and as they do so, access selections need to be made independently in a sequential manner. In some cases decisions can be made simultaneously for all flows in a bundle, for example, during a multiflow session setup. However, even in this case the application will typically request allocation sequentially of one flow after the other. To improve the access selection allocations it may be advantageous to periodically evaluate the assignments from a global perspective, considering the bundle constraints for all sessions to a user terminal and possibly also considering all user terminals (or user networks) jointly together. Due to the complexity of such a global evaluation, and the possibly long time for its completion, it may not be practically feasible or at all desirable to execute it whenever a single access selection event needs to be resolved. Reference [2] proposed that a correlation list between access selection choices for bundles of end-to-end flows is managed by the global RRM entity (e.g., MRRM). This list keeps track of the correlation utility values that are used for the

90

Network and Mobility Management

access selection flow decision, in addition to any other access selection criteria. An entry is kept in the list for each access flow that is available for assignment of future end-to-end flows, such that it would be influenced by already assigned flows. It is assumed that the decision can be influenced towards a particular access flow (or a set of access flows) if a high positive correlation utility value is assigned and away from a particular access flow for a high negative correlation utility value. The correlation utility values then are just fed into the decision algorithm. The range of the correlation utility values, how they are combined with other access selection utilities, and to what extent they influence the decision, depends on the actual implementation of the managing entity (i.e., MRRM) as well as on the preferences for resource-efficient, revenue-maximizing operation of a multiaccess system [37]. The access correlation list is updated when an access selection decision has been made for an end-to-end flow. If the access selection decision is such that it would correlate with the decisions for subsequent end-to-end flows, then a nonzero correlation utility value is set for the corresponding access flow(s). Table 2.1 shows an example access correlation list after a first end-to-end flow f1_ID has been allocated to an access flow AF1. In this example, it would be beneficial to use the same access flow AF1 for future flows (+2 correlation utility). It would also not be good to use access flow AF3 (-5 correlation utility). For each entry there is also a record that lists the end-to-end flows that relate to it (the related flow bundle). When an access selection decision needs to be made for a second end-to-end flow f2_ID, the access correlation list is consulted. When an access flow is evaluated, the corresponding correlation utility value in the list is used to influence the access selection decision. If this access flow is ultimately selected then the related flows record in the access correlation list is updated (f2_ID added). The related flow bundle list is also updated when flows are terminated—if it becomes empty then the corresponding entry is removed from the access correlation list. The access correlation list can also be further separated in terms of the types of flows for which the entries apply. That is, each entry is extended with one or more flow qualifiers for future end-to-end flows. The flow qualifiers are the constraints on future end-to-end flows that need to be satisfied in order to apply the access correlation utility. Those can, for example, require a certain direction of the flow or define some quality of service requirements (maximum bit-rate, best effort, etc). When an access selection decision needs to be made for a second end-to-end flow the access correlation list is consulted, but now the flow qualifiers must also be matched against the characteristics of the second end-to-end flow before the corresponding correlation utility value is applied to influence the evaluation of a particular access. The updates of the related flow bundle list are similar.

Table 2.1

Example of an Access Correlation List [37].

Entry #

Access Flow

Correlation Utility

Related Flows

1

AF1

2

{f1_ID}

2

AF3

−5

{f1_ID}

…

2.2 Mobility Management

91

A multiflow session setup will typically be implemented sequentially in a one-flow-after-another way. The final outcome of such a multiflow access selection sequence depends on the order of the flows. If it is possible to signal to MRRM that a multiflow setup is in progress, then additional gains can be made by ordering the flows in some way. The flows may be ordered according to some of the other criteria used for access selection decision-making (flow requirements, policies, preferences), for example, according to bit rate requirements. Each flow may also first be tentatively evaluated for an access selection decision using the access correlation list where the correlation utilities are virtually updated. When this has been done for all flows the virtually updated correlation utilities are inspected and the flows are ordered following which had the most impact; that is, the largest net change in correlation utilities. This may also be extended so that the tentative evaluations are repeated for all pairs of flows in the multiflow session. That means, that first evaluation and virtual allocation/update for the first flow in the pair is done, then the same process is repeated for the second flow in the pair, and only after this a check of the net change in correlation utilities is done. 2.2.3.6

Path Selection

Mobility management is dependent on the selection of the appropriate path through the network, which in turn is dependent on the availability of radio accesses as detected by the entity executing RRM mechanisms (e.g., CoopRRM or MRRM). An entity would be required for path selection and it would assess the constraints on the choice of access in order to select the most appropriate path for a flow once the access has been decided by the central entity (e.g., CoopRRM or MRRM) [21]. This latter aspect also requires selection of the most appropriate locator to use for the flow to ensure correct routing across the network. The blocks for mobility management including path selection are shown in Figure 2.21. During handover, the bearer requirements are passed on to the path selection entity, and this information would be combined with information from other entities in order to determine, which access is most suitable. The split of responsibility between entities, such as the MRRM, the HOLM, and the path selection allows for using different constraints by each entity to assess during access selection and for using its own internal parameters in the process. For example, an operator may wish to influence the selection based on its own policy without disclosing this to the MRRM entity in the access network, or only to make use of certain handover tools. The need to assess available paths may be initiated either upon receipt of a request to establish a new flow, or as a result of a need to handover. For example, the MRRM detects and monitors possible network points of attachment (PoA) and receives triggering events directly or via the rigger management system. The MRRM can react on this with a target access selection for one or several flows and a handover command to the handover and locator management entity. But for the choice between possible PoAs there are a number of constraints inside and outside the MRRM that may influence, which PoA is selected for a flow or set of flows.

92

Network and Mobility Management

Figure 2.21

Interactions during mobility management [21].

The MRRM and the path selection entities both play a significant role in the access selection decision. The MRRM selects suitable access point(s) and the proper time to perform a handover. The path selection can provide information to the MRRM that constrains or influences the access selection decision, (e.g., information about availability of mobility protocols, locator lifetime constraints and end-to-end communication (beyond the view of the local access conditions). For this purpose information from other entities, local or nonlocal, can be used. The policy entity captures the preferences of the operator, user, and bearers with regard to the characteristics of the network in use. It is expected that most of this information is available in a context information base (CIB), but some aspects of the information (e.g., operator policy associated with the user) may be restricted (e.g., operator policies, user policies, bearer requirements related to the current bearer QoS characteristics) [21]. The entity responsible for the capability aware routing (see Figure 2.21) selects the route for a flow can be based on information, such as the path characteristics (e.g., QoS, security, and node identity [43] router preferences). The amount of information available about routing can vary depending on the sophistication of the network and the terminal, and can be distributed across both terminal and network(s). To avoid a trial and error basis, these considerations should be taken into account prior to the handover decision by interacting with the “routing function” in some way. The following different cases can be summarized:

2.2 Mobility Management

•

•

• •

93

Local information: information is advertised that indicates whether the network supports public access to external networking services. This is analogous to the capabilities devised within groups such as the IEEE 802.11u [44]. End-to-end information: query messages can be used to establish whether the end-to-end characteristics across a set of possible target networks are sufficient. Interaction with the network node identity (NID) architecture. Dependencies between flows: when applications have multiple active flows, there may be some binding between them such that the flows should follow the same route across the network.

2.2.3.7

Decision Metrics

A distributed decision may use a metric regarding only the results of constraint assessment rather than the exchange of the limiting parameters (e.g., rather than telling that the end-to-end bandwidth is 1MBit/sec it is stated that it is “not quite sufficient”). Reference [21] proposed to use relative suitability as the metric of each constraint, (i.e., any constraint enters the metric as a percentage number ni calculated from the ratio of the limiting parameter i to the according demand). Multiple constraints can be combined to yield the overall suitability for the access selection. A low fit of one constraint can set the whole metric to a low value and must not be compensated by a high fit of another (as would happen in a weighted sum). Instead, all constraints ni are to be regarded as in a logical AND rather than a logical OR( i.e., a failing fit of one term shall lead to a zero metric result). A possible constraint metric is given in (2.5): c total = 100% ⋅

n1 n2 n ⋅ K m 100% 100% 100%

(2.5)

A more flexible constraint ranking mechanism may use nonlinear behavior of constraints and/or different weighting for each constraint (i.e., assigning limits, offsets, or exponents to each constraint) [45]. This allows adjustment of the importance of the constraints from different sources and according to the context. For example, the constraint metric may put a higher weighting (e.g., a quadratic exponent) on the handover interruption time for a real-time application than for a background service (exponent set to 1 or even to 0). Due to the distributed access selection cascading of metrics is required to be implemented in an entity such as path selection or the MRRM [21]. The MRRM establishes a candidate list of PoA based on the radio ranking and requests the path selection module to perform a constraint survey of each. The path selection evaluates its own database (e.g., CIB) and may contact other entities as required, for example, the capability aware routing entity [43]. The path selection evaluates the weighting of these constraints and attaches one percentage value to each candidate on the list. The MRRM compromises the access selection ranking between radio constraints, other MRRM constraints (e.g., cost or system load) and the path selection constraint.

94

Network and Mobility Management

2.2.4

Mobility Management Service Access Points (SAPs)

Mobility management in next generation networks requires the following functionality at the SAPs of a system [21]: •

• • • •

Sending trigger events (such as security policy change, or under provisioning of QoS); Receiving trigger events (e.g., policy changes or HO commands; Applying the constraints to the suggested handover; Execution of the handover; Indication (on receipt of triggers) to MRRM that a handover should be considered.

The interactions of the entities shown in Figure 2.21 are supported at different SAPs by primitives and corresponding signaling sequences. Usually, the service requests at the SAPs will be node internal or at least internal to one network (i.e., ambient network [2]), while the functionality of the service request may require communication between peer entities in different ambient networks. An example of the interaction of the previously described HOLM and MRRM entities for mobility management is shown in Figure 2.22. Four different types of SAPs can be used for entering trigger events into the repository and for distributing them to consumers. Shows the different processes and message interchanging between a triggering producer through a trigger producer SAP. One of the main challenges is that some of those sources may send information that is relatively fast changing, so the interface between them and the TRG FE block in Figure 2.23 needs to be simple to ensure a quick, yet reliable, delivery of the corresponding events. The information provided by the source about the event will not be interpreted by the triggering, but will be, if all policies and filtering rules are met, sent to the corresponding consumer(s). Another relevant aspect about the interface between producers and the trigger entity is the security considerations. There must be some means to ensure the trustworthiness of the incoming events, since a malicious triggering source may be able to influence the whole operation of the decision making entity (i.e., access control server-ACS) and, thus, the ongoing services. A registration process (between the producer and the TRG FE) may serve as a way to ensure the fidelity of such a source and, in addition, composition may also be an alternative way to lessen security risks [21]. 2.2.4.1

Handover Constraint Selection SAP

Another important SAP for mobility management is the handover constraint selection SAP. The distributed decision on the selection of the target access for handover events will be negotiated by a constraint selection request [21]. For the exchange of handover constraints between the path selection and the MRRM the following messages are defined on the handover constraint SAP of the path selection entity: •

Handover_constraints_request;

2.2 Mobility Management

95

Figure 2.22 Mobility related communication using SAPs between different functional entities (architecture and peer) [21].

Figure 2.23

• •

Triggering event through a trigger producer SAP [21].

Handover_constraints_response; Suggest_handover indication.

Figure 2.24 shows the basic request-response signaling sequence of the handover constraint selection.

96

Network and Mobility Management

Figure 2.24

Signaling sequence for constraint selection at the handover constraint SAP [21].

Some MRRM event (e.g., a mobility or load trigger) regarding a flow x and currently using access A can cause the MRRM to envision a handover. Then the MRRM compiles a list of potential target radio accesses out of its set of detected radio accesses or from the subset of validated radio accesses [14]. The MRRM requests constraints on accesses of this list from the path selection. The constraint selection response then enables the MRRM to reduce these sets to the candidate set [14] of accesses, from which it can choose the handover target access. The description of the flows is based on the identifiers that are used for mapping the bearers to flows. But in many cases the access selection will include candidate PoAs, to which no association or signaling exists. Then, only limited knowledge may exist, (e.g., no locator is available for some of the accesses). Thus, the handover_constraint request can only be based on radio level identifiers of the accesses, (i.e., Cell-ID, Operator-ID as used in WLAN, or 3GPP). Further, the transaction ID and sequence number shall be used to distinguish messages from subsequent requests and responses. In the handover_constraint response, the path selection takes reference to the request either by the transaction ID and/or by including the flow-ID, current access and the list of potential accesses. It attaches to each element of the list a single constraint value. This value is evaluated according to a metric D = f (ni, wi) with a range of inputs ni regarding different parameters known about this access (e.g., end-to-end path characteristics such as QoS capabilities and security properties) and with the weights wi, which indicate the importance of each constraining parameter. An entity such as the MRRM would also have knowledge of other parameters about the possible accesses, (e.g., radio link quality assessed by scanning or radio load retrieved from the network databases). The MRRM will enter the constraint values from the handover_constraint_response into another metric E = f (mi, vi) with (at least) inputs m1, m2, and weights v1 and v2, where the first parameter m1 = D and D = f (ni, wi). The input m2 probably will be calculated by yet another, internal to the entity metric. This calculation scheme for the constraint metric is shown in Figure 2.25. Sorting the list of potential accesses in the order of their values of metric E now allows to select the target access for the handover request.

2.2 Mobility Management

Figure 2.25

2.2.4.2

97

Metric for handover_constraints _collection distributed across different entities [21].

Handover Execution SAP

The weighted list of accesses delivered in the handover_constraint_response is used by the MRRM to take a handover decision and to select the target access. The MRRM then requests the handover and locator manager at the handover execution SAP to execute the handover. The handover and locator manager selects the handover protocol best applicable from the toolbox. The sequence of the protocol steps for a handover event depends on this selection. For example, if comparing between three different MIP [23] handover types, namely, the MIP using break-before make (BBM) [46] with a single radio interface, MIP with two radio interfaces enabling make-before-break (MBB) [46], and a fast handover MIP (FMIP), which typically uses a single interface and lists the corresponding steps for performing the radio and the IP layer connectivity change in chronological order. The differences in the steps involved are shown in Tables 2.2, 2.3, and 2.4. A single request-response pair of messages between the MRRM and HOLM is not sufficient for the handover execution. This would change the type of exchanged messages generating a sequence of interactions as shown in Figure 2.26 that may take place across the HOLM SAP during handover. These messages require the use of sequence numbers to distinguish them from subsequent messages. For each flow the handover and locator entity maintains the following state machine as shown in Figure 2.27. The following three states are shown:

98

Network and Mobility Management Table 2.2 Sequence for Handover Based on BBB MIP [21] Protocol Step Initiated By Release old connectivity

MMRM

Setup new radio connectivity

MMRM

Create locator, request composition and security

HOLM

Update routing and forwarding state

HOLM

Table 2.3 Sequence for Handover Based on MBB MIP [21] Protocol Step Initiated By Setup new radio connectivity

MMRM

Create locator, request composition, and security

HOLM

Update routing and forwarding state Release old connectivity

HOLM MMRM

Table 2.4 Sequence for Handover Based on FMIP and a Locator Preparation via the Old Radio Link [21] Protocol Step Initiated By Create locator, request composition, and security

HOLM

Release old connectivity

MMRM

Setup new radio connectivity

MMRM

Update routing and forwarding state

Figure 2.26

HOLM

Interaction between entities during handover decision and execution [21].

1. Idle (nothing in progress; waiting for a trigger or request message (e.g., handover_request or handover_constraints_request);

2.2 Mobility Management

Figure 2.27

99

Flow state machine [21].

2. Processing_handover (in the process of assessing constraints; selecting a tool or executing a handover); 3. Waiting (e.g., for a handover_next_step message in order to proceed with the handover execution). If no handover_next_step message is received, then a timeout expires and a transition back to idle state occurs. It is assumed that the transport provides reliable in-order delivery of messages; therefore, no explicit acknowledgements are included in the message sequence. From the message exchange described above, the following two cases are to be considered: 1. Basic request-response transaction (e.g., where the receipt of the response completes the transaction. This can occur in a handover_request with a handover_complete or error response); 2. Extended transaction (e.g., where more than two messages are exchanged. This can happen if the handover_request is followed by a handover_incomplete response. At least two further messages finishing with handover_complete or error response are required to complete the transaction. Note that the first and last messages of the transaction correspond to the request and response of a basic transaction, but there are other messages exchanged in between).

100

Network and Mobility Management

2.2.4.3

Path Query SAP

A key part of the constraints assessment is to determine whether suitable paths exist across a particular access to support the flow that is being handed over. Figure 2.28 shows the signaling required for this procedure; in order to determine the path availability, the path selection entity initiates a path request to the capability routing FE, including the list of potential accesses provided by the MRRM, and the address of the destination. The capability routing FE then analyzes the paths using one of a set of possible path assessment techniques. A complete description of these techniques is available in [48]. 2.2.5 2.2.5.1

Evaluation of Mobility Management Schemes Multiaccess Implementation

Figure 2.29 shows the mapping of the multiaccess architecture in Figure 2.12 onto a set of software components. The three main entities are the MRRM, the GLLIM and the GLLAL. The GLL is divided into two different entities, to implement the abstraction mechanisms below the ARI interface. In the implementation described here, the MRRM was developed in Java [37]; one instance runs in the user terminal (MRRM-TE), while another one is running within the access element at the network edge (MRRM-NET). In addition, an access broker role could also be added into the scenario, because the MRRM implementation offers the required flexibility. In order to ease its operation, a Web-based application was added to the MRRM implementation. The interfaces between the multiaccess functional entities are based on the traditional socket architecture; in this sense, some of the entities are listening on well-known ports, which may be used by other entities for interaction. The protocols running on top of each of these interfaces is the MGI [38].

Figure 2.28 Signaling sequence between path selection and capability aware routing for requesting path characteristics as needed to constrain access paths [21].

2.2 Mobility Management

Figure 2.29

2.2.5.2

101

Multiaccess architecture implementation [37].

Performance Evaluation

Multiradio access selection (MRAS) [49] is about selecting, which radio access(es) that should be used for the access flows. The procedure of the overall access selection process consists of a sequence of distinct phases. Each one of the phases is associated to the execution of corresponding MRRM and GLL functions [37]. The MRAS process involves the following functions: MRRM advertisement and discovery, MRRM access selection and multiradio transmission diversity Implemented as a multiradio packet scheduler within the GLL. These phases are not necessarily passed in a unidirectional, linear way. After allocating a number of RAs to an access flow, more RAs can be discovered causing reallocation of the allocated set of RAs for that access flow. In a first evaluation case, a number of decision strategies are analyzed using both centralized and distributed approaches as well as assuming different levels of knowledge [21]. Distributed Access Selection Algorithm

The current practices to perform an access selection and handover decision are not likely to be sufficient in the future networking environment where multiple cooperative and/or competitive players like operators and service providers are present. The goal of providing “best connectivity” for end users in such diverse environment requires more sophisticated methods where end users’ needs and preferences as well as the network side business relationships are taken into account during the access evaluation and selection process. A distributed decision-making where both the terminal side and the network side contribute to the decision process is considered more beneficial in a future communications scenario [50]. Resource management decisions, such as handover decisions and PoA selection in the clients, are subject to be influenced by several entities colocated (i.e., inside the mobile terminal), as well as external entities, for example, the MRRM of a network operator. While any of those entities may have constraints and objectives on

102

Network and Mobility Management

the decisions, in the same time, they would not all share that specific information with each other. For example, the MRRM FE of the operator may not want to tell the clients the current load of its APs, which should influence its optimal PoA decision. The client may not want to tell the contractual details (e.g., price) to all operators in the vicinity, which the operator MRRM needs to know in order to make an optimal offer to the client. In this sense, the problem is of how to create a decision framework, where (1) the information must be kept partially distributed among the deciding participants (i.e., is incomplete), and (2) the communication cost varies (i.e., communication delay, errors, battery consumption). The particular target for the constraint-based handover decision is to maximize the network utilization and connectivity of the MNs. The actual handover decision logic in the described evaluation [49] only considers use of the MRRM and path selection function under the assumption that both the MRRM and the path selection can obtain relevant constraints originating from other FEs and can combine them with their own scope of constraints. It is also assumed that the constraints availability depends on the entity location and that, for example, the network side constraints are not available in the terminal and vice versa. Typically, constraints related to radio access are contained in the MRRM entity, while constraints related to network, IP level and above are contained in the path selection function. To execute the handover decision logic, the relevant location of the MRRM and path selection functions is of importance; these can be located in the terminal and the networks side [49]. Depending on the location, the available constraints vary and the scope of the handover decision is influenced, and the actual decision power can be exercised in either the terminal or at the network side. The handover triggers, such as thresholds and conditions can also be different depending on the location. During the evaluation, the MRRM and path selection handover decision algorithms compare several algorithm alternatives; the main groupings are the following: • •

MRRM versus path selection centric handover decision; Network versus terminal centric decision.

Simulation Model

In the simulation model, all constraints are classified according to two (independent) factors: 1. Based on constraint vector values—binary versus nonbinary; 2. Based on how the conditions of a constraint should be satisfied—hard constraint versus soft constraints. Based on such classification, the following three types of constraints can be defined: 1. Binary soft constraints; 2. Nonbinary hard constraints; 3. Nonbinary soft constraints.

2.2 Mobility Management

103

When constraints are applied, each constraint is represented by a vector, with the vector element count equal to the number of accesses to be evaluated. The vector type (binary vs. nonbinary) depends on the constraint type. Binary constraints are represented by binary vectors where the vector elements with the value of one indicate that a condition is satisfied and respectively zero values indicate that a condition is not satisfied. Nonbinary constraints are represented by nonbinary vectors where each element represents for example a measured condition like signal strength. Hard constraints are processed in the final access selection so that all accesses that are not satisfying a condition are discarded and only satisfying accesses are qualified. Respectively, the processing of soft constraints does not discard any accesses even if the conditions are not fully met. Instead, depending on how well a soft constraint is satisfied it has an effect on the priority order of accesses. In [50], the following constraints and corresponding constraint weights were used for simulation evaluation: •

Terminal Constraints:

1. Signal quality (70%)—prefers stronger signals (soft nonbinary constraint); 2. Same RAT (30%)—prefers access in the current RAT to minimize inter RAT handover(s) (soft binary constraint). •

Network Constraints:

1. Relative cell load (100%)—prefers accesses according to the load balancing; (i.e., lower loaded accesses are preferred over high loaded ones (soft nonbinary constraint); 2. Roaming agreement available. •

Legacy Algorithm:

1. Terminal constraint—signal quality (100%); 2. Network constraint—roaming agreement available. In the simulation model in Figure 2.30, there are three different abstractions used: (1) radio cells, (2) areas representing RATs consisting of a set of cells, and (3) mobile nodes (MNs) consisting of a set of movement vectors modeling their random movement paths.

(a)

(b)

(c)

(d)

Figure 2.30 Cell placement with (a) hotspot-1, (b) hotspot-2, (c) wide area-1 (GSM), and (d) wide area-2 (3G) [49].

104

Network and Mobility Management

The simulation models a single operator case with four different RATs; two wide area coverage RATs and two hotspot RATs. First, the wide area coverage RAT consists of four large cells placed arbitrarily in order to provide approximately 97% coverage of the simulation area. The other wide area coverage RAT consists of 119 smaller cells approximately of 70% coverage. The hotspot RATs both consists of 180 small radio cells resulting in approximately 16% coverage. The simulation area (5,000×5,000 units) corresponds to the area size of 5×5 km. The simulation duration is 500 seconds. When 10 measurements (simulation time units) are done in each second, it means that the mobile node’s maximum speed is 20 meters per second (72 kmph). For each algorithm, the simulation is run once with the same topology and mobility configurations. Figure 2.30 shows the location of the cells in the simulation area. The following assumptions were made [21]: The relative cell load is used and is measured based on the active mobile nodes in the cell. The maximum cell load defines how many MNs can have their radios associated with the cell at the same time. • Each MN generates the same load; an equal share of the RAT capacity divided by the number of attached MNs. The maximum load of each RAT is then defined by a maximum numbers of attached MNs. • The upper layer (L3+) constraints are simplified and modeled for the simulation purposes by two different constraints processed by the path selection in the terminal side (i.e., aggregated capability constraint (ACC)) and in the network side (i.e., user profile constraint(UPC)); both the ACC and the UPC are representatives for the sets of upper layer “technical” constraints such as the bandwidth, the QoS class, security, and cost. The ACC is defined for each MN in each measurement period (= simulation time unit; about 0.1 sec) and it represents how the upper layer constraints may vary. For example, the constraints derived from the user traffic requirements of a MN may vary from best effort (=3 and 4) to real time (=1 and 2) over the time. The UPC is also defined for each MN in each measurement period and it represents how the user’s subscription characteristic may be used in the network side to set the weights for the available RATs; (i.e., hotspot RATs have UPC value 1 and, respectively, wide area coverage RATs have UPC value 0. • The radio interference is not included and each radio cell has the same fading curve, based on which the MNs signal strengths are calculated. • Each MN has only one active RAT at the time. In the terminal centric algorithm model, the path selection and MRRM specific constraints are differentiated and the constraints execution order is as follows; terminal–network–terminal. First, the terminal uses the signal strengths in order to minimize the inter RAT handovers and the ACC value to construct its CS based on the DS. After this, the network checks each access in the CS to see if there is room for a new terminal, and if not, the access is removed from the CS and omitted in further constraint processing. Once the CS has been checked, the network applies the constraints based on the relative network load; (i.e., all cells are tried to load evenly whenever applicable. Finally, the terminal performs the final access selection by •

2.2 Mobility Management

105

reapplying its constraints without weighing to the new CS constructed by the network and the terminal has the possibility to override the network priorities. In the network-centric algorithm model, the path selection and the MRRM specific constraints are differentiated and the constraints execution order is terminal–network–terminal. The terminal uses the signal strengths in order to minimize the inter-RAT handovers and the ACC value to construct its CS based on the DS. After this, the network checks each access in the CS if there is room for a new terminal, and if not, the access is removed from the CS and omitted in the further constraint processing. Then the network applies the constraints based on the relative network load; (i.e., all cells are tried to load evenly whenever applicable. Both the access lists ordered according to the terminal’s and network’s preferences are considered and the network makes a combined weighted access list, thus the best weighted access will be selected and returned to the terminal, which then constructs its new AS. In the legacy algorithm model, only the MRRM specific constraints are considered and the terminal constructs its CS purely based on the signal measurements of each access in its DS. Then the network finds the access with the highest signal strength that has a room for a new MN. The constraints used by the two functions are summarized in Table 2.5. The statistics for inter- and intra-RAT handovers obtained with the simulation model described above are shown in Figures 2.31 and 2.32. It can be seen that the network-centric approach involves the highest amount of intra-RAT handovers with relatively high variation, whereas the legacy approach involves the least intra-RAT handovers with small variation. The situation is quite the opposite for inter-RAT handovers where the network-centric approach causes the least handovers and the legacy one the most. In both cases, the terminal-centric approach holds the middle position in terms of numbers of handovers. The significant differences in inter- and intra-RAT handovers can be explained by the big differences in the coverage characteristics between the RATs involved, thus the MNs easily move between RATs depending on mostly two factors: (1) RAT wide load balancing (network-centric) and (2) signal strengths (legacy). The network-centric approach involves the highest amount of handovers implying that the network load balancing causes additional handovers, but at the same

Table 2.5

Summary of Constraints for Access Selection [21]

Algorithm

Terminal Constraints

Network Constraints

Terminal centric

1. Signal strength (MRRM) 2. RAT; same vs. different compared to the current AS (MRRM)

1. Current relative load levels of related cells (MRRM) 2. UPC (Path Selection)

Network centric

1. Signal strength (MRRM) 2. RAT; same vs. different compared to the current AS (MRRM) 3. ACC value compared against cell/RAT capabilities (Path Selection)

1. Current relative load levels of related cells (MRRM) 2. UPC (Path Selection)

Legacy

1. Signal strength (MRRM)

1. Max load level of cells (MRRM)

106

Network and Mobility Management 2500

Number of HOs

2000

1500

Terminal Network Legacy

1000

500

0 Min

Mean

Max

Min

Inter RAT Figure 2.31

Mean

Max

Intra RAT

Intra- and inter-RAT HOs [21].

5000 4500

Number of measurements

4000 3500 3000

Terminal

2500

Network Legacy

2000 1500 1000 500 0 Connected

Figure 2.32

Disconnected

Longest Longest Connection Connected Disconnected Breaks

Average connection statistics [21].

time it tries to maximize network’s capability to serve the MNs as shown in Figure 2.32. In a single operator case where the networking conditions at upper layers (i.e., layer 3 and above) are fairly homogenous, the difference between the terminal and the network centric algorithms is not as significant as it could be in a more heteroge-

2.2 Mobility Management

107

neous environment involving multiple operators. The same applies to path selection and MRRM constraint execution ordering. General Access Evaluation Algorithm

A generic access evaluation algorithm is shown in Figure 2.33. The starting point of the access evaluation algorithm is the construction of a DS, which consist of all cells that the MN can hear in its current location. In other words, detected set embraces a number of accesses and the following general expression is a mathematical representation of the method, which is used to evaluate the rating of each cell in the detected set as the next target cell: N

M

i=0

i=0

A j = Γ ∑ γ i tc i + λ ∑ λ i nc i

(2.6)

In (2.6), Aj is the final evaluation (rating) value for cell j, Γ is the terminal-centric algorithm weight and Λ is the network-centric algorithm weight. The algorithm assumes that there are N different constraints for the terminal (tc) and M for the network (nc). Two remaining variables in the expression represents terminal constraint specific weights (γ) and network constraint specific weights ( ). As an outcome of the calculations in (2.6), each cell in the detected set has a comparable real value, which defines its rating as a new target cell. The final cell selection is done by choosing the cell from the candidate set having the highest rating. The mathematical model for the generic access evaluation algorithm is shown in Figure 2.34. An evaluation of the access selection algorithm shown in Figure 2.34 is done for cell selection and evaluation in [50]. It is assumed that the evaluated MNs current DS contains the following cells [31, 35, 65, 85]. Further, it is assumed that the MN is initially connected to the cell number 35. The simulation uses a specific cell load balancing threshold, which is set to 80%. This threshold is used to define the values for the relative cell load constraint. If the load of a cell is less than 80%, the constraint value for that cell is set to a constant value 1.2. If the load of the cell is 100%, the cell must be discarded in the cell evaluation. Otherwise, the value is the inverse of the relative load and the relative load is calculated in the following way: (current cell load + additional load) (maximum cell load)

Figure 2.33

General access selection logic [50].

108

Network and Mobility Management

Figure 2.34

Mathematical model of the generic access evaluation algorithm [50].

For the same RAT constraint, it is assumed that the cells 31 and 35 belong to the same RAT, whereas the remaining cells in the detected set belong to a separate RAT each. For the signal quality constraint vector, the calculated signal quality values that are assumed are [0,75 1.0 0.25 0.5] and for the relative cell load vector the calculated relative loads are [0.25 1.1 0.9 1.0], which means that cell 35 must be discarded in the evaluation. For the weights of the algorithm it is assumed that Γ = 3 and Λ_N = 1 (i.e., terminal-centric). According to these assumptions, the constraint vectors can be constructed according to the algorithm as follows: Initial terminal side constraint vector: Signal Quality [0.25 0 0.8 0.75] Same RAT: [1 0 0 0 ] Network side constraint vector: Relative Load: [1.2 0 1.2 1]

2.2 Mobility Management

109

Before constructing the terminal and network candidate sets, all constraint vectors are normalized and after that the constraint vectors assume the following values: Signal Quality: [0.3125 0 1 0.9375] Same RAT: [1 0 0 0] Relative Load: [1.0 0 1.0 0.833]

The next step in the evaluation is to multiply the constraint vectors with their respective weights, which results in the following values for the vectors: Signal Quality: [0.2188 0 0.7000 0.6563] Same RAT: [1 0 0 0] Relative Load: [1.0 0 1.0 0.833]

In order to construct the terminal (T_CS) and the network candidate sets (N_CS), the respective constraint vectors are summed, yielding the following results: T_CS: [1.2188 0 0.7 0.6563] N_CS: [1.0 0 1.0 0.833]

Before combining the candidate set to the final candidate set, the T_CS and N_CS are multiplied with the algorithm weights. T_CS: [3.6564 0 2.1000 0] N_CS: [2.0 0 1.7000 1.4893]

The multiplication vector sets are summed up and the evaluation part of the access selection algorithm is completed. In this example case the candidate set for the MN was CS: [5.6564 0 3.8001 1.4893]

It can be seen that cell 31 has the highest rating in the CS and therefore in the final selection phase, when the active set is formed for the MN, it is set as the value for the AS, namely, AS: [31]

In this example, the MN would make an intra-RAT handover from cell 35 to cell 31. Multioperator Environment

The simulations are performed here for the case of access selection based on distributed decision making in a multioperator environment.

110

Network and Mobility Management

In the simulation setup, the population of MNs is moving randomly in the area of one square kilometer and all MNs are actively and constantly requesting one of the defined traffic classes throughout the simulation period. In these simulations services and service providers are not modeled separately and, therefore, when the network can provide access to an MN, it also provides the service. This means that traffic classes have relevance only when the calculating cell loads. MNs gain their access via one of the access providers operating in the area. Operator-1 provides full wide-area radio coverage and short-range radio access in small a hotspot area, whereas operator-2 provides extensive but not full short/mid-range radio coverage. These accesses are defined as RAT-1, RAT-2, and RAT-3, respectively. The RAT configuration in the simulation environment consist of 94 cells, which are divided into three RATs in the following way as shown in Table 2.6. The reference technology for the wide-area radio is UMTS and WLAN was used for the short-range radio. Figure 2.35 shows the cell locations and the RAT coverage for both operators. The MNs movement paths and preferred application types for each time unit are stored into specific vector sets, which are randomized using a unified distribution during the first phase of the simulation. The movement vector set of the MN and the application vector set unambiguously define the path of the MN, speed, and requested application type for each time unit (i.e., the behavior of the MN is through the whole simulation. A movement vector is defined by three parameters: direction, speed, and duration, for which the following limiting values are used for the parameters:

Table 2.6

RAT Configurations [50] # cells

Type

Cell Radius

Cell Capacity

Operation

RAT-1

30

WLAN

80

6

1

RAT-2

4

3G

600

30

1

RAT-3

60

WLAN

120

6

2

1000 800

Meters

Meters

1000 800 600 400 200 0

600 400 200 0

0

Figure 2.35

500 Meters (a)

1000

Coverage areas for both operators [50].

0

200 400 500 800 1000 Meters (b)

2.2 Mobility Management

• • • •

111

Vector direction: −90…+90 degrees of previous vector direction; Mobile node speed: 0..20 meters/second (1sec = 10 time units); Movement vector duration: 10…600 time units; Application session length: 100…1,200 time units.

The sample movement vector sets for the group of MNs is shown in Figure 2.36. The simulation setup for the simulation runs for the measurement period = 1 (i.e., the mobile nodes (DOTs and STARs) are in their starting positions) is shown in Figure 2.37. The business setup for the simulation consists of a multiaccess operator-1, which is competing with a legacy operator-2 on the same area and with partly overlapping radio coverage. Mobile nodes can freely attach to any cells in the simulation area, but handovers between operator networks are not possible, due to the lack of horizontal agreement. This approach is useful when desiring to demonstrate the benefits of the network-centric and the terminal-centric strategies over the legacy one for the operator-1 multiaccess environment. On the other hand, the results show that for operator-2 the applied strategies do not provide benefit, because of the lack of cooperation between the two operators. The results of the simulations are shown separately for operators-1 and operator-2. Figure 2.38 shows the network utilization as a function of the number of MNs. For operator-1 the network-centric and the terminal-centric strategies provide better network utilization than the legacy one. For operator-2 the differences between the employed strategies are small. The differences between strategies throughout the simulations are exhibiting themselves the strongest when the number of MNs is within the range 300 to 700, which shows the benefits of employing the access selection strategies. The range

Figure 2.36

Movement paths of the MNs [50].

112

Network and Mobility Management

Figure 2.37

Simulation environment for measurement period = 1 [50].

Figure 2.38 tor-2[50].

Reference simulation network utilization results. Left: operator-1. Right: opera-

2.2 Mobility Management

113

[300, 700] corresponds approximately to the requested network load range [450 TU, 1100 TU], when unified distribution is used [50]. In addition, the respective range for the disconnected time units is from 5% to 30%. If the number of disconnected time units is approximated to correspond the number of disconnected MNs and is taken into account in the approximation, the requested load for the range [300, 700] is approximately [430 TU, 770 TU]. This means that the strategies are provide better network utilization for the operator-1 when the requested load in the network is within the range of 65% to 117%. The network utilization results also show that the load balancing function of the AN strategies in the multiaccess network plays a key role for the benefits. The differences appear beyond the used load balancing 40% utilization border. Figure 2.39 shows the network utilization for different access selection strategies, when the number of MNs in the system is 400. Figure 2.39 shows the exact values of utilization per time unit during the simulation run. Figures 2.38 and 2.39 suggest that the network utilization gains for the AN strategies in the operator-1 multiaccess environment can be as high as 10% and the average benefit is approximately 6% to 7%. Figure 2.39 shows that this trend is “permanent.” In the operator-2 network the average results show that the legacy strategy provides best utilization for each reference case. However, in contrast to operator-1 case Figure 2.39 shows that there is some variation. The reasons why the legacy strategy provides better utilization in the operator-2 network are related to the used simulation scenario, the used traffic model, the used cell resource model, and the behavior of the access selection strategies. In the operator-2 network there is only one RAT, which means that inter-RAT load balancing is not possible as it is in the operator-1 network. Also, in the operator-2 network resources are more evenly distributed to the simulation area and there are always several overlapping cells to be evaluated in the access selection. In such environment the AN strategies try to fill the cells evenly, if the load balancing threshold is exceeded. For example, if there are two overlapping cells, each having two TUs free resource, and there are two new MNs both requesting TC-1, the AN strategies would most likely put one MN to each cell (unless there is considerable difference in the signal qualities). This decision leaves one TU free resource to both

200

400

600

800 1000 1200

Time unit (a)

100 95 90 85 80 75 70 65 60 55 50 0

Utilization (%)

Terminal Network Legacy Optimal

Utilization (%)

100 95 90 85 80 75 70 65 60 55 500

Terminal Network Legacy Optimal

200

400

600

800 1000 1200

Time unit (b)

Figure 2.39 Operator specific network utilization for all the strategies, mn=400. Left: operator-1. Right: operator-2 [50].

114

Network and Mobility Management

cells. In contrast to that, the legacy strategy would put both MNs to the same cell, because the only constraint used in the evaluation is the signal quality and it is highly unlikely that the values for both cells would be the same, thus the legacy strategy leaves two TUs free in one cell. If the next new MN to be evaluated is requesting TC-2, in the AN strategy case neither of the cells have space for it, whereas the legacy strategy has free resources and capability to serve the third MN. In other words, the described example case enables the legacy strategy to perform better than the AN strategies. In an interoperator scenario, different access networks would cooperate with a certain level of information exchange. The distributed global RRM (e.g., MRRM) entities of the interoperator networks base their radio access selection decision on their own strategy [51]. The distributed MRRM entities of the networks exchange cell load information elements, which are defined by 3GPP [52]. Within each network and its MRRM entity, the physical cell parameters are mapped to the cell load values, which are then used by the MRRM radio access selection (MRAS) function. The cell load mapping can either be based on the average user data rate or based on the user satisfaction. The MRAS function can either be based on the total cell load value or on the nonreal time (NRT) cell load value. Thus for each network, there are four mapping + RA selection combinations and any type of the networks can be composed together. Figure 2.40 shows the average user data rate per user over different interoperator scenarios V1...V13, possible between a UMTS and GSM systems. The users move around according to a random walk model, and intra-, intersystem handovers as well as intersystem cell change orders (IS-CCO) are supported. Pure NRT traffic is used according to a Web-browsing model with a configurable maximum data rate. The offered traffic load is high and IS-CCOs are carried out instantaneously without any delay. The possible scenarios are summarized in Table 2.7. While most scenarios manage to provide all users with a good average data rate, the system becomes instable in the scenarios V4, V9, and V12, which is manifested as a strong decrease of the data rate in one or both of the air-interfaces. Mean data rate per completed PK call 100

kbps

80 60 40 20 total

GSM

UMTS

0 V1

Figure 2.40

V2

V3

V4 V5

V6

V7

V8 V9 V10 V11 V12 V13

Average user data rate over all combinations of interoperator scenarios V1..V13 [51].

2.2 Mobility Management Table 2.7

115

Interoperator Scenarios MRRM 1 (total MRRM 1 (total MRRM 2 (NRT MRRM 2 (NRT load) + Mapping 1 load) + Mapping 2 load) + Mapping 1 load) + Mapping 2 (data rate) (satisfaction) (data rate) (satisfaction)

GSM UMTS MRRM 1 (total load) + Mapping 1 (data rate)

V1

V1

V2

V4

MRRM 1 (total load) + Mapping 2 (satisfaction)

V1

V1

V3

V5

MRRM 2 (NRT load) + Mapping 1 (data rate)

V6

V7

V8

V9

MRRM 2 (NRT load) + Mapping 2 (satisfaction)

V10

V11

V12

V13

The number of IS-CCO initiated by the MRRM entities is shown in Figure 2.41. While in many scenarios, a low number of IS-CCO is sufficient to carry out the desired MRRM strategy, in some scenarios a very high IS-CCO rate is observed. The number of IS-CCOs is related to the intersystem signaling and processing costs. 2.2.6

Summary

Multiaccess is a key component of mobility management enabling the cooperation between heterogeneous access technologies to provide cost effective, affordable, wireless bandwidth practically everywhere. A mobility management architecture should provide an advanced joint management of radio resources including access

500 IS CCO rate 400 300 200 100 0 V1

Figure 2.41

V2

V3

V4

V5

V6

V7

V8

V9 V10 V11 V12 V13

Number of IS-CCO over all combinations of interoperator AN scenarios V1.V13 [51].

116

Network and Mobility Management

selection and load sharing between the different radio accesses, and an adaptation to the underlying RATs in support for intersystem handover. Mobility management architectures can be implemented at different levels of the communication systems and can benefit for a joint use of a centralized and distributed approach. Dynamically selecting the access for users in a multiaccess network provides a gain to both the user and the network. An access selection algorithm allocates user sessions to the available RATs in order to maximize the system capacity and/or user performance. The access selection gain can be provided as trunking gain or gain due to spatial transmission diversity. For sustaining scalability, evaluation algorithms and supporting architectures should be technology-independent; no (or minimal) changes should be required when introducing a new technology.

2.3

Location-Based Mobility Management One way to autonomously perform measurements in the destination network to collect required for handover decisions data is by the terminal itself. If this procedure shall take place during an ongoing connection, two transceivers are required, which enhances the complexity of the UT. If no ongoing connection is active, the UT may switch to another network in order to derive the respective measurements at arbitrary times. Nevertheless, to prevent the UT from being paged from its current system, while scanning another one, the respective signaling indicating some kind of sleeping and temporary nonavailability is necessary. If the UT demands for up to date information on other networks in order to guarantee the best QoS, the aforementioned signaling/scanning procedure needs to be repeated on a regular basis resulting in transfer overhead that does not even pay off if the conditions in the possible destination network are too bad and thus no handover takes place. Another way for gathering information about a target cell is to adopt foreign-party-based measurements [16, 17]. The idea is that a nearby located UT of the other system makes a status report and transfers this report by a gateway to the currently employed network. Hence, an overview of the conditions of possible destination systems is provided without the need for leaving the current system. Even if the existence of other systems is announced in the broadcast channel, the question remains, which link conditions the UT can expect if it really changes to the announced system. Thus, information about other systems as well as their link conditions needs to be provided. Especially for the vertical handover (VHO)-case this means a remarkable gain. It must be noted that it is not explicitly proposed to include vertical system information in current broadcast transmissions. It is proposed to employ measurements taken by other parties. The interesting aspect concerning the gathering of those measurement reports is that they do not need to be rendered explicitly. The idea is to exploit available information, (e.g., signaling information with the original purpose to adjust power control mechanisms or link adaptation). The challenging task is how to process, recycle, and supply the information. Figure 2.42 shows the information exchange during a location-based handover.

2.3 Location-Based Mobility Management

Figure 2.42

117

Information exchange during handover with help of the HIS [17].

Each active UT reports about the current link condition; see (1) in Figure 2.42. Together with the measurement report, the location of the reporting UT is stored in a database (DB) (2). A UT that intends to perform an intersystem handover sends a request to its BS, see (3). The BS acquires the corresponding measurement report from the DB, depending on the current location of the UT, (4), and signals the HO decision (respectively related information that allows the UT to take the decision) to the UT (5). The UT can then perform the handover, which is marked by step (6). This basic approach is referred to as the HIS (see Section 2.1.2.1). Measurements that are inherently available for each system are made available to support the interworking between the heterogeneous systems. Depending on the new target system and the current location of the mobile, the mobile is supplied with state reports of the same system type (for horizontal handover, HHO) or a VHO, and subsequently may perform the (V)HO, which is referred to as location-based VHO since the location of the mobile is exploited in the HO process. The HIS is both, an intelligent concept facilitating intersystem cooperation and a means to allow for context transfer between different systems. The HIS can perform accurate detection of complementary systems and initiate optimal VHO execution by respective triggering. In all cases, the HIS approach offers a great economic potential since participating devices can minimize or even avoid selfdriven scanning. The HIS entails a decision unit that takes into account trigger origins as input and produces handover recommendations (i.e., handover triggers) as output. The advantage is that the HIS is not restricted to local and system specific trigger origins. Besides incorporation of a multiple number of systems, HIS supports load balancing and joint RRM. Further, due to its backbone connection, specific user preferences may be requested (e.g., from the home network provider) and incorporated in any decision process. Thus, the HIS supports intelligent intersystem-control by combined evaluation of various trigger origins. As the location is a key parameter in the location-based VHO the degree of precision and accuracy that can be achieved is a key attribute. The less accurate and precise the location information is, the larger the difference between the anticipated,

118

Network and Mobility Management

(i.e., retrieved) measurement report, and the real link condition in the target system after the handover. 2.3.1 2.3.1.1

Elements of the HIS HIS Internal Data Administration

Central elements of the HIS are the intelligent service control (ISC) unit and an affiliated DB. The task of the ISC is to administer incoming data from the feeding clients and to respond adequately to information requests from the information clients. Depending on the purpose for which data shall be used, the ISC may also perform respective filtering and averaging—this applies to both time and space domain. To allow for a reliable and smooth operation of the HIS, incoming data from the feeding clients needs to be administered and stored. For this, a set of DB servers is associated to the ISC in the HIS. Their task is the reliable and fast storage and access to dedicated system information. Basic entries in the DB comprise a compound of measurement reports, positioning data, and time stamp. In this way an internal representation of the link/interference condition within each associated radio system, a so-called link map is achieved. With the reception of new measurement reports, an update of the link map is triggered. The link map has a different set up at respective points of time (t1, t2, t3, t4, …, tn) as it was shown in Figure 2.42, resembling slices. The minimal thickness of those slices is directly related to the interarrival times of the measurement reports of the feeding clients. Thicker slices result from quantization of measurement reports whereby a diversified weighing of probes within one quantization interval by the ISC is possible. Besides a time-concerned description of the DB maintained data, the granularity of the slices corresponds to the spatial resolution with which the HIS may provide interference information. The spatial resolution is directly related to the penetration and position of feeding clients within a given system. The thickness of the slices may be administered with different internal data structures as shown in Figure 2.43.

Figure 2.43

Possible storage of measurement reports inside the HIS [17].

2.3 Location-Based Mobility Management

119

Both types of measurement reports are quantized both in time and space domain (left side, Approach A) before storage or the DB entries contain raw data (right side, Approach B), meaning that a dedicated entry is written for each incoming report. Realization of the latter approach can be done as double-linked list with the time index as sorting criteria. Both approaches feature different properties. While approach A probably means less administration overhead and faster data access, the inherently introduced quantization entails respective errors (local and time fuzziness). An implementation with approach B is favored, which means evaluation is done by filtering data on information requests, which is also favorable when assuming that the number of requests is low compared to the number of entries (i.e., arriving measurement reports). Regardless of which approach is chosen, one has to be aware of the fact that entries in the database undergo an aging process due to changing link conditions in the field. This means that certain entries (e.g., positions) in the DB are almost up-to-date, while other link states positions are only documented based on old measurement reports or no entry at all is even written (since no active mobile has provided measurement reports before). If the HIS gets requests for these positions, the ISC has to apply dedicated averaging algorithms considering time and space domain. Besides basic DB entries, further parameters could be added. Extended entries consist of terminal-related properties such as velocity, moving direction, current service consumption, and others. In this way, the extended entries support personalized service provision. By evaluation of that data it is possible to set up user profiles. Additionally, it will be possible to predict user requirements. If for example a user moves with high speed along a road, it is very unlikely that he will spontaneously turn left or right. In this case, an enhanced RRM mechanism could exploit the HIS information to prepare a planned handover to another serving BS or RAN. Due to the interference maps, the current link condition in the future target system is well known, and it can be decided whether extra bandwidth needs to be reserved for the shortly to handover terminal. Moreover, if the geographic target is covered by several vertical systems, the HIS may even trigger intersystem support for the terminal and support joint RRM in this way. 2.3.1.2

Short-, Mid-, and Long-Term Data

An interesting point with respect to usability of the information stored by HIS is the use case, for which respective data shall be applied to. It does not make much sense if a mobile that wants to handover to another system is provided with interference information being totally out-of–date. On the other hand, if system engineers want to get more information on areas with low coverage, they are not interested in present fading analyses. The concept of HIS accommodates both needs by distinguishing between short-term, mid-term, and long-term data, (see Figure 2.43). Short-term data is meant to support real-time requests from the information clients. As soon as a feeding client provides new measurement reports, the essence is extracted and stored in the HIS DB. Short-term data then reflects the latest entries in the data base. Respective information is used to serve as decision basis for short-dated handover triggers. Mid-term data instead is less time critical. It is based on short-term input but due to respective filtering and averaging time-selective fad-

120

Network and Mobility Management

ing effects are equalized. Nonetheless, mid-term data is of interest for ongoing communication since it serves as a set value especially for predictable actions. Especially, in combination with prediction and profiling, mid-term data is useful for planned handover triggering, (joint) RRM or connection admission control (CAC). Finally, the HIS distinguishes long-term data addressing either permanent impacts, (e.g., to determine areas with ongoing insufficient link quality), or recurrent events such as the analysis support of daily occurring networking congestions during, for example, rush hours. Such long-term data comprises more or less static information. Effects like cell breathing or sudden interference are eliminated, too. The period for long-term data is supposed to be longer than one day. Table 2.8 summarizes the basic properties of short-, mid- and long-term data. With this classification, the different sets of data can be applied to different algorithms using the information from the HIS as input to their calculations. To increase the coverage or adapt to different loads in a system, an algorithm that dynamically adjusts the down-tilt of the BS antennae may be employed [53]. This algorithm can use the mid-term or long-term data as input to its calculations. To support algorithms such as handover, link adaptation, or power control, short-term or mid-term would be used. 2.3.2

Intrasystem Handover Assisted by HIS

Handover algorithms for the cooperation between different modes of the same communication system were proposed and investigated within the scope of the FP6 IST project WINNER [3]. The higher layer triggers are expected to be activated either by BS calculations on the cell status or by information sent by the monitoring entities [54]. A handover process can be triggered by periodic measurements and by a higher layer trigger (e.g., cell load), then the UT requests to the network elements information on the possible cells of the same mode or different modes, or different RANs. Depending on the type of handover; intramode, intermode, or intersystem, this information will be provided by a specific entity: the BSs, GW/SRRM, or CoopRRM (see Section 2.1.2). In particular, intermode decision will be advised by the following entities serving different areas within the RAN: Table 2.8

Short-, Mid- and Long-Term Data as Basis for RRM Decisions

Short-Term Data Basically, newly achieved information on the current status within the cell Mid-Term Data

Long-Term Data

Support of ongoing handover

Cell breathing -> excluded

execution Decision basis for time critical handover “Short” life cycle Fading, shadowing, and other propagation effects included High variance over time

Based on short-term data Averaged/extracted from short-term data Quasi-static character since short-term fading -> excluded Cell breathing -> still included Shadowing included

Based on mid-term Period: >= 1 day Periodicity given? (e.g. egular football matches) Used f. network optimzation Coverage Detection of shadowed reas

2.3 Location-Based Mobility Management

• •

121

BSWA/BSMA will be deciding the handover between a LA and WA/MA; GW/SRRM will be deciding the handover between WA and MA.

If following a self-organized and partially distributed approach, the intramode handover decision could be taken by the BSs /UTs of the same mode, in a similar way to the current 802.11 standards, (i.e., without a central entity). The BSs, of the same mode in the same deployment zone, could use a protocol to exchange control messages between them, in a similar way that the 802.11 APs use the Interaccess Point Protocol (IAPP), to give a continuous coverage in support of terminal mobility. Intramode handover is the handover between radio access points (BSs and relay nodes in a multihop communication system) operating in the same mode, there are three possibilities: intra-BSs, intra-RNs, and between RN and BSs of the same mode. This type of handover includes the intracell handover where the user remains in the same mode (e.g., the change of frequency in the same cell) and the intercell handover between cells of the same mode. The basic trigger for intercell handover is the received signal strength (RSS), but also the load of the neighbor cells, congestion situations, increased interference, the location of the user, and so forth. The intramode handover (between RNs and/or BSs), for example, could be triggered when the RSS is below a fixed specified minimum value. Based on location-related measurement reports, the HIS calculates cell borders, and signals a UT to handover as soon as the target cell is reached. UTs that are located near the cell borders and that do not move too fast can be identified easily by the HIS. These UTs may in principle be used by other UTs currently outside the cell coverage to enable communication to the other modes (WMs). The HIS informs the UTs that are leaving the cell about a possible topology within their vicinity to establish communication with that attachment point. In that way measurement reports for areas outside the cell coverage may be gathered. These reports may then be used to determine the link quality outside the cell coverage to recommend the modes and hence the possible attachment points to the arriving UTs. It should be noted that link quality measurements lose much of their relevance with varying position information. To solve this problem in general, each measurement needs to be associated not only with the position of the UT but also with the current position of different attachment points including fixed and mobile relays. To overcome increase in data complexity, probabilistic statements based on measurements and basic assumptions for the signal range of currently available points can be considered. Combination of several input parameters for trigger generation might be needed. The following are examples for how to find the optimal handover points between RNs and BSs in a next generation multihop communication system [3]: •

Frame measurement report. Frame measurements can be used to easily gather received power histograms (RPIs) for different source stations. Thereby, measurements are only made during frame transmissions and are each associated with the MAC address of the frame source. This is especially useful to perform measurements for a multiple stations simultaneously. If relay and access point

122

Network and Mobility Management

•

•

•

operate on the same channel, both signal strengths can be measured simultaneously. Channel load report. This measurement both takes into account the physical carrier-sense mechanisms (clear channel assessment—CCA [55]), as well as the virtual carrier-sense mechanisms (e.g., network allocation vector (NAV) [56]), to determine the current channel utilization. This is especially useful to estimate the available system capacity. Medium sensing time report. The channel load report gives information on the current channel use. The medium sensing time report gives more detailed information by not only indicating a percentage of the used channel but reporting a histogram of sensing times, which allows for a more sophisticated view on the channel status and thus for an estimation on the expected packet delay [57]. STA statistics report. This measurement can be used to query different counters within the UT, such as retry, multiple retry, and failed counters. This allows for information gathering that does not only account for the physical layer but incorporates the link layer as well.

It is possible to perform position-based handover decisions using the center of gravity (CoG) algorithm [58]. The CoG algorithm was designed to compensate effects of “misleading” measurements introduced to the database by erroneous positions. Thereby misleading are the measurements that actually have been recorded inside the cell coverage. Due to positioning errors, associated coordinates reported along with the measurements indicate positions outside the actual coverage area. “Correct” measurements suffer from the same positioning error but the reported position effectively is inside the cell coverage area. The CoG algorithm exploits the fact that the density of misleading measurements is lower than the density of correct measurements. When a UT is approaching the cell boarder, the algorithm calculates the distance from the terminal to the CoG. The CoG algorithm not only gives a scalar distance, but returns a vector towards the center of gravity. This allows for estimation whether the UT is moving towards the cell center or whether it is just passing by. Accordingly, it may be applied in the context of ping-pong handover avoidance [59]. Incorporating more information sources into the handover decision will further optimize the resource utilization. This means that more measurements from the attached communication system will be incorporated and that in addition to these estimations of the current network state, the user profiles, the current QoS demands, and the operator policies need to be taken into account, too. Systematic combination of both physical measurements and the guidelines that are defined in the operator policies can be successfully handled by a well-defined framework. In cellular network based positioning the localization process is generally based on measurements in terms of time of arrival (ToA), time difference of arrival (TDoA), angle of arrival (AoA), and/or RSS, processed by the network or UT [60]. Another solution is based on the Global Navigation Satellite Systems (GNSSs) [61]. UT localization using GNSSs, such as the Global Positioning System (GPS) or the future European Satellite Navigation System GALILEO [62] deliver very accu-

2.3 Location-Based Mobility Management

123

rate position information for good environmental conditions, (i.e., for direct line of sight (LoS) access to several satellites the achievable accuracy can be very high (e.g., WA)). Nevertheless, the performance loss in metropolitan area or local area scenarios can be dramatic if the limiting factors (multipath, non-LoS) occur. For indoor scenarios usually no GNSS-based positioning is possible due to the weak satellite signals. The additional receiver hardware leads to higher power consumption. For a general solution a hybrid approach is suitable depending on the UT position and the environmental conditions [54]. Usually, as much as possible, available information sources should be used for positioning. In wide area scenarios where good LoS access to the satellites is possible, a GNSS-based solution is the best choice with supporting information and measurements from the next generation RAN. In local area or indoor scenarios, where no satellite signals are available, a pure RAN-based location determination is necessary. In metropolitan area, it could be a RAN-based solution where, if available, the GNSSs signals are used to improve the positioning of the UT. The limiting factors in these scenarios are determined by non-LoS and multipath effects [54]. A general overview of the location determination use in support of mobility management for next generation systems and that was proposed for support of the WINNER system concept is shown in Figure 2.44. The quality of GNSS positioning depends on the number of visible satellites that can be accessed LOS and the geometric constellation [64]. Furthermore, similar to cellular-based positioning, multipath is a performance decreasing effect. For standalone GNSS positioning at least four satellites have to be visible. In [64] the satellite constellations were simulated for 10 days (maximum period) with time steps of 15

Figure 2.44

Location determination architecture [54].

124

Network and Mobility Management

minutes resulting in 960 different satellite constellations for each simulation. The position on the Earth was fixed to 48 degree latitude and 11 degree longitude. Figure 2.45 shows the cumulative density function (CDF) for the number of visible satellites for all time steps without any blocking buildings. The minimum number of visible satellites is 6 for GPS and Galileo, and 13 for combined GNSS (GPS+Galileo). The maximum number of satellites is 10 for GPS, 11 for Galileo, and 20 for GNSS. Figure 2.46 shows the underlying probability density functions (PDF). The results for visible satellites in an urban canyon scenario with different orientations of the canyon are shown in Figure 2.47. Figure 2.47 shows a snapshot of one constellation (i.e., skyplot) where the position of the satellites is plotted in terms of azimuth and elevation. Also, plotted is a blocking urban canyon using an orientation of alpha = 0 degree with respect to the North–South axis. Satellites within the green “eye” shape have LOS to the UT, whereas satellites outside it have NLOS to the UT and cannot be used for positioning with a good performance. The width of the street in this example is W = 10m, the heights of the buildings are H = 10m, and the user is in the middle of the street at a height of 1.5m. Figure 2.48 shows the resulting CDF averaged over several satellite constellations (see above) for this scenario with different orientations of the urban canyon. We see that the worst case is given for an urban canyon orientation of alpha = 0 degree, where it can happen that only two satellites can be seen LOS. The best case is given for alpha = 90 degree. Figure 2.49 shows the CDF results when the heights of the buildings increase for a street width of W = 20 m..

Figure 2.45

CDF for number of visible satellites, free space [64].

2.3 Location-Based Mobility Management

Figure 2.46

125

PDF for number of visible satellites, free space [64].

Figure 2.47 Satellite constellation with blocking urban canyon, W = 10m, H = 10m, UT in middle of the street at height of 1.5m [64].

For example, at H = 30m, only in about 30% of the cases more than the required four satellites are visible for positioning. Then an adequate positioning based on stand-alone GNSS is no longer possible and support from additional measurements performed with a cellular network is necessary. In even more critical situ-

126

Network and Mobility Management

Figure 2.48 CDF for number of visible satellites, urban canyon, W = 10m, H = 10m, UT in middle of the street at height of 1.5m [64].

Figure 2.49 CDF for number of visible satellites, urban canyon, W = 20m, alpha=0 degree, UT in middle of the street at height of 1.5m [64].

ations (e.g., indoor) usually no satellites are visible LOS and a high effort is needed just for the acquisition of the satellites In the following, the navigation equation is solved by a Gauss-Newton (GN) algorithm [65] for each satellite constellation time-step, where in each time-step several realizations of standard error models are simulated.

2.3 Location-Based Mobility Management

Figure 2.50

127

CDF for RMSE, free space [64].

Figure 2.51 CDF for RMSE, urban canyon, W = 10m, H = 10m, UT in middle of the street at height of 1.5m [64].

Figure 2.50 shows that for GNSS positioning in 90% of the cases the root mean square (RMSE) is below 9m for the free space situation. Figure 2.51 shows the RMSE performance in an urban canyon with W = 10m, H = 10m, the UT in the middle of the street at height of 1.5m that was simulated for

128

Network and Mobility Management

the worst case (alpha=0 degree) and best case (alpha=90 degree) canyon orientation. These simulations can also be related to the emergency call requirements. The system combines GNSS measurements with two TDOA measurements taken from simulations with the WINNER channel model in the base coverage metropolitan area scenario. All measurements are integrated in the extended Kalman filter (EKF) tracking algorithm [67] where a pedestrian user is assumed. For optimum GNSS conditions (free space), the 90% error is below 7.5m and it can be seen that the performance gain by additional TDOA measurements is small when enough satellites, (i.e., at least four), are available for LoS. However, for only three or two satellites the performance can be increased and the lack of satellites can be compensated by the TDOA measurements. In 90% of the cases the error can be reduced from below 80m to below 60m if only three satellites are available, for two visible satellites the performance gain by additional TDOA measurements is even higher. Emergency calls, intersystem handover, and radio resource management as system-side applications can benefit from use of the available location information. Use of positioning information to manage radio resources is attractive but also a sensitive new field. The fact is that exploitation of location information requires new regulative actions, legislation, and self-commitments. Supervision to avoid possible illegal and unethical use of personal information is also imperative.

2.4 Conclusions This chapter investigated the fundamental benefits of a novel approaches to network and mobility management to ensure the interworking between next generation systems and legacy systems, as well as the interworking within the next generation system in support of user mobility and QoS. A qualified basic RRM concept was presented that includes the latest advancements in the area of radio access technologies. An appropriate system/RAT selection that guarantees QoS to users as well as efficient network management should employ a supporting management architecture and should be based both on a centralized and distributed approach.. Mechanisms should be based on a set of selection criteria. The load, the mean user throughput, the distance to the BS, the signal strength, and the type of services are the main selection criteria for executing an access selection or an RRM mechanism. A combined centralized and distributed approach to network and mobility management provides scalability and flexibility of the framework. The mechanisms operate at various levels of the systems, from L2 to L3 and above depending on the scenario requirements. This is an optimal approach for next generation radio access systems, which would be foreseen of a distributed and flat RAN architecture. Intersystem interworking requires a centralized approach. It was proposed that the control as a principle is performed by an entity located outside the RANs to maintain the generic character of the proposed RRM framework and to maintain the original RAN architecture of the legacy systems. Intersystem interworking relies on cooperative RRM. New systems can benefit by the combined distributed/central-

2.4 Conclusions

129

ized RRM approach, which allows that the cooperative RRM functions are implemented at lower layers and closer to the air interface.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

[15]

[16]

[17] [18] [19] [20] [21] [22]

[23] [24] [25] [26]

FP6 IST Projects, Cluster of Beyond 3G Architectures, at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. FP6 IST Project Ambient Networks (AN), at www.ambient-networks.org. FP6 IST Project WINNER and WINNER II, at www.ist-winner.org. FP6 IST Project EVEREST, at http://www.everest-ist.upc.es/. FP6 IST Project AROMA, at http://www.aroma-ist.upc.edu/. FP6 IST project PHOENIX, at http://www.ist-phoenix.org/. FP6 IST Project ENABLE at http://www.ist-enable.org/. FP6 IST project CAPANINA, at http://www.capanina.org. FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. Mihovska, A., et al., “QoS Management in Heterogeneous Environments,” Proceedings of ISWS’05, Aalborg, Denmark, September 2005. Mino, E., et al., “Scalable and Hybrid Radio Resource Management for Future Wireless Networks,” in Proceedings of IST Mobile Summit 07, ,Budapest, Hungary July 2007. FP6 IST Project WINNER, Deliverable 4.1, “Identification and Definition of Cooperation Schemes,” February 2004 at www.ist-winner.org. FP6 IST Project Ambient Networks (AN), “Ambient Networks Project, Description and Dissemination Plan,” July 2001, at www.ambient-networks.org. Mihovska, A., et al., “Requirements and Algorithms for Cooperation of Heterogeneous Networks,” in Springer International Journal on Wireless Personal Communications, DOI: 10.1007/s11277-008-9586-y, September 2008. Sdralia, V., et al., “Cooperation of Radio Access Networks: The IST FP6 WINNER Project Approach,” in Proceedings of Wireless World Research Forum (WWRF), 11th meeting, Oslo, Norway, June 2004. Lott, M., et al., “Cooperation Mechanisms for Efficient Resource Management Between 4G and Legacy RANs,” in Proceedings of Wireless World Research Forum (WWRF), 13th meeting, Seoul, Korea, March 2005. FP6 IST Project WINNER, Deliverable 4.3, “Identification, Definition, and Assessment of Cooperation Schemes between RANs,” June 2005, at www.-ist.org. Schieder, A., et al., “Mobility Management and Radio Resource Management in the WWI System Architecture,” in Proceedings of WWRF 17, November 2006, Heidelberg. World Wireless Initiative, (WWI), http://www.wireless-world-initiative.org/. FP6 IST project MOBILIFE, at www.ist-mobilife.org. FP6 IST Project Ambient Networks, Deliverable D9.B1, “Mobility Support: Design and Specification,” December 2006, at www.ambient-networks.org. Giaffreda, R., et al., “An Information Service Infrastructure for Ambient Networks”, in Proceedings of the 25th IASTED International Conference on Parallel and Distributed Computing and Networks (PDCN 2007), February 2007, Innsbruck, Austria. Perkins, C., “IP Mobility Support for IPv4,” IETF RFC 3344, August 2002. Keszei, C., et al.,“Evaluation of the BRAIN Candidate Mobility Management Protocol,” in Proceedings of the IST Mobile Summit 2001, September 2001, Barcelona, Spain. Kempf, J., “Goals for Network-based Localized Mobility Management (NETLMM),” IETF, October, 2006. International Engineering Task Force, at http://www.ietf.org/.

130

Network and Mobility Management [27] Henderson, T., “End-Host Mobility and Multihoming with the Host Identity Protocol,” draft-ietf-hip-mm-04.txt, June 2006, at http://www.ietf.org/. [28] Devarapalli, V., et al.,“Network Mobility (NEMO) Basic Support Protocol,” RFC 3963, IETF, January 2005. [29] REcommendation ITU-R M.1645, “Framework and Overall Objectives of the Future Development of IMT 2000 and Systems Beyond IMT 2000,” at www.itu.int. [30] FP6 IST Project WINNER II, Deliverable 4.8.3, “Integration of Cooperation in WINNER II System Concept,” November 2007, at www.ist-winner.org. [31] International Telecommunications Union, ITU, at www.itu. int. [32] Long Term Evolution (LTE), at www.3gpp.org/Highlights/LTE/LTE.htm. [33] FP6 IST project WINNER II, Deliverable 6.3.14, “ WINNER II System Concept Description,” November 2007, at www.ist-winner.org. [34] Mihovska, A., et al., “Policy-Based Mobility Management for Next generation Systems,” Proc. of IST Mobile Summit 2007, July 2007, Budapest, Hungary. [35] FP6 IST Project WINNER II, Deliverable 4.8.2, “Cooperation Schemes Validation,” June 2007, at www.ist-winner.org. [36] Tragos, E., et al., “Hybrid RRM Architecture for Future Wireless Networks,” in Proceedings of IEEE PIMRC’07, September 2007, Athens, Greece. [37] FP6 IST Project Ambient Networks, Deliverable D2-C1, “Multi-Access and ARI Design and Initial Specification,” November 2006, www.ambient-networks.org. [38] FP6 IST Project Ambient Networks, Deliverable D7-A.2, “Ambient Networks System Description,” December 2006, at www.ambient-networks.org. [39] FP6 IST Project WINNER, Deliverable 1.4, “Final Requirements per Scenario,” November 2005, at www.ist-winner.org. [40] Lightweight User Datagram Protocol (UDP-Lite) at www.ietf.org/rfc/rfc3828.txt. [41] Sachs, J., and B. Dilbaz, “Radio Resource Efficient Transmission Scheme for Error Tolerant Applications,” in Proceedings of the 13th European Wireless Conference (EW 2007), April 2007, Paris, France. [42] FP6 IST Project Ambient Networks, Deliverable D7-2, “Ambient Network Security Architecture,” December 2005, www.ambient-networks.org. [43] FP6 IST Project Ambient Networks, Deliverable D-H.1, “Final Application Scenarios and Prototype Design,” January 2007, at www.ambient-networks.org. [44] IEEE 802.11u at www.ieee802.org/11/Reports/tgu_update.htm. [45] Pandolfi, A., et al., “Optimizing Simultaneous Interface Usage in a Converged Multimode Terminal,” in Proceedings of the IST Mobile and Wireless Communication Summit, June 2005, Dresden, Germany. [46] Manner, J. (ed.), “Mobility Related Terminology,” RFC 3753, June 2004 at www.ietf.org. [47] Koodli, R., “Fast Handovers for Mobile IPv6,” RFC 4068, IETF, July 2005, at www.ietf.org. [48] FP6 IST Project Ambient Networks, Deliverable D11-E.1, “Basic Functionality and Prototype,” December 2006, at www.ambient-networks.org. [49] FP6 IST Project Ambient Networks, Deliverable D2-4, “Multi Radio Access Architecture,” December 2005, at www.ambient-networks.org. [50] FP6 IST Project Ambient Networks, Deliverable D2.0-B2, “Annex to Mobility Support: System Specification, Implementation, and Evaluation,” December 2007, www.ambient-networks.org. [51] FP6 IST Ambient Networks, Deliverable D21-C.3, “Multi-Access Evaluation and Assessment,” December 2007, at www.ambient-networks.org. [52] 3GPP Specification, TS 25.413, “RANAP over Iu Interface,” at www.3gpp.org. [53] http://www.terabeam.com/support/calculations/antenna-downtilt.php.

2.4 Conclusions

131

[54] FP6 IST Project WINNER II, Deliverable 4.8.1, “WINNER II Intramode and Intermode Cooperation Schemes Definition,” June 2006, at www.ist-winner.org. [55] Ramachandran, I., and S., Roy, “On the Impact of Clear Channel Assessment on the MAC Performance,” in Proceedings of GLOBECOM, San Francisco, California, November 2006. [56] Liu, H.-H., Wu, J.-L., C., and W.-Y., Chen, “New Frame-Based Network Allocation Vector for 802.11b Multirate WLANs,” IEE Communications, Vol. 149, No. 3, June 2002. [57] Kowalski, J., US Patent 20060046688, “Medium Sensing Histogram for WLAN Resource Reporting,” February 2006. [58] Landi, G., “Properties of the Centre of Gravity Algorithm,” in Proceedings of Como Communications, October 2003. [59] Kim, W.-I., et al., “Ping-Pong Avoidance Algorithm for Vertical Handover in Wireless Overlay Networks,” IEEE Communication Magazine 2007, pp. 1509–1512. [60] Gustafsson, F., and F. Gunnarsson, “Mobile Positioning Using Wireless Networks,” IEEE Signal Processing Magazine, Vol. 22, No. 4, July 2005. [61] Parkinson, B., W., and J. J. Spilker, Jr., “Global Positioning System: Theory and Applications, Volume 1,” Progress in Astronautics and Aeronautics, Vol. 163, 1996. [62] European Satellite Navigation System GALILEO at http://ec.europa.eu/dgs/energy_transport/galileo/index_en.htm. [63] IST Project WINNER, Deliverable 6.13.7, “WINNER Test Scenarios and Calibration Case Issues,” December 2006 at www.ist-winner.org. [64] IST Project WINNER, Deliverable 4.8.2, “Cooperation Schemes Validation,” September 2007, at www.ist-winner.org. [65] Foy, W., “Position-Location Solutions by Taylor-Series Estimation,” IEEE Transactions on Aerospace and Electronic Systems, Vol. 12, pp. 187–193, March 1976. [66] Minn, H., V. K. Bhargava, and K. B. Letaief, “A Robust Timing and Frequency Synchronization for OFDM Systems,” IEEE Transactions on Wireless Communications, Vol. 2, No. 4, July 2003. [67] Zaidi, Z., R., and B. L. Mark, “Real-Time Mobility Tracking Algorithms for Cellular Networks Based on Kalman Filtering,” IEEE Transactions on Mobile Computing, Vol. 4, Issue 2, March–April 2005, pp.195–208. [68] Long Term Evolution, http://www.3gpp.org/Highlights/LTE/LTE.htm. [69] WiMAX Forum, at http://www.wimaxforum.org. [70] IEEE 802.16e available at:// www.ieee802.org/16/tge/. [71] UTRAN Radio Interface Protocol Architecture, Release 5, TS 25.301, V 5.2.0, www.3gpp.org, September 2002. [72] ETSI TR 101 957, “Broadband Radio Access Networks (BRAN); HIPERLAN Type2; Requirements and Architectures for Interworking between HIPERLAN/2 and 3rd Generation Cellular Systems,” V1.1.1 (2001–08). [73] 3GPP TR 22.934, V1.0.0 Feasibility Study on 3GPP system to Wireless Local Area Network (WLAN) Interworking Rel-6. [74] Ojanpera, T., and R. Prasad, Wideband CDMA for Third Generation Mobile Communications: Universal Personal Communications, Norwood, MA: Artech House, 1998. [75] WLAN at http://en.wikipedia.org/wiki/Wireless_LAN. [76] FP6 IST Project My Personal Adaptive Global Net (MAGNET) and MAGNET Beyond, at www.ist-magnet.org. [77] FP6 IST Project MAGNET, Deliverable “D3.2.2a Candidate Air Interfaces and Enhancements,” October 2004, at www.ist-magnet.org. [78] FP6 IST Project Wireless Interface New Radio, WINNER and WINNER II, www.ist-winner.org.

132

Network and Mobility Management [79] FP6 IST Project Flexible Relay Wireless OFDM-based Networks (FIREWORKS) at www.fireworks.intranet.gr. [80] Mino, E., A. Mihovska, et al., “Scalable and Hybrid Radio Resource Management for Future Wireless Networks,” Proc. of IST Mobile Summit 07, Budapest, Hungary, July 2007. [81] GPRS technology at http://www.gsmworld.com/technology/gprs/index.shtml. [82] IEEE 802.11, The Working Group Setting the Standards for Wireless LANs, at http://www.ieee802.org/11. [83] HIPERLAN standards, at http:// www.etsi.org/. [84] UMTS, at http://www.umts-forum.org. [85] IST Project WINNER, Concept Group WA, D6.13.1, “Intermediate Concept Proposal and Evaluation,” http://www.ist-winner.org. [86] IST Project SURFACE, at http://www.ist-surface.org/deliverables.htm. [87] 3GPP, “Services and Service Capabilities,” 3GPP TS 22.105 V8.0.0 (2006-06). [88] http://www.itu.int/ITU-R/conferences/wrc. [89] World Wireless Research Forum (WWRF) at http://www.world-wireless.org. [90] IST Project WINNER , Deliverable 2.1 “Identification of Radio Link Technologies,” July 2004. [91] Hanzo, L., C. H. Wong, and M. S. Yee, Adaptive Wireless Transceivers: Turbo-Coded, Turbo-Equalised and Space-Time Coded TDMA, CDMA and OFDM Systems, John Wiley, March 2002. [92] Walko, J., “Mobile Operators Under Pressure in Barcelona—3GSM Report,” Picochip, EETimes Europe, February 19–March 4, 2007. [93] CELTIC Project WINNER+, at www.celtic-winner-org.

CHAPTER 3

Quality of Service The diverse range of users and converging markets of relevance to next generation systems imposes new requirements and scenarios for the provision of quality of service (QoS), which in turn demand novel or modifications to existing solutions. Adding to the complexity are new network communication modes, like peer-to-peer creating new potentials in regard to the exploitation of existing infrastructures. To the overall landscape, adds up the expected adoption of IPv6, and the promising solution of using an optical backhaul infrastructure. QoS features in IPv6, namely Differentiated Services and Integrated Services, provide means for application to reserve network resources using IP signaling between the application and the network layers. Another example of the layer-to-layer signaling can be found from the IEEE 802.11e standard where the QoS provisioning is performed between the application and the medium access layers. The QoS information considering the IP packet priorities alone will not be sufficient for delivering optimization information between the source and physical layers. More detailed information needs to be delivered in order to fully optimize the transmission using both source and channel coding. The issues around QoS provision have many aspects depending on the adopted scenario. This chapter focuses on some of the solutions proposed for QoS delivery in the scope of the scenarios adopted by a number of FP6 IST projects within the areas of mobile and wireless beyond 3G [1] and broadband for all [2]. This chapter is organized as follows. Section 3.1 introduces into the QoS concepts and state of the art. The various means of qualifying and quantifying QoS are described. Section 3.2 describes various QoS architectures developed by the FP6 IST projects (e.g., WINNER and WINNER II, Ambient Networks, ENABLE, PHOENIX [1]). Section 3.3 describes platforms for QoS testing and validation.

3.1

Introduction Wireless networking segments of different technologies are going to coexist and interoperate in the context of a future all-IP next generation networks. The rapid uptake of communicating while on the move is generating an increasing demand for a “global” mobility service. The users are asking to stay always connected and enjoy a wide variety of voice, data, and multimedia services independently of their geographical location, and with performance significantly better than today.

133

134

Quality of Service

It is getting widely accepted that one key technology to achieve these objectives will be the next generation Internet protocol (IPv6), which will support the foreseen growth in the number of mobile users without breaking the end-to-end transparency of the Internet [3]. Another prerequisite is that proper cooperation and coexisting architectures are designed and implemented that can ensure that the various available in the infrastructure access networks are cooperating for satisfying the user requirements. In addition, a significant criteria is to keep the costs for operators and service providers down. Cooperation architectures of the type introduced in Chapter 2 ensure that QoS is provided in the different access networks based on various technology-specific mechanisms. This in turn, requires further harmonization. 3.1.1

Performance Metrics

QoS can be defined as the collective effect of service performance, which determine the degree of satisfaction of a user of the service [4]. QoS can be measured as a set of performance metrics called key performance indicators (KPIs) [5, 6]. A KPI is mostly a mathematical formula used to define a metric that describes network quality and behavior for network optimization purposes. Comparison of KPI values can point out, in a simple and understandable way, whether actions that have been made to improve the network and service quality, have been successful or not. This information is normally obtained by performing periodic measurements. The performance measurement is an effective means of scanning the whole network at any time and systematically searching for errors, bottlenecks, and suspicious behavior. KPIs are a set of measurements used to keep track of a network status over the time. Therefore, KPIs have been used often in relation to RRM algorithms [6–9]. KPIs can be measured at different levels in the system depending on the objective of the applied RRM mechanisms. Figure 3.1 shows an example of KPIs measurement and gathering for the purpose of optimizing the performance in the physical (PHY) layer of a reconfigurable air interface. In this case, the RRM decisions will be taken at radio resource layer (RRC). Other types of KPIs are related to network and service performance.

Service level KPIs Higher layers

Radio Resource Control (RRC)

Network (IP) layer Network level KPIs

RLC

PHY

Figure 3.1

KPIs at different system levels [6].

Reference values, requirements, and scenarios specific to the selfconfigurable air interface

3.1 Introduction

3.1.1.1

135

KPIs Classification

KPIs can be classified according to different points of view, depending on the way that they are taken, at what level they are taken, or what is the scope that they will have. One way is by considering the protocol level the KPIs refer to, (e.g., PHY, RLC, network end-to-end or application/service). For example, throughput at the application level refers to an application layer session and might be obtained as the ratio between the number of bytes transferred from a server to a client and the time required to complete successfully the data transfer; throughput at PHY might be defined as the information rate of link in the wireless interface [6]. Another way to classify KPIs is by considering whether they reflect a state of the user or control planes (e.g., access delay defined as the time elapsing from when a MAC entity becomes backlogged to the time when the radio resource to carry the backlogged frame(s) is assigned to the entity is a control plane KPI, since a signaling procedure is involved). If there is any active action from the operator a KPI can be defined as passive or active. Passive KPIs are computed directly by the management system of the corresponding mobile communications network. Active KPIs are measured on the field by a human operator with different types of monitoring tools. KPIs can be also classified in a simplified way depending on whether they focus on the network performance or on the service performance. There are also different types of aggregations that can be typically considered for each KPI. Temporal aggregation defines the different KPIs by considering different time scales, (e.g., the SINR might be referred to a single block, averaged over many consecutive blocks, or even averaged over an infinite time horizon in a stationary channel setting; mean traffic intensities can be referred to hourly, daily, or monthly time scales). The relevant time scale for each KPI should be clarified in its formal definition. Spatial aggregation means that indicators can have different aggregate levels of the topology of the network (e.g., cell level, BSC level, or even network level); the relevant spatial scale for each KPI should be clarified in its formal definition. 3.1.1.2 KPI Calculation

The KPIs are composed of several raw counters or other measurements collected from the different levels in the network because a single measurement is considered too detailed to be used as a KPI. From a mathematical point of view, a KPI is a function F: Rn > R such that [10]: KPI = F( reward 1 , K , reward n )

(3.1)

where rewardi is a performance variable. A performance variable is a generic definition that can be used to represent dependability and performance variables. It is strictly related to the modeling tool, in which it is calculated. A performance variable allows for the specification of a measure on one or both of the following:

136

Quality of Service

•

•

The states of the model, giving a rate reward performance variable. A rate reward is a function of the state of the system at an instant of time. Action completions, giving an impulse reward performance variable. An impulse reward is a function of the state of the system and the identity of an action that completes, and is evaluated when a particular action completes.

A performance variable can be measured at an instant of time, measured in steady state, accumulated over a period of time, or accumulated over a time-averaged period of time. Once the rate and impulse rewards are defined, the desired statistics on the measure must be specified (mean, variance, distribution of the measure, or the probability of the measure falling within a specified range). KPIs are split in two types depending on whether they describe the network’s resources or the delivered QoS. The main KPIs related to QoS can be measured in any type of packet-switched network. In order to obtain a more general KPI, able to express the behavior of a set of network components, a general calculus procedure consisting on a progressive aggregation of partial KPIs can be applied [10]. At level zero, the performance variables can be computed using a modeling tool (e.g., UltraSAN [11], Möbius [12]). At level 1, the first set of KPIs can be calculated by using the function F defined in (3.1). At level 2, the preceding KPIs are subsequently aggregated and other sets of KPIs are identified, and so on. More formally, the aggregation procedure consists in applying a function that takes in input a tuple (KPI1,…, KPIk) and provides in output a real value. Through the aggregation procedure, general KPIs for each network can be obtained (KPInetwork1,…, KPInetworkr) and, finally, a general KPI showing the overall system behavior (KPIoverall-system) is obtained. Naturally, it is possible that the aggregation procedure does not totally complete because, for example, some partial indicators have completely different meanings and then they cannot be combined together. Nevertheless, the provided useful criteria can be utilized in a decision-making process. Furthermore, the capability of the KPI overall-system to properly represent the system performance is strictly related to an appropriate choice of the aggregating functions, and of the performance variables. In a realistic scenario, each KPI is calculated separately and compared with the given thresholds provided from the operator. An alarm (AL) is created when these values are within the threshold limits. The generation of an alarm is shown in Figure 3.2. The monitoring entity (e.g., SRRM, CoopRRM, MRRM, see Chapters 1 and 2) receives in input periodical reports from the controlled network with a rate λIN = λReports. These reports may be correct or incorrect with a probability and 1- , respectively. The processing of these reports leads to the output of an alarm, which is when a KPI exceeds its corresponding threshold (with a rate λINNER = λAlarms). Therefore, λINNER = IN INNER IN p * λ with 0 ≤ p ≤ 1 (i.e. λ ≤ λ ). This relation is shown in Figure 3.2. However, the ITMU can generate (as consequence of an internal error) an alarm by itself (with a rate λspurious). Thus, the overall output rate is λITMUIN->OUT=λAlarms+λ spurious. The output can be correct (either correct emission or correct omission) or incorrect (either incorrect emission or incorrect omission). Within an interval, the KPIs that show after an initial calculation an alarm value is recalculated. A relaxed KPI value after the recalculation would not generate an

3.1 Introduction

137 1/λ Alarms

KPI Threshold spurious alarm

1/λ Reports

Figure 3.2

Correspondence between λAlarms and λReports.

alarm message. If recalculation still indicates that the KPIs are close or larger than the predefined threshold, an alarm message is generated with a structure depending on the type of KPI that has triggered it. 3.1.1.3

Network Performance Characterization

From the user point of view, the whole network can be considered as a data bearer that provides certain transmission capabilities [6, 13]. These capabilities can be defined by the combination of two basic parameters: throughput and latency. In order to fully define an access network, other additional factors should be considered, such as the accessibility and the retainability of the connections. Based on these considerations, network performance is defined as a set of five main indicators [6]: 1. Throughput Throughput can refer to a single user or to a cell. The user throughput is defined as the amount of data correctly transferred; that is, transferred within a certain block error rate (BLER) level, in one direction over a link divided by the time taken to transfer it, expressed in bits, or bytes per second. For example, the throughput in the radio interface is termed as the effective radio link control (RLC) payload throughput. The concept of user throughput leads to that of cell throughput, the amount of data that a cell can transmit through the available channels during a certain period of time. In RANs the factors that determine both user and cell throughput are the peak throughput, the resource multiplexing among users, the BLER, and the RLC signaling. The throughput may be limited by every component along the path from source to destination host, including all hardware and software.

138

Quality of Service

Throughput also has two characteristics—achievable throughput and maximum throughput. Achievable throughput is the throughput between two end endpoints under a completely defined set of conditions, such as transmission protocol, end host hardware, operating system, tuning method, and parameters. This characteristic represents the performance that an application in this specific setting might achieve. Therefore, the available bandwidth is a measurement that indicates whether there are still resources in the network that the users can exploit. The achievable throughput can be low even if there is still available bandwidth, for example, this is the case when a network element is limitative. 2. Latency (or Delay) End-to-end latency or delay is the time needed by a packet to cross a network connection from a sender to a receiver. Latency is determined by the data delivery delay just crossing the wireless interface, by retransmissions, by RLC signaling in connection establishment, by the TCP level performance, and other processing delays. A round-trip delay is measured by the time taken for sending a packet that is returned to the sender. From this, the one-way delay can be calculated, being half of the round-trip delay. A delay much longer than expected indicates congestion in the network. To calculate the end-to-end delay from these factors the following formula can be used [6]:

(3.2)

Expression (A) in (3.2) is dependent on the traffic loading, protocols, and delay in the lower layers, in some cases; expression (B) is dependent on the distance between the user terminal, and the base station expression (C) is dependent on the implementation. 3. Accessibility In [4] a difference is given between service and network accessibility. Service accessibility is the probability that a service can be obtained within specified tolerances and other given operating conditions when requested by the user. It depends on a range of factors (from network connectivity with external nodes and application servers, to signal coverage). Service failures can be due either internal or external causes to the operator network. Network accessibility is the probability that the user of a service after a request receives the proceed-to-select signal within specified conditions. 4. Dependability

3.1 Introduction

139

Availability (and most generally dependability) is an important aspect of telecommunication systems and it is tightly linked to the concept of QoS. The availability and reliability requirements constitute an important factor in the competition among service providers, network operators, and equipment manufacturers. Wireless systems are particularly vulnerable to failures and malfunctions for several reasons. First, wireless architectures are naturally distributed over a wide geographic area. Second, equipment-pricing pressure and fast technology progresses prohibit massive fault-tolerance procedures. Third, the responsibility for insuring dependable functioning of the system is generally distributed among several independent collaborating entities. Fourth, the RF access medium is much more vulnerable than the access medium of a wired network. Usually, the specific targeted application field dictates both functional and nonfunctional system requirements (dependability requirements are among the nonfunctional ones). For traditional high critical application fields like nuclear and transport control systems, dependability requirements are well established, being often regulated/imposed by international certification bodies. In other application areas, where criticality is more related with economical aspects more than human life and environmental damages (e.g., commercial-grade and telecommunication applications), agreed minimum levels of dependability are not yet imposed, although dependability is of high interest because of competitiveness among the several operators in the respective fields. 5. Retainability There is also a difference between service and connection retainability, the latter being a network indicator. Service (connection) retainability is the probability that a service (connection), once obtained, will continue to be provided for a communication under given conditions (for a given time duration). 3.1.1.4

Transport Layer Effects on QoS

In the case of classic, wired networks, the Transmission Control Protocol (TCP) [14] or some other, similar solutions [15] are employed to provide reliable packet transmission. It is commonly known, however, that TCP performs poorly when wireless links are concerned [16]. The reason is that TCP is not able to distinguish the losses caused by overflowing the buffers from the losses connected with wireless effects such as fading, interference, and handovers [17]. More specifically, TCP tries to avoid packet losses by lowering the transmission (congestion) window, initiating congestion control or avoidance, or backing off the retransmission timer [16]. Unfortunately, such an approach also holds true when packets are lost due to reasons other than congestion and that is what inevitably leads to suboptimal system performance [18]. There are different methods aimed at mitigating this undesirable effect [16, 17]. First, one can hide packet losses resulting from the aforementioned wireless effects, so only the losses related to congestions are visible to the source node. On the other hand, the TCP option field can be exploited for the purposes of conveying addi-

140

Quality of Service

tional information pointing out, which losses are due to wireless effects. Following, it is also possible to try to avoid packet losses related to buffer overflow and consequently only the losses resulting from wireless effects can be seen by the source node. This, however, makes it necessary to estimate congestion with the use of some other mechanism. It is possible to enhance TCP with the so-called selective acknowledgments (SACK), because the cumulative acknowledge mechanism is usually unable to provide the source node with all information necessary for quick recovery from multiple packet losses within a transmission window [16]. SACK will allow the sender to recover from multiple packet losses in a window without resorting to a coarse timeout. The sender can distinguish between congestion and other form of losses using an explicit loss notification (ELN) mechanism. All those methods pertain to an end-to-end flow control. One should, however, note that there are other options as well. Namely, the end-to-end connection can be split into two distinct parts and the one related to the wireless link may be operated by a specialized protocol, tailored accordingly to the requirements of the wireless environment [16]. Pure link layer protocols, which employ forward error control (FEC) techniques and retransmission of lost packets in response to automatic repeat request (ARQ) messages, may also be considered. For example, the link-layer protocols for CDMA [19] and TDMA [20] primarily use ARQ techniques. While the use of ARQ in TDMA guarantees reliable, in-order delivery of link-layer frames, the CDMA protocol only makes a limited attempt and leaves eventual error recovery to the TCP. Other protocols such as AIRMAIL [21] employ a combination of FEC and ARQ techniques for loss recovery. The main advantage of employing a link layer protocol for loss recovery is that it fits naturally into the layered structure of network protocols. The link layer protocol operates independently of higher layer protocols, and does not maintain any preconnection state. The main concern of these protocols is the effect on the TCP [16]. The evolution of the RAN towards simplified architecture has made necessary that most of the functionalities related to radio control (CP) and radio link (UP) have been relocated to the BS. An important issue that needs to be taken into account is that the radio interface for next generation systems is solely based on packet transfer. Even though packet transfer is an efficient method for sharing communication resources among multiple users there is also a downside. Usually, the underlying network introduces plenty of uncertainties that generally impair information transfer reliability. Scheduling functions, retransmission protocols, and (dynamic) routing schemes (together with multihopping techniques) are examples of techniques that may change the packet transmission, and reception sequence. Similarly, retransmission ambiguities, signaling errors, and unreliable feedback channels may result in unnecessary retransmissions and residual errors. Out-of-order delivery, duplicates, and lost packets are therefore typical error events that would occur in this type of communication systems. A problem arises, since all these events then would degrade the upper layer protocol or user perceived communication quality. In the context of next generation systems, the reliable packet transfer of services towards the upper layers is the responsibility of the RLC protocol (see Figure 3.1).

3.1 Introduction

141

In current standards, multiple retransmission functions are often located at different protocol layers on the top of each other [22, 23]. Lower layer retransmission aims to correct transmission errors on the physical channel over one hop, whereas higher layer retransmission ensures reliable information transfer over the RAN and its different interfaces. A similar kind of function is also proposed for next generation systems employing multihop communication [24]. There a hop-by-hop enabled by a hybrid ARQ (HARQ), and a single hop retransmission (enabled by an outer ARQ) functions interact closely to ensure an efficient overall system performance. The interaction is a consequence of the envisioned for the next generation systems interaction between RLC, medium access control (MAC), and physical (PHY) layers [25, 26]. The normal situation is that the retransmission unit (RTU) of the end-to-end retransmission provided by the RLC layer and the hop-by-hop retransmission provided by the MAC can be of the same size. Thus, the sequence numbers can be reused, and this motivates the choice to perform the segmentation/concatenation of packets to appropriate retransmission units in the RLC layer. With dynamic link adaptation, however, the capacity of the resource units to carry a FEC block is not fixed, but depends on the actual resources selected by the resource scheduler. In order to facilitate a good resource optimization, the scheduler controls the complete transmission chain on a packet-by-packet basis. Thus, the segmentation/concatenation of packets in the RLC layer is controlled by the scheduler in the MAC layer along with controlling the coding, modulation, multiantenna processing, and mapping onto transmission resources that are performed in the physical layer. This approach enables the following: • • •

• •

Arbitrary sized network layer packets entering the RLC layer; A static predefined set of optimized FEC block sizes; Multiuser QoS scheduling per frame with the potential for multiuser scheduling gains; Per chunk link adaptation; Adaptive resource mapping per frame, including fast switching between frequency-adaptive and nonfrequency-adaptive transmission for ongoing flows.

The PHY layer itself can be completely controlled by the scheduler in the MAC layer. It does not contain any additional control functionality. This fast and tight interaction is made possible by the assumption that RLC, MAC, and PHY layers of a node are always colocated physically and can therefore interact with negligible delays. 3.1.1.5

User Datagram Protocol

The User Datagram Protocol (UDP) is a transport protocol with less drawbacks over the wireless network than the TCP, because it does not implement retransmissions or flow and congestion control mechanisms, and its overhead is smaller. Consequently, its throughput is constant, but does not guarantee a reliable data transmission. It is intended for services where the main priority is achieving a constant maximum throughput available, such as in streaming services.

142

Quality of Service

3.1.1.6

Application Layer Effects on QoS

Application layers also introduce degradation effects from a delay perspective. Because this layer is responsible, among other tasks, for establishing sessions, processing application content, or handling the required transport connections, the delays associated to these procedures should be considered in the QoS performance analysis. As examples, two different protocols can be mentioned: the File Transfer Protocol (FTP) and the Hyper Text Transfer Protocol (HTTP). HTP is used for general file exchange, and HTTP is used for specific hyper text files. They are built on the lower layer TCP. Because of the widespread use of hypertext file exchange in mobile communications, HTTP is also used in some mobile communications high layer protocols, such as WAP 2.0. In this case, in order to minimize the undesired effects of TCP in this environment, a wireless specific HTTP protocol has been specified, namely HTTP/1.1. An application protocol and a service are two distinct concepts. A service is usually built on several applications and application protocols. However, some application protocols are sometimes called services on their own. This is the case of FTP, for example. QoS refers to what an end user perceives when using an application to support a service. It depends on the connection hops between two users, or between a user with a server, with parameters that define the network status, and with parameters of the transport and application layers [6]. It also depends on the service the network supports. The performance of an application is linked directly to the characteristic of the service itself, regardless of the used wireless system. 3.1.2

QoS Provision in IP Networks

Providing QoS at network level involves optimization of existing network and transport layer protocols as well as developing new mechanisms in order to improve the QoS guarantees of the applications envisioned for the system [27]. At the network layer, different management schemes can be considered, in order to bundle together components with similar QoS requirements. The effect of mobility in the wireless link should also be considered at the IP layer. 3.1.2.1

Transport Layer Protocols and Mechanisms

Transport Layer Services

Transport layer services can be divided into the following features according to [28]: • • • • • •

Connection-oriented (message vs. byte stream) versus connectionless; No-loss, uncontrolled-loss, and controlled-loss; No-duplicates and maybe-duplicates; Ordered, unordered, and partially ordered; Data-integrity, no-data-integrity, and partial-data-integrity; Blocking and nonblocking;

3.1 Introduction

• • • • •

143

Multicast and unicast; Priority and no-priority; Security and no-security; Status-reporting and no-status-reporting; QoS and no-QoS.

A connection-oriented service usually has three phases: connection establishment, data transfer, and connection termination. Connectionless service provides only one phase, the data transfer. The connection-oriented service can be message-oriented or byte-stream. In the former case, messages have a specified maximum size and message boundaries are preserved. This means that for example two 1K messages will be sent as two separate 1K messages, never as one 2K message or four 0.5K messages. In the byte-stream service the flow of data from end-to-end is viewed as an unstructured sequence of bytes that flow in a first-input-first-output (FIFO) manner. There is no such thing as message (maximum) size. Data is appended to the end of a byte-stream and at the other end it is read from the head of the stream. The byte-stream service makes it possible to better exploit the underlying network service. On the other hand, it does not deliver data to the application in meaningful units as the message-oriented service does. In the connectionless service the data is submitted in messages, and the message boundaries are preserved as in the connection-oriented message-oriented service. The next features are related to the reliability. The terms reliable and unreliable convey different meanings. A reliable service is defined in [28] as a service having no-loss, no-duplicates, ordered, and data-integrity features. No-loss means that the data is delivered to the receiver or that the sender is informed that (part of) the data might not have been delivered. Uncontrolled-loss (e.g., best-effort service) does not provide any guarantees for the delivery. The controlled-loss service is something between the no-loss and uncontrolled-loss services. For example, messages can be divided into reliable, partially reliable, and unreliable ones. Reliable messages will be retransmitted until successfully delivered, partially reliable ones k times before dropped, and unreliable ones only once. The no-duplicates service guarantees that the data will be delivered at most once to the receiver. Maybe-duplicates does not guarantee that. An ordered service preserves the order of data in the delivery to the receiver. If A is sent before B, it never occurs that B is delivered before A. For the unordered service this is possible. In a partially ordered service the data is delivered according to the predefined permitted orders agreed by the sender and the receiver. A data-integrity service guarantees with high probability (depends on the efficiency of error detection method) that there are no bit errors in the delivered data. No-data-integrity means that bit errors can occur. Partial-data-integrity allows for a controlled amount of bit errors in the delivered data. This may be useful in case of multimedia streams, for example, because audio/video codecs usually prefer damaged data over totally lost data. A blocking service provides flow control between the user and the transport sender. The user sender waits for the signal of the transport sender to continue. In a

144

Quality of Service

nonblocking service the user sender can continue sending without waiting for the signals of the transport sender, thus neglecting the use of the buffering capabilities of the transport layer and the receiving rate of the receiver. A multicast service delivers the same data to one or more receivers while there is exactly one receiver in the unicast service. A priority service enables the sender to indicate that some messages are more important than others and should be delivered sooner (if possible) than lower priority messages. In no-priority services all messages are handled equally. A security service provides some kind of security functions such as authentication, access control, confidentiality, or integrity. Naturally, no-security service does not provide any of those mentioned above. Status-reporting gives specific information about the transport entity such as performance characteristics of a connection (e.g., throughput, mean delay), addresses, and timer values. A QoS service allows the user to specify some desired parameters for the quality of the transmission service. Parameters can be the connection establishment delay, connection establishment failure probability, throughput, transit delay, residual error rate, transfer failure probability, connection release delay, connection release failure probability, protection, priority, and resilience. Transport Layer Protocols

Some transport layer protocols were described in Section 3.1.1.3. It was mentioned that network protocols, such as IP do not perform any error control on the user data. For realistic high-speed networks with low error rates, the transport layer error control is more efficient than the link layer error control [27]. Error detection identifies lost, misordered, duplicated, and corrupted protocol data units (PDUs). The sequence number helps in the case of first the three problems. The corrupted data is discovered by using length fields and checksums. Error reporting and recovery are accomplished using timers, sequence numbers, and acknowledgments (ACKs). Common retransmission strategies are the conservative selective approach, where only lost packets are retransmitted and the Go-Back-N approach, in which all the packets transmitted after the lost packet are also retransmitted automatically. The transport layer flow control is defined as any scheme, by which the transport sender limits the rate, at which data is sent over the network. The goals of the flow control are to prevent a transport sender from sending data, for which there is no available buffer space at the receiver side, and/or preventing too much traffic in the network. The latter is also referred to as congestion control or congestion avoidance. Basically there are two techniques to avoid network congestion and overflowing receiver buffers: window flow control and rate control. In window flow control, the transport sender continues sending new data as long as there is space in the sending window. The window size can be fixed or variable. Rate control uses timers to limit the data transmission. Either burst size and interval (=burst rate) or an interpacket delay time is used. Fairness and optimality are the goals of the congestion control.

3.1 Introduction

145

The Datagram Congestion Control Protocol (DCCP) [29, 30] is intended for applications that require the flow-based semantics of TCP, but have a preference for delivery of timely data over in-order delivery or reliability, or which would like different congestion control dynamics than TCP. To date most such applications have used either TCP, whose reliability and in-order semantics can introduce arbitrary delay, or UDP, and implemented their own congestion control mechanisms or no congestion control at all. In these kinds of situations, DCCP can be used instead of UDP or TCP. DCCP is also intended for applications that do not require features of the Stream Control Transmission Protocol (SCTP), (e.g., sequenced delivery within multiple streams). SCTP was initially proposed to accomplish signaling transport over IP networks [31]. DCCP was designed for use with streaming media (i.e., the packet stream, application is responsible for framing). This protocol provides unreliable flow of datagrams with acknowledgments but with a reliable handshake for connection setup and teardown. There are no retransmission methods, however, for the datagrams. Only options are retransmitted as required to make the feature negotiation and acknowledgment information reliable. Feature negotiation means that end endpoints can agree on the values of the features or properties of the connection. There is up to 1,020 bytes space for different options. There are two TCP-friendly congestion control mechanisms available: 1. TCP-like (CCID 2) for flows that want to quickly take advantage of the available bandwidth, and can cope with the quickly changing send rates; 2. TCP-friendly rate control (CCID 3) for flows that require a steadier send rate. The congestion control may differ even in the direction of the connection: from A to B CCID 2 can be used, while in the same time from B to A CCID 3 can be used. Congestion control incorporates explicit congestion notification (ECN) and ECN nonce. DCCP provides options to tell the sender which packets have reached the receiver and whether those packets were ECN marked, corrupted, or dropped in the receive buffer. The distinguishing of different kind of losses is also supported. The acknowledgment mechanism of the DCCP protocol is a little different from that of TCP. In TCP a packet is acknowledged only when the data is queued for delivery to the application. In DCCP, a packet is acknowledged when its options have been processed. The data dropped option may later tell that the packet’s payload was discarded. In DCCP, even acknowledgments will get their own sequence numbers. A mechanism allowing a server to avoid holding any state for unacknowledged connection attempts or already-finished connections is also provided as well as path MTU discovery. A simplified version of the DCCP is the DCCP-lite [32]. The simplifications were achieved by use of the following techniques: • • •

Eliminate options but not all features supported by options; Eliminate back-and-forth negotiation; Eliminate features with limited use or applicability;

146

Quality of Service

•

•

Where similar results are supported by multiple features or methods, eliminate all but one; Push congestion control related features and topics to the CCID documents. This makes it simpler to implement a DCCP-lite that only supports one CCID.

TCP is considered to be too slow protocol for real-time multimedia data, such as audio and video because of its three-way handshaking [27]. That is why UDP is usually used instead of TCP over IP. UDP, however, is unreliable because there are no retransmissions upon packet losses. RTP instead was designed by IETF as a transport protocol for real-time multimedia applications [33]. Strictly speaking, RTP is not a transport protocol since it does not provide a complete transport service. Instead, the RTP PDUs must be encapsulated within another transport protocol (e.g., UDP) that provides framing, checksums, and end-to-end delivery. RTP provides the timestamps and sequence numbers, which may be used by an application written on top of RTP to provide error detection, resequencing of out-of-order data, and/or error recovery. RTP itself does not provide any error detection/recovery; it is the application on top of RTP that may provide these. RTP also incorporates some presentation-layer functions: RTP profiles make it possible for the application to identify the format of data, (i.e., audio/video, what compression method). The RTP sequence numbers can be also used (e.g., in video decoding packets do not necessarily have to be decoded in sequence). RTP is independent of the underlying protocol. It can work on any type of network such as a TCP/IP, ATM, or frame relay. The RTP supports multicast if it is provided by the underlying network. The overhead of RTP header is quite large, and header compression is proposed. The Real Time Control Protocol (RTCP) takes care of QoS monitoring, intermedia synchronization, identification, and session size estimation/scaling. The control traffic load is scaled to be a maximum of 5% of the data traffic load. RTP receivers provide reception quality feedback using RTCP report packets that can be of two types: a sender or a receiver type. The receiver sends sender reports (SR) if it is actively participating in the session. Otherwise it will send the receiver reports (RR). Multicast Transport Protocols

Multicast protocols can have a different definition of reliability and can operate in a more or less different environment. That is why there will never be a single multicast protocol that fits well for all multicast applications [27]. It is possible to develop a family of protocols or a single protocol with a variety of selectable features to satisfy the different requirements of multicast applications. Multicast protocols can be classified according to the following parameters [34]: • • • •

Number of senders. Point-to-multipoint (1-to-N). Multipoint-to-multipoint (M-to-N). Group organization and receiver scalabilit.

3.1 Introduction

•

• •

•

•

•

•

•

• • •

• • •

•

147

Four levels of scalability: small groups (only few members); medium groups (e.g., a single LAN and the cost of multicasting from a receiver is low); large groups (geographical distribution or the cost of multicasting from a receiver is high); and enormous groups (losses on separate branches of the distribution tree are uncorrelated or there is no reverse path to provide feedback for error control). Data reliability. Best-effort reliability: no effort to improve the reliability provided by the network layer, (e.g., XTP). Bounded latency reliability: each packet has a certain lifetime, thereby defining an upper bound on its delivery latency. Packets arriving outside their lifetimes are discarded. Video stream is a good example of this. Most recent reliability: Only the most recent data for a particular parameter is of interest. For example, in stock quotes service if a particular quote is lost and a new value is available before the retransmission is possible, there is no sense in retransmitting old values. Receiver-centered reliability: The sender has no responsibility for error recovery (other than possibly providing retransmission of packets) and often no knowledge of the success of delivery. Absolute reliability: Multicast file transfer is an example of this. All transmitted multicast packets must be delivered to the active group. If any of the data are missing at the receiver, none of the data will be useful. Congestion control: In presence of congestion the same speed for all receivers must be maintained, or certain receivers are permitted to lower their rate requirements in case of congestion. Group management. 0-reliable multicast: the sender is not required to know of its set of receivers. K-reliable multicast: at least K (0 ≤ K ≤ N) members of the receiver group are alive (i.e., responding at any time). If receiver failure is detected, that particular receiver is removed from the group. The remaining group members can continue as long as there are at least K members remaining. Ordering. Νo ordering (e.g., XTP). Local ordering: all reliable multicast protocols must provide local ordering (i.e., packets are sequenced). Χausal, partial, and total ordering are meaningful only when there are multiple senders, and reasonable only when there are few senders.

3.1.2.2

Network Layer Protocols and Mechanisms

Multicast Group Management

In IP multicast the sender only sends a packet once. The multicast routers along the path of the multicast flow duplicate a packet, if necessary. In that way, multicast decreases the bandwidth usage of the underlying network.

148

Quality of Service

A multicast framework consists of two main elements: (1) Multicast group management protocols, and (2) multicast routing protocols. Multicasting builds on the multicast group concept. A multicast group is a set of hosts who are interested in the reception of the multicast flow sent to this group. The group is identified by a multicast address. The hosts use group management protocols to enter or leave a given group. Multicasting uses multicast routing protocols for delivering the multicast packets to the hosts. Currently the Internet Group Management Protocol (IGMP) for IPv4 and the Multicast Listener Discovery (MLD) for IPv6 [35] are used for group management in IP networks [27]. The most important task of these protocols is servicing the group membership information. Multicast routers use the group membership information to create a multicast distribution tree. Every multicast group has a group identifier—an IP address (e.g., in IPv6 the addresses have the “ff” prefix). MLD is used to discover the group members of the multicast groups on a specified link. MLDv2 supports source filtering of multicast flows. This means that a host can set the source addresses, from which it wants to receive the multicast flows. Multicast Routing Protocols

The group membership information collected by the group management protocols are used by the multicast routing protocols to forward the multicast packets to the group members. There are two types of multicast trees: 1. Source-based trees. By using source-based trees, the root of the multicast tree will be the source of the multicast flow. 2. Shared trees. A shared tree algorithm builds only one shared tree for a group. This tree has some core multicast routers, through which every multicast packet must travel. The building of this tree is receiver driven. When a receiver wants to join a shared tree, it sends a join message, which travels back to the core routers. Using a shared tree is efficient as only one multicast tree has to be maintained by the network. However, this tree will not be an optimal one, and the load concentration on the core routers can be very high. The distribution of the group members is relevant when selecting the tree type, as in the following: •

•

Dense mode. The preassumption of this mode is that the subnets containing the hosts have many group members. Other assumption is that there is plenty of bandwidth available. This mode is useful when there are only a few sources and many destination hosts, or the multicast flow’s needed bandwidth is high and constant. Most dense mode protocols use source-based trees. Sparse mode: in this mode the hosts are distributed widely in the whole network. This means that there can be as many members as in the dense mode but they are widely spread. This mode does not need high bandwidth; it is useful when we have sources that only need low bandwidth or the multicast flow is not constant (e.g., in a video conferencing application). Most sparse mode protocols use shared trees.

3.1 Introduction

149

The Internet Engineering Task Force (IETF) [36] developed many protocols for both modes. Some of these are listed as follows: • • • • • •

Distance-Vector Multicast Routing Protocol (DVMRP) [37]; Multicast Extensions to Open Shortest Path First (MOSPF) [38]; Protocol-Independent Multicast (PIM); Protocol-Independent Multicast—Dense Mode (PIM-DM) [39]; Protocol-Independent Multicast—Sparse Mode (PIM-SM) [40]; Core-Based Tree (CBT) Protocol.

The above-mentioned protocols are mainly used for intradomain multicasting. For interdomain multicast, the following protocols should be used in addition: • •

Border Gateway Multicast Protocol (BGMP) [37]; Multiprotocol Border Gateway Protocol (MBGP) [38].

The PIM protocols do not depend on any unicast routing protocols. That means that they can use the unicast routing table of any unicast routing protocol (e.g., OSPF or RIP). The PIM protocol supports both the sparse mode (PIM-SM) and the dense mode (PIM-DM) multicasting. To support the multicast service, they introduce the following new entities: •

•

Rendezvous point (RP): Every multicast group has a shared multicast distribution tree. The root of this tree is the RP (RP-tree). Designated router (DR): A subnet can join the Internet through several routers. This means that a subnet can have more multicast routers. If these routers would work independently from each other, the hosts would receive every multicast packet duplicated, which would be a waste of bandwidth. That is why they choose a designated router among themselves, which will work as the only multicast router of the given subnet. If needed, the function of the DR can be overtaken by another multicast router on the subnet.

The PIM-DM protocol uses flooding for the building of the multicast tree. It uses unicast routing information for the flooding process; first it floods the network with multicast packets and then uses prune messages to cut of those routers that do not have any members in their subnets. The PIM-SM protocol can either use the routing information gathered by any unicast routing protocol or build on the information gathered by other multicast routing protocols. It builds one-way shared trees for every multicast group. The root of this tree is the rendezvous point (RP-tree). One great advantage of this protocol is that it can change from the RP-tree to a shortest path tree (which is mainly a dense mode structure). The shortest path tree root is the source itself. One difference compared to the PIM-DM protocol is that the group members should explicitly join a multicast group in order to receive the multicast flow. Another advantage of this protocol is that it does not use flooding for building the tree. After joining a multicast group, the DR can change when needed from the RP-tree to a shortest

150

Quality of Service

path tree. This reduces further the bandwidth use, which makes the protocol quite attractive. 3.1.2.3

Requirements and Parameters of QoS

The above protocol definitions are quite simple and comprehensive, but it is sometimes complex to determine how these reflect into specific network requirements or constraints [27]. Furthermore, realizing applications conforming to subjective parameters can be extremely difficult due to contrasting user needs. For these reasons, standard organizations and network researchers have spent considerable efforts in order to map the end-user perspective to specific network requirements. The results essentially report a subjective opinion of a properly set of hypothetical and testing user with regards to the satisfaction of the service (e.g., the vision of a video or the listening of a recorded audio), that in turn depends on several aspects, in particular, network-related in a telecommunication scenario. The QoS framework introduced by the ITU-T [4] gives a number of guidelines for the specification of QoS parameters relatively to the network level aspects. First, it can be distinguished between primary and secondary parameters as follows: •

•

A primary QoS parameter is determined on the basis of direct observations of “events” at interaction points; A secondary QoS parameter can be determined as a function of other, previously defined QoS parameters.

For a telecommunication service primary QoS parameters can be classified using a 3x3-matrix approach [4, 27]. In this approach, a general network is described as a system capable of providing the following three generic functions: (1) access (to network services), (2) information transfer, and (3) disengagement. The 3×3 matrix approach also defines three criteria for characterizing how these functions are realized: 1. The speed criterion characterizes the time related performance characteristics of QoS associated with a function. Speed parameters are defined on the basis of statistics made on sets of “duration times.” 2. The accuracy characterizes the degree of correctness with which a given function is realized. Accuracy parameters are defined on the basis either of the ratio of incorrect realizations on total attempts, or of the rate of incorrect realizations during an observation period. 3. The dependability characterizes the degree of certainty a function is performed. Dependability parameters are defined on the basis either of the ratio of failures on total attempts, or of the rate of failures during an observation period. Section 3.1.1.2 specified some of the fundamental primary QoS parameters as the throughput, error rate, end-to-end delay, and jitter.

3.1 Introduction

3.1.2.4

151

Qualitative and Quantitative QoS

QoS can be supported to different levels, depending both on the application requirements and on the QoS capabilities of the transport network [27]. One is related to the specific characteristic of the involved application and media type, (e.g., real-time applications have tight requirements on the delay and jitter, while large file transfers require a considerable amount of available bandwidth and no losses). QoS at the IP layer can be supported by deploying either the Internet Integrated Services (IIS) or the Internet Differentiated Services (IDS) architecture. The IIS architecture can support quantitative quality levels at a fine grain, while the IDS architecture can offer service quality at an aggregate level that makes it more scalable in a backbone context. In a QoS model different type of service quality can be addressed: absolute, relative, and proportional. An absolute service quality can be deterministic or statistical; in the first case a certain set of quality parameters are guaranteed for all the packets of the requiring application, but in the second one the same set of quality parameters is assured for the application flow in a statistical way (e.g., for the 99% of the total amount of concerned traffic). This type of service quality requires in general a proper resource allocation for the traffic of the application. In a relative service quality, different service classes are supported, each one with a quality level that is defined in a relative way, rather than in an absolute one. This means that the service experimented by the application using a certain service class is not strictly guaranteed, but statistically “better” than the service experimented under a lower service class. Also, in this QoS model a resource allocation for the various service class is mandatory, but this reservation is determined in a relative way, not to assure the absolute QoS guarantees to the applications. In a proportional service quality, the service levels for each service class are defined in a strictly proportional way; the amount of allocated resources for each class is, as a first instance, independent on the traffic that is fed into them. This model is particularly indicated for a network that is statically configured and does not need to support tight QoS guarantees. More than one QoS model can be supported in a real-IP network infrastructure, mostly depending on the QoS type required by the application and on the sustainable network complexity. The base service supported by the IP-packet switched data networks was the best effort. Within this kind of a service, fair behavior for the traffic flows into the overall network is not guaranteed. Quite simply, the best treatment is applied to the traffic by exploiting the potentiality of the available resources. This operating mode is suitable for the traditional applications, such as Telnet, FTP, and, to some extent, text-based WWW browsing. It may be totally unacceptable for the new applications identified for the next generation telecommunication scenarios (see Table 3.1). For example, in order to evaluate the impact of gaming data delay or gaming data loss according to Table 3.1, to the QoS of providing network gaming over wireless systems, it is necessary to define the QoS metrics for the game traffic model. For car racing games, an average round trip time of 100 ms is suggested [42]. Based on the work in [43] and a subjective quality assessment [44], an average round trip time of 139 ms would provide sufficient game quality for first-person shooter games, such as Counter Strike or Quake. Assuming an average network delay of 50

152 Table 3.1

Quality of Service Service Classes for Next Generation Systems [41]

Service Class

1. Real time collaboration and gaming

2. Geographic real time datacast

3. Short control messages and signalling

4. Simple interactive applications

5. Interactive high multimedia

6. Geographic interactive multimedia broadcast

7. Interactive ultra high multimedia

8.Simple telephony and messaging

9. Data and media telephony

Data Rate

Traffic Type

Delay

1-20 Mbps

highly Service requested interactive bit rate (SERR) (<20 ms)

2–5 Mbps

SERR Point to Region

highly interactive (<20 ms)

Error Rate

-6 -9 10 to 10

10

SERR

/control (20 – 100 ms)

10

Alarms Remote control Sensors Presence driven transfer (lightweight content)

-9

Prescence driven transfer (heavy content) Interactive geographical maps (remote processing)

Interactive 64–512 kbps SERR

/control (20 – 100 ms)

10

-6

Rich data call Control Video broadcasting/ streaming

Interactive 2–5 Mbps

SERR

2–5 Mbps

SERR Point to region

/control (20 – 100 ms)

10

-6

Video broadcasting/ streaming Localized map download

Interactive /control (20 – 100 ms)

10

-6

Interactive 10–50 Mbps SERR

8–64 kbps

SERR

64–512 kbps SERR

/control (20 – 100 ms)

Conversational (100–200 ms)

Conversational (100–200 ms)

-3

Telepresence/ Videoconference Collaborative work Navigation systems Real-time Gaming

Real time video streaming Collaborative work

-6

Interactive 8–64 Mbps

Example Applicaions

-6

10 to 10

High quality video conference Collaborative work

10 to 10

Voice telephony Instant messages Lightweight multiplayer games Bets and gambling

-3 -6 10 to 10

Audio streaming Video telephony (medium quality) Multiplayer games (high quality)

-3

-6

3.1 Introduction

10. Geographic datacast

153

64–512 kbps

SERR Point to region

Conversational (100–200 ms)

10 to 10

Localized datacast/ beacons High quality video telephony Collaborative work Standard data call

-3

-6

11. Rich data and media telephony

2–5 Mbps

SERR

Conversational (100–200 ms)

-3 -6 10 to 10

12. LAN access and file service

Up to 50 Mbps

System assisted bit rate (SYSA)

Conversational (100–200 ms)

10

13. Multimedia messaging

14. Lightweight browsing

8–64 Mbps

SYSA

64–512 kbps SERR

Few seconds (>200 ms)

Few seconds (>200 ms)

Access to data bases, filesystems

-6

-6

-9

10 to 10

10

-6

15. File exchange

Up to 5 Mbps

SYSA

Few seconds (>200 ms)

10

16. Video streaming

5 Mbps

SERR

Few seconds (>200 ms)

10

17. High quality video streaming

30 Mbps

SERR

Few seconds (>200 ms)

10

-9

18. Large files exchange

SYSA

SYSA

Few seconds (>200 ms)

10

-6

-6

-6

Messaging (data/voice/ media) Authentication (m-payment, m-wallet, m-ticket, m-key, etc.) Web browsing (lightweight) Messaging (data/voice/ media) (medium weight) Access to corporate database (lightweight) Audio on demand Web browsing (medium weight) Internet radio Access to databases (heavy weight), filesystems, Video download/upload peer-to-peer file sharing Video streaming (normal) Video streaming (archival)

ms and an average downlink delay of 30 ms, the average delay for the uplink wireless air interface will be 59 ms. In [42, 43], it is observed that players experience serious degradation of game playability with a round trip delay of 200–225 ms. To maintain the playability, a maximum delay of 145 ms is applied to all data transfers (i.e., the gaming data is dropped if it is not delivered after 145 ms). There are very few statistics available for the tolerance of network/mobile gaming to data loss,

154

Quality of Service

partly because there is no clear threshold of data loss rate beyond which the game becomes unplayable. The playability of games decreases as the data loss rate increases. Guarantees to the information transfer are critical for the operation of applications. A growing number of new value-added applications are emerging, making it a priority to support QoS in the network. The services that need QoS guarantees encompass, in most cases, the transmission of media flows such as audio and/or video. To maintain a certain end-to-end fixed quality, which users are accustomed to by every day experience, tight constraints in terms of delay, delay-jitter, and packet loss must be met. 3.1.2.5

End-to-End QoS

Integrated Services (IntServ) was designed to augment the existing best effort Internet with a range of services tailored for real-time streaming and interactive applications. Within IntServ, the two services that can support the two types of applications are the guaranteed service [45], for support of real-time applications with stringent bandwidth and latency requirements; and the controlled load [46], in support of traditional applications, whose users require a performance similar to the one offered by a best-effort, under a lightly loaded network. In IntServ, the traffic characteristics associated to these services are strictly defined and the resources are previously reserved by means of a signaling protocol, usually the Resource Reservation Protocol (RSVP) [47]. IntServ architecture requires per-flow traffic handling and signaling at every hop along an application’s end-to-end path. This means that it does not scale well to large networks and large customer populations [27]. Differentiated Services (DiffServ) provides a framework for service providers to offer each customer a range of services that meet different QoS requirements. The services are contractually established, between the provider and the customer, by means of service-level agreements (SLAs). Service-level specifications (SLSs) are the part of the SLA, where the performance of the service is described. DiffServ was designed to scale to large networks and large customer population. Therefore, its concept of QoS provisioning relies on the use of complex QoS functions at the edge of the network, applied to each incoming traffic flow, and very simple functions at the core network, applied to each aggregated traffic flow. These requirements lead to two key concepts: (2) performing traffic classification and conditioning at the edge of the network, and (2) forwarding traffic at the core. DiffServ QoS is defined as a 6-bit codepoint (DSCP) [48], in a particular field of the IP packet header—the type of service (ToS) field of IpV4 or the traffic class field in IpV6, which is used to classify the IP packets, at the so-called boundary nodes. In order to meet the established SLAs, these IP packets are then conditioned by applying a set of rules known as traffic conditioning agreements (TCAs). These rules define procedures for metering, marking, policing, and shaping. The packets are forwarded, on a hop-by-hop basis, based only on the DSCP value. In DiffServ terminology, this is called a per-hop-behavior (PHB).

3.1 Introduction

155

Given a SLA, the ISP must decide how to configure the network and how to handle the incoming traffic streams in accordance to its commitments. This means that classification, conditioning, and forwarding rules must be defined. Static SLAs are used when customers contracts services for a long period of time. In this scenario, all configuration tasks may be done manually, which means that the corresponding resources are statically allocated. Dynamic SLAs are used when customers require a specific service, with a certain quality, to perform a specific task. For example, a customer may require an assured forwarded (AF) service to support a video conference call among a set of specific end endpoints. For dynamic SLAs, resource allocation is closely related to signaling process [27]. While the IntServ architecture focuses on providing resource reservations for the delivery of end-to-end QoS to applications over heterogeneous networks, the DiffServ architecture focuses on providing scalable service differentiation. It is thus advantageous to combine both models with IntServ in the access network and DiffServ in the core network [49]. The main benefits of this model are the following: •

•

•

A scalable end-to-end IntServ service model with reasonable service guarantees in the core network. Explicit and dynamic reservations through RSVP signaling, which helps to assure that the network resources are optimally used at the IP level. This is especially important for access links, where resources can be scarce. Flexible access to a DiffServ core network with individual QoS for flows, in contrast to static DiffServ configuration.

3.1.2.6

Packet Scheduling

Packet scheduling is part of the traffic management framework, also known as queuing [27]. Sophisticated queuing can provide performance bounds of bandwidth, delay, jitter, and loss at each transmission interface, and thus, can meet the requirements of real time services. Queuing is also vital to best-effort services to avoid congestion and to provide fairness and protection, which leads to more stable and predictable network behavior. A scheduling discipline has to decide which request to serve next. An important instrument of this discipline is the queue; a buffer where the calls of the services are stored. If, because of a statistical fluctuation, requests arrive faster than the processor can serve them, some request must wait in the service queue. The time between the arrival and eventual service is the queuing delay. The storage is limited and if the queue is full, the server can drop the request. Thus, scheduling must choose which ones to discard. It allocates different QoS to different users, associated each with a queue, by its choice of service order and request to drop. A scheduling discipline must satisfy the following requirements [27]:

156

Quality of Service

•

•

•

•

Ease of implementation. In high-speed network a server must take a decision in few microseconds, so the discipline should require only few and simple operations and, if possible, inexpensively in term of hardware. Fairness and protection. It can allocate a share of the link capacity and output buffer to each queue it serves. An allocation at a link interface is referred as “fair” if the allocation satisfies the max-min allocation criterion. A fair share allocates a user with a small demand what it wants and evenly distributes unused resources to the other users. Initially, the capacity of the link is divided between the users, then the customers that required less than the available to them let the further bandwidth go to the others. Weights can be assigned to the different queues and allocate the resources not only in order of increasing demand, but also normalized by the weights themselves. Performance bounds. An operator can guarantee performance bounds for a queue only by reserving some network resources. The user agrees that its traffic will remain within certain bounds and the operator guarantees that the network will meet the user-connection’s performance requirements. The operator must control a connection performance not only when served by a single scheduler but also when the connection passes through many different scheduling disciplines. Ease and efficiency of admission control. A link interface controller should be able to decide if it is possible to meet the new connection’s performance bounds without ruin the performance of existing connection. A technique for efficiency control is the “schedulable region.” We define a set of all possible combinations of performance bounds that a scheduler can simultaneously meet, and this is the region. Then the admission control is simple, and we can only check if the parameter lies within or not.

There are four main degrees of freedom in designing a scheduling discipline: 1. The number of priority levels. In a priority scheduling scheme, each queue is associated with a priority level. The scheduler serves a packet from a priority level k only if there are no packets awaiting service in level k+1, k+2, …. 2. If each level is work-conserving or nonwork-conserving. A work-conserving scheduler is idle only when there is no packet awaiting service. A nonwork-conserving scheduler may be idle even if it has packets to serve. The reason is that it makes the traffic more predictable, thus reducing both the buffer size necessary at the output queues and the delay jitter (more control on the traffic profile of each queue). 3. The degree of aggregation of connections within a level. The scheduler treats all packets from connection in the same queue the same way; it provides different QoS to different queues and each class share the same quality. 4. Service order within a level. There are two fundamental choices: serving the packet in the order they arrive at or serving them out of order, according to a per-packet “service tag.” With this tag packets are allowed to jump to the head of the transmission queue.

3.1 Introduction

157

A generic scheduling discipline can be deployed either in a IntServ or in a DiffServ architecture, the difference relying practically on the number of application flows that insists on the same queue. In the former, at least for the guaranteed services class each queue is fed with a single flow, while in the latter, an aggregate of them share the resources allocated to the same queue. The first case is able to achieve more stringent QoS assurances but may suffer of scalability problems in a backbone scenario [27]. For a given configuration setting of a real scheduling scheme the delay, delay-jitter and bandwidth granted to each traffic aggregate in a queue can be quite different from the corresponding ideal case, for which the different queues would send their data independently and in parallel on the link. The traffic to be generated must represent a typical aggregate in a differentiated service network [27]. In the following, H.263 video flows are considered at different bit rates, ranging from 64 to 256 Kbitps as a mean value, created from real traces of video streaming and conferencing applications [50]. Figure 3.3 shows the traffic generated by such a source. Considering the nature of a typical compressed video flow, the bit rate can be highly variable with a burstiness factor (peak to mean rate ratio) of even 10. If a scheduler based on a FIFO queue is fed with a traffic aggregate then the resulting traffic will be as shown in Figure 3.4. The mean rate of the traffic aggregate is 3.3 Mbps and the peak about 10.5 Mbps. Obviously, the bursty behavior of the aggregate improves with the number of component source flows: the higher the number of multiplexed sources the better. As a result, the QoS granted to the aggregate increases with the multiplexing factor, at the same ratio of link capacity and aggregate mean rate. QoS is fundamental for real-time and streaming applications; in particular, the delay, delay-variation, and loss strongly impact the service perceived by the end user. QoS guarantees can be ensured through the allocation of a proper amount of bandwidth to the considered traffic aggregate. Even the loss probability can be controlled in such a way, also with a correct buffer dimensioning. The major issue is

Figure 3.3

Traffic generated by a video source [27].

158

Quality of Service

Figure 3.4

Traffic aggregate injected in a FIFO queue [27].

typically on the delay-variation (jitter), which is difficult to grant at a reasonable cost. For this motivation, the receiver video application is commonly tied up with a dejitter buffer, whose task is to equalize the delays of the incoming packets. A delay at a single router interface of 10 ms is a reasonable value and targeting a video quality that is at least equal to the VHS standard one, a loss of not higher of 1% should be guaranteed. A simulation study related to the above example would require that a value of 10 ms for the 99th percentile of the statistical delay distribution should be adopted. The probability density function (PDF) and cumulative density function (CDF) for the delay experienced by the traffic aggregate based on FIFO scheduling are shown in Figures 3.5 and 3.6, respectively. The same principle can be applied to a set of queues managed by a packet scheduler. An actual scheduling discipline, however, has some limitations dictated by the traffic granularity or the implementation issues, in the first place the complexity [27]. For these reasons, the performance provided by such a scheduler is lower compared to the one of an ideal scheme, as a compromise between the different design choices and working conditions. The results can be improved for the same case, when weighted fair queue (WFQ) scheduling is employed [51]. WFQ creates different queues for different user-connections in an IntServ context or dynamically adapts the bandwidth allocation for each queue in a fixed set in a DiffServ context, and assures that each queue receives some share of the bandwidth. The analysis with the WFQ scheduler is performed here considering four different queues, each one fed with an aggregate of video sources [27]. In order to obtain valuable results, the traffic aggregates are composed of exactly the same set of flows; this is important to investigate the performance of the scheduling algorithm with respect to an ideal scheme.

3.1 Introduction

PDF of a queuing delay for FIFO scheduling [27].

Value

Figure 3.5

159

Delay (sec)

Figure 3.6

CDF for a queuing delay for FIFO scheduling [27].

In practice, the limitations of an actual packet scheduler display themselves in lower performance or, in other words, in a less control of it. This means that it is necessary to allocate more resources, specifically more bandwidth, to a given queue to achieve the same performance as in the ideal case. The simulation analysis performed in [27] had the objective to determine the additional cost, in terms of allocated resources, in order to provide the QoS guarantees specified for the video applications described above. All the queues are loaded with the same traffic, which leads to the worst working conditions scenario, when a traffic burst on a queue is also present on the others more or less simultaneously. The bandwidth allocation in a WFQ scheduler is configured by setting its weights. In the analysis, a single queue on a link interface has a speed that is four times (40 Mbps) the transmission capacity considered in the analysis of the FIFO

160

Quality of Service

scheduler, in particular the third one, and will vary the weights in order to achieve the target performance for the associated traffic aggregate. Four ordered weights, from the lowest (first queue) to the highest (fourth queue) are considered. The sum of the weights must be equal to the unit in all of the conducted simulations. Figures 3.7 and 3.8 show the PDF and the CDF for the delay of the third queue with weight that equals to 0.25, (i.e., with the same bandwidth allocation as in the ideal case). The mean delay is comparable to the value obtained in the FIFO queue study, but the 99th percentile is slightly worse: a 3.4% of the considered traffic aggregate packets exceed the target QoS parameters. The performance of the CDF also decreases with the value at 10 ms approximately 3% lower than for the FIFO scheduling. This means that the third weight must be increased in order to achieve the target performance. Figures 3.9 and 3.10 show the PDF and the CDF, respectively, of the considered queue delay with a bandwidth allocation dictated by weight values of 0.10, 0.18, 0.32, and 0.4. This means that the additional bandwidth to be allocated is about 28% (the weight of the third queue is 0.32 instead of 0.25), to achieve the reference QoS parameters. The mean delay of the analyzed queue when the weight is set to 0.32 is smaller than for a weight value set at 0.25; nevertheless, the related weight must be big enough to compensate for the impact of the worst-case behavior of the WFQ, in particular, when the traffic bursts arrive (whose effect is more evident considering the 99th percentile as QoS reference parameter rather than the mean value). A higher bandwidth allocation on average leads to smaller packet delay. If the new link speed is set to four times the capacity required to achieve the target QoS guarantees while the generated traffic aggregates remain the same, the relationship between the weight assigned to the third queue and the incoming traffic

Figure 3.7

PDF for a traffic aggregate using WFQ for weight set at 0.25 [27].

161

Value

3.1 Introduction

Delay (sec)

Figure 3.8

CDF results for a traffic aggregate using WFQ for weight set at 0.25 [27].

Figure 3.9

PDF for a traffic aggregate using WFQ for weight set at 0.32 [27].

aggregate rate, when the packet delay is approximately 10 ms (e.g. in the range 9.5–10.5) will be as shown in Figure 3.11. The results were obtained considering the mean value of several measurements for the considered rate, in order to obtain consistent data (each sample is gathered in a 40-ms interval). The lowest value is set to 0.1 and the maximum to 0.8. The limit of 10 ms cannot be kept when the burst peak reaches 8.5 Mbps. The linear slope of the line shows how a small weight is required when the traffic burst is low, while it must be high when there is a heavy traffic burst. The waste of resources is intrinsically due to the basics of WFQ scheduler. This suggests some considerations and

162

Quality of Service

Figure 3.10

CDF of queuing delay with a 0.32 weight [27].

Figure 3.11 tees [27].

Relationship between weight and aggregate rate to achieve the target QoS guaran-

further development, possibly leading to optimized resource exploitation at the IP level. The higher the number of multiplexed sources, the better the utilization factor of the concerned link [27]. An initial resource optimization would dynamically vary the weight values in order to achieve the target QoS guarantees while exploiting the transmission resources as efficiently as possible at the same time. In some cases the incoming traffic to the overall queue system can have a critical bursty nature for which it is impossible to simultaneously provide the required QoS guarantees to all the aggregates, because the link capacity is fixed anyway and so limited. In this condition, some design and configuration choices must be taken, for

3.1 Introduction

163

example, to provide well-defined guarantees to some set of queues and looser ones to others, or alternatively for the support of a QoS scheme, where the scheduler grants performance to the different aggregates on the basis of a mutual relationship specified by fixed configuration parameters. The actual absolute value of the QoS would depend on the resource availability over the amount of overall incoming traffic ratio. A fundamental point is to preserve the low complexity and stability of the overall system, because a too frequent updating of the queue weights would lead to a very high CPU power consumption and poor control of the QoS provided to the different traffic aggregates [27]. 3.1.2.7

Optimized Resource Scheduling

Optimized resource scheduling is described here by a very basic algorithm, able to dynamically and consistently adapt the queue weights according to the time-variant amount of the incoming traffic and the preassigned target QoS [27]. This algorithm is referred to as dynamic WFQ (DWFQ). The fundamental issue is to correlate the burstiness of the traffic with the weight value to achieve given delay and loss guarantees. The measurement of the burstiness of the three aggregate entering each queue could be realized by evaluating the resulting buffer dimension, which is somehow related to the experienced worst-case delay. For what concerns the QoS, a relative model can be applied. Each queue has assigned a static parameter and the performance guarantees provided to the set of queues should be in line with the mutual ratio of the said parameters. For example, if the queue Qi and Qj have the parameters Pi and Pj, respectively, with Pj = 2Pi, the QoS provided to Qj should be two times better the one granted to Qi. No absolute QoS assurances are supported in this case. The weight values must be calculated taking into account the time-variant buffer sizes and the QoS parameter ratios. If in a given interval Tn, Bn represents the average buffer dimension of Qn, which is associated to the parameters Pn, a very basic rule to determine the queue weights could result from the resolution of a linear system whose equations are of the following form:

(B

i

) (

) (

/ B j * Pi / P j = W i / W j

)

(3.3)

where, Wi and Wj are the weights to be assigned to the queues Qi and Qj, respectively. If the duration of the updating interval T is properly selected, (i.e., not too small to avoid complexity and not too long in order to follow the traffic dynamic promptly enough), the resolution of a linear system with a number of equations that equals to the queue set cardinality is not critical at all. The simulation analysis is performed by assuming the same scenario in terms of link capacity and set of queues as in the simulation analysis in Section 3.1.2.6. In this case, the traffic aggregates entering each queue have the same average rate but are comprised of different video sources with different burstiness-time characteristics. A traffic aggregate is composed of the following flows:

164

Quality of Service

• •

3 video sources at 64 Kbps; 12 video sources at 256 Kbps.

The parameters Pi assigned to each of the four queues are 1, 2, 3, and 4, respectively; the second queue should have a delay guaranteed to be two times better than the first one and the fourth queue two times better than it. The traffic aggregate rates for the different queues are shown in Figure 3.12. The measurement interval, at the end of which the queue weights are updated is fixed to a small value, (e.g., 40 ms), in order to highlight the benefit of the proposal. The buffer dimension is calculated according to a low-pass filter processing as follows: Bi(n ) = k * Bi(n − e) + (l − k)* Bi ist (n )

(3.4)

where Bi(n) represents the average buffer dimension at the n-h interval of the queue i and Biist(n) the instantaneous value for queue I in the same interval. The parameter k determines the width of the low-pass filter and it is set to 0.99. A comparison of the static WFQ behavior with the weights configured to 0.10, 0.18, 0.32, and 0.4, respectively, which could be the initial values of the dynamic shows in Figure 3.12 that the rate of the traffic aggregates feeding each queue has the same mean value (i.e., they are composed of the same video flows) but different instantaneous ones, because the bursts that happen in different time intervals. The packet delays in the different queues for the static and dynamic WFQ, respectively, are shown in Figures 3.13 and 3.14. The results show that the static delay is more variable, because it depends both on the instantaneous rate of the incoming traffic and the assigned fixed weights.

queue 2

queue 3

queue 4

Rate (bit/sec)

queue 1

Time (sec)

Figure 3.12

Traffic aggregate rates for different queues [27].

3.1 Introduction

165

Figure 3.13

PDF curves for the average delays in the queues for static WFQ [27].

Figure 3.14

PDF curves for the average delays in the queues for dynamic WFQ [27].

Observing the traffic burst at 110 seconds for the third queue shows that how use of the dynamic algorithm reduces the delay value from the static WFQ case by 4.5 ms. The 99th percentile is under the 10 ms only in the fourth queue, in the third it exceeds the goal of about 1 ms. The performance of the first and second queue are worse. A dynamic WFQ allows for a better resource exploitation, trying to distribute the available transmission capacity in relation to both the QoS guarantees to be provided to each traffic aggregate and the time-variant bandwidth requirements [27].

166

3.2

Quality of Service

QoS Architectures Large software systems, such as a network management system, are a capital investment that operators cannot afford to replace every time its requirements change. Network operators are seeking cost-effective solutions to their short-term needs. All these reality-related issues are vital constraints that reflect on the QoS architecture designs. 3.2.1

Policy-Based Architectures

One approach to provide for flexibility and decrease costs is the use of policy-enforcing architectures. Policy-based management allows operators and network providers to deploy and correlate business strategies with the overall network actions [52]. Policy-based QoS control has already been introduced into the IP multimedia system (IMS) concept in relation to UMTS systems [53]. There, a policy decision function (PDF) for the provision of IP QoS services over the UMTS access network was introduced. Proposals have been made related to the extension of the IMS solution for the management of QoS over integrated scenarios, such as UMTS and WLAN [54]. The scope of this work was limited because it proposed that in order to handle the IP resources for QoS provisioning in each domain, the consistency of the policies applied in each one needed to be checked. The FP6 IST project EVEREST [52] proposed a QoS policy-based control in the scope of beyond 3G systems. The mechanisms were built around the concept of the UMTS architecture and allowed the integration of heterogeneous radio access networks. The underlying assumption was that in the considered scenario, common radio resource management (CRRM) functionalities were available in the RAN part. A CRRM function that was able to steer the traffic distribution among the RATs towards an optimal distribution, could provide a clear benefit by increasing the radio resource efficiency and improving the perceived service quality. As two important aspects, the identification of the involved entities and their interactions for enabling the policy-based QoS over a B3G system were addressed [52, 55]. The basic problematic of the QoS provisioning over a B3G network is shown in Figure 3.15. Each radio access network (RAN) would provide the user connectivity to the core network (CN) through specific attachment points and the gateways (GWs), through which the access network is connected to the external IP networks. The QoS management should provide a decision on which RAN is the most appropriate to handle a particular connection, and how the requirements can be balanced among the access part and the core network. A number of complex scenarios are possible where decisions can be taken according to many criteria, such as terminal capabilities, radio access network capabilities, user preferences, and network operator preferences. The FP6 IST project WINNER [24] and the FP6 IST project Ambient Networks [56] extended the policy-based network management for the provisioning of QoS to the scenario where one of the networks is a next generation system and where composition of networks is possible (i.e., the ambient network concept). In particular a

3.2 QoS Architectures

Figure 3.15

167

EVEREST approach towards QoS provisioning in a B3G system [52].

number of policies were proposed in relation to user context transfer during handover that would reduce the delays and improve the overall network performance. To enable efficient signaling and management between network and user terminal (UT), all profiles can be captured in the home operator domain for all the registered UTs [57–59]. The RAN is responsible for enforcement of the policy determined by the core network. The policy management is distributed between the HSS entity and the GW (see Figure 2.1). Further, mobility in the RAN is supported by traffic and control signaling from the UT to the BS that the UT is connected to, and also by the BS to BS control signaling. To ensure flexibility of the architecture, logical functionalities of the physical entities can be grouped according to the situation [57]. The interactions of the mobility management functions are shown in Figure 3.16. The interactions were derived from the required procedures identified for idle and active UTs in the scope of IMT-A candidate systems [57]. Therefore, Figure 3.16 does not represent a complete view with all the state-transitions but is rather simplified. After power on, the UT is authenticated and authorized, a paging area update is performed (both interacting with the UT register function) and an UT micromobility anchor is created. In idle mode only paging area updates and macromobility functions are performed by the UT if the UT detects respective movements. Both the network and the UT can trigger a state change from idle to active mode. In the network this is initiated by the UT anchor point function that triggers respective paging, in the UT this is done by direct cell selection and by performing the related admission control. In this case data is exchanged with the UT register function and the UTN micromobility anchor. In active mode the handover function decides about handover from one BS to another. If the decision was taken two processes run in parallel. The network performs the necessary routing changes and context transfers while the UT associates with the new cell. Finally the routing over the radio interface is updated.

168

Quality of Service Macromobility (including IP HO, Interran HO, and Global binding update)

Triggers/requires Authorization and authentication

e.g., key exchange

Paging area update (Micromobility function in UT idle mode)

Informs about paging area change

Creates/updates

UP micromobility anchor

Requests in case of UT idle and new data to be transmitted

UT register

Obtains paging area

Paging

Informs about new cell

Triggers

(New) cell association/RI link establishment

Initiate update

Route establishment for flows in RNs

Requires

Flow admission control

Path switch (forwarding of UP data during HO)

Figure 3.16

Requires/ interacts

Handover decision (micromobility function in active-mode)

Initiates

Initiates

Initiates

Flow context transfer

User context transfer

Mobility management interactions in a next generation candidate system [57].

This description assumes a single link between a UT and a BS. The need to support multiple links for one UT to multiple BS must be taken into account especially in the case of applying policies for RAN/BS associations. The procedure given here is based on the assumption that there is an UT active state where the network has detailed knowledge about the cell association and an UT idle state where only the rough location is known in order to enable power saving in the UT. The relation between the mobility functions is denoted by the text given at the arrows. Figure 3.17 shows the congestion control interactions related to flow handling. The left part shows the flow-related functions that all packets have to pass between the ingress endpoint of the RAN and the scheduler. The right part shows the congestion avoidance control functions and the flow establishment and release function. New incoming packets are analyzed and assigned to flows. If there is no existing flow, the flow establishment function invokes flow admission control to decide on acceptance of the new flow [57, 61, 60]. If positive, the new flow will be established and header compression and per-flow policy enforcement functions are configured. This and all following packets of this flow pass the header compression and policing functions. Directly before the packets are transferred to the MAC, the packet rate over the air is measured and the activity state of the flow is detected by the flow

3.2 QoS Architectures

Figure 3.17

169

Flow handling interactions for congestion control [61].

monitoring function. After a flow has become inactive, flow monitoring triggers the release of the flow. The load supervision gathers the flow specific load information of all monitoring functions and evaluates the load situation of the cell. After exceeding of the thresholds (overload warning and overload indication), load balancing is invoked that decides on the countermeasures to resolve the overload situation. The requesting of handover of flows to other cells or traffic reassignment to another BS as a means for QoS handling are assumed for the proposed policy-based RRM framework. If none of these exist, load has to be reduced by changing the QoS policing parameters up to dropping all packets of a flow. 3.2.1.1

Flow-Centric Addressing in IP Networks

A lot of research has been done in solving the QoS mobility issues related to flows in an IP networking environment. Many of the proposed solutions are based on end-to-end address update of the IP address of the flow end endpoints, (e.g., diverse

170

Quality of Service

solutions based on mobile IP (MIP), hierarchical MIP (HMIP), or HIP [62]). When HIP is used, the continuity of flows can be ensured for the control entities and applications running at or above the data transportation layer. When the end endpoints move, there is no continuity of flows at the network layer (IP layer). Every time when the locator (IP-address) of an end endpoint of a flow changes, all the signaling/routing states established for the corresponding existing flow have to be cleared and the required states have to be newly established. This may lead to a performance blackout of minutes, which is not always acceptable for some performance sensitive applications. The flow continuity in the cases of end endpoint changes are not even enabled in the layers above the IP layer. Because the two end endpoints of a flow can move (or even change) concurrently, all the solutions based on end-to-end address-updates need some third-party help-service from the background infrastructure, which does not move or change and is well-known for all computing entities of potential flow end endpoints. It is not really reasonable to require the existence of such infrastructure help-services in all possible networking environments (e.g., ad hoc networks, personal area networks, and body area networks) and communicating with such infrastructure help-services costs in general performance and resources. The concepts and the basic approaches to flow-centric addressing in IP networks, which eliminate the requirement to any infrastructural third-party service and minimize the performance degrading of a flow when its end endpoints move or change were studied by the FP6 IST project Ambient Networks (AN). The basic principles and state of the art of the IP protocols supporting mobility were described in Chapter 2. The fundamental drawback of the current technologies, which lead to the serious issues related to performance blackout and thirdparty service in mobile data communication over IP networks, is that at the IP layer source end endpoints have to address all user payload data packets, which are sent with the current locators of the corresponding destination end endpoints [62]. A flow may be considered as a data stream flowing in a logical autonomous reconfigurable tunnel connecting two mobile end endpoints. After the tunnel is established, it is theoretically not necessary for an end endpoint to know the current IP-address of the other end endpoint. All it has to know is the local entrance of the tunnel and all it has to do is to send related data packets to and to receive data packets from the tunnel. It is irrelevant if the other end of the tunnel moves/changes or not. The tunnel ensures that all data will be correctly delivered from one entrance to the other entrance, no matter if the entrances are moving/changing or not. When an entrance of a tunnel moves/changes, it is not necessary for this entrance to inform the other entrance. All it has to do is to inform the tunnel about the movement of its local entrance so that a possible minimal part of the tunnel can be rebuilt autonomously to connect the new entrance to ensure the most efficient data delivery. The approach of flow addressing, requests both the source end endpoint and the destination end endpoints of a data stream to address and to deal with only the local end of the related flow (i.e., the tunnel) between them, without taking care of the movements and changes at the other end of the same flow. In this way, the effect of the movement and change of an end endpoint of a flow is limited and localized without influencing the normal operation at the other end endpoint of the same flow. Because the effect and the requested modifications at an end endpoint of a flow are

3.2 QoS Architectures

171

most possibly localized and no change at the other end endpoint of the same flow is required, the related performance degrading can be minimized. Further, because there is no need for the two end endpoints of a flow to update each other to ensure the correct address-bindings at each side, there is no need to any third-party service to guarantee the rendezvous between the two moving or changing end endpoints of the flow. The different data packets of the one and the same flow may travel hop-by-hop along different routes from the source end endpoint (e.g., S) to the destination end endpoint (e.g., D) in an IP network. All these routes meet at some common points (e.g., X, Y, and Z) between the two end endpoints, where the routing and the other signaling states of the whole flow are established, monitored, and maintained. These points are called conjunction points (CPs). The two special CPs of a flow are its two end endpoints (e.g., S and D). This is shown in Figure 3.18. The groups of the subroutes, along which data packets of a flow are delivered between two neighboring CPs are called a subflow. A flow consists of a sequence of concatenated subflows. For example, in Figure 3.18, the flow (S, D) consists of subflows (S, X), (X, Y), (Y, Z), and (Z, D). When an end endpoint of a flow moves or changes, only the subflows nearest to that end endpoint have to be rebuilt. It is not necessary to always rebuild the whole flow completely from the other end endpoint. For example, when the end endpoint D moves or changes, it may inform the conjunction point Z about its new locator. Z does not move in relation to D, therefore, it is always reachable from D and there is no need to any third-party help. Z checks in this case if it is the optimal point to rebuild the connection to D, (i.e., a sequence of one or many concatenated new

Figure 3.18

A data flow from S to D over X, Y, and Z [62].

172

Quality of Service

subflows connecting Z and D. If yes, it starts the required signaling process immediately to establish a new connection to the endpoint D. Otherwise, it forwards the request to the next CP, (i.e., Y). This procedure is repeated until the required new connection is built from one of the CPs of the flow, which is possible nearest to the endpoint D. This approach seems optimal and easy. But it cannot be directly implemented in an IP network, because it is required in the IP network that every data packet sent by the source endpoint has to contain the current address of its final destination endpoint, (e.g., every packet containing payload user data sent by the end endpoint S has to be addressed directly with the current IP-address of the endpoint D. This requires end-to-end address-binding-updates and complete reestablishments of signaling states between the two endpoints of a flow, every time when endpoints move or change. This leads to the problems related to performance blackout and third-party rendezvous-service. The concept and the approach of flow-centric addressing enable an endpoint of a flow to address the flow (more exactly, the nearest subflow of the flow) instead of the other endpoint at the other end of the flow. To avoid unnecessary scalability issues and to improve routing efficiency a flow is identified by the identifiers of all its subflows. The identifier of a subflow consists of the following three parts: 1. The effective locator of the upstream CP, (i.e., the CP from which the subflow begins); 2. The effective locator of the downstream CP, (i.e., the CP at which the subflow ends; 3. A sequence number, with which the subflow is uniquely identified among all the subflows existing concurrently between the same upstream and downstream CPs. In an IP network the identifier of a subflow is a triple consisting of two IP-addresses and a sequence number. The length of an IP address is fixed. A sequence number with 16 bits should be long enough to distinguish all possible concurrent subflows between the same upstream CP and downstream CP. The IP addresses of the upstream CP and the downstream CP correspond to the source and the destination IP addresses in a normal IP data packet. Only the sequence number has to be carried additionally as an optional data. Instead of sending the user payload data packets directly with the IP address of the destination endpoint of the flow, the source endpoint sends all the data packets with the identifier of the next subflow of the flow, (i.e., its own IP address as the source IP address of the data packets, the IP address of the next downstream CP as the destination address of the data packets, and the sequence number as an optional information). The data packets will be delivered autonomously by the underlying IP network to the next downstream CP, where the identifier of the next subflow is found, for example in a table, according to the IP- address of the upstream CP and the sequence number. The data packets are then forwarded with the identifier of the next subflow. This procedure is repeated at every CP until the data packets arrive at the destination endpoint. Taking the flow shown in Figure 3.18 as an example, the data packets sent by S are addressed to X, then readdressed to Y at X, to Z at Y, and at last to D at Z.

3.2 QoS Architectures

173

The routing procedure at each CP is simple and straight and directly can be implemented in hardware. Such an approach makes the routing at the CPs as efficient as the normal IP routings. Flow Establishment

There are basically two possibilities to determine the optimal route from the source endpoint to the destination endpoint of a flow and all the involved CPs. The first one is to handle all CP capable nodes as an overlay and to calculate the optimal route only at this overlay [62]. The second one is to rely only on the routing capability of the underlying IP network. Here only the second possibility is described. The basic approach of the flow establishment is to use the router alert option (RAO) specified in IETF RFC 2113 to find and to signal all the involved CPs step-by-step. It is natural that before a flow is successfully established the source endpoint has to dig out somehow the current IP address of the destination endpoint. To establish the flow, the source endpoint has to create a signaling data packet with the current IP address of the destination endpoint and to put this signaling data packet to the underlying IP network with the RAO set. The signaling data packet is delivered hop-by-hop from the source endpoint towards the destination endpoint according to the routing strategy of the underlying IP network until the first CP-capable node is arrived. Alerted by checking the RAO, the CP catches the data packet and stops forwarding it. The signaling messages are then exchanged between the source endpoint and this CP and the first subflow is established. The CP creates a new signaling data packet with the IP address of the destination endpoint and to put this signaling data packet back to the underlying IP network with the RAO set. This process repeats until all the involved CPs are found, the last signaling data packet built by the last CP arrives at the destination endpoint, and all the corresponding subflows are successfully established. Taking the flow shown in Figure 3.18 as an example, a signaling data packet is created by S and addressed to D, initially. This data packet is caught by X, which builds a new signaling data packet addressed to D. The new signaling data packet is in turn caught by Y, which builds a new signaling data packet addressed to D. The signaling data packet sent by Y is then caught by Z, which builds a new signaling data packet addressed to D. Finally, the signaling data packet created by Z is received by D and a flow between S and D consisting of the subflows (S, X), (X, Y), (Y, Z), and (Z, D) is successfully established. If the destination endpoint of the flow moves or changes before or during the process of the flow establishment, the process fails. In this case the source endpoint has to dig out the new IP address of the destination endpoint and to retry the flow establishment process from the beginning. Because the user payload data packets of a flow are always addressed only with the identifier of the next subflow of that flow, it is not necessary for the related endpoints to update each other when they move or change. This makes it possible and easy to limit and to localize the effect of the movement or change of an endpoint. When an endpoint of a flow gets a new IP address, it requests the next CP of the flow for a new connection (a sequence of one or several new subflows). The CP checks if it is the optimal point to establish the new connection to the new IP address

174

Quality of Service

of the endpoint. If it is not, it forwards the request to the next CP in the same direction. This process repeats until the optimal point is found at a CP, which uses the same signaling process described in the last section to establish a new connection (a sequence of one or several new subflows) to the moved or changed endpoint. The resources allocated for the obsolete subflows are released. The flow is updated, but for all the CPs including the unmoved endpoint behind the CP of the optimal point, there is change at all. Taking the flow shown in Figure 3.18 as an example, when D moves or changes it sends a request to Z. Z checks and determines that it is not the optimal point for building a new connection. Z forwards the request to Y, which decides to establish a new connection to the new IP address of D. A sequence of new subflows is then established from Y to D, probably involving some new CPs. The obsolete subflows (Y, Z) und (Z, D) are removed. The flow is updated. But from the viewpoints of S and X there is no change. Because the effect and influence of the movement and the change of the endpoints of a flow are most possibly limited and localized, the performance degrading is minimized [62]. In most cases only the nearest subflow has to be reestablished, because most of the MNs usually move continuously. The nearest CP does not move or change in relation to an endpoint and is always reachable for it, therefore, there is no need to any third-party rendezvous-service. RoutingTable at a Conjuction Point

At each CP-capable node a routing table exists for each of its IP addresses, which is maintained and updated during the signaling processes of flow establishment. Figure 3.19 shows the logical structure of a routing table. Each entry of this two-dimensional table stores the identifier of the next subflow of a flow in the downstream direction. The flow, which the corresponding subflow

Figure 3.19

Routing table at each CP [62].

3.2 QoS Architectures

175

belongs to, is identified by the exact position of the entry in the table. The column position of the entry is determined by the upstream CP address carried in the field of the source IP address of a received data packet, while the row position of the entry is determined by the sequence number carried as optional information in the same received data packet. At each CP, including the destination endpoint of the flow, when a user data packet is received the following processes take place: •

•

•

•

•

The upstream CP address and sequence number of the previous subflow of the corresponding flow are taken out, respectively, from the field of the source IP-address and from the field of the related optional information of the data packet. A special sequence number, (e.g., “0”, is reserved to indicate that the destination endpoint of the flow has arrived. If the sequence number carried in the received data packet is 0, the user payload data is forwarded to the upper layer application for further processing and the process ends successfully; The table entry, where the identifier of the next sub-flow of the same flow is stored has to be located. The row and column positions of this entry are calculated respectively from the sequence number and the upstream CP address of the previous subflow. The identifier of the previous subflow carried in the data packet is then replaced by the identifier of the next subflow of the same flow stored in the table entry found before. The updated data packet is sent to the next downstream CP by the underlying IP network.

At the source endpoint of a flow, the upper layer application uses a simple flow index, (e.g., an integer, to address the user payload data of the flow. The index is created during the flow establishment (see more in the next section) and can be used to determine the table entry, where the identifier of the first subflow of the flow is stored. The corresponding fields of the data packets are then filled with this subflow identifier and sent to the next downstream CP of the flow by the underlying IP network. This process is very simple and easy. It can be implemented directly with hardware so that the routing can be as efficient as normal classical routing in IP networks [62]. When an endpoint of a flow moves or changes (i.e., it gets a new locator), it is very crucial for minimizing the unavoidable performance degrading to determine fast and efficiently the optimal CP, from which a new connection, (i.e., a sequence of new subflows, is to be established to connect the moved or changed endpoint). A flow may cross the boundary of a moving network connecting to outside by mobile routers. When such a network moves, the locators of its mobile routers change when observed from outside the network. But the internal structure of the mobile network remains the same. From the points of view of a flow this means a sequence of concatenated subflows, from one endpoint to an intermediate CP, say CP-mobile, implemented at the mobile router of the moving network, move together. Within

176

Quality of Service

the moving part there is basically no change. The question is just how to rebuild the connection between CP-mobile and the most possible nearest CP of the unmoved part. Because the effect and the influence of a moving end point or a moving mobile network is limited and localized with the concept and the approach of flow-centric addressing, in principles, multiples concurrent movements or changes of different CPs (including the both endpoints) of a flow can be handled in parallel without interdisturbances. 3.2.2

Dynamic Internetworking

The commercial success and widespread use of the Internet have lead to new requirements, which include internetworking over business boundaries, mobility, and multihoming in an untrusted environment that supports QoS. One approach to satisfy these new requirements is to introduce a new internetwork layer [63]. Such a layer would run on top of the different versions of IP, but could also run directly on top of other kinds of network technologies, such as MPLS and 2G/3G PDP contexts. This approach would enable connectivity across different communication technologies, and would be an enabler to realize dynamic network composition. The envisioned future networking landscape is largely characterized by its dynamic nature, its heterogeneity, and ubiquity. There are a number of challenges that an internetworking framework would face and a set of functionalities it would need to provide. Dynamic control of internetwork QoS agreements can be implemented as a module in an overall internetworking architecture in order to provide for advertisement, negotiation, realization, and monitoring of QoS agreements, as well as an internetwork signaling [63]. The effective capacity of the network depends on how well available resources can be utilized and, typically, this is not an issue under a light network load, but it becomes increasingly important, considering how a network behaves under a heavy load. Inefficient network use might lead to temporary load peaks under heavier traffic conditions affecting service availability and quality [64]. The IST project Ambient Networks developed a dynamic internetworking architecture, also called the node ID architecture to provide connectivity in a heterogeneous and dynamic network environment. The architecture has a naming system that provides separation of node identities from their location by adding a node-naming layer using cryptographic node identities on top of the current network technologies. A unique feature in the design is to perform network routing in the naming layer using the identities with the purpose to provide mobility, multihoming, and support for heterogeneous network technologies. The two main concepts in the design are locator domains (LDs), providing an abstraction of the addressing domains of network technologies and node identity routers, which are the devices performing routing between the locator domains at the node naming layer. A flexible forwarding mechanism at the level of the cryptographic identities is a centerpiece of the architecture. The forwarding mechanism uses a routing hint to

3.2 QoS Architectures

177

enable scalability as well as to provide support for multiple routing schemes with different and complementary characteristics. The design space for dynamic internetworking within the legacy TCP/IP framework is restricted by the dual role of the IP address as both a locator and a host identity. As a consequence, to support the TCP connection continuity, the IP address of a host must not change when the topology changes. Such restrictions on the design space have resulted in the mobile IP solution for host mobility [65] and the NEMO solution for network mobility [66]. This class of solutions is based on indirection via one or several mobility agents along the data path and therefore suffers from the problems of suboptimal routing and tunnel overhead. When the identity of a host is separated from its locator, new types of multihoming and mobility solutions become feasible. One example of such a solution is the HIP mobility and multi-homing framework [67, 68]. Here, TCP connection continuity is based on the semi-static and cryptographic host ID [63]. The IP address of the host is independent of the host ID and can be updated as needed when the topology changes without the disruption of the TCP connections. A host registers its current IP address with a rendezvous server (RVS). The IP address of the RVS itself is semistatic and is stored in the DNS in a new type of resource record for the host. To initiate a session, the source host uses the DNS to resolve the fully qualified domain name (FQDN) of the destination host into the IP address of its RVS. When initiating a session, the source host then reaches the destination host via the RVS, and learns the current IP address of the destination host. The source host then uses this IP address as a destination address, and sends packets directly to the destination host without any data path indirection via the RVS. The node ID architecture generalizes the HIP approach of using a name system to retrieve a locator for an entity that can support reachability of a destination node. In the node ID architecture, the generalized pointer that is retrieved from the name system (e.g., DNS) is called a routing hint. The routing hint for a node points to any type of network entity that supports reachability of that node. The network entity can for example be a forwarding entity, such as a core node ID router (CNR) or a mobility agent that holds forwarding state for the destination node. Alternatively, the network entity can be a lookup system (e.g., an RVS) that stores the current locator of a network entity that holds forwarding state for a destination node. The definition of the routing hint is intentionally flexible to avoid an overly rigid architecture that prescribes specific mechanisms. This flexibility allows for a wide range of approaches to dynamic internetworking, (i.e., to routing, multihoming, and mobility). Solutions can thereby be locally optimized for the characteristics of specific edge networks. For example, different solutions for aggregation of the routing state can be employed in large fixed access networks on the one hand, and in highly dynamic edge networks on the other hand. Several approaches to dynamic internetworking in the edge topology exist [63]. When initiating a session, the source node queries the name system for the node ID forwarding tag (NIFT) and the routing hint of the destination node. The source and destination NIFTs as well as the source and destination routing hints are inserted in the packet header. The NIFTs are never changed along the end-to-end path. The routing hint can be updated by an NID router.

178

Quality of Service

An NID router forwards a packet based on the destination NIFT. If the NID router does not hold forwarding state for the NIFT, it forwards the packet along a default path or based on the routing hint. The semantics of a routing hint is specified by a type field in the packet header. The type field supports the following two types of semantics of the routing hint: 1. Cryptographic hash of the cryptographic ID of a network entity; 2. Hierarchically structured forwarding tag. A type 1 routing hint for a node is a tag that identifies a network entity that supports reachability of the node. The NID router that processes a packet with a type 1 routing hint uses it as a forwarding tag or as a lookup key depending on the routing context. For example, if the type 1 routing hint in the header of a packet matches a forwarding table entry in a NID router, the NID router uses the routing hint as a forwarding tag to forward the packet within the edge topology. Alternatively, to forward the same packet across the core network, a CNR uses the type 1 routing hint as a lookup key to map it to a core locator of a CNR, through which the destination node is reachable. A type 2 routing hint for a node is a core locator for a network entity, through which the node is reachable. Examples of such network entities are a CNR or a mobility agent. The core locator may be hierarchically extended with a forwarding tag that is valid in the local edge topology along the data path between a CNR and the NID router where forwarding based on the NIFT starts. Because the extension is only processed by NID routers in this local edge topology, the semantics of the extension can be specific for the routing approach employed in the edge topology. For example, the extension can be the cryptographic ID of the LD that the end node is attached to or it can be an encoding of the internetwork path from the CNR to the end node. To allow for indirection via a separate lookup system, the name system can return a routing hint of type 1 or 2 where the type field indicates that it is a referral. This referral is used as a forwarding tag to a lookup system such as an RVS or a locator construction system. The NIFT for the node associated with the routing hint is then used as a key to this lookup system. The referral routing hint is inserted by the source node in the packet header, just as a nonreferral routing hint. An NID router that cannot forward a packet based on NIFT or the default path information inserts the referral routing hint in the header of a signaling packet and sends it to the lookup system to query it for a nonreferral routing hint of type 1 or type 2. This nonreferral routing hint is then used for the continued forwarding towards the destination. An alternative to introducing a specific type value for referral routing hints is to introduce a route redirect mechanism. A NID router then does not need to distinguish between referral and nonreferral routing hints. A NID router that forwards a packet based on a routing hint that addresses a lookup system will forward the packet to the lookup system just as to any other NID router. The lookup system will use the destination NIFT in the packet header as a lookup key, and retrieve a new routing hint that points at a NID router that holds forwarding state for the destination NIFT. The new routing hint will be returned to the first NID router in a route

3.2 QoS Architectures

179

redirect message. This NID router will store the new routing hint and use it when forwarding subsequent packets with the same destination NIFT. The routing hint allows for decoupling of the routing approaches in the source and in the destination edge networks. The destination routing hint has a semantic that depends on the core network technology (type 2 semantic), and in some cases on the routing approach in the destination edge network. However, the semantic is independent of the routing approach employed in the source edge network. Therefore, a source node can be multihomed to networks with different routing approaches without any impact on the routing hint of a destination node in a remote network. The already described routing hint plays an important role for mobility by providing a simple and effective mechanism for routing to a mobility anchor point for a node. The routing hint relieves the name resolution system from having to support updates due to mobility. A common problem of many mobility schemes using the concept of a home agent is that routing may become very inefficient. The node ID forwarding mechanism therefore has a route redirect function. A NID router detecting that the next hop is in the same locator domain as the previous hop in the forwarding path can issue a route redirect message to the previous hop with information about a more direct route. This function is in principle very similar to the ICMP route redirect for IP. Multi-homing is supported by allowing multiple routing entries for the same destination, each entry representing one of the options for reaching the destination. The multiple routing entries can be held at one or several multihoming anchor points, and/or show up as multiple routing hints. 3.2.2.1

Routing between IPv4 and IPv6 Core Networks

The Node ID architecture enables coexistence of the IPv4 Internet with the IPv6 Internet, effectively removing the problem of migrating from IPv4 to IPv6. The solution proposed by [63] was based on the following two ideas: 1. Use of IP anycast [69] addresses on a large number of gateway NID routers interconnecting the IPv4 world with the IPv6 world; 2. Use of the routing hint to provide the routing information needed to route over to the other side. IP anycast on a global scale is implemented as a feature of the BGP routing protocol. The same IP anycast address is assigned to a set of nodes providing the same service. The address is then announced in the BGP protocol from the location of each node. When a client uses that IP anycast address as the destination, the routing system delivers the packet to one of the nodes having that address. IP anycast thus enables service redundancy. IP anycast is in general used for replicating some of the root DNS servers. Figure 3.20 shows the solution in more detail. There are three gateway NID routers (NR1-NR3) interconnecting the IPv4 and IPv6 Internets. In a realistic scenario a much larger number is needed, perhaps tens of thousands. There is one IPv6 anycast address to reach the IPv4 world. All NID routers are configured with the same IPv6 anycast address on the IPv6 side, and like-

180

Quality of Service

Figure 3.20

Routing between IPv4 and IPv6 core networks [63].

wise for the IPv4 side. It is assumed that the anycast addresses are entered as extra information in the DNS for the communicating nodes. An alternative would be to hardwire the anycast addresses into the protocol. Having the addresses in the DNS also enables use of site-specific gateways not using IP anycast. If node B wants to communicate with node A, it sends a packet with NID(A) as destination, the IPv4 anycast address as IP destination, and A’s IPv6 address as the (destination) routing hint. The IP routing system takes care of delivering the packet to the closest, in the metric of the routing protocol, gateway NID router with this anycast address. The gateway NID router then rewrites the packet using the routing hint as the new destination IP address, and adding the source address (B’s IPv4 address) as a source routing hint. For the return path, A has to use the received source hint as the destination hint, so the gateway finds the way back to B. It is probably useful for the gateway to use its regular unicast IP address as the source address of the rewritten packets, so that the return path goes through the same gateway NID router as the forward path. It is important for scalability that the gateway NID routers only depend on the routing information in the routing hint for their operation. When implementing the node ID architecture using session state setup, for instance as an extension to HIP, it is however unavoidable to store session state in these NID routers. Node mobility can be hidden from the core network as long as the movement takes place inside the same edge topology, (i.e., as long as the routing hint does not change). The larger the physical extension of the region associated with a given edge

3.2 QoS Architectures

181

topology, the greater the probability that during a communication session, the mobility of a node or a network takes place within the same edge topology. During internetworking between dynamic networks, the access control server entities of each network need to share information about their own network (e.g., parameters, services, etc.). This exchange can be related to a checkup of available resources and mechanisms. This first communication (independent of final composition) to share information between the networks could be managed by the interaction of the flow-management signaling interfaces Based on a flow abstraction of nodes, links and internetworking paths, the flow management procedure is a single, flexible process and message format, allowing negotiation of abstracted resources (the flow abstraction) through different message types (advertising, discovery, setup, teardown, etc.). In particular, the endpoint services are negotiated including the access network services (e.g., access advertiser, access discoverer, access selector, access provider, or access broker) as well as routing, data transit, and basic connectivity services. Further, the procedure allows negotiation of flows as an abstraction of paths and related data-transfers, including characteristics such as protocol stack, routing characteristics, access technologies, and required QoS performance. It allows for defining the endpoints, described through the node ID, related locators, and network characteristics. Multiple locators of different technologies can be specified for the same endpoint, as well as different locator domains and address resolution schemes. State information may be associated with each locator for paging purposes. The QoS performance of a flow can be described in terms of bit rate, delay, error rate, and priority. The above flow management procedure allows for defining, negotiating, and dynamically using standard QoS classes. Indication of availability of the transport services of specific QoS can be given in terms of maximum user bit rate and quantity. Analysis [63] shows that it is difficult to develop a single routing protocol that can satisfy every possible routing requirement in all scenarios. All routing protocols and systems must make compromises between functionality, scalability, and ability to respond to changes and a potential migration path. The ideal interdomain routing system will balance these compromises and, in particular, offer different solutions within regions with different requirements [70]. Network bandwidth and latency are some key constraints on how fast routing protocol updates can be disseminated (i.e., how fast the routing system can adapt to changes). Therefore, the routing architecture should not make undue assumptions about bandwidth available [63]. Furthermore, both bandwidth and latency pose a much more serious problem in the rapidly increasing number of wireless networks at the edge of the Internet. 3.2.2.2

Network Capability Aware Routing

The calculation of a route from an arbitrary source to an arbitrary destination across a global network taking network capability restrictions into account is a hard problem. Doing this across a highly dynamic topology adds to the complexity. Reference [63] simplified the problem by assuming that the core network is semistatic

182

Quality of Service

and overdimensioned to such an extent that the performance would be good enough regardless of the selected core network path. Based on this assumption a routing solution was designed that divided the original hard problem into the three simpler problems of finding a path (1) from the source to the core network, (2) across the core network, and (3) from the core network to the destination. The routing mechanism in each of these three legs operates independently of, and in parallel with, the routing mechanism in the other legs. Finding a path from the source to the core network in the first leg is relatively straightforward, and can be based on a capability aware distance vector protocol that announces the distance to the core network per capability class across the edge topology. The routing across the core network in the second leg is done by legacy backbone routing protocols such as border gateway protocol (BGP) and is done independently of the routing across the edge topologies. Finding a path from the core network to the destination in the third leg is more complicated. One solution is to install routing state per destination and per capability class in the edge topology all the way up to the CNR, but this solution does not scale well. A more scalable solution is using a distance vector protocol that announces the distance to the core network per capability class. This routing information is of no use when forwarding a packet from the core network across the edge topology towards the destination, because the distance vector protocol provides information about the shortest path in the reverse direction. Figure 3.21 shows the signaling of a distance vector routing protocol that announces the path length to the core network for two capability classes. All network entities and links along an announced path fulfils a specific capability criterion. The capability aware distance vector protocol constructs routing hints that describe a path between the core network and a network entity that fulfils specific capability criteria. Each network entity registers its neighbors as well as its capability parameters related to those neighbors [71]. Examples of such capability parameters are QoS parameters, such as bandwidth on the link to the neighbor network. The capability parameters are used by the routing protocol when processing the distance vector routing information that is received from the neighbor network entities.

Figure 3.21 Capability aware distance vector routing protocol announcing the shortest path to the core network [63].

3.2 QoS Architectures

183

A topology change is caused by a network entity or an internetwork link that appears in, or disappears from, the topology. The network entities that are directly connected to such network entities or links must register this event with their attachment registers. Also, the distance vector protocol announces a new distance to the core network based on the new topology. If the topology change breaks a path used by a communication session, a routing hint corresponding to a new path must be constructed. These tasks can be finalized within a few hundred milliseconds even in complex edge topologies. This is a significant improvement in the routing convergence time and in the amount of route update signaling compared to traditional interdomain routing solutions, such as BGP. This makes the approach useful not only for routing, but also for host and network multihoming, as well as host and network mobility. The feasibility of the dynamic internetworking architecture was investigated by simulations in a proprietary packet-level simulator [63]. A simplistic mobility model was used. In the proposed scenario, the moving networks and hosts are initially positioned randomly within a rectangular space, and then start moving in random directions and with random speeds uniformly distributed between zero and a maximum speed v. The hosts attach to the moving networks that are within a specific range r, and each moving network also attaches to other moving networks and CNRs that are within a range r. The time varying topology formed with this simulation model has an average hop count of three and a maximum hop count of seven from a host to a CNR along the default path. The simulated topology consisted of 20 core edge routers, 200 moving networks, and 1,000 hosts. No simplifying assumptions about a tree topology had been made. Figure 3.22 shows the fraction of the host population that establishes end-to-end connectivity as a function of time after the initial state where all network entities are detached. Traces are shown for three different values of the maximum speed parameter v. This speed parameter is related to the range limit r d so that v = 1 corresponds to a speed of 1% of the range limit per second. At this speed the topology changes at such a rate that 15% of the hosts need to update their source or destination routing hint every second. For larger values of v a substantial fraction of the host population has to update a routing hint more than once before connectivity is established, which is reflected in the longer convergence time of the simulation results. The simulator does not model the impact of limitations in link bandwidth, or limitations in the capacity for the processing of the network signaling. The simulation results thus reflect the impact of packet loss and changes in the topology due to mobility events, but not the impact of link or processing capacity limitations. The following simple model can be used to calculate the maximum handover time for a single mobility event [63]. The handover time Thandover depends on the time Tdetect for the source entity to detect that a routing hint is invalid, the time Tretrieve it takes to retrieve a new routing hint, the time Te2e it takes to send a packet with the new routing hint to the destination, and the time it takes for the routing protocol to converge to the new topology. The above procedures occur sequentially, except for the update of the routing state, which occurs in parallel and does not contribute to the handover time. Therefore, the following relationship holds:

184

Quality of Service

Figure 3.22 Fraction of the host population that has established end-to-end connectivity as a function of time after the initial state where all network entities are detached from each other. Traces are shown for three different values of the speed parameter v [63].

Thandover = Tdetect + Tretrieve + Te 2 e

(3.5)

A three-leg path with h1 number of network hops on the first leg, Tcore packet delay over the core network, and h3 number of network hops in the third leg can be assumed. Further, it would take the time Thop for a packet to traverse a network hop, and the time Tprocess to process a locator construction request and forward it. The end-to-end latency is then: Te 2 e = ( h1 + h3)* Thop + Tcore

(3.6)

The maximum handover time is caused by mobility events close to the destination end system, because the time to return an error message to the source is maximized [63]. In this case: Tdetect = Te 2 e

(3.7)

For the source to retrieve a new destination routing hint, the signaling packets have to traverse the first leg back and forth, and also to be processed by the attachment registers associated with the network entities in the third leg: Tretrieve = 2 * h1 * Thop + h3 * Tprocess

Then:

(3.8)

3.2 QoS Architectures

Thandover = 4 * h1 * Thop + h3 (2 * Thop + Tprocess ) + 2 * Tcore

185

(3.9)

In the simulations, all T-values are 50 ms. For two network hops in each of the first and third legs, for example, the maximum handover time for a single mobility event is 800 ms according to this model. Since the same mechanisms are used to handle rehoming events as to handle mobility events, the rehoming time can be calculated using the same model [63]. Should ISPs and operators largely adopt NID technology and locator domain topologies of a certain depth exist, the future core network would be much smaller than today. Structured routing hints could then significantly improve core scalability (and speed convergence) by encouraging aggregation. This is the basis of the “hierarchical locator” approach, designed to allocate addresses to follow the physical network wherever possible. The general tendency to match existing Internet topology should also aid migration. However, these advantages must be traded off against the difficulty of motivating core changes and the need for a globally administered address space. 3.2.2.3

Internetwork QoS Agreements

The internetwork QoS agreements (INQA) [72, 73] is an internetwork QoS negotiation protocol based on bilateral agreements that was studied and specified in [56]. According to INQA, a network can have one of the following three roles: 1. Provider that advertises service level specification (SLSs) to other networks; 2. Customer that negotiates SLSs; 3. Customer-provider that resells SLSs advertised by its neighbors. The INQA protocol maintains SLS state in adjacent networks, without the need of refreshing messages since each SLS has an expiration time. Consequently, the state is kept until the SLS is expired. In order to control the SLS state, INQA uses the following four message types, namely: advertisement, negotiation, acknowledgment, and monitoring. The advertisement message is used as an announcement for unexploited SLSs to a set of neighbor networks. The negotiation message is used by a customer or a customer-provider to reserve previously advertised resources. After a successful negotiation (initiated by an acknowledgment message sent by the provider), a new SLS state is allocated. In nontrusted environments, a customer network may query (with a monitoring message) the provider network about the level of the provided service in order to check its consistency to the negotiated SLS. To check the authenticity and integrity of the monitoring message and its corresponding reply message, neighboring certificates can be used [63]. In general, the INQA protocol boosts the routing mechanisms studied in WPE with a suitable tool to assess the capability of available paths across different networks. The SLSs include negotiated QoS-related parameters such as latency, packet loss ratio, and jitter, which can be used in the corresponding routing metrics to calculate and select the minimum-cost path according to the traffic class, user or network priority, requested QoS level, amd so forth. The original INQA provides only bilateral internetwork negotiations between topologically adjacent networks. An

186

Quality of Service

extension allowing bilateral end-to-end QoS negotiations between nonadjacent networks was proposed and evaluated in [74]. The proposed extension can provide a straightforward assessment of the capability of a path that traverses several networks from the core network to the destination node. This path capability assessment could be used by the routing mechanisms to assign different weights to each path depending on the traffic class. 3.2.2.4

Adjustment of QoS Parameters

The adjustment procedure for QoS parameters is useful inscalability evaluations and is presented here for a linear topology with 10 networks in the backbone line: one provider network and one customer network at each edge of the backbone, and eight customer-provider networks between the former two [62]. Figure 3.23 shows a variable number of customer-networks (from 1 to 10) connected to each customer-provider network, depending on the details of each particular experiment. Furthermore, each customer-network consists of 10 local hosts, which are the end users of the traffic assurances. Each end-host runs three different applications (in Figure 3.23, 3 appl represent the three assigned application to each end-host). For each experiment, the total transmitted data (in number of messages and bytes), the convergence time (in seconds), the memory-state (in number of stored messages), and the satisfied applications ratio were measured. The ratio of the number of matched negotiation profiles was illustrative to the total number of customer assigned negotiation profiles. All the experiments have a nondeterministic nature. Consequently, each experiment was executed a number of times using different initiation values. In the experiments, only the provider-network advertises resources. SLSs are assigned to the provider-network in the beginning of the experiment. It is assumed that each customer-host runs three applications. Practically, three different random-generated negotiation profiles (one for each application) are set to each cus-

Figure 3.23

Simulation setup for scalability analysis [62].

3.2 QoS Architectures

187

tomer-host. The bandwidth parameter of the negotiation profiles is set based on the bandwidth requirements analyzed in [41]. Each customer-provider is connected with 10 customer-networks and defines the type of SLS offers that it is willing to accept, reflecting the needs of its local customer-networks and thus their customer-hosts. The bandwidth associated with each customer-provider’s negotiation profile is obtained by summing the bandwidth of similar negotiation profiles/classes of its customer-networks. In case of INQA, a customer-provider network accepts any offer (advertised SLS) that matches one of its negotiation profiles. Although the offered SLS may not match any of its negotiation profiles, the customer-provider network will always accept the SLS, with the intention of “reselling” it to other customer-provider networks. It can be assumed that the assigned bandwidth to the provider is randomly estimated using a uniform distribution between the two boundaries [62] according to (3.10). min_ Bandwidth = max{TR} − 10 max_ Bandwidth = 2 max{TR}

max{TR} − min{TR} 100

(3.10)

TR represents the total required bandwidth for a specific application. In order to have unsatisfied applications, the value of the minimum bandwidth (min-bandwidth) to a value that is 10% lower than the total rate. Reference [75] recommends a classification of all applications into eight network classes, according to their special demands in terms of delay, jitter, and packet losses. Here, the same classes (except class 5 that is related to the best-effort service) are used for any generated SLS. Each SLS is defined in terms of delay, loss, jitter, and bandwidth. The delay, jitter, and packet loss that are sold by each network to the next one are computed as follows: DP =

DT m+1

JP =

JT m+1

LP = 1 − m + 1 1 − LT

(3.11)

where m represents the position of the customer-provider networks in the backbone line (from left to right in Figure 3.23 starting from m = 1), and DP, JT, LT are the maximum tolerable end-to-end delay, jitter, and loss for a specific class, respectively. Furthermore, a 1% probability of having insufficient resources in order to produce results with unsatisfied customers has been introduced. The scalability properties of two signaling methods using two different scenarios were evaluated. In the first scenario, INQA and INQA-VAR were evaluated when the number of the assigned customer-networks increases. The number of customer-networks was adjusted from 1 to 10 and the number of SLSs was kept fixed (equal to 10). The objective was to explore the impact of the number of SLSs in the system by attaching a fixed number of 10 customer networks to each customer provider and by increasing the number of SLSs from 1 to 10. Figure 3.24 shows that the INQA-VAR signaling method converges more than three times faster than INQA. This is because the intermediate customer-providers operate as transit networks that forward any SLS offer without additional checks, because they do not have any assigned negotiation-profiles.

188

Quality of Service

In contrast, the INQA intermediate customer-providers spend extra time checking each SLS and iterate through all negotiation profiles until a match is found. The number of customer networks impacts the convergence time of the INQA-VAR method slightly. The convergence time increases by 0,74% for each new customer network, whereas in INQA it is almost stable. In INQA-VAR, if a negotiation profile is matched, a QoS agreement between a customer and the provider would be set up. The end-to-end method of INQA-VAR introduces extra communication overhead because all customers need to establish an agreement with a single provider. This is shown in Figure 3.25 where it can be seen that the INQA method transmits fewer messages (and thus bytes) than INQA-VAR (i.e., 44,44% less bytes). Consequently, their messages need to traverse a number of hops. In contrast, the bilateral method of INQA is based on local agreements between two neighboring networks. While the INQA signaling method establishes an agreement between a provider and a next-hop customer, in INQA-VAR the same agreement is taking place between a provider and a customer regardless of its location in the topology. The transit networks situated between the provider and the customer (negotiating for the offered resources) assist to the maintenance of this agreement by keeping it in their databases. In INQA-VAR, the overall number of messages kept in the databases is related to the distance (in hops) between the customers negotiating for the resources and the provider. For the same ratio of satisfied applications, INQA stores almost half of the number of messages in memory. This is shown in Figure 3.26. Figure 3.26 shows that INQA is more efficient in terms of memory consumption (55,05% less memory consumption). Finally, Figure 3.27 shows that the two protocols satisfy the same number of applications.

450

Time (ms)

400 350 300 250 1

2

3

4

5

6

7

8

9 10

Number of neighbors Figure 3.24

Convergence time as a function of the number of customer networks [62].

3.2 QoS Architectures

189

300000 Bytes transmitted

250000 200000 150000 100000 50000 0 1

2

3

5

4

6

8

7

9

10

Number of neighbors INQA Figure 3.25

INQA-VAR

Communication overhead as a function of number of customer networks [62].

Number of messages

5000 4000 3000 2000 1000 0 1

2

3

4

5

6

7

8

9

10

Number of SLSs

INQA

Figure 3.26

INQA-VAR

Memory consumption as a function of the number of SLSs [62].

The two methods end up in the same stable state, where resources are allocated to each node in the same manner. However, they do not achieve a rate of 100% satisfied applications (even for more than seven SLSs). In order to achieve more realistic results, a uniform distribution in the assignment of the QoS requirements of the networks can be used. This introduces a probability 1% of insufficient delay, 1% for insufficient jitter, 1% for insufficient loss and 10% for insufficient bandwidth. Figure 3.28 shows that the smaller convergence time of INQA-VAR prevails even with an increasing number of SLSs (i.e., converges almost three times faster than INQA).

Quality of Service

Satisfied applications ratio

190

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 1

2

3

4

5

6

7

8

9

10

Number of SLSs INQA Figure 3.27

INQA-VAR

Satisfied applications ratio as a function of the number of SLSs

Although the number of SLSs significantly impacts on the convergence time of INQA-VAR (i.e., a 1.34 % increase for each new SLS), INQA needs a fixed amount of time to converge (i.e., 446 msec for any number of SLSs). When the QoS controller releases more than 7 SLSs, the redundant SLSs (8th, 9th, 10th) are a repetition of the previous ones (specifically 1st, 2nd, and 3rd), because the classification of traffic is up to seven classes. In case of more than seven SLSs, the convergence time of INQA-VAR appears stable. For example, the case of ten SLSs, the last three SLSs are going to be negotiated only by a customer, which remains unsatisfied with the first three SLSs. With the existent internetwork QoS negotiation and provision strategies [62], INQA provides an efficient alternative which can be easily implemented as an extension of the BGP, for example. The flexibility that INQA provides to network operators and providers to deal with QoS issues negotiations represents a big progress in the research field on this area.

3.3

QoS Testing The coexistence and interoperation requirements for next generation networks creates a number of open research and standardization issues making the necessity of testing an important key enabler towards the transmission of existing wireless networks to the next generation ones. One requirement for reliable B3G testing is the formation of big infrastructures that provide advanced testing facilities incorporating a number of hardware and software components, clusters, and testbeds. Real-time simulation is another accurate, convenient, and cost-effective solution to evaluate protocols in real time. Simulators cannot reliably represent reality because intrinsically such models are based on problem simplification and abstrac-

3.3 QoS Testing

191

Time (ms)

450 400 350 300 250 1

2

3

4

5

6

7

8

9

10

Number of SLSs

INQA Figure 3.28

INQA-VAR

Convergence time as a function of the number of SLSs [62].

tion, focusing only on a specific protocol or algorithmic function of great interest, each time. A testbed implementation is an expensive way of performance evaluation that gives a possibility for real-time element operations but some drawbacks are that a testbed can become useless and create misleading results if some specific network conditions and traffic dynamics never occur during a test. Also, any testbed trial is dependent on the operating system that hosts it. If some software modules required for a trial have not been implemented, it may be time wasteful to program all of them. Furthermore, setting up a wireless testbed, in particular for the evaluation of QoS mechanisms, requires that several software modules related to the wired and the wireless domain are available, in order to ease the integration process. Section 3.3 describes some of the achievements under the umbrella of the FP6 IST program in the area of experimental set ups for validations of QoS mechanisms. 3.3.1 Virtual Distributed Testbed for Optimization and Coexistence of Heterogeneous Systems

The FP6 IST project UNITE [1] developed a virtual distributed testbed (VDT) that offers the capability for advanced next generation radio resource management testing in the context of beyond 3G systems. In particular, the testbed is suitable for the testing of algorithms designed for cross-layer and cross-system optimization. The UNITE platform integrates independent physically/geographically distributed simulation clusters and realizations of optimization algorithms in order to allow for intersystem and cross-layer optimization studies in heterogeneous networking environments. Towards this end, two main functional requirements were addressed. The first was the derivation of a simulation facility for composite wireless networks by interconnecting existing simulators of diverse RATs running on different platforms. The second was the incorporation of facilities for joint radio resource management (JRRM).

192

Quality of Service

The designed VDT is structured around an event-based logic, its macroscopic picture resembles an event-based distributed system. This created an event-based virtual distributed testbed that can be used for exhaustive B3G cross-layer/cross-system testing. The VDT can be enhanced in a straightforward manner in order to constitute a complete end-to-end experimental infrastructure. Towards this direction, a VDT module could be extended to be a streaming server, a codec/decodec/ transcoder, a license server, a terminal, a sensor, and so forth. This allows experimentation for both, end-to-end horizontal service provision (i.e., user-application-network) and vertical cross-layer optimization concerning all layers from physical up to application. A testbed controller entity is responsible for connecting the VDT platform with the external world. Using this interface and the facilities provided by the testbed controller (e.g., identification of available simulators and optimization algorithms, exposure of simulator parameters and list of supported events), end users can compile simulation plans and submit them for execution (plans are created through a graphical tool called the VDT editor). Additional functionalities of this component include management of user authentications and permissions, retrieval of past simulation plans from the repository, validation of simulation plans, scheduling of the simulation instance execution, monitoring of the simulation state and storage of simulation plans to the repository for future use. The components of the UNITE VDT system are shown in Figure 3.29. When a simulation is eligible for execution, the testbed controller hands over control to the central controller. The latter is comprised of two modules: (1) the UDB/repository module responsible for storing of the simulation results and simulation plans, and (2) the scenario manager (Scnr) that undertakes functions like termi-

Figure 3.29

Components for validation of RRM capabilities [76].

3.3 QoS Testing

193

nal management, service, and traffic stream and simulators clusters time management. The scenario manager is the core component of the simulation platform. A detailed description of the functions of the scenario manager and the events needed for the integration of the VDT modules implementing handover algorithms can be found in [77, 78]. At the lowest level of the VDT architecture, there are a number of components (federates) responsible for simulating radio technologies or implementing the RRM algorithms. These components are attached to the testbed by forming VDT modules (RAT VDT modules and URRM VDT modules, respectively). These modules are comprised of three entities: (1) the actual simulator or the optimization algorithm (in general the module/cluster service), (2) the federated gateway (FG) which manages the simulation cluster or the execution of the algorithm and translates cluster-specific messages to VDT messages and vice versa, and (3) the VDT module API, which provides the interface (functions and parameter definitions), through which VDT modules communicate with the components of the central controller. The cluster service calls specific functions from the FG to send VDT events to the central controller. In the other direction, a specific function from the cluster service is called each time a VDT Event is received from the central controller, so that the event can be processed. The communication framework is supported by an event-based middleware implemented using SOAP messages over HTTP. The control of the events and their routing towards the distributed modules registered for them is undertaken by the central controller. The VDT module is the basic building block of the VDT architecture and it can be used for any function that needs to be implemented in a separate hardware/software environment. In general, the VDT module can be considered as an abstract implementation of a desired function serving a specific purpose. In this regard, the notion of the VDT module can perfectly apply as well to the simulation control functions of the central controller. Additionally, the federated service of a VDT module can equally correspond to a simulated, an emulated or a physical networking testbed. The VDT platform addresses two types of terminals: single-mode terminals that are connected to and managed by only one simulator and multimode terminals that have connectivity to several simulators (each one simulating the radio technology of a given interface). At the system level (composite simulator level) every mobile terminal is allocated a unique global identifier (ID). For multimodal terminals, however, there is an additional need to identify the mobile in all systems it is supposed to have access to. This introduces a second level of mobile indexation inside RAT VDT modules. The mapping between the global mobile ID and the simulator-specific ID is based on the concept that (virtual) multimode terminals are identified by many instances, each one of which applies to a different simulator. The global IDs are provided by the VDT editor and are managed by the scenario manager in a centralized manner while the local ones are assigned by the corresponding simulators upon terminal registration in the simulated radio access system. The VDT testbed supports several types of services, all of which comply with a common service description [76]. Services correspond to sessions initiated between mobile nodes in different RATs and fixed nodes (i.e., nodes that are supposed to belong to a wired infrastructure outside the wireless simulators). The description of the VDT services and the configuration of the associated sessions are given in a

194

Quality of Service

combined structure, including service description (identified by the service ID and the corresponding parameters), service QoS requirements (QoS identifier and parameters), service binding (source and destination terminal IDs), service start (and possibly stop) time, and description for the session initiation (intersession idle time distribution and parameters) and session duration processes (distribution and parameters). Examples of services include Voice over IP, HTTP, near real-time video, FTP, as well as more abstract services corresponding to constant bit rate (CBR) and Poisson traffic models. Services are characterized by QoS requirements (e.g., minimum rate, tolerable packet loss/delay) and are bound to source and destination terminals identified by unique global IDs. Session arrivals are managed by the service start time and intersession idle time, while session termination takes place in accordance to the session duration (and possibly a service stop time). When a new session (traffic stream) is set up, it is assigned a unique ID. Several sessions (applications) can run on a mobile using any of the available radio access technologies. The mapping of the sessions to the source/destination mobile terminals and the corresponding RAT VDT modules is handled by the scenario manager. When a new mobile must be added to a simulator, an AddMobile event is sent by the scenario manager. Because the insertion of a new mobile requires imminent service activation, the characteristics of the service (including the QoS requirements) are incorporated in the body of the message. The newly added mobile appears in the simulator as an idle node; it would not yet produce or receive any traffic. Service configuration is performed by the SendStreamToMobile event sent by the Scenario Manager to the RAT VDT module. Traffic activation and deactivation, on the other hand, takes place through the StartTxToMobile and StopTxToMobile events (the StartTxToMobile event is not combined with the SendStreamToMobile event in order to avoid multiple configurations of the same service in cases of frequent handovers). The StartTxToMobile is sent by the scenario manager to the RAT VDT module, indicating that a specific mobile should start transmitting traffic according to the profile that had been previously configured. The StopTxToMobile event indicates that a specific mobile should stop transmitting traffic. An additional RemoveMobile event has been specified to indicate that a specific mobile should be completely removed from a simulator in order to free resources. All of the previously described events are complemented by appropriate replies. Each VDT module has specific configuration parameters that must be initialized before the simulation starts. For RAT VDT modules, these configuration parameters are separated in two types. The first includes parameters that are specific to the simulated RAT (e.g., physical and MAC layer parameters) and the second includes parameters (common for all simulators) for adding background traffic to the simulator (in this case the number of terminals and their service ID are provided). For the RRM VDT modules, the parameters are algorithm-dependent. Time management in the VDT platform is achieved by a simple efficient scheme that guarantees that all connected simulators are synchronized at specified points in time (i.e., they have simulated up to a given time). With the aim of facilitating the validation of inter-system optimization algorithms, these points in time have been selected to correspond to instances when intersystem optimization functions are executed. This means that for the cases of initial network selection and intersystem

3.3 QoS Testing

195

handover operations the simulators need to be synchronized both when the new sessions are set up and when the handover algorithms are executed. The requirement to address synchronization at session setup points results in an “irregular” set of synchronization points (in the sense that the intervals between synchronization points are not constant). Handover optimization algorithms, on the other hand, can be reasonably assumed to be executed on a regular basis (e.g., every few seconds). If, however, this assumption is not acceptable it is the responsibility of the RRM VDT module to predict the time it would require a service by the time manager and communicate this information to the scenario manager. This prediction can be assisted from the fact that the handover decisions are usually not based on single snapshots of the system state but rather on observations taken during some time period. Each simulator is responsible for producing simulation results for the time interval it was instructed to simulate. After the end of the simulation step and before sending the permission for time advancement, each RAT VDT module updates the UDB with new measurements. These results are of interest to the RRM VDT modules. To achieve proper communication between the RRM and the UDB modules three events have been specified [76]. The GetGlobalInformation event is sent from the RRM to the UDB, requesting “global-level” data for the whole composite network (e.g., simulator configuration parameters, terminal and session mapping to different RAT VDT modules), the GetSystemInformation event is sent from the RRM to the UDB, requesting “system-level” results for different simulation clusters (e.g., total load, number of connected and/or active terminals), while the GetMobileInformation event requests detailed information (e.g., throughput, packet error rate, signal strength) for specific mobiles inside simulator clusters. When an admission control VDT module is included in a simulation, the default session allocation strategy, according to which sessions are allocated to different networks on the basis of preferences defined by the end user, is bypassed and the allocation of new sessions to simulators takes place according to the decision of the algorithm. In such cases, the scenario manager takes the necessary actions to call the admission control algorithm at appropriate time instances and implement the decision. When a handover control VDT module is included in a simulation, this module is called after the regular ProcessTime and ProcessTimeReply cycles. The handover algorithms take decisions on the basis of the status of the different simulator clusters received from the UDB. The handover decisions are propagated back to the scenario manager, which takes the appropriate actions to implement the reallocation of streams between the simulator clusters. At session initiation times an AdmissionRequest event is sent by the scenario manager to the admission control module to let it decide on the admission of a new service in the system. Apart from the terminal’s ID, service’s description, and the QoS requirements, the message also includes a list of simulated networks that are candidates for accepting the new service (this list may be utilized by the joint admission control algorithms). After the execution of the algorithm, an AdmissionReply event is sent to the scenario manager, indicating the acceptance or rejection of the service. In the former case, the network, in which the service will start, is indicated.

196

Quality of Service

The trigger for the execution of the vertical handover algorithm is provided through the postProcessTimeHandover event, which is used to let the RRM module report whether actions must be taken in order to efficiently reallocate sessions between the networks. The output of the vertical handover algorithm is sent back to the scenario manager through the postProcessTimeHandoverReply event, which contains a table with the sessions that would be subject to handovers and the target RAT VDT module for each one of them. The session reallocations themselves are performed by the scenario manager. 3.3.1.1

Service and Session Description

The VDT testbed supports several types of services, all of which comply with a common service description. Services correspond to sessions initiated between mobile nodes in different RATs or between mobile and fixed nodes (i.e., nodes that are supposed to belong to a wired infrastructure outside the wireless simulators). The syntax for the description of the VDT services and the configuration of the associated sessions are described in detail in [77, 78]. This syntax is generic (and powerful) enough to allow for the definition of a wide range of services with different traffic parameters and QoS requirements. For the experiments, a predefined set of services (i.e., traffic models) where the traffic profile and the QoS requirement parameters are preconfigured and incorporated into the ServiceID parameter can be used. This results in the simplified syntax shown in Table 3.2. Services are bound to source and destination terminals, which are identified by unique global IDs. Session arrivals are managed by the service start time and intersession idle time, while session termination takes place in accordance to session duration. Insertion of a mobile terminal in a simulation cluster is managed by the “terminal appear at” time, if such a parameter has been included in the syntax. If this parameter has not been specified then terminal addition is done at the time the first service for this terminal is to be initiated (default behavior). The “terminal appear at” time has been included in the syntax to allow mobile terminals appear at the simulator before the admission control module is executed. This is necessary in cases the admission control algorithm needs to know the status of the mobile before deciding on the most appropriate RAT for service initiation. In this regard, the terminal appear at time allows the mobile to report measurements to the UDB before the admission control module asks for these measurements through the GetMobileInformation event.

Table 3.2 [76] Service Description (service ID)

Syntax for Service and Corresponding Session Description used for Testbed Validation Service binding (source terminal ID, destination terminal ID)

Session duration Session initiation (Inter(distribution, session idle time distribuparemeters) tion, parameters)

Service start time

Terminal “appear at” time (optional)

3.3 QoS Testing

197

One assumption that is used for the traffic activation between nodes is that either the source or the destination MobileID is 0 (i.e., the mobile terminals either receive traffic from a wired node or transmit traffic to a wired node; no traffic flows between mobile nodes). This assumption, which is absolutely acceptable for performance evaluation studies, is necessary in order to avoid the need to handle the high correlation of traffic in the two directions (i.e., from a mobile node to the wired node and from that to the other mobile node). With the use of the service/session description syntax, a user is able to define a sequence of records for services for every terminal participating to the experiment and every considered type of service. An example of a session description corresponding to the syntax of Table 3.2 is shown in Table 3.3. This session description is provided by the VDT simulation plan editor to the scenario manager module of the central controller. According to this example, for terminal 1 (first record) one stream is set up (sessions open and close in an ON-OFF pattern) and it corresponds to a service with a serviceID 3. For destination mobile with global identifier of 1 the first stream (session) for this service will start at simulation time 1s (new streams will be created according to the description as long as the simulation end time for the particular scenario has not been reached). The central controller receives the file with the above-mentioned session description. The file must be properly analyzed in order to produce the desirable sequence for events (e.g., AddMobile, SendStreanToMobile). The second record of Table 3.2 shows an example use of the terminal appear at parameter. For the purposes of the tests, a set of three representative traffic models have been specified. All software simulators participating in the experiments are capable of supporting the traffic models (services) shown in Table 3.4. 3.3.1.2 Terminals Connectivity and Preferred Network Connection

This input must also be provided by the VDT Simulation Plan Editor. Information on the terminal network connectivity capabilities is kept in a structure as shown in Table 3.5. “Y” denotes that the terminal has support for this RAT, while “N” means no support. The preferred RAT for every service both for the downstream and the upstream cases is also shown. The option preferred RAT is used when no initial access selection algorithm has been specified in the simulation.

Table 3.3

Example of a Session Description

1.

ServiceID 3 SrcTerminal 0 DstTerminal 1 SessionDuration exp 5 InterSession const 5 StartAt 1

2.

ServiceID 2 SrcTerminal 0 DstTerminal 2 SessionDuration const 5 Intersession const 5 StartAt 10 AppearAt 8

3.

ServiceID 1 SrcTerminal 0 DstTerminal 3 SessionDuration const 5 Intersession const 5 StartAt 50 StopAt 70

198

Quality of Service Table 3.4 Traffic Models Used in the Experiments [76] ServiceID Description Parameters Name

Type

Distribution

Unit

Parameter Value

1

CBR

pkktMean pktRate

integer Constant integer Constant

Bytes packets/sec

1000 8

2

Poisson

pkktMean pktRate

integer Constant integer Poisson

Bytes packets/sec

1000 8

integer Truncated integer Lognormal integer integer Exponential

Bytes

3GPP FTP

fSizeMean fSizeStdDev fSizeMax reading Time

2000000 722000 5000000 180

3

Table 3.5

3.3.1.3

seconds

Example of Terminals Capabilities and Default RAT [76]

Experimental Setup

The physical demonstration and evaluation setup is shown in Figure 3.30. One PC is used to run the VDT editor; that is, the application, through which an end user accesses the UNITE system, identifies available simulators, simulation plans, and optimization algorithms, and consequently creates a simulation plan (comprising also traffic description, terminal connection capabilities, and default networks for service activation). Another PC is used to host the functionality of the UNITE and central controllers. Components provide the facility to run simulation plans by interconnecting all simulators involved in the plan and storing simulation results. Four PCs/laptops were used to simulate the HSDPA (the simulator is called MOTION and runs on Linux), WiMAX (the WiMAX simulator runs on Windows), WiFi (the simulator is called Pythagor and also runs on Windows), and 3GPP LTE networks (the simulator is called CellNET, and runs on the Linux OS). The WCDMA/TDD cluster was emulated using two PCs/laptops (the OpenR emulator runs on Real-Time Linux): one for the base station and one for the mobile terminal. Another PC was used to host

3.3 QoS Testing

Figure 3.30

199

Experimental setup [76].

the federate gateway of a composite wireless network (DCWN) consisting of IEEE 802.11b and GPRS/3G physical segments. The DCWN prototype platform included also a multimodal mobile terminal equipped with management software that allows for handovers between the two wireless networks without noticeable service disruption. All software simulators can support a large number of terminals (the number of terminals is bounded by memory and computational constraints). The emulated and the physical clusters, on the other hand, can only support one terminal due to hardware constraints. The ability of the testbed to simulate a heterogeneous wireless network was evaluated in terms of the communication delays of the AddMobile, SendStreamToMobile, StartTxToMobile, StopTxToMobile, ProcessTime, and UpdateValuesReply events. The test parameters are summarized in Table 3.6. Traffic activation for the different simulators is based on the preferences set by the end user (e.g., place all ServiceID 2 streams on VDT RAT1, place all ServiceID 1 streams on VDT RAT2) as no admission control module is specified. Figures 3.31 to 3.36 show the event delays for test1. The simulation duration for this remote test was set to 60s and the actual duration of the test (time to complete the simulation) was 1,021s. Communication between the simulators and the UNITE central controller was over the standard Internet; the two simulation clusters were running on laptops located in Nice, France, and the central controller was running on a server located in Lisbon, Portugal. The roundtrip time delays between the two locations were measured at about 200 to 300 ms.

200

Quality of Service Table 3.6

Parameters for Tests Involving Several VDT RAT Modules

TestID

Modules Involved

Type of Test

Max No. of Terminals

Simulation Step

Simulation Duration

Actual Duration

Test 1

Pythagor, WiMAX, Scnr, Remote UDB

50

1s

60s

1021s

Test 2

Pythagor, WiMAX, OpenR, Scnr, UDB

Remote

50

1s

60s

1183s

Test 3

CellNET, OpenR, Scnr, UDB

Remote

50

1s

60s

1153s

Test 4

MOTION, CellNET, Scnr, Remote UDB

50

1s

60s

995s

Test 5

DCWN, Pythagor, Scnr, Local UDB

10

1s

120s

180s

AddMobile delay (ms)

Pythagor WiMAX

Event number

Figure 3.31

Test1: delay of AddMobile event [76].

The delay of the ProcessTime event (see Figure 3.35) is much longer than the delay of the other events (significant differences in the delay of this event for a specific simulator are mainly due to the variable number of active terminals). This is because the delay of the ProcessTime event includes the following: • • • • •

The delay of the SOAP message itself; The delay to simulate for the specific time interval; The delay to send the UpdateValues event; The delay to receive the UpdateValuesReply event; The delay to send the ProccesTimeReply event.

3.3 QoS Testing

201

SendStreamToMobile delay (ms)

Pythagor WiMAX

Event number

Test1: delay of SendStreamToMobile event [76].

StartTxToMobile delay (ms)

Figure 3.32

Pythagor WiMAX

Event number

Figure 3.33

Test1: delay of StartTxToMobile event [76].

Different simulation clusters introduce different delays regarding the events for the addition of a new mobile terminal. The configuration of the service, the initiation and termination of the traffic, and the processing of the simulation step (i.e., the spikes in the AddMobile, SendStreamToMobile, StartTxToMobile, and StopTxToMobile delays are mainly due to temporary congestion in the Internet). Moreover, these delays for the WiMAX cluster are significantly larger than the delays for the Pythagor module. This is mainly due to the different complexity of these two simulators: the WiMAX simulator is based on the OPNET Modeler Wireless Suite, while the Pythagor simulator is a home-brewed simulator written in C++. The delay of the UpdateValuesReply event is much shorter than the delay of the other events. This is because the measured delays for this type of events correspond

Quality of Service

StopTxToMobile delay (ms)

202

Pythagor WiMAX

Event number

Figure 3.34

Test1: delay of StopTxToMobile event [76].

ProcessTIme delay (ms)

Pythagor WiMAX

Event number

Figure 3.35

Test1: delay of ProcessTime event [76].

to the time between the reception of the UpdateValues event by the central controller and the transmission of the corresponding UpdateValuesReply event to the simulation clusters. Thus, this delay includes only a processing delay at the central controller and, consequently, it does not depend on whether the test is remote or local, and on the characteristics of the simulation clusters. For this reason, the delay figures for the UpdateValuesReply events can be omitted for remaining tests. Figures 3.37 to 3.41 show the AddMobile, SendStreamToMobile, StartTxToMobile, and StopTxToMobile, and ProcessTime event delays for test2.

3.3 QoS Testing

203

UpdateValuesReply delay (ms)

Pythagor WiMAX

Event number

Figure 3.36

Test1: delay of UpdateValuesReply event [76].

AddMobile delay (ms)

Pythagor WiMAX OpenR

Event number

Figure 3.37

Test2: delay of AddMobile event [76].

The simulation duration for this remote test was set to 60s and the actual duration of the test was 1,183s. The delays associated with the physical OpenR cluster are much longer than the delays associated with the software simulators. These increased delays are due to the complexity of the WCDMA/TDD emulation cluster. The simulation processing delay of the CellNET cluster can overcome that of the hardware cluster in the cases when the number of active terminals (i.e., terminals involved in the traffic generation) is large. This is shown in Figure 3.42 for test3 when the actual test duration was 1.153s. Based on the results [76] from the rest of the tests in Table 3.6, it can be summarized that the delays of the AddMobile, SendStreamToMobile, StartTxToMobile, and StopTxToMobile events for these simulators are mainly governed by the connection round trip time. Processing delays on the other hand are clearly dependent on the number of simulated streams.

204

Quality of Service

SendStreamToMobile delay (ms)

Pythagor WiMAX OpenR

Event number

Figure 3.38

Test2: delay of SendStreamToMobile event [76].

StartTxToMobile delay (ms)

Pythagor WiMAX OpenR

Event number

Figure 3.39

Test2; delay of StartTxToMobile event [76].

The integration of the different RRM algorithms in the modules can be validated through similar tests. Shows the delay of the AdmissionRequest events for an integrated capacity-based admission control algorithm described in [79] for different clusters. Figure 3.43 shows the results for a single Pythagor cluster, while Figure 3.44 involved two separate MOTION clusters running on the same machine. The larger delay associated with the AdmissionRequest event for the IT_NORM_LOAD module is due partially to communication delays over the Internet and partially to the fact that it involves more accesses to the UDB through GetSystemInformation events.

3.3 QoS Testing

205

StopTxToMobile delay (ms)

Pythagor WiMAX OpenR

Event number

Figure 3.40

Test2; delay of StopTxToMobile event [76].

ProcessTime delay (ms)

Pythagor WiMAX OpenR

Event number

Figure 3.41

Test2: delay of ProcessTime event [76].

The results in Figures 3.45 to 3.48 address the integration of a RAT selection and admission control algorithm described in detail in [79]. This algorithm makes use of the AdmissionRequest, PostProcessTimeHandover, GetGlobalInformation, GetSystemInformation, and GetMobileInformation events, and involves three separate Pythagor clusters running on the same machine. The simulation duration was set to 60s and the actual duration was measured at 1,119s. This large discrepancy between the simulation and actual execution time is mainly caused by the excessive number of GetGlobalInformation, GetSystemInformation, and GetMobileInformation events that are exchanged at times when the RRM algorithm is invoked (this algorithm is also registered for the

206

Quality of Service

ProcessTime delay (ms)

OpenR CellNET

Event number

Test3: delay of ProcessTime event [76].

DEM_EFF_CAP

AdmissionRequest delay (ms)

Figure 3.42

Event number

Figure 3.43

Delay of AdmissionRequest event [76].

PostProcessTimeHandover event, and also incorporates the GetGlobalInformation and GetMobileInformation events). The simulation step is a parameter of great importance for the performance of the testbed [76]. The value of the simulation step parameter has no impact on the delay of some of the events (e.g., AddMobile, SendStreamToMobile, StartTxToMobile, and StopTxToMobile [76]); however, the simulation step is expected to have significant impact on the delay of the ProcessTime event and consequently on the actual simulation execution duration, as well as on the network traffic that is contributed by the communication framework.

3.3 QoS Testing

207

AdmissionRequest delay (ms)

IT_NORM_LOAD

Event number

Delay of AdmissionRequest event for two separate clusters [76].

AEGEAN_Greedy

AdmissioRequest delay (ms)

Figure 3.44

Event number

Figure 3.45 [76].

Integration of RAT selection and admission control: Delay of AdmissionRequest event

The ProcessTime event delay for test10 and test11 involving the WiMAX simulator in remote tests is shown in Figures 3.49 and 3.50. The simulation duration for test10, having a simulation step of 1s, was set to 60s and the actual duration was measured at 1,410s. The respective figures for test11, having a simulation step of 0.1s, were 30s and 1,668s. These results show that a smaller simulation step leads to larger simulation execution time mainly due to the exchange of more ProcessTime/ProcessTimeReply and UpdateValues events for the same simulation duration. The delay of the ProcessTime events, on the other hand, increases as the simulation step is getting larger. Figures 3.49 and 3.50 show that a reduction factor of 10 for the simulation step does not cause a reduction of

Quality of Service

PostProcessTimeHandover delay (ms)

208

AEGEAN_Greedy

Event number

Delay of PostProcessTimeHandover event [76].

AEGEAN_Greedy

GetGlobalInformationReply delay (ms)

Figure 3.46

Event number

Figure 3.47

Delay of GetGlobalInformationReply event [76].

the same degree for the delay of the ProcessTime event for the WiMAX cluster. This is mainly due to the complexity, with which the WiMAX simulator handles the simulation time advancement. The simulation step parameter has also impact on the network traffic load contributed by the communication framework. This load increases with decreasing the value of the simulation step. The network load measured for the local tests 12, 13, and 14 was approximately 80, 110, and 350 kbps, respectively. The impact of the simulation step on the communication delays is shown in Figures 3.51 and 3.52 for test15 and test16 was evaluated by use of two simulators in a remote and local setting, respectively. Figures 3.53 and 3.54 address a single simulation cluster. The results for the ProcessTime event delay show that the implemented

209

GetMobileInformationReply delay (ms)

3.3 QoS Testing

AEGEAN_Greedy

Event number

Figure 3.48

Delay of GetMobileInformationReply event [76].

ProcessTime delay (ms)

WiMAX

Event number

Figure 3.49

Test10: delay of ProcessTime event [76].

middleware does not introduce significant delays (simulation performance is mainly governed by the delays to simulate the wireless technologies) and, thus, it can be a valid approach for large-scale experimental infrastructures interconnecting simulators of wireless technologies. 3.3.2

Practical Implementation of RRM Mechanisms in Support of QoS

This section describes the practical implementation of the RRM platform and the demonstration set up at a low level.

210

Quality of Service

ProcessTime delay (ms)

WiMAX

Event number

Figure 3.50

Test11: delay of ProcessTime event [76].

WiMAX

ProcessTime delay (ms)

CellNET

Event number

Figure 3.51

Test15: delay of ProcessTime event for a remote scenario [76].

The platform supports the interworking between a next generation RAN [24] and legacy systems (i.e., WLAN, UMTS, GPRS). The platform is based on real-time monitoring of the RANs. The platform demonstrates for a real-time application the advantages of the proposed cooperative RRM functionalities for the provision of QoS and based on use congestion management. Another objective for the real-time simulation was to prove the generic nature of the proposed RRM framework. Results are shown in terms of capacity enhancements achievable through use of cooperative RRM in different types of systems (e.g., IMT-A and WLAN) and different deployments of the IMT-Advanced system. The platform is evaluated for three traffic load scenarios (TLSs) and shows the performance of the RRM framework in a WA and LA deployment for a selected number of services and in terms of handling of higher system loads. The perfor-

3.3 QoS Testing

211

WiMAX

ProcessTime delay (ms)

CellNET

Event number

Figure 3.52

Test16: delay of ProcessTime event for local scenario.

ProcessTime delay (ms)

Pythagor

Event number

Figure 3.53

Test17: delay of ProcessTime event.

mance is compared to the performance of a WLAN system. Finally, results are shown also in real time for a high quality video streaming application for a scenario of intersystem handover as a means for congestion management. The implementation supports user mobility in a heterogeneous scenario (e.g., intersystem handover), as well as mobility within the RAN (intermode handover). The topology of the proposed real-time RRM implementation is shown in Figure 3.55. The objective of the real-time simulation is to emulate a scenario where a UT will be able to initiate a request of a service with the following requirements: 1. Always connected; 2. Best coverage (strongest signal); 3. Best available bandwidth;

212

Quality of Service

ProcessTime delay (ms)

Pythagor

Event number

Figure 3.54

Test18: delay of ProcessTime event.

Figure 3.55

Topology of the real-time simulation platform for cooperative RRM.

4. Best available QoS. From the network point of view the system should handle all traffic through the implemented cooperative RRM mechanisms in order to decongest an area either as part of a single RAN or as part of an area covered by multiple RANs, and help the initiation of a handover. For example, for a congestion situation, based on the input received from the monitoring subnetwork, the main monitoring module, and the CoopRRM perform decision-making processes to identify suitable strategies to relief the effects of the congestion. To that, they have available a set of RRM management techniques, (RMTs), which represent the means by which the allocation of resources to the incoming traffic can be arranged in order to optimize resource utilization. The platform can function as a stand-alone or as an integrated implementation. In the stand-alone implementation the IMT-A candidate RAN can be emulated by an access point of the type 802.11a/b/g. In the integrated topology of Figure 3.55, the

3.3 QoS Testing

213

IMT-A candidate RAN is emulated by a testbed configuration. Therefore, the integrated implementation includes additional entities, such as the antennas for the transmission and the reception, a receiver terminal, and an entity that controls the transmission antennas at the BS. This last entity is responsible for the management of the transmitters; it gets the measurements from the radio link and sends them to the BS. In this way, the RRM platform knows at any given time the RTTMs of the radio link. The receiver PHY entity is the entity that controls and manages the receiver antenna and it is connected with the RRM platform UT as a network interface card, in order to forward the packets to and from the UT. The SRRMW functionality has been implemented in the BS/GW physical entity and the SRRML functionality has been implemented in the CoopRRM physical entity. This was done to simplify the setup for actual demonstrations. In the stand-alone implementation the BS and a GW monitor the state of the system and send alarms and reports to the CoopRRM through the CPW interface. The BS and GW communicate through the Ca interface. The legacy RAN is emulated in both cases as a WLAN based on the 802.11g wireless standard, and comprises also an SRRML module that monitors the system state and informs accordingly the CoopRRM through the CPL interface. The UT is capable of connecting to all the modes of the WRAN and the legacy RAN, using a high-level application that exchanges XML formatted messages with the CoopRRM. The integrated implementation was used to show results in terms of user-perceived QoS for a real-time high-quality video streaming. An HDTV camera captures video and sends it to the application server that streams it to the UT. The UT has two network interfaces, an Ethernet card and a wireless card. When the UT is connected to RAN 2, the Ethernet card is enabled and the wireless is disabled and the opposite happens when the terminal is connected to the legacy network through the access point. 3.3.2.1

System Requirements

The following technical assumptions were made related to the emulation of the IMT-A RAN, to be able to realize a stand-alone implementation for the cooperative RRM architecture. To be able to emulate the chosen reference IMT-A RAN as an adaptive system operating in the three main scenarios (i.e., LA, MA, and WA), the characteristics were assumed as shown in Table 3.7. The following system modes were assumed: time division duplex and frequency division duplex (TDD and FDD, respectively) with exemplary raw data rates for TDD of 100 MHz and for FDD of 2×20 MHz. The following calculation metrics were assumed for calculating the BER per chunk, subframe, and frames (see (3.12-3.16): BitRate chunk = BitRate SubFrameDLorUL =

SymbolsPerChunk ⋅ BitsPerSymbol ⋅ CodingRate ChunkDuration

SymbolsPerSubFrame DLorUL ⋅ BitsPerSymbol ⋅ CodingRate FrameDuration

(3.12)

(3.13)

214

Quality of Service Table 3.7

Parameters for the Emulated Reference RAN

Parameter

FDD Mode (2 x 20 MHz)

TDD Mode (Unpaired 100 MHz)

Center frequency (GHz)

4.2 (UL), 5.0 (DL)

5.0

Number of subcarriers in OFDM

512

2048

FFT BW (MHz)

20

100

Signal BW (MHz)

16.25

81.25

Number of subcarriers in use

416

1664

Subcarrier spacing (Hz)

39062.5

48828.125

OFDM symbol length (exlcuding guardtime) (ms)

25.6

20.48

Guardtime/cyclic prefix (ms)

3.2

1.28

Total OFDM symbol length (ms)

28.8

21.76

Chunk length in OFDM symbols

12

5

Chunk duration (ms)

345.6

108.8

Physical chunk size (KHz x ms)

312.5 x 35.6

781.25 z 108.8

Chunk size in symbols

96

80

Duplex guard time or transition gap TX/RX (ms)

—

19.2

OFDM symbols per frame (UL or DL)

12

15

Chunks per sub-frame (UL or DL)

52

312

Frame duration (ms)

691.2

691.2

Control super-frame duration

172.8

130.56

Frames per super-frame

8

8

Super-frame duration excluding control (ms)

5.5296

5.5296

Modulation alphabet and coding schemes

Bits per symbol

Coding rate

QPSK 1/2

2

0.5

QPSK 3/4

2

0.75

16 QAM 1/2

4

0.5

16QAM 3/4

4

0.75

64QAM 2/3

6

0.67

64QAM 3/4

6

0.75

Modulation alphabet and coding schemes

FDD model (2 x 20 MHz)

TDD mode (unpaired 100 MHz)

QPSK 1/2

278

735

QPSK 3/4

417

1103

16QAM 1/2

556

1471

16QAM 3/4

833

2206

64QAM 2/3

1111

2941

64QAM 3/4

1250

3309

BCCH duration (ms) RAC duration (ms)

Raw Bit Rate per Chunk (Kbps)

3.3 QoS Testing

215

Aggregated DL or UL Raw Bit Rate per Frame (Mbps) (DL and UL for 1:1 asymmetry) Modulation alphabet and coding schemes

FDD mode (2 x 20 MHz)

TDD mode (unpaired 100 MHz)

QPSK 1/2

14.44

36.11

QPSK 3/4

21.67

54.17

16QAM 1/2

28.89

72.22

16QAM 3/4

43.33

108.33

64QAM 2/3

57.78

144.44

64QAM 3/4

65.00

162.50

Aggregated Raw Bit Rate per Frame (MBPS) (DL and UL for 1:1 asymmetry) Modulation alphabet and coding schemes

FDD mode (2 x 20 MHz)

TDD mode (unpaired 100 MHz)

QPSK 1/2

14.44

72.22

QPSK 3/4

21.67

108.33

16QAM 1/2

28.89

144.44

16QAM 3/4

43.33

216.67

64QAM 2/3

57.78

288.89

64QAM 3/4

65.00

325.00

SymbolsPerSubFrame DLorUL = ChunksPerSubFrame DLorUL ⋅ SymbolsPerChunk (3.14) BitRateFrame =

SymbolsPerFrame ⋅ BitsPerSymbol ⋅ CodingRate FrameDuration

SymbolsPerFrame = ChunksPerFrame ⋅ SymbolsPerChunk

(3.15) (3.16)

The above parameters are used to determine the status of the IMT-A candidate RAN. To assess the performance of the proposed RRM framework, different user classes, with different service characteristics were identified for the IMT-A candidate system and derived from [80]. The IMT-A system modes were emulated with an access point into which three modes are imported and controlled by a workstation (i.e., the BS), emulating the IMT-A RAN. An integrated implementation provides an emulator of the IMT-A air interface as a testbed configuration. This was used to assess the user-perceived QoS. 3.3.2.2

Performance Requirements

The performance measurement is an effective means of scanning the whole network at any time and systematically searching for errors, bottlenecks and suspicious behavior. Through KPI aggregation, one can to deal with the many input and output parameters indicative for the network performance and as a means to assist the RRM decision process with a minimum set of metrics for tracking the system progress towards a performance target [13].

216

Quality of Service

The most important KPIs used in the real-time RRM framework implementation are the delay, expressed as the time needed for one packet of data (or a flow) to get from one point to another; the jitter, expressed as the delay variation of the received packets (inter-RAN flows) over time; the peak user data throughput, expressed as the maximum rate achieved during the transmission of data in the network; and the mean user data throughput, expressed as the average rate achieved during the transmission of data in the network. The load L can be defined in a generic way as a function of the total capacity as in N nu

Ln =

∑ DR i =1

Cn

i

(3.17)

where Ln is the load of the nth cell; Cn is the total capacity of the nth cell; Nnu is the total number of users running applications in the nth cell; and DRi is the data rate of the ith user. The congestion threshold, CT, is the load value, expressed in percentage of the total capacity, chosen to identify a congestion situation, and is used to indicate the upper congestion limit. Equation (3.17) was obtained by a defined dependency between the load L and the delay (τ). If the maximum load, at which a system can function without entering a congestion state is given by Lth, in a low network load situation, or L < Lth, the delay value (τ) can be represented as a typical delay (τtyp ). When the load increases and gets in the congestion zone, the delay value then augments very quickly. In the scope of the cooperative RRM investigated in the real-time platform implementation, once this critical value has been reached, the CoopRRM entity will receive a request for handling the arisen congestion situation and an algorithm will be activated. The congestion threshold, CT, is the load value L, expressed in percentage of the total capacity, chosen to identify a congestion situation, and is used to indicate the upper congestion limit. Measurements defined below are used in the proposed implementation to detect the status of the system. In addition, these can also be classified as triggers that can necessitate or cause handover [8]. To ensure real-time monitoring functionality for the support of inter- and intrasystem cooperation, the following measurements are provided to the SRRM/CoopRRM as a minimum required information. A very important measurement is the received signal strength in the UT, the interference level, and the C/I ratio. This allows for concluding on the reception quality of the actual configuration and the possibility (or the necessity) of doing a handover to other cell or a RAT. In the IMT-A system, these measurements are based on the UL and DL synchronization pilots and are performed by either the UT, BS/RN, on the IMT-A RAN, but also on the legacy RANs, when necessary. Three different types of measurements should be available intrafrequency, interfrequency, and intersystem; the last one requires a multimode UT. The transmitted power of the BS/UT is reported to the SRRM/CoopRRM entities. This is just a report of the transmitted power setting in a precise moment. Path loss measurements can also be mea-

3.3 QoS Testing

217

sured as the difference between the transmitted power and the received signal strength. For the execution of the RRM mechanisms related to QoS some quality measurements are also needed. These are a measure for the quality offered and perceived by the UT and GW and to compare it with the required quality. Measurements are performed on the user data flow in order to determine the QoS level and compare it with predetermined thresholds. The QoS indicators are the block error rate (BLER), the retransmitted block rate or the bit rate at different layers level (e.g., the PHY layer with instantaneous bit rate, MAC layer with throughput or IP layer level). For the IMT-A RAN these are performed by the UT and GW. For all the RRM mechanisms the cell load measurement is common. The cell load corresponds to the currently used resources in comparison to the available in the RAN resources, at different levels. The cell load is measured at the PHY layer as the transmitted power or it can be derived from the bit rate, the number of used chunks, and so forth. For the legacy RANs the cell load is defined in accordance with the specifics of that RAN, but in general, it is considered how the measured load compares to a predefined threshold, or whether Load < Lth. The UT velocity and location are two needed measurements for the execution of the location-based mechanisms. This is important for the RAN/cell selection during handover. As a minimum requirement the system should know to which BS/RAN the UT will be attached and what is the coverage area of the serving BS, a more detailed position determination should be performed by the GW, using the received signal strength measurements or satellite measurements (GPS). The KPIs are calculated based on the performed measurements, after performing an aggregation procedure (see Section 3.1.1.1) and the outputs are forwarded to the CoopRRM. 3.3.2.3

Traffic Load Scenarios

The TLSs are used in the real-time implementation as categorization of congestion situations and are based on parameters that introduce load augmentation. The TLSs are also associated with three service sets in the real-time implementation. This approach was adopted so that the TLSs are system-independent, which is important considering the generic nature of the proposed cooperation mechanisms. The TLSs are used as an indicator of which RRM technique must be selected to resolve an occurred congestion or load situation. This is achieved by associating High-Medium-Low (H-M-L) values for KPI parameter and indicating the resources availability, the type of user-perceived QoS, and the level of congestion. To determine the system states, the TLSs are represented by a logical tree, where the outcome of the KPIs calculation generates a certain TLS. This is shown in Figure 3.56 where the number of generated states during the TLS is 27 [80]. The KPIs related to QoS (i.e., delay, jitter) require that the RRM technique can improve the QoS state if the final calculation indicates a “high” state for the TLS. Each of the states at each level requires the execution of a suitable RRM technique. In the proposed real-time implementation, the TLS are generated by the process shown in Figure 3.57. To manage the resources for a given TLS, users are prioritized according to a user and application prioritization process [80]. By submitting all

218

Quality of Service

Figure 3.56

Logical tree for TLSs evaluation.

these values different kinds of traffic can be emulated and more freedom can be ensured for creating different types of traffic. A “medium” or “high” state generates an alarm message that triggers a suitable RRM technique. The alarm message is based on the values of the calculated KPIs. This is achieved by the monitoring process. For the evaluation of the real-time RRM platform, three TLSs describing the resources availability in terms of load, congestion, and mean user and data throughput were defined: normal hour (low), busy hour (medium), and emergency (high). The TLS corresponding to one of the three TLSs is translated into the number of users. Different user classes, with different service and radio capabilities were identified for the IMT-A candidate system and derived from [8]. The set of possible services is associated with a given user profile. The alarm message generated by a high state has a structure as shown in Figure 3.58. Calculation of the KPIs is one of the major roles of the monitoring unit. In the proposed implementation the message exchanges between different entities are XML-based and are transported over the TCP/IP protocol. The RTTMs are an indicator for the network parameters and actual operating modes of the reference WRAN. A selection of RTTMs that would be sent via a dedicated interface is summarized in Table 3.8. The different TLS are associated to different values of the bandwidth/delay/jitter. This process generates the traffic on the link according to the selected TLS and reports to the link controller, in order to change the state of the BS. The results of the TLS are forwarded to the reporting module that sends the RTTMs to the SRRMW. These RTTMs are also the ones stored locally in the SRRM W. The messages are grouped hierarchically and based on the identification sequence from the BS. The grouping is continuous per BS mode. A hierarchical group provides faster search results for further processing of the messages and for later use based on the demands of the CoopRRM. Continuously, the process of “receive” and “calculate” is straightforward because there is not any major event that would cause an H state, even if the messages are sent asynchronously. In order

3.3 QoS Testing

Figure 3.57

219

TLS generation and selection process.

to fulfill the requirement of calculation and produce the specified KPIs, each message is labeled with a unique queue number and time/date information. When a specified amount of messages have been stored locally and the process window has closed, the actual process of KPI calculation starts. 3.3.2.4

Results

The real-time simulator was used to assess the cooperative and generic RRM algorithms for three TLSs. In particular, the action of the congestion control mechanism was investigated. The objective is to observe to what extent the proposed RRM framework is effective to handle a congestion situation and what are the approximate congestion thresholds for different system loads. The KPIs related to the load, delay, jitter, and throughput were observed in real time as shown in Figure 3.59.

220

Quality of Service

Figure 3.58

Structure of an alarm message.

On the left side there are the statistics coming from the BS and then they are computed together with other network statistics and data and the network’s KPIs on the right are extracted. The bars on the right are green when the network is in normal condition and become red when there is an overload or critical to overload condition. The network is congested when the available resources are not sufficient to satisfy the experienced traffic load. Two congestion scenarios were observed: 1. The network experiments a traffic overload that cannot be totally covered by the available resources, because the traffic rapidly increases inside a group of contiguous cells. This corresponds to the TLS sports event. 2. An outage occurs because of unavailability of (part of) the network resources, typically because of malfunctions somewhere. Based on the load-congestion dependency defined in (3.17), congestion can be detected caused by a traffic overload and such a situation would trigger an alarm that would activate a cooperative RRM mechanism. When the user is connected to the WLAN (see Figure 3.55), there is a loss in data throughput of about 6 to 8 Mbps, which is due to the lower capabilities of the air

3.3 QoS Testing

221 Table 3.8

Figure 3.59

Summary of RTTMs Obtained from the BS

RTTM

Type

RTTM1

Latency per user

RTTM2

Latency

RTTM3

Erroneous UL packets per user

RTTM4

Total UL packets per user

RTTM5

Erroneous DL packets per user

RTTM6

Total UL packets per user

RTTM7

Erroneous UL packets

RTTM8

Total UL packets

RTTM9

Erroneous DL packets

RTTM10

Total DL packets

RTTM11

Lost UL packets per user

RTTM12

Lost DL packets per user

RTTM13

Lost UL packets

RTTM14

Lost DL packets

RTTM15

Peak throughput per user

RTTM16

Average throughput per user

RTTM17

UL payload data (Kbytes)

RTTM18

DL payload data (Kbytes)

Real-time observation of KPIs (in SRRMW) module.

interface, and cannot be resolved by the cooperative RRM framework. The high-quality video that was transmitted needed more than 29 Mbps throughput. The WLAN that was used had a maximum throughput of 22 Mbps with the best conditions (maximum transmit power, no collisions, no interferences, very small

222

Quality of Service

Figure 3.60

Quality of the real-time video streaming application through the WLAN.

Figure 3.61

Quality of a real-time video streaming application through the IMT-A RAN.

distance between the access point and the receiver, etc.). The user perceived QoS in real time is shown in Figures 3.60 and 3.61, for the WLAN and IMT-A RAN, respectively. The IMT-A RAN had a maximum throughput of 100 Mbps. The WLAN is not capable of meeting the throughput requirements of that high-quality video, which results in loss of packets, delays, and many collisions in the access point; therefore, an intersystem handover to a RAN with lower throughput would result in a reduced QoS perceived by the user.

3.4

Conclusions With the introduction and integration of several systems with several modes and several layers, QoS becomes a more and more complicated task. QoS issues are found in many types of wireless networks, including LANs, PANs, MANs, 3G, mobile ad hoc, sensor, and heterogeneous. This chapter introduced some of the fundamental concepts of QoS provisioning and presented various techniques, such as centralized and distributed resource management mechanisms at different layers of

3.4 Conclusions

223

the system to combat QoS problems that include system performance impairments, multimedia applications, and broadband wireless access. The chapter covered different wireless networks and the QoS service frameworks specified for next generation communication systems, along with recent research progress on improving the performance of QoS services in wireless networks. Resource management at both radio and network layer is one set of techniques to provide for QoS. Handover and load sharing algorithms must not only maintain the connection at a reasonable quality, they should also consider whether it would be beneficial to move the connection to another system/layer/mode. This decision is not solely based on changing radio propagation, anymore, but also on system load, operator priorities, and service quality parameters. Transmission protocols can be evaluated and optimized in order to maintain and monitor the required end-to-end QoS level, and to provide information required and delivered by the respective entities in charge of network management control through the network and network protocol stack. At the transport layer several different protocols can form a basis for further optimization of end-to-end transport protocols and for possible new protocol extensions. Validation of QoS supporting algorithms and architectures can be a useful way to verify the practicability of theoretically developed concepts. This can be done by testbed implementations, field tests, or real-time simulations.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. FP6 IST projects in Broadband for All, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project ENABLE at http://www.ist-enable.org/. ITU-T, “Terms and Definitions Related to Quality of Service and Network Performance Including Dependability,” ITU-T Recommendation E.800, 08/94 at www.itu.int. Kyriazakos, S., and G. Karetsos, Practical Radio Resource Management in Wireless Systems, Norwood, MA: Artech House Publishers, 2004. FP6 IST Project SURFACE, Deliverable 2.1 “System Requirements on QoS,” at www.ist-surface.org. Nousiainen, S., et al, “Measurements and Performance Evaluation,” Deliverable 2.3, IST Project CAUTION, May 2003. Mihovska, A., et al., “Algorithms for QoS Management in Heterogeneous Environments,” Proc. of WPMC’06, San Diego, California, September 2006. FP6 IST Project WINNER II, Deliverable 6.12.3, “Report on Validation and Implementation of Key WINNER Cooperation Functionalities,” June 2007, at www.ist-winner.org. A., Bondavalli, “Model-Based Validation Activities,” IST Project CAUTION, October 2003. Sanders, W., H., et al., “The UltraSAN Modeling Environment,” Performance Evaluation Journal, Special Issue on Performance Modeling Tools, Vol. 24, pp. 89–115, 1995. Clark, G., et al., “The Möbius Modeling Tool,”Proceedings of PNPM 2001, 2001. Gómez, G., and R. Sánchez, End-to-End Quality of Service over Cellular Networks, Wiley Editorial, 2005. Postel, J., “Transmission Control Protocol,” RFC793, http://www.ietf.org, September 1981.

224

Quality of Service [15] Na, S.-U., and J.-S. Ahn, “TCP-like Flow Control Algorithm for Real-Time Applications,” Proceedings of the IEEE International Conference on Networks, ICON, September 2000, pp. 99–104. [16] Balakrishnan, H., et al.,”A Comparison of Mechanisms for Improving TCP Performance over Wireless Links,” IEEE/ACM Transactions on Networking, December 1997, Vol. 5, Issue 6, pp. 756–769. [17] Athuraliya, S., et al., “REM: Active Queue Management,” IEEE Network, May–June 2001, Vol. 15, No. 3, pp. 48–53. [18] Li, V. H., and Z.-Q. Liu, “PET: Enhancing TCP Performance over 3G & Beyond Networks,” Proceedings of IEEE 58th Vehicular Technology Conference, October 2003, Vol. 4, pp. 2302–2306. [19] Karn, P., “The Qualcomm CDMA Digital Cellular System,” in Proceedings of USENIX Symposium on Mobile and Location-Independent Computing, August 1993, pp. 35–40. [20] Nanda S., et al., “A Retransmission Scheme for Circuit-Mode Data on Wireless Links,” IEEE Journal on Selected Areas of Communication, October 1994, Vol. 12. [21] Ayanoglu, E., et al., “AIRMAIL: A Link-Layer Protocol for Wireless Networks,” ACM Journal on Wireless Networks, February 1995, Vol. 1, pp. 47–60. [22] 3GPP TS 25.308, Technical Specification Group Radio Access Network; “UTRA High Speed Downlink Packet Access: Overall Description; State 2,” at www.3gpp.org. [23] 3GPP TR 25.813 (2006-06), “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Radio Interface Protocol Aspects,” at www.3gpp.org. [24] FP6 IST Project WINNER and WINNER II, at www.ist-winner.org. [25] FP6 IST Project WINNER II, Deliverable D.2.2.3 “Modulation and Coding Schemes for the WINNER System,” November 2007, at www.ist-winner.org. [26] FP6 IST Project WINNER II, Deliverable D6.13.14”Final WINNER System Concept II,” December 2007, at www.ist-winner.org. [27] FP6 IST Project PHOENIX, Deliverable D3.2a, “Specification and Preliminary Design of Transport and Network Layer Protocols and Mechanisms,” September 2004, at www.ist-phoenix.org. [28] Iren, S., P. D Amer, and P. T. Conrad, “The Transport Layer: Tutorial and Survey,” ACM Computing Surveys, December 1999, Vol. 31, No. 4. [29] Kohler, E., and S. Floyd, “Datagram Congestion Control Protocol (DCCP) Overview,” July 2003, at http://www.icir.org/kohler/dcp/summary.pdf. [30] Kohler, E., M. Handley, and S. Floyd, “Datagram Congestion Control Protocol,” draft-ietf-dccp-spec-07.txt, July 2004, at http://www.ietf.org/internet-drafts/ draft-ietf-dccp-spec-07.txt. [31] Stewart, R., et al., “Stream Control Transmission Protocol,” RFC 2960, October 2000. [32] Phelan, T., “Datagram Congestion Control Protocol – Lite (DCCP-Lite),” draft-phelan-dccp-lite-00.txt, August 2003, at http://www.phelan-4.com/dccp/ draft-phelan-dccp-lite-00.txt. [33] Schulzrinne, H., et al., “RTP: A Transport Protocol for Real-Time Applications,” Audio-Video Transport Working Group, RFC 1889, January 1996. [34] Atwood, J.W., “A Classification of Reliable Multicast Protocols,” in IEEE Network, May/June 2004. [35] Deering, S., “Multicast Listener Discovery (MLD) for IPv6,” RFC, October 1999, at www.ietf.org. [36] Internet Engineering Task Force (IETF), at www.ietf.org. [37] Waitzman, D., “Distance Vector Multicast Routing Protocol (DVMRP),” RFC, November 1988, at www.ietf.org. [38] Moy, J., “Multicast Extensions to OSPF (MOSPF)”, RFC, March 1994, at www.ietf.org.

3.4 Conclusions

225

[39] Adams, A., “Protocol Independent Multicast–Dense Mode (PIM-DM),” Internet draft, September 2003, at www.ietf.org. [40] Deering, S., “Protocol Independent Multicast – Sparse Mode (PIM-SM),” RFC, June 1998, at www.ietf.org. [41] FP6 IST Project WINNER, Deliverable 1.4, “Final Requirements per Scenario,” November 2005, at www.ist-winner.org. [42] Pantel, L., and L. C. Wolf, “On the Impact of Delay on Real-Time Multiplayer Games,” in Proceedings of the 12th International Workshop on Network and Operating Systems Support for Digital Audio and Video, 2002. [43] Farber, J., “Network Game Traffic Modelling,” in Proceedings of the First Workshop on Network and System Support for Games, 2002. [44] Schaefer, C., et al., “Subjective Quality Assessment for Multiplayer Real-Time Games,” in Proceedings of the First Workshop on Network and System Support for Games, 2002. [45] IETF, Specification RFC 2212, “Guaranteed Quality of Service,” September 1997 at www.ietf.org. [46] IETF, Specification RFC 2211, “Controlled Load Network Element Service,” September 1997 at www.ietf.org. [47] IETF, Specification RFC 2210, “The use of RSVP with the IETF Integrated Services,” September 1997 at www.ietf.org. [48] IETF, Specification of RFC 2474, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998, at www.ietf.org. [49] IETF, Specification RFC 2998, “A Framework for Integrated Services Operation over Diffserv Networks,” November 2000, at www.ietf.org. [50] H.263/MPEG4-compressed video traces: http://www-tkn.ee.tu-berlin.de/research/trace/ trace.html. [51] Keshav, S., An Engineering Approach to Computer Networking, Addison-Wesley Professional Computing Series, 1997. [52] FP6 IST Project EVEREST, Deliverable D08, “End-to-End QoS over B3G Systems,” July 2004 at http://www.everest-ist.upc.es/. [53] 3GPP Specification TR 23.027, “End to End Quality of Service Concept and Architecture,” Release 6, at http://www.3gpp.org/ftp/Specs/html-info/. [54] Zhuang, W., et al., “Policy-Based QoS Management Architecture in an Integrated UMTS and WLAN Environment,” in IEEE Communications Magazine, November 2003. [55] FP6 IST Project EVEREST, Deliverable 16, “Final Report on QoS Management in the Core Network and QoS Mapping,” July 2005, at http://www.everest-ist.upc.es/. [56] FP6 IST Project Ambient Networks (AN), “Ambient Networks Project, Description and Dissemination Plan,” July 2001, at www.ambient-networks.org. [57] IST Project WINNER II, Deliverable “D 4.8.1 WINNER II Intramode and Intermode Cooperation Schemes Definition,” June 2006, at www.ist-winner.org. [58] A. Mihovska, et al., “Policy-Based Mobility Management for Next generation Systems,” in Proceedings of IST Mobile Summit 2007, Budapest, Hungary, July 2007. [59] IST Project WINNER II, Deliverable “D1.3 Final Usage Scenarios,” February 2005, at www.ist-winner.org. [60] A., Klockar, et al., “Network-Controlled Mobility Management with Policy Enforcement towards IMT-A,” in Proceedings of ICCCAS 2008, May, 2008, Xiamen, China. [61] IST Project WINNER II, Deliverable “D4.8.3 Integration of Cooperation in WINNER II System Concept,” November 2007, at www.ist-winner.org. [62] IST Project Ambient Networks, Deliverable 26-GA, December 2007 at www.ambient-networks.org. [63] IST Project Ambient Networks, Deliverable 23-E2, “Connectivity and Dynamic Internetworking Prototype and Evaluation,” December 2007, at www.ambient-networks.org.

226

Quality of Service [64] IST Project Ambient Networks, Deliverable 27-EH5, “System Evaluation Results,” December 2007, at www.ambient-networks.org. [65] “IP Mobility Support for IPv4”, C. Perkins, Ed., RFC 3344, August 2002. [66] Devarapalli et. al., “Network Mobility (NEMO) Basic Support Protocol,” VRFC 3963, January 2005. [67] Henderson, T., (ed.), “End-Host Mobility and Multihoming with the Host Identity Protocol,” Internet Draft, draft-ietf-hip-mm-05, March 2007. [68] Laganier, J., and L.Eggert,, “Host Identity Protocol (HIP) Rendezvous Extension,” Internet-Draft draft-ietf-hip-rvs-05, June 2006. [69] Abley, J., and K. Lindqvist, “Operation of Anycast Services,” RFC 4786, December 2006. [70] Botham, C., P., et al., “Inter-Network Routing in Ambient Networks,” in Proceedings of the IST Mobile Summit 2007, July 2007, Budapest, Hungary. [71] FP6 IST Project Ambient Networks (AN), Deliverable D11-E.1 “Basic Functionality and Prototype,” December 2006, at www.ambient-networks.org. [72] Mendes, P., J.-A. Colas, and C., Pinho, “Information Model for the Specification of QoS Agreements among Ambient Networks,” in Proceedings of the IEEE International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC), September 2005, Berlin, Germany. [73] Psaras, I., L. Mamatas, and P. Mendes, “QoS Control in Next Generation IP Networks: An Experimental Analysis of Flow-based and SLS-based Mechanisms,” In Proceedings of the Workshop on Networking in Public Transport (WNEPT 2006), August 2006, Ontario, Canada. [74] Kamateri, E., “Analysis of Methods for Controlling QoS Agreements among IP Mobile Networks,” in Proceedings of the 18th Annual IEEE International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC’07), September 2007, Athens, Greece. [75] Ash, J., et al., “Y.1541-QOSM - Y.1541 QoS Model for Networks Using Y.1541 QoS Classes,” Internet Draft, NSIS Working Group, May 2006. [76] FP6 IST Project UNITE, Deliverable 5.5.2, “Final Validation of Testbed and of Proposed Cross-System/Layer Algorithms,” February 2009, at www.ist-unite.org. [77] FP6 IST Project UNITE, Deliverable D3.5.1, “Simulation Engine User Manual,” March 2008, www.ist-unite.org. [78] FP6 IST Project UNITE, Deliverable D5.1.1, “Framework and Testbed Implementation Guidelines,” September 2008, www.ist-unite.org. [79] FP6 IST Project UNITE, Deliverable 4.3.1, “Evaluation of Cross-Layer and Cross-System Algorithms Suited to the Pan-European VDT,” January 2009, at www.ist-unite.org. [80] A., Mihovska, et al., “QoS Management in Heterogeneous Environments,” Proc. of ISWS’05, Aalborg, Denmark, September 2005.

CHAPTER 4

Satellite Networks Satellite technologies were developed as a means to provide for broadband communications. Traditionally, satellite networks offer moderate capacity at higher expense and are mostly aimed at corporate users, yet have the potential to provide universal geographic coverage. Next generation services at millimeter wave (Ka band and above) have been slow to progress towards the market. Low earth orbit (LEO) systems have been hampered by excessive cost and complexity. This chapter describes the achievements made by the projects funded within the frames of the EU Framework program 6 (FP6) [1, 2] to assist the adoption of services delivered by satellite and to provide easy interoperable solutions that allow for fully exploiting the potential of satellite access technologies and networks for delivering low-cost broadband technology, for enhancing the performance of next generation terrestrial technologies, and for the delivery of emergency and similar services in the scope of a converged communications scenario. Some of the FP6 IST projects contributing to this area were CAPANINA, [3] which developed a low-cost broadband technology from high-altitude platforms (HAPs) for extending the broadband coverage to users in remote locations or similar impairing scenarios; WINNER and WINNER II [4], which used positioning technologies as an enhancement to a radio resource management framework for an improved performance of next generation cellular systems; SATSIX [5], which developed new satellite access techniques and integrated these with wireless local loops (WiFi and WiMax); VIVALDI [6], that advanced the state of the art of interactive broadband satellite access by optimal convergence of session-based services over the European standard DVB-RCS; MAESTRO [2], which developed a satellite overlay network for 3G and beyond 3G networks; ATHENA [2], which developed a DVB-T architecture for enabling triple-play services provision and interactive access; and some others. This chapter is organized as follows. Section 4.1 introduces into the main challenges for satellite networks and access, and describes these on the background of their potential for next generation communication systems and services. Section 4.2 describes the functionalities and possible realizable architectures. Section 4.3 describes the interworking between the satellite and other systems and required actions in support of such. Section 4.4 concludes Chapter 4.

227

228

Satellite Networks

4.1 Introduction Satellite communications can play an important role in provisioning the next generation telecommunication services and networks, provided the protocols specifying these services and networks are satellite-compatible and the satellite subnetworks, consisting of Earth stations interconnected by the processor and the switch on board the satellite, interwork effectively with the terrestrial networks [9]. The Satellite Action Plan Regulatory Group (SAP REG) of the International Telecommunication Union [10], representing most satellite operators and manufacturers in Europe, noted that beyond 3G systems will lead to a convergence of services, including fixed and mobile service, telecommunications, and broadcasting, as well as a hybrid of satellite and terrestrial platforms. Basic requirements of all these systems, however, are huge bit rates, up to several hundreds of megabits per second. Figure 4.1 shows the position of satellite technologies in the full plethora of Internet access technologies. The result is a need for more spectrum, which requires the convergence between terrestrial and satellite systems. Efficient use of the spectrum/orbit resource is one of the most crucial challenges that the international community faces in efforts to promote the worldwide telecommunication development [10]. Satellite systems development and integration into the overall concept of next generation networks (NGNs) is important for satellite applications within the fixed satellite, broadcasting satellite, mobile satellite, and radio-determination satellite services [11]. Alongside the provision of traditional applications such as capacity leasing, the most dynamic growth areas for satellite operators are direct-to-business or direct-to-home applications, and the provision of triple-play application, (i.e., telephone, high-speed data transmission/Internet, and television and sound broad-

Figure 4.1

Segmentation of Internet access technologies.

4.1 Introduction

229

casting programs) to fixed, transportable, and mobile terminals. This is leading to the convergence of systems operating within the above-mentioned different space services and their gradual integration with terrestrial telecommunication networks. For global disaster management, it is extremely important to have a rapidly deployable solution that remains unaffected in the event of disasters or similar emergencies; satellite communications meet these criteria and thus constitute a key element in a cost-effective disaster management strategy. Among the most important challenges to be overcome are the need for more satellite capacity, more efficient use of space/orbit resources, lowering the costs of satellite access, and integration with other communication concepts. Some enabling factors that can ensure this are use of new interference reduction, mitigation or compensation techniques; the use of cognitive radio systems or software-defined radio (SDR) technology for achieving dynamic spectrum management and flexible spectrum use; increase of the use of more homogeneous satellite network parameters in order to facilitate intersystem coordination; permitting a greater use of a satellite network integrated with terrestrial services (complementary ground components or ancillary terrestrial components) for more efficient use of spectrum; and so forth [11]. In addition, improved regulatory and economic conditions are also of importance. 4.1.1

Broadcast and Multicast for Fixed and Mobile Networks

The traditional way of data communication had mainly been from one host to another (unicast) [1]. With the growing number of users demanding Internet, video, and audio applications, many simultaneous connections and a large amount of bandwidth and server processing power was required to serve such a growing user community. Historically, broadcast networks have provided virtually everyone with a broadband one-way channel, offered by satellite/terrestrial broadcast systems, and cable networks. These trends lead to exponentially growing bandwidth and server requirements. The solution for this problem was to increase the capacity of both the backbone and the server at the same speed, as well as the capacity of the access network, so that the end-user terminals could receive higher bit rates. Currently, there is a growing demand for both interactive services, audio- and video-based IP telephony combined with TV provision. To enlarge the capacity, the EU research identified a combination of unicast and multicast services, known as IP multicast, as an interesting solution. The introduction of broadcast/multicast schemes is motivated by both, technological and application drivers (e.g., saving of bandwidth, economy, the introduction of e-based services.) The FP6 IST projects that targeted broadcast and multicast issues offered increased influence on international standards through their achievements, due to the massive support from many scientific, academic, and businesses sectors. The challenges identified and undertaken by the relevant FP6 IST projects (e.g., B-BONE [12], C-MOBILE [13], BROADWAN [14]) related to routing, quality of service (QoS), security, resource management, and reliability [14]. Also, the on-demand services and fair revenue share were addressed. The issue of spectrum efficiency and the role of local storage are some of the important research areas.

230

Satellite Networks

4.1.2

The Digital Dividend

The switchover from analog to digital television raises the digital dividend issue. The digital dividend represents radio spectrum that will be released by the switch from analog TV broadcasting to more spectrally efficient digital transmission. Already underway in some European regions [16], this changeover is intended to free a significant dividend in frequencies in the UHF band. This spectrum can be used for broadcast applications, notably using UMTS/HSPA mobile broadband networks, and their evolution (e.g., LTE, LTE-Advanced, IMT-Advanced). The digital dividend raises an opportunity to offer ubiquitous mobile broadband connections. This can only be entirely fulfilled through the following: • •

Allocation of a significant part of the digital dividend to mobile; Harmonization of digital dividend plans across the world.

In Europe the analog terrestrial TV broadcasting in the frequency band 470 to 862 MHz (channels 21 to 69) is being switched over to digital TV (DVB-T and DVB-H standards). The upper range from 790 to 862 MHz was coallocated to mobile service (MS) in Europe (Region 1) by the World Radio Communication (WRC)-07 [10]. In some countries this range is still used for defense systems, (e.g., tactical radio relay systems). With the opening up of the frequencies for dual use, these channels can be used by mobile communication systems. Locally unused channels or the gaps between the analog TV channels are used for professional radio microphones and broadcasting supporting services; these applications are distributed over the whole UHF band. A special case is channel 38, which is used by the Radio Astronomy for very long baseline interferometry (VLBI) observation and therefore cannot be used in large areas around radio astronomy stations. Not all channels are used in each country. The current usage and the transition from analog to digital TV may differ from country to country. The digital dividend will provide new digital terrestrial services; therefore, the competitive implications on satellite networks could be big. These new services also raise questions of subsidies and interoperability of equipment that affect the satellite industry [17]. The European Commission recognized the “impressive prospects” of satellite broadcasting for mobile multimedia as an offshoot of the digital dividend. The issues of broadcast terrestrial mobile TV services are separate from the issue of what satellites have to offer. The possibilities of satellite technology span well beyond the delivery of the above-mentioned services. Among the different competing designs for the last kilometer solution, space systems exhibit strong flexibility. They can be deployed very quickly to bridge the divide, and at least offer a temporary solution in cases where a cheaper long-term solution could be provided by terrestrial infrastructure. 4.1.3

High Altitude Platforms (HAPs)

The use of aerial platforms for the delivery of broadband communications requires a different approach to radio regulation. The ITU-R has chosen to define the concept of a high altitude platform station (HAPSs), which would operate between the altitudes of 20 to 50 km, differentiating it from satellite and conventional terrestrial

4.1 Introduction

231

fixed services (FS). To date, worldwide radio regulatory strategy has been based on requesting use of little used frequency bands, (e.g., 47/48 GHz (available for primary services worldwide) and 31/28 GHz (now available in 40 countries (with HAPSs given a secondary status, operating on a nonharmful interference, nonprotected basis). Frequency bands for the delivery of third generation services from aerial platforms have been made available on a worldwide basis. The existing HAPS definition covers a subset of proposed aerial platform deployments, but the HAPS frequency allocations are used to enhance the whole aerial platform sector’s market potential, thereby helping to reduce risk and ultimately to facilitate investment [18]. The biggest handicap on furthering the radio regulatory process for aerial platforms was identified as the absence of commercial craft available in the near term, which means that other more established technologies have received priority access to the spectrum. Some of these aspects were part of the research and development plan within the FP6 IST project CAPANINA [3]; Aerial platforms do not need long-term allocations of spectrum at the initial stage of deployment. What is needed first are experimental licenses, followed by temporary operating licenses, and then finally permanent spectrum, ideally within the 31/28-GHz bands (in Europe), or technology equivalent bands [18]. It is important that the future radio regulatory strategy is sufficiently flexible to ensure that frequency bands are appropriate licensed, as the platforms and commercial applications become available. It is crucial that the decisions to license such bands are based on sound technical arguments, presented at the appropriate forums, to ensure that the future commercial potential is not impeded. A large number of the related activities were part of the European funded research and development. Spectrum-sharing studies for HAP systems in the 28/31-GHz were carried out by the project CAPANINA [3, 19]. The primary purpose of the spectrum sharing work was related to studies that are ITU compliant, with the goal of submitting these as a contribution to the ITU-R [10]. In this respect the research was based on ITU models. Spectrum sharing within a regulatory context tends to be very conservative, and the most pessimistic assumptions are often used regarding whether one system will interfere with another. A good example in the context of this work is that all communication nodes are within line of sight of one another, even over several tens of kilometers. In practice, this is not true, and cellular operators use complex clutter models for statistical analysis of interference [19]. Unlicensed band systems are often designed to cope with interference by being sufficiently agile, with spectrum etiquettes used to more relaxed control interference. Key to assessing performance within the ITU context is the interference to noise ratio (I/N) threshold, often taken as being equal to −10 dB. This is radically different to assumptions made in traditional cellular design, where it is assumed that systems are interference limited (I/N = ∞). However, there are very good reasons for these pessimistic assumptions as traditionally such systems are controlled by different operators, often in different countries, and such systems may be nonagile and unable to avoid external interference, which is why these can still be adopted in studies. A more radical approach, especially in work dealing with multiple HAP systems, would permit for more than one HAP to serve the same coverage area using the same frequency band.

232

Satellite Networks

In this case, the key performance driver is the carrier to interference plus noise ratio (CINR), which is directly related to capacity. Because the 47-GHz bands are highly susceptible to rain attenuation, provision had been made at the WRC’00 [10] for HAP systems to use the 27.5- to 8.35-GHz and 31.0- to 31.3-GHz bands for fixed services (FS) in certain countries, under the condition that they do not cause harmful interference to, nor claim protection from, other types of FS systems or other coprimary services. In Bhutan, Indonesia, Iran (Islamic Republic of), Japan, Maldives, Mongolia, Myanmar, Pakistan, the Republic of Korea, Sri Lanka, Thailand, and Vietnam, the 27.5- to 28.35-GHz and the 31.0- to 31.3-GHz bands have been set aside for potential use by HAP systems in the HAP-to-ground direction and in the ground-to-HAP direction respectively, for the provision of FS. A pictorial representation of the interference scenario from a HAP system into existing radio communication systems is shown in Figure 4.2, based on the ITU-R frequency allocations in the 28/31-Hz bands, which in turn are shown in Figure 4.3: ITU-R Frequency allocation table in the 28- and 31-GHz bands. Relatively few studies have been carried out to investigate the impact of interference from HAP systems into fixed wireless access (FWA) systems [20]. Initial results show that while multiple HAP airships will not excessively interfere with a FWA base station (BS), a single airship induces a large amount of interference into the subscriber stations, and so a distance of 200 km is required between the nadir of a HAP airship and the FWA subscriber stations (SSs) [20]. These studies show that it is impractical for HAP and FWA systems to coexist, but the results are based on highly simplified scenarios. A more detailed analysis is required to examine the interference from HAP systems into FWA systems, based on a more accurate interference model incorporating practical antenna patterns for both the HAP and FWA systems; an appropriate propagation model; and realistic FWA system parameters. ITU-R related studies show that interference to FWA services can be reduced by using

Figure 4.2

Interference scenario from HAP systems into other radio communication systems [19].

4.1 Introduction

Figure 4.3

233

ITU-R Frequency allocation table in the 28- and 31-GHz bands [19].

appropriate mitigation techniques, and interference to the FSS services can be controlled by keeping the power flux density (PFD) at the geostationary satellite below a specified limit. The ITU-R has conducted sharing and compatibility studies between HAP systems and the following systems/services: • •

• • •

FWA systems for fixed services in the 28- and 31-GHz bands [21]; Geostationary orbit fixed satellite service (GSO/FSS) systems in the 28-GHz band [21]; Experimental Earth satellite service (EESS) in the 31-GHz band [22]; Radio astronomy service (RAS) in the 31-GHz band [23]; Terrestrial fixed service (FS) and geostationary orbit fixed satellite service (GSO/FSS) systems in the 47.2- to 47.5-GHz and 47.9- to 48.2-GHz bands [24].

The ITU-R has performed a basic technical examination of a proposed system using HAPs for fixed services within the 27.5- to 28.35-GHz and 31.- to 31.3-GHz bands, leading to recommendation ITU-R F.1569, which establishes a reference model of a HAP system, including a set of performance and operational parameters [25]. These parameters are intended for use in studies related to sharing and compatibility issues in these bands. The studies have also included an investigation and feasibility study of interference mitigation measures that could be applied to a HAP system in order to facilitate sharing and improve compatibility with other services (see [26]). Results of these studies indicate that the mitigation techniques described in [26] could result in viable solutions to problematic interference situations. 4.1.3.1

Analysis on the Interference from HAP Systems into FWA Systems

In examination of the interference from a HAP airship into a FWA BS, it is supposed that 11×21 HAP airships are deployed in a 500×1,000 km area as shown in Figure 4.4.

234

Satellite Networks

Figure 4.4

HAP airships located in a 500×1,000 km area [19].

Four interference cases from HAP systems into FWA systems have been studied: 1. 2. 3. 4.

Interference from an HAP airship into a FWA BS; Interference from an HAP airship into a FWA SS; Interference from an HAP ground station into a FWA BS; Interference from an HAP ground station into a FWA SS.

The results show that multiple HAP airships do not generate serious interference into the FWA BS, but even a single airship will induce a high level of interference into a SS when the same frequency is used. It is noted that a distance of 200 km is required between the nadir of an HAP airship and an FWA subscriber station in the case the transition point from using a 30-cm diameter antenna to that of a 60-cm diameter antenna [20]. Considering the interference from an HAP ground station into an FWA BS, a separation distance of around 5 km is required for an interference to noise ratio (I/N) of −15 dB and the assumed minimum elevation angle of 20 degrees [20]. Considering that FWA base stations are installed repeatedly with a frequency reuse distance of 2 to 3 km, coexistence of FWA base stations and HAP ground stations would be difficult unless interference mitigation techniques are introduced. This analysis also shows the required separation distance is about 80 km in the case of interference from an HAP ground station into an FWA subscriber station using the assumed I/N of -15 dB and an elevation angle of 20 degrees. Coexistence of the FWA subscriber station and the HAP ground station is impossible without interference mitigation. It is noted that the interfering signal is intercepted by hills and/or buildings in the majority of cases where the two stations are located more than 100 km apart.

4.1 Introduction

4.1.3.2

235

Analysis on the Interference from HAP Systems into GSO/FSS Systems

In this analysis, it is assumed that the boresight of the spot beam antenna of the GSO satellite is always directed towards the reference point, regardless of the orbital location of the spacecraft [20]. In cases where the reference point is not visible to the GSO satellite, it is assumed that the reference point is moved to another point under the condition that the elevation angle toward the GSO satellite is the minimum value. Figure 4.5 shows the geometric model of this example including the reference point. Figure 4.6 shows the aggregate interference from a triple HAP system as a function of the longitude of a GSO satellite. The transmit power required to cater for typical rain conditions is assumed for the HAP airships. The aggregate interference from a triple HAP system into a GSO-P/Ka-2 satellite does not exceed the assumed interference level of −132.22 dBW, which corresponds to an I/N ratio of 6%. Another maximum interference threshold from the side and back lobes of HAP downlink transmissions at 28 GHz can be calculated using the HAP system parameters given in [25]. The effective isotropic radiated power (EIRP) towards the GSO satellite is well below the levels from the individual HAP-to-ground transmissions of –7.08 dB (W/MHz) or –8.27 dB (W/MHz) calculated, resulting in an interference level of less than –139.80 dBW, which corresponds to an I/N ratio of less than 1% in FSS satellites with 2.0-degree or 0.3-degree antenna beams. 4.1.3.3

Analysis of the Interference from HAP Systems into EESS systems

The geometry of the model used for the evaluation of the interference is shown in Figure 4.7. The number of HAP ground stations that are allowed to transmit signals simultaneously is restricted to four due to the limitation of the available frequency bandwidth. The four HAP ground stations are located at the center of each spot beam and their impact is calculated. In this case, the aggregate interference from 4×367 = 1,468 HAPS ground stations is summed. Four HAP ground stations are HAPS

Reference point θ(g,h,r)

GSO orbit

Figure 4.5

GSO satellite

Geometric model of the reference point for a GSO satellite [19].

236

Satellite Networks

Figure 4.6

Aggregate interference power from three HAPS systems to GSO satellite [19].

Figure 4.7

Geometry of impact evaluation model [19].

located at the center of each cell with 5.5-km spacing. It is assumed that all the HAP ground station antennas are pointing towards the HAP airship at an altitude of 20 km and that the passive sensor is pointing towards the nadir direction in order to consider the worst-case interference [22].

4.1 Introduction

237

The aggregate interference from 4×367 HAP ground stations into the passive sensor is -185.9 dBW/MHz, which is 2.9 dB lower than the protection criterion of the EESS (passive) in the 31.0- to 31.3-GHz band. The aggregate interference from the HAP ground stations in the area covered by another HAP is negligible (30 dB less than –185.9 dBW/MHz). Therefore, the aggregate interference from the HAP ground stations covered by 200 HAP airships does not exceed the protection criterion of the EESS (passive). 4.1.3.4

Analysis of the Interference from HAP Systems into RAS Systems

The following models and assumptions are used for the evaluation of aggregate interference: •

•

•

•

•

Four HAP ground stations are located in the center of each service cell and all the antennas point to the corresponding HAP airship (total bandwidth of 300 MHz (in the 31.031.3-GHz band), frequency reuse factor of four and signal bandwidth of 20 MHz are assumed). The aggregate interference is obtained by summing a parameter defined as the received interference PFD at the RAS station plus “he receiving RAS station gain for the interference for all HAP ground stations (= 367 cell×4 stations×3 HAPS service area). An out-of-band emission power of −100 dBW/MHz is assumed from each HAP ground station. The RAS antenna is located at between the boundary (A) of the three HAP airship service areas and the nadir point O. The RAS antenna located at point B is directed towards A or O in azimuth. It is assumed that the RAS antenna is at the lowest elevation angle at which observations are made using that instrument (5 or 15 degrees).

The model is shown in Figure 4.8. Results indicate that in order to protect a radio astronomy station, HAP airships should not be located in the vicinity, to avoid the situation where many HAP ground stations are pointing in azimuth towards the radio astronomy station. The FS using HAPs should not operate within an area equivalent to one or more spot beam cells around a radio astronomy station. Table 4.1 summarizes results for the required separation distances between the HAP ground stations and the radio astronomy stations for the single entry case of interference, including the worst-case condition where a HAP ground station antenna is pointing towards a radio astronomy station in azimuth. 4.1.3.5 HAP Interference Studies in the 47/48-GHz Bands

The ITU-R has studied spectrum-sharing issues in the fixed service between HAP systems and GSO/FSS satellite systems in the 47.2- to 47.5 and 47.9- to 48.2-GHz bands. The results of this work are contained in Recommendation ITU-R SF.1481-1 [24], which notes that further studies could identify additional operational scenarios and mitigation techniques to further facilitate frequency sharing.

238

Satellite Networks

Figure 4.8

Model for interference aggregation in an RAS scenario [19].

Table 4.1 Required Separation Distances between an HAP and RAS for the Single Entry Case Using Antenna Pattern Given in ITU-R F.699 (Time Percentage: 1%) [19] RAS antenna elevation Required Separation Distance (km) angle (degrees) HAPS Ground Station Antenna Elevation Angle 20 Degrees

HAPS Ground Station Antenna Elevation Angle 90 degrees

Forward

Backward

Forward/Backward

1

60.3

21.4

21.4

5

7.9

2.4

2.4

10

3.0

1.0

1.0

15

1.8

0.6

0.6

4.1.3.6

Summary of Interference Studies

The aggregate interference from HAP ground stations covered by 200 HAP airships does not exceed the protection criterion of the EESS (passive) [22], and that the interference effects from HAP systems into RAS systems can be ignored unless the airship is located directly above the RAS station and the RAS antenna elevation angle is below 5 degrees [23]. Significant sharing studies in this band have been completed within the ITU-R [10]. No additional issues are considered necessary in spectrum sharing between systems using HAPs in the FS and other types of FS systems in the 48-GHz range at the time of the writing of this book. The results of studies already completed indicate that systems using HAPs could operate in the 27.5- to 28.35-GHz and 31.0- to 31.3-GHz bands without generating excessive interference to other types of FS systems or other coprimary services, through appropriate interference mitigation measures and an appropriate geographical separation distance and frequency guard bands. It is also confirmed that deploy-

4.1 Introduction

239

ment of HAP systems in the 31.0- to 31.3-GHz range could happen without causing harmful interference to the passive services in the 31.3– to 31.8-GHz band, through use of appropriate interference mitigation measures. However, additional studies are required within the ITU-R to investigate the compatibility of alternative HAP system deployments with different FSS and FS configurations. In addition, more accurate models are required for effective interference analysis of these more complicated scenarios. Since the uplink channels of GSO/FSS and FWA systems are in the same band as the proposed HAP systems, the two cases of interference from HAPs into GSO/FSS and FWA systems needed to be analyzed further [18]. In the case of interference from HAP systems into GSO/FSS systems, the preliminary results suggest that the aggregate interference from a single HAP into a GSO satellite would represent an I/N increase of at most 1.5% at the satellite. The aggregate increase in interference arising from three identical systems using HAPs would be at most 4%. Practical and operational considerations stemming from limited elevation angles and adaptive transmission and power control on the HAP downlink may lower these levels even further. The earlier studies show that while the interference into a GSO satellite from the HAP downlink is minimal, an impractical separation distance is required for effective operation of HAP and FWA systems in the same band. As a result, it is most important to carry out further investigations into the interference from HAP systems into FWA systems. This further investigation into the compatibility of HAP and FWA systems was done by the FP6 IST project CAPANINA [3]. 4.1.4

Emerging Standards

4.1.4.1

Standards for Terrestrial Digital TV in Europe

The following standards have been identified for delivering terrestrial digital TV in Europe [27]: •

•

•

Digital Video Broadcasting-Terrestrial (DVB-T)is on the same channel bandwidth as analog TV (8 MHz). DVB-T allows at least four digital programs of similar quality. DVB-H is a modified version of the DVB-T standard optimized for reception in mobile receivers and telecommunication handhelds (mobile TV). DVB-T2 is a standard that is under development at the time of writing of this book and it is expected to deliver an increase of at least 30% in the capacity of a digital TV multiplex over the current standard while maintaining the same coverage. It should be noted that DVB-T2 is not compatible with DVB-T and would require new hardware for the consumer.

Applying new broadcastings schemes based on DVB-T2 means that less than 10% of the original spectrum is needed to accommodate the analogue programs. Other standards for digital TV (e.g., DMB or MediaFLO) have minor importance in Europe. Recently, a major revision of the DVB-Return Channel Satellite (DVB-RCS) standard has been initiated [28]. The specifications shall include improvements in the following areas:

240

Satellite Networks

• • • •

Channel coding and modulation formats; IP traffic encapsulation and framing; Access protocols; Internetworking and management.

DVB-RCS is the only multivendor very small aperture terminal (VSAT) standard. It was conceived to provide a standardized broadband interactivity connection as an extension of the DVB satellite systems. It defines the air interface waveform and protocols used between the satellite operator hub and the interactive user terminals. It embraces the DVB-S and the DVB-S2 standards implemented in the commercial broadcasting environment, exploiting its economics of scale. Low-cost VSAT equipment can provide highly dynamic, demand-assigned transmission capacity to residential and commercial/institutional users. DVB-RCS provides users with the equivalent of an ADSL or cable Internet connection, without the need for local terrestrial infrastructure. Depending on satellite link budgets and other system design parameters, DVB-RCS implementations can dynamically provide in excess of 20 Mbps to each terminal on the outbound link, and up to 5 Mbps or more from each terminal on the inbound link. The standard was first published by the European Telecommunication Standardization Institute (ETSI) [29] in 2000 as EN 301 790. Subsequently, this increases the competitiveness of satellite networks with respect to terrestrial technologies. Many such systems, mostly in the Ka band, have recently been deployed (e.g., Wildblue, SpaceWay) or will be operational (e.g., HylasOne, KaSat). The next generation mobile network (NGMN) has defined the following basic requirements for the development of the DVB standards: •

•

•

•

•

Sufficient spectrum needs to be allocated within the 470- to 862-MHz band to allow for multiple full deployment of the next generation of mobile networks; more than 120 MHz of harmonized spectrum. The channeling arrangement within the band needs to be defined taking into account the possible asymmetry of traffic due to services such as mobile TV. Sufficient guard band will be needed to reduce the threat of interference between the digital dividend services and DVB-T. The spectrum for IMT should be harmonized globally if possible, and at least on a regional basis. The standard duplex direction may have to be reversed, with uplink in the upper band as this will minimize the interference between a mobile uplink and a broadcast downlink in the user equipment.

4.1.4.2

Architectures for Broadband Satellite Multimedia Standards

Broadband satellite multimedia (BSM) architecture and related concepts are designed as the basis of an open platform based on IP service delivery [30]. It is important to further develop and extend the standards for IP interworking functions

4.1 Introduction

241

and related network services that have already been identified, both within ETSI and in other standards bodies. Satellite networking standards are needed to promote the convergence of the satellite access network services with the established and emerging terrestrial access services by providing a comprehensive framework for standards-based interworking between satellite networks and terrestrial IP networks (both Intranets and Internet). Mesh DVB-RCS/DVB-S satellites networks can provide direct connectivity (only one satellite hop) between sites. Mesh IP communications enable the possibility of carrying traffic LAN-to-LAN, secure communications without a hub, Intranet, and two-way traffic generated by real-time applications (e.g., videoconferencing, VoIP) [30]. It must be noted that it requires a connection control protocol (C2P). C2P is capable of setting up MAC connections to convey any traffic transmission among return channel satellite terminals (RCSTs). It enables a dynamic connection control interface between the network control center (NCC) and RCSTs. Further, C2P brings extra flexibility and efficiency to the DVB-RCS systems, in terms of dynamic bandwidth and dynamic resource allocation. The possibility of having peer-to-peer communications using the DVB-RCS standard had also been discussed in ETSI [29]. The C2P applied for a regenerative scenario could also be applied to a mesh-transparent scenario. In parallel, the Telecommunications Industry Association (TIA) [31] started to work on a C2P standard for satellite network mode systems (snms). A C2P development within ETSI TC SES (Satellite Equipment and Systems) was performed in order to link and combine all C2P activities. ETSI SES BSM created two work items: a general C2P standard and a C2P for DVB-RCS systems, both approved with the support from ESASatLabs, DVB-RCS, TIA, and ETSI SES BSM. These two work items were created in order to link and combine all C2P activities. TAS-E has been the responsible for the coordination and liaison between all the different groups. Within the International Engineering Task Force (IETF) [32], the IP-DVB (IP over DVB) Working Group (WG) is active in satellite-specific areas concerning several aspects of IP over DVB transport. In addition, other special satellite issues are also discussed, such as multicast security, robust header compression, and so forth. The ETSI BSM specifications were used as a basis for the system designs developed within the FP6 IST project SATSIX [5], which significantly contributed to the following BSM topics: • •

• •

DVB/RCS Connection Control Protocol (C2P) requirements; GSE-Protocol-spec-v09, IP/S.2 study of DVB-GBS and the DVB-Generic Stream Encapsulation (GSE) Protocol. Development and refinement of BSM specifications for the SI-SAP; Refinement of the security BSM security architectures (unicast and multicast).

4.4.2.1.1 BSM Protocol Architecture

The BSM protocol architecture used throughout the standards is characterized by a clearly defined boundary at the SI-SAP [33] separating the common satellite-inde-

242

Satellite Networks

pendent (SI) protocol layers and the alternative lower satellite-dependent (SD) layers. This concept has enabled to address complex technical issues in a systematic and consistent manner. This interface has also enabled the treatment of issues for the IP layer and above for all types of satellite system and independently of the satellite technology-specific layers below the interface. Address management at SI-SAP describes the relationships between IP addresses and lower layer addresses, called BSM_IDs as a generic term for lower layer addresses in different satellite systems (e.g., in a DVB-RCS system the BSM_ID could relate to a MAC address) [34]. It also covers how to create, manage, and query the BSM_IDs for the purpose of sending and receiving user data (in particular IP packets) via the SI-SAP. The technical standard document elaborates the details of the address management functions, namely the address resolution function for relating BSM_IDs to IP addresses. The BSM address resolution (B-AR) is defined as the function that associates a BSM_ID with the corresponding IP address. The BSM architecture shown in Figure 4.9 must provide a service where AR is supported for B-AR clients in all STs by a central B-AR server. The STs include both the gateways (typically the hub for a star network) and remote STs. Each ST should also have an AR table as part of the B-AR client. The B-AR server could, in principle, be located anywhere but it is realistic to assume that is under the control of the BSM operator because it needs knowledge of the BSM address space. Typically, the B-AR server will be located at a gateway or at the NCC. Having the B-AR server located at the NCC may be appropriate if the AR function is used to support traffic management, (i.e., allowing and denying IP packets access to the BSM network. B-AR is a C-plane function. Two distinct processes are required for the AR to function. Above the SI-SAP, a BSM_ID must be associated with an IP address. Below the SI-SAP, a BSM_ID is associated with a MAC address. The BSM_ID must be resolved to a MAC address whenever an IP packet has to be transmitted by the lower layers; this is also usually a static or pseudostatic process.

Figure 4.9

BSM AR architecture [30].

4.1 Introduction

243

The process of association can store pairs of values in a table, as is the case with entities using AR over wired networks such as Ethernet. The process of resolution can examine the table, usually stored at the location, where the resolution occurs. Mechanisms are required to populate and update the local tables that store the associations. Updates to a local table will normally be performed by periodically transferring data from a central, or reference table. The transferred data will either replace or enhance the local data. It is highly desirable to minimize the flow of the B-AR data traversing the satellite link. B-AR may be used whenever an IP packet is to be forwarded to a new destination across a BSM network. The BSM_ID of the next hop must be determined for the packet to be forwarded, and B-AR must be used if the BSM_ID for a given next hop IP address is not already known at that ST. There are three cases: 1. Star network inbound: All IP addresses resolve to the hub gateway BSM_ID. The BSM_ID associated with the hub gateway is either acquired at ST startup as part of the configuration management by the NCC or it is preprogrammed. 2. Star network outbound: IP addresses resolve to specific BSM_IDs. The IP address resolution may require policy decisions in connection with the access management. An OBP satellite that performs layer switching may need an AR table that is at least partially managed by the B-AR server. 3. Mesh network: IP addresses resolve to specific BSM_IDs. IP address resolution may require policy decisions. An OBP satellite that performs layer 2 switching may manage an AR table itself or it may be managed by the B-AR server. In all cases a B-AR client at the sending side performs address resolution. Initially, this should use the cached entries in the local AR table, but if there is no match the ST sends an address resolution request to a B-AR server whose address is acquired dynamically or is preconfigured. 4.4.2.2.1 Multicast Source Management

The multicast source management defines the architectures and functions required for the interworking of IPv4 multicast protocols, including multicast sources, with the BSM. The technical standard document firstly considers the BSM network scenarios for IP multicast interworking, with two main aspects: (1) The satellite network architecture, and (2) the management of multicast sources and data forwarding, either statically or dynamically. The BSM functional and protocol architectures are then derived for the management of the following: • •

IP multicast control messages (group management and routing protocols); Multicast access control (including resource management) and multicast address resolution.

Reference [35] defines the detailed functional requirements and interactions of the above three functions with respect to the BSM lower layer interface, the SI-SAP. The satellite-dependent (SD) functions below this interface are system-specific.

244

Satellite Networks

In the case of multicast routing protocols, the PIM-SM protocol (including the PIM–SSM variant) is the basic protocol, which is almost exclusively used in existing and proposed multicast routing applications today. To make multicast services effective over the BSM, multicast must take advantage of the satellite’s native multicast capabilities. Unlike unicast, where destination IP and link layer addresses are specific to an end host, multicast employs a common IP “group” address for a given flow to all receivers, and, therefore, the BSM SISAP should also employ a corresponding common address, or GID (Group ID), for each multicast flow. The four main network scenarios and their features are summarized in Table 4.2. The network configuration is either star or mesh. The star topology refers to a star arrangement of links between a central hub station and remote STs through the satellite. The Hub acts as the sole BSM ingress router and distribution node for the BSM multicast. The STs are all egress routers connected either directly to hosts or via premises networks. The mesh topology refers to a mesh arrangement of links between STs where all STs can be interconnected directly through the satellite and each ST can act as a multicast distribution node to STs. STs can therefore be both ingress and egress routers. The push and pull cases refer to multicast services, which are configured by the BSM network operator, or a similar centralized management entity, in terms of which groups are forwarded over the BSM on a quasi-static basis. The manager may not always know in advance what kind of resources (bandwidth, delay, jitter) will be required for a given multicast flow, but it has to configure the BSM resources based, for example, on a service level agreement (i.e., push service). In the pull case, the multicast services are requested and initiated dynamically (i.e., on demand) by each receiver host issuing a join to an IP multicast group, and therefore by relay through each egress ST, to the ingress ST using IP multicast protocols. The conditions, under which a new group membership can be allowed and the associated multicast flows forwarded over the BSM are determined by BSM network policies. Figure 4.10 shows an example of a mesh pull scenario. This architecture is focused on the functional entities involved in the end-to-end BSM multicast control mechanisms that enable multicast flows to be forwarded or removed across the BSM

Table 4.2

BSM Multicast Network Scenarios [30]

Scenario

Multicast Traffic Ingress Point

Multicast Traffic Egress Point

BSM Ingress IP Network IP Multicast Multicast Control Control

STAR PUSH

Hub

ST

None

STAR PULL

Hub

ST

IGMP/PIM IGMP/PIM IGMP/PIM Dynamic

MESH PUSH

ST

ST

None

MESH PULL

ST

ST

IGMP/PIM IGMP/PIM IGMP/PIM Dynamic

Egress IP Multicast Control

BSM Access Control

None/ None/ Static IGMP/PIM IGMP/PIM

None/ None/ Static IGMP/PIM IGMP/PIM

BSM Address Management Static/ Dynamic Dynamic Static/ Dynamic Dynamic

4.1 Introduction

Figure 4.10

245

Mesh pull bsm multicast source management control plane architecture [30].

from ingress to egress. The architecture must support dynamic control of multicast groups, allowing groups to be added and removed on demand. BSM multicast source management refers to the combination of control plane functions needed to create, maintain, and remove BSM multicast distribution trees, and which includes multicast control management (using PIM and IGMP), multicast access control, and multicast address management. The NCC is concerned with BSM SI-SAP and SD layer functions. The NMC is considered closely related to, or part of, the NCC, whose actions are performed under the aegis of the NMC for aspects such as policy, security, and authentication. The message flows for the mesh pull scenario are shown in Figure 4.11. The detailed multicast source management architecture considers the three constituent functions: 1. Control management (MCM); 2. Access control (BMAC); 3. Address management (MAM). The protocol architecture differs between the ingress and egress STs. The different architectures for each case are shown in Figures 4.12 and 4.13, respectively. In Figure 4.12, the IGMP/PIM protocol entity (in the MCMC) establishes the IP group membership list for each of the Ingress ST BSM interfaces. Whenever there is a change of aggregate group membership over all of these interfaces, and/or periodically as necessary, the MCMC sends a resolution request for any new groups to the lower layers of the attached network in order to obtain associated link layer addresses. It also sends a resolution request for the groups to the SISAP to obtain associated GIDs on the BSM side. Reception and forwarding of multicast groups is controlled by the MCMC, and having obtained the BSM resources necessary, the

246

Satellite Networks

Figure 4.11

Information exchange in a mesh pull scenario [30].

Figure 4.12

BSM multicast ingress ST protocol stack [30].

MCMC issues a listen command to the attached network interface together with the binding of relevant IP groups and multicast link layer addresses. The MCMC also issues a forward command to the IP forwarding engine together with the binding of the groups to GIDs.

4.1 Introduction

247

In Figure 4.13 the IGMP/PIM protocol entity (in the MCMC) establishes the IP group membership list (under the aegis of the BMAC). Whenever there is a change of group membership it issues a join request to the upstream router. The MCMC also sends a resolution request for any new groups to the SISAP to obtain associated GIDs on the BSM side. It also sends a resolution request for the groups to the lower layers of the attached network in order to obtain associated link layer addresses. Reception and forwarding of multicast groups is controlled by the MCMC, and it issues a listen command to the IP forwarding engine together with the binding of the groups to GIDs. The MCMC also issues a forward command to the attached network interface together with the binding of relevant IP groups and multicast link layer addresses. 4.4.2.3.1 QoS Functional Architecture

QoS is a network feature that will be increasingly valuable for service differentiation and support of more QoS-sensitive applications. In contrast to wired or optical networks where over-provisioning of capacity is often used to ensure QoS for packet-based transport, satellite systems, as for other wireless networks, allocate capacity efficiently and carefully. This requires more sophisticated QoS methods that are closely linked to resource provision and control at lower protocol layers than IP. No standardized or common approach to network architecture for end-to-end QoS provision to applications exists at present [30].

Figure 4.13

Detailed BSM multicast egress ST protocol stack [30].

248

Satellite Networks

Various approaches to QoS provision can be proposed based on varying complexity and performance. A modular architecture is preferable, which can be adapted to meet different needs. QoS provision within ETSI BSM systems is one of the first aims, but because BSM systems are intended to access the Internet, end-to-end QoS across integrated networks including satellites is also important. A BSM QoS functional architecture has been defined for IP-based applications [36]. Compatibility with QoS requirements for generic internetworking including next generation networks (NGNs) are taken into account [37]. The BSM architecture is characterized by the separation between the common satellite-independent (SI) protocol layers and alternative lower satellite-dependent (SD) layers. At the SI layers, several methods of ensuring end-to-end QoS over integrated networks are foreseen, by means of signaling protocols (e.g., based on SIP) at the session (or application) layers and DiffServ, RSVP/IntServ, or NSIS at the IP layer. At the SD Layers alternative lower protocol layers offer different QoS characteristics. The focus of the architecture definition here is on maintaining compatibility with these alternative methods and approaches by addressing the generic BSM QoS functions required in the SI layers (including IP). These functions can provide interfaces where appropriate with higher-layer and lower-layer QoS functions, and with external networks and customer equipment. The BSM global QoS functional architecture, including the relationship of the BSM with QoS protocol layering and with the rest of the network, is shown in Figure 4.14. It shows the range of possible functions involved in the QoS process and their functional partition between control and user planes. The management functions are not shown because these are considered more implementation-specific). Two main kinds of message flows between functional blocks are shown in Figure 4.14: primitives between the protocol layers, and peer-to-peer protocols. The peer-to-peer protocols are shown as horizontal lines for clarity, in reality these are transported via the user plane.

Figure 4.14

BSM QoS functions in the IP layer and higher layers [30].

4.1 Introduction

249

The BSM QoS architecture is based on a centralized control and management of the BSM subnetwork through a server entity called the BSM QoS manager (BQM). The BQM can consist of several physical entities. The STs, as network edge devices, are responsible for traffic processing and policy enforcement at the ingress and egress, but they should be controlled from the BQM. The BQM should contain all the necessary functions to manage QoS for all layers above the SISAP in both management and control planes. The BQM interacts with equivalent local functions in the STs. The control and management functions below the SISAP (for connection control, bearer set up, BSM QoS, etc.) are usually also centralized in the NCC, which may be closely associated with the BQM. Many of the functions in the BQM are standardized functions such as those for signaling (RSVP/NSIS or SIP Proxy/SDP), but others specific to the BSM, such as those for managing the BSM’s global IP and SIAF layer resources, are allocated to a functional entity called the BSM resource controller (BRC). Central to the QoS capability of the BSM is the interface of the IP layer with the lower SD layers at the SISAP. To abstract the user plane QoS interface at the SISAP the concept of queue identifiers (QIDs) has been introduced. These represent abstract queues available at the SISAP, each with a defined class of service for transfer of IP packets to the SD layers. The satellite-dependent lower layers are responsible for assigning satellite capacity to these abstract queues according to the specified queue properties (e.g., QoS). The QID is not limited to a capacity allocation class; it relates also to forwarding behavior with defined properties. A QID is only required for submitting (sending) data via the SISAP and the QID is assigned when the associated queue is opened. An open queue is uniquely identified by the associated QID: in particular, the QID is used to label all subsequent data transfers via that queue. The way in which QIDs are mapped to the IP layer queues is an important consideration for the overall QoS. The different cases of interaction between the QoS requests and the BSM involve not only the user plane containing the QIDs, but also the control and management planes that influence the way the QIDs are used. The interaction between the IP layer QoS and the SD layer QoS takes place across the SISAP and is thus the major issue for the BSM. 4.4.2.4.1 Security Architecture

The detailed security system is described for various architectures in [38]. These security cases are focused on the positioning of security functions above or below the SI-SAP. For example, the security key management and data encryption entities can both be above or below the SI-SAP or one above and one below. In addition, the concept of BSM security association identity (SID) is present. For example, if there is a secure connection between an ST and a gateway, then the SID is the reference number that is used to convey security information between BSM local and network security managers such as encryption keys, digital signature methods and security policy exchanges. If there is only one single BSM network security manager, then the SID will be unique for the whole BSM network. If there are several network security managers

250

Satellite Networks

(for example one for each ISP), then the SID must be used together with BSM-ID of the source and destination entities, in order to identify a security association between two BSM entities. The security cases can be applied to both BSM star and mesh topologies. For a mesh topology with no on-board processor (OBP), STs communicate with each other through a BSM gateway (hub). For a mesh topology with OBP, STs communicate directly with each other without the need for the BSM gateway (hub). For a mesh topology with OBP, the BSM network security manager function can be located at any BSM ST [30]. Figure 4.15 shows the use of IPsec over BSM network in a security gateway-to-gateway configuration such as VPN over satellites scenario. The IPsec protocol operates above the SISAP. Security is provided between security gateways (that can be co-located with BSM ST or gateway). The security gateway consists of two functional entities: 1. Secure data handling entity (privacy/integrity engine): IPsec must operate in tunnel mode; 2. Key management entity: In a star topology, there will be a network security manager for the whole BSM network (co-located with BSM gateway/hub). In addition there is a local security manager in each ST. Figure 4.15 shows that all security entities are above the SI-SAP. The SI-U-SAP (i.e., the user interface) is used only to communicate all secure information (i.e., user data and key management messages).

User data privacy Supplicant Secure data handling (encryption engine)

BSM ST

SI-U SAP

BSM local security manager SID, keys

SI-M SAP

SI-C SAP

BSM network

BSM gateway SI-U SAP

SI-M SAP

SI-C SAP

SID, keys

Secure data handling (encryption engine)

BSM network security manager SID, keys

Authentication server

Authenticator

User data BSM billing entity

User data privacy

Key data Authorization data ST local key data

Figure 4.15

Case 1 IPsec and BSM security entities [30].

4.1 Introduction

251

The client authentication process (supplicant, authenticator, and authentication server entities) involves IPsec, which is used to carry authentication information (such as user name and password) between the supplicant and the authentication server. Both the authentication server and the BSM network manager communicate with the BSM NCC regarding security and authorization. These interactions are not shown in Figure 4.15. Registration and rekey security association must be established between the BSM network security manager and the local security managers in each ST. In the case of IPsec, the IETF Internet Key Exchange (IKE) protocol (RFC 4109) must be used to establish all security associations. This is necessary in order to ensure the mutual authentication between all security entities, establishing the keys used subsequently to secure the user data. Using IKE will also ensure compatibility between the BSM and the general Internet (terrestrial) security systems.

Figure 4.16

Mixed link layer BSM security entities [30].

252

Satellite Networks

The security association identity SID must be used in all security management message exchanges. IPsec for multicast (star topology) is a challenge because IPsec tunnels must be set from the BSM gateways per ST. This is effectively a unicast configuration and the benefits of IP multicast are lost [30]. Use of link layer security (below SI-SAP) with the key management (security manager) as an application above the SI-SAP in a star topology with a centralized security network manager (can be colocated with the BSM gateway/hub) is also possible. Examples of such systems are DVB-RCS with MPE or the unidirectional lightweight encapsulation (ULE) RFC 4326 IP encapsulation. Figure 4.16 shows the security entities above and below the SI-SAP. The diagram also shows that the SI-USAP (the user interface) is used to communicate secure user information, while the key management secure information is passed through the SI-C-SAP interface. The client authentication messages use the SI-U-SAP interface. Pure link layer security is applicable to ATM, DVB-RCS, and ULE security systems that are implemented in the BSM network in the satellite link layer only. This case is transparent to the BSM network. The BSM local and network security managers must be able to enforce the BSM security policy rules in this case such communication must use the SI-M-SAP interface. The security association identity SID must be used in all security management message exchanges. An end-to-end security architecture is applicable to end-to-end and remote access scenarios and is transparent to BSM network. In the case when end-to-end security is combined with other types of security architectures, a careful consideration must be paid to the BSM network performance degradation due to the dual security processing [30]. Further, it is important to ensure secure QoS signaling both in the user and control planes [37]. In the control plane, secure signaling is required between the resource management in the ST/GW and the NCC. The QoS messages between the ST/GW and the NCC must be authenticated and optionally may be encrypted (this depends on the security policy for the BSM network). In BSM networks, the common open policy service (COPS) protocol can be used to carry QoS or security information between the BSM management entities and satellite terminals (gateways/ST) (RFC 2748). In addition, if COPS is used for QoS provisioning, then COPS Policy Provisioning protocol (COPS-PR) can be used for security policy transfer (RFC 3084). 4.1.4.3

Summary

The standardization activities described above were partially the work of FP6 EU-funded projects [2, 5]. For example, the FP6 IST Project SATSIX helped to establish a range of ETSI technical standards covering a range of issues focused on IP services provision over networks with integrated satellite subnetworks. The generic standards were further employed in the EU-funded work as a basis for project-specific solutions.

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

4.2

253

Functional Layers, Protocols, and Segments of Satellite Systems The transparent architecture shown in Figure 4.17 is part of a satellite system that supports the following communication scenarios: corporate, residential, and collective [39]. Both transparent and regenerative satellite scenarios are considered and also the convergence of both platforms, providing advantages to the systems in terms of system capacity, system coverage, and system services. Figure 4.18 shows the regenerative platform architecture for providing the services defined for the three scenarios. Next generation satellite platforms have to migrate towards DVB-S2 and an adaptive return link: intended as the signaling to transfer MODCOD, CNI, modulation, and coding formats among space and ground segment elements [39]. This is mostly relevant to regenerative satellite systems for the closed loop operations involving the system elements and impacting on connection behavior and performance. The uplink boards of the regenerative subsystem can measure the quality of the bursts received. This feedback will be sent to the NCC when a CSC or a SYNC message is decoded. This is the information needed to modify the modulation and codification for a better adaptation in the uplink or the downlink. The RCSTs for a next generation communications satellite system must be low-cost and high-performance satellite terminals, providing interfaces with final users. All terminals should transmit based on adaptive DVB-RCS and receive based on DVB-S/S2. At the time of writing of this book, the terminals transmission is based on DVB-RCS (not including the adaptive return link) and the reception on DVB-S.

Figure 4.17

SATSIX transparent platform architecture [39].

254

Satellite Networks

Figure 4.18

4.2.1

SATSIX regenerative platform architecture [39].

Functional Layers

Functional layers are introduced to facilitate the system engineering. The system layers can be split up into a user plane, control plane, and management plane. The physical and access layers as part of the user and control planes for the satellite system architectures shown in Figures 4.17 and 4.18 are implemented in both ground and on-board equipment. In the satellite, the physical layer is shown twice to emphasize the split between the uplink and downlink transmission functions. The management functions are implemented in the ground equipment for both platforms and also in onboard equipment for the regenerative platform. The network layer is implemented only in the ground equipment. The physical layer (user plane) and the access layer (user and control planes) implement the DVB-S2 and the DVB-RCS (MPEG or ATM) standards. 4.2.2

Protocols

The SATSIX satellite system allows MPEG and ATM profiles in the uplink and this implies a particular protocol stack for the traffic and signaling between RCSTs and between RCST- NCC/hub. The reference protocol stacks for the user plane of a SATSIX DVB-RCS system are shown in Figures 4.19 and 4.20. The return signaling message formats are defined in the DVB-RCS standard. The signaling messages are composed of CTRL/MNGM messages mainly dedicated to the connection control protocol message, which are DULM encapsulated, and specific logon (CSC) and synchronization (SYNC) bursts. The capacity requests are transmitted via the SAC field associated to each SYNC burst. Signaling tables are encapsulated in PSI or SI, according to the DVB-S standard. The RCST specific messages (TIM) use DSM-CC encapsulation as defined in the DVB-RCS standard. The on-board reference clock is transported in the adaptation field of the dedicated PCR

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

Figure 4.19

SATSIX transparent user plane protocol stack [39].

Figure 4.20

SATSIX regenerative user plane protocol stack [39].

255

MPEG-2 packet. Each MPEG-2 TS Packet is associated with one transport stream (TS) logical channel, which is identified by a 13-bit packet ID (PID) carried in the MPEG-2 TS packet header. Also, the SI/PSI tables are uniquely identified by a PID in the TS. The reference protocol stacks for the control plane of the system are shown in Figures 4.21 and 4.22. In Figure 4.22 the OBP control commands used by the NCC for MUX reconfigurations, are DULM encapsulated. The CSC/SYNC bursts are on-board processed: they are translated into DULM information element (IE) to be inserted into MPEG-2 packets. 4.2.3 4.2.3.1

Ground Segment Transparent Platform

The network has a typical star topology. The central node or hub contains the NMS, the satellite front-end, IP infrastructure, and the terrestrial networks interfaces. The ground segment for the transparent platform is shown in Figure 4.23.

256

Satellite Networks

Figure 4.21

Control plane protocol stack for the transparent satellite architecture [39].

Figure 4.22

Control plane protocol stack for the regenerative satellite architecture [39].

Figure 4.23

Ground equipment of the transparent platform [39].

The platform offers bi-directional IP connectivity between terminals and between terminals and terrestrial networks, always through the hub, allowing different services such Internet access, Intranets/VPNs, VoIP, and multicast. On the other hand, MPEG2/DVB-S unidirectional services are available from the hub to the terminals.

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

257

The DVB-RCS hub consists of an antenna pointing to the satellite, RF equipment, and the gateway with terrestrial networks interfaces. The structure for the hub is shown in Figure 4.24. The operational frequency band is the Ku band, for both forward and return links, with both Europe-Europe and American-Europe connectivity. The subsystems, of which the gateway is mainly composed, are shown in Figure 4.25. The interfaces between the ISP/operator and the hub are part of the network management system (NMS), which manages the user traffic and services provision. The NMS also performs the control and supervision of the hub equipment, network, and terminals. The forward link subsystem (FLS) encapsulates the IP packets in the MPEG-2 frames and transmits these frames on a TDM carrier, baseband modulated. In the RF equipment, the modulated bit stream is upconverted and sent to the antenna, which transmits it up to the satellite at frequencies in the Ku band. The return link subsystem (RLS) ensures that the gateway antenna receives the downlink signal at

Figure 4.24

Generic block diagram of the hub [39]

Figure 4.25

Functional architecture of a gateway [39].

258

Satellite Networks

the Ku band and downconverts it to the 950–1450-MHz IF band. Thereafter, the RLS filters the different return channels that compose a superframe, demodulates the signal, decodes the TDMA bursts form the terminal, and extracts the frames containing the IP packets and sends them to the hub station Ethernet. The reference and synchronization subsystem (REFS) receives time signals from the GPS and provides synchronization and timing for the different gateway subsystems. An IP infrastructure, makes possible the establishment of the management and traffic networks as well as the routing between the Internet and the different subsystems. User terminals provide bi-directional services through the satellite network. These terminals consist of an InDoor and an OutDoor Units, also DVB-RCS standard compliant. 4.2.3.2

Regenerative Platform

The functional architecture for the regenerative platform is shown in Figure 4.26. A management station (MS) manages all the elements of the system. It also controls the sessions, resources, and connections of the ground terminals. It is composed of the following subentities: 1. The NCC, which controls the interactive network, provides session control, routing, and resource access to the subscriber regenerative RCSTs and manages the OBP configuration and DVB-S/DVB-RCS tables. 2. NCC_RCST, the satellite terminal of the MS, supporting modulation and demodulation functions to access to the satellite.

Figure 4.26

Functional architecture for a regenerative platform [39].

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

259

3. A network management center (NMC), in charge of the management of all the system elements. An element manager (EM) is responsible for the management of the redundant NCC (including NCC-RCST) and of the GWs, while a network and service manager (NSM) is responsible for the management of the VSNs, service providers, RCSTs, and telecom services, and NCC-initiated connections. The RSGW provides functions similar to those offered by the GW in the transparent networks (TSGW). It provides interconnection with terrestrial networks (ISDN/POTS, Internet, and Intranet). At the same time, it manages all its subscribers, guaranteeing their service-level agreement (SLA). The RSGW as well establishes point-to-multipoint connections to provide a dynamic star multicast service. In the transparent platform, there is only one TSGW, but the regenerative platform supports several RSGWs. This implies that the maximum transmission and reception rates are lower than in the transparent platform case, as the total bandwidth for interworking with external networks is shared between all the RSGWs in the system. 4.2.4

Common Equipment

In order to provide for more complete triple play or corporate services the RCST (transparent or regenerative) can have different equipment attached to it. For example, in the consumer network scenario, a home gateway entity (fixed/wireless) would interconnect and integrate all kind of products in the home, all working together in a common home automation system. The home gateway is a device that ensures continuity between the home network(s) and the in home connected devices and the satellite network (also with the external networks accessible through the satellite network). It can be fixed or wireless. In the operator network, an IP DSLAM equipment could serve a group of users by providing them connection to an ADSL provider through an RSCT near to the customers. Users in different continents could receive the service without significant performance inequalities between them. A video on demand (VoD) server can provide such services for satellite networks although near video on demand (nVoD) fits better in this domain. NVoD means transmitting an IP video over multicast, by taking an advantage of the data replication on board of the OBP (in transparent systems data is replicated in the uplink). 4.2.5

Convergent Satellite Platform

A convergent satellite platform is the combination of the transparent and regenerative connections, in a way that could be observed by the end user and INAP operators as a unique platform. The advantage is the exploitation of regenerative or transparent connectivity only for those services or applications that really require each of them (i.e., depending on the type of service and application). The convergent system should allow full connectivity between different beams. Depending on the level of the integration between the transparent and regenerative parts there are different modes of operation based on this architecture:

260

Satellite Networks

•

•

•

•

Loose integration: Both systems work independently except for a common management system that allows for configuring a terminal as transparent or regenerative. The operator decides at a time of provisioning, what system the terminal will use. Medium integration: A terminal is provisioned as transparent or regenerative but the NCC/hub can decide to change this assignment depending on the service it is using. A logoff of the terminal is needed to change from the reception of one DVB-S2 flow to the other (note that the DVB-RCS uplink is shared by the two systems). The advantage of this solution is the cost reduction in management for a change of service (no operator is needed). Tight integration: In this case there is a collaboration between the NCC and the HUB to manage the available resources. For example, before switching from transparent to regenerative the HUB could ask the NCC if there are enough resources for the connection requested. If this is not the case, the hub will perform the mesh connectivity with double hop (if possible). Full integration: The terminal must have two DVB-S2 receivers so that it can handle the two DVB-S2 streams. Depending on the type of service it will decide to use one path or the other. Another step is to decide dynamically what bandwidth of the transponder would be dedicated to the transparent and the regenerative system depending on the current network status. This would imply impacts at satellite level (active filters instead of passive filters, etc.).

Medium integration is a good alternative for implementing a convergent solution. The rest of the modes are rather complex. Figure 4.27 shows a convergent network management system (NMS). In a scenario of a user (RCST) moving from transparent to regenerative and going back to regenerative, the key will be mesh connectivity. An example of a medium integration hybrid scenario with mesh connectivity is shown in Figure 4.28.

Figure 4.27

Centralized management system [39].

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

Figure 4.28

261

Medium integration hybrid scenario [39].

As soon as there is a request of a mesh connection the terminal will pass to the regenerative platform. If other connections are demanded, while in this situation (e.g., a connection to the Internet) they will be provided within the regenerative system with its own resources. It is assumed that C2P protocol is compatible to regenerative and transparent modes. The disadvantage of this solution is the time to start the service. When the mesh connection is finished a graceful switchover may be triggered to return to the transparent system. The NCC calculates the superframe where the RCST will move to the regenerative system to prepare the TBTP and not to waste resources. In the case, when the NCC or the called RCST rejects the connection the HUB will check if it can provide the resources in the transparent mode and respond accordingly. The HUB will synchronize as a normal RCST in the regenerative system at startup. No other RCST is allowed to do so until the hub has reached the fine synchronization with the NCC. 4.2.6 4.2.6.1

Satellite Payload Regenerative Payload

The next generation on-board processor (OBP) has to combine DVB-RCS and DVB-S2 standards into a single multispot satellite system allowing cross connectivity between the different uplink and downlinks thanks to the signal processing on board [39]. Providing the packet-level switching and multiplexing, it has to be designed to physically support the IP multicast on-board. The OBP payload must support

262

Satellite Networks

configurations from the management station, or through the standard (TM/TC) channel. The regenerative payload offers multiplexing and demultiplexing of MPEG-2 transport streams and is therefore not only capable of offering IP services over MPEG-2, but also allows for the routing of the flows. At the physical layer, an improvement of the OBP usage is mainly due to the reduction of the data communication path to 1/2 of the typical transparent satellite path. In a transparent satellite, both the degradation of the C/N0 uplink and downlink need to be considered, obtaining a total figure of the link C/N0. In the case of regenerative, only the uplink C/N0 needs to be considered. Depending on the uplink and the downlink link budgets, a maximum improvement of 3 dBs in the link budget conditions could be obtained with the regenerative strategy [39]. OBPs are typically placed before the satellite TWTAs, which are the main contributors of the nonlinearities affecting the signal quality. OBP is especially well oriented when the modulations sensitive to the nonlinearity are involved in the uplink scheme (i.e., 16-APSK, 32-APSK). Furthermore, in a regenerative scheme, the uplink is a multicarrier with different power levels in each carrier, while the downlink is a monocarrier TDM, with a constant and guaranteed power level. The multicarrier is removed from the TWTA input and replaced by a monocarrier constant signal, reducing substantially the nonlinearity effects. The OBP payload has to include a number of DVB transponders, each one composed of the following elements: •

•

•

A Ku-IF down-converter (DOCON) in charge of transposing the input channel from the Ku to the BB frequency. A baseband processor (BBP) module, whose role is to demultiplex, demodulate, and decode the carriers located within a transponder bandwidth in order to generate a single multiplex of MPEG-2 or ATM packets following the DVB-S2 standard using carriers from any input transponder. A Ku modulator that performs I/Q modulation in the Ku band.

4.2.6.2

Transparent Payload

The transparent payload is a conventional payload used for audiovisual services. DVB-RCS signals are uplinked in a multicarrier and a frequency-hopping group to the DVB-RCS hub, which is transmitting a saturated DVB-S carrier in a 36-MHz full-transponder. Thus, the transparent payload has not the complexity of the regenerative one, and acts as a mere “repeater” in the air. The transparent payloads are typically used by GEO satellites for applications, for which the Doppler translation and retransmission of the uplink noise is less of a problem and, for which, multiple spot-beams are not required [40]. The benefits of a transparent payload for satellites can be summarized as follows: •

High flexibility, because even if digital filtering or scheduled switching is used, these can be reprogrammed from the ground;

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

•

• •

263

Easy separation of service provider traffic (i.e., separately leased bandwidth at layer 1); Long life; Relatively low cost.

The specific technical issues considered in respect to transparent payloads are the Doppler shift, which is translated from uplink to downlink for transparent payloads and can make the overall (uplink plus downlink) Doppler shift worse or better depending on the frequencies and orbit types; and the correlation of fades. The Earth station receiving the downlink will suffer outages due to fades on the uplink and downlink, but these may not be correlated. Further, the transponder resource is either power or bandwidth limited. For example, in the case of an frequency division multiple access (FDMA) scenario with a transparent payload, where many narrowband signals pass through one quasi-linear transponder, on-board filtering and a level control on each uplink could be advantageous in giving a constant downlink effective isotropic radiated power (EIRP) for each uplink. Without automatic level control (ALC), the uplink fade reduction of the uplink signal will automatically appear as the same reduction of EIRP on the corresponding downlink signal. Although the on-board level control will not prevent degradation of uplink C/N, the overall end-to-end C/N degradation with ALC will be less than without the ALC. The implementation of filtering and ALC is probably most easily achieved by means of sampling/ digital filtering techniques, especially if many simultaneous uplinks are present. 4.2.6.3

Convergent Payload

The convergent payload is a next generation type of payload. It is a mixed payload that combines the transparent and regenerative payloads. The users of the system can use the regenerative or transparent payload depending on the service, for example, using the regenerative payload for real time or multicast-based applications and the transparent payload for Internet access. It is reasonable to expect that most of the convergent system traffic (mainly Internet data) may use the transparent payload. To be able to offer competitive solutions in price to the different users, the regenerative system will be used only in the case of mesh communications and certain multimedia services. All services that require mesh connectivity can be provided by means of the regenerative system. Those services that require star communication can be provided by means of the transparent or the regenerative system, depending on the service. Table 4.3 shows an example classification for the different services and the type of payload these can use. All services should be provided by both worlds in the case that a user needs a mix of them simultaneously (e.g., a mesh connection and an Internet connection). The Virtual Satellite Network (VSN) concept is an equivalent in satellite networks to the terrestrial networks Virtual Private Network (VPNs). The VSN can be considered as a group of RCSTs that share certain resources:

264

Satellite Networks Table 4.3

Service Classification

Service

Transparent

Internet access service

X

Regenerative

Intranet access service/VPN

X

IP multicast data service

X

LAN interconnection service

X

Audio/Video communication service

X

Asynchronous E-services (e-medicine, e-commerce, e-government, e-learning...)

X

Synchronous E-services (e-medicine, e-commerce, e-government, e-learning...)

X

Video on demand

X

Software download

X

•

•

IP addressing: VSNs provide IP isolation to their RCSTs. This means that the terminals belonging to the same VSN can use the full IP addressing plan. Satellite capacity: For each route defined in the system, the system permits to reserve bandwidth (guaranteed and nonguaranteed) to a VSN.

4.2.6.4

HAPS Payload

In general terms, the HAPS payload can be processing or transparent [40]. A processing payload can be defined as one that demodulates the signal and makes decisions about switching or routing based on the contents of packet headers. A transparent payload is one that re-transmits the received signal without demodulation. It is irrelevant whether analog or digital channel filters are used or whether the carriers are switched between beams according to a schedule. It is assumed that satellites in geostationary orbits are the only type of platform that would incorporate a transparent payload. This is because nongeostationary satellites and HAPS will use steerable beams with cross-polarization correction and the benefit of these cannot be realized with transparent transponders. HAPS systems offering 3G services need to offer interoperability with standard 3G handsets, although the spectrum allocation to HAPS systems might prevent this. The Ka- and V-band capacity could be used to provide a fat-pipe backbone channel between the platform and terrestrial gateway station. The network integration requirements (i.e., backhaul to terrestrial gateways, end-user CPE equipment, inter-HAPS links) bring some complexity load on the payload configuration. For example, the carrier signals would need to be terminated (demodulated, decoded, decrypted, etc.), switched, and routed towards the appropriate spot-beam or backbone link. Therefore, the HAPS platforms for mobile communications tend to use on-board processing (OBP) payloads. 4.2.6.5

Queuing

The management of queues is a principal overhead on the processor; there will typically be at least one queue per uplink beam and one per downlink spot-beam. There-

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

265

fore, each packet will need to be processed by at least two queues, which are not independent, which in turn complicates the theory for the overall delay [40]. Packets should be ordered and removed from queues to comply with delay and delay variation requirements and to cooperate with mechanisms such as early packet discard. If packets are switched, the processor has to read the addresses and consult a lookup table for the correct beam number. If packets are additionally routed, there would be a requirement to consult a routing table and to accommodate routing table update protocols, such as open shortest path first (OSPF). The queue will also contain packets of varying priority, which will mean additional reordering, and possible discarding. The overhead with managing queues will be higher when the payload is operating at higher frequency bands, (e.g. V-band, because of interruptions to the link). This will cause packets to arrive incomplete and result in an increase in useless cells in the queues and incomplete packets at any layer 3 processes. The payload would have to make a decision on whether to search out and discard these cells from within queues or wait until they reach the head of the queue before discarding them. 4.2.7

Network Topologies for HAP-Based Systems

Network architecture requirements depend on the network topology targeted for different market segments [40]. A number of different network topologies foreseen for HAPS connectivity are shown in Figure 4.29. These include the following: •

The access network via the HAPS connects the end user(s) to the core network edge. This is the typical network configuration for broadband Satellite overlay (optional)

Core network

Access network: Broadband last-mile content distribution

Core network trunk

Point-to-point Point-to-multipoint

Figure 4.29

HAPS connectivity [40].

HAPS private networks Corporate private networks Virtual LANs

266

Satellite Networks

•

•

•

Internet/Intranet and for multicast/broadcast services to (low-cost) user terminals. The content distribution is enabled to content providers via the core network (backhaul). The content is distributed via the HAPS to the end user terminals (e.g., TV broadcast, content distribution services via IP multicast, VoD). As the above, this configuration can be considered as an access network, but for the content distribution a high bandwidth is essential in the ground segment (e.g., content provider to HAP). The core network trunk (bearer services) is connected via the HAPS at two points within the core network. Point-to-point private circuits (bearer links) could form a part of the core network perhaps as part of a core network overlay to provide network resilience. The inter-HAPS connections were also considered here. The HAP private network is enabled by the connection of two or more users to form a VPN, with or without the direct connectivity to the core network. This is the classic use of VSAT to provide a private data network, (e.g., for point of sale credit card authorizations, stock control, financial, and insurance services).

The HAPS network architecture is best described as a local multipoint distribution system (LMDS) [40]. It is a radio technology that provides broadband network access to many customers from a single or multiple HAPS platforms (base station in the air). Although LMDS specifically refers to a frequency allocation in the United States, the term is generally used to refer to broadband, multiservice radio access systems. These systems are also sometimes known by other terms, such as broadband wireless access (BWA), broadband point-to-multipoint (PMP), or broadband wireless local loop (B-WLL). A major benefit of broadband radio access via HAPS is that once the HAPS platform is in place, the remaining infrastructure required is only the customer units. Hence, this enables provision of high-bandwidth access in a very expedient manner. The HAPS radio broadband system can be used to extend the coverage of terrestrial broadband networks, such as fiber rings or ADSL, without the need to negotiate wayleaves and build infrastructure, such as cable ducts (although it is usually necessary to negotiate roof rights for both HAPS ground-station equipment and customer equipment). 4.2.7.1

Single-HAPS Platform

A single HAPS platform scenario (i.e., only one flying platform used) is envisaged for providing an ad hoc network for special events (e.g., Olympic games), disaster recovery, or rapid broadband employment over highly populated cities for either staged network deployment (i.e., large numbers of end broadband users located in relatively small geographical area). Customers are connected within a cell (i.e., HAPS footprint) that may typically have a radius of around 40 km from the central base station. The HAPS is usually connected to the remainder of the network using fiber (i.e., tethered balloons) or point-to-point radio (for airships). The ground station acts as a hub for the network

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

267

and provides service to customers who are in direct line of sight with the HAPS antenna and within the cell radius. Generally, it is possible to further split the cell area into a number of sectors, which allows the cell radius, and the capacity offered within a cell, to be increased. LMDS allows flexibility in the way that capacity is allocated to customers (e.g., asymmetric circuits can be allocated in addition to symmetric circuits and QoS options can be offered for data circuits). Many systems also allow bandwidth to be allocated on demand [40]. The point-to-multipoint topology of an LMDS system is not dissimilar to that of a cable modem in that the BS sends information to all end customers within a radio sector on a single radio link and the customer premises equipment selects the information intended for it. Typically, a single HAPS platform may provide an asymmetric capacity of around 200 Mbps to be shared between the users in a cell, with the couple of Mbps capacity on the return link, also shared (e.g., LMDS can outperform ADSL in terms of upstream data rates [41]). The core network infrastructure used to connect to HAPS ground stations is virtually the same as that used to connect ADSL exchange units (DSLAMs), and hence, the technologies can be deployed in a complementary manner. 4.2.7.2

Multiple HAPS Platform

The main purpose of increasing the number of HAP platforms is to provide national or regional broadband coverage whereby inter-HAPS links form part of the overlay core network with one or more gateway stations providing the backhaul connection to the terrestrial core network [40]. Multiple HAPS platforms can also be deployed to serve a common coverage area in order to increase the capacity provided per unit area (i.e., the bandwidth efficiency). A multiplatform HAPS architecture is shown in Figure 4.30. The other reasons for this platform configuration are to provide resilience (e.g., backup systems) and also to provide spatial diversity to end users receiving antennas for improved service availability (e.g., improved line-of-sight (LOS) coverage). Normally, the coverage area is split into multiple cells to increase the capacity. This technique can also be adopted with a multiple platform scenario. Multiple HAPS can increase the capacity by exploiting the directionality of the fixed user antenna, which is typically a dish with relatively narrow beamwidth. The narrow beamwidth is required to provide sufficient gain to support the link budget, but additionally it can be exploited to reduce the levels of interference progressively from other HAPS arranged at an angle away from the boresight of the user antenna. 4.2.7.3

Reference Model of a Network Architecture

An HAP network may use either a nonregenerative or a regenerative HAP architecture [40]. A nonregenerative architecture refers to an architecture commonly called bentpipe architecture. This architecture does not terminate any layers of the air interface protocol stack in the HAPS; the HAPS simply transfers the signals from the

268

Satellite Networks

Figure 4.30

Multiple HAPS platform [40].

user links to the feeder links transparently. The implementation is easier but the functionality is reduced. A regenerative architecture is the range of architectures that provide additional functionality in the HAPS. In these architectures, the HAPS functions terminate one or more layers of the air interface protocol stack in the HAPS station. In addition, the protocol stack can be terminated at higher layer thus enabling additional functionality. For example, HAPS can be used as the router (network layer termination), on-board packet switching for multiple HAP architectures, signal regeneration, content buffer, etc. In addition, the mobility anchor point (MAP) can be put on the HAPS in the case of supporting mobile IP. A typical network architecture for providing IP-based services to fixed users and fast trains is shown in Figure 4.31. It consists of a single-HAPS platform, which is connected via a backhaul link to a gateway (GW) station, which connects to the Internet. Users are connected via fixed or wireless LANs to a HAP access termination (HAT) node. The main functionality of the HAT is the interworking between the user terminal, via a common interface (e.g., Ethernet adapter), on the user side and HAPS, via a radio interface (e.g., adapted 802.16 SC), on the other side. Simplified reference models can be derived form the network topologies described above. These are shown in Figure 4.32. A reference model of an access network scenario is shown in Figure 4.33. The interworking function (IWF) occurs at both ends of the network. One type of the IWF is required to translate the internal HAP interfaces (I.HN) to an external network (e.g., IP network), while the other IWF is required to translate the internal

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

Figure 4.31

Provision of IP-based services by a single HAP platform [40].

Figure 4.32

Simplified reference models [40].

269

HAP interfaces (i.e., I.HATU) to the external interfaces of the premises network (e.g., W-LAN). In the case of multi-HAPS network there is an interplatform link (IPL) between two HAPS, which represents an additional network interface, (e.g., I.HH). Figure 4.34 shows the reference model of a multi-HAP network scenario.

270

Satellite Networks

Figure 4.33

Reference model of an access network architecture [40].

Figure 4.34

Reference model of a multi-HAP network scenario [40].

Each HAPs platform can be connected to one or more other HAPS. Thus, different network topologies would apply (e.g., mesh). 4.2.8

Networking Topologies for Converged Satellite Systems

The following network topologies can be defined on basis of the satellite network architecture, and satellite payload features, and classified by considering the satellite transponder [39]: • • •

Star Transparent Network topology; Star / Mesh Regenerative Network topology; Mesh Regenerative Network topology.

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

271

The above topologies support different types of connections. Connections can be divided in function of the casting feature (i.e., unicast or multicast) and based on the type of connectivity (i.e., star or mesh). A connection is understood as a logical association between two or more network entities. Connections can be defined at different layers of the protocol stack (e.g., MAC connections, IP connections, TCP connections). They are defined as the means to propagate packets (traffic or signaling) with the same priority level from one network reference point to one (unicast) or more (multicast or broadcast) distant network reference points. In the context of C2P over DVB-RCS systems [39] a connection refers to a MAC connection enabling the transmission of packets in a MAC format from one network reference point to one (unicast) or multiple (multicast or broadcast) network reference point(s). The network reference points can be RCSTs (including the RSGW-RCSTs in case of regenerative systems of Amerhis type) or the NCC/GW. When the connection is defined at the MAC layer, the reference points are identified by their MAC addresses. An additional MAC identifier is needed for the purpose of encapsulation / reassembly at the reference points of the connection. One possible option could be the use of VPI/VCI (ATM profile) or PID (MPEG2 profile). If multiple connections are established between two reference points (e.g., for different service classes / priority levels), they can be differentiated by their PID or VPI/VCI values. One can, therefore, state that a connection characterized by a combination of the following parameters: •

• •

A pair (return and forward) VPI/VCI (ATM profile) or PIDs (MPEG2 profile) and a pair of MAC addresses; A pair of MAC addresses and C2P priority / QoS class; A pair of terminal addresses (logonID and groupID) and C2P priority / QoS class.

Figure 4.35 shows an Internet access one-hop connection based on star transparent and star regenerative network topologies. Figure 4.36 shows a unicast RCST to RCST star connection based on a star transparent network topology. A double hop is used to communicate two RCSTs in a star transparent network: it is equivalent to two star connections between a RCST and the TRGW. Figure 4.37 shows a unicast RCST to RSGW star connection, for access to RSGW LAN. The GW-RCSTs (the terminals of the RSGWs) may be connected to a LAN/LANs. The connection between a PC in this LAN and a PC in the LAN/LANs connected to other RCST is a star connection. Figure 4.38 shows a unicast RCST to RCST one-hop mesh connection. For multicast connections, the relevant elements that determine the connectivity type are the transmitters involved in the multicast transmission. The receivers are passive elements of the communication, so they are not considered as part of the connection.

272

Satellite Networks

Figure 4.35

Internet access connection through satellite [39].

Figure 4.36

RCST to RCST star connection [39].

For example, for a TSGW initiated star transparent multicast one-hop connection, the multicast flow must reach several beams. If there are multicast members on several beams, the NCC/TSGW must perform multicast replication to reach all the beam destinations. This is shown in Figure 4.39. Figure 4.40 shows an RCST sender mesh regenerative one hop multicast connection. To summarize, in the star transparent scenario the IP connectivity can be divided in the following two groups: 1. Star connectivity between an RCST and external networks. The RCST sends the data to the NCC/TSGW and it routes it to the Internet through an ISP network.

4.2 Functional Layers, Protocols, and Segments of Satellite Systems

Figure 4.37

RCST to RSGW star connection [39].

Figure 4.38

RCST to RCST mesh connection [39].

273

2. Star connectivity between two RCSTs, all the data is received in the NCC/TSGW and routed to the other RCST. This means that the connection between RCSTs is indirect (double hop) and the RCSTs only have direct connectivity to the GW. In both cases all the data goes through the NCC/TSGW, the first one needs two satellite hops, while the second one requires a satellite hop to reach the ISP. This is applied both for unicast and multicast communications, but for multicast in multibeam system the flow has to be replicated by the NCC/TSGW as many times as the destination beams, so if there are four destination beams the multicast flow is transmitted four times in the return link. The star/mesh regenerative scenario allows the following kinds of connections: •

Mesh communications between RCSTs in any user beam with RCSTs in the same beam or any other user beam in one hop. The RCSTs can be connected

274

Satellite Networks

Figure 4.39

A multicast TSGW initiated connection [39].

Figure 4.40

RCST initiated mesh regenerative multicast [39].

•

to an isolated LAN or to the Internet; in the case that one of them has Internet access and the other don’t have it the first one can act as GW of the second. This connection can be unicast or multicast. The mesh multicast service consists of the ability to statically transmit multicast flows receivable by the rest of the terminals in the VSN, which can be in the same or different beams. Star communication between an RCST and a RSGW for Internet access. This connection is also in a single hop. Star multicast connectivity allows the RCSTs to statically or dynamically receive a multicast flow coming from the RSGW. Dynamically means that the star flow will start only when a user joins a certain multicast session and it will stop when the RSGW access router does not receive membership reports for the group.

4.3 Interworking Between Satellite and Other Systems

•

275

Star connections between two RSGWs in a single hop. If one of the RSGWs is routing the traffic from this connection to an RCSTs the resulting connection would have a double hop. More than one RSGW per VSN (and only one GW-RCST) configured to transmit star multicast can lead to multicast addressing conflicts. Transmitting more than one MMT table per VSN can solve this [39].

The deployment of different connectivity services, such as Internet access service, intranet access service, LAN interconnection service, multicast, video and VoIP, video broadcasting, and so forth can be provided by network layer services, such as IP addressing, IP routing, QoS, network address translation, and security policies.

4.3

Interworking Between Satellite and Other Systems Interworking with other networks is one of the main requirements of any communication system. In general, there are two primary ways of solving the interworking issues: (1) loose interworking; and (2) tight interworking [40, 42]. Loose interworking is defined as the utilization of a satellite or HAPS network as an access network complementary to current access networks. There are no common network elements with other networks (i.e., avoiding the common SGSN, GGSN nodes, etc.). In the case of loose interworking the satellite network is more independent and flexible. In order to provide for IP compatibility, security, mobility, and QoS need to be addressed by using IETF schemes. In the tight interworking case, a satellite/HAPS network is connected to some other network as a subcomponent. For example, a HAPS network can be connected to the UMTS network (the core network) in the same manner as other UMTS RATs (e.g., UTRAN, GERAN). In this way, the mobility, QoS, and security mechanisms in the UMTS core network can be reused. In addition, the GGSN is the interface between the UMTS core network and the Internet. Similar requirements would apply to satellite networks whereby the multi-HAPS platform might need to communicate with each other via a satellite backhaul channel. In either case, the ability to seamlessly integrate with different core networks is seen as an essential requirement. The long-term vision of the NGN) is that all network components will be complementary parts of a fully integrated multiplatform multiservice global network (e.g., definitions of 4G, 5G) [40]. 4.3.1

Mobility and Handover

The requirements for mobility and handover differ depending upon the type of network involved. For example, mobility within and between HAPS networks shall be supported between HAP networks belonging to different administrative domains. Handover shall be provided within a HAP network belonging to the same administrative domain. Handover might be performed based on a link layer network handover procedure with the possible addition of higher layer mobility protocols. In light of the all-IP concept, mobile IP and all its variants are recommended. Handover

276

Satellite Networks

should be supported within a HAP network belonging to different administrative domains [40]. Mobility between HAPS and other networks, on the other hand, would require full association and authentication within the respective network; the terminals shall support mobility between different HAP and other networks; and mobility between administrative domains must be supported. When needed (e.g., for QoS purposes), upper layer mobility in satellite systems such as the one shown in Figure 4.17 can be provided by SIP applications with QoS support, maybe combined with an MIPv6 architecture. The localization of the access router, separated or integrated, with the satellite terminal/BS determines the transport format over the satellite (e.g., tunneling or native IPv6 transport). With an integrated access router more than one subnet can exist behind the satellite terminal/BS. In this case, optimized techniques, such as hierarchical mobile IP can improve the mobility process if moving to another subnet, because micromobility inside the visited network is managed locally without involving the home agent. For example, layer 2 mobility and handover can be included in the WiMAX/WiFi part of the local network, where handover (fast handover) has to be combined with Mobile IPv6 solutions (MIPv6) [39]. With an access router separated from the satellite terminal/BS, the transport over the satellite will be at layer 2. The layer 3 mobility will be anchored in the core network (behind the satellite gateway for a transparent satellite). An example of mobility with tunneling of IP packets through a satellite/WiMAX network is shown in Figure 4.41. A functional mobility architecture in a star topology is shown in Figure 4.42. In this case, the home agent (HA) is located in the GW subnetwork, and the GW AR provides PMIP functionalities to support non MIP-aware or MIP-capable users. Integrated RCST/BS, separated RCST and BS and stand-alone RCST cases are considered. In a mesh topology, the HA is located in the home network behind a particular RCST [39]. 4.3.2

QoS

When defining the QoS requirements for a satellite network, the restrictions and limitations of the radio interface should be considered [40]. Although it could be a

Figure 4.41

Mobility with tunneling of IP packets through the satellite/WiMAX network [39].

4.3 Interworking Between Satellite and Other Systems

Figure 4.42

277

Functional mobility architecture in a star topology [39].

very complex task to define QoS mechanisms that include the air interface, the QoS mechanisms provided in a satellite network have to be robust and capable of providing reasonable QoS solutions. The following capabilities should be supported in the overall QoS requirements for a satellite/HAPS system [40]: • •

•

•

•

•

•

QoS provisioning should be subject to the users subscription; It should be possible for a satellite/HAP network operator to monitor the QoS provided to the users; It should be possible to charge a user based on the level of QoS provided and on the QoS subscribed; The provisioning of QoS in the satellite/HAPS network should have a minimum impact on the provisioning of QoS in other networks; It should be possible for applications to request QoS treatment for their communications through one mechanism independently of the access network used; It should be possible to prevent unauthorized users to send (upstream) inadmissible data through the network; The QoS mechanisms towards external networks should be aligned with the IP mechanisms (in order to simplify interworking with the ISP platform of the operator). Additionally, it should be possible to easily integrate, in the future, the IP multimedia subsystem QoS requirements.

In order to meet the user requirements the following QoS components shall be used [39]:

278

Satellite Networks

• •

•

•

•

•

•

A SIP proxy, in charge of the QoS-aware applications; A QoS agent, in charge of the non-QoS aware applications. It sends the wanted QoS level for a given traffic flow to the QoS server; A QoS server, in charge of collecting the QoS information of the traffic flows and of configuring accordingly the IP and MAC layers; A Protocol Extension Protocol (PEP), in charge of the TCP and HTTP acceleration in order to limit the delay for the corresponding applications; IP compression, in charge of the header compression in order to decrease the overhead introduced by the successive stacks and thus decrease the load and the delay; An IP QoS, in charge of the classification, the marking; the policing/shaping/dropping, and the scheduling at the IP layer; it should provide a transparent service in terms of QoS and mobility management; A MAC QoS, in charge of the queuing, dropping, and scheduling at MAC layer.

The above require a dynamic QoS architecture in support of the specifics and requirements. Two approaches were proposed in the FP6 IST project SATSIX in support of the designed satellite platform. The first one is based on an IP-oriented approach using SIP proxies or specific signaling (e.g., QoS agent / QoS server / access resource controller) between the RCST and the GW (see Figures 4.19 and 4.20). Proxies are in charge of configuring the IP and MAC components directly, without any MAC signaling path [39]. The second one relies on the concept of access connection in an MAC-oriented approach. The dynamic QoS depends on the information provided by the proxies (SIP, QoS server, etc.) but the communication between the RCST and the GW is based on the use of the C2P protocol. The resulting dynamic QoS architectures are shown in Figures 4.43 and 4.44, respectively. The disadvantages of the QoS architecture in Figure 4.43 are that it is needed to have several proxies at both, the RCST and GW side (SIP proxy). Further, it only addresses the DVB-RCS star systems. Indeed, the mesh case cannot be handled directly, mainly due to a connectivity problem (non-QoS specific) as long as the RCST have to retrieve the destination identifiers, but also due to the need to route the SIP signaling to the NCC (the signaling path and the traffic path are different in this case). The QoS architecture in Figure 4.44 requires a longer establishment time due to the need to establish the C2P connection, which adds into complexity. The ability to handle both regenerative and transparent DVB-RCS topologies is a major advantage. The regenerative topology is a means to retrieve the destination identifiers to transport the traffic flows at the MAC layer. The DVB-RCS C2P is a natural way to implement this feature because it was designed especially for this purpose [39]. In this case, the QoS architecture benefits from the C2P facilities. A convergent architecture, therefore, able to address both transparent and mesh systems should be based on C2P. The only drawback of this solution is the impact on the establishment delay in the star topology case. A solution can be to use the

4.3 Interworking Between Satellite and Other Systems

Figure 4.43

IP oriented QoS functional architecture for transparent star topology [39].

Figure 4.44

MAC oriented QoS functional architecture in a regenerative mesh topology [39].

279

connections between the RCST and the GW established during the logon phase in order to address the transparent systems and to only use C2P to modify dynamically the characteristics of the connection in function of the SIP proxy or QoS server information. Such solution allows for having the same QoS architecture independ-

280

Satellite Networks

ently from the target system, to avoid the impact on the establishment delay in the transparent case, and to avoid the use of a SIP proxy in the GW. In any case, most of the functions are the same in both architectures, and the IP-oriented one can be seen as a first step towards the convergent QoS architecture. Figure 4.45 shows a functional architecture to be deployed in order to support application layer mobility scenarios. Such an architecture is based on the use of SIP. A QoS-aware application using SIP is provided with a mobility mechanism. The used mechanism can be either MIPv6 or HMIPv6, depending on the kind of scenario considered. To support SIP mobility, the architecture needs to implement all the devices defined in the SIP architecture, (e.g., SIP registrars). These elements must be available in the satellite access network. If the network topology is meshed, its location depends on the choice of the satellite network operator. In a star topology, these elements are located behind the gateway. A QoS-based connection setup requires the interaction of three control functions: (1) routing, (2) Call admission control (CAC), and (3) resource reservation. These control functions are performed separately in the network and the decision of one influences the decisions of the others. The CAC and the reservation processes are highly dependent on the path selected by the routing algorithm. Combining these functions together without having enough information about the path may cause reservation of a path that includes links with insufficient bandwidth to accommodate the call. Consequently, it will result in long setup delays and high blocking ratios. IP support in DVB-S(2)/DVB-RCS networks involves the usage of Internet multicast protocols at satellite stations. IGMPv2, (i.e., RFC 2236 [32]), is the protocol used in the Internet for signaling group membership to multicast routers in IPv4 networks.

Internet CN

MN network

MN network

Figure 4.45

MN

Functional SIP mobility architecture [39].

4.3 Interworking Between Satellite and Other Systems

281

IPv6 no longer makes use of broadcast addresses, but uses more intensively IP multicast addresses [39]. These IPv6 multicast addresses can be assigned permanently or temporarily, and can be valid within different scopes. The IPv6 multicast listener discovery (MLDv1) protocol provides a mechanism for IPv6 multicast routers to discover on these interfaces hosts interested in receiving IPv6 multicast packets. Multicast listener discovery (MLD) enables each IPv6 router to discover the presence of multicast listeners on its directly attached links and to determine, specifically, which multicast addresses are of interest to those nodes. MLDv1 is defined in the IETF specification RFC 2710. MLD is IPv6 specific and is equivalent to the Internet Group Management Protocol (IGMP) in IPv4. MLDv2 adds the support of a source-specific IP multicast. MLDv2 is equivalent to IGMPv3 for IPv4. There has been some previous EU-funded work [43] in adapting the IGMPv2 for the satellite environment for the scenario DVB-S(2)/DVB-RCS transparent source in the Internet. This work was standardized under the ETSI TS 102 293 V1.1.1 IGMP Adaptation. MLDv2 must be adapted to the satellite environment, where the new features necessitate a different approach to adaptation. In addition, multicast routers build a multicast tree for distribution of data in the multicast network, and multicast routing protocols, such as DVMRP, MOSPF, and PIM (DM and SM), perform this function. In a DVB-RCS network, gateways will behave as multicast routers and thus they will feature a multicast routing protocol. Terminals usually will have multicast end nodes, and in these cases IGMP/MLD proxying is enough to provide multicast services to the attached networks. In other cases the organization of networks attached to terminals may be more complex and involve also multicast routing protocols, but terrestrial networks attached to terminals will finally behave as leaf nodes in the multicast tree, and a solution based on IGMP at the terminal can be used to signal group membership to the satellite-enabled multicast network. OBP support for IP multicast is possible, with multicast routing capabilities. 4.3.3

Interworking Between Layer 2 and Layer 3 in an HAPS-Based System

The underlying wireless access technologies applied in HAPS networks such as IEEE 802.16 have their own mechanisms to ensure QoS in the link layer [40]. To provide end-to-end QoS, architectures such as Diff-Serv [44] Int-Serv [45] should be considered. Mapping of the link layer QoS to the IP layer QoS architecture is the primary task of the adaptation sublayer [40]. Another important task of the convergence sub-layer is the mapping between the IP address and link layer address or a session id. To enhance the performance of TCP, link layer automated repeat request (ARQ) can be applied to hide the random losses from the upper layers. ARQ is a link layer mechanism to retransmit the lost radio packets (link-layer data blocks). Without ARQ, any random loss will be evaluated as the congestion loss by TCP. ARQ is one of the most effective methods to enhance the performance of TCP. For VoIP applications using UDP, delay is more important than the loss rate [40]. ARQ improves the loss rate but at the same time increases the delay. This is the reason why ARQ may not be required for VoIP. The decision whether to apply

282

Satellite Networks

ARQ according to the upper layer protocols or traffic classes is also the task of the adaptation layer. The convergence sub layer should be defined independently from the underlying link-layer protocols. To this end, some assumptions about the link layer should be selected such as addressing, QoS, multicast, and broadcast mechanisms. The assumptions should be general in order to cover all candidate wireless standards for a satellite system. A centralized AAA server is required to manage and control the user access. Every HAPS can act as a network access server (NAS), to forward the user’s authentication information to the centralized AAA server. Selecting the AAA architecture may require a modification in protocol structure, which basically has an important implication on the implementation complexity of the protocol stack in the CPE as well as in the on-board BS. The AAA architecture must support other functionalities of HAPS networks, such as mobile roaming, which will require authentication from the AAA server and updated location information to the server 4.3.4

Security

Link layer security can be considered as an additional security mechanism to IPsec, TLS/SSL, and application layer security. Link layer security allows to combine the satellite/WLL link protection (providing data confidentiality) with a secure access control to a satellite /WLL network in an inherent way [39]. Moreover, with IPSec in a tunnel mode or SATIPSec, there is an extra overhead [i.e., the extra IP header (IPv4 or IPv6)], that link layer security avoids. The solution proposed for the satellite segment protection allows a network operator to provide similar functions to that of IPSec, but in addition provides an MPEG-2 transmission link confidentiality and protection of ULE receiver identity (NPA). Link layer security and its applied level will depend on the type of customers and applications. For example, in the case of a military use scenario, where, apart from the extremely importance for privacy and integrity of the data that is exchanged between the end points (which in general is encrypted/decrypted by the military network equipment), the protection of the identity of end points assumes a decisive role, too [39]. In a typical scenario, a military army have a geographically spread group of stations exchanging confidential information among them. In a first approach, the encryption of the data appears as a natural demand in the mutual communication process. Even if the intruders (e.g., enemies, spies) are not able to decode the information, they can detect which stations are involved in the communication process, which can trigger some undesirable reactions. Another issue is the amount of information that is exchanged between the sites. This point can lead the intruders to understand that some “movements” are being planned whenever the amount of data increases asynchronously. Therefore, link layer security becomes an identity protection issue [39]. In order to achieve a safety protection of the identity of the stations involved, the MAC address fields (destination and source) and the signaling exchanged between the HUB station and the military stations must be protected.

4.4 Conclusions

283

A key management system [39] can be defined for control/management systems for the unicast, multicast, and broadcast cases. Such a system can be designed to achieve maximum inter-operability with terrestrial IP networks (e.g., IETF IPsec protocols family). In addition, the key management system can provide for scalability (for very large global operations) and robustness against transmission and intrusion errors. The key management procedure could be done on an RCST-logon session level or on a connection-level based on C2P messages. For securing the communications at the MAC level, the C2P IE related to security shall be specified. The security solutions deployed to a scenario of a business network have to take into consideration the importance of the related cost. Regarding the aspects involved in the communication process in the business organizations, the privacy and integrity has appeared as the main issues that have to be guaranteed by the security mechanisms. Based on the experience of the network providers, this kind of customers are not interested in hiding the source, destination, nor the amount of information, as opposed to the privacy and integrity of the information. Therefore, link layer security has not been a main issue to the business organizations, whenever the high-level security is already applied. On the other hand, the encryption of sensitive data plays a decisive role in the required network solutions that are being deployed nowadays. Link layer security may become an important requirement in envisioned future use. Private customers do not demand low-layer security as a main feature in their communications. This major cluster, when the security issues are required, is identical to the business organizations (high-layer security solutions are sufficient). An important issue is to drive the research in the security field for the DVB-RCS industry to propose modifications in the control and management planes of the terminals and Hubs. A cost-effective specification is needed to promote the security enhancements. Figure 4.46 shows a general security functional architecture in the frames of SATSIX platform given for the data plane. Figure 4.47 shows the architecture for the control panel.

4.4 Conclusions The broadband service providers of today face the challenge of connecting an enormous number of diverse, relatively low-speed access services into their high-speed backbones. Supporting a wide range of access interfaces is a potentially complex and expensive undertaking but is necessary if all customers are to be served. Satellites and HAPS offer the potential to play an active role in providing broadband services in the core network segments (e.g., access network, content distribution, core network, private networks). Because larger bandwidth always costs more, particularly in the access network, an effective implementation of broadcast and multicast have a direct impact in providing every citizen with affordable broadband access. An active engaged

284

Satellite Networks

Application

DRM, HTTPs, XML web services

Transport

SSL, SSH

Network

IPSec*

Link End user

DRM, HTTPs, XML web services

SSL, SSH

IPSec/SatIPSec

IPSec/SatIPSec

IPSec/SatIPSec

IPSec/SatIPSec

WIFI/WiMAX security

WIFI/WiMAX security

L2 (SatIISec & ULE/AAL5)

L2 (SatIISec & ULE/AAL5)

WIFI/WiMAX terminal

WIFI/WiMAX access point

IDU

Gateway

IPSec*

Server

*Incompatibility with PEP and firewall

Figure 4.46

Security functional architecture: data plane [39].

Network

Link

DVB-S/RCS signaling security IDU

Figure 4.47

DVB-S/RCS signaling security Gateway

Security functional architecture: control plane [39].

population will use the technology for peer-to-peer broadband communications, and it this presumably can increase in the future. The future mobile satellite services will be provided by an increase in capacity and achievable bit rates, and will be focused on niche markets (the evolutionary approach). The convergence of broadcast with mobile satellite services and the advent of multicast services is another trend. The coverage extension for mobile terrestrial networks would result in a higher integration of satellite networks with terrestrial networks and the Internet. An evolutionary approach can steadily improve the existing mobile satellite systems. The cost and limited capacity for a mobile satellite component, requires the best possible system design for the mobile satellite access network, with the aim of serving the largest possible volume of users with the lowest possible utilization of satellite resources for the required QoS and service portfolio. Next generation mobile satellites will be required to provide higher levels of flexibility, and will need multiple gateways, which may not be fully deployed at the service startup. The processed capacity of next generation systems will be at least 10 or 20 times more than those of the current generation. The processors will need to interface with a much higher number of antenna feed array elements and cope with a range of new dynamic control techniques aimed at optimizing the system performance. If next generation mobile satellites are required to offer the anticipated increase in capacity, it has to be done within the context of severe mass, power, and dissipation constraints, and thus exceptional efforts are required on the appropriate technological developments to meet the needs of the next generation.

4.4 Conclusions

285

The difficulties associated with the control, accommodation, and deployment of large structures of this type are prime research areas.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[21]

[22]

[23]

[24]

[25]

FP6 IST Projects, Cluster of beyond 3G Architectures, at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST project CAPANINA, at http://www.capanina.org. FP6 IST Project WINNER and WINNER II, at www.ist-winner.org FP6 IST Project SATSIX, at www.ist-satsix.org. FP6 IST project VIVALDI, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project MAESTRO, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project ATHENA, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. Chider, D. M., “Satellite Communications for the Next Generation Telecommunication Services and Networks,” NASA Publication, 1991. International Telecommunications Union (ITU), at www.itu.int. ITU BR Workshop on the Efficient Use of the Spectrum/Orbit Resource, May 2009, Geneva, Switzerland, at www.itu.int. FP6 IST Project B-BONE, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project C-MOBILE, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 Projects and Cluster Results, European Commission, February 2008, at http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project BROADWAN, at http://www.telenor.no/fou/prosjekter/broadwan/. UMTS Forum, http://www.umts-forum.org/content/view/2700/174/. Oberst, G., “Satellite’s Digital Dividend,” Satellite Today, March 2008. FP6 IST project CAPANINA, “An Overview of the CAPANINA Project and its Proposed Radio Regulatory Strategy for Aerial Platforms,” 2005, at www.ist-capanina.org. FP6 IST Project CAPANINA, D10, “Spectrum Sharing Studies for High Altitude Platform (HAP) Systems in the 28/31-GHz Band,” February 2005, at www.ist-capanina.org. ITU-R Doc. 9/123(Rev.)-E, “Interference Evaluation from Fixed Service Systems Using High Altitude Platform Stations to Conventional Fixed Service Systems in the Bands 27.5-28.35 and 31.0-31.3-GHz,” at www.itu.int. ITU-R Doc. 4-9S/334-E, “Methodology for Interference Evaluation from the Downlink of the Fixed Service Using High Altitude Platform Stations to the Uplink of the Fixed-Satellite Service Using the Geostationary Satellites Within the Band 27.5-28.35-GHz,” at www.itu.int. ITU-R Doc. 9/116(Rev.)-E, “Impact of Uplink Transmission in the Fixed Service Using High Altitude Platform Stations (HAPS) in the Fixed Exploration-Satellite Service (passive) in the 31.3-31.8-GHz,” at www.itu.int. ITU-R Doc. 9/117(Rev.)-E, “Interference Evaluation of the Fixed Service Using High Altitude Platform Stations (HAPS) to Protect the Radio Astronomy Service (RAS) from Uplink transmission in HAPS systems in the 31.3-31.8-GHz,” at www.itu.int. SF. 1481-1 Recommendation ITU-R SF.1481-1, “Frequency Sharing between Systems in the Fixed Service Using High-Amplitude Platform Stations and Satellite Systems in the Geostationary Orbit in the Fixed-Satellite Service in the Bands 47.2-47.5 and 47.9-48.2-GHz, at www.itu.int. F.1569 Recommendation ITU-R F.1569, Technical and Operational Characteristics for the Fixed Service Using High Altitude Platform Stations in the Bands 27.5-28.35 GHz and 31-31.3 GHz, at www.itu.int.

286

Satellite Networks [26] F. [HAPS-MT] (Doc. 9/BL/40) [Document 9/115(Rev.)-E, Interference Mitigation Techniques for use by Altitude Platform Stations (HAPS) in the 27.5-28.35 GHz and 31.0-31.3-GHz Bands, at www.itu.int. [27] CELTIC EU Project WINNER+, Deliverable 1.2, “Initial Report on System Aspects of Flexible Spectrum Use,” January 2009, at http://projects.celtic-initiative.org/winner+/. [28] European Space Agency (ESA) at http://telecom.esa.int/telecom/. [29] European Telecommunication Standardization Institute (ETSI), at www.etsi.org. [30] FP6 IST SATSIX, SATSIX Deliverable 4000–2, “Standardization Impact Report,” December 2007, at www.ist-satsix.org. [31] Telecommunications Industry Association (TIA) at www.tiaonline.org/. [32] International Engineering Task Force (IETF), at www.ietf.org. [33] ETSI TS 102 357, “Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia; Common Air Interface Specification: Satellite Independent Service Access Point (SI-SAP),” at www.etsi.org. [34] ETSI TS 102 460, “Satellite Earth Station and Systems (SES); Broadband Satellite Multimedia; Address Management at the SI-SAP,” at ww.etsi.org. [35] ETSI TS 102 461, “Satellite Earth Station and Systems (SES); Broadband Satellite Multimedia; Multicast Source Management,” at ww.etsi.org. [36] ETSI TS 102 462, “Satellite Earth Station and systems (SES); Broadband Satellite Multimedia; QoS Functional Architecture,” at www.etsi.org. [37] ETSI TS 185 001 “NGN; QoS Framework and Requirements,” at www.etsi.org. [38] ETSI TS 102 465, “Satellite Earth Station and systems (SES); Broadband Satellite Multimedia; General Security Architecture,” at www.etsi.org. [39] FP6 IST Project SATSIX, Deliverable D1000_4, “Satellite Network Requirements,” January 2007, at www.ist-satsix.org. [40] FP6 IST Project CAPANINA, Deliverable 13, “General Network Architecture Requirements,” May 2005, at www.ist-capanina.org. [41] Marks, R., “What is LMDS”, April 1998, Web article available from http://nwest.nist.gov/lmds.html. [42] ETSI TR 101 957, “Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Requirements and Architectures for Interworking between HIPERLAN/2 and 3G Cellular systems, at http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp. [43] FP5 IST Project GEOCAST, at http://cordis.europa.eu/fetch?ACTION=D&CALLER= PROJ_IST&RCN=57127. [44] IETF RFC 2475, “An Architecture for Differentiated Services”, December 1998, at www.ietf.org. [45] IETF RFC 2215, “General Characterization Parameters for Integrated Service Network Elements,” September 1997 at www.ietf.org.

CHAPTER 5

Broadband Access Networks and Services Low-cost broadband technologies are important for making broadband services available and affordable for everybody, including rural communities. The demand for Internet access speeds has been rising as well, with ADSL speeds not nearly enough any longer for the emerging new services and applications, and in some cases even restricting their deployment. There is a proven correlation between broadband deployment and GDP; therefore, part of the European-funded research was aimed at enabling broadband access at speeds of 100 Mbps and above towards 1 Gbps, at the development of components and systems and their integration in an end-to-end converged communication infrastructure. Research spanned from the physical to the service and applications layer, in the whole range of technologies from optics, powerline, DSL, satellite, and wireless. This chapter is primarily focused on the research and development achievements [1] in relation to fixed broadband access and services and the development of a new broadband component towards next generation communication networks. Some of the major projects active in this area under the umbrella of the FP6 program were the IST project MUSE [2], which focused on broadband access for residential subscribers, the IST project PIEMAN [3], which focused on the physical layer research for a future broadband optical access and a metro system of enhanced capacity, and the IST project OBAN [4], which focused on low-cost broadband access technologies and proposed an innovative approach to an open access network built upon the existing “privately owned” wireless local area networks (WLANs) and the fixed access lines (e.g., ADSL/VDSL, optical fiber, cable modems). Access protocol effects were identified as significant for extension of the wireless networks in reach by fiber systems. A novel technique was developed by the FP6 IST project ISIS [5], which used an optical feeder to send data over cable in a format that also allowed it to be transmitted over wireless networks. The FP6 IST project POF-ALL [6] showed that plastic optical fibers (POFs) were attractive in terms of easy deployment and immunity against electrical interference. Powerline communications (PLC) is an attractive low-cost alternative that can stimulate competition in the broadband access network next to the DSL solutions offered by incumbent providers and is a practical solution for developing regions lacking the commodity of fixed-line telephone infrastructure. The IST projects OPERA [7] and POWERNET [8] researched the support of triple-play services and some deployment aspects of PLC. The FP6 IST project NOBEL [9] focused on the design of a next generation optical network.

287

288

Broadband Access Networks and Services

This chapter is organized as follows. Section 5.1 gives an introduction and outlines the main challenges in the fixed broadband research. Section 5.2 explores the potential of the integration of broadband technologies with power lines. Section 5.3 describes a future broadband access platform that supports fixed-mobile convergence. Section 5.4 concludes the chapter.

5.1

Introduction The smoothless provision of broadband services to everyone is considered one of the key components of the information society. Traditionally, the delivery of broadband connections to the end user has been targeted through the deployment of optical fiber leading to the concepts of fiber to the curb and fiber to the home. During the last decade, however, the impact of wireless technology to provide a new sense of freedom and autonomy for the end user has become more significant [10]. This has initiated considerable research to integrate the fixed broadband access to wireless communications. Bandwidth intensive content and peer-to-peer applications consume the great majority of bandwidth in most broadband networks today. New broadband deployments are commonly justified primarily by today’s applications rather than anticipated demands. Streaming video content is considered by many as the ultimate bandwidth-hungry application. When one adds the bandwidth requirements of one high-definition TV stream and Internet browsing, it may seem that 20- to 25-Mbps bandwidth is sufficient in the long term [11]. Service providers are already offering 1-Gbps access to residential customers, and there are some substantial deployments of 100-Mbps networks by means of fiber architectures. Aggregation and backbone networks can be upgraded comparatively easily, and bandwidth increases can be accommodated without much additional investment. Investments into an access infrastructure have to be considered with care in order to determine whether a seemingly cost-effective shared access technology will constitute a bottleneck for the bit rates required in the future [11]. Fiber-based broadband architectures that have been deployed can be classified in the following three broad categories [11]: • • •

Ring architectures of Ethernet switches; Star architectures of Ethernet switches; Tree architectures using passive optical network (PON) technologies.

Network architectures based on Ethernet switching provide excellent resilience against fiber cuts and can be built cost-effectively. The disadvantage is the sharing of a bandwidth over each access ring (1 Gbps) that is comparatively small in relation to long-term requirements, thus providing a challenge for scalability of the architecture [11]. Ethernet star architectures provide dedicated fibers (typically single-mode, single-fiber with 100BX or 1,000BX Ethernet transmission) from every endpoint to the point of presence (POP), where they are terminated on a switch. Endpoints can be single family residences, apartments, or multidwelling units where a switch in the

5.1 Introduction

289

basement fans out to the apartments using any appropriate transmission technology. PON architectures are characterized by passive optical splitters to distribute the fiber to each customer using splitting ratios ranging up to 1:64 or even 1:128. The physical PON architecture typically supports the Ethernet protocol. In some cases, an additional downstream wavelength is overlaid in order to distribute the traditional analog and digital TV services to each user without the need for IP set-top boxes [11]. There are three major benefits for service providers that deploy PON architectures instead of deploying point-to-point fibers: • • •

Access fiber saving; Port saving in the aggregation central office or POP; Analog video overlay.

Some of the issues related to the ease of deployment of PON architectures are the following. The bandwidth on the PON fiber tree is shared among as many customers as possible in order to benefit from potential cost savings on a per-subscriber basis. As GPON technology provides 2.5 Gbps of aggregate downstream capacity, it does not seem to provide for longer-term service growth and future subscriber demands given the exponential growth in bandwidth demand [11]. Furthermore, some proportion of the bandwidth has to be reserved for streaming services, reducing the bandwidth that can be shared statistically. As every PON effectively constitutes a shared medium, encryption is needed on all data streams. Encryption requires some substantial overhead with each packet which can, depending on the traffic mix, considerably reduce the usable bit rate on a PON. Due to the shared medium nature of PONs, every endpoint (ONT/OLT) has to operate at the aggregate bit rate, which has direct cost implications. Every 1:2 power split causes a degradation of the power budget by 3.4 dB. Consequently, a 1:64 split degrades the power budget by 20.4 dB. Flexibility of the allocation of customers to PON optical splitters can theoretically be achieved by combining the splitter with an optical distribution frame in a field cabinet [2]. It is becoming widely accepted that the integration of heterogeneous access infrastructures, possibly distributed among different administrative domains, will be the key to cope with the bandwidth and access needs, as it is cheaper than realizing a global coverage based on a single radio technology and has the potential of improving the overall user experience. 5.1.1

Optical Access Solutions

Optical technology offers higher bandwidth and high splitting ratios that can be very space- and energy-efficient compared to broadband capacities of other technologies [12].

290

Broadband Access Networks and Services

The local loop networks built around the middle of the past century provided a dedicated wire pair from each house in an area to the local exchange (LEx) [13]. Figure 5.1 shows a typical topology for the local loop network. A thick binder cable, the main cable, containing a large number of copper wire pairs, runs from the local exchange to a street cabinet. From the street cabinet a number of distribution cables emerge containing a smaller number of wire pairs. These distribution cables end in the street, for example, in an external or a buried connection box, from where a “drop” cable with one or two wire pairs runs to each house. Typically, a cable with smaller gauge wires inside is used between the exchange and cabinet than from the cabinet to the distribution point because in this way, the overall size of the bundle of cables is more manageable there, where the number of cables is higher. There are a number of variations of the topology. Some short lines may go directly to a distribution point (DP) rather than via a cabinet. Although cables were designed to optimally carry analog voice signals, a large variety of cable designs that meet this criterion is possible. This leads to significant variations regarding the crosstalk performance and loss and has an impact on the reliability of the network. The mix of underground and overhead cables impacts also the digital subscriber line (DSL) performance [13]. One issue which has a significant impact on predicting the DSL performance is the accuracy of cable records and whether there is an automated access to the records. A local exchange area consists of several flexibility points and link levels. The flexibility points, which allow access, are the following: • • •

Main distribution frame (MDF) located in the LEx; Passive cabinet (Cab) without powering and cooling located at the roadside; DP, typically located at/in the buildings.

The copper cables connecting the flexibility points are distributed by branching boxes. These connections constitute the main and the distribution networks. Figure 5.2 shows the flexibility points and link levels within a typical European access network.

ma

main cable Cabinet Distribution cable Distribution point (DP) x. l

oop

len

gth

Tree structure

Figure 5.1

Architecture of first mile network areas [13].

5.1 Introduction

291

In-house

Building

Distribution cable

Aggregation section fiber cable

Main cable

Cabinet/Curb Copper - xDSL

Figure 5.2

CEx

LEx xDSL

A typical European access network model [13].

The access network is divided into an aggregation network and a first-mile network. The aggregation network infrastructure is mostly fiber-based, usually without any wavelength division multiplexing (WDM) technology. Different network topologies such as star, ring, or mesh are present. The existing aggregation network is divided into different platforms (e.g., SDH and ATM), whereas IP is usually transparently transported over ATM and SDH, respectively, up to the edge node. In order to reduce the overall investments and running costs, the design of a universal aggregation platform with a common layer 2 (L2) transport technology, which is able to carry all services and to support all connected first-mile solutions, is very important. The first-mile segment is mostly copper-based in contrast to the aggregation network. These technologies are limited in both reach and bandwidth depending on the real copper plant. 5.1.1.1

xDSL over Optics

DSL technologies allow for using the POTS copper infrastructure to offer broadband services [13]. DSL solutions are limited in reach and bandwidth when depending on the real copper plant. In general, beyond the 8-Mbps downstream rate, it would be increasingly necessary to move the optical fiber techniques from the central office closer to the customers. The optical access nodes have to move towards the first-mile network locations (e.g., cabinets, buildings). This requires the roll-out of new optical fiber cables and the installation of optical equipment at a large number of locations including new housing and powering requirements. Such a platform upgrade causes high initial investments in the first-mile segment. To keep down the costs, different DSL migration possibilities are being considered by operators and researchers. The main driver is the increase of subscriber bandwidth (bit rate) enabling the operator to offer new or additional services and to satisfy the increasing demand of the customers. Enhanced DSL technologies focus mainly on how to advance the bit rates. Usually an upgrade of the subscriber bandwidth requires a technology exchange or capacity extension in the access or the aggregation domain (e.g., the installation of a VDSL system in the access domain or additional aggregation nodes, interfaces, and links in the aggregation domain). Ethernet can also provide cost advantages, compared to ATM-based systems.

292

Broadband Access Networks and Services

xDSL over optics is a concept of a transport system between the digital subscriber line access multiplexer (DSLAM) and a remote node (e.g., at a distribution cabinet) that offers the possibility to reduce the complexity and power consumption of the remote node that works as a simple de-/multiplexer without the additional signal processing, usually provided by a DSLAM. This is shown in Figure 5.3. The DSLAM functionality is limited on the LeX location. To keep down the high initial investments for the optical deployment in the first-mile segment, the fiber to the x (FTTx) solutions offer the chance for a smooth migration by deploying hybrid fiber/copper networks. The xDSL DSLAM can be pushed towards the customers and fed by fiber. The existing copper cable flexibility points of the traditional access network, however, are to be considered. These are the LeX, the distribution cabinet that is the demarcation point between the main cable and the distribution cable, and the in-house DPs terminating the in-house cabling. The corresponding concepts are called Fiber-To-The-Local-Exchange (FTTEx), Fiber-To-The-Cabinet (FTTCab), and Fiber-To-The-Building (FTTB). An FTTEx approach means DSL starting from the local exchange (LEx). According to the operator’s point of view, the LEx is an ideal location to introduce new techniques because there are powering, air-conditioned environment, and footprint for telco racks. But each DSL technology has its specific reach limitations so that more or less customers of a service area can be connected depending on the xDSL type (Figure 5.4). In general, the higher the data rates, the lower the reach. However, the FTTEx approach also makes sense for high rate ADSL2+ or VDSL2 solutions and can be seen as a migration step. Usually there is a part of a service area around the LEx that can be reached by a specific high rate DSL technique without any infrastructure workings. Especially in urban areas, a considerable number of customers can be connected on the basis of ADSL2+ or VDSL2. In order to exploit the higher bandwidth capabilities of advanced DSL-technologies also in the part of the service area that cannot be reached by a specific high rate DSL type, the optical fiber has to be used to bridge a section of the service area to bring the DSL closer to the customer. The FTTCab concept represents a beneficial solution for a DSL migration [13]. It uses the distribution (street) cabinet in order to install a remote DSLAM with an

CPE modem 1 CPE modem 2

Distribution point

Central office

CPE modem 3 SuDMT MUX/ DEMUX

TX/ RX

CPE modem 16

Figure 5.3

xDSL over optics [13].

Optical Access Aggregation Network

TX/ RX

SuDMT MUX/ DEMUX

DSLAM

5.1 Introduction

293

Service area Part of service area that can be reached by a DSL technology starting from the LEx

LEx FTTEx

Part of service area that requires a FTTCab or FTTB approach

FTTCab/FTTB

Figure 5.4

FTTEx limitations.

optical fiber uplink (Figure 5.5). Usually, the cabinet location has to be upgraded related to space, outside capability, power supply, and air conditioning. This migration requires a fiber roll-out in the main cable section of the service area between LEx and the distribution cabinet. The customers that can be reached by an FTTCab solution and the data rates are limited by the distribution cable length, the copper cabling, and the applied DSL technology.

Customer

FTTcab with optical ptp uplink

Distribution cable

Main cable

LEx

2 MAN

CPE

Remote DSLAM Opt. ptp links, Aggregation switch with opt. ptp e.g., optical or DSLAM with opt. uplink ethernet ptp line card

VDSL2 (Eth.)

FTTcab with optical ring concept

Cabinet

MAN CPE Aggregation switch or DSLAM with opt. ptp line card

Remote DSLAM VDSL2 (Eth.) with two opt. ptp uplinks Passive splitter FTTcab with PON uplink

2 1:X VDSL2 (Eth.)

Figure 5.5

MAN

CPE

FTTCab uplink options [13].

Remote DSLAM with FON uplink

OLT or DSLAM with PON line card

294

Broadband Access Networks and Services

The links between the LEx and cabinets will be realized on the basis of fiber connections that can be realized by different optical system solutions. The optical Ethernet standards, especially the Ethernet in the First Mile (EFM) specifications, can be used for that scenario. FTTCab with an optical ring concept aims on a fiber ring topology in the main cable section of the access network in order to reduce the needed fibers. The ring bandwidth can be shared by multiple remote DSLAMs. This solution offers more redundancy, but the complexity of the remote DSLAM increases because a ring routing mechanism and more backplane capacity are required. This solution can also be realized by an optical Ethernet (e.g., gigabit Ethernet) using the IEEE 802.1 Spanning Tree Protocols (native STP, rapid spanning tree, multiple spanning tree protocol) [14] that generate a logical tree structure on the ring and provide a redundancy mechanism. Rapid spanning tree is able to provide a reconfiguration time less than 1 second. Faster ring reconfiguration can be realized by the IEEE Layer-2 protocol Resilience Packet Ring (RPR) or other propriety protocols. 5.1.1.2

FTTB

Fiber To The Building (FTTB) could become necessary if the high bandwidth capabilities of advanced DSL technologies from the cabinet/curb (e.g., VDSL2) are not sufficient. In such cases, an FTTB DSLAM with optical uplink can be installed inside of the buildings (e.g., in the basement). The powering of the building DSLAM should be separated and not accessible for the dweller, in order to avoid intended or inadvertent disabling. In-house wiring can be realized by quadruple bundles with twisted copper pairs in contrast to the first-mile outside plants, where usually quadruple bundles with untwisted copper pairs are deployed. The twisting of pairs improves the crosstalk conditions, compared to the untwisted pairs. Hence, the limits of FTTB are not really caused by the in-house wiring, but rather by the high-bandwidth limitations of the advanced DSL technologies with up to 100 Mbps. In general, an FTTB concept is more expensive than an FTTCab approach, but it can be an economically feasible solution for multidwelling buildings or office buildings and Greenfield situations [13]. 5.1.1.3

Migration Towards Enhanced DSL

Introduction of enhanced or novel DSL solutions is driven by the following factors: • • • •

Low-cost bandwidth upgrade; Low-cost reach upgrade; Low-cost service enabling; Reduction of operation expenses.

The offering of a new service generation that is optimized for packet-oriented traffic with very high data rates and QoS provision might require the introduction of a new DSLAM generation [13]. Figure 5.6 shows some migration options and features of a new DSLAM generation, which give the operator the needed flexibility. An advanced Ethernet/IP

5.1 Introduction

295

Local exchange

First mile access domain

DSLAM ADSL Today

ADSL2/2+ FTTEx

ATM based ADSL

ATM SDH

ATM based ADSL2/2+

Ethernet

EeVDSL2 Ethernet/IP DSLAM

Ethernet EoVDSL2 FTTCab

Optical ethernet

ADSL2/2+

Eth.

or PON ADSL2/2+ Cabinet

EoVDSL2 FTTB PON or optical ethernet

Today's ATM based techniques Optical fiber

Figure 5.6

New Ethernet/IP techniques Telco copper cable

First-mile migration option [13].

DSLAM should be able to substitute the installed ADSL base by providing line cards, which support ADSL lines. While the availability of low-cost VDSL2 techniques is insufficient, the DSLAM should support ADSL2+ line cards. In addition, it is necessary to support an adequate optical feeding system to connect the remote DSLAMs on the basis of FTTCab or FTTB. The FTTCab concept enables reaching the majority of customers with very high data rates provided by ADSL2+ or VDSL2. 5.1.2

Fixed Wireless Access Based on Radio over Fiber (RoF)

A major property of a radio over fiber (RoF) system is that radio access points or base stations (BSs) are significantly simplified through the consolidation of signal processing functions in the head end [15]. In addition, fixed wireless access (FWA) has the inherent advantage of being able to reach all users and can be deployed in areas or buildings, where it is difficult or impossible to deploy wired infrastructure [xDSL (digital subscriber line)/fiber].

296

Broadband Access Networks and Services

A cost-effective and WiMAX-compliant solution to implement RoF to feed BS for FWA was developed in [2] as an alternative to the conventional digital baseband feeders already commercially deployed. The employed system is based on the optical frequency multiplication (OFM) method [15]. OFM enables the use of only low-frequency optical components at the head end, while supporting high-frequency wireless system operation at a simplified remote antenna unit (RAU). OFM involves the interferometric filtering of a frequency-modulated (FM) optical signal and the resulting FM-intensity modulation (IM) conversion is used to optically upconvert carrier frequencies. The appearing high-order harmonic components of the sweep frequency are used as a radio frequency (RF) carrier at the RAU. Experiments have shown that OFM is chromatic dispersion tolerant, making it possible to have a longer reach (> 10 times) than IM with IM-direct detection (DD) [16]. This tolerance is due to the sweeping of the optical wavelength: both the interferometric filtering and the chromatic dispersion result in FM-IM conversion, which causes the generation of sweep frequency harmonics. Because of its dispersion tolerance, OFM is very suitable for such a study. Figure 5.7 shows how OFM can be interconnected with an extra large (XL)-PON (XL-PON) system. An implementation of the OFM system in the XL PON will require a separate wavelength overlay. There are several issues regarding this interconnection which need to be considered. Of major importance is that the splitting factor and the reach of the PON system put constraints on the optical power budget in the FWA feeder network. Therefore, it is recommended [15] to investigate the ability of the RoF system to transport WiMAX-compliant FWA services over a long optical link. A challenging criterion is that the OFM system must be able to operate over fiber lengths of up to 100 km. Additional nonlinear effects in the fiber transmission link will have an impact on the RoF system. In long-reach optical fiber links it is desired to launch high power in order to offset the effects of the higher attenuation losses that occur along the fiber. However, increasing the launch power may lead to nonlinear effects taking place owing to the high optical intensity that may occur in the fiber core given the small core radius in standard single mode fiber (SMF).

WiMAX RAU

λ

100 km OLT

ROF head

Split 1:512 ONU Ethernet

Figure 5.7

An XL-PON with interconnected FWA feeder system [15].

λ

5.2 Broadband over Powerline

297

While PONs can deliver huge bandwidth and spread the cost of the infrastructure between many users sharing only a few fibers, the laying of fiber in rural regions is still prohibitively expensive. Providing public access over WLAN is one very cost-effective solution. The FP6 IST project OBAN [4] developed the concept of an open access network (OAN), in which wireless broadband is offered to mobile users. The realization of such a concept requires a consideration of aspects such as security as imposed by regulatory authorities, commercial players, and private users [12]. Other important technical aspects regard how to offer mobile services with an acceptable level of quality of service (QoS) in an OAN. Low-cost optoelectronics and microwave photonics techniques and innovative high-frequency components can enable fiber-fed networks for new wireless systems (such as new versions of Wi-Fi, WiMAX, and UWB) and future millimeter-wave communications.

5.2

Broadband over Powerline Broadband over power lines (BPL) can offer low-cost broadband communications over the ubiquitous power grid. The technology has a big market potential [17]. The main advantage of BPL over the other broadband technologies is that no extra cables are required, as in every building where access must be provided, the electricity network is utilized. 5.2.1

Cognitive BPL

A plug-and-play cognitive broadband over power lines (CBPL) communications equipment that meets the regulatory requirements concerning electromagnetic radiations can deliver high data rates, while displaying low transmit power spectral density and working at a low signal-to-noise ratio [17]. The CBPL technology is employing asynchronous, peer-to-peer communications between the users to keep the required transmit power spectral density as low as possible to comply with the regulatory requirements. Access to BPL communications happens as follows. In the access, the electricity provisioning to each house normally comes from a local low voltage transformer, which supplies the home with 400V (three phases) or 220V/110V (one phase). CBPL equipment called the BPL access multiplexer (BPLAM) is installed at this transformer. The data to transmit coming from an ISP or a content provider is injected into the power distribution cables at this transformer by the BPLAM and is transmitted to the houses served by the low-voltage transformer. At the user end, a CBPL modem is plugged into any wall socket to receive the data forwarded by the BPLAM. If required, a CBPL residential gateway (CBPL_RG) is installed before the electricity meters at the house or apartments to serve as a relay and a firewall. CBPL_RG allows the combination of CBPL with other broadband technologies in the case that another broadband technology is providing the interconnection to the ISP or to the content provider and the data received is distributed via in-house CBPL.

298

Broadband Access Networks and Services

Figure 5.8 shows that if the CBPL technology is in operation with a transmit PSD of –60 dBm/Hz, the electromagnetic noise is not increased. The electromagnetic measurements were conducted in a school and made at a 1- or 2-meter distance from the wall. The measured electromagnetic radiation has been corrected to 3 meters. This explains why the electromagnetic radiation is below the electromagnetic noise. The CBPL technology is based on multicarrier modulations (MCM) and uses digital filter banks (DFB) instead of OFDM to obtain high-level stopband attenuation to ensure that the technology does not have a power leakage in the frequency bands allocated to other users of the HF band. Furthermore, CBPL uses peer-to-peer communications instead of the commonly used master-slave communications to keep the electromagnetic radiations as low as possible. The medium access control (MAC) of CBPL allows for ad hoc networking and self-organization. The results of computer simulations show that the CBPL technology can achieve high data rates (up to 300 Mbps) and both interactive (IP services) and broadcast (DTV) services can be offered. 5.2.2

Integration of Wireless Technologies with PLC

The integration of some emerging wireless communication technologies with PLC is very beneficial for achieving economical feasibility [19]. Some of the selected technologies described here are the most widely deployed wireless technologies available at the time of this writing. PLC can be expected to profit from interworking with Wi-Fi, WiMAX, ultrawideband (UWB), ZigBee, and Bluetooth. New developments where a relatively early association with PLC will help both partnering technologies with market acceptance should be considered as well for integration with PLC technology.

100 90 80

dBμV/m

70 60 50 40 30 20 0,00

5,00

10,00

15,00

20,00

25,00

30,00

frequency/MHz m26

Figure 5.8

m21 noise

Electromagnetic radiation measured during the coexistence tests at CPLN [18].

5.2 Broadband over Powerline

299

The wireless technologies range from personal area network (PAN) technologies with a range of only a few meters to access grade metropolitan area networks (MANs). Bandwidth for these technologies ranges from very low (up to 1 Mbps) to the bandwidth of wire-based PLC itself. These different wireless concepts result in a wide range of business models required for combining wireless technology with PLC. New business cases were commercially and technically analyzed in [19]. The following business cases were reported for integrating Wi-Fi with PLC: •

•

•

•

PLC backbone based on Wi-Fi: This business case is technically feasible. It is seen as a niche market. PLC as a backbone to a Wi-Fi system: This business case is technically feasible. Commercially it is very interesting for specific applications. Wi-Fi router as in-house extension for the customers: This business case is technically feasible. It is seen as a very interesting commercial opportunity. PLC as complement of a Wi-Fi installation: This business case is technically feasible. Commercially it is very interesting for specific applications.

The following business cases were reported for integrating WiMAX with PLC [19]: •

•

•

WiMAX backbone/backhaul based on PLC connections: This business case is technically feasible. Commercially it is seen as a niche market. WiMAX as backbone/backhaul for PLC distribution: This business case is technically feasible. Commercially it is interesting for special applications without an alternative solution. PLC as in-building communication for WiMAX subscriber stations: This business case is technically feasible. It is seen as a very interesting business opportunity.

The business cases for UWB with PLC are: •

•

•

Wireless extension of PLC using UWB: This business case is technically feasible. Commercially this is a very interesting business proposal for the future acceptance of UWB. AV/data streaming between CEs over PLC: This business case is technically feasible. It is seen as a very interesting commercial idea for the future integration of UWB. Wired UWB architecture over PLC: This business case is technically feasible. It could be a future vision for using synergies between PLC and UWB.

The business cases for ZigBee with PLC are: •

•

Automatic meter reading: The business case is technically feasible. It is seen as commercially very interesting. Automated digital home: This business case is technically feasible. Commercially it is seen as a niche market.

300

Broadband Access Networks and Services

The business cases for Bluetooth with PLC are: •

•

•

Home automation: This business case is technically feasible. Commercially it is seen as a niche market. Medical surveillance: The business case is technically feasible. It is seen commercially as a niche market. AMR extension: The business case is technically feasible. It is seen as commercially very interesting.

5.2.2.1

Wi-Fi and PLC Integration

In the following sections some of the new business models proposed by [7] are described. 5.2.2.1.1 PLC Backbone Based on Wi-Fi

If a public utility company wants to install a PLC system on its power grid, an analysis of the design of the power grid is necessary. In a first step, it is important to get an overview over the number of transformer stations, street cabinets, and the number of households in the selected area. The next step is to define how many head ends should be installed in the area and where these should be installed. PLC as a typical last-mile technology needs a backbone connection at the head end (e.g., in transformer stations or in street cabinets). Therefore, it is useful to keep in mind where an easy and cheap connection to the backbone is practicable. Quite often it is too expensive to lay a fiber optics connection to the transformer station. In these cases, one alternative is to install a Wi-Fi system as a backbone (Figure 5.9). The choice of the type of Wi-Fi system used for the integration will depend on the following criteria [19]. The first criterion is the required range of the Wi-Fi system. The range of the system refers to the distance between the BS and the remote station and the angle of the sector that should be covered. The range of a 2.4-GHz frequency block, for example, is slightly better than the range of a 5-GHz frequency block. Otherwise, the allowed output power for outdoor systems in Europe in the 5-GHz band is 10 times higher than in the 2.4-GHz band. Another criterion is how

Internet

Wi-Fi AP

Wi-Fi AP

Figure 5.9

A PLC backbone based on Wi-Fi [19].

PLC system

5.2 Broadband over Powerline

301

many point-to-point connections are needed in the same sector. In the 2.4-GHz band there are only three nonoverlapping channels available. In the 5-GHz band, 11 nonoverlapping channels are available for outdoor use. In Europe the 2.4-GHz systems are very popular for use inside the home. Consequently, the probability of problematic interference in the 2.4-GHz band is higher. Another criterion to consider is the price of the connection through the respective Wi-Fi system. For a Wi-Fi based backbone infrastructure the most important requirement is a line of sight (LoS) connection of paired APs. Therefore, it is useful to install the base for the wireless backbone on top of a high building or a tower. The range of a connection is not only depending on the line of sight, but also on a free Fresnel zone. The first Fresnel zone is a concentric ellipsoid between the antennas. In this zone most of the energy is transmitted. If there are obstacles in this zone, the radio wave is reflected and received by the antenna out of phase, which causes interference with the signal. Some obstruction in the Fresnel zone can be tolerated; however, the maximum obstruction should not exceed 40%, with the recommended obstruction at less than 20%. Some examples of how the Fresnel zone can be disrupted are shown in Figure 5.10.

5m

3 Km

5m

5.7m House

House By the ground

7m

700m 2.8m

7m

5m Condos

By road traffic

Building

15m

20m

2.8 Km

20m

7.8m 15m

Building

Tree By an obstacle

Figure 5.10

Examples of a disrupted Fresnel zone [19].

Building

302

Broadband Access Networks and Services

Other considerations can relate to the antenna specification, the channel configurations, the level of security, the bandwidth, the QoS, and so forth. 5.2.2.1.2 Wi-Fi Backbone Based on PLC

In increasingly more hotels and public buildings WLAN-(Wi-Fi) coverage or a WLAN hotspot should be provided. In some cases, especially in historical buildings or museums, it might be difficult and expensive to install LAN cable to access the WLAN access points. Under these circumstances, PLC as a backbone solution for Wi-Fi hot spots could be installed quickly and without any disturbance of the guests and the public foot traffic. This configuration is shown in Figure 5.11. PLC is a good alternative to the installation of network cable through the building. If there are different overlapping coverage areas in the building, the channel configuration of the access points (APs) is important. Roaming between APs means that the WLAN client moves from one AP to the next. While roaming, the WLAN client must not lose the connection. A special protocol or communication between the APs is needed. This roaming action has to be supported by the PLC system. There are two possibilities of roaming, namely [19]: • •

Roaming on the same network segment; Roaming across network segments.

5.2.2.1.3 Wi-Fi-Router as In-House Extension for the Customers

For an Internet access with xDSL or cable, it is a standard application to install a Wi-Fi router behind the xDSL modem or the cable modem to make the Internet access available everywhere inside the home. The only requirement is a Wi-Fi-compliant interface in the computer equipment. Most portable computers have an integrated WLAN functionality. The proposed integration is shown in Figure 5.12.

Wi-Fi Ap CPE

Internet

PLC system

Wi-Fi Ap CPE

Wi-Fi Ap CPE Figure 5.11

Wi-Fi backbone based on PLC [19].

5.2 Broadband over Powerline

Internet

303

PLC system CPE

Figure 5.12

Wi-Fi router

Wi-Fi router as in-house extension for the customers [19].

It is also possible to install a Wi-Fi router with a PLC CPE. Thus, the Internet access is available throughout the house without reinstalling the modem in another room and it is also available at the same time with different PCs in different rooms. 5.2.2.1.4 PLC as a Complement of a Wi-Fi Installation

In some buildings or enterprises it is not possible to install a reliable WLAN coverage. There are different examples. One example is when the thick concrete walls impede the WLAN communication due to the high attenuation of concrete walls for an electromagnetic wave with a wavelength of circa 12.5 cm. Most of the electromagnetic waves (in the 2.4-GHz range) will be reflected on a concrete wall (e.g., in hotels where the WLAN coverage for the complete building including every guest room can only be realized by installing an AP in all public areas and every guest room; a similar problem can occur in school buildings). Another example is a steelwork where due to the many reflections of electromagnetic waves, the WLAN AP receives the transmitted signals very often, which in turn causes them to overlap so that the information cannot be decoded. In such cases, there is a combination of WLAN for the public areas (e.g., meeting rooms in hotels or the auditorium in a school) and a PLC network for the areas where WLAN installations are too expensive or not possible. The proposed integration of PLC is shown in Figure 5.13. Based on the fact that the Wi-Fi system (802.11a/h and 802.11/b/g) is deployed in almost all parts of the world, the market acceptability is very high. Due to the wide spreading of the 802.11b/g systems in Europe, the use of a 5-GHz system, especially for a backbone, promises a more stable connection and consequently higher market acceptability. For a PLC operator one of the main expense factors is the installation of the backbone connections to the head ends. The use of a Wi-Fi backbone is an easy and cheap possibility to install a backbone very quickly and without any excavation. On a lot of towers or high buildings, antennas for mobile phone coverage have already

304

Broadband Access Networks and Services

Wi-Fi AP CPE

Internet

PLC system

CPE

CPE

Wi-Fi AP CPE

Figure 5.13

PLC as complement of a Wi-Fi installation [19].

been installed, implying that it is relatively likely to easily install the additional antennas for a Wi-Fi system. It must be noted, however, that for WLAN installations there are some reservations regarding the use of radio communication in residential areas, because of the health risk that might be associated with the high-frequency radio waves [19]. 5.2.2.1.5 Specification of Technical Requirements for the Integration

The technical requirements will differ depending on the chosen integration model. For the communication between a PLC system and a Wi-Fi system, only a RJ45-cable is needed. Both systems have RJ45-connectors. For a lot of Wi-Fi APs, Power-over-Ethernet solutions are available. Thus, the power supply should not be installed nearby the antenna or the AP to be able to use a short antenna cable. This is especially interesting for installations on high towers or aerial masts where no power supply is available on the top of the tower or the mast. The signal coupling into the power grid will be realized with standardized equipment without switching of the power on the grid. No additional elements for the business plan of the PLC operator are needed. The figures for the line rental need to be adjusted according to the rental price of the Wi-Fi connections. If a PLC operator offers the Wi-Fi router in expectation of a higher subscriber acceptance, the subscriber revenues need to be adapted. The price for the additional Wi-Fi router has to be implemented in the business plan. 5.2.2.2

PLC and WiMaX Integration

The aspects related to such an integration are shown in Figure 5.14. In the view of networks applications, WiMAX can support the following areas:

5.2 Broadband over Powerline

305

0. WiMAX

2. Mobility access

1. Fixed access

1.1 Public access

1.1.1 Urban area

Figure 5.14

• • •

1.1.2 Rural area

1.2 Private access

1.2.1 Industrial networks

1.2.2 Local networks

Investigation for WiMAX application sectors [19].

Classical city networks; Industrial networks; Cooperate networks.

The basic units in a WiMAX network are the BS and the subscriber station (SS); for the PLC, this corresponds to the head end (HE) and the customer premise equipment (CPE). The mobile CPEs are called mobile subscribers (MS). A WiMAX BS usually supports connectivity to the access service network by network interfaces. The physical interfaces can be 10/100Base-T or Coax-RG6 with a DC-Supply of 40-60VDC. Ethernet will support IEE802.3 CSMA/CD with Half/Full Duplex. Coax will support the DOCSIS. The management of the BS will be done through telnet/CLI, SNMP interfaces and/or FTP transfer. For a high market share, the combination of WiMAX and PLC seems to be a reasonable solution, by supporting the customers by both solutions. The location for a BS should be in a place where the cardinal points are optimal for economics of frequency. In this case, the BS may be situated where no backbone is available but supply power must always be supported and the backbone can be supplied by the power lines. In the urban area with many high buildings, non-LoS is quite common. As economical planning requires optimal customer coverage [19], a sector-oriented antenna planning has to be introduced. A possible solution can be worked out through an adaptive antenna system (AAS), which is included in the standard. This technology can extend the coverage and capacity [19]. At the time of this writing, two principles for AAS were considered. The first introduces a beamforming antenna (BF), where the signal from the BS to the SS is formed. This results in higher distances to the signal. The second is done with multiple-input multiple-output (MIMO) technology, where the signal is distributed uncorrelated, which relates to higher data throughput [19]. All these efforts seem to require special planning tools for the WiMAX frequency and antenna installation to find the optimal location for the WiMAX coverage and signal strength. Today, the GSM tools are adapted with

306

Broadband Access Networks and Services

special WiMAX parameters in order to optimize the planning for WiMAX [19]. Frequency planning is another factor, which cannot be neglected. The WiMAX antenna technology and planning are essential for the installation. Here the PLC technology can contribute with backbone data and can be used as in-building communication, even though there is no frequency overlap with PLC. 5.2.2.2.1 WiMAX Backbone/Backhaul Based on PLC Connections

The general idea here is to support the WiMAX BSs by PLC connections. This can be done with indoor and outdoor units. Figure 5.15 shows how the connectivity between WiMAX and the access service network could be realized by the PLC connection. This situation can basically occur in every urban area where the access network is located in street cabinets next to the building. Even private networks and industrial networks can benefit from the fast deployment. The main advantage is the use of the existing power lines for offering new access points for the WiMAX deployment. It will be easy, fast, and cost-effective. Every deployment for WiMAX base stations (BS) needs connectivity to the access network. Different strategies from the operators are used to install the BS at optimal locations. Usually, the network planner tries to optimize the customer coverage with respect to the power supply and access the network to maximize the benefits from the location. Here, the PLC connections can simplify the process, as at the WiMAX location there should be at least the power supply based on medium or low voltage for the dual use of an access network. Considering the case in exurban or rural areas, where a WiMAX BS could cover areas with about 10,000 inhabitants, the acceptance for the backhaul with PLC will

Figure 5.15

PLC as a backbone for WiMAX BS [19].

5.2 Broadband over Powerline

307

be possible for a medium voltage PLC solution. Considering urban areas with a higher residential density rate and with high-density areas, more WiMAX BS can be installed, also as micro-BS. Here, difficulties with the access network can be solved by PLC connections on medium or low voltage. The PLC operator in this scenario offers service to the WiMAX operator. The PLC subscriber is the WiMAX operator. The PLC operator needs to guarantee the data line parameters, which can be bandwidth, availability, and other QoS parameters. The WiMAX BSs are interfaced with the access service network (ASN) via the normative reference point R6 to the access service network and/or with R8 to the next BS for mobile applications, as shown in Figure 5.16. In combination, the function at the reference points should be fulfilled by the PLC backbone. The functions are supported for the control protocols for the communication between the BS and ASN, as well as the bearer protocols for the data path establishment, modification, and release control in accordance with the mobile subscriber events. Depending on the chosen WiMAX ASN network model, this can be bridged (Ethernet) or routed (IP) packets. The PLC should be able to support at least one, either bridge or routed packets. For mobility applications, the PLC should support the required functions (e.g., in support of the handover procedures for the WiMAX mobile SS, which makes sure that a cell change should not take longer than 50 ms [20]). BS products that support an interface based on RJ45 with physical conditions to the Ethernet IEE802.1 standard already exist. Regarding the applications class, the PLC should at least fulfill the class 2 to 5 applications (i.e., VoIP, videoconference, streaming media, Web browsing, media content downloads) [19].

ASN R3

R1

R6 BS

R8

ASN gateway and decision enforcement points

R6

R1 BS

Figure 5.16

Network access provider (NAP) within the WiMAX architecture [19].

R4

308

Broadband Access Networks and Services

Class 1 (i.e., multiplayer interactive gaming) with the latency of less than 25 ms is a new requirement for the PLC devices. 5.2.2.2.2 WiMAX as Backbone/Backhaul for PLC Distribution

This model implements the access for a PLC distribution via WiMAX. The idea is to use the WiMAX point-to-point solution for the PLC head-end access. This supports PLC installation in rural, urban, and industrial and private networks. By planning the PLC installation in the low-voltage grid, it is necessary to have access to the backbone. Due to the fact that the transformer stations do not usually have backbone access, the WiMAX with a point-to-point capability can reduce the installation effort and time. Figure 5.17 shows how WiMAX extends the access network to the head end of the PLC installation to supply the customer with PLC to the services. In this model, the PLC operator offers the services to the customer, while the PLC operator rents the backbone from the WiMAX operator. The WiMAX operator has to guarantee the relevant line parameters such as bandwidth, availability, and other QoS parameters. 5.2.2.2.3 PLC as In-Building Communication for WiMAX Subscriber Stations

WiMAX promotes the possibility of using subscriber units with indoor and outdoor capability. Due to the non-LOS aspects in the urban areas, the BSs have difficulties to support the theoretical distances of 500–900m for public access in urban areas [19]. Therefore, a fixed antenna connection on the building seems to be a reasonable solution. The internal connection between the active antenna and the internal WiMAX components can be used to connect by PLC communication as shown in Figure 5.18. Another possibility is the extension for the WiMAX access to the internal network. This supports the IP structure of the whole building through the power lines.

PLC installation

CPE WiMAX SS

HE

RP

CPE

WiMAX BS

PSTN Access Network Internet

Figure 5.17

WiMAX as backbone/backhaul for PLC communication [19].

CPE

5.2 Broadband over Powerline

309

PLC connection

Figure 5.18

WiMAX connection with fixed or nomadic antenna in buildings [19].

This model can be used in industrial and private networks and will serve the customer by the WiMAX service with extended PLC connections. This is shown in Figure 5.19. The WiMAX operator offers the services to the customer. The PLC operator is transparent to the customer depending on the business model chosen by the WiMAX operator. This architecture is used for private networks realized as local or industrial networks. 5.2.2.2.4 Technical Requirements

PLC connections as backbone/backhaul for WiMAX are based on IP over Ethernet (IPoETH). IPoETH relies on the DHCP protocol for identification and for configuration issues. Figure 5.20 describes the interfaces and the related layer for the connectivity.

PLC in building installation

Figure 5.19

WiMAX SS with PLC for in-building installation [19].

310

Broadband Access Networks and Services

Figure 5.20

Architecture for WiMAX backbone/backhaul based on PLC connections [19].

IFA is defined by the WiMAX BS with a standard RJ45 connection and 10/100Base-T. IFB can be low or medium voltage power lines, where the physical access is optimized for the connectivity point. IFC should support the RJ45 and 10/100Base-T. The IFD interface between the access network with the connectivity network and with the service providers, respectively, can connect either the application service provider to the network service provider owing the access network or in sharing scenarios the network service provider with the access network. Figure 5.21 shows a PLC installation supported by WiMAX point-to-point connections. IFA is typically the low or medium voltage power line. At IFB the WiMAX SS supports the connectivity by the RJ45 10/100Base-T interface. IFC is the WiMAX air interface based on 802.16. IFD defines the interfaces to the access service network based on the RJ45/10/100Base-T. The IFE interface between the access network with the connectivity network and with the service providers can connect either the application service provider to the network service provider owing the access network or in sharing scenarios the network service provider with the access network. 5.2.2.3

Integration of PLC with UWB

Ultrawideband (UWB) communication system is the transmission of pulses having an extremely narrow duration in the time domain and a corresponding extremely wide signal bandwidth in the frequency domain. It operates at a very low power across its ultrawide frequency spectrum and with a good degree of robustness to interference and multipath fading [21], [22]. In February 2002 the Federal Communications Commission (FCC) issued a basic definition of a signal to be considered a UWB signal and detail standard specifications were included in the FCC Part 15 standards (15.503a,b) [23]. In this basic definition a signal is considered a UWB signal if it has a minimum of 500-MHz bandwidth or a minimum of 20% fractional bandwidth [23]. The fractional bandwidth itself is defined as the ratio of the −10-dB BW below the maximum emission

5.2 Broadband over Powerline

Figure 5.21

311

Architecture for PLC backbone/backhaul based on WiMAX point to point [19].

level to the center frequency, at which that maximum emission from the signal occurs (15.503b). This standard also preserves the 3.1–10.6-GHz frequency band as an unlicensed band for the UWB applications in the United States, and applications in the other frequency bands would be required to meet the relevant emission mask. Since then, the efforts to commercialize and to standardize the technology in the other parts of the world regions, including the European countries, have been so far successful, with the European Union passing legislations to adopt the UWB technology in its February 2007 ruling [21]. Similar legislations have also been passed in Japan and Korea [22], and a final decision in China is scheduled to be finalized [24]. Due to its two main advantages, namely, high data rate and low interference, the performance of UWB is much superior to the other IEEE 802.11 wireless standards, and therefore, it is a suitable future technology for short distance WPAN and WLAN applications [25]. The high data rate UWB applications include in-house AV media distribution, on-board (in-flight and in-car) entertainment system, photo/movie kiosks, cable-free home theater and PC peripherals, file synchronization, ad hoc gaming/streaming between mobile devices, and others. Other applications that require lower data rates can also be realized using UWB. At the time of this writing, two competing UWB technologies are available: the multiband OFDM-based UWB technology (MB-OFDM UWB) and the direct spectrum-based UWB technology (DS-UWB). UWB is a one-room coverage communication system, which means that the UWB pulses that are used for communication systems do not penetrate walls and doors. Multiroom or multistorey buildings cannot be served by UWB coverage even if the distance may still fall within the 3-m range from the antenna [19]. If UWB signals are routed over the PLC channel this can extend the streaming of high data rate information. The currently available PLC modems with integrated wireless AP are based on the IEEE 802.11g (54-Mbps theoretical/19-Mbps typical) wireless architecture.

312

Broadband Access Networks and Services

However, the integration of the IEEE 802.11g into the new generation of PLC modems that have the 200-Mbps PHY rate for a wireless extension of PLC services hugely underutilizes the capacity of the PLC modem by creating data rate bottlenecks. Due to this reason, the future PLC wireless AP architectures need to have an integration of a wireless architecture with a much larger data rate than the 802.11g standard, which makes the UWB technology a suitable candidate. With the legacy universal serial bus (USB) technology undergoing an important transformation towards wireless-USB (WUSB based on the UWB technology), more than 1 Gbps future capacity can be achieved. A single WUSB host supports up to 127 WUSB peripherals, and it allows, among other things, multiple HDTV streaming, each of which requires a data rate between 19 and 24 Mbps. This data rate, however, is attained within a maximum of a 3-m range inside the same room, with the data rate dropping rapidly to about 110 Mbps at a 10-m distance [19]. 5.2.2.3.1 Transmission of UWB Signals over PLC Channels

The integration of wireless UWB to a wired PLC, with signal transmissions over both wireless and wired channels, is based on using the 3.1–10.6-GHz frequency band for the wireless architecture and the frequency below 30 MHz for the PLC architecture. There is, however, another reason for integrating UWB technology with the PLC, namely, to minimize the electromagnetic interferences from the PLC signals. This is possible by transmitting signals that fulfill the basic UWB definitions over the PLC channel. This does not need a wireless architecture, but rather adopts the advantage of UWB signals for a wired PLC medium in the frequency range below 100 MHz. This is more to be realized by DS-UWB approaches downconverted for the frequency range below 100 MHz [19]. Some early-level researches at universities have shown that pulses as narrow as a 40-ns width can be transmitted and received over PLC channels. By implementing proper baseband modulations and coding levels, these can produce high data rates over the PLC channel. 5.2.2.3.2 Powerline Reference Model

A powerline reference model is shown in Figure 5.22. The functions of the different layers in the PLC reference layer model are the following: •

•

•

•

•

A PLC PHY layer defines the physical data transmission format on the powerline channel. A PLC MAC layer defines how different powerline nodes are allocated transmission opportunities. An LLC layer handles packet segmentation and grouping and defines how error-free communication is achieved between the communicating nodes. A convergence layer defines how standard protocols such as IEEE 802.3 Ethernet are mapped to the PLC protocol and how the data encapsulation is done. A layer management defines how each of the layers is configured and adopted to changing network conditions.

5.2 Broadband over Powerline

313

Bridging

Ethernet frame

Packet=CLPDU LLC Burst=LPDU PLC MAC

Layer management

Convergence layer

Frame=MPDU PLC PHY PPDU Figure 5.22

Powerline reference layer model [19].

5.2.2.3.3 Wireless Extension of PLC Using UWB

This scenario is intended to transmit IP traffic over both the PLC and the UWB channels, with two different possibilities: for the in-house powerline and for the access powerline networks. The need for wireless extension of PLC network in the home or office environment needs an integration of the wireless architecture to the wired PLC architecture. The new business model proposed in [19] was intended for the wireless extension of the PLC services and presumed that the mobile hosts are equipped with future UWB-based wireless network cards. The scenario is shown in Figure 5.23. In an access PLC/UWB modem a service provider can provide services, such as VoIP and Internet surfing services, at public spots such as bus stops and train stations through PDAs and WLAN-equipped mobile phones. An example for the placement of the access PLC/UWB modem in the PLC network architecture is shown in Figure 5.24. The above scenarios require a protocol conversion between the PLC LLC-PDU (LPDU) and the UWB MAC and vice versa. This, in turn, would require a finalized standard for IP networks on the UWB radio. This scenario, however, is unaffected by future IP technologies over the UWB radio platform since the data transmission protocol is governed by the PLC protocols and not by the UWB protocols. The protocol conversion block that plays an important role in extending the PLC service onto the UWB-based wireless service and the placement of the protocol conversion block are shown in Figure 5.25. The possible functional block diagrams that may be included inside the protocol conversion block-1 are shown in Figure 5.26.

Broadband Access Networks and Services

Figure 5.23

PLC/UWB wireless AP

WUSB network card

PLC modem

High speed PLC network

PLC modem

314

Application example for in-house PLC/UWB modem [19].

HE

REP

Acess PLC/UWB modem

REP

CPE

REP

HE: Head End REP: Repeater CPE: Customer Premises Equipment

Figure 5.24

CPE

Possible placement of the access PLC/UWB modem [19].

5.2.2.3.4 AV/Data Streaming Between CEs over PLC

The demand for whole home AV streaming using the evolving UWB technology in the consumer electronics industry has its own challenges, due to the short coverage distance and the inability to penetrate walls, doors, and floors. By integrating the PLC into the UWB-based CE cluster, the proposed PLC/UWB adaptor (PLUBA) can

5.2 Broadband over Powerline

315

Bridging Ethernet frame

Packet=CLPDU

UWB MAC

Protocol conversion block-scenario 1

LLC Burst=LPDU

PLC MAC

UWB PHY

Layer management

Convergence layer

Frame=MPDU

PLC PHY PPDU

Figure 5.25

Reference model stack and protocol conversion block [19].

Protocol conversion block-scenario-1

Existing PLC protocols Existing/Future UWB protocols New protocols

Figure 5.26

Functional blocks in protocol conversion block-1 [19].

provide a longer coverage range, on one hand, and the possibility of spanning over multiple rooms and floors, on the other hand. The proposed scenario is shown in Figure 5.27. The WUSB connection between the HWA and DWA changes is shown in Figure 5.28. The model in Figure 5.28 requires one host-side PLUBA (HS-PLUBA) and at least one device-side PLUBA (DS-PLUBA) to be connected to the powerline network. The HS-PLUBA should be scalable to accommodate multiple DS-PLUBA on the powerline network. The session request, device identification, authentication, and authorization procedures are to be handled according to the current WUSB protocols. The PLC channel only introduces a delay of transmission and reception corresponding to its length. This should be taken care of during the protocol specification so that this

Broadband Access Networks and Services

DS-PLUBA

HS-PLUBA

316

WUSB device

High speed PLC network

Host wire adapter (HWA) or PC

WUSB device

DS-PLUBA

Device wire adapter (DWA)

Wired USB devices

Figure 5.27

Application example for data streaming in the home [19].

Figure 5.28

The effect on the current WUSB architecture [19].

delay may not be interpreted as otherwise and lead to time-out session between the HWA and DWA [19]. AV/data streaming between CEs over PLC can be realized with different transmission protocols. In this case, the MAC layer for case 2 should be revised to include a protocol in which the completion of data transfer would automatically initiate disassociation of the device. The WUSB-based transmission control does not initiate a device disassociation after the completion of the data transfer unless it is requested by the user. An example of an application of this case is the communication pipe established between a home computer and an automobile parked in the garage; video, navigation map, and downloading from the Internet to the automobile, assuming that the automobile has a UWB-based an entertainment system onboard; and a telemetric data transmission and remote monitoring between the automobile and the home computer during the night or when parked for a long time during the weekends. This is shown in Figure 5.29.

5.2 Broadband over Powerline

317

Internet connection

WUSB adapter High speed PLC channel UWB antenna connected to the entertainment system of the automobile PLC/UWB adaptors

Automobile parked in a garage

Figure 5.29

AV/data streaming between CEs over PLC with different transmission protocols [19].

The scenarios described above are intended for an adaptation of data routing over a wireless UWB channel and a wired PLC channel. As discussed earlier, these scenarios are also based on the MB-OFDM UWB technology [19]. When using the integration in order to extend the coverage of WUSB and streaming AV signals inside the digital home or digital office, the higher layers of the PLC reference layers are not necessary to provide their functions as in the case of Figure 5.25. In Figure 5.30, the functions of the PLC LLC would be a part of the new PLC PAL in the protocol conversion block-2 to provide the PDU the PLC MAC expects from PLC LLC (LPDU), which results in a new reference model stack corresponding to changes in the protocol conversion block (Figure 5.31). A scenario of a wired UWB architecture over PLC (see Figure 5.32) is intended to propagate a UWB signal over the PLC channel without involving any wireless architecture. This scenario assumes an electromagnetic environment where the interference from the OFDM-based PLC transmission at higher data rates may influence very sensitive devices or equipment operating in that same environment. A compromise in the data rate through the flexibility of the OFDM architecture by frequency notching may bring the interference to a lower limit, though that may not be always welcome; therefore, an alternative PLC modem whose architecture is based on UWB, is required. Additionally, the scenario in Figure 5.32 assumes the

WUSB

Burst=LPDU

Convergence layer

Protocol conversion block scenario 2

PLC MAC Frame=MPDU

Layer management (?)

Broadband Access Networks and Services

Others

318

PLC PHY

UWB MAC

PPDU

UWB PHY

Figure 5.30

Changes in the protocol stack for the data streaming over the PLC scenario [19].

Protocol conversion block-scenario-2

Existing PLC protocols Existing/Future UWB protocols New protocols

Figure 5.31

Protocol conversion block [19].

DS-UWB instead of the MB-OFDM UWB technology. The frequency of operation for the wired UWB application can be designed on the 20% fractional bandwidth requirement of the basic UWB definition, and, therefore, this model views the UWB technology as one which can be implemented in the frequency band below 100 MHz. A proposed scenario for the Figure 5.32 business model has the value chain as shown in Figure 5.33. 5.2.2.4

Integration of PLC and Bluetooth

Bluetooth is a simple and cheap wireless solution with wide market coverage, but small range and low data throughput. Combining PLC with Bluetooth drastically increases the coverage and allows for mobile and lightweight devices to connect to a

319

PLC network

Wired PLC/UWB modem

5.2 Broadband over Powerline

Figure 5.32

Propagation of a UWB signal over the PLC channel [19].

Figure 5.33

Value chain-3 [19].

PLC backbone network. Areas where these capabilities are needed are home automation, medical surveillance, extension for automatic meter reading (AMR), and process automation. Figure 5.34 shows an example of this integration scenario for medical surveillance. Patients should not be hindered by this monitoring and be able to continue with their normal life. This requires unnoticed data collection and transfer. A second important aspect is the easy installation of such a monitoring system. Most of the

320

Broadband Access Networks and Services

Bluetooth links PLC access network

PLC/BT

Surveillance terminal

Patient Figure 5.34

Scenario for medical surveillance with Bluetooth and PLC [19].

monitoring shall take place at the home and large installation efforts (e.g., extra cabling) for a short time period of monitoring are not acceptable. This means that existing networks need to be used or networks have to be created on an ad hoc basis, which leaves wireless installations and the combination of wireless and PLC. The former is at a disadvantage if larger areas need the coverage. The latter allows for only small distances of the wireless transmission to the next BS. From there, the PLC transports the data to a central recording station or for live monitoring to a monitoring station. Bluetooth is a good choice here, as it is well suited for creating ad hoc networks and low power transmission. Low power transmission is an important feature, as it allows for longer monitoring periods without recharging the necessary batteries. Figure 5.35 shows a possible scenario for the extension of AMR with Bluetooth. Current PLC-based AMR systems require a PLC modem for each meter. However, in environments where multiple meters are deployed such as apartment houses, this becomes an increasingly costly solution. Not every meter needs a direct high bandwidth connection to the remote accounting infrastructure. Bluetooth is used to connect all meters to one central gateway with PLC and Bluetooth interfaces. The gateway forwards the metering data to the accounting office. This setup enables AMR for water and gas as well, as both to report to the PLC/Bluetooth gateway via the Bluetooth technology. As Bluetooth is a versatile technology which is used for very different applications, the protocol stack has to reflect this. Figure 5.36 shows one possible protocol stack for the PLC/Bluetooth adapter. This protocol stack does not specify which application protocol is transported over the Bluetooth link. The host controller interface is the interface to the Bluetooth hardware. L2CAP is the logical link control and adaptation layer. It is the interface for all higher protocol layers to the baseband. RFCOMM is used for all types of cable replacement, packet-type applications. The application layer(s) using RFCOMM usually use an asynchronous connectionless link for their Bluetooth links. As Bluetooth devices are capable of ad hoc networks, they need to discover the services other nodes in the network can offer. For this the Service Discovery Protocol (SDP) is used. The data from the Bluetooth interface has to be reencoded for transmission over the PLC link and vice versa, which requires a new software component in the Bluetooth modem.

5.2 Broadband over Powerline

321

accounting Bluetooth links PLC

gas meter

PLT/BT apartment meters

Figure 5.35

AMR extension with Bluetooth [19].

Application SDP

Control

RFCOMM L2CAP Link Manager

Host Controller Interface

Baseband Radio Figure 5.36

5.2.2.5

Generic data transfer Bluetooth protocol stack [19].

Summary

The integration of some emerging wireless communication technologies with PLC can enhance the benefit for the potential market of PLC. In the preceding sections, this integration was carried out only partially, but it provides a sufficient insight in the possibilities offered by the integration of PLC with other wireless technologies.

322

5.3

Broadband Access Networks and Services

Next Generation Broadband Access Platforms A future broadband access platform should not only have multiservice capabilities, but also multihosting capabilities. Multiple providers will, on one hand, compete, but on the other hand, join complementary expertise in alliances to offer the most attractive service package to the end users. A good understanding of the roles and responsibilities is essential, because a future network architecture should allow for a flexible implementation of possibly different business models. In such an environment, interoperability between access/edge network elements and customer premises equipment (CPEs) across different network layers for delivering a variety of broadband services, including fixed mobile converged services, is essential [29]. In order to achieve interoperability and finally convergence, the following research issues are of importance: • •

•

•

•

•

•

•

5.3.1

Analysis of business roles; How to support secure communication in the data plane based on Ethernet and IP; How to support of one type of services in an access architecture that might have been designed for another type of services, thereby dealing with specific aspects like security, VoIP, and VPNs; How to enhance the delivery of multimedia services by the integration of service enablers in the access architecture [e.g., DPI, SBC, lawful intercept, improved quality of experience (QoE) for video services]; Handling of authentication, authorization, and accounting (AAA) through the definition of AAA concepts, identification of requirements, and the best suitable protocols to carry the related information; Realization of QoS in the network and providing the best delivery of services to the end customer; Planning [e.g., congestion avoidance control (CAC), policy enforcement, and management of unicast and multicast traffic]; Fixed mobile convergence where architectural issues related to nomadism and roaming must be handled. Business Roles

Figure 5.37 shows the network architecture reference model with the various network elements and business role domains that were established in the framework of the FP6 IST project MUSE [2]. Different roles can be distinguished in the business model. The network access provider (NAP) is responsible for the infrastructure of the first mile and the aggregation network up to the access edge nodes. The regional network provider (RNP) connects the access network with the service providers (typically via a metro network). There are also different types of service providers that can be distinguished. A network service provider (NSP) offers network access to the Internet or a corporate network. An application service provider (ASP) delivers applications (e.g.,

5.3 Next Generation Broadband Access Platforms

Figure 5.37

323

Future broadband network architecture and business roles [29].

video-on-demand) and has relations with a content provider. An Internet service provider (ISP) is a combination of an NSP which at the same time offers Internet services such as Web access or e-mail. The connectivity provider (CP) is responsible for obtaining end-to-end connectivity between the CPE and the NSP or ASP network and for guaranteeing the agreed QoS and security characteristics. The packager role combines connection services obtained via the connectivity provider from NAPs, RNPs, and NSPs, on one hand, with application services from one or more ASPs, on the other hand, and offers this as a package to the customer. In general, the packager is technology agnostic and is the single point of contact for the subscriber. In reality, a player can take up one or more of the above-mentioned business roles. For example, the packager role can be combined with an NAP or an NSP. Reference [29] defined the different responsibilities per business role and allocated the network functions at data plane, control plane, or management plane. Details are also described in [30, 31]. In the case of nomadic services or session continuity, a user may connect to services offered by the providers in a visited network that are different from the providers in his or her home access network (i.e., the network where a user is subscribed and where the main repository with the credentials and user profile is located). Roaming agreements between peer roles (e.g., connectivity provider–connectivity provider, NSP–NSP, ASP–ASP) are then required to exchange the credentials and user policies in order to authorize the subscriber to access resources and services in the visited network [32]. 5.3.2

Architectural and Protocol Reference Models

The FP6 project MUSE [32] developed a number of basic reference models, which formed the basis of the specification of the platform in Figure 5.37. These reference models can be summarized as follows:

324

Broadband Access Networks and Services

•

•

•

The public network reference model, including the service provider networks, showing the functional entities in the public network; The residential network reference model, valid in the residential environment, and showing the functional entities in the residential network; The protocol reference model, showing the protocol stack and planes in the global broadband network.

5.3.2.1

Public Reference Models

Two public reference models were developed in [29], which were an evolution from the existing ATM-based access networks. Both models rely on the Ethernet as the link layer and their use is closely tied to the different business roles of the network operators and local constraints. An Ethernet network reference model relies on the Ethernet practices and techniques to achieve connectivity in the network with additional mechanisms for security, multicasting, and configuration. The second model is an IP network reference model, which adds some IP awareness in the access nodes and allows interpretation, and even modification of the IP packets. The two models are shown in Figure 5.38 and Figure 5.39, respectively. As part of the Ethernet network model, the access nodes work in both modes with an intelligent bridging used for residential customers and cross-connect for business customers. The main reasons leading to the choice of intelligent bridging are: •

•

A simpler provisioning of virtual local area network (VLAN) (with only one single VLAN to be configured and interpreted in the aggregation network), Local peer-to-peer traffic at layer 2 is possible (for IPoE) if allowed at the access node (AN) or the edge node (EN).

In addition to the residential case, the AN shall support business users, which can carry their own VLANs in their traffic. Therefore, traffic from the business users

Figure 5.38

Ethernet network reference model [32].

5.3 Next Generation Broadband Access Platforms

Figure 5.39

325

IP forwarding reference network reference model [29].

should be cross-connected transparently in the AN based on S-VLAN tags, and if more than 4,094 business VPNs are to be supported, it is recommended to use multiple protocol label switching (MPLS) in the aggregation network (from the aggregation switch onwards). Reference [29] recommends to use both a VLAN per [AN;EN] pair in order to limit the broadcast domain per AN and an S-VLAN for allowing stacking with the VLANs generated by the business customers. On the last mile (between the CPE and the AN), priority-tagged VLANs are recommended for the upstream QoS classification. For multicasting traffic, it is recommended to apply stream replication in the AN by means of an IGMP snooping or proxy and to build the corresponding multicast trees in the aggregation network by means of the IGMP snooping in the aggregation switch. It is recommended to terminate IGMP at the EN and to connect the EN to the multicast servers [29]. Some aspects of the Ethernet network model cause limitations, which can be overcome by using the IP network model, namely: •

•

•

•

The end-to-end QoS is managed at the IP layer. For the Ethernet model the necessary QoS mechanisms must be mapped to the layer 2 functions. The goal is to evolve towards an IP QoS as the global management mechanism. Layer 2 access and aggregation networks are more prone to security attacks, in particular, theft and denial of service. Additional security mechanisms must be foreseen for L2 networks. Forwarding and ARP tables can become huge in the case of intelligent bridging and the number of VLANs is limited in cross-connect. These two limitations are overcome when there is a layer 2 separation between end users and aggregation network combined with forwarding at the IP level. Faster and more reliable switchover can be reached with the IP access networks.

326

Broadband Access Networks and Services

•

The traffic control at layer 3 in the access node will simplify the local peer-to-peer traffic and would facilitate the realization of service enablers at layer 3 and above.

The IP network model can be based on IPv4 or IPv6 or a combination of both. The following three scenarios can be identified for an IP network model: •

•

•

IP forwarding, where the NAP transports IP packets from the AN to the appropriate ISP/NSP/ASP through service connections. Those service connections may either be implemented by VLAN or by connection oriented MPLS LSP, for example. The main advantage of this scenario is its simplicity (address resolution based on ARP without needs for routing message exchanges) combined with a centralized addressing scheme per service connection. Moreover, NAP and NSP roles can be strictly separated. IP routing for retail users. NAP becomes also NSP in a sense that it offers an IP network service to its retail end users in order to upgrade its access and aggregation network to a QoS-enhanced IP network. The addressing scheme becomes a critical issue (IP address waste, size of routing tables, routing information volume). Wholesale users are still managed at L2 and no virtual router is needed. IP routing for retail and wholesale users. In this scenario, multiple NSPs must be enabled to assign the IP addresses to the customer premise network. Different approaches have been studied but provide some extra complexity in the access network (multiple virtual routers, source-based routing combined with IP tunneling, for example).

IP forwarding with a centralized addressing scheme for the short and mid term was recommended in [29]. IP routing for retail was recommended for the longer term. IP routing for retail and wholesale is not recommended due to complexity and lack of flexibility. Existing IP services are mostly based on the Point-to-Point Protocol over the Ethernet (PPPoE). It is, therefore, important that during a migration phase the PPPoE traffic can still be supported in parallel to the IP over Ethernet (IPoE). In [33], which provided functional specifications for the multiservice access and aggregation networks, three solutions were proposed. Reference [29] recommends the solution related to the switching of PPP frames due to its simplicity and its capability to reuse the already deployed broadband remote access server (BRAS). For the support of multicast sources in the network, it is recommended to use protocol independent multicast source-specific multicast (PIM SSM) for the IP nodes in complex network topologies because it allows dynamic routing and mesh topologies in the access network. In the case of simple tree-like topologies, simple multicast group management protocols (IGMPv3 in snooping or proxy mode) make sense, because there is less configuration effort involved [29]. For the support of multicast streams generated by the end users, it is recommended to use PIM (ASM) because it avoids the need to route the streams via the EN.

5.3 Next Generation Broadband Access Platforms

5.3.2.2

327

Residential Reference Models

Figure 5.40 shows a residential network reference model. It shows the functional entities in the residential network, which is located behind the U-interface in the customer premises. Figure 5.40 shows the possible entities in the residential network and their interfaces. These functional entities are: the NT1 (WAN modem), the NT2 (L2/L3 forwarding unit), the CPN (wireline or wireless distribution), the ST (IP-based terminal), or a terminal adapter (TA) converting for an ST’ (non-IP-based terminal). An NT1 and an NT2 can be combined in an NT12, which is generally referred to as a residential gateway. The interfaces between the functional entities are identified by reference points: U, T1, T2, S, and R. It should be noted that in different literature and standards the terminal might be referred to in a different way (e.g., device, consumer equipment device-CE, user equipment-UE, wireless station-STA, and so forth). 5.3.2.3

Protocol Reference Model (PRM)

In modern communication systems, a layered approach is used for the organization of all communication functions. The functions of layers and the relation of layers with respect to each other are described in a protocol reference model (PRM). The PRM provides a system model including the following features: • • • •

Communication protocol stacks for data and for control/management; layers and service access points (SAPs); Management on protocol layers; Internal (system) functions.

The PRM is composed of seven layers (e.g., see OSI model) and three planes (i.e., data, control, and management) and is based on the (B-) ISDN PRM (which consists of three planes [34]). Some of the layers may consist of multiple sublayers. The data transfer is performed using the data plane. The system control and management communication are performed in the control plane. The system functions, including switching, are located in the management plane. The PRM is applicable in every entity shown in the architecture reference models.

Figure 5.40

Residential network reference model [29].

328

Broadband Access Networks and Services

The data transfer is based on layers 1, together with layer 2, or with layers 2 and 3. Layer 2 (Ethernet) and/or layer 3 (IP) is used for switching (bridging, forwarding) the transferred data within an entity. Layers 2 and 3 are basic layers in the next generation broadband architecture. All layers may contain a number of sublayers. In particular, in between L2 and L3, L2.5 may exist in order to interconnect the network entities. A number of different physical interfaces (layer 1) may be used [29]. Within an actual system entity, some of the layers or planes may not be present. The PRM is extremely useful in order to position particular protocols or functions, and to show peer-to-peer and link-by-link communications. 5.3.3

Small and Medium Enterprises Support

Operators currently deploy new access and aggregation networks in order to face the new bandwidth and service requirements. Most operators target both residential and business customers. If large companies have dedicated solutions, it is crucial for operators to adopt a single network architecture for both residential and SME customers. Network convergence can dramatically reduce the investment costs for operators [29]. The following three topics are considered as particularly important with impact on the next generation broadband communication architecture: 1. Security: The needs of SMEs are quite similar to those of residential customers, but the requirements are stronger: • Confidentiality: One customer cannot have access to the traffic destined to another customer. • Theft of service (ToS)/theft of identity prevention: One customer cannot use the IP address assigned to another customer. • Denial of service (DoS) prevention: One customer cannot disturb the communications of another customer. 2. VoIP: The SMEs’ needs lead to improved QoS and particularly to a higher number of simultaneous calls. Classical solutions dedicated to residential customers do not fit these requirements and additional features are needed. 3. Virtual private networks (VPNs): These are an essential business service for the network operators. VPNs provide secure data access and allow reuse of the available public networks. 5.3.3.1

Security

The most important threats regarding confidentiality are the ToS and the DoS. In order to face these critical threats, it was recommended in [29] to tackle the MAC address spoofing through the VMAC functionality on the access node. For L3 access nodes, VMAC shall be activated only on the PPP customers, which have not yet migrated to a DHCP-based access. Moreover, it is recommended to implement IP antispoofing based on the DHCP learning function on the access node (L2 or L3). This functionality, however, is not needed for the regular PPPoE customers because the IP antispoofing functionality is delegated to the BRAS. A PPPoE session ID antispoofing mechanism is also delegated to the BRAS. Additional details related to threats and antispoofing mechanisms can be found in [31].

5.3 Next Generation Broadband Access Platforms

329

Because sniffing is usually the initial step before an attack, it is necessary to deny the opportunity of malicious users to analyze the traffic intended for another customer. While a point-to-point architecture, such as the DSL one, naturally prevents sniffing, special attention should be paid to the shared medium access networks. Activating the encryption provisions available in the different access technologies when possible and providing a point-to-point logical link is one way to protect the shared medium. When this is not possible (e.g., for Wi-Fi access), higher layer encryption mechanisms like IPSec tunnels can be used. Because the DHCP servers are also critical elements, an implementation of a mechanism on the access node, which limits the number of IP addresses per customer and the number of DHCP messages per second per customer port, can be useful [29]. The AN shall implement a DHCP relay function in order to avoid that the fake DHCP servers reply before the genuine DHCP servers. DoS/DDoS cannot be efficiently tackled by the previous mechanism, but it seems unreasonable to implement complete firewalls in the access nodes. Static filtering on the AN and firewall solutions in the NSP domain are a possible solution. Another critical threat is the routing protocol attacks and this requires generic solutions that would be implemented in the access and backhaul networks. 5.3.3.2

VoIP for SMEs

The major objective is to replace either an E1 connection (or a number of POTS/ISDN lines) between the SME and the network by a pair of DSL lines. The business VoIP requires more security than the classical VoIP, but this can be provided by running it through a VPN (e.g., between the VoIP PBX and the Call Server on the operator side). VPNs allow encryption for security and enhanced QoS and, thus, allow operators (and resellers) to provide value-added features in the form of SLAs to the end business user. Multiple DSL (at least 2) connections are needed in this case, which can be used either for simple resilience, or also to increase the capacity under normal operation by load sharing. The CPE is the weakest link in the chain and is less reliable overall than the xDSL link. Ideally, the best solution would be one that would allow an SME to initially use a single CPE on a bonded xDSL line—but then allow it to add a second CPE seamlessly at a later date to implement a dual CPE solution. It would be possible to integrate the functionality of the business gateway and an IP-PBX into a single unit [31]. 5.3.3.3

VPN

Generic requirements for VPN have been reported in [35]. Technological solutions in the aggregation network area with respect to L2VPN and main technologies providing L2 VPN services were proposed in [31] [e.g., 802.1q, 802.1ad, 802.ah, PBB-TE, VPLS (flat or hierarchical), and Ethernet over MPLS]. Arguments for and against the most promising candidates (i.e., PBB, PBB-TE, T-MPLS, flat and hierarchical VPLS) can be identified based on the requirements of [35].

330

Broadband Access Networks and Services

In order to validate the technologies from an operator point of view, a questionnaire among the operators can identify an actual ranking for the technologies. Based on this approach, [2] identified that for an actual deployment, the most promising candidates are the flat and hierarchical VPLS. The major problem of the other solutions is the relatively short standardization time and the consequence that not all required features of operators are covered. For specific points, the solutions seem to suit the basic operator needs. 5.3.4

Service Enablers

A service enabler is a general term for a function required for the delivery of a service or a function that improves the QoS, enhances the security, allows for a more efficient use of resources, or facilitates the management of the network. Basic network service enablers are the authentication and QoS support or service enablers at a higher layer above the network layer. With the decreased price of processing and the improved caching capabilities in the ANs (e.g., the concept of the service plane in [36]), the optimal distribution of such service enablers in the access and aggregation networks are also of interest. More details can be found in [37]. The following sections elaborate a few relevant example cases of service enablers in the context of global broadband communications. 5.3.4.1

Deep Packet Inspection Enabler

A deep packet inspection enabler (DPI) consists of a piece of software or hardware that is either embedded into the existing equipment (e.g., AN, BRAS) or is a stand-alone equipment. The main function of the DPI is to identify the traffic at the application level (or the OSI level 7). A full description of the DPI Service Enabler is available in [37]. Once the traffic has been identified as belonging to a specific protocol (e.g., HTTP), it is possible to apply a specific action (e.g., shape, TOS remapping). In the context of a global broadband communication architecture, the DPI shall be used to perform the following actions: •

•

Remark the DSCP value of the traffic in accordance with the service implemented in the AN. The devices further down in the network will manage the traffic accordingly [in order to apply a QoS policy at the congestion point(s), and only if there is congestion]. Identify the traffic and apply policies defined by the service. This function is used as a security service (e.g., a DDoS attack or spit/spam sent by an infected host).

The location of the DPI depends on the service. The following two possibilities have been identified: • •

Distributed in the ANs; Centralized within an IP-Edge node or in front of a service platform.

5.3 Next Generation Broadband Access Platforms

331

As several services may be enabled by the DPI, the location has to be studied carefully. Some services favor the installation of the DPI in the AN or as a centralized enabler (e.g., legal interceptions); for others, it is mandatory to be installed in the AN (e.g., security services, QoS services on the uplink). Reference [29] recommends the installation of the DPI functions within the AN in order to deal with security near the source, mark the upstream flows of the dynamic applications on the first node trusted by the operator, and apply fine-grain QoS policies on an application-level knowledge, possibly coupled with QoE mechanisms. Services such as spit/spam detection and prevention, legal intercept, QoE measurement, and QoS trigger for P2P services rely on the installation of a DPI. If an operator wants to implement these services with high constraints on time to market, quality, and at a low cost, it is better to build these services from a common DPI achieving a single application-level analysis and triggering flows to different application servers, rather than having different services doing their own application-level analysis at different places (and possibly located in cascade) in the network [29]. 5.3.4.2

Session Border Controller Enabler

A session border controller (SBC) is an important service enabler for multimedia conversational services that are using SIP, such as voice or videoconference calls (i.e., sessions). With the arrival of next generation networks (NGN) [38] and the IP multimedia subsystem (IMS), the role played by the SBC is expected to become crucial [29]. In a conventional architecture, an SBC is located at the “border” of the network domains and provides various “control” functions, such as NAPT traversal of signaling, policy enforcement, pin holing, remarking of packets for QoS control, and others. Reference [29] investigated the benefits of distributing the SBC functions closer to the user at the access node or even in the residential gateway. The architectural distribution of the SBC functions into the AN is different for a retail business model (in which the NAP and ASP are a single business entity or have a trusted relationship), and a wholesale business model (in which the NAP and NSP are distinct entities). In a retail model, there is no more need for an SBC at the edge between the NAP and the ASP. In a wholesale model, an SBC is still required at the edge with the ASP, although with a reduced set of functions (e.g., policing at aggregate level, simplified control) [33]. Figure 5.41 shows the distributed SBC architecture for a retail model and how the secure overlay network is extended to the ANs. The QoS control and the enforcement are performed at the actual “ingress” of the NAP network, in the first “trusted” network element of the domain. The overall security is improved. Shaping at the ingress of the NAP network has also the benefit of limiting the upstream load on the aggregation part of the network and providing fairness and QoS guarantees among the different users connected to the AN. Another benefit is the protection of the soft switch against signaling of the DoS attacks at the network access.

332

Broadband Access Networks and Services

Figure 5.41

Extension of a secured overlay network [29].

Generally known motivators for decentralization also apply to a distributed SBC architecture; namely, a better scalability is achieved (e.g., smaller number of users per local SBC). The robustness is also improved: a single point of failure (SPOF) affects far less users than having an SBC at the edge and fewer sessions have to be switched over at the same time in case of a failure event. Resilience techniques will have to be implemented to redirect users to a spare SBC in the case of failure. The cost for resilience in a distributed architecture is lower, thanks to a 1:N node protection scheme [29]. The SIP awareness introduced in the ANs with the move of the border controller part of the SBC eases the integration of resource management across multiple services in the AN (e.g., VoD and VoIP) for the first mile. Techno-economic evaluations in [30] show that adding functionality in the AN does not lead to a higher investment cost. The cost of the end-to-end solution is in fact very similar for a distributed or centralized approach, with a slight benefit for a distributed architecture if the functions are well integrated in an optimized AN hardware. Savings in the core network offset a small increase of the cost of the AN. Though more difficult to quantify, a possible increase of operational costs for managing distributed functions is expected to be balanced by fewer operator interventions, thanks to an improved security, more manageable scalability, and a reduced impact of network failures. On the longer term, some of the SBC functions could also be pushed further into a residential gateway (RGW) of the home network assuming that it would become a trusted network element. Reference [2] assessed a new hardware platform with certified software that could indeed make the RGW trusted, although at an additional investment and operational cost and not suitable for the already installed base. The study in [37] provides a baseline for the next steps in the evolution towards a simpler and more efficient access and aggregation network in which, for example, the identi-

5.3 Next Generation Broadband Access Platforms

333

fication of terminals and the classification of traffic would be performed by the RGW. 5.3.4.3

Lawful Intercept Enabler

Lawful interception is an important service enabler for providers. Authorities may request from an operator to intercept and deliver all traffic of a subscriber, or only a specific part of the traffic (e.g., e-mail). Reference [37] analyzed how the D-SBC architecture, as described in Section 5.3.4.2, provides means for lawful interception of SIP services. The D-SBC architecture was extended with DPI to allow for the lawful interception of non-SIP based services as well. The authentication process is an important constituent for identification of a subscriber as a potential target for lawful interception. The studies are based on a standard reference model for lawful interception [39, 40], which was mapped to possible business scenarios [30]. Two examples (one for SIP, one for non-SIP) are described next. For SIP, the straightforward mono-provider model has that all functions are performed within a single operator’s equipment and stay in a trusted relationship. The operator owns a soft switch and all SIP messages sent by a retail subscriber are directed to the session border controller (SBC), located in the AN, and then on to the central server. This is shown in Figure 5.42. After the detection of a suspect’s user ID in the SIP dialogue, the soft switch triggers the AN of the subscribers, which begins duplicating data and sending them to a Lawful Enforcement Monitoring Function (LEMF) via the mediation function (MF). Data sent between an access node and the MF are transmitted over a VLAN dedicated for lawful interception communication. Other scenarios such as multiprovider, roaming, and wholesale are described in [30]. Figure 5.43 shows the retail model for the non-SIP services. All entities in the lawful interception chain belong to the same operator and the same OSS. The AN is the traffic mirroring point. After the report and configuration are performed by the OSS, the AN duplicates the whole traffic of a target subscriber (both directions) and passes it to the DPI.

EN (router) SIP RTP

EN (router) Intercept Related Information (IRI) Content of Communication (CC)

Figure 5.42

Retail mono-provider SIP session [29].

334

Broadband Access Networks and Services

User traffic Intercepted traffic

Figure 5.43

Retail model for non-SIP services [29].

The DPI device, which has been configured by the OSS with an appropriate traffic descriptor, discards the unwanted traffic and leaves only that requested by the Law Enforcement Agency (LEA). The extracted part of the traffic is then sent to the mediation function (MF), which formats it according to the standard [41] and forwards it to the LEMF. Both in the SIP and the non-SIP cases, it is advisable to start the traffic duplication in the AN. As only a limited amount of intercepts is running at a time, this can be achieved with low resource consumption within an AN. In the SIP case, only the traffic to be intercepted is duplicated. In the non-SIP case, the work is split between the AN (duplicates all the traffic of a user to be intercepted) and the DPI box (filters the traffic in such a way that only the requested traffic is forwarded to the legal entities). Standardization is needed here to define the interfaces required to set up the interception within the AN and other nodes [29]. 5.3.4.4

Video Service Enablers

In order to enhance the QoE for video applications, two approaches were proposed in [29] to achieve a more reliable transport of video services over a network that includes error prone DSL or wireless sections. Figure 5.44 shows one solution based on retransmissions. State-of-the-art protocols show that one can build on the Real-Time Protocol (RTP) protocol for a more efficient transport of broadcast video or video on demand. RTP can be implemented either on top of the already in use User Datagram Protocol (UDP) or as a replacement of the MPEG2-TS (Motion Picture Expert Group–Transport Stream) over UDP. Existing RTP retransmission mechanisms used for videoconference calls can be improved to make the protocol usable for broadcast TV services. The specification of an RTP proxy in the AN developed in [29] with some caching resources is an effective solution to accommodate for the losses of video packets in the home network or on the last mile.

5.3 Next Generation Broadband Access Platforms

Figure 5.44

335

Principle of improved video reliability by packet retransmission [29].

As an alternative solution, the benefits of an end-to-end forward error correction (FEC) at the transport layer were quantified by field trial results. After the correction by FEC, the number of noticeable artifacts is below the recommendation given by the standard (1 or 2 per hour). When comparing retransmission with FEC, FEC is transparently carried over the network, but requires an additional bandwidth of about 20%. Retransmission, on the other hand, requires little average bandwidth overhead (only the bandwidth for retransmission of the lost packets), but additional intelligence in an intermediate node. 5.3.5

Authentication, Authorization, and Accounting

Authentication, Authorization, and Accounting (AAA) are important functions accompanying the auto-configuration process that establishes a service in a multiservice access network [29]. Authentication is the process of determining whether someone or something is, in fact, who or what it declares to be. Authentication is based on the identifiers and security attributes: the so-called credentials. Authorization is the process of giving individuals or devices access to particular resources, guarantees, or applications based on their identity. Accounting is the recording, classifying, summarizing, and interpreting of events for charging purposes. A conventional broadband access network most often uses the PPP. PPP is a tunnel-based connectivity protocol, which has the following disadvantages with regard to the deployment of multiple services. First, a tunnel needs to be set up for every path between a user device in the customer premises and an edge point. Furthermore, for every layer 2 QoS class that is supported between the edge and the user, an extra tunnel is required. This is due to the fact that once packets enter a PPP

336

Broadband Access Networks and Services

tunnel, it is not possible anymore to reshuffle these based on a certain criteria (e.g., IP QoS parameters). On top of that, a PPP-based connectivity model cannot take advantage of the multicast streams. The Dynamic Host Configuration Protocol (DHCP) can be used [29] in the access network for the configuration and control of the link and network layer of a connection, as an alternative to PPP. DHCP, however, does not sufficiently support two essential functions provided by PPP, namely the authentication, and the management of a subscriber session. An additional new requirement can appear to be the support of nomadic users, which implies that users or devices need to be easily authenticated from different places in a network, and even from different networks (roaming situations). Different levels of authentication are required depending on the purpose of authentication [35]. The first set of requirements described here deals with the authentication in a nonnomadic context. The most important entity to be authenticated is the subscriber. This is needed in order to configure the personalized authorized network services and allow for accounting. Another reason for the subscriber authentication is that an ISP is legally obliged to know and to record at all times what IP address was allocated to which subscriber. Also, for legal interceptions, a provider must be able, when requested by the authorities, to intercept and to duplicate the traffic originating from or destined to some particular subscribers. It must be possible to authenticate a subscriber in one of the following ways: per line (which is equivalent to a physical port on the access node), per circuit (e.g., a configured virtual circuit or a medium access control identifier on a PON), or per RGW (which then uses hard-coded or configured credentials for the identification). An option is also to perform subscriber authentication based on the credentials embedded in a terminal, in case the RGW would not have the required functionality to participate in the authentication process. In addition to the subscriber, who pays the overall bill, individual users on the premises could in principle be authenticated as well (e.g., for parental control or detailed accounting of specific services). This, however, complicates the authentication infrastructure and is better handled locally or at the application level. Another entity that can be authenticated is the physical device being used. It should be possible to identify a device type in scenarios where an operator relies on a specific functionality in a RGW or a set-top box for the deployment of services. The operator should be able to verify whether the device is a sufficiently trusted entity, whether the software or hardware was modified, or whether it incorporates the necessary security functions. A next possible level would be to authenticate the individual devices (e.g., to block the traffic to stolen devices). This, however, might have an excessive implementation complexity [29]. There are some additional requirements in case that the network has to support nomadic services. In order to control and trace the traffic of the nomadic subscribers, it can be necessary to independently authenticate and authorize a permanent subscriber of a given access point on certain premises (the host), and the occasional users who are passing by and are subscribed to a broadband service (the visitors), whereby the visitors must not disturb or change the network services received by the host. The connectivity provider and the NSP of a visited network must furthermore

5.3 Next Generation Broadband Access Platforms

337

be able to correlate each visiting user/device IP address with the identity of a subscriber, and particularly with the credential information given by this user/device during the authentication request. Both the permanent host and the nomadic visitor will have expectations in terms of confidentiality of their traffic. The AAA architecture must allow the different actors involved to interact in a way that would not allow the controlled nomadic access to a user connecting from different places in the home access network, or in a visited network for the case of roaming. 5.3.5.1

Solutions for Authentication

Figure 5.45 shows the different functional elements of a basic AAA architecture. The network performs authentication by means of an authenticator, which collects the authentication credentials from a supplicant at the end user’s side, and an AAA server, which determines whether these credentials match a known entity (e.g., the end-user device). The network is then able to authorize the authenticated entities to access the network resources. In the case of multiple providers, an AAA proxy will forward the request to the proper provider based on a provider identifier in the credentials. The authorization can typically take the form of an authorization profile, which is returned by a policy server to the authenticator on a network node. Such an authorization profile can contain a collection of network policies ranging from a simple acceptance to use the network, over an access control list (ACL) of permitted and forbidden services, to a complete list of QoS parameters for each class of service. It can also contain network-specific parameters and settings. These policies have to reach the appropriate points in the network where they must be enforced. The communication between the supplicant and the authenticator is handled by protocols such as PPP, IEEE802.1X, or others, as discussed later in this section. The communication between the authenticator and AAA proxies or servers is handled via the Remote Authentication Dial In User Service (RADIUS) or the DIAMETER protocol (the latter offering additional capabilities for mobility services). After authorization, an IP configuration is performed by means of DHCP. The exact location of the supplicant and the authenticator depend on the type of RGW (bridged, routed with or without NAPT) plus the nomadic aspect, and, respectively, on the type of AN (L2 or L3). The authenticator is colocated with the AAA client for interaction with the AAA infrastructure. Depending on the type of authentication, the policy enforcement point (authorizations) can be colocated with the authenticator or on a node closer to the end user.

Figure 5.45

General AAA architecture.

338

Broadband Access Networks and Services

Different solutions can be investigated to carry the credentials between the entity to be authenticated (i.e., the supplicant) and the authenticator, possibly across different types of RGW. Some common solutions are per line identification or password-based authentication using a Web application. Line identification is a static authentication without the credentials per subscriber and which is limited to a single entity per line. Web-based authentication with a password is limited to terminals that feature a browser and some form of a user interface (e.g., a screen and keyboard). The Extensible Authentication Protocol (EAP) overcomes these limitations and allows for dynamic authentication with different types of credentials [e.g., certificates, one-time passwords, or Subscriber Identification Module (SIM) or smartcard]. It is possible to use EAP during the authentication phase of PPP, but it requires PPP(oE) termination. If the objective is to find authentication solutions complementary to DHCP, other protocols to carry EAP can be investigated, such as the IEEE802.1X [42], the Protocol for carrying Authentication for Network Access (PANA) [43], and EAP over DHCP [44]. IEEE802.1X allows carrying EAP over Ethernet and is used to open a port to an Ethernet switch. The advantage is that it is a defined standard and available on products today. The limitations of the standard are that it cannot cross bridges or routers, it cannot be VLAN tagged, and it is not conceived for multiple authentications on the same physical port for wired access. It is, hence, well suited for single authentication of an RGW on an Ethernet-based access line and is, as such, a solution in the short term. It does not allow for multiple authentications on the same line, as needed in the context of nomadism [multiple subscribers (resident + nomadic visitors)] and in the context of multiple service providers. It is possible to circumvent this by designing an IEEE802.1X proxy on the RGW that authenticates the users or devices behind it, but this requires a trusted RGW that directly connects the network’s AAA infrastructure, which is not a viable option for many providers. Using IEEE802.1X in an architecture that supports Control and Provisioning of Wireless Access Points (CAPWAP) [45–47] is a possible solution to the mentioned problems. The CAPWAP architecture splits the access point into a wireless termination point on the RGW and an access controller, which performs authentication, on a trusted access node in the network. All control frames, including those for authentication, and data frames are carried over an encrypted tunnel that is terminated in the access controller. The advantage is that the terminals are not affected (no new requirements). However, CAPWAP is positioned for IEEE802.11 Wi-Fi devices and as such is not expected to be available on wired devices (e.g., wired terminals behind a bridged RGW). Another possibility is the use of 802.1AE [48] in combination with 802.1AF [49], allowing for a secure tunnel connection between the terminal itself and the AN across a bridged (part of the) RGW. The enforcement is based on the MAC address of the user, which is integrity protected by the 802.1AE protocol. At the time of this writing, this protocol had not yet been deployed in terminals. PANA is a link-layer agnostic network access authentication protocol. It is conceived to transport EAP across layer 3 networks and the PANA multihop extension under a definition that allows for crossing routers. It is possible to have multiple

5.3 Next Generation Broadband Access Platforms

339

EAP sessions per line. It also supports the traversal of network address translation (NAT) between the supplicant and the authenticator. It requires interaction with other protocols (e.g., DHCP) in the network node to enforce the authentication result at layer 3. This means that the two separate state machines must be coupled. PANA can be combined with IPSec to support nomadism. It implies the use of an unauthenticated IP address at the beginning of the PANA authentication process, and additional filtering of PANA messages is required in the AN for security. A more recent initiative in IETF is the extension of DHCP for carrying EAP [44]. EAPoDHCP allows for crossing routers and the handling of multiple EAP sessions per client. Unlike PANA, EAPoDHCP is intended to become an integral part of the DHCP auto-configuration process and avoids the need for an assignment of a temporary IP address prior to the authentication. It will impact the DHCP state machine in client and proxy. Furthermore, a specific local proxy function is needed in the RGW for allowing the authentication of nomadic terminals when the RGW is of the routing type with NAPT. For the authentication of nomadic subscribers, this protocol should be combined with IPSec tunnel establishment just like PANA. It is a strong alternative for PANA, if it gets sufficient definition in standardization. The choice between PANA and EAPoDHCP is not straightforward [29]. Given the extra requirements with PANA of binding the two protocol state machines and foreseeing extra filtering for security, the use of EAPoDHCP as a global authentication method may be favored. 5.3.6

Quality of Service and Connection Admission Control

Figure 5.46 shows a QoS architecture for support of broadband communications. The introduction of QoS into networks as this allows better resource use, while providing multiple and different applications with the transport quality they actually need. Traffic classes, selective CAC, and appropriate network dimensioning are the keystones of a QoS solution for next generation broadband communications [29]. The usage of at least four traffic classes (e.g., real-time, streaming, transactions, and best-effort) can help differentiate the traffic, while preserving the scalability of the network. The classification of the upstream traffic into the traffic classes, and its prioritization onto the access link can be realized by the RGW according to users’ preferences. The prioritization of downstream traffic per traffic class is made by the network according to the rules described in the users’ contracts. The use of central CAC for the small subset of services that actually need it (e.g., VoD) and only in those parts of the network where the network operator has identified a potential dimensioning problem can be very beneficial in support of QoS and network performance. Local CAC at the AN or no CAC can be used for the rest of the traffic. Appropriate network dimensioning will help to minimize the risk of having congestion or blocking problems. A “provisioning” scenario where the central CAC, which has a view of all network resources usage, is able to allocate to a local CAC a certain amount of resources that will then be managed locally. Within this

340

Broadband Access Networks and Services

Figure 5.46

Broadband QoS architecture [29].

approach, the central CAC regularly monitors the usage of local resources at the ANs and adjusts the resources allocated to the local CAC entities if needed. 5.3.6.1

Connection Admission Control

5.3.6.1.1 On Demand and Preprovisioned CAC

On-demand CAC means that the CAC decision is based on calculating the current usage and availability of network resources for the requested QoS in real time. On-demand CAC can support requests that are heterogeneous in the sense that the flows do need to have the same QoS parameters. The preprovisioned CAC refers to the CAC process where a decision is simply made on the basis of the number of accepted requests, which must not exceed a previously specified number. The preprovisioned CAC supports only homogeneous calls (i.e., those having the same network requirements, and only the number of accepted calls is counted). With both techniques, there has to be a mechanism so that the actual state of the network and the net number of accepted calls remains synchronized (i.e., if a call teardown is missed, then the additional calls may be unnecessarily rejected). Synchronization at regular intervals could be done by an extended performance monitoring system. 5.3.6.1.2

Selective CAC

In large access network domains, a scalability problem could arise when implementing signaled CAC for each and every flow. A solution is required to provide QoS without the need to have a view of used resources for every individual flow. This can be achieved by using signaled CAC for a subset of services, and in those parts of the network where the network operator has identified a potential dimensioning prob-

5.3 Next Generation Broadband Access Platforms

341

lem. Traffic engineering (i.e., the provisioning of virtual pipes) can be used to segregate the network resources into the following groups: •

•

One set of resources that can be used by services without an on-demand or signaled CAC process. For best-effort traffic, which has no QoS guarantees, there is no CAC needed with respect to usage of network resources. Another set of resources for which signaled CAC is needed on a call/session basis. A given pipe can either be completely dedicated to traffic subject to CAC or, to improve the network use, may be shared between CAC and non-CAC traffic. In the case of sharing, then prioritization mechanisms will be required in addition to CAC. Depending on the network architecture and dimensioning, CAC may only be needed for certain links within an end-to-end path.

5.3.6.1.3 Central CAC

A central CAC system means that there is one CAC system for the network and all call admission requests have to be signaled to this central system. The central CAC system has a complete view of the resources of the appropriate parts of the network. For each and every call (signaled) request or (nonsignaled) detection, the central CAC system is consulted, which depending on the availability of the resources decides either to allow or block the requested call. This decision is sent to the boundary node (i.e., AN or the EN) where enforcement may be done. 5.3.6.1.4 Local CAC

A local CAC system (i.e., local to a given network node) is when the CAC decision is made at the domain border elements such as the AN or EN. For a CAC decision to be made locally, it is necessary that there is a local view of the availability of network resources that are exclusively available to that border node. In order to allow for CAC decisions to be done independently by different border nodes, the different local views of resources should be maintained independently. To reach this, it is necessary that the network resources are previously partitioned and allocated to the different border nodes. This naturally leads to a reduction of the potential multiplexing gains that could be obtained, as unused resources allocated to a given border node cannot be used by another border node. In order to avoid this, partitions should be updated on a regular basis by a central authority that has a historic and a global view of network resource usage. Further refinements of the local CAC are possible, with the introduction of usage thresholds in the allocations of a resource to different border nodes. In this way, when the thresholds are exceeded, the central authority is informed so that it may recalculate a new partitioning. Any reallocation of resources must of course take into account the commercial agreements (SLAs) between network operators and service providers, which might specify bandwidth on a link-by-link basis. 5.3.6.2

Policy Enforcement

After a CAC decision is made, enforcement of the allowed QoS policy (bandwidth, QoS class, and maximum size of packet) may be required so that misbehaving flows

342

Broadband Access Networks and Services

do not impact the QoS of the other flows. A total protection can only be provided if the enforcement is done on a per flow basis. It is recommended that policy enforcement is done on aggregates of IP flows where it is possible to lower the processing power required at the nodes, especially for those nodes aggregating large amount of flows. This will not prevent a single misbehaving flow from impacting the aggregate, but will limit any damage to that aggregate, which in some cases may simply be the sum of the bandwidth allocated to an individual access line. Policy enforcement on aggregate IP flows could be based on aggregate IDs, such as VLANs, traffic classes, or other suitable IDs. Policy enforcement on individual IP flows could be based on either an L2 parameter or the IP 5 tuple (or a subset thereof), whereas the preferred choice of the flow ID for enforcement is the IP 5 tuple. In general, the enforcement of the individual IP flows may be more practical at the ANs with the aggregate flows being used at the ENs. This will lower the processing power requirements for policing at the ENs. For the upstream traffic, it is recommended that the policy enforcement is done at the ANs. This will minimize the chances of misbehaving flows altering the QoS of other flows in the aggregation network. After the CAC decision, the QoS policy has to be made available at the ANs (either sent from the central CAC system or available locally in case of having local or nonsignaled CAC). In addition to the aggregate enforcement at the ENs for downstream traffic, it is recommended to have per user class enforcement of the different traffic classes at the AN to prevent congestion of the first mile. Per line enforcement (or shaping) is commonly done at the BRAS in existing architectures. This is no longer viable in a multiedge architecture [29]. The only point at which all the traffic for a given line comes together may be the AN itself. An alternative to per user enforcement is to have strict priority scheduling of the downstream traffic at the AN for each user. This, however, could lead to starvation of lower classes in case of an accidental or misbehaving usage of the higher classes, as the undesired traffic marked as high priority would disturb the traffic marked as low priority. 5.3.6.3

Integrated Resource Management for Unicast and Multicast Traffic

The need for sharing the network resources between unicast and multicast traffic is due to the following possible aspects: •

•

•

Replacement of MPEG2 with H.264 for unicast or multicast traffic will lead to a gain in bandwidth. Multicast distribution will evolve from a situation where all channels are distributed to all access nodes to a more efficient situation where channels will be distributed to only those access nodes that have receivers in these groups. Unicast audiovisual applications (e.g., VoD and its variations) are a key differentiator for DSL operators compared to broadcasters (i.e., digital TV, satellite) and the former will probably look to increase the use of those unicast applications [29].

The sharing of network resources between unicast and multicast can be done in the following manner:

5.3 Next Generation Broadband Access Platforms

•

•

343

Using a global resource management that has a view of all resources used in a network, both unicast and multicast. This global resource manager can decide whether a new unicast flow can be accepted or not, or if the threshold allowed for multicast on a link could be increased or not. Using a local mechanism embedded in each network node for multicast flows. This local mechanism keeps the amount of multicast traffic under a predefined threshold. The multicast bandwidth is reserved in this model (i.e., not available for unicast traffic), because the central system has not the visibility of the instantaneous use of that bandwidth. The central system should get periodic feedback on the use of the multicast bandwidth, and thresholds can be adjusted in nonreal time (subject to any contractual agreements).

5.3.6.4

Policy-Control Framework

An optimal policy control framework is important to manage and provide the appropriate QoS for all broadband services in a multiservice, multiprovider environment. In the case of roaming, it is also important to define how policies are exchanged between a visited network provider and a home access network provider. The service level agreement (SLA) between the ASP and the CP (and in turn between the CP and the NAP if they belong to different business entities) specifies the QoS classes and total amount of network resources assigned for this service provider. The SLA is usually translated into network policies, which are then referred to when a subscriber initiates the service. For example, when a subscriber initiates a video on demand (VoD) request, a request to the application function (AF) is made with the appropriate service identification. This is shown in Figure 5.47. The AF interacts with the policy decision function (PDF) to check the policies for the particular service (e.g., VoD here), which is indicated by the service identification (step2). Having obtained the agreed-upon QoS class and parameters of the IP flows needed for this service (step 3), the resource admission control (RAC) checks for the availability of resources in the network to guarantee the QoS (step 4). The

Figure 5.47

QoS architecture based on RAC [29].

344

Broadband Access Networks and Services

RAC replies with a success if there are sufficient resources or with a failure if there are not sufficient resources to guarantee the required QoS (steps 5, 6, 7). As such, policy control provides the means for handling a more predictable service delivery, a better use of the network resources, and a more defined control of QoS and other parameters (e.g., charging). In order to respond as quickly as possible to the services that need fast response times, relevant policies must be made available close to the point of inception of the service. This can be achieved by making them available at local policy repositories, in addition to central policy repositories. There are different types of policies that all need to be available at the time of inception, such as subscription policies, QoS policies, roaming policies, charging policies, and others. An access policy manager (APM) is used to automatically distribute the relevant policies to the appropriate network elements in the access network. In a roaming scenario, the APM also provides an interface that allows for dynamically receiving policies from other networks. It checks for race conditions or discrepancies in the policies, whenever a user from another network domain visits the network, by distributing the appropriate policies to the different local and central policy servers. Some of the functionality of the access policy manager can be separated into the following management submodules: external policy management (EPM), service policy management (SPM), network policy management (NPM), and user policy management (UPM). These functional management submodules are shown in Figure 5.48 for a nomadic scenario where the user traverses from a fixed home access network to a visited mobile network. Figure 5.48 shows the distribution of those submodules, which are part of the policy control framework, according to the different business roles identified in Section 5.3.1 for the broadband access network. The EPM is responsible for generating business-related policies and pushing them down to the correct policy decision points. In the case of roaming, the EPM is the policy management entity that is responsible for the exchange of policy information with another provider. The information will generally be retrieved for the first time when a user moves to a new visited network. The SPM creates and pushes service related policies to the proper policy enforcement points. The service policies among other service aspects include the overall business logic that is applied to the requests from the application servers and from a peer SPM. The most significant service policies include the service resource requirement policies, the QoS policies, and the nomadic policies. Service policies generated by an SPM are based on the policies of the SLA held by the EPM and depend on how the roaming policies are defined in the EPM. The NPM receives service policies from the service policy managers and maps them to network policies such as QoS class, resource access priorities, and so forth. It is also responsible for pushing the network policies to the enforcement points in the network. The NPM can create network policies either statically, where the existing policies are not changed, or dynamically, where the existing policies are changed to accommodate to a new situation with additional services or different characteristics. Dynamic creation of policies is especially relevant where the NPMs need to communicate with multiple SPMs. When supporting nomadic services, the NPM needs to be prepared to receive policies for “foreign” services, which may need spe-

5.3 Next Generation Broadband Access Platforms

Figure 5.48 [29].

345

Policy architecture in support of a nomadic user moving between roaming networks

cial handling. The UPM controls all end-user related policies, such as user identification, AAA, billing records, subscription-related QoS, and so forth. In addition to the management functional entities, there is a PDF in the control plane, which is responsible for the execution of the configured policies. The PDF checks service requests against service policies. If there is a match, it forwards the service requests to the RAC. If the service request does not match the agreed service policies, a denial is reported. 5.3.7

Quality of Experience

The QoE concept starts by first identifying the main applications, which are running over the broadband network. Then the corresponding end-user quality (this is basically what QoE stands for) should be identified, and finally, the mapping to quality parameters that are under the control of service and network providers (which are usually described as QoS parameters) should be specified. Some of the aspects to be considered when discussing QoE in general can be summarized as follows: • • •

Easy first-time service setup; Easy and fast service start and stop; Available when needed;

346

Broadband Access Networks and Services

• • • • • • •

Quality matching the expectations/needs; Responsiveness; Consistency; Security; Cost transparency; Reliable and comprehensible billing; Easy deinstallation of a service.

Reference [29] provided some network relevant aspects for QoE considerations for different applications. For example, for the video application, the main finding was that the performance monitoring is essential for the QoE supervision and the most important metric was identified as the number of lost packets. This led to further work on truncated packet inspection described in [29]. For best-effort Internet access, mainly the interactive applications need to be considered. Thereby the most important aspect is the delay experienced by the user. For gaming, the delay is also critical; thus a proposal for the maximum round trip delays for three different game types were made in [29]. For multimodal/multiparty applications, the additional problems occurring at network nodes where the traffic is multiplexed and demultiplexed are also important. In summary, a measurable QoE would allow feedback on the customer satisfaction. This goal is not easy to be reached, as different services will produce different QoS requirements to achieve a good QoE. As a reference, Table 5.1 summarizes the most critical QoS parameter per type of service. Network providers need to be aware of QoE during the installation of a service (and the underlying network), as well as during the run time of the service. 5.3.8

Fixed Mobile Convergence

Fixed mobile convergence (FMC) should bridge the gaps between fixed broadband networks and mobile networks. An architecture in support of FMC should be able to provide those bridges. One approach to the development of an FMC architecture [29] is based on an evolution from the fixed network architecture by adding mobile aspects. The following two steps can be distinguished: •

•

Adding functionality to the fixed network for the support of nomadism and session continuity; Using roaming with mobile networks for the support of nomadism between fixed and mobile networks.

Table 5.1

QoS Parameters Per Service [29]

VoIP

Low delay

Web browsing

Low packet loss

Gaming

Low delay

IPTV

Low packet loss

5.3 Next Generation Broadband Access Platforms

347

Among the many initiatives that address the convergence of fixed and mobile telecommunication networks, the FP6 IST project MUSE [2] specifically addressed the FMC from a fixed network point of view. Other research and standardization initiatives are taking an approach starting from the mobile network architecture, such as the 3GPP Service Architecture Evolution (SAE) [50]. The functionality developed in the SAE has been reused in the approach in [29]. However, there the SAE was not mapped onto the chosen business models due to a different decomposition of the business roles defined in 3GPP. The SAE functions are from 3GPP Release 8. In the FMC architecture shown in Figure 5.49, these Release 8 functions coexist with the 3GPP Release 6 architecture. A full FMC architecture should also include the WiMAX access networks. The WiMAX parts are not shown here for simplicity. In the development of the FMC architecture in Figure 5.49, the following aspects were considered: • •

• •

•

Data path connectivity (e.g., from NAP via RNP to NSP and so forth); Authentication and authorization (e.g., based on AAA proxies and AAA servers), using the general principles described in Section 5.3.6; IP address assignment (e.g. based on DHCP servers); Policy control and management in line with the overall QoS strategy (the architecture is based on User/Service/Network/External Policy Manager–UPM/SPM/NPM/EPM, and Service/Resource Controller–SC, RC); Specifically the external policy manager as an important addition to exchange policies for visiting users between network provider domains;

Figure 5.49

Node view of an FMC architecture with 3GPP release 6/8 network entities [29].

348

Broadband Access Networks and Services

•

Mobile IP for support of session continuity at the network layer (e.g., MIP Home Agent–HA). Session continuity at the application layer using SIP Refer or SIP Re-invite messages in combination with security functions in a B2BUA at the edge nodes.

5.3.8.1

Achieving Session Continuity in an FMC Architecture

Session continuity is an integral and necessary part of FMC and NGN, in general [38]. For interactive voice (“telephony”), it is a necessity. For other services, it is recommended to apply a careful techno-economical analysis to confirm the requirement [29]. 5.3.8.2

Mobility Mechanisms in 3GPP and WiMAX Architectures

The many competing Mobile IP (MIP) alternatives that appear in the 3GPP and WiMAX architectures are not fully supporting the success of MIP as a basis for session continuity and interworking between mobile networks and fixed and mobile networks. MIP has not really booked full success when it comes to actual widespread deployment in the fixed network domain [29]. MIP, however, has become popular in relation to the mobile network, and for an FMC architecture, this will increase the complexity of nodes, such as the PDN GW or the GGSN [41]. It should be avoided to look at another solution that does not make it from specification to actual deployment or that the solution will only work within the limited “islands” of the network. Reference [2] recommends the use of DS-MIPv6 and PMIPv6 in support of the FMC architecture shown in Figure 5.49. There are two main reasons for this choice, namely: •

•

The networking world is moving towards IPv6 (although the pace of change varies great among operators). An MIPv6 variant of MIP saves operators a cumbersome MIP migration on top of the already demanding IP migration. An MIPv6 variant requires that terminals (and HAs) are dual-stacked, but this does not introduce complications as many modern operating system (OS) implementations have dual stack support. DS-MIPv6 also allows for tighter integration with IPv6 (e.g., route optimization).

An issue with PMIPv4/v6 is how well it would work in practice with an “off-the-shelf” OS. On paper, PMIP looks simple and requires no functionality on the MS. However, most likely the OS (the socket implementation) must be modified to tolerate the activations/deactivations of the network interface cards (NICs) that will happen during mobility. 5.3.8.3

SIP-Based Mobility

The Session Initiation Protocol (SIP) has become the control protocol of choice that enables multimedia services [51]. It also provides some means of mobility manage-

5.3 Next Generation Broadband Access Platforms

349

ment. As an application layer solution, it allows mobility to be managed on top of the IP layer, across boundaries between networks that are possibly managed by different operators. SIP offers the following several advantages in terms of mobility: •

•

• •

• •

Facilitates mobility management across different operators’ networks (multiprovider environment); Is independent of the network access technology (support for heterogeneous access networks); Is independent of the IP version; Is already established protocol for conversational services and incorporated by both ETSI TISPAN and 3GPP; Supports all mobility types: personal, terminal, service, and session; Provides AAA functionalities: user/terminal identification and means to build the interface towards the AAA infrastructure of the operators.

Apart from the advantages listed above, SIP suffers from some shortcomings in the area of mobility management. These can be summarized as follows: •

•

Standard SIP session/terminal mobility methods (REFER and re-INVITE) are not able to provide continuous mobility. During the move to another IP address subnet, the SIP sessions (both signaling and data) are terminated because the underlying TCP/UDP socket addresses are no longer reachable. Due to the end-to-end nature of the SIP communications, the privacy of the moving session/terminal cannot be granted. Each time that a session/terminal changes IP address, this fact is signaled to the communication peer to redirect the user data traffic to the new destination.

In support of the FMC architecture in Figure 5.49, an extended SIP-based mobility management solution was developed to overcome issues derived from the standard SIP based mobility. The elaborated SIP-based mobility management solution does not require any new SIP method or a header to be defined, but proposes novel access network architecture and functionalities. It is based on the following two concepts [29]: •

•

IP soft handover allows for a seamless session transfer between the terminal as well as terminal mobility applying a make-before-break handover scheme. It provides network support to the make-before-break handover process utilizing P-CSCF (SIP Back-to-Back User Agent) and C-BGF functions as well as an RTP proxy and a conferencing module to allow for seamless handover controlled at the SIP layer. P-CSCF and C-BGF are sometimes combined into the SBC node. SBC daisy-chaining when the session/terminal moves from one network served by one SBC to another network served by different SBC, IP soft handover capable SBCs are daisy-chained to provide seamless handover during such move.

350

Broadband Access Networks and Services

A detailed description of the SIP-based mobility management solution for the FMC can be found in [32]. 5.3.8.4

Roaming

Roaming is an important aspect for the support of nomadism across administrative domains. In the simplest case roaming implies a session interrupt. This corresponds to a situation with roaming in legacy mobile networks. One of the reasons for session interruption for roaming is the complexity arising from the charging of existing sessions while moving across network boundaries. In case of roaming, the data path taken from the customer equipment through the visited network to the home service provider (i.e., the customer’s ASP) can follow different paths. Figure 5.50 shows the following two main options for fixed-to-mobile roaming: • •

Visited network routed roaming; Home network routed roaming.

The visited network routed roaming is also used for fixed-to-fixed roaming. Here, the data path typically follows a visited NAP, RNP, and NSP (abbreviated NAP-v, RNP-v, and NSP-v, respectively) and a visited CP (abbreviated CP-v) is involved for (part of) the authentication and authorization and for (part of) the policy management and control. In some cases (e.g., for QoS reasons) the home NSP (abbreviated NSP-h) may be involved, but this would require nonstandard IP routing (e.g., involving IPSec tunnels, or Mobile IP solutions). The home network routed data path is used specifically in mobile network architectures. In this case, the data path crosses from the visited network to the

Figure 5.50

Possible data paths in FMC roaming scenarios [29].

5.3 Next Generation Broadband Access Platforms

351

home network via the 3GPP GRX tunnels between the SGSN and the GGSN nodes. Mapping the home routed data path onto the MUSE unbundled fixed network can be viewed as if the crossover is done inside the NAP-v to the NAP-h. The analysis above shows that roaming requires the introduction of roaming agreements between the visited business roles and the home business roles. In mobile networks, such roaming agreements already exist, but the home and the visited networks are each operated by a single business entity. In fixed networks and perhaps in future fixed-mobile integrated networks, roaming agreements will involve multiple roles in the home network and multiple roles in the visited network. In theory, roaming agreements can be made between various parties in the home and visited network, such as between a CP-v and Packager-h, between an ASP and NAP-v, and so forth. Such an arrangement would require each party to have a multitude of types of roaming agreements in addition to the ordinary business relations already existing in their own network. A better approach seems to be the restriction of roaming agreements to parties of the same type. That is, roaming agreements need only to exist between the following entities: • • •

CP-v and CP-h; NSP-v and NSP-h; Packager-v and Packager-h.

Roaming agreements between NAP-v and NAP-h (and between RNP-v and RNP-v) are usually not needed, because each NAP (and RNP) has usually only local significance and the associated CP can take care of the required roaming agreements. This is shown in Figure 5.51. From the three types of roaming agreements mentioned above, the agreements between CP-v and CP-h and between NSP-v and NSP-h will occur most frequently.

Figure 5.51

Three types of roaming agreements in an FMC [29].

352

Broadband Access Networks and Services

Roaming agreements between Packager-h and Packager-v will occur only in special occasions when the standard roaming agreements between CPs and between NSPs are not sufficient. 5.3.9

The Residential Network and Gateway

The residential network is a network in the residential and SOHO environment (house, apartment building, small office). As introduced in Section 5.3.2, the global broadband communication system is based on an Ethernet and an IP environment. A border between the residential network and the public network at the U reference point is considered. Figure 5.52 shows an overview of a residential network for home users. Home users are using a number of devices, in the home or in its environment, which have communication facilities to the outside or to each other. Some devices are connected to the RGW via Ethernet compatible wireline [e.g., being an IEEE 802.3 Ethernet variant, powerline (UPA or HomePlug), or other] or wireless (e.g., Wi-Fi) to a physical access port in the RGW. Devices which are on the same cabling may communicate directly to each other, in the case when these do not need QoS. All wireless communication—local traffic needing QoS and all outside traffic—passes over the RGW. There is only one connection to the public NGN network via the WAN interface. The network border is at the U reference point, located at the user side of the access line. The bandwidth capability of the WAN line depends upon the access line technology and is a determining factor for the upper limit of downstream and upstream traffic. The home users are subscribed to a default connectivity provider, giving them access to Internet, IP-based services, other users in homes, users attached to hotspots, and even mobile users attached to mobile IP enable networks. The main functions of the multiplay RGW are the following: •

Termination of the access lines and of the internal lines and support of wireless access;

Figure 5.52

The residential network and gateway connected to an NGN [29].

5.3 Next Generation Broadband Access Platforms

• • • •

353

Transfer of flows, in-home, and between home and outside, supporting QoS; Control/signaling functions with regard to connectivity; Management functions for local and remote management; Enabling additional functions such as media storage support, FMC support, IMS support, and backup/restoration of management data.

A high level block diagram of the RGW is shown in Figure 5.53. The architecture is compliant with the PRM model and shows the data, control, and management flows, as well as the two communication stacks and the system (management) plane. The assembly of all these higher layer communications and handling in the RGW is called the RGW IP-Host. These are the functions of the RGW above the IP layer, and these are addressed via the IP addresses, by which the RGW is reached on the IP layer. Communication may happen from the LAN side via a private IP address, and/or from the WAN side via a public IP address. Below the IP host, there is the switching block. Within the IP host, there are data, control, and management termination functions, as well as interoperability functions. The IP host is also containing a number of enablers, related to higher layer functions. The RGW may contain a number of legacy interfaces (and appropriate adapters) such as FXO and FXS for voice communication.

Figure 5.53

High-level, multiplay RGW block diagram [29].

354

Broadband Access Networks and Services

The “switching” of data in the RGW may be performed on layer 2 (Ethernet bridging/switching) or on layer 3 (IP forwarding). QoS priority mechanisms, connection admission control, and bandwidth control mechanisms are foreseen in the RGW in order to control the QoS. A firewall is in place in order to avoid insecure flows. In combination with the IPv4 forwarding, an NA(P)T function is usually used for the translation between the RGW public IP address/port(s) into private IP address/port(s). Data flows through the RGW are in principle transparent (apart from the firewall control and possible data flow monitoring). In case the RGW contains service adapter functionalities (ATA, STB, …) some data flows are destined for the RGW itself. Data plane protocols on top of TCP/IP or UDPoIP are the HTTP(s), FTP, RTP, NTP, and so forth. Around the home, the residential users may be classified, based on the capabilities or profiles that are assigned to them. In the home there are the residents, which can be classified as adults and children. There are the visitors, which can be distinguished into the following types: the ones using the home broadband provider facilities, the ones using their own broadband provider facilities, and the travelers using the colocated hotspot capability if present in the RGW. Figure 5.54 shows the types and differences between them. The user types are recognized by dedicated access (e.g., SSID or port) or by local authentication to the RGW. The user types are mapped to device addresses and get a profile, defining how the communication requests/data will be treated. Three FMC cases are distinguished related to user types, namely: •

•

•

The restricted visitor: uses the default broadband connectivity of the home; as such for legal reasons, he or she is subject to parental control. The relocated user: uses a selected broadband connectivity (to fixed or mobile provider) and gets his or her own profile different from the home default one. The hotspot user: uses a selected broadband connectivity to a hotspot provider, and gets a minor QoS than the other users, because the main purpose is to fill up the unused bandwidth on the access line. By identifying the hotspot user (subscriber) through authentication with the network, he or she can also receive differentiated treatment in the network.

Figure 5.54

User types and FMC cases [29].

5.3 Next Generation Broadband Access Platforms

355

If there are conflicting settings in the RGW with regard to multiple providers controlling the same function (and QoS is for sure one of them), agreements are needed among the multiple providers in order to consolidate. In order to make the RGW data model multiprovider supported, a number of leveled management roles and permissions on the object or on the parameter level of the data model must be defined. The general principles of QoS and CAC as described previously are also valid in the residential network/gateway. However, some specific issues need to be taken into account. In the home environment other mechanisms have been defined for QoS management than in the public network (e.g., using UPnP QoS control). These home mechanisms have to interwork with the external mechanisms like IMS and ACS. For Wi-Fi, the WMM (Wi-Fi Multimedia) QoS can be applied. Interworking of the IMS-enabled RGW with the TISPAN IMS control in the IMS enabled public network is needed [52]. There is an interaction between the SIP B2BUA and the QoS control in the RGW. The QoS priority settings for hotspot users are either best effort, or at least less than the ones of the other basic users for the same service. In addition, there might be a maximum bandwidth consumption for hotspot traffic, both on the access line, and on a Wi-Fi access point, for hotspot traffic [29]. An IMS-enabled RGW is in principle supporting non-IMS enabled devices behind it. The communication with IMS enabled devices behind the RGW must be transparent over the RGW. For the non-IMS enabled devices [e.g., legacy devices and SIP (non-IMS) devices], the RGW acts as an IMS proxy to the network, showing one IMS identity (simultaneously), and as such one private user identity IMPI. Each non-IMS device gets a public user identity (IMPU). The IMS proxy functionality is in fact an IMS B2BUA, supporting SIP on the LAN side and SIP/IMS on the WAN side. The IMS/SIP handling function between the SIP UAs on both sides is interacting with the CAC, NAPT, and firewall functions as well as with dedicated IMS functions such as location and accounts database, configuration file, and mapping database. The development of a new broadband component and the integration of heterogeneous wireless networks is a must in order to achieve the vision for the so-called 4G network. The provision of the high bit rates (~1 Gbps) that could be envisioned of interest for the end user and easily provided with fixed optical connections still represents enormous challenges to the wireless community. FMC can provide the capability to offer a wide variety of IP services (mobile office, audio/videoconferencing, push2talk, and rich call), with a quality significantly better than today. Changing access technologies can require full connection, registration, and authentication on each access network followed by manual intervention to switch from one to the other. Even when the mobile device supports all access technologies, the data flow cannot be handed over seamlessly without the user being aware of the change. The solution is to connect mobile networks to the core network through IMS. IMS allows seamless handover between multiple access technologies and provides the

356

Broadband Access Networks and Services

necessary mobility and routing management. The core network sees the mobile network as another IP network and does not need to manage mobility, authentication, or security control as the user changes access technology. IMS uses the Session Initiation Protocol (SIP) to allow fast connection between mobile devices and the core network. Initial setup of data sessions in traditional wireless networks can take between 1 and 15 seconds compared with milliseconds in a fixed network.

5.4

Conclusions In many parts of the world mobile broadband services are now available at prices and speeds comparable to fixed broadband, and mobile broadband-enabled laptops are creating sharp increases in mobile traffic. Fixed Internet traffic is not about to migrate in volume to the spectrum-constrained mobile environment. Nonetheless, mobile data traffic may overtake mobile voice traffic as early as 2011, and much sooner in some countries. This will have a significant impact on the design, rollout, and operation of future mobile networks. Networks with greater capacity but lower costs per bit need to be deployed to handle the future demand for mobile broadband. An NGN is a packet-based network able to provide telecommunication services to users and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent of the underlying transport-related technologies. It enables unfettered access for users to networks and to competing service providers and services of their choice. It supports generalized mobility, which will allow consistent and ubiquitous provision of services to users. The current and future physical network technologies in fixed (e.g., xDSL, CATV, fiber) and wireless (e.g., GSM, EDGE, 3G, HSDPA, 4G, mobile WLAN, mobile WiMAX, satellite) technologies need to cope with this in a myriad of protocols and transmission media. The fixed transmission media of copper, power line, cable, fiber, and air continue to be there, with even more focusing on the optical fiber and the air interface for the purpose of sustainable growth rates and for the important aspect of mobility. The deployment of fiber will continue to get closer to the home/office bringing higher capacities by integrating optical technologies into the access and home networks. Traditional business models, especially in rural and remote areas, often do not support the needed investment. In addition, insufficient local content is available and too few people have training in the required technologies. To overcome these challenges, new approaches are needed, including innovative public-private partnerships, involving committed stakeholders working together towards a common goal. Convergence at the technical network level should be accompanied with an alignment of the business environments. The mobile value chain unbundling is found primarily at the level of mobile virtual network operators who resell and rebrand services from mobile infrastructure operators. In the fixed value chain, various types of unbundling are found at the network level.

5.4 Conclusions

357

The next steps for future research would be to pave the way for proactive operation of the networks in a holistic view. This is interpreted into enriching future networks with novel intelligence for improved adaptation to user needs and to the networking environment. This raises interesting challenges in terms of routing requirements, self-adaptability, self-awareness, self-healing, and robustness. Topics of special interest will become issues regarding the availability of resources, online adaptation in response to QoS needs, perceived performance of the different network infrastructure elements, instantaneous traffic loads, and the resulting economic costs.

References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16]

[17] [18] [19]

[20]

FP6 IST Projects, Broadband for All, http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project Multi Service Access Everywhere (MUSE), http://www.ist-muse.org. FP6 IST Project Photonic Integrated Extended Metro and Access Network (PIEMAN) http://www.ist-pieman.org/. FP6 IST Project Open Broadband Access Network (OBAN), http://www.telenor.no/fou/prosjekter/oban/. FP6 IST Project Infrastructures for Broadband Access in Wireless/Photonics (ISIS) http://www.ist-isis.org/. FP6 IST Project Paving the Optical Future with Affordable Lightning-fast Links (POF-ALL), at http://www.ist-pof-all.org/. FP6 IST Project Open PLC European Research Alliance (OPERA), http://www.ist-opera.org/. FP6 IST Project Broadband over Powerlines (POWERNET), http://www.ist-powernet.org/. FP6 IST Project Next Generation Optical Network for Broadband in Europe (NOBEL), at http://www.ist-nobel.org/. FP7 ICT Project FUTON, at http://www.ict-futon.eu/. CISCO White Paper, “Fiber to the Home Architectures,” www.ist-bread.org. FP6 IST Projects Cluster Report 2008, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm FP6 IST Project MUSE, Deliverable 2.3, “Optical Access Solutions,” January 2006, www.ist-muse.org. IEEE 802.1, http://www.ieee802.org/1/pages/802.1w.html. FP6 IST Project MUSE, Deliverable 2.7, “FWA over Long Optical Links,” March 2008, www.ist-muse.org. Ng’Oma, A., G.-J. Rijckenberg, and A. M. J. Koonen, “Building Extended Reach RoF Links by Exploiting the Optical Frequency Multiplication Dispersion Tolerance,” Proceedings of IEEE MTT-S International Microwave Symposium, Honolulu, HI, 2007. FP6 IST Project POWERNET, Deliverable 1.1, “Project Presentation,” December 2005, http://www.ist-powernet.org. FP6 IST Project POWERNET, Deliverable 4.2, “Report on Final Field Trials,” March 2008, http://www.ist-powernet.org. FP6 IST Project OPERA, “D33: New Business Models and Technical Feasibility with Wi-Fi, WiMAX, UWB, ZigBee, and Bluetooth,” December 2007, http://www.ist-opera.org/. Maucher, J., and J. Furrer, WiMAX, Heise Verlag, 2006.

358

Broadband Access Networks and Services [21] Commission of the European Communities, Commission Decision “On Allowing the Use of the Radio Spectrum for Equipment Using UWB Technology in a Harmonized Manner in the Community,” Brussels, Belgium, February 2007. [22] Yomogita, H., “Japan’s UWB Finally Takes Off with Upcoming UWB-Enabled Devices,” Nikkei Business Publications, August 2006. [23] http://www.fcc.gov/Bureaus/Engineering_Technology/News_Releases/2002/nret0203.html. [24] Lee, H., “200x Faster Than Bluetooth, UWB and 60GHz Wireless Communication Coming Year 2007,” ZDNet Korea, July 11, 2007; http://www.zdnet.co.kr. [25] FP6 IST Project MAGNET and MAGNET Beyond, http://www.ist-magnet.org. [26] http://www.wimedia.org. [27] http://www.uwbforum.org. [28] IEEE Standard 802.15.3: “Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for High Rate Wireless Personal Area Networks (WPANs),” September 2003. [29] FP6 IST Project MUSE, Deliverable D TF1.9, “Part A: GSB Access Network Architecture,” January 2008, www.ist-muse.org. [30] FP6 IST Project MUSE, White Paper, “MUSE Business Model in Broadband Access,” April 2007, www.ist-muse.org. [31] FP6 IST Project MUSE, Deliverable DTF1.9, “Part B—GSB Access Network Architecture, Additional Network Architecture Topics,” December 2007, www.ist-muse.org. [32] FP6 IST Project MUSE, Deliverable DTF1.8, “FMC Support in the Fixed Access Architecture,” June 2007, www.ist-muse.org. [33] FP6 IST Project MUSE, Deliverable DA4.4, “Network Architecture and Functional Specifications for the Multiservice Access and Edge,” November 2004, www.ist-muse.org. [34] International Telecommunication Union (ITU), “B-ISDN Protocol Reference Model and Its Application,” Recommendation I.321, 1991, Geneva, Switzerland, www.itu.org. [35] DSL Forum Working Text WT-144 (TR-058bis) “Broadband Multi-Service Architecture and Framework Requirements,” dsl2006.483.09, April 2007, www.ieee802.org/1/. [36] FP6 IST Project MUSE, Deliverable MUSE DB1.8, “Access Multiplexer: Design Specification,” June 2007, www.ist-muse.org. [37] FP6 IST Project MUSE, Deliverable DTF1.7, “Multimedia Support in the Access Architecture,” June 2007, www.ist-muse.org. [38] Next Generation Mobile Network (NGMN) Alliance, “Next Generation Mobile Networks Beyond HSPA and EVDO: A White Paper,” December 2006, www.ngmn.org. [39] European Telecommunications Standard Institute (ETSI), DTS/TISPAN-07013 v0.0.11 Telecoms and Internet Converged Services and Protocols for Advanced Networks (TISPAN), “NGN Lawful Interception; Lawful Interception Functional Entities, Information Flow and Reference Points,” www.etsi.org. [40] Third Generation Partnership Project (3GPP) TS 33.107 v7.3.0, “Lawful Interception Architecture and Functions (Release 7),” www.3gpp.org. [41] Third Generation Partnership Project (3GPP) TS 33.108 v7.6.0, “Handover Interface for Lawful Interception (Release 7),” www.3gpp.org. [42] IEEE Standard 802.1X, “LAN IEEE Standard for Local and Metropolitan Area Networks Standard for Port based Network Access Control,” 2004, www.ieee.org. [43] Ohba, Y., et al., “Protocol for Carrying Authentication for Network (PANA),” draft-ietfpana-pana-18, September 2007, ietf.org. [44] Pruss, R., et al., “Authentication Extensions for the Dynamic Host Configuration Protocol,” IETF draft-pruss-dhcp-auth-dsl-02, November 2007, ww.ietf.org. [45] Yang, L., P. Zerfos, and E. Sadot, “Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP),” RFC 4118, June 2005, www.ietf.org.

5.4 Conclusions

359

[46] Calhoun, P., M. Montemurro, and D. Stanley, “CAPWAP Protocol Specification”, draft-ietf-capwap-protocol-specification-07, June 2007, www.ietf.org. [47] Calhoun, P., M. Montemurro, and D. Stanley, “CAPWAP Protocol Binding for IEEE 802.11”, draft-ietf-capwap-protocol-binding-ieee80211-04, June 2007, www.ietf.org. [48] IEEE Standard 802.1AE, “IEEE Standard for Local and Metropolitan Area Networks—Media Access Control (MAC) Security,” 2006, www.ieee.org. [49] IEEE Draft Standard, “Local and Metropolitan Area Networks—Port-Based Network Access Control—Amendment 1: Authenticated Key Agreement for Media Access Control (MAC) Security,” www.ieee.org. [50] Long Term and Service Architecture Evolution, http://www.3gpp.org/Highlights/LTE/LTE.htm. [51] Session Initiation Protocol (SIP), at www.ietf.org/rfc/rfc3261.txt. [52] FP6 IST Project MUSE, Deliverable DTF3.3, “Parts 1 and 2—Specification of an Advanced, Flexible, Multi-Service Residential Gateway,” December 2006, www.ist-muse.org.

CHAPTER 6

Services and Service Platforms The success of next generation networks depends on appropriate service infrastructures supporting secure, personalized, and ubiquitous services. The rapid development of the Internet, both in speed and in capabilities, is an enabler of new and innovative market of services and provides a new experience to the users. The convergence of services is another trend observed in parallel with the trend of convergence of technologies and networks. The challenges of service delivery that providers and creators face are how to enable the capability to offer a wide variety of IP services (mobile office, audio/videoconferencing, push2talk, and rich call), with the required quality for each of the delivered services. It is becoming widely accepted that the integration of heterogeneous access infrastructures, possibly distributed among different administrative domains, will be the key to cope with these needs, as it is cheaper than realizing a global coverage based on a single technology and has the potential of improving the overall user experience. A converged global network faces the challenges of resource efficiency and service flexibility and interoperability issues, where the service integration, authentication, privacy, and security are important service enablers. Furthermore, converged services require a global and open service delivery platform that supports interoperability and security [1]. This chapter describes the research and development activities and resulting achievements of the European (EU)-funded projects under the Framework Program 6 (FP6) in the area of services, service enablers, and service platforms. The activities spanned the definition, creation, and delivery of services, and the provision of environments supporting their execution [2, 3]. The FP6 IST project DAIDALOS [4] performed the provision and evaluation of a pervasive service platform that incorporated enabling services offering security, privacy, personalization, context-awareness, and service management capabilities to mobile user services deployed on the related network and service infrastructures. The FP6 IST project SPICE [5] defined a reference architectural framework for an open service platform, comprising a reference model and a functional architecture. A unique feature of the framework developed by SPICE was the balance between tight and loose integration with the IP Multimedia Subsystem (IMS). The FP6 IST Project PLASTIC [6] developed a conceptual model for Beyond 3G (B3G) services enabled by an environment for context-aware, component-based mobile services, and leveraging middleware. The FP6 project OPUCE [2] proposed a service

361

362

Services and Service Platforms

life-cycle manager that could let nonexpert end users control the whole life cycle of a service, from creation to withdrawal. The FP6 project E2R [3] defined a cognitive service provision building block as part of the E2R system architecture [7]. Such a module consisted of the content and service adaptation function and the reconfiguration services discovery function. In this direction, specific support protocols and mechanisms were specified for multimedia adaptation and cognitive service provision and discovery. The FP6 project Ambient Networks [8] developed service aware transport overlays (SATO) that offer an that offer an abstraction to service developers that makes it easy to instantly create adaptive and optimized content delivery networks. The FP6 project MAGNET and MAGNET Beyond [9] developed and implemented a service platform for the provision of secure and personalized services via wireless personal area networks (WPANs). The FP6 Project C-MOBILE [10] focused on the provision of broadcast and multicast services. In summary, the FP6 IST work on services and service platforms managed to unite the areas of information technology (IT) and telecommunication to fulfill the vision of the mobile information society (IST). This chapter is organized as follows. Section 6.1 introduces into the main challenges and aspects of service provision for next generation mobile systems. Section 6.2 describes service architectures intended for pervasive services and platforms for personalized service provision across heterogeneous technologies. Mechanisms such as service discovery, context-aware composition, security, and privacy are discussed. Section 6.3 focuses on service provision through personal networks and personal network federations. The interactions between different modules, the role of security and privacy, and integration with the IP multimedia system (IMS) are described. Section 6.4 concludes the chapter.

6.1

Introduction Over the last decade the services sector has become the biggest and fastest-growing business sector in the world [11]. For this growth to continue, the European Commission recommended that services should be more widely and easily available and ways should be sought for yielding higher productivity. Research in the mobile service platform area under the FP6 program contributed to realize the vision of “Optimally Connected Anywhere, Anytime” for end users and a consolidated approach to serving mobile users with appropriate enablers for applications and services [2]. The service delivery platform, in support of the above user connectivity vision, goes beyond the client-server model of service delivery in order to support rich mechanisms of global service supply, where third parties have the capability to aggregate services, act as intermediaries for service delivery, and provide innovative new channels for consuming services. This reflects the future requirements of the mainstream enterprise service communities and the globalization of these enterprise services [1]. Such a platform will need to build upon and extend the Web 2.0 concepts to allow for community-driven service innovation and engineering on a large scale, providing global repositories for value-added services (VAS), and semantic support

6.1 Introduction

363

to enable the automatic on-the-fly composition of VAS. The above will enhance the reusability of services and would allow for reasoning to derive some further knowledge. Figure 6.1 shows the model for a global service delivery platform for future Internet services. In order to enable seamless service delivery during user mobility, services have to be supported by an underlying infrastructure that allows them to coordinate with each other. This has introduced the concept of pervasive environments. One important aspect of pervasive environments is to provide users with the ability to freely move about and continue the interaction with the applications in use through a variety of interactive devices with different interaction resources (i.e., cell phones, PDAs, desktop computers, digital television sets, intelligent watches, and so on) and communication channels with different characteristics and performance (i.e., WiFi, Bluetooth, sensor networks, UMTS). In this regard, there has been a recent increase in interest in migratory interactive services [13]. Such services provide users with the ability to change the interaction device and still continue their tasks through an interface adapted to the new platform. In some cases, migration can be used to improve the user’s experience by switching to a better suited devices (e.g., bigger screen, more graphical power) or to a more efficient communication channel/a communication channel that can guarantee better QoS (shorter delays, higher bandwidth). Service migration is a main concept here. Service migration can involve devices belonging to different platforms. The concept of a platform is used to group those devices that have similar interaction resources (e.g., the graphical desktop, the graphical PDA, the vocal device, the digital TV). 6.1.1

Pervasive Service Platform

Implementing global pervasiveness poses real challenges to the conventional operator business because it is primarily about open markets, competition, and superior

Figure 6.1

Global service delivery platform of the future Internet [12].

364

Services and Service Platforms

user experience [14]. Each of these aspects requires a complete rethinking of not only the business models, but also, as a consequence, the technology assets of operators. Important challenges are the support of cooperation among service and resource providers, the privacy and trust, and the application of context information and user preferences in order to support a higher degree of user experience across a global service landscape. Some of the major research questions are the following: •

•

•

•

•

•

•

Service management must answer the question of how mobility of different types (terminal, user, session, service) can be combined in order to provide the ubiquitous access to services to which a user subscribes or wishes to subscribe. Service discovery and composition are a way to discover and combine services and resources from different providers and operators and to be into services that are more meaningful for users. Run-time environments must meet the heterogeneity and dynamism of composed mobile and embedded services. Context management is a mechanism for collecting and providing context information related to users and their environments to those who wish to consume this information. The type of information and the QoS are very important for context management. Management of context information can be used to trigger and support the migration procedure; this context includes user and device information, network/connectivity information, and service level information, namely, the presence and capabilities of certain application parts on different end systems [13]. Privacy and security of customers must be protected in a heterogeneous service landscape, where using third-party services is a frequent handling. Privacy and personalization in the context of the concept of virtual identities pose the challenge of how to help protect the privacy and at the same time enable access to personalized services and information. Learning can allow for removing the burden of configuring services from the user by automatically or semiautomatically learning about the user’s behavior.

Figure 6.2 shows a multimedia service provisioning platform (MMSP) proposed by the FP6 IST project DAIDALOS for the delivery of SIP-based context-aware real-time multimedia services with quality of service (QoS) and authentication, authorization, and accounting (AAA) auditing and charging (A4C) support. The MMSP elements can be classified into the following functional groups: •

The session control elements constitute the core of the MMSPP signaling layer. This element group is composed of two different types of SIP proxy/server entities in charge of the call routing and session control, each of them focusing on the following different aspects: • The MMSP Proxy (MMSP-P) is the entry point to the MMSP for subscribers, as it is in charge of handling all the requests to/from users and forwarding them as required. It also performs security and authentication functions, signaling validation, signaling compression, and resource autho-

6.1 Introduction

Figure 6.2

•

•

•

365

Multimedia service platform and its subsystems [12].

rization and QoS management in the access network by interacting with the QoS subsystem. • The MMSP Broker (MMSP-B) is the central node of the MMSP session control framework. It behaves as a stateful SIP proxy/server providing registrar, authentication, and session control features. The MMSP-B is always located in the operator’s home network, and it constitutes the central control point for operator-provided services. It also constitutes the entry point to an MMSP administrative domain for foreign MMSP networks. It provides call routing features, and it may also optionally implement topology-hiding capabilities by encrypting those parts of the SIP messages, which contain sensitive information about the inbound domain. The database elements are tightly coupled with the control layer. This element group is mainly based on the home subscriber server (HSS) and its different database views. This server holds the user-related information such as profiles, subscription data, logical location, and security information. The multimedia user equipment is based on the MMSP user agent (MMSP-UA), which is an enhanced SIP UA and a multimedia (e.g., RTP) client. The service elements are intended for the service hosting and execution within the MMSP. The core element of the native service provisioning is the SIP-application server (AS), which can take the role of a SIP proxy, UA, or B2B-UA. The MMSP-B, upon a correct match of a service trigger, will forward the SIP request to an appropriate AS, which will in turn perform the associated service logic. The ASs are actually external components, which can

366

Services and Service Platforms

•

•

•

•

•

be developed, operated, and managed by third parties. The MMSP provides certain native ASs for the provision of the following basic multimedia services [13]: • A streaming server (SS): The SS is a native application server, which takes the SIP UAS role for the delivery of on-demand multimedia streaming content. • A conferencing server (CS): The CS is a native application server, which takes the SIP UAS/UAC role for the provision of centralized group of communication services. The media processing elements are known as content adaptation nodes (CANs) and are application-level media adaptors applicable for the provisioning of advanced multimedia services (e.g., transcoding, filtering, and mixing). These are composed of a control part, located in the signaling layer, and a media processing engine, which is a part of the media plane. The service discovery elements allow the dynamic location of multimedia services and network resources. This element group is based on the following entities, according to the client/server model: • The service discovery server (SDS) is a central repository in charge of storing all the MMSP service-related information. • The service discovery client (SDC) allows for registering the multimedia services at the SDS and for querying the SDS for services matching certain selection criteria. The location elements allow the end systems to determine their physical positioning. This element group is based on the following entities, according to the client/server model: The location server (LS) is a core-network entity in charge of providing the location services and for storing the user positioning information. The location client (LC) allows the end systems for determining their physical positioning thanks to the services provided by the LS.

6.1.1.1

Network Context Provisioning, Discovery, and Awareness

Presence and location are two of the most important areas regarding context provisioning by the network. A service discovery architecture (SDA) must support a number of innovative ways to the perform service discovery. The following service discovery types can be summarized: •

•

Multiprotocol service discovery is based on a set of Application Program Interfaces (APIs), that allow for the possibility to perform service discovery using all service discovery protocols, with which these APIs are implemented (e.g., Bluetooth, SLP, UPnP, Knopflerfish’s service discovery); The ontology-based service discovery is based on ontologies (e.g., OWL/OWL-S based) that enhance the capabilities of the service descriptions, resulting in the possibility to produce more complex queries on the service

6.1 Introduction

367

descriptions, which help the user to find the services corresponding to his/her requirements. 6.1.1.2

Service Architecture for Location Dependent Information

Figure 6.3 shows an open architecture for accessing and managing of the location-dependent information available via the user terminal (UT). The architecture in Figure 6.3 can lead to a generic purpose platform equipped with the basic required functionality and open APIs, thus enabling maximum flexibility in the definition and deployment of new context-aware services to match the increased user needs. Such a system can run in parallel to all available access networks via suitable interfaces, but this poses a requirement for support of the heterogeneity to be ensured by the architecture. Therefore, the goal is to identify an open platform based on open technologies, guaranteeing interoperability with a variety of access networks and technologies. A functional reference model is shown in Figure 6.4. This model introduces a three-layer architecture comprising the monitoring layer, the service enabling layer, and the underlying monitored objects layer. The monitored objects layer consists of objects which can be monitored by the system [e.g., several radio access technology (RAT) modules, user equipment (UE), hardware modules, UE software modules, external (e.g., USB, Bluetooth) devices, and any sensors integrated or attached to the UE]. The monitoring layer consists of two sublayers, namely, the monitoring enabling sublayer, which is responsible for all the monitoring functionality (it is

Figure 6.3 [16].

High-level architecture for accessing and managing of location-dependent information

368

Services and Service Platforms

Figure 6.4

Functional reference model for support of heterogeneity of services [16].

radio-access and terminal technology dependent), and the monitoring integration sublayer, which aggregates the monitoring information and forwards it to the various functional entities of the service enabling layer via the appropriate interfaces. The monitoring enabling sublayer supports monitoring functionality based on certain rules (e.g., sampling periods, range of measurements, and averaging window), which can be modified depending on the target application. The following tasks are supported: •

•

• •

Monitoring of the various performance indices of each radio access network (RAN) of the heterogeneous environment to which the UT is attached; Monitoring of the performance of the UT and its applications as well as other indices related to the UT behavior (e.g., faults, device status information, settings); Monitoring of position related information; Monitoring of data collected from other sources connected to the terminal (e.g., sensors and external devices connected through short-range interfaces).

The monitoring integration sublayer is responsible for collecting and preprocessing the monitored information, temporary storing of information based on application requirements and terminal storage capabilities, and finally forwarding of properly pre-processed information to the service enabling layer either on a scheduled basis or on demand. The service enabling layer exploits the information provided by the monitoring layer so as to enable the implementation of various applications. Examples of main service enabling modules are the end-to-end user experience monitoring, ubiquitous terminal assisted positioning, and anonymous mobile community services [17]. In the case when a new application cannot be implemented based on these three enablers, a new one can be designed and integrated to the system, which is one of the advantages of the proposed architecture. The functional reference model of Figure 6.4 can be split into two main functional domains: the terminal and the network domains [16]. 6.1.2

Middleware

A component-based middleware layer is required for the interworking of the components of a service platform [2].

6.1 Introduction

369

Future mobile services must operate seamlessly in a heterogeneous communication environment. To achieve this flexibility, both the services and the operating platforms will need to be set up, taking into account contextual changes and making adaptation decisions in an autonomous fashion, yet controlled by the end user or by the operator via rules [18]. The introduction of semantically annotated Web services and semantic knowledge management middleware can serve as the basis for automatic service compositions and creation of autonomic processes. The introduction of autonomic aspects [19] in service-oriented architectures (SOA) is the key to minimizing human intervention, thus reducing management complexity [18]. Autonomic communication systems are adaptive networks, governed by human specified goals and constraints on the network services behavior. Reconfiguration provides the necessary mechanisms to facilitate the service adaptation, by utilizing service-specific knowledge that may be required. Monitoring, processing, and inferring context information are also part of the attributes of mobile networks. To enable rapid development of context-aware services, context information has to be retrieved from the environment, modeled, processed, and distributed to these services [20]. Figure 6.5 shows a service architecture developed by the FP6 IST project MIDAS [21], for the rapid deployment of services on heterogeneous network infra-

Figure 6.5

The role of middleware in the service architecture [18].

370

Services and Service Platforms

structures. At the core of it is the design and development of middleware for the management and the distribution of information in the infrastructure-based and infrastructure-less communications networks. Furthermore, the middleware component supports the deployment of the applications in these networks. The middleware includes modules for the establishment and management of the connectivity using the heterogeneous networks, for the distributed data sharing in unreliable networks [22], for the generation of synthesized context data [20], and for the context-based routing of the messages. A domain as shown in Figure 6.5 is a type of event for which a mobile service is to be implemented (e.g., an emergency event). A domain has a definite purpose with well-defined activities, roles, and event “rules.” A service is designed to contribute to achieving the business or operational goal of the particular domain and is realized by a set of cooperating applications (e.g., for service A, Appl-A1, and Appl-A2; see Figure 6.5). Each application has a distinct purpose within the overall mobile service. For example, for the emergency event example of the domain, there might be one application to be used for reporting on the status of the emergency and for receiving instructions from the emergency coordinator, and another application for use by the accident coordinators in a control room to gather and synthesize reports from the staff on site and to send instructions to them. Applications within a given mobile service are designed to work together and are developed independently of the applications making up another mobile service [18]. There is one standardized domain model per domain, which is defined in the form of an ontology.

Figure 6.6

Example of a context model [21].

6.1 Introduction

371

The context model ontology is defined and developed by the domain responsible (helped by some chosen ontology expert). The domain context model specifies a vocabulary for a domain. It includes terms of the vocabulary, the meanings of the terms, and relationships among them. Figure 6.6 shows an example of a context model. The terms and their relationships are specified formally, while the meanings are provided as human-readable definitions, so that the programmers can understand them. The main advantage of having a domain context model is that the mobile service developer can express statements about the context at a high level of the abstraction, using the domain-specific terms. The term relationships allow for deriving a new statement about the context from the existing ones. A second advantage is that the model is common to all services within that domain, which means that data modeled according to the model is shared between the different service creators (i.e., they can share or access the same data). For a given domain, there can be several (possibly competing) service creators, providing mobile services to which end users can, independently, subscribe. Each service is developed according to the domain context model and in this way ensures that the application interoperability across services can be provided when needed, using the context information. For example, a service could be produced, in which multiple applications would be developed to handle multiple types of sensors to provide accurate information about the weather conditions at different locations (e.g., realized by Appl-A1 and Appl-A2 in Figure 6.5). Other services (e.g., realized by Appl-B1 and Appl-B2) could rely on the context information provided by this service, knowing in advance that they can refer to context items, such as the temperature or the humidity in a standardized way. A service might also develop its own specific operators (e.g., “Service A-specific operators”; see Figure 6.5). A context operator functions as a plug-in to an application and gives the applications greater freedom in forming context queries. The specific operator produces new context information based on the existing context information (defined by the domain model). A service might specify many different context operators. In addition to context operators, a service creator should define the service-specific data of the service. The service-specific data is the data that is unique to the service. The schema describes in detail the structure and the content of the data, in the form of table definitions, which allows different applications belonging to a service (e.g., Appl-A1and Appl-A2 in Figure 6.5) to work with the same data and ensure the same semantic understanding [18]. The main players and processes of the mobile service delivery enabled by the platform of Figure 6.5 are shown in Figure 6.7. The middleware platform operates a self-discovering context-aware network where machine and user devices join, interact, and leave the network. The middleware is independent of any specific mobile service or domain and can support several applications simultaneously, possibly belonging to different services. Customization is done by importing a specific domain context model. If a user wants to take part in a service that belongs to a different domain, the (new) domain’s context model must be installed and the middleware be restarted.

372

Services and Service Platforms

Figure 6.7

6.1.3

People, equipment, and activities involved in mobile service provision [21].

Business Impact

Pervasive computing represents a high level of fragmentation in the business models of operators. Providers of the building blocks enabling pervasive computing are usually different business units. A fully open access model where all information can be accessed by any service might be difficult to accomplish from point of view of the business players. In this context the concept of federation [4] can be valuable from a business point of view. Federation as proposed in [14] and among service discovery providers can allow customers access to services registered in foreign registries, such as more specialized registries or company-internal registries. Such an approach requires the implementation of federation mechanisms that allow for sharing of discovery queries and lists of discovered services. In order to provide a service with a holistic view of a user’s context, context information from different networks and sensors is needed. Some operators can provide very few context pieces (e.g., GSM location), while more specialized context providers can provide other needed information (e.g., operators of specialized sensor networks). This requires that context management implements mechanisms for the federation of context information and maybe also fine-grained control of access to context attributes. Network resources such as bandwidth and devices can in many cases be provided by different operators. Moreover, these resources might be combined within the same composed service. A run-time environment that makes use of, for example, public devices and online services has to take into account the interaction with the operators of such devices. Federation mechanisms need to be implemented for allowing the sharing of run-time-related information, such as session information and information about the status of different services, and policy information for how to use various resources.

6.1 Introduction

373

The sharing of private data with third parties needs to happen as an integrated part of the federation mechanisms. The mechanism of federation might involve many operators/owners within the same session and make it dynamically changing. Learning is dependent on information about the user’s actions when using services. When using third-party services or enablers provided by different operators, this information needs to be collected through the process of federation. Additionally, the evaluation of the user preferences depends on the context data, possibly provided by the different context providers. Composed services include services and enablers from different operators. The execution of such composed services requires federation mechanisms that communicate varying information about service level agreements (SLAs) and policy requirements, for example. Service composition and session management need to implement mechanisms for allowing the communication of the necessary information within federated composed services. Figure 6.8 shows an architecture where the final user may have subscribed to services from different types of operators across a constellation of platforms [14]. These operators may have various types of commercial relationships between them, sharing different types of information (potentially even about the final user) reflecting the varying degrees of federation potentially existing between operators. The overall control flow and end-user service capabilities can be quite different, but the final user may be satisfied by several approaches depending on the defined business scenarios. In a next generation service delivery scenario, the convergence between different communication technologies is a main characteristic. It implies that regulatory aspects need to be addressed when developing service platforms for next generation systems. For example, the regulatory issues affecting next generation systems and the convergence of telecoms and broadcasting still suffer from many inconsistencies [14]. In many cases in Europe, the issues are not directly between telecoms and

Figure 6.8

Operator-user relationships and federation [14].

374

Services and Service Platforms

broadcasting but more in between, for example, telecoms and cable operators where rules have constrained what one or the other can or cannot do. Inconsistent regulation may actually be restricting innovation in some of the market sectors and impede the adoption of the modern technologies. A stable and predictable regulatory environment can encourage investor confidence in the services industry sector and encourage start-ups and competition. No business plan can be convincing in this domain if new regulations are likely to change and restrict the business potential of the market players [14].

6.2

Architectural Concepts for Pervasive Services Platform There are five concepts that were identified as essential for a pervasive service platform [14]. These are the mobility, A4C, resource management, QoS, and security (MARQS) concept, the virtual identity concept (VID), the ubiquitous and seamless pervasiveness (USP) concept, the seamless integration of broadcast (SIB), and the federation concept. Pervasive computing is the paradigm of computing everywhere, enabled by ubiquitous access to communication technologies and services. The FP6 IST project DAIDALOS [4] realized the concept of global or universal pervasiveness, enabled through, designed, and developed within the project as trustworthy, secure, and dependable infrastructure. Such an infrastructure is needed to foster an open market for pervasive and user-friendly services [14]. The key concepts of VID and federation have a great impact on how the pervasive services platform is refined and structured. The federation concept leads to a higher level of modularity in the platform and the adoption of a SOA. The concepts of the SOA Entity and the Administrative Domains are two main concepts related to federation. The VID concept can be integrated into the core of the platform by requiring a VID to exchange dialogue between all the components in the architecture. The MARQS concept is important for the integration of network and mobility resources as sources and consumers of context information. Additionally, service management (e.g., service discovery and composition) can be extended to include mobility-related resources. USP is core to the service architecture. In addition to the five key concepts, the pervasive service platform is composed of several architectural building blocks, namely: • • • • • •

6.2.1

Service discovery; Service composition; Session management; Personalization; Context management; Security and privacy. Pervasive Service Management

A pervasive services architecture is characterized by a core of service and identity management [23]. Dealing with services means that networked components are

6.2 Architectural Concepts for Pervasive Services Platform

375

deployed on a network node and that there is a network-reachable interface to their functionality. All services can be described in the form of compositions; the basic case is a composition of 1, or an atomic service. The industry standard OWL-S language can be used for the definition of these compositions. An application described by OWL-S is a collection of services and the specific dependencies among these services. OWL-S provides a comprehensive set of dependency types. Applying logic that takes into consideration that various types of dependencies found in a typical OWL-S file are not in the architectural issues and relate more to the implementation of applications or specialized workflow management type platforms. A number of innovative elements can be added to the composition and resource management process [23]. Figure 6.9 shows the components of a pervasive service management architecture. A composition template as described in an OWL-S file provides some information about the functional pieces constituting the given application. Once this information is parsed and understood by the composition manager, a composition plan is created by finding service instances that match the composition requirements. This composition plan is passed to the session manager, which creates a session plan based on this. A session plan is created with pointers to specific resource/service instances, VIDs to be used when accessing these instances, QoS parameters to be used with these instances, and so forth. Such a session is then deployed using the deployment management process [24]. During this process, the network resource management

Figure 6.9

Components of an architecture for pervasive services management [23].

376

Services and Service Platforms

interfaces are contacted in order to start the various communication sessions, reserve network resources, and so forth. Additionally, services are deployed across the newly reserved network. Services might be deployed completely (e.g., if these did not exist before) or might be only initialized using the correct credentials and preferences (e.g., if these already existed but were used by other people). During the deployment process, various policies (such as user or operator policies) can be applied in addition to the specific preferences. Once the session is deployed, the deployment infrastructure is responsible for monitoring and fixing of the errors/changes in the running sessions. A session might change because of many reasons, such as a context shift (e.g., a user moving from one room to another), thereby rendering a service (e.g., a display on the wall, obsolete in the new room). Sessions might also need reconfigurations due to errors (e.g., a service crashing). When a session needs reconfiguration because of one of the above reasons, the deployment management infrastructure will do one of the following depending on the specific situation: (1) try to fix it dynamically (e.g., by restarting the services), or (2) invoke a recomposition process by notifying the service composition. In the latter case, a new session will be created using new, healthy services. Recovering to the state before the crash or change is supported by the deployment infrastructure by allowing the services to store their latest state information regularly. The session concept is generic and can specialize in different directions. For example, a specific session might know how to control and monitor a multimedia session initiated and run by the MMSP infrastructure (see Section 6.1.1). Another session might specialize in Web service type of services or broadcast services. Multimedia and broadcast sessions can also be integrated. Eventually, a session of the pervasive service management can act as an overlay coordinating session that will allow mixing the different types of resources in innovative ways [23]. 6.2.1.1

Service Discovery

Service discovery is the act of looking for services. Service discovery relies on the service instance, which is responsible for creating a “service advertisement,” to provide information about a service, its context, and the requirements. The service advertisement contains a basic description of a service (in the form of attribute-values pairs recorded in a service discovery server), a full description of a service (in the form of an OWL/OWL-S file recorded in the ontology manager), and some contextual information (recorded in the context manager). For a service to be visible to the service discovery framework, it can register the basic service advertisement into a service discovery service that advertises its presence to the rest of the world whenever a service discovery action is done by an end user. In this case, capability, status, and availability of the service are provided on request. The service discovery is then able to provide the following two related functionalities: •

Service registration and deregistration. Each of these takes the service advertisement and passes it to the real service discovery modules, which are service

6.2 Architectural Concepts for Pervasive Services Platform

•

377

discovery protocol specific. Interaction with a service registry is optional, as some service discovery protocols operate without a service registry. Service advertisement retrieval. This takes an interface on which to report results and a query string to limit the number of services found. This request is passed to the real discovery modules. The filtering of services can be done as a separate step, to permit the filtering on the service discovery modules that do not directly support complex filtering. The results of the semantic filtering are passed to the requestor-supplied interface. This allows for further (client-defined) ranking and selection processes to be applied to the results of the discovery process.

In addition, some network components (such as access routers) are able to act as service announcement proxies, taking requests to announce a (user-) service periodically (e.g., over a broadcast channel of the air interface) without further communication on the core network. Service discovery support should include heterogeneous service discovery architectures with specific support for the user authentication and ciphering of information and using VID as the key to personalized service discovery, thus addressing the AAA and the security aspects. One of the main challenges in service discovery is to allow integration and interoperability of the different service discovery architectures from the point of view of the service ontology. This allows for mobility between the device and the service implementations and allows for the resource management of services and devices. Mobility is supported through the location and general context enabling of the service discovery process. Service composition and recomposition are the process through which a composition template is taken and the set of services types, which can be used to fill out the composition template, are identified. Many of the five key concepts listed in the beginning of this section are relevant to the service composition. The (re)composition process is a key part of the resource management as it allows for selecting, through service ranking, of the optimum resources (device and services) to be used in order to address the users requirements. Mobility is relevant as both user and service location are a key factor in triggering the recomposition of services, while QoS, a low level of which will also trigger recomposition and which may be a criteria in service ranking, is another important issue. 6.2.1.2

Security and Privacy Management

Privacy-enabled composition can be enabled by a VID infrastructure, where the users and service providers are represented as virtual identities to each other, and any exchange of sensitive information among the parts of a composition and the subsequent session is controlled by rigorous security and privacy management. Extensive personalization can be applied at different points during the service composition process. The composition process, during its search for services to be composed, uses a preference management infrastructure [24] to filter out and rank the discovered services. Additionally, each service in a composition, after having been selected and deployed, can use preference management to fetch context-defined preference outcomes for the user. A novelty of personalization is the application of dynamic context information to the outcome of the preferences.

378

Services and Service Platforms

6.2.1.3

Context-Aware Composition

In addition to allowing the preference outcomes to be defined by the particular context a user is in, context-aware composition is enabled by allowing the service discovery process performed during the composition to use the context information for targeted discovery. For example, for physical services (such as printers) this means that services in the greatest proximity to the user will be discovered rather than services far away. Additionally, services constituting a deployed composition will have the possibility to use context information directly. 6.2.1.4

Ontology-Enabled Composition

A service ontology manager allows for defining the OWL-based descriptions of the services that constitute a specific domain. The discovery and composition processes use this service ontology to guarantee interoperability among the differently composed services. 6.2.2

Personalization and Learning System

The personalization and learning system aims to maintain and apply user preferences to tailor the pervasive environment and all relevant components thereof in order to meet the individual users’ current needs. Figure 6.10 shows the component view of the personalization and learning system including the various interfaces between the components. The preference manager has a passive role in the architecture and it never initiates events. Instead, the preference manager acts upon receiving requests from other components or services. It provides two major functions. The first is to store and retrieve the user preferences, and the second is to evaluate the preferences and the current context of the user and return the desired outcome. The preference condition monitor (PCM) continually monitors the context for changes, which may alter the preference outcomes of the currently running services. The PCM maintains a list of context changes that affect the preference outcomes for the currently running services and when an important context change occurs the PCM notifies the preference manager to reevaluate the preferences related to the currently running services. The reevaluated preference outcomes are then communicated to the appropriate services via the PCM. The preference GUI allows the user to create new preferences and view, edit, or delete the existing ones. The presence of a graphical user interface, through which the user can modify his or her preferences, is essential to allow to the users greater control over their preferences, which in essence is personalization. The preference GUI is invoked through the service whose preferences the user wants to change. The service will supply the preference GUI with its service identifiers and the preference GUI will request the preferences on behalf of the service. The personalization ontology manager provides a single point of access for any information model needed by the other personalization components. In particular, the preference GUI strongly relies on these models to guide the user when he or she creates his or her own preferences. Four different models were devised for the architecture in Figure 6.10 and the personalization ontology manager interfaces provide

6.2 Architectural Concepts for Pervasive Services Platform

379

ID Top Level Components Diagram ActionHandlerIF

PCMIF

PCMIF

LearningManagerIF

<<use>>

FeedbackGUIIF

LearningManagerIF <<use>>

LearningManagerIF

<<use>>

OsgiServiceRegistry

PreferenceManagerIF

AdvQuerylfc

AdvQuerylfc

PreferenceManagerIF

PreferenceGUIIF PreferenceManagerIF <<use>>

<<use>>

PersonalizationOntologyManagerIF <<use>> <<use>>

ContextMgtIF AdvQuerylfcOsgiServiceRegistry

Figure 6.10

Personalization and learning components [23].

a uniform access to them. The core models provided by the component are the context model, where any available context attribute is defined, and the preference model, where any existing preference and their allowed outcomes are defined. There is also a context situations model, where complex conditions on context attributes corresponding to the useful user states (i.e., situations) are precompiled and given a name. Finally, the preference stereotypes model allows new users to gain a basic preference set that best fits their profiles. An action handler monitors the user behavior for use throughout the personalization and learning system. When a monitored action is received, the action handler disseminates it in the appropriate way to various locations. First, the action is sent directly to the PCM for dynamic personalization and then combined with context before it is sent to locations related to learning. This context information is valuable for the learning processes because it enables behavior patterns to be extracted from the raw data. The user action along with its associated context is sent to one of two places. First, it is sent to the user’s history database in a context management system, where it is stored until required by the batch learning process.

380

Services and Service Platforms

Second, it is sent to the learning manager where it is used in online learning processes. The main functionality of the learning manager is to learn the user preferences based on the monitored user behavior. It manages several different learning algorithms to achieve this goal. Each learning algorithm runs in its own thread and is constantly processing the information. The learning manager manages the running of each thread (including the triggering of the batch learning algorithms) and handles input such as user actions from the action handler. When input arrives, the learning manager forwards the input to the online learning algorithms. Any output produced by the learning algorithms is sent to the preference manager in the form of user preferences in order to update the user’s preference set. Learning is a continuous and cyclic process within a pervasive services platform and the feedback GUI enables the users to provide input. In some situations, for example, when a service wishes to implement a user preference, a notification of this will be displayed to the user through the feedback GUI module. The user may object and indicate what he or she prefers. This feedback will be passed back to the learning processes, enabling further refinement of the user preferences. The feedback GUI will feed back to the proposing service indicating what the user response was by means of an ACK/NACK signaling to the proposed action. 6.2.3

Context Management

Figure 6.11 shows a simplified component diagram of a context management system. The database management system (DDBMS) is the component responsible for managing and maintaining all context data. All the core functionality of the context management (CM) is provided by this component. DDBMS is the only component having a direct access to the databases. It is divided in two main subcomponents: the context model and the core DDBMS. The context model subcomponent includes all the classes that model the context information to be retrieved, exchanged, maintained, and managed, in general, in the pervasive system platform. The context model is not only used internally by the CM, but it is exported, so that it can be used by other enabling services and external actors of the system. It implements the following interfaces: (1) the ModelObject that is the base interface of all NDQL model objects, (2) the entity, (3) the attribute, and (4) the association that extend the ModelObject and are assigned with a unique URL-based identifier and a stub that is actually a reference to a model object that is not instantiated as a JAVA object. The context model does not depend on any external interfaces. On the other hand, the basic interface implemented by the DDBMS subcomponent is the QueryIfc that enables external parties to retrieve, update, add, and remove context data by providing methods allowing for the execution of DDQL or NDQL statements. The ResultSet interface is used to incorporate the information returned by the database management system in response to a query statement, while it supports access to the result objects. The connectionIfc supports an open connection to a local database management system or a remote node-manager. It provides methods, which allow for the execution of sql-instructions. The SqlStatementIfc is the base interface of the SqlStatement class, which contains all information related to an SQL statement. It

6.2 Architectural Concepts for Pervasive Services Platform

AdvQuerylfc

Querylfc

381

HoC_BasicPredictionRule HoC_BasedInference HoC_Management ContextTime HoC_Recorder RuleGenerationModel

ResultSet

44_ContextBroker

44_ContextInterferenceEngine

InferenceEngine

Identifier

Entity

<<use>> Association

InferenceRule AdvQuerylfc InferenceRuleParameters

<<use>> ModelObject

Attribute

InferenceRuleStructure

ModelObject

Identifier

Attribute

<<use>> <<use>> ContextEventManager

EventManager

Querylfc

ResultsSet

ContextSourceManager

44_DDBMS

ContextSource

44_ContextSourceManager

ObfuscationManagerIF

WP3: LocationServer

<<use>>

WP3: LocationServer

WP3: IDBroker

Identifier

Figure 6.11

Entity

Association

Attribute

ModelObject

Querylfc

ResultSet

Attribute

Top-level component overview of a context management system [23].

includes the statement string itself and JAVA objects that should be included in the actual call. The SqlStatement implements also the basic substitution mechanism for the extended query language (i.e., JAVA object substitution by aliases). Finally, the SqlStatement provides a method for modifying the jdbc PreparedStatements. Thus, it supports a straightforward way for using the SQL statements, not having to rely on the poor java.sql design. The DDBMS also implements the necessary context access control interfaces, that is, the AccessController, which is used for access control operations and decisions, the AccessControlContext, which is used to make model object access decisions based on the context it encapsulates, and the ModelObjectPermission, which represents access to model objects and consists of a model object identification string, as well as a set of actions valid for the identified model objects. In addition to the above, the DDBMS is also responsible for the context event handling and implements the DES ContextEventManager interface for this purpose. The latter is integrated with the event handling mechanism of the deployment and run-time environment. The interfaces required by the DDBMS are all the ones implemented by the context model component, the EventManager interface, the ObfuscationManagerIF and the ObfuscationFilter, the IDBroker and the LocationServer. The context source manager component is responsible for handling the various context sources attached to the CM. It implements two main interfaces: the

382

Services and Service Platforms

ContextSourceManager, which is the core interface that enables the collection of context data from the relevant sources and its dispatch to the DDBMS, and the ContextSource, which represents the context sources themselves or the drivers attached to them. It requires the following interfaces: the QueryIfc and the ResultSet of the DDBMS, as well as the attribute of the context model. The context inference engine component is responsible for deriving the secondary context information based on the various inference mechanisms (e.g., Bayesian networks, Bayesian filters, statistics). It implements the following interfaces: •

•

•

•

•

•

•

•

•

•

The InferenceEngine wraps the functionality to learn and evaluate the inference rules. The InferenceRule interface wraps the access to structure and parameters that are used to describe the input and the attributes to be inferred. The InferenceRuleParameters provide the parametric representations of the inference rules. The InferenceRuleStructure provides the structural representation of the inference rules. The HoC_BasicPredictionRule represents the HoC-based inference rules that are created based on a given rule generation model. The HoC_Management is responsible for the extraction of the BPR tables based on the registered/required rule generation models. The HoC_Recorder monitors and sends context history data to the BPR_Handler. The HoC_BasedInference handles the estimation/prediction of context values based on the applicable basic prediction rules. The RuleGenerationModel carries the information concerning the available RGMs. The ContextTime handles the information concerning the time and day of the week.

The ContextInferenceEngine component relies on the ModelObject, the Attribute, and the Identifier interfaces of the context model component, as well as on the AdvQueryIfc implemented by the context broker. The context broker component of the CM provides an abstraction layer for the IFs of the DDBMS. It extends the interfaces provided by the DDBMS supporting the filtered/extended queries on the context data, and is responsible for triggering of the context inference engine when required. It implements one main interface, the AdvQueryIfc that extends the QueryIfc and performs the aforementioned tasks. In addition to the navigational and spatial queries of the DDBMS, it also supports semantic queries. It depends on the QueryIfc and the ResultSet of the core DDBMS, as well as all interfaces provided by the context model. 6.2.4

Security and Privacy

Figure 6.12 shows the components of the security and privacy system, which is a part of the pervasive system platform [23].

6.2 Architectural Concepts for Pervasive Services Platform

383

cmp top-level Component view UserExperienceUSIM PrivacyManager PrivacyManager UserExperienceUSIM User Experience USIM

Properties: *Instantiated by Privacy Manager as Singleton per user OSGi Entity PrivacyAgent

Properties: *Instantiated as Singleton per user

Executive Identity Management

<<use>> ExecutiveUSIM

IOSGi

ExecutiveUSIM

PrivacyAgent <<use>>

Executive Identity Management ExecutiveUSIM NegotiationAgent

A4CMangement

NegotiationAgent

:NegotiationAgent

Negotiator

Properties: *No persistent state, only volatile memory *Instantiated as Singleton per user

WP4 A4C OSGi

WP3 ID-Broker WP3 Key Manager WP2 VID-Authenticator

IOSGi

IDBroker

KeyManager

A22_MT_VID_Authenticator

Entity NegotiationAgent

EntityInterface In simplest scenario optional. TrustManager

TrustManager Properties: *Instantiated by Privacy Agent in a particular request to contact some other entity

Interface to CMS of A4.4

To get notification from WP2 about status os user logins and VID-Wallet retrieval

TrustManager TrustManager

Context Obfuscation::COSManager

Adm Interface User Interface

Figure 6.12

Components of the security and privacy system in a pervasive services platform [23].

The Privacy Manager is the main functional block, which resides on each terminal and has the responsibility for the bootstrapping of all the privacy related systems before the login process. It also executes the login process. The Privacy Agent is a main functional block, which is personalized for a certain person and has access to the VIDs and key material. The Negotiation Agent performs the complex process of negotiation with the corresponding negotiator on the other side by using the privacy policy, which is included in the configuration for the privacy protection system for this person. The User Side Identity Manager is the functional block responsible for selecting the appropriate VIDs by the consideration of decisions taken by other components (e.g., negotiator and trust manager), and it evaluates the possible threats to the privacy protection aimed by certain VID. The Trust Manager is concerned with the evaluation of trustworthiness or reputation of actors in the system (according to a person’s context) and uses fusion of reputation techniques to achieve this. The context obfuscation is a special functional block, which makes the context hard to define, while still preserving its functional value in the transaction. The architecture of Figure 6.12 is divided into two parts, namely, the service and identity management layer (execution layer) with a basic functionality, and the user experience layer with an advanced functionality. Some of the components operate only on one level; for example, the negotiation agent and context obfusca-

384

Services and Service Platforms

tion only operate on the execution layer, while some operate regardless of the splitting (e.g., the Privacy Manager and the Privacy Agent), and some are designed in two different systems, for example, the User Side Identity Management, which comes with a basic functionality (i.e., the Executive Identity Management) and another component (i.e., the User Experience Identity Management), which can be added to the basic functionality to extend it for a better user experience and an automated VID selection. 6.2.5

Deployment and Run-Time Environment

The deployment and run-time environment is a well-defined execution environment that enables pervasive services (a perDES environment) and third-party applications. This environment is based on already established standards (OSGi and a compendium of base services) and takes into account the highly dynamic nature of the service environment. In order to embed into the overall services architecture and to provide an additional support for the perDES, a number of supporting components must be specified. These components are shown in Figure 6.13. The deployment and life-cycle management component is intended as an execution support layer for the session management component. While the session manager is responsible for the planning, coordination, and adaptive reconfiguration of the composed sessions, this component operates on individual service instances, but with the awareness of their embracing session. This session awareness is crucial because each decision on the life cycle of individual services will affect and harm the corresponding session(s). The main input to the deployment functionality is a list of all identified candidate services for the instantiation of a composed session. Potentially, such a descrip-

Figure 6.13

Components of the deployment and run-time environment [23].

6.2 Architectural Concepts for Pervasive Services Platform

385

tion can contain a number of equivalent service descriptions. In such cases, it is the responsibility of the deployment management to select, deploy, and instantiate the most suitable candidate with respect to load balancing and resource usage. The main goal is to make the discovered services available for session management and to remove them if they are not needed anymore. At the high level the responsibility of this block can be summarized as follows: •

•

•

Retrieve or create a representation of a service instance in the run-time environment. Ensure that this representation can be used in the current context, including the access control, and that the resource situation can provide valid control interfaces to the service representations. Update and undeploy service representations.

The data management block is responsible for providing persistence to the pervasive services run-time environment and its services and sessions. This involves local or remote storage of data. Most important is the ability to enable state persistency, so that states can be recovered after failures/crashes. The data management is also responsible for the state transfers that are instrumental to the state persistency (i.e., the transfer of the state from the service instance to the persistent storage and back) and the redeployment and replication of services (i.e., the transfer of the state from one instance to the other). Redeployment is a special case of replication, where a service is replicated and the original is removed afterwards. In the case when replication schemes are used, the data management is also responsible for the provision of support for achieving the data synchronization among the service replicas when the services are replicated. Replication may be the result of load balancing decisions. The pervasive services run-time environment includes a mechanism for describing the dependency of a service on the resources. Furthermore, this environment manages the access to the required resources. The management of the resources is based on OSGi compendium services (e.g., device admin, user admin, and so forth). The resource dependency management is responsible for the integration of the resources. One prominent example is the QoS management. For QoS management, the QoS interface needs to be integrated in the overall architecture. The resource dependency management then will include the QoS client interface that provides access to the QoS service. The “random nature” of pervasive computing application scenarios already suggests that sudden changes in a pervasive computing system can be critical. Given the constant change and unpredictable availability of arbitrary resources such as devices, network connection, and so forth, in ubiquitous computing, failures can occur easily. In pervasive computing application scenarios failures are much more common compared to traditional computing systems. Accordingly, in order to realize dependable pervasive computing applications, which is required by quite different application domains, a certain degree of “fault tolerance” needs to be considered in the design phase of such a computing system right from the beginning.

386

Services and Service Platforms

The dependability management is a mechanism for the support of the critical situations during the execution of services. Both are optional mechanisms, which need to be considered by the developers of controllable services already at the design time. The goal is to detect unpredicted behavior in the system. Any detected misbehavior will be reported to the deployment and the life-cycle management and—if critical—will be notified to the session manager, where it can initiate a recomposition. A close integration of the dependability mechanisms with the persistency of the data management allows for smart fault backup and recovery strategies. The A4C management (see Section 6.1.1) provides mechanisms for mutual authentication and restriction of the service access by means of access control decisions. Due to the fact that such functionality is essential for the pervasive services platform, it is part of the running environment. The mutual authentication guarantees the communication partners that the remote partner is the one he or she claims to be. This does not imply any statement about the trustworthiness or reputation of the opponent. In order to control the access to the services, two different mechanisms have to be differentiated: local A4C management, which is strongly related to the sandboxing mechanisms, and a global A4C management, which deals with the service access authorization. Another very essential privacy requirement is the access control on attributes of the user, which restricts, for example, service providers in the amount of information that can be gained about a user. The policy management provides policy evaluation functionality for the management of the distributed devices. More specifically, it allows for evaluating locally the policies targeted at entities on the local device. This functionality allows for applying policies internally within a device, (e.g., supplying configuration details to a local client, under the direction of an operator or service provider). These policies are specified in a management environment by specifying a set of attributes that describe the applicable targets of the policy and the effects of the policy as a set of obligations. The configuration management block provides a configuration functionality for the management of the distributed devices. The configuration management component can be seen as a logical policy enforcement point (PEP) for configuration settings. These configuration settings are then applied within the other platform or a third-party service. The configuration management aspects are fulfilled by applying the cached policies locally, and when policies have been previously cached, they can be used during a disconnected or bootstrapping operational mode. The EventManagement (EM) can fill the gap of a standardized asynchronous notification framework in OSGi. The functionality of the EM can achieve this for notifications in a single container. 6.2.6 Tools and Support for Third-Party Service Development and Provisioning

A set of APIs can to allow third-party service providers to make use of the pervasive service platform functionality. These APIs allow for making use of service management, context, and personalization aspects of the pervasive services platform in order to enhance the third-party services.

6.2 Architectural Concepts for Pervasive Services Platform

387

Figure 6.14 shows the interfaces offered by the pervasive service platform, and Figure 6.15 shows the view of the third-party service as seen by the pervasive services platform. It shows the interfaces that are available to the third-party developer to implement that will allow for the service to be acted upon or called directly by the pervasive services platform. These interfaces will be used by the third-party services to carry out various actions that are facilitated by the platform. The view of the third-party services shows a simple split between the service itself and the pervasive service platform. The design of the third-party service is at the discretion of the service designer. The service will view the platform as a single component accessible through the PervasiveX interface. The pervasive service platform sees the third-party service through the service model (or part of the service model since some parts are optional). This means that services must comply to this prescribed ServiceModel (or a subset of this model), in order for the platform to get a handle on and manage the service. Additionally, in order to be initially discovered and used within the platform, the service must also describe itself using the OWL-S (and OWL where necessary).

Figure 6.14

Component diagram of interfaces offered to third parties [23].

388

Services and Service Platforms

Figure 6.15

6.3

Component diagram of interfaces which third parties can implement [23].

Service Platforms and Service Provisioning in Personal Networks In personal networks (PNs), users interact with various companion, embedded, or invisible computers not only in their close vicinity, but potentially anywhere. They also need to interact with other persons having their own PNs, leading to group communication and federation of PNs to achieve particular tasks. PNs constitute a category of distributed systems with very specific characteristics [9, 26–28]. PNs comprise potentially “all of a person’s devices capable of network connection in the real or virtual vicinity.” Security and privacy of the users and their data are very important in the context of PNs. In order to offer the user viewing, managing, and access to all its PN resources and services from anytime and anywhere, proper mechanisms for service discovery, provisioning, access, session control, mobility management, bundling and composition are needed [29]. A service management system in support of PN services called the MAGNET Service Management Platform (MSMP) was proposed and designed for that purpose in [9]. Its structure follows both a centralized approach at the PN cluster level and a peer-to-peer (P2P) approach at the PN level (between the PN clusters). Thereby, a service management node (SMN) is elected for each PN cluster. It discovers and manages services at the PAN/cluster level and interacts with SMNs of other clusters at the PN level in a peer-to-peer fashion. The SMN is responsible for the discovering and the advertising of remote services within the cluster. The MSMP global architecture [30, 31] is shown in Figure 6.16. The PN service level architecture in Figure 6.16 has been limited to the development of a wide area service discovery resulting from the combination of a local dis-

6.3 Service Platforms and Service Provisioning in Personal Networks

389 Home cluster

SMN P2P overlay network P-PAN

User

Public IP network

Cluster gateway

NAT

Edge node

Firewall

Figure 6.16

MSMP SMN SMN super peer

Office cluster

MSMP structure overview [29].

covery protocol and a framework (specifically UPnP), and a naming system (specifically INS Twine). The concept of a service management node within the PN clusters and especially the P-PAN was introduced and foreseen for service session control and management. The SMN function is enabled or activated in powerful nodes within the clusters, called service assistance nodes (SANs) and capable of handling the tasks and transactions related to the service life-cycle management. Figure 6.17 shows the underlying protocol stacks involved in the service discovery and name resolution of an implemented service discovery architecture. A P2P overlay of SMN nodes located typically in clusters ensures the name resolution to facilitate the PN networking and implements a device and a service locating function to achieve inter-PN cluster service discovery. This overlay, which can

Figure 6.17

Basic protocol layers for the service level architecture for PNs [29].

390

Services and Service Platforms

be built on any P2P paradigm, even if actually designed using a distributed Hash table (DHT) and a chord ring, enables communications between the SMNs acting as super peers. Three other modules are also involved. These are mainly a transcoding module that converts the INS Twine service descriptions to and from the UPnP service description, an SMN AAA server function to handle the interaction with the foreign nodes in the architecture that can be replaced by a full-blown security framework [31], and finally an adaptation layer to interface with the lower layers and the protocol stacks, upon which the most existing service discovery frameworks rely. The Service Discovery Adaptation sub-Layer (SDAL) acts as a convergence layer that links the lower layers components to the P2P naming system, the service APIs above, and the AAA server. Figure 6.18 shows a high level view of the MSMP and the functionalities to enable the interaction with the context management framework. It shows in a very generic fashion the relationship to the service bundling and applications as well as the networking layer for the target service management level. A module called the Service Session Management Module is incorporated for monitoring and controlling of the service sessions between the clients and the servers. Because the PN services are discovered by the MSMP, it is possible to divert the signaling and, if necessary, the normal service flows through the MSMP. In this case, the MSMP overhears the signaling messages between the clients and the servers to achieve the monitoring or sends control messages (to either clients, servers or both) to harness the service sessions. The service session control in the simplest case may include the termination of a service session because of the policy enforced by other components of the system (e.g., by the policy engine), or termination and the reinitiation of the service sessions in case of mobility. The concept of the PN can be extended further to the concept of the PN-Federation (PN-F) [32]. In order to handle PN federations, a PN-F service overlay is designed and implemented. The PN-F overlay, based on the PN Agent framework and called the PN-F Agent framework, establishes the P2P overlays at the service

Figure 6.18

High-level view of the MSMP global architecture [32].

6.3 Service Platforms and Service Provisioning in Personal Networks

391

level dedicated to the PN-Fs. PN-F participants publish, register, update, and discover the information on their shared services within the PN-F through the PN-F Agent service overlay, by relying on an intentional name format providing the needed service descriptions. Figure 6.19 shows the high-level architecture of the PN-F service overlay. A special peer in the overlay is the PN-F Agent. It implements all PN Agent functions (used in the case of PN-centric services) but is exclusively dedicated for storing and discovering of the PN-F resources/services at the PN level. All the PN-F Agents are created and populated (in terms of PN-F service descriptions) by the PN-F participants (including the PN-F creator) during the PN-F establishment process. In the design shown in Figure 6.19, only one PN-F Agent per federation is activated within a PN. At federation level, the PN-F Agents of the participants interact in a peer-to-peer manner via a PN-F service overlay to provide PN-F-wide service discovery according to PN-F participation profiles. The PN-F service overlay formation takes place after PN-F connectivity establishment and relies on the PN-F networking [30]. The service related functions provided by the “SD with GUI” are extended to the PN-F case. The MSMP components protocol stack was shown in Figure 6.17 and the interactions with other PN and PN-F entities are shown in Figure 6.20. In the envisioned service proxy case, the PN services for external use will be “emulated” at the PN gateways. For the internal services, the service is accessed by another node within the PN. When the requesting PN-F member receives a notification that it is allowed to use the service (i.e., depending on the established trust and security), it can register the client emulating part of the service with its service proxy. Finally, the service can be consumed and the corresponding communication

Figure 6.19

Service overlay solution for PN- and PN-F-wide service discovery [32].

392

Services and Service Platforms

Figure 6.20

MSMP components interactions with other PN and PN-F entities [32].

and messages are relayed by the service proxies. In the “pure ad hoc” situation, that is, when no connection to an infrastructure network is available, the service proxy may perform the following actions: • • • •

Periodically announce its service information; Disseminate some of its service information within the ad hoc network; Import and export services from/to foreign nodes; Wait for service requests that match to some of its offered services.

In the proposed service overlay solution, where the PN Agent acts as a name resolution system, PN/PN-F clients use this PN Agent framework to discover the available SMNs in the PN/PN-F. 6.3.1

Solutions for Securing the MSMP Operations

Operations of the MSMP are secured on lower levels by the underlying mechanisms. However, on the application layer, operations also require authorization according to the authentication and the proper monitoring and accounting. For this purposes, an AAA Module was designed at the service level [23]. The proposed AAA module is addressing the PN case and is also extended for the PN Federation (PN-F) case. 6.3.1.1

SMN AAA Module

The AAA Module is a component which, together with the service profiles and policies, forms the security management box (see Figure 6.18). It consists of the following components:

6.3 Service Platforms and Service Provisioning in Personal Networks

•

•

•

•

393

A Web server is responsible for handling the incoming RPC and SOAP requests; it also encapsulates the interfaces to the external modules such as the SDAL or an external policy engine. The Profile Manager is responsible for parsing, querying, and modifying the profiles according to the requests received. The requests can derive from the external modules or the profile management GUI (e.g., add a new policy). Also, it is responsible to provide input to the policy decision point or any external policy engine. Finally, it is also responsible for properly propagating all changes to all AAA modules throughout the PN overlay, so as to achieve profile synchronization. The Policy Decision Point receives proper input from the profiles and the profile manager regarding the rules and the security parameters and is responsible for taking policy decisions. The Profile Management GUI is a graphical tool which enables the user management of profiles and policies, thus linking the security profiles—and encapsulated policies—with the user.

A high-level view of the AAA module is shown in Figure 6.21. 6.3.1.2

Security Profile and Policies

Trust management is performed through the use of profiles, which encapsulate the security policies. The profiles provide structured information about all PN elements and the conceptual entities (e.g., users, PNs, federations, services, nodes-devices, SMN-devices), along with the related security policies. As far as the service authorization is concerned, these policies state what rights users have for the service access according to the devices they use. By properly applying these policies towards authenticated requests, service access control is realized. The profiles determine the access rights for users and contain authorized users, credentials needed, subscription to groups, and acceptable reputation values as follows: •

•

User information is the identity, organization, role, group membership, areas of interest, and preferences of the user. The pair-wise long-term keys are shared with other paired devices/nodes that are referenced by their unique device IDs and their group. The group information includes the group name, members, and membership profiles. Profile Management GUI

AAA Module Web Server XML - RPC / SOAP

Figure 6.21

Profile Manager Policy Decision Point

High-level view of the AAA module [29].

394

Services and Service Platforms

•

•

•

•

•

The service information is a unique service name, a short description of what the service offers, the service location (i.e., which node provides the service), and the information around the subscriptions, charging rates, password, and credential requirements. Owned devices and networking information concern the owned PN and clusters. Trust level is determined from the position of the node inside a well-defined trust framework (e.g., long-term trusted personal nodes or ephemeral trusted foreign nodes). In order to apply reputation-based policies, profiles have the option to impose a requirement for an acceptable given reputation value. Local policy specifies how and when the services and security mechanisms should be used and can be preset or configured by the user. This policy can be used to specify which access rights are granted to access services in other networks.

As an extension to the PN-Federations, the security profiles also contain: • •

The PN-Federation credentials, timestamps, and related information. The user role associations, which will grant the corresponding user appropriate rights. This also includes appropriate credentials for the PN-federation status: creator, simple, or privileged member.

Security profiles will bear information, which is provided to and from the AAA Module and the Context-Aware Security Manager (CASM). Security policies can be created and managed through the use of an appropriate tool. A policy is in general a rule or rules that consist of a set of defined values, value sets, or value ranges for parameters that exist inside the security profiles. The appropriate ranges lead to the extraction of specific cases, which usually fall under the case of a positive or a negative decision. However, more complex policies can be defined, which guide decisions through a well-expanded decision tree [30]. Figure 6.22 shows the process of privacy enforcement and the flow of privacy enforcement and access control, as requests for visibility and access to services arrive from the service discovery components. Security-related attributes of the requester are checked and then if these are considered valid and privileged enough, the trust, security level, and privacy policies are checked in order to come up with a final decision for the request. The aim is to optimize the handling of these requests and avoid having unauthorized requests keeping the system busy for too long. 6.3.2

Context Management Framework

A Context Management Framework in the context of PNs should be secure. A Secure Context Management Framework (SCMF) is proposed in [9] and a general view is shown in Figure 6.23. The purpose of the SCMF is to provide efficient access to context and user profile information for any type of software clients such as applications, services, or PN

6.3 Service Platforms and Service Provisioning in Personal Networks

Figure 6.22

395

Privacy enforcement and access control procedure [29]

components. This includes gathering, storing, processing, and distributed access to context and user profile information. Context gathering means accessing the data from different data sources such as sensors, the network stack, or the operating system and transforming this information into a common context representation, following a common context model. The user profile and context information will be stored in storage components and processing modules can be used to derive higher levels of context information. The overall architecture is highly distributed (i.e., context information will be gathered and accessed on all nodes). This requires efficient structures for accessing the context information. The language for accessing the context information can be the Context Access Language (CALA), which is used by components that access context and user profile information. Overall, the SCMF provides the following advantages: •

A developer writes all his or her applications against this common interface.

396

Services and Service Platforms

Context Aware Context Aware Component Context Aware Component Component

Context Aware Context ServiceAware Context ServiceAware Service

Query Subscription

Context Aware Context Aware Application Context Aware Application Application

Response

Secure Context Management Framework

Data Source (Sensors)

Data Source (PHY/MAC Parameters)

Context Access Layer (CAL)

Notification

Data Source ( …)

Communication with other Nodes

Data Source Abstraction Layer (DSAL)

Context Agent Figure 6.23

•

•

•

•

A general view of an SCMF [29].

A developer does not have to know anything about the specifics and internals of the context sources. A developer/user can replace sources (e.g., use completely different sensors with different protocols) easily, as long as they provide the same type of context information in the end. A developer can reuse your context processing components as they operate on the common model; they do not have to be adapted to different sensors/representations. A developer does not have to know anything about the distribution of context information and context sources; this is made transparent by the SCMF.

With respect to the SCMF, two abstraction layers can be defined, namely, the Data Source Abstraction Layer (DSAL), where the SCMF is abstracted from the individual sources of information and how these are retrieved, and the Context Access Layer (CAL), which is the abstraction from where applications, services, and other networking components are being abstracted from the retrieval, processing, and distribution done in the SCMF. In the case of PN federations, it may be useful or even necessary to share context information between different PNs. This is a new situation, as within a PN the security is guaranteed through the PN mechanisms themselves, and there is no need for additional privacy protection, since the whole personal network is private and context management and exchange can rely on it. Within a PN federation, the privacy of the user needs to be specially protected, that is, the user needs to be in full control of his or her context information. Therefore, the user has to define policies regarding

6.3 Service Platforms and Service Provisioning in Personal Networks

397

what context information should be visible within the PN federation and who is allowed to access this context information. As privacy is already enforced by the CASM, this component would be the natural location for also enforcing privacy policies in a PN-Federation. 6.3.3

Interaction Between MSMP and SCMF

The MSMP and SCMF require interaction on two levels: (1) since context may also be related to services, service states, and so forth, the MSMP can act as a context provider, and (2) since the MSMP may enhance its functionality by the use of context, for example, doing context-sensitive service discovery, it will also need to interact with the SCMF as a client. The interaction is shown in Figure 6.24. Many of the subcomponents inside the MSMP may benefit from context information. Context-aware service discovery was introduced and evaluated in [33] as a response to the fact that a PN, or, in particular, a PN-Federation, may contain many services of the same type, making it not easy for the user to determine which of the services is the most relevant to the user. The context-aware service discovery implementation proposed in [33] did not incorporate the SCMF and the interaction with it, as it did not yet exist (instead, there was an MSMP-internal context management module, relying on the UPnP module in the MSMP). Context-aware service discovery is based on a concept in which a service score is associated to all discovered services and which reflects the relevance to the user in his or her given context (considering the user’s preferences). Figure 6.25 shows a high-level overview of the interactions between the components involved in the context-sensitive service discovery process. Every service discovery request originating from a Service Assistant Node (SAN) or from the local SMN is mediated to the SDAL. Depending on whether it is a context-sensitive or a normal discovery request, it is forwarded to the SDM. Figure 6.24 shows the context-sensitive service discovery concept on a PN level, and the request is mediated throughout the system to other SMNs in step A, whereas in step B, the SCMF has been sent a request for the service preferences (Context Parameter Data, CPD), which are maintained as user profiles by the SCMF. The CPD contains

Figure 6.24

Interaction between MSMP and SCMF [32].

398

Services and Service Platforms

Figure 6.25 High-level overview of interactions between the MSMP and SCMF for a global (and local) context-aware service discovery [32].

the necessary information for the SMN to calculate the service relevance, including necessary information on what context information is relevant for the given service type and on how the score should be calculated. Once this is known, the SMN requests the context data itself from the SCMF in step C. The SMN is aware of the information needed to calculate the service relevance, which is done in step D according to: S SSF ( x s , x u , x c

∑ )=

M n =1

(

(n ) w ( n ) fCSF xs

(n )

∑ n =1 w M

, xu

(n )

(n )

, xc

(n )

)

(6.1)

where SSSF is the service score function, xs is the context associated to the service, xu is the context associated to the user, xc is a preference value used to set the focal point of the context score function, fCSF, and finally the weight w is used to weight the individual score contributions (e.g., if one context element has higher priority than others then w is used to adjust the impact of the difference). The value of xc and the function description/type plus other relevant parameters are all described in the CPD, whereas the values of xs and xu are context data. Four main types of functions for the numerical evaluation were proposed in [33]: •

• •

Below: gives a high score when |xs| < xc ± σ, or ||xsxu||< xc ± σ, with σ indicating a distance of fuzziness (the score is not binary 1 or 0, but has a slope in the area xc ± σ). Above: gives a high score when |xs| > xc ± σ, or ||xsxu|| > xc ± σ. Between: gives a high score when xc,low < |xs| < xc,high ± σ, or xc,low < ||xs3u|| < xc,high ± σ.

6.3 Service Platforms and Service Provisioning in Personal Networks

•

399

Avoid: gives a high score when xc,low > |xs| > xc,high ± σ, or xc,low > ||xsxu|| > xc,high ± σ.

For nonnumerical context representations (e.g., textually represented context), other types of functions need to be defined (e.g., a semantic match or distance metrics in a Markov chain state space where each state is represented by a text string). 6.3.3.1

Solutions Enabling the Interaction Between the MSMP and the SCMF

Figure 6.26 shows the details of the interaction between the two frameworks. The interaction occurs between the SDAL internal to the MSMP and the SCMF through the CMI (using the CALA language) [30]. If context-aware service discovery is not used, the SDAL simply skips the intermediate steps to/from the SDM (and hereby also to/from the SCMF). The direct interaction between the SDM and the SCMF is carried out by the SCMF client, located inside the MSMP. The purpose of the SCMF client is to translate between the MSMP-internal context representation and the XML-based CALA language. The output of the process is a filtered list of services with the service score associated to each item of the service list. This is eventually returned to the user, who can then select, based on the service score, among the most relevant services. The service discovery request when forwarded to the SDM must be based on a service ontology, which enables the SDM to derive service types and relevant context information. Based on the existing ontology used in the SCMF [30], a service ontology can be created following the SCMF structure, as shown in Figure 6.27. When receiving a service discovery request (e.g., about a PrintingService), the SDM knows that this is a service and as such has a providedBy attribute. The value of this attribute (providedBy) is another entity, which is a device. The SDM can now find the location of the device, and compare it to the location of the user (as in this

MSMP

SDAL

Service discovery request

SDM

CMI

SCMF

Service discovery rank query has identifier, resource type, or service type list of service-entity identifiers

getServicePreferences( ) service type from query

getCurrentUser( ) getContextEntities( )

from query and preferences

Filtered list of services

rankServiceEntities( ) from context entities

Service discovery response Figure 6.26 Mechanism for node-local activity of context-aware service discovery when a service discovery request is accepted [32].

400

Services and Service Platforms MagnetEntity VirtualEntity

Service PrintingService BicycleGymService StorageService

Figure 6.27

Service ontology as an extension to the existing ontology used in the SCMF [32].

case the distance between the service and the user is used for the service score calculation). The CPD records are maintained as profile information in the SCMF. At least, the CPD needs to contain information about what service it refers to and what attribute a given CPD record is used for (e.g., location of a PrintingService). Furthermore, it needs to contain the necessary parameters for shaping the Context Score Functions (fCSF). For this purpose, the value and accuracy attributes are used to contain xc and σ, as introduced earlier. Furthermore, the CPD needs to contain information on whether relative or absolute score calculation should be used, or in effect, whether |xs| or ||xsxu|| is to be used in the calculation. Finally, the CPD needs to hold also information on what type of function is to be used (e.g., above or below). In summary, a CPD record would need to include the following attributes: • • • • • •

appliesToEntity: single MagnetEntity (‘PrintingService’); appliesToAttribute: single Property (‘hasSymbolicLocation’); value: single String (‘A5-203’); accuracy: single Int (0); isRelative: single Boolean (‘false’); rankType: single {match, above, below, between, avoid}.

The SMN in the MSMP handles a large amount of information, but among all these service-related data, some that are related to service availability/accessibility, and maybe to service session status, are viewed as context information. This means that they have to be forwarded to the SCMF by the MSMP (i.e., by the SMN to the local context agent). According to the SCMF architecture, this implies that the SMN acts as a Data Source forwarding service-related context data to the DSAL of the context agent. In order to have a minimum set of normalized attributes for sharing a common understanding of the services, the generic service attributes need to be defined irrespective of their native description language (i.e., similar as for an ontology).

6.3 Service Platforms and Service Provisioning in Personal Networks

401

A unique service identifier (UUID) attribute can be required as mandatory because the context-related service information stored within the SCMF needs to be uniquely associated with the service itself. For that purpose, [32] proposed to associate this UUID to each service, as a new normalized service attribute, and to couple this UUID with the service-related context information that is being stored in the SCMF (i.e., also including this attribute within the context ontology). This new service attribute, called hasIdentifier, is the UUID and should not be technology dependent (e.g., it could be a text string or a randomly generated part combined with a PN or a user ID). The initialization of the hasIdentifier attribute is handled at the SDAL level. This attribute must be forwarded by the SMN SDAL (or by the Context Providing Modified UPnP Device of the SMN, depending on the retained solution) to the SMN Retriever of the SCMF. The two other normalized service attributes that can be introduced are: •

•

ResourceType: It is used for storing the type of service environment that is providing the service and could have, for example, the following values: PN-Pilot, UPnP, WebServices, JINI. Service Type: It is used for storing the kind of service offered and could have, for example, the following values: PresentationService, CommunityBuilding, PrintingService.

An event-handling mechanism can be implemented in order to forward any changes occurring in a service state to the SCMF (i.e., the MSMP retriever), provided that this SCMF has subscribed to this MSMP event server. All the service-related information is retrieved by the SMN from the service nodes via modified SD Clients/Servers within the MSMP architecture. The Service descriptions and attribute values are accessible through the SMN, either using one of the SMN-managed SD frameworks (UPnP and Bluetooth) or calling dedicated SMN SDAL (Service Adaptation sub-Layer) RPC function calls. Two communication interfaces could, therefore, be envisioned between the SMN data source and the corresponding DSAL retriever of the local context agent. The first solution consists in using the UPnP advertisement, control, and event-handling mechanisms to retrieve the service-related context data from the SMN (UPnP being currently the most powerful SD framework handled by the SMN). The main advantages of this solution are: • •

To provide a data source discovery mechanism; To allow an event-based update (i.e., via subscriptions/notifications) of the service-related context data. Notifications are sent to the DSAL retriever whenever a change has happened to these data. This mechanism should allow a reliable update of the context storage in the local context agent.

The interactions of the MSMP and SCMF via the UPnP are shown in Figure 6.28. This solution requires the implementation of the following:

402

Services and Service Platforms

Figure 6.28

•

•

•

SMN and DSAL interactions through UPnP [32].

A full UPnP protocol stack (SSDP, SOAP, and GENA) within the DSAL of the Context Agent; A dedicated control point (UPnP SD client) within the DSAL of the Context Agent; A dedicated UPnP Device within the SMN. The service offered by this UPnP Device is providing service-related context information.

Another possible solution consists in using some dedicated RPC function calls of the SMN SDAL to retrieve the service-related context data from the SMN. This is shown in Figure 6.29. There is no need to implement a SMN data source discovery mechanism because the active cluster SMN information (name, address, and port) is accessible from the PN Agent. This solution is also easier to implement in the DSAL of the local context agent than the previous one. Furthermore, it only implies a few minor updates of the SMN SDAL module. On the other side, no event-based updates of service-related context data are provided. The periodic RPC function calls at the DSAL retriever

Figure 6.29

SMN and Context Agent DSAL interaction through RPC [32].

6.3 Service Platforms and Service Provisioning in Personal Networks

403

level should a priori enable a proactive update of the context agent in an acceptable way (this strongly depends on the retriever RPC call frequency, the service variation frequency, and so forth). 6.3.3.2

Interactions with the IMS System

The IMS allows seamless handover between multiple access technologies and provides the necessary mobility and routing management. The core network sees the mobile network as another IP network and does not need to manage mobility, authentication, or security control as the user changes access technology. IMS uses the Session Initiation Protocol (SIP) to allow fast connection between mobile devices and the core network. Initial setup of data sessions in traditional wireless networks can take between 1 and 15 seconds, compared with milliseconds in a fixed network. The PN can be viewed as virtual access network from the IMS platforms [33]. Typically, the interface between access, core networks, and the IMS can be achieved via wireless access gateways [32]. The same paradigm can be adopted also for the PN, and a tighter collaboration between the PN architecture and IMS frameworks might even be favorable in order to achieve service bundling or composition and provisioning. This imposes a number of basic requirements on the PN node and especially on the nodes involved in the service sessions with the external service platforms. Here, the focus is on the IMS, which also relies on the session establishment protocol of IETF adopted by 3GPP and, consequently, is assumed by the TISPAN

Figure 6.30

Interactions in the PN and IMS domains [32].

404

Services and Service Platforms

concept of a service plane independent of underlying access technologies. The envisioned interactions between a PN and the IMS are shown in Figure 6.30. The PN nodes must be provided with an IMS Client and an SIP UA with a SIP URI for each node. Furthermore, the PN nodes must support the communication of the Gm interface with the IMS service plane and, especially, the P-CSCF. This entity is responsible for the service-based local policy control that enables the IMS operator to authorize and control the usage of bearer traffic based on SDP parameters negotiated at IMS session. Moreover, the P-CSCF is defined as the contact point to the IMS; therefore, it must be located in the IMS operator’s domain. The I-CSCF entity is the IMS user’s home network entity that interacts with the home subscriber server (HSS) in order to find out the capabilities of the available S-CSCFs and to select a suitable S-CSCF for the IMS client. The I-CSCF is located in the IMS operator’s domain. The S-CSCF is responsible for the session establishment and the service invocation. It is possible to install a local S-CSCF in the PN clusters in order to enable intercluster session establishment, service invocation, service interoperability, and service composition. In this case, the local S-CSCF can be installed or deployed in the PN clusters as well as in the edge nodes or routers belonging to trusted third party. The service capability is a modular and self-contained service building block that can be shared and reused by various application servers (e.g., a Presence Service Capability that could be reused and shared by Multimedia Conferencing, Chatting, and Multiparty Gaming). In order to ensure a call or session forwarding, control, and management, the application servers and service capabilities can be designed in the PN clusters to enable the PN to use its local and personalized services and to manage the composition of the service capabilities locally to introduce new integrated services. This proposal can be realized through a distributed control between the providers and the PN users on the basis of viable and acceptable agreements to these actors. However, the PN must also support the access of the PN nodes to application servers and service capabilities that are in IMS operator’s domain. Because the PN users can use any kind of air interface and access technology, including WLAN and IP directly, the IMS registration can happen via any access network. The registration procedure also enables the user to know the contact point for the IMS because the address of the P-CSCF is found through the registration and may rely on the DNS or a DHCP server. The P-CSCF adds to the received request its address and the visited network identity. The P-CSCF forwards the request to the I-CSCF of the user equipment home network by using the home domain name of the user equipment. The server level registration is shown in Figure 6.31. The interaction between the MSMP (as an IMS client) and the IMS core is provided via the Gm interface. When an invite message arrives to the SGN, the MSMP will be contacted for the list of all resources via the Im and will, therefore, behave as a user equipment. These services (as IMS clients) are already registered with the MSMP. The MSMP, by using the context information provided by the SCMF, provides the URL of the device acting as a user equipment for taking the call. The list of API for the implementation of this interface on both sides is as follows:

6.4 Conclusions

Figure 6.31

• •

405

Service level registration in the IMS [32].

serviceDiscoveryRequest (out); serviceDiscoveryResponse (in).

The two major components that must be added to the IMS core are the SIP AS and the SGN. Reference [32] proposed as a solution for an application server the MobiCents [34]. MobiCents provides a variety of components such as the SIP Resource Adaptor, the Media Resource Adaptor, and the Media Gateway resource adaptor for advanced media control. MobiCents is an Open Source VoIP platform, certified for JSLEE 1.1. A Service Level Execution Environment (SLEE) is a high throughput, low latency event processing application environment. JSLEE is the Java standard for SLEE, designed to allow for implementations of the standard to meet the stringent requirements of the communications applications, achieve scalability, and availability through clustering architectures. JSLEE is an industry standard aimed at portable communications applications. JSLEE is the point of integration for multiple network resources and protocols. Applications can use many different external network resources from within the JSLEE environment. More on applications and application environments will be discussed in Chapter 7.

6.4

Conclusions Changing access technologies today can require full connection, registration, and authentication on each access network followed by manual intervention to switch from one to the other. Even when the mobile device supports both access technologies, the data flow cannot be handed over seamlessly without the user being aware of the change.

406

Services and Service Platforms

The solution is to connect mobile networks to the core network through the IMS. Further to the use of the IMS system, platforms for service provision must incorporate mechanisms for service discovery, context management, security, privacy, and virtual identities. Middleware is the enabler of the proper functioning of such mechanisms in support of service and application provision during user mobility. A next generation network (NGN) is a packet-based network able to provide telecommunication services to users, able to make use of multiple broadband, QoS-enabled transport technologies, and in which service-related functions are independent of the underlying transport-related technologies. It enables seamless access for users to networks and to competing service providers and services of their choice. It supports generalized mobility, which will allow consistent and ubiquitous provision of services to users. The current trend for networks is service-awareness. It can have many aspects, including the delivery of content and service logic, the fulfillment of business and other service characteristics such as QoS and SLAs and the optimization of the network resources during the service delivery. Services are must be executed and managed within network execution environments. Furthermore, both services and network resources should be managed uniformly in an integrated way. The adaptation of services to the context of the mobile user will determine the adoption and popularity of emerging services. The FP6 IST projects provided solutions to challenges such as dynamic adaptation, in which the mechanisms should apply to both the output and input models of the service and allow the end user to interact with the service using the most natural modality and using the most appropriate interaction component available. The adaptation should not be completely automatic, and the end-user should be able to approve/disapprove of the adaptation decisions. This chapter described some of the architectures and middleware building blocks developed by the EU-funded projects and providing solutions to technical issues related to the development and life-cycle management of mobile services. Mobile service provisions in situations where the network may need to be set up at short notice, or for limited duration, and where communications infrastructure may be unavailable for some users, necessitating the need for use of ad hoc communications, are one of the characteristics of services delivered through next generation communication systems.

References [1] [2] [3] [4] [5] [6]

FP7 ICT EU-Funded Program and Projects, “The Future of Internet,” ftp:// ftp.cordis.europa.eu/pub/ist/docs/future-internet-istag_en.pdf. FP6 IST Projects, Cluster of Beyond 3G Architectures, http://cordis.europa.eu/ ist/ct/proclu/p/mob-wireless.htm. FP6 IST projects in Broadband for All, http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. FP6 IST Project DAIDALOS and DAIDALOS II, www.ist-daidalos.org. FP6 IST Project SPICE, www.ist-spice.org. FP6 IST Project PLASTIC, www.ist-plastic.org.

6.4 Conclusions [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[21] [22]

[23] [24] [25]

[26]

[27]

[28] [29]

[30]

[31]

407

Prasad, R., and A., Mihovska, (eds.), New Horizons in Mobile Communications: Reconfigurability, Norwood, MA: Artech House, 2009. FP6 IST Project Ambient Networks (AN), www.ambient-networks.org. FP6 IST Projects MAGNET and MAGNET Beyond, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. FP6 IST Project C-MOBILE, http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. IST Advisory Group, Working Group on Web-Based Service Industry, Version 12, February 2008, ftp://ftp.cordis.europa.eu/pub/ist/docs/web-based-service-industry-istag_en.pdf. FP7 ICT EU-Funded Program and Projects, “The Future of Internet,” ftp://ftp.cordis.europa.eu/pub/fp7/ict/docs/ch1-g940-280-future-internet-ld_en.pdf. FP7 ICT Project OPEN, http://cordis.europa.eu/fp7/ict/ssai/projects_en.html. FP6 IST project DAIDALOS II, Deliverable DII-411, “Concepts for Pervasive Services and Applications with Relation to Key Concepts,” September 2006, www.ist-daidalos.org. FP6 IST Project DAIDALOS II, Deliverable DII-151, “DAIDALOS Transition and Interworking Based on 3GPP and TISPAN,” October 2008, www.ist-daidalos.org. FP6 IST Project MOTIVE, Deliverable D2.2, “MOTIVE System Architecture,” http://www.cn.ntua.gr/ist-motive. FP6 IST Project MOTIVE, http://www.cn.ntua.gr/ist-motive. Demeter, H., et al., “Mobile Service Platforms—Architecture Whitepaper,” February 2008, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. Murch, R., Autonomic Computing, Upper Saddle River, NJ: Prentice Hall, 2004. Devlic, A., and E., Klintskog, “Context Retrieval and Distribution in a Mobile Distributed Environment,” Proceedings of the Third Workshop on Context Awareness for Proactive Systems, June 2007, Guildford, United Kingdom. FP6 IST Project MIDAS, at www.ist-midas.org. Plagemann, Th., et al., “A Data Sharing Facility for Mobile Ad-Hoc Emergency and Rescue Applications,” Proceedings of the First International Workshop on Specialized Ad Hoc Networks and Systems (SAHNS 2007), June 2007, Toronto, Canada. FP6 IST project DAIDALOS II, Deliverable DII-413, “Report on Application of Key Concepts to Pervasive Service Platform,” October 2007, www.ist-daidalos.org. FP6 IST project DAIDALOS II, Deliverable DII-461, “Architecture and Design: Pervasive Service Framework Management,” October 2006, www.ist-daidalos.org. FP6 IST project DAIDALOS II, Deliverable DII-331, “Architecture and Design: Context-Aware Network Resource Management and Monitoring,” December 2006, www.ist-daidalos.org. Niemegeers, I. G., and S. M. Heemstra de Groot, “From Personal Area Networks to Personal Networks: A User Oriented Approach,” Special Issue, Journal on Wireless Personal Communication, May 2002. Niemegeers, I. G., and S. M. Heemstra de Groot, “Research Issues in Ad-Hoc Distributed Personal Networking,” Special Issue, Journal on Wireless Personal Communication, Vol. 26, No. 2-3, 2003, pp. 149–167. Mohr, W., et al., (eds.), The Book of Visions 2000—Visions of the Wireless World, Version 1.0, Wireless Strategic Initiative, November 2000, www.wireless-world-research.org. FP6 IST project MAGNET Beyond, Deliverable 4.1.2, “Selections and Implementation of Protocols and Solutions in the View of the PN-Platform,” February 2007, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. FP6 IST project MAGNET Beyond, Deliverable 2.3.1, “Specification of PN Networking and Security Components,” January 2007, http://cordis.europa.eu/ist/ct/proclu/p/ mob-wireless.htm. FP6 IST Project MAGNET Beyond, Deliverable 1.1.1, “MAGNET System Specification,” January 2007, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm.

408

Services and Service Platforms [32] FP6 IST project MAGNET Beyond, Deliverable 2.2.1, “Specifications of Interfaces and Interworking between PN Networking Architecture and Service Architectures,” January 2008, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. [33] FP6 IST project MAGNET, Deliverable 2.2.3, “Resource and Context Discovery System Specification,” December 2005, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. [34] http://www.mobicents.org-a.googlepages.com/index.html.

CHAPTER 7

Applications and Application Environments An improved user experience is key to achieving successful businesses. In the mobile communications world, the user experience is enabled by the applications and content on the mobile device. The applications that developers create greatly increase the device usability and enable operators to differentiate their services and charge accordingly, which in turn requires appropriate business models. Open application environments facilitate the development of a consistent suite of applications that can be customized for a diverse community of end users. The integration of an open application environment on top of a consistent architecture minimizes the efforts required to port applications between classes of devices. In order to realize a platform for seamless end-user experience in a global scenario, the connectivity and application features are combined by means of the application program interface (API). The trend of heterogeneity of next generation systems puts a number of requirements on the applications, the APIs, and the mechanisms, enabling a user access to applications and services. As with services, the main challenges for applications are how to ensure and support pervasiveness, how to provide security, privacy, and trust, and how to cope with heterogeneity of technologies. A number of EU-funded projects within the Framework Program Six (FP6) [1–3] focused on improving existing mechanisms and integrating them into novel network structures, on the enabling of fast adaptation of services and applications, on the development of supporting platforms, and on the validations of services and applications. Significant results were achieved by the FP6 IST projects SPICE [4], PLASTIC [5], MOBILIFE [6], MIDAS [7], MAGNET and MAGNET Beyond [8], E2R [9], and some others. This chapter is organized as follows. Section 7.1 introduces the topic of applications and their enablers. Some of the challenges and requirements are outlined on the background of the development trends and the requirements of next generation systems. Section 7.2 describes a framework for service adaptation and application development and validation. The required middleware functionalities and some example applications that can be based on the proposed framework are also described. Section 7.3 concludes the chapter.

409

410

7.1

Applications and Application Environments

Introduction New technologies open up the opportunity for new actors (other than telcos) to provide users with network access, services, and content. Chapter 6 described the requirements and challenges, including some advancements for the service platforms, which are the basic enabler of mobile services and applications [10]. The service provisioning can be divided into the service deployment, service operational management, service usage, and service retirement. The service deployment refers to the process of deploying the service in the service provider’s environment. It includes the steps needed to make the service up and running and ready to be subscribed by end users. The service operational management is the set of processes for managing the services according to the requirements of the users. The service usage means that actions and functionalities are needed when accessing and using a service and includes the service discovery and service chaining mechanisms. The service retirement includes the processes related to disabling and running down a service. The Internet technology is a major technical facilitator for the convergence of the fixed and mobile networks and for the new access-independent service offerings [10]. The service oriented architecture (SOA) is an important architecture to be used in future services. The principle of that architecture is to see an application as a cluster of services, which communicate with each other through messages and platform-independent interfaces. The Web services can be considered as a subset of the SOA [10]. New enabling technologies play a key role in the development of new innovative services and applications for the individual users and user groups. These technologies relate to the topics of personalization, context management, privacy and trust, multimodal interfaces, and so forth. 7.1.1

Enabling Technologies for Services and Applications

Many research and standardization activities worldwide are directly or indirectly focused on research towards the enabling of personalization and context awareness of services and applications to the end users. Development of concepts, requirements, and specifications are being carried out by the Open Mobile Alliance (OMA) [11], the Third Generation Partnership Project (3GPP) [12], and the TeleManagement Forum [13], bodies which are leading the industry in mobile services and application development and IP Multimedia System (IMS) development. The trend towards ad hoc communications and networks and reconfigurability has also put the demand for a more decentralized service environment, where the user cannot always count on operators and other external providers to be available [14]. In order to optimize services, settings, and use of resources for the end user in any given situation, and taking advantage of the user profile, in particular the user’s preferences, and available context information, release policies and access control must be enforced to protect the user’s security and privacy. Sometimes the user will have to rely solely on a trusted, secure, and personal environment and possibly on sharing resources with other users to facilitate tasks. Even under these conditions, support for personalization, context awareness, and

7.1 Introduction

411

privacy protection should be provided. On the other hand, users will also want to access a wide variety of external or foreign services in different domains via the Web or their devices of different types. It is essential to provide a smooth interface to these services (when available), service enablers, and enablers to take advantage of the external support from operators, identity, and personalization providers, whenever it is possible and desirable. Important examples are the IMS and the Generic User Profile (GUP) of 3GPP [12], and the federated identity management proposed by the Liberty Alliance project. In this context, the concept of the user profile (i.e., description of the user, generic information, different types of user preferences, initialization, and maintenance) and the management of the user identity are important enablers of personalization and context management. From a security point of view, the “security role” or “clearance” of a user determines access rights (e.g., the common distinction between normal users, administrators, and super-users), and this is often managed through user IDs, passwords, and certificates. In addition, users take on different social roles and identities, which influence their preferences, capabilities, and settings. The relation between these roles and identities and the mechanisms for switching between them can be based on a manual input, or context-based triggers could be used for switching between different roles and various parts of the user profile. There is a large diversity among users and varying attitudes towards having their personal profiles managed and making use of context information, which should be taken into account when designing service and application delivery platforms and mechanisms. A comprehensive and integrated approach to supporting service and application development, spanning model-based design and validation, and execution platforms are needed. Some of the solutions to enabling this can be summarized as follows [16]: •

•

•

•

A conceptual model for services that enables abstracting from low-level implementation details at the design time, while anticipating critical aspects in the development of robust, distributed, and adaptable services in next generation environments; Integrated tools for developing and validating services that include their own service level agreements (SLAs) through the entire development life cycle; New communication mechanisms that truly take into account heterogeneity and dynamicity of next generation communication environments; Revisiting the traditional service development process in order to delay until deployment or run time the adaptation and validation of services.

Context and knowledge management is a very important feature of a service platform, particularly where services are expected to behave intelligently, learn, exhibit awareness of their surroundings, and react to changes. Context generally refers to all types of information pertaining to a service and or the user of the service. Knowledge refers to more general information, of which context is a specific type. Knowledge would typically include information about users and their preferences and also information that can be inferred from other sources [17].

412

Applications and Application Environments

Context and knowledge management was researched across a number of FP6 IST projects [4, 5, 8, 9, 18]. Some of the topics in focus were: •

•

• • • •

Identification of the use and representation of information using ontologies and other methods; Identification of relevant context information depending on the scenario including description/modeling; The uses of context such as adapting services and networks; Context gathering, interpretation, synthesis, and reasoning; Context publication and discovery; Profiles, negotiation, management, and description.

The dynamic creation and delivery of user services and applications requires an open environment, which allows the application developers and the end users the creation of applications and ad hoc services in an easy and transparent way for both. This in turn implies the need, design, implementation, and delivery of a global software infrastructure of a business-enabled collaborative and dynamic, loosely coupled services [18] and the provision of an infrastructure where end users and third-party service developers can build innovative and integrated services in an easy and interactive way. The infrastructure should support adaptability and composability of services and context awareness regarding users, networks, and terminals. Such a new platform should be based on reliable open source software, by integrating existing technology components and platforms into a unified software infrastructure. At the same time new technologies are necessary to achieve the interworking between the infrastructure elements. An example of a platform that incorporates different enablers of next generation services and applications is shown in Figure 7.1. In order to support the service life cycle of personalized applications, the role of the various actors (i.e., end users, devices, network operators, service providers, content providers, service developers, regulators) must be defined in the value chain. The applications must be decomposed into elementary functionalities and components that can be reused and reorganized to create personalized environments adapted to customers and market needs. With such a support, a business process can invoke simpler services and at the same time enhance performance regarding the individual user’s requirements. A link must be available between the software and hardware architectures, part of an open service and application platform. In the context of the evolution and the strengthening of the role of the grid infrastructure, a service aware network infrastructure should plug in between the SOA and the computing grid and should be foreseen with the necessary resource functions to optimize the data transport and the end-to-end quality in the service delivery. This can be done by enabling the different network nodes involved in the execution of distributed services to become part of the computing grid [18]. Cross-operator and cross-network service availability and service execution are crucial. These need dedicated open software systems and a new abstraction layer between services and execution.

7.1 Introduction

Figure 7.1

413

Example of a service platform for innovative communications environment [4].

The convergence of fixed and mobile network capabilities allows for the creation of services based on the interaction of the capabilities of both, including convergence, compatibility, and mapping between fixed data and mobile data as well as consistency across networks. New concepts for system-to-system communication use service discovery networks where security, authentication, QoS, and charging (including SLA policy handling) must be provided by network operators. The functional tools in support of this are libraries or integrated environments for third parties (e.g., SME, service/content providers, developers). It must be noted that such third parties might not have deep knowledge of the communication infrastructure, just as the end user; therefore, such tools should easily enable the creation of individual services. Security and accounting mechanisms to control the access to an open platform by third parties and end users, both from a functional (service access) and nonfunctional (service creation and management) perspective, are another requirement. Finally, self-management and self-organizing capabilities, especially in the context of distributed network configurations for enhanced structural redundancy and service scalability, are another requirement. The self-awareness provides support for the automatic configuration of devices and services and the local connectivity in the end user’s proximity environment [10]. It also enables automatic and multimodal interfaces that enhance the user experience and minimize the active user effort needed in managing the local environment. The group awareness comprises the context and presence support enabling individuals to interact with each other and to share common artifacts. The services, which are available to end users, are instant messaging, sharing calendar, communities, and presence.

414

Applications and Application Environments

The context awareness is a major building block needed to detect and to reason about the actual context in which an end user or a group may be. In order to exploit the context awareness, the context should be modeled, taking into account identity, spatial, temporal, and environmental information, social situation, and so forth. The distributed nature of contextual information and its incompleteness, semantic variety, and privacy sensitivity make a proper dealing with relevant context difficult. It requires coherent and extendable taxonomies for profiles that accommodate managing the capabilities of the ambient environment [e.g., the dynamics of (ad hoc) group memberships]. An example of leveraging the context awareness is location-based services [10]. The user-centered design (UCD) is an important and fairly new way of developing services for end users. It is a research and product development concept that uses the end-user information in making the products and services. The key idea is to involve the end user in the very early stage of the product or service development process. 7.1.2

Middleware and Enablers

In the SOA paradigm, the entities create capabilities (i.e., services) to provide solutions to the problems that other entities require to be solved. When this paradigm is applied toward distributed computing systems and platforms, one entity’s requirements, where the entity is a software agent (usually referred to as a consumer or a client), can be met by another entity referred to as a provider or service. For an interaction to be possible, entities require visibility, but may and often will belong to different owners or administrative domains. Web services provide standard technologies for the interoperability between various software applications, running on a variety of middleware platforms and/or developed using a variety of programming languages. Examples of Web services are the Web services v1.0, which is specified using three “core” Web service specifications including SOAP, WSDL, and UDDI. Web services v2.0 includes an extensive ever-growing set of Web service specifications, collectively referred to as WS-* specification, and support interoperation, security, reliable messaging, and transactions in loosely coupled systems. In the semantic Web, semantic metadata, including all domain-specific information about content in a specific context or setting and grounded in a domain-specific representation of the concepts for the specific domain using an ontology language or a similar conceptualization representation language, is used as an implicit input to the operations of the system. An ontology is a data model. It is a set of machine-interpretable representations used to model an area of knowledge or some part of the world, including software. An ontology represents a set of concepts within a domain and the relationships between those concepts. It is used to reason about the objects within that domain. Ontologies consist of several concepts. Three key concepts are classes, instances, and relations. Classes are the types of instances. This is similar to object-oriented programming where one can define a class and instantiate an object, whose type is the class of the object.

7.1 Introduction

415

A middleware component is a unit that provides one or more capabilities. Key properties of such a component include the following aspects [4]: • • • • • •

A unique identification; One or more service interfaces of capabilities; Service capabilities described using formal descriptions; Support for common and specific interfaces; Support of stateless or stateful condition; Information about the different execution environments.

A component-based middleware layer for the platform shown in Figure 7.1 is shown in Figure 7.2. Adaptive middleware would use the user preferences during the service selection. Hard preferences (e.g., “never select service x”) would be used during service filtering to remove the unwanted services from the discovered service list. Softer preferences (e.g., “choose cheapest service”) are used during service ranking to rank the remaining services in the filtered list. The ranked service list is then used to select the services, which can run as either atomic services or as part of a composite service. Component publication is the process that a service component follows during the publication of service description metadata into a registry, containing a Discovery Facility, in order to expose its capabilities to potential service consumers [17]. Potential service consumers use the process of service discovery, to execute search queries against the published service descriptions in order to retrieve one or more matching service components based on the input contained in the query. Traditionally, service discovery matchmaking has been based on the use of functional or nonfunctional syntactic searches using keywords or simple regular expressions over the metadata in a service description. The platform in Figure 7.1 can extend the

Figure 7.2

Component-based middleware layer [4].

416

Applications and Application Environments

simple component publication with semantic publication, by providing a means to extend the syntactic searches to include reasoning. Furthermore, it uses additional semantic annotations in order to improve the search results in comparison to only nonsemantic annotation discovery techniques. Semantic publication considers semantic annotations as a new form of metadata that extends the functional and nonfunctional metadata descriptions, such as the components input/output parameters, preconditions, effects, goals, and policies with additional semantics. Semantically published metadata can then be used as an additional input during the processing of a discovery query for matching service components. This extended matchmaking functionality is proved by the use of semantic annotations to the processes of service publication and service discovery within the platform [19]. Thus, the requirement for the middleware is that it should enable the acquisition of components by using semantic publication and semantic discovery features. Before a component resource can be acquired, one fundamental requirement for the enabling middleware is to enable the discovery of the resource by publishing the metadata describing the resource. By leveraging the semantic-based description, metadata techniques, such as concept vocabularies and ontologies, enable diverse classes of component resources to be described and published as a basis for the creation of larger service instances. Thus, the fundamental requirement of the semantic publication is the acquisition of components, whereby the service component descriptions as metadata are made publishable to enable the discovery of the resource and possibly the use in the composition of larger service instances. A semantic publication architecture for service enablers is shown in Figure 7.3. The following functions can be identified: •

•

The Publishing Service function provides an ingress interface for semantic publishing of the service component semantic service description metadata. This interface is exposed to all potential consumers for publishing. The Ontology Transformation Engine function provides a point of advanced processing for the ontological data model (i.e., model transformation) of the service component’s semantic service description metadata.

Publishing service

Ontology transform engine Service description storage

Discovery service

Ontology query transformation engine

Query matchmaker engine

Figure 7.3

Example of a semantic publication architecture [19].

7.2 Resource-Aware Programming for Adaptive Services

•

•

417

The Service Description Storage function provides a storage service where a service component’s semantic service description metadata can be reliably stored and retrieved. The Discovery Service Function provides an ingress interface for semantic discovery of a service component’s semantic service description metadata. This interface is exposed to all potential consumers of discovery.

The service architecture associated with the semantic publication must be open in regard to the types of existing and future metadata technology that it can handle in order to effectively extract the optimal value out of a service component’s semantic service description metadata, while still remaining relevant with regard to the new metadata technology. The use of metadata encoded in platform-neutral formats is based on distributed and service-oriented architectures, such as the Common Object Request Broker Architecture (CORBA) and Web services. Through the addition of semantic information of service capabilities, the semantic Web initiative was launched. One issue in the traditional semantic Web is that there are a number of different groups attempting to define the ontology languages for the semantic Web [19]. These languages allow for the construction of ontologies that can enable their use in the semantic Web stack [20] to be understandable and accessible by machines, but in the disjointed pursuit often effort is duplicated. Not all ontology languages possess the same constructs and expressive power to represent the rich semantics of information. To remain relevant in the future, a semantic publication architecture for service enablers must be able to handle multiple ontologies created using a variety of ontology languages, without the necessary exclusion of any other specification technology that may exist currently or exist in the future. At the same time mobile users are demanding more local computation capabilities as they transition from simple to more complex mobile applications. Middleware-based run-time algorithms can ensure the continuous availability of novel multimedia and streaming applications in scenarios where the node mobility leads to frequent network partitions.

7.2

Resource-Aware Programming for Adaptive Services Ubiquity, context-awareness, and flexibility are the main characteristics of the distributed applications [16]. These will be released over heterogeneous networks (including Wi-Fi, Bluetooth, and cellular networks) and will provide mobile users with seamless access to a variety of networked services. To accomplish this vision, services should be easily deployed on a wide range of evolving infrastructures, from networks of devices to stand-alone wireless resource-constrained handheld devices. Services need to be resource-aware, so that they can benefit from networked resources and related services. Furthermore, these ought to be provisioned in a way that guarantees their dependability. Addressing these challenges ensures that users always experience the best possible quality of service (QoS) according to their specific situation.

418

Applications and Application Environments

A service development platform for lightweight devices interacting in a heterogeneous networking environment was proposed by the FP6 IST project PLASTIC [16]. It is shown in Figure 7.4. The platform in Figure 7.4 allows the design of services intended to run on wireless handheld devices such as smart phones, PDAs, or highly mobile computer devices, but also networking equipments, such as residential gateways. The platform tools can be easily personalized and customers can set up a service platform that best suits their requirements, in particular, regarding the targeted networking environment and the software engineering technologies with which they are normally acquainted. Various service delivery platforms have been proposed (e.g., JAIN, CAMEL, OSA, and IMS, PARLAY). These platforms focus on network-layer services, further introducing infrastructure-centric solutions. The rich networking and processing capacities of end-user devices require truly pervasive services. This further paves the way for innovative services in diverse application domains, bringing mobile services to any user. Considering the application layer, modeling, development, and deployment tools for programming, uploading and instantiating applications, and code on mobile, wireless devices have been in use worldwide by many manufacturers. The major standards in this space include J2ME, OSGi, and others. Java virtual machines, lightweight messaging systems, lightweight Web services tool kits, small-footprint databases for device controllers, and programming environments have been developed. In addition, much research has been conducted in the areas of mobile computing frameworks, mobile grids, and environments for enabling ad hoc communication and integration. The techniques, methods, tools, and programming models are still evolving. However, these are primarily based on horizontal solutions (i.e., for a single layer of the system’s infrastructure).

Figure 7.4

A service development platform for lightweight devices [16].

7.2 Resource-Aware Programming for Adaptive Services

419

For example, the state of the art in resource adaptation and QoS, which is a key feature of mobile adaptive services, addresses the network, middleware, and application layers separately. All architectural elements of the service platform in Figure 7.4 rely on a conceptual model, which provides a shared conceptual foundation for the construction of a service model [19]. It defines the guiding principles and main conceptual elements that should be considered for the rigorous design of an integrated platform for the modeling, analysis, development, validation, and deployment of robust lightweight services that communicate over heterogeneous networks. The platform has three main building blocks: (1) a development environment, (2) a validation framework, and (3) a middleware. 7.2.1

Development Environment

The development environment leverages model-driven engineering for the thorough development of SLA- and resource-aware services, which may be deployed on the various networked nodes, including handheld devices. This is shown in Figure 7.5. By means of the development environment, the functional behavior of the service and its nonfunctional characteristics can be specified. Then the implementation of the service can be obtained by analysis and development activities. For validation purposes, this implementation can be coupled with the service functional interface specification and its service level specification (SLS). The SLS relies on information retrieved by quantitative analysis of the specified service

Figure 7.5

Development environment of a service platform [16].

420

Applications and Application Environments

model. When the requested and offered SLSs match, an SLA is established between the service provider and the service user. The SLA is expressed in a specific language called SLAng, whose specification is publicly available. The language can describe the timeliness constraints, such as latency, reliability, throughput, and availability of the services. It can also be used to determine the time when service providers and service users can reconcile their actual experience in a process that we refer to as the administration of an SLA. As part of that reconciliation service, providers and users will work out whether the QoS that was provided and the service use were in line with the SLA and, in case they were not, then penalty clauses may be evoked to compensate for poor service quality or use of the service beyond agreed limits. SLAng was designed in [5] by using the model-driven development principles of the OMG EMOF and OCL. 7.2.2

Validation Environment

The validation framework enables off-line (i.e., prior to the service deployment) and online (i.e., after the service deployment) validation of the designed and implemented services regarding functional and QoS properties. Off-line validation is performed through advanced model-based techniques, specifically conceived for service-oriented applications. Once the implemented service is validated off-line, an instance of it may be deployed in a particular execution environment. As mentioned above, through adaptation, different instances of the same service may be deployed, each of them suitable for a specific discovered execution environment. Online validation refers to activities that are performed after the service deployment in their productive environment, including the monitoring of functional properties of a composite service, as well as the SLA monitoring. The latter takes into account the SLS embedded in the service implementation. The efficient monitoring of services is possible by means of run-time monitoring of QoS constraints through the SLAngMon tool, which implements a lightweight technology that can dynamically detect violations of extra-functional properties (specified in SLAng) by means of automatically generated online monitors. Events related to the extra-functional characteristics are logged and can be used (e.g., to resolve controversies concerning the SLA violations). The validation framework described here was not conceived as a fixed methodology, but rather as a set of techniques/tools that can be used alternatively or in combination, depending on the constraints and requirements of the considered application [16]. 7.2.3

Middleware Environment

Through the service-oriented middleware, the SOA can be empowered with heterogeneous networking capabilities, in particular enabling adaptive lightweight services to be executed on mobile nodes or access to services over multiradio, multinetwork links. The middleware is capable to enrich the Web service architecture with key features and make the services truly pervasive. This is achieved by taking full benefit of the rich capacities, including multiradio interfaces, of modern wireless devices. The middleware component can be implemented as a layered archi-

7.2 Resource-Aware Programming for Adaptive Services

421

tecture. The lower multiradio networking layer abstracts the multiradio connectivity, selecting the optimal communication link to/from nodes, according to quality parameters. The mid-communication layer allows for communication in the heterogeneous networking environment according to content-based routing (e.g., SOAP or CBR) protocols. The protocol SOAP, in particular, allows for multinetwork routing of SOAP messages as well as group communication over the multiradio links. The CBR protocol provides content-based networking, complementing the traditional unicast and multicast address-based networks, to support the communication modes of the underlying large-scale, loosely coupled, multiparty, distributed applications. The upper middleware services layer then brings advanced distributed resource management functionalities customized for the B3G networking environment, dealing in particular with pervasive service discovery, context awareness, and security. A mobility-aware middleware allows for its functionalities to adapt to the physical mobility of both clients and services, in particular exploiting the rich multiradio, multinetwork connectivity. 7.2.4

Developing and Provisioning Services and Applications

Figure 7.6 shows the process of developing and provisioning services using the adaptive service platform shown in Figure 7.4. A service model involves the specification of both functional and nonfunctional aspects. Based on such a service model, the service process is structured into four main flows of activities, which exploit a UML profile for the service modeling.

Figure 7.6

Service development and provisioning flows [16].

422

Applications and Application Environments

Flow 1 shows the generation of the analysis models, which enable the QoS analysis of the service under development. This flow consists in the QoS analysis process executed starting from the early phases of the software life cycle. The aim of this activity is twofold: (1) to verify the service model with respect to the QoS requirements, and (2) to generate the QoS models (e.g., queuing network) that the service can use later, at run time, to adapt itself when context changes or when the QoS level degrades. The generation and the evaluation of the QoS models are automated and executed by the combination of tools, whereas the interpretation of the results and feedback provision is still a human activity. Flow 2 represents the automated generation of the service implementation. It concerns the development of both the core code and the “adaptable” code of a service. The core code is the frozen unchanging portion of a self-adapting service (e.g., its required/provided interface). On the other side, the adaptable code embodies a certain degree of variability making it capable to evolve (e.g., the logic of a service operation that depends on available resource constraints). This code portion is evolving in the sense that, based on contextual information, the variability can be solved with a set of alternatives (i.e., different ways of implementing a service), each of them suitable for a particular execution context. An alternative is selected by exploiting the analysis models available at run time. Flow 3 represents the off-line validation, which concerns validation at development time. In this phase, the services are tested in a simulated environment that reproduces functional and/or nonfunctional run-time conditions. Flow 4 represents the online validation and generally consists of testing a service when it is ready for deployment and during live usage. In particular, the validation framework supports online validation, by observing the service behaviors during the real execution to detect the possible deviations from the expected behavior. Also, online validation can cover both functional and nonfunctional properties. All these four flows heavily rely on model-to-model and model-to-code automatic transformations [16]. 7.2.5

Example Applications

Several advanced mobile services and applications were designed and developed using the platform tools described previously. 7.2.5.1

E-Business

The field service management (FSM) application permits to dispatch dealer alerts to field workers issued by the service division of a car manufacturer, which is in charge of resolving complex vehicle issues. The application features the distribution of dealer alerts to field workers in the heterogeneous environment, content-based routing of issues within the field force, and adapting issue assignments to the actual context (location, agenda, preferences) of the field workers. 7.2.5.2

E-Health

The application comprises services providing access to medical care at the home and everywhere. Medical information is delivered to the specialist that best fits the condition of the patient. The scenario extensively features heterogeneous networking

7.2 Resource-Aware Programming for Adaptive Services

423

over multiple user devices and the SLA agreement checks among the stakeholders. Through the adaptive service platform, the solution could be simulated and tested prior to deployment on the real network. A scenario implementing an e-health application is shown in Figure 7.7. This application effectively brings mobility to online consultation as follows: 1. Consultation request. The Pocket Doctor scenario starts when a patient triggers a consultation, asking for medical care. For the purpose of this discussion, it is assumed that the consultation is considered to be low risk and not an emergency. 2. Request routing. The consultation is automatically routed according to its content to available and suited mobile health professionals, for example, according to the specialty of the consultation (pediatrics, neurology, allergy), the language to be used, the city of the patient, and so forth. For example, a pediatrician will get only consultations regarding patients that are under a certain age. A clinic might receive consultations based on the location or language or even regarding the consultation itself. Therefore, the consultation is targeted to a professional based on its content and not on a static centralized routing table. This is a first challenge of this scenario: consultations must be routed based on content. After the consultation arrives, the health professionals who are reached can accept or reject it. 3. Chat. The patient will select one of the available professionals to start the diagnosis, according to the ranking of available professionals (see the screenshot on the right of Figure 7.7). The selected health professional chats with the patient to understand the problem.

Figure 7.7

Implementation of an e-health application [16].

424

Applications and Application Environments

4. Diagnosis. The health professional can at any moment choose to cancel the consultation, terminate, and send the diagnosis or redirect the patient to specific health services. 5. Ranking. Once the consultation ends, the patient is asked to rank the health professional, and this evaluation will be processed and the professional ranking mean will be updated for further consultations. It is assumed that both the patient and the client are mobile and connected to next generation networks through their mobile devices (e.g., PDA and smartphone). For example, the health professional may move and get out of range of a Wi-Fi hotspot and enter another one, or he or she may switch from Wi-Fi to a Bluetooth connection. This would require that intersystem handover is performed during the remote diagnosis, and it should be transparent to all users. When many networks are available, the best network should be chosen, in terms of cost, availability, speed, and reliability according to the mechanisms of network access selection (see Chapter 2). The advantages of mobility in this scenario are many. First, mobility enables people living in isolated areas to have access to everyday medical consultations. It also allows health professionals to optimize their time. The approach also benefits from choosing in real time the available professionals that are more adequate to answer a particular consultation. In particular, an elderly person might get details on the dosage of his or her medication without having to call a particular physician. Specific consultations can be done that might reduce the people attending an emergency room. A medical doctor might be productive during the waiting times in the emergency room or when commuting. This application has a strong reliability requirement: The reliability offered must be defined and further verified in a dynamic way and the verification and validation of the systems used must be thorough. The specific challenges of the Pocket Doctor scenario are answered by the adaptive service platform. The service middleware exposes services for content-based routing, which are used by the pocket doctor prototype in order to solve routing consultations to available professionals in a truly distributed way. The middleware also provides services for mobility management, used in the Pocket Doctor prototype to ensure in a transparent way the communication between the mobile devices and over the heterogeneous and changing networks. The middleware thus facilitates the deployment of the solution since it provides a homogeneous and abstracted answer to these problems that are common to mobile implementations. The verification and validation tools can be used to address the reliability requirements through off-line and online validation of the application and services. 7.2.5.3

E-Learning

The e-learning application implements a remote learning scenario, in which mobile users are communicating with each other and with a content repository in order to collaboratively manage the learning content. The main focus on this application uses the platform lightweight security. The application has to be highly adaptive to

7.3 Conclusions

425

prevailing conditions to ensure robustness. For example, a battery switch-off during content downloads is a highly undesirable event. 7.2.5.4

E-Voting

This scenario challenges particularly mobility issues in the context of e-voting services, exploiting heterogeneous networks to provide e-voting services to mobile decision makers, who communicate with heterogeneous mobile devices, such as smartphones or PDAs, in an ad hoc manner. According to this scenario, a group of people (“decision-makers”) are bound to form a decision on a critical and confidential issue, given that a required critical infrastructure is malfunctioning or destroyed. Due to this infrastructure malfunction, it is assumed that the decision-makers have gone mobile, possibly dispersed over a large geographical area. The scenario starts when one of the decision-makers (the “initiator”) decides to initiate an e-voting process, advertising it as a secure service to a limited and trusted set of recipients. The participating mobile users form an ad hoc network, and connectivity and successful voting must be achieved by all possible means, for example, exploiting various networks, maintaining link connectivity in a flexible manner, balancing between resource usage and security in a dynamic and adaptive manner, and so forth. During this process, intersystem handover may be required (e.g., when a user is moving from one place to another and needs to switch over to a better network connection). Another very important issue in this application is providing trust and security. Ensuring confidentiality, secure communication among the mobile users, and fault-tolerant connectivity in this scenario are of paramount importance. The middleware provides the needed services to meet such requirements, while the development environment and validation framework serve guaranteeing the dependability of the application. The software related to the adaptive service platform [16] is released under an open source license and may be used in isolation or in combination, according to requirements of the target application services. It is available for download [21].

7.3

Conclusions The users of next generation systems should be provided with a variety of application services exploiting the network’s diversity and richness, without requiring systematic availability of an integrated network infrastructure. The success of the provided services then depends on the users’ perception of the delivered QoS, which varies along several dimensions, including type of service, type of user, type of access device, and type of execution network environment. To manage these various factors, the network’s diversity and richness must be made available at the application layer, where the delivered services can be most suitably adapted. This demands a comprehensive software engineering approach to the provisioning of services, which encompasses the full service life cycle, including development, validation, deployment, and execution. In response to these needs, a comprehensive

426

Applications and Application Environments

platform for the creation and provisioning of lightweight, adaptable services for the open wireless environment is one possible solution. An efficient context model is a key factor in designing context-aware services. Generic uniform context models are more useful in pervasive computing environments, in which the range and heterogeneity of services is unique. Some of the approaches include key-value models, mark-up scheme models, graphical models, object-oriented models, logic-based models, and ontology-based models. In order for intelligent services to adapt to the end user, gathering and interpretation of contextual information about the user and user environment are required. Such information is obtained from various sources, ranging from sensors on the user terminal to knowledge bases on the service and application platform. The gathered context information is combined and interpreted with reasoning techniques to obtain a higher level view of the situation of the user. Sensors and reasoning components that facilitate this process are distributed throughout the platform, running on a generic middleware framework. Within this framework, each component is specialized in gathering or inferring a particular type of contextual information, often utilizing the results of other components in the process. To discover and exchange information between context gathering and reasoning components, a common data format is needed that defines both the syntax and semantics of the contextual information at hand. Representing this information ontologically ensures that all middleware components have a common understanding of the contextual information that is exchanged. Besides specifying the types of information that can be exchanged, the ontology provides generic mechanisms for expressing the information about the quality of the contextual information. Interesting research questions that the FP6 IST projects managed to raise through their achievements are related to the ways of best defining the context: how to create a universal context ontology and how to unify context and user information, given their different life cycles. These and other questions are in the scope of the FP6 European research.

References [1]

FP6 IST Projects, Cluster of Beyond 3G Architectures, http://cordis.europa.eu/ist/ct/proclu/ p/mob-wireless.htm. [2] FP6 IST Projects at http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm [3] FP6 IST projects in Broadband for All, http://cordis.europa.eu/ist/ct/proclu/p/broadband.htm. [4] FP6 IST Project SPICE, www.ist-spice.org. [5] FP6 IST Project PLASTIC, www.ist-plastic.org. [6] FP6 IST Project MOBILIFE, http://www.ist-mobilife.org. [7] FP6 IST Project MIDAS, www.ist-midas.org. [8] FP6 IST Project MAGNET and MAGNET Beyond, http://cordis.europa.eu/ist/ct/proclu/p/ mob-wireless.htm. [9] FP6 IST Project E2R and E2R II, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. [10] FP6 IST Project MOBILIFE, Deliverable D33, “State-of-the-Art in Service Provisioning and Enabling Technologies,” December 2004, www.ist-mobilife.org. [11] Open Mobile Alliance Group (OMA), www.openmobilealliance.org.

7.3 Conclusions

427

[12] Third Generation Partnership Project (3GPP), www.3gpp.org [13] Telemanagement Forum (TMF), www.tmforum.org. [14] FP6 IST Project MAGNET Beyond, Deliverable 1.2.1, “The Conceptual Structure of User Profiles,” December 2006, www.ist-magnet.org. [15] The Liberty Alliance Project, http://www.projectliberty.org/. [16] FP6 IST Project PLASTIC, “Final Report,” December 2008, www.ist-plastic.org. [17] Mullins, R., et al., “Context and Knowledge Management,” Mobile Service Platforms Cluster, White paper, June 2008, http://cordis.europa.eu/ist/ct/proclu/p/mob-wireless.htm. [18] FP6 IST Project OPUCE, http://www.opuce.tid.es/. [19] FP6 IST Project SPICE, Deliverable 2.2, “Semantic Publication Architecture for Service Enabler Components,” April 2007, www.ist-spice.org. [20] Berners-Lee, T., “Enabling Standards and Technologies—Layer Cake,” 2002, http:// www.w3.org/2002/Talks/04-sweb/slide12-0.html. [21] FP6 IST project PLASTIC Software download at http://www-c.inria.fr/plastic/ softwaredownload/software-download/view.

About the Editors Ramjee Prasad received a B.Sc. in engineering from the Bihar Institute of Technology, Sindri, India, in 1968, and an M.Sc. and a Ph.D. from Birla Institute of Technology (BIT), Ranchi, India, in 1970 and 1979, respectively. Dr. Prasad has a long path of achievement and rich experience in the academic, managerial, research, and business spheres of the mobile communication areas. He joined BIT as a senior research fellow in 1970 and became an associate professor in 1980. While with BIT, he supervised a number of research projects in the areas of microwave and plasma engineering. From 1983 to 1988, he was with the University of Dar es Salaam (UDSM), Tanzania, where he became a professor of telecommunications in the Department of Electrical Engineering in 1986. At UDSM, he was responsible for the collaborative project Satellite Communications for Rural Zones with Eindhoven University of Technology, the Netherlands. From February 1988 through May 1999, he was with the Telecommunications and Traffic Control Systems Group at Delft University of Technology (DUT), where he was actively involved in the area of wireless personal and multimedia communications (WPMC). He was the founding head and program director of the Centre for Wireless and Personal Communications (CWPC) of International Research Centre for Telecommunications and Radar (IRCTR). Since June 1999, Dr. Prasad has held the chair of Wireless Information and Multimedia Communications at Aalborg University, Denmark (AAU). He was also the codirector of AAU’s Center for PersonKommunikation until January 2004, when he became the founding director of the Center for TeleInFrastruktur (CTIF), established as a large multiarea research center on the premises of Aalborg University. Dr. Prasad is a worldwide established scientist, which is evident from his many international academic, industrial, and governmental awards and distinctions, more than 25 published books, numerous journal and conference publications, a sizeable amount of graduated Ph.D. students, and an even larger amount of graduated M.Sc. students. Under his initiative, international M.Sc. programs were started with the Birla Institute of Technology in India, the Insititute of Technology Bandung in Indonesia. Recently, a cooperation was established with the Athens Information Technology (AIT) in Greece. Under Dr. Prasad’s successful leadership and extraordinary vision, CTIF currently has more than 150 scientists from different parts of the world and three CTIF branches in other countries: CTIF-Italy (inaugurated in 2006 in Rome), CTIF-India

429

430

About the Editors

(inaugurated on December 7, 2007, in Kolkata), and CTIF-Japan (inaugurated on October 3, 2008). Dr. Prasad was a business delegate in the Official Business Delegation led by Her Majesty The Queen of Denmark Margarethe II to South Korea in October 2007. He is a Fellow of the IEE, a Fellow of the IETE, a senior member of the IEEE, and a member of NERG. He was the recipient of the Telenor Nordic Research Award (2005), the Samsung Electronics Advisor Award (2005), the Yearly Aalborg-European Achievements Award (2004), and the IEEE Communication Society Award for Achievements in the area of Personal, Wireless, and Mobile Systems and Networks (2003). Dr. Prasad is a member of the steering, advisory, and program committees of many IEEE international conferences. He was the founding chairman of the European Centre of Excellence in Telecommunications, known as HERMES, and is now an honorary chair of HERMES. HERMES currently has 10 member organizations from Europe. Dr. Prasad is the founding cochair of the International Symposium on Wireless Personal Multimedia Communications (WPMC), which has taken place annually since 1999. Dr. Prasad has been strongly involved in European research programs, such as the FP4-ACTS project FRAMES (Future Radio Wideband Multiple Access Systems), which set up the UMTS standard, as a DUT project leader. He was a project coordinator of EU projects during FP5 (CELLO, PRODEMIS) and FP6 (MAGNET and MAGNET Beyond), and is currently involved in FP7. Dr. Prasad was the project leader for several international industrially funded projects with NOKIA, SAMSUNG, Ericsson Telebit, and SIEMENS, to name a few. He is a technical advisor to many industrial international companies, is the founder of the IEEE Symposium on Communications and Vehicular Technoliógy (SCVT) in Benelux, and was the chairman of SCVT in 1993. Dr. Prasad is the founding editor-in-chief of the Springer International Journal on Wireless Personal Communications. He is a member of the editorial board of other international journals and is the series editor of the Artech House Universal Personal Communications Series. Albena Mihovska completed a B.Sc. in engineering at the Technical University of Sofia, Bulgaria, in 1990, followed by an M.Sc. in engineering at the Technical University of Delft, the Netherlands, in 1999. Since then, Professor Mihovska has been with Aalborg University, Denmark, where she is currently an associate professor at the Center for TeleInFrastruktur (CTIF). During her years of employment at Aalborg University, Professor Mihovska gained extensive experience in the administrative and technical management of EU-funded research projects. She also gained experience initializing industrial research cooperation as well as research cooperation funded by the EU. She joined Aalborg University as a research engineer in July 1999 and was appointed to the European Union–funded technical management team within the FP4 ACTS project ASAP until its successful completion in 2001. From September 2001 until April 2005, she was the project coordinator of the European Union–funded FP5 IST project PRODEMIS as a special support action instrument until its successful completion. The project was a main supporting project of the EU IST projects within the

About the Editors

431

mobile and satellite area. The outcome of the project was published as two books by Artech House in 2005, as well as in a number of technical research publications in peer-reviewed journals and conferences, an e-conference on mobile communications, a joint workshop, and a technology roadmap for the future development of mobile communications. From January 2004 until December 2005, Professor Mihovska was the research coordinator of the research team within the EU-funded IST FP6 project WINNER, which continued from January 2006 to December 2007 as WINNER II. The main objective of the project was the design of a new air interface that could be a competitive candidate for next generation systems, in the scope of standardization activities within the IMT-Advanced ITU group. The project was a part of the WWI initiative and, as such, had close and required cross-issue collaboration with the rest of the WWI projects. Professor Mihovska was part of the research teams working toward the identification of the system requirements and the design of interworking mechanisms between the newly designed system and other systems. Within the project, she proposed a concept for cooperation between different systems based on an autonomous decision framework. Based on this research idea, the theoretical approach was put forward as a development activity in the second stage of the project and was successfully demonstrated at a number of international events, including the Wireless Radio Communication (WRC) ’07 Conference held in Geneva from October through November 2007. The experimental setup is now being considered for use in other projects, such as the CELTIC project WINNER+ and the FP7 project FUTON, working toward an architecture design for converging heterogeneous systems and service provisioning in which AAU is a consortium member. Professor Mihovska was part of the research group within the project consortium who developed the final system concept requirements for the air interface. From September 2006 to March 2008, Professor Mihovska was the deputy technical manager of MAGNET Beyond. Therein, she contributed to the overall technical work progress and to the finalization of the MAGNET Beyond Platform system requirements. Further, she was involved in AAU-related research activities in the area of security for personal networks (PNs). Since April 2008, Professor Mihovska has been involved in research activities within the CELTIC project WINNER+, working toward advanced radio system technologies for IMT-Advanced systems. She is conducting research activities within the area of advanced radio resource management, cross-layer optimization, and spectrum aggregation. The work proposed in pursuit of her Ph.D. degree from Aalborg University is a novel concept for interworking between radio resource management entities in the context of next generation mobile communication systems. It is based on research activities commenced prior to and continued within the frames of the WINNER project. The concepts proposed within her Ph.D. thesis have been successfully implemented in the overall WINNER concept and have resulted in a number of peer-reviewed journal and conference publications, including the demonstration activities mentioned above. In addition, she has a number of project-related publications, presentations, and various international and EU events. Professor Mihovska is a reviewer for IEEE Communication Letters and The Springer Journal of Telecommunication Systems. She has been part of the organiz-

432

About the Editors

ing and TPC committees of a number of international conferences, such as WPMC 2002, WCNC 2007, VTC 2008 Spring, the IST Mobile Summits 2002-2007, ATSMA-NAEC 2009, IEEE Mobile WiMAX 2009 Symposium, and several workshops.

Index A Abstractions capability, 77 for RAT specific measurements, 77–81 resource, 78–81 weighted metrics, 81 Access ambient network (A-AN), 69 Access control lists (ACLs), 39, 337 Access correlation lists, 90 Access flows, 70–71 dependencies between, 93 flow qualifiers, 90 multiflow session setup, 91 QoS, 71–77 selecting, 84 setup delay, 75 UML model, 74 Accessibility, 138 Access network utility, 85–86 Access policy manager (APM), 344 Access resource areas (ARAs), 78, 79 Access resources (AR), 69–70 Access selection, 74–77 A-AN during, 76 constraints summary, 105 decision dependence, 89 design trade-off, 75 multiradio (MRAS), 101, 114 objectives, 84–85 procedure, 82–91 rate-based, 88 resource-based, 87 triggering of, 82–83 as two-stage process, 87 Access selection algorithms, 83 discrete services, 85 distributed, 101–2 elastic services, 85 functions, 85–86 implementation of, 84–91 objective, 86

Access service networks (ASNs), 307 Achievable throughput, 138 Active KPIs, 135 Adaptive antenna system (AAS), 305 Adaptive middleware, 415 Adaptive radio multihoming (ARMH), 24–25 Agent discovery, 60 Aggregation networks, 291 Alarms defined, 55 message structure, 220 Ambient Networks (AN) project, 166, 170 dynamic internetworking, 176 service aware transport overlays (SATO), 362 Application layer effects, 142 Application profiles, 38 Application program interfaces (APIs), 409 Applications, 409–26 developing, 421–22 e-business, 422 e-health, 422–24 e-learning, 424–25 enabling technologies, 410–14 e-voting, 425 example, 422–25 FP6 IST projects related to, 409 provisioning, 421–22 resource-aware programming, 417–25 Application service providers (ASPs), 322–23 Architectural/protocol reference models, 323–28 PRM, 327–28 public, 324–26 residential, 327 ATHENA project, 227 Authentication, authorization, and accounting (AAA), 2, 322, 335–39 architecture, 337 auditing and charging (A4C) support, 364 authentication solutions, 337–39

433

434

Authentication, authorization, and accounting (AAA) (continued) defined, 335 DHCP use, 336 PPP use, 335–36 Automatic level control (ALC), 263 Automatic meter reading (AMR), 319, 320 Automatic repeat request (ARQ), 72, 140 to hide random losses, 281 hybrid, 141 loss rate and, 281 for VoIP, 281 Availability, 139

B Backward error correction, 72 Beamforming antenna (BF), 305 Bidirectional service, 88 Bit error rate (BER), 31 Block error rate (BLER), 137 Blocking service, 143–44 Bluetooth and PLC integration, 318–21 AMR extension, 321 business cases, 300 generic data transfer Bluetooth protocol stack, 321 medical surveillance scenario, 320 Border gateway protocol (BGP), 182 Break-before make (BBM) MIP, 97–98 Broadband for All initiative, 3 Broadband over powerline (BPL), 297–321 access multiplexer (BPLAM), 297 cognitive, 297–98 defined, 297 PLC integration, 298–321 Broadband point-to-multipoint (PMP), 266 Broadband satellite multimedia (BSM), 240–44 address resolution, 242, 243 AR architecture, 242 architecture, 240 common open policy service (COPS), 252 gateway, 250 mixed link layer security entities, 251 multicast control mechanisms, 244 multicast ingress ST protocol stack, 246 multicast network scenarios, 244 multicast source management, 243–44, 245 network operator, 244 network security manager, 249 protocol architecture, 241–43 QoS functional architecture, 247–49 QoS functions, 248

Index

security architecture, 249–52 Broadband wireless access (BWA), 266 Broadband wireless local loop (B-WLL), 266 Broadcast networks, 229 Business roles, 322–23

C Call admission control (CAC), 280 Capability aware distance vector routing protocol, 182 Capability aware routing, 92, 93, 181–85 CAPANINA project, 227 Care-of-address (CoA), 58 collocated, 59 local (LCoA), 60 regional (RCoA), 59 Cell load balancing threshold, 107 Cell throughput, 137 Center of gravity (CoG) algorithm, 122 Central CAC, 341 Centralized management system, 260 Channel load report, 122 C-MOBILE project, 362 CODMUCA project, 4 Cognitive BPL (CBPL), 297–98 Combined RRM, 17–18 COMET project, 4 Common Object Request Broker Architecture (CORBA), 417 Common open policy service (COPS), 252 Common RRM (CRRM), 19–21 defined, 19 entities, 19, 20 functionalities, 21 radio resource pool coordination, 20 RRM functions, 21 server, 19, 20, 21 in UTRAN and GERAN, 21 See also Resource management technique (RMT) Component publication, 415–16 Composite applications, 38 Composite wireless network (CWN), 199 Concurrent RRM (ConRRM), 25–26 defined, 25 in loose-coupling architecture, 26 MIB, 25–26 Congestion avoidance control (CAC), 322 Congestion control, 145 DCCP, 145 flow handling interactions, 169 Conjunction points (CPs), 171–76

Index

defined, 171 downstream, 172 routing tables at, 174–76 upstream, 172 Connection admission control (CAC), 339–41 central, 341 local, 341 on-demand, 340 preprovisioned, 340 selective, 340–41 Connection-oriented service, 143 Connectivity provider (CP), 323 Content adaptation nodes (CANs), 366 Context Access Language (CALA), 395 Context-aware composition, 378 Context awareness, 414 Context information base (CIB), 92 Context management, 380–82 service framework (SCMF), 35, 396–403 topics, 412 Context model domain, 370, 371 efficient, 426 example, 370 ontology, 371 Control and Provisioning of Wireless Access Points (CAPWAP), 338 Controlled-loss service, 143 Convergent payload, 263–64 Convergent satellite platform, 259–61 defined, 259 full integration, 260 loose integration, 260 medium integration, 260 network topologies, 270–75 tight integration, 260 See also Satellite networks Cooperative mechanisms, 15–29 approaches, 17–19 combined RRM, 17–18 ConRRM, 25–26 CRRM, 19–21 interworking, 15–17 JRRM, 22–25 layered RRM, 26–28 next generation systems, 28–29 RMT, 18–19 CoopRRM, 49, 51 COPS Policy Provisioning Protocol (COPS-PR), 252 Core networks (CNs), 5 DAIDALOS architecture, 10–12

435

evolution of, 8–15 IP multimedia (IM CN), 8 multihoming, 12–13 routing between, 179–81 seamless integration of broadcast (SIB), 13–14 Core node ID router (CNR), 177 Cross-domain service access, 35–38 Cross-network service availability, 412 Cumulative density function (CDF), 124 delay, 158 for number of visible satellites, 126 performance, 160 of queuing delay, 162 for RMSE, 127 traffic aggregate, 161 Customer premises equipment (CPEs), 322, 329 Cyclic redundancy check (CRC), 72

D DAIDALOS architecture, 10–12 Care of Address (CoA), 12 common interface for triggers, 10 defined, 10 innovation, 11 MMSP, 364 multihoming, 12–13 service platform, 361 universal pervasiveness, 374 VIDid registration, 12 virtual identity (VID) model, 11 Database management system (DDBMS), 380, 381, 382 Datagram Congestion Control Protocol (DCCP), 145 Data-integrity service, 143 Data Source Abstraction Layer (DSAL), 396 Decapsulation, 61 Decision metrics, 93 Deep packet inspection (DPI) enabler, 330–31 Delay-insensitive applications, 73–74 Delay-sensitive applications, 73 Dependability, 138–39 Deployment and life-cycle management, 384 Deployment and run-time environment, 384–86 Development environment, 419–20 Differentiated Services (DiffServ), 154–55 Digital dividend, 230 Digital filter banks (DFB), 298

436

Digital subscriber line access multiplexer (DSLAM), 292 functionality, 292 generation, 294–95 multiple remote, 294 Digital subscriber line (DSL) performance, 290 Digital Video Broadcasting-Terrestrial (DVB-T), 239 Direct spectrum-based UWB (DS-UWB), 311 Discrete-rate applications, 73 Discrete services, 85 Distributed access selection algorithm, 101–2 Distributed decision-making, 101 Distributed Hash table (DHT), 390 Domain name service (DNS), 29 DVB-H, 239 DVB-Return Channel Satellite (DVB-RCS), 239–40, 253 DVB-T2, 239 Dynamic Host Configuration Protocol (DHCP), 336, 337, 338 Dynamic internetworking, 176–90 adjustment of QoS parameters, 186–90 feasibility, 183 internetwork QoS agreements (INQA), 185–86 network capability aware routing, 181–85 node ID architecture, 176 routing between IPv4/IPv6 CNs, 179–81 Dynamic SLAs, 155 Dynamic WFQ (DWFQ), 163, 164, 165

E E-business, 422 Effective isotropic radiated power (EIRP), 263 E-health, 422–24 Elastic applications, 73 Elastic services, 85 E-learning, 424–25 Encapsulation, 61 End-to-end connection, 140 End-to-end flows (EFs), 70 End-to-end latency, 184 End-to-end QoS, 154–55 Enhanced DSL migration towards, 294–95 technologies, 291 Enterprise support, 328–30 security, 328–29 VoIP, 329 VPN, 329–30 Error-sensitive applications, 72

Index

Error-tolerant applications, 72 Ethernet network reference model, 324 E-UTRAN architecture, 6–7 Evolved-UTRAN, 12 Evolving packet core (EPC) network, 6 E-voting, 425 Explicit congestion notification (ECN), 145 Explicit loss notification (ELN), 140 Extended Kalman filter (EKF) tracking algorithm, 128 Extensible Authentication Protocol (EAP), 338

F Fiber-To-The-Building (FTTB), 292, 294 Fiber-To-The-Cabinet (FTTCab), 292, 293, 294 Fiber-To-The-Local-Exchange (FTTEx), 292, 293 Field service management (FSM) applications, 422 File Transfer Protocol (FTP), 142 First-mile networks, 291 Fixed mobile convergence (FMC), 346–52 architecture support, 346 cases, 354 mobility mechanisms, 348 node view, 347 roaming, 350–52 roaming agreement types, 351 roaming scenarios, 350 session continuity, 348 SIP-based mobility, 348–50 user types and, 354 Fixed wireless access (FWA), 232 base stations, 234 ground station, 234 Flat and hierarchical VPLS, 329 Flow-centric addressing, 169–76 Flows addressing, 170 defined, 170 destination endpoint, 175 establishment, 173–74 QoS performance of, 181 Flow state machine, 99 Forward error correction (FEC), 72, 140, 335 Forward link subsystem (FLS), 257 Frame error rate (FER), 31 Frame measurement report, 121–22 Framework Program (FP) 6, 1, 41 EU-funded projects, 41 IST projects, 3

Index

See also specific projects Frequency division multiple access (FDMA), 263 Fresnel zone, 301 Fully qualified domain name (FQDN), 177

G Gateways (GWs), 61 as anchor point, 64 functionality, 62 grouping, 63 logical association, 63 Gauss-Newton (GN) algorithm, 126 General access evaluation algorithm, 107–15 mathematical model, 108 multioperator environment, 109–15 General access selection logic, 107 Generic link layer-interface and context transfer (GLL-ICT), 66 defined, 66 forwarding point (FP), 67 generic interface, 66 monitoring, 67 Generic User Profile (GUP), 411 GLL context anchor (GLL-CA), 67 Global Navigation Satellite Systems (GNSSs), 122–23 optimum conditions, 128 positioning, 127 Global utility, 87 Ground segment, 255–59 regenerative platform, 258–59 transparent platform, 255–58 See also Satellite networks Group awareness, 413

H Handover algorithms, 223 hybrid, 64 intercell, 121 intersystem, 65–66 intracell, 121 intramode, 121 intrasystem, assisted by HIS, 120–28 IP, 61–65 location-based, 116 mobile IP for, 59 radio, 61–65 satellite networks, 275–76 vertical, 116

437

Handover and locator management (HOLM), 56–57 Handover constraint selection SAPs, 94–97 defined, 94 messages, 94–95 request-response signaling sequence, 95 signaling sequence, 96 See also Service access points (SAPs) Handover execution SAPs, 97–99 break-before make (BBM) MIP, 97–98 interaction, 98 See also Service access points (SAPs) Heterogeneity, network, 2–32 Heterogeneous mobility, 58 High-altitude platforms (HAPs), 227, 230–39 access termination (HAT) node, 268 airships, 234 carrier to interference plus noise ratio (CINR), 232 connectivity, 265 content distribution, 266 core network trunk, 266 defined, 230–31 fixed wireless access (FWA), 232 frequency allocations, 231 ground stations, 235 interference analysis, 233, 235–37 interference scenario, 232 interference studies, 237–38 interference studies summary, 238–39 into EESS systems, 235–37 into FWA systems, 233–34 into GSO/FSS systems, 235 into RAS systems, 237 multiple, 267, 268 network topologies, 265–70 nonregenerative architecture, 267 payload, 264 private network, 266 radio broadband system, 266 regenerative architecture, 267, 268 single, 266–67 spectrum-sharing studies, 231 Home subscriber server (HSS), 5–6, 49 Hybrid ARQ (HARQ), 141 Hybrid handover framework, 58–66 intersystem handover, 65–66 mobile IP (MIP), 58–61 radio and IP handover, 61–65 Hybrid information system (HIS), 48–49, 51–53 elements, 118–20

438

Hybrid information system (HIS) (continued) function, 52 illustrated, 52 intelligent service control (ISC), 118 internal data administration, 118–19 intrasystem handover assisted by, 120–28 location-based mobility management, 117 network connection, 53 principle, 51 short, mid-, long-term data, 119–20 See also Location-based mobility management HyperText Transfer Protocol (HTTP), 142

I IMT-A RAN maximum throughput, 222 performance requirements, 215–17 real-time video streaming application quality, 222 results, 219–22 system nodes, 215 system requirements, 213–15 traffic load scenarios, 217–19 Information and communication technologies (ICT), 1 Integrated resource management, 342–43 Integrated Services (IntServ), 154 Intelligent service control (ISC), 118 Interaccess Point Protocol (IAPP), 121 Intercell handover, 121 International Engineering Task Force (IETF), 3 Internet Differentiated Services (IDS), 151 Internet Group Management Protocol (IGMP), 148 Internet Integrated Services (IIS), 151 Internet Key Exchange (IKE) protocol, 251 Internet service providers (ISPs) defined, 323 guarantee, 2, 48 Internetwork QoS agreements (INQA), 185–86 bilateral method, 188 customer-provider network, 187 defined, 185 INQA-VAR, 188, 189, 190 intermediate customer-providers, 188 message types, 185 negotiations, 185–86 roles, 185 routing mechanism, 185–86 Interoperator scenarios, 115 Interplatform link (IPL), 269

Index

Intersystem handover, 65–66 associations during, 66 occurrence, 65 Interworking mechanisms, 15–17 Intracell handover, 121 Intramode handover, 121 IP-connectivity access network (IP-CAN), 8 IP convergence layer (IPCL), 61 IP forwarding, 325, 326 IP multicast, 229 IP multimedia core network (IM CN), 8 IP multimedia system (IMS), 8, 42, 166, 361, 410 interactions with, 403–5 seamless handover, 403 service level registration in, 405 SIP use, 403 towards multiservice networks with, 10 IP network reference model, 324 IP QoS, 278 IPSec, 29

J Joint call admission controller (JOSAC), 23–24 Joint RRM (JRRM), 22–25, 191 adaptive radio multihoming (ARMH), 24–25 architecture, 22 defined, 22 features, 22 functionalities, 22–24 intersystem handover, 22–23 joint call admission controller (JOSAC), 23–24 joint scheduler, 24 load controller, 22 traffic optimizer, 24 See also Radio resource management (RRM) Joint scheduler, 24

K Key performance indicators (KPIs), 18 active, 135 aggregation, 215 calculation, 135–37, 217 classification, 135 defined, 134 measurement, 134 passive, 135 Knowledge management, 412

Index

L LASAGNE project, 3 Latency, 138, 181 end-to-end, 138, 184 round-trip, 138 Lawful Enforcement Monitoring Function (LEMF), 333, 334 Lawful intercept enabler, 333–34 Layered RRM, 26–28 defined, 26 functions, 26, 27 illustrated, 27 scheduler, 26 signaling protocol, 28 See also Radio resource management (RRM) Learning manager, 380 Legacy algorithm model, 105 Lightweight user datagram protocol (UDP-Lite), 73 Link attachment, 69 Load sharing algorithms, 223 Load supervision, 169 Local area networks (LANs), 3 Local CAC, 341 Local CoA (LCoA), 60 Local mobility management (LMM), 10 Local multipoint distribution system (LMDS), 266 Location-based handover, 116 Location-based mobility management, 116–28 HIS, 117 HIS elements, 118–20 See also Mobility management Location determination architecture, 123 Loose coupling, 16

M MAC QoS, 278 MAGNET Beyond project, 362 MAGNET project, 362 MAGNET Service Management Platform (MSMP), 388 high-level SCMF interaction overview, 398 IMS system interactions, 403–5 interaction with PNs, 392 operation security, 392–94 SCMF interaction solutions, 399–403 SCMF interaction with, 397–405 SMN in, 400 Maximum throughput, 138 Maximum transfer unit (MTU), 32

439

Medium access control (MAC), 61, 298 Medium sensing time report, 122 Mesh communications, 273–74 Mesh topology, 244, 250 defined, 244 MAC oriented QoS functional architecture, 279 See also Star topology MIDAS project, 4, 369 Middleware, 368–72 adaptive, 415 defined, 415 environment, 420–21 role, 369 See also Service platforms Mobile IP (MIP), 58–61 architecture, 59 break-before make (BBM), 97–98 entities, 59 for handover, 59 v6 (MIPv6), 58 Mobile networks (MNs) movement paths, 110, 111 number of, 113 population of, 110 Mobile RRM (MRRM), 66–69 access selection, 68 AF, 71 ANF, 68 ASF, 68, 69 CMF, 68, 69 defined, 66 distributed, 68 EF and, 71 entities, 68 example decisions, 80 functionality, 66 resource measures, 80 set management, 76–77 MOBILIFE project, 53 Mobility anchor point (MAP), 59, 268 Mobility management, 54–116 conclusions, 128–29 FP6 IST projects, 47 hybrid handover framework, 58–66 interactions during, 92 interactions in next generation system, 168 introduction, 48–54 location-based, 116–28 multiaccess as key, 115 multiaccess implementation, 100–101 multiple access architecture, 66–93

440

Mobility management (continued) performance evaluation, 101–15 scheme evaluation, 100–115 service access points (SAPs), 94–100 state-of-the-art, 54–55 summary, 115–16 triggers, 55–57 MOTION simulator, 198, 204 Multiaccess architecture implementation, 100–101 Multiband OFDM-based UWB (MB-OFDM UWB), 311 Multicarrier modulations (MCM), 298 Multicast group management, 147–48 Multicast Listener Discovery (MLD), 148, 281 Multicast routing protocols, 148–50, 281 Multicast service, 144 Multicast source management, 243–47 BSM, 245 functions, 245 Multicast transport protocols, 146–47 Multicast trees, 148 Multihoming, 12–13 Multimedia broadcast/multicast service (MBMS), 13–14 Multimedia service provisioning platform (MMSP), 364–66 defined, 364 elements, 364–66 Multiple access architecture, 66–93 abstractions, 77–81 access flows, 70–71 access resources (AR), 69–70 access selection procedure, 82–91 decision metrics, 93 integrated framework, 67 path selection, 91–93 Multiple HAPS platform, 267, 268 Multiple-input multiple-output (MIMO), 305 Multiple protocol label switching (MPLS), 325 Multiprotocol service discovery, 366 Multiradio access selection (MRAS), 101, 114 MUSE project, 287, 322, 323, 347 MWIF OpenRAN Reference Architecture, 5

N Network access providers (NAPs), 307 Network access servers (NAS), 282 Network attachment, 69 Network bandwidth, 181 Network-centric algorithm model, 105 Network interface cards (NICs), 348

Index

Network layer protocols, 147–50 multicast group management, 147–48 multicast routing protocols, 148–50 Network management system (NMS), 257, 260 Network performance characterization, 137–39 accessibility, 138 dependability, 138–39 latency, 138 retainability, 139 throughput, 137–38 See also Performance evaluation Network security privacy, 30 requirements, 29–30 summary, 30 Network service provider (NSP), 322 Network topologies converged satellite systems, 270–75 HAP-based systems, 265–70 star regenerative, 271 star transparent, 271 Network utility, 86 Next-generation mobile networks (NGMN), 240 Next-generation networks (NGNs), 8, 228 architecture, 13 characteristics, 14–15 as packet-based network, 356, 406 residential network and gateway connection, 352 NOBEL project, 3, 287 Node ID architecture, 176 Node ID forwarding tag (NIFT), 177, 178

O On-board processors (OBPs), 250, 261 mesh topology and, 250 payload, 261–62 On-demand CAC, 340 Ontologies, 414 Ontology-aware composition, 378 Ontology-based service discovery, 366–67 Open access networks (OANs), 297 Open Mobile Alliance (OMA), 3, 410 Open shortest path first (OSPF), 265 OPERA project, 287 Optical access, 289–95 DSL performance, 290 enhanced DSL, 294–95 FTTB, 294

Index

RoF, 295–97 xDSL over optics, 291–94 Optical frequency multiplication (OFM), 296 Optimized resource scheduling, 163–65 OPUCE project, 361–62 Organization, this book, 40–42 OWL-S, 375, 387

P Packet scheduling, 155–63 degrees of freedom, 156 discipline requirements, 155–56 generic, 157 queuing, 155 weighted fair queue (WFQ), 158–59 Passive KPIs, 135 Passive optical network (PON) architectures, 289 encryption, 289 extra large (XL), 296 fiber tree, 289 technologies, 288 Path query SAPs, 100 Path selection, 91–93 function, 102 handover decision algorithms, 102 Peer AN (P-AN), 69 Performance evaluation, 101–15 application layer effects, 142 distributed access selection algorithm, 101–2 general access evaluation algorithm, 107–15 network performance characterization, 137–39 simulation model, 102–7 transport layer effects, 139–41 User Datagram Protocol (UDP), 141 See also Mobility management Performance metrics, 134–42 KPI calculation, 135–37 KPI classification, 135 See also Quality of service (QoS) Performance variables, 135 Per-hop-behavior (PHB), 154 Personalization based on user profiles, 33 concept, 32–33 learning system and, 378–80 ontology manager, 378 service platform requirements, 34 Personal networks (PNs), 34 defined, 388

441

Federation (PN-F), 390–92 MSMP components interactions with, 392 service overlay solution, 391 service platforms in, 388–405 Pervasive service platform, 363–68 architectural concepts, 374–88 composition template, 375 context-aware composition, 378 context management, 380–82 deployment and run-time environment, 384–86 management, 374–78 ontology-aware composition, 378 personalization and learning system, 378–80 security and privacy, 382–84 security and privacy management, 377 service discovery, 376–77 session plane, 375 third-party service deployment, 386–88 PIEMAN project, 287 PLASTIC project, 361, 418 PLC/UWB adaptor (PLUBA), 314–15 PN-Federation (PN-F), 390–92 Point-to-Point Protocol over the Ethernet (PPPoE), 326 Policy and charging control (PCC) subsystem, 6 Policy-based architectures, 166–76 flow-centric addressing, 169–76 flow establishment, 173–74 routing table at conjunction point, 174–76 See also QoS architectures Policy-control framework, 343–45 Policy decision function (PDF), 166, 343 Policy enforcement, 341–42 Policy enforcement point (PEP), 38, 386 Policy management, 386 Powerline communication (PLC) integration, 298–321 Bluetooth, 300, 318–21 overview, 298–300 summary, 321 UWB, 299, 310–18 Wi-Fi, 299, 300–304 WiMAX, 299, 304–10 ZigBee, 299 Powerline reference model, 312–13 POWERNET project, 287 Preference condition monitor (PCM), 378 Preference manager, 378 Preprovisioned CAC, 340

442

Priority service, 144 Privacy, 30 Privilege management infrastructures (PMIs), 39–40 Probability density functions (PDF), 124 average delays, 165 delay, 158 for number of visible satellites, 125 for traffic aggregate, 160, 161 Profile information composition, 39 Protocol Extension Protocol (PEP), 278 Protocol for carrying Authentication for Network Access (PANA), 338, 339 Protocol-Independent Multicast (PIM), 149 dense mode (PIM-DM), 149 sparse mode (PIM-SM), 149–50 Protocol independent multicast source-specific multicast (PIM SSM), 326 Protocol reference model (PRM), 327 PSTN/ISDN Emulation Subsystem (PES), 9 Public land mobile network (PLMN), 6 Public reference models, 324–27

Q QoS architectures, 166–90 dynamic internetworking, 176–90 policy-based, 166–76 QoS provision, 133, 142–65 end-to-end, 154–55 EVEREST approach, 167 in IP networks, 142–65 network layer protocols, 147–50 optimized resource scheduling, 163–65 packet scheduling, 155–63 qualitative, 151–54 quantitative, 151–54 requirements and parameter, 150 transport layer protocols, 142–47 QoS testing, 190–222 real-time simulation, 190–91 results, 219–22 RRM mechanisms, 209–19 virtual distributed testbed (VDT), 191–209 Qualitative QoS, 151–54 Quality of experience (QoE), 345–46 aspects, 345–46 defined, 345 measurable, 346 Quality of service (QoS), 2, 31–32, 41, 133–223 access flows, 71–77 access selection, 74–77

Index

agent, 278 application layer effects on, 142 application requirements, 71–74 for broadband communications support, 339 cooperation architectures, 134 delivery, 133 end-to-end, 154–55 error control, 71–74 evaluation, 31 flow performance, 181 functional architecture, 247–49 guaranteed, 31 introduction, 133–65 IP, 278 MAC, 278 management, 50–51 models, 71–77 overheads in, 32 parameters, 150 parameters, adjustment of, 186–90 parameters, ratios, 163 performance metrics, 134–42 policing parameters, 169 qualitative, 151–54 quantitative, 151–54 RAC-based architecture, 343 requirements, 150 satellite networks, 276–81 server, 278 supporting algorithm validation, 223 transmission errors, 71–74 transport layer effects, 139–41 See also QoS architectures; QoS provision; QoS testing Quantitative QoS, 151–54 Queue identifiers (QIDs), 249 Queuing, 155, 264–65

R Radio access networks (RANs), 2, 5, 48, 166 emulated reference, parameters, 214–15 evolution, 4–7 legacy, 213 operator, 62 policy enforcement, 62 WINNER architecture, 7 Radio access terminals (RATs), 116 Radio link control (RLC), 61 Radio network controllers (RNC), 2, 4 Radio network gateways (RNGs), 5 Radio over fiber (RoF), 295–97

Index

Radio resource control (RRC) protocols, 49, 61 Radio resource management (RRM), 2 combined, 17–18 common (CRRM), 19–21 cooperative framework, 50 joint (JRRM), 22–25 management techniques (RMTs), 212 mechanisms, 209–19 mobile (MRRM), 66–69 real-time implementation, 211 reference protocol architecture, 28, 29 specific (SRRM), 28–29, 49, 213 Rate-based access selection, 88 Real Time Control Protocol (RTCP), 146 Real time measurement reports (RTTMs), 65 obtaining, 65 summary, 221 Real Time Protocol (RTP), 145–46, 334 Real-time simulation, 190–91 Received power histograms (RPIs), 121 Received signal strength (RSS), 121 Reference and synchronization subsystem (REFS), 258 Regenerative payload, 261–62 Regenerative platform, 258–59 functional architecture, 258 subentities, 258–59 See also Ground segment Regional CoA (RCoA), 59 Regional network provider (RNP), 322 Registration, 60–61 Remote Authentication Dial In User Service (RADIUS), 337 Rendezvous server (RVS), 177 Residential gateway (RGW), 332 authentication, 354 data switching, 354 IP-Host, 353 legacy interfaces, 353 Residential networks, 352–56 Residential reference models, 327 Resource abstraction, 78–81 Resource-aware programming, 417–25 development environment, 419–20 middleware environment, 420–21 validation environment, 420 Resource-based access selection, 87 Resource dependency management, 385 Resource management technique (RMT), 18–19 defined, 18–19

443

examples, 19 Resource reservation, 280 Resource Reservation Protocol (RSVP), 154 Retainability, 139 Return link subsystem (RLS), 257 Roaming, 350–52 Round-trip delay, 138 Router alert option (RAO), 173 Routing capability aware, 92, 93 hints, 177 INQA, 185–86 between IPv4/IPv6 core networks, 179–81 QoS-based connection setup, 280

S Satellite Action Plan Regulatory Group (SAP REG), 228 Satellite networks, 227–85 common equipment, 259 conclusions, 283–85 convergent satellite platform, 259–61 emerging standards, 239–52 FP6 IST projects, 227 functional layers, 254 ground segment, 255–59 handover, 275–76 high altitude platforms (HAPs), 230–39 interworking, 275–83 interworking between layer 2/layer 3, 281–82 introduction, 228–52 mobility, 275–76 protocols, 254–55 QoS, 276–81 satellite payload, 261–65 security, 282–83 WiMAX, 276 Satellite payload, 261–65 convergent, 263–64 HAPS, 264 queuing, 264–65 regenerative, 261–62 transparent, 262–63 SATSIX project, 4, 227 MPEG and ATM profiles, 254 regenerative platform architecture, 254 regenerative user plane protocol stack, 255 transparent platform architecture, 253 transparent user plane protocol stack, 255 Scalability properties, 187

444

Scalability (continued) simulation setup for analysis, 186 Seamless integration of broadcast (SIB), 13–14 Secure sockets layer (SSL), 29 Security enterprise support, 328–29 functional architecture, 284 gateway (SEG), 38 link layer, 282 parameter indexes (SPIs), 60 pervasive service platform, 382–84 satellite networks, 282–83 service, 144 Selective acknowledgments (SACK), 140 Selective CAC, 340–41 Self-awareness, 413 Self-management, 413 Semantic knowledge management, 369 Semantic publication, 416–17 defined, 416 functions, 416–17 for service enablers, 416 Service access points (SAPs), 94–100 assured forwarding (AF), 155 functionality at, 94 handover constraint selection, 94–97 handover execution, 97–99 path query, 100 trigger procedure, 94, 95 types, 94 See also Mobility management Service adaptation, 35 Service assistance nodes (SANs), 389 Service aware transport overlays (SATO), 362 Service classes, 152–53 Service context management framework (SCMF), 35, 394 abstraction layers, 396 general view, 396 high-level MSMP interactions, 398 MSMP interaction, 397–405 MSMP interaction solutions, 399–403 SDM interaction, 399 service ontology and, 400 Service discovery, 376–77 architecture (SDA), 366 defined, 376 functionalities, 376–77 multiprotocol, 366 ontology-based, 366–67 service instance, 376 types, 366–67

Index

Service Discovery Adaptation sub-Layer (SDAL), 390 Service Discovery Protocol (SDP), 320 Service enablers, 330–35 deep packet inspection (DPI), 330–31 lawful intercept, 333–34 session border controller (SBC), 331–33 video service, 334–35 Service-level agreements (SLAs), 2, 154, 259, 343 dynamic, 155 static, 155 Service Level Execution Environment (SLEE), 405 Service-level specifications (SLSs), 154, 419 convergence time and, 191 provider-network, 186 satisfied applications ratio and, 190 Service life-cycle manager, 361–62 Service management node (SMN), 388 AAA Module, 392–93 active cluster information, 402 IMS system interactions, 403–5 interactions through UPnP, 402 security profile and policies, 393–94 Service ontology manager, 378 Service operational management, 410 Service-oriented architecture (SOA), 37, 410 Service platforms, 32–40, 361–406 applications, 38–40 architectural concepts, 374–88 business impact, 372–74 cross-domain service access, 35–38 FP6 IST projects, 361–62 introduction, 362–74 for lightweight devices, 418 middleware, 368–72 multiple heterogeneous execution, 36 for personalization, 34 pervasive, 363–68 in PNs, 388–405 service adaptation, 35 summary, 40 Service provisioning, 410 Service radio network subsystem (SRNS), 5 Services, 361–406 adaptation of, 406 advertisement retrieval, 377 composed, 373 context operators, 371 developing, 421–22 enabling technologies, 410–14

Index

registration/deregistration, 376–77 Service utility, 85 Serving access points (SAPs), 61 Session border controller (SBC) enabler, 331–33 defined, 331 distributed architecture, 331 motivators for decentralization, 332 See also Service enablers Session initiation protocol (SIP), 15 advantages, 349 functional mobility architecture, 280 IMS use, 356, 403 mobility, 348–50 QoS-aware application use, 280 SIMPLICITY project, 35, 36 Simplified user profiles (SUPs), 35 Simulation model, 102–7 assumptions, 104 constraints, 102 legacy, 105 legacy algorithm, 103 network-centric, 105 network constraints, 103 terminal-centric, 104 terminal constraints, 103 See also Performance evaluation Single-HAPS platform, 266–67 SIP proxy, 278 Software-defined radio (SDR), 229 Spatial aggregation, 135 Specific RRM (SRRM), 28–29 functionality, 213 module, 49 See also Radio resource management (RRM) Spectrum sharing, 231 SPICE project, 36 architecture layered design, 37 capabilities and enablers layer, 36–37 component services layer, 37 open service platform, 361 platform capabilities, 36 value added services (VAS), 37 Star communications, 274 Star topology, 244 connections, 275 functional mobility architecture, 277 QOS functional architecture, 279 regenerative network, 271 transparent network, 271 See also Mesh topology

445

STA statistics report, 122 Static SLAs, 155 Status-reporting, 144 Stream Control Transmission Protocol (SCTP), 145 Subflows defined, 171 obsolete, 174 See also Flows

T TeleManagement Forum, 410 Terminal-centric algorithm model, 104, 107 Third Generation Partnership Project (3GPP), 3, 410 core IMS specifications, 9 distributed architecture, 5, 6 E-UTRAN architecture, 6–7 OPEN RAN architecture, 6 Throughput, 137–38 achievable, 138 IMT-A RAN, 222 maximum, 138 types, 137 Tight coupling, 16 interworking architecture, 17 scenario, 16–17 very, 17 Traffic conditioning agreements (TCAs), 154 Traffic load scenarios (TLSs), 210, 217–19 generation and selection process, 219 as indicator, 217 logical tree, 218 in real-time implementation, 217 Traffic optimizer, 24 Transmission Control Protocol (TCP), 139–40 Transparent payload, 262–63 Transparent platform, 255–58 Transparent ring connection, 3 Transport layer effects, 139–41 Transport layer protocols, 142–47 Datagram Congestion Control Protocol (DCCP), 145 error detection, 144 flow control, 144 multicast, 146–47 Stream Control Transmission Protocol (SCTP), 145 Transport layer security (TLS), 29 Transport layer services, 142–44 blocking, 143–44 connection-oriented, 143

446

Transport layer services (continued) controlled-loss, 143 data-integrity, 143 multicast, 144 no-duplicates, 143 priority, 144 security, 144 Trigger procedure SAPs, 94, 95 Triggers, 55–57 defined, 55 format, 55 generation, 121 high-level architecture, 56 management system, 55 TRIUMPH project, 3

U U-AN, 69, 70, 76 Ultrawideband (UWB) communication system, 310 direct spectrum-based (DS-UWB), 311 multiband OFDM-based (MB-OFDM), 311 Unidirectional lightweight encapsulation (ULE), 252 Unique service identifier (UUID), 401 UNITE project, 198 central controller, 199 VDT, 191 Universal Terrestrial Radio Access (UTRA), 55 UPnP, 401, 402 User-centered design (UCD), 414 User datagram protocol (UDP), 72 defined, 141 RTP and, 334 User network utility, 85 User profiles, 33 User throughput, 137 User utility, 85 UWB and PLC integration, 310–18 access PLC/UWB modem placement, 314–18 business cases, 299 PLC/UWB adaptor (PLUBA), 314–15 powerline reference model, 312 UWB signal propagation, 319 UWB signals over PLC channels, 312 wireless extension of PLC, 313–14

V Validation environment, 420 Value-added services (VAS), 362–63 Very long baseline interferometry (VLBI), 230

Index

Very tight coupling, 17 Video on demand (VoD), 259 Video service enablers, 334–35 Virtual distributed testbed (VDT), 191–209 admission control module, 195 architecture, 192–93 components, 192 defined, 191 event-based logic, 192 experimental setup, 198–209 experimental setup illustration, 199 handover control module, 195 module integration, 193 RAT module, 194, 200 RRM module, 195 service and session description, 196–97 services, 196 services support, 193–94 session description example, 197 simulation plan editor, 197 terminals addressed by, 193 terminals connectivity, 197–98 testbed controller, 192 time management, 194 See also QoS testing Virtual local area networks (VLANs), 324–25 Virtual private networks (VPNs), 2, 263 enterprise support, 329–30 need for, 328 Virtual Satellite Networks (VSNs), 263, 264 VIVALDI project, 3–4, 227 VoIP ARQ for, 281 for SMEs, 329

W Wavelength division multiplexing (WDM), 291 Weighted fair queue (WFQ) scheduler, 158–59 analysis with, 158 bandwidth allocation, 159 Weighted metrics, 81 Weighted sum, 93 Wide area networks (WANs), 3 Wi-Fi and PLC integration, 300–304 business cases, 299 PLC as complement, 303–4 PLC backbone, 300 technical requirements, 304 Wi-Fi backbone, 302 Wi-Fi router, 302–3

Index

See also Powerline communication (PLC) integration Wi-Fi routers, 302–3 WiMAX antenna technology, 306 application sectors, 305 base stations (BS), 306, 307 coverage, 305 frequency, 305 operator, 308, 309 point-to-point capability, 308, 310 simulator, 198, 201 WiMAX and PLC integration, 304–10 business cases, 299 PLC as in-building communication, 308–9 technical requirements, 309–10 WiMAX backbone/backhaul for PLC connections, 306–8 WiMAX backbone/backhaul for PLC distribution, 308 WINNER II project, 227

447

WINNER project, 53, 120, 166, 227 radio access network (WRAN), 7 TDOA measurements, 128 Wireless local area networks (WLANs), 40 performance comparison, 211 privately owned, 287 for public areas, 303 Wireless personal area networks (WPANs), 362 World Wireless Initiative (WWI), 53

X xDSL, 291–94 illustrated, 292 over optics, 291–94 XL-PON, 296

Z ZigBee with PLC, 299

The Artech House Universal Personal Communications Series Ramjee Prasad, Series Editor 4G Roadmap and Emerging Communication Technologies, Young Kyun Kim and Ramjee Prasad 802.11 WLANs and IP Networking: Security, QoS, and Mobility, Anand R. Prasad and Neeli R. Prasad CDMA for Wireless Personal Communications, Ramjee Prasad From WPANs to Personal Networks: Technologies and Applications, Ramjee Prasad and Luc Deneire IP/ATM Mobile Satellite Networks, John Farserotu and Ramjee Prasad Multicarrier Techniques for 4G Mobile Communications, Shinsuke Hara and Ramjee Prasad New Horizons in Mobile and Wireless Communications, Ramjee Prasad and Albena Mihovska, editors Volume 1: Radio Interfaces Volume 2: Networks, Services, and Applications Volume 3: Reconfigurability Volume 4: Ad Hoc Networks and PANs OFDM Towards Broadband Wireless Access, Uma Shanker and Jha Ramjee Prasad OFDM for Wireless Communications Systems, Ramjee Prasad OFDM for Wireless Multimedia Communications, Richard van Nee and Ramjee Prasad Practical Radio Resource Management in Wireless Systems, Sofoklis A. Kyriazakos and George T. Karetsos Radio over Fiber Technologies for Mobile Communications Networks, Hamed Al-Raweshidy and Shozo Komaki, editors Simulation and Software Radio for Mobile Communications, Hiroshi Harada and Ramjee Prasad Space-Time Codes and MIMO Systems, Mohinder Jankiraman TDD-CDMA for Wireless Communications, Riaz Esmailzadeh and Masao Nakagawa Technology Trends in Wireless Communications, Ramjee Prasad and Marina Ruggieri Third Generation Mobile Communication Systems, Ramjee Prasad, Werner Mohr, and Walter Konhäuser, editors Towards a Global 3G System: Advanced Mobile Communications in Europe, Volume 1, Ramjee Prasad, editor Towards a Global 3G System: Advanced Mobile Communications in Europe, Volume 2, Ramjee Prasad, editor

Towards the Wireless Information Society: Heterogeneous Networks, Ramjee Prasad, editor Towards the Wireless Information Society: Systems, Services, and Applications, Ramjee Prasad, editor Universal Wireless Personal Communications, Ramjee Prasad WCDMA: Towards IP Mobility and Mobile Internet, Tero Ojanperä and Ramjee Prasad, editors Wideband CDMA for Third Generation Mobile Communications, Tero Ojanperä and Ramjee Prasad, editors Wireless Communications Security, Hideki Imai, Mohammad Ghulam Rahman and Kazukuni Kobara Wireless IP and Building the Mobile Internet, Sudhir Dixit and Ramjee Prasad, editors WLAN Systems and Wireless IP for Next Generation Communications, Neeli Prasad and Anand Prasad, editors WLANs and WPANs towards 4G Wireless, Ramjee Prasad and Luis Muñoz For further information on these and other Artech House titles, including previously considered out-of-print books now available through our In-Print-Forever® (IPF®) program, contact: Artech House

685 Canton Street Norwood, MA 02062 Phone: 781-769-9750 Fax: 781-769-6334 e-mail: [email protected]

Artech House 16 Sussex Street London SW1V 4RW UK Phone: +44 (0)20 7596-8750 Fax: +44 (0)20 7630-0166 e-mail: [email protected]

Find us on the World Wide Web at: www.artechhouse.com