Institute of Electronic Systems

Aalborg University

Future Mobile Networks:

Quality of Service Provisioning for Macro-Mobility in IMS-based Networks

Master Thesis / Group 05gr995-06gr112 / June 1, 2006

Aalborg University Institute of Electronic Systems

TITLE QoS provisioning for Macro-mobility in IMS-based networks PROJECT PERIOD September, 2005 - June, 2006 PROJECT GROUP Mobile Communications 05gr995/06gr1112 GROUP MEMBER German E. Castro D. SUPERVISORS Hans-Peter Schwefel Kim Lynggaard Larsen

ABSTRACT
Multimedia content is becoming a popular service for actual and next generations of mobile wireless networks; the IP multimedia subsystem (IMS) is a platform intended to provide such content in an efcient way. Additional to the IMS, the provision of the necessary Quality of Service (QoS) and performing handover (HO) are used in order to improve customer experience while using multimedia services. The perceived quality can be affected by the time for session setup and the QoS negotiation procedures, but this is not always an issue when it has to be done just once and at the establishment of the communication. Nevertheless, certain handover scenarios imply that the connection to the multimedia session has to be re-established and the QoS parameters re-negotiated; this can seriously affect the QoS perceived by the user. The aim of this project is to study and to propose strategies in order to provide QoS efcient reestablishment of an ongoing IMS real time multimedia session in case of macro mobility from the IMS perspective. The study is conducted by two approaches, rst by a theoretical analysis of the involved concepts and technologies and second by simulation using NS2 in order to validate concepts and to compare different solutions.

Number of reports 8 Total number of pages 130

Preface
This report has been written by German Castro on the 9th and 10th semester of the International Master of Science (M.Sc.) in Mobile Communications. It constitutes the documentation of the project done about Quality of Service Provisioning for Macro-Mobility in IMS-based Networks. It is primarily addressed to the supervisors, examiners and students at Aalborg University. The structure of the report is as follows, rst an introductory description of the problem is given and then the report is divided in three parts. The rst one, gives the theoretical background required in order to understand the components and the technologies involved. Once the background knowledge is given a second part is presented, it contains a redenition of the problem, the description of existing solutions and nally a conceptual proposal about how to solve the problem. In the third part the simulations and their results will be shown, followed by an analysis of the results and a comparison between the theoretical and simulation approach. The literature references are numbers in square brackets, e.g. [1], which means the rst material in the bibliography list. The equations are marked by numbers in brackets, e.g. (3.1), where the rst number indicates that the equation belongs to the third chapter, and the second number indicates that it is the rst equation in the chapter. The same method is also used for tables and gures. A copy of this report can be found at: http://kom.auc.dk/group/05gr995/05995/ Mobile Communications group 05gr995, Aalborg University. June 21, 2006.

German Castro

Acknowledgements
This work was partially supported by Siemens Communications Mobile, Munich, Germany. I would like to thank in particular to Gerhard Kuhn and Enzo Scotto di Carlo for their input and helpful comments. I would like to thank my supervisors, Hans-Peter Schwefel and Kim Lynggaard Larsen for their guidance, support, motivation and knowledge during this project. I want to thank specially Dorthe Sparre and Muhammad Imadur Rahman for their kind help always and all the professors and PhD students who helped me during the Master studies. I would also like to thank my parents and my brother for their support during my education and my life. Finally, I would like to specially thank Anyela, my wife, for being always at my side, helping me, supporting me and giving me all her happiness and unconditional love. German Castro June, 2006

ii

Contents
Preface Acknowledgements Abbreviation List 1 Introduction - General Project Description 1.1 Motivation . . . . . . . . . . . . . . . . 1.2 Overview . . . . . . . . . . . . . . . . 1.3 Possible Sub-problems . . . . . . . . . 1.4 Work to be done . . . . . . . . . . . . . i ii x 1 1 2 3 4

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

I
2

Theoretical Background
QoS and Handover 2.1 QoS Denition . . . . . . . . . . . . . . . . . 2.2 QoS Parameters . . . . . . . . . . . . . . . . . 2.2.1 Delay . . . . . . . . . . . . . . . . . . 2.2.2 Jitter . . . . . . . . . . . . . . . . . . 2.2.3 Loss Rate . . . . . . . . . . . . . . . . 2.2.4 Throughput . . . . . . . . . . . . . . . 2.3 Signaling for QoS . . . . . . . . . . . . . . . . 2.3.1 On-path / Off-path . . . . . . . . . . . 2.3.2 Soft-State / Hard-State . . . . . . . . . 2.3.3 Uni-directional / Bi-directional . . . . . 2.4 QoS Mechanisms . . . . . . . . . . . . . . . . 2.4.1 Differentiated Services (DiffServ) . . . 2.4.2 802.1P . . . . . . . . . . . . . . . . . 2.4.3 Other IP QoS provisioning mechanism 2.5 Handover Denition . . . . . . . . . . . . . . 2.6 Types of Handover . . . . . . . . . . . . . . . 2.7 Conclusions about handover . . . . . . . . . . iii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
6 6 6 8 8 8 8 9 9 10 11 11 11 12 12 15 15 15

3 Access technologies 3.1 WLAN . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Architecture of WLAN and modes of operation 3.1.2 QoS in WLAN . . . . . . . . . . . . . . . . . 3.1.3 Mobility in WLAN . . . . . . . . . . . . . . . 3.1.4 Authentication and association . . . . . . . . . 3.1.5 Authentication Methods . . . . . . . . . . . . 3.2 WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Architecture of WiMAX . . . . . . . . . . . . 3.2.2 QoS in WiMAX . . . . . . . . . . . . . . . . 3.2.3 Mobility in WiMAX . . . . . . . . . . . . . . 3.3 UMTS . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 UMTS Services . . . . . . . . . . . . . . . . . 3.3.2 Architecture of UMTS . . . . . . . . . . . . . 3.3.3 Packet Data Protocol (PDP) Context . . . . . . 3.3.4 QoS in UMTS . . . . . . . . . . . . . . . . . 3.3.5 Mobility in UMTS . . . . . . . . . . . . . . . 3.4 Other technologies . . . . . . . . . . . . . . . . . . . 4 IMS 4.1 Denition . . . . . . . . . . . . . . . . . . . . . . . . 4.2 IMS and SIP Architecture . . . . . . . . . . . . . . . . 4.3 QoS in IMS . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Description of functionalities . . . . . . . . . . 4.3.2 Requirements for IP Multimedia Core Network 4.3.3 Logical components for QoS management . . . 4.4 Mobility support in IMS . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

17 17 17 19 21 22 22 24 25 25 28 29 29 29 31 32 34 36 38 38 38 40 40 41 41 43

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

II Specic problem denition and possible solutions

5 Problem Statement 5.1 Access Network Architecture . . . . . . . . . . . . . . . . . . 5.1.1 Architecture description and important considerations 5.2 Layer 1/2/3 attachment . . . . . . . . . . . . . . . . . . . . . 5.3 PDP Context establishment . . . . . . . . . . . . . . . . . . . 5.4 QoS Management . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Call admission Control (CAC) . . . . . . . . . . . . . . . . . 5.6 Handover analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44
45 45 46 48 48 49 51 52 53 53 54 56

6 Proposed Solutions 6.1 Optimized SIP handover . . . . . . . . . . . . . . . . . . . . . . 6.2 QoS Context transfer . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Dropping calls in the CAC . . . . . . . . . . . . . . . . . iv

6.3 6.4

6.5

6.2.2 Service Downgrade in the CAC . . . . . . . . . . . . . . 6.2.3 Call queueing in the CAC . . . . . . . . . . . . . . . . . Bandwidth Broker . . . . . . . . . . . . . . . . . . . . . . . . . . Delayed QoS negotiation . . . . . . . . . . . . . . . . . . . . . . 6.4.1 Start with BE, update to maximum available BW and nally update to the requested BW when possible . . . . . 6.4.2 Accept maximum available BW and update to the requested BW when possible . . . . . . . . . . . . . . . . . . . . . 6.4.3 Mantain BE until requested BW is available . . . . . . . . Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57 58 58 59 61 61 63 64

III
7

Setup, results and conclusions

Simulation 7.1 Simulation tool . . . . . . . . . . 7.2 Important Considerations . . . . . 7.3 IMS simulator . . . . . . . . . . . 7.3.1 Description and Topology 7.3.2 Session setup simulation . 7.4 QoS Simulation Structure . . . . . 7.4.1 Description and Topology 7.4.2 Trafc . . . . . . . . . . . 7.4.3 CAC . . . . . . . . . . . 7.4.4 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65
66 66 66 67 68 69 71 72 73 75 76 81 81 81 84 87 91 91 94 94 94 94 95 95 97

Results comparison and analysis 8.1 Improvements simulation . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Optimized SIP handover . . . . . . . . . . . . . . . . . . 8.1.2 QoS Context Transfer . . . . . . . . . . . . . . . . . . . 8.1.3 Bandwidht Broker . . . . . . . . . . . . . . . . . . . . . 8.1.4 Delayed QoS negotiation - Mantain BE until requested QoS is available . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Combined simulation of improvements - Performance evaluation . Conclusion 9.1 Access Network . . 9.2 IMS/SIP signaling . 9.3 QoS . . . . . . . . 9.4 Future Work . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

References Appendixes v

A QoS A.1 QoS and network performance . . . . . . . . . A.1.1 Reliability . . . . . . . . . . . . . . . . A.1.2 Availability/Accessibility . . . . . . . . A.1.3 Dependability . . . . . . . . . . . . . . A.1.4 Signaling Plane . . . . . . . . . . . . . A.1.5 Handover performance . . . . . . . . . A.2 QoS Mechanisms . . . . . . . . . . . . . . . . A.2.1 Multiprotocol Label Switching(MPLS) A.2.2 Resource Reservation Protocol (RSVP) A.2.3 Integrated Services (IntServ) . . . . . . A.3 Applications and QoS . . . . . . . . . . . . . . A.3.1 Inelastic . . . . . . . . . . . . . . . . . A.3.2 Elastic . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

98 98 98 98 99 99 99 99 99 100 100 100 100 101

B WLAN 102 B.1 PHY Layer in 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 102 B.2 Data Link Layer in 802.11 . . . . . . . . . . . . . . . . . . . . . 104 C WIMAX C.1 MAC generalities . . . . . . . C.1.1 MAC packet format . C.1.2 MAC Data transport . C.1.3 Bandwidth allocation . C.1.4 MAC support of PHY D SIP 106 106 107 107 108 108 110

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

E Programming tools 112 E.1 Overview of NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 112 E.1.1 DiffServ module . . . . . . . . . . . . . . . . . . . . . . 113

vi

