PhD Course: UMTS and IP based mobile networks

PhD Course: UMTS and IP based mobile networks
Werner Mohr, Ljupco Jorguseski, and Hans-Peter Schwefel Day 1 Architecture and Core Network Aspects (HPS) Day Radio Resource Management and Radio Planning (LJ) Day 3 Radio Propagation (WM) Day 4 W-CDMA & TD-CDMA (WM) Day 5 Cell Structure & Outlook Beyond 3G (WM) Organized by Ramjee Prasad

Content Performance & Network Planning
Performance Impacting Factors, circuit switched planning approaches, packets switched planning IP Quality of service and performance optimizations Basic methods, implementation approaches Protocol Enhancements (RoHC) Session Initiation Protocol (SIP) Architectures & Entities Methods IP based multimedia subsystems (IMS) Architecture & components Registration & Call Routing Services Outlook: Beyond 3G Networks

Core Network Planning Determine topology, # and type of network elements and link capacities Plus planning of radio cells (topic in subsequent lecture) Based on operator requirements on: Security Availability/Reliability Performance (Transmission-, Processing-, Queueing delays) Input data for planning: Traffic and Mobility models # subscribers, # active users during busy hours, # active PDP contexts, traffic characterisation Functional Requirements E.g. number of supported APNs, supported security features, redundancy for high availability

IP Protocol: Packet-Based Transport
Advantages of Packet-Based Transport (as opposed to circuit switched) Flexibility Optimal Use of Link Capacities, Multiplex-Gain for bursty traffic Drawbacks Buffering/Queueing at routers can be necessary Delay / Jitter / Packet Loss can occur Overhead from Headers (20 Byte IPv4, 20 Byte TCP) ... and it makes performance modeling harder!! Main motivation for Performance Modeling: Network Planning Evaluation/optimization of methods for congestion control & QoS provisioning  + queueing

The circuit switched scenario
K channels Users allocate one channel per call for certain call duration If all channels are allocated additional starting calls are blocked How many channels are necessary to achieve a call certain maximal blocking probability? Common Model Assumptions: Calls are arriving according to a Poission Process (justified for large user population, limit theorems for stochastic processes) with rate  Call durations are exponentially distributed with mean T (okay for voice calls)

Computation of Blocking Prob.: M/M/K/K model
Poisson arrival of calls (first ’M’  Markovian) with rate  ti : arrival time of call i Xi:=ti+1-ti : interarrival time Poisson process of rate lambda: Xi independent and Pr(Xi<x)=1 - exp(- x) Exponentially distributed call holding times of rate 1/T per call (second ’M’) K ’Servers’ No additional waiting room for calls beyond K Illustration of exponential distribution (Prob. that call longer than x, leftmost curve)

Computation of blocking probabilities: M/M/K/K models
    K 1/T 2/T K/T 3/T Finite Birth-Death Process (see e.g. [Cassandras & Lafortune]): Probability of i calls active [using Chapman-Kolmogorov Equations] pi := Pr(n=i) = p0 (T)i /i! , i=1,…,K where p0 = 1/[(T)i /i!] (sum taken over i=0 to K) Probability of blocked call: p(B) = pK = p0 (T)K /K! [also known as Erlang-B formula]

Challenges in Packet Switched Setting
Challenges in IP networks: Multiplexing of packets at nodes (L3) Burstiness of IP traffic (L3-7) Impact of Routing (L3) Performance impact of transport layer, in particular TCP (L4) Wide range of applications  different traffic & QoS requirements (L5-7) + Feedback: performance  traffic model, e.g. for TCP traffic, adaptive applications (cross-layer optimization) HTTP TCP IP Link-Layer L5-7 L4 L3 L2 Traffic Model Network Model Performance Values (Delay, Loss, etc.) TCP / adaptive applics. Mobility Model

Network model example: M/M/1/K queue
 Poisson arrival of packets (first ’M’  Markovian) with rate  Exponentially distributed service times of rate  (second ’M’) Single Server (1) Finite waiting room (buffer) for K packets Often also specified: service discipline Default: First-In-First-Out Others: Processor Sharing, Last-In-First-Out, Earliest Deadline First,...  Finite buffer (size K)

M/M/1/K queue: Performance
    K     Finite Birth-Death Process (see e.g. [Cassandras & Lafortune]): Probability of i packets in queue [using Chapman-Kolmogorov Equations] pi := Pr(n=i) = (1-)/(1- K+1) * i , where = /  1, i=0,…,K Probability of packet loss: p(loss) = pK = (1-)/(1- K+1) * K Average Delay: Ď = 1/[ (1-pK)] * /(1- K+1) * [(1- K)/ (1-) – K K ]

