Tse Ss2004 Notes

I
Stephan Rupp Gerd Siegmund
Telecommunication Software Engineering
Lecture Notes Edition: V 0.2, December 20, 2006
Copyright 2004 by Stephan Rupp and Gerd Siegmund Reproduction is not permitted without the consent of the authors.
Contact: srupp@srupp.de Homepage: http://www.srupp.de
II
Foreword
III
Foreword
This manuscript originates from lecture notes of joint and individual activities of the authors in 2004. Also, it is based on material the authors have used in other publications. The topic has been inspired by the opinion, that telecommunication is becoming a core discipline of information technology, along with data bases or operating systems. Telecommunication software represents a natural follower of the microprocessor: Most systems do not operate in isolation, but are in communication with others. What information technology can benefit from telecommunications are solid engineering methods and the design of complex systems. Engineering practice in telecommunications today incorporates new technologies such as Web-Engineering, novel applications of data bases and storage systems, as well as the object oriented frameworks and methods for the development of applications. While this goes well beyond the traditional design of functional architectures, it is still rarely reflected in textbooks about engineering methods in telecommunications. This manuskript intends to address software engineering in a modern telecommunication environment. It is organised in 6 chapters, which are largely self contained and may be read independently from each other. In the same way, single chapters may be used as material to supporting training or lectures. Chapter 1 is a summary of telecommunication networks and mobile networks. Someone familiar with this may directly proceed to chapter 3, which is about distributed computing. Chapter 6 is about security. Chapters 1, 3 and 6 represent an entry level of the material. The other parts move deeper into specific subjects: chapter 2 covers protocols and protocol engineering, chapter 4 is about services architectures within the network and on terminal devices, and chapter 5 explains methods for software engineering. The exercises are organisaed in the same way: Part 1 of the exercises follow the entry level tour, part 2 covers the complete manuskript. In total, the focus is on basic concepts and on methods. In chapters 1 to 6, concepts and methods are developed close to reality, or at least shown in a practical or realistic context. The exercises follow a more conventional approach. They stay on an abstract level, but also are aimed to show the basic concepts and methods. Acknowledgements: Leonhard Stiegler has made available the practical case for protocol conformance tests in section 2.4. The summary of the Bluetooth protocol stack in section 2.5 has been provided by Harald Orlamuender, who also has contributed on CORBA and Web-Services in section 3.2.5. Chapter 6 is based on a large extent on material provided by Matthias Duspiva. Xuepeng Tan has provided the material on the development environment in section 5.3. The service architecture
IV
Foreword
which is presented in chapter 4 contains many creative ideas from Rodolfo Lopez-Aladros and Franz-Josef Banet.Thanks to all of them for their contributions and for frequent discussions. Klaus Jobmann of the institute for Communication Technologies (IANT) at the university of Hannover has encouraged us on the service architecture, we thank for his continuous support. Many thanks to Paul Khn and the Institute for Communication Networks and Computer Engineerings (IKR) at the university of Stuttgart for hosting the lecture and for their contributions on modelling and simulation.
Stuttgart, July 2004
Stephan Rupp
Gerd Siegmund
Note on Edition 0.2, December 2006: After the 3rd term, the exercises have been updated. The exercises include the examinations within the first 3 years of the lecture. Each examination consists of two tasks with maximum 8 questions according to the following logic: Exercises 7.2.14 and 7.2.15: Trial examination 2004 Exercises 7.2.16 and 7.2.17: Examination 2004 Exercises 7.2.18 and 7.2.19: Examination July 2005 Exercises 7.2.20 and 7.2.21: Examination October 2005 Exercises 7.2.22 and 7.2.23: Examination July 2006 Exercises 7.2.24 and 7.2.25: Examination October 2006 Stuttgart, December 2006 Stephan Rupp
How this book is organised
Chapter 1 - Telecommunication Networks The first chapter represents a summary on communication networks with emphasis on 2G (GSM, GPRS) and 3G (UMTS). It explains the general structure of telecommunication networks and what happens, when a mobile phone is switched on or when a call is initiated. Also it explains the design principles of telecommunication networks and of services in telecommunication networks. Chapter 2- Protocol Engineering ? When terminals or network elements communicate with each other, they are exchanging messages in a specific context and according to specified rules. Chapter 2 explains the concept of such protocols at different levels ? of abstraction.The chapter contains the ISO/OSI Reference model, state diagrams, data flow diagrams, the basics and a practical test for protocol conformance testing and a summary of the the Bluetooth protocol stack as a practical example.
Chapter 3- Network Organisation ? How may functions be separated and allocated to different network elements or terminal equipment? Chapter 3 explains the difference of distributing functions within one system and distributed systems, summarises the corresponding technologies, and explains the basic principles of service discovery and and organisation of networks. It also introduces the perspective of an application programmer on connections and on using middleware to handle distribution of functions in order to develop services.
VI
Chapter 4- Service Architectures What do modern terminals such as mobile phones and ? network elements provide for the development of services and applications? Chapter 4 has a look at traditional functional design, design while using a service archisoftware tecture based on distributed computing, as well as the application frameworks available at modern terminal devices. At abstract level, chapter 4 explains how resources for computing, storage and network capacity are handled. It then shows a representative practical case for a service architecture (a virtual HLR/VLR) and the application framework of a mobile phone (based on Symbian operating system). Chapter 4 introduces class diagramms and message sequence diagrams. Chapter 5- Engineering Methods for Services While Chapter 4 is focussed on what the network elements provide for software development, Chapter 5 has a look at the methods for software development and at the development process. The basics of how to apply the ? software Universal Modelling Language (UML) are shown by supplementing the diagrams which have already been shown in Chapter 2 and 4 by introducing use cases, activity diagrams, and package diagrams. Concerning the development process, the components needed for a prototype development (development environment and runtime environment) are shown. While Chapter 5 cannot provide a comprehensive view of tools and process, the target is to give an idea about the practicalities of software development. Chapter 6- Security for Services and Applications While we increasingly carry communication devices with us and are inceasingly living in an environment ready to communicate with us, security with respect to the design of software and the handling of software is becoming increasingly important. Chapter 6 explains the security threads and countermeasures within the network as well as for terminals. It introduces the basic prionciples such as active attacks, passive attacks, protective measures, sandboxes for software, signed content, secure connections and how cryptography is applied. Exercises Part 1 - Entry Level This book may be used in two levels: Chapters 1, 3 and 6 Chapter 1 Chapter 6 provide the entry level (i.e. without going deeper into Chapter 3 protocols and software engineering, but covering the basic principles about networks, distribution of functions and security). Part 1 provides the corresponding exercises.
VII
Exercises Part 2 - Complete Manuscript Part 2 of the exercises provide a deeper level including protocols, systems design and the basics of software engineering. For self-study, it may be recommendable to do Part 2 after Part 1 of the exercises. For training or lecture, the sequence does not really matter. Web-Site of the book It is planned to provide the illustrations, exercises and more supporting material on a web-site. For the time being, the material used in the lecture of 2004 can be retrieved from: http://www.ind.uni-stuttgart.de/Content/Courses/Overview/SS-2004.html
Chapter 1
Chapter 6 Chapter 2 Chapter 5
Chapter 3
Chapter 4
WWW
VIII
Table of Contents
1 1.1
1.2
1.3
1.4 1.5
1.6 1.7
1.8
Telecommunication Networks 1 Introduction 1 1.1.1 Circuit switched networks and packet switched networks 2 1.1.2 Access networks and core networks 5 1.1.3 Services and applications 9 Terminology 12 1.2.1 Communication model 13 1.2.2 Connections 14 1.2.3 The architecture of telecommunication networks 15 Concepts for Switching and Routing 18 1.3.1 Connection orientet exchange of messages 18 1.3.2 Connectionless exchange of messages 19 1.3.3 Circuit switched connections 19 1.3.4 Store and forward routing 22 1.3.5 Message switching (datagram service) 23 1.3.6 Cell based connections (ATM) 23 Mobile communication networks 24 1.4.1 Summary of mobile communication systems 24 1.4.2 Basics of radio transmission and cellular networks 26 GSM - Global System for Mobile Communication 28 1.5.1 Basic architecture 28 1.5.2 Services 29 1.5.3 Establishment of connections 30 1.5.4 Interfaces and Protocols 33 1.5.5 Addressing and Identification of subscribers 34 1.5.6 Sequences in calls and connections 36 GPRS - General Packet Radio Service 41 1.6.1 Summary 41 1.6.2 Architecture 42 UMTS - Universal Mobile Telecommunication System 43 1.7.1 Architecture 44 1.7.2 UMTS Phase 1 (Release 3 or Release 99) 46 1.7.3 UMTS Phase 2 (Release 4/5) 47 1.7.4 UMTS Service Areas 48 1.7.5 Identities and Security Aspects in UMTS 49 1.7.6 UMTS Services 50 Web based service architectures 51 1.8.1 Traditional architectures for services 52 1.8.2 Object oriented software design 54 1.8.3 Web-Services and distributed computing 56 1.8.4 A challenge for a new service architecture 60 Protocol Engineering 63 Processes and Protocols 63 2.1.1 ISO/OSI Reference Model 64 2.1.2 Numbers and Addresses 70 2.1.3 Communication Processes and Protocols 71 Formal Specifications 73 -V-
2 2.1
2.2
2.3 2.4
2.5
2.6
2.2.1 Formal Methods 73 2.2.2 Finite State Machines 75 2.2.3 Specification and Description Language (SDL) 75 Formal Verification 77 Implementation and Tests 79 2.4.1 Hardware and Software Design 80 2.4.2 Model of a protocol stack 81 2.4.3 Protocol Tests 82 A practical case: INAP conformance tests 84 2.5.1 Conformance testing concepts 84 2.5.2 INAP interface test configuration 85 2.5.3 Protocol Tracer Configuration 92 2.5.4 Sample Message Trace 93 The Bluetooth Protocol Stack 95 2.6.1 Bluetooth Radio Technology 95 2.6.2 Networking 97 2.6.3 Protocols 99 2.6.4 Profiles and Service Discovery Protocol (SDP) 104 Network Organisation 107 Basic Principles 107 3.1.1 Communication and Context 107 3.1.2 Service Discovery and organisation of networks 113 Some Concepts in Practice 116 3.2.1 JXTA networks 117 3.2.2 Bluetooth Service Discovery 119 3.2.3 Java RMI and JINI 121 3.2.4 J2ME MIDP 2.0 125 3.2.5 CORBA and Web-Services 127 3.2.6 Universal Plug and Play 131 Export and Import of Functions 131 Service Architectures 133 Introduction 133 4.1.1 Resources: Storage, Computing, Network 134 4.1.2 Centralised Data in Communication Networks 135 4.1.3 Framework Protocols 140 Network Service Architecture 144 4.2.1 Concept 145 4.2.2 Data Interface 147 4.2.3 Application Interface 151 4.2.4 Consolidation of Interfaces 152 Data Models and Semantic Models 154 Terminals and Embedded Systems 154 4.4.1 Symbian Architecture 154 4.4.2 Client and Server Threads 157 4.4.3 GUI Framework 160 4.4.4 Data Storage 162 4.4.5 Communication Framework 163 4.4.6 Messaging Framework 169 Engineering Methods for Services 173 Introduction 173 Engineering Services with UML 174 5.2.1 A sample application 174 5.2.2 Summary of popular UML diagrams 180 5.2.3 Tests 181 Development Tools and Process 182 - VI -
3 3.1 3.2
3.3 4 4.1
4.2
4.3 4.4
5 5.1 5.2
5.3
5.4 6 6.1
5.3.1 Development Environment 182 5.3.2 Runtime Environment 184 5.3.3 Development Cycles 185 Plug-ins and Bundles 187 Security for Services and Applications 189 Sandbox and Middleware 189 6.1.1 The Java Sandbox as role model 189 6.1.2 Middleware - the J2ME MIDP security concept 191 6.1.3 Buffer overflows 193 Common IP security issues 195 6.2.1 Wireless network access 195 6.2.2 Security Issues with IP networks 195 6.2.3 Security issues with wireless personal devices 197 6.2.4 Technical solutions 198 6.2.5 Procedures to address security issues 204 Identity 206 6.3.1 Identity, Authentication and Authorisation 206 6.3.2 Implications on Accounting 209 6.3.3 Security and Privacy Requirements 210 6.3.4 Credentials 212 Web Services Security 214 Exercises 215 Part One (Chapters 1, 3, and 6) 215 7.1.1 System Availability 215 7.1.2 Mobile Terminating Call 215 7.1.3 Virtual HLR/VLR 217 7.1.4 Data Traffic in Wide Area Networks (WAN) 218 7.1.5 Mobility 219 7.1.6 Location based Services 221 7.1.7 Distributed Computing 222 7.1.8 Service Inventory 223 7.1.9 Name, Address and Identity 225 7.1.10 Name Spaces 225 7.1.11 CORBA and RMI 227 7.1.12 Clients and Servers 228 7.1.13 Threads and Processes 228 7.1.14 Memory Leak 229 7.1.15 Viruses and Trojan Horses 229 7.1.16 Service Discovery 229 7.1.17 Bluetooth 229 7.1.18 Communication End Points 229 7.1.19 File-Sharing 229 7.1.20 CORBA and Web-Services 230 7.1.21 Direct Provision of Client Applications 230 7.1.22 A Sandbox for Software 230 7.1.23 Buffer Overflow 230 7.1.24 The phantom menace 231 7.1.25 Attacks 231 7.1.26 Requirements on public network infrastructure 231 7.1.27 The security hole in your pocket 231 7.1.28 Town Gate 231 7.1.29 Defence System 232 7.1.30 Key Ring 232 7.1.31 Session Keys 232 7.1.32 GSM Authentication 232 7.1.33 One-Time Pads and Stream Ciphers 232 - VII -
6.2
6.3
6.4 7 7.1
7.2
7.1.34 IPSec 233 7.1.35 IP-VPNs 233 7.1.36 Identity, Authentication, Authorisation 233 7.1.37 Biometrics 234 7.1.38 GSM-Keys 234 7.1.39 Cloned SIM Cards 234 7.1.40 Credentials 234 Part Two (Complete Book) 234 7.2.1 Collisions in Piconets 234 7.2.2 Framing protocol 236 7.2.3 Protocol Overhead in VoIP 238 7.2.4 Shopping carts 239 7.2.5 Output Buffer 239 7.2.6 Intelligent Network 240 7.2.7 Virtual HLR in a Mobile Network 240 7.2.8 Location Updates 241 7.2.9 Classes and Objects 241 7.2.10 Relations at Examination Time 241 7.2.11 Evaluation of Results 242 7.2.12 Service Discovery 245 7.2.13 Personal Networks 248 7.2.14 Mobile Instant Messaging 250 7.2.15 UPNP Remote Control 254 7.2.16 Location Based Services 256 7.2.17 Client-Server Communication 259 7.2.18 Local Context Service 261 7.2.19 Home Networks 264 7.2.20 Fixed Mobile Convergence 266 7.2.21 Mobile Peer-to-Peer Networks 270 7.2.22 Mobility Management 272 7.2.23 Remote Control for Home Networks 277 7.2.24 Mobile Video-Streaming 279 7.2.25 Remote Player 281 References 285 Translations English - German 289 Abbreviations 291
8 9 10
- VIII -
1.1 Introduction
1 Telecommunication Networks
In this chapter, we will have a look at telecommunication networks and at the services they provide. Section 1.1 represents a qualitative summary of networks. Section 1.2 will present a look at the terminology used in communication networks. Section 1.3 provides the essential concepts of circuit switched and packet switched exchange of information. Section 1.4 summarises the essentials of mobile communication networks. The following sections 1.5 to 1.8 introduce the basic architecture of existing network technologies (that is GSM, GPRS, UMTS and the World Wide Web). In perspective, chapter 1 is intended as introduction to communication systems as basis for telecommunication software engineering.
1.1 Introduction
The world wide telephone network represents the biggest machine which has ever been build by humankind. However, little of it is known to us in everyday life. Who knows what is behind the telephone outlet, the cable modem or DSL modem? What makes mobile phones work? Connections to the world wide communication infrastructure is becoming an elementary feature in our households, in education, in business, and increasingly while we are on the move. Most probably, information technology will change the way we work much faster and fundamentally than the steam engine or the car have been doing over the last centuries. Following work, capital and soil, information is becoming an increasingly important asset in our society. Communication networks carry information and this represent a vital infrastructure in our society. Globalisation of markets and customisation of products will influence the way products are designed and manufactured. Most probably, it will also fundamentally change the way we work. Working time and the place of work are becoming flexible. This enables people to get organised in a flexible way, in smaller teams with flat hierarchies and short communication links. In many cases, communication networks already are a basic condition for many jobs (how many enterprises do operate without telephone or PC?). Telecommunication facilitates co operation with other people, wherever they are.
world wide connections ...
... change the way we live
It also facilitates trends such as the current migration of jobs to start-up countries.
Fig. 1-1 Telecommunication networks carry digital information (bits)
What are telecommunication networks about? Figure 1-1 shows a summary. Communication networks cannot carry physical goods. They carry data, such as digitised media. Media includes any kind of information, such as words, signals, voices, music, pictures, movies or files and messages exchanged between machines. The digitised information is represented by numbers, or bits. For transport, bits may be packaged into packets if information. The most relevant (the most universally accepted) packet format today are IP packets.
1.1.1 Circuit switched networks and packet switched networks

The traditional way of connecting to ends to each other has been a circuit. In analogue networks at the beginning of last century, the circuit also represented an electrical circuit for the signal. Essentially, the idea of a circuit is to connect to ends through pipes. Figure 1-2 shows the principle.
Fig. 1-2 Switched connections - signalling phase
1.1 Introduction
Between the connected parties, the network has generated an individual pipe. The pipe is used for a stream of information (usually in both directions). Usually, the flow of information is possible with a guaranteed continious data rate (such as 64kBits per second by a telephone line or ISDN B-channel).
Fig. 1-3 Circuit switched connections - connection phase
Todays circuit switched networks are completely digital, such as the telephone network that handles analoge terminals and ISDN, or the GSM networks for mobile phones. The circuits does not exist in a verbal sense, but as a concept: - the network establishes a communication channel - the channel provides a constant bitrate - the channel is maintained until one of connected parties hangs up. The concept of packet switched network is equally simple, as shown on Figure 1-4. It corresponds to packets deliverd by a postal service. Packets are labelled with the adress of their destination (and the address of their sender). The postal service takes care of routing and delivery.
Fig. 1-4 Packet networks
The implications on the delivery of the specific content of the packets are less simple. Packets may carry an e-mail, an audio stream or video stream, or a telephone call. Requirements on latency for each service are entirely different: a video stream may arrive 10 seconds later without bothering the user. The natural interactions in a telephone conversation need latencies below 50 milliseconds (you will need to interact with "roger and over", if latency goes beyond 200 milliseconds). For a download of a file or for an e-mail, latency is in the order of minutes or hours. In order to carry such different loads, package switching networks will need a concept to provide different qualities of service.
Fig. 1-5 Example: Voice over Packets
Jitter translates into delay
How does the transfer of information through packages work? Figure 1-5 shows the principle. As example, the information is represented by a voice converation with the user on the left talking to someone on the right. At the sender, the signal needs to be digitised, coded and cut into piexec of a given lenght. These pieces are put into packets, together with a time stamp. This procedure inevitably generates a delay (or latency). Packets are now transferred over the network. Depending on how many hops the packed needs to pass, and depending on traffic conditions on the network, this will generate another delay. At the receiver, the pieces of information are lined up according to their timestamp. This procedure is called "dejittering" (the jitter represents variations in the delay caused by the transfer over the network). Also, the signal needs to be decoded before it is transformed into an audible signal at the speaker of the phone. The procedures at the receiver also cause further delays. In particular, the delay caused by dejittering corresponds to the delay caused in the network (this is well known from streaming audio or video over the internet, where the media player buffers the signal in order to generate a continuous output signal).
1.1 Introduction
Fig. 1-6 How to deliver packets over a large distance?
A brief look at packet transport: Does it make sense to deliver each packet individually? This will depend on distance and on the volume of traffic. For a Pizza-Service, it may be o.k. to deliver orders individually. For a postal service, distance and volume make other solutions more efficient. Figure 1-6 shows the principle. Packets from one area to another area are collected in a container and transferred together. At the destination, the container is uncharged and packets are routed to their destination. At physical level, wireline infrastructure or wireless infrastructure may be used.
Postal service
1.1.2 Access networks and core networks

Following the qualitative view of some basic concepts in the last section, we will now have a look at the geographic proportions of networks and their consequences on network technologies. We will start with larger distances. To connect the larger cities in a place like Germany, we think about the motor highway or the intercity railway network. In terms of telecommunication networks, this corresponds to the data highway, which is represented by optical fibre networks. Figure 1-7 shows such a network.
A road system for data traffic
Fig. 1-7 The information highway
However, this information highway does not carry regional traffic or metropolitain traffic. In terms of the railway system, this corresponds to everything that a regional train or metro line (S-Bahn) connects. In terms of the road system, this also corresponds to a regional or metropolitain network. In a metropolitain communication network, optical fibre connects the main sites, such as data centres, main distribution frames of the telephone networks, fibre nodes (hubs) of Cable TV networks, or base station controllers of mobile networks. The distribution networks which connect to the metropolitain fibre connect to the homes and offices of the end users, the so called last mile. Figure 1-8 shows the metropolitain area and two squares, which represent cuts of about 5 kilo meters and 500 meters. Depending on the density of population, a wireline or wireless access network would supply such an area.
Fig. 1-8 Metro networks and the last mile
1.1 Introduction
As example for networks on the last mile, Figure 1-9 shows a cable TV network. Cable TV networks originally represent long trees of coaxial cable and coaxial amplifiers. In order to allow interactive services (such as Internet access via cable modem or telephone services over cable), areas within the copper network are supplied via optical fibre. Figure 1-9 shows the corresponding fibre nodes (hubs) and the coaxial trees that emerge from them. Depending upon demands of bandwidth, one area represents about 5000 housholds who share the cable. Also shown in Figure 1-9 is a photograph of a stree cabinet which holds a fibre node of caxial distribution. Similar streat cabinets are used to distribute copper wires of the telephone networks (or electrical power).
Fig. 1-9 Example: Cable TV networks
Figure 1-10 shows a summary of the different types of networks. All networks shown represent wide area networks (WAN). They include access networks in the last mile, fibre rings in metropolitain areas, and the data highways to bridge national and international distances. At access level, the major physical infrastructure is represented by copper wires (of the telephone network), CaTV networks, and the base stations for cellular mobile networks. By the proportion of connections they provide, access networks represent the biggest share of investment in network infrastructure (digging cable and mounting base stations on a large scale is expensive).
Fig. 1-10 Fig. 1-10 Summary of network infrastructure
Network design follows traffic
Given the high density of traffic in a densely populated area, fibre rings connect the different access networks and also collect their traffic. Transmission systems used in fibre networks allow to carry both packed switched and continuous types of traffic. The fibre networks in the metropolitain area connect to the access points of different network providers, which are shown as Points of Presence (POP) in Figure 1-10. The point of presence is providing network access (it generates the UserID/Password request of your internet connection or allows your mobile phone to use the network). It also represents a point of interconnect between different networks and network operators. In other cases, such as an IP based cable network connecting to a circuit switches telephone network, it performs a conversion of media (such as packets to circuits). The POP shown in Figure 10 is an abstraction of different network elements which are used in different network technologies to perform such functions. At backbone level, network elements which switch telephone traffic in GSM networks or PSTN networks, or handle large amounts of packets in the internet. The performance of today's network elements allows to handle highly concentrated traffic. For instance, a mobile switching centre can handle millions of mobile subscribers. A switch (exchange) in a public telephone exchange can handle hundreds of thousands of subscribers. Before the digitisation of networks, there had been 8000 analogue telephone exchanges in Germany (for a total of about 40 millions of telephone lines). 20 years ago, they have been replaced by 1500 digital exchanges. With today's technology, about 100 systems would be sufficient.
Fig. 1-11 Fig. 1-11 What about Satellites?
So far, satellites have not been mentioned. Figure 1-11 shows a scanrio, which includes satellites in the communication networks. Because geostationary satellites cover a large area, they are particularly usesful to broadcast information to a large number of destinations. For the same reason, they are less useful to generate a individual communication links between a large number of users. Digital transponders allow to broadcast any type of information (including the Internet) to different destinations. The bandwidth covered by one TV channel (analogue channels with 5 MHz each) corresponds to about 35 Mbits of da-
1.1 Introduction
ta (or 6-8 digital TV channels). Media received by satellite may also may be distributed over wireline access networks, such as telephone lines (over DSL). Not shown in Figure 1-10 are terrestrial TV networks. Terrestrial TV networks are now also being digitised and may supplement wireless networks (such as UMTS).
Fig. 1-12 What about Wireless LAN and Bluetooth?
With the exception of satellites (and terrestrial TV), which directly reach the end user, the other networks discussed so far basically represent Wide Area Networks (WAN). In the local area, there are private telephone systems with private networks, or PCs and servers connected in a Local Area Network (LAN). Still closer to the end-user are the devices he may connect to with the Bluetooth interface or infrared interface of his PDA, mobile phone or PC. Such networks are called Personal Area Networks. Figure 1-12 shows a summary. It should be noted that local area networks (wireline or cordless telephone systems or wireline or wireless data networks) usually connect to the subscriber interface of a Wide Area Network (such as a DSL modem, cable modem or equivalent interface).
Local Area Networks
1.1.3 Services and applications

Services are functions that networks provide to us (such as a mobile phone comes with a telephone service). Applications are something that can be provided on top of the basic services (such as an interactive game that can be downloaded and installed on a mobile phone). Increasingly, networks become open for new applications. Both services and applications are the essential part of Telecommunication Software Engineering. In this section, we will raise some questions on services and applications.
Services generate traffic
10
Fig. 1-13 Where do we use networks?
First of all: Where do we use networks? As shown in Figure 1-13, networks are largely used at the desk of an office and home office. The mobile phone has enabled us to use networks everywhere. Further services will be provided on the move (by adding data services to the mobile device which allows us to arrange our life or work on the spot), as well as in the living room (basically entertainment, but also home automation).
Fig. 1-14 What services do we use?
What services do we use? Figure 1-14 provides a classification with some examples: conversational services, interactive services, streaming services and services which may run in the background. Again, services are moving from the traditional combination of telephone and PC into different areas. They are getting more diversified. Also, networks will go beyond connecting people:
1.1 Introduction
11
they will connect an increasing number of machines and vehicles. For networks, it will become important to ba able to handle a diversity of services.
Fig. 1-15 The value chain: Who is providing which service?
Who is providing services? As shown in Figure 1-15, there is also a growing diversity of players in the value chain. In the traditional telephone network, the network operator provides the complete service (sometimes also including the terminal set). For new services, the value chain is more complex. It largely corresponds to the current practice in the internet or in the entertainment media business: A content provider provides the media (such as a web-site or movie), a portal provider aggregates different offerings of content (such as Yahoo or iTunes), a service provider specialises on end user demands (such as providing Internet access, web-hosting, IT-services, hotlines). In this scenario, the role of the network operator is reduced to transport of data (and the traditional telephone services).
Fig. 1-16 Who will use future services and which concepts are used to provide services?
12
Services are used by people and machines
Who will use future services? Which concepts will be used to support such services in communication networks? Figure 1-16 shows a summary. Users today are largely people. Tomorrow, networks will connect an increasing number of vehicles, machines, appliances, consumer electronics, sensors and actors. The predominant concept to implement services in networks today is the client-server architecture. Concepts tomorrow include software downloads & updates, user agents, peer-to-peer networking, and ad-hoc organisation of networks and resources. Applications will become more data centric, diverse and dynamic. This development is largely driven by the migration of the microprocessor into almost every device, i.e. the increase of so called embedded systems. Maybe, in a couple of years, we will see a microprocessor in every lightswitch. A natural follower to the microprocessor is a communication infrastructure. This is because one thing that the microprocessor will certainly demand is a software update. Generally, it will also want to communicate the state of the system it represents or take instructions from a controlling network element. The conclusion is, that we will have two major areas of development in telecommunications: (1) networks for embedded systems, (2) service architectures in core networks.
Fig. 1-17 How are networks organised?
After covering some qualitative views, there are two remaining questions: how are networks organised and is there is an abstract and systematic way to handle communication networks? This will be shown in the following sections.
1.2 Terminology
Networks, Access Points, and Terminals
The main task of a communication network is to allow the exchange of messages between the access points of the network, i.e. to transport messages from one access point to another access point or to other access points. Figure 1-18 shows the principle.
1.2 Terminology
13
Fig. 1-18 Network Access Points

Network
Source/ Sink
Source/ Sink
Network Access Point
The main requirements on such a network are: - an access point must be available at any time to transfer messages to any other access point - the user at an access point is able to decide on the destination of the message - the network must be able to handle a large number of simultaneous transactions - the technical efforts to do this is minimised by utilising the statistical qualities of the transactions. Telecommunication networks operate in large scales: The telephone networks for instance connect more than 1 billion telephone subscribers and more than 1.5 billion mobile phone subscribers worldwide.
1.2.1 Communication model

Users do not directly communicate with network access points. They are using terminal devices like a telephone or a desktop computer. The terminal devices provide the user interface (towards the user), as well as the user network interface (towards the network). Figure 1-19 shows this basic communication model. Modern terminal devices like an ISDN phone or a desktop computer do not connect directly to the network access points, but are using intermediate networks like the S0 bus or a LAN-connection to another device, which connects to the network access points (such as a ISDN NT or a DSL modem or cable modem). In terms of Figure 1-19, all of this represents terminal equipment (sometimes also called customer premise equipment because it is installed at the customer's place).
Terminals and Applications
14
Fig. 1-19 Communication Model

User Interface Network Interface Termination
Network
Network Interface
User Interface
Termination
Source/ Sink Signal Transfer Message Transfer Application
Source/ Sink
Network Access Points
Services to support applications
Messages are created by the applications running in the terminal devices. Among such applications are the telephone service, FAX, e-mail and all applications running on a desktop computer which communicate over the network. The terminal equipment at the user network interface (such as modems) transforms messages the respective types of signals to transfer them over a larger distance to the network access points. Such transformations happen repeatedly within the network. In order to enable applications, the network provides services. For instance, the telephone service implemented in the telephone networks enables voice communication as application. The telefax service enables the exchange of facsimile documents as application. The e-mail service enables the exchange of electronic documents. The World Wide Web enables access to documents stored in the network.
1.2.2 Connections
Post-Box or on the line
A connection represents the establishment of a communication channel between the communicating parties for a period of time. The communication channel may be used to exchange messages. There are different types of communication channels, which the network can provides. For instance, an ISDN connection offers a channel for the transparent exchange of messages at a continuos bit rate of 64 kbits per second. A completely different type of connection is represented by e-mail. In this case, the communication partners connect to post boxes. The network transfers messages between the post boxes. Figure 1-20 shows the path of a connection through the network.
1.2 Terminology
15
Connection
Fig. 1-20 The route of a communication link through the network
calling Party
called Party Verbindungsleitung
A
Destination Address
B
Accessline
Communicaton Channel
Telecommunication Network Network Node, Exchange
There are many ways of implementing connections. The traditional way has been the physical connection between communication partners by a switchboard. The modern equivalent are connections at continuous bit rates provided by time division multiplex systems (such as ISDN mentioned above). Another concept are virtual channels, which provide the required bitrate on demand and else allocate resources to other traffic flows. Connections may be provided on request of the user (dial-in connections), or be provided between known communication partners continuously (fixed lines). In general terms, a connection exists, as long as the communicating partners maintain a communication link, i.e. they are in a state of communication with each other.
Allocation of resources for connections
1.2.3 The architecture of telecommunication networks

How do networks manage to provide connections between a large number of access points? Figure shows the principle architecture of a network such as the telephone network. It is using an hierarchical structure. There are network elements (nodes), which connect to network access points (with terminal equipment attached to them by access lines). In a telephone network, such network elements are called local exchanges.
Hierarchical structure
16
Fig. 1-21 Structure of a telecommunication network

Bundle Connecting Lines Switched Connection
Bundle (Channel)
Communication Link Access Line
Terminal Sets
efficient utilisation of resources
Network Layers
These network elements at the lower network level connect to network elements further up the hierarchy. In a telephone network such network elements are called transit exchanges. Network elements at this level do not carry subscriber lines, but connect to each other. Also shown in Figure 1-21 is a connection through the network. The network takes care that the route of such a connection is short and utilises resources in the best way. In a telephone network, a path is chosen before the connection is established (this happens only after the called person picks up the phone). If, for instance, the called person is busy or does not accept the call, no connection is established at all (in this case, you will hear a busy signal, or hear a free signal). In reality, networks are a bit more complicated than shown in Figure 1-21. They are using a layered approach which allows an optimum utilisation of resources. These layers are: - Transmission Layer - Switching and Routing Layer - Service Layer. Figure 1-22 show an overview. The transmission layer provides connection to access networks. It also represents connectivity to switching networks (both fixed networks and mobile networks) and the Internet. In switching network, a service layer has been separated in order to facilitate network design, planning and operation. The service layer provides services such as number translation and special tariffs by the so called Intelligent Networks (such as freephone 0800 or premium rate services such as 0900). It also provides number portability.
1.2 Terminology
17
Fig. 1-22 Traditional Network Structure

Service Plane
Intelligent Network SCP IN Intelligent Network SCP IN
Scitching Plane
Fixed Network
Mobile-Network
Access-Netz
Transmission Network
Transmission Plane
Access Network
Internet
The Internet is by nature an overlay network which may utilise any existing network infrastructure (it is an inter-network network). Internet network elements such as Routers and the Domain Servers may be connected anywhere in the network infrastructure. However, the volume of traffic provided by Internet users and the number of users using services like the WWW and e-mail has made the Internet a driving force in network design and planning. Broadband access such as DSL-Modems or Cable Modems are specifically driven by the Internet. Also, the provision of services in the WWW has generated extremely effective engineering methods (Web-Engineering), that will drive the provisioning of services and applications. Similarly, the wide acceptance and universal connectivity of IP as routing protocol is driving a next generation of network elements. In such networks, IP is becoming a universal transport layer. Figure 1-23 shows the principle architecture.
Internet
18
Fig. 1-23 Separation of Transport and Control in Next Generation Networks

Intelligent Network SCP IN Intelligent Network SCP IN Multimedia Applications Multimedia Applications
Control
Call Feature-Server Signalling & Media Gateway Controller Call Feature-Server Signalling & Media Gateway Controller
Fixed Network
Mobile Network
Access Network
Internet + Transmission Network
Access Network
Next Generation Networks
Besides the prominent role of IP as transport layer (over existing transmission technologies), the most significant difference between Figure 1-23 and Figure 1-22 is the separation of control of traffic and handling of traffic. The traffic is handled by gateways (which for instance pick up a 64 kbit channel, transform it to packets which it sends to another destination). The traffic is controlled by gateway controllers (which for instance instruct a gateway to switch a connection to a specific destinations). The IP-layer of the network (routing layer) in such a network has to handle a variety of traffic classes (such as e-mail, media streaming and interactive services).
1.3 Concepts for Switching and Routing

1.3.1 Connection orientet exchange of messages
The communication in connection oriented networks follows a general sequence: - connect: The network uses the destination address provided by the user,
19
finds out whether the destination is ready to communicate (i.e. not busy), reserves the required resources and establishes the connection. - use the connection: The network maintains a communication channel for the exchange of messages between communication partners. - disconnect: Upon request of one of the communication partners, the network de-allocates all resources and cancels the connection. One important part of this sequence is the allocation of resources. It allows to provide a specific quality of service, once a connection is established. Resources will be available to the communication partners as long as they maintain the connection. For a regular telephone call, the quality of service represents a continuous bit rate, a specific quality of the voice transmission (such as echoes, delays, distortion). Such quality criteria are strictly specified and need to be maintained by suppliers of infrastructure and by operators, who interconnect their networks. Also, the network is able to manage it's resources and avoids degradation of services. For instance, in new years night, telephone networks tend to get under heavy traffic conditions. They operate at maximum load and accept only the number of calls they can actually handle (so if you receive a busy signal on your mobile in such a situation, it is not because the network has crashed, but because it is fully loaded).
Quality of Service
1.3.2 Connectionless exchange of messages

Computers connected to a LAN or over the Internet do not follow a sequence of establishing a connection (at least not at Ethernet level or IP level). In a connectionless environment, a device is allowed to send a packet containing the message spontaneously. The packet contains the destination address and the address of the sending device (so that the destination may respond). Packets are transferred through the network according to their addresses. This transfer is also called routing. In order to be able to do this, routers will need to maintain information about the network topology. However, they do not allocate resources. In an overload conditions, packets are allowed to get lost. The benefit of such networks are that they only need resources when there are actually packets to transfer (they combine different packet streams in a statistical way, which is called statistical multiplexing). However, this situation makes it difficult to maintain a quality of service in such networks. Delay times are unpredictable and may have significant variations. Heavy load conditions are difficult to handle. This situation corresponds to cars and vehicles on a highway. On a highway, the faster vehicles are allowed to use a dedicated lane. Differentiation and priorisation are also concepts to improve quality of services in connectionless networks.
Transfer of packets
Differentiation of traffic
1.3.3 Circuit switched connections

In this section, we will have a closer look on how connections work in a circuit switched network. This essentially explains, what happens when you pick up your phone and dial a number.
20
Establishing a connection
Figure 1-24 show the basic sequence of events. As soon as subscriber A picks up the phone, he indicates the wish to establish a connection. If the network is ready to accept a connection, it quits by sending a dial tone. The subscriber now dials a number (or selects a number from the telephone directory on the phone). The network is checking, whether the destination B is ready to accept a call (e.g. not busy, or mobile phone not switched off), then allocates resources and lets the phone at B ring.
Fig. 1-24 Sequence of events in a telephone call
Network A Off-Hook Dial Tone (Accept) Dial Digits Ring Signal Ring Tone B Off-Hook Indication Release (B On-Hook) Time B Off-Hook Exchange of User Information Release Indication (Busy) Release (B On-Hook) Connection Release Connection Establishment
User A
User B
The networks sends a free tone to subscriber A, which indicates that the phone on the other end is ringing. As soon as B picks up the phone, the network establishes a communication link. A and B are nor connected and may exchange information. In the scenario shown in Figure 1-24, the connection is maintained until A hangs up, which is indicated to B. Terminating the connection includes de-allocation of all required resources by the network.
Signalling
Separation of control and payload
What Figure 1-24 does not shows is the communication between the network elements which is associated with the connection. Telephone exchanges use special protocols and channels for such procedures, which are called signalling. Signalling is used between terminal devices and network access points, as well as between nodes in the networks, in order to exchange control information. In classical networks designs, control is entirely separated by the user information and even uses separate channels (such as the ISDN D-channel) or even networks (such as the signalling system 7). Separation of control (Control Plane) and user information (User Plane) is also maintained in next generation network architectures and ist associated protocols (such as SIP).
Network elements
How does a telephone exchange actually look like? Figure 1-25 show the prin-
21
ciple architecture of a local exchange. On the left, it connects subscriber lines (via line cards). On the right, it connects to other exchanges (over so called bundles, which are each going to the same destinations). At the core of the exchange, there is the digital switching matrix, which allows to connect user traffic from different incoming ports to different outgoing ports, as well as the control.
Fig. 1-25 Structure of a local telephone exchange
Trunks for Interconnection Bundle Direction1
Local Telephone Exchange

Line Terminations
Direction 1
Switching Network . . .
. . .
Control
. . .
Direction N
Control Processor Signalling Signalling Bundle DierectionN
Control information is handled separate from user traffic. This is indicated in Figure 1-25 by signalling channels leading from subscriber line terminations to the control box, which is using the information provided through signalling to transfer signalling information to other exchanges and to control ist own switching fabric (and vice versa for terminating calls). Figure 1-26 again summarises the complete scenario of a connection from A to B. In a circuit switched network, the characteristic part is the connection point maintained in each switch (telephone exchange), which is part of the connection. What circuit switched network also maintain is information about the distance and duration of connection. Such information is used for accounting and billing.
Circuit switched connection
22
Connection Crosspoint
Physical Connection (Crosspoint)
Calling Party
Communication Link
B
Access Line
Channels (Bundles)
Telecommunication Network Network Switching Node (Exchange)
Fig. 1-26 Circuit Switched Connections
1.3.4 Store and forward routing

The transfer of messages over a packet based network may follow an entirely different principle. Because packets have a limited duration, they may be stored in a network element and then transmitted again in the appropriate direction. A condition to do this is, that each packed contains a label which indicates control information about the destination or logical connection the packed belongs to. Figure 1-27 shows the fragmentation of a message into a package.
Fig. 1-27 Fragmentation of a message into packets

Message Blocks: Message Header Body
Packet
Each packet consists of a header (which contains addressing information), and a body (which contains the message or part of it). In messages fragmented into several packets, the sequence of the fragments also needs to be included (for example by a sequence number). Packets are generated at the source of the communication network. A path through the network may be shared by several connections, by transferring the corresponding packets in an alternating way (one using the pauses of the others). Through storing and forwarding packets, the network elements represent a buffer (or queue) for packets.
23
Network
Switching by storage and forward of packets
A
Buffer
Network Switching Node
Figure 1-28 shows the principle. For the user, a packet switched connection looks like a permanent connection. Still, resources are only allocated if they are actually used to transfer a packet, i.e. during the period of time a packed is stored within each network element. In practice, packets with the same destination will always take the same path (i.e. as long as the routing information in the network elements is stable and does not change). By nature, packet switching does not exclude the notion of a connection in terms of a common path and destination of a sequence of packets.
Fig. 1-28 Packet Switched Connections
1.3.5 Message switching (datagram service)

In message switching, each packet represents a complete and independent unit, i.e. a complete message or datagram. Each network element will store and forward the packet entirely based on the information included in the header. There is nor relation between packets, even if they originate from the same source. Else, message switching entirely corresponds to the store and forward routing described in 1.3.4. A practical example for message switching are IP packets or UDP packets in the Internet.
Fig. 1-29 Generation of a packet at the sender
Message Block:
Body
Header
Header: Control (destinationl, lenght, priority...) Body: Payload
1.3.6 Cell based connections (ATM)

One property of packet switched networks makes mixing of different kinds and qualities of traffic difficult to mix with each other: variable and unpredictable packet lenghts. This makes it difficult for continuous types of traffic (such as a sequence of small packets each carrying 10 mseconds of a voice call) to mix up discontinuous traffic with long packet lengths (such as from a downloaded file).
A conveyor belt for data
24
Fig. 1-30 Fragmentation of a message into cells

Message Cell Header Cells
Cell based connections like ATM are using a stream of packet entities with a fixed length, the so called cells, as shown in Figure 1-30. As usual, a message is fragmented into the cell stream. The cell stream represents a continuous flow with predictable resources trough the networks elements (see Figure 131), even if cells are empty. At the incoming ports of each network element, cells are processed according to the information in their header and put on the appropriate outgoing cell streams.
Fig. 1-31 Cell based connections
Network
A
Header Processing
Because it allows to mix up different kind of traffic in combination with an efficient use of resources, ATM is used as transport layer to aggregate IP traffic and TDM traffic in access networks, as well as for exchanging and distributing traffic in core networks.
1.4 Mobile communication networks

Like mushrooms
Mobile communication networks have had a remarkable start-up world-wide. In Germany, for instance, it has taken less than 10 years for mobile phones (from the availability of the first digital network in 1991) to grow beyond 50 million mobile subscribers, which is higher than the number of fixed telephone lines (it took about 100 years to grow a number of about 40 million fixed telephone lines). Also, mass production has enabled mobile phones to become small and ubiquous. Beyond cellular mobile networks, other wireless technologies are emerging.
1.4.1 Summary of mobile communication systems

The most simple mobile communication is using a cordless phone. As indica-
25
ted by the name, the cord between the handset and the telephone set is replaced by a radio interface. All handsets associate with the fixed line that their base station connects to. They either associate with this number or, in the case of a private exchange, use an extension of this number. Cordless phones are supported by the same network as fixed line and do not cause any changes there. In comparison, mobile cellular networks, which handle mobile phones (predominantly networks using the GSM standard), are quite complex. They allow subscribers to roam (that is use their phone in any place world wide). They also manage to keep a conversation going while the user is on a train or in a car (i.e. they need to hand over the radio connection between different base stations without interruption). In order to identify subscribers and to encnrypt communication, they use smart cards (SIM cards). In the last couple of years, GSM has been extended by a packed based data service, GPRS (General Packed Radio Service). GSM has been designed about 20 years ago as the second generation of mobile networks which has replaced former analogue networks. Over the coming years, the next generation of mobile networks will be deployed, the third generation: UMTS (Universal Mobile telecommunication System). In fact UMTS claims to be more than the next cellular system. It also promises integration of other technologies to provide a uniform level of service.
Where ever you are
Fig. 1-32 Mobile Communication Technologies

Transmission Rate [Mbit/s] wireline terminals
100
10
WLAN
1,0
UMTS
0,1
Cordless
(CT, DECT, WPABX, WLL)
Cellular Systems
(GSM and others)
0,01 Office/Home Indoor Building stationary
Mobility walk Outdoor drive
Figure 1-32 shows a summary of the different wireless technologies. It indicates the bandwith they provide versus the degree of mobility. For instance, a cordless telephone technology may provide indoor mobility, but fail to provide stationary mobility (roaming or nomadic mobility) or movement between base
26
stations (handover). The same holds for wireless LAN (unless it is integrated as radio access technology in a UMTS network). In this section (and the following sections until 1.8), we will focus on the cellular mobile networks and the services they provide.
1.4.2 Basics of radio transmission and cellular networks

Tough conditions for radio waves
Radio waves do not enjoy the comfort to travel in a predictably environment such as waves travelling along through a fibre or along a pair of copper wires. Between sender and receiver, much more difficult conditions need to be handled. Radio waves suffer attenuation and reflections. In an urban area, reception without multiple reflections would be quite difficult, as shown in Figure 1-33. In a rural area, there are far less reflections (except for mountains, which cause rather long delays of about 20 microseconds compared to 0,2 microseconds in urban conditions). Multiple reception (but also absorbtion, polarisation and interference) is causing fading of signals received.
Fig. 1-33 Radio Reception
Cellular networks
Cellular networks also are designed to handle fast moving users (i.e. the Doppler shift of frequencies while moving). GSM is designed to support moving users up to speeds of 250 km/h (which corresponds to a fast moving car or train). But why are those networks called cellular? The idea is to provide a large area of coverage by a grid of cells which closely fit to each other. Figure 1-34 shows the principle: each base station covers 3 areas (cells), which intersect with other cells to a cluster. In theory, the cells represent hexagons. The cluster shown has a similar structure than a single cell and may be used this way to generate larger structures. The different shades in the figure represent different frequencies. Frequencies may be reused in a reasonable distance, which results in a tile structure. Interference between cells is further minimised by power management, i.e. the base station limits the power of the mobile set to the required strength.
27
Fig. 1-34 A Cluster of nine Cells
B A
B B
C Location of the Base Station
C C
The size of a cell depends on the power of the base station. The size is adjusted to the traffic density, which corresponds to the density of the population. In an urban area, we should expect smaller cells than in a rural area. In GSM, cell sizes may vary between a diameter of 250 m and 35 km (with 6 to 8 km on average).
Motorway Rural Area
Suburban Area City Fig. 1-35 Size of Cells corresponds to Traffic Density
Figure 1-35 shows cells covering an urban area, a suburban area, as well as a rural area including a highway.
28
1.5 GSM - Global System for Mobile Communication

1.5.1 Basic architecture
No national boundaries
From the beginning, GSM has been planned as a seamless digital European mobile network system, that does not end at the national boundaries. The specifications have been published by ETSI in 1990. In the subsequent years, GSM has been deployed in Europe and now provides a seamless connectivity from Spain to Sweden. Also, it has gained world wide acceptance and now represents the predominant cellular network technology. Figure 1-36 shows the network architecture. Geographical coverage is obtained by base stations which generate radio cells. Adjacent cells do not interfere with each other, so a seamless coverage can be achieved. Two basic subsystems of GSM can be differentiated: the Network Subsystem (NSS), which represents an ISDN like network architecture, and is shown on the right of Figure 1-36 beginning with the Mobile Switching Centres, the Radio Subsystem (RSS), which represents the base station controllers, bas stations and the radio cells on the left of Figure 1-36.
Fig. 1-36 Structure of a GSM Network
Radio Cell BSS BTS BSC
Signalling Channels with Mobile Applicaton Protocols Home Register Authentication Authority Gateway MSC Equipment Reg. Tepehone Network
Visitor Register
Signalling Channels with Mobile Applications Part and ISDN Applications Protocols
MSC
Home Register Authentication Authority Equipment Reg.
Visitor Register
The Network Subsystem connects the mobile network to public telephone networks (via Gateways Mobile Switching Centres). Mobile Switching Cen-
29
tres (MSCs) are the equivalent of telephone exchanges. However, they do not contain line cards to connect subscriber lines. Else, the mobile network uses the same circuit switched principles as in fixed networks (see section 1.3.3). However, there is an entirely new aspect with mobile subscribers: a mobile subscriber may show up anywhere in the network (respectively, in any mobile network). So the network needs to identify the subscriber, accept outgoing calls from the subscriber and deliver calls to the subscriber. This is achieved by adding additional network elements: the Home Location Register (HLR) is a data base which holds the basic profile of the subscriber and associates with the subscribers mobile telephone number. The Visitor Location Register (VLR) contains information about subscribers which are actually roaming in the area covered by an MSC, i.e. dynamic data. The role of the HLR is that of the local post office in the home town of the subscriber. While the subscriber has temporarily moved to another place, it will know the post office of the visited place (the VLR) and arrange for traffic to be forwarded. Other network elements allow to identify SIM-cards and equipment (mobile sets). How the different components inter-operate, will be shown with some sequences in section 1.5.3 and 1.5.6. In total, the Network Subsystems consists of the following components: - Mobile Switching Centre (MSC) - Visiting Location Register (VLR, usually part of an MSC) - Home Location Centre (HLR) - Authentication Center (AuC, usually part of the HLR) - Equipment Identification Register (EIR, not mandatory) - Operation and Maintenance Centre. The Radio Subsystem connects the mobile sets over the radio network to the mobile switches. It include the mobile terminals (i.e. mobile stations and handheld devices), the base stations and the base station controllers. The last two components form another entity in GSM: the Base Station Subsystem (BSS). The BSS includes: Base Station Controllers (BSC) Base Transceiver System (BTS, i.e. the base stations). Base Stations (BTS) and Base Station Controllers may be collocated (i.e. at the same location) or operate remotely (i.e. separated from each other). A BSC may connect to several base stations.
Mobile users may show up anywhere
1.5.2 Services
The basic service that GSM provides is telephony. The telephone service also includes the display of calling numbers and other features (so called supplementary services) from ISDN. However, the physical implementation is different. Over the air, GSM is using speech compression and channels with maximum bit rate of 9,6 kbits (which makes the quality of GSM inferior to what we know from a fixed line). In order to minimize the use of radio resources, a voice activity detector eliminates pauses in conversation from transmission. This discontinuous transMobile telephone service
30
FAX and data
SMS
mission also helps the terminal set to save power. GSM coded signals are transcoded into 64 kbits bitstreams at connections to public telephony networks (and vice versa). The use of voice compression make FAX services and analogue modem types of services difficult to directly connect over GSM. However, digital data services are supported with 9,6 kbits per channel. The mobile set may be used as modem to connect a notebook computer to the Internet (via serial interface cable, infrared or bluetooth). High Speed Circuit Switched Data (HSCD) allows to bundle several channels together in order to achieve higher bit rates. Another service which had been designed into GSM from the beginning is the Short Message Service (SMS). Today, it has reached an astonishing acceptance and popularity. SMS allows to send text messages of up to 160 characters per message, which are transported in the signalling network of the GSM Network Subsystem-
1.5.3 Establishment of connections

The typical assemply of components of a GSM network are shown in Figure 1-37. On the left, the mobile set connects to a base station over the GSM air interface. As indicated on the top of Figure 1-37 , the Base Station Subsystem connects to the Network Subsystem. There, the other components mentioned above con be found.
31
Fig. 1-37 GSM Components
BSS
NSS
SMS-C AC HLR OMC BTS MSC VLR
BSC
digital radion transmission
A-Interface
BTS
Abis-Interface
EIR
MS
Air-Interface
Voice Mail System
AC: Authentication Center BSS: Base Station Subsystem BSC: Base Station Controller BTS: Base Transceiver Station EIR: Equipment Identification Register HLR: Home Location Register
MSC: Mobile Switching Center MS: Mobile Station NSS: Network Subsystem OMC: Operation and Maintenance Center SMS-C: Short Message Service Controller VLR: Visitor Location Register
The mobile set, which today is a rather small device of less than 100 grams of weight, still indicates its origin by the correct name: mobile station. Literally, a "mobile station" is a portable radio station. Because subscribers in a mobile network cannot be identified by the line or radio channel they use, the mobile set needs to provide its specific identity to the network. This is achieved by the Subscriber Identity Module, the well known SIMcard. The SIM card is a chip card (or smart card), which contains a secret key. This key is used to identify the subscriber (actually the key is never transferred over the network but used to generate a signature to a random message send to the mobile set, which proves that the mobile set knows the secret). In order to avoid misuse, the SIM card may be protected by a PIN code, which must be entered by the subscriber in order to activate the card (and thus the mobile set).
Portable radio stations
32
Fig. 1-38 Basic Sequence of a Mobile Terminating Call

Location Area 7 6 Mobile SC 4 3
HLR
Home Register 2
Telephone Network
7 8 7
GatewayMobile SC
5 6
6 Visitor Register
2b 2a
VLR
Radio Cell Radio Base Station
What happens, when you get a call?
In order to show how the different network components co operate, we will follow the sequence of an incoming call from a fixed line to a mobile subcriber. Figure 1-38 shows the different steps: (1) The call from the fixed network is transferred to a Gateway MSC. The correct mobile network and the Gateway MSC may be identified from the structure of the mobile number (see section 1.5.5) (2) The Gateway MSC requests information about the actual location of the subscriber from the HLR (3) The HLR delivers the required information. If the subscriber is not located in the area of the HLR, the HLR knows which VLR actually takes care of the subscriber. (4) Using the information obtained from the HLR, the MSC initiates a connection to the target MSC. (5) The target MSC reuests the actual location of the subscriber from its VLR. (6) The VLR delivers the requested coordinates. (7) The MSC does know which area, but not exactly in which cell the subscriber is in. So it pages all BTS in the corresponding area. (8) The mobile set responds on the page requests, authenticates its identity and receives a session key for encryption. The connection is establis-
33
hed as soon as the subscriber answers the call.
1.5.4 Interfaces and Protocols

The sequence described in the last section demonstrates, that, most probably, there are many protocols to be followed and a variety of messages to be exchanged. In this section, we will have a look at interfaces and protocols. Figure 1-39 shows the corresponding view of Figure 1-37.
Fig. 1-39 Interfaces and Protocols
Mobile Set
CC SMS SS
BTS
BSC
CC
MSC
SMS SS
MM
MM
RR
RR
RR BSSAP Layer 3 SCCP + MTP BSSAP Layer 3 SCCP + MTP Layer 2 MTP Layer 1
Layer 2 LAPDm Layer 1
Layer 2 LAPDm Layer 1
Layer 2 LAPD Layer 1
Layer 2 LAPD Layer 1
Layer 2 MTP Layer 1
Um Air Interface
The interfaces shown in Figure 1-39 are:
Abis Interface
A Interface
Behind the curtain
Um: represents the interface between mobile station and base station, i.e. the air interface, which uses TDMA-Frames (Time Division Multiple Access) in a GSM specific format Abis: uses 2Mbits/s lines to connect the base station to the base station controller. The traffic from the radio part per 2 Mbit/s line represents up to 80 channels (in a 64 kbits/s structure with 16 kbits/s per channel) A-Interface: compliant with regular 2Mbits/s trunks in switched networks including the signalling system no. 7. Each traffic channel now represents the standard format of 64 kbits per channel. The protocols shown in Figure 1-39 correspond to three layers: physical layer (layer 1), data link layer (layer 2) and network layer (layer 3). First, we have a
34
look at the layer 2 protocols: LAPDm: A mobile version of the ISDN framing protocol LAPD, which takes care of the safe transport of signalling information MTP 2: Message Transfer Part of the signalling no. 7 type of layer 2 protocols. The layer 3 protocols differentiate the different functions of the network elements in GSM. Functions such as Radio Resource Management (RR) need to be contains in the mobile set, the base station and the base station controller. Other functions such as Mobility Management (MM) are just passed by through BTS and BSC (see Figure 1-39), they concern arrangements between the Mobile Set and the Mobile Switching Centre (MSC). A brief summary of the layer 3 protocols (or rather sub layers of layer 3): Radio Resource Management (RR): This protocol arranges the resources of the air interface, such as access to channels and allocation of channels. It also takes care of searching for a subscriber (paging) for an incoming call (see step (7) in the scenario in section 1.5.4), as well as random access to channels by a mobile set for outgoing calls. Mobility Management (MM): As already stated, this protocols concerns arrangements between the mobile set and the MSC. Mobility Management includes procedures for Authentication, which is the basis of the localisation of a roaming subscriber. It also arranges for the hand-over procedure of a moving subscriber to another cell. Mobility Management is the condition for the following protocol layers (sub layers). Call Control (CC): Establishes, monitors and disconnects incoming and outgoing connections. Co-operates with the following Supplementary Services and Short Message Service. Together, these protocols are named Connection Management. Supplementary Service support (SS): Handles special features such as display of the called party number, put calls on hold, hand-over of calls, 3 party conference, display of charging information etc. Short Message Service (SMS): Handles exchange of telegrams between mobile sets (internally represented as part of the signalling messages).
1.5.5 Addressing and Identification of subscribers

How to address a mobile user?
With moving subscribers through the network, addressing and identification is much more complex than in a fixed network. Subscribers are addressed by their mobile telephone number and also own a universal identity, which is stored in their SIM card. Home Location Register (i.e. the home post office) and Visitor Location Register (i.e. the post office at the visited place) take care of the required associations between addresses and identities. Addresses: Mobile Subscriber Number (MSISDN): is associated with a mobile termination in a specific GSM network. The format is compatible with the international scheme for telephone numbers (the so called E.164 numbering
35
scheme). Figure 1-40 shows the structure. A Mobile Subscriber Number contains a country code (49 for Germany), a national destination code which represents the network (or is translated into a network), the code of the HLR in charge of this number, and finally the subscriber number. Thus, the MSISDN is a pointer to the HLR which is in charge of a subscriber. Mobile Station Roaming Number (MSRN): A temporary number assigned by the VLR and associated with a visiting mobile set, which allows to address the VLR. Handover Number: From the perspective of the MSC in charge of a call, handover represents a call forwarding (i.e. the MSC stays in charge of call control). The handover number is used to forward a call to another MSC in case the subscriber is handed over into the radio domain of this MSC.
Fig. 1-40 Mobile Subscriber Numbers
HLR HLR Destination Code Subscriber Number (SN)
Country Code
National Destination Code
171 - D1 172 - D2 177 - E+ 179 - E2
Identities: International Mobile Subscriber Number (IMSI): A universal unique identifier for the mobile subscriber, which is stored on the SIM card. If the mobile set is switched off (or the SIM card is removed), the MSC will block incoming calls (or divert them to a mail box) in order to avoid pointless paging). Temporary Mobile Subscriber Identity (TMSI): Once a subscriber is authenticated (i.e. his identity has been proven), the VLR in charge assigns a temporary identity to this subcriber. The temporary identity works as a pseudonym for the subscriber and helps to protect his privacy. Local Mobile Subcriber Identity (LMSI): An optional further local pseudonym which may be assigned by the VLR following updates of the subscriber location. International Mobile Station Equipment (IMEI): Not only the SIM card has a universally unique identity, but also (and independently from the SIM card) the mobile set: the IMEI. This basically corresponds to the use of MAC addresses in computer networks. The IMEI may be used to locate or to bar stolen devices. Identities for location areas and base stations: In order to support hand overs, there are identities for location areas. Other geographical identi-
Who is this?
36
ties are cell identities, which identify a radio cell within a location area. Base station identity codes allow to identify base stations from different networks.
1.5.6 Sequences in calls and connections

In this last section about GSM, we will show some scenarios for outgoing calls, incoming calls, location updates and hand over in more detail. The idea is to give an impression what is specific for a mobile call, and what the associated protocols are doing. It will not provide an in depth analysis.
Outgoing call
Radio channels are not assigned to terminals, but represent a shred media which needs to be allocated according to demand. For an outgoing call, the mobile set will first need to get hold of a channel (by using a "random access" procedure), and then signal a service request. Figure 1-41 shows the sequence of events.
37
Fig. 1-41 Sequence of an outgoing mobile call
BSS Random Access
VMSC/VLR
GMSC
Exchange
Establish a Signalling Link
Service Request (MS-No.,Service type ...) Authentication (RAND/SRES)
Encryption (Cipher Mode Setting)
SETUP (B-Number, Bearer Service, Tele Service...)
Allocate User Channel
IAM (B-Number, Bearer Service, Tele Service...)
ACM (B-User available, Ringing) ALERT
ANS CONN (establish connection)
Cennection
38
Next, the mobile set will need to identify (this procedure is called authentication). Following authentication, encryption is set up with a session key send by the network. At this stage, the regular procedure for setting up a call connection follows (which includes the allocation of a traffic channel and alerting the called party).
Incoming call
What, more specifically, happens, when you get a call?
The incoming call (see sequence shown in Figure 1-42) to a mobile subscriber corresponds to a mail which is relayed to the actual place where the subscriber is located. First of all, the subscriber number (MSISDN) allows to identify the correct network and the responsible HLR (home post office). The HLR contacts the VLR/VMSC in charge, which generates a transfer of the temporary address (MSRN, see section 1.5.5) to the MSC.
39
Fig. 1-42 Sequence of an incoming mobile call
BSS
VMSC/VLR
HLR MAP: Send Routing Info
GMSC IAM
Exchange
MAP: Provide Roaming Number (IMSI/LMSI) Check authorisation and requested services
(B-Number Tele Service ) HLR Request
(B-Number, Tele Service)
MAP: Result (MSRN)
MAP: Result (MSRN) IAM
(B-Number, Tele Service) Read subscriber data from VLR Paging Random Access Set up Signalling Connection Response to Paging (MS-No./CKSN/MS-Classmark) Connection Resolution Authentification (IMSI/TMSI)
Cipher Mode Setting
Call Setup (BC/Facility) Assign Channel (TCM Assignment) ALERT CONN ACM (B available, Ringing) ANS (establish connection) Connection
40
The GMSC now sets up a connection to the visited MSC (VMSC). Still the exact location of the mobile subscriber is not known (i.e. which radio cell he is in). Thus, the target MSC (VMSC) is paging the corresponding base stations. The requested mobile set responds by starting the random access procedure to allocate radio resources. After a signalling connection between mobile set and VMSC, is established, the mobile set responds to the paging request. The following steps are not entirely new. Following authentication and set up of an encrypted connection, a call is set up and the calling party is alerted (that the mobile set is ringing now). If the called party accepts the call, a connection is established.
Location management (Roaming)

How does the network keep track of mobile users?
How does the Home Location Register know, which Visiting Location Register is handling the subscriber? This is achieved by a procedure called Location Update. Location updates take place if the mobile set is switched on, whenever it is moving into a different location. They also take place, when a mobile set is switched on in a new place (e.g. following arrival at an airport or railway station). Figure 1-43 shows the procedure.
Fig. 1-43 Location Updates
new BSS Random Access VMSC/VLR HLR
Establish Signalling Connection Request Location Update
Update Location Insert Subscriber Data Subscriber Data Insertion Ack.
Confirm Location Update
Update Location Ack.
In GSM, a location update is always activated by the mobile set. If the mobile set moves into the area of a new VLR, the HLR is informed about the change. There are two different cases here: (1) The mobile set is not registered in any VLR in this are (e.g. if it is switched on after a travelling for a while). In this case, the subscriber information is requested from the HLR and transferred to the VLR in charge. (2) The mobile set has been registered in an VLR already. In this case, the subscriber information is transferred from the previous VLR to the
1.6 GPRS - General Packet Radio Service
41
new VLR in charge. A location area may comprise multiple cells. Within the location area, no location updates are required. Location updates take place, when the device is switched on, but do not require the hand-over of active connections from one cell to another.
Hand-over
If a mobile set is engaged in a connection and moves from one cell to another (such as someone walking through a city, or driving in a car while running a phone conversation), the connection needs to be maintained without interruption. This is called hand-over. In a simple case, the mobile set moves between cells which belong to the same base station controller. In more difficult cases, the cells belong to different base station controllers or different MSCs. Figure 1-44 shows those scenarios.
Keep talking while you drive
MSC
MSC
Fig. 1-44 Hand-over between Cells
Location Area
Location Area
Zelle
BTS
BTS
BSA
Base Station Area (BSA) BSA
BSA
BSA
Handover
Handover
Location Update
In any case, the request for a hand-over is triggered by the base station subsystem based on measurements of the quality of reception. The MSC, which is handling the active connection, arranges for the hand-over of a base station subsystem with better quality of reception. In the scenarios shown in Fig. 144, this arrangement may either include own base station subsystems of the MSC, or base station subsystems of another MSC. In any case, call control stays with the original MSC (the anchor MSC).
1.6 GPRS - General Packet Radio Service

1.6.1 Summary
GSM is a connection oriented service. While it allows data connections (for instance with a browser of WAP browser on a mobile phone, or from a notebook computer which uses the mobile set as a modem to connect to the Internet), GSM always will allocate one or more channels to this specific connecCircuit switched connections are not effective for data traffic
42
GPRS provides a better utilisation of resources for data
tion. This is not an optimum solution for the "bursty" type of Internet traffic (while browsing, there are long periods of silence which do not need a channel assigned). GPRS represents a packet based data service in GSM networks. It uses the same radio resources as GSM, however allocates them in a different way. For instance, a set of GSM channels representing a total 115kbits/s (with 8 GSM channels) are allocated on demand and shared between a number of subscribers. The allocation of GSM channels for GSM is up to the network operator and also up on demand. If there are no GPRS requests, no channels will be allocated. As a general policy, GPRS fits in the gaps left in the GSM radio resources. GSM channels will always have priority. Beyond the base station subsystem, GPRS is not using 64kbit/s channels from the MSC either. Instead, it is using its own data equipment (just as a DSL modem on a fixed line does not terminate at a local exchange). Because there is no constant allocation of resources, GPRS allows the network operator to offer volume based tariffs (rather than time based tariffs). This differentiation is maybe the most significant feature of GPRS. It significantly facilitates the introduction of new, data based services.
1.6.2 Architecture
Components of GPRS
The architecture of GPRS as extension of GSM is shown in Figure 1-45. The physical infrastructure in the base station subsystem (BTS and BSC) remains unchanged. However, there is a functional upgrade required (such as a software upgrade). The mobile set must support the GPRS way of exchanging information. Plain GSM phones or PC-cards will not be able to use GPRS, but most mobile sets which went on the market after 2001 support the standard.
Fig. 1-45 GPRS Architecture
GSM
U mInterface FDMA/TDMA
ISDN
VLR BTS MSC
A-Interface
MS-GSM
Air-Interface 64 kbit/s
HLR/(GR)
BSC
Gb-Interface
SGSN
GGSN
Packet Network
The Base Station Controller supports a new interface for the packet based data: the Gb interface. The interface to the MSC (the A-interface) remains unchanged. The network element, that connects to the Gb interface of the BSC is the SGSN, the Serving GPRS Support Node. So what is the "serving" part of this entity? The mobile set needs to register at the SGSN (to do this, a Packet Temporary Mobile Subscriber Identity, or P-
1.7 UMTS - Universal Mobile Telecommunication System
43
TMSI, is used). Also, the SGSN assigns an IP address to the registered subscriber (a dynamic IP address provided by the network operator). Data communications uses logical links between the SGSN and the mobile set. Physical resources are assigned to those logical links on demand. The second new network element introduced by GPRS is the GGSN, which means Gateway GPRS Support Node. It interconnects the IP-Domain of the mobile network operator to the Internet.
MS Applicat.
Network Layer
Fig. 1-46 Communication Protocols in GPRS

GGSN SGSN Relay SNDCP GTP BSS Relay RLC BSSGP MAC PLL RFL Um RFL Gb RFL RFL Gn RFL Gi NS LLC BSSGP NS TCP/UDP IP Data Link IP GTP TCP/UDP IP Data Link
IP SNDCP
Data Link Layer
LLC RLC MAC
Physical Layer
PLL RFL
SNDCP: Subnetwork Dependent Convergence Protocol LLC: Logical Link Control RLC: Radio Link Control MAC: Medium Access Control PLL: Physical Link Control RFL: Physical RF Layer
BSSGP: BSS GPRS Application Protocol GTP: GPRS Tunneling Protocol TCP: Transmission Control Protocol UDP: User Datagram Protocol IP: Inernet Protocol NS: Network Service
Figure 1-46 shows the protocols used in GPRS for the chain of Mobile Set, Base Station Subsystem, SGSN and GGSN at the different layers (physical layer, data link layer, network layer). We will not further discuss them in this place. One interesting part is "IP over IP" at the GGSN, which results from an IP tunnel (GTP) between SGSN and GGSN.

While GSM has been a European initiative, UMTS soon became a global activity, based on the success of GSM. Countries like the USA and Japan, which have less or no GSM infrastructure deployed, also became engaged in order to create a global standard. UMTS claims to be the third generation of cellular mobile systems (i.e. the generation following analogue standards and digital standards like GSM). UMTS also claims to integrate all mobile technologies including cordless system (or local area systems) and satellite based systems. Figure 1-47 shows the UMTS zones.
The next generation of cellular mobile networks
44
Fig. 1-47 UMTS Zones

Zone 4: Global
Zone 4: Global Zone 3: Suburban
Zone 3: Suburban
Zone 2: Urban
Satellite
Satellite
Zone 2: Urban
Zone 1: In
Zone 1: In-Building
- Building Pico
World
World-Cell
- Cell
Macro
Macro-Cell
- Cell
Micro
Micro-Cell
- Cell
Pico-Cell
Cell
Cell size follows density of traffic
Services should be available to the user through all zones in a transparent way. The zones include: Pico Cells: The typical radius of a Pico Cell would be about some 10 meters, which is sufficient to cover access at home or in the office. The user is supposed to move slowly (not faster than 10 km/h) and to be provided with a channel of 2 Mbits/s. Urban Cells: An Urban Cell (or Micro-Cell) represents a "hot spot" in an urban area with a radius of about 100 meters. Users are supposed to move while running a communication link either with medium speed (max. 10 km/h) to get a capacity of up to 2 Mbits/s, or to move at higher speeds (max. 120 km/h) and get a capacity of up to 384 kbits/s. Suburban Cells: Suburban Cells or Macro-Cells are supposed to cover rural areas and the road systems. Their radius is about some kilometres. Communication is supported at speeds up to 120 km/h (medium mobility with up to 384 kbits/s) and up to 500 km/h (high mobility with up to 144 kbits/s). Global Cell: The Global Cell also covers deserts and oceans. Areas are supposed to be between some 10 km to some 1000 km (to be covered by satellites). Channel capacities will be limited (max 144 kbits/s).
1.7.1 Architecture
Components of UMTS
The high level architecture of UMTS, as shown in Figure 1-48, is not too different from GSM. It basically distinguishes the following areas: User Equipment: The UMST Mobile Set (MS, Mobile Station) and the UMTS-SIM card (U-SIM). UMTS terminals support data services and multi-media services (audio, video, pictures). UMTS Terrestrial Radio Access Network (UTRAN): The base stations and base station controllers which arrange the cellular radio infrastructure. Core Network (CN): The network covers mobility management (roaming, hand-over), handles connections and transport of traffic, provides services and administrative functions.
45
other mobile or fixed Networks
Fig. 1-48 Basic UMTS Architecture
CN Core Network
Transport user data, Roaming, User data bases, Services
UTRAN UMTS Terrestrial Radio Access Network

Radio interface and radio specific funktions (Radio Resource Management)
MS Mobile Station
Radio interface, Service execution User interface
USIM UMTS Subscriber Identity Module

User specific data authentification for network access
UMTS handles a variety of different zones and their associated cells (Pico Cells, Micro Cells, Macro Cells), which may overlap according to the required density of traffic. Figure 1-49 shows the overlay of the different zones.
Fig. 1-49 Overlay of different Zones
Macro Micro Pico
46
Different releases with different technologies
UMTS is scheduled to be rolled out in different releases, which introduce different technologies. The segmentation in releases has been enforced by the enormous pressure, which had been on the standardisation groups to publish specifications for an early roll-out of UMTS in the years 1999 to 2000. The different phases and the technology they represent are shown in the following sections.
1.7.2 UMTS Phase 1 (Release 3 or Release 99)

UMTS radio access in combination with GSM core networks
Phase 1 of UMTS basically introduces a new radio subsystem into a core network, which is compliant with GSM and GPRS. The radio subsystem uses a wide-band code multiplex technology (CDMA). Code multiplex does not assign channels of a specific capacity, but rather makes the whole signal spectrum available to all devices, which decode the signal which is addressed to them by correlation. Thus, channel capacity limited by the number of active devices (which lower the signal to noise ratio, just like many people speaking in the same room). The radio subsystem of UMTS and the way it allocates resources seem to be more appropriate to future services, which tend to be more data oriented than plain voice calls. Figure 1-50 shows the architecture of UMTS Phase 1. At the radio part, GSM is supplemented by the UMTS radio part (UTRAN). Compared to GSM, the network elements have been named differently: base stations are now called Node B, the base station controller is called RNC (Radio Network Controller)
Fig. 1-50 Architecture of GSM and UMTS Phase 1

Um
GSM BSS
BTS BTS
BSC
TRAU
Abis
IWF/TC
Gb
MSC/VLR
GMSC
PSTN ISDN
Abis
UTRAN
CSE RNC
Iu(CS) Iu(PS)
EIR
HLR
AC
Node B
Uu
Iub
Node B
Iub Iur
SGSN
Gn
GGSN
Gi
X.25 IP
Node B Node B
Iub
GSM Phase 2+ Core Network
RNC
Iub
AC: Authentication Center BSC: Base Station Controller BTS: Base Transceiver Station (GSM) CSE: CAMEL Service Environment (GSM SSF und GSM SCF) EIR: Equipment Identification Register GGSN: Gateway GPRS Support Node GMSC: Gateway MSC
HLR: Home Location Register IWF/TC: Interworking Function/Transcoder MSC: Mobile services Switching Center PSTN: Public Switched Telephone Network RNC: Radio Network Controller SGSN: Service GPRS Support Node TRAU: Transcoding and Rate Adaption Unit VLR: Visitor Location Register
UMTS also supports voice channels, which connect from the circuit switched interface of the RNC (the Iu(CS) Interface in Figure 1-50) to a transcoder, which interconnects to a regular GSM MSC. The packet switched interface of
47
the RNC connects to the Serving GSN (SGSN) of GPRS (the UMTS packet interface is called Iu(PS)). The other network elements should be know, from GSM (with the exception of the CSE, which represents a service control point for number translation services provided by an Intelligent Network). The main reason to deploy UMTS phase 1 is to enhance to capacity on the air interfaces with a new technology, instead of a further increase of the capacity of GSM radio (which would require smaller cells and more antenna in dense areas).
1.7.3 UMTS Phase 2 (Release 4/5)

UMTS Phase 2 changes the architecture of the core networks. Phase two has two steps with different architectures: Release 4 introduces the concept of next generation networks, which separate control and transport in the MSCs and put everything on IP. Release 5 introduces the concept of an IP based multi-media domain, with more IP based protocols (such as the Session Initiation Protocol, SIP, for call handling; also ATM as a transport layer is to be replaced by MPLS).
Separation of control frm handling payload in the core network
Call Control Level MSC Server GERAN UTRAN

A Mc Nb Nc
Fig. 1-51 UMTS Release 4 Architecture
GSMC Server
Mc
Iu
CS-MGW
CS-MGW
Bearer Level
Figure 1-51 shows the architecture of Release 4. The packet switched part (SGSN and GGSN) remain unchanged and are not shown in Figure 1-51. However, the MSCs have been replaced by an MSC Server (which contains the control functions), and MSC Gateways (Which actually handle the payload traffic). This brings more diversity to communication protocols (e.g. the control protocols between controllers and gateways).
48
Fig. 1-52 UMTS All IP Core Network (Release 5)
IN and Application Servers

CSE WAP
...
UTRAN
Node B
Uu Iub
CSCF RNC HLR R

Iur
MGC
PSTN MG R ISDN
Node B
Iub
Node B Node B
Iub
IP-Backbone
Iu(PS)
RNC R SGSN
All IP Core Network
R GGSN
Gi
X.25 IP
Iub
MG: Media-Gateway MGC: Media-Gateway-Controller CSCF: Call State Control Function R: IP-Router/IP-Switch
All over IP
Also the Gateways now use IP as transport level. This has been indicated by the overview shown in Figure 1-21 in section 1.2.3. In some more detail, data streams are carried over the Real Time Transport Protocol (RTP), which is IP based, and uses ATM-(AAL2) as supporting layer. Signalling protocols use other transport layers. Figure 1-52 shows a rough sketch of the Release 5 architecture.
1.7.4 UMTS Service Areas

No national boundaries
As already GSM, UMTS differentiates between areas, which describe the location of a mobile subscriber. UMTS knows the following hierarchy of service areas: Internationsl GSM/UMTS Service Area: The world wide area with access to a UMTS/GSM-System. National Service Area: The area covered within a nation, which is identified by the Mobile Country Code (MCC) and the Country Code (CC). A National Service Area multiple contain multiple networks, which are represented by PLMN Service Areas. PLMN Service Area: PLMN (Public Land Mobile Network) is another work for a national cellular mobile network. A PLMN Area is characterised by the Mobile Network Code (MNC) and the Network Destination Code (NDC). A national network may contain a circuit switched (or voice based) Service Area, and a packet switched Service Area (as follows). MSC or SGSN Area: An MSC Area (respectively SGSN Area) describes an area, which is controlled by an MSC (respectively SGSN). These areas
49
now contain circuit switched or packet switched location areas (Routing Areas). Location Area (circuit switched): The location area (which corresponds to the location area discussed in more detail in the context of GSM) contains the most detailed information about the actual location of a subscriber. The location area of a subscriber is maintained in the VLR (respectively MSC/VLR), to locate the subscriber for an incoming call. Location Areas can be identifies by a global unique Location Area Identifier (LAI). Routing Area: The Routing is the equivalent if the circuit switched (or MSC-controlled) location area. It is controlled by the SGSN, which keeps information about subscribers with packet based services located in this area. Routing Areas also come with a globally unique identifies, the Routing Area Identifier (RAI). Cell Area: The smallest unit of a subscriber location in a cellular system. The Radio Network Controller holds information about terminals located in a cell. Radio cells may be identified by globally unique Cell Global Identifiers (CGI).
1.7.5 Identities and Security Aspects in UMTS

While in GSM, the network is requested to identify towards the network, the network does not prove its identity to the terminal. In UMTS, both terminal set and network need to identify to each other. This represents the normal procedure: someone checking your passport or your Metro ticket also needs to identify as some who is actually authorised to do so (this is usually done by a by wearing a police uniform or an identity badge). In UMTS, there are identities for terminal devices and network elements. For terminals, the following identities apply: IMSI: The International Mobile Subscriber Identity is the same as in GSM. It consists of a mobile Country Code (MCC, 3 digits), Mobile Network Code (MNC, 2-3 digits) and the Mobile Subscriber Identification Number (MSIN). All together, the IMSI has a maximum number of 15 digits. It is sutored on the USIM card (the UMTS SIM card). TMSI: The Temporary Mobile Subscriber Number represents an identity, which is temporarily assigned by the VLR in order to protect the privacy of the subscriber. The TMSI is 4 bytes long and it is stored by the terminal on the SIM card. The acronym is pronounced "Timsi" (as temporary IMSI). P-TMSI: The Packet Mobile Subscriber Identity (P-TMSI) represents a TMSI for packed based services. Because the packet channel is handled by different network elements (the SGSN instead of the VLR), a separate identity is assigned. The P-TMSI is 3 bytes long and is also stored on the USIM. IMEI: The International Mobile Equipment Identity is a unique identifier for the terminal device (like MAC addresses in computer networks). The
Who is this network? Who is this mobile user?
50
IMEI may be checked before communication against a central registry, the Equipment Identity Register (EIR). The IMEI is a 15 digits number (6 digits type approval code, 2 digits final assembly code, 6 digits serial number, one digit reserved). Identities used to identify the network to the terminal are the following: RNC Identifier: Identifies an RNC (Radio Network Controllers) within an UTRAN. In combination with the Mobile Country Code (MCC) and the Mobile Network Code (MNC) they provide a global identifier for RNCs. UTRAN Registration Area (URA): The URA is a network specific identifier, which describes a number of cells (maximum of 3 cells) at different layers. It is used to organise soft-handovers. UTRAN Cell Identifier (UC Id): The UC Id allows to identify a cell within a radio network subsystem. It consists of the Cell Id and the RNC Id.
UMTS provides a better level of security than GSM
In comparison to GSM, UMTS utilises an extended set of security checks. These include equipment checks (based on the IMEI), use of temporary identities as pseudonyms (TMSI and P-TMSI), authentication of both the terminal against the network, as well as the network against the terminal (the terminal may check, whether the network is authorised by the operator of its home network), extended encryption of communication links, as well as checks of data integrity. The last one has been introduced in UMTS to protect signalling messages from manipulation (message authentication).
1.7.6 UMTS Services

Beyond the telephone service
In general, UMTS provides a platform for applications. It is much better suited for data applications than GSM. UMTS provides the basic services, which are also called Bearer Capabilities. In Release 4 and 5, UMTS is provides endto-end IP connectivity (IP bearer) from an application server to a terminal device (MS, Mobile Set). Figure 1-53 shows an overview. At application level, the network elements of UMTS become transparent (they do not need to be considered by a developer of applications).
1.8 Web based service architectures
51
Fig. 1-53 Service Layers in UMTS R4/5

MS Application Service Server CPE
IP-Bearer UMTS-Bearer SGSN RAB
GGSN
QoS enabled Elements Access Server
GTP-Tunnel
Complex applications, such as integration of a mobile device into a workflow including messaging services, may be provided by attaching an application server (Server) to the network. The mobile set (MS) communicated to this server through UMTS. The server connects to any other equipment installed in the Internet or at the customers premises (CPE) over the Internet.
For applications, the network is transparent

Over the last 10 years, the Internet has gained a tremendous growth and acceptance, mainly by the applications E-mail and the World Wide Web. Progress in computer technology has made extremely powerful hardware available at reasonable prices. Also, storage and data base technologies have increased performance and are widely used. At the same time, through progress in optical networks and router technologies, the performance of core networks has increased significantly. This development makes new methods and platforms available for telecommunication software engineering: - Web-Engineering provides new methods and components (middleware, object oriented frameworks, Web-Services) - standard platforms for hardware and operating systems can be used - data bases and fast communication links allow the virtualisation of resources (data may be separated from specific network elements, processing power may be distributed more easily). New methods for software engineering and the development of applications allow to break from some traditional design principles. Some examples for traditional design principles: - Traditional network design in telecommunications (such as in ETSI, 3GPP) starts with a functional architecture (defining the functions neeYouve got mail!
The traditional way: functional architectures and protocols
52
ded, breaking them down into logical entities, and defining the interfaces and protocols between those entities). While this approach generates complete functional architectures (such as ISDN, GSM, or UMTS), it also generates specialised architectures, which live in isolation and are difficult to extend with new functions. - Traditional procedures in the Internet (such as in the IETF, Internet Engineering Task Force) concentrate on recommendations for protocols, i.e. a specific solution including reference implementations for proof of concept. While this approach is flexible, it does not provide architectures at all.
New ways: Middleware and frameworks provide a higher level of abstraction
Systems today are able to carry much more middleware (that is much more software and more pre-fabricated software). This allows to put the problem at the next level of abstraction. Rather than the distribution of specific functions, generalised functions may be distributed (the specific function of a network entity is formally described in a generalised way and included in the network entity). The message protocol does not matter, it is an automatic follower to functions (i.e. by using a protocol framework such as SOAP or ASN.1). The communication interfaces between functional entities may be negotiated (for instance, HTTP represents the common denominator to carry a protocol framework, but a more performing protocol can be used if it is available between two functional entities). In this abstract functional view, data and processor power may also be separated and allocated later and according to demand. Such options provide the basis for new design principles for network architectures and the development of application software. In this last section of chapter 1, we will have a look at the history and the general structure of telecommunication networks, as well as the basics of the new concepts (such as what object oriented frameworks mean and how WebServices work as an implementation of distributed computing). The subjects will be followed up in more depth within the following chapters. Here, the intention is to present a rough overview.
1.8.1 Traditional architectures for services

Networks
ISDN
ISDN represents a typical example of a universal network architecture. This claim is in its name: Integrated Services Digital Network. Against the recommendations of many specialists, at the end of the 70ies, it was decided to digitise voice networks. There were little economical reasons at that time (analogue networks were doing fine), the main reason was the ability to integrate data services and future applications within one network (in those days, data communications were point-to-point links with 4,8 kbits/s and the progress described in the beginning in this section was far from being obvious). In the end, ISDN has been an economical success, because progress in computer and chip technology allowed digital network elements (digital exchanges) to become much smaller, much more performing, needing less repair
53
and floor space in buildings, which allowed operators to reduce costs and meet increasing demand on connections for phones and data. Now, about 20 years after the digitisation of telephone networks, it is about time for the next generation of networks. GSM has been specified in the 80ies and has been rolled out since the early 90ies. Technologically, it builds on ISDN, but introduces completely new concepts, such as identities for mobile sets and the corresponding data bases to handle mobility management. With GPRS, a packet network is introduced for the first time in a traditional telecommunication network. Connecting a modem to a fixed telephone line (or ISDN line), is not the same thing: packets are transported over continuous bit streams, which is entirely unefficient and a waste of resources. With DSL (Digital Subscriber Line), packet networks are introduced on the fixed subscriber line in the late 90ies (and transported over a separated core network from ISDN). UMTS as next generation technology to GSM builds on IP (with releases 4 and 5). However, the design principles have not changed from ISDN and GSM. IP is basically used as a transport layer for a variety of network entities and their associated protocols. In the fixed networks, the next generation of networks follows the same design principles as in UMTS. The Internet represents an overlay network to existing telecommunication networks. It is using its own scheme of addressing and routing on top of any available connections. For instance, when a PC connects to the Internet, it receives an IP address from the Internet Service Provider. The type of connection (modem, GSM, DSL) is irrelevant. Identification is at application level (e.g. the user ID and password that T-Online requests). The separation of network addressing and identities has been one of the benefits of applications in the Internet: There is no specific Internet access line for a subscriber, access to services such as E-mail of Home banking can be provided from every terminal and any network. Openness and general availability also have drawbacks: they can more easily be misused. The Internet knows an impressive amount of malicious attacks (such as viruses, worms, trojan horses, intrusion, denial of service attacks, spam, ...). Closed environments like the traditional telecommunication networks are much more resilient against such attacks. Reasonable security measures most certainly represent an instrumental part of the design of networks and applications.
GSM
UMTS
Internet
Open environments prvie less protection
Terminals
In traditional networks, the terminal was an integrated part of the network. An ISDN telephone set provides exactly the functions which are supported by the network and which are specified for instance in the European standard for ISDN. A GSM mobile set comes with an in-built telephone service. It includes more features, such as SMS or a personal address book. However, there is little the user or a third party can change. Menus with ISDN or GSM for instance, are fixed. SMS display on a fixed line requires a special telephone set. New terminals are becoming more flexible. They may be programmed by third parties. There are even standard platforms becoming available which support different manufacturers. Some examples include the Java Edition for mobile phones (J2ME MIDP), the Java Framework for applications on TV setSpecialised terminals
Universal terminals
54
Top-Boxes (MHP). In other cases, the operating system represents a platform to program and install applications (such as Palm OS, Symbian OS or Pocket PC). In many ways, terminal devices are becoming much more flexible to download and run different applications, which may contain everything the user specifically needs for the communication demands in his job or private life.
Services
Specialised services
In traditional designs, services have been part of the network. Among others, ISDN provides telephony, FAX and video-conferences. GSM provides mobile telephony including global roaming and fast hand-over. Packet based services may be provided either through circuit switched pipes (or tunnels), or, alternatively, over attached networks such as GPRS or the DSL infrastructure. Another part of the service architecture of traditional networks are the so called Intelligent Networks. Like the databases used for mobility management in GSM, Intelligent Networks provide data bases for number translation services with flexible rates (such as the free of charge service dialled with 0800, or a variety of rates and services offered with 0900). Another application of Intelligent Networks is Number portability (keep the telephone number if you change your service provider or if you move at a different place in the same town). Intelligent Networks are also used to handle most of the pre-paid mobile telephone contracts (in this case, the database keeps track of the pre-paid accounts and decrements them according to usage).
1.8.2 Object oriented software design

Object oriented design provides models of our technical environment
Pre-fabricated software, re-use of components, separation of implementation and usage of a framework represent the result of object oriented software design. The major promises are a better stability of software (by re-using proven components and proven concepts for the design) and less development efforts (by using common models, well defined frameworks and pre-fabricated components). In summary, this represents a standardisation of components and methods. Why does standardisation go well together with object oriented design? The main reason is, that object oriented design supports the modelling of our environment quite well. Figure 1-54 shows some objects together with their associated attributes and methods.
55
Fig. 1-54 Objects, Attributes and Methods
The first object (the play card showing a car) represents an abstract view of a car. In the play, attributes are extremely important (like maximum speed, motor power, weight etc). In real life (with a real car), for most people the methods are more relevant (such as "drive", "stop", "open the door", ...). The second object represents a mobile phone with its methods "dial number", "hangup", "accept call", "send SMS" etc. The third object represents a TV set. Intuitively, objects, attributes and methods seem to be familiar concepts to us. Strictly speaking, objects are instances of an abstract idea, which generalises the object. The abstraction of the real instances is called a class. When we talk about the class of a car, a mobile set or a TV, we think about the general properties of the specific model, that every real device of that sort will have. In other words, the class represents a template for objects. On the factory belt and in real life, we will find objects, not classes. In fact, classes represent a botanical or zoological concept. In the time of the analogue TV, radio and phone player, there would have been little benefit in such as classification. Today, most such devices include a microprocessor and many common subsystems (such as buttons, displays) and handle digital media. Classification of subsystems will show many similarities between classes of the same kind and even between different kinds of devices. The botanical concept for software is generating models for systems and subsystems.
Classification of objects
Modelling of subsystems
56
Fig. 1-55 Object oriented Software Design
Encapsulation of attributes and methods
The crucial point
Another properties of object oriented design is the encapsulation of data. The object provides the methods to change its internal data. This makes software more resilient to mistakes by developers. It also provides the basis to create frameworks. The user of a framework only needs to know how methods are invoked (i.e. the name of the method, parameters, return values). The user of a framework for instance is a developer of applications. He does not need to care about the implementation of the classes and methods that he uses. The implementation of a framework is entirely up to another developer. Usually, this developer is the supplier of a device, that implements the framework, such as a mobile phone which complies to a Java framework such as J2ME MIDP 2.0. The benefit of frameworks is this separation of powers. The implementation may be completely replaced by a more stable or powerful implementation without any effect on the applications developed on top of the framework. Figure 1-55 shows a trivial example of an object. The object represents a mathematical point on an even plane. Its attributes are the co-ordinates (xp, yp). Using one of the methods the object provides will change these co-ordinates (like move_to(10, 17)). Strictly speaking, Figure 1-55 represents a class, i.e. is a template for point objects. A program can use this template to construct many instances of the class (objects), which exist in physical memory until they are destroyed.
1.8.3 Web-Services and distributed computing

Currently the World Wide Web (or short: the Web) is based on the exchange of documents, which are requested, transferred and displayed from a web-server by a web browser. Figure 1-56 shows the structure of a web-browser, which represents the client function in the web. The web represents a distributed architecture of an unlimited number of servers and clients. Documents may be retrieved by pointing at their location (using a Uniform Resource Locator (URL), e.g. http://www.dpunkt.de). HTTP represents the transport protocol. Documents are structured in HTML (hypertext mark-up language), or, in more generalised terms, in XML (extended mark-up language).
Fig. 1-56 WWW Client Software
Documents may be nested to each other by including hyperlinks, i.e. pointers to other documents, which may be attached to key words or pictures. This ge-
57
Browser Displaying Content HTTP TCP IP Layer 1 Plug-in Supporting applications
nerates the typical point and click environment for looking up documents in the web. Surfing or browsing represent visits without specific target. A more structured search for specific documents will involve a search engine (such as Google), which indexes web content like the index of a library. Figure 1-57 shows the sequence of requests and responses while looking for documents in the web.
Fig. 1-57 Surfing the Web
Server www.info.de
Homepage
Domain Name Server
Disk 2 4 3 1
Server www.more-info.de
Homepage
WWW
A more generalised kind of distribution may be achieved by not limiting requests and responses to the exchange of documents, but by directly nesting applications to each other over the web. This concept is called Web Services. It implements general concepts of distributed computing and distributed objects in a Web-compliant way. That is, HTTP is used as transport protocol and XML is used as message format. However, the messages do not represent requests and responses for documents, but requests to execute a remote function and send the result with the response. While HTTP and XML represents a widely available transport layer, the most relevant concepts are the following:
Nesting applications
58
Service Registry
Use of a service registry to look for services: This corresponds to using the so called yellow pages of a telephone directory to find a specific service (like a pizza service in the neighbourhood). The directory returns a pointer (URL) to a server which offers the requested service. In Web Services, the service registry is named UDDI (Universal Description, Discovery and Integration). Use of a framework protocol to translate service requests into messages, which may be carried over HTPP, but also over other transport protocols. In Web Services, the framework protocol is named SOAP (Simple Object Access Protocol). The name is probably not very well chosen. SOAP allows to access remote objects in the sense of distributed computing, but it is not really simple (it is represented by a rather complicated XML structure). The most relevant point is, however, that an application programmer does not need to care about SOAP or any other protocol. WebServices represent a completely automated environment (the compiler takes care of protocols and messages). Use of a formal description of the functions, that a server provides. The Server itself contains a description, how to invoke functions (i.e. the name of the functions, the parameters and return values including their data types). The formal description may be used by a tool to automatically generate a client software to the server. In Web Services, the formal description of server functions is named WSDL (Web Services Description Language). Those concepts are hardly new, but represent the foundation of distributed computing, which are generally contained in remote method invocation (remote procedure call) or the Common Object Request Broker Architecture (CORBA). However, Web-Services implement those concepts in an extremely popular way which is backed by all major players in communications and information technology. How does invocation of a web service work? Figure 5-58 shows the basic scenario.
Framework protocol
Interface description
Distributed computing
Fig. 1-58 Access to Web-Services

Service Look-up Service Address (URL) Client UDDI-Server HTTP-Demon SOAP-Server Internet Program
RPC
Service Invocation (Method)
The first step may represent the look up of a service in a service directory of registry. This step is not mandatory. If the location of a service is known already, it may directly be addressed by invoking it with its URL. In case a service registry is used, the registry will return a URL as pointer to the services (or a
59
choice of URLs). Providing directory services to clients may represent a service in its own. If the URL of the server is known, the service may now be invoked by the client. This triggers the execution of a remote procedure call (RPC) at the server. The results are delivered to the client. In fact, some details have been left out of this chain of events: How does the server function register at the directory (the UDDI)? How is the appropriate client function for the server generated? We will have a closer look.
UDDI-Server Repository 1. Publish Client 2. Search SOAP 3. Invoke SOAP WSDL
Service Discovery by UDDI
SOAP-Server Dienst
Figure 1-59 show a more detailed view at service discovery (i.e. how services register and how they may be looked up). A server (SOAP server in Figure 1-59) may publish ist services at the service registry (UDDI). To do so, it uses a pre-defined format, which includes keys, which allow to identify the service entry. Also, the description includes the name and contact address of the service provider. For business services, more formal descriptions may be included. The essential point is, that the service entry also includes the URL of the server, that actually provides the service. By contacting the UDDI server (by its URL) the client may discover the service description and the pointer (URL) to the server. Now, the second detail (how to provide a client function to the server) needs to be resolved, before the service may be invoked. Following reception or knowledge of the URL of the service, invocation requires two steps (1) generation of a client function to the service, (2) using this client function to invoke the service. Step (1) first requests and receives the formal description of the server function to the client. This represents a regular HTPP request, which returns the WSDL description of the service as an XML document. Anyone may do this with your browser (switch the view to source code to properly display the XML file on the screen): For instance, Google offers Web-Services, which allow to include Google-search into clients. Simple point your browser at http://api.google.com/GoogleSearch.wsdl. This will return a lengthy WSDL file.
UDDI provides a pointer (URL) to the service
Java WSDL
WSDL -> Java z.B. Glue
Fig. 1-59 Tools for Client Generation and formal Descriptions of Server Functions
Java -> WSDL
60
WSDL provides a formal Interface Definition
The WSDL file, which is received from the server, is not intended for human consumption (although it is in readable XML form). Usually, it may be put through a tool, which generates source code for a client function (for instance in Java). There are also tools for the opposite way (e.g. Java to WSDL). At the server side, WSDL is also not generated by a human programmer. It is automatically generated by the server, which provides Web-Services. Figure 1-61 shows the principle.
Fig. 1-60 Using a Web-Service

WSDL Client Fetch WSDL SOAP-Server Dienst Invoke Response SOAP
Invoke
Binding
Response
Binding to a service
Step (2) now represents the invocation of the service by using the client function. The required messages to be send between client and server have been defined at the compilation of the WSDL in step (1). They are using the SOAP protocol framework now for message exchange. In the most simple case, SOAP transports the messages over HTTP. However, other protocols may be used (such as the CORBA protocol IIOP). Invocation of services binds the program, which is executed in the server, into the client request. Figure 1-62 shows the sequence of fetching a server description and generation of a client (step (1)), and execution of the client function (i.e. invocation of the service at the server, step (2)). More details of distributed computing will be presented in chapter 3. In this place, the intention was to present an alternative way inter-operation between network elements to the traditional way of defining a function, an interface and the associated protocols. With Web Services, this process is automated.
1.8.4 A challenge for a new service architecture

Why does a mobile phone not plug into a LAN?
In this last section of chapter 1, we will present an example of an application, which goes beyond the limits of current network design. One of the current limits is, that services are enclosed into specific networks. We cannot plug our mobile phone into the telephone socket and have a call. We cannot plug our mobile phone into a LAN and use it over the Internet. The reason is, that services are enclosed into specific networks. The type of network access already determines the service.
61
How could an alternative architecture look like? An alternative architecture would need to allow separation of access and service. For example, we could take a mobile phone with a bluetooth interface, and install a software on it, which provides the telephone client. Such a device could actually connect over a Bluetooth access point (e.g. a LAN access point, which uses a cable modem, DSL modem, ISDN or UMTS for Internet access). In fact, a bluetooth enabled PC, which connects to the Internet, could represent this function. Figure 1-61 shows the scenario.
Fig. 1-61 Make your mobile phone a cordless phone
local Server 2 3 6 GSM-Exchange or GSM-Gateway HLR 7 5 4 4a 4b UDDI-Server Pointer Server for GSM-Services
GSM-Interface
The sequence of connecting the phone and having a call as follows: (1) Within the office or at home, if Bluetooth radio coverage is provided as alternative, the mobile phone decides not to use the GSM interface, but to connect to a Bluetooth access point. (2) To make is more complex, we assume, that a telephone service for the phone agent of the mobile phone is not known in the local area network (Intranet of the company or local home network). A local server, which acts as a proxy to the mobile phone, requests service information from a registry in the Web (UDDI). (3) A server is detected and contacted, which provides telephone services over the Internet and over GSM. From the server, a formal description is extracted, which allows to generate a client to the telephone service in the local server. (4) Following a request by the mobile phone to set up of a call, the telephone server authenticates the mobile phone at its associated HLR. In comparison with section 1.5 (see GSM call scenarios), the authentication procedure is now carried over bluetooth and over the Internet, rather than using the GSM network for transport. Else, the procedure remains the same. (5) Following authentication, the local server receives a pointer to a gateway, which connects the call to a GSM network.
Voice over Bluetooth
62
(6) The local server establishes a connection through this gateway and sets up a call to the required destination. (7) The rest of the call set up (locating the terminating mobile subscriber), corresponds to standard procedures in GSM.
Download the application to your phone
In comparison to traditional scenarios, communication in this scenario is enabled by the following new principles: (1) A client software may be installed on the telephone set, (2) gateways arrange the connection between established networks and new components. This method effectively separates the service from the type of network.
2.1 Processes and Protocols
63
2 Protocol Engineering
In this paragraph, we will have a look at communication between systems. Communication is based on the exchange of messages between the systems. Systems have been programmed to follow a specific behaviour, so the exchange of messages needs to follow specified rules, or protocols. The exchange of messages according to protocols represents a fundamental principle in communications. Rather than starting each time from scratch, conceptual architectures and methods have been established for the design and development of such systems. Those methods are summarised as protocol engineering. In section 2.1, we will show a way to decompose the complexity of communication between systems into a modular, layered architecture, the so called ISO/OSI reference model. The basic principle is to assign different jobs to different functional layers, so one module may use another module as service. Next, we will have a look at the bahavious within the systems. In order to describe the interior of a system, the model of a Finite State Machine is introduced, i.e. a system may be described as being in a specific state, until it changes to a different state. Changes between states may be triggered by messages, which have been received. In this way, transactions between systems may be described as a sequence of events. For the design of sequences of events, states and protocols, there are formal methods. Among the tools which are used specifically in protocol engineering is SDL, the Specification and Description Language. In section 2.2, the basic concept is introduced. To some extent (i.e. in simple cases), the formal correctness of the design of protocols may be validated by checking state transitions for dead-end streets and other flaws. The principle is shown in section 2.3. Implementation and tests demand special attention for systems, which interoperate with each other. Rather than debugging and testing code on a single system, it needs to be checked whether communication between systems works in a correct way, i.e. conforming to protocols. Such tests demand test configurations with the real implementation and a test normal which allows to check the conformance of protocols against a specification. Also, transactions on the communication links will need to be analysed. The principles are shown in section 2.4. The chapter ends with a practical case of a conformance tests in section 2.5, and another practical case of a communication system used in small devices (Bluetooth) in section 2.6.
Communication between systems follows protocols

Our daily life is organised in a way, that many complex procedures are offered as services. We are able to qualify and work as specialists and to engage specialists for specific tasks. For example, we may engage a mail service to deliver a letter. As a customer of this service, all we need to do is to put the letter in an envelope, address it in the right way and drop it in a letter box. We rely on the mail service to deliver the letter to the right mailbox. In addition, we
Complex procedures are offered as service
64
may register the letter in order to get a confirmation of receipt or in order to trace its route. Figure 2-1 shows the principle.
Fig. 2-1 Principle of service layers
An example: the mail service
The mail service corresponds to a message delivery service in a communication network. As a user of this service, we do not need to care about the way the letter is actually delivered. In abstract terms, the mail delivery service represents a service layer (layer N in Figure 2-1). Within this layer, there may be another layered structure, which may be useful for the postal organisation, but is hidden to the user of the service (such as the collection of mail from letter boxes or the transport of all assorted mail from one city to another). Addressing and sending mail (layer N+1 in Figure 2-1) may also represent a service layer to a still higher service (such as the printing and sending of bills or advertisements by a company specialised on this service for another company). The same concept applies for the communication between systems over a network.
2.1.1 ISO/OSI Reference Model

Generalisation of service layers
The Basic Reference Model (RM) represents the generalisation of a functional hierarchy for the communication between systems. It distinguishes different types of systems, different functional layers for protocols and a generalised architecture for protocols. The Reference Model has been standardised by the International Organisation for Standardisation (ISO) in the standard ISO 7498. The target is to provide a framework for the connectivity between systems, i.e. Open Systems Interconnection (OSI). The ISO/OSI Basic Reference Model contains 3 concepts: Structure Concept for the role of communication systems and functional layers Service Concept describing a model for the communication between functions of the same layer and between layers Protocol Concept describing the encapsulation, decapsulation and handling of service specific information between adjacent protocol layers and between systems at the same layer.
65
Structure Concept
The Reference Model defines different classes of systems and entities, which are shown in Figure 2-2. Application Entities represent logical units (such as software applications running at a system), which communicate with each other. Systems are either End-Systems (user terminals such as PCs, mobile phones etc.), or systems within the network, i.e. Transit Systems, which arrange for the communication links (such as routers, exchanges etc). Transmission Links represent the channels for communication between the systems.
Systems and entities
Fig. 2-2 ISO/OSI RM structure - basic elements
The systems shown in Figure 2-2 already show different levels of functional content. An application entity at an end system (such as the application that allows you to compose and send an SMS on a mobile phone) contains a higher level of functions than a transmission entity (such as a network elements that delivers packets containing the SMS through the network). The Reference Model contains an abstract view of functions at different layers, which is shown in Figure 2-3.
Functional layers
Fig. 2-3 Functions of the layers
66
Physical layer
Logical link layer
Network layer
Transport layer
The bottom layer is the Physical Layer. The Physical Layer takes into account the different properties of the channel in use (such as a radio link or a wireline connection of a specific kind). It provides an unprotected connection between systems for the transmission of bits. Among the functions of the Physical Layer are the activation and deactivation of a transmission link, the transmission of bit streams or blocks of bits. It handles all electrical and mechanical functions which are associated with the transmission of bits over the specific channel (such as clock generation, pulse forming, transforming for serial or parallel transmission, bit synchronisation etc). The next functional layer represents the Data Link (DL) layer or Logical Link layer (LL). The Data Link layer provides protected connections between systems. It assures the integrity of data over the Physical Layer by mechanisms such as sequences of data, data flow control, error detection and correction and acknowledgements of receipts). Data Link connections may be established and released. The Network Layer contains knowledge about the topology of the network. It allows to connect to different systems within the network by using addresses or a numbering scheme. The Network Layer provides the establishment and release or connections to other systems in the network. A connection may represent a circuit switched connection or a virtual connection in case of packets being routed between systems. The Transit System shown in Figure 2-2 ends at the Network Layer. Thus, the transit system may represent a router or a circuit switch. While the Network Layer allows to connect to other network elements within the network, it provides little functionality for the transport of data. This is handled by the next layer, the Transport Layer. Pleas note, that a Transport Layer does not need to be present in a Transit System. It provides "end-to-end" control of data transport, i.e. from and End System to another End System. The network appears to be transparent (i.e. not visible) from this layer. The Transport Layer takes care of: - integrity of end-to-end data exchange (including sequence integrity, control of data flow, segmentation and re-assembly, error control) - establishment and release of Transport Connections - multiplexing of Transport Connections to Network Connections - transport layer classes of service to compensate for deficiencies of the network service layer. The upper 3 layers of the Reference Model (see Figure 2-3) represent different application specific aspects: Session Layer: Supports the concept of a session. A session includes a complete telecommunication transaction, such as logging into a system, doing transactions and logging out again. Following session interrupts, the Session Layer provides synchronisation so dialogs may be restored and continued from the point of interrupt (think of filling a form on a website). This mechanism includes protection from loss of data. Presentation Layer: The Presentation Layer takes care of the syntactical presentation of data. In order to allow different systems to interpret the data in the correct way, data need to be presented in a specified format (such as data types). For the description of data formats, abstract langu-
Upper layers
67
ages may be used (such as the Abstract Syntax Notation ASN.1). Application Layer: As shown in Figure 2-2, the Application Layer represents the interaction between applications running on End Systems (such as an e-mail application or SMS application). It is the most complex layer, which also needs to consider properties of the operating system and supporting applications. In terms of communication, the Application Layer contains the most abstract view, such as file transfer, composing and sending an SMS, controlling the configuration of a remote system etc.
Fig. 2-4 ISO/OSI RM structure - layers
Figure 2-4 shows the mapping of the functional layers of the Reference Model to its entities (Figure 2-2). The End Systems are shown with the complete functional stack, while the Transit System in the middle only contains functions up to the Network Layer. Below the Network Layer, the Transit System shows one supporting stack (Data Link and Physical Layer) for each of the connected End Systems. Please note, that those supporting layers could be entirely different from each other (such as in case of a router with wireless LAN interface at one end, and a wireline LAN on the other end).
Layers and entities
Fig. 2-5 Concept of planes in the RM
68
Layers and planes
Another concept of the Reference Model is the use of Planes. While Layers represent a functional hierarchy, Planes are used to describe different types of applications. In Figure 2-5, Planes are shown as an extra dimension to the functional layering. The Planes support different purposes: The User Plane describes the exchange of user information The Control Plane describes the exchange of control information, such as signalling in order to set up a connection before the user channel ist established. As shown in chapter 1, control and user data are kept apart in traditional network design. The Management Plane contains layer specific administration functions, and plane specific administration.
Service Concept
Between the layers: services
How does one layer actually make use of the service of the supporting layer? How does the supporting layer correspond to the supporting layer of the other system? These question are addressed by a simple client-server type of communication model as shown in Figure 2-6. User A is placed at system A, user B at system B. Both are at the same functional layer, e.g. the (N) Service Layer. The (N)-Service Layer is the service provider.
Fig. 2-6 ISO/OSI RM Service Concept - service invocation
Messages for service invocation
Communication between users A and B are relayed by the service provider, i.e. a request from is translated into a request at B. In the opposite direction, a response at B is translated into a response at A. The messages have been named differently. They are called Abstract Service Primitives (ASPs): - (N)-REQUEST: system A, request from service layer (N+1) to N - (N)-INDICATION: system B, request from service layer N to (N+1) - (N)-RESPONSE: system B, response from service layer (N+1) to N - (N)-CONFIRM: system A, response from service layer N to (N+1) The communication between A and B is handled by service layer N, the service provider. Figure 2-7 shows the communication between layers in more detail. User A is positioned at entity (N+1) in system A, user B at entity (N+1) in system B. between (N+1) and (N), the Abstract Service Primitives described
69
above are exchanged. How are requests and responses actually conveyed between systems and between layers?
Fig. 2-7 ISO/OSI RM Service Concept - communication between layers
As with any communications, there are messages to do this. In the Reference Model, there are a generalised or abstract messages and corresponding formats: Protocol Data Units (PDU) and Service Data Units (SDU). Protocol Data Units are exchanged between systems. In Figure 2-7, service layer (N) is shown to exchange (N)-PDUs between system A and B. Service Data Units are exchanged between adjacent service layers. In Figure 2-7, a (N)-SDU is indicated between layers (N+1) and the serving layer (N). SDUs carry the Service Primitives between layers, including their parameters (such as (N)-CONNECT_REQUEST(CalledAddress, CallingAddress, UserData). Service Primitives correspond to procedure calls in a computer program. The serving entity may provide different types of services, such as establishing a connection and the transport of user data over a connection. Services may be identified by Service Access Points (SAP, see Figure 2-7). A different SAP indicator (SAPI) may invoke a different service. A Service Access Point may contain a number of Connection Endpoints to provide different instances of the service. Connections may be provided in a connection oriented mode (establish a connection and then send many data units the same way) or connectionless mode (handle each data unit separately).
Service Data Units and Protocol Data Units
Protocol Concept
In the last section, Protocol Data Units have been used to communicate between systems at the same functional layer. Service Data Units have been used to invoke services between adjacent layers. Apparently, as this same structure applies at different service layers, PDUs and SDUs will need to relate to each other in some way. As it may be assumed, A PDU is used to transfer a SDU from one system to the other:
Encapsulation of Protocol Data Units in lower layers
70
(N)-PDU: (N)-PCI + (N)-SDU The additional part, the (N)-PCI, contains Protocol Control Information, that is, everything that is needed in layer (N) to convey the message (such as addresses, identifiers, indicators for the protocol type, length indicators, sequence numbers, error control etc). Figure 2-8 shows the mechanism of encapsulation from layer (N+1) to layer (N).
Fig. 2-8 SO/OSI Reference Model - Encapsulation
like Russian dolls (matrioshky)
The procedure of encapsulations corresponds to putting a letter (containing a service request) into an envelope (with addressing information on it). Encapsulation is repeated from one layer to the next lower layer. With each step, encapsulation treats the received data as payload and is adding new header information (think of Russian dolls). At the corresponding stack in system B, the data units are de-capsulated in reverse order (that is from the bottom of the stack to the upper layers). In practice, the size of data units may vary at different protocol layers. Data Unit Management provides a set of functions for segmentation (splitting a PCI and SDU in order to carry it over multiple PDUs) and re-assembly (the reverse process), as well as blocking (package multiple PCIs and SDUs into a larger PDU) and de-blocking.
2.1.2 Numbers and Addresses

You know the name, you know the number
Telephone networks
When going back to the initial example of the mail delivery service, it becomes obvious, that a network needs addresses in order to define its topology. In the mail system, addresses follow a hierarchical system: the nation, city (including ZIP-code), street and number. Without addresses, there is no network. In fact, the absence of street names and house numbers may create total confusion and is an effective protective measure against intruders. The numbering in mobile networks has been described in chapter 1 already. In mobile networks, there is an international agreement on the MSISDN (the Mobile Subscriber ISDN number). It also follows a hierarchical structure (country codes, mobile network code, subscriber address). In fixed networks, ISDN numbers are structured in a similar way. They represent a 15 digit number, which contains a country code, a national destina-
71
tion code, and a subscriber number. Numbering schemes in telephone networks are standardised by recommendations of the ITU, such as E.160 and E.164. Numbering in the Internet predominantly uses two levels of addresses: the network topology is represented by IP addresses. They follow a hierarchical structure. Another level of addressing represents domains (such as www.domain.de in the Web, or user@domain.de for e-mail). For addressing, domain names are resolved into IP addresses by specific data bases (the Domain Name Servers). With number portability and service numbers (such as 0800xxx), telephone networks apply the same principle (the translation of logical addresses into physical addresses). There are also concepts (such as ENUM), which associate E164 telephone addresses with Web-Domains. The use of addresses is at the Network Layer is instrumental for the organisation of the network. However, it should be noted that addresses are used in the other layers of the Reference Model, too, in order to identify the correct peer-entity. Prominent examples are the MAC-Addresses (Media Access Control) used in Local Area Networks, and the ISDN addressing of Service Access Points (SAP) at Logical Link Control. At the Transport Layer of the Internet, there are addresses for TCP-ports.
Internet
Network layers
2.1.3 Communication Processes and Protocols

In this section, we are going to have a look into the interior life or the systems, which communicate with each other. Within each system, different flows of control may be active. Control flows correspond to processes. One of the processes is the Kernel process of the operating system. This process is responsible for starting and terminating other processes. Smaller systems (such as embedded systems or mono-tasking devices) load one single program as soon as they are powered up. In an abstract view, we will consider the interior life of a system as a process. Processes will use protocols to communicate over communication interfaces. Communication means the exchange of messages, such as Protocol Data Units between the systems. Figure 2-9 shows the principle.
Message exchange between processes
Fig. 2-9 Communication Processes

State P1 Transition 1 2 3 1 4 2 2 4 P2 5
Data-PDU
Control-PDU
Most of the time, a process will reside into a specific state. For example, it will wait for an event or it will process a transaction. For a limited number of such states, the process may be described in abstract terms as a Finite State Machine (FSM).
72
Finite State Machines
A Finite State Machine consists of: - States which describe the actual status of the process - Transitions between states which indicate changes - Representation by a process graph which contains states at the vertex of the graph and transitions at the edges of the graph - Input signals and output signals which represent events for state transitions - Protocol Data Units to carry messages between distributed processes. The protocols used for communication between the processes are assumed to provide all the functions described in the Reference Model. They are essential to keep processes in both entities synchronised. Among the mechanisms to provide this are acknowledgements, time outs, check points for transactions, time stamps, sequence numbers and mechanisms for data flow control.
Keep processes synchronised
Fig. 2-10 Example: Client-Server Communication
States
Figure 2-10 shows an elementary example for communication processes. System A represents a client, which issues a request to receive data from a server. The server is represented on the right as system B. Both client and server may reside in the following states: 0: Disconnected (DISC) 1: Waiting (WAIT) 2: Connected (CONN).
Transitions
The number of the states corresponds to the graphs shown in Figure 2-10. Transitions between states are triggered by user actions or by receiving messages. With each transition, messages are send or received. From the perspective of each individual process, outgoing messages are indicated by a "+", received messages by a "-" in the notation of Figure 2-10. The numbers correspond to the following events: -/+ 1: send/receive Connect Request (CReq) -/+ 2: send/receive Connect Acknowledge (CAck)
2.2 Formal Specifications
73
-/+ 3: send/receive Disconnect Request (DReq). In this simple case, client and server change states in an entirely symmetrical way. In fact, the solution is much too simple to be used in practice. Some problems are evident: if the server becomes inactive during the WAIT state, the client will not realise and will wait for a connection indefinitely. There is no protection against messages being lost or duplicated in the channel. Also, the client disconnects abruptly after sending a disconnect request, without waiting for a potentially ongoing data transfer being terminated.
Issues

2.2.1 Formal Methods
In section 2.1.3 formal methods have already been used in order to describe processes: the Finite State Machine. Formal methods are indispensable in any complex development process. In this section, we will present Finite State Machines and the Specification and Description Language in the context of the general development process of communication systems. In telecommunication software engineering, as in many other software projects, there are basically two major areas of generation: the generation of models and the generation of code. Both areas do not start from scratch, but build on existing components and knowledge. The two associated processes are: Planning and Design: which represents transformations on the model Building: which represents transformations on code. Figure 1-11 shows a very generic perspective on planning and building. Depending on the type and the size of a project, emphasis may be different. In an Open Source project, the model may be well known, so emphasis is on code transformation. In a well defined project, code may be derived automatically at the end of the model tool-chain.
Fig. 2-11 Planning and Building The right tool for every occasion
For entirely new developments, an iterative procedure with two or more complete development cycles may be the best solution: first develop a functional prototype from existing components, then use it to get more detailed spe-
74
Development Process
cifications and develop the next iteration, which is closer to the result and also contains some non-functional requirements (such as better stability, conformance to industry practice). Figure 2-12 shows a more detailed view of the development process. The top down approach starts with the specification of system requirements, which is followed by the specification of functional requirements and the design specifications for the different components of the system. From there follows the specification and implementation of modules, which are composed of units. As indicated in Figure 2-12. Formal specifications and formal validation are part or the design specification. Formal specifications for protocol engineering are described in section 2.2 (this section), some methods for the formal validation of protocols are shown in section 2.3.
Fig. 2-12 Software Development Process
Implementation and tests
Functional tests: protocol conformance
Also shown in Figure 2-12 is the process of Implementation and Tests (which will be discussed in more detail in section 2.4). In fact, iterations may take place at every level, as the specific project demands. Unit tests allow to check the implementation of units. Module tests may check the implementation of modules according to the specification. Both may result in changes of the design specification to eliminate flaws or provide a better design. Some further details on Figure 2-12: Module tests and unit tests are normally done by software engineers and based the source code of the modules. Because the software is known in such tests, they are also called "white box" tests. The next level of tests, i.e. integration tests, functional tests and systems tests, does not need knowledge of the source code. Different components of the system are connected to each other to check, whether their inter-operate correctly and where their behaviour deviates from the desired behaviour. Functional tests represent the conformance to the functional specification and include conformance tests. System tests go beyond the functional requirements. They also include tests of performance, load, stability, behaviour in error situations, tests of user acceptance and any specified criteria of quality. Any changes in design and implementation will require a repeated run of tests in order to prove the quality of the new release. Such tests are called Regression Tests.
75
2.2.2 Finite State Machines

Finite State Machines represent a formal specification for processes with a finite number of discrete states. As shown in Figure 2-13, a Finite State Machine is characterised by a graph, which indicates the states and transitions between states. State transitions are associated with events. In Figure 1.13, state transitions are indicated with input signals and output signals (to signal events), which are received or send by the process before the transition.
Events and state transitions
Fig. 2-13 Finite State Machines
Extended Finite State Machines (EFSM) contain some more attributes and tools, such as a more detailed structure (blocks, channels, processes, tasks), the definition of data types and data structure, attributes for input and output signals and formal languages such as SDL.
2.2.3 Specification and Description Language (SDL)

The Specification and Description Language (SDL) is a standard of ITU-T (Z.100) and is based on Extended Finite State Machines. It uses EFSM as concept to describe processes. SDL provides the following structural concept: System: Like the systems discussed before, a system is an entity, which is well separated from its environment, has well defined boundaries and communicates with other systems over channels and signals. A system consists of subsystems represented by blocks. Channel: A Channel provides unidirectional transport for signals between blocks (i.e. subsystems). Channels may be further refined to containing channel substructures. Signal: A Signal represents an element of data flow, which is used to exchange information between processes. Signals may be defined with data types and data structures. Block: A Block represents a subsystem. It hosts one or more Processes, interconnects to other Blocks by Channels and transfers received Signals to the input ports of Processes. Process: A Process represents an Extended Finite State Machine. It is residing in states, performing transitions to other states and executes tasks. A Process receives and sends Signals. Processes may be further refined by Procedures and Macros.
SDL uses FSM
76
Structural diagrams
The structural elements may be represented in structural diagrams. Figure 214 shows a sample of a process description in SDL. Tasks, states, input signals and output signals are indicated with dedicated symbols. As processes represent a control flow, the structure looks familiar to the flow diagrams used in other process descriptions. From a given control flow, new processes may be created and terminated.
Fig. 2-14 Formal Process Description with SDL
Figure 2-15 shows an SDL diagram of the simple client-server communication processes of Figure 2-10. Within client and server, one process starts at the start symbols at the top. The initial state of the client communication process (and the server communication process) are DISC (disconnected). The client communication process then receives an "open" signal from another process. The client communication process then sends a "Creq" (Connection Request) message to the server and transits into a WAIT (waiting) state.
Fig. 2-15 Example: Client-Server Communication in SDL
Flow of control between client and server
The client communication process stays in the waiting state, until the the server communication process sends a "Cack" (Connection Acknowledge)
2.3 Formal Verification
77
message. Note: Leaving the waiting state and sendeing Cack follows after the reception of an internal signal, that the server is ready to connect, which is not shown in the figure. Reception of Cack leads the client communication process into a CONN (connected) state with the server communication process. The client may now request data from the server. The connection stays, until the client communication process is triggered to disconnect by a "close" message from another process. The client communication process then requests to disconnects and changes into the disconnected state. This fairly simple example should only provide a first impression about SDL as a method. To conclude, the processes that trigger the client communication process in a sequence diagram are shown (see Figure 2-26). In comparison the Figure 2-15, two more instances have been added at the client side: (1) a client object, which provides a simple get()-Method in order to connect to a server and request data. This method returns the requested data. (2) a client stub, which represents a proxy object to the server function. This client stub triggers the client communication process to communicated with the server via the specified protocol.
Fig. 2-16 Example: Sequence of the Client-Server Communication
The sequence now starts with a request from the client object (which again could be triggered by a user through a user interface). The client stub triggers the client communication process to open the requested connection. Then some data are transferred to the server over the established connection which specify the requested data. The corresponding method invocations including their return values are also shown in the sequence diagram. Following transfer of the requested data to the client, the connection is closed again.
Sequence of events
2.3 Formal Verification

To some extent, the properties of a design specification may be checked and proven by formal methods. The choice of the formal specification determines the limits of formal verification methods. In this section, we will apply an algorithmic method to check the design of Extended Finite State Machine. The
78
Global states
method applies to simple conditions with a low number of states and will allow to check for properties such as deadlocks, faulty cycles (lifelocks), completeness (no unspecified messages) and inconsistencies. The method starts with a summary of the states of the individual processes and their associated channels into Global States. Following the selection of an initial Global State, all consecutive Global States are determined. This procedure is re-iterated for each consecutive state in a recursive way. The method is illustrated in the following figures.
Fig. 2-17 Global States including the channel
Including channels
Figure 2-17 shows the summary of processes and their associated channels. As example, the client-server communication from Figure 2-10 has been chosen. The client communication process is represented as process 1, the server communication process as process 2. In addition, the channels between client and server (Channel 12, which indicates the direction from process 1 to process 2), and between server and clients (Channel 21) have been added. The state of a channel is either empty (E), or carries a message. The channel may loose messages.
2.4 Implementation and Tests
79
Fig. 2-18 Example: Verification of the Client-Server Communication Protocol
As initial Global State, the disconnected state of both client and server is chosen. This initial Global State is the starting point of the sequence shown in Figure 2-18. The sequence of Global States only shows conditions without loss of messages (messages are carried over the channel in each case). If there is no protection such as a time-out in the protocol, the client will end up in a deadlock state if the first connect request to the server gets lost (it will transit to the waiting state and wait forever). Among the evaluation criteria are: - deadlocks (paths without exit) - unspecified reception (signals without reception) - non-executable states (not all states are reachable) - ambiguous states (the same global state is reached by different events).
Who wants to wait forever?

Implementation and tests are an instrumental part of software engineering. Sloppy engineering is responsible for the bad reputation of software quality. Figure 2-19 highlights, how large the part of implementation and tests is in the development process.
80
Fig. 2-19 Implementation and Test within the Development Process
Testing represents a professional and creative job in itself and is part of all steps in the development process. In this section, we will have a closer look at conformance tests for protocols.
2.4.1 Hardware and Software Design

Where to find protocols
Where are protocols actually implemented in a system? Usually, the lower layer of protocols are implemented in hardware, such as communication controllers or separate subsystems in a unit. This design is driven by higher performance requirements at the lower layers. Higher layers of protocols are closer to the application and demand more flexibility. They tend to be implemented directly on the host system. For example, a PC may be extended with extra LAN interfaces by adding a board to the system bus. Or a USB-type of Bluetooth-device provides wireless connectivity. In both cases, the lower layers of protocols are represented by a specific hardware. In the case of the Bluetooth device, the physical layer and a large part of the logical link layer really resides on the hardware. All higher layers, including logical link control, are already performed by the host system. Figure 2-20 shows the general concept of a host system with a separate communication controller.
81
Fig. 2-20 Hardware Architecture
The software architecture may be shown in a way, which closer reflects the functional hierarchy, such as used in the ISO/OSI Reference Model. Figure 221 shows the principle software architecture. The communication controller and host system are using an inter process communication, which is handled by the Kernel of the respective operating system. Between processes, communication is arranged by exchange of messages.
Fig. 2-21 Software Architecture
In Figure 2-21, the communication controller is handling almost the complete protocol stack. In practice, the functional split between host system and communication controller may vary considerably (see the Bluetooth USB-device mentioned above). Also, as the Microprocessor keeps moving into more and more devices, there will be a considerable number of future embedded systems.
2.4.2 Model of a protocol stack
82
How does a model for the structure of a protocol stack look like? Figure 2-22 shows a model for one specific Service Layer.
Fig. 2-22 Model Structure of a Protocol Stack
It represents a layered structure of processes. Processes are coupled to each other by message queues (respectively the passing of messages). Each process is represented by an Extended Finite State Machine. Layer management procedures include the provision of timers and configuration of layers.
Fig. 2-23 Event-State Tables
Processes may be administered by tables, such as the Event-State table shown in Figure 2-23. It shows the Event Primitives together with the corresponding transition of states. Event Primitives may be represented by data types.
2.4.3 Protocol Tests

There are different aspects of protocol tests, which may be shown at the Reference Model in Figure 2-24. The test may be targeted at: - a Protocol-Entity
83
- a Protocol Layer (the peer-to-peer relation in Figure 2-24) - the Service provided by this Protocol Layer - the behaviour of the system under unpredictable and faulty conditions (Robustness Tests) - the behaviour of a system under load, which reveal the performance, delays, loss, througput etc. of an implementation (Performance Tests).
Fig. 2-24 Protocol Tests
The first three of the above mentioned aspects represent Conformance Tests. They check the conformance of a protocol implementation with the specification (or more specifically with a reference implementation of the specification). What are the criteria for conformance? There may be mandatory requirements, conditional requirements and options. Conformance includes the dynamical behaviour of the system under test (such as response times). According to demand, classes of conformance may be defined (such as basic interoperability or detailed tests). What is the behaviour be measured against? Test need to be specified. The following hierarchy of test specifications my be distinguished: A Test Suite contains the summary of all Test Cases in a class (which may be grouped into Test Groups). A Test Case contains Test Steps, which are composed of Test Events.
Conformance tests
Test cases
84
Fig. 2-25 Conformance tests with an external tester
There are different methods for conformance tests. A local test method monitors the upper layer and lower layer of a Service Entity (the Entity Under Test, EUT, or Implementation under Test, IUT). The upper and lower layers to the Service Entity are emulated by test equipment. A more thorough test, which includes the Service provided by the Service Layer will use a remote configuration, which is shown in Figure 2-25.
2.5 A practical case: INAP conformance tests

The real thing
In this section, a sample configuration for a conformance test is described in some detail. The systems use the Intelligent Network Application Protocol (INAP). The details, such as the supporting protocols and their parameters are entirely irrelevant in the context of this chapter. The example should demonstrate two things: (1) the practicalities and complexity of protocol tests in a real environment, (2) the methods applied.
2.5.1 Conformance testing concepts

Test System and System Under Test
As protocol tester, a real device is used (the A8619 protocol test system), which allows to simulate a wide variety of protocols in order to test the protocol conformance of telecommunications equipment. Simulation-based test procedures consist of a system under test (SUT) and a test system, which is used to create protocol messages (Protocol Data Units) and send them to the SUT in order to change the state of the protocol layer under test. The state transitions and the associated protocol responses are evaluated by the test system. If the protocol responses are as defined by the relevant standards, a test is passed. Else, it has failed. Because each state of a protocol layer normally is related to a specific protocol event, the behaviour of a telecom protocol layer can be described by a finite state table and the software that controls this state table is called a finite
85
state machine or state engine. Figure 2-26 shows a simple state table and some transitions.
Fig. 2-26 State transition table
The state transitions create the dynamic behaviour of a protocol layer. It is the task of a conformance test system, to verify all possible transitions defined in a transition table and the protocol conformance of all events (parameters and encoding), sent by the SUT. Only a conformance test system is able to send invalid messages to the SUT and to verify the conformance under various conditions, including fault conditions. For this reason, a protocol test suite often consists of different test groups, belonging to one of the following testing goals: - test of valid behaviour (SUT receives only valid events) - test of invalid behaviour (SUT receives invalid events) - test of in-opportune behaviour (SUT receives valid events at in-opportune states.
Verification of state transitions
2.5.2 INAP interface test configuration

The example shown in this section describes the configuration of a conformance test system for the Intelligent Network Application Part(INAP) Protocol. The basic set-up for the interface test is shown in Figure 2-27.
Fig. 2-27 Set-up of the Interface test
86
Where INAP is placed
The protocol interface is located between the Service Switching Point (SSP) and the Service Control Point (SCP). In this example, the system under test is the SSP, which is directly connected to the test system (point-to-point configuration). The latter simulates SCP protocol behaviour. The relevant protocol layer is INAP. The test cases will have to test INAP procedures and INAP PDUs (Protocol Data Units). An important pre-requisite for testing the INAP protocol is the presence of all lower layers in the test system. They have to be implemented to emulate the service, which they provide to INAP. Successful testers put careful attention on the functional states of the lower layer emulator. Without detailed understanding of these layers a successful conformance test can hardly be achieved.
INAP Protocol Stack and test configuration

The INAP protocol stack in the context of the Signalling System SS No. 7 consists of the layers shown in Figure 2-28.
Fig. 2-28 Layers of the INAP stack
If the test case produces INAP messages, all the layers (the lower layer ser-
vice) below need to be emulated by the test system. Figure 2-29 shows the basic configuration.
Fig. 2-29 INAP test configuration
87
The INAP layer of the System under Test communicates with the A8619 test case. This communication is realised with Abstract Service Primitives (ASP) which the test case uses to send information to and to receive information from the lower layer services.
Hardware (Layer-1) parameters

Hardware configuration is necessary for all interface cards: PRI1_P, PRI2_P, PRI3_P, PRI4_P of type E1 (2 Mbit/s). Each card can be configured individually with the same profile selection menu. The configuration relates to the type of cables, the termination needed and various layer-1 parameters, e.g. CRC mode or clock source, the timeslot and the layer-2 controller type. If there is a handset to be connected to test the speech path, then this can also be configured.
Configuration of the physical interface
MTP parameters
Fig. 2-30 MTP parameters
The following parameters relate to layer-2 and layer-3 of the SS7 protocol or MTP level-2 and level-3 (also see Figure 2-30): - OPC (Origination Point Code): the own (A8619 test system) network - address - DPC (Destination Point Code): the network address of the SCP - NI (Network Indicator): needs to be set to the appropriate value (e.g. National Network) - SLC (Signalling Link Code): a variable which contains the Link Code used for Signalling Link Selection. - PC length: the Number of bits used for the OPC and DPC (default = 14 bits).
Layer 2: Message Transfer Part
SCCP Parameters
SCCP parameters are used to configure the SCCP layer. This layer is used to address a point-to point connection between two elements of a CCS#7 network. There are different addressing methods, so the SCCP service provider (the A8619 SCCP emulator) needs to know the required method. The first method is to address a distant service with the DPC address and a specific sub-system number (SSN) which identifies the service within the netLayer 3: Signalling Connection Control Part
88
work element. Another method is to hide the physical network address (DPC) using a logical address the Global Title. This value has to be translated by SCCP to a DPC which can be processed by the MTP. The SCCP also can handle methods to transmit information via different signalling links.
Fig. 2-31 SCCP parameters
The description of SCCP parameters is as follows (also see Figure 2-31): - SI: Service Indicator (for IN = 3) - SLS: Signalling Link Selection (Link-Id of used signalling link) - SSN: Sub-system Number (for IN = 241). The number of simultaneous signalling link connections: default = 10 - XUDT: SCCP frame Type. UDT = normal data frame, XUDT = extended data frame - GT Ind: Set to used, if addressing uses Global Title mechanism - GT: Set to Originating GT value if GT Ind is set to used - GT-DPC: Set to DPC translation value.
TCAP Parameters
Transaction Capabilities Part
The Transaction Capabilities Application Part (TCAP) has the task to support a dialogue between the two IN applications SSP and SCP when an IN service is requested. Because such a service request may contain multiple activities, e.g. send an announcement, collect input digits, etc. each of these activities is wrapped into a Remote Operations Service Protocol.
Fig. 2-32 TCAP parameters
89
Among the TCAP parameters are (also see Figure 2-32): - Protocol: Protocol version - N-Transactions: Max. number of parallel transactions - N-Dialogs: Max. number of parallel dialogues - Transaction-Id length: Length of T-Id parameter - Use Timers: TCAP supervision timer used (Y/N).
Other Test Suite Parameters

The following part explains the procedure to set additional parameters according to the test configuration. There are different types of parameters which relate to the physical and logical configuration of the test environment (Figure 2-33 shows their location): Emulator Parameters (in this case, for the A8619 Analyser) PIXIT (Protocol Implementation eXtra Information for Testing), PICS (Protocol Implementation Conformance Statement) parameters.
Set-up of the test configuration
Emulator Parameters
Fig. 2-33 PIXIT and analyser A8619 configuration parameters
Emulator Parameters affect the emulator, which has to provide the lower layer service. For Intelligent Network tests, it consists of the layers: MTP, SCCP and TCAP. They can be set according to the A8619 configuration procedure. The following table shows the A8619 internal parameter list for emulating lower layers of the INAP protocol stack.
90
91
Table 2-1 Emulator Parameters

Object name SS7_TCAP_STK_B TCAPASP_P PC_Length Combined TCAP_P Protocol N_ISMs N_Transactions N-Dialogs Trans_ID_Length User_Timers SCCP_P OPC Default_DPC SI SSF SLS SSN N_Sig_Conns PC_Length XUDT Global_Title_Used_1 Global_Title_1 Global_Title_DPC_1 MTP3_P MPT_OPC Link_Entry_Used_1 Link_Entry_NI_1 Link_Entry_SI_1 Link_Entry_DPC_1 Link_Entry_SLC_1 Link_Entry_PC_Len_1 ..... Routing_Entry_Used_1 Routing_Entry_DPC_1 Routing_Entry_LS_ID L1_Status_B L1_Status_P Tracer_B Tracer_P SPM_OID CCA_ITF_B CCA_P SDL_ITF_P PRI_B PRI1_P .. PRI4_P Mode Clock_Src L1_Mode Interframe_Fill Ch_A_Mode CH_A_Timeslot Handset_Mode Handset_Timeslot Link Term Description SDL Block SDL Process: Length of Point code SDL Process: Protocol Version Max. number of TCAP transactions Max. number of TCAP dialogues Length of Transaction ID TCAP timers used SDL Process: Origination Point Code Destination Point Code Service Indicator Service Switching Function: Net. Indicator Signalling Link Selection Sub-System Number Max. Number of signalling connections Point Code Length Extended UDT or normal UDT used GT addressing used GT value GT -> DPC translation SDL Process Origination Point Code First entry in link table Link table: Network Indicator Link table: Service Indicator Link table: Distination Point Code Link table: Signalling Link Code Link table: Point Code length ..... First enty in routing table Routing table: Destination Point Code Routing table: Link Set ID SDL Block SDL Process SDL Block SDL Process: Protocol stack definitions list SDL Block SDL Process SDL Process SDL Block SDL Process Test mode: User/Net simulation, monitoring Clock Source: internal, external Layer-1 mode: CRC multi/doubleframe V5.2 filling frames: flags or "1" Protocol interface: SS7, ISDN or V5 SS7, ISDN or V5 timeslot Handset used for speech test Speech test timeslot Parameter Value 14 bits Combined 0 10 40 40 4 octets Without_timers Dec number Dec number IN = 3 National_network Dec number (0) IN = 241 10 14 bits UDT Unused/used Dec number Dec number Dec number In_use National_network IN = 3 Dec number SLC_0 14 bits Entry_used Dec number ID_1 no variables select an object no variables no variables user/net/mon on_board, link Doubleframe Flags SS7 16 off 1 .. 31 Bal 120
92
PIXIT and PICS Parameters

Addresses of the test configuration and protocol versions
The task of PICS (Protocol Implementation Conformance Statement) and PIXIT (Protocol Implementation eXtra Information for Testing) parameters is to make a test suite flexibly usable for different configurations of the network and the SUT. PIXIT variables very often refer to subscriber numbers, addresses etc. which are valid only for the present SUT. The PICS parameters refer to the implemented protocol and very often consists of flags which are used to select the relevant test cases. If only parts of the protocol need to be tested, this part can be selected by PICS variables. Normally we find the definition of PIXITs within the test suite declarations part, in the test suite parameter declarations table. This table defines the PIXIT names, types and if necessary it may also assign an initial value. The TTCN editor can export this table to a PIXIT file, which may then be edited by a PIXIT editor program. Such a tool also has to validate the PIXIT values according to their defined TTCN types. At execution time this file is imported into the Executable Test Suite (ETS) without re-compiling it. Because PIXITs play a very important role in a TTCN test suite, they are explained in a specific PIXIT document.
2.5.3 Protocol Tracer Configuration

TTCN: Testing and Test Control Notation
The Protocol tracer window opens when a TTCN application (simulation) and a monitor application is launched from the files-run menu in the SXI window. The protocol stack can be selected through the files-configuration menu, by selecting the Tracer_B block and the Tracer_P process. Then a list of pre-defined protocol stack decodes is displayed. Generally the A8619 protocol test system defines two kinds of protocol stacks: One stack containing all hierarchical protocol layers and One stack containing only the highest layer (IUT) and a primitive interface below. Such a stack always has the extension ASP (Abstract Service Primitive).
Fig. 2-34 Trace Points
93
The first type of protocol stacks is used for normal tracer operation - decoding a trace buffer, which has been created from a tracer application (monitor). The second type of protocol stacks is only used together with the Simulator. A simulation or ASP-trace is automatically created during execution of a test case. The buffer information contains only the protocol messages at the IUT interface without any lower layers present and thus needs a different protocol decoder. Figure 2-34 shows the positions of a full trace (all layers) and the ASP trace.
Protocol stacks for decoding a trace or to execute simulation
2.5.4 Sample Message Trace

The following trace shows an INAP IDP (Initial Detection Point) message. Layers-1 to layer-3 are decoded with a maximum detail, while TCAP and INAP layers are decoded according to their INAP ASN.1 structure. 20-03-97:15:18:16.605 Port-1 D1-Usr L1->L0 L1: L0_Raw_Message L2: MTP (Bluebook) 0 1....... : Bwd indicator bit....01 Hex .0110110 : Bwd sequence num.....36 Hex 1 1....... : Fwd indicator bit....01 Hex .1110000 : Fwd sequence num.....70 Hex 2 00...... : Spare................Ok ..111111 : Length Indicator.....63 Dec 3 10...... : Network Indicator....National network ..00.... : Spare................Ok ....0011 : Service Indicator....SCCP 4 ******** : DPC..................10-2-00-3 5 ******** : OPC..................14-0-12-0 7 0010.... : SLS..................2 Dec L3: SCCP 0 00001001 : Message type.........UDT-Unitdata 1 1000.... : Message handling.....Return message on error ....0001 : Class................Class 1 2 00000011 : Parameter pointer....03 Hex 3 00001101 : Parameter pointer....0d Hex 4 00010100 : Parameter pointer....14 Hex -- Called Party Address 5 00001010 : Length...............10 Dec 6 0....... : Reserved.............00 Hex .0...... : Routing..............Based on global title ..0100.. : Global title ind.....Transl-numb-encod-nature ......1. : Subsystem nr ind.....Included .......0 : Point code ind.......Not included 7 11110001 : Subsystem number.....INAP (German) 8 00000000 : Translation type.....00 Hex 9 0001.... : Numbering plan.......ISDN/Telephony numbering plan ....0001 : Encoding scheme......BCD (odd) 10 0....... : Spare................00 Hex
ASN.1: Abstract Syntax Notation
MTP (link) address
94
own address
end-to-end address
.0000011 : Nature of address....National significant number 11 ******** : Address..............130323458F BCD -- Calling Party Address 16 00000111 : Length...............7 Dec 17 0....... : Reserved.............00 Hex .0...... : Routing..............Based on global title ..0100.. : Global title ind.....Transl-numb-encod-nature ......1. : Subsystem nr ind.....Included .......0 : Point code ind.......Not included 18 11110001 : Subsystem number.....INAP (German) 19 00000000 : Translation type.....00 Hex 20 0001.... : Numbering plan.......ISDN/Telephony numbering plan ....0010 : Encoding scheme......BCD (even) 21 0....... : Spare................00 Hex .0000011 : Nature of address....National significant number 22 ******** : Address..............9125 BCD -- Data 24 01010111 : Parameter Length.....87 Dec L7: 163TR78 CHOICE { begin [APPLICATION 2] IMPLICIT Begin SEQUENCE { otid OrigTransactionID [APPLICATION 8] IMPLICIT OCTET STRING (90 04 04 84) dialoguePortion DialoguePortion [APPLICATION 11] OBJECT IDENTIFIER (0.0.17.773.1.1.1) [0] CHOICE { dialogueRequest AARQ-apdu [APPLICATION 0] IMPLICIT SEQUENCE { application-context-name [1] OBJECT IDENTIFIER (0.2.262.1.5.0.1.0.1) } } components ComponentPortion [APPLICATION 12] IMPLICIT SEQUENCE OF Component CHOICE { invoke [1] IMPLICIT Invoke SEQUENCE { invokeID InvokeIdType INTEGER (1) INTEGER (initialDP) initialDP OPERATION InitialDPArg SEQUENCE { serviceKey [0] IMPLICIT ServiceKey INTEGER (1) calledPartyNumber [2] IMPLICIT CalledPartyNumber OCTET STRING (83 10 31 30 32 54 08) callingPartyNumber [3] IMPLICIT CallingPartyNumber OCTET STRING (03 13 19 52 13 11)
INAP + TCAP protocol layers start of transaction
logical connection (association)
call control to IN
request service type
service related parameters
2.6 The Bluetooth Protocol Stack
95
callingPartysCategory [5] IMPLICIT CallingPartysCategory OCTET STRING (0a) highLayerCompactibility [23] IMPLICIT HighLayerCompatibility OCTET STRING (91 81) bearerCapability [27] IMPLICIT BearerCapability CHOICE { bearerCap [0] IMPLICIT OCTET STRING (80 90) } } } } } }

This last section of chapter 2 will give another practical example of a protocol stack. Rather than within core networks, Bluetooth represents a system, which is used in terminal sets and embedded systems. Bluetooth is a short range radio communication system for the connection of devices in near proximity. Its history dates back to 1994 when Ericsson studied short range communication to interconnect mobile phones and accessories. So the main features were: low cost and low power consumption. During the study phase it became obvious that such a system has a much larger potential than just in the mobile radio sector. In the year 1998 a Special Interest Group (SIG) was founded which released in 1999 the first version (1.0) for this system. The IEEE has adopted the Bluetooth specification in their Working Group IEEE 802.15 (Task Group 1) which deals with Wireless Personal Area Networks (WPAN) as part of the IEEE 802 LAN/MAN Committee. The name Bluetooth has its origin in the name of the Danish King Harald Blatand (in English: Harold Bluetooth). In the 10th century he had been instrumental in uniting warring groups in Scandinavia. A comparable situation was seen with this new technology: it was designed to allow collaboration between differing industries such as the computing, mobile phone and automotive markets. The logo combines the runic alphabetic characters "H" which looks similar to an asterisk and a "B". The current version of the Bluetooth Specification is version 1.2 from November 2003, however, most implementations on the market today are conforming to version 1.1 from February 2001. Most changes between these two versions relate to editorial issues, so version 1.2 is restructured and follows the rules of IEEE for standards. This description is structured in the following sections: in the radio part, the networking and in the higher protocols.
Short range communications
Harald Blatant
2.6.1 Bluetooth Radio Technology

Bluetooth uses the 2,4-GHz-ISM-Band (Industrial, Scientific, Medical) which is used by many other applications, most prominent currently is WLAN.
Licence free ISM band
96
From the whole 83,5 MHz bandwith a guard band of 2 MHz at the lower end and 3,5 MHz at the upper end are subtracted. The remaining 79 MHz are divided into 79 channels of 1 MHz bandwidth each, as shown in Figure 2-35. All 79 channels are used for communication.
Fig. 2-35 Bluetooth frequency range
Physical layer
Power management
Using an ISM band means that there is no licensing needed (no fee, not even an registration). However, this also means that there is no protection from other users of the same frequencies. In order to make the system robust against disturbances a frequency hopping scheme is applied where 1600 times per second the frequency is changed. This hopping through all of the 79 RF channels is called in Bluetooth terms a channel. A subdivision in time slots follows the hopping scheme which results in time slots of 625 msec, giving a clock rate of 3,2 kHz. Time slots are numbered from 0 to 227-1 and then starting from 0 again. However, the corresponding counter runs from 0 to 228-1 where the least significant bit toggles with the half slot rate. The resulting cycle time is around one day. The hopping sequence has to be synchronised between the communication partners. It is derived from the (unique) Bluetooth address of the master of the communication. With this frequency hopping the disturbance caused by a single carrier is heavily reduced. Only a small part of the communication is then affected and the remaining errors can be corrected on higher protocol levels. The modulation scheme is GFSK (Gaussian Frequency Shift Keying) where a logical one is represented by a frequency higher than the carrier frequency, the logical zero by a frequency lower that the carrier. By filtering the digital data before passing then to the modulator, the frequency efficiency can be optimised and cross talk in the neighbouring channels can be minimised. With 1 MHz bandwidth and a two-level modulation scheme the theoretical bandwidth for digital data is 1 MBit/s. Due to protocol overhead, this is reduced to 432,6 kbit/s per symmetric link or 721 kBit/s and 57,6 kbit/s for an asynchronous link. In Bluetooth three classes are defined with different power output level and (correspondingly) different reach. It is difficult to derive the reach just from the power level because various constraints have an influence like type and position of the antenna, type of the housing (if the antenna is built in), environment etc. So the reach indicated just gives an impression and is not a guaranteed value. On the other hand with directional antennas the reach in a certain direction can be extended.
97
The Classes 1 (1 mW to 100 mW with up tp 100 meters of reach) and 2 (0.25 to 2.5 mW with 10 to 30 meters of reach) have a power control scheme implemented which adjusts the transmitted RF power to the required minimum which is needed to maintain the communication link. In case of a strong receiving signal, the receiver sends a message to the transmitter of the other device requesting a reduction of the RF output power. This process is performed for each bi-directional communication link. If more than two devices are in the network, the power adjustment is done for each link which may result in a situation, where each link uses another value for the RF output power. The power control reduces the power consumption of the device and reduces also the probable disturbance of other communication links using the same frequency spectrum.
2.6.2 Networking
Bluetooth is often considered as a replacement for a cable, as shown in the case a) scenario of Figure 2-36. Examples are the interconnection of a mobile phone with a head set or a PC with a printer. But even in these two examples very soon the requirement to connect further devices will come up, e.g. in the mobile phone case a PDA for dialling from the address book or in the PC case a cordless mouse and keyboard shall also be connected. Bluetooth can cope with such configurations by setting up so called Piconets where up to 8 devices can be interconnected. One of them is the master, up to 7 of them may be slaves (correctly: connected slaves), as in case b) of Figure 2-36.. There are no dedicated masters, each device can act as a master or as a slave. The role will be determined by the connection set up. Devices which are included in an existing Piconet are always slaves. In principle it is possible to change master and slave roles in an existing Piconet.
Much more than cable replacement
Fig. 2-36 Bluetooth Networking Configurations
Even larger networks are possible by the interconnection of so called Scatternets. Here two (or more) Piconets are interconnected in such a way, that one device is master in one Piconet and simultaneously slave in another Pico-
Hip-Hop
98
Ad-hoc
net ( case c) in Figure 2-36). But how is the frequency usage managed? As said before there is a frequency hopping scheme applied to each Piconet. In the case of a Scatternet, each Piconet has its own hopping sequence. It is very unlikely that in a certain time slots both Piconets use the same frequency. However, with the growth of the Scatternets (means: inclusion of further Piconets) the probability of collisions increases. As the hopping scheme is derived from the Bluetooth Address of the master, one device cannot be master of two Piconets (because this would mean both are using the same hopping scheme which will result in 100% collisions). But it is possible that a device is slave in more than one Piconet. Setting up connections and networks in Bluetooth is spontaneous. The technical term for a spontaneous or self-organising way of forming a network this is Ad-hoc-Networking. No pre-configuration is needed. Devices can search for other Bluetooth devices in their proximity. If new devices are found, a logical connection between them can be set up. Depending on the application it might be necessary during the first contact to authenticate on both devices by entering the same PIN code. It is possible then to add the device to a list of authorised devices. In case of future contacts the authentication process for authorised devices it performed without human interaction. Other applications just request an acknowledgement, for example the reception of an electronic business card (v-card). In order to minimise collisions when devices transmit spontaneously, master devices start their transmission in even-numbered slots, slaves in odd-numbered time slots. A packet usually is contained in one slot, however, a packet is allowed to span up to five time slots (so called Multi-slot packets). As the start of transmission is bound to the odd or even numbered slots, there is only an odd numbered count of slots possible. Therefore the Multi may be 3 or 5. For the duration of the Multi-slot packet there is no frequency hopping. (see Figure 2-37).
Fig. 2-37 Usage of Time Slots
Bluetooth device address
Each Bluetooth device has a unique 48-Bit-Address comparable to the MAC-Address in Ethernet. Even more, this address follows the rules of the IEEE for such addresses. It is called Bluetooth Device Address (BD_ADDR) and is subdivided in - Lower Address Part (LAP) of 24 Bit, - Upper Address Part (UAP) of 8 Bit, - non-significant Address Part (NAP) Part of 16 Bit.
99
UAP and NAP are the company ID (manufactuer ID). 64 LAP values are reserved for inquiries (see chapter 2.6.3). This address is also used to determine the hopping sequence of the frequency hopping scheme as mentioned before.
2.6.3 Protocols
The exchange of data between Bluetooth devices uses packets which are positioned in the time slots resulting from the frequency hopping scheme. Bluetooth allows a master to maintain a number of asynchronous communication links and up to three synchronous connection oriented links (SCO) with the slaves. The latter are used to convey audio, mainly speech. Therefore, there is no retransmission in case of lost packets. For data an asynchronous connectionless (ACL) link is used where lost packets are retransmitted. SCO and SCL links can be active simultaneously.
Connection oriented and connectionless types of links
Protocol Stack
The Protocols of the protocol stack shown in Figure 2-38 can be divided in 4 categories: - Bluetooth core protocols (in the box market core protocols) - Cable replacement protocol (RFCOMM): - Telephony control protocols (TCS BIN, AT-Commands) - adopted protocols (everything else).
Fig. 2-38 Bluetooth Protocol Stack
100
Bluetooth core protocols
Baseband layer
Bluetooth core protocols comprise the Bluetooth Radio Layer as it was described in chapter 2.6.2, the Baseband Layer and the Link Manager Layer. Further the adaptation protocol and multiplexer (L2CAP, Logical Link Control and Adaptation Protocol) and the Service Discovery Protocol which allows a device to check the capabilities of the other side are part of the core. In the Baseband Layer the Link Controller performs the encoding and decoding of data towards and from the physical channel. The Baseband Resource Manager handles the access to the radio part. So its main part is a scheduler which grants time slots to the entities which negotiated access. Functions of the Baseband Layer in detail are: Error Correction because a radio channel is very unreliable various error handling mechanisms are implemented. Scrambling in order to ease the clock recovery on the receiving side a sufficient amount of changes in the digital signal are necessary. A scrambler cares for this function. Synchronisation as all devices in a Piconet shall use at a given time a given frequency a strict timing and a synchronisation of the timing of all devices is necessary. An internal clock of 3,2 kHz is used for this purpose. All slaves in a Piconet synchronise with the master. Addressing the Bluetooth Device Address (BD_ADDR) allow for a world wide unique identifier for each device. Security a very important issue in all radio based communication systems. A certain amount of security is provided by the use of the frequency hopping scheme. However, this is not enough when really critical data are exchanged. Bluetooth defines three levels of security: (1) Security Mode 1 (non-secure) with no security on the base band level. (2) Security Mode 2 (service level enforced) adds security after connection set up, e.g. encryption. (3) Security Mode 3 (link level enforced) checks the devices before accepting or denying a connection.
Link Manager Layer
Host Controller Interface
RFCOMM Others
The Link Manager is responsible for the creation, modification and release of logical links. The Link Managers of the devices involved in the link are communicating via an own protocol, the Link Management Protocol (LMP). The Device Manager controls the behaviour of the Bluetooth device like searching for other devices. It is not directly involved in the transport of user data. Interesting is the subdivision shown by the HCI-line which stands for Host Controller Interface. The idea is to have all below the line (marked HCI in Figure 2-38) implemented in the HW of the Bluetooth chip. The protocols above the line are usually implemented in SW on the controller. The Bluetooth Specification contains a detailed description of the HCI with all the command which can be exchanged via the HCI. The cable replacement protocol (RFCOMM) represents the protocol which emulates the behaviour of an asynchronous serial interface. Telephony control protocols are well known protocols from the telephony world: a Telephony Control Protocol Specification (TCS) and the AT-commands which were used to control modems but have now a wider scope. The other protocols shown in Figure 2-38, which have been categorised as adopted protocols, include some well known protocols from the data world (PPP and IP for the asynchronous link) as well as Bluetooth specific protocols
101
like the Object Exchange Protocol (OBEX) which allows the exchange of objects such as electronic business cards (V-cards), pictures or audio files. The Bluetooth Network Encapsulation Protocol (BNEP) allows to transport packets of other protocols (such as IP) over Bluetooth. A Bluetooth implementation does not need to implement a complete set of protocols. Depending on the capabilities, functions and envisaged applications of a device, only the necessary protocols need to be implemented. In the remaining part if chapter 2.6, the most relevan protocols are shortly described.
Implementation depends on device capabilities
Packet Format
How are Bluetooth packets structured and what do they contain? Figure 239 shows the general packet format. The general packet format comprises an access code, a header field and the payload area.
Fig. 2-39 Bluetooth General Packet Format
The access code is used for synchronisation and identification. All devices in an Piconet have the same access code. Therefore Bluetooth devices check the access code of received packets and process them only when it contains the number of the piconet the device belongs to. Usually the Access Code is 72 Bit long, where after a preamble (a series of zeros and ones for bit-synchronisation) a synchronisation word (Sync Word) of 64 Bit length follows, which is derived from the 24 Bit of the Lower Address Part (LAP). A trailer is only used when a header follows (the trailer is also constructed of a series of zeros and ones). The Header contains in 10 Bit the address of the slave (Logical Transport Address, LT_ADDR), the type of the packet (TYPE) and three parameters for flow control. Three principle packet types can be distinguished by the TYPE: - SCO packets (synchronous data) - ACL packets (asynchronous data) - Control packets.
Packet identification
102
Error correction
As the header contains very important information it is error protected in two ways: an 8 Bit error correction code (HEC) is applied to the 10 Bit and the whole 18 Bits are repeated three times (resulting in 54 Bit transmitted). The Payload area contains the user data or control data depending on the TYPE.
Link Manager Layer

The Link Management Protocol (LMP) handles the connection between the devices. The Link Managers of the devices communicate for this purpose. The functions comprise - Connection set up and tear down, - Generation, exchange and check of security keys, - Adjustment of the transmitter output Power, - Negotiation of the packet size, - Handling of QoS requests, - Monitoring of the link. Interesting is the handling of connections and allocation of radio resources. Bluetooth devices are entering after power up the STANDBY state. The device is not member of a Piconet. Every 1,28 sec it searches for devices in its proximity. Power consumption is very low. The device can now leave the STANDBY state in order to listen for incoming connection set up messages (PAGE SCAN or INQUIRY SCAN), to search for devices (INQUIRY) or to send connection set up messages (PAGE). INQUIRY is a procedure to determine which other Bluetooth devices are in the range. During INQUIRY a device collects all information from devices in range (addresses, timing, ..). It is also possible to restrict the scanning by asking only for a certain class of devices to respond (e.g. only printers). If a device is found suited to communicate with, a connection can be set up using the PAGE procedures. Paging (PAGE) is used by a master to activate and connect to a slave whose address is known. The slave has to be in the PAGE SCAN mode to listen for PAGE messages. As the devices are not yet synchronised the master does not know when the slave is listening. Therefore a train of PAGE messages is sent on different frequencies containing the Device Access Code. A device receiving this message and responding synchronises with the master and enters the CONNECTION state as slave. A slave in the CONNECTION state is assigned a Logical Transport Address (LT_ADDR) of 3-Bit by the master. The value of 000 is reserved for broadcasts within the Piconet. The master itself has no LT_ADDR, he is identified by his timing (transmission in even numbered slots). This allows 7 active slaves in the Piconet. (The LT_ADDR was formerly named Active Member Address , AM_ADDR). After setting up a connection, both endpoints (Master and Slave) are in the CONNECTION state and can exchange data. However, in order to save power it is possible to reduce the activity of slaves if currently no data have to be exchanged. Therefore in the CONNECTION state three modes are possible for slaves: Active Mode: Active slaves are listening for messages addressed to them. Therefore all information received is checked. If a transmission grant is
Allocation of radio resources
Connected state
103
received the slave starts its transmission. Power consumption is high in this mode but reaction time is short. Masters are always active. Sniff Mode: The slave is only listening periodically during short intervals (Sniff Interval). The master knows the timing of the slave. As the slave is powered down between the listening intervals power consumption is low, however, reaction time is higher than in Active Mode, depending on the Sniff Interval. Hold Mode: The slave is deactivated by the master for a certain period of time which is negotiated by master and slave beforehand. After this time the slave enters the Active Mode. Power consumption is usually lower than in Sniff mode.
Fig. 2-40 States and Modes of Bluetooth Devices
Figure 2-40 shows the state diagram of a Bluetooth device with all possible transisions. But what to do when more than 7 slaves have to be handled or the power has to be reduced further ? If a slave does not need to participate in a Piconet but shall be synchronised with the master it may enter the PARK state. For this synchronisation and to react on an unpark-command from the master the slave is listening periodically during short intervals in which the master transmits a specific beacon signal. The master knows the timing of the slave. As a slave in PARK mode does not count to the 7 connected slaves in a Piconet it looses its LT_ADDR and is assigned two new addresses: a PM_ADDR (Parked Member) and an AR_ADDR (Access Request). Each slave in the park state is identified by the 8 Bit long Parked Member Address (PM_ADDR). The value 00Hex indicates that this slave is identified only by his BD_ADDR. This allows to address 255 parked slaves in the Piconet using the PM_ADDR. However, using the BD_ADDR to unpark a slave
Parking position
Addresses for active and parked members of network
104
the number of parked slaves is nearly infinite. A slave can only have either an LT_ADDR (in connected state) or a PM_ADDR (in park state). As all transmission over the physical channel start with an Access Code, an Access Request Address (AR_ADDR) is assigned to one (or more) parked slaves to get access. Three types are to be distinguished: Device Access Code (DAC), Channel Access Code (CAC) and Inquiry Access Code (IAC).
Logical Link Control and Adaptation Protocol(L2CAP)

Providing logical channels for connectionless links
L2CAP is only handling ACL (asynchronous connectionless) packets. L2CAP multiplexes information from various higher layer protocols and passes it to the base band. At the L2CAP layer, devices communicate on a peerto-peer basis via so called channels (logical channels, not to be confused with the RF channels or the time slots). L2CAP-channels can be connectionoriented or connectionless. The endpoints of the channels are identified by channel IDs (CID). Two of these CIDs have special meaning: CID=1 indicates that this packet is a control packet, CID=2 indicates a broadcast packet. As various higher layer protocols use L2CAP a kind of protocol identifier is needed in order to enable L2CAP to pass the packet to the right higher layer protocol (comparable to a port number in the Internet). Several parameters can be negotiated by L2CAP, such as: - maximum length of L2CAP packet, the so called Maximum Transmission Unit (MTU). If the higher layer passes packets to L2CAP which are longer than the MTU the L2CAP performs fragmentation. - Number of retries to transmit a packet in case it is not acknowledged. - Type of QoS.
RFCOMM
Serial ports
One of the design goals for Bluetooth was the emulation of well known cable based interfaces. Most prominent still is the asynchronous serial interface. RFCOMM now emulates just the serial interface (and is therefore sometimes named cable replacement protocol). Up to 60 simultaneous connections can be handled by RFCOMM. They are distinguished by a Data Link Connection Identifier (DLCI). The DLCIs for user data are numbered 2 to 61. DLCI=0 is dedicated to the signalling channel.
2.6.4 Profiles and Service Discovery Protocol (SDP)

Profiles for typical areas of applications
To simplify the handling of the various protocols and their parameters so called profiles were defined and new ones are in definition. A profile is not another protocol or protocol layer but a description which protocols to use and in what manner it is to be used for a specific service. It can be seen as a vertical slice trough the protocol stack and defines which options in each protocol in use are mandatory and defines also parameter ranges. Profiles work on several levels. There are profiles for a dedicated service like the Headset Profile which handles the connection of a wireless headset with a mobile phone, but there are also more generic profiles which are the base for
105
dedicated services like the Serial Port Profile which only emulates a serial interface. Figure 2-41 shows the specified profiles and their relationship. (The LAN Access Profile has been deprecated in version 1.2, it will be replaced by the PAN Profile).
Fig. 2-41 Standardised Bluetooth Profiles
Different profiles build on each other. Thus, the figure may be read like this: The File Transfer Profile for example requires the Generic Object Exchange Profile which requires the Serial Port Profile which is based (like all profiles) on the Generic Access Profile. Most profiles have self-explanatory names. Two profiles result from the handling of PDAs: The Generic Object Exchange Profile has its history in the Infra Red communication (IrDA) available in most PDAs and ensures that applications formerly ran over IrDA now can run under Bluetooth. The Synchronisation Profile is used to synchronise the content (such as a name directory or a calendar) of a PDA with the host, usually a PC. The TCS (Telephony Control Protocol Specification) binary based profile handles the signalling for voice connections. It is based on ITU-T Recommendation Q.931 (ISDN D-Channel) with Bluetooth-specific adaptations. Of course an SCO-link for the audio is necessary in parallel. Besides these currently standardised profiles, further profiles is in the specification process. Among them is a profile for Personal Area Networks (the PAN profile) which serves two purposes: - it allows a user to access a network (via a Network Access Point, NAP) and - allows a user to set-up or join a Group Ad-hoc Network (GN). The PAN Profile can be seen as an Ethernet-Emulation over Bluetooth. The Bluetooth Network Encapsulation Protocol (BNEP) substitutes the Ethernet header by the BNEP header. The NAP provides therefore some features of an Ethernet Bridge. Figure 4-42 shows the configuration of the network access
A stack of profiles with increasing specialisation
Personal area network profile
106
and the corresponding protocol stacks. Service Discovery (SDP) and Link Management (LMP) are also in place and work as usual.
Fig. 2-42 NAP in a PAN Configuration
Bluetooth network access point
In the Group Ad-Hoc Network Application the devices in one Piconet exchange data using the BNEP (no support of Scatternets). So it can be seen from the functionality point of view like an Ethernet LAN segment. A list of the actual profiles and their specifications can be retrieved from the Web site of the Bluetooth SIG (see references). Two devices can only handle a service if both have the profile for this service implemented. So after setting up a Bluetooth link and before starting an application the devices check their profiles. For this a specific protocol, the Service Discovery Protocol (SDP) is defined. All devices have a SDP server implemented which stores all profiles available in the device. Services are instances of service classes. A certain service can belong to more than one class, as an example a colour printer can belong to the services classes printer, Postscript printer and colour Postscript printer. Each service class has an Universal Unique Identifier (UUID). If a device now wants to know which profiles the other device offers or whether the other device has a certain profile implemented it SDP client connects to the SDP server of the other device and asks for all profiles (browse) or asks for a certain service class (by asking for a UUID).
3.1 Basic Principles
107
3 Network Organisation

In this chapter, we will find out how a TV remote control works and why we need so many of them. Also, we will find out how functions within a system work and what is needed to distribute functions between systems. Finally, we will have a look at how networks of distributed systems organise and which components within each system are needed to support such an organisation.
How many remote controls do we need?
3.1.1 Communication and Context

Figure 3-1 shows a basic scenario of distributed systems including a TV, a TV set-top-box and a remote control. There are two ways of operation. In case 1 a remote control is used to switch between channels or turn up the volume. In case 2, controls at the set-top-box are used for the same function.
Fig. 3-1 Distribution of functions - direct control vs. remote control
When we press a button directly at the set-top-box, we trigger functions that the programmer of the set-top-box software has provided for this purpose (from the perspective of the programmer, the user is a system, which presses buttons or types text when prompted to do so). The interaction completely remains within the system. While using the remote control, the situation is entirely different. Remote control and set-top-box are on separate systems. They do not share the same software environment and system resources. They need to communicate with each other by sending messages. The messages need to be received correctly and need to be interpreted correctly. If the context needed for reception and for interpretation is not available, the systems are unable to co-operate. This is the reason, why each system comes with its own remote control and why we need so many of them.
Separation of functions
108
Fig. 3-2 Communication by exchange of messages
Figure 3.2 shows the basic concept of distributed functions between System A and System B. System B represents a receiver (such as the set-top box) which waits for requests from System A, which represents a sender (such as the remote control). In more general terms, System B is a server and System A a client. The functions of a client go beyond a pure sender (such as a the remote control). A client may also receive response messages from the server. The ability to send request messages and to receive response messages represents a basic communication link. However, in order to generate a useful interaction, the messages need context in order to be interpreted in the correct way. What is this context within a given system? We will take a look into a real device. Rather than a simple remote control, we chose a mobile phone or PDA based on a modern operating system. Once we understand what context is needed internally, we also know which context is needed to distribute functions.
Fig. 3-3 Communication within the system - The Symbian OS Client-Server Framework
Systems typically consist of hardware and software. Simple embedded sys-
109
tems are not using an operating system and do not support the installation of software applications by the user (except firmware upgrades in some cases such as set-top-boxes or routers). Other systems, such as PDAs and mobile phones use operating systems, which provide application frameworks and provide access to system resources. Usually, they also allow to run multiple tasks in parallel. Such operating systems use the following concepts: processes with own address space threads within a process (same address space as process) a memory management unit to swap address spaces between processes and handle the physical storage of address spaces a kernel which runs in privileged mode, i.e. has the privilege to access system resources and the corresponding address space applications, which are not privileged to access system resources but run in a less privileged user mode. Applications cooperate with the kernel to get access to system resources. Figure 3-3 shows the client-server framework within the Symbian Operating System (Symbian OS). Symbian OS is using a Mikrokernel architecture, which means that only a minimum of code is executed within the privileged kernel mode. Access to files, the windowing environment for user interaction, or hardware drivers for communication interfaces are handled by server functions, which are executed in user mode. The kernel provides access to system resources to the servers. When a name is looked up from the phone directory in such a system, the application will use a file server to access the phone directory. The client application and server may run in different threads of different processes. Interprocess communication can be difficult and tricky to program and thus may generate many problems. For this purpose, the API framework provides a client interface for the application, which allows to access the file server through the kernel in a well organised way. This scenario is shown in Figure 3-3. The client thread and client interface are shown on the left. An application may use this client interface to invoke a server function by sending a message, which is passed through the kernel to the server. The server responds by sending a return message to the client. Through the API framework, there is a context agreement between client and server. This context agreement includes message formats (names of the functions, parameters and return values) including their data types, as well as abstract classes for server and client functions to be implemented by the application developer (also servers may be developed, not only clients to existing servers).
Operating System
Clients and Server communicate through the operating system
110
Fig. 3-4 Example: Client calls server function
Communication by exchanging messages
Figure 3-4 shows the message types used for communication between threads. In this case, a message is represented by a fixed length of 5 subsequent 32 Bit words of a specific data type (such as signed or unsigned integers, or pointer types). The first field of the message contains the name of the function, the following fields the parameters of the function. With this structure, a function call f1(a,b,c) translates into am message as indicated in Figure 3-4, leaving the last data field empty (because the sample function f1 only has 3 parameters). A software module which represents a function usually has a return value, i.e. the value the function returns after execution. In this case, the return value has been specified to be just one 32 Bit expression of a specific data type. In Figure 3-4, the server returns the return value "x", so the complete function call corresponds to x = f1 (a,b,c). On the right of Figure 3-4, there are also two methods from the API framework who are involved in the processing of the message received from the client.
Fig. 3-5 Example: Client call including data transfer
111
While Figure 3-4 explains how functions are invoked between different subsystems (threads), it does not explain how data is transferred (such as the name from the phone directory to the display, or a picture or an audio file). In fact, such data does not need to be transferred, because both subsystems run on the same system. It is sufficient to pass pointers to the address space of the requested data (or processed data). Figure 3-5 shows the principle. The client now invokes a function y = f2 (p,q,r) where f2 is the name of the function, p is a parameter transferred by value, and q and r represent pointers to data to be read and to be written to by the server. On the right of figure 3-5, there are the corresponding server classes. As in Figure 3-4, specific messages are used to invoke specific functions at the server. The server functions and their corresponding messages need to be defined in advance. What else does the developer of applications get as context? For the development of client applications and for the development of server applications there are conventions which are summarized in a framework API. Also, there are sample applications which may be used as a guideline and reference. An API (application programm interface) basically has two sides: (1) functions specified in the API need to be implemented, (2) functions specified in the API (and implemented) may be utilised by applications. Figure 3-6 shows a diagram of the most essential classes out of the framework API for the client-server communication. At the client side, there are functions (methods) to initiate a session with the server and to pass messages to the server. At the server side, sessions may be generated on request. A session holds a set of messages (or rather message processing objects), which invoke specific functions, transmit a return value or read or write data. The details of Figure 3-6 do not matter. The example is only intended to represent a practical view into the interior of a system.
Data transfer
The perspective of the application developer
Fig. 3-6 Example: Context includes framework API for client-server relations
So what can we conclude? The example has been showing interworking between two subsystems with different control flows within the same systems. The essential way of invoking a function in the other subsystem has been a
112
function call. In the chosen example (client-server interworking within Symbian OS), the function call has been translated into sending a message in a specified format. Essentially the same thing happens in any call of a subroutine within a computer program, but it is less visible to the programmer. Because the client and server subsystems in the example have different control flows, the same mechanism may be used for distributed computing. Figure 3-7 show a general scenario. The essential component is the exchange of messages in a specified context. The context includes agreement on the function name, the parameters and return values together with their specific data types. This allows to perform remote function calls (other names are remote procedure calls, or in object oriented terminology, remote method invocation).
Fig. 3-7 Distribution of functions between different systems
Differences in a closed system and separate systems
However, when comparing Figure 3-7 to Fig. 3-3, there are some apparent differences. One is the missing convenience of a common framework API. Another one is the lack of common address space or address spaces within the system. When distributed, clients and servers need to be addressed properly. Also, the common kernel is missing. What does the kernel do in Figure 3-3 anyway? It certainly takes care of the transfer of messages between subsystems (threads) and of handling error situations, load situations and priorities. In a distributed system, this will need to be managed in a different way. When comparing Figure 3-7 with Fig. 3-2, some further generalisations have been introduced. The difference between a sender-receiver cooperation and a client-server cooperation has been mentioned already. As a further concept, the user agent is introduced. When we use our mobile phones, we are in fact doing both client and server functions: when the phone rings and we accept a call, we represent the server side. When we take the phone to make a call, we are representing the client side. Software, such as a Web-Browser, always represents the client function. It may issue requests, but it does not wait for requests or handle requests. Software, which is doing both client-type interaction and server-type of interaction is called a user agent. For instance, the active part of a SIP based telephone is called a user agent. Such telephones are available both as "softphone" downloaded as software to a device or included in a real telephone set. We will use the term "user agent" in the following for any type of system which
113
interacts with other systems. Typical examples would be applets, Midlets or any executable software downloaded to a device, which is communicating with other systems. Software used in file sharing networks (such as Gnutella) or used for instant messaging (such as ICQ) are further examples.
3.1.2 Service Discovery and organisation of networks

When user agents are downloaded as software to devices such as servers, desktop systems, portable computers, PDAs and mobile phones, they can cooperate and form networks with each other. Figure 3-8 shows the principle. Such overlay networks are also is called "peer-to-peer" networks. Because the meaning of a peer tends to be vague, we will keep using the terminology of "user agents" as defined above.
Fig. 3-8 Overlay networks by groups of user agents
In order to form networks, user agents will need to contain functions which allow them to detect other user agents, to communicate with them and to find out about the capabilities of other user agents, such as the services, applications or information they provide. Figure 3-9 shows the essential components of a user agent. In fact, it represents a generalisation of the concepts used in JXTA (which is an architecture for peer-to-peer networks from the Java community). The structure shown in Figure 3-9 allows to discuss the concept of forming networks of user agents in an abstract way. In this terminology, a user agent is a system, which relates to its exterior world by using communication interfaces. The communication interfaces are represented by endpoints shown in Figure 3-9. The communication endpoints look like antenna for reception and sending of signals. A possible physical implementation could be a socket interface.
Organisation of networks at application layer
114
User Agents
What the user agent knows about his external environment (such as other user agents) is kept within a local cache. Among the information contained in a cache are the co-ordinates of other user agents, so a practical example for a local cache would be the addresses contained in the directory of a mobile phone. What makes the user agent interesting to the exterior world is what it knows and what it can do. What it is ready to share with the exterior world (knowledge and services) is communicated by the peer through advertisements. In Figure 3-9, knowledge and services are represented as content (such as a website or a file) or as module. A module would be a function or software, which is executed within the user agent. There are two functional levels of modules: services (the lower level, such as providing routing information or other network specific services), and applications (the higher level, such as finding the next compatible printer on request of another application).
Fig. 3-9 The anatomy of a user agent
Advertisements to communicate supply and demand
In summary, a user agent can offer to other user agents: - Modules: Services and Applications - Content: such as Information, Rich Media, Documents - Knowledge about offerings of other user agents. The last point (knowledge about other user agents and their service offerings) is of great value for organising networks. Thus, user agents which offer such knowledge deserve a specific name: Rendezvous Agents (or rendezvous peers, which describes the ability to arrange appointments). A practical example for a Rendezvous Agent in a network at service level would by a router or DNSserver. However, the definition of a Rendezvous-Agent is not limited at service level, it can provide any type of directory or registry services. At least one question remains: How can the services provided by a user agent be made known to its exterior world? For this purpose, the concept of advertisements is introduced. An advertisement (as shown in the flag symbols used in Figure 3-9) can include the identity of the user agent (names, numbers used as identifiers etc) the identity of a group the user agent belongs to, the modules that the user agent provides, the content that it can make available, as well as the communication endpoints (such as the type of endpoint and addres-
115
ses of the endpoints). Also, an advertisement is used to indicate that a user agent represents a rendezvous agent.
Fig. 3-10 Discovery updates and relations
The concept of overlay networks formed by user agents takes networks to the application layer. While the Internet is organised by IP Addresses, the Web by domains, or telephone networks by telephone numbers, networks of user agents (or peer-to-peer networks) are organised by the addresses of user agents (which correspond to UAIDs), or peer-addresses (which corresond to PeerIDs). For instance, such IDs could be implemented by 128-Bit UUIDs (Universal Unique Identifiers). Networks of user agents are constantly changing, depending on the presence of of user agents and on the way, in which demand and supply is handled by the network. Such Networks are self-organising. Functions like DNS (resolution of Webdomains to network addresses), resolution of telefone subscribers to telefone numbers, or resolution of IP Adresses to MAC addresses in a LAN are allocated to instances of user agents in the network. Resolution within such a network includes everything which is in demand and supply, i.e. services, content, routing information and communication links. If the supporting networks provides specific resolution functions (such as DNS or routing), this resolution maybe re-used in the overlay network. Because of the dynamic nature of overlay networks, user agents need to constantly refresh their knowlegde about their environment. Figure 3-10 shows the basic principles of keeping relations and to update service discovery. Basically, there are two ways a user agent may advertise its services: lacally or at a Rendezvous Agent. If a local advertisment is published, it may be discoverd by other user agents. If the advertisment is published at a Rendezvous Agent, the Rendezvous Agent makes it known to other user agents. How a published advertisment is discovered, depends on how service discovery is implemented: on request of user agents, or by sending messages from the place where the advertisement is published. In any case, the publishing of advertisements will need a decay mechanism. Local advertisments remain valid until they are deleted by the user agent. Advertisements published in a Rendezvous Agent remain valid for a given period of time (such as some hours) and then need renewal by the advertising agent. Else the are removed by the Rendezvous Agent.
Service Identifier
Resolution to match demand and supply
Service inventories
Decay mechanisms for advertisements and relations
116
Also, relations between peers need a decay mechanism. The other user agents that a local user agent discovers may terminate or leave the vicinity of the local agent. The network changes with time. One concept to implement temporally limited relations are leases: Each user agent stores coordinates of other user agents for a limited period of time. After this given time, coordinates are removed or need renewal.
Fig. 3-11 Establish a communication link
How to connect
How do user agents establish communication links? Figure 3-11 shows the principle. There are two basic mechanisms at work: The Discovery Process includes all transactions within the system (new offerings, requests, relations, formation of a network topology, related signalling). Thus, the user agent on the left (local user agent) is advertising its endpoints including an input pipe for connections. The user agent on the right (remote user agent) may discover the communication endpoints of the other. Establishment of a communication link: Following the discovery of the input pipe of the local user agent, the remote user agent may connect to the input pipe, transmit the coordinates of its own input pipe and establish a connection. The concept of pipes corresponds to server interfaces (input pipes) and client interfaces (output pipes). Both are needed in user agents. Pipes represent an abstract concept of a communication link. The communication endpoints contain everything which is required to establish a link or a communication channel.
3.2 Some Concepts in Practice

Reality check
In this paragraph, we will have a look at some technologies, which use service discovery and organisation of networks. The goal is to gain a practical view and a sense of proportions. The following technologies will be discussed: JXTA: an generalised concept for peer-to-peer networks with reference implementations. JXTA is derived from file sharing networks. The protocols will only work between desktop systems.
117
Bluetooth: A practical implementation of wireless service discovery and interoperation. Bluetooth is becoming popular with mobile phones, where it allows to connect headsets to the phone or notebooks using the phone as a modem. Java RMI & JINI: Allow the implementation of distributed systems on Java Virtual Machines. RMI is a framework for "Remote Method Invocation", JINI is an extension of RMI which supports service discovery and distribution of software for clients to servers (so called client stubs). J2ME: The Java 2 Micro Edition for mobile phones. J2ME contains a modern API framework for communication endpoints: the Generic Connection Framework. CORBA & Web-Services: General frameworks for distributed computing. CORBA (Common Object Request Broker Architecture) and Web-Services rather apply for servers within core networks or desktop systems than with mobile terminal devices. Web-Services are based on the concepts of CORBA, but have gained huge popularity because messages are XML-type and may be transmitted over HTTP.
3.2.1 JXTA networks

In JXTA, a set of core protocols have been derived which are mandatory for each implementation. As shown in Figure 3-12, the core protocols include: Endpoint Routing Protocol: Allows to find a path to another user agent (routing). This protocol may be carried through the networks by protocol such as TCP or HTTP. Rendezvous Protocol: Is used for the subscription of an information service at a Rendezvous Agent (respectively for the offering of such a service). The Peer Resolver Protocol (on the next protocol layer) uses the Rendezvous Protocol for the exchange of messages. All Relations are temporary (based on leases) and need renewal. The specification contains no specific formats for messages (e.g. XML could be used). Peer Resolver Protocol: Allows the mapping of any type of queries to offers. The type of requests are interpreted by the modules contained in user agents by using a handler name. The Peer Resolver Protocol takes care of the formal relation between queries and advertisments.
Generalised concept from file sharing
118
Fig. 3-12 JXTA Protocols
On top of the core protocols, JXTA provides optional protocols for Standard Services: Pipe Binding Protocol: used for publishing of advertisements and discovery of advertisments on other user agents. The Pipe Binding Protocol utilises the Peer Resolver Protocol (PRP). Peer Information Protocol: Delivers status informations about other user agents, such as up-time, duration of connection, traffic load, properties. The Peer Information Protocol also utilises PRP. Peer Discovery Protocol: Establishes virtual connections between peers using their endpoints for the exchange of messages. Utilises PRP for pipe binding requests.
Fig. 3-13 The discovery phase in JXTA
How does the discovery phase in a JXTA network look like? Figure 3-13 shows the general scenario. When a local user agent (local peer in JXTA) is
119
activated, it will need to get in touch with its environment in order to collect more information. The first thing that a local peer will do is to connect to a known rendezvous peer or to any other known peer and starts discovery of its environment. It may discover and publish advertisements from there. There are different scenarios and kinds of local peers shown on the left of Figure 3-13. If the local peer is located behind a Firewall or NAT (Network Address Translation) it will not be able to initiate contacts to the exterior network. Network Address Translation makes a proxy to the local peer outside of the private network a mandatory requirement for discovery. The proxy represents a relay point. If a firewall is in use, communication will need to use HTTP requests (because HTTP on port 80 is usually configured to be passed through the firewall). If the local peer is hosted in a low-end device (such as a mobile phone ar PDA), it will most probably not be able to run XML based protocols with a high verbosity, which tend to be power consuming and slow over air interfaces. For Java enabled devices, there are concepts such as JXTA for J2ME or JXME. Such concepts use a proxy or relay agent to the low end device. Low end devices are also called Edge Peers. Such devices are without an own XML parser, with limited computation power and effective use of air interfaces. The relay node takes care of the more demanding transactions and protocols and translates them to the low end device.
Passing NAT and firewalls
Proxies
3.2.2 Bluetooth Service Discovery

Bluetooth is a radio standard for devices with limited battery power and limited computation power. Other than for mobile phones and PDAs this also applies for smaller embedded systems such as sensors, actuators, headsets, toys, MP3-players, network access points etc. The range is usually limited to about 10 meters, which is adequate for personal devices. Access points may cover about 100 meters. Bluetooth supports the generation and organisation of networks on demand (the so called piconets or the interconnection of piconets to so called scatternets). In this chapter, we will only have a look at service discovery within Bluetooth.
Proximity based networks
120
Fig. 3-14 Bluetooth Service Discovery by SDP
Service Discovery Protocol
Service Inventory contains Service Records
Bluetooth service discovery happens, when you send a picture or an entry from the telephone directory of your mobile phone to another device. Your own device will need to detect other devices in the vicinity. Bluetooth devices need to get along with constantly changing environments (i.e. to form ad hoc networks). In order to find devices and to identify applications, Bluetooth uses a dedicated protocol: SDP, the Bluetooth Service Discovery Protocol. Figure 3-14 shows the principle of operation. On the left of Figure 3-14 is a device, which issues service discovery requests. This represents a client function. On the right, there is a device which is receptive to service discovery requests (usually, this function may be enabled or disabled by the user through a configuration menu). This device represents a server. At the bottom of Figure 3-14, the corresponding client and server functions of the Bluetooth Service Discovery Protocol is shown. SDP represents a fundamental language, that every Bluetooth device can speak, irrespective of their specific services and applications. The Service Discovery Protocol has a specified format for the exchange of messages. The basic scenario represents a simple request-response mechanism, which allows to read information from a specific directory with a specified format, the Service Record. At the client side, a service discovery application will use the SDP client in order to read information from the Service Record of the server. In general terms, the service record contains the advertisements of the services that the server is offering. Service records are generated by the programmer of server applications. When a new software is installed on the server device, a new service record is entered in the registry of service records. How can a specific application be identified by the client? How does the client know, that the serving device is a headset or an internet access point? How does it know, which protocol to use for communication and which functions to call? Basically, Bluetooth works by the principle of a catalogue: All applications have a unique identifier (UUID, Universal Unique Identifier). Through UUIDs, bluetooth operates with a virtual directory of applications. Why virtual? Service Records are real. However, the agreement which UUID associates
121
with which component is not stored in a specific device (UUIDs work as identifiers just like MAC addresses, telephone numbers or Web-Domains). In order to utilise an application on the server, clients need to have a corresponding client software to the application identified by the UUID. This also corresponds to the plug & play-method used by PCs to identify and install a suitable driver for a newly discovered device.
Fig. 3-15 Bluetooth Service Records
What exactly a Bluetooth service record contains, is shown in Figure 3-15. The service record is a simple list of identifiers (IDs) and values. IDs are represented by 16Bit words with a pre-defined meaning. Also, the data types of the values of a service record are pre-defined. For instance, a specific identifier represents a ServiceID and is followed by a UUID. As shown in Figure 3-15, other entries in the Bluetooth service record represent protocols used by the application (e.g. serial port), the name and icon of a service (to be displayed to the user of the client), or pre-defined classes of services. The number of entries in a service record depends on how many attributes are needed in order to discover and use the applications. The specific meanings of the entries shown is not relevant in this place. The relevant part is that Bluetooth uses a directory with UUIDs as catalogue numbers to describe services and how to use them. The second relevant component is the Service Discovery Protocol which is used to access this information and which represents a common language for all user agents. The catalogue of UUIDs can arrange to identify matching clients and server applications (repectively matching user agents). How such matching user agents can be provided (i.e. how they may be distributed and installed on the devices) is out of the scope of Bluetooth. This will need to be handled by the user, just in the same way as the user installs a file sharing client or instant messaging software on his desktop PC.
Records contain Service Identifiers
UUIDs as identifiers
3.2.3 Java RMI and JINI
122
In the case of Java Remote Method Invocation (RMI) and JINI, a uniform program environment and runtime environment provides the same context in different devices. As such, Java RMI may directly compared with the initial case of method invocation between two threads within the same system (the Symbian OS case chapter 3.1). Figure 3-16 shows the basic principle of writing and running an application on two separate systems. On the right of Figure 3-16, the client is represented, which should invoke a method (or call a remote procedure) on the server on the left. This method (or procedure) is defined by the application developer. As shown in the upper half of Figure 3-16, the developer of an application first defines the name of the method, together with parameters and the return value of the method. For instance, a method z = f3(d, e, f) could be chosen with F3 representing the name of the method, d, e and f the names of the parameters, and z the return value of the method.
Fig. 3-16 Java-RMI (Remote Method Invocation)
Interface definition in Java language
The definition of this function is represented in some lines of Java source code. The programming language requires that data types are specified for all names (such as z represents a string, d and e are Java types of integers etc). At this stage, the details of how the return value is calculated from the parameters do not need to be known. The class, where the method f3() belongs to, is called an abstract class or in Java terminology an interface. An Interface does contain all the names and type definitions, but not the implementation of the classes and ist methods. This would be the next step in application development. With Java RMI, the interface type of the method contains everything which is needed for the client to invoke the method on the server. The server will contain the same method, however, with a full implementation. The application developer does not need to care how the client invokes the method through composing a message and sending it to the server by using some kind of communication protocol. All of this is handled by the compiler (Java RMIC).
123
In fact, the compiler can add everything which is needed for composing messages and communication between client and server from a library. For communication, Java provides an own message protocol, but also allows to use standard protocols, such as IIOP (the Internet Inter ORB protocol from CORBA). By using IIOP, CORBA server and clients may interoperate with Java RMI applications. So far, we have been able to see how a uniform programming environment and runtime environment can take care of distributing execution of code (i.e. bytecode in the case of Java) between two systems. Still, this code will need to be deployed (i.e. loaded and installed) on those systems. Also we did not see any concept for service discovery of network organisation. A concept, that builds on the Java RMI and provides service discovery and deployment of executable code, are JINI networks. JINI is an open architecture for dynamically changing network applications (se www.jini.org bzw. www.sun.com/software/jini). JINI extends the concept of RMI by the dynamic loading of client-proxies (i.e. distribution of Java bytecode, same concept as applets). As Java RMI, JINI needs a Java runtime environment as condition for distributed applications. Any concept, which uses the dynamic download of software as design principle, the control of malicious code represents a big issue. For such as system, a uniform runtime environment for applications (i.e. dedicated middleware) makes sense, because it allows to design a security framework into this environment. Such as security framework provides a layer of insulation between the code and system resources (the so called Java sandbox). JINI supports a dynamic federation of distributed applications, which includes: Procedures for handling demand and supply of services (Service Discovery, Service Look-Up) Mechanisms for allocation of relations on time (Leases),for synchronisation of cooperating applications (Events and Notification) and for handling transactions (using a 2 phase commit method) Building blocks for applications (Specifications, APIs, sample applications, reference implementations) Further development of concepts and projects through the Java Community Process. Figure 3-17 shows a basic scenario for the operation of JINI. In addition to the client system and the server system from Java RMI (see Figure 316), an additional component is introduced: the Lookup Server. This component words as a directory for Advertisements and as a repository for the deployment of client code which matches the published advertisements. We will follow the scenario with a sample application: camera needs printer.
Compiler adds communication and context from libraries
Service deployment
Service inventory contains client applications
124
Fig. 3-17 JINI - a concept for discovery and download of client proxies
Camera needs printer
Discover an inventory
Get client application for printer
The sample application starts on the right of Figure 3-17 with a printer (the server system) getting started up. As soon as the printer application on the server is running, the JINI framework makes it issuing requests in order to find a service directory (i.e. a Lookup Server in JINI terminology, respectively a Rendezvous Agent in general terms), where the printer can publish an advertisement for a printing service within the JINI network. This process is called the discovery process in JINI and is numbered with (1) in the figure. In the discovery phase, a JINI device contacts network via look-up request messages (more spefically, IP-multicast messages according to the JINI API). Following discovery, the printer will join the Lookup Server in step (2). Joining means, that first off all the client object (or Proxy-Object) of Lookup Server is loaded to the printer in order to allow the printer to communicate with the Lookup Server and to publish a service advertisement within the lookupserver. The service advertisement may include a name, icons, a description, service attributes such as resolution, color, paper formats etc. More significantly, joining the Lookup Server also includes the uploading of a client-object for the printer (printer proxy-object) to the lookup-server. This is a major difference to the concept for service discovery in Bluetooth (see 3.2.2), which does not take care of distribution of client-objects or user agents. The digital camera in our scenario, which would like to print out a foto, will also initiate the discovery process in the JINI network and register at the lookup-server (by using the LookupDiscovery method of the JINI API). The digicam now is a member of the local federation of applications. It now initiates a service request at the lookup-server. The Lookup-Server identifies the printer and offers the corresponding proxy-object of the printer for download. The digicam downloads the proxy-object of the printer and may now directly communicate with the printer, i.e. the digicam calls printer methods and transmits a foto as parameter to the printer. Depending upon the implementation, the printer reports the progress of the printing transaction back to the digicam.
125
3.2.4 J2ME MIDP 2.0

In Java terminology, J2ME is an acronym for the Java 2 Micro Edition, which is the Java edition for small devices, such as mobile phones which are far less powerful than desktop systems, which are the domain of the Java 2 Standard Edition. MIDP means Mobile Information Device Profile, which represents an API for functions, which each device that complies to the MIDP specification must support, irrespective of the manufacturer. In more detail, MIDP is an extension of another functional layer, the so called Connected Limited Device Profile (CLDC). Figure 3-18 shows the fucntional architecture of J2ME.
Fig. 3-18 The structure of J2ME
Applications, which make use of the MIDP framework, are called MIDlets. This name should associate with Applets, i.e. the small Java applications that execute within a Web-Browser. Midlets execute on mobile devices, typically mobile phones. The increasingly popular games that maybe downloaded to Java enabled mobile phones in fact are Midlets. The version 2 of the MIDP specification is now becoming available for most mobile devices. The most interesting part of MIDP and ist supprting layer CLDC in the context of distributed computing is, that CLDC contains a very nice abstract view for communication endpoints: the so called Generic Connection Framework. Other important components of J2ME are the Java Sandbox which provides security, the Java Community Process for standardization., as well as other useful APIs with nice abstractions (such as the Multi Media API which represents a subset of Java Media Framework, the Personal Information Profile for access of Contacts & Calender, a Bluetooth API for communicatiuon links. However, J2ME does not enable Java RMI. The reason is, that RMI requires a system to reflect on objects running within and to provide access and serialisation of objects to external processes. In order to keep memory consumption and consumption of computational power low, reflections and object serialisation are not supported by J2ME. Thus, J2ME does not support JINI.
A general model for connections
126
Fig. 3-19 The J2ME CLDC Generic Connection Framework
Input and output connection
As already mentioned, the most interesting part of J2ME in the context of this chapter is how communication endpoints are represented in an abstract and most general way. Figure 3-19 shows the main classes of the CLDC Generic Connection Framework. Generic means, that it allows to establish connections independently of a specific communication protocol or a specific communication interface. At the top of the diagram shown in Figure 3-19 is the interface Connection, which is generated by a Connector (the Connector is a so called factory for connections). Derived from Connection are the classes InputConnection and OutputConnection. These classes exactly correspond to the communication endpoints shown in Figure 3-9. The InputConnection represents an incomingpipe, i.e. a server type of communication interface. It utilises the StreamConnectionNotifier to notify the system about incoming requests. The OutputConnection represents an outgoing pipe, i.e. a client type of communication interface. Both InputConnection and OutputConnection represent a connected type of communication (with difference to a connectionless, datagram type of communication which is represented by DatagramConnection). Still, both input and output connection types do not indicate, what types of data they transmit. This is achieved by a further specialisation: StreamConnection, which supports any type of serialised data. The transfer of files is achieved by a further specialisation of the data streams, the ContentConnection. How then can communication links be established with the Generic Connection Framework? There is a general scheme for using methods of the Connector class (which returns a corresponding Connection):
Connector.open("<Protocol>:<Address>;<Parameters>")
Object reference
This allows to use a variety of communication links by just handing a string to the Connector object, which specifies the type and endpoints of the communication. The syntax follows IETF recommendations for URIs (Uniform Resource Indicators). Some examples:
Connector.open("http://www.dpunkt.de")HTTP connection Connector.open("socket://162.234.100.200:8090")SocketConnection
127
Connector.open("comm:0;baudrate=9600")Serial Port Connector.open("file:/hiScore.dat")Data from file
Another implication of using such a generic framework is, that the actual communication protocol is chosen at runtime (i.e. the so called binding of a protocol to the connection may be dynamic). This allows protocols to be updated, exchanged or debugged completely independent from the application code. In object oriented terminology, the corresponding property of intefarces or abstract classes is called polymorphic.
Binding of a protocol
3.2.5 CORBA and Web-Services

The Common Object Request Broker Architecture (CORBA) and Web-Services follow an approach to distribute objects between systems. One way of explanation is to follow the evolution of computer programming (see Figure 3-20). In the early days of linear programming, a computer program represented one piece of executable code, which results from compilation of source code and linking with library functions. Running such a program loads it into the computer memory and has the processor following instructions. As programs became longer, it made sense to indroduce a modular structure. So subroutines were introduced (functions, which delivered a return value, or procedures, which just executed a subroutine without returning a specific value). In general terms, subroutines were changing data, which were made accessible to them. With functional programming, the modularity helped to structure source code. It did not help to structure data and its relation to the functions.
History
Fig. 3-20 Evolution of Computer Programming
The next logical step was object oriented programming, which supports a much higher degree of modularity. Data is encapsulated into object. Access to data or transformation of data is performed by invoking methods of the object. Also, objects support relations between each other. Invocation of methods means sending a message to an object, which contains the name of the method, parameters and their correct data types. Following execution of the method, the return value is delivered as response by another message. In order to dis-
Object oriented software
128
tribute objects, there needs to be an agreement between the systems on the context of the messsages. This context includes names and data types. Also, there needs to be an agreement on the location of the distrubuted objects, i.e. pointers or addresses. CORBA represents a framework for object distribution. Others are Java Remote Method Invocation(RMI) invocation, the Microsoft Distributed Object Model (DCOM), and Web-Services. All of them represent specifications and implementations for the distribution of objects. Figure 3-21 shows an overview and their development.
Fig. 3-21 Distributed Computing
Interface definition
All implementation have in common, that they specify the context of the distrubution. CORBA provides a formal way to document the specifiaction of this context: the Interface Definition Language (IDL). Web-Services support the same concept: The Web-Service Definition Language (WSDL) specifies the context of distribution in a formal way in an XML document. Both CORBA and Web-Services use message protocols to carry messages for remote method invocations. For Internet based communication, CORBA uses the Internet Inter Object Protocol (IIOP). Web-Services use a framewrok protocol, the Simple Object Access Protocol (SOAP) which carries messages over a choice of other available protocols, such as HTTP or SMTP. In order to publish objects for usage by a remote clients, supporting functions are needed. Those supportung functions handle addressing of objects, and access to objects by generating messages and sending messages over the protocols in use. With Java RMI, we have seen that the supporting functions are added by the Java Compiler out of a library. With CORBA and Web-Services, a similar and matching environment is needed on bothe ends of object distribution (i.e. both on the server and on the client). Such software is also called middleware. Figure 3-22 shows a client and server configuration for CORBA. The middleware on the client represents a so called Client stub, the equivalent part on the server side is called server skeleton. Stub and Skeletons are the supporting functions provided by the CORBA middleware which accommodate the client object and server object.
129
Fig. 3-22 CORBA
As shown in Figure 3-22, CORBA also utilises a server to contain object references (addresses, pointers, ports). This is one of the drawbacks of CORBA: Also, the middleware on all interworking parts of a distributed system needs to match to each other. Compatibility between different implementations (i.e CORBA products) is an issue. Web-Services represent an increasingly popular implementation of the same concept. There is a choice of mature and compatible implementations and supoort from all main players in the software industry. Also, Web-Services are very well suited for the distribution of functions in IP networks. Among the reasons is, that the framework protocol SOAP may be carried over HTTP, which allows to access any place within the Internet. Another reason is the use of XML based documents for WSDL, the formal descrption of server functions and URLs as pointers. Web-Service do not need an intermediate server for access to objects. A URL is sufficient to extract a WSDL document from a server, generate a corresponding client function, and invoke the server functions from the client. The WSDL contains a pointer (URL) to the corresponding port of the server. Figure 3-23 the sequence of events.
Web-Services
Fig. 3-23 Reconstruction of a client from WSDL context
Just like CORBA, Web-Services also need a middleware to accomodate the applications. At the server side, this middleware allows the developer of applications to publish objects and make them accessible at a port of a web-server. As soon as an object is published at the server, the object and its corresponding
130
WSDL description and are accessible by their appropriate URLs. The WSDL description is generated by the server side middleware. The middleware also handles the translation of incoming and outgoing SOAP messages (XML documents) into calls to the methods of the objects running on the server. At the side of the client, a simple HTML browser allows to extract a WSDL document from a server, if the appropriate URL is known. There are tools to extract WSDL documents and automatically generate client source code in the language of choice of the client (such as Java) . While generating the client function, those tools inlude library functions to generate the appropriate SOAP messages to the server (i.e. the middleware part at the client side). This client source code may be incorporated in the software running at the client. The client software may access and use the services provided at the severs. This usage of server applications by the client is also called the binding of the server application into the client application.
Fig. 3-24 Components of Web-Services and their Relations
Service inventory
Web-Services also provide a directory or look-up server for publishing and finding service applications. The usage of this directory is not mandatory. If the URL of a server is known, services may be invoked as discribed above. The major function of the directory is indeed to deliver pointers, i.e. URLs to mathcing serveices. The directory of Web-Services is called Universal Description Discovery and Integration (UDDI). Figure 3-24 shows the principle. UDDI introduces the concept of a provider of web-services (who publishes his offerings in the directory) and a user or consumer of web-services (who is able to locate a matching service from the directory). To a Web-Service user, the directory itself does just return pointers to matching servers. The server then contains the WSDL document which formally describes the service and how it can be used. Figure 3-25 shows the structure of the UDDI and the description of the service by the WSDL document. The UDDI allows to describe services according to the following categories: White pages contain general information about the organisation or the company which offers the services, i.e. the business entity. Among such information are simple things like the name, address, telephone number and e-mail coordinates of the service provider.
3.3 Export and Import of Functions
131
Yellow pages contain a structure to search for services according to specified categories (just like the yello pages of a telephone book, which allows to look for a pharmacy, repair service etc). Green pages contain the so called binding template of the service, i.e. pointers (URL) to the WSDL documents. The WSDL document represents is the technical model of a service, which contains the message types, ports to evoke the service and names of the objects.
Fig. 3-25 The principle of UDDI
In summary, the UDDI contains information about services in the categories Business Entity (white pages), Business Service (yellow pages) and Binding Templates (green pages). As already states, the usage of UDDI is not mandatory and has not gained the same level of acceptance and attention as other components of Web-Services (SOAP, XML and WSDL). Also UDDI is handled by a different body, the OASIS organisation, while most other WebService specifiocations are handled by the World Wide Web Consortium (W3C).
3.2.6 Universal Plug and Play

... discovery, notification, control
3.3 Export and Import of Functions

... OSGi Framework; bundles as components, OSGi and UPNP
132
4.1 Introduction
133
4 Service Architectures
4.1 Introduction
Service Architectures in the traditional telecommunication networks have been dominated by one fundamental design principle: functional architectures. For ISDN and GSM, functions have been defined, and then associated with functional entities (i.e. network elements). Between network elements, functional design leads to the specification of network protocols. Strict rules for the design and standardisation have been the foundation of the world-wide success of fixed and mobile communication networks. Progress in software technology, computer technology and high performance networks allows to apply more flexible design principles today. Functions do not need to be fixed at detailed level. In many cases, it is sufficient to follow general rules for the distribution of functions. Also, persistent data may be handled in a more flexible way. On a higher level of abstraction, data storage, processing power and network capacity may be considered as resources. Priority is shifting from the provision of resources to the management of resources. New design principles originate in the area of enterprise network infrastructure and from the integration of the applications which are required to run large enterprises. For an insurance company or a bank, this may be the integration of their core application (to handle banking transactions or insurance transactions) with common management applications. For a car manufacturer or the chemical industry, among the core applications may be the simulation of designs or tests. Among the common management applications are Enterprise Resource Planning (ERP) and Customer Relation Management (CRM). Such applications also apply for operators of telecommunication networks. All those applications demand large capacities of resources (i.e. data storage, processors and networks). For smaller enterprises, the same concepts apply if a service provider takes care of the provisioning and management of shared resources for small enterprises. In this chapter we will have a look at service architectures for telecommunication software engineering. There are basically two areas: (1) the of core communication networks, (2) terminal devices. For core networks, we will show the design principles of network service architectures and ways to model and validate the design. This development is quite new. In real communication networks, it starts with the logical centralisation (or virtualisation) of data storage. The second relevant area for the development of communication software are terminals. Modern terminals like mobile phones or PDAs allow to develop and to install application software. They provide frameworks for the development of such applications. In the last section, we will have a look at such an application framework. In general, the focus of chapter 4 is on concepts and methods. Details about implementations, tools and development processes are left aside for the sake of showing the basic principle or general rule.
Functional architectures
Integration of information and handling resources
Target systems: servers and terminals
134
4.1.1 Resources: Storage, Computing, Network

On an abstract level, running an application involves the following kinds of resources: Storage: the place to hold persistent data, which can be retrieved and deposited from there by an application. On a desktop system or a server, this is typically represented by a hard disk and a file system or data base. Among the solutions to share the storage of data in a network of servers are Storage Area Networks. Computing: processing power, respectively the allocation of a processor for an application. Within a system, this is typically handled by the operating system. Here, we are talking about allocation of processing power in the most general terms, i.e. in a network of systems. Network: the connectivity and capacity to make systems inter-operate. Within a system, the network is represented by system busses or I/O busses. Here we are talking about communication networks for local connectivity and wide area connectivity. High performance communication networks allow to distribute data storage and processing power. While this view may seem to be new, it is not. The networks shown in chapter 1, such as the GSM and GPRS networks have always been operating as distributed systems with distributed resources. Only the perspective is a more abstract one. On this higher level of abstraction, the allocation of resources for applications within distributed systems seems to be easier and more flexible.
Fig. 4-1 Resources: Storage, Computing and Network
Ease of implementation
This can be demonstrated by an example: the upgrade of subscriber capacity in a GSM network. With the traditional concept for the provisioning of resources, this most likely means more HLRs with impact on the whole network structure (e.g. a planning process and deployment process for addressing, routing, network upgrades and integration with provisioning and management systems). In the abstract view, which only perceives resources for data storage and resources for processing, the procedure is much more simple: It means a capacity upgrade of the storage of subscriber data a and capacity upgrade of processors (as well as a capacity upgrade of network resources). The question is, how easy this abstract concept can be implemented. With the current functional network designs, implementation is a tedious and complex process. We will see where the service architecture discussed in this chap-
4.1 Introduction
135
ter has the potential to facilitate implementation. Ease of implementation can be measured by the complexity or cost of the management procedures, which are required to change or upgrade resources. Another term that is frequently associated with resources is the so called Virtualisation of Resources. In this context, "virtual" is another word for "more abstract". Rather than handling the physical resources, which tend to show a high complexity, high diversity and tend to be distributed all over the place, we are handling virtual resources, i.e. a layer of software that hides the diversity and distribution or provides a simplified or generalised view of physical resources. There are many examples for virtual views, such as the Java Virtual Machine, SQL as a generalised way to access data bases, or Web-Services and CORBA to handle distribution. Middleware is another word which is used to describe such concepts or layers of software.
Virtualisation of resources
4.1.2 Centralised Data in Communication Networks

When networks such as GSM have been designed, the design objective has been to provide specific services, such as mobile telephony including roaming and hand-over. Such networks are optimised for the services they have been designed for. The provision of arbitrary new services has never been the objective. Such new services are largely data driven applications, which are to be handled by the data domains of GSM (GPRS) and UMTS.
Fig. 4-2 Functional design lacks flexibility
For new applications, which need to be introduced frequently and in larger numbers, the traditional functional design does not apply very well. Figure 42 shows the reasons. First of all, a functional entity is specialised for its function by definition. For a new service, new functions and new functional entities would need to be introduced. Although there have been concepts to break down services to building blocks, which could be re-used, this concept of prefabricated bricks does not apply well in practise. In practise, it is difficult to anticipate the requirements new services and applications. Another reason is that functions and their allocation to functional entities leads to specialised communication protocols between the entities. A diversity of functional entities generates an ever greater diversity of communication protocols between them. This is heavily increasing the complexity and cost for
Specialisation and individuality increase complexity
136
Limited flexibility to introduce new services
providing new functions. Even if a new function only requests a functional upgrade of existing entities and protocols, the cost and complexity can be prohibitive. Also, communication protocols normally follow a process of standardisation between network operators and suppliers of network entities, before they can be implemented. Another reason for limited flexibility in functional design is that persistent data, such as subscriber data, is enclosed in many network elements. From there, it has to be retrieved through a multitude of communication interfaces, or by management interfaces (i.e. administrative interfaces for operation and provision), which normally are supplier specific and not standardised. This makes it difficult to add more services to the network. It also makes it difficult to integrate the network entities which provide active services with administrative network entities. In practical terms, this difficulty surfaces when a customer is at the hotline of a network operator (or service provider) and tries to find out, why his service is not working right now. The logical chain from the potential irritation of the network to the irritation of service for this specific customer can be an extremely difficult issue for the network operator (or service provider). Another source of headache may be a simple view about which services a specific user has subscribed to and the administration of this portfolio.
Fig. 4-3 Traditional Networks - HLRs including subscriber data
In order to illustrate these issues, Figure 4-3 shows an array of HLRs, which contain a major amount of subscriber information (see chapter 1). A mediation device connects the HLRs to the administrative network entities and provides te mapping of subscribers to their location in specific HLRs. Among the administrative network entities are Enterprise Resource Planning (ERP), Customer Relation Management (CRM) and Billing (for customers, who do not use a pre-paid account for their service). Of course, HLRs are not the only network elements which need to interconnect with administration. Others are Intelligent Networks (IN) or Multi-Media Message Services (MMS). Still others are Location Based Services, Platforms for downloads of logos, ringtones and games to mobile sets, Platforms for E-Mail, Media Streaming, Instant Messaging etc.
4.1 Introduction
137
Fig. 4-4 Alternative Solution - One virtual HLR with direct access to data
What does virtualisation of data storage change in this HLR-based scenario? Figure 4-4 shows an alternative solution to the array of HLRs shown in Fig. 43. In this scenario, the HLR is decomposed into the following components: HRL Data Bases: the storage of the HLRs which is now separated and directly accessible to the administrative entities. In practical terms, the data base includes: (1) the physical storage, which can be geographically distributed, but still represents a logical entity, and (2) the data base management system. For a practical implementation, Storage Area Networks may be used for the physical storage with logical representation as one entity, and state of the art data bases to access the data. HLR Back-End Processors: This is the place where the service logic of an application resides. For an HLR, the service logic would be location updates or authentication of subscribers (see chapter 1). For access to subscriber data, the back end processors use to HLR data bases. The back end processors do not need to process specific communication protocols (this is done by the front end processors). Thus, they may be implemented on conventional IT equipment for servers. HLR Front-End Processors: The front end processors handle the network specific communication protocols, i.e. the lower protocol layers. The split of functionalities between front ends and back ends can follow a variety of designs. As a general rule, the communication between them will be carried over the IP protocol. Whether the front-ends work as a protocol gateway or whether the upper layers of the network protocols are directly based on IP depends on the situation. While not changing the overall functionality (a virtual HLR still is an HLR), this alternative design fundamentally changes the environment for upgrades and for the implementation of new services: rather than an array of HLRs, it
An alternative design
138
Reducing complexity
Scalability
represents one virtual HLR both to the communication network and to the administrative layer. Although the decomposition of the HLRs may seem to have increased complexity, this actually is not the case. There is a higher degree of standardisation in the alternative scenario and scalability is entirely different. What has been disappearing, is the individuality of HLRs in the network (i.e. their individuality at application layer). A traditional HLR performs HLR applications for its own subscribers. An HLR Back-End processor performs HLR applications for any subscriber. Concerning standardisation, IT platforms and methods of interconnection of elements follows common practice in enterprises. Also, integration with administrative entities follows such common practice. Concerning scalability, the major difference in design is, that now, the back ends and frond ends do not hold specific data. This is again the individuality that they have lost. While a traditional HLR needs careful consideration in network planning and for integration with administration, the new components are purely processors which may be replicated according to demand. They are much closer to computing resources than entities which hold subscriber data (which such entities, replication does not work). This makes concepts to provide non-functional requirements (such as resilience to faults, fail-over, redundancy, data back-ups, performance under load) easier to design and to implement. Upgrades of resources have less impact on the structure of the network: data storage and processing power can be adjusted according to demand in an easier way.
Fig. 4-5 Virtualisation of Data Storage - Generalised Concept
General concept
The alternative design for allocation of data does also work for other network elements. Systems with different fucntionalities, but of the same class of fucntionalities as HLRs are HSS (the HLR concept in UMTS), VLRs, SCPs (Service Control Points), MSCs and platforms for SMS, MMS etc. While most of the elements should be familiar from chapter 1, SCPs may not. Service Control Points (SCP) are used to provide number translation services and services with special tariffs. They are part of a functional design
4.1 Introduction
139
called Intelligent Networks. Among the familiar services provided by Intelligent networks are free-phone numbers (such as 0800), numbers with special tariffs used for hot-lines (such as the 0180 numbers in Germany), or numbers with higher tariffs to pay for services provided over the telephone line (such as 0900). For hotlines, the SCPs translate the service number into an actual destination number (which depends on time-of-day, geographical location of the calling party, load of the call centres etc). Also, Intelligent Networks provide pre-paid subscriptions in mobile networks. In this last case, the SCP decrements the prepaid account of the subscriber during calls. Just like HLRs, all of the above mentioned network elements contain subscriber data. Thus, the same concept for virtualisation of data applies. Figure 4-5 shows the basic scenario. Again, it leads to a network structure with frontend processors to handle communication protocols, back-end processors to run applications, and centralised storage of data. In fact, some large systems have already been designed and implemented in the way shown in Fig. 4-4. Among such systems are the so called Intelligent Networks, which provide number translation services for a large number of subscribers and users. Another example are systems which provide number translation for number portability (while users are moving within an area with the same prefix, such as +49 711, or if they change to a different network operator, they may keep their telephone number). Number portability in a large network also leads to large systems to handle the translation of numbers. Rather than using a multitude of SCPs in combination with address tables (which subscriber is handled by which entity), there is only one virtual SCP (or a number of functionally equal SCPs), which can handle any subscriber. Each virtual SCP consists of a multitude of front-end processors, back-end processors and a common data base which is accessible to the back ends. Still, the alternative scenarios for HLRs or SCPs comply with the traditional functional network architecture, as long as they are separately implemented from each other. What Fig. 4-5 suggests is to use a common data storage for the different entities of a network. Concerning the virtualisation of data storage, the difference in this design principle is illustrated in Figure 4-6 and Figure 4-7
Intelligent Networks with the same design
Fig. 4-6 Different views: Functional Design
140
Data centric design improves flexibility and scalability
Figure 4-6 shows how subscriber data (information about customers and the services they subscribe) are handled in a functional design. Functions demand which information a network entity needs to contain. The consequence is, that information about customers is scattered and replicated between network elements. Getting a coherent view means to access many entities through their functional communication protocols, or non-functional (and supplier specific) administrative interfaces. While this is perfectly acceptable for a network which has been designed for a specific function, it does not provide much flexibility for functional upgrades and adjustments of resources.
Fig. 4-7 Different views: Data centric Design
Figure 4-7 shows a data centric view which corresponds to the virtualisation of data storage shown in Fig. 4-5. In this view, emphasis is not on the functional content of network entities, but on the information, which is needed to handle a customer and his services. This information needs to be accessible to both active entities and to the administrative entities of a network.
4.1.3 Framework Protocols

Binding of communication protocols
Among the consequences of functional design are communication protocols which are designed to support the specific functions. This leads to new protocols (or protocol versions) with every change in the functional content. In this section, we take a look at ways to generalise protocols. By using object distribution (in concepts such as CORBA or Web-Services) the communication protocol is a natural follower to the functional specification and can be automatically generated and re-generated on demand. This makes changes in the functional content of a network (such as for functional upgrades) much easier. In more detail, not the entire protocol is generated, but just the upper layers, i.e. the messages and their data types. A supporting layer is used to carry this application specific part. Rather than being application specific, a framework protocol supports a variety of applications and transport protocols. This means that the functional set of the protocol may adapt according to the distribution of functions, and that different protocols may be chosen to carry the messages.
4.1 Introduction
141
Fig. 4-8 Polymorphic property of objects
Framework protocols follow the same principle as the polymorphic property of objects and support object distribution. Figure 4-8 attempts to illustrate this property with an example. The object LocationService within the memory on the right originates from an abstract class LocationService. This class defines a method getLocation(), which returns the geographical co-ordinates of a mobile user. An identity of the mobile user could be passed as parameter of this method. What is contained in the definition of the abstract class is the name of the method, its parameters and its return value, including the corresponding data types. However, the abstract class does not indicate or specify the implementation of the method. There may be different implementations for this method. In the example, one implementation could be based on what is implemented in the GSM network to locate the mobile user (from cell IDs or triangulation). Another method of localisation could be based on GPS. Still another implementation could be used if the mobile user currently is in a WLAN hot spot. Irrespective of the different implementation, the method ivocation stays the same: getLocation(). Because it comes in a variety of shapes, the corresponding property of the object LocationService is called polymorphic. The binding of the appropriate method depends on the situation and may be even be decided at runtime (dynamic binding). Next, we recapitulate object distribution. How can the services of an object be made available to a remote client? Figure 4-9 shows the mapping of a formal description of the offered service by WSDL (the formal description for Web-Services) to Java objects. The left contains the description of an abstract class (such as the LocationService described above). With distributed objects, this abstract class represents the client interface to a server object (the server object will need to contain the implementation of the class).
Binding of objects
Interface definition
142
Fig. 4-9 Mapping of Java Objects to WSDL descriptions
Translation into a programming language
In a Java program, the definition of the abstract class (e.g. the Java Interface of the server object in Fig. 4-9) contains all the required names and data types. The WSDL document on the right represents a formal specification of this abstract class, but also contains information which are required for distribution (such as the message protocol which is used). The structure of the WSDL document is indicated in the figure. The general structure contains data types, messages, port types, binding and services. Within this structure, the Message part describes the methods, parameters and return values. Method invocations from the client are translated into messages, which transmit the name of methods and the values of parameters to the server and return the result of the operation as return value. The Port Types describe the abstract objects and their methods. The Binding describes which protocol is used to carry the messages. The Service part contains a summary and includes ports and addresses for service invocation.
4.1 Introduction
143
Fig. 4-10 Publish Java Objects as Web-Service
How does the publication and invocation of a server object actually work? Figure 4-10 shows the basic scenario of publishing a server object on a webservices platform and how it can be used by a client. The sequence starts with the publication of the server object on the server (on the right in Figure 4-10). For instance, the server object could be the LocationService from above with a GSM type of implementation. There are some conditions at the server side: making Java applications run requires a Java Virtual Machine or Java Runtime Environment (JRE). To make the server object available as a Web-Service, will require a Web-Service platform on the system. This is indicated by the WS-Server (Web-Service Server) on top of the Java Runtime Environment. A Web-Services platform includes a Web-Server (HTTP-Server) and additional functions to register and publish Web-Services and to handle the framework protocols (i.e. as XML parser to interpret the messages from the message protocol and invoke the right server objects). To the application developer, the Web-Service platform provides a simple interface. All he needs to do is to include a few extra functions from a library, such as starting up the HTTP-Server at a specified network address and to register an instance of the desired server object. In practical terms, this may be expressed in two lines of code:
HTTP.startup(http://172.23.56.250:8004/WS-Server); Registry.publish("locationServer", new LocationServer() );
Publishing and usage of Web-Service
Object Reference and Advertisement
Another function supported by the Web-Service Platform (WS-Server), is the generation of the WSDL description of the published object. This is generated automatically on request of a client (it may also be generated in a dynamic way directly from the objects running in the physical memory by using Java reflections). The application developer does not need to care about WSDL. Despite being a readable XML document, WSDL is intended to be generated and evaluated by machines. The extraction of a dynamic WSDL document
144
from the server by a client is indicated as step (1) in Figure 4-10. In the example, the client may extract the WSDL by pointing a browser type of client to the server at the following URL: http://172.23.56.250:8004/WS-Server/locationServer.wsdl. The next step (step (2)) then takes place at the client side: The WSDL may be used to generate a client object which can invoke the server methods. Again, this is an automated process. For example, a tool such as WSDL2Java translates the WSDL document to Java source code. Following compilation, the client is ready to invoke services from the server. This is indicated as step (3) in Figure 4-10.
Fig. 4-11 SOAP as Framework for Message-Protocols
SOAP binds to communication protocols
The Framework Protocol used in Web-Services is SOAP (Simple Object Access Protocol). Again, it is nothing that the application developer needs to care avout. Technically, SOAP contains everything to handle methods and their corresponding messaged and data types, which are described in the WSDL document. As indicated in Figure 4-11, SOAP may carry those messages over a different message protocols. The most commonly used protocol is HTTP. Other protocols may be the CORBA message protocol IIOP (Internet Inter Object Protocol), or the Java Messaging Service (JMS). Like other abstract descriptions (such as ASN.1), SOAP may also be used as an envelope to other network protocols, such as the Mobile Application Protocol (MAP), which is used in GSM networks to interconnect network elements like MSCs and HLRs. Framework protocols like SOAP and the distribution of functions with formal descriptions such as WSDL are the foundations for the service architecture described in the next section. They provide a higher level of abstraction which is needed to operate with virtual resources for the storage of data and for the interoperation of network entities without fixation of communication protocols. If needed, they also can provide the flexible allocation of processor resources to processes (this involves more complex management functions to register resources and to allocate them according to demand).
4.2 Network Service Architecture
145
In this section, we will define an architecture on a more abstract level than the traditional functional architectures. The design objective is to provide better flexibility and less complexity for frequent functional upgrades, i.e. the frequent provision of new services in the network. This is why we call it a Network Service Architecture. The architecture described in this section is also the subject of a European research project which involves network operators, suppliers and universities (FLEXINET, IST-507646). The target is a proof of concept, the development of prototypes, the evaluation of the performance and the finding of dimensioning rules and models.
Design at a higher level of abstraction
4.2.1 Concept
The concept of the Network Service Architecture derives from the following assumptions: - data should be accessible to network elements, but not be enclosed into network elements - data storage is to be considered as a virtual resource, which can be implemented in a physically and geographically distributed way - processors do not necessarily need to be allocated in a dynamic way, this can be arranged by careful planning of resources - conventional IT components should be used for processors (both hardware and software) - rather than using fixed communication protocols, applications are supposed to use a framework protocol and formal descriptions for the functions provided in the network - where it can be achieved in a reasonable way, the architecture should enable the re-use of common functions, which are frequently needed for different applications - the network is assumed to run over IP and to provide sufficient network capacity and performance (this already is the case in core networks and consistent with the current approach of next generation networks - the design should use conventional and state-of-the art technologies which are consistent with technologies used in the administrative parts of networks and in enterprises, as well as for Web-Engineering - the design should enable the integration of administrative network elements and existing active network elements. Figure 4-12 shows an architecture which meets the above mentioned demands. It is using two abstract interfaces: one to access data storage (the Data Interface), the other to access other applications (the Application Interface). The blocks in the middle represent Applications (App) and Common Functions (CF). A Common Function represents a reusable components for frequently needed functions such as authentication of a subscriber or entity in the network. An Application can be any service or function that the network provides.
Design objectives
Service Architecture
146
Fig. 4-12 Components of the Service Architecture
Applications
Common Functions
Application Interface
Applications and common functions are supposed to run on conventional IT platforms. Resources may be allocated in the way that suits best to the needs of a network operator. In order to be compliant with the architecture, all applications and common functions need to support the two interfaces. The application interface provides access to other applications (i.e. to computing resources). The data interface provides access to data storage. The service architecture can be best demonstrated by an example. Let the Common Function in Figure 4-12 be the authentication of users for network access. This Authentication CF can access the data storage, which contains subscriber profiles and subscriber credentials (passwords or the usage of secrets used in a GSM HLR to provide SIM based access). This way, the Authentication CF is a generalised authentication centre. It supports the authentication of a user for different network access technology. For example, the user could use SIM based access not only in a GSM network, but also to get access over DSL, Wireless LAN or a cable modem. The user dialogs through different access technologies could be the function allocated to an Application. This Application does not need to access the subscriber profiles, but is using the Authentication CF to provide authentication as a remote function. To access the service of the Authentication CF, the application uses the application interface. How do Application and Authentication CF communicate over this interface? As a popular state-of-the-art solution, the Application Interface will be based on Web Services. This means, that the Authentication CF is published as a service and described by a WSDL document (see section 4.1.3). From this formal description, the application may generate a client function to the Authentication CF and bind to it by an appropriate protocol, Concerning message protocols, the general assumption of this concept is, that the common denominator is HTTP. HTTP should provide the basic communication facilities to all components. However, it is assumed, that there are also more performing network protocols , which can be negotiated between the network elements.
147
This defines the Application Interface in a more abstract way than by the traditional communication protocols. For the Data Interface, a corresponding abstraction may be found. Rather than defining a fixed scheme for objects (like a database scheme), the Data Interface is also to be implemented by a framework, which describes the format of the data and how it can be accessed. Basically, there are two popular concepts for implementation of the Data Interface: Web-Services or an equivalent formal description to WSDL for objects (which is called Object Definition Language, ODL and originates from the Object Management Group). By using Web-Services, the Data Base Management System is just behaving like a common function. ODL is not as mature as Web-Services yet (i.e. with less implementations on the market), but is more straight forward from a conceptual point of view. For Data Storage, the state-of-the-art technology is called Storage Area Networks, which have already been mentioned in section 4.1.2 as a way to organise data in communication networks in a more flexible way. In summary, there are conventional technologies on the market to implement such Network Service Architectures and to validate the concept. Two more general remarks on the Service Architecture: Distribution: Figure 4-12 does not show, how geographical distribution of functions and allocation of functions to processors is handled. Allocation of functions to physical entities is supposed to be handled according to demands on processing power and storage capacity. The figure is on a purely functional level. Equally, every component may be distributed. Distribution of storage is arranged both below the data interface (as part of storage area level) and by the data interface. Equally, the Application Interface supports the distribution of functions. Distribution is handled by the supporting technologies (such as Web-Services, ODL and Storage Area Networks) Gateways: Besides Common Functions and Applications, Figure 4-12 shown another component: a Gateway. A Gateway is a component, which compliant with the architecture (i.e. it supports the application interface and data interface), but also may connect to traditional network elements and make their functions available to the Network Service Architecture. Gateways are used for Integration. For example, a traditional HLR could be used to provide SIM based authentication in a Wireless LAN or in the Web. This is achieved by connecting the HLR to a Gateway. The gateway translates requests from the service architecture into requests that the HLR is able to handle. In order to do this, the Gateway needs to handle the traditional communication protocols and translate them according to the requested functions. Such Gateways are state-ofthe art, for example as HLR-Gateways for SIM based authentication.
Data Interface
Distribution and system integration
4.2.2 Data Interface

In this section, we will take a closer look at the data interface. Again, emphasis is on the concept, rather than on details of implementation. Figure 4-13 shows in more detail, what is behind the storage of the service architecture represented in Figure 4-12. In Figure 4-13, the storage consists of two components:
148
Data Base Management Systems (DBMS) and a Storage Area Network (SAN).
Fig. 4-13 Data Interface
Storage Area Networks
Essentially, a Storage Area Network (SAN) is high capacity and high performance mass storage for a group of hosts (or users). A Storage Area Network contains three main components: - Storage Units (SU) - Switches (SW) - Hosts (or users). The Storage Unit supports the SAN with its array of disks which connect over an SCSI interface, or , alternatively over fibre channel (FC) interfaces, which allow high-speed connections over large distances (hundreds of kilometers, over channels of 2 Gbits/s per port). The Storage Unit also contains a cache memory. The storage unit is controlled by redundant storage processors. A storage processor controls the disk and manages the available common memory space. In order support fast writing as well as fast reading, the storage processor uses the so called striping the data blocks for the corresponding disks, and arranges for redundancy of data on disks. Different trade-offs between memory space, speed and redundancy are defined in the different levels of Redundant Arrays of Independent Disks (RAID levels). The Storage Processor of a Storage Unit also takes care of the virtualisation of the physical memory space into logical memory units, which are then designated as logical unit numbers (LUN). Finally the storage processor handles the tasks of switching to a redundant device within the storage unit in case of a failure. In order to have the storage unit communicate with diverse hosts or users, a Switch (SW) is used. In the case of Fibre Channel connections, the SAN uses a fibre channel switch (FCS). A back-up unit, which normally should be geographically displaced from the core of the SAN, in order to be resistant against fire or comparable damages, can alternatively be connected directly to the FCS or via one of the more reliable or faster hosts. It total, a Storage Area Network represents towards a host one virtual data storage and hides the physical distribution. In Figure 4-13, the SAN is shown
149
as such a virtual storage unit, which connects to hosts which are running Data Base Management Systems (DBMS). The Data Interface of the network service architecture is represented on top of the data base management system. It is located between applications and data base. In order to get a better understanding of the requirements on the data interface, we will briefly recapitulate how objects are handled by applications and how objects are handled in data bases. Figure 4-14 shows a summary.
Fig. 4-14 Usage of Relational Databases and Object Databases
The application in the upper part of Figure 4-14 corresponds to applications of common functions in the service architecture. The lower part represents the data base and storage, which connect over the data interface to the application. Inside the application, data is contained in objects, i.e. instances of classes in the memory (object heap). Some of the objects or some of the data in the objects will need to be persistent. Persistence means, that this data can be made available again, for example after the application has exited and has erased all its objects in memory. Persistent objects will need to be stored in a file or in a data base. The point is now, that the description of objects contained in an application is different from the description of objects in a data base. Within the application, it depends on the programming language and runtime environment (e.g. Java objects in a Java environment). Within a data base, the description of objects or relations is specified in the data base scheme. What we are looking for, is a formal way to describe objects, which is both accessible for applications and may be maintained in databases. In Figure 4-14, a root object and two depending objects are shown in a symbolic way. Within the application, the process takes care of the correct addressing of the root object and the depending objects. In a representation within a data base, such addresses will need to be formalised and included as keys. Also, in a relational data base, objects will need to be transformed into relations (which is a simple trick: classes translate to relations and objects translate into tupels of this relation). However, conceptually relations are different from objects. Relations may operate in sets, which is missing in object terminology,
Handling persistent objects
150
Databases and applications do not integrate well
but can be arranged for (by lists and cursors to selected tupels). For object oriented databases, a transformation into relations is not required. The major drawback of currently established solutions is, that applications and data bases do not integrate well. Usually, the data base scheme is defined entirely separated from the development of applications. The developer of applications needs to get familiar with the data base scheme or define his own scheme, but implement it separately. Data base queries, for example via languages like SQL, may be embedded into applications. However, the degree of integration is low. The compiler, for example, is not able to check the correctness of data structures or queries. At application level, component based frameworks like J2EE or MS .NET provide a high level of support for handling data transactions. They are providing so called containers for applications. The container takes care of the management of persistent data and of the management of distributed transactions. The application developer may use a framework provided by the container for those functions. All of this does not leave too many options for the data interface. One obvious choice is to use Web-Services again. In this case, a WSDL document would describe access to data, and the DBMS would need to run a corresponding server to provide the data. The benefit of this option is, that it is not limiting the architecture by a limited choice of specific platforms or products. Another option builds on an emerging standard: ODL, the Object Definition Language of the Object Management Group. ODL provides language independent type specifications for objects, extensions for multiple instances and data base keys. The object model is supported by an object query language (OQL) and supports bindings to programming languages (Java, C#, C++, ...).
Fig. 4-15 Concept of Java Data Objects (JDO)
ODL helps integration
One implementation of ODL is provided by Java Data Objects (JDO). JDO (Java Data Objects) supports the concept of a universal persistence model (which is independent from storage technology). Just like Enterprise Java Beans (EJB) from J2EE, JDO provides an own container to handle the persistence of objects. Figure 4-15 shows an overview of JDO. In the upper part of Figure 4-15 we find the application and the container with two symbolic objects. Transient objects remain within the application.
151
Persistent objects are supported by the container (the JDO Persistence Manager), which supports queries of the data base and transactions for storage and retrieval. Both relational data bases and object data bases are supported. The most interesting part is how the data base scheme integrates into the application, or more specifically, into the programming environment. The lower part of Figure 4-15 shows a sequence of steps for the generation of executable software. The chain originates from two source documents: (1) the Java source code, (2) a formal description of persistent objects (JDO XML Description). The latter one represents the formalised object model, which is described in an XML document. This formal description of persistent objects is used to generate both executable code (bytecode), and the data base scheme. In order not to modify the standard compiler (javac in the Figure), the object model is processed by a post-processor, which inserts library functions into the resulting bytecode to handle persistent objects. The post-processor now also is in a position to check the correctness of the source code with respect to the handling of persistent objects.
Common formal description of persistent objects for applications and database
4.2.3 Application Interface

The Application Interface between applications and common functions is shown again in Figure 4-16. The principle of operation is (as summarised in the figure) the reconstruction of client interfaces from formal functional descriptions (WSDL) and the negotiation of wire protocols (with HTTP as common denominator) which bind into the SAOP framework protocol.
Fig. 4-16 Application Interface
In the telecommunication industry, there is one initiative which specifies standard APIs for services provided by networks: the OSA/Parlay Group (Open Service Access). The specifications are also available as WSDL documents. The idea is to provide access to network functions for service providers and 3rd parties to the network operator. The service architecture may be compliant to the OSA/Parlay, if servers are offering services specified in the OSAAPI.
OSA-API
152
The OSA-API represents a super-set of potential functions that a network may implement and offer. OSA/Parlay also specifies a framework, which can be used to find out which subset of the API a network element actually supports. The tricky part of such APIs is the support of such functions by the actual network elements, which generally demands high development efforts and costs.
Fig. 4-17 Applications on the service architecture
Formal service description by WSDL
The Network Service Architecture presented in this chapter follows a more moderate approach. It does not require a super-set of functions, but leaves the functional content completely open. Whatever is provided by a server, may be published as WSDL and may be made available to 3rd parties. Third party applications connect to services which are published by the network operator in the same way as services within the network. Figure 4-17 shows the principle: 3rd party applications represent an extension of the operator's Intranet, i.e. a so called Extranet.
4.2.4 Consolidation of Interfaces

A new service architecture will not start on a green field. There have been massive investments in network infrastructure and modern communication networks provide many services in the most performing and professional way. A service architecture will need to integrate with existing infrastructure in order to make existing functions available to new services, to facilitate the inter-operation of systems and to facilitate the provisioning of services.
153
Fig. 4-18 Gateways to consolidate interfaces
In the approach presented in this chapter, this is achieved by gateways, which connect to existing infrastructure. Figure 4-18 repeats this architecture. In more detail, there are two types of network elements: administrative elements like Customer Relation Management, Enterprise Resource Planning or Billing, and active network elements, such as HLRs, MSCs, SCPs, SGSN and others (see chapter 1). Because virtualisation of data storage is one of the key objectives, network elements which hold service and user specific data are most relevant. Figure 4-19 shows an overview.
Fig. 4-19 Integration of administrative and active network elements
On the left, there are administrative elements. The corresponding Gateway is called EAI (Enterprise Application Interface), which associates with the consolidation of administrative solutions in the Enterprise segment (Enterprise Application Integration). Web-Services are perceived as one major technology for this integration. On the right, the equivalent process has been named Telecommunication Application Integration (TAI). The corresponding gateways provide Telecommunication Integration Interfaces to the networks.
Gateways for EAI and TAI
154
As the service architecture promises to consolidate data in order to provide a more flexible way of provisioning new services and the required resources, it is supposed to accommodate more functions from existing infrastructure over the time.
4.3 Data Models and Semantic Models

...
4.4 Terminals and Embedded Systems

What do we get to develop software on?
In this last section about service architectures, we will take a look at the interior life of a modern telecommunication terminal and what it provides to develop applications. In order to make this look a practical one, the Symbian Operating System and its programming environment has been chosen as example. This choice is completely arbitrary. Any other modern platform will contain the same concepts. Also, the level of detail will not go to platform specific issues, or tool specific issues (the development process, which necessarily is platform specific, is entirely left out). Another obvious candidate for terminals and embedded systems would have been Java (J2ME and associated packages). Java certainly provides the most mature application frameworks (including the Java Media Framework and its mobile equivalent, the Mobile Media API). It is highly recommended for further study. A thorough study of API frameworks is beyond the scope of this rather compact section. Another reason for not using Java as an example is, that a virtual machine only gives a limited view of the practicalities in a small system (such as shortage of resources and ways to handle this).
4.4.1 Symbian Architecture

A popular platform for mobile phones
The Symbian Operating System represents the latest generation of a family operating systems for pocket computers, which started end of 1984 with the first handheld computer: the PSION Organiser I. The PSION I came equipped with the state of the art 20 years ago: 2 kBytes of memory (extensible to 16 kBytes), a Hitachi 6301 processor with 0.92 MHz clock, and a display of 16 characters. Further generations appeared. By 1991, when other products from Apple, Sharp and HP went on the market, PSION organisers already were in their 3rd generation. The PSION devices of that time had an operating system called SIBO (for 16 Bit Operating System) and had a big success on the market. By 1997, under the name of EPOC, a new operating system went to the market for devices such as the PSION 5 MX. Further devices on that basis were the PSION NetBook, the MC128 from Ericcsson, and the PSION series 7 and Revo. A licence model for EPOC was established in order to improve the marketing of their operating system. As a more decisive step, the Symbian consortium was founded by the PSION Group by June 1998. The Symbian consortium also included the major manufacturers of mobile phones: Nokia, Ericcsson, Motorola and Panasonic. Other manufacturers, such as Siemens,
155
Samsung, Sony-Ericcson and others have joined the alliance. The first mobile device with a Symbian operting system (as EPOC had been renamed) became the Nokia 9210 communicator, which entered the market in 2001. By end of 2003, more than 8 million Symbian phones had been sold world wide, which makes it the most successful operating system in that category for the time being. Devices come in different categories. A summary is shown in Figure 4.20. All of them have a common basis. However, the "look and feel" can be adapted according to different device categories, design of manufacturers or design specifications of operators. For an application developer, the major differences are in the capabilities and the design of the GUI (graphical user interface).
Fig. 4-20 Classes of Symbian Devices
The Series 60 (Pearl) the most widely used category today. It applies to so called Smart Phones, i.e. devices, which are the closest to a conventional mobile set. They come with a comfortable color display and are operated by a regular telephone keyboard. Still, they provide features of an organiser, such as calender, a comfortable telephone directory and a Web-Browser. As a mobile set, they may be operated with one hand. Another category, the Series 80, is much closer to an organiser such as the traditional PSION devices. They are operated by a full keyboard, which facilitates handling of e-mail, documents and access to the Web. The most popular (and almost single) representative for this class is the Nokia 9210 communicator. A third category of devices is closest to convential PDAs (such as Palm devices or devices running MS Pocket PC). They are operated by a pen and a touch screen, but also support single handed operation by the telephone keyboard. The most prominent representative from this class is the P800 (and recently P900) from Sony-Ericcsson. Others are the Motorola A920 and the Benq P30. Such devices are classified according to the name of their GUI framework: UIQ. The number of Symbian devices which are currently rolled out is constantly growing. This summary represents the state-of the art at the beginning of 2004.
One hand operation, pen or keyboard
156
Fig. 4-21 Functional System Architecture
Building blocks for applications
What does Symbian OS and its device specific frameworks provide to the application programmer? Figure 4-21 gives a summary of the architecture according to different categories of applications. Symbian OS provides an object oriented design and a framework of conventions and APIs which may be programmed in C++. All categories shown in Figure 4-21 are accessible to application developers. Of particular interest for communication applications may be the Application Engines (engines are applications without a GUI), the Messaging Framework, the Application Framework, access to short range interfaces like Bluetooth for Personal Area Networks (which includes a framework for different classes of applications and service discovery), handling of Multi Media, as well as Communication interfaces. Of specific importance for downloads of applications, which represents a regular action of a personal mobile device, is the Security Framework. In this short survey, we will not be able to enter any detailed level of the Symbian architecture and programming environment. Instead, the target is to show the major design principles and characteristics. One of the most essential features of Symbian is the Micro Kernel architecture. A Micro Kernel is a small kernel (i.e. the core of an operating system): The design principle is only to run the most essential part of code in the privileged kernel mode. The majority of code, including the biggest part of device drivers is represented in servers, which are using the kernel, but are only running with user mode privileges. Figure 4-22 shows a comparison of a Micro Kernel architecture with monolythic Kernels (which are used in operating systems such as LINUX or MS Windows).
157
Fig. 4-22 Micro Kernel versus monolythic Kernel
A Micro Kernel architecture also allows to load and de-allocate servers on demand. Among the benefits are stability (a flaw in the protocol implementation may crash the bluetooth device driver, but it will not crash the operating system) and good use of limited resources (memory is scarce in small devices, which do not have a hard disk). Applications are running a long time and may be launched continuously. As the system may hardly ever be switched off, out of memory situations may occur at any time. The system will need to handle this. Another benefit is flexibility and scalability (server interfaces at the Mikro Kernel facilitate re-design and extensions). Among the draw backs of a Micro Kernel architecture are overheads by inter-process communication (frequent context switching slows down the performance). Context switching is a consequence of good design, which demands servers to be separated into different processes. Generally, performance requirements demand that the most relevant parts and processes are arranged in special ways for Micro Kernel architectures (such as combining processes into threads of one process and fixing address space for the most essential processes).
Keep it small and simple
4.4.2 Client and Server Threads

The system architecture provides different means for segmentation between components: boundaries of privileges and process boundaries. Figure 4-23 shows the basic principle. The vertical boundaries represent process boundaries. A process is a flow of control with its own address space. A process may be an application, or a server (which provides access to resources for other servers or applications). An Engine (Application Engine) is an application without a user interface. The segmentation of different functions (servers and application) into different processes supports the modular design and the stability of a system. Decomposing a complex architecture into modules makes them easier to handle and to maintain. If one process runs into a faulty condition which it is unable to recover from, it will crash, without impact on other processes. Processes may be re-started.
Modular design
158
Fig. 4-23 Boundaries between Components
Boundaries
The horizontal boundary in Fig. 4-23 is the privilege boundary. In a Micro Kernel architecture, the privileged part of code is minimal. Faulty or malicious code which is running in kernel mode (such as flaws in the driver of a communication interface) may be devastating to a system. Executing such a piece of code with only user privileges keeps the essential part of a system out of harm's way. Another horizontal boundary in Figure 4-23 is the DLL boundary (Dynamic Link Library, i.e. code which is loaded and executed by the application on demand) between the engine and its application. This is basically a design boundary which supports modularity in a more or less elegant way, depending on the skills and taste of the designer. One problem with segmentation of functions into processes is the overhead which results from inter-process communication. Each process has its own address space and CPU context (registers, which are particularly heavily used by the ARM processors, which most frequently support handheld devices such as Symbian). The Memory Management Unit, which maps physical and logical addresses needs to load and store the process specific context each time the CPU is allocated to a different process (this is called context switching).
Fig. 4-24 Allocation of Applications and Servers into Address Space and Processes
While processes represent a reasonable environment for different applications, which do not communicate heavily with each other, inter-process com-
159
munication may slow down performance considerably for processes which are frequently used and which frequently interact with each other. For such processes, there are the following measures to improve performance: (1) combine processes into threads of the same process. A thread is a flow of control within a process, which is running within the address space of the hosting process. One typical applications for threads are graphical user interfaces (which benefit from multiple asynchronous flows of control). (2) Allocation of fixed address space to the most frequently used processes and thus eliminating this part of context switching. Figure 4-23 shows how those measures apply to the Symbian OS. The most frequently used servers (i.e. the File Server which provides access to data, the Windows Server, which handles the GUI, the Font & Bitmap Server and Servers for communication interfaces) are allocated with fixed address space. Different communication servers, which are frequently used in combination (such as running sockets over a serial interface over a modem link), are combined into the same process. While those measures provide a secure and stable design with reasonable performance, it leaves another issue unsolved: Instabilities introduced by the application developer by flaws in his software. Separation of control into processes and the use of servers demands, that the application developer needs to get along with the complexity of programming inter-process communications, which is a tricky business. It may result in faulty programs and thus generate another source of instability. In order to solve this issue, Symbian provides a Client-Server framework, which contains the inter-process communication and only request the application programmer to include code to the client side (or server side) of the framework. Figure 4-24 shows the principle (this Figure has been shown in chapter 3 already in the context of distributed computing).
Inter-process communication
Fig. 4-25 Communication within a system - Symbian OS Client-Server Framework
In the client-server framework, access to files, the windowing environment for user interaction, or hardware drivers for communication interfaces are handled by server functions, which are executed in user mode. The kernel provides access to system resources to the servers. When a name is looked up from the phone directory in such a system, the application will use a file server to access the phone directory. The client application and server may run in dif-
Framework APIs for clients and servers
160
ferent threads of different processes. For this purpose, the API framework provides a client interface for the application, which allows to access the file server through the kernel in a well organised way. The client thread and client interface are shown on the left. An application may use this client interface to invoke a server function by sending a message, which is passed through the kernel to the server. The server responds by sending a return message to the client. Through the API framework, there is a context agreement between client and server. This context agreement includes message formats (names of the functions, parameters and return values) including their data types, as well as abstract classes for server and client functions to be implemented by the application developer (also servers may be developed, not only clients to existing servers).
4.4.3 GUI Framework

As one of the most differentiating features of Smart Phones is their ability to change their "look and feel" according to the demands of the manufacturer or network operator, we will have a look at the structure of the API of the Graphical User Interface (GUI) in this section. Figure 4.17.10.2.9 shows an abstract view of the architecture.
Fig. 4-26 GUI Framework API
Application framework builds on kernel and servers
At system level, there is the Kernel, user libraries and the system servers. System servers include the Communication Server, File Server, Windows Server and Font & Bitmap Server. The graphical layer takes care of the presentation of the UI at the display. The Application Architecture (AppArc) and the Control Environment (CONE) provide an abstract level of user interface functionalities required for this. The Application Architecture also provides persistence of states to allow an application to recover and to continue at the state of its exit. The Control environment (CONE) is responsible for the handling and passing of events and for handling the application. It represents the basis for gra-
161
phical programming includung GUI components (controls) at abstract level. Uikon is closer to the actaul implementation and the actual look and feel of standard GUI components. Both CONE and Uikon provide a set of abstract classes for implementation by the application programmer. Basically, the development of a GUI is all about implementation of abstraction from the CONE and Uikon framework. Uikon represents a universal set of a user interface library for all types of Symbian devices. Different device classes (such as Series 60 or UIQ) build on this library and extend this library. In principle, the application developer may also access this level, although in most of the cases, the more specialised and easier to use higher level of classes (such as Series 60 or UIQ) will be used. "Eikon" represents a look and feel which has been used by traditional Symbian devices. "Avkon" represents the look and feel of the Series 60, "Uikon" the look and feel of UIQ (such as P800 and P900).
GUI builds on CONE and UIKON frameworks
Fig. 4-27 Major Classes and Relations within the GUI Framework (Lists)
In order to provide a sample of the interior life of the framework, Fig. 4-26 shows the classes, which represent lists for menus with the Series 60 GUI framework. The framework implements the model-view-control design pattern. CEikListBox represents the controller, CEikListBoxView represents the view, and CeikListBoxModel the model. CEikListBox is the basic class for lists in the Series 60. The view represents all visible parts of it, CListBoxDrawer takes care of drawing the specific contents. The lower part of the figure represents different types of lists. On order to display lists, MEikListBoxObserver processes data in an adequate form.
GUI development is implementation and extension of framework classes
162
Fig. 4-28 Example: GUI Layout for UIQ
Conventions on using the display
Part of the look and feel of an implementation is a prefabricated set of controls. Figure 4-27 show the layout of controls in the UIQ GUI into different panes (windows). In UIQ, a control represents an area on the touch screen, which may be activated by the user and may respond to user actions, i.e. a button or a choice menu. Controls may be either associated with the touch screen, or with physical buttons. The standard controls, which any Symbian device provides, are associated with the Status Pane, Main Pane and the Control Pane. Those may easily associate with any Series 60 device (although they look differently). The top panes of Figure 4-27 are specific for UIQ. The main pane is the typical domain of the application developer. He is in charge of the look and feel of everything presented there.
4.4.4 Data Storage

Symbian supports persistent data (else there is no point in the most common applications such as calender of telephone directory). It also provides support for the most different representations of data, i.e. basically everything that can be attached to an e-mail. Who ever send a power-point attachement to his P800 or P900 will also have noticed, that the presentation can also be displayed on the device. Behind handling of persistent data are basically two concepts: (1) the file server, which provides access to data for applications, (2) the stream store, which operates as a data base and container for data. The file server follows the general rules of the client-server framework. Applications will need to open a session and then invope finctions and exchange data with the server.
163
Fig. 4-29 Stream store with embedded objects
The basis type of container to handle data are data streams. In general terms, a stream represents any type of serialised data, i.e. a sequence of bytes (which may be an object or content from a buffer). From the perspective of the system, serialisation (i.e. the "externalisation" of an object) represents the "write"-direction. De-serialisation (i.e. the "internalisation" of an object) represents the "read"-direction. Each stream is handled by an object reference, i.e. a Stream ID (a 32 bit number). In this way, streams and data records are equivalent. A store may contain a set of data records or a set of streams. Symbian provides a choice of strores with different ways of handling persistency and access: Buffers may not need to be persistent. Persistent streams may be either handled like a file, i.e. written completely when stored, or more like a database, i.e. with only elements updated. Streams may represent an hierarchical structure, i.e. they contain object references to other streams. In this case, the system takes care of the root object. This also allows to embed complete stores as streams into another store (i.e. a grouping of objects). Figure 4-29 shows the principle.
4.4.5 Communication Framework

Because of its relevance to telecommunications software, the last section has a look on the Symbian Communication Framework. Figure 4-30 again shows the functional architecture. This time the parts which are relevant to the communication framework are highlighted. What are the corresponding components within the system?
164
Fig. 4-30 Components of the Communication Framework
Communication Servers
Roadmaps through components reveal the history of communications
The corresponding components represent another client-server framework, which is shown in Figure 4-31. At the top, there are applications, such as messaging applications or web-applications, which use the supporting infrastructure. By following the functional dependencies, Figure 4-31 to follow different paths like on a map. A Web-application will finally use the socket server for communication. The socket server may communicate over infrared or over a dial-up connection. The dial-up connection may use the telephony server to connect over GSM or over a modem. The telephony server may use a serial interface to connect over a GSM interface or to the modem. In fact, Figure 431 quite nicely reflect the complete history of telecommunications over the last 30 years and all the traces it has left. This lack of a coherent concept is a general issue and not specific to Symbian.
165
Fig. 4-31 Communication Servers
The most relevant communication servers have been highlighted in Figure 4-31: the Serial Communication Server, the Telephony Server and the Socket Server. Another essential component is the Communication Database. It contains all the data, which is necessary to configure the different ways of communication (i.e. network access points, provider settings, Bluetooth device lists, default settings, security settings etc). The communication database is also accessible to the regular user via the control panel. Figure 4-32 shows an example (setting the GRPS part of connections).
Fig. 4-32 Access to the Communication Database by the Control Panel
Setting up a socket connection

Among the most relevant parts in the context of communiction services most probably is the socket server, the messaging framework and the bluetooth interface. The remaining part of this summary on Symbian will have a practi-
166
cal look at what the application developer gets. Figure 4-33 shows the main classes of the socket server API.
Fig. 4-33 Socket Server API
API provides framework for connections
The core of any application is represented by the CSocketEngine. This class provides connection with the socket server (RSocketServer). It also may resolve DNS requests (RHostResolver), and establish socket connections (RSocket). By using CSocketReader, the CSocketEngine places requests to read data from the connection. MEngineNotifier notifies about incoming data or error messages received. In the opposite direction, the writing of data over the socket connection is provided by CSocketWriter. The engine, reader and writer are so called Active Objects (hence the stereotype <<active>> in the figure). Active Objects represent the event handling framework within Symbian, which is a fundamental part of the system design. By using the active object framework, the application developer does not need to care about multi-thread programming, but rather may delegate events and have events evoke pre-fabricated functions. The methods SetActive() and RunL() in Figure 4-34 are the fundamental representatives of the active object framework.
167
Fig. 4-34 Example: Set up a Socket Connection
Figure 4-34 shows the sequence of establishing a server side socket connection, which involves some methods of the classes described in Fig. 4-33. A condition for the sequence is, that an instance of the socket engine and the depending objects have been created and initialised. The socket engine starts from a not connected state. The sequence start with a request to the engine to establish a connection to aADDR, i.e. an IP address in the network. It changes to the connecting state, sets a timer to time out after a specified period of time and delegates an active event. The engine stays in this state, until its RunL() method is evoked by the framework (which either reflects the arrival of data or a time out).
States, events and messages to framework objects
Exchange of messages over Bluetooth

Fig. 4-35 Bluetooth Message Server by Sockets
168
Sockets over Bluetooth
To conclude on the Symbian communication framework, we will have a look how the socket server combines with the bluetooth interface and the message framework. Figure 4-35 shows the most relevant classes in this context. The central components is the the Message Server CMessageServer, with the application view CPointToPointAppUi. The message server initialises the serial port of a Bluetooth connection, publishes the application, authorises and accepts connection requests and receives messages. Connections may be initiated by the socket server described above. In more detail, there are two instances of sockets (RSocket) used in a connection: iListeningSocket to receive connection request, and iAcceptSocket for actually accepted connections. The instances can bee seen in the following sequence diagram Fig. 4-36.
Fig. 4-36 Example: Sequence at the Bluetooth Server
Bluetooth service advertisements at the server
Bluetooth connections are protected at different levels. The configuration is handled by the Bluetooth security manager: RBTMan. The settings are contained in RBTSecuritySettings. Applications will need to register at the the security manager. For security settings, a data type TBTServiceSecurity is dedicated. Finally, applications will need to be published in a Bluetooth Service Record. This is handled by the classes at the bottom of Fig. 4-35. The message server is using CMessageAdvertiser to do this. The classes RSdp and RSdpDataBase connect to the database of the Bluetooth Service Discovery Protocol (SDP). Figure 4-36 shows the most prominent instances and the sequence of events at the server side. How is this service advertised in the Bluetooth Data Records for Service Discovery? Figure 4-37 shows the corresponding service record. The first entry is the ServiceClassIDList, which identifies the service as a serial port service with a corresponding UUID. The next entry, ProtocolDescriptorList, allows to identifiy the protocols used to invoce the service. In this case it indicates the serial port protocol (cable replacement protocol) RFCOMM over the Bluetooth L2CAP layer (see chapter 2.6 for the Bluetooth Protocol Stack). Both protocols are labelled by their corresponding UUIDs. For RFCOMM, also the port number to be used is indicated. The elements of the ProtocolDescriptorList are sorted in a sequence from the lower to the hig-
169
her layers of the protocol stack. Those protocols are required in order to access the application on the dervice.
Fig. 4-37 Service Record of the sample application
The remaining attributes of the service record are the name of the service (ServiceName), a brief description of the service (ServiceDescription) and an attribute, which indicates the auvailability of the service (ServiceAvailability is set to true, as soon as the entry into the service record has been completely written, which is handled by a method of the Message Server). The name and description of the service are character strings which may be displayed to the potential user of the service. All entries of the service record are handled by the object RSdpDatabase which is shown in Figure 4-35.
Service Record contains specificaton of communication interface
4.4.6 Messaging Framework

Messaging describes the exchange of documents which may contain different kinds of media. Media includes any kind of digital media, such as text, audio, pictures, video or signals. This media needs to be composed and transferred over a network. A messaging framework needs to support those two functions: (1) the composition of media by the user and (2) the transfer of media over a network. An example for a messaging application is an e-mail client, which allows to attach documents and send them to someone. On a mobile device such as a PDA or a mobile telephone, text messages, pictures or audio files may be composed and send as messages over a diversity of services (such as SMS, MMS, Bluetooth, E-Mail, FAX). Also, the user will need to be informed about incoming and outgoing messages. For this purpose, messages are kept in different accounts (such as SMS, MMS, E-Mail accunts). Each account has an in-tray and out-tray and an indication of the number of messages contained there. Messages may directly be send from applications. For example, every kind of document has an option send as. In this case, the transport service is selected by a user dialog (send as e-mail, Bluetooth, Infrared, MMS etc). Different transport services have different requirements. While Infrared or Bluetooth directly deliver the message to devices which may be detected in the environment of the user, sending a message over e-mail, MMS or need a cou-
Messages are to be composed and transferred to a transport service
170
rier service to handle the transport. This will need an e-mail account or MMS account and a corresponding service. The usage of such services needs and their network interfaces needs configuration, which is not part of the messaging framework.
Fig. 4-38 Components of the Messaging Framework
Messaging framework contains composition, storage, transfer and display of messages
However, the messaging framework includes everything which is associated with the composition, display, copying and storage of messaging on the system, the selection of a transport service and the transfer of the message to this service. Figure 4-38 shows the components of the messaging framework. The upper part contains components for the composition or formatting of messages, the lower part is in charge of transport. The central part is an application which handles the user interface (Application UI). Writing such applications is supported by components of the messaging framework: User Interface MTM (message type module): provides message specific context for the user interface. For example, an e-mail is more complicated to edit than a SMS. The User Interface MTM supports the display of messages, the editing of messages, the disposal of messages in the in-tray or out-tray, the selection of the transport service, the hand over to the transport service as well as the display of status reports or error reports. User Interface Data MTM: A support function for the User Interface MTM, which contains data such as icons or bitmaps associated with the user interface for handling messages. Keeping data apart from the User Interface MTM (instead of having copies with instances of the user inetrface) allows to save some memory. Client Side MTM: Provides an abstract view of different message formats. The Client Side MTM takes care of transormation of message formats between storage and display. It also provides access to address books and support for answering or forwarding of messages. Applications, which do not need a user interface, may directly access the Client Side MTM. Session: Provides sessions with the Message Server (i.e. the client interface to the Message Server). Message Server MTM: The major function of the Message Server is the
171
transport of messages over the corresponding message services (such as e-mail, MMS etc). The Message Server provides access to the message storage and the Message Type Modules which are requested by the application. Incoming messages are stored by the Message Server with an indication in the corresponding in-tray of the message account. The Message Server also handles the remote accounts for e-mail and provides indication about the progress of transactions. Communication between clients and the server is asynchronous. Each client request generates a copy (an instance) of a message server object. Server Side MTM: Supporting functions which are used by the message server. The major function of Server side MTMs is the copying and moving of messages and components of messages within the internal directories and strorage. Also the transfer of messages over different transport services is handled by Server Side MTMs (sending a message over e-mail is different than sending the message over FAX).
Fig. 4-39 How messages are stored
What exactly is contained in a message and how are messages handled and stored? The general composition of a message has the following components: a message header which contains gerneral information about the message and MTM specific information, the message body, which contains the message itself, and attachments. Not every message contains all components. A simple text message does not have attachements. A FAX does not have a message body, but a document containing a graphic as attachement. Because the composition of messages may differe considerably, the three components (message header, nessage body and attchments) are stored separately. Figure 4-39 shows the components of a message and some of the information which is contained in an index, which is part of the message header. This index contains all required information about the composition of a message, the location of the copmponents, the status of the message and the handling of the message including the transport service. The body of the message is a so called rich text format, i.e. a text with embedded files (pictures etc).
Composition of a message: index, body and attachments
172
5.1 Introduction
173
5 Engineering Methods for Services
5.1 Introduction
In the process of software engineering, there are two major areas of activities: (1) planning and design, (2) building. Planning and design represents transformations on a model. To support these activities, the Unified Modelling Language (UML) provides a terminology and diagrams to represent different aspects of a model.Also, like in planning and designing a house or an airport, some parts of the model are repeating (like windows and doors in a building, or the design of the roof). They show recurring patterns. In a software architecture, a recurring task is the graphical user interface, the control of the program and the persistant data. For this task, the Model-View-Control pattern represents a way of design.
Fig. 5-1 Methods for Planning and Building
The second area of activity, building, represents transformations on code. Developing software rarely starts on a green field and has the complete code developed and compiled to the target device from scratch. In the usual case, the newly developed code builds on an existing base. In particular for object oriented design, there are API frameworks specified and libraries available, which can be build upon. Besides reducing the total development effort, this also improves the quality of code and generates a common basis of code and conventions for developers. In component based software, the most frequently used functions, such as handling persistence of data or handling transactions, are handel by a so called container. Applications run in such a container according to specified rules. Figure 5-1 shows the relations between planning, design and building. Both interrelate. Building always has a model in mind.While using an application
Different ways of using lego bricks
174
Chose the right development process for the project
framework, this model is specified and may be incorporated in the toolchain. From planning and design, code may be generated in the build process. The development process, i.e. which activites are done at which specific point in time, largely depends on the type of problem. Developing a new application for a mobile device represents a smaller activity and will follow closely to the application framework of the device while using the corresponding Software Development Kits (SDK). Development of a large project with many people involved represents a higher challange for project management and needs a stricter specification and management of the development process. Developing a functional prototype again has different constraints and requirements and thus has other demands and priorities concerning the development process. But not every case is individual. There are also classes or types of development processes. The right choice and management of the process will largely determine the success or failure of a project. This chapter aims to show the basics of engineering methods for services, i.e. to introduce models and the development process as concepts in the context of software engineering. It does not represent a solid introduction to UML, but only shows what it looks like and how it is applied. Also, it does not represent a summary of development processes, but rather shows a representative case of tools for the development environment and for the runtime environment of a prototyping process. Both on UML and on development processes, there is plenty of literature available.
5.2 Engineering Services with UML

5.2.1 A sample application
Remote controls again
As an example, a service will be designed according to the scenario shown in Figure 5-2. The idea is, to develop an application, which allows a user to select a movie by his mobile phone and play it on his TV. To do this, the user is supposed to start an application on his mobile phone. The application will then connect with a Pay-per-View system over the Internet. The user is presented a choice of movies. The user selects the movie, pays for it in some way, and then is able to control the movie with his mobile phone. The control of the movie may take place just in the way of controlling a media player (i.e. using controls such as start, stop, play, mute, fastforward etc.).The movie is played out by a broadcast network, such as CaTV, terrestric TV or over satellite, i.e. not necessarily an interactive channel. Interactions are handled by the mobile set. This scenario is arbitrarily chosen and just represents a case to demonstrate service engineering. The Unified Modelling Language (UML) provides diagrams and specifications for different views at designing a solution for this service. It does not specify a specific process to follow in the design. Thus, it is the designers choice how to proceed. In this case, a logical first step would be de specification of the use cases.
175
Fig. 5-2 Mobile controlled media
The Unified Modelling Language (UML) provides diagrams and specifications for different views at designing a solution for this service. It does not specify a specific process to follow in the design. Thus, it is the designers choice how to proceed. In this case, a logical first step would be de specification of the use cases.
Use cases
Use cases are close to the interactions of the user and the system. They show how the system is interacting with its environment (i.e. users but also other actors such as other systems). In a use case diagram, actors are represented together with their actions (use cases) to a system. Figure 5-3 shows the uses cases for the mobile remote control.
Fig. 5-3 Use Cases and System Components
176
Select, pay and play
The use cases are inside a box or package, which contains the components of the Pay-per-View control. Other components, such as administrative functions, are not part of this package. There are the following actors: the user, a media gateway which is actually playing out the movies, and a AAA-server for authentication, authorisation and accounting. The uses cases are: select movie, pay for the movie and play the movie. The selection of a movie needs authentication of the user. Authentication is included as a separate use case, because authentication represents an own building block which could also be used in other places. Inclusion means that the use case select movie includes the case authenticate user like a subroutine. Another case which is included is the update of the user account, i.e. the decrease of the account by the maount which is due to pay for the movie. The use case diagram explains in very simple terms what the system described by the package is going to do and with which other systems it interacts.
Activities
The target of the different descriptions is to define the system and its components by a model which can be represented by software. Another diagram on this way is the activity diagram, which describes the sequence of actions and interactions between systems which are required to complete the use cases. The flow of actions has a starting point and an end point. Figure 5-4 show the activities of the user (on the left) and of the media control centre (on the right). Activities are represented by rounded rectangles and connected by a flow of control. Comments in document boxes explain activities and give hints for the implementation.
Fig. 5-4 Specify Activities and find corresponding Classes
The first activity shown in figure 5-4 is the user login into the system. The system is doing a check of the user identity (i.e. authentication). The way of authentication (e.g. password or token) is not further specified at this stage. In order to do authentication, the system is supposed to contain a representation
177
of the user, i.e. a user object which contains the user profile including credentials and access rights (privileges). If authentication is not successful, the user is prompted to identify again. Else, the flow of control proceeds to the next activity: the generation of a choice of movies by the system. This choice is then passed as an object (named selection in the figure) to the user. A remark concerning terminology: a flow of control may be represented by the flow of an object. In this case the object is shown between arrows with dotted lines. The next activity is again at the users side (or so called swim lane). The user selects a movie from the list. The comment indicates, that the system also will need to contain an object which represents the film. Selection will set an attribute within this object to a selected state. Following selection, the user will need to agree to pay for the movie. As indicated in the comment, this action will decrement the user account. The comment also suggests that the user account may be implemented as an attribute of the user object. Following payment, the media control centre prepares the play out of the movie. This will need interaction with the media gateway, which is represented by the subsequent action select media format in the media control centre. Because users may have different ways to play out the movie (such as media formats for streaming), the comment suggests ro implement different types of media as attribute of the user object. Playing out the movie will also need to pass control to the user, for example to show a media player type of user interface with buttons stop, play, mute, fast forward etc. at his terminal device. In order to both activities in parallel, the flow of control needs to split, which is indicated by the transistor like symbol. Both branches following the splitting point are executed in parallel. Following preparation, both flows of control return in a synchonized way, which is indicated by the synchronisation point. The activities proceed, after both actions have completed: the movie starts.
Interaction and transfer of control between user control centre
Classes and Relations

The activity diagram already made some suggestions about some of the classes which are required to proceed with the software design: a user class: Thes class represents the users of the system. It will need to contain a user ID, the user name, credentials and rights, how much is on the user account. Also contains further information about the service profile of the user, such as the type of media channel. a class to present a choice of movies: A choice of movies, most probably according to categories (such as action, comedy etc). a class to represent a movie: Movies belong to a category, have a name or title, and contain information about the movie (main actors, director, how long it plays, year of procuction etc). Also they will need an identity for internal represention within the system. Figure 5-5 shows a class diagram of a potential design. It contains the above mentioned classes for films and movies. In order to generate a choice of films, a class which represents the category of a film is proposed. This class relates with a multiple number of films. It is supposed, that the user selects a category.
Developing a model
178
The arrows at the relations between the classes indicate the direction of navigation. i.e. the user selects a category or movie.
Fig. 5-5 Classes and their Relations
The class doagram also indicates how the user is supposed to control the playout. The class channel represents the equivalent of a TV channel and correspomds to the media type that the user is able to receive. The comment at the channel indicates, that the channel has different states (such as playing, stopped, muted), that the user can change by his remote control. The comment at the user class explains the way the classes are used. In general, the class diagram describes the static design, that is the types of objects and their relations. It does not represent the instances of the classes, i.e. the objects that are actually generated from the classes at runtime, for instance, the objects according to the movies contained in the systems. Those may be represented by an object diagram, which describes the dynamic behaviour of the design (objects are generated, used, exchanged or deleted).
Design Patterns
Use patterns for modelling and design
When designing software, there are some recurring problems, such as the design of a user interface. In the example shown in Figure 5-5, the user is suppoosed to select a channel and tho change the state of the channel to play or stop the movie. In order to do this, there will need to be other elements to represent the display and the buttons which are used for interaction with the user. This is a recurring problem. It has some general elements, such as different types of classes. The channel type of class shown in Figure 5-5 if an information element: it contains the status of the channel. Such classes are called entity types of classes, or model types of classes. They represent a model of the system and frequently, they contain persistent data (e.g. the status attribute of the channel could be persistent in a robust design). Other classes will needed to represent the display elements and buttons. Such types of classes are called boundary or view type of classes. Other classes are requried to generate a flow of control, such as tu instantiate classes
179
and generate objects and to comtain methods that actually do something (such as to start the graphical user interface and to change the status in the channel object). Such types of classes are called control. The relations between the types entity (or model), boundary (or view) and control follow a general pattern. Such design patterns may be used to solve recurring problems. Figure 5-6 shows a potential user interface for the media remote control with the above mentioned types of classes.
Fig. 5-6 A potential User Interface
The boundary or view part contains the visible parts of the user interface: graphical elements to represent the title of the movie and a choice of options which correspond to buttons at the mobile device. This class belongs to the control type of class. The design shown in Figure 5-6 uses an aggregation as relation between control and view, so both classes must exist together. The control type also changes the status of the information or model type of class (the channel). The figure also indicates, that the Media Control Centre instantiates the control element, which subsequently instantiates the others. The example shown in this chapter is just a hypothetical design in order to illustrate the bsic principles. In a real design, functions would need to be distributed to the different components of the system (see Figure 5-7). The graphical user interface described in Figure 5-6 would run on the mobile set. The channel with the status would reside within the media control center. Thus, the status information would need to be communicated between the mobile set and the media control center. Also, there need to be communication interfaces between the media gateway and the media control centre, and between the AAAserver and the media control centre. Persistent data may be kept in a central place. Figure 5-7 illustrates another typical systems design: it represents a 3 tier architecture with clients, application servers and data bases. The clients on the mobile set (and on the TV set-top-box) generate the user interface. The applications reside on the servers of the 2nd tier. This corresponds to the typical Web-Design with browsers or Applets running on the clients, and applications handled for example by Servlets, Enterprise Java Beans etc. The typical way
Model, boundry and controller
Three tier architecture for clients, application server and data repository
180
of communication between clients and applications in such a design are messages exchanged as XML documents over HTTP.
Fig. 5-7 Components for Service Implementation
5.2.2 Summary of popular UML diagrams

UML diagrams have been used to represent different views of a design. Among the most popular diagrams are the following: Class Diagram: Shows the classes and their relations that build a system. Class diagrams are indispensible in software design and also form the bridge between the static construction (classes) and the dynamic behaviour (objects). An API shows the classes including attributes and methods that are available to the application developer (but does not show the implementation). Class diagrams have already been shown in this book in chapter 3 (see Fig. 3-6 on the client server framework of a mobile device), chapter 4 (see Fig. 4-27 on the GUI API framework, Fig. 4-33 on the socket server API, and Fig. 4-35 on the message server API). Fig. 4-14 shows the relation between classes and data objects. Packet Diagram: Help to organize a large and complex design by putting elements that logically belong together into units. The package PPV in this chapter represents a packet diagram (see Fig. 5-3). Object Diagram: Represents a snapshot of the system at runtime with (relation to the class diagram). Illustrates attributes (i.e. data) contained in objects and multiplicity of objects. This book does not go to this level of detail, but elementary object diagrams can be found in the exercises. Use Case Diagram: Shows what the system is doing in relation to its environment. Represents the exterior view of the system at the highest level of abstraction and in a very simple way. Thus, it is a good entry point of a design.
181
Activity Diagram: Shows the flow of control in a process, i.e. how a job is organised as a sequence of actions. Also shows actions that run in parallel, conditions and loops. Fig. 5-4 represents an activity diagram. State Diagram: The state diagram shows the different states of an object, of an interface or an object and the events that correspond to changes in the states. State diagrams have been shown in chapter 2 in the context of finite state machines (see Fig. 2-9, 2-10, 2-13, 2-17) as well as in the context of the Bluetooth protocol (see Fig. 2-40). In chapter 6, the states of an application (Midlet) in its application environment are shown (see Fig. 6-3). Sequence Diagrams: Similar to Message Sequence Charts. Sequence Diagrams describe the exchange of information between objects in detail, i.e. which messages in which sequence are exchanged between objects. Sequence diagram procide a very precise way of interactions between systems or objects (as instances of classes). Sequence diagrams have been shown in chapter 1 to explain how mobile networks work (see Fig. 1-24, Fig. 1-41, Fig. 1-42 and Fig. 1-43), in chapter 2 to the seequence of messages exchanged over protocols (see Fig. 2-16) and in chapter 4 to describe the interactions between objects in a software design (see Fig. 4-34 and Fig. 4-36)
5.2.3 Tests
No design is perfect and thorough tests are a mandatory part of the development process. Different tests apply at different stages of the development process. A brief summary of the different steps and types of tests has been given in chapter 2 (see section 2.4). In this section, we have a look at functional tests of an application on a mobile client and how to apply test tools. There are different methods to facilitate tests. One method is to include checkpoints into the software (so called assertions), which make bugs visible. An assertion is boolean type of expression which checks a condition within the system (e.g. whether a counter stays within some boundaries). Assertions may be used in the debug version of a software, or even stay in the final code. In the latter case, they may help to locate bugs after the software is shipped to customers. For example, an assertion may cause a process to derminate (to panic) with a fault condition. Such assertions are easy to identify by the user and may be used for foult reports. There are test tools available, which facilitate unit tests by automatically generating a test environment, so the developer may concentrate on writing the test cases. Using test cases, it can be measured, whether the classes or modules within the code behave correctly or deviate from their specification. If a module has been modified, all tests which involve this module and have been passed already will need to be repeated (the so called regression tests). Test tools facilitate the repated running of test cases. Also, test tools automatically generate a test report. Using unit test tools may improve the quality of code significantly at a moderate expense of time and resources. Test coverage tools indicate code, which has not been tested. Coverage analysis tools indicate whether a sufficient amount of tests have been done.
Tests are part of the development process
Test tools at unit level and at system level
182
Another level of tests works at system level, i.e. by testing the interactions of a system (black box) with its environment. To test complete applications at system level, there are also tools available. Figure 5-8 show the scenario.
Fig. 5-8 Test Tools for Applications
Tools cannot generate test cases
The application at the center of the figure is running inside a test envirnment. Physically, the application may either be running on an emulator (such as a PC which emulates e mobile set), or directly on the target system. The test environment basically records inputs generated by the user (such as pressing buttons following the user interface of the application). The recorded imputs may be played back to the application automatically and for an idefinite number of times (the automatic playback may also be used for demonstrations of the applications). The recorded inputs are stored in a test script by the test tool. An editor allows to modify the test scripts and thus to generate test cases for different sequences. Also, fault conditions and events may be introduced that the application needs to be able to handle and test reports are generated by the tool.
5.3 Development Tools and Process

Development system, runtime system and development cycles
So far, we had a look on the design of software based on models and code. This section has a look on the development tools and on the development of prototypes. The focus is on popular open source tools and on popular and free runtime environments. Again, the idea is to provide a view about the practicalities of software development rather than a thorough description of tools and platforms. For all of the components there is an abundance of literature and information in the web.
5.3.1 Development Environment

Figure 5-9 shows the components of a development platform. The major components are the software platform (i.e. the operating system and software development toolkit), the Integrated Development Environment (IDE) with its associated tools and tools for version control, bug reports and modeling. Not
183
all components are mandatory. The development platform rather represents a collection of tools that are used in the development process. All tools will need to be installed and to run on the software platform, i.e. on an operating system such as Linux or on a Java runtime environment (whcih is contained in the Java 2 SDK). The IDE is software (such as Eclipse) which integrates tools needed in the development process.
Fig. 5-9 Development Platform
The components (or plug-ins) of the IDE and other tools shown in Figure 59 are the following: Modelling tools: are used to generate UML type of models in the software design. Build Tool: The build process is the process of generating executable code from source code and resources. In the most simple case, the build process is a sequence of compilation of source code and linking with code from libraries (compile, link, run). In reality, the build process involves many files and can be extremely complex. A build tool automises this process. Code is generated by pressing a button, while the tool keeps track of files, directories and the right sequence of steps. Build tools operate from a script, which may be edited or configured by the developer. Deployment is executabele code may also be handled by the build tool. Test Tool: The most important tests during the development of software are unit tests. Test tools allow to run software under development in a controlled environment against test cases (see section 5.2.3). Bug Tracker: Software sometimes takes a long time to mature. Bug reports are important to improve the quality of a software. A bug tracker follows up bugs discovered during development and after shipment of the software. The central part is a bug report which follows the different states of a bug, A reported bug may be deffered or handled on a process. The processing of a bug includes the following steps: as opening and assig-
184
ning a a bug to a developer responsible to fix the bug, assigning the state fixed after the problem is solved, verify the state fixed and finally assigning the state closed to the bug. Version Control: Different states of maturity are represented by different versions of a software. While the latest release may contain all the new features, an older release may be more stable. Also, when developing in a team (which represents the regular case in development), different versions of software modules need to be managed. Besides source files and resources, version management also keeps documentation and other related files in a consisten state. Version control tools also provide snapshots of files at a specific date or may roll back a file to a version number in its history. Profiler: A profiler allows to check the performance and demand on resources of a software. A profile includes how much memory is consumed, CPU usage, I/O times and throughput, generation and consumption of threads, the number of objects generated, and the usage of code (which parts are used frequently, rarely or never). Profiling tools are used to locate bottlenecks in the performance of code and to compare the performance of different versions. Templates and Wizards: Help to manage configurations and settings. J2ME Development: A J2ME development toolkit is only required if client code for a mobile set based on the Jave 2 Micro Edition is developed. J2ME represents one way to actually implement the sample application shown in chapter 5. Database utilities: Another set of tools (not represented in Figure 5-9) are database design tools and database administration tools. Database design tolls allow to generate a database from a graphical user interface and to generate scripts such as SQL. Database administration tools are used to actually run scripts and queries, to configure data base settings, to activate or stop the data base server, as well as to browse, import or export data.
5.3.2 Runtime Environment

Following development, the application will run on a runtime platform, i.e. on a server in the network or on a client. Figure 5-10 shows the components ofJava based runtime platforms. On the right, applications are running either on an emulator or on the target system. In each case, the Java Runtime Environment (JRE) and J2ME Application Management System is hosting the application and is hiding the actual operating system. The server shown on the left is much more complex than a mobile client. It contains a Java Runtime Environment, a Web Server and a data base management system. Also, a significant amount of libraries and software components are used (such as Servlets, Java Server Pages, Enterprise Java Beans or other parts of J2EE, the Java 2 Enterprise Edition). Applications are hosted as WebServices or by J2EE application servers (wich provide a Web-Container for Servlets and Java Server Pages or an EJB container).
185
Fig. 5-10 Runtime Platform
There is a choice of products on the market for the different components. Figure 5-11 shows a collection of state of the art open source products both for the development platform and for the runtime platform.
Fig. 5-11 Components for the Development and Runtime Platform
5.3.3 Development Cycles

If the requirement on a system is very well known, e.g. in a situation, where new features are added to an existing system, the development process tends to be very straight forward. The design is well known. In some cases, in particular for new systems and new applications, the requirements are less clear. In such a case, it may be useful to develop a prototype, which only provides part of the functionality and follows a simplified development process.
Iterations facilitate the process
186
Each iteration contains a development cycle
Such prototypes represent a method to fix requirements and find out more about different options for the design. The development process follows several iterations. A first prototype may show some of the functions, such as part of the user interface, while emulating other parts of the system. The next prototype may provide a redesigned user interface and may contain more fucntionality. The final development will need to cover all non-functional requirements such as performance, quality, design rules, documentation, and the general compliance to the designated environment. In each iteration, software needs to be developed both for the clients and the servers. Figure 5-12 shows the development cycle (which needs to be passed for for any development, inlcuding the development cycles of a prototype). The assumption is, that the development is based on a 3-tier architecture: clients, application servers, and data base servers (data provider). The steps of the development cycle include the original (manual) development of the core elements, the generation of templates by tools, and finally the implementation of the remaining pieces of code and to run the build process.
Fig. 5-12 Development cycle
Steps of a development cycle
In more detail, the steps contain the following actions: Step 1: Original Development. This is the modelling phase. UML is used to generate the key elements. Also, the representation of persistent objects in a data base needs to be defined (either from an existing data base or as a new design). UML editors also allows to handle data and to generate classes according to a data base scheme. Step 2: Generating everything by tools. In the 3-tier architecture dynamically generated HTML pages are used between client and application (e.g. using Java Server Pages at the server), respectively the client application corresponds over HTTP with the application (e,g, using Servlets at the server to communicate with Midlets or Applets on the client). Further, it is assumed that he application server communicates with the data base server over Web-Services. The tools provided by the IDE provide templates for all the elements needed in the application (such as empty Mid-
5.4 Plug-ins and Bundles
187
lets, empty JSP and Servlets, as well as the classes and scripts required in the Web-Servics environment on both the application server and data base server. Also, tools like WSDL2Java translate a WSDL which has been extracted from one existing Web-Services implementation automatically into a Java client. At the server side, beyond publishing and registering the server application all communication and exchange of SOAP messages is hidden from the application developer. Step 3: Implementation, building and deployment. In this final step, the remaining functions are implemented in the templates that have been generated by the tools and in the previous steps. Data extracted from the data base will need to be organised in a way that can be handled by the templates and by the conventions of the application framework. Also, data will need to be prepared for the GUIs at the clients. Following implementation of the remaining source code, the build process can be started. As in every development, this will generate error reports and warnings generated by the compilers. Thus, there is some iteration in step 3 itseld. Finally, the code is deployed on the runtime systems.
5.4 Plug-ins and Bundles

... OSGi & Eclipse components
188
6.1 Sandbox and Middleware
189
6 Security for Services and Applications
A reasonable level of security is a condition for the deployment of any telecommunication service and application. While traditional telecommunication networks (such as ISDN or GSM networks) have well been isolated between network operators and from the Internet, the next generation of networks provides two new challenges: (1) they are based on IP networks and provide less isolation, (2) terminal devices allow to download and run software. In this chapter we will look at security issues and the methods that apply to handle them. The first paragraph describes a sandbox concept for software on terminal devices, the second paragraph is about IP security issues and solutions. The third paragraph describes the increasingly relevant concept of identity for network access and services. The chapter ends with a parapgraph on the security concept for Web-Services.
Cryptography is fine, networks are lousy, users are unpredictable. Bruce Schneier, Secrets and Lies

6.1.1 The Java Sandbox as role model
The concept of a sandbox is simple: it basically means the insulation of applications from system resources. Figure 6-1 shows the principle. The operating system controls access to systems resources (such as files, physical memory, peripherals etc). However, the level of protection that modern operating systems provide is quite low. The reason is, that restrictions for applications would generate more hassle for the user and application developer. For instance, restricted access to specific data files would need to be configured. So, as it is very well known from Viruses, Trojan horses and Worms, malicious applications can generate a lot of hazards. A better level of security may be provided by running a middleware on top of the operating system, such as a Java Virtual Machine. Applications will run inside of this middleware in a controlled environment, the sandbox. Access to resources is restricted by the sandbox. Applets running in a web-browser are another example. Generally, applets are not allowed to access the file system. But what are the components of a sandbox and how does it work? We will use Java as a role model and have a practical look at J2ME.
Execute applications in a safe environment
190
Fig. 6-1 The sandbox concept
More than restricted access to resources
The history of Java actually begins with a design for executable code on any kind of embedded systems, i.e. connecting doorknobs to light switches. Distribution of software and a security concept with a particularly high level of usability for both application developers and users have been in the design of Java from the beginning. In practice, a sandbox represents a combination of many concepts. Basic concepts from standard Java include handling of name spaces, enforced data types, intermediate code (bytecode), bytecode verification and garbage collection. With J2ME MIDP as a middleware for mobile devices, there are further concepts derived from practicalities, which will be summarized in the follwing section. Basic security concepts in Java: Handling of source code: Java-Sources are kept in files ending with .java. A file may contain multiple classes, however only one class of public type, which corresponds to the name of the file (for instance AudioPlayer.java). The Compiler translates source code to byte code. Each class of byte code is kept separately in a file ending with .class. Java is utilising internally unicode characters. Unicode represents an internationally standardized set of 16 bit characters, which contains the 7 bit ASCII format as subset. ASCII sources are transformed to unicode before compilation. Handling of name spaces: A name space is the context, in which a specific name (e.g. of a method or class) is valid. The basic principle of organisation is that a local name always covers names further up the hierarchy. The hierarchy of name spaces is organised in the following sequence: name spaces of packages, name spaces of classes, name spaces of methods of classes, name spaces of block within methods. The compiler resolves names from interior to exterior until the first hit. Enforced data types: Java knows the elementary data types logical (boolean), integers (int, byte, short, long), floating point numbers (float, double) and characters (char). Constants are declared using the final attribute. There are no pointers in Java. Data elements in objects are initialised automatically. Java supports operations on data types String (characters) und Arrays. String operations include generation, literals and conversion into elementary data types. Bytecode verification: In combination with bytecode verification, the strict
191
handling of data types is the reason, that Java applications are resilient to buffer overflows. Bytecode verification also checks for violations of address space and correctness of code (no endless loops etc). Garbage Collector: Objects are generated using the operator new. The programmer does not require cleaning the heap from unused objects using a destructor. The garbage collector is a process, which takes care of removal of unreferenced objects within the heap. This makes one of the major sources of instabilities and faults caused by application programs redundant.
6.1.2 Middleware - the J2ME MIDP security concept

J2ME security concept goes beyond the standard protection provided by Java. It includes a bytecode verification, which is specialised for devices with a small memory footprint and limited computing power. Also, fixed class loaders now enforce name spaces for class libraries. Communication links may be secured and always demand authorisation by the user. Downloads of applications may be secured using certificates in order to identify their source and deliver them unmanipulated. Also, applications are isolated from each other and from each other's data. Applications are embedded in a container, i.e. a management system that controls their lifecycle.
A recipy for disaster: download applications
Fig. 6-2 The structure of the Java 2 Micro Edition
As shown in Fig. 6-2, J2ME applications also run on a virtual machine, which has a smaller footprint than the standard virtual machine and protects the system from unauthorised access and runtime errors. Verification of byte code includes the validation of data types, instructions and the validation of address space. The middleware part includes two layers of basic functions, the CLDC (connected limited device profile) and MIDP (mobile information device profile). Name spaces are maintained by a fixed class loader, which gives priority to the libraries which are installed on the system. Using this class loader ensures, that classes from the library may not be overwritten by other classes. The application developer is not able to use another class loader in order to bypass this mechanism.
A class loader with clear priorities
192
Access to communication links needs permission
Access to communication links only with consent of the user, i.e. a user dialog is called each time an application wants to interconnect. Alternatively, the user may allow a specific trusted application to use communication interfaces without asking for an individual permission (as a preset by the user). Most importantly, Midlets (or more specifically Midlet-Suites) run in an application environment and are not allowed to communicate with other midlets or to access data of other midlets. This basically corresponds to the container principle used by Applets or Java Enterprise Beans. Figure 6-3 shows the states of a midlet in its container.
Fig. 6-3 States of a midlet in its container
A container for applications
The Midlet container is using an application model: Each Midlet needs to implement specific Java interfaces, which allow the container (the application management system) to control its states Midlet. Midlets within the same Midlet-Suite are allowed to communicate with each other. A Midlet-Suite represents a set of Midlets, which are downloaded within the same archive (JARFile, see Fig. 1-3, which shows the build process for Midlets). Also, a MidletSuite contains its own persistent memory (Record Store). Midlets may be switched between the states active, paused (waiting), and destroyed (finished and to be removed from the heap) with given methods.
193
Fig. 6-4 The build process for Midlets
Optionally, signed Midlets may be used. The signature allows to identify the source of the software and the integrity of the data, i.e. to verify that the software has not been tampered with. Signed midlets and the corresponding certifications work under the assumption, that the user is able to handle certificates and is able to draw reasonable conclusions. For regular users, this represents high expectations on the users abilities and willingness to bother with all of this (see PC downloads). However, when a limited number of credible sources can be configured in the right way, this will work quite nicely. Also the build process for generating and loading Midlets enforces some rules that a developer of applications needs to follow. Figure 6-4 shows a summary of the build process. On the left, the development process is shown. After passing the compiler and pre-verification of code, a Midlet is filed together with its resources (icons, data etc.) into a archive (JAR File). The archive also includes a formal description of the Midlet (the so called Manifest which is contained in a JAD file). The formal description includes information such as the name and source of the midlet, which environment it needs (such as MIDP version), and from what URL it may be loaded. The process shown on the right of Figure 6-4 allows to check the JAD file first before downloading a Midlet (JAR file). Following download, the Application Management System takes care if installation. Before execution of code, the code is checked by a runtime verification.
Strict conventions for development and download
6.1.3 Buffer overflows

Generally, programming environments provide far less protection than Java. For instance, while programming in C, a programmer will prompt for a user input (such as key "A" to chose from a menu or a user ID). The input is then transferred from the key buffer the to a string variable of a specified length
194
(such as 10 characters). If the programmer does not check the length of the user input, it may cause the program to crash during execution (e.g. by violating the address space assigned to the program). The compiler cannot provide protection or enforce rules. Even if the programmer uses functions from a library, he cannot be on the safe side (checks on buffers may not be implemented in the library function). There are other popular functions in C-libraries which work with unchecked string length.
Fig. 6-5 Buffer overflows
Variables and strings kept in the stack
Overwrite frame pointer causes address violations or execution of other code
What happens during execution of the program? We will need to have a look into how a processor keeps track of stack addresses. Figure 6-5 shows the principle of stack organisation for processors like the popular Intel x86 family. The stack of a process within the systems starts with a specific address in the physical memory. A subroutines called within the process will cause to push a frame for the variables of the subroutine on the stack. With each subroutine of stack frame, the stack is growing from lower addresses to higher addresses, i.e. it is growing deeper into the memory. The processor keeps a pointer to the actual position of the stack. It also keeps a frame pointer to the actual stack frame. The position of the previous stack frame is stored at this position and may be retrieved from there after the subroutine has finished (and is "popped" from the stack). As the subroutine executes, variables (such as the 10 character string from the example above) will be placed on the stack beginning with the position of the stack pointer. The frame is filled in the opposite direction of stack growth. If there have been 10 characters reserved for the string, and the user enters 11 characters, this will cause other fields to be overwritten. At execution time, there is no protection for overwriting the previous frame pointer (N-1 frame pointer in Figure 6-5). The processor will use this value to find the previous subroutine put on stack. If this value violates the address space of the process, the process will exit in an error condition (i.e. the program will crash). If the value retrieved from the frame pointer is a valid address for the process, the processor will simply execute the procedure that it points to. This can be misused to cause the execution of code, which provides more access to an attacker, or for the execution of malicious code smuggled in by an attacker. Such attacks tend to be extremely dangerous, if the process from where they
6.2 Common IP security issues
195
start have root-privileges or execute in kernel mode (such as drivers for a communication protocol).

6.2.1 Wireless network access
State of the art wireless networks are using a variety of mobile devices and access technologies. Figure 6-6 show an overview. Mobile clients include mobile phones, PDAs and Laptop computers. WLAN, Bluetooth, GSM/GPRS and increasingly UMTS provide the most popular wireless connections. The network infrastructure contains different domains: the personal network, local area networks, public networks operated by mobile network operators, as well as the Internet.
Fig. 6-6 Wireless network access
Also connected to the networks is a variety of IT Infrastructure: IT infrastructure operated by IT departments of large companies), IT infrastructure (servers, PCs, LAN, network access) of small and medium sized companies, who generally only can provide limited support for their IT Infrastructure, ISPs, Mobile Network Operators, Web Hosting Providers, Application Service Providers (who provide applications and manage IT infrastructure remotely), and Service Provider (Shops, Tickets, Banking etc.). The common denominator of this collection of devices and interests is IP: all is connected through an IP network.
Access to the Intranet over public networks
6.2.2 Security Issues with IP networks

When looking at security issues, the first logical step is to look at the threats. There are threats at a variety of levels. Local threats include theft (visitors, cleaning personal, mobile device stolen while travelling, ...), eavesdropping of
Threat
196
communication or passwords (can be very easily done if passwords are communicated over the mobile phone or typed into a laptop computer on a train or in a public place), operating systems not being safe (e.g. single tasking), interfaces not protected (e.g. WLAN without end-to-end encryption), as well as simply the way security is handled by the user (will he really learn 10 different good passwords by heart or just use one and the same simple password). Another critical issue caused by the user is to store company data or customer data on personal devices or use company devices in an unprotected environment (such as the company Laptop in the private and unprotected WLAN at home). Personal devices, which migrate in and out of a company intranet or another protected environment, always represent a critical security issue because they may carry either critical data or infections.
Fig. 6-7 Security issues with IP networks
Among the threats within the network are eavesdropping (there is someone listening and copying a communication stream), the man in the middle (there is someone in the line who is able to manipulate the communication link), Denial of Service attacks and Spam. All of this is very well known from the desktop environment and will now move in our pockets and follow us in our daily life with personal devices and personal networks. Together with the common threats on the network, there are the common threats on IT Infrastructure. Among the usual suspects are Active X-Controls, Cookies, Caches, Worms, Viruses, Trojan Horses, and backdoors introduced by WLAN and modems for remote access. In general, the handling IT infrastructure without clear guidelines for employees is a security issue already because it inevitably leads to privately installed modems (or WLAN or Bluetooth) which connect company PCs and protected infrastructure directly to the Internet. A threat needs both a security leak and someone willing to attack. So who is attacking? A major source of attacks are own employees and former employees (attacks from within the system). Others include hackers, vandals, IT Spies, IT Terrorists and professional criminals. Differentiation is relevant, because all have very different motives and different willingness to take risks.
197
What kind of attacks do we need to consider? Basically there are passive attacks and active attacks. Figure 6-8 shows an overview. The common scenario has Alice communicating over a network with Bob. Eve represents someone who is eavesdropping the communication, but does cannot not manipulate messages. Passive attacks include eavesdropping at hubs, bridges, and gateways in order to extract passwords, identities, confidential information etc. Also, traffic flows and usage patterns may be analysed: Who is communicating with whom in which way?
Living next door to Alice
Fig. 6-8 Passive attacks and active attacks
With progressing technology, passive attacks also have gone wireless: from wire tap to directional antenna. Whereas the old wire tap needs physical access and can be noticed (changes of impedance etc.), wireless attacks are far more effective. Radio can be monitored from large distances and can be easily done with increasingly wireless technologies such as WLAN, trunk radio, Bluetooth, IrDA or wireless keyboards. With more professional equipment, also electrical radiation may be monitored (e.g. radiation from computer monitors). Active attacks are a completely different and dangerous kind. In the common scenario shown in Figure 6-8, the active attacker is represented by Malory, the man in the middle. Active attacks comprise repeated or delayed responses (e.g. during login, which prompts the user to try his different passwords), insertion and deletion (manipulate communication or documents, e.g. by deleting the word not), modification (e.g. the amount on a bank account by a commercial transaction), boycott (Denial of Service, jam radio interface, ...), masquerade (steal an identity in order to get access), repudiation (deny having been part of a communication or transaction such as having bought that expensive watch at e-bay), or hijack a communication link following authentication. An extremely effective attack simply uses social engineering (e.g. an apparent call from your service provider we need your password, or a call to the service provider or IT manager I forgot my password, can you please help me).
The man in the middle
6.2.3 Security issues with wireless personal devices
198
The Internet in your pocket
All of the issues described within the paragraph 6.2.2 are not specific will proliferate from the desktop PC to mobile and wireless devices and thus much deeper into our daily life. Another group of security issues is actually been generated by an increasing use of wireless devices. As shown in Fig. 6-9, the networks in our environment connect us at home, at work, outdoors and basically any place. This wireless environment is able to notice us and to interact with us.
Fig. 6-9 From the desk to the pocket - security issues with personal networks
Always connected, everywhere
Among the increasingly relevant risks, which moves from the desk to the pocket, are software downloads to the mobile device. Basically, they represent the same hazards as on a desktop system, but an entirely new set of opportunities. Also, there is significantly more sensitive information send over the personal connections: Today, we organise our daily life on the move largely with telephone calls or SMS from the mobile set. Increasingly, we will organise work on the spot with software over alwayson connections running on the personal device. The issues are amplified by the facts, that a growing complexity of the environment facilitates attacks, and that SW-design tends to be sloppy. The user cannot be expected to bother with secure configurations, analysis threats and finding out a reasonably and safe way to handle this. Another big issue is privacy. Automation (e-commerce, m-commerce, pay back cards, RFID-tags etc.) transforms anonymous transactions to monitored transactions. Location based services, instant messaging services and proximity to sensors allow to trace users. Intelligent vehicle, intelligent office and intelligent homes allow to monitor user habits. There seems to be no apparent business model for privacy.
6.2.4
Demand on security
Technical solutions
Technical solutions can only increase security if they are usable and if they can be managed in a reasonable way. Also, technical solutions will need to be properly targeted to the security needs. While using public networks we rely on: the identity of the communication partner the integrity of messages and data
199
the availability of services the confidentiality of communications the commitment and non-repudiation of messages and transactions. Among the basic principles to fulfil those needs is controlled access (i.e. the proven concept of a town gate for the control of goods and traffic in and out). Technical policies based on the concept of access control will need to be combined with organisational policies in order to be effective. Another proven concept is a fortress or fortified system with inner walls and outer walls. The area in between (the demilitarised zone) may be given up in fighting an attack without loosing the complete system. The concept of encrypted messages and tunnels also has historical roots. Connections to exterior world and to dependencies now translate to application layer encryption and layer 2 or 3 tunnels. The technical solutions can be summarized as a combination of systems architecture (such as access control, firewalls) and encryption (secure transmission, secrets to prove identities, signed documents). The related organisational solutions include the definition of roles and responsibilities for users and operators, the definition of roles for the central IT administration (or a corresponding service provider), policies, recommendations for products and regular security audits.
Controlled access
Protective measures
There are protective measures at the planning phase, as well as during operation and runtime. Protective measures during planning and organisation include: - analysis which devices and data to be protected - analysis of existing IT-infrastructure, incl. the environment, boundary conditions, and policies - analysis of threats, weak links and risks - definition of a security policy incl. partner companies - definition of roles and responsibilities - selection of security mechanisms and products - technical and organisational implementation of the security policy - utilise interfaces, mechanisms, services, protocols and algorithms - run validation, penetration-tests, evaluations and audits. Protective measures during operation and runtime include: - Run an intrusion detection system - Maintain and analyse log files - Run periodical security audits - Run SW updates (systems, applications, virus scanner) - Provide a written emergency plan and plan for escalation - Train employees and operators incl. new technologies - Inform users, support and train them appropriately. Figure 6-10 shows a state of the art firewall configuration including a demilitarised zone. There are three protective layers, which will need to be overcome by an intruder: the outer firewall, the proxy (bastion host) and the inner
Defence systems
200
firewall. The demilitarised zone does not contain any original data, so it may be sacrificed in a serious attack without loss of data. Also, the inner network may be de-coupled from the Internet for a period of time.
Fig. 6-10 Protective measures: firewall configuration
Intrusion detection
Safe door locks and firewalls are a good protection, but if there are values to protect, an alarm system makes sense. Intrusion detection systems (IDS) recognise typical patterns of attacks (e.g. port scans, unusual changes in traffic, topologically wrong addresses). Also, an IDS logs attacks and generates security alerts at specific thresholds. Sensors for an IDS may be located at the outside firewall (to detect first attacks), within the DMZ (to detect a breach of the outside firewall), within the private network (to detect successful attacks from outside and attacks from within). However, alerts without analysis and without response are useless. As with any protective system, there are limits to firewalls. Firewalls are not sufficient at all, because they provide no protection from attacks within the network. They only protect from known attacks, which are represented in the rules and configuration of the firewall. A firewall does not provide protection from back doors (modems, WLAN, ...) and may be by-passed by Notebook PCs, which migrate in and out of the private network and may carry infections and confidential data. In cases where the attacker cooperates with machines inside the network (e.g. by encrypted remote access), firewalls are entirely useless. In the most common case of running an Internet browser through HTTP port 80, a firewall does not protect from any malicious code that a user catches this way, or by malicious code entering via e-mail.
Cryptographic components
Symmetric and asymmetric encryption
What are the cryptographic components used in state-of-the art security solutions? Basically, there are keys (secrets) used for encryption. Symmetric encryption provides effective algorithms, but the key management is not effective. Symmetric procedures use the same key for encryption and decryption. With N-partners, this requires handling of N2 keys (more exactly N*(N-1)/2). Asymmetric procedures only require 2N keys. Thus, asymmetric encryption provides effective key management, but the algorithms are not efficient. In
201
practice, both methods are used in combination: asymmetric encryption is used to generate and distribute a symmetric session key. Figure 6-11 shows the use of private keys and public keys.
Fig. 6-11 Keys and Encryption
In the common scenario for communication, the channel may be eavesdropped, as shown in Figure 6-12. Cryptoanalysis is about breaking the encryption. Encryption works by confusion (e.g. substitution), diffusion (e.g. transposition) and the avalanche effect (changing one bit within the plain text of key results in changes of 50% of bits of ciphered text). Hash Functions provide fixed length signatures. Among the most relevant standards for symmetrical encryption are: DES (Data Encryption Standard) AES (Advanced Encryption Standard) RC4 (stream cipher, i.e. using stream of a pseudo random generator which is started by a key as initial value for XOR operation with plain text; e.g. used with GSM and WLAN)
Crypto-analysis is about breaking encryption
Fig. 6-12 Encryption used in a communication link
Because DES is an older technology (published in 1974 and declared an ANSI standard in 1977), the basic standard is only using a key length of 56 bits. This may be improved by applying the three times (triple-DES of 3DES). Figure 6-13 shows the basic function of DES encryption with 2 or 3 keys. Be-
202
cause the procedure in the middle is an inverse DES, a triple-DES encoder can also perform single DES by using just one key. Figure 6-14 shows the principle of the stream cipher algorithms RC4.
Fig. 6-13 Encryption with Triple DES
The most relevant standard for asymmetric encryption is RSA (named after its inventors Rivest, Shamir, and Adleman). It encrypts and decrypts blocks of data.
Fig. 6-14 Encryption with RC4
Another important concept of cryptography is hash functions. A hash function (also called a message digest) generates a unique fixed length output to an input message, which does not allow to reconstruct the input message and changes if the input is modified. The hash function of a message or a document thus serves as a signature or identifier. The usage of an input message in combination with a key allows identifying the sender and proof of integrity of the message (this is called message authentication code). Among the most popular hash algorithms are MD5, SHA-1, and RIPE-DM-160
Secure connections
Tunnels and safe roads
In order to communicate over unsecure or public resources, tunnels or endto-end encryption are used. Among the most popular state-of-the art solutions are secure sockets and IPSec. Secure connections allow building virtual priva-
203
te networks, i.e. to connect own infrastructure over public networks. All solutions build on the Internet protocol stack, which is shown in Figure 6-15.
Fig. 6-15 Summary of IP related protocols
Secure Sockets originate with Netscape and are available with any contemporary Internet Browser. They support confidentiality, authenticity and integrity between hosts (end-to-end security between client and server). Secure Sockets are a framework protocol including SSL handshaking to negotiate keys, host authentication, and encryption algorithm and message integrity. Figure 6-16 shows an overview. Normally a specific TCP-port is used (e.g. port 443) for HTTP over SSL, which needs to be configured in firewalls. Secure socket connections are visible within the browser as https in URLs (instead of http). With end-to-end encryption, proxies in the path are unable to control packets, but are only able to monitor sources and destinations.
Transport layer security
Fig. 6-16 Secure Sockets (SSL)
Another popular solution is IPSec. IPSec works on the IP layer and thus is much more universal than SSL (for instance it may include UDP messages which carry voice calls). The most relevant concepts with IPSec are the Authentication Header (AH) protocol and Encapsulated Security Payload (ESP) protocol, which provide transport mode (encryption of payload) and tunnel mode (encryption of com-
IP layer security
204
plete IP packets). Both are based on common key exchange and management. ESP is particularly relevant for VPN tunnels. Figure 6-17 shows an example of an ESP encoded packet.
Fig. 6-17 IPSec
Virtual private networks are private networks embedded within public networks and interconnected through public networks. The VPN has its own addresses and secrets, but uses public network infrastructure and thus represents a virtual network.
Fig. 6-18 IP-VPNs
As shown in Figure 6-18, basic VPN applications include: Remote Access (RAS): remote connections to the company network or central resources via telephone line, cable modem, WLAN, UMTS etc. This requires strong authentication by smart card or RAS token to generate the VPN tunnel, rather than the usual combination of User-ID and password. Intranet: connects different branches and locations of a company over public resources. Extranet: connects suppliers or customers (e.g. in the car industry) and requires separation of competing parties from each other.
6.2.5 Procedures to address security issues

Finding an appropriate solution
Security is very much about finding the right solution which will fix the security needs and is acceptable in terms of usability and lack of convenience
205
(the trade-offs). A systematic approach to apply security can be summarized in the following steps (from [Schnei03]): Step 1: What assets are to protect? Step 2: What are the risks to those assets? Step 3: How well does the security solution mitigate these risks? Step 4: What other risks does the security solution cause? Step 5: What costs and trade-offs does the security solution impose? In practice, it is important to consider all parties who are involved in the process and to note, that all parties have different and conflicting agendas. Fig 619 summarizes the parties and agendas involved in a typical telecommunication solution. The most obvious parties are the user and the content provider or commercial company, which utilises the network for business. Those parties have entirely conflicting interest. The user expects to be protected from attacks, viruses and worms. He expects a correct and fair accounting practice, end-to-end security to keep communication confidential. He also expects transactions to stay anonymous. Anonymity and confidentiality directly conflicts with the interests of a content provider or any business running over the network: they want to know there customer as exactly as possible (e.g. they like location information, usage patterns, spending habits etc.). Also their business demands the maintenance of digital rights and limits to illegal copies.
Conflicting interests
Fig. 6-19 Different parties have different agendas
The other parties involved in a communication solution are the network operator, his suppliers of network infrastructure, service providers and the government. Network operators demand cost effective solutions for infrastructure and operation of infrastructure. Thus, they like standards and like security to be kept at the same level as it has been with telephone lines. Infrastructure suppliers also need standards to keep costs low and have their products interoperate with products from other suppliers. They dont mind expenditures for security solutions if they can sell them. Service providers will
206
Each party needs to contribute
need the infrastructure to enable exact accounting and a high level of service availability. Governments like control to provide security and generally favour seamless surveillance. Any network solution will need to fit into this general context. What do the individual parties contribute to security? In order to have a working solution, each party will need to be involved. Network operators can provide secure routing to the CPE (customer premise equipment), secure service provisioning and network administration, secure roaming-connections, as well as fraud detection and fraud management. Service providers may provide secure service provisioning and encrypted billing records. Content providers may provide copyright protection (DRM digital rights management, e.g. water marks for video and audio). The user will need to take care of protection for the terminal device and of end-to-end security (for instance by deploying an IP-VPN). If all of this looks too complicated, some tasks may be outsourced to a specialist. If planning appears too complicated, engaging a consultant may be an option. If operation appears too complicated, e.g. management of an IP-VPN may be outsourced. However, it may be wise to keep core security management within the own organisation, such as the generation, distribution and replacement of keys (key management).
6.3 Identity
6.3.1 Identity, Authentication and Authorisation
In search of our identity
Apart from the philosophical view of identity, the identity of a communicating party is a tangible and important concept. A communication party may be a user of a system, an application called by a user, or interacting services on distributed systems (such as Web-Services). The identities of each party should be verified before valuable data are exchanged. But what is the identity of a communicating subject? A formal definition could be: a set of identifiers associated with an entity. However, for a human entity (a person), there are several realms of identity: identity as an employee (relative to employer, co-workers, customers ) identity as a citizen (voting, driving, taxes, ) identity as a consumer (supermarket, doctor, Amazon, ) identity as a parent or relative (spouse, children, neighbours, friends, clubs, )
Different levels of identification
The identity comprises usage preferences such as preferred language, airline seating preferences, medical history, etc. What the identifiers associated with a communication entity are, depends on the view that a communication partner has: Communication network operator: who pays for the service? Marketing: binding of different usage profiles to a specific person Government: map all communication on different channels onto individu-
6.3 Identity
207
als. In the situation of a service provider or a network operator it is basically irrelevant who in a family used the service as long as the bill is paid. The calling line identity is sufficient to prepare the bill. In the case of supervision of a suspect, the government uses the personal identity of the suspect to extend the view beyond the communication on specific networks as fixed or mobile lines. Identity is closely related to the question of authenticity of communication. The communication partners who want to establish a secure communication path need to provide a proof of identity to each other. Figure 6-20 helps to explain identity in the context of authentication and authorisation with a scenario from every day life.
Authentication: proof of identity
Fig. 6-20 Identity, Authentication and Authorisation
At customs control or at the ticket counter, an authentication of people is used to only let pass individuals which are allowed in, or to hand an airline ticket only to the right individual (who has booked the flight and paid for it). The regular procedure is to match the person at the counter with an identity document (identity card, passport). This is done manually by the person behind the counter by matching the visible biometrical features of the person in front with the picture on the identity document. On online system which shows the same picture from a database when entered the name or identity number on the identity card further improves authentication. Authorisation is a subsequent, but entirely separate procedure. The airline ticket handed by the authenticating employee (the authentication authority) authorises the boarding of the aircraft. The people who control access to the aircraft at the gate based on this ticket thus only represent an authorisation authority (they will check the identity of the ticket, not the identity of the person). To summarize: authentication represents an identity check (is it you?), authorisation represents a check of rights or privileges (are you allowed to do this?). Again, matching identities for a ticket or token can be used for authorisation. A ticket inspection in a train or metro certainly does not validate the identity of passengers, but validates tickets (even if a one year ticket carries a photograph of the ticket holder in order to make it non transferable).
Authorisation: having the right to do something
208
Authentication based on credentials (to know. to have, to be)
There are different kinds of authentication. One-factor authentication means: relevant is what you know (username, password). Two-factor authentication checks what you know and what you have. i.e. in addition to knowledge of a PIN a physical document issued by a trusted authority or the possession of a secure device is required. Several layers are relevant: the device layer: MAC addresses or IMEI identify the equipment used the personal identity: individual access to services the role of an individual An authorization profile is assigned to each layer, i.e. a set of rights to use. On the device layer, WLAN security policies can include MAC address filters to permit access to the network only for registered equipment. This scheme, however, cannot prevent from misuse of registered equipment. Figure 6-21 shows how identity based concepts are handled in a network. The key words here are credentials, stored identities and profiles. Authentication and authorisation represent processes in this environment.
Devices and roles
Fig. 6-21 Identity in networks basic concepts
Circle of trust
Identity provider
Checking of individual login data (typically as username and password) is crucial for all service providers. Several individuals create a group that can share the same set of authorizations, e.g. all operators or the service personnel. In any case, their individual identity is required for detailed log files. The identity of a user can be verified by an organization and then asserted to another one. If both parties trust the third party, the identifying party that issues certificates on the identity of the user, then the third party is called a trust center. The Liberty Alliance defines network identity as the overall global set of attributes constituting the various accounts of an individual. This means a twostep procedure: first authenticate the requesting user (called the principal), then assign it to the already stored account profile. Figure 6-22 shows the se-
6.3 Identity
209
paration of authentication (done by an identity provider), and service providers, who rely the assertion of identity from the ID provider. In order to make this distribution of roles work, ID providers and service providers need to trust each other.
Fig. 6-22 Identity - roles and environment
How can the identity of a communication partner be checked online? All the mechanisms to identify a human partner, e.g. recognition of the face, the voice, the behaviour, reactions to a challenge, etc. fail in this case, or better: need to be formalized in the form of a protocol that exchanges proofs of the identity. The handling of the so called credentials in a network is described in section 6.3.4. Identification is the creation of an association between the subject, in Liberty terms the principal, and its identity. Identity federation means in effect the out-sourcing of the identification to an identity provider, i.e. agreements, standards, technologies that make identity and entitlements portable across autonomous domains. Since a trust relation between the acting entities is required, all entities belong to a circle of trust. Identity federation creates new risks: when service providers rely on external parties for identity assertions, forensics must span domain boundaries. The transitive trust used in a federation enables cross-over attacks. On the other hand, identification can be done by the most responsible party and the parties are less reliant on a large scale, centralised security infrastructure.
Identity checks
Identity federation
6.3.2 Implications on Accounting

It is in the interest of all involved parties to clearly identify the account to be billed. The subscriber wants to be sure that no one else can create charges to his account. He cannot check the bill without keeping notes of all communication and comparing them with a detailed bill. This creates undesirable privacy problems. The service provider or network provider needs to reduce the effect of fraud and wants to establish trust in the billing procedures. If the subscriber is not known to the service provider, the identity needs to be assured by the operator of the home network. This is for instance important for mobile networks: roaming agreements between mobile network operators allow the world-wide authentication and billing of subscribers.
Roaming agreements
210
IP networks will need to deploy a similar solution. The user identity needs to carry an indication of the organisation that issued the proof of identity (smart card, certificate, etc.). A trust relation between the service provider and the identity provider is the commercial basis for IP mobility.
6.3.3 Security and Privacy Requirements

In fixed networks, calls are established between lines. Nobody cares who actually placed the call from this line and to whom he talked to. In mobile networks the mobile equipment and the subscribers carry individual identities (the IMEI and the IMSI). This allows the binding of the subscriber identity to the IMSI, regardless of the equipment used. Tracing of the location and communication of a subscriber allows the creation of a location traces and usage profiles. In GSM networks, the subscriber identity is communicated only in the initial procedure of attachment to the network. From then on a temporary identity is used, the TMSI, which is assigned by the mobile switch and does not allow the attacker to identify and follow a victim. Storage of all communication attempts permits verifiable individual bills, but creates a loss privacy for the sake of security. A limited timeframe for the storage may help, but cannot be enforced, nor checked by the subscriber. In the Web, the identity of a user is known to the Internet Service Provider due to the login procedure. The owner of a address can be found from the DENIC data base. In ad-hoc networks, nobody knows the identity of the partners, unless it is verified by an identity provider. In the context of federated identity, the procedure of attributes exchange between Identity Provider and Service Provider still is not very clear. It is supposed that the Identity Provider transfers info to the Service Provider, but not vice versa. How the privacy policy can be enforced remains an open issue. The procedures used to manage the identities of entities are known as Identity Management, which is a set of processes and a supporting infrastructure for the creation, maintenance, and use of identities and their attributes, credentials, and entitlements. Identity management includes: user management - creation and maintenance of user accounts and rights - categorization of users by roles and groups - central provisioning and administration tools authentication - verifies identity by challenges - username/password, PIN, token, digital certificates, biometrics access management - determine rights and privileges using a policy This scheme is in use for years in the enterprise identity management to simplify the administration. In business to business applications, SAML (the Security Assertion Markup Language) represents a concept to help organise large networks of suppliers, manufacturers, and sales organisations as an element in building extranets from collaborating applications. In the scenario of public identity, the concept of identity federation comes in. The token returned in the
Location profiles and usage profiles
Privacy policies
Identity management
6.3 Identity
211
identification process can be passed to other Web sites, without requiring the user to log-in again. Figure 6-23 shows the SAML based scheme used by the Liberty Alliance Framework.
Fig. 6-23 Identity Management use of SAML in the Liberty Alliance Framework
SAML basically represents the format for tokens. SAML tokens may be used for authentication assertions, assertions of any specific attributes or as tokens for authorisation. An SAML token may be transferred in a protected way (i.e. encrypted, including identification of the source of the token and protected against tampering). The framework shown in Figure 6-23 also includes policies and possible sequences (for instance authentication before authorisation or assertion of attributes). Identity management has many aspects. In enterprises, the main emphasis still is on internal consolidation, e.g. on customer-relationship management and on integrating different access channels such as phone and Internet for customers, or Internet and internal systems for employees. In the privacy-research community, the emphasis is on enabling people to manage their identities themselves including free choice of pseudonyms. It also includes the transfer of credentials from one pseudonym to another pseudonym of the same person, and appropriate user interfaces. The gap between these aspects is wide. Two real co-operating federation members will require the users name and address and relatively strong identification and will not be easily persuaded out of this demand. The user has no choice but to have confidence that they do not exchange undesired information about him. In other words, the user has to trust these organisations explicit or unwritten privacy policies. The privacy provided by a single-sign-on protocol like the Liberty Alliance Framework can be investigated in two areas: First, to make sure that the privacy policies and implications are clearly specified. This is a purely technical goal. Second, to find out whether these policies, including the given user options, are appropriate for the stated purpose.
Security Assertion Markup Language
Pseudonyms
Single sign-on
212
Biometrical data
As a general rule, personal data has to be confined to the realm where it is strictly required. Two aspects of privacy can be distinguished: passive privacy versus active privacy. Passive means, that users pass their identity to a target and rely on the targets privacy policy. Active means that users release only these attributes to the target which are appropriate and necessary, i.e. the user has a choice which attributes are released. The widespread use of bio-metrical data is a data privacy problem in its own: miscellaneous commercial companies handle and store invariable personal data that are today restricted to the use by law enforcement agencies. Network Identity provides identity information that is context-sensitive and governed by usage protocols. This eliminates duplication of information and preserves identity privacy in a trusted and secure environment. Privacy is even good for security, because non-identifiable records reduce the vulnerability to hackers and authorised insiders.
6.3.4 Credentials
Handling credentials
Authentication means verifying credentials presented by the service requestor. Commonly used credentials issued by trusted authorities are passports, drivers licenses authorising the use of specific vehicles, national ID cards, company cards, etc. The most obvious and often used mechanism for authentication is the check of knowledge of a username and password combination. Appropriate procedures must ensure the secure transfer of the credentials, the secure storage in the directory service, and the frequent renewal of the password. One of the major problems is the number of different username/password combinations that are necessary for different services and access networks. Instead of remembering a dozen of passwords, they are usually written down in a notebook or in a PDA. In both cases, they are not stored in a safe place. The solution for this situation are the so called single sign-on systems. They even ease the job of central user administration. As already shown in Figure 6-21, there are three categories of credentials: to have, to know, and to be. At least two credentials of these three categories should be presented for verification: the possession of specific equipment (e.g. an identification card), the knowledge of a secret (e.g. the PIN necessary to activate the card), and biological characteristics to bind the identity to a person. Typical biometrical characteristics are the image of the face, voice prints, fingerprints, or the shape of a hand, iris pattern, and retina pattern. Secrets like passwords should be changed periodically in order to limit the timeframe for successful attacks. The drawback of biometrics is, that these characteristics are invariable. This makes biomedical characteristics are a bad choice for secrets or passwords (for keys in general). Other drawbacks are the relatively expensive equipment, the reluctance of users, and the moderate precision. Figure 6-24 shows the typical credentials presented for network access and for services in the network.
Secure transfer and storage of credentials
The limited life of secrets
6.3 Identity
213
Fig. 6-24 Credentials used for network access and services
Username/password combinations are the most common credentials for network access and service log-in. The secret is stored in a directory (LDAP) and checked in the authentication protocol running on the ID server. A similar authentication procedure can be build on authentication using a hard token which can be checked by a token server. In this case, the possession of the hard token is required. The hard token contains a secret key and a clock is required. In addition, the token is activated by entering a PIN. The token creates a one-time password that is based on the stored secret key, the PIN, and the current time. The one-time password has an expiration time of one minute. In all configurations the credentials presented by the requestor are checked against stored references.
Username and password
Tokens
A sample implemention
Centralised architectures rely on central servers which store the secret that is shared between the user and the service. Figure 6-25 shows the typical configuration with a centralised authentication and an identity federation.
Fig. 6-25 A centralized architecture for handling credentials
214
SIM authentication
Any kind of credentials
Username/password combinations are compared against the stored values of a directory service. Depending on the authentication algorithm used, either hash values calculated from the passwords are stored or the passwords are stored in plain text. In the latter case, the directory service, which is the key element for the access security, is of special interest as target of attacks. A different approach is to transfer the identity of a mobile network subscriber into a new context: the Subscriber Identity Module (SIM) which is used for the subscriber authentication in a mobile network can also be for authentication in the Web. In fact it works like a hard token already. The user opens the SIM by entering a secret PIN. The ID server now requests the IMSI from the SIM, then asks the Home Location Register HLR of the mobile network for a challenge to the SIM and for the expected answer to it. It passes the challenge to the SIM, which responds with the calculated result that is based on the same common secret that was used in the HLR to calculate the expected answer. If the answers match, the user is authenticated by the HLR. This configuration benefits from the widespread use of mobile terminals and from the secure storage of the secret key. The sample implementation shown in Figure 6-25 also supports hard tokens. The one-time-password generated in the hard token is verified in the token server which has all secret keys of the users stored. Other means for presenting evidence of the identity could be based on certificates and use SSL (secure socket layer) or TLS (transport layer security) as authenticating protocols. The schemes are very different in providing mechanisms which allow to minimise the compromise of credentials: credential renewal (periodic change of passwords), client side key generation, and in the mechanism to store and protect the credentials in a safe place. The lower half of Figure 6-26 contains the paths of the identity federation functionality. The identity server checks the credentials presented by the requestor and passes back a token (SAML token). This token is used by the service provider to request from the identity provider a security assertion indicating the identity of the user and the credentials and algorithms used for the authentication.
6.4 Web Services Security

... SAML
7.1 Part One (Chapters 1, 3, and 6)
215
7 Exercises
Exercises are organised in two different levels with different dephts: Part one provides a basic level of exercises. For part one, lecture of chapter 1 (networks), chapter 3 (distribution) and chapter 6 (security) is sufficient. Part two of the exercises covers the whole book including the remaining chapters and requires a deeper level of expertise.

7.1.1 System Availability
An experimental system (file server) has an availability of 80%, i.e. the average down time is 20%. In order to improve the system availability, it is foreseen to replicate the the data on a system of the same kind and to operate both in parallel. File Server 2 System
File Server 1
Question 1.1: What is the over all system availability after this measure? Question 1.2: Systems in telecommunication networks are called carrier grade if their availability is better than 99,999%, i.e. their downtime is below one hour per year. In order to achieve this figure, how big needs the availability of a single server to be in the replicated configuration shown above?
7.1.2 Mobile Terminating Call

When calling a mobile subscriber, the network elements communicate with each other according to the scenario as shown in the figure. A mobile network operator is estimating the number of transactions and volume of data which is used for this procedure. Such an estimation represents a foundation for the basdimensioning of the network elements. For his network, the network operator is using the following assumptions: - 50 million subscribers
216
7 Exercises
- 2 transactions per subscriber per hour (i.e. about 2 calls per hour) - 1 kByte of data per message - 50 ms latency (delay) for looking up the requested information within a HLR or VLR One transaction in the scenario below corresponds to the provisioning of the subscriber location for a mobile terminating call (i.e. a call that terminates in the mobile network). The number of messages which are exchanged between the network elements depend on the type of scenario. ...
BSS
VMSC/VLR
HLR
GMSC call set up
Exchange
Transaction Request Provide Roaming Number
Request Send Routing Info
Response Provide Roaming Number Response Send Routing Info
call set up
paging
Question 2.1: Calculate the total number of transactions in the network: total number of transactions per second Question 2.2: Calculate for the scenario shown in the figure: - the total number of messages per second - the total volume of data which is exchanged per second - the average duration of a transaction (from GMSC request to the response received by the GMSC) Question 2.3: Looking up of information from the VLR is only required, if the subscriber is not present in his home location (in this case, the HLR keeps the routing information). By the assumption, that on average 80% of subscribers are located in their home location, the figures calculated in questions 2.2 should improve. Calculate: - the total number of messages per second - the total volume of data which is exchanged per second - the average duration of a transaction (from GMSC request to the response received by the GMSC. Question 2.4: The network operator plans to implement HLR and VLR in one single network element. Such an implemenmtation promises to im-
217
prove performance and protentially to reduce cost. Calculate for a combined HLR/VLR: - the total number of messages per second - the total volume of data which is exchanged per second - the average duration of a transaction (from GMSC request to the response received by the GMSC). Question 2.5: Compare the solutions of questions 2.2, 2.3 and 2.4 concerning benefits, drawbacks and obvious difficulties in implementation. Question 2.6: The messages of the original scenario as shown in the figure need to be transferred over communication channels. (1) For a channel with a bitrate of 64 kbits/s, calculate the additional latency which is introduced by this bitrate for one transaction. (2) By which measure could this latency eventually be reduced while maintaining the bitrate? (3) What improvement can be achieved by using faster channels with a bitrate of 10 Mbits/s?
7.1.3 Virtual HLR/VLR

It is planned to implement the combined HLR/VLR described in exercise 2 as one virtual HLR/VLR according to the configuration which is shown below.
virtual HLR/VLR
Storage System Back-End Processors IP Network
GMSC MSC
BSS
Among the components of theconfiguration are a central storage system and 10 back end processors which are running the HLR/VLR application. The
218
7 Exercises
back end processors operate in load sharing. The network operator plans to use low-proced equipment for the back-end processors with an availbility of 99,9% per processor. The virtual HLR/VLR connects to the GMSC by an IP based interface. Thus, the GMSC represents a bridge between the traditional networks and the new network element virtual HLR/VLR. Question 3.1: Calculate by using the data indicated in exercise 2 the throughput (requests and data base inquiries) per system (per back-end processor): - Transactions per second - Data throughput per second. Question 3.2: Calculate the availability of the overall system. Question 3.3: It is planned that the storage system should alsocontain the complete subscriber data records and provide access to these data sets to administrative systems and operational systems. One subscriber record is 5 kBytes. The same record also contains the routing information which is maintained by the virtual HLR/VLR. Calculate the overall capacity of the data storage and the proportiopn of the amount of data which is moving through the network by transactions. a - total amount of data to be stored - amount if data moving in the network (per second) - proportion of moving data (per second) of stored data.
7.1.4 Data Traffic in Wide Area Networks (WAN)

For the model network from exercise 2, the volume of user data which is to be transferred over the network is to be calculated. The following assumptions are taken (as in exercise 2): - 50 million users (subscribers) - 2 transactions per user per hour. Transactions are detailed as follows: - 40% telephon calls of 100 seconds each and a continous flow of data at 64 kbits/s data rate - 40% SMS of 200 bytes data volume per SMS - 20% MMS repectively e-mail with 200 kBytes of data each. The network is organised in 16 areas of supply (regions). The regions are organised in groups of 4: the traffic of 4 regions is collected and distributed by
219
one wide are network node. Wide area nodes are fully meshed. The configuration is shown in the figure below.
Wide Area Node
1
Regional Node
Question 4.1: How large is the average amount of data per transaction which is produced by a user (subscriber)? Question 4.2: How large is an average the amount of data per second which is generated by one user (subscriber)? Question 4.3: Consider the network shown in the figure as a closed system and calculate the bi-directional flow of traffic (bits/s) at the interface (1) from regional node to wide area node, as well as at the interface (2) between the wide area nodes. It is assumed, that subscribers are equally distributed over all regions. - average traffic at interface (1) - average traffic at interface (2). Question 4.4: The distance between the network elements of interface (1) (i.e. between regional node and wide area node) is assumed to be 100 km. The distance between the wide are nodes is assumed to be 1000 km. A further assumption is that signals travel at a speed of 300000 km/h. Calculate the total amount of data which is stored in the network by travelling between the network elements. Question 4.5: Each node on the network causes a delay of 10 ms by processing of messages (storage and forward routing). Calculate the amount of data wich is stored in the network within the nodes.
7.1.5 Mobility
220
7 Exercises
A mobile network operator plans to build a network as shown in the figure. In this network, Alice may send a message to bob by addressing the message to 32-17. where 32 represents the address of the network node 32, and 17 repressents the device address of Bobs terminal set.
Alice
Ports A
Node
1
B
D C
2
Name Server
4 41 43 31
A
3
B
33
32
Location Area
17
Bob
Question 5.1: The nodes hace ports and contain routing tables to forward messages. Some ports are indicated in the figure. Supplement the routing tables of node 1 and of node 3: - Node 1: Destination : Port Number - . .......................4 .....: ........ B .......... - .........................3......: ...................... - Node 3: Destination : Port Number - . ......................31 ... : ..................... - ....................... 32 ... : ..................... Question 5.2: Node 32 contains the device address of Bobs terminal set, which is needed to deliver messages. Each time a new location area is detected, the device address is entered in the corresponding node on initiative of the terminal set. Bob travels to location are 43. (1) What is changing by moving to area 43? (2) Delivering messages this way to roaming users has one problem What exactly is this problem? Question 5.3: The network operator plans to solve the problem indicated in question 5.3 by introducing a Name Server, which is able to resolve names into network addresses. The Name Server is accessible to every network node. Entries in the Name Server are updated each time a subsciber has been moving with the valid location area. Supplement the entries in
221
the directory of the name server: : - (1) Bob is in Location Area 32: Name : Adresse - ..................................................... Bob : ............. - (2) Bob is in Location Area 43: Name : Adresse - ......................................................Bob : ............ Question 5.4: (1) How does Alice benefit from this type of addressing messages? (2) Which drawback has the simple concept of name resolution for a large network with thousands of subscribers? (3) Indicate some options to uniquely identify subscribers. Question 5.5: A planning engineer discovers a flow in the current network design. Because there is no storage for messages, messages are lost when terminal devices are switched off. The marketing department assumes that terminal devices get switched off and are off 20% of time, so that this issue needs to be tackled. The introduction of a storage system for messages is proposed. The storage system is supposed to be introduced as a new network element which is accessible from every other network element. Explain a concept for storage and delivery of messages to terminal devices (i.e. when are messages to be stored, when are messages to be deliverd, what initiates delivery). Question 5.6: The security specialist of the network operator discovers the following flaws in the current network design. A terminal set could be manipulated to present Bobs address. Thus, a someone might get access to Bobs messages or send messages on Bobs account. Also, a foreign network element could pretend to be a vaild regional node, register Bobs terminal and thus be in the communication line. Describe some counter measures which help to prevent such manipulations.
7.1.6 Location based Services

A manufacturer of city giudes and city maps enters the business of providing location based services to mobile subscribers. For the provision of such services, the mobile network operator provides a system with an interface, which allows to request the location of mobile subscribers. The Service Provider is using this interface to request coordinates. Further, the Service Provider uses a Geo-Information System (GIS), which contains maps with local information. On request by the mobile subscriber, the Service Provider combines coordinates and a map of the corresponding local environment and transmits it to the mobile subscriber. The principle is shown in the figure. Question 6.1: In the procedure described in the figure, the mobile network operator provides user identifiers (User IDs) to the service provider and to the service users. Thus, the service provider is in a position to know the location of service users and to generate migration patterns. (1) What benefit may the user get as a result from this knowledge? (2) Which disadvantages may occur to the user by this knowledge?
222
7 Exercises
Alice
Mobile Network Operator
whereIs(UserID)? you are here
Request: getLocation(UserID)
Response: coordinates(UserID)
GIS
Location Service Provider
Question 6.2: Describe a procedure, which makes the relation between user and service provider an anonymous one by using pseudonyms as UserIDs.
7.1.7 Distributed Computing

Within a system, objects may be found and utilised by their object references within the address space of a process. When distributing objects between systems, object references are also required to locate and use remote objects. System 2 System System 1 Stack Heap
Object Reference
Middleware
Middleware
Object Reference Question 7.1: What is required in order to reference a remote object? O Network address of the remote system O Serial number of the remote system. O Communication end points (port and network protocol) O Object Name
223
System 1 y=f1(a,b)
System 2
y=f1(a,b)
f1: type a : type b : type
f1: type a : type b : type
Middleware
Question 7.2: System 1 would like to invoke a method from a remote object. To do this, the middleware in each system (see figure) takes care about packaging and translation of the request for remote method invokation What exactly needs to be defined by the middleware for the exchange of messages between the systems (pls. mark items of the list): O Formats of messages exchanged O Data types of messages and message elements O Layer within the OSI-Reference Model. Question 7.3: The figure of questrion 7.2 above only shows the request of a method invokaktion for a method with name f1() and the parameters a,b. Supplement the response of system 2, which implements the corresponding method and returns y=f1(a,b) in the figure below. System 1 y=f1(a,b) System 2
y=f1(a,b)
Middleware
7.1.8 Service Inventory

A mobile network operator plans to generate a plattform for any kind of services based on his network infrastructure. To do this, he makes a Service Inventory available to all service providers and service users. Service providers may use the Service Inventory to publish object references to their services with unique identifiers (UUIDs). The object references point to the servers, which actually provide the service. The mobile network operator only provi-
224
7 Exercises
des the inventory for the services. Users may generate refernences to the Service Invontory in their mobile sets. The figure shows the relations between entries in the mobile set (personal name space), inventory numbers and object references (Service Inventory).
Alice Mobile Network Operator Service Provider
request object ref.

Personal Namespace Service Inventory
publish object ref.

Service
Bob Music Chess Car ... ...
UUID1 UUID2 UUID3 UUID4
UUID1 UUID2 UUID3 UUID4
ObRf1 ObRf2 ObRf3 ObRf4
ObRf3
Service Logic (Chess Game with Charly)
Question 8.1: A service provider uses as object references the connectors of the Generic Connection Framework of the Java 2 Micro Edition (J2ME GCF). This kind of object reference includes network address, protocol, ports and object name in a generalised way into one string, which is handed as a parameter to a method, which opens a connection:
Connector.open("<Protocol>:<Address>;<Parameters>")
Some examples for the usage of the GCF connector:

(1) Connector.open("http://www.dpunkt.de") (2) Connector.open("socket://162.234.100.200:8090") (3) Connector.open("comm:0;baudrate=9600") (4) Connector.open("file:/hiScore.dat") (5) Connector.open("phone:/+4917123456789")
Which of the examples from the list point to local references (pls. include a short explanation)? Question 8.2 Another service provider is offering services based on WebServices. What would this service provider use as object reference? Question 8.3: One of the service providers offers remote chess as service. Alice and Bob may deposit their game of chess at a given UUID. The server of the service provider keeps track of the game and whos turn it is. The mobile sets need a specific client application which matches the server application. Name some of the ways to provide such client applications for users. Question 8.4: The local pharmacies would like to use the Inventory Server by entering a reference to the homepage of the respective pharmacy,
225
which is on duty over night and during week-ends. Describe, how this project may be implemented.
7.1.9 Name, Address and Identity

Name N Entity M Address Question 9: Describe the relations shown in the figure and give some examples for adresses and identities for users of mobile networks, users of regular telephone networks and web domains.
Identity
7.1.10 Name Spaces

Name spaces may be represented as labelled, directed graphs. Followingthe labels of such a diagram results in path descriptions in this general form: N:<label-1><label-2> ...<label-m> where N indicates the starting point (relative path) or the root of the name graph. Such representations are familiar from directories in a file system. The graph shown in the following figure represents a hypothetical path in the name space of the directory service X.500. C=DE O = Uni Stuttgart OU = Informatik CN = Info_Server C : Country O : Organisation OU : Organisation Unit CN : Common Name
Host_Name = Andromeda
Host_Name = Gemini
226
7 Exercises
Question 10.1: A file system has the following paths:

/home/files/drafts /home/files/publications /games/tetris /games/chess /publications
Supplement the corresponding name graph in the diagram: Diagram for question 10.1 publications
Question 10.2: The Java 2 Microedition supports (among others) the following packages:
java.lang java.util javax.microedition.lcdui javax.microedition.io javax.microedition.lcdui.games javax.microedition.media.control javax.microedition.midlet javax.microedition.pki javax.microedition.rms
Supplement the graph of the corresponding name sapce in the diagram:
227
Diagram for Question 10.2
Question 10.3: The Domain Name System of the WWW also has a name space. Supplement the following hypthetical path in the diagram below www.ikr.uni-stuttgart.de/index.html: Diagram for Question 10.3 com edu org ... de
7.1.11 CORBA and RMI
228
7 Exercises
The figure shows the process of generating a server application and a matching client application by use of CORBA, as well as the resulting architecture. Object Interface Definition
IDL to C++ Compiler C++ Interface C++ Client Application C++ Compiler C++ Stub
IDL to Java Compiler Java Skeleton Java Interface Java Server Application Java Compiler
written by application developer
ObRf C++ Stub ORB Core Client Middleware IIOP Obj. Java Skeleton Adapter ORB Core Server
Question 11.1: Explain the process and the role of the resulting components on the system. Question 11.2: When using the Java Remote Method Invokation (RMI), the procedure is similar as with CORBA. However, there are some characteristic differences. Compare both technologies.
7.1.12 Clients and Servers

Explain the difference between a client and a server.
7.1.13 Threads and Processes

Threads are flows of control within the address space of a process.
229
Question 13.1: What happens, when a violation of address space occurs within a thread? Question 13.2: A part of the application is moved to a remote system. What happens, when a violation of the address space happens on the remote system?
7.1.14 Memory Leak

A badly written application keeps allocating memory by generating objects without eliminating all of them after they are not needed any more. Question 14.1:The user of a desk-top system which extends memory by a hard disk is running such an application and notices, that the system is continuously getting slower. Why? Question 14.2: What would happen on a mobile phone (whithout a hard disk) in the same situation? Question 14.3: The user of the deskt-top system has learned to exit and restart the application it this situation. How does this measure work?
7.1.15 Viruses and Trojan Horses

Which kind of system allows to provide better protection against viruses and trojan horses: a mono-tasking operating system or a multi-tasking operating system (pls. indicate the reason).
7.1.16 Service Discovery

How may a device discover services which are offered in a new environment and how can the device offer own services? Describe some general ways and mechanisms.
7.1.17 Bluetooth
Describe, how Service Discovery with Bluetooth works in principle. Explain, how an application which has been written by yourself may be discoverd on your device.
7.1.18 Communication End Points

How would you define an end point for communications?
7.1.19 File-Sharing
230
7 Exercises
As shown in the figure, a file sharing network is organised in a way, that network nodes may escalate a message that they have received to other known network nodes. The figure shows two levels of escalation. Level 2 Level 1
Question 19.1: We take the assumption, that each network node escalates a message to 100 other network nodes. How many levels of escalation are needed to address a total of 100 billion (i.e. 100 0000 million) network nodes? Question 19.2: Describe ways to prevent endless loops in escalation and how to avoid escalation to spread to infinity.
7.1.20 CORBA and Web-Services

While using CORBA, a client-stub is compiled from a formal interface definition which is contained in an IDL-file. Name an equivalent formal description of the interface with Web-Services.
7.1.21 Direct Provision of Client Applications

An alternative to the tedious procedure of generating client-stub for client applications from formal descriptions is to provide the complete client application for loading and installation on the target client system. Compare both alternatives and indicate typical ares of application.
7.1.22 A Sandbox for Software

Explain the concept of a sandbox for loading and running software on a system and describe some of the components of such a concept.
7.1.23 Buffer Overflow

Why are buffer overflows not occuring with Java programs?
231
7.1.24 The phantom menace

It is assumed, that the infrastructure of the institue is connected as shown in the figure.
Explain some of the threats within the scenarion shown in the figure.
7.1.25 Attacks
Explain the difference between passive attacks and active attacks and give some examples.
7.1.26 Requirements on public network infrastructure

What do we rely upon while using public network infrastructure, which is provided by network operators? Indicate some key requirements.
7.1.27 The security hole in your pocket

Which dangers to we expose ourselves by using one of the modern smart phones? Indicate some of them.
7.1.28 Town Gate

Explain the well proven concept of a town gate.
232
7 Exercises
7.1.29 Defence System
Explain the concept of a defence system with two protective walls, as shown in the figure,
7.1.30 Key Ring

Why are asymmetric encryption methods much better suited for communication with many partners than symmetric encryption methods? Explain the the scalability of both methods for a number of N communication partners.
7.1.31 Session Keys

In practice, following verification of identity of the communication partner by using asymmetric keys, symmetric keys are used as session keys for the subsequent for communication. Why is this? Indicate two reasons.
7.1.32 GSM Authentication

Explain the principle sequence of authentication in GSM.
7.1.33 One-Time Pads and Stream Ciphers

At their last meeting, Alice and Bob have been exchanging a random text. Each is using an exact copy of this text to encrypt messages they send to each other. The encryption is done bit by bit: one bit of plain text is combined with one bit of the random text at an XOR function (exclusive or). Decryption works in a similar way: the necrypted text is combined with a copy of the random text at an XOR function. Question 36.1: Try the procedure described above in practice with the bit
233
streams shown in the figure. Supplement the figure. Alice Plain Text: 0101 1001 ........................ Cipher Text Random Text: 1001 0111 Random Text: 1001 0111 Bob
Question 36.2 The procedure is considered as extremely difficult to attack (i.e. analyse and crack). Why is this? Question 36.3: Do you recommend Alice and Bob to re-use the same random text several times? Explain your recommendation. Question 36.4: Describe an appoximation of the procedure which utilises the same type of random text generator with Alice and Bob.
7.1.34 IPSec
Explain the tunneling of ecnrypted or non-encrypted IP packets and the corresponding private and public address spaces, as shown in the figure.
Private IP Network (Intranet) Public IP Network (Internet) Private IP Network (Intranet)
Gateway
Gateway
IPpriv
IPpriv IPpub
IPpriv IPpub
IPpriv IPpub
IPpriv
IPpriv
data
IPpub IPpriv
data
IPpriv
data
7.1.35 IP-VPNs
Explain the concept and areas of application of IP-VPNs.
7.1.36 Identity, Authentication, Authorisation
234
7 Exercises
Explain the terms Identity, Authentication and Authorisation and indicate some corresponding examples.
7.1.37 Biometrics
Why is it not so clever to uses biometrical characteristics as keys?
7.1.38 GSM-Keys
With GSM, why is the secret key, which is stored on the SIM card never read out and communicated over the network?
7.1.39 Cloned SIM Cards

What can be done if somebody succeeds in copying the key stored on a SIM card (e.g. if replications or clones of a SIM card are put into circulation)?
7.1.40 Credentials
Question 45.1: You have purchased an electronic airline ticket with your credit card. What do you need to present in order to print out the ticket at the automatic ticket machine or to receive the ticket from the ticket counter or the airline? Question 45.2: You have been buying books at amazon with direct debit to your bank account. What prevents somebody else from using your account to buy books? Question 45.3: At passport control, you are requested to present your identity card or passport.How do you prove your identity? Question 45.4: In generalised terms, what may be used as credentials for authentication?
7.2 Part Two (Complete Book)

7.2.1 Collisions in Piconets
While using the Bluetooth radio technology, devices may form piconets as shown in the figure. All devices on one piconet communicate using frequency hopping over a total of 79 channels (channel 0 to 78). In each piconet, one master (M) determines the hopping sequence of its piconet with all slaves following this hopping sequence. Also, only one device within a piconet can trans-
235
mit at the same time. Thus, there are no collisions of devices within one piconet.
M M
But what happens, if several piconets are operating in the same room and at the same time? From the perspective of one given piconet, how many other piconets can operate in the same room for a given collission rate? The assumption is taken, that collisions happen every time, when any of the piconets in the room happen to use the same channel, i.e. every piconet is able to interfere with each other piconet. Question 1: What is the probability for 2 piconets to operate without collisions? (Hint: Each piconet runs all 79 channels in random sequence, irrespective of the number of devices in the piconet. What is the probability that 2 piconets incidently use the same channel? What is the probability of not colliding when operating two piconets?) Question 2: What is the probability for not colloding when operting 3 piconets? Generalise the term for the collisionfree operation of N piconets. Question 3: When a collision occurs, the packet is lost and will need to be retransmitted. The probability calculated so far just represents collision of one slot. In Bluetooth, master and slaves use alternating slots for transmission, one containing confirmation of receipt. If the packet is lost during transmission, it will need to be retransmitted. If the confirmation of receipt is lost in a collision, the packet will also be retransmitted. Adapt the probability for collisionfree operation accordingly. Question 4: If we take the assumption, that collision rate (probability of collisions) of 50% is acceptable, how many (N) piconets can operate in the same room? Answer 1: When 79 channels are used and piconet 1 is transmitting on one of the channels (e.g channel 0), there is a 1 to 79 chance that piconet 2 is transmitting on the same channel at the same time. Thus, the probability for not colliding between 2 piconets is: P2 = 1 - 1/79. Answer 2:With 3 piconets, the chance that neither the second or third piconet will collide with the first piconet corresponds to the chance, that the third piconet will not collide with the first two piconets (answer 2), i.e. P3 = (1 1/79)2. In general terms, the probability for N piconets to operate without collission is PN = (1 - 1/79)N-1. Answer 3: The probability of N piconets not colliding in both the transmit slot and the receive slot is: PN = (1 - 1/79)2N-2. Answer 4: With a collision rate of 50%, PN = 0,5 so N in the equation from answer 3 indicates the number of piconets able to cooperate under thee conditions in the same room: 0,5 = (1 - 1/79)2N-2 log (0,5) = (2N-2) log (1-1/79)
236
7 Exercises
N = 1 + log(0,5)/2 log(1-1/79) = 28,2. Hints: This problem corresponds to what is also called the birthday problem. Imagine a number of N people in the same room.There are two questions concerning collsions of birthdays: (1) You are one of the people in the room. What is the probability, that no one else has birthday the same day as you? With 365 possible timeslots (days per year), the answer follows the same logic as above. Pls. note, that this is all about collisions between one selected person and any one else. It is well possible, that two or more other peoples have colliding birthdays. (2) What is the probability, that all people in the room have different birthdays? The solution follows the same logic, but now we need to look at collisions between any of the N members, not just one selected member agains anyone else. Go step by step startring with N=2, then N=3 in order to find out the right scheme, and then do numerical simplifications for given values. There are more exercises which will make use of this to follow.
7.2.2 Framing protocol

10 000 Byte are to be transmitted using an air-interface with a Bit-Error-Rate of 10E-4. The data link layer is using a HDLC (High Level Data Link Control) protocol with the following parameters: Case I) Each I-Frame carries 128 Byte of user information. Case II) Each I-Frame carries 512 Byte of user information. For both cases applies: In Case of errors, each I-Frame should be immediately retransmitted (window size 1). Each I-Frame is using a header field with a length of 6 Byte. Questions: a)How many Frames must be transported in both cases (incl. the retransmissions in case of errors)? b)How long does the transmission with 32 kbit/s-channels take in both cases (not including the time for acknowledgments and any time for waiting). c)Which case is more effective, with respect to transporting more user information per second. d)Witch case is more effective using a bit error rate of 10-6? Solutions:
237
Question a) case I:
10000 Required Frames = -------------- = 78, 125 = 79 Frames 128 Number of Bytes = 10000 + 79 ! 6 = 10474 Bytes Number of Bits = 10747 ! 8 = 83792 bit Number of Errors = 83792 ! 10
4
= 8, 38 " 9 Error-Frames
Required Frames (incl. Error-Frames) = 79 + 9 = 88 Frames
Question a) case II:

10000 Required Frames = -------------- = 19, 53 = 20 Frames 512 Number of Bytes = 10000 + 20 ! 6 = 10120 Bytes Number of Bits = 10120 ! 8 = 80960 bit Number of Errors = 80960 ! 10
4
= 8, 1 " 9 Error-Frames
Required Frames (incl. Error-Frames) = 20 + 9 = 29 Frames
Question b) case I
Number of Byte (incl. Error Frames) = 10474 + 9 ! ( 128 + 6 ) = 11680 Byt Number of Bits = 11680 ! 8 = 93440 bit 93440 Transmission Rate = -------------- = 2, 92 s 32000
Question b) case II:

Number of Byte (incl. Error Frames) = 10120 + 9 ! ( 512 + 6 ) = 14782 Byte Number of Bits = 14782 ! 8 = 118256 bit 118256 Transmission Rate = ----------------- = 3, 7 s 32000
238
7 Exercises
Question c) case I:
10000 Bytes (eff.) per second = -------------- = 3424, 66 Bytes per second 2, 92 Bits (eff.) per second = 3424, 66 ! 8 = 27397, 28 bit/s (eff.)
Question c) case II:

10000 Bytes (eff.) per second = -------------- = 2702, 70 Bytes per second 3, 7 Bits (eff.) per second = 2702, 70 ! 8 = 21621, 6 bit/s (eff.)
Answer to question c): Case I is more effective. Question d): In case of a bit error rate of 10-6 one Error-Frame occur in both cases. Question d) case I:
Number of bytes (incl. Error Frames) = 10474 + 1 ! ( 128 + 6 ) = 10608 Bytes Number of Bits = 10608 ! 8 = 84864 bit 84864 Transmission Rate = -------------- = 2, 65 s 32000
Question d) case II:

Number of bytes (incl. Error Frames) = 10120 + 1 ! ( 512 + 6 ) = 10638 Bytes Number of Bits = 10638 ! 8 = 85104 bit 85104 Transmission Rate = -------------- = 2, 66 s 32000
Answer to question d): Now we have nearly the same effectivity in both cases.
7.2.3 Protocol Overhead in VoIP
239
In order to transmit Voice over IP packets, voice samples are digitised, coded and put as payload into IP packets, together with the packed header. The ration of the header information to the payload is called packet overhead.
Vers. Traffic Cl. Flow Label Payload Lenght Next H. Hop Limit
10 ms
Source Address
Codec
Destination Address
header voice
IPv6 header
Question 1: Calculate the packet overhead of voice, which is digitised at a sampling rate of 8 kilo samples per second and coded with 8 bits per sample (which corresponds to a continuous bitrate of 64 kBits/s), under the condition, that each packet is 10 ms long and that the IP header is 40 Bytes (which corresponds to the IPv6 header shown in the figure). Further overhead which is introduced by higher protocol layers (such as RTP or UDP) for time-stamps and packet sequence numbers is neglected. Question 2: Calculate the packet overhead under the condition, that before packaging, voice is compressed from 64 kbits/s to 8 kbits/s. What is the total amount of data to be transmitted per second?
7.2.4 Shopping carts

A super market has one check-out desk in service. One check-out desk can handle 6 customers per minute (on average). At the busy hour, there are 10 customers per minute (on average) arriving with their shopping carts at the check-out. Question 1: What will happen? Question 2: The management immediately reacts to the situation and opens a second check-out desk. How many customers can now be handled with 2 check-out desks? Explain, why the service rate will always need to be higher than the arrival rate and why a utilisation factor of 1 (service rate equals arrival rate) cannot be achieved. Question 3: Same situation as in question 2 (i.e. 2 check-out desks in operation). Under the assumption, that customers are driven to the check-out according to a Poisson-type of process, how many customers are in the system (in the queue and being served) on average?
7.2.5 Output Buffer

At the output interface of a system, messages are exchanged with another network element. A buffer is used to queue messages until they have been
240
7 Exercises
transmitted over the communication channel. The system generates 10 transactions per second. For each transaction, a message is send to the output buffer. The message size is 600 Bytes. Calculate the utilisation factor and the average number of messages in the system (buffer plus being served) for the following two cases: Case I) the channel provides a bitrate of 64 kbits/s Case II) the channel provides a bitrate of 10 Mbits/s
7.2.6 Intelligent Network

A mobile network is extended by an Intelligent Network (IN), i.e. by a system which is to be used to provide pre-paid services in a flexible way. The question is on the capacity of the IN-System . The mobile network supports a total of 80 million subscribers. Requests to the Intelligent Network are directed to 2 IN-Systems, which operate in loadsharing. One subscriber is generating 0,02 transactions per hour (within the busy hour). The handling of one transaction by the IN-system takes 50 ms on average. In order to provide a sufficient performance, the utilisation factor should be below 0,8 (i.e.#<0,8). Question: How many servers (m) are required within each IN-System in order to handle the requests (transactions) in parallel? Solution:
80000000 Users per System = ----------------------- = 40000000 Users per IN-System 2 Number of transactions per h = 40000000 ! 0, 02 = 800000 transactions per h 800000 Number of transactions per s = ----------------- = 222, 222 transactions per s 3600 $ 1 # = ----------- where = ------------ and $ = 222, 222 transactions per s !m 50ms $ 222, 22 ! 50 ! 10 m = ---------- = ------------------------------------------- = 13, 88 " 14Servers 0, 8 !#
3
7.2.7 Virtual HLR in a Mobile Network

A mobile network with a total of 40 million users consists of 80 location areas with one MSC. Assumption: the users are equally distributed. Each user has 5 transactions (signalling activities) for incoming and out going calls during the Busy Hour. The ratio of outgoing calls to incoming calls is 60% to 40%. The average serving time within the HLR is 40 ms. The system utilization factor # should be better than 0,8. Other activities (location update or VLR-requests) should not be taken into consideration, all requests should be sent to the HLR. Question: How many servers in load sharing are required per HLR?
241
Solution:
40000000 Users per HLR = ----------------------- = 500000 Users per HLR 80 Number of transactions per h = 500000 ! 2 = 1000000 transactions per h 1000000 Number of transactions per s = -------------------- = 277, 78 transactions per s 3600 $ 1 # = ----------- where = ------------ and $ = 277, 78 transactions per s !m 40ms $ 277, 78 ! 40 ! 10 m = ---------- = ------------------------------------------- = 13, 8 " 14Servers 0, 8 !#
3
7.2.8 Location Updates

Explain the concept of location updates within a GSM mobile network.
7.2.9 Classes and Objects

A zoological case: A dog is an animal, which barks, hunts sticks and attacks intruders. A pitbull is a dog race which has developed a particularly nasty form of attack. Bob has a pitbull named Charlie, which is 10 years old. Where appropriate, represent those relations in a class diagram or in an object diagram.
7.2.10 Relations at Examination Time
242
7 Exercises
The class diagram below describes relation at the time of the examination. Read and explain the figure.
Aggregation (has a) Participant Generalisation (is a) +name
takes part *
Examination +time +date +location terminate()
Student -immatriculno: int -confident: boolean think() write() terminate()
Teacher
writes solves Task +titel +date Association
Composition Problem * +number +text * Question +questionno +text
More specifically, the examination for Telecommunication Software Engineering will look like this:
Task +titel +date 2 Problem +number +text * {< 8} Question +questionno +text
7.2.11 Evaluation of Results

Following examination, the results are evaluated by the teacher and made available to the students by using the immatriculation numbers as reference. Also the overall results (average, standard deviation) are evaluated and made
243
available, so everone may find out his individual position in the results. The corresponding classes and relations are shown in the figure.
Student
reads
IndividualScore immatriculno: int totalPoints totalPointsAchieved countPoints() evaluates Teacher QuestionNo * maxPoints pointsAchieved
assignPoints()
Question 1: Extend the diagram above to allow the evaluation of the average results of all students (i.e. the total score) and the evaluation of the overall standard deviation. The total score should be accessible to all students. Solution:
Student reads
reads
IndividualScore immatriculno: int totalPoints totalPointsAchieved countPoints() * 1 TotalScore average standardDeviation calcAverage() calcDeviation() evaluates Teacher QuestionNo * maxPoints pointsAchieved
assignPoints()
Question 2: The diagram above represents a class diagram. Show the relations between the IndividualScore, TotalScore and QuestionNo in an object diagram with instances for 3 students (with imatriculation numbers 37, 56, and 89) and 2 questions (QuestionNo) per IndividualScore.
244
7 Exercises
Solution (including some arbitrarily chosen values for attributes):

:TotalScore average= 74 standardDeviation= 8 :QuestionNo maxPoints= 40 pointsAchieved= 26 :QuestionNo maxPoints= 60 pointsAchieved= 30 :QuestionNo maxPoints= 40 pointsAchieved= 36 :QuestionNo maxPoints= 60 pointsAchieved= 42 :QuestionNo maxPoints= 40 pointsAchieved= 40 :QuestionNo maxPoints= 60 pointsAchieved= 48
:IndividualScore immatriculno= 37 totalPoints= 100 totalPointsAchieved= 56
Question 3: How would the same instances as in question 3 look like in tables (such as tables in a relational data base)? Solution: Classes thanslate into rows of a table (i.e. relations), objects populate the table (i.e. represent tuples). This results in the following structure:
TotalScore average 74 standardDeviation 8
IndividualScore immatricul total no Points 74 56 89 100 100 100 totalPoints Achieved 56 78 88 Question max No Points 1 1 1 40 40 40 Question max Points Points Achieved No 26 36 40 2 2 2 60 60 60 Points Achieved 30 42 48
Question 4: In C++ a class can be represented in code as shown in the figure.
245
How would the classs IndividualScore be expressed in C++ (for IndiviTable column1: int column2: int setValue() getValue()
class Table { Integer column1; Integer column2; void setValue() { // ... (Implementation) } void getValue() { // ... (Implementation) } }
dualScore see the figure at the beginning of this exercise above question 1)?
7.2.12 Service Discovery

A Service Provider plans to offer services, which are accessible via Bluetooth access points. Access is possible from personal computers (laptops, PCs), but the most popular devices are supposed to be mobile phones (smartphones). The Bluetooth access points represent Server devices, the mobile phones represent Client devices (see Figure below).
Part 1
For both the mobile phone and the access point, a software application needs to be developed. The figure below shows the design of the Bluetooth access point (Server device) and the mobile phone (Client device).
Client device
Server device
Client application
Service discovery Service access
Server application
Service registration
Bluetooth stack SDP client Service Discovery Protocol
Bluetooth stack SDP server SDDB Service record
Question 1: Explain the components of the Server device and the Client device (i.e. their function and how they interact). Note: SDP: Service Dis-
246
7 Exercises
covery Protocol, SDDB: Service Discovery Data Base. Question 2: Indicate the sequence, in which the Server application and Client application use the functions which are provided by the Bluetooth stack and explain why this sequence is used.
Part 2
The figure below shows the life cycle of a Service Record on the Service Discovery Data Base (SDDB). The Server Application controls the complete process. The Service Record is generated by a pre-fabricated method of the Connector type of object, and is finally written to the SDDB.
Server Application : : open(ObjRf) : new : new : set service attributes return notifier : : acceptAndOpen() : create record like rec in SDDB : SDDBRecord notifier : rec : ServiceRecord : Connector
: wait for client connection
return connection : : close() : remove record from SDDB
Question 3: Describe the role of the objects shown in the figure and identify the objects, which are obviously pre-fabricated and are contained in the API framework of the Server device. Question 4: From the perspective of the Server Application, the sequence diagram contains different actions: service registration, waiting and handling a client connection, and closing the connection.Identify the actions in the diagram and indicate, between which messages of the Server Application they happen. Also explain what is happening within each of the actions. Question 5: Indicate which of the messages shown in the diagram obviously correspond to methods contained in the API framework of the Server device.
247
Part 3
In the Bluetooth API framework described in this task, Object References are defined as a character string of the follow type:
<Protocol>:<Address>:<Port>;<Parameters>
For example
btspp://008003AB8901:1;authentication=true
indicates that the Bluetooth Serial Port Profile is used (btspp), that the device has 008003AB8901 as Bluetooth device address (BD_ADDR), that serial port 1 is used, and that authentication is required. This Object Reference is handed to the Connector.open method:
Connector.open(btspp://008003AB8901:1;authentication=true)
At the server side, this can be seen in the figure of part 2 (first method call : open(ObjRf)). The same Object Reference is also handed to the Connector.open method of the client. Question 6: Explain the purpose of handing the Object Reference to the Connector.open method at the server side and at the client side.
Part 4
After the client has succeded in connecting to the server and to invoke the Server application, it may exchange objects (files, messages etc) using the OBEX protocol. In terms of the API framework in use, OBEX represents a content type of connection over input streams and output streams (the connection framework is shown in chapter 3.2.4).
248
7 Exercises
However, the server settings require the client to submit to authentication, before OBEX can be invoked (application level authentication). OBEX authentication follows the procedure shown in the figure below.
Client
password Random Generator Challenge append Password+ Challenge Response append Password+ Challenge Hash Hash compare [equal] [not equal] indicate authentication failed indicate success
Server
password
MD5
MD5
Question 7: Explain the procedure shown in the figure. Question 8: The procedure is only possible under a specific prior condition. What is this condition and how can it be realised? Question 9: The diagram does not comply with standards for UML activity diagram. Synchronisation points at append and compare are missing. Also, there is no starting point and no end point for the flow of control. Change the figure to comply with UML standards.
7.2.13 Personal Networks

A Service Provider plans to offer Personal Network Services. The services should enable service subscribers to connect devices from their personal environment to a Personal Network and to access their Personal Network from anywhere. Access is possible from personal computers (laptops, PCs), but the most popular device is supposed to be a mobile phone (smart phone). For mobile phones, the Service Provider plans to use Bluetooth access points (or Access Gateways, AGW). The network is an ad-hoc type of network, i.e. it allows to discover devices and services which are connected for the time being. For a user of the Personal Network, this means, that the user may detect a network access point, and the access point transfers to the users device a choice of services, which are available. Within the system, services are identified by ServiceIDs. Also,
249
the access point transfers Object References of the services, which may be used by the users device to invoke a service.
Part 1
There are two different scenarios in discussion: Scenario 1 is a completely decentralised architecture. There is no central place to keep an inventory of services.
Scenario 1
Location A Wide Area Network
AGW1
B
AGW2
C A Location B
In scenario 2, a server is installed in the wide area network, which contains an inventory of services.
Scenario 2
Location A Wide Area Network
AGW1
B
AGW2
C A
Service Inventory
Location B
Service Service Object Name ID Reference
250
7 Exercises
Question 1: What is the difference between both scenarios. Hint: Use the sequence of events starting from Alice (with der device A) entering location A and initiating service discovery on her device. Question 2: Put the sequence of main events for each scenario in a sequence diagram, which contains A, AGW1, AGW2, as well as the Service Inventory (in scenario 2). Question 3: For scenario 2, show the sequence of actions between A, AGW1, AGW2 and Service Inventory in an activity diagram. Question 4: Compare both scenarios, decide for one of them for implementation (on behalf of the Service Provider) and explain your decision.
Part 2
Following service discovery and presentation of available service to Alice, Alice (A) may select one of the services. We take the assumption, that Location A is a public access point, and Location B is the office at the company, where Alice works. Alice discovers, that her collegues Bob (B) and Charlie (C) are present at her chat application and opens a chat window. Question 5: In scenario 1, there is no chat server (AGW1 and AGW2 do not provide this function). How can a chat between A, B and C be realised? Question 6: The service provider decides to install a chat server in the wide area network. Describe the role of the chat server and how it works in principle. Question 7: Remote access to the office (Location B) from a public place (Location A) generates some security issues: Authenticity, Confidentiality and Integrity need to be provided. Describe adequate measures to solve these issues for the Personal Network. Question 8: Draw a use case diagram for Alice and her interaction with AGW1 for Scenario 2 (starting from service discover and including security measures).
7.2.14 Mobile Instant Messaging

A Mobile Network Operator plans to offer Instant Messaging for mobile phones. The service allows subscribers to see where their friends or collegues are by a presence indication (icon) in a telephone directory (or presence table, see figure). For example, on his mobile set, Bob can see that Alice is at home,
251
so he can decide whether to send her a message, invite her to chat, give her a call, or better not to disturb her.
presence indication
Bobs Friends Alice Charlie Evelyn Bob

presence table
Configuration Options Home Office Off-line Swimming Shopping Tennis Pub ...
...
Alice in her Home Cell at configuration time
The presence indications may be configured by the service subscribers from a choice list. For example, when Alice is at home, she selects the home icon in a configuration menu of the service (as shown on the right of the figure above). This selection will associate the Cell-ID of the mobile network with the home icon within the mobile set (the Cell-ID is visible to the mobile set). After configuration, whenever Alice enters this Radio Cell, the home icon will be activated and made visible to her friends automatically. When Alice leaves her home cell, her presence indication will change to another state (such as offline, on-line, or another presence out of the configured items). The Network Operator plans to implement the service by installing a Messaging Server, which performs the following functions (also see figure below): (1) Collection of presence updates from users (e.g. as soon as Alice arrives in the cell that she has configured as home, her mobile set sends a presence notification to the message server. (2) Associate presence updates from users to presence tables of subscribers (e.g. Bob has subscribed to Alice, Charlie and Evelyn, their presence state is kept in a presence table for Bob). (3) Generate and send presence updates to subscribers every time, when a state of presence has changed. When the table needs to be initialised, the complete table is transmitted. Else, the Messaging Server only sends pre-
252
7 Exercises
sence updates.
Bobs Friends Alice Charlie Evelyn
table update (presence update)
Bob
Messaging Server
notification (presence update) Area of Cell-ID
Alice
Home Cell of Alice Office Cell of Alice
Part 1
The mobile network serves 60 Million subscribers. For Mobile Instant Messaging, the assumption is, that one subscriber generates 0,3 transactions (presence updates) per hour in the busy hour. A presence update message is 400 Bytes (same message lenght for both notification and table update). There are an average of 10 subscribers (friends) per table. Question 1: Calculate the total transaction rate (presence updates per second) and throughput (bits/s) for incoming messages at the Messaging Server. Question 2: Calculate the total transaction rate (presence updates per second) and throughput (bits/s) for outgoing messages from the Messaging Server (no initial tables, updates only). Question 3: The Messaging Server is composed of serving units, which may receive, process and forward messages to the receivers in 40 ms. For a system utilisation of 0,8, how many serving units are required for the Messaging Server?
Part 2
The Mobile Network Operator also offers the secure exchange of documents between users of the Instant Messenging service. Documents may be selected
253
and be sent in a secure mode to members of the Friends Lists. The figure below shows, what happens within the sending device.
A (Sender)
Document checksum Hash
B (Receiver)
private
signed checksum
Archive (File)
Send Archive
Question 4: Complete the figure with the corresponding actions at the receiving device. Question 5: This procedure proves the integrity and origin of the document. However, it does not protect confidentiality. Show a diagram with a procedure, which also protects confidentiality. Question 6: One of the issues with the procedure is key management, i.e. how to get the public keys of subscribers on the device and how to prove their authenticity. For this purpose, the Mobile Network Operator signs public keys of service subscribers and sends the signed keys to the respective subscribers (organised in Friends Lists). When a document is transferred, the public key of the sender is sent together with the document. Explain, how this measure works and why it improves the situation.
Part 3
Using the Mobile Instant Messenger, Bob subscribes to the presence of his friends. (1) In return, friends of Bob subscribe to Bobs presence. (2) Presence information is sent as messages (presence updates) over public networks. Question 7: What privacy issues and security issues does this generate for Bob? Question 8: Describe suitable measures to protect privacy and to improve security for the service.
254
7 Exercises
7.2.15 UPNP Remote Control

It is supposed, that the suppliers of Consumer Electronics and Domestic Appliances have agreed on a common interface for controlling devices in order to overcome the problem of the steadily growing number of individual remote controls in households. It is assumed, that they plan to implement Universal Plug and Play as standard for service discovery and service control.
Part 1
In Universal Plug and Play, devices are assumed to contain services. Devices and services are required to follow the general model shown in the figure.
Device deviceType : String friendlyName : String manufacturer : String manufacturerURL : URL modelDescription : String modelName : String modelnumber : String modelURL : URL serialNumber : String UDN : String UPC : String urlBase : String presentatioURL : URL descriptionURL : URL Service serviceType : Stringl serviceID : String controlURL : URL eventSubURL : URL descriptionURL : URL
0 .. *
0 .. * Action name : String StateVariable sendingEvents : Boolean name : String dataType : String defaultValue : String allowedValues : Enumeration value : String
0 .. * Icon mimeType : String width : Integer height : Integer depths : Integer url : URL Argument
0 .. * returnValue : Boolean name : String direction : String value : String 1 related state variable
Question 1: Explain the model for devices and services according to the figure. Question 2: In UPNP, actions of a service may be invoked by sending messages to the control URL of the service. The service RemoteTvCtrl of a TV Set-Top-Box supports the following actions: (1) mute() (2) setVolume(string Level), where the value of Level is between 0 and 10 (3) getChannelNo(string ChanNo)
255
Show the Actions and Arguments in an object diagram of the RemoteTvCtrl service instance. Question 3: About states. If the sendingEvents attribute of the StateVariable is set true, the value of the StateVariable will be automatically communicated to other devices, which subscribe to state changes. A technical alternative to Event Notifications would be explicit State Requests by invocation of actions. Explain the pros and cons of an automatic State Eventing versus explicit State Requests. Question 4: About service descriptions to generate clients. A Remote Control may extract a formal description of the services offered by the device (XML document) by issuing a request to the description URL contained in the Service object. What information will the service description need to contain in order to enable the generation of a corresponding client function in the Remote Control?
Part 2
When a device enters a new environment, it needs to perform Service Discovery in order to find other devices. In UPNP, the device gets a network address (e.g. by DHCP), then sends a multicast discovery message to the network and waits for responses. In order to avoid collisions by having other devices reply at the same time, the device sends a time interval with its Discovery Requests. Other devices answer within this interval at a randomly chosen point of time. It is planned to use UPNP discovery for wireless devices (e.g. infrared or Bluetooth) which operate over 10 kbits/s interfaces. Discovery response messages are 500 Bytes. Question 5: Calculate the length T of the time interval for responses, which is needed for a collissionfree operation of Pno-coll=0,9 for a number of 10 devices. Question 6: When a new device enters a UPNP network, it also multicasts a presence notification which includes the advertisment of its services. Explain the difference between issuing service discovery requests and issuing such presence notifications. Indicate, whether there is a useful combination of both methods.
Part 3
With UPNP, the interface of a service contained in a device is specified in a service description, which may be read from the service as an XML document. From this formal description of the server interface, a client function may be generated for the UPNP Remote Control.
256
7 Exercises
The figure on the left shows the relations between client, server and the interface. This relation may also be expressed as shown in the class diagram on the right.
Client
Client
use
<<interface>> ServerInterface
ServerInterface
Server
Server
<<interface>> ServerInterface
Question 7: Explain this relation.
Part 4
Using a UPNP Remote Control in a domestic environment generates security issues. Question 8: Indicate some of the issues and describe adequate potential solutions.
7.2.16 Location Based Services
257
A Service Provider plans to extent its Mobile Instant Messaging Service with a proximity indication for friends on the presence table, who happen to be close to each other. The service is designed to work as shown in the figure.
Geo-Matching Server Messaging Server
Pseudonym Space Alice
proximity indication
presence table
local area
Bobs Friends Alice

proximity alert
Bob
Real World Alice
Bob
Cell based location (Cell-ID)
Proximity based location (Spot-ID)
- Proximity is based on Cell-IDs of cellular mobile networks and IDs of hot spots (Spot-IDs) implemented by other radio technologies (such as WLAN or Bluetooth Hot-Spots). - Cell-IDs and Spot-IDs are known to the mobile sets in the respective area (they can be read from the the cells and spots and are communicated by the mobile set over the network within presence update messages). - Cell-IDs and Spot-IDs of different network operators in the same area may be matched to local areas in a Geo-Matching Server. - Users of the service are notified if their friends are present in the same area (e.g. by an indication on the presence table and a special ringtone as proximity alert) - The collection of presence updates from users and the notification of users is handled by a Messaging Server. The Messaging Server consults the Geo-Matching Server for users in the same local area. In the scenario shown in the figure, Alice is located in a cell, that she has configured as her favourite pub. Bob happens to be shopping in the same area and is notified about the presence and proximity of Alice.
258
7 Exercises
Part 1
Within the area served by the Service Provider, there is a total of 100 million of subscribers to the service (with different mobile network operatos). For Mobile Instant Messaging, the assumption is, that one subscriber generates 0,36 transactions (presence updates) per hour in the busy hour. A presence update message is 400 Bytes (same message lenght for both notification and table update). There is an average of 10 subscribers (friends) per table. Question 1: Calculate the total transaction rate (presence updates per second) and throughput (bits/s) for incoming messages at the Messaging Server. Question 2: Take a design decision about where to match friends to tables and where to match Cell-IDs and Spot_IDs to local areas. Decide which information elements of messages to be transmitted from the Messaging Server to the Geo-Matching Server for each presence update. Under this assumption, calculate the total transaction rate (requests to the Geo-Matching Server per second). Question 3: Under the assumption, that messages for request and responses are 400 Bytes each, calculate the troughput (bits/s) at the interface between the Messaging Server and the Geo-Matching Server. Question 4: The Geo-Matching Server is composed of serving units, which may receive, process and forward messages to the receiver in 40 ms. For a system utilisation of 0,8, how many serving units are required for the Geo-Matching Server?
Part 2
In order to find out how likely friends are going to meet (get proximity indications), the Service Provider takes the following assumptions: one local area contains 1000 users, a region contains 100000 users. Question 5: What is the probability that Bob will meet one or more of his 10 friends, who all live in the same region, in the same local area? The assumption is that users randomly roam through all local areas in an equally distributed way. Question 6: A more realistic assumption probably is, that each user spends most of his time in one of his 3 favourite locations (such as home, work and leisure). 5 out of Bobs friends (his closest friends) each share 1 of these locations (local areas) with Bob. What is the probability that Bob meets one or more of his closest friends in one of his favourite locations?
Part 3
259
The Mobile Network Operator has a view of the true identities of users and devices.The figure below descibes the authentication procedure in GSM.
GSM Network (HLR/AuC)
Generator
Mobile Set (SIM card)
Ki
private
Random Number (Challenge)
Challenge
Ki
private
A3
Response Response
A3
=
equal?
Question 7: Explain the procedure and discuss the protection it provides against potential attacks. Question 8: The Provider of the Location Based Service in this task has a limited visibility of the identity of his users: users register with nicknames (pseudonyms). Also, user locations are communicated by pseudonyms (my shop, my pub). Discuss privacy issues with Location Based Services in general and how this design of Location Based Services handles these issues.
7.2.17 Client-Server Communication

Part 1
Messages from application SOAP supporting protocol ( HTTP, IIOP, ...) Transport Protocol (TCP, ...) Message Exchange Pattern Encoding for transport
Client and Server of an application communicate with each other using SOAP as protocol framework. SOAP is agnostic of the supporting protocol (it binds to it and is aware of its properties), but does not depend on it (i.e. the supporting protocol may be exchanged).
Question 1: What are the pros and cons (benefits and drawbacks) of using a protocol framework versus directly usind a specific protocol? Question 2: The following table shows states and events of the SOAP Request-Reply Message Exchange Pattern which is to be used for the client-server communication. The table shows the client side. Translate the table into a state diagram. How does the corresponding state diagram for
260
7 Exercises
the server differ from the client?

Transitions: State Init Description Generate & send request message Event Request sent successfully Failure to send Requesting Waiting for reply Receive reply Reception Failure/ Time out Sending& Receiving Receiving reply message Response message well formed Reception failure Next state Requesting Failed Sending& Receiving Failed Success Failed
Question 3: For transport, messages will need to be serialised. Name pros and cons of binary encoding versus representation by text.
Part 2
The Client is going to be implemented by using a Finite State Machine according to the following Class Diagram. The diagram also includes some suggestions on the implementation of the methods (as comments in pseudocode).
Context stateVariable : State setState() : void stateAction() : void 1 transit(c : Context) : void State
InitState ... stateVariable.transit(this) ...
RequestingState
SendReceiveState
transit() : void
transit() : void
transit() : void
... setState(s : State) { stateVariable = s; } ... ... // do actions c.setState(rs : RequestingState); ... ... // do actions c.setState( srs : SendReceiveState); ...
Question 4: Explain the components of the class diagram and their relations (syntax only, more questions follow). Question 5: Complete the diagram with the missing states (see Part 1). Question 6: Explain the function of the components and how state transitions are handled. Hints: Which component holds the state? Why do the
261
state objects do not have attributes? Which objects handle state transitions? What is the sequence of events in a state transition (also see comments in the diagram)?
Part 3
While client and server communicate with each other, they exchange SOAP messages. Most frequently, SOAP messages are represented by text messages (in form of XML documents which are exchanged over HTTP ). Question 7: There are security risks in exchanging such messages over the Internet. Name some potential threats. Question 8: Name some measures, by which such risks in the communication between client and server may be mitigated and explain why they improve the situation (i.e. explain the basic principle of the suggested measures).
7.2.18 Local Context Service

A Mobile Network Operator plans to run a Wikipedia type of database for local information. The database is going to be filled by users themselves: users may select from a menu of choices and enter information including telephone numbers and URLs. The menu contains a choice of symbols to identify local entities such as pharmacies, gas stations, railway station, taxi, car repair, shops, restaurants, government institutions, medical service etc. This information is stored in the data base according to the location areas the users are in. When users enter location areas, the information available for the respective location area is transferred automatically to their local telephone directory (information is pushed). As shown in the figure, the service is triggered by a location update. A Context Server extracts the local context from the data base according to the corresponding location area. From the local telephone directory, the user may now directly access more information (including recommendations from other users), or place a call.
262
7 Exercises
Context Server
local directory Pharmacy Taxi Shops i

location update
data base
context update
Area of Cell-ID
Bob
Bob
Location Area
Part 1
The mobile network serves 50 Million subscribers. For the Local Context Service, the assumption is, that one subscriber on average generates 3,6 transactions (context updates) per hour in the busy hour. A context update message is 1000 Bytes. Question 1: Calculate the total transaction rate (context updates per second) and throughput (bits/s) for outgoing messages at the Context Server. Question 2: The Context Server is composed of serving units, which may receive, process and forward messages to the receivers in 10 ms. For a system utilisation of 0.8, how many serving units are required for the Context Server? Question 3: One disadvantage of this design is, that it transfers information every time Bob passes a location area, even if Bob does not use the context information. Explain a different design, which transfers less information and compare both.
Part 2
In the service, each information item(such as taxi, pharmacy, shops etc.) is assigned a unique identifier (UID). This is done by assigning a randomly chosen 64 bit number to each item. The database is designed to keep a total of 100 million information items. Question 4: What is the probability, that all 100 Mio. UIDs will be different?
263
(Hint: What is the probability, that the second item has a different UID than the first? What is the probability, that the UID of the 3rd item will be different from the UID of the 2nd and the UID of the 1st? Generalise for N items. If the number of items is small in comparison to the address space (i.e. ID space), the resulting formula may be simplified.) Question 5: Describe a technical alternative to assigning UIDs by random numbers and discuss benefits and drawbacks.
Part 3
When using the service, the icon of the information object can be associated with different types of connections: placing a call, opening a web page, sending a message, opening an instant messaging session etc. In order to do this, each icon associates with a set of Object References (such as telephone numbers, URLs etc.) for the respective service. In the mobile set, this is done by a generic connection framework: the Object Reference is text string, which is passed to the open() method of a factory class Connector. This will return a Connection object for the requested kind of connection. Question 6: Draw a sequence diagram for this sequence of events.
Part 4
In order to economise on costs, the Mobile Network Operator has altered the design of the service. The context server now holds a table with AreaIDs and RecordIDs. Each RecordID points to a record, which contains the icons with their corresponding information and object references for that specific location area. The specific record is only transferred to a mobile device, when icons are actually selected. Because the table containing RecordIDs and records is quite large, it is partitioned between 10 file servers. The address of the correct file server is obtained by the RecordID modulo 10, as shown in the figure below.
AreaID RecordID Record
0 Address = (RecordID) mod 10 ... ... ... 9 1
Question 7: A software development engineer suggests to economise even more, by distributing the records in a peer-to-peer way directly on active mobile phones instead of using a file server (i.e. is using modulo N addresses for N active devices on the network). However, there are some problems with this approach. Explain them.
264
7 Exercises
Question 8: The engineering department has found an alternative approach for peer-to-peer distribution of records on devices: Devices get assigned random DeviceIDs. Each record is stored on the device (or retrieved from the device), which is closest in ID space to the RecordID. In order to forward requests, each device contains a routing table with detailed knowledge of its own environment in ID space. IDs are represented using hexadecimal digits. The figure below shows the principle (with 28 bit addresses for simplification). How many hops are required at maximum to reach one of 5 million active devices?
2 28 - 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 0 d60afc9 d53b42 d53b4f 0 1 2 3 4 5 6 7 8 9 a b c d e f d53b0d d53a71 0 1 2 3 4 5 6 7 8 9 a b c d e f
f d57fb2 65a1fc
... Routing information of node with ID 65a1fc d13db9
add(d53b42)
(respectively store(d53b42), get(d53b42) in case of records)
7.2.19 Home Networks

In a home network, sensors (such as light switches, door bell, temperature measurement, smoke detection, moisture measurement, counters) are planned to be coupled over wireless interfaces with actors (such as lights, shutters, local and remote displays, alarms).
Part 1
The following classes are planned to be used as part of the software for devices in home networks.
265
.
Subject attach(Oberser) detach(Oberserver) notify() ... for all o in Oberservers { o.update(); } ... ConcreteSubject - subjectState + setState() + getState() return subjectState; ... observedState = subject.getState(); ... + update() * << abstract >> Obersver update()
ConcreteOberver - opservedState
Question 1: Explain the diagram (syntax only, more questions follow). Question 2: Explain how it works.
Part 2
Question 3: 2 Two instances of ConcreteObservers have been attached to an inctance of a ConreteSubject, as shown in the following sequence diagram. Complete the actions in the sequence diagram.
266
7 Exercises
switch : ConreteSubject
display1 : ConcreteObserver
display1 : ConcreteObserver
setState(on) notify()
Question 4: In the case of the two ConcreteObservers being different from each other (not just different instances), how would the class diagram need to be changed to reflect the difference?
Part 3
Question 5: The 2nd ConcreteObserver is going to be implemented in a different system than the ConcreteSubject and the 1st observer (e.g. system 1 being a light switch with control LED and system 2 the light). Explain which additional context is needed to make both systems interact. Question 6: In such a network, it is essential to connect the right sensor to the right actor (i.e. match light switches to the right lights). Also, it should be possible to add and remove devices easily at any time. Explain the corresponding issues and possible solutions. Question 7: Security. Name security issues in such a network and possible measures for protection. Question 8: Explain how certificates could be used to improve security issues.
7.2.20 Fixed Mobile Convergence

A Fixed Network Operator plans to provide a uniform telephone service in cooperation with a Mobile Network Operator (so called Fixed-Mobile-Convergence): When a mobile subscriber is close to his fixed line at home or at work, calls to his mobile set are diverted automatically to the fixed line. The service is provided with two options: either calls in the home location may be picked up with a fixced line telephone set (option 1), or calls are picked up
267
with the mobile set, but delivered trough the fixed line over a cordless radio technology such as Bluetooth (option 2). The benefit for the subscriber are reduced call rates over the fixed line and a single telephone number for all calls (i.e. the mobile telephone number). For families or small companies, the service can be provided over a single fixed line access point to multiple mobile sets. Ultimately, the mobile set may become the universal personal telephone set.
Other National Networks (PSTN/VoIP/PLMN)
Subscriber Location Register (SLR)
data base
HLR Fixed Network (PSTN or VoIP)
Mobile Network (PLMN)
cordless access point
2 1
Bobs home location
Bob
at home at work 1 2 divert calls to fixed line divert calls and use cordless access point with mobile set
at home at work
Part 1
The mobile network of the cooperaring Mobile Network Operator (MNO) serves 30 Million subscribers within the given national network. An additional 50 Mio. mobile subscribers are with other national Mobile Network Operators. The Fixed Network Operator (FNO) serves 40 Mio. fixed lines, which represents the vast majority of national fixed subscribers. The Fixed Network Operator plans to provide a Service Location Register, (SLR) which can be queried from his own network and from the cooperating mobile network. If a subscriber moves into his home area, a pointer to ths SLR
268
7 Exercises
is entered into the HLR (Home Location Register) of the MNO. The SLR holds the number of the corresponding subscriber line of the FNO. Also, the SLR is used as a general data base for the delivery of all calls which originate from the network of the FNO. Because national telephone numbers represent a national resource, the FNO uses the SLR to find out whether a call needs to be delivered to a competing national FNO within the same national numbering plan. For the service, the assumptions are, that one mobile subscriber generates on average 2,25 call transactions per busy hour, that 80% of all mobile calls are delivered from the home location, and that one fixed subscriber generates 3,6 call transactions per busy hour. An SLR message is assumed to be 400 Bytes (each query and response). Question 1: Calculate the total transaction rate and throughput (bits/s) for query messages at the Location Service Registry. Question 2: The SLR is composed of serving units, which may receive, process and forward messages to the receivers in 10 ms. For a system utilisation of 0.8, how many serving units are required for the SLR? Question 3: One of the competing MNOs plans to operate own cordless access points for his own 30 Mio. subscribers over a new VoIP infrastructure without cooperation with a FNO and without fixed line numbers. The SLR functionality is to be included in the HLR. What is the extra amount of traffic on the combined HLR/SLR for the SLR function, if 30% of the mobile subscribers use the service at their home access points and cancel their fixed line telephone service with their FNO? For comparison with regular HLR load, it is assumed that the major source of HLR traffic are location updates with an average rate of 4 location updates per mobile subscriber and busy hour. Do you consider an extended HLR as feasible (in terms of the extra load)?
Part 2
In the service, home access points are used in combination with mobile sets. In order to trigger the diversion of mobile calls over the fixed line only for authorized mobile devices, individual mobile sets need to be made familiar with their access points. Else, unauthorised devices might pick up calls or deliver calls. The figure below explains what happens inside the home access point
269
(A) and the mobile set (B), when Bluetooth is used as cordless radio technology within a home location.
A (Access Point)
random Generator
B (Mobile Set)
random
User
PIN BD_ADDR(B)
E22 initial key K_init E21 link key K_ab
E22 initial key K_init E21
PIN BD_ADDR(B)
User
Random numbers and BD_ADDR from A and B
Random numbers and BD_ADDR from A and B link key K_ab
Pairing Authentication
Pairing Authentication
random (128 bit) Generator
random (128 bit)
E1
link key K_ab
response (32 bit)
Question 4: Bluetooth uses two different steps: (1) make devices familiar with each other (the so called pairing), (2) authentication of one device to the other, once devices have been paired. Explain what happens in step (1) according to the figure. Question 5: The authentication procedure is not complete. Add the missing part in the figure and explain the procedure. Do you consider pairing including user intervention (i.e. step 1) necessary each time or is it safe to let devices automatically authenticate after an initial pairing? Question 6: Compare the security aspects (i.e. the risks and the level of protection they provide) for a telephone service according to the following options: (1) current fixed lines including cordless telephone sets, (2) home access points over VoIP according to this service, (3) mobile telephone sets over GSM or UMTS.
270
7 Exercises
Part 3
In the service described in Part 2, authentication of devices is based on Bluetooth link keys (K_ab), which are 128 bit numbers. Given a hugh amount of bluetooth devices, a device might accidently authenticate to another device by having a matching link key. Question 7: If link keys are randomly distributed, what is the probablility, that among 10.000 Mio. of devices, all link keys are different? Question 8: Given one specific device, what is the probability that no other device (among the 10.000 Mio. devices) has the same link key?
7.2.21 Mobile Peer-to-Peer Networks

By downloading and installing software on mobile phones, mobile peer-topeer networks may be generated (in much the same way than instant messaging or file sharing works with PCs over the Internet). A service provider plans to provide such client software for download. Clients may become part of the network, when they activate the software, and leave the network when they quit the application. Strictly speaking, clients can also receive messages and offer services, i.e. act as servers. Because both client and server part are implemented, participants in the network are called peers. By joining in, peers generate a logical network, or overlay network (see figure below). The service provider also plans to provide super peers, i.e. more permanent participants installed on servers, which serve as directories or look-up servers in order to facilitate network organisation.
Overlay Networks (Peer-to-Peer Networks)
Super Peer
Peer
server
Physical Networks
mobile phone
271
Part 1
Question 1: Peers can be identified by their PeerID, i.e. a number, which serves as a unique identifier. Explain, how Peer IDs can be assigned to peers and chose a design for the service provider. Question 2: Peers may join the network, look-up the presence of other peers, and leave the network. Specify a principle design for network organisation for the service provider (i.e. functions to be supported by peers and to be developed for the peer software). Question 3: Alice and Bob have both installed the peer software on their mobile phones and Bob is now trying to find Alice over the network. There are 100 Mio. peers in the network, each peer knows 8 other peers on average. How many discovery requests are required and how many nodes (hops) does a discovery request need to travel in the following cases: (1) without the super peers (i.e. Bobs peer sends a request to 8 other peers, which again propagate the discovery request), (2) including the super peers, with each of them knowing 100.000 users (peers) and connecting to 8 other super peers. Can you improve the design of question 2?
Part 2
The peer software needs to be designed to support different physical interfaces, such as HTTP type of connections over GSM or UMTS channels, serial connections over Infrared or Bluetooth, TCP sockets etc. The following design has been chosen.
Client uses
<< abstract >> Generator generates Connection:createConnection(typeInfo)
<< abstract >> Connection transmit() receive()
ConcreteGenerator Connection:createConnection(typeInfo)
HTTPConnection transmit() receive()
SerialConnection transmit() receive()
return new ConcreteConnetion();
ConcreteConnetion
272
7 Exercises
Question 4: Explain the components of the diagram and their relations (syntax only, more questions follow). How could the diagram be extended for a TCP socket type of connection? Question 5: Explain the function of the diagram, i.e. how it is used to establish a connection from one peer to another. Explain how the ConcreteGenerator could be implemented and what the typeInfo needs to contain in order to connect to another peer over the network. Question 6: Explain the sequence of events when connecting from one peer to another over a HTTP connection in a sequence diagram.
Part 3
Alice installs a new service on her mobile phone, which provides access to her photo library over the peer-to-peer network. Bob has been able to discover the phone of Alice and is able connect to Alice. Question 7: How can Bob discover the new service and find out what it is? Explain which information needs to be specified for service discovery and give some guidelines for implementation. Question 8: Following discovery, what is needed to access and use the service? Explain which information needs to be specified on the phone of Alice and how the service can be invoked by Bob.
7.2.22 Mobility Management

A network operator plans to run a network which is based on the new Limex technology, which promises to squeeze radio channels more effectively and is entirely based on the popular packet switching technology IP. In comparison to the traditional mobile networks such as GSM or UMTS, which are extensively standardised, Limex specifications basically cover the radio interface and leave many options for implementation. (Note: Limex is just made up for this exercise, the name is not relevant).
273
The network is planned to support mobile users. The network architecture
AuS AC
HA
other networks
Core 2 AG2 AG1 1 ...
AC
AG2 AG1
BS Cell MS Bob
Limex network BS
which is envisaged by the network operator is shown in the figure. Each base station (BS) connects mobile users (such as Bob in the figure) over the Limex radio interface within its radio cell. It is envisaged, that mobile sets (MS) such as laptop computers, PDAs and phones will support the Limex radio interface. Traffic is collected with 2 levels of aggregation (AG1 and AG2). AG1 (aggregation level 1) collects the traffic from the base stations. At AG2 (aggregation level 2), an Access Controller (AC) supports the authentication of mobile users. The AC cooperates with an Authentication Server (AuS) at core network level, which contains the credentials of mobile users for network access, as well as user profiles for authorisation and accounting. As mobile users also may receive requests from the network, the network keeps track of the location of mobile users. This function is supported by a Home Agent (HA) in the core network. Each time, a mobile user moves into a new radio cell, his location is updated in the HA. The core network interconnects with other networks, such as the Internet.
Part 1
The network operator plans to apply for a national licence, i.e. to provide Limex coverage for the complete country. For a rough estimation of the network infrastructure, the following assumptions are taken: one base station (BS) may handle 20 Mbit/s of traffic for a total of 400 users per cell, aggregation level one (AG1) collects traffic from 5 base stations on average, AG2 col-
274
7 Exercises
lects traffic from 10 first level aggregation networks. The network is expected to support a total of 4 million users. Question 1: Calculate the total traffic at the interfaces 1 (after AG1) and 2 (after AG2) in the network. Question 2: The traffic model for mobile users is not known yet (i.e. how many location updates per user and per busy hour the HA needs to process). The HA-server is composed of 2 serving units, which may handle update requests within 10 ms. For a system utilisation of 0.8, how many location updates per user can the system handle in the busy hour? Question 3: How many authentication requests per user and busy hour does one Acces Server (AC) need to handle? Question 4: You may find the transaction load on the AC (authentication requests) and HA (location updates) unbalanced. Describe a way of putting load off the HA. Bonus question: What about the AuS (load situation and potential ways of improvement)?
Part 2
An important part of mobility management is the authentication of mobile users. Because users are allowed to roam anywhere in the network, each base station (BS) must accept any user for an authentication procedure. Following successful authentication, any data, which is exchanged over the radio inter-
275
face, needs to be encrypted. The following figure shows the authentication procedure envisaged by the network operator.
Mobile Set
authentication request
BS
AC
AuS
check certif. and retrieve public key server key (public)
server certificate
Random
private
server key (private)
E session key server authentication user credentials UID PWD UID PWD
UID
PWD
E session key
retrieve user credentials PWD UID UID
UID look up password
UID session key
PWD
append session key and credentials
generate authentication key (AK) AK
yes
=? no
PWD
PWD
hash
authentication failed
AK
authentication key client authentication
AK
AK
data from application
HA / Any Server
AK E data from application data from application AK
data encryption on the radio interface
Question 5: Explain the role of each network element (MS, BS, AC, AuS) and explain the procedure. Question 6: On the mobile set and on the access controller, there are details
276
7 Exercises
missing on the following activities: (1) check certificate, (2) retrieve user credentials, (3) generate authentication key. Provide solutions for the missing details.
Part 3
A condition for the authentication procedure shown in part 2 is, that the mobile set is equipped with a valid network address (IP address) in order to be able to communicate with other network elements. Assigning network addresses to mobile users is a special case: because users are roaming, the may not become a static part of the network topology, at least not in the access network. For this reason, mobile users are not assigned addresses of the access network (an), but core network addresses (cn). This leaves the access network untouched by mobility. The figure below illustrates the principle. In order to to ac-
IPcn, MS
IPan, BS
...
...
MS BS
Router (e.g. at AG1, AG2), AC, AuS, ... access network
HA
Any Server
core network
IPcn
IPcn IPan IPan
IPcn IPan
IPcn
IPcn
data
IPan IPcn
data
IPcn
data
cess a specific mobile user, the HA maintains a table, which allows it to send a package for the specific mobile user to his current base station (as a care of address). While doing location updates, the mobile set registers its current base station at the HA. Question 7: Explain how core network elements communicate with each other and how packets are routed through the access network (e.g. use of address spaces and tunnels as shown in the figure). Question 8: Being equipped by a valid network address, a mobile set could just decide to ignore the authentication procedure of part 2 and start to communicate with other network elements. Is there anything in the current network design, that prevents this kind of misuse?
277
7.2.23 Remote Control for Home Networks

Devices at home, such as TV, stereo, lights, door opener, cookers, washing machines etc. increasingly support interfaces, which allow to monitor their states and allow to call actions on them. However, most of the device interfaces are proprietary, i.e. they are specified any way their vendor likes. Thus, a universal remote control for a variety of devices needs to be developed in a way that allows to handle a multitude of interfaces and is easily extensible.
Part 1
It is supposed, that each device has an interface description, which is specified in a well known format (i.e. using an interface description language). The interface description may be retrieved as a text document either directly from the device or it may be downloaded from the Web, so that there is no need for the developer of the remote control to study specification papers. The figure below illustrates the principle of how to retrieve, process and use the interface description to control a device.
Remote Control
selected action display (1) retrieve interface description (2) process interface description
Device, e.g. TV
... on() mute() channelUp() volumeUp() off() ...
IDL-Doc.
Device: TV on() mute() channelUp()

exec back
interface description (3) call actions on device
execute command
scroll through command list
Question 1: Which information needs to be contained in the interface description in order to allow the remote control to use it? Question 2: Explain the 3 steps indicated in the figure. How are vendor specific actions handled? Question 3: What do all devices and the remote control need as common runtime environment to support step 1 and 3?
Part 2
278
7 Exercises
Rather than using a display, the developer decides to use a more conventional design with real buttons for actions on devices, as shown in the figure below.
Remote Control
light on TV on door open Stereo setDVD Stereo setTV light off TV mute door lock Stereo setRadio execute undo command buttons
Remote Control
light on TV on door open Stereo setDVD Stereo setTV light off TV mute door lock Stereo setRadio undo
device buttons
device buttons execute commands
This design is driven by the following considerations: (1) At configuration time, commands according to actions contained in the interface description are associated with device buttons (configuration time corresponds to step 2 of part 1). (2) Following configuration, the device buttons are labelled and may be used in the following way: select a device action, then execute the action by pressing a command button. In the design on the right, selection and execution are combined. This design leads the developer to the following domain model for the software to be developed on the remote control.
Command activeCmd; public void setCommand(Command c) { activeCmd = c; } << interface>> Command execute() undo()
Configurator
Activator setCommand()
contains the vendor specific actions on devices ConcreteCommand DeviceCtrler creates action() execute() undo()
creates
public void execute() { deviceCtrler.action(); }
279
Question 4: 2 Explain the components of the diagram and their relations (syntax only, more questions follow). Question 5: Explain the role of each component and how the software is supposed to work. Question 6: In relation to the design of the remote control (with device buttons and command buttons), explain what happens at runtime when buttons are pressed. Which difference does the design of the remote control on the right make in comparison to the design on the left? Question 7: Again at runtime, explain how the configuration works (i.e. what the code of the Configurator is supposed to do). How flexible is the concept really with respect to configuration? Question 8: Explain in general, how the concept needs to be extended in order to support the undo command (i.e. what extra information is needed and how it may be processed).
7.2.24 Mobile Video-Streaming

A mobile network operator plans to offer videos to be selected by mobile users and streamed to their mobile sets. The network supports 36 million mobile users. The mobile network is structured as shown in the figure below. A radio cell serves 400 mobile users on average. At aggregation level 1 (AG1) the traffic of 10 cells is collected. Aggregation level 2 (AG2) collects traffic
280
7 Exercises
from 20 AG1. In order to provide the new video service, a video server is placed in the core of the network.
Video Server Mulitcast Server

other networks
Core 2 AG2 AG1 1 ... AG1 BS Cell MS Bob Mobile Network BS
AG2
Part 1
An average video plays 3 minutes. Due to the limited screen size of mobile phones, videos may be streamed at 128 kbits/s. There is a collection of free videos available for mobile users. It is estimated, that in the busy hour, 1 video is selected and played per user (i.e. 1 transaction per user in the busy hour). Question 1: Calculate the extra traffic generated by the video service per radio cell. Question 2: Calculate the total number of transactions per second to be handled by the video server. Question 3: The video server is composed of serving units (processor boards) with 10 ms service time. How many processor boards are needed for a system utilization of 80%? Question 4: Calculate the total traffic to be handled by the video server.
Part 2
281
A collection of 100 free videos is made available for mobile users. Videos may be selected by users and are started in intervals of 1 second by the video server. Question 5: If it is assumed that the free videos are the most popular source of traffic, how many videos playing at the same time are actually the same videos (on average)? Question 6: Playing the same video at exactly the same time over many individual streams represents a waste of resources. In order to econimize on network bandwith, the network operator considers to introduce multicasting, i.e. the same video is only streamed once to its next destination and then further distributed as individual streams. If multicasting is introduced between the video server and the second aggregation level (AG2), what is the potential gain of the procedure (reduction of traffic)? Do you recommend the procedure for the given network? Question 7: How would the network structure need to be changed in order for multicasting to become effective? What could be done at the video server to make multicasting more effective?
Part 3
The mobile network operator also offers video blogs to its mobile users, i.e. every mobile user may upload own videos to the video server and make them available for viewing to others. Question 8: There is a probability, that all the videos, which are played concurrently, are different. For this probability to be below 1%, how many video blogs need to be on the server (equal distribution of selected videos is assumed). Hint: How many videos are played at the same time?
7.2.25 Remote Player

For audivisual media in the network, remote players are used to access and play the media. In order to allow remote players to interoperate with the media servers, there need to be some conventions concerning the interface between player and server. The interfaces need to be implemented by both the providers of media servers, and by the providers of remote players, e.g. as software clients to be installed on mobile devices.
Part 1
A network operator, who provides audiovisual content on media servers in his network, intends to stimulate the development of player software on mobile devices. For this reason, he publishes some conventions for the interface to
282
7 Exercises
the media servers to be followed by the player software, as shown in the figure below.
Media Server
display Movie MovieList 0 .. * movieTitle : String genre : String author : String duration : String movieID : String classifier: String Stream mimeType : String size : String controlObjRF : URL
Remote Player
movie in focus
Movies title1 title2 title3

more back
0 .. * Action 1 Icon mimeType : String width : Integer height : Integer iconObjRF : URL 0 .. * Argument returnValue : Boolean name : String value : String name : String
select command for more information
scroll through movie list
Question 1: Which information needs to be contained in the Object References (ObjRF) for the icon and the stream in order to access the referenced objects? Question 2: Instantiate the model for a media stream with the actions play(), stop() and goto(SceneNumber)?
Part 2
When a movie or a song has been selected from the list on the remote player, the next step should be to show the icon of the movie or song on the player. The client on the remote player is using the structure shown in the following diagram.
283
.
Client << interface>> Icon show()
... ImageIcon show() ImageProxy iconObjRF : URL imageIcon : ImageIcon show() if ( imageIcon == 0 ) { // display message loading icon imageIcon = new ImageIcon( iconObjRF ) } imageIcon.show() ...
Question 3: 2 Explain the components of the diagram and their relations (syntax only, more questions follow). Question 4: Explain the role of each component, in particular the role of the proxy, and how the software is supposed to work. Question 5: Show the sequence of events when an icon needs to be loaded for the first time in a sequence diagram. Question 6: One drawback of the procedure is, that if the proxy needs to load the image icon, the procedure will not return until the icon has been loaded, which freezes the client interface. Describe a way to improve this situation.
Part 3
Not every content on the media server is intended for everybody. The free movies and songs are available for everone, but there is also material, which is not free of charge and other material only intended for adults. So the media server will need some access control. Question 7: What credentials could be used to authenticate users who want to access classified content? Describe a suitable procedure for authentication. Question 8: How could the class diagram be extended to support access for authenticated users? How would the new procedure work? Hint: There can be more than one proxy.
284
7 Exercises
285
8 References
Distributed Systems
[Emmerich] W. Emmerich, Engineering Distribted Objects, John Wiley & Sons, 2000, ISBN: 0471986577; also available in German: dPunkt Verlag, 2003, ISBN: 3898641406 [Riggs] R. Riggs, Programming wireless devices with the Java 2 Platform, Micro Edition, Addison Wesley, 2001, ISBN 0-201-74627-1 [Tanenb] A.S.Tanenbaum, Computer Networks, third edition, Prentice Hall, 1996 [Glass] G. Glass, Web-Services, Building Blocks for Distributed Systems, Prentice Hall, 2002, ISBN 0-13-066256-9 [SnellTK] J.Snell, D.Tidwell, P.Kulchenko; Programming Web Services with SOAP; OReilly&Assiociates Inc.; 2002 ...
Formal Descriptions
[Larman] C. Larmann, Applying UML and Patterns, Pearson Education, 2002, ISBN 0137488807 [JeckRup] M. Jeckle, C. Rupp et. al, UML 2 glasklar, Hanser Fachbuchverlag, 2003, ISBN 3446225757 [HiKa03] M. Hitz, G. Kappel, UML@Work, Von der Analyse zur Realisierung, 2. Auflage, dPunkt Verlag, Heidelberg, 2003, ISBN 3-89864-1945 [HruRup] P. Hruschka, C. Rupp, Agile Softwareentwicklung fr Embedded Real-Time-Systems mit der UML, Carl Hanser Verlag, Mnchen, 2002, ISBN 3446219978 ...
Networks
[Siegm03] G.Siegmund, Technik der Netze, Hthig Verlag, Heidelberg, 5. Auflage, 2003, ISBN: 3-8266-5021-2 (of which a summary is included in chapter 1 of this maniscript) [Peters00]L. Peterson, B. Davie, Computer Networks, Morgan Kaufmann Publishers, 2000, ISBN 0155860832X [Siegm01] G. Siegmund et. al. Intelligente Netze - Technik, Dienste, Vermarktung, Hthig Verlag, Heidelberg, 2. Auflage, 2001, ISBN:
286
8 References
3778539485 [RuSie03] S. Rupp, G. Siegmund, Java in der Telekommunikation - Grundlagen, Konzept, Anwendungen; dPunkt Verlag, Heidelberg, ISBN 389864-244-5, 2003 ...
Technologies
[Bray01] J. Bray, C. Sturmann, Bluetooth 1.2 - Connected without wires, Prentice Hall PTR, 2001, ISBN 0130661060 [Kumar] C. Bala Kumar, Paul Kline, Tim Thompson, Bluetooth Application Programming with the Java APIs, Morgan Kaufmann Publishers, 2003, ISBN 1558609342 [Schmatz] K.-D. Schmatz, Java 2 Micro Edition - Entwicklung mobiler Anwendungen mit CLDC und MIDP, dPunkt Verlag, Heidelberg, ISBN 389864-271-2, 2004 [GeRu04] A. Gerlicher, S. Rupp, Symbian OS - Eine Einfhrung in die Anwendungsentwicklung, dPunkt Verlag, 2004, Heidelberg, ISBN 1558609342 []...
Standards and References in the Web

[BlueOrg] Web Site of the Bluetooth Special Interest Group http://www.bluetooth.org [BlueSpec12] Specification of the Bluetooth System, Version 1.2.5, November 2003, Bluetooth SIG: http://www.bluetooth.org/spec [BlueSpec11] Specification of the Bluetooth System, Version 1.1, February 22, 2001, Bluetooth SIG: http://www.bluetooth.org/spec [BlueJSR82] Bluetooth APIs der JSR-82: http://www.jcp.org/en/jsr/detail?id=82 [Palowire] Bluetooth Resource Center: www.palowireless.com/infotooth [BlueTec] Bluetooth technology website: http://www.bluetooth.com/ [BluePAN] Personal Area Networking Profile, Bluetooth SIG, June 26, 2001. [BlueIEEE] See: http://grouper.ieee.org/groups/802/15/Bluetooth/ [BlueNEP] Bluetooth Network Encapsulation Protocol (BNEP) Specification. Bluetooth SIG. June 12, 2001. See: http://grouper.ieee.org/groups/802/15/Bluetooth/ [JiniOrg] Web-site of the Jini Organisation: http://www.jini.org/ [JiniWP] Jini technology white papers and other documents, Sun Inc. http://wwws.sun.com/software/jini/whitepapers/architecture.html
287
[JiniTec] JINI Network Technology: http://wwws.sun.com/software/jini/ [JxtaOrg] Web-site of the JXTA Organisation: http://www.jxta.org/ [JxtaPrj] Project JXTA: http://wwws.sun.com/software/jxta/ [JxtaBk] Projects::JXTA jects/jxta/ Book, http://www.brendonwilson.com/pro-
[JxtaSpec] JXTA Specification V2.0: http://spec.jxta.org/nonav/v1.0/docbook/JXTAProtocols.html [JabberOrg] The Jabber software Foundation: http://www.jabber.org/ [JabberTec] Jabber Technologies and resources: http://www.jabber.com/ [Gnutella] Gnutella Technologies and Clients: http://www.gnutella.com/ [WenLctr] K.Weniger, Lecture on Ad Hoc Networks, http://www.tm.uka.de/lehre/SS02/vorlesungen/V_MK_Unterlagen/ mk09-1.pdf [W3Crg] Web Site of the http://www.w3.org/2002/ws/ [UddiV30] UDDI Version di.org/pubs/uddi_v3.htm W3C 3.0, 19. Org on Web 2002, Services: http://ud-
July
[UddiOrg] UDDI Organisation: http://www.uddi.org [OasisOrg] Standarsisation body OASIS for UDDI: http://www.oasisopen.org ...
288
8 References
289
9 Translations English - German
Admission control: Zulassungskontrolle Air Interface: Funkschnittstelle Application layer: Anwendungsschicht, Verarbeitungsschicht Basic Services (BS): Basisdienste Bearer Service: Trgerdienst Block Error Rate: Blockfehlerrate Broadcast: Rundsendung Call Control: Rufsteuerung Call drop rate: Verbindungsabbruchrate Call Forwarding (CF): Rufumleitung Carrier: Verbinungsnetzbetreiber Cell Identity (CID): Zellkennung Circuit switched domain, CS domain: Leitungsvermittelte Domne Circuit switching: Leitungsvermittlung Confidentiality: Vertraulichkeit Content Provider: Inhalteanbieter Control plane: Steuerungsebene Core Network: Kernnetz Data Link Layer: Sicherungsschicht Delay, Latency: Verzgerung, Laufzeit Downlink: Abwrtsstrecke Echo canceller: Echokompensator Expedited Forwarding: beschleunigtes Weiterleiten Fading: Schwund Firewall: Brandschutzmauer, Paketfilter Frame Error Rate: Rahmenfehlerrate Frequency Division Multiple Access: Frequenzvielfachzugriff Handover, Handoff: (Verbindungs-)bergabe, Weiterreichen Integrity: Unversehrtheit (von Daten) Jitter: Laufzeitschwankungen Line of Sight: Sichtverbindung Local Area Network: Lokales Rechnernetz Location Area (LA): Aufenthaltsbereich Mobile Termination: Mobilfunk-Netzabschluss Mobility Management: Mobilittssteuerung Multicast: Vielfachsendung narrowband: schmalbandig Network Layer: Vermittlungsschicht Packet loss: Paketverlust Packet switching: Paketvermittlung Penetration Loss: Wanddmpfungsverlust Physical Layer: Physikalische Schicht Power Control: Leistungsregelung Presence Service: Erreichbarkeitsdienst Processing Gain: Prozessgewinn
290
9 Translations English - German
Pseudo Noise Sequence: Pseudozufallsfolge Push Service: Zustelldienst Quality of Service: Dienstgte Release: Ausgabe (eines Normenpaketes oder Softwarepaketes) Resource management: Administration der Betriebsmittel Resources: Betriebsmittel Routing: Verkehrslenkung Scrambling: Verwrfelung Sensitivity: Empfindlichkeit Service provider: Dienstanbieter, Diensterbringer Session connection: Sitzung Session layer: Sitzungsschicht, Kommunikationssteuerungsschicht, Session management: Sitzungssteuerung Short Message: Kurznachricht Spread Spectrum State Event Diagram: Zustandsbergangsdiagramm Subframe: Teilrahmen Sublayer: Teilschicht Subscription: Vertragsabschluss, Subskription, Diensteinschreibung Supplementary Services (SS): Zusatzdienste Terminal Equipment: Endgert Time Division Multiple Access: Zeitvielfachzugriff Traffic Model: Verkehrsmodell Transcoding: Umcodierung Transport layer: Transportschicht, Uplink:Aufwrtsstrecke User Equipment: Teilnehmerausrstung User plane: Nutzerebene
291
10 Abbreviations
2G: 2nd Generation (of Mobile Radio) 3G: 3rd Generation (of Mobile Radio) 3GPP: 3rd Generation Partnership Project (UMTS) AAA: Authentication, Authorization, Accounting ADSL: Asynchronous Digital Subscriber Line AG: Access Gateway AP: Access Point API: Application Programming Interface APN: Access Point Name AS: Application Server ASP: Application Service Provider ATM: Asynchronous Transfer Mode AuC: Authentication Center BLER: Block Error Rate BSC: Base Station Controller BSS: Base Station System BTS: Base Transceiver Station CAMEL: Customized Applications for Mobile network Enhanced Logic CCBS: Customer Care and Billing System CDMA: Code Division Multiple Access CK_ Ciphering Key CORBA: Common Object Request Broker Architecture CPE: Customer Premises Equipment Dedicated Channel DECT: Digital Enhanced Cordless Telecommunications DHCP: Dynamic Host Configuration Protocol DIAMETER: successor to RADIUS DNS: Domain Name Service DSL: Digital subscriber line DVB: Digital Video Broadcasting DVB-S: Satellite DVB DVB-T: Terrestrial DVB EDGE: Enhanced Data rates for Global Evolution EIR: Equipment Identity Register ERAN: EDGE Radio Access Network ETSI: European Telecommunications Standards Institute EU: European Union FA: Foreign Agent FBI: Feedback Indicator FDD: Frequency Division Duplex FDMA: Frequency Division Multiple Access FEC: Forward Error Correction FER: Frame Error Rate FTP: File Transfer Protocol GERAN: GSM/EDGE Radio Access Network
292
10 Abbreviations
GGSN: Gateway GPRS Support Node GMLC: Gateway Mobile Location Center G-MSC: Gateway MSC GPRS:General Packet Radio Service GPS: Global Positioning System GSM: Global System for Mobile communication GTP: GPRS Tunneling Protocol HAP: High Altitude Platform HDTV: High Definition Television HLR: Home Location Register HSCSD: High Speed Circuit Switched Data HSS: Home Subscriber Server HTTP: Hypertext Transfer Protocol IAM: Initial Access Message ID: Identity IDL: Interface Description Language IEEE: Institute of Electrical and Electronics Engineers IETF: Internet Engineering Task Force IM: Instant Messaging IMEI: International Mobile Equipment Identity IMSI: International Mobile Subscriber Identity IN: Intelligent Network INAP: Intelligent Network Application Part IP: Internet Protocol IPsec: IP Security Protocol IP-VPN: IP Virtual Private Network ISDN: Integrated Services Digital Network ISIM: IMS Subscriber Identity Module ISO: International Organization for Standardization ISP: Internet Service Provider ISUP: ISDN User Part IT: Informations Technologie ITU: International Telecommunication Union J2ME: Java 2 Micro Edition Kc: Ciphering Key LA: Location Area LAN: Local Area Network LBS:Location Based Service LLC: Logical Link Control LOS: Line of Sight MAC: Medium Access Control MAN: Metropolitan Area Network MAP: Mobile Application Part MID: Mobile Information Device MMS: Multimedia Messaging Service MNC: Mobile Network Code MP3:Moving Pictures experts group 1 layer 3 standard MPEG: Moving Pictures Experts Group MPLS: Multi-Protocol Label Switching Multimedia Resource Function Processor MS: Mobile Station
293
MSC: Mobile Switching Center MSIN: Mobile Station Identification Number MSISDN: Mobile Subscriber ISDN number MTP: Message Transfer Part NAT: Network Address Translation NSS: Network Subsystem OFDM: Orthogonal Frequency Division Multiplexing OMA: Open Mobile Alliance OMG: Object Management Group OSI: Open Systems Interconnection OSPF: Open Shortest Path First PCM: Pulse Code Modulation PDA: Personal Digital Assistant PHY: Physical Layer PLMN: Public Land Mobile Network PPP: Point to Point Protocol PS: Packet Switching PSTN: Public Switched Telephony Network P-TMSI: Packet TMSI QoS: Quality of Service RA: Routeing Area RAB: Radio Access Bearer RADIUS: Remote Authentication Dial In User Service RAN: Radio Access Network RFC: Request For Comments (IETF) RLC: Radio Link Control RNC: Radio Network Controller RTP:Real Time Transport Protocol SAP: Service Access Point SAT: SIM Application Toolkit SCCP: Signaling Connection Control Part SCP: Service Control Point SDH: Synchronous Digital Hierarchy SDP: Service Discovery Protocol SDU: Service Data Unit SGSN: Serving GPRS Support Node SIG, (Bluetooth) Special Interest Group SIM: Subscriber Identity Module SIP: Session Initiation Protocol SMS: Short Message Service SMSC: Short Message Service Center SMTP: Simple Mail Transfer Protocol SOAP: Simple Object Access Protocol SS7: Signaling Subsystem No 7 SSF: Service Switching Function SSP: Service Switching Point STP: Signaling Transfer Point TCAP: Transaction Capability Application Part TCP: Transmission Control Protocol TD/CDMA: Time Division / Code Division Multiple Access TDD: Time Division Duplex
294
10 Abbreviations
TDM: Time Division Multiplex(ing) TDMA: Time Division Multiple Access TE: Terminal Equipment TMSI: Temporary Mobile Subscriber Identity UDP: User Datagram Protocol UML: Unified Modeling Language UMTS: Universal Mobile Telecommunications System URL: Universal Resource Locator USAT: USIM Application Toolkit USIM:Universal Subscriber Identity Module UTRA: Universal Terrestrial Radio Access UTRAN: Universal Terrestrial Radio Access Network VLR: Visitor Location Register VPN: Virtual Private Network WAN: Wide Area Network WAP: Wireless Application Protocol W-CDMA: Wideband CDMA WLAN: Wireless Local Area Network WPAN: Wireless Personal Area Network WSDL: Web Services Description Language WWW: World Wide Web XML:Extended Markup Language
295
A Abis 33 Abstract Class 141, 142 Abstract Service Primitives (ASP) 68, 87 Access Control 199 Accounting 21, 209 Active Attacks 197 Active Objects 166 Activity Diagram 176, 181 Address Space 112, 158 Addresses 34, 70 Administrative network entities 136 Advanced Encryption Standard (AES) 201 Advertisement 114 A-Interface 33 Alice 197 Anonymity 205 API Framework 173 API framework 109 Application Architecture 160 Application Engine 157 Application Entities 65 Application Interface 145, 151 Application Layer 67 Application Programm Interface (API) 111 Application Server (Server) 51 Applications 109, 145 Assertion 181 Asymmetric Encryption 202 ATM (Asynchronous Transfer Mode) 23 ATM-(AAL2) 48 Attachment 171 Attacks 53 Attributes 55 Authentication 207 Authentication Center (AuC) 29 Authentication CF 146 Authentication Header 203 Authorisation 207 Availability 199
296
B Base Station 27 Base Station Controller (BSC) 29 Base Station Subsystem (BSS) 29 Base Transceiver System (BTS) 29 Basic Reference Model (RM) 64 Bearer Capabilities 50 Billing 136 Binding 60, 130, 210 Bio-metrical data 212 Block (SDL) 75 Bluetooth connection 168 Bluetooth L2CAP 168 Bluetooth Network Encapsulation Protocol (BNEP) 101 Bluetooth Service Record 168 Bluetooth, Active Mode 102 Bluetooth, Hold Mode 103 Bluetooth, Piconets 97 Bluetooth, Protocol Stack 95 Bluetooth, Scatternet 97 Bluetooth, Service Discovery 117, 119 Bluetooth, Sniff Mode 103 Bob 197 Body 22 Broadband access 17 Browser 56 Buffer Overflows 193 Bug Tracker 183 Build Process 193 Build Tool 183 Building 73, 173 Busy signal 16 Bytecode 190 C Cable Modems 17 Cable TV networks 7 Call Control (CC) 34 Camera needs printer scenario 123 Cell Area 49 Cell Global Identifiers (CGI) 49
297
Cell Stream 24 Cellular mobile networks 26 Cellular Phones 25 Channel (SDL) 75 Circuit switched networks 2, 19 Class Diagram 177, 180 Class Loader 191 Classes 111 Client 72, 108 Client application 109 Client Interface 109, 160 Client object 144 Client Side MTM 170 Client Thread 109, 160 Client-Object 124 Client-Server Architecture 12 Client-Server Communication 76 Client-Server Framework 108, 159 Code Multiplex Multiple Access (CDMA) 46 Common Functions (CF) 145 Common Object Request Broker Architecture (CORBA) 58, 117, 127 communication 126 Communication channel 14 Communication Database 165 Communication Endpoints 126 Communication Framework 163 Communication Link 20, 116 Communication protocols 135 Communication Servers 159, 164 Complexity 138 Component Based Software 150 Computing 134 Confidentiality 199, 205 CONFIRM 68 Conflict of interests 205 Conformance Tests 83 Connected Limited Device Profile (CLDC) 125 Connection 14, 23, 30, 126, 199 Connection Endpoints 69 Connection orientet exchange of messages 18
298
Connectionless exchange of messages 19 Connector 126 Container 192 Containers for applications 150 Content Provider 205 ContentConnection 126 Context Switching 158 Control Environment 160 Control of traffic 18 Control Plane 20, 68 Control Processor 21 Cordless telephone 24, 61 Core Network (CN) 44 Credentials 208, 212 Cryptoanalysis 201 Cryptographic Components 200 Customer Premise Equipment (CPE) 51 Customer Relation Management (CRM) 133, 136 D Data Base Management System (DBMS) 149 Data Base Management Systems (DBMS) 148 Data Base Scheme 149 Data centric design 140 Data Encryption Standard (DES) 201 Data Interface 145, 147, 149 Data Link (DL) Layer - Logical Link layer (LL) 66 Data Record 163 Data Storage 162 Data Types 190 Datagram Service 23 DatagramConnection 126 Deadlock 79 Decay mechanism 116 Demilitarised Zone 199 Denial of Service Attacks 196, 197 Design Patterns 178 Development Platform 182 Development Process 174, 185 Device Layer 208 Dial tone 20
299
Differentiation and priorities 19 Digital Rights Management (DRM) 206 Digital Switching Network 21 Digital transponders 8 Directory 130, 213 Discovery Process 116 Distributed Object Model (DCOM) 128 Distributed objects 127 Distribution of functions 107, 133 DLL Boundary (Dynamic Link Library) 158 Domain Name Server 71 DSL 53 DSL-Modems 17 E Eavesdropping 195 EJB Container 184 E-Mail 14, 169 Embedded Systems 12, 154 Emulator Parameters 89 Endpoint Routing Protocol 117 End-Systems 65 End-to-End Connectivity 66 End-to-end encryption 203 Enterprise Application Integration (EAI) 153 Enterprise Java Beans 184 Enterprise Java Beans (EJB) 150 Enterprise Resource Planning (ERP) 133, 136 Entity Under Test (EUT) 84 Equipment Identification Register (EIR) 29 Event-State Table 82 Extranet 204 F Fading 26 FAX 30, 169 Federation 209 Fibre Channel (FC) 148 Fibre Channel Switch (FCS) 148 Fibre networks 8 File Server 109, 159, 162 Finite State Machine (FSM) 63, 71, 75
300
Firewal 199 Flow of Control 177 Font & Bitmap Server 160 Formal Process Description 76 Fragmentation of a message 22, 24 Frame Pointer 194 Framework Protocol 52, 140, 144 Framework protocol 58 Functional architecture 51, 133 Functional Entity 133, 135 G Garbage Collector 191 Gateway 18, 47, 147, 153 Gateway controller 47 Gateway controllers 18 Gateway GPRS Support Node (GGSN) 43 Gateway MSC 32 Gaussian Frequency Shift Keying (GFSK) 96 General Packet Radio Service (GPRS) 41 Generic Connection Framework (GCF) 125 getLocation() 141 Global Cell 44 Global States 78 Government 206 GPRS 25 Graphical User Interface (GUI) 160 Green pages 131 GSM 25, 27, 28 H Hacker 196 Hand-Over 41 Handover Number 35 Handset 25 Hardware Architecture 81 Hash Function 202 Hash values 214 Header 22 Headset Profile 104 High Speed Circuit Switched Data (HSCD) 30 HLR 32
301
HLR Back-End Processor 137 HLR Front-End Processor 137 Home Location Register (HLR) 29 Host 148 HRL Data Base 137 I Identification 34, 209 identifiers (IDs) 121 Identity 49, 198, 206 Identity Management 210 Identity Provider 209 IMEI 49 IMSI 49, 210 INAP Protocol Stack 86 Incoming Call 38 Index 171 INDICATION 68 Information Highway 6 InputConnection 126 Instant Messaging 136 Integrated Development Environment (IDE) 182 Integrity 198 Intelligent Network (IN) 54, 136, 139 Intelligent Network Application Protocol (INAP) 84 Interface 33 Interface Definition Language (IDL) 128 International Mobile Station Equipment (IMEI) 35 International Mobile Subscriber Number (IMSI) 35 International Organisation for Standardisation (ISO) 64 Internationsl GSM/UMTS Service Area 48 Internet 17, 51 Internet Inter Opject Protocol (IIOP) 128 Internet Protocol 17 Intranet 204 Intrusion Detection System (IDS) 200 IP addresses 71 IP bearer 50 IP over IP 43 IP packets 23 IP traffic 24
302
IP tunnel 43 IPSec 202 ISDN 14, 52 ISDN D-channel 20 ISO/OSI Reference Model 63, 64 Iu(PS) 47 J J2ME 125 Java 2 Enterprise Edition (J2EE) 184 Java 2 Micro Edition (J2ME) 117, 125 Java Data Objects (JDO) 150 Java Remote Method Invocation (RMI) 117, 128 Java RMI 121 Java Server Pages 184 JINI 117, 121 JXTA 116, 117 K Kernel 109 Keys 200 L LAPDm 34 last mile 6 Leases 116 Liberty Alliance 208 Local area networks 9 Local Exchange 15, 21 Local Mobile Subcriber Identity (LMSI) 35 Location Area 35, 49 Location Area Identifier (LAI) 49 Location Based Services 136, 198 Location Management 40 Location Update 40 LocationService 141, 143 Logical Link Control and Adaptation Protocol (L2CAP) 100 Logical Unit Number (LUN) 148 Look-up Server 123, 130 M MAC-Addresses (Media Access Control) 71 Macro-Cell 44 Man in the Middle 196, 197
303
Management Plane 68 Masquerade 197 Memory Management Unit 158 Message Body 171 Message Digest 202 Message Format 160 Message Header 171 Message Server MTM 170 Message Trace 93 Messages 14, 169 Messaging Framework 169 Methods 55 Metro networks 6 Micro Kernel 156 Micro-Cell 44 Middleware 128, 129, 135, 189 Mikro Kernel architecture 109 MMS 169 Mobile communication networks 24 Mobile Country Code (MCC) 50 Mobile Information Device Profile (MIDP) 125 Mobile Network Code (MNC) 48, 49, 50 Mobile phone 25, 133 Mobile Set (MS) 30, 51 Mobile Station 31 Mobile Station Roaming Number (MSRN) 35 Mobile Subscriber Identification Number (MSIN) 49 Mobile Subscriber Number (MSISDN) 34 Mobile Switching Centre (MSC) 28 Mobile Terminating Call 32 Mobility 25 Mobility Management (MM) 34 Mobility, indoor 25 Mobility, nomadic 25 Mobility, outdoor 25 Mobility, stationary 25 Modelling Tool 183 Model-View-Control design pattern 161 Model-View-Control Pattern 179 Modular Design 157
304
MSC Gateway 47 MSC Server 47 MTP 2 34 Multi-Media Message Service (MMS) 136 N Name Spaces 190 Network 134 Network Access Point 12, 13, 165 Network Address Translation (NAT) 119 Network architecture 15 Network design 51 Network Destination Code (NDC) 48 Network Layer 66 Network Operator 205 Network Service Architecture 144 Network Subsystem (NSS) 28 Network Termination 13 Next Generation Networks 18 Non-Repudiation 199 Numbers 70 O Object Definition Language (ODL) 147, 150 Object Diagram 180 Object distribution 141 Object Exchange Protocol (OBEX) 101 Object Oriented Database 150 Object Oriented Design 54, 156 Object Oriented Programming 127 Object Query Language (OQL) 150 Object Reference 129, 163 Objects 55, 149 Objects in a data base 149 Objects in an application 149 Open Service Access (OSA) 151 Operation and Maintenance Centre 29 Outgoing Call 36 OutputConnection 126 Overlay Networks 113 P Packet 19, 22
305
Packet Diagram 180 Packet Switching Network 3, 22 Packet Temporary Mobile Subscriber Identity (P-TMSI) 42 Paging 40 Passive Attacks 197 Patterns 173 Peer Discovery Protocol 118 Peer Information Protocol 118 Peer Resolver Protocol 117 PeerIDs 115 Peer-to-Peer Networks 113 Persistent data 133, 136, 149, 162 Persistent objects 151 Personal Area Network (PAN) Profile 105 Personal Digital Assistant (PDA) 155 Personal identity 208 Physical Layer 66 Pico Cell 44 PIN 31, 213 Pipe Binding Protocol 118 Pipes 116 Plain Text 201 Planning and Design 73, 173 Point of presence (POP) 8 Policies 199 Presentation Layer 66 Principal 208 Privacy 198, 210, 211 Private key 201 Privilege Boundaries 157 Process 71, 109 Process (SDL) 75 Process Boundaries 157 Process Graph 72 Process Stack 194 Profiler 184 Protective measures 199 Protocol 33, 52, 63 Protocol Control Information (PCI) 70
306
Protocol Data Unit (PDU) 69, 72, 84 Protocol engineering 63 Protocol Implementation Conformance Statement (PICS) 89, 92 Protocol Implementation eXtra Information for Testing (PIXIT) 89, 92 Protocol Stack 81 Protocol Tests 82 Pseudonyms 211 P-TMSI 49 Public Keys 201 Public Land Mobile Network (PLMN) 48 Q Quality of Service 19 R Radio Network Controller (RNC) 46 Radio Resource Management (RR) 34 Radio Subsystem (RSS) 28 Radio waves 26 Real Time Transport Protocol (RTP) 48 Redundant Arrays of Independent Disks (RAID) 148 Regression Tests 181 Relational Data Base 149 Remote Access (RAS) 204 Remote Method Invocation (RMI) 112, 122 Remote Procedure Call (RPC) 112 Rendezvous Agent 114 Rendezvous Protocol 117 REQUEST 68 Resolution 115 Resources 19, 20, 23, 133, 134, 189 RESPONSE 68 RFCOMM 99, 104, 168 RNC Identifier 50 Roaming 25, 40 Roaming agreement 209 Role 208 Root object 149 Routing 19, 23 Routing Area 49 Routing Area Identifier (RAI) 49 Runtime Platform 184
307
S SAML token 211 Sandbox 189 Satellites 8 Scalability 138 Secure connections 202 Secure Socket Layer (SSL) 202, 203 Security Alert 200 Security Assertion Markup Language (SAML) 210 Security checks, UMTS 50 Security Settings 165 Security Threats 195 Sequence Diagram 181 Sequence number 22 Serial Communication Server 165 Serial Port Profile 105 Serialisation 163 serialised 163 Server 72, 108 Server Function 160 Server Object 143 Server Side MTM 171 Server Side Socket Connection 167 Server Threads 157 Service Access Points (SAP) 69 Service Architecture 12, 51, 52, 60, 133 Service Concept (ISO/OSI RM) 68 Service Data Units (SDU) 69 Service Descovery 168 Service Discovery 113 Service Discovery Protocol (SDP) 100, 104 Service Discovery Protocol, Bluetooth 120 Service Discovery, Bluetooth 106 Service Discovery, JINI 123 Service Layer 16, 64, 68, 84 Service Logic 137 Service Provider 11, 205 Service Records 120 Service Registry 58 ServiceID 121
308
Services 9, 14, 29, 54 Serving GPRS Support Node (SGSN) 42 Servlets 184 Session 111, 170 Session Layer 66 Short Message Service (SMS) 30, 34, 169 Signal (SDL) 75 Signalling 20 Signed Midlets 193 SIM card 25, 29, 34 Simple Object Access Protocol (SOAP) 58, 128 Single-Sign-On 211 Smart Phones 155 Social Engineering 197 Socket Connection 165 Socket Engine 167 Socket Server 164, 166 Software Architecture 81 Software Development Kit (SDK) 174 Software Development Process 74 Software-Download 198 Source Code 190 Specification and Description Language (SDL) 63, 75 Stack Pointer 194 State Diagram 181 State transition table 85 States 72 Statistical multiplexing 19 Storage 134 Storage Area Network 147 Storage Area Network (SAN) 148 Storage Processor 148 Storage Unit (SU) 148 Store and Forward Routing 22, 23 Stream 163 Stream Cipher 201 Stream Store 162 StreamConnection 126 StreamConnectionNotifier 126 Structured Query Language (SQL) 150
309
Subscriber Identity Module (SIM) 31, 214 Subscriber lines 21 Subscribers 34 Suburban Cell 44 Supplementary Service (SS) 34 Switch (SW) 148 Switching and Routing layer 16 Symbian Operating System 154 System 75 System Tests 182 System Under Test (SUT) 84 T TDM traffic 24 TDMA 33 Telecommunication Application Integration (TAI) 153 Telecommunication networks 13 Telefax service 14 Telephone Exchange 20 Telephone networks 13 Telephone numbers 34 Telephone service 14, 29 Telephony Server 164 Temporary Mobile Subscriber Identity (TMSI) 35 Terminals 13, 15, 53, 154 Test configuration 85 Test Tool 183 Tests 74, 79, 181 Thread 109, 159 Ticket counter 207 Time division multiplex 15 TMSI 49, 210 Transit exchange 16 Transit Systems 65 Transitions 72 Transmission Layer 16 Transmission Links 65 Transport Layer 66 Transport of traffic 18 Trojan Horse 196 TV remote control 107
310
U UDP packets 23 Um 33 UML Diagram 180 UMTS 25, 44 UMTS MSC or SGSN Area 48 UMTS National Service Area 48 UMTS Phase 1 (Release 3 or Release 99) 46 UMTS Phase 2 (Release 4/5) 47 UMTS PLMN Service Area 48 UMTS Releases 46 UMTS Services 50 UMTS Terrestrial Radio Access Network (UTRAN) 44 UMTS-SIM card (U-SIM) 44 Unified Modelling Language (UML) 173 Uniform Resource Locator (URL) 56 Unit Tests 181 Universal Description Discovery and Integration (UDDI) 58, 130 Universal Mobile Telecommunication System (UMTS) 43 Universal Unique Identifier (UUID) 106, 115, 120, 168 Urban Cell 44 Use Case 175 Use Case Diagram 180 User 205 User Agent 112, 113, 114 User Interface 13 User Interface Data MTM 170 User Interface MTM 170 User Plane 20, 68 Users 12 USIM card 49 UTRAN Cell Identifier (UC Id) 50 UTRAN Registration Area (URA) 50 V Value chain 11 Version Control 184 Virtual channels 15 Virtual data storage 148 Virtual HLR 137 Virtual Private Network (VPN) 204
311
Virtualisation of persistant data 139 Virtualisation of Resources 51, 135 Virus 196 Visitor Location Register (VLR) 29 Voice over IP 4 VPN tunnel 204 W WAP 41 Web-Container 184 Web-Engineering 17, 51 Web-Services 51, 56, 117, 127 Web-Services Description Language (WSDL) 58, 141 Web-Services platform 143 White pages 130 Wide area networks 7 Windows Server 159 wireless 195 Wireless connections 195 Wireless network access 195 World Wide Web 14 Worms 196 Y Yellow pages 131

Tse Ss2004 Notes

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Tse Ss2004 Notes

Încărcat de

Drepturi de autor:

Formate disponibile

I

Stephan Rupp Gerd Siegmund

Telecommunication Software Engineering

Lecture Notes Edition: V 0.2, December 20, 2006

Contact: srupp@srupp.de Homepage: http://www.srupp.de

Stuttgart, July 2004

How this book is organised

How this book is organised

How this book is organised

How this book is organised

Chapter 6 Chapter 2 Chapter 5

How this book is organised

... change the way we live

Fig. 1-1 Telecommunication networks carry digital information (bits)

1.1.1 Circuit switched networks and packet switched networks

Jitter translates into delay

Fig. 1-6 How to deliver packets over a large distance?

1.1.2 Access networks and core networks

A road system for data traffic

Fig. 1-7 The information highway

Network design follows traffic

Fig. 1-11 Fig. 1-11 What about Satellites?

Local Area Networks

1.1.3 Services and applications

Fig. 1-13 Where do we use networks?

Services are used by people and machines

Fig. 1-17 How are networks organised?

Fig. 1-18 Network Access Points

Network Access Point

1.2.1 Communication model

Fig. 1-19 Communication Model

Source/ Sink Signal Transfer Message Transfer Application

Network Access Points

Services to support applications

Fig. 1-20 The route of a communication link through the network

called Party Verbindungsleitung

Telecommunication Network Network Node, Exchange

Allocation of resources for connections

1.2.3 The architecture of telecommunication networks

Fig. 1-21 Structure of a telecommunication network

Communication Link Access Line

efficient utilisation of resources

Fig. 1-22 Traditional Network Structure

Fig. 1-23 Separation of Transport and Control in Next Generation Networks

Internet + Transmission Network

Next Generation Networks

1.3 Concepts for Switching and Routing

1.3 Concepts for Switching and Routing

1.3.2 Connectionless exchange of messages

1.3.3 Circuit switched connections

1.3 Concepts for Switching and Routing

Local Telephone Exchange

Control Processor Signalling Signalling Bundle DierectionN

Circuit switched connection

Physical Connection (Crosspoint)

Telecommunication Network Network Switching Node (Exchange)

Fig. 1-26 Circuit Switched Connections

1.3.4 Store and forward routing

Fig. 1-27 Fragmentation of a message into packets

1.3 Concepts for Switching and Routing

Switching by storage and forward of packets

Network Switching Node

Fig. 1-28 Packet Switched Connections