List of Figures
1.1 2.1 3.1 3.2 3.3 3.4 3.5 3.6 3.7 4.1 4.2 5.1 5.2 5.3 5.4 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 General scenario . . . . . . . . . . . . . . . . . . . . . . . . . . Relation between user-perceived QoS and network layered model . ISO and WLAN . . . . . . . . . Infrastructure mode for WLAN . QoS in WLAN - EDCF . . . . . Message exchange for 801.1x . . UMTS architecture . . . . . . . PDP context . . . . . . . . . . . Bearer service in UMTS [www3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 7 18 18 20 24 30 32 33 39 40 46 47 49 49 54 54 55 56 57 58 59 60 60 62 62 63

IMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . SIP signaling for session intiation and QoS setup . . . . . . . . . Access Network Architecture . . . . . . IP addresses within WLAN or WiMAX . Procedure for attaching to the network . Procedure for establishing PDP contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re-authorization message ow for optimization of handover . . . Message ow of session Re-establishment . . . . . . . . . . . . . PDP context generation . . . . . . . . . . . . . . . . . . . . . . . QoS context transfer and activation . . . . . . . . . . . . . . . . QoS context transfer with CAC dropping calls . . . . . . . . . . . QoS context transfer with negotiated downgrade . . . . . . . . . . QoS context transfer with Call queueing in the CAC . . . . . . . . Core Network Architecture including Bandwidth Broker . . . . . . Session re-establishment for a Bandwidth Broker transfering the context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.10 Message ow for multiple updating of QoS . . . . . . . . . . . . . 6.11 Message ow for updating of QoS starting with the maximum available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.12 Message ow for updating of QoS starting with Best Effort . . . . vii

7.1 7.2 7.3 7.4 7.5 7.6 7.7 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13

IMS simulation Input/Output block diagram . . . . . . . . . . . IMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . Message ow for session establishment . . . . . . . . . . . . . Total time Vs BS detection time . . . . . . . . . . . . . . . . . . QoS simulation Input/Output block diagram . . . . . . . . . . . Simulation topology . . . . . . . . . . . . . . . . . . . . . . . . Edge and Core routers implementation in the simulated scenario

. . . . . . .

68 68 69 70 72 72 80 82 83 83 84 85 85 88 88 89 90 90 92 93

Simulation architecture for Optimized SIP handover . . . . . . . . Register/Reauthotization comparing Optimized and Unoptimized solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Register/Reauthotization and Invite/Re-establishment comparing Optimized and Unoptimized solutions . . . . . . . . . . . . . . . . . Setup for simulating Context Tranfer between PDGs and ASNGs . Simulated architecture for signaling in QoS Context Transfer . . . Simulated architecture for trafc in QoS Context Transfer . . . . . Time in queue for a HO video call according to percentage of VoIP sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time in queue for a HO video call according to percentage of Video sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time in queue for a HO video call according to percentage of HTTP sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . Setup for simulating Bandwidht Brokers and Context Transfer . . Simulated architecture for signaling for the Bandwidth Broker approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Available BW during the time of simulation . . . . . . . . . . . . Used BW Vs time . . . . . . . . . . . . . . . . . . . . . . . . . .

D.1 SIP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 E.1 User view of NS . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

viii

List of Tables
3.1 3.2 3.3 6.1 7.1 7.2 7.3 7.4 7.5 7.6 7.7 8.1 8.2 8.3 8.4 8.5 8.6 8.7 Variants of the 802.16 standard . . . . . . . . . . . . . . . . . . QoS classes in UMTS. [www3] . . . . . . . . . . . . . . . . . . . UMTS bearer attributes dened for each trafc class. [2] . . . . . Combination of improvements to be tested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 34 35 64 70 71 74 74 76 77 78 82 86 86 87 89 91 92

Input parameters for the IMS/SIP simulation model Approximated times for IMS session setup . . . . Simulation Parameters . . . . . . . . . . . . . . . Trafc Parameters in Simulation . . . . . . . . . . Assumed EB for the different trafc sources . . . . DSCPs for the different trafcs and priorities . . . RED queue parameters . . . . . . . . . . . . . . .

Time comparison for Optimized SIP handover . . . . . . . . . Handover delay for QoS Context Transfer . . . . . . . . . . . . Handover delay for QoS Context Transfer in Service downgrade Session characteristics for call queueing . . . . . . . . . . . . . Handover delay for QoS Context Transfer . . . . . . . . . . . . Comparison between AF and BE in a 100% load scenario . . . . QoS requirements for the different trafcs . . . . . . . . . . . .

B.1 802.11 WLAN Speeds. . . . . . . . . . . . . . . . . . . . . . . . 103 B.2 Modulation and Coding for WLAN OFDM Data Rates. . . . . . 104

ix

Abbreviation List
3G 3GPP AAS AF AK AN AP APC APN APR ARQ AS ASN ASNG ASP ATM BB BBM BE BER BPSK BR BS BW BWA C/I C/N CID CIR CN CRC CS DHCP Third Generation Third Generation Parthership Program Adaptative Antenna System Assured Forwarding Authorization Key Access Network Access Point AP Controller Access Point Name Ap Router Automatic Repeat Request Application Server Access Serving Network Access Serving Network Gateway Application Server Provider Asynchronous Transfer Mode Bandwidht Broker Break-Before-Make Best Effort Bit Error Rate Binary Phase Shift Keying Bandwidth Request Base Station Bandwidth Broadband Wireless Access Carrier-to-Interference Ratio Carrier-to-Noise Ratio Connection Identier Commited Information Rate Core Network Cyclic Redundancy Check Convergence Sublayer Dynamic Host Conguration Protocol

DL DRM DSCP E2E EB EDCF EF FA FDD FER FFT GGSN GPRS GSM HO HUMAN HSS IMS IP IP-CAN LAN LER LOS LSB LSP MA MAC MAN MBB MIP MN MPLS MSB MSH MSS NAR NLOS NRT NS NS2 OFDM OFDMA OSI

Downlink Domain Resource Manager DiffServ Code Point End-to-End Equivalent Bandwidth Enhanced Distribution Coordination Function Expedite Forwarding Foreing Agent Frequency Division Duplex or Dluplexing Frame Error Rate Fast Fourier Transform Gateway GPRS Support Node General Packet Radio Service Global System for Mobile Communications Handover High-Speed Unlicensed Metropolitan Area Network Home Subscriber Server IP- Based Multimedia Subsystem Internet Protocol IP Connectivity Access Network Local Area Network LAbel Edge Routers Line-of-Sight Least Signicant bit Label Switched Paths Mobility Agent Medium Access Control Layer Metropolitan Area Network Make-Before-Break Mobile IP Mobile Node Multiprotocol Label Switching Most Signicant Bit Mesh Mobile/Fixed Subscriber Station New Access Router Non-Line-of-Sight Non Real Time Networks Simulation Networks Simulation 2 Orthogonal Frequency Division Multiplexing Orthogonal Frequency Division Multiple Access Open System Interconnection

xi

P-CSCF PAR PDF PDG PDP PDSN PDU PHB PHS PHSF PHY PLMN PMP PSTN PTT QAM QoS QPSK RAN RED RNC RNG RNSN RRM RT SAP SBLP SDP SDU SGSN SIP SLA SNR SPI SS TDD TDM TDMA TE TFT ToS

Proxy Call State Control Function Previous Access Router Policy Decision Function Packet Data Gateway Packet Data Protocol Packet Data Serving Node Protocol Data Unit Per Hope Behaviour Payload Header Suppression Payload Header Supression Field Physical Layer Public Land Mobile Network Point-to-Multipoint Public Switched Telephony Network Push to Talk Quadrature Amplitude modulation Quality of Service Quadrature Phase-Shift Keying Router Access Network Random Early Detection Radio Network Controller Ranging Radio Network Serving Node Radio Resource Management Real Time Service Access Point Service Based Local Policy Session Description Protocol Service Data Unit Serving GPRS Support Node Session Initiation Protocol Service Level Agreement Signal-to-Noise Ratio IPsec Security Parameter Index Subscriber Station Time Division Duplex or Duplexing Time Division Multiplexing Time Division Multiple Access Terminal Equipment Tracc Flow Template Type of Service

xii

UDP UE UL UMTS UTRAN VLAN VLR VoIP VoWIP WiMAX WirelessMAN WirelessHUMAN WLAN WRR

User Datagram Protocol User Equipment Uplink Universal Mobile Telecommunications System UMTS Terrestrial Radio Access Network Virtual Local Area Network Visited Location Register Voice Over IP Voice Over Wireless IP Worldwide Interoperability for Microwave Access Wireless Metropolitan Area Networks Wireless High-speed Unlicensed Metropolitan Area Networks Wireless Local Area Network Weighted Round Robin

xiii

Chapter 1

Introduction - General Project Description

1.1 Motivation

Actual and future applications in mobile communications are becoming more and more complex in terms of the amount of data to be transfered and the technological requirements of the new contents. One of the challenges for the service providers is to attract their users to use these new applications and at the same time provide them in a efcient way and billing them accurately. Real time multimedia content is an example of this type of content, it can be very heavy in terms of amount of data and being real time represents extra complexity from the technological and quality point of view. To deal with this multimedia content, 3GPP (Third Generation Partnership Project) created the IP-Based Multimedia Subsystem (IMS). IMS is a platform that allow mobile operators to offer services based on Internet applications independently from the actual conectivity (UMTS, WLAN, among others). The IMS provides session and connection control as well as an application service framework. All entities in an IMS network use the Session Initiation Protocol (SIP) to communicate one with another. SIP provides session to a user equipment (UE) connecting to the IMS. Using SIP, the IMS offers services such as user registration, instant messaging or presence services. SIP manages multimedia sessions, mobility and QoS. The quality of the offered services, can be seen or meassured by many different parameters or categorized in many different ways, in the case of multimedia services one of the most important parameters (if not the most important one) is the human perception. The way the user perceives the quality of the multimedia content being presented, is what can make a difference in terms of what the user is aiming to pay for.

Introduction - General Project Description

Different access technologies provide different quality of service capabilities due to diverse transmission conditions like coverage, data rate capabilities, among others; each one of them at certain cost/price. Switching between access technologies or the simultaneous use of them can be useful in order to increase capabilities or decreasing costs. The aim of this project is to analize possible solutions for providing real time multimedia services under certain quality conditions in the cases where a user is switching from one access network to another, it is important to notice that the use of IMS as a core is implied. In other words, what mainly motivates this project is to study the implications that the inter-technology handover brings to the QoS in a connection in the IMS platform during real time multimedia transfer and to propose possible solutions to the related issues.

1.2 Overview

Figure 1.1: General scenario A general scheme of the actual scenario is presented in Figure 1.1, it shows a communication between an application server (AS) and a user equipment (UE). Additional to these components two additional block are present, the rst one is the IMS platform and transport and the second one are the access networks. The UE is moving from the rst access network (AN) to the second one. There are several options about the access networks, in the present case the idea is to work with access technologies that allow to manage the QoS and that are new or at least that are expected to be in use or in the market for a considerable period of time, for examples WiMAX, WLAN, UMTS. When the UE is moving from one AN to another, it is for example from WLAN to WiMAX and viceversa

1.3 Possible Sub-problems

or from WLAN to UMTS and viceversa. When changing the access network, it is important to notice that each AN has its own schemes or strategies for providing the QoS. Therefore, the rst part of the theoretical study presents the reader a common denition of quality of service, the parameters that can affect it and show the elements that dene the QoS. After the denition of QoS for the project, the issues related to the handover are presented, as shown in Figure 1.1 the UE is performing a HO from one access network to another, so, dening handover and studying different categories of it is important in order to delimit the problem denition to the type (or types) of handover that can be more relevant for the present case of study. After the presentation of these two concepts, it is important to understand how different access networks work. Aspects like the components of the network, their functionality and the way each one of them manages the mobility and the QoS are going to be studied in order to determine the most relevant aspects to be considered while changing from one access network to another. Finally, when a UE is moving from one access network to another, it is not only relevant to the session within the access networks, as shown in Figure 1.1 the IMS & transport are also part of the communication between the AS and the UE so it is worth to know how the IMS works, its components, how the QoS is managed within the IMS and how the handover impacts current sessions and their related QoS.

1.3

Possible Sub-problems

From this rst analysis some issues can be expected for the project, some of them are shown below: Determine the entity in charge of triggering the handover. Select the most appropiated components of the network to negotiate the QoS. Choosing between different handover scenarios: Breaking the rst connection before having a second one. Simultaneous connectivity to both access networks: Improvement via temporary multicast. Flow splitting. Dene the components that are more relevant for the whole problem in order to be simulated.

Introduction - General Project Description

After the theoretical study has been done and during the simulation more subproblems are expected, because of that in chapter 5 a redenition of the problem statement will be presented.

1.4 Work to be done

The research work in this project will be conducted rst by a theoretical analysis of the problem, where a study of the technical elements will be performed in order to determine the specic problem(s) to be studied, as well as the most relevant components for the case of study. Then, a conceptual solution will be proposed based on the background knowledge, current existing solutions, previous studies about similar problems and of course personal contribution. Finally, simulation work will be performed. In order to do this, a simulation tool has to be chosen and as mentioned before, the most relevant parameters and/or components have to be included in the simulation test bed in order to have enough tools to analyze the problem and compare the solutions. The main purpose of having theoretical and simulation approaches is to prove the concepts and also propose and/or develope new solutions from the results obtained by testing.

Part I

Theoretical Background

Chapter 2

QoS and Handover

2.1 QoS Denition
QoS stands for Quality of Service and it can refer to the probability of a telecommunication network meeting a given trafc contract for a specic user and/or content. In many cases it is used informally to refer to the probability of a particular packet succeeding in passing between two points in the network under certain conditions [www1][www2]. Additionally, the idea of implementing QoS is strongly related with features as distinguishing trafc into different types, features, demands to the networks, and of course to charge the customers differently according to these. When talking about real time applications, the term QoS becomes more specic and can be understood as user-perceived QoS. This means that even if the basis for providing QoS are related to technical parameters, they are aimed to satisfy agreements mainly based on certain quality provided at the user interface. In order to study the user-perceived QoS in an IP-based network architecture with hetereogeneous wireless access, the factors that inuence it are presented in Figure 2.1. It shows the relation between the network layer model and the user-perceived QoS; It can be seen that the user-perceived QoS depends on application QoS which at the same time is depending on network QoS [5]. The present case of study focus on Network QoS, meaning layers below layer ve in the protocol stack.

2.2 QoS Parameters

There are some factors that have an impact on the QoS in a network, the most signicant ones are listed below [5]: Network architecture and transmission paths (routing) Processing delays (e.g., for encryption) Congestion/trafc loads

2.2 QoS Parameters

Figure 2.1: Relation between user-perceived QoS and network layered model

QoS and Handover

Link properties (in particular for wireless links) Failure events Mobility events Even if the main concern for real time aplications is the user-perceived QoS as mentioned before, there must exist clear, measurable metrics that specify quantiable QoS parameters of the system components, these are delay, jitter, loss rate and throughput [2].

2.2.1

Delay

It is the elapsed time for a packet to traverse the network from the instant a packet is generated at the source until it reaches the destination or the arrival of a correct aknowledgement of the successful reception of the sent packet is received. At the network layer, the end-to-end packet latency is the sum of processing, transmission, queuing and propagation delays.

2.2.2

Jitter

It is dened as the variation of the delay encountered by similar packets having the same source and destination through the network, the jitter requirement can mainly affect real time streaming applications. Jitter is generally included as a performance parameter, since it is very important at the transport layer in packet data systems, due to the inherent variability in arrival times of individual packets. Services intolerant of delay variation will usually try to reduce it by means of buffering. However, delayed data arrivals make data useless resulting in receiver buffer underow and early arrival can lead to receiver buffer overow.

2.2.3

Loss Rate

Loss rate refers to the percentage of data loss among all the delivered data in a given transmission time interval, it can be evaluated in bit lavel (Bit Error Rate BER), packet level (Packet Error Rate - PER) or frame level (Frame Error Rate FER), loss rate requirements apply to all classes of applications. Real time (RT) applications might tolerate a limited amount of data loss depending on the error resiliency of the decoder and the type of application; whereas non real time (NRT) applications, typically, have much more strict requirement on data loss.

2.2.4

Throughput

It can be dened as the amount of data from a source to a destination processed by the protocol for which throughput is to be measured during a specic time interval. The throughput, differs between protocol layers, for example, a loss of one IP packet that generates a loss of also one packet in the application layer, impacts the

2.3 Signaling for QoS

meassure of the throughput in a different way, because it is possible that there are less packets in the application layer, because, each one of the these packets can be composed and therefore affected by many packets in the IP layer. The throughput, can be expressed as a peak rate or an average rate depending, for example, if the rate at which packets are transmited is constant or not.If retransmissions are involved in protocols, the throughput is reduced due to gaps in the transmission while waiting for acknowledgements.

2.3

Signaling for QoS

QoS signaling refers to the exchange of information between network elements that is aimed to setup a specic QoS treatment for certain data packets. Examples of QoS signaling are [5]: Communicate and negotiate QoS requirements for a certain type of data packets. Discover the next relevant QoS-signaling aware entity in the network. Exchange information about current QoS state like available bandwidths or buffer-occupancy in terminals or network elements. Messages modicating the QoS state. It is important to notice that in some cases, QoS signaling can be part of the user-data packets, like for example, when a congestion notication bit in the header of the packets is being setted or cleared by the routers in order to generate notication. A categorization of the QoS signaling can be done by the following properties:

2.3.1

On-path / Off-path

If the packets containing the signaling information follow exactly the same path as the data packets, the approach implements on-path signaling also called pathcoupled signaling, it is characterized by: QoS resources are managed locally by each router. Signaling is triggered by the terminals and follows the data path. End-to-end reservations are set up hop-by-hop by a signaling protocol that installs states in routers.

10

QoS and Handover

The RSVP protocol is an example of such approach. The signaling messages normally install or modify QoS state of the network elements that it crosses. As a disadvantage, RSVP is not mobility-aware and because of that, it does not support a change of the IP address. By the other hand, an off-path (or path-decoupled) signaling, the signaling messages are directed by entities like bandwidth brokers (BB) or domain resource managers (DRM), the main functions of these entities are to: Handles the resources for one domain. Maintains an up-to-date image of the resources and reservations in its domain. Requests resources from DRMs in adjacent domains along the data path in order to provide end-to-end reservations. These central QoS entities in most of the cases have other interfaces like for example COPS based (RFC2748 and RFC 3084) in order to control entities like router in the data-paths. There are different QoS mechanisms on the data path that can be used in the off-path signaling, such as DiffServ or IntServ which are explained in subsections 2.4.1 on the facing page and A.2.3 on page 100. An advantage of the use of a DRM over an on-path signaling scheme is that if a router fails, the failure is not directly noticed by the terminals in the case of hop-by-hop signaling and re-establishment may require new signaling from the terminals. In comparison, a DRM can be notied of local changes and can adapt the reservation. On the other hand, the DRM itself can fail but its reliability can be improved by the use of redundant systems.

2.3.2

Soft-State / Hard-State

Signaling messages commonly install some kind of QoS state in the entities that they cross. If this state has to be modied or erased with the help of additional signaling messages, it is called a hard QoS state. The danger of this hard state is that improper use of signaling or loss of connectivity could result in permanent, un-used QoS state and will consume resource unnecessarily. This problem can accumulate over the time and nally block any network activity. In the soft QoS state, the state is automatically removed, for example, after certain timeout intervals. If state needs to be maintained over a longer period of time, refresh messages have to be sent by the initiating component. This adds additional signaling overhead but it has the advantage that no unneeded QoS state blocks resources.

2.4 QoS Mechanisms

11

2.3.3

Uni-directional / Bi-directional

In many applications, like video streaming, the QoS requirements are non-symmetrical with respect to the direction of transmission. This mean that even if signaling messages are being exchanged in both directions, unidirectional QoS signaling establishes only state with respect to one transmission direction. For uni-directional signaling, it can be distinguished between receiver initiation and sender initiation. In case of on-path signaling problems can arise with receiver initiated signaling if routers through the network are not symmetric, for example if a message send from receiver to sender passes through different entities than in the reverse direction.

2.4

QoS Mechanisms

There are several mechanisms to provide the QoS over a network, the most relevants for the present project are:

2.4.1

Differentiated Services (DiffServ)

The DiffServ provides a mechanism for enabling different treatment of packets in an IP network, this is done by marking (using) the type-of-service (TOS) bits previously dened in the IP standard, so that differential levels of service can be given to different aggregate ows at the entry points to the network. According to this, DiffServ takes a very local view of the problems involved in providing a certain quality of service. DiffServ species the called Per Hop Behaviour (PHB), which determines how a router or switch should forward the packet to the next node in the network, the requested PHB is stored in the IP packet. There are three dened PHBs: Assured forwarding (AF) Denes four trafc classes, each of which can have three drop-precedence values for a total of twelve. Expedited forwarding (EF) Provided for low latency, low jitter, low loss, and assured bandwidth. Best-effort forwarding The Differentiated Services architecture does not have a well-dened concept of a service class. Instead it leaves the classication of trafc to the nodes at the edge of a DiffServ network. The classication used there is based on the SLA existing between the DiffServ network and its neighboring networks. DiffServ contains no signaling protocol so the edge nodes must in general be manually congured to match the Service Level Agreement, and therefore the resource reservation in the

12

QoS and Handover

nodes is more or less static. The main disadvantage of DiffServ is that it can not guarantee a specic QoS, especially on an end-to-end link. Because no signaling is involved, it has no prior knowledge of whether a specic ow will receive adequate QoS even if it is marked preferentially, if a route or router is heavily congested all packets will be rejected whether they are priority packets or not. Similarly, because there is no signaling, applications cannot adjust their requirements in advance in response to network conditions and many IP applications do adjust to network conditions in this way, given the chance.

2.4.2

802.1P

IEEE 802.1p specication enables layer two switches to prioritize trafc and perform dynamic multicast ltering. The prioritization specication works at the MAC framing layer. The standard also offers provisions to lter multicast trafc to ensure it does not proliferate over layer two switched networks. The IEEE 802.1p is an extension of the IEEE 802.1Q (VLANs tagging) standard. The 802.1Q standard species a tag that appends to an Ethernet MAC frame. The VLAN tag has two parts: The VLAN ID (12-bit only used by the 802.1Q) and Prioritization (3-bit) eld used by the 802.1P, the three-bit eld for prioritization, allows packets to be grouped into various trafc classes. It can also be dened as best-effort QoS at layer two and it is implemented in network adapters and switches without involving any reservation setup. 802.1p trafc is simply classied and sent to the destination; no bandwidth reservations are established. By the use of the prioritization eld, IEEE 802.1p establishes eight levels of priority. The highest priority is seven, which might go to network critical trafc such as Routing Information Protocol (RIP). Values ve and six might be for delay sensitive applications such as interactive video and voice. Data classes four through one range from controlled load applications such as streaming multimedia and business critical trafc down to loss eligible trafc. The zero value is used as a best-effort default, invoked automatically when no other value has been set.

2.4.3

Other IP QoS provisioning mechanism

Scheduling and buffering are common mechanisms for handling IP packets and important in order to implement QoS differentiation between User Equipments. Scheduling When multiple queues are sharing a common transmission media, a scheduler is needed in order to decide how to pick up packets from each queue to send out.

2.4 QoS Mechanisms

13

Generally a packet scheduler is expected to have the following properties: Low time complexity to select and forward a packet. Treat different ows fairly. Provide low worst-case delay and delay variation. Simple enough to be implemented efciently. When talking about schedulers, the simplicity and time-complexity properties collide with fairness and delay-bound properties. Schedulers with short term fairness and strict delay bound generally have high time complexity and are hard to implement. The simplest scheduler is called Round Robin (RR) and it works by selecting a packet from each queue in a circular way, so all the queues have equal chances to send. Weighted round robin (WRR) is an extension of RR, and allows the bandwidth between queues to be distributed according to weights. Each time a non-empty queue is examined, it may send as many packets as its weight indicates. The WRR carry several improvements like: To use bytes or chunks of bytes, instead of packets. This gives greater granularity on the resource to be distributed. Allow queues to be selected several times within short intervals, instead of being selected many times in series. There could be two implementation methods of WRR: a standard WRR and a Weighted Interleaved round point (WIRR) implementation. Another type of scheduler is Priority (PRI). With PRI the queue with highest priority will always be served rst until it is empty, then the second highest priority queue will be served so that the lowest priority queue can only be picked when all the other queues have been emptied. Queuing The simplest queue algorithm for routers is Drop Tail. The way it works is that when there is sufcient buffer space Drop Tail queue accept any incoming packet but when the buffer is full it simply drops any new arriving packet. RED (Random Early Detection) is a congestion avoidance algorithm that can be implemented in routers, RED queue computes a weighted average queue size to detect a congestion before the queue becomes really full, because a sustained long queue is a sign of network congestion. As any packet arrives, a RED gateway checks the weighted average queue size and compare with it is minimum and maximum thresholds, if there is congestion, it either drops a packet or sets a bit in a header eld of the packets according to certain probability. There are three phases for RED gateways which drops packets:

14

QoS and Handover

Normal operation: If the average queue size is less than the minimum threshold, no packets are dropped. Congestion avoidance: If the average queue size between the minimum and maximum thresholds, packets are dropped with a certain probability. This probability is a function of the average queue size, so that larger queues lead to higher drop probabilities. Congestion Control: If the average queue size is greater than the maximum threshold, all incoming packets are dropped. The effects of RED gateways in a network will be: Control the average queue size, and reduce the average queuing delay. Act as a low-pass lter, so the burst trafc gets easier to be dropped. Avoid synchronization of TCP connections. A TCP based trafc source will reduce its transmitting rate when some of its burst packets will be dropped which cause RTT time-out. But the Drop Tail queue drops all the packets in congestion which cause that all the TCP sources reduce their transmitting rate at the same time and the total throughput suddenly becomes very low after the congestions period. RED drops packets randomly before the buffer gets overowed, which prevents this synchronization problem, reduces trafc oscillation effect and hence increase the overall throughput.

2.5 Handover Denition

15

2.5

Handover Denition

Handover (HO) can be understood as the process by which an active Mobile Node (MN - MN is the same as a UE and this two terms are going to be used during the project), changes its point of attachment to the network, or when such change is attempted. The access network may provide features to minimize the interruption to sessions in progress. It is also called handoff. [6].

2.6

Types of Handover

As can be seen in [6], there are many different kinds of handovers, classied according to the aspects involved, like: The scope: Which refers about from where to where is moving the MN. The control: This classication refers to the node initiating the handover, the node having the primary control over the handover process, the node collecting the measurements for supporting the decision of when and where to handover to, if the handover is initiated by the new or the previous Access Router (AR) and nally if the handover is proactive or reactive (Planned or Unplanned respectively). Connectivity to Access Routers: Depending if a new connection is made before or after the old one is broken, the handover can be classied as Makebefore-break (MBB or Soft Handover) or Break-before-make (BBM or Hard Handover)

2.7

Conclusions about handover

As mentioned in the previous chapter, the QoS for real-time applications is related with the user perception of the quality, according to this, the present project aims to improve the quality of service re-establishment, so it gets reected in application and user- perceived QoS and therefore contributes to get closer to a seamless handover, understandig this concept as a handover in which even if in practice some degradation in service is to be expected, some protocols, applications or end users do not detect/perceive any change in the service capability, security or quality. It also means that the aim is to have a smooth and fast handover, implying respectively reducing the packet loss and the handover latency. Even if this reduction does not directly imply having a seamless handover, the idea is to study solutions that may help to decrease the impact of the handover compared with the case where no additional solution is implemented. From the scope of the handover point of view, there are some denitions of types of handover that can overlap with each other, like for example, the case of

16

QoS and Handover

Inter-technology handover and Vertical handover. The rst one is dened as a handover between equipment of different technology and the second one involve MNs moving between access point of different type. Even if one is talking about equipment and the other about AP, a clear distintion is not made. Also, for example the differences between a horizontal and vertical handover can be vague. For example, a handover from an AP with 802.11b WLAN link to an AP with 802.11g WLAN link may be considered as either vertical or horizontal handover, depending on an individuals point of view. Understandig the horizontal handover as the one that involves MNs moving between access points of the same type. The actual case can be seen as an Inter-technology / vertical handover which despite of the overlaping denitions, implies that the MN is moving between access points of different type and technology, for example, from WLAN to WIMAX and/or viceversa. The sub-classications of the handover from the control type talk by themselfs. Noticing that this ve handover types are independent, and the present handover case should be classiable according to each one of this types. Node initiating the handover: This can depend on the AN architecture and will be discussed later when studying estrategies for the HO that will be used in the present project. Node having the primary control: This is also related to the AN technology and can depend for example if the QoS is managed on-path or off-path, a BB can be the entity also controlling the HO procedure. Node collecting the measurements: It is similar to the previous one. AR initianting the HO: If the case of study is a sudden break up of the communication it can result that the new AR is the one initiating the HO and the previous one is not completely involved. Proactive or reactive: If the case of study is a sudden break up of the ongoing communication, this is a clear reactive handover, otherwise it can be proactive. In case of classifying according to the connectivity to the access routers, both cases result interesting for the present study, the BBM gives the challenge of reestablish in an efcient way the QoS of an ongoing session that was suddenly interrupted and the case of MBB has to set minimum times in order to have the full QoS provisioning pre-established before being able to move completely to the second connection, the second one also has the additional issue of managing the data content during the time the handover is being done, this in case a simultaneous connection to both access networks is possible.

Chapter 3

Access technologies
There are many different access technologies in the market, each one of them intended to serve specic user requirements and dealing with situations as handover or QoS managing in a particular way. This chapter presents background knowledge about different access technologies, their architecture and the way they deal with situations as HO and QoS; the emphasis is done in those technologies which are strong candidates to be used for the present project.

3.1

WLAN

A wireless LAN (WLAN) is a data transmission system, designed to provide locationindependent network access between computing devices by using radio waves rather than a cable infrastructure. The IEEE ratied 802.11 specication as the standard for wireless LANs. Like all IEEE 802 standards, the 802.11 standard focus on the bottom two levels of the ISO model, the physical (PHY) layer and data link layer. Any LAN application, network operating system or protocol, like for example TCP/IP, will run on an 802.11-compliant WLAN as they run over Ethernet. See Figure 3.1

3.1.1

Architecture of WLAN and modes of operation

802.11 denes two pieces of equipment, a wireless station and an access point (AP), the last one acts as a bridge between the wireless and wired networks. An access point usually consists of a radio, a wired network interface like for example 802.3 and a bridging software. The access point acts as the base station for the wireless network, aggregating access for multiple wireless stations onto the wired network. The 802.11 standard denes two modes: infrastructure mode and ad hoc mode. In infrastructure mode the wireless network consists of at least one access point connected to the wired network infrastructure and a set of wireless end stations.

18

Access technologies

Figure 3.1: ISO and WLAN This conguration is called a Basic Service Set (BSS). An Extended Service Set (ESS) is a set of two or more BSSs forming a single subnetwork. This mode can be seen in Figure 3.2

Figure 3.2: Infrastructure mode for WLAN The Ad hoc mode (also called peer-to-peer mode or Independent Basic Service Set - IBSS) is simply a set of 802.11 wireless stations that communicate directly with one another without using an access point or any connection to a wired network. This mode is useful for quickly and easily setting up a wireless network

3.1 WLAN

19

anywhere that a wireless infrastructure does not exist or is not required for service but, is not relevant for the present case of study and therefore will no longer be considered. As the situation for the actual project implies that the WLAN has to be connected within the IMS and a full scheme of QoS provisioning has to be established, additional components to the infraestructure mode in an ESS have to be included, this elements for the interconnection are discussed further in the second part of this document.

3.1.2

QoS in WLAN

As users experience the convenience of wireless connectivity, they are beginning to demand support for the same applications that they run over wired networks. Because wireless bandwidth availability is restricted, quality of service is increasingly important in 802.11 networks. On WLANs based on this standard, all users share the networks capacity and no packet gets priority over any other. This usually is not a problem with typical data applications, such as exchanging e-mail and browsing the Web, but with voice calls and streaming video, packets have to get across the network at the right time. The original 802.11 MAC protocol was designed with two modes of communication for wireless stations. The rst, Distributed Coordination Function (DCF), is based on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA), sometimes referred to as listen before talk. In this mode, a station waits for a quiet period on the network, begins to transmit data and detect collisions. DCF provides coordination, but it does not support any type of priority access of the wireless medium. The second mode is called Point Coordination Function (PCF) and it supports time-sensitive trafc ows. Wireless access points periodically send beacon frames to communicate network identication and management parameters specic to the wireless network, between the sending of beacon frames, PCF splits the time into a contention-free period and a contention period. With PCF enabled, a station can transmit data during contention-free polling periods, however, PCF has not been widely implemented because the technologys transmission times are unpredictable. Because DCF and PCF do not differentiate between trafc types or sources, the IEEE developed enhancements in 802.11e to both coordination modes in order to facilitate QoS. This standard denes QoS mechanisms that gives support to bandwidth-sensitive applications such as voice and video by prioritizing trafc and preventing packet collisions and delays, which should improve the experience of the users while maintaining backward-compatibility with current 802.11 standards.