More realistic models: ON/OFF Models
Parameters: N sources, each average rate  During ON periods: peak-rate p Mean duration of ON and OFF times ON & OFF Times exponential  MMPP representation with N+1 states

Traffic models: General hierarchical models
Mathematical /stochastic description of traffic Frequently used: Several levels with increasing granularity E.g. 3 levels: sessions, connections, packets Or: 5-level model:

Example: HTTP traffic model
‘Main’ objects contain zero or more embedded objects that the browser retrieves  Correlated requests for embedded objects within retrieval of main object HTTP Session (User A) Session Level HTTP Session (User B) HTTP Session (User C) ... ’exit browser’ ’start browser’ ’click’ ’click’ ’click’ ... Download Phase 1 Idle time Read time Download Phase 2 Dld. Phase 3 Dld. Phase K Connection/ Flow Level ... Get Main Object Get embedded Obj. 1 Get emb. Obj. 2 Get emb. Obj. N Packet Level, TCP dynamics (not shown here) Statistics: Session arrivals: Renewal process (Poisson) Idle time: heavy-tail # embedded objects: geometric (measurements e.g. mean 5) Object size: heavy-tailed

IP QoS Solution I: Over-Provisioning
Design network to be able to deal with worst-case traffic scenario Advantage: no impact on architecture, protocols and user equipment simplicity Problems: Traffic depends on number of active users, user mobility, type of application, daily utilization profile  difficult forecasting Data traffic tends to be very bursty (even `self-similar´)  waste of resources if planned for worst-case scenario  can be very expensive Unforseeable events can occur (new applications; changes in user behavior, e.g. always-on)

QoS Solutions II: DiffServ
Basic Idea: reduce queueing delay/loss for critical traffic by preferential treatment at routers  improve per-hop transmission behavior Packets marked by DiffServ Code Points (DSCPs, 6bit) Various scheduling disciplines at routers possible (e.g. static priority, weighted fair queueing) Advantage: Simple and scalable Problem: No performance guarantees unless used in conjunction with connection admission and traffic shaping/policing at ingress routers SLA Customer Network DiffServ Domain Boundary Router Host Edge Router SLA: Service Level Agreement

QoS Solutions III: IntServ/RSVP
Fundamental Idea: Reserve necessary resources for each traffic flow along its transmission path, which requires: Connection Admission Control (CAC): traffic specification + info about available resources at router  admission decision (if no, then re-routing) Packet Classification: which flow does it belong to? Packet Scheduling: make sure, flow obtains resources as specified

QoS Solutions III: IntServ/RSVP (cont`d)
Signalling by Resource Reservation Protocol (RSVP) Path Message: sender initiated, description of traffic parameters and path Resv Message: receiver initiated, causes connection admission/reservation along path; specifies QoS parameters Other messages for reservation teardown and error treatment Soft-State concept: periodic refresh of reservation required Advantages: Fine Granularity: per flow treatment, flexible set of QoS parameters Able to provide QoS guarantees (if admission, classification, scheduling is performed correctly) Disadvantages Scalability problem: management of state for each single flow Complexity (already connection admission can be complex, e.g. effective bandwidths, etc.)

Protocol Enhancements: Motivation
Wireless links tend to show poor performance Large delays Low throughput Bit errors / packet losses due to radio transmission Protocols in IP family not originally designed for such links Increased volume due to headers Deficiencies of TCP flow control ... many more (e.g. applications HTTPWAP) Protocol Enhancements are required, two examples discussed here Robust Header Compression (RoHC) Enhancements for Wireless TCP

Robust Header Compression (RoHC)
Motivation IP voice packets: header 40/60Bytes, average payload 25Bytes TCP ACK packets: header 40/60 Bytes, payload often 0Bytes Data in many header fields … … hardly ever changes e.g. source/destination address within same IP flow … or changes in a regular pattern Idea: reduce header length by compression, e.g. differential encoding of fields and/or variations of Huffman compression Compression can be applied to several protocol headers, e.g. RTP/UDP/IP

Robust Header Compression (RoHC)
Synchronized compression context required in compressor and decompressor Lost packets Synchronization disturbed Additional mechanisms for context synchronisation required: Robustness Error detection by Cyclic Redundancy Codes (CRC) Loss detection through sequence numbers Reduced compression efficiency price for error robustness Current RoHC methods: 40 Bytes RTP/UDP/IP header on average 1 or 2 bytes