20

Access technologies

The enhancement to DCF - Enhanced Distribution Coordination Function (EDCF) - introduces the concept of trafc categories in the MAC layer. Each station has eight trafc categories, or priority levels. Using EDCF, stations try to send data after detecting the medium is idle and after waiting a period of time. This time is dened by the corresponding trafc category called the Arbitration Interframe Space (AIFS). A higher-priority trafc category will have a shorter AIFS than a lower-priority trafc category. Thus stations with lower-priority trafc must wait longer than those with high-priority trafc before trying to access the medium. To avoid collisions within a trafc category, the station counts down an additional random number of time slots, known as a contention window, before attempting to transmit data. If another station transmits before the countdown has ended, the station waits for the next idle period, after which it continues the countdown where it left off. No guarantees of service are provided, but EDCF establishes a probabilistic priority mechanism to allocate bandwidth based on trafc categories. In Figure 3.3, an example of how EDCF works, is shown. Three main steps can be distinguished from there [www4]:

Figure 3.3: QoS in WLAN - EDCF 1. Devices with trafc categories of high, medium and low, have data to send on the WLAN. After the rst device nishes sending a packet, the Access Point acknowledge its receipt. 2. After the acknowledgement, comes the AIFS which is based on the trafc priority. The lower is the priority, the longer is this waiting time. 3. Once this AIFS ends, the stations has a random contention window and begin to countdown over it. Once this contention window is over the device begins to transmit and the other stations (normally the ones with lower priority)

3.1 WLAN

21

suspend the countdown once the device who has the access begins to transmit a packet. The way 802.11e aims to extend the polling mechanism of PCF is with the Hybrid Coordination Function (HCF). A hybrid controller polls stations during a contention-free period. The polling grants a station a specic start time and a maximum transmit duration. EDCF appears to be gaining more early acceptance than HCF.

3.1.3

Mobility in WLAN

The 802.11 MAC layer is responsible for how a client associates with an access point. When an 802.11 client enters the range of one or more APs, it chooses an access point to associate with, based mainly on signal strength. Once it is accepted by the access point, the client tunes to the radio channel to which the access point is set. Periodically it surveys all 802.11 channels in order to assess whether a different access point would provide it with better performance characteristics. If it determines that this is the case, it reassociates with the new access point, tuning to the radio channel to which that access point is set. Reassociation usually occurs because the wireless station has physically moved away from the original access point, causing the signal to be weak or due to considerable changes in the radio communication characteristics, or just because of high network trafc on the initial access point. The last case is known as load balancing, since its primary function is to distribute the total WLAN load in an efcient way across the available wireless infrastructure. The process of associating and reassociating users with APs in a dynamic way can be used in order to setup WLANs with very broad coverage, this coverage can be achieved by the use of overlapping cells through the areas that are inteded to be covered. The overlapping can employ techniques such as channel reuse. While the standard denes how a station associates with APs, it does not dene how APs track users as they roam about, either at layer 2 between two APs on the same subnet or at layer 3 when the user crosses a router boundary between subnets. The rst issue is handled by vendor-specic inter-AP protocols and therefore it may vary in performance. If the protocol is not efcient, there is a chance of packets being lost while the user moves from one access point to another. The second one can be handled by layer 3 roaming mechanisms as for example the implementation of a DHCP that just implies that in the new subnetwork, the user obtains a new IP address or by estrategies like mobile IP (MIP). The issue of the layer 3 mobility is highly related with the access network architecture and will be discussed in detail in the following part of the document about the WLAN being interconnected with the IMS platform.

22

Access technologies

3.1.4

Authentication and association

The rst step for connecting to a wireless LAN is authentication, it is the process through which a wireless node has its identity veried by the network to which the node is attempting to connect. Sometimes this process is null, meaning that, although both the client and access point have to proceed through this step in order to associate, there is really no special identity required for association. In infrastructure mode, the client begins the authentication process by sending an authentication request frame to the access point, then the access point will either accept or deny this request and notify the station of its decision with an authentication response frame. The authentication process can be accomplished at the access point or the access point might pass along this responsibility to an upstream authentication server. This server would perform the authentication based on a list of criteria and return the results to the access point so that it could return the results to the client station. Once the authentication is completed, the station sends an association request frame to the access point who replies to the client with an association response frame either allowing or disallowing association. The complete process of authentication and association has three distinct states: 1. Unauthenticated and Unassociated: In this initial state, the wireless node is completely disconnected from the network and unable to pass frames through the access point. Access points keep a table of client connection states known as the association table. 2. Authenticated and Unassociated: In this second state, the wireless client has passed the authentication process, but is not yet allowed to send or receive data through the access point. Normally, clients pass the authentication stage and immediately proceed into the association stage very quickly, (milliseconds) rarely at the access point the step of authenticated could be seen, it is far more likely that unauthenticated or associated are seen. 3. Authenticated and Associated: In this nal state, the wireless node is completely connected to the network and able to send and receive data through the access point to which the node is connected (associated). At the access points association table, it can be seen that this client is fully connected and authorized to pass trafc through the access point.

3.1.5

Authentication Methods

The authentication process for a client means a series of steps with the access point that vary according to the authentication procedure. The IEEE 802.11 standard species two methods of authentication: Open System Authentication (OSA) and Shared Key Authentication (SKA). This methods do not provide end-to-end or

3.1 WLAN

23

user-to-user authentication, therefore, some additional authentication mechanisms were added to the specication, one of them is the EAP/802.11x. The three of them are explained in the following subsections: OSA OSA is not really authentication, because the access point accepts the mobile station without verifying the identity of the station. The AP authenticates a client when the client simply responds with a MAC address during a two-message exchange, the process is as follows: 1. The client makes an active probe request. 2. The client receives response from the neighbours AP. 3. After a timeout, the client starts the authentication. 4. As OSA is null authentication, the AP allows the client to enter the network. 5. The association procedure starts. 6. The client is associated with the AP and can pass data through the network. SKA SKA uses criptography in order to have a secure communication between the client and the AP. It uses the principle of challenge-response, the client is assumed to know a shared key previous to the start of the authentication process, the process is as follows: 1. The client makes an active probe request. 2. The client receives response from the neighbours AP. 3. After a timeout, the client starts the authentication. 4. The client receives an unencrypted challenge from the AP. 5. The client encrypts it and send it back to the AP. 6. If the challenge is encrypted correctly, the AP allows the client to enter the network. 7. The association procedure starts. 8. The client is associated with the AP and can pass data through the network.

24

Access technologies

EAP/802.1x Extensible Authentication Protocol (EAP) uses legacy OSA authentication-association before 802.1x authentication. It has two main characteristics. First, it separates the message exchange from the process of authentication by providing an independent exchange layer and second, the authentication process can be extended by adopting a new mechanism without necessarily affecting the EAP layer. The message exchange can be seen in Figure 3.4.

Figure 3.4: Message exchange for 801.1x

3.2 WiMAX
Worldwide Interoperability for Microwave Access (WiMAX) is the name given to the type of network that makes Broadband Wireless Access (BWA) available for the IEEE standard 802.16, therefore, in this section the standard 802.16 and the name WiMAX will be used without making any distinction. The 802.16, as many other IEEE standards mainly focuses on the PHY and MAC layers. There are three main variants of WiMAX (see Table 3.1). The most relevant for the actual case of study and the one that will be studied in this section is the 802.16e because is the only one supporting mobility. It is worth to mention that this standard is still on drafts and has not been completely approved, so, some of the characteristics mentioned in this document about it, are subject to be changed

3.2 WiMAX

25

in the nal approved standard documentation even if changes in the fundamentals are not expected.

3.2.1

Architecture of WiMAX

According to the standard, there are two types of equipment: Base Station - BS is an equipment providing connectivity, management and control Subscriber Stations (SS) Subscriber/Mobile Station - SS/MS is an equipment set providing connectivity between subscriber and BS There are two main network architectures mentioned in the 802.16 standard, the rst one is called mesh (MSH), in this architecture SSs are capable of forwarding trafc from and to multiple other SS. The second architecture and the one that can be used for the present project is called PMP (Point-to-Multipoint), it works with a centralized BS dealing with multiple SS The wireless links for PMP are managed by a central BS and a sectorized antenna that is capable of handling multiple independent sectors simultaneously. Within a given frequency channel and antenna sector, all stations receive the same transmission. The BS is the only transmitter operating in this direction, so it transmit without having to coordinate with other stations, except for the overall TDD that may divide time into uplink and downlink transmission periods. SS share the uplink to the BS on a demand basis. Depending on the class of service utilized, the SS may be issued continuing rights to transmit or the right to transmit may be granted by the BS after receipt of a request from the user. Within each sector, users adhere to a transmission protocol that controls contention betwen users and enables the service to be tailored to the delay and bandwidth requirement of each user application. This is accomplished through different types of uplink scheduling mechanisms. These are implemented using unsolicited bandwidth grants, polling, and contention procedures. For example, contention may be used to avoid the individual polling of SSs that have been inactive for a long period of time but, the use of polling simplies the access operation and guarantees that application receive service on a deterministic basis if it is required.

3.2.2

QoS in WiMAX

The principal mechanism for providing QoS is to asociate packets traversing the MAC interface into a service ow identied by a connection identier (CID). A service ow is a unidirectional ow of packets providing a particular QoS, the SS and BS provide this QoS according a set of QoS parameters dened for the service

26

Access technologies

Description

802.16a Initial version of 802.16, line-of-sight communication to xed devices

802.16-2004 Revised version of 802.16 standard, non-line-ofsight communication to xed or portable devices July 2004 From 1H06 10-66GHz and <11GHz focused on 2.5GHz (licensed), 3.5GHz (licensed) and 5.8GHz (unlicensed) Up to 75 Mbit/s with 20MHz channels. 4-18 Mbit/s in 5 MHz channels

Standard completed product availabe Spectrum

Jan 2003 1H05 < 11GHz

802.16e Enhanced version of standard to support mobility and adds enhancements to the implementation of OFDMA Expected 2H05 2007 <11GHz but Europe likely to be 3.5GHZ and/or 2.5 - 2.69GHz

Peak raw data rate

Up to 75 Mbit/s with 20MHz channels. 4-18 Mbit/s in 5 MHz channels

Mobility

Fixed

Fixed and portable

Channel bandwiths

20, 25 and 28 MHz

Typical cell radius

5-8km NLOS; maximum range of 50km based on LOS depending on tower height, antenna gain and transmit power Applications Fixed outdoor: E1/T1 service for enterprise, backhaul for hotspots, limited residential broadband access End-user Externally mounted box equipment with antenna

Selectable channel bandwiths between 1.25 and 20MHz, with up to 16 logical sub-channels 5-8km NLOS; maximum range of 50km based on LOS depending on tower height, antenna gain and transmit power Fixed indoor: portable broadband access for residential users

Up to 75 Mbit/s with 20MHz channels. Mobility offers to 80% performance of xed usage model Fixed, portable and mobility up to 100km/h, regional roaming Same as 802.16-2004

3-5km NLOS

Nomadic broadband consumers

/ mobile access for

Portable box with built-in antenna

PC cards initially, laptops and other mobile devices later

Table 3.1: Variants of the 802.16 standard

3.2 WiMAX

27

ow. A service ow is characterized by a set of QoS parameters such as latency, Jitter and throughput assurances. In order to standarize operation between the SS and BS, these attributres include detail of how the SS request uplink bandwidth allocation and the expected behavior of the BS uplink scheduler. Each service ow has a set of parameters to dene it, the most relevant are: Uplink/Downlink indicator Maximum sustained trafc rate: Is the peak information rate of the service at the input of the system, it does not include transport, protocol or network overhead. Maximum trafc burst Minimum reserved trafc rate Maximum latency The 802.16e also dene data delivery services for the mobile network, this services are associated with a predened set of QoS-related service ow parameters. The types of data delivery services and their meanings are: Unsolicited Granted Service (UGS): is to support real-time applications generating xed-rate data, the parameters for this service are: Tolerated jitter SDU size Minimum reserved trafc rate Maximum latency Request/Transmission Policy Unsolicited Grant Interval Real Time - Variable Rate Service (RT-VR): supports real-time data applications with variable bit rates requiring guaranteed data rate and delay, the related parameters are: Maximum Latency Minimum reserved trafc rate Maximum sustained trafc rate Trafc priority Request/Transmission Policy Unsolicited Polling Interval

28

Access technologies

Non-Real Time - Variable Rate (NRT-VR): support applications that require a guaranteed data rate but are insensitive to delays, the parameters that dene this service are: Minimum reserved trafc rate Maximum sustained trafc rate Trafc priority Request/Transmission Policy Best Effort (BE): is for applications with no rate or delay requirements, the parameters are: Trafc priority Request/Transmission Policy Extended Real-Time Variable Rate (ERT-VR): support real-time applications with variable data rates that require guaranteed data and delay, for example VoIP with silence supression. The parameters required for this service are: Maximum Latency Tolerated jitter Minimum reserved trafc rate Maximum sustained trafc rate Trafc priority Request/Transmission Policy Unsolicited Grant Interval

3.2.3

Mobility in WiMAX

In the 802.16e protocol there are four steps dening the HO process of a MS migrating the air-interface provided by one BS to the air-interface of another, these steps are: 1. Cell reselection Using the information from neighbor BS, requesting schedule scanning intervals or sleep intervals to scan the MS evaluates potential target BS to perform handover. 2. HO Decision & Initiation The decision of handover can be originated at the MS or at the serving BS, the handover begins with that decision for an MS to handover from the serving BS to a target BS. 3. Synchronization to Target BS downlink MS synchronizes to downlink transmissions of the target BS in order to obtain downlink and uplink parameters

3.3 UMTS

29

4. Ranging It is important to notice that the standard also denes a HO process optimization, this assumes the transfer of the operational state between the serving BS and the target BS (timers, counters, MAC state machines, CIDs, service ows information and other connection information), so BS and MS do not exchange re-entry messages after ranging before resuming normal operations.

3.3

UMTS

UMTS stands for Universal Mobile Telecommunications System, UMTS represents an evolution in terms of capacity, data speeds and new service capabilities from second generation mobile networks. UMTS has been specied as an integrated solution for mobile voice and data with wide area coverage.

3.3.1

UMTS Services

UMTS offers teleservices (like speech or SMS) and bearer services, which provide the capability for information transfer between access points. It is possible to negotiate and renegotiate the characteristics of a bearer service at session or connection establishment and during ongoing session or connection. Both connection oriented and connectionless services are offered for Point-to-Point and Point-to-Multipoint communication. Bearer services have different QoS parameters for maximum transfer delay, delay variation and bit error rate. Offered data rate targets are: 144 kbits/s satellite and rural outdoor. 384 kbits/s urban outdoor. 2048 kbits/s indoor and low range outdoor. UMTS will also have a Virtual Home Environment (VHE). It is a concept for personal service environment portability across network boundaries and between terminals. Personal service environment means that users are consistently presented with the same personalised features, user interface customization and services in whatever network or terminal, wherever the user may be located. UMTS also has improved network security and location based services.

3.3.2

Architecture of UMTS

A UMTS network consist of three interacting domains; Core Network (CN), UMTS Terrestrial Radio Access Network (UTRAN) and User Equipment (UE). In the gure 3.5 an example of the structure of an UMTS network is shown. The specic network elements and their roles in UMTS are:

30

Access technologies