RoHC in UMTS L1 RLC PDCP MAC IP v4 or v6 Application ATM UDP/IP GTP‑U AAL5 Relay L2 3G‑SGSN UTRAN MS Iu-PS Uu Gn Gi 3G‑GGSN RoHC optional part of Packet Data Convergence Protocol (PDCP)  headers compressed only over radio link (RNC-UE) In principle compression already in GGSN possible, but Flow identification/separation necessary Large number of flows (up to 104 active flows)

Session Initiation Protocol -- SIP
SIP: Application layer signalling protocol (RFC 3261) Provides call control for multi-media services initiation, modification, and termination of sessions terminal-type negotiation and selections call holding, forwarding, forking, transfer media type negotiation (also mid-call changes) using Session Description Protocol (SDP) Provides personal mobility support Independent of transport protocols (TCP, UDP, SCTP,…) ASCII format SIP headers Separation of call signalling and data stream Application types/examples: Interactive Voice over IP (VoIP) Multimedia conferences (multi-party, e.g. voice & video) Instant messaging Presence service Support of location-based services

SIP – Basic messages Selected Requests (Methods) Responses
INVITE: initiate call ACK: confirm final response (after ‘invite’) BYE: terminate call CANCEL: cancel pending requests OPTIONS: queries features supported by other side REGISTER: register with location service Responses 1xx Intermediate results e.g. 180 Ringing 2xx Successful Responses e.g. 200 OK 3xx Redirections e.g. 302 Moved Temporarily 4xx Request Failures 5xx Server Failures 6xx Global Errors

SIP Addressing and header format
Addresses specified SIP URL, in the format: Examples of SIP URLs: Example: SIP Header INVITE SIP/2.0 Via: SIP/2.0/UDP :5060 From: To: Call-ID: CSeq: 100 INVITE Expires: 180 User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled Accept: application/sdp Contact: Content-Type: application/sdp

SIP: Architecture & Entities
Location Server Redirect Server Registrar Server User Agent User Agent Proxy Server Proxy Server User agent: An application program which initiates SIP requests (User agent client) and also acts upon (accepts, rejects or re-directs) incoming SIP requests (User agent server) Location server provides SIP redirect or proxy servers information about a callee's possible location(s). Proxy server takes requests on behalf other user agents or servers and forwards them to the next hop. Redirect server accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. Unlike a proxy server, it does not initiate its own SIP request. Registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and may offer location services.

SIP Call Signalling: Example
INVITE Location/Redirect Server Proxy Server Proxy Server User Agent 302 (Moved Temporarily) ACK INVITE Call Setup INVITE 180 (Ringing) 180 (Ringing) 180 (Ringing) 200 (OK) 200 (OK) 200 (OK) ACK ACK ACK Media Path RTP MEDIA PATH Call Teardown BYE BYE BYE 200 (OK) 200 (OK) 200 (OK)

SIP: Separation of signalling and data
Route of SIP messages (proxy chain) different than media stream route:  Potential Problems with Firewalls & NATs

SIP: Mobility support User Mobility (change of terminal)
Registration via SIP ‘REGISTER’ mid-session mobility (application mobility): call transfer, SIP method ‘REFER’ (RFC3515) Host Mobility (change of IP address) Pre-call: re-register, routing of ‘INVITE’ based on SIP-URL mid-call: re-invite

SIP: additional topics
Not touched in this lecture, see IETF SIP WG: Multitude of SIP extensions: new methods (e.g. instant messages) SIP over NAT/FW Authentication and security aspects Support of location based services Discovery of SIP entities (e.g. DNS SRV records) Service Discovery (e.g. SLP) Reliability aspects of SIP-based call control

IP based Multimedia Subsystem (IMS)
Additional domain in UMTS Rel. 5, based on Packet-switched domain Establishment and Control of IP based multimedia calls based on SIP Standardized interfaces to applications Authentication and authorisation of service access Service based charging QoS control Global roaming and access to home services Originally planned to be based on IPv6 ‘Network centric’ approach (as opposed to IETF SIP) In principle access independent (e.g. also WLAN access) No Network layer mobility support in IMS (mobility via SIP or in access networks)

Network Entities and Protocols
R-SGW Applications and Services IM Subsystem Multimedia IP Networks HTTP Others ? ? Sh HSS CSCF BGCF ? SIP SIP Mk ISC Diameter SLF Mm SIP TCP UDP SIP BGCF CAP IM-SSF SIP Mi Cx Dx Mw CS Domain -or- PSTN -or- Legacy -or- External OSA OSA-SCS ? SIP Mj Sc CSCF SIP MGCF T-SGW SIP ? AS PCF Mg H248 Mr R-SGW SIP Mc MAP Mp Sr MRF-C MRF-P SCP ? COPS MGW H248 Gr Gc Go Gm CAP SIP „Gi-Cloud“ GGSN TCP/IP/UDP/RTP/… UE PS Domain Alternative Access Networks Gn GERAN MT TE SGSN UTRAN R Uu Iu

Network Entities CSCF (Call State/Service Control Function)
Additionally: - Charging Entities - Security Entities - Lawful Interception - Firewalls - DNS, DHCP, TRIP, … - QoS Entities - OAM and NM - … CSCF (Call State/Service Control Function) PCF (Policy Control Function) HSS (Home Subscriber Service) SLF (Subscription Locator Function) MRF (Multimedia Resource Function) BGCF (Breakout Gateway Control Function) MGCF (Median Gateway Control Function) MGW (Media Gateway) T-SGW (Transport Signaling Gateway) R-SGW (Roaming Signaling Gateway) AS (Application Server) SCP (Service Content Provider) IM-SSF (Service Switching Function) OSA-SCS (Service Capability Server)

IMS: Important Network Elements
HSS : Home Subscriber Service Database for subscriber related information Identification (SIP, Mail, E.164, Label, IMSI, ...) Location management (P-CSCF, S-CSCF, IP address) List of authorized services, List of subscribed services Quintuplets for Security Proxy Call State Control Function (P-CSCF) First contact point of an operator‘s network (for the mobile terminal) Forwarding of SIP messages between terminal and core network Generation of charging records Translation of IDs other than SIP URIs into SIP URIs (e.g. E.164 numbers) Termination of confidentiality and integrity, Lawful interception Authorisation of bearer resources and QoS management Detection of emergency calls and selection of a emergency S-CSCF Translation of SIP URIs for local services SIP header compression

IMS: Important Network Elements (cntd.)
Interrogating Call State Control Function (I-CSCF) First contact point of an operator‘s network (for other operators) Forwarding of SIP messages (proxy functionality) Assignment of a S-CSCF during registration and during invite (for services for not registered subscribers) Generation of charging records Hiding of internal network configuration/capacity/topology Serving Call State Control Function (S-CSCF) Performs session control and service triggering Acts as a registrar according to RFC2543 May behave as a Proxy Server as defined in RFC2543, i.e. it accepts requests and services them internally or forwards them on, possibly after translation. May behave as a User Agent as defined in RFC2543, i.e. it may terminate and independently generate SIP transactions. Interaction with service platform(s), provides endpoints with service event related information Authentication (based on quintuplets from HSS), Generation of charging records

Levels of Registration
Visited Network Home Network UE xGSN DHCP CSCF HSS CSCF AS HLR UMS Bearer Level DHCP IM Subsystem Application?

Registration in a Roaming Scenario
Home Network of MS B Home Network of MS A HSS-A HSS-A User Profile User Profile 5 5 I-CSCF-A S-CSCF-A S-CSCF-B I-CSCF-A 4 4 2 2 MS A Network visited by MS A Network visited by MS B MS B REGISTER REGISTER P-CSCF-A P-CSCF-B 1 1

Routing of Mobile-To-Mobile Calls
Home Network of MS A Home Network of MS B HSS-A I-CSCF-B HSS-B User Profile 4 5 3 I-CSCF-A S-CSCF-A S-CSCF-B User Profile MS A Network visited by MS A Network visited by MS B MS B 6 REGISTER REGISTER Call Control INVITE P-CSCF-A P-CSCF-B 1 2 7

Routing of Mobile Calls to CS or PSTN (3GPP)
Home Network of MS A Foreign Network PSTN HSS-A BGCF-A A BGCF-B User Profile 4 User Profile 3 I-CSCF-A S-CSCF A I-CSCF-B 5 B REGISTER MGCF-B T-SGW-B MS A Network visited by MS A 6 Call Control INVITE P-CSCF-A 1 2 7 Gateway Control MGW-B