Figure 3.5: UMTS architecture User Equipment Is the equipment used to access the UMTS Services, it has two main components: The rst one is the UMTS Subscriber Identity Module (USIM) that stores the identity of the user, operator and service provider and user service prole and the second one is the radio terminal. The complete UE is capable of managing PDP contexts.

UTRAN The UTRAN provides the air interface access method for the UE. In UTRAN, Wideband Code Division Multiple Access (WCDMA) technology was selected for radio access. It is a Direct Sequence CDMA system and it has two basic modes of operation: Frequency Division Duplex (FDD) and Time Division Duplex (TDD). The components of the UTRAN are: Node B: Is a logical node equivalent to a base station and is responsible of converting data between radio interface (Uu) and UTRAN (Iub). It performs Modulation/Demodulation, CDMA Physical Channel coding, Forward Error Correction, Closed loop power control and participate to radio resource management (RRM). RNC: It is the control equipment for one or more Node-Bs. It manages radio resources, admission control, channel allocation, handover control, among others.

3.3 UMTS

31

Core Network The basic Core Network architecture for UMTS is based on GSM network with GPRS. All equipment has to be modied for UMTS operation and services. It is divided in circuit switched (CS) and packet switched (PS) domains. Some of the elements of the circuit switched domain are Mobiles Services Switching Center (MSC), Visitor location register (VLR) and gateway MSC (GMSC). Packet switched elements are Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). Some network elements, like Equipment Identication Register (EIR), Home Location Register (HLR), and Authentication Center (AUC) are shared by both domains. MSC and GMSC: The MSC is a switching node that supports circuit-switched connections, user mobility and handover procedures. GMSC is a special MSC, which serves as an interface to various external networks. HLR and VLR: The HLR is a database in the users home system which keeps all the user prole. The VLR is a database similar to the HLR which locate the network a user is currently operating. SGSN and GGSN: The SGSN carries out routing information in PS domain and manages the authentication and current user position, like HLR/VLR in CS domain. GGSN offers interfaces to external PS netwroks like the Internet.

3.3.3

Packet Data Protocol (PDP) Context

The PDP context is a data structure present in both the SGSN and the GGSN which contains the subscribers session information during subscriber active session. A mobile needs to acquire and congure itself with a PDP address (i.e. an IP address when the PDP is IP). Mobile may use single or multiple PDP addresses simultaneously as per requirement. A PDP context must be established (to get PDP address) and activated in the PS CN domain and on the mobile, before any user packets destined or originated from a PDP address can be transported over a PS core network. A PDP context is maintained between the SGSN and the GGSN and carries the following information: PDP address used by the mobile to send and to receive PDP packets. Routing Information used by the network node to determine where to forward a user packet such as an identier (established between SGSN and GGSN for this PDP context) and an Access Point Name (APN). APN is a logical name used by the SSGN to determine which GGSN is suitable for a mobile and the determination of the service request by user or address of an access point in an external packet network to which user packet should be forwarded by GGSN.

32

Access technologies

QoS Prole QoS Prole Subscribed: Describe QoS characteristics subscribed by mobile user. QoS Prole Requested: Describe QoS characteristics currently requested by mobile user. QoS Prole Negotiated: QoS provided by the network to the mobile at the current time. The way a mobile can have different PDP context with different APN is shown in gure 3.6

Figure 3.6: PDP context

3.3.4

QoS in UMTS

Network Services are considered end-to-end, this means from a Terminal Equipment (TE) to another TE. An End-to-End Service may have a certain Quality of Service (QoS) which is provided for the user of a network service. Although 3GPP species signaling procedure of QoS requirements like trafc classes or delay parameters, among others, it does not provide the mechanism to be used during the user-data transfer: QoS parameters need to be mapped to appropiate Radio Resource Management (RRM), strategies in the UTRAN and IP-layer mechanisms in the CN.

3.3 UMTS

33

To realise a certain network QoS, a Bearer Service with clearly dened characteristics and functionality is to be set up from the source to the destination of a service. It includes all aspects to enable the provision of a contracted QoS. These aspects are among others the control signalling, user plane transport and QoS management functionality. A UMTS bearer service layered architecture is depicted in gure 3.7, each bearer service on a specic layer offers its individual services using services provided by the layers below.

Figure 3.7: Bearer service in UMTS [www3] There are four different classes of QoS are mentioned below, their characteristics and an example of them are given in Table 3.2. Conversational class Streaming class Interactive class Background class The UMTS bearer attributes dened for each trafc class are presented in Table 3.3.

34

Access technologies

Trafc class Fundamental characteristics

Example of application

Conversational Real Time -Preserve time relation (variation) between information entities of the stream -Conversational pattern (stringent and low delay ) Voice

Streaming Real Time -Preserve time relation (variation) between information entities of the stream

Interactive Best Effort -Request response pattern

Background Best Effort -Destination is not expecting the data within a certain time

-Preserve payload content

-Preserve payload content

Streaming video

Web browsing

Telemetry, e-mails

Table 3.2: QoS classes in UMTS. [www3]

3.3.5

Mobility in UMTS

Generally we can distinguish between intra-cell handover and inter-cell handover. For UMTS the following types of handover are specied: Handover 3G -3G (i.e. between UMTS and other 3G systems) FDD soft/softer handover FDD inter-frequency hard handover FDD/TDD handover (change of cell) TDD/FDD handover (change of cell) TDD/TDD handover Handover 3G - 2G (e.g. handover to GSM) Handover 2G - 3G (e.g. handover from GSM) One cause for performing a handover is that due to its movement a user can be served in another cell more efciently (like less power emission, less interference). It may however also be performed for other reasons such as system load control. Some of the different parameters that are measured over the air interface in order to determine if to make a handover or not are: Intra-frequency measurements: Measurements on downlink physical channels at the same frequency as the active set. A measurement object corresponds to one cell.

3.3 UMTS

35

Trafc class Maximum bitrate (kbps) Delivery order Maximum SDU size (octets) SDU format information Delivery of erroneous SDUs Residual BER SDU error ratio Transfer delay (ms) Guaranteed bit rate (kbps) Trafc handling priority Allocation / Retention priority Source statistics descriptor

Conversational < 2048 Yes/No 1500 or 1502 X Yes/No/5 x 102 10

6

Streaming < 2048 Yes/No 1500 or 1502 X Yes/No/5 x 102 10

6

Interactive < 2048 - overhead Yes/No 1500 or 1502

Background < 2048 - overhead Yes/No 1500 or 1502

Yes/No/4 x 103 6 x 10 8 103 10 6

Yes/No/4 x 103 6 x 10 8 103 10 6

102 10 5 100 (max) < 2048

101 10 5 250 (max) < 2048

1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3

Table 3.3: UMTS bearer attributes dened for each trafc class. [2]

36

Access technologies

Inter-frequency measurements: Measurements on downlink physical channels at frequencies that differ from the frequency of the active set. A measurement object corresponds to one cell. Inter-RAT measurements: Measurements on downlink physical channels belonging to another radio access technology than UTRAN, for example GSM. A measurement object corresponds to one cell. Trafc volume measurements: Measurements on uplink trafc volume. A measurement object corresponds to one cell. Quality measurements: Measurements of downlink quality parameters, for example downlink transport block error rate. A measurement object corresponds to one transport channel in case of BLER. A measurement object corresponds to one timeslot in case of SIR (TDD only). UE-internal measurements: Measurements of UE transmission power and UE received signal level. UE positioning measurements: Measurements of UE position. The UE supports a number of measurements running in parallel. The UE also supports that each measurement is controlled and reported independently of every other measurement.

3.4 Other technologies

As mentioned before, there are many other access technologies in the market and there are other new arising, like can be for example GSM/GPRS, bluetooth, Hyperlan, 802.15, 802.20. All of them would have something interesting to offer to the present case of study, nevertheless, due to reasons like the ones mentioned below, some of them were discarded or it was just considered that they could be part of future research projects. The main reasons for prefering the technologies described above are: The discarded technology has similar functionalities compared with the chosen ones, this can cause an overlap and the market penetration of the chosen is bigger, which makes it more used and therefore more interesting for being studied. Even if any technology has a strategy for dealing with matters related to the QoS, its structure could not be strong enough like to be considered to be studied in here. The data transfer rates are not enough like to make them strong candidates for dealing with heavy multimedia applications like in the present case.

3.4 Other technologies

37

Their network and layer architecture does not make it likely to be easily connected to the IMS. And nally, maybe just because they are to far on time in order to be standarized and therefore to be a reality in the market, so all the research would be based on guessing.

Chapter 4

IMS
4.1 Denition
The IP-based Multimedia Subsystem is a framework designed by the 3GPP (Third Generation Partnership Project) that allows mobile operators to offer services based on Internet applications independently from the actual connectivity (GPRS, WLAN, among others) even if it was at rstly dened as an extension to UMTS. The IMS provides session and connection control as well as an application services framework. The IMS framework allows operators to manage IP-based multimedia services in an efcient and protable way. It species interoperability and roaming; and it provides bearer and resource control, user charging and security [8]. All entities in an IMS network use the Session Initiation Protocol (SIP) to communicate with each other. SIP provides session to a user equipment (UE) connecting to the IMS, using SIP, the IMS offers services such as User Registration, Instant messaging of Presence Services. The IMS also supposes that services can be deployed externally from the IMS framework, letting PLMNs and other third parties develop their own services through Application Servers (AS) [1]. However, using SIP does not provide so good performance regarding mobility management [13], especially in cases where a change of IP address takes place. Such change can occur when the end users terminal changes its access network (e.g. WiMAX to/from WLAN) and gets into a new network domain. As SIP is a protocol from the OSI session layer (OSI L5), it is supported by lower layer protocols such as IP; thus an IP address change brings down existing SIP sessions and induces long delays because of session re-establishment.

4.2 IMS and SIP Architecture

The architecture of the IMS is illustrated in Figure 4.1, only the signaling path is shown due to the fact that the path of the data ow is direct between the UE and the

4.2 IMS and SIP Architecture

39

AS. In the Figure, additional to the paths it is also important to notice the entities present in the IMS architecture, those are:

Figure 4.1: IMS architecture P-CSCF (Proxy-CSCF) The Proxy Call State Function (P-CSCF) is the rst contact point to the IMS for the UE. It is a Proxy in the sense that it accepts requests and processes them internally, or forwards them towards the nal destination. S-CSCF (Serving-CSCF) The S-CSCF main functionality is to perform the session control services for the UE. It also mantains a session state needed for support of services. I-CSCF (Interrogating-CSCF) The I-CSCF is the contact point for all connections going to or coming from an external network. It is used in the registration process by assigning an S-CSCF (and obtaining its address) to the EU performing registration. HSS (Home Subscriber Server) The HSS holds the subscriber data for a given identity. It is contacted for registration purposes and setting QoS parameters. Although SIP is a protocol built to establish sessions, it corresponds to the session layer in the OSI model. Its main purpose is to provide management for mobility, data trafc and security.

40

IMS

Figure 4.2 shows the SIP messages used for initiation of a session as well as the messages needed for the activation of a secondary PDP context.

Figure 4.2: SIP signaling for session intiation and QoS setup

4.3 QoS in IMS

This section presents rst the QoS functionalities of the IMS as well as its requirements on the core network, then the logical components involved in managing QoS are shown.

4.3.1

Description of functionalities

Quality of Service performs the following functions, from two different points of view: In the control plane Translation function- This translates the QoS requirement of the communication into a set of QoS parameters for service establishment or modication. Translation is performed between external QoS requirements and the provided AN service, and between the QoS parameters of the different AN internal services. Admission/Capability control- This function maintains information about the available resources for a network entity. It determines for each service request or modication whether the requested QoS can be provided by this entity.

4.3 QoS in IMS

41

Subscription control- The IMS framework must make sure the user requesting a service has previously suscribed to it, and that is being charged accordingly. In the user plane Mapping function- This function changes the QoS parameter indication provided with a packet according to that indication relevant for the next service, at transition from one service to another. Classication function- This assigns packets to the established services, according to the related QoS parameters. The related QoS parameters are derived from the packet header, or are xed for all packets of a specic UE service access point (if a physical or logical interface supports different QoS parameters without analysing each packet). Resource Manager- In the IP Connectivity Access Network (IP-CAN), this function supervises the resources for the Radio Access Bearer and allocates resources on request for services establishment or modication. Trafc conditioners- They mantain the signalling and user data trafc of an individual service, of aggregated services or of a whole network within certain limits. These limits are dened by specic QoS parameters. Services with different QoS parameter levels shall be supported by the trafc management functions. These functions ensure the provision of the QoS negotiated for a service.

4.3.2

Requirements for IP Multimedia Core Network

1. The UE shall be able to establish a dedicated signalling or use a generalpurpose IP-CAN bearer for IMS signalling trafc. 2. All messages from the UE that use a dedicated signalling IP-CAN bearer shall have their destination restricted to the P-CSCF assigned to this UE, and towards DHCP and DNS servers whitin the IMS operators domain where the P-CSCF is located.

4.3.3

Logical components for QoS management

1. Packet Data Protocol (PDP) Context Is a logical association between a UE and an Access Point Name (APN) running across a network. As the UMTS network was the base for the IMS and is itself based on the GPRS architecture, the concept of a PDP context is still fundamental to the IMS even though it is now supposed to be access network independent. This enables the access network to recognize which UE to send incoming data to.

42

IMS

A secondary PDP context allows differentiated QoS under one APN. For example, a user can receive an audio streaming ow from a web server while is browsing a website and each one of these services will be treated different according to the specic requirements of the content. 2. Trafc Flow Template(TFT) Is a packet lter supplied by the UE, allowing the GGSN/PDG to classify packets received from the external network into the proper secondary PDP context, it applies only for the downlink. Each TFT contains a combination of the following attributes: Source Address and Subnet Mask Destination Port Range Source Port Range IPsec Security Parameter Index (SPI) Type of Service (ToS) (IPv4)/ Trafc Class (IPv6) and mask Flow Label (IPv6)

3. Service Based Local Policy (SBLP) Manages access control and QoS parameters on both uplink and downlink. It denes what trafc the operator allows on its network and overrides the TFTs when it is applied. In any case, QoS parameters are included in PDP contexts. The SBLP checks the following parameters: Destination IP address Destination port number Transport Protocol ID Media direction information Direction of the source (needed as the SBLP is applied on both uplink and downlink) Media type information Bandwith parameters Indication of forking/non-forking.

4. Policy Decision Function (PDF) Is a logical entity co-located with the PCSCF and is the decision point of the SBLP. The decisions are made based on the information obtained from the P-CSCF. 5. The last component is the access router located between the UE and the PCSCF, it performs the tasks assigned to the Gateway GPRS Support Node (GGSN) in a UMTS/IMS implementation. This Gateway is the SBLP Enforcement Point, in fact, the PDF has a protocol interface with the gateway (Go Interface) which supports the transfer of information and policy decision point and the IP BS Manager in the gateway (following the COPS framework).

4.4 Mobility support in IMS

43

4.4

Mobility support in IMS

The following procedures have to be considered by a UE when moving during an IMS session: If a UE explicitly deactivates the IP-CAN bearer that is being used for IMS signalling, it shall rst de-register from the IMS (while there is no IMS session in progress). If a UE explicitly deactivates the IP-CAN bearer that is being used for IMS signalling while an IMS session is in progress, the UE must rst release the session and de-register from the IMS and then deactivate the IP-CAN bearers. If a UE acquires a new IP address, the UE shall re-register in the IMS by executing the IMS registration These concepts underline that in case of performing a handover that implies a change of the IP address, the service from the IMS may have to be re-established, meaning with this that a new invite message has to be send and all the consequences that this can bring as a new conection.

Part II

Specic problem denition and possible solutions

Chapter 5

Problem Statement
5.1 Access Network Architecture

As presented before, WiMAX and WLAN handle the QoS by the use of strategies at the MAC layer and their respective standards only dene parameters from this layer and below. Therefore, as a rst step it is important to have a complete access network architecture in which QoS can be implemented and that is able to fully interconnect with the IMS platform. The proposal of an architecture for WiMAX and WLAN has clear similarities with the one of UMTS as can be seen in Figure 5.1. In order to simplify the understanding of the network, it can be divided into three different parts or sub-networks:

1. Access Serving Network (ASN) - It can be seen as the subnetwork composed by the Access Serving Network Gateway (ASNG), one or multiple Access Points (AP) and the components below them. 2. WLAN/WiMAX Core Network (CN) - It is mainly composed by the Packet Data Gateway (PDG), a Mobility Agent (MA) and one or a set of ASNs, as well as other components inteded for authorization and authentication. 3. Application Network - Understood as the network components involved in the connection between the Application Server (AS) and the Mobile Node (MN). Even if the present study is based on the case of macromobility and therefore the mobility inside the access network is not the main goal, it is considered in order to propose a solution that is compatible with the micromobility cases and also because it is important to understand how are the procedures for getting connected to the access network.

46

Problem Statement

Figure 5.1: Access Network Architecture

5.1.1

Architecture description and important considerations

For the communication between the mobile user and the AS, there must be a radio connection between the MN and at least one of the AP. One or a group of APs are controlled by an ASNG, which main function for the present case is to lter and route data packets from and to the MNs attached to its APs and also to perform QoS functionalities as will be discussed furhter in section 5.4. The ASNG is also involved in the handover process, it is assumed that the mobility inside an ASN (Change of AP within the same ASNG) is performed by using L2 mobility and therefore, it depends on the technology being used. In case the user is changing to an AP from a different ASNG (but still in the same access core network), the mobility is hidden from the PDG by the use of MIPv6, therefore, a Mobility Agent (MA) is needed. Having the three different sub-networks means that for this case, the mobile node needs to have also three different IP addresses: 1. Global IP - It is the one seen from outside the access network, it can be said that is the one used between the PDG and the Application Server. 2. Core Network IP - This is the IP address inside the CN, it is mainly used between the PDG and the MA. Using MIPv6 will hide any change of this IP address to the PDG and therefore to the external connection. 3. Internal IP - This IP address is the one that will change in case a change of

5.1 Access Network Architecture

47

gateway, it is the one to be used locally. In order to understand better what happens with these multiple IP addresses, the example of a packet being sent from an AS to the MN is shown in gure 5.2. First the AS is sending a packet (P1) to the MN, it is using its own IP address as source address and the MN global IP address as the destination. This packet has to pass through the PDG at the entrance of the CN where the MN is located.

Figure 5.2: IP addresses within WLAN or WiMAX The PDG has among other functionalities to translate the Global IP address into the one that is used internally inside the CN, so it converts the packets with the form of P1 into packets looking like P1, additional to the previous header there is a new IP header (or elds) added where the new source is the PDG IP address and the destination is the IP address of the mobile node in the access network. The packets having as a destination the access network IP address of the MN are intercepted by the MA, which according to the actual location and mobility situation of the MN will send the packet to the correct ASNG using the IP internal address as the destination as it is shown in packet P1 in gure 5.2. Due to the fact that all the packets are routed through the MA, it is proposed in order to simplify procedures, that the MA functionalities are co-located within the PDG, so, in case the MN is moving between AP of different ASNG, the update is done directly to the MA functionalities of the PDG.

48

Problem Statement

It is important to notice that the fact that the Global IP address is not changing does not mean that there are not modications in the IMS ongoing session, it has to be re-established in case there are changes in the QoS offered by the new connection inside the AN but that case is not being studied in the present project. Additional to the ltering and routing functionalities of the PDG, it can add to the packets a eld called Context Identier (CID) which can be used on top of the IP addresses of the packets in order to simplify the procedure in all the components of the CN. Multimedia packets sent by the AS to an specic port in the MN can be mapped by the PDG using a CID, this will help later for example the ASNG to route the packets to the appropiate MN, because it will not have to look at all the packet (IP addresses and ports), it will just consider the CID as the criteria for forwarding packets. The procedure for a downstream packet has been described but it is also important to show the steps and the format of a packet going from the MN to the AS. First, the packet is sent to the ASNG by the use of MAC routing, but having as destination in the network layer the AS IP address and using the IP internal address as the source, packets are to be intercepted by the MA which will add part of an IP header using as source the IP access network address and as as destination it will use the address of the PDG. Once the packet is received by the PDG, it will send the packet to the AS, using the Global IP address of the MN as the source and the AS IP address as the destination. Once more, the use of a context identier simplies the procedure for processing the packets in the different components of the CN, because it summarizes the information of IP address and ports of the content.