SIP in IMS Mandatory existence of P-CSCF as first point of contact
Network initiated call release (e.g. due to missing coverage or administrative reasons) Proxies are able to send BYE Network Control of Media Types P/S-CSCF checks the SDP in the SIP body If SDP contains invalid parameters (e.g. not supported codecs), P/S-CSCF rejects the SIP request by sending a 488 (“not acceptable here”) response that contains a SDP body indicating parameters that would be acceptable by the network Network Hiding (Encryption of Route and Via Headers) Additional Signaling Information For example Cell-ID, Mobile Network/Country Code, Charging-IDs Information transported P-header based solution Compression SIP Compression is mandatory as radio interface is a scarce resource Compression / decompression of SIP will be performed by the UE and the P-CSCF Authentication & Integrity protection S-CSCF performs the Authentication using AKA P-CSCF checks the integrity of messages received via the air interface via IPsec ESP

IMS: Services are Home Controlled
The Serving CSCF (S-CSCF) is located in the Home Network The Visited Network only provides a proxy (P-CSCF): all calls are always first routed to the Home Network. 3rd Party Service Provider Home Network Application Server Application Server Visited Network Application Server ? ISC ? Proxy CSCF Serving CSCF SIP SIP SIP UE

IMS Security Architecture
IM Core Network Subsystem ISIM UA UE Mutual authentication IMS AKA HSS I-CSCF S-CSCF Home / Serving Network IPSec: Integrity Protection IPSec: Confidentiality and Integrity Protection P-CSCF Visited / Home Network

End User Services: Categorization
Unified Messaging MMS Chat Conferencing Entertainment m-Gaming Gambling Audio Video Communication Voice over IP Buddy list Presence configuration Availability configuration Commerce m-Banking m-Shopping m-ticketing & reservations m-advertisement Information Dynamic Info Svcs. Static Info Svcs.

Service Market Analysis Willing to Use (W2U) / Willing to Pay (W2P)
Source: Adopted from Siemens End-User Survey 2000 Commerce Entertainment Communication Information 27 % 14 % 29 % 30 % Service Desirability (W2U) Commerce 12 % Information 3 % Communication 57 % Entertainment 28 % Source: Durlacher UMTS Report Service Revenue Potential (W2P)

Prediction: services in mobile NWs
350 300 Browsing & Download 250 Messaging Mbit/ User/ Month 200 150 Real-Time Multimedia 100 50 Voice (Minutes of Use x 9,6 kb/s) 2003 2004 2005 2006 2007 2008 Within the next six years data and multimedia traffic will overrule voice In 2008 Multimedia Communication will account for ¼ of mobile traffic

Summary Performance & Network Planning

Outlook: Beyond 3G networks
Services and applications IP based core network Media access system IMT-2000 UMTS WLAN type cellular GSM short range connectivity Wireline xDSL other entities DAB DVB return channel: e.g. GSM download channel New radio interface Unifies different access technologies IP as convergence layer Mobility support on the network layer Ad-hoc networks can extend geographic reach of cellular wireless technologies Personal Area Networks (PAN) Ubiquitous Computing

Mobile IP Motivation: Host mobility & Routing
Problem: IP address identifies host as well as topological location Reason: IP Routing: Routes selected based on IP destination address network prefix (e.g ) determines physical subnet change of physical subnet  change of IP address to have a topological correct address Solution? Host-based routing: Specific routes to each host Handover  change of all routing table entries in each (!) router Scalability & performance problem Solution? Obtain new IP-address at hand-over Problem: how to identify host after handover? DNS update  performance/scalability problem Higher protocol layers (TCP/UDP/application) need to ‘handle’ changing IP address  Development of mobile IP Subnet A IP network Mobile Node Subnet B

Mobile IP: Principles & Terminology
Home network IP network HA Mobile Node Home Address IP1 FA Home Address IP1 Care of Address: CoA1 Correspondent Node Visited network Underlying Approach: separate host identifier and location identifier  maintain multiple IP addresses for mobile host Terminology: Mobile Node (MN) with fixed IP address IP1 (home address) Home Network: subnet that contains IP1 Home Agent (HA): node in home network, responsible for packet forwarding to MN Visited Network: new subnet after roaming / handover Care-of Address (CoA): temporary IP address within visited network Foreign Agent (FA): node in visited network, responsible for packet forwarding to CoA

Mobile IP: Tunneling &Triangle Routing
FA Visited Network Home Network  CoA1 Mobile Node IP1, CoA1 IP2   Home Agent Subnet IP1  Source: Mobile IPv4 illustrated  CN sends packets to the MN using its Home Address IP1  HA tunnels them to FA, using CoA1; FA forwards them to MN  MN sends packets back to the CN using IP2 (without any tunneling)  Home Agent needs to contain mapping of care-of address to home address (location register) Correspondent Node (CN) IP2

Mobile IP: Agent Discovery & Registration
[Agent Solicitation] (opt.) HA FA MN Agent Advertisement Obtain c/o address Registration Request Registration Reply Time Mobile Node finds out about FA through Agent Advertisements FAs broadcast Advertisements in periodic intervals Advertisements can be triggered by an Agent Solicitation from the MN Care of Address of the MN is determined, either Dynamically, e.g. using Dynamic Host Configuration Protocol (DHCP) Or: use IP address of FA as CoA MN registers at FA and HA: Registration Request & Reply MN signals COA to the HA via the FA HA acknowledges via FA to MN Registration with old FA simply expires (limited life-time, soft-state)

MIP messages:Agent advertisement
Procedure: HA and FA periodically broadcast advertisement messages into their subnets MN listens to these messages and detects, if it is in the home or a (new?) foreign network when new foreign network: MN reads a COA from the advertisement (opt.) ICMP Router Discovery extension: 7 8 15 16 23 24 31 type code checksum #addresses addr. size lifetime router address 1 preference level 1 router address 2 preference level 2 . . . type = 16 R: registration required B: busy, no more registrations H: home agent F: foreign agent M: minimal encapsulation G: GRE encapsulation r: =0, ignored (former Van Jacobson compression) T: FA supports reverse tunneling reserved: =0, ignored type = 16 length sequence number registration lifetime R B H F M G r T reserved COA 1 COA 2 . . .

MIP messages: registration request & reply
Registration Request (via UDP) 7 8 15 16 23 24 31 S: simultaneous bindings B: broadcast datagrams D: decapsulation by MN M mininal encapsulation G: GRE encapsulation r: =0, ignored T: reverse tunneling requested x: =0, ignored type = 1 S B D M G r T x lifetime home address home agent COA identification extensions . . . Registration Reply (UDP) Example codes: registration successful 0 registration accepted 1 registration accepted, but simultaneous mobility bindings unsupported registration denied by FA 65 administratively prohibited 66 insufficient resources 67 mobile node failed authentication 68 home agent failed authentication 69 requested Lifetime too long registration denied by HA 129 administratively prohibited 131 mobile node failed authentication 133 registration Identification mismatch 135 too many simultaneous mobility bindings 7 8 15 16 31 type = 3 code lifetime home address home agent identification extensions . . .

MIP: Care-of addresses
MN obtains local care-of address either from FA Advertisement (see before) Or via Dynamic Host Configuration Protocol (DHCP) supplies systems with all necessary information, such as IP address, DNS server address, domain name, subnet mask, default router etc. Client/Server-Model: client sends request via L2 broadcast server (not selected) server (selected) client initialization DHCPDISCOVER DHCPDISCOVER determine the configuration determine the configuration collection of replies DHCPOFFER DHCPOFFER selection of configuration time DHCPREQUEST (reject) DHCPREQUEST (options) confirmation of configuration DHCPACK initialization completed

The future of mobile networks
“Much of the initial enthusiasm for the concept appears to have evaporated and the original launch target of autumn this year has been slipping. When the government asked companies to apply for licences, international consortia rushed to compete. (…) Since then, the economy has sunk into recession, forecasts of the number of subscribers have been scaled down and the need for heavy investment has scared many of the original shareholders.” Financial Times: September 1992 “The Future of GSM Mobile Communications”

Acknowledgements (Lectures 1 & 2)
Tutorial: IP Technology in 3rd Generation mobile networks, Siemens AG (J. Kross, L. Smith, H. Schwefel) Lecture notes: Wireless Data Communication, MM5, Tutorial: Voice over IP Protocols – An Overview, Various 3GPP slide-sets Siemens ICM N PG U SE and Siemens CT IC 3 Other References IETF ( WGs: MMUSIC (old), SIP 3GPP:

PhD Course: UMTS and IP based mobile networks

Similar presentations

Presentation on theme: "PhD Course: UMTS and IP based mobile networks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

PhD Course: UMTS and IP based mobile networks

Similar presentations

Presentation on theme: "PhD Course: UMTS and IP based mobile networks"— Presentation transcript:

Similar presentations

About project

Feedback