5.2 Layer 1/2/3 attachment

After the user has been disconnected from the previous network, it must establish a connection with the new one that will provide the service, even if the interest of this project is mainly based on the consequences of a change in the IP address (Layer 3) it is also important to study the complete procedure for connecting to the network for the lower layers. Figure 5.3 shows the steps that have to be followed in order to get layer 1 and 2 connectivity and a new IP address of the new network. As it can be seen it, the message exchange is mainly based on OSA and EAP authentication methods.

5.3 PDP Context establishment

In order to differentiate users and contents and to give every packet the appropiated service inside the network it is necesary to establish PDP contexts similar to how is done in UMTS. The procedure for establishing the PDP context (highly

5.4 QoS Management

49

Figure 5.3: Procedure for attaching to the network related with the QoS provisioning) is presented in Figure 5.4, some of the steps mentioned in there are not fully relevant, so special attention will be given to steps two and seven about Call Admission Control (CAC) and all the ones related with QoS negotiation, capabilities reservations and updates of the PDP context.

Figure 5.4: Procedure for establishing PDP contexts

5.4

QoS Management

From the QoS and resource management point of view, the End-to-End QoS can be divided into four different sections that can be studied separately in order to give a

50

Problem Statement

clear structure to the problem analysis, those are: QoS in the air interface and Radio Resource Management (RRM). QoS into the Access Serving Network (between ASNG and APs). QoS inside the Access Network Core between the PDG and the ASNGs. QoS within the IP Core (Internet) In the rst part, the way the QoS is handled in the air interface mainly depends on the access technology being used and therefore is particular for 802.11e and 802.16e (WLAN and WiMAX respectively) and is based on layer 2 QoS mechanism. Between the Base Stations and the ASNGs the QoS is also based on L2 mechanisms by priority according to 802.1P (extension of 802.1Q) for using VLAN. The QoS mechanism between the ASNGs and the PDG is provided by the use of DiffServ. The QoS outside the CN is assumed as granted and will not be considered as an issue, of course it is also part of the QoS negotiation within the IMS but it is assumed that there are always enough resources in that part of the network and that the bottleneck for the data transmission is present inside the CN. As there are three different mechanisms for QoS provisioning inside the access network, it has to be considered the links or correspondance that must exist between them and between the classes or priorities specied for each one of them. For the present case there will be three different priorities, this means for example that in the case of DiffServ there will be packets marked as EF, AF or BE. This packets once received by the ASNG have to be mapped in three out of the eight L2 priorities given by 802.1P, nally in the access points the packets have to be enqueued to be delivered to the correct MN accoridng to the different priorities of 802.11e/EDCF. It has been seen that EDCF is not completely optimal for the management of the QoS in an infrastructure mode, this because the AP instead is simply another node compared with the MN connected to it. All signalling and control packets, independently of the direction they are being sent (from or to the MN) will always be marked with the highest priority in order to decrease the probability that one or more of these packets are being droped. Additional to the QoS mechanisms mentioned before, the ASNGs and the PDG will be perfoming Call Admission Control (CAC), this in order to accept, enqueue or deny incomming calls in case there is not enough bandwith available in the network to fulll the QoS requested by the MN. The main importance of the CAC is based on the fact that the QoS re-negotiation is not just a matter of time consumption, it highly depends on the available resources in the new network that is

5.5 Call admission Control (CAC)

51

providing the service, the application that is running, the user expectations, among others.

5.5

Call admission Control (CAC)

In general, Call Admission Control (CAC) is performed in every multiplexing point (PDG, ASNG, routers, etc) in a PDP context. For the present case the CAC is assumed to be performed only in the PDG and in the ASNG and uses the concept of equivalent bandwidht (EB) in order to determine if the entity (PDG or ASNG) will be able to meet the QoS requirements of the new and the previously established calls and therefore to accept or deny the incoming call. The principle for the EB is to estimate the network resources required to provide the requested QoS. In general, the CAC procedure would be relatively easy if enough resources are available, the problem occurs when the incoming call is requesting more resource than available. In case there are not enough resources in the AN, there are different options for the CAC: 1. The easiest but not always the best solution is to simply deny the incoming call, this solution has a big impact in the QoS perceived by the user because it means that there is a sudden interruption of the communication. 2. The second option is to downgrade the service that was provided before and adjusting it to the available resources in the network, this can also have two main possibilities: (a) First, an increased setup time due to the negotiation with the user equipment, the available QoS can be enough for the communication or maybe is better to drop the call. (b) The second case is that the user equipment automatically accepts a service downgrade without being asked beforehand. Even if this may cause an inconvenience in terms of the perceived quality, it will help to have a shorter re-establishment time and under certain circunstances to improve the QoS. 3. A third possibility is to place the call in a queue, keeping it in hold until enough resources are available or a maximum waiting time is reached. 4. Finally, another option consists in downgrading one, some or all the communications of the other users in order to release the requested resources and accept the call. This is very dependant of the way the service provider administrates its network, the SLAs of the users making use of the network at the specic moment of the request and of course the type of content being used and the QoS and BW granted to them. In case of high load of the network with several users this can become a very complex task and absolutely

52

Problem Statement

dependant on the way the service provider deals with the SLAs. This type of CAC is considered out of the scope of the actual project due to the fact that it is dependant of the policies of the service provider and its SLAs.

5.6 Handover analysis

Performing a handover between different technologies implies among many other things, that there are different capabilities to be offered by the new access network, for example, differences in the availabe bandwith of the core network at certain time or in the capabilities that can be offered by different MAC and/or PHY layers. The case being presented in here is the one in which a sudden break up of the ongoing communication occurs and therefore the following general steps should be considered at reconection. 1. Detection of a new network / AP (Scanning). 2. L1/L2 Authentication and Association. 3. L3 Authentication and Association. 4. Generation of PDP contexts with QoS negotiation. 5. Re-establishment of the SIP session and data communication. The rst three steps, (specially in the cases of WLAN and WiMAX) are very related with the parameters dened by the standard, so after a rst study of the values in time, that they might have for the different technologies to be studied, they will be not longer considered as an issue for the present study. A change of access network and therefore, a change in the IP address implies repercussions in the mobility and resource management aspects. Such a change means also, from the IMS point of view that a new session must be established. As the QoS in the core network is not longer addressed by this project, all the efforts will be focused on the IMS signalling, a efcient QoS provision and assurance within the AN and the radio resources of each of the technologies after a hardhandover during an on going communication has occured.

Chapter 6

Proposed Solutions
6.1 Optimized SIP handover

This section mainly describes the research work by [11] and [12], the aim of those projects were to reduce the handover interruption between access networks. The main concept used in order to make that improvement possible is to use information known from previous context/session saved by CSCF servers within the IMS. The context transfer will help to reduce the number of messages exchanged between the UE and the IMS in situations of changing P-CSCF and therefore IP-addresses. The context transfer in this case is performed from the old P-CSCF to the new one. As the present case implies a change of access technology, it is assumed that it also means a change in the P-CSCF. Due to the fact that the new P-CSCF does not have any information about the UE, the context transfer between P-CSCFs contains information about session states, call states and parameters for the security association between the old P-CSCF and the UE. Nevertheless, the context transfer is only possible if the new P-CSCF has enough information about the previous one, such information is provided by the UE using a Re-authorization message. The message ow can be seen in Figure 6.1 Once the re-authorization has been done, the terminals involved in the session have to be informed about the new IP-addresses for the different medias. The description for each media (IP-addresses, ports, etc.) is given in the SDP. In the unoptimized procedure, the UE sends new invites to setup the path via the proxy servers to provide all relevant information to the proxy-servers and to negotiate parameters with the network and the called terminals, like for example the QoS settings for the session. However, the involved terminals have already negotiated the parameters in the initial invite request and as the CSCF-servers stay in the path and store the appropriate information, only the correspondant terminals have to be informed about the modied IP address for the various media.[11]

54

Proposed Solutions

Figure 6.1: Re-authorization message ow for optimization of handover As proposed by [11] the optimized invite request will be transported in a new message containing only the necessary information; the correspondent terminal will respond with an existing message (e.g. OK) as show in Figure 6.2.

Figure 6.2: Message ow of session Re-establishment For this approach, it has been assumed that the QoS from the IMS point of view can remain the same even with the change of the P-CSCF; as the bottleneck is considered to be the CN capabilities, this assumption is completely valid. Despite of that, it is important to look further inside the CN QoS capabilities in order to study the situation where there is change in the QoS capabilities compared with the ones that were provided by the previous CN.

6.2 QoS Context transfer

As it was shown in the previous section, transfering the context between core networks in order to re-establish the ongoing communication, can be an effective procedure in terms of saving time due to the reduced message exchange while performing a handover. Such approach can also be used for the QoS, in this case, instead of having to renegotiate all the QoS settings once again since the beginning, QoS parameters can be transfered between PDGs and also from the previously used ASNG to the new one.

6.2 QoS Context transfer

55

It is important to notice from gure 6.3 that the generation of a primary PDP context is unavoidable, due to the fact that it assigns a PDG to the connection so SIP messages can be exchanged with the IMS platform. All the packets using this rst PDP context are marked with the highest priority in order to protect signaling messages and therefore decrease the session setup time by avoiding signaling loss or retransmission. Even if it is not completely accurate, it can be said that signaling messages do not consume any bandwidth compared with data ows of video streaming or a VoIP call, so for the CACs it is said that no BW is requested so it will always accept this type of request.

Figure 6.3: PDP context generation Within the standard procedure, the secondary PDP context is created during the SIP invite procedure, just after the initiating node sends the PRACK message (See Figure 4.2). In order to save time in the generation of this secondary PDP context, it is proposed that information about the previous connection is sent from the previous CN to the new one and resources are reserved in the new one even before the re-invite is performed. This implies that the new core network must be notied about the previuos connection and establish a communication within the previous PDG and its ASNG. From Figures 6.1 and 6.4 it can be seen that this can be triggered when the UE has sent the Re-authorization message to the P-CSCF, this message after reaching the previous P-CSCF has to be forwarded to the previous ASNG and PDG in order to begin a QoS context transfer request. As can be seen in Figure 6.4, once the Re-authorization message reaches the old P-CSCF (Msg 1. and 2.), it begins two different context transfer procedures, one was the context transfer described in the previous section (Msg 3.) and the other one is the QoS context transfer from CN to CN (Msg 4. to 8.). An important consideration here is that the new P-CSCF must know the address of the previous P-CSCF and also must have information about the previous CN, this information must be provided by the UE.

56

Proposed Solutions

Figure 6.4: QoS context transfer and activation The IP address of the previous PDG is stored at the previous P-CSCF, therefore, the P-CSCF can send the QoS Context Request Message to the previous PDG (Msg 4,). Assuming that there is no direct connection between the ASNGs, the request is forwarded from the old PDG to the old ASNG. In order to know which one was the previous ASNG, the PDG can make use of the MA. From the information sent by the P-CSCF that was used before to the old PDG, it determines the IP CN address that the MN was using, and then it sends a request to the MA asking for the IP address of the previous ASNG in order to forward the QoS context transfer request to it. After receiving the request, the old ASNG can reply to the PDG with information about the QoS previously granted to the user, the PDG can add information about the ports being used, the IP destination address, the type of content being transfered, the bandwidth used, among others. All this information is sent to the new PDG and this will forward it to the new ASNG. After this, the involved entities have the required parameters for the CAC in the new AN for the re-establishment of the communication. It is expected that the new core network can provide at least the same quality in order to perform the new session establishment. In case it can not do it, it becomes mainly an issue of the CAC, according to the schemes mentioned in 5.5.

6.2.1

Dropping calls in the CAC

For the case where the call is just dropped (Figure 6.5), a message is sent by the PDG and/or the ASNG to the UE (depending on which entity is rejecting the call), notifying that if it tries to re-establish the SIP session and therefore the secondary PDP context for it, it will be rejected by the entity not having enough resources

6.2 QoS Context transfer

57

to assign (ASNG, PDG or even both). After this message is received, the user is notied that the call is lost and the UE begins to close the IMS session.

Figure 6.5: QoS context transfer with CAC dropping calls In case the entity rejecting the call is the PDG, it sends the QoS Deny message to the ANSG and then the message is forwarded to the UE (Msg 10.), this message is also used by the ASNG to release the resources it reserved (in case of having previously accepted the call). In case the entity rejecting the call is the ASNG, two messages have to be sent, the rst one is sent to the UE (as before) and the second one is sent to the PDG in order to notify it that the call is being rejected and that the reserved resources for that call, can be released. Even if this solution is a good alternative due to the simplicity of its implementation, it will be not longer considered because the aim of this project is to propose solutions for connection re-establishment and this is not offered by this proposal.

6.2.2

Service Downgrade in the CAC

Figure 6.6 shows the message ow for a negotiated service downgrade, it can be seen that while the SIP re-registration is being done, (Msg 1., 2., 3., 9. and 11.) this time is also used in parallel to transfer the previous QoS parameters (Msg 4. to 8.) and to negotiate with the UE if the available resources for the data transfer in the secondary PDP context are enough (Msg 10. and 12.). If the UE accepts to use those resources, they are reserved until the SIP session re-establishment makes use of them or a maximum holding time is reached. In order to use the reserved resources, once the complete re-invite procedure has been done, the P-CSCF has to notify the PDG by the use of the PDF that it has to activate the PDP context to be used.

58

Proposed Solutions

Figure 6.6: QoS context transfer with negotiated downgrade Another possibility is that even if the UE accepts the downgraded service, the AS does not want to provide the service under those conditions, this means that the Re-establishment message (Msg 13.) has to include and SDP with all the information about the new QoS to be used, it is up to the policies implemented in the AS to decide if the QoS being proposed by the UE is acceptable or not and it has to accept it, negotiate it or reject it, the accepted case is the one show in Figure 6.6, the other two possibilities are mentioned as possible, but not further studied.

6.2.3

Call queueing in the CAC

The case of call queueing for QoS context transfer is shown in Figure 6.7. There are different options according to the time that it takes for the call to be accepted or rejected by the CAC algorithm and the time for the SIP session re-establishment. In general, the improvement compared with the unoptimized case as in the previous cases is given by the two processes being done simultaneously (SIP session re-establishment and secondary PDP context generation). This case is very dependant on the amount of sessions in progress in the network, the type of sessions already established and parameters related to the ongoing sessions like holding time, interarrival time, among others.

6.3 Bandwidth Broker

Additional to what has been mentioned before, it is also proposed a scheme using a Bandwidth Broker (BB). The use of this resource management entity aims to be a unique device taking care of the complete call admission control, simplifying the CAC procedure and decreasing the amount of signalling messages because there

6.4 Delayed QoS negotiation

59

Figure 6.7: QoS context transfer with Call queueing in the CAC will be only one QoS negotiation, based on the knowledge of the complete network status and allotment and release of all the resources inside the CN for QoS provisioning. The architecture of the CN with a BB can be seen in Figure 6.8. An aditional advantage of using the BB is that a context transfer between BBs of different CN simplies the process mentioned before for QoS context transfer, it is expected that it will help to decrease the delay in the reprovisioning as can be seen in Figure 6.9. Finally, the request for resources is not made completely by the UE once the reconnection is done and also some steps can be done in advance compared with the unoptimized model in order to improve the performance.

6.4

Delayed QoS negotiation

As mentioned before, when a user is intending to get certain QoS from a network, additional to the subscriber privileges, also the availability of the network plays an importat role that has to be considered. Therefore, not always what the UE is requesting can be provided by the network and there must be a negotiation between the network and the UE in order to determine whether the offered QoS is satisfactory or not. In some cases and even if certain degradation of the service can be expected, what the network is offering to the UE can be enough from the user perspective, nevertheless, the negotiation of the QoS can be a time consuming procedure Keeping this in mind, there are three different proposed solutions in order to compare their performances mainly in terms of the HO delay and the amount of received/droped packets after the re-establishment. It is important to notice that the BW is the main requirement to be fullled in order to determine if there are enough

60

Proposed Solutions

Figure 6.8: Core Network Architecture including Bandwidth Broker

Figure 6.9: Session re-establishment for a Bandwidth Broker transfering the context

6.4 Delayed QoS negotiation

61

capabilities in the new network or not, therefore when talking about a negotiation about QoS it is relevant to the fact of using the network with a reduced BW available and packets not being marked (BE approach).

6.4.1

Start with BE, update to maximum available BW and nally update to the requested BW when possible

If there are not enough resources to be allocated to the new incomming call (HO call), instead of rejecting the call or loosing time in QoS negotiation, it is proposed that the data trafc is restarted just as a BE service, in this case, the rst messages will look very similar to the ones in Figure 6.2, once the data trafc is restored the QoS negotiation starts (without interrupting the data trafc ow), assigning as many resources as possible (keeping as the upper limit the BW requested by the user). Keeping track of the available resources on the network, the conditions for the communication can be continuosly improved until the level desired by the user is reached. By the use of this approach, it is expected that the time used in the re-establishment of the communication is decreased compared with a full negotiation of the QoS, and even if the QoS is not optimal at the beginning, some packets are received, so it becomes an issue of for example, how the application layer presents these packets to the user in order to minimize the impact. Figure 6.10 shows the signalling messages for this approach, it is important to notice that the trafc keeps owing independently of the renegotiation of the QoS parameters. The PDP contexts are also updated at the same time as the SIP messaging is done.

6.4.2

Accept maximum available BW and update to the requested BW when possible

As in the previous case, it is also assumed that there are not enough resources to fulll user requirement and instead of rejecting the call, the QoS negotiation is made with as many resources as possible and later on, when possible, the communication is upgraded in order to satisfy user requirements. Even if at the beginning, the time for setting up the communication can be longer because of the need of the complete message exchange for the QoS negotiation, the advantage of using this method is that it gives to the user as many resources as possible, trying to minimize user discomfort until the complete request can be fullled. Figure 6.11 shows the messages used for this purpose, at the beginning it just follows the standard procedure for session establishment and later on, it is upgraded without interrupting the ongoing data ow.

62

Proposed Solutions

Figure 6.10: Message ow for multiple updating of QoS

Figure 6.11: Message ow for updating of QoS starting with the maximum available

6.4 Delayed QoS negotiation

63

6.4.3

Mantain BE until requested BW is available

Finally, this approach is independent of the availabity of network resources in the AN, rst the data trafc is restarted just as a BE service by the use of a quick reconnection, postponing the QoS negotiation, using messages looking similar to the ones in Figure 6.2; this is done in order to minimize the handover delay, even if some packets are discarded (due to congestion, excesive delay or jitter, among others). Once the data trafc is restored and without interrupting the data trafc ow, there is a continuous tracking of the available resources, once there are enough capabilities to serve user requirements. a QoS update is performed in order to assign the requested resources to the ongoing communication. The main advantages of this approach is the reduced time for session re-establishment and the fact of not using as many signaling messages as in the previous proposals. Under a congestion scenario, reducing the amount of signaling trafc is positive because it reduces the load of the network and also because an error in these messages can cause several delays in the negotiation if there is not a proper scheme for dealing with signaling errors.

Figure 6.12: Message ow for updating of QoS starting with Best Effort Figure 6.12 shows the message ow. It is worth to notice that the trafc keep owing under best effort conditions and it is only updated when there are enough resources to modify it according to user (and contractual) request.

64

Proposed Solutions

Optimized HO Yes Yes Yes Yes Yes Yes

QoS Transfer Downgrade Queueing No No Yes No No Yes No No No No Yes No

BW Broker No No No Yes No Yes

Delayed QoS (BE until BW available) No No No No Yes Yes

Table 6.1: Combination of improvements to be tested

6.5 Methodology
From the previously presented solutions it can be seen that even if an improvement of the performance is expected by the use of each one of them, a combination of them can be even more effective, therefore, Table 6.1 shows the combination of the proposed solutions that are investigated in this project. The solutions provided in a conceptual way will be conrmed by simulations. The parameters to be meassured in order to test the system performance will be mainly the handover delay time (depending on load, number of nodes involved, trafc model, among others), the QoS re-provisioning delay, the performance after the handover under different congestion conditions.

Part III

Setup, results and conclusions

Chapter 7

Simulation
7.1 Simulation tool
Many software tools are available in order to simulate the proposed scenarios, each one them has its advantages and disadvantages. Despite of that, there are some characteristics that are decisive at the moment of choosing the appropiated simulator, the most important are listed below: Open source, so it can be modied and adjusted to very particular requirements. Already include wireless functionalities or are easy to be generated. Allow to connect wireless and wired networks in an easy way. Functionalities to have different kind of networks and its components (WLAN, UMTS, among others). Good documentation and support in general. Better a software that works as a network simulator and not in general with predictive and mathematical models. Considering this preliminary requirements, the choosen simulator was the Networks Simulator version 2 (NS2).

7.2 Important Considerations

Due to incompatibilities between different modules of NS2, there is not a unique complete simulation scenario to be used for the present study, instead of that, there are two different modules which are combined manually according to the requirements of each simulation. The two main blocks in which the simulation scenario is divided are:

7.3 IMS simulator

67

1. QoS Simulation 2. IMS/SIP Simulation The QoS simulator requires the simulation of both, wired and wireless links and therefore it requires the use of hierarchical addresses, allowing the model to work with domains and subdomains. Such addressing structure cannot be used for the IMS/SIP simulation because the SIP module for NS2 was designed to be used in a single domain with no hierarchy and only over wired networks. Further explanation and details about the QoS and the IMS/SIP simulation, as well as the ways they are combined are discussed in subsequent sections.

7.3

IMS simulator

The IMS simulator is an extension to the original NS2 software distribution (version 2.28), it adds the SIP protocol to the already existing set of protocols, includes a list of possible SIP messages/responses and create/modify the nodes in order to make them able to understand and to react to the different SIP messages, acting as state machines. Additional to the IP address of the nodes, with this SIP addition it is also possible to assign to the nodes a SIP addresses, composed by a domain (url) and a name. Additionaly, there are two components of this simulator intended to perform server functionalities, they are of course, also able to understand and to react to SIP messages, the rst one is intended to emulate proxy servers (P-CSCF) so all the IMS/SIP signaling has to pass through them and together with the other components of IMS, it contributes in order to establish the communication. The second component is able to perform functionalities of the HSS, such as keeping information about the network location of the IMS components, user proles, among others. For a simulation, it is possible to have as many P-CSCF and HSS as required. The main purpose of this simulator was to be a tool that allows the user to see in a dynamic way the messaging ow required for different IMS procedures and to provide different parameters that can be used for the analysis of the performance of the SIP signaling under different architecture scenarios. For the actual project it has be modied in order to test different approaches, in this case, there are new messages, new states and procedures and the intention is to validate if the proposed solutions are suitable and how is their performance under different scenarios. Figure 7.1 shows the parameters that are considered as an input for the system, which are the link delay between the different nodes of the network, processing time for each one of the messages and a future extension also the call ow in order to make a relation between the actual status on the network and the consequences that this might have over processing times, for example.

68

Simulation

Figure 7.1: IMS simulation Input/Output block diagram

7.3.1

Description and Topology

Figure 7.2 presents an schematic of the basic components involved in the current investigation of IMS handover. As mentioned before, these nodes are able to deal with SIP messages, the Proxy Servers (PS/P-CSCF) deal with the registration and session setup/update messages and the Location Server (LS/HSS) has information about proles and locations in the IMS. Also a DHCP was included in the network in order to emulate the required delay inherent to the connection establishment in layers 1, 2 and 3.

Figure 7.2: IMS architecture In the IMS/SIP module for NS2, all the components of the IMS platform are being simulated by the use of the P-CSCF and the HSS and by giving every message and independent treatment (different processing delays) according to the steps or ow it should have in a complete IMS platform (e.g. interaction with I-CSCF and/or S-CSCF). The standard messages being exchanged during session registration and session

7.3 IMS simulator

69

setup are shown in Figure 7.3, the link delays, Round Trip Times (RTT), processing times for each message and the time for L1, L2 and L3 association (related with the DHCP) are easily congurable in the tool and in real situations may depend on different factors as network topology, congestion, hardware and software being used, among many others.

Figure 7.3: Message ow for session establishment As mentioned before, for the IMS/SIP simulation, inputs and outputs are dened. The main parameters that are given as inputs for the system are the processing times, link delays and the variation that these values can have, details about these parameters and the typical values given to them, are shown in table 7.1. The outputs of the system are basically the signaling times/delays of the different IMS/SIP procedures, these parameters as well as their values will be discussed further in the following section.

7.3.2

Session setup simulation

For the simulated IMS/SIP architecture there are 4 main parts in which the complete setup can be divided, those are: 1. L1, L2 detection, authentication and IP address assignment 2. Register 3. Simple invite

70

Simulation

Parameter Processsing Time Link Delay Variation

Component SIP layer & L3 processing Serialization, Propagation, Buffering & Retransmission

Value Between 10 - 100 ms 5 ms Air, 10 ms inside CN/IMS & 20 ms Between CN and IMS 10 - 20 %

Table 7.1: Input parameters for the IMS/SIP simulation model 4. QoS reservation The rst one can be divided into three different procedure, rst is the time for nding a new base station that can be between 0 and the interval between advertising messages sent by the BS, then the time for the message exchange (OSA + EAP) that is around 70ms depending on the link delays and the processing times and nally the RTT for the IP address request with the DHCP that has been dened as 800ms with a possible variation of a 10%. Figure 7.4 shows the total time for this rst procedure according to different times of advertising messages, It can be seen that as the maximum detection time increases, also the total time increases linearly.

Figure 7.4: Total time Vs BS detection time The other three (Register, Invite and QoS Reservation) behave very similar with each other, the simulator deals with the message ow according to the SIP protocol and estimates a time for every message (transmitted and processed) according to the values of the input parameters mentioned in the previous subsection. Without congestion in the network and giving the messages a variable processing delay according to the type of message and the nodes involved in the IMS for the processing of the message (even if they are part of the simulator or not, like for example the I-CSCF) and assuming that the interval between advertising messages

7.4 QoS Simulation Structure

71

Activity L1, L2 authentication and IP address assignment Register Simple invite QoS reservation Total

Required mean time (ms) 1120 410 1180 1720 4430

Table 7.2: Approximated times for IMS session setup

is 500 ms and the RTT for requesting an IP address is 800ms, the Table 7.2 shows the simulated mean times needed for different procedures in the IMS. This is the simulated mean time for setting up a complete session, including QoS establishment and assuming that the QoS can be granted without any additional negotiation message. For a hard handover without the implementation of improvements this is also the time that will be needed for re-establishing the communication. The time given for the session setup or the handover delay (session re-establishment) is considerably large in terms of user perception and is a clear example of the need of implementation of improvements. The time used for each message or a set of them are the outputs of this model and will work as an input for the simulation of the QoS when it is relevant, otherwise it is assumed that both analysis can be done separately.

7.4

QoS Simulation Structure

It is important to analyze the behaviour of the data ow trafc before, during and after the handover, in order to meassure how good is the QoS estrategy that has been implementated and also to rate the performance of the proposed solution. The QoS simulator allows to modify the conguration of the QoS implementation by varying characteristics like the parameters dening the RED queues, the CIR used as a criteria for marking the packets, the EB that is assumed for the CAC and, the values of the different trafc models. In order to determine the performance of the different proposed solution over this simulator, the parameters that can be compared are for example the time that a HO session must wait in order to be accepted by the new network, the ammount of calls that are dropped due to the fact that HO calls are prioritized over the sessions that are being established for the rst time, the amount of HO calls that fail to be re-established due to lack of resources in the new network and the amount of packets that are dropped during and after the HO. Figure 7.5 summarizes the inputs and outputs for this simulator.

72

Simulation

Figure 7.5: QoS simulation Input/Output block diagram

7.4.1

Description and Topology

The network topology used for the simulation in NS-2 is presented in Figure 7.6. In this gure two bottlenecks are present, the rst one is between the PDG 2 and ASNG 2, in this part the QoS is managed by using DiffServ. The second bottleneck is in the air interface between the base station BS2 and the mobile nodes sharing the medium.

Figure 7.6: Simulation topology The main analysis is focused on the node called MN, this node has a pre-

7.4 QoS Simulation Structure

73

established real time video session and performs a hard handover by moving from BS1 to BS2 and therefore changing its IP address (1.1.1 to 2.1.9). For the case of WLAN it was found by simulations that the throughput in NS2 is in average 4.14 Mbps (depends on packet size). This value will be used as the total bandwidth available for each base station in order to perform a rst CAC. The second CAC depends on the available bandwidth in the bottleneck between routers, in this case, the total bandwidth is assumed to be 7,5Mbps; this assumption is taken from the fact that there are 2 base stations passing their trafc through this link (BS2 and BS3), therefore, in case both of them are using most of their available BW, this will cause an overow in the mentioned link. There is not trafc from BS1 as the only node connected to it was MN. Due to the fact that the amount of ASNGs, BSs and nodes inside an access network might be much higher in a real network than in the simulation, the value chosen as the BW for the bottleneck between PDG and ASNG is not expected as a normal value an operator will have for this link. Nevertheless, this value is used in the simulation in order to represent a general overow scenario where the link does not have enough bandwidth or the PDG capacity becomes the bottleneck. The non congested links have a BW of 10 Mbps and normally a delay of 10 ms for each one of them, such capability does not present any restriction in terms of data transmission through them but of course it has relevance in the E2E delay. In order to create congestion trafc there are several mobile nodes connected to the base stations 2 and 3, each one of them can generate and terminate different types of sessions at different times during the simulation. The generation of trafc in the different nodes of different BS, adds the possibility that the congestion is in the air interface, the link between ASNG and PDG or both. For this simulation, only the downlink trafc is investigated and it is assumed that for the uplink, there are enough resources and therefore QoS strategies are not required. A summary of the most relevant simulation parameters can be found in Table 7.3

7.4.2

Trafc

There are three different types of trafc/sessions generated in the network: VoIP, Video and HTTP, all of them with different characteristics and built for reacting in different ways to the network congestion. The main assumptions for the trafc model are shown in Table 7.4. Parameters such as the amount of sessions of each type and the average duration of each one may vary from simulation to simulation and will be discussed in detail where it is required.

74

Simulation

Simulation duration

600 sec Wired Domain Link Bandwidth (Mbps) Link delay (ms) 10 10 10 10 10 10 7,5 10 10 10 Wireless Domain 3 4,14Mbps 1 (MN) 9 (8 X-trafc Nodes + MN) 8 (X-trafc Nodes) Table 7.3: Simulation Parameters

Servers-Router 0 Router 0-PDGs PDG1-ASNG1 PDG2-ASNG2 ASNGs-BSs Cells Cell Bandwidth Active nodes cell 1 Active nodes cell 2 Active nodes cell 3

RT/NRT Transport Layer IP Packet Size (Bytes) Trafc source model Rate on period (kbps) On-time (sec) Off-time (sec)

VoIP RT UDP 120 Exp On/Off 30 4 5

Video RT UDP 160 Exp On/Off 128 1.5 1.5

HTTP NRT TCP 240 Exp On/Off 60 1.6 12

Table 7.4: Trafc Parameters in Simulation

7.4 QoS Simulation Structure

75

VoIP trafc VoIP sessions are based on UDP-agents, trafc is generated according to an Exponential On/Off distribution. Constant size packets are sent at a xed rate during on periods, and no packets are sent during off periods, both on and off periods are taken from an exponential distribution. The main parameters dening VoIP trafc are: Burst time (seconds) Idle time (seconds) Burst send rate (bps) Packet size (bytes) It is important to notice that UDP connections are not affected by loss of packets in terms of trafc generation because there are not retransmissions or adjustments to the packet send rate. Video trafc Parameters used for dening video sessions are the same as the ones used for VoIP, but the values used for them are different as can be seen in Table 7.4. HTTP trafc The HTTP-objects are typically quite small in terms of kB and many TCP-connections are created in relation to amount of data transmitted. TCP connections are subject to retransmission and adjustment of packet rate, so normally a large portion of time and packets are spent on connection establishment and tear-down. For the present case the trafc is sent using an Exponential ON/OFF distribution. Parameters for HTTP are also the same as for VoIP and Video trafc.

7.4.3

CAC

As mentioned in Section 5.5 on page 51, the principle to be used in order to accept or deny a call will be the bandwidth, therefore, the EB plays an important role in order to determine if there are enough resources available or not. In order to estimate the EB there are different mathematical models for the Exponential OnOff trafc model for real-time services and for non-realtime services, considering parameters such as packet loss ratio and buffer size. Equation 7.1 is an estimation of EB for an Exponential On-Off source whitout buffer [2]: EB = m + , = 2ln() ln(2) (7.1)

76

Simulation

Peak rate (kbps) Mean rate (kbps) Assumed EB value (kbps)

VoIP 30 13 18

Video 128 64 96

HTTP 60 7 10

Table 7.5: Assumed EB for the different trafc sources where m is the mean rate of the aggregate sources, is the standard deviation and is the target packet loss ratio. With more sources aggregated the trafc becomes more Gaussian distribution. For the present scenario, it can be said that there are N sources generating exponential On-Off trafc of identical characteristics (same On and Off mean time and same sending rate), for this case and according to [2], with a large amount of sources (big N), the EB converge to the mean rate, m = ron OnTime OnTime + O f f Time (7.2)

where ron is the on time sending rate. Otherwise the EB for a single source in a N sources scenario can be approximated to EB = m + N (7.3)

It is important to notice that the equivalent bandwidth is a value between the peak rate and the long term average sending rate of the trafc source. If the peak rate is used as the EB for each trafc, the QoS will be absolutely supplied but the average bandwidth utilization will be low; and if the EB is the average sending rate of the each one of the sources, the QoS will be seriously affected for realtime services during congestion periods. Therefore, an intermediate value for the EB has to be assumed in order to get an improved performance compared with the cases of the peak or the average rate of transmission. Table 7.5 shows the values related to the EB assumption and the value that will be used as EB for the simulations. The assumed value for EB of VoIP is a 60% of the peak rate according to [2], the value for the EB of the video is the mid value between the peak and the mean rate and for the HTTP value it was randomly chosen with a value near the mean rate because of the long off periods.

7.4.4

Differentiated Services

As mentioned before, DiffServ uses DiffServ codepoints (DSCP) in the packet IPheader to distinguish trafc with different Per Hop Behaviour (PHB), which denes a forwarding treatment of a single packet in a router. It is important to notice that there are not guarantees regarding gained bandwidth, packet delay or jitter, it is just a way to dene priorities from one type of trafc to another.

7.4 QoS Simulation Structure

77

Trafc Type VoIP Video HTTP

Priority EF AF BE

DSCP 10 20 30

Queue weight 6 3 1

Table 7.6: DSCPs for the different trafcs and priorities For the present case there are three different priorities and therefore there are three different physical queues, they are: EF - Expedite Forwarding, used for VoIP communications. AF - Assured Frowarding, used for Video sessions. BE - Best effort will be used for HTTP connections Routers will divide the trafc in different queues based on the DSCP (Table 7.6). Additional to this, for the the simulation there are important parameters to be considered: Policy - TSW2CMPolicer The policy to be used in the present case is called TSW2CMPolicer (Time Sliding Window with 2 Color Marking). This policer uses a Commited Information Rate (CIR) and two drop precedences (red or green). The lower precedence (red) is used probabilistically when the CIR is exceeded but, as the implemented source in NS2 will not exceed the peak rate (CIR), marking the packets is not necesary, therefore, all the packets of each type of trafc are marked as green and handled in multiple queues. The values used for the CIR for the trafc sources are the peak transmission rates previously mentioned in Table 7.5 Queue - RED Random Early Detection queues drop packets at an increasing probability as the buffer begins lling up. Minimum and maximum threshold of buffer occupation are dened and between them the probability of dropping a packet is increased linearly. Below the minimum threshold packets are not to be dropped at all and above the maximum threshold all arriving packets are dropped. Table 7.7 shows the values used for the parameters dening the RED queue, where: In-min: Minimum dropping threshold in the RED-queues for the in-packets. In-max: Maximum dropping threshold in the RED-queues for the in-packets.

78

Simulation

Type EF AF BE

In-min 4.5 30 15

In-max 8.0 60 60

In-prob 0.05 0.05 0.05

Out-min 0.0 15 15

Out-max 0.0 60 60

Out-prob 1.00 0.1 0.05

Table 7.7: RED queue parameters In-prob: Maximum dropping probability in the RED-queues for the outpackets.

Out-min: Minimum dropping threshold in the RED-queues for the out-packets. Out-max: Maximum dropping threshold in the RED-queues for the outpackets.

Out-prob: Maximum dropping probability in the RED-queues for the outpackets.

It is important to notice that this values might vary in future simulations in order to determine if adjusted values give a better performance, the different values and the results will be discussed in the following chapter. Scheduling - WRR Weighted Round Robin shares link access circularly, one buffer at a time. Each buffer has weight which assigns a relative share of link access time compared to other buffers. WRR offers a type of preferential treatment to high priority trafc. WRR was chosen over PRI for the present analysis becuase PRI will serve VoIP trafc (EF) always and the other trafcs will be served in a Best Effort maner compared to it, so WRR scheduler will serve each queue more fair and the relative importance of each class can be modied easily according to the amount of sessions of each type, the initial weights given to the buffers were shown in Table 7.6. Core and Edge routers Core routers perform Per Hop Behaviour (PHB) on incoming packets. In order to do this, they mantain multiple physical queues which at the same time have virtual queues or precedences. Every packet is placed in a virtual queue inside a physical queue according to the DSCP-value in the IP header.

7.4 QoS Simulation Structure

79

Physical queues are implemented as a RED-queue in NS2. Virtual queues within the same queue use the same buffer to temporarily store packets. However, all virtual queues can be congured with their own RED-parameters (minimum and maximum thresholds and dropping probability). The parameters to be dened for the core router are: Amount of physical and virtual queues The DSCPs needed Mapping of each DSCP to a physical and virtual queue RED-parameters (min and max thresholds and dropping probability) for the virtual queues Edge routers perform the same functionality as core routers (PHB) but in addition they manage the following functionalities: Policing Metering Packet marking In order to congure edge routers the same parameters as the core routers must be dened, additional to this, the criteria of marking the packet with a DSCP must be included (Table 7.6). The following parameters are used: 1. Distinguish the packet of belonging to certain trafc aggregate. The decision is based on source address, destination address and trafc type. 2. Measure transmission rates of the given trafc aggregate and the conformance of it to predened values Figure 7.7 shows the relation between the actual scenario and the edge (Router 0) and the core routers (Router 3/PDG 2 and Router 4/ASNG 2). The IP data packets from the servers are sent to the edge router, that works as the ingress and egress of the DiffServ domain. This router marks the IP packets with the different DSCPs according to the type of application and forwards them to the PDG. The PDG outlink differentiate the IP data ows by using the DSCP and transmits them using the scheduling and queueing schemes described before..

80

Simulation

Figure 7.7: Edge and Core routers implementation in the simulated scenario

Chapter 8

Results comparison and analysis

8.1 Improvements simulation

The improvements proposed in the actual project are not related to all the activities mentioned in Table 7.2, for instance, the rst activity called L1, L2 authentication and IP address assignment is assumed as a xed value for the present simulation everytime a handover is performed. The proposal given by [11] with the Optimized SIP handover aims to decrease the time for the Register and the Invite activities and some of the the other proposed solutions in the project intend to decrease the time for QoS reservation and the total time by dealing with the Invite and the QoS reservation simultaneously.

8.1.1

Optimized SIP handover

Due to the fact that the Optimized SIP handover does not deal with any QoS considerations, the simulated model is shown in Figure 8.1. As it can be seen, the model is the same as the one simulating the IMS and described in a previous section, the main difference is the messages that are sent through the network. The time for the Register activity can be longer for the optimized version, because even if the amount of messages sent in the optimized version is very similar to the number of messages sent in the unoptimized one (Enumerated below) and in the unoptimized version the messages have to travel twice the time over the air interface, it can be assumed that the processing time of the context transfer messages is higher than the time for a normal Register, therefore, Figure 8.2 shows the time of the Register/Re-authorization procedure in the optimized and the unoptimized versions, It can be seen that as the time for the message processing increases, the time of the Re/authorization in the optimized version also becomes higher and it can be even biger than the Register in the unoptimized one. 1. SIP Register message

82

Results comparison and analysis

Figure 8.1: Simulation architecture for Optimized SIP handover Activity Register/Re-authorization Invite/Re-establishment Total Unoptimized time (ms) 410 1180 1590 Optimized time (ms) 420 230 650

Table 8.1: Time comparison for Optimized SIP handover 2. 401 response - Unauthorized 3. SIP Register message with credentials 4. 200 OK The importance of such registration with the context transfer is then, the time that is saved later by the Invite (Re-establishment) procedure, instead of having all the message ow shown in Figure 7.3, it gets reduced to two simple messages as shown in 6.2 on page 54. The time differences between the unoptimized and the optimized versions can be seen in Table 8.1. The impact of the longer Re-authorization becomes almost neglectible when compared with the total time (Register/Re-authorization + Invite/Re-establishment) as can be seen in Figure 8.3. The values presented in Table 8.1 are the one that will be used for the coming simulations, as can be observed, the average time saved by this proposal compared with the unoptimized version is about 0.95s which will reduce the overall time to around 3.5s (From Table 7.2). Even if it is a signicant improvement, this time is still a considerably long interruption from the user perspective.

8.1 Improvements simulation

83

Figure 8.2: Register/Reauthotization comparing Optimized and Unoptimized solutions

Figure 8.3: Register/Reauthotization and Invite/Re-establishment comparing Optimized and Unoptimized solutions

84

Results comparison and analysis

8.1.2

QoS Context Transfer

The complete simulation for the QoS context transfer, would be similiar to the scheme shown in Figure 8.4, nevertheless, due to the internal incompatibilities inside NS2 mentioned before, the simulation has to be splitted into two parts, the one dealing with the SIP messages and the QoS signaling is shown in Figure 8.5 and the other handling the trafc itself, is presented in Figure 8.6.

Figure 8.4: Setup for simulating Context Tranfer between PDGs and ASNGs The simulation in Figure 8.5 carries all the signaling messages shown in 6.4 and therefore it is also assuming that there are enough resources in the air interface and between PDG and ASNG (no bottlenecks), so the call admission is always possible. The information about CAC for the call queueing approach is given by the architecture simulated in 8.6, for the case were the system is not overloaded it is not necessary to use this model because it is assumed that there are enough resources to be assigned to the incoming call (system not overloaded) and therefore the CAC always will accept the call, for the case of service downgrade this topology will tell the amount of resources available and therefore as a result of the CAC, there will be always necessary the message for downgrading the service. The performance after the re-establishment in the case of service downgrade will be studied in the next session.

8.1 Improvements simulation

85

Figure 8.5: Simulated architecture for signaling in QoS Context Transfer

Figure 8.6: Simulated architecture for trafc in QoS Context Transfer

86

Results comparison and analysis

Activity L1, L2 authentication and IP assign Register Simple invite QoS reservation Time simultaneously Total

Optimized time (ms) 1120 420 230 1600 -340 3030

Unoptimized time (ms) 1120 410 1180 1720 0 4430

Table 8.2: Handover delay for QoS Context Transfer Activity L1, L2 authentication and IP assign Register Simple invite QoS reservation Time simultaneously Total Optimized Time (ms) 1120 420 230 1685 -410 3045 Unoptimized time (ms) 1120 410 1180 1910 0 4620

Table 8.3: Handover delay for QoS Context Transfer in Service downgrade

The total time for re-establishing the session by using this approach is shown in Table 8.2. This table shows that the time for QoS reservation remains very similar to the one without the optimization (approximately 100ms less) but the improvement is given by the time that the messages are sent simultaneously. The total time for this re-establishment (including Optimized SIP handover) is approximately 1.4 seconds less than in the unoptimized version.

Service downgrade The option of the service downgrade as proposed in the optimization shown in Figure 6.6, takes approximately the same time as if the resources were available (Table 8.3), this happens because the extra message that is sent (Msg.12 in Figure 6.6) can be sent almost simultaneously with message number 13 of the same gure, therefore, the increased time is given only by the processing time in the UE. In case of using the unoptimized approach, the negotiation messages are also sent but there is not other message sent at the same time and therefore the total time increases in the time that takes for the messages to be sent and processed from the UE to the PDG. The performance after the re-establishment and therefore after the downgrade of the service depends mainly on the congestion of the network at the moment of the handover and will be studied in the next section.

8.1 Improvements simulation

87

Total simulation time Handover moment Inter-arrival time (sec) Session duration (sec)

600 sec @ 300 sec VoIP Video HTTP 0,3 4,6 1,2 40 120 300

Table 8.4: Session characteristics for call queueing Call queueing For call queueing there are other parameters to be considered, for the previous cases, the sessions that were already established were assumed as persistent, meaning, that the moment when they were beginning or ending was not considered, when talking about call queueing there are important characteristics to be considered like the amount of already ongoing sessions, the type of each one of these sessions, the average duration of them, how often a new call is coming (Interarrival time), among many others. Table 8.4 show some of the parameters used for the simulation. In the proposal of the call queueing, the principle is to determine the time that takes for the network to have enough resources to be allocated to the session that is performing the HO, in order to do this, all the new comming sessions are blocked until the HO session can be established and this will occur when one or several active session nish and release the resources. At the moment when the HO is happening, there are several combinations for the usage of the BW, depending on the amount of sessions of each type that are active. In order to have a general view of the differences, three different groups of simulations were performed, in the rst one (Figure 8.7) the use of the BW was divided within the different sessions by varying mainly the amount or VoIP sessions, it was varied from a 0% to a 100% of the BW used by this type of sessions and the remaining BW was divided equally between the other two types of sessions. Figures 8.8 and 8.9 are similar to the one previously described but the value varying is the percentage of the used BW by video or http sessions respectively. In general, it can be said that the average time required for having the BW available for the HO video session is around 100ms and this is the values that will be used for further analysis. It is important to notice that this time is just the waiting time for the call to be accepted, so this value has to be added to the total time for re-establishing the session (SIP and QoS signaling times mentioned previously).

8.1.3

Bandwidht Broker

The general scheme for the simulation of the BB can be seen in Figure 8.10, the validation of the improvement of this proposal is mainly related with the IMS sim-

88

Results comparison and analysis

Figure 8.7: Time in queue for a HO video call according to percentage of VoIP sessions

Figure 8.8: Time in queue for a HO video call according to percentage of Video sessions

8.1 Improvements simulation

89

Figure 8.9: Time in queue for a HO video call according to percentage of HTTP sessions

Activity L1, L2 authentication and IP assign Register Simple invite QoS reservation Time simultaneously Total

Time without BB (ms) 1120 420 230 1600 -340 3030

Time with BB (ms) 1120 420 230 900 -340 2330

Table 8.5: Handover delay for QoS Context Transfer

ulator and therefore, the architecture shown in Figure 8.11 is used in order to probe the concepts of a decreased time for the re-establishment of the communication.

The actual simulation is the message ow in Figure 6.9 being sent over the architecture shown in Figure 8.11 and this, compared with the message ow presented in Figure 6.4 over the simulator architecture of Figure 7.2. As can be seen from this comparison, the amount of signaling messages is less in the BB proposal and there is only one CAC checkpoint, this two characteristics reduce the re-establishment time because there are less messages to be transmited and a reduced processing time for the CAC. This results are clearly reected on the results of the simulations and presented in Table 8.5.

90

Results comparison and analysis

Figure 8.10: Setup for simulating Bandwidht Brokers and Context Transfer

Figure 8.11: Simulated architecture for signaling for the Bandwidth Broker approach

8.2 Combined simulation of improvements - Performance evaluation

91

Packet Loss E2E delay (ms)

AF 0 145

BE 0 240

Table 8.6: Comparison between AF and BE in a 100% load scenario

8.1.4

Delayed QoS negotiation - Mantain BE until requested QoS is available

For this approach, it is important to notice that not only the time for the resources to be available has to be considered, as can be seen in Figure 6.12 once the resources are available, signaling messages have to be sent in order to upgrade the service. As mentioned in the part about call queueing, an average waiting time for the availability of the resources can be 100ms and considering that the signaling messages can take approximately 400 ms in total, the total evaluation time will be 500ms. Table 8.6 shows the results achieved, comparing between two sessions of the same kind of trafc(Video UDP/RT) over a congested link but one of them with packets marked as as AF and the other ones as BE. It does not consider the amount of packets lost due to the HO situation: It can be seen that even if some packets might be discarded by the application due to an excesive delay, there are still some that can be presented to the user and therefore during those 500ms the user does not perceive a complete interruption of the session.

8.2

Combined simulation of improvements - Performance evaluation

In order to determine which proposal or combination of proposals behave better compared with the others, an specic criteria must be dened, the parameters used in order to compare the different solutions are going to be the waiting times for the re-establishment, the amount of X-trafc calls that are dropped due to the prioritization of the HO session, the probability that a HO call that will be dropped in case no queueing mechanism exist and the packet loss during the handover. Some of this parameters cannot be relevant for some of the simulations but most of them will be used for the comparison. In order to generate congestion in the network the amount of sessions that will be generated are equivalent to a 140% of the total available BW, it was estimated that around 250 seconds after the start of the simulation the BW will be around its maximum ocupancy and therefore the handover is performed after 300s. Figure 8.12 present the amount of BW available as the multiple sessions start, the upper line is the available BW in the link between the PDG and the ASNG and the dashed

92

Results comparison and analysis

Simulation BB + delayed QoS BB + call queueing Delayed QoS Call Queuing

Re-establishment time (s) 2.33 2.42 3.03 3.11

Dropped X-trafc (sessions) 14.95 15.42 19.37 20.03

Packet loss 112.43 119.74 143.17 151.28

Table 8.7: QoS requirements for the different trafcs one is the available BW in the air interface of the BS2.

Figure 8.12: Available BW during the time of simulation The division of the BW for the simulations was made equitative between the 3 types of trafc, it was found that the probability of blocking a handover call between 300s and 600s is as shown in Figure 8.13, it shows how the BW is being used for a load of 100% and 120%, thevertical line is the limit over which the HO call will not have enough resources for being accepted by the CAC, under it, the session can be accepted without needing any additional method. As can be seen the approaches using a BB have a better perfomance compared with the ones without it, this is mainly because of the reduce signaling ow and therefore reduced re-establishment time, it can also be observed that when combined with the delayed QoS approach it decreases the packet loss because it begin receiving packets without having to wait for the negotiation of the QoS.

8.2 Combined simulation of improvements - Performance evaluation

93

Figure 8.13: Used BW Vs time

The tool also can be useful in order to analyze other behaviour or statistics such as blocking rate of the overall simulation, average e2e delay of the different types of trafcs on the network, queue statistics over the server, the client sides and over the whole network, among others but those statistics are not discussed here as they are not completely relevant for the comparison.

Chapter 9

Conclusion
9.1 Access Network
The main interest of this investigation was to determine the issues related with the handover during a macromobility situation for a multimedia session in IMS based networks and to propose solutions in order to improve user perceived QoS during this situation. The rst main issue that arised, was to dene an architecture that will allow access network technologies such as WLAN or WiMAX to interconnect with the IMS platform and that at the same time enables them to establish end2-end QoS reservations. A proposal for an architecture was made including the most relevant components that shoud be included, as well as an analysis of how micromobility can be done, the description of the establishment of L1, L2 and L3 attachment to the network and the structure of the IP addresses and packet ow over the complete scheme.

9.2 IMS/SIP signaling

Once the complete scheme was dened, different theoretical solutions were presented in order to improve the overall time for the re-establishment of the communication, it was demostrated by the simulations that the context transfer provides a notorious improvement compared with the unoptimized case. Even if all the proposed solutions showed in the simulation an improvement compared with the unoptimized situation, it is worth to notice that an inclusion of a Bandwidth Broker can bring advantages to the system in terms of reduce re-establishment time and reduced signaling ows.

9.3 QoS
A sudden interruption of a communication can be a very unpleasant situation for a user while making use of a multimedia service, in order to minimize the impact of

9.4 Future Work

95

such situation, additional to the reduced/improved signaling ow, it is also important to determine the quality of the communication after the handover, especially in cases where there is not enough BW in the network that is receiving the HO session. In this project, different strategies were proposed, as a result it was seen that even if the effect of the congestion cannot be completely neglected, the quick re-establishment of the communication in a BE mode can decrease the negative effects of the session being queued until enough resources are available. It is important to notice that just one call moving to a new network does not considerably affects the performance of the trafc of the already established sessions.

9.4

Future Work

There will always be many possibilities to be studied in order to improve user perception of the QoS, as an extension of this project it is proposed to combine the achieved results with different mechanisms in the air interface that can also improve the overall performance of the system, it is also sugested to study other possiblities for a improved CAC mechanisms. As a direct continuation of this work, it is proposed to extend the SIP module so it can work simultaneously with the QoS trafc model, this, in order to determine the inuence that the network congestion can have over the signaling and viceversa; also to study if there is a difference in the performance once the size of the signaling messages is considered. Finally, performing a similar study but for a different access technology, like WiMAX can also be interesting due to the already existing considerations in this technology such as the HO process optimization, mentioned in the theoretical part of this report.

References
[1] Boursier, A.; Santander, T.; Adenet, A. (2005). Integration of MIP in an IMS environment. Project Report, MSc. Mobile Communications, CPK. Aalborg University. [2] Wang, H.; Prasad, D. (2005). End-2-End QoS Provisioning in UMTS networks. Project Report, MSc. Mobile Communications, CPK. Aalborg University [3] Dahlen, S. (2005). VoIP over WLAN: Security Aspects. Project Report, MSc. Mobile Communications, CPK. Aalborg University [4] Walke, B.; Seidenberg, P.; Althoff, M. P. (2003). UMTS The Fundamentals. Wiley. ISBN 0-470-84557-0. [5] Center for Netvrks-og Tjenestekonvergens (CNTK) (2003). Quality of Service. CNTK. [6] Manner, J.; Kojo, M.. (June 2004). Mobility Related Terminology. [RFC 3753]. [7] Enhanced UMTS Radio Access Network Extensions for ns-2 (2005). User Guide. Release 1.5, http://www.ti-wmc.nl/eurane/eurane user guide 1 5.pdf. [8] Ericsson (October 2004). IMS - IP Multimedia Subsystem. http://www.ericsson.com/products/white papers pdf/ ims ip multimedia subsystem.pdf. [9] The VINT Project (2005). The ns Manual. UC Berkeley, LBL, USC/ISI and Xerox PARC. http://www.isi.edu/nsnam/ns/tutorial/. [10] ING Telecoms (10 October 2005). http://research.ing.com WiMAX - Not a big winner.

[11] Schwefel, H-P.; Larsen, K.; Renier, T. (June, 2005) Mobility Schemes for Future Mobile Network Deliverable 2:SIP Mobility within the IMS CTIF Aalborg University, Denmark Siemens Mobile, Munich, Germany [12] Larsen, K.; Matthiesen, E. (November, 2005) Mobility Optimization within IMS Deliverable 3:Macro Mobility in IMS - Experimental Work CTIF Aalborg University, Denmark Siemens Mobile, Munich, Germany

REFERENCES

97

[13] Kumar, A. (June 2003) MSIP: A Protocol for Efcient Handoffs of Real-time Multimedia Sessions in Mobile Wireless Scenarios Indian Institute of Technology, Bombay [14] Schwefel, H-P.; Larsen, K.; Renier, T. (June, 2005) Mobility Schemes for Future Mobile Network Deliverable 2:SIP Mobility within the IMS CTIF Aalborg University, Denmark Siemens Mobile, Munich, Germany [15] IETF (1998). An Architecture for Differentiated services. [RFC 2475]. [16] Joos, P.; Verbiest, W. (1989). A statistical bandwidth allocation and usage monitoring algorithm for ATM networks. Proc IEEE ICC1989, Vol.1, pp. 415422. [17] Viipuri, T. (November, 2002) A Case Study of Simulating DiffServ in NS-2 (with a modied version of NS-2) [18] Liebhart, R.; Pfeil, B. (June, 2004) 3GPP/WLAN Interworking Architecture as Paradigm for NGN Acces Independence Siemens Mobile Networks ETSI TISPAN - 3GPP workshop [18] Telefonica Espana Las telecomunicaciones y la Movilidad en la Sociedad de la informacion Chapter 12 http://www.telefonica.es/sociedaddelainformacion/pdf/publicaciones/movilidad/capitulo12 Internet References [www1] http://www.webopedia.com/TERM/Q/QoS.html [www2] http://en.wikipedia.org/wiki/Quality of service [www3] http://www.umtsworld.com [www4] http://www.networkworld.com/news/tech/2003/0623techupdate.html [www5] http://www.networkworld.com/news/2005/101005-wlan-qos.html [www6] http://www.networkworld.com/details/6224.html

Appendix A

QoS
A.1 QoS and network performance
QoS parameters and perceived QoS are related with the performance of the network(s) used for the transmission of the information. In the current section is presented a description of the parameters dening the network performance and their relation with the quality of service is presented.[5]

A.1.1

Reliability

The reliability of a network implies the estimation of the failure probability. Reliable systems rarely experience failures or are able to fully recover from them. Failures can be expected from different sources such as software bugs in the entities of the network, network congestion, overload of network entities and wireless link quality. In order to increase network reliability, retransmissions of lost or corrupted data packet are required but this increase the network delay and decrease the throughput. It is important to evaluate for example throughput vs. PER performance, in order to assess the network reliability and optimize the system parameters to achieve required QoS. The signal quality also has an impact on the network reliability, if it is below certain required value for more than a given time interval (The interval depends on the application) the communication may be considered to be lost.

A.1.2

Availability/Accessibility

Availability refers to the accessibility of the network to the users (also known as accesibility). A network is available if its users are accepted when they request for a service; it is measured instantaneously and not over a period of time as reliability. Availability is affected by network congestion because it can result in a blocked call if there are not enough radio resources available. Call-blocking probability is a performance metric that assesses the network availability.

A.2 QoS Mechanisms

99

A.1.3

Dependability

A reliable systems is not necessarily highly available and viceversa, for example a reliable system can be robust by recovering of the failures but, the recovery procedures can be time consuming and result in the system denying new service requests. The combination of reliability and availability is called dependability, it is assessed by the full initiation-termination probability of a successful service.

A.1.4

Signaling Plane

Signaling can also affect network performance. Session setup requires the exchange of messages in order to for example, negotiate the media parameters and/or reserve resources along the path. Therefore, setup delays can be measured as well as the trafc correspondant to signaling messages.

A.1.5

Handover performance

A decision to initiate a handover can be made based on measurements of the current link quality and the prediction of the future link quality. There are two metrics related to the performance of handover decision: Dropping probability: Is a measure of how often a handover fails and Handover rate: Is a measure of how often a handover decisions are made. The combination of these two, assess the performance of the handover.

A.2
A.2.1

QoS Mechanisms
Multiprotocol Label Switching(MPLS)

MPLS can be seen as a routing as well as a QOS technology. In MPLS, bits are marked (or labeled), and explicit paths called label-switched paths (LSPs) are assigned through the network based on the labeling, which is contained in an MPLS header that becomes a prex to each IP frame. Labels are assigned based on agreed policies for specic applications. In an MPLS-enabled network, upgraded routers called label-switched routers (LSRs) read the labels to forward the packet to the next router in the link. MPLS can also work across network boundaries so long as network operators are using the same version of MPLS on their routers. A benet of MPLS from a QOS point of view is that it directs packet ows along specic paths, and is thus an enabler of IP trafc engineering. As it will be discussed later, neither DiffServ nor IntServ can assign paths; so the ows will run on the best-effort route that is assigned in the router, regardless of priority, but because MPLS assigns paths the QOS characteristics can be addressed.

100

QoS

A.2.2

Resource Reservation Protocol (RSVP)

RSVP reserves capacity along an end-to-end route for a specic packet ow by signaling its requirements before the ow is sent. It can be seen ass a binary protocol so that either receives a signal that the capacity is available, or it does not.

A.2.3

Integrated Services (IntServ)

IntServ is a type of Hard QoS, because it can make strict bandwidth reservations but it needs signaling rst, this signaling is done by the use of RSVP. It has to be congured on every router along a path. IntServ denes three classes of service: Guaranteed service Delay is limited and zero packet loss is guaranteed. Controlled load service Aimed to provide the same service in a heavily loaded network that you would get in a lightly loaded network. Best-effort service Is the same as the service availabe without IntServ. Each ow is assigned to one of these classes. However, IntServ could carry many different classes and is not restricted to three. IntServ has two main disadvantages, the rst one is that it places a heavy processing load on routers in the core of the network; and the second is that it does not scale well in large networks with many IntServ ows. This is because it operates at the level of each individual packet ow, and there is thus a proportionate relationship between the number of IntServ ows and the processing load. Although IntServ denes classes, it does not aggregate ows into classes before they cross the network, so that the processing load can be reduced. However, IntServ has one important advantage over DiffServ, which is that it clears a path for the ow before sending it so, it can guarantee QoS under certain circumstances.

A.3 Applications and QoS

A quality contract (SLA, Service Level Agreement) species guarantees for the ability of a network/protocol to give guaranteed performance/throughput/latency bounds based on mutually agreed measures, usually by prioritising trafc. Each application over a network can have different requirements regarding QoS and it can be divided into two main groups [www2]:

A.3.1

Inelastic

For applications with this type of service can be understood those which require certain level of bandwidth to function - any more than required is unused and any

A.3 Applications and QoS

101

less will render the service non-functioning. As an example of inelastic applications can be seen streaming multimedia due to the fact that human ear and eye are sensitive to delay and delay jitter for real-time applications, so, it may require a guaranteed throughput and big Jitter can become a hard issue in order to calculate buffer size. Also, the example of IP telephony is a clear case of inelastic application due to the fact that it may require strict limits on jitter and delay (one-way end-to end delay < 150ms jitter within a call < 1ms).

A.3.2

Elastic

By contrast, elastic applications can take advantage of however much or little bandwidth is available, for example, simple web page browsing does not have very hard restrictions related with the quality parameters mentioned above but are sensitive to data loss. This type of applications are not really relevant for the case of study and are just mentioned as a reference.

Appendix B

WLAN
B.1 PHY Layer in 802.11
The original 802.11 wireless standard operate within the 2.4 GHz band and denes data rates of 1 Mbps and 2 Mbps via radio waves using frequency hopping spread spectrum (FHSS) or direct sequence spread spectrum (DSSS). For the FHSS the 2.4GHZ band is divided into 75 one-MHz subchannels. The sender and the receiver agree on a hopping pattern, and data is sent over a sequence of subchannels. Each conversation within the 802.11 network occurs over a different hopping pattern, and the patterns are designed to minimize the chance of two senders using the same subchannel simultaneously. FHSS techniques allow for a relatively simple radio design, but are limited to speeds of no higher than 2 Mbps. This limitation is because FCC regulations restricted the subchannel bandwidth to 1 MHz, so the system has to spread de subchanel usage across the entire 2.4 GHz band, meaning the hops must be often, and as a consequence, a high amount of hopping overhead is added. In contrast, the DSSS signaling technique divides the 2.4 GHz band into 14 twenty-two MHz channels. Adjacent channels, overlap with another partially, with 3 of the 14 being completely nonoverlapping. Data is sent across one of these 22 MHz channels without hopping to other channels. To compensate for noise on a given channel, a technique called chipping is used. Each bit of user data is converted into a series of redundant bit patterns called chips. The redundancy of each chip, combined with spreading the signal across the 22 MHz channel provides a form of error checking and correction in order to minize the amount of retransimissions. The original 802.11 DSSS standard species an 11-bit chipping called a Barker sequence to encode all data sent over the air. Each 11-chip sequence represents

B.1 PHY Layer in 802.11

103

Data Rate 1 Mbps 2 Mbps 5.5 Mbps 11 Mbps

Code Length 11(Barker Sequence) 11(Barker Sequence) 8(CCK) 8(CCK)

Modulation BPSK QPSK QPSK QPSK

Symbol Rate 1MSps 1MSps 1.375 MSps 1.375 MSps

Bits/Symbol 1 2 4 8

Table B.1: 802.11 WLAN Speeds. a single data bit (1 or 0), and is converted to a waveform, called a symbol, that is sent over the air. Symbols are transmitted at a rate of 1 MSps (1 million symbols per second) using a Binary Phase Shift Keying (BPSK). In the case of 2 Mbps, Quadrature Phase Shift Keying (QPSK) is used so it doubles the data rate available in BPSK, via improved efciency in the use of the radio bandwidth. This standard was improved by the 802.11b, the main contribution of it is that this standard support two new speeds, 5.5 Mbps and 11 Mbps for the PHY layer. In order to do this, DSSS was selected as the physical layer technique for the standard because, as noted above, frequency hopping cannot support higher speeds due to FCC regulations. As can be inferred, 802.11b systems interoperate with 1 Mbps and 2 Mbps 802.11 DSSS systems, but not with FHSS systems. To increase the data rate in the 802.11b standard, advanced coding techniques are employed. Instead of using the Barker sequences, 802.11b species Complementary Code Keying (CCK), which consists of a set of 64 eight-bit code words. These code words have mathematical properties that allow them to be correctly distinguished one from another by a receiver even in the presence of substantial noise and multipath interference. The 5.5 Mbps rate uses CCK to encode 4 bits per carrier, while the 11 Mbps rate encodes 8 bits per carrier. Both speeds use QPSK as the modulation technique and signal at 1.375 MSps. Table B.1 shows the differences. 802.11b WLANs use dynamic rate shifting, in order to allow data rates to be automatically adjusted to compensate in case of very noisy environments. Rate shifting is a physical-layer mechanism transparent to the user and the upper layers of the protocol stack. As an evolution of 802.11b, the standards 802.11a and 802.11g are presented, both of them use the Orthogonal Frequency Division Multiplexing (OFDM) transmission method, the rst one transmits in the 5GHz frequency range and is not backward compatible with 802.11b and 802.11g transmits in the same 2.4GHz range so it is fully compatible. The OFDM is different from CCK-Barker modulation methods because CCK/Barker

104

WLAN

Data Rate

Code Rate

Modulation

6 Mbps 9 Mbps 12 Mbps 18 Mbps 24 Mbps 36 Mbps 48 Mbps 54 Mbps

1/2 3/4 1/2 3/4 1/2 3/4 2/3 3/4

BPSK BPSK QPSK QPSK 16 QAM 16 QAM 64 QAM 64 QAM

Code Code Bits/Subcarrier Bits/OFDM Symbols 1 48 1 48 2 96 2 96 4 192 4 192 6 288 6 288

Data Bits/OFDM Symbol 24 36 48 72 96 144 192 216

Table B.2: Modulation and Coding for WLAN OFDM Data Rates. is a single carrier method that relies on PSK modulation to transmit digital information while OFDM is a multi-carrier modulation scheme. In OFDM, PSK modulation and Viterbi convolutional coding provide data rates up to 54 Mbps. Different coding levels and modulation complexities are used to support the various rates as shown in Table B.2. In 802.11a and 802.11g OFDM systems, data is Viterbi-encoded prior to transmission and distributed across several subcarriers via an interleaver. A total of 52 subcarriers spaced 312.5 kHz apart are employed. Because of the redundancy induced by the convolutional code and the distribution of the coded bits across many subcarriers, the data can be received reliably even if several of the subcarriers are completely lost due to multipath fading. The 802.11g/a OFDM symbol rate is 250 kHz, corresponding to a symbol period of 4 sec and each OFDM pulse contains a guard interval of 800 ns for avoiding inter-symbol interference (ISI).

B.2 Data Link Layer in 802.11

Data link layer of 802.11 consists of two sublayers: Logical Link Control (LLC) and Media Access Control (MAC). 802.11 uses a 48-bit addressing as other 802 LANs, allowing bridging from wireless to wired networks, even if the MAC is unique to WLANs. The 802.11 MAC layer provides two robustness features: CRC checksum and packet fragmentation. Each packet has a CRC checksum calculated and attached to ensure that the data was not corrupted in transit. This is different from Ethernet, where higher-level protocols such as TCP handle error checking. Packet fragmentation allows large packets to be broken into smaller units when sent over the air, which is useful in very congested environments or when interference is a factor, since larger packets have a better chance of being corrupted. This technique re-

B.2 Data Link Layer in 802.11

105

duces the need for retransmission in many cases and thus improves overall wireless network performance. The MAC layer is responsible for reassembling fragments received, rendering the process transparent to higher-level protocols. The 802.11 MAC is designed to support multiple users on a shared medium.

Appendix C

WIMAX
C.1 MAC generalities
The Medium Access Control layer (MAC) supports a primary point-to-multipoint (PMP) architecture, with an optional mesh topology that will not be considered in the present case. The MAC is structured to support multiple physical layer (PHY) especications, each suited to particular operational environment. For example, duplexing techniques like Time Division Duplexing (TDD) or Frequency Division Multiplexing (FDD),are supported by the MAC protocol. The MAC is connection-oriented. For the purposes of mapping to services on SSs and associating varying levels of QoS, all data communications are in the context of a connection. Shortly after SS registration, connections are associated with service ows (one connection per service ow) to provide the reference against which to request bandwidth. Additionally, new connections may be established when a customers service needs change. A connection denes both the mapping between peer convergence process that utilize the MAC and a service ow. The service ow denes the QoS parameters for the packets that are exchanged on the connection. Each Subscriber Station (SS) shall have 48-bit universal MAC address. This address uniquely denes the SS. It is used during the initial ranging process to establish the appropiate connections, it is also used as part of the authentication process by which the BS and the SS each verify the identity of the other. Connections are identied by a 16-bit Connection Identier (CID). At SS initialization, management connections shall be established between the SS and the BS in order to exchange management messages.

C.1 MAC generalities

107

C.1.1

MAC packet format

MAC packets begin with a xed-length generic MAC header, it is followed by the payload, this payload shall consist of zero or more subheaders and the information contained may vary in length; this allows the MAC to tunnel various higher-layer types without knowledge of the formates or bit patterns of those messages. A MAC packet may also contain CRC, depending on the band and therefore, the application. Two MAC header formats are dened. The rst is the generic one that begins each MAC packet, containing either management messages or data. The second is the bandwidth request header used to request additional bandwidth.

C.1.2

MAC Data transport

Each connection is associated with a single data service. Each data service is associated with a set of QoS parameters that quantify aspects of its behavior. These parameters are managed using Dynamic Service Addition (DSA) and Dynamic Service Change (DSC) message dialogs. Four services are supported: Unsolicited Grant Service (UGS), Real-time Polling Service (rtPS), Non-real-time Polling Service (nrtPS), and Best Effort (BE). The UGS is designed to support real-time data streams consisting of xedsize data packets issued at periodic intervals. The mandatory QoS service ow parameters are: Maximum Sustained Trafc Rate, Maximum Latency, Tolerated Jitter and Request/Transmission Policy. The rtPS is designed to support real-time data streams consisting of variablesized data packets that are issued at periodic intervals. The mandatory QoS service ows parameters are: Minimum Reserved Trafc Rate, Maximum Sustained Trafc Rate, Maximum Latency and Request/Transmission Policy.

108

WIMAX

The nrtPS is designed to support delay-tolerant data streams consisting of variable-sized data packets for which a minimum data rate is required. The mandatory QoS service ows parameters are: Minimum Reserved Trafc Rate, Maximum Sustained Trafc Rate, Trafc Priority and Request/Transmission Policy. The BE service is designed to support data streams for which no minimum service level is required and therefore may be handled on a space-available basis. The mandatory QoS service ows parameters are: Maximum Sustained Trafc Rate, Trafc Priority and Request/Transmission Policy.

C.1.3

Bandwidth allocation

Normally, a SS requests uplink bandwidth on a per connection basis (implictly identifying the service ow). Bandwidth is granted by the BS to a SS as an aggregated of grants in response to per connection requests from the SS. There are numerous methods by which the SS can get the bandwidth request message to the BS. The methods are: 1. Requests 2. Grants 3. Polling 4. Contention-based focused Bandwidth Request for WirelessMAN-OFDM 5. Contention-based CDMS Bandwidth Request for wirelessMAN-OFDMA

C.1.4

MAC support of PHY

Several duplexing techniques are supported by the MAC protocol. The choice of duplexing techniques may affect certain PHY parameters as well as impact the features that can be supported, the available duplexing techniques are listed below and some of them will be deployed deeper when talking about the PHY layer. FDD

C.1 MAC generalities

109

TDD DL-MAP UL-MAP

Appendix D

SIP
The SIP architecture is dened by the following entities (See Figure D.1):

Figure D.1: SIP architecture

User Agent Client (UAC) Corresponds to the user who initiates the establisment of a session, it is equivalent to the UE/MN. User Agent Server (UAS) Corresponds to the end terminal with which the UAC wants to establish the session. It can be another user or a server; this is equivalent to the CN. Proxy Server (PS) Is the entry point for the UAC/UAS in SIP architecture. Every UAC/UAS is attached to a PS. All SIP registration requests and all session initiation requests sent from or received by the UAC/UAS ow trough the PS, which is able to modify or add some elds in the headers of SIP request.

111

Redirect Server (RS) Provides information about the mobility of an EU, the need to nd the attached proxy, which can have changed. Location Server (LS) Provides the location of UACs/UASs. It is used by both, the PS and the RS. Registration Server (RG) Allows a UAC/UAS to register to the SIP infrastructure.

Appendix E

Programming tools
E.1 Overview of NS-2
NS2 is a discrete event simulator, targeted at networking research specially a variety of IP networks. NS provides substantial support for simulation of Transport Protocols, trafc source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanisms such as Drop Tail, RED and CBQ, routing algorithms and multicast protocols over wired and wireless networks, among others. NS is a tool that is still being developed and provides the advantage that its code and modules can be modied and added by the user, it is writen in C++ and OTcl (Tcl script language with Object-oriented extensions developed at MIT).

Figure E.1: User view of NS As shown in gure E.1, NS is and Object-oriented Tcl (OTcl) script interpreter that has a simulation event scheduler, network component object libraries, and network setup (plumbing) module libraries. From the user of NS2 point of viev, NS simulation program is written has to be written in OTcl script language; in order to setup and run a simulation network, such script hsa to initiate an event scheduler, set up the network topology using the network objects and plumbing functions in the library, and tell trafc sources when to star and stop transmitting packets

E.1 Overview of NS-2

113

through the event scheduler. About the event scheduler, an event in NS is a packet ID that is unique for a packet with scheduled time and the pointer to an object that handles the event. In NS, the event scheduler keeps track of simulation time and res all the events in the event queue scheduled for the current time by invoking appropriate network components, which usually are the ones who issued the events, and let them do the appropriate action associated with packet pointed by the event. Network components communicate by passing packets, however this does not consume actual simulation time. All the network components that need to spend time handling a packet (i.e. need a delay) use the event scheduler by issuing an event for packet and waiting for the event to be red to itself before doing further action handling the packet. Another use of an event scheduler is timer. For example, keeping the time for TCP retransmissions. As mentioned before, NS is not only written in OTcl but also in C++. In order to be more efcient NS separates the data path implementation from control path implementations. The event scheduler and the basic network component objects in the data path are written and compiled using C++. These compiled objects are available to the OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the congurable variables specied by the C++ object act as member functions and member variables of the corresponding OTcl object.

E.1.1

DiffServ module

The DiffServ module in NS-2 implemented the AF PHB with a modied Random Early Detection (RED) queue mechanism. This module was contributed by Nortel Networks. AF PHB Implementation with multiple RED queues In the Diffserv approach QoS was provided by dividing trafc into different classes and marking each packet with a code point corresponding to its class, and scheduling packets accordingly. The Assured-Forwarding mechanism in NS-2 can include at most 4-physical queues for 4 PHB classes and 3 virtual queues in each physical one for the 3 drop precedences. Those drop precedences enable differential treatment of trafc within a single class. Different RED parameters are used for the virtual queues, causing packets from one virtual queue to be dropped more frequently than packets from another. A packet with a lower drop precedence is given better treatment in times of congestion because it is assigned a code point that corresponds to a virtual queue with

114

Programming tools

relatively lenient RED parameters. For example, one code point might be used for assured trafc and another for best effort trafc. The assured packet virtual queue will have higher minimum and maximum thresholds than those of best effort queue, meaning that best effort packets will enter the congestion avoidance and congestion control phase prior to assured packets. Core Router Core routers only have functionality of performing PHB on incoming packets. In NS-2, core routers maintain at most 4 physical queues in its output link, each of them can have no more than 3 virtual queue or precedences. An incoming packet is placed in a virtual queue within a physical queue is implemented as a RED-queues within the same physical queue all use the same buffer to temporarily store packets. However, all virtual queues can be congured with their own RED-parameters (minimum and maximum threshold and dropping probability). Edge Router Edge routers include the same PHB functionality as core routers, and in addition perform the following functions: . Policing. . Metering. . Packet Marking. Policer The DiffServ module currently supports six policer types. 1. Time Sliding Window with 2 Color Marking (TSW2CMPolicer): uses a CIR and two drop precedences. The lower precedence is used probabilistically when the CIR is exceeded. 2. Time Sliding Window with 3 Color Marking (TSW3CMPolicer): uses a CIR, a PIR, and three drop precedences. The medium drop precedence is used probabilistically when the CIR is exceeded and the lowest drop precedence is used probabilistically when the PIR is exceeded. 3. Token Bucket (tokenBucketPolicer): uses a CIR, a CBS and two drop precedences. An arriving packet is marked with the lower precedence if and only if it is larger than the token bucket. 4. Single Rate Three Color Marker (srTCMPolicer): uses a CIR, CBS and a EBS to choose from three drop precedences.

E.1 Overview of NS-2

115

5. Two Rate Three Color Marker (trTCMPolicer): uses a CIR, CBS, PIR, and a PBS to choose from three drop precedences. 6. NullPolicer: Does not downgrade any packets. Scheduler Scheduling modes supported in NS2 are: . Round Robin. . Weighted Round Robin. . Weighted Interleaved Round Robin. . Priority. The default scheduling mode is Round Robin. For Priority scheduling, priority is arranged in sequential order with queue 0 having the highest priority. Also, one can set the a limit on the maximum bandwidth a particular queue can get.