1 / 58

Wireless Data Communication

Wireless Data Communication. by Tatiana Madsen & Hans-Peter Schwefel. Mm1 Short range Wireless Communication (TKM) Mm2 IP Mobility Support (HPS) Mm3 Ad hoc Networks (TKM) Mm4 Wireless TCP (HPS) Mm5 Wireless applications (HPS). www.kom.auc.dk/~tatiana/WDC.

connie
Download Presentation

Wireless Data Communication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wireless Data Communication by Tatiana Madsen & Hans-Peter Schwefel • Mm1 Short range Wireless Communication (TKM) • Mm2 IP Mobility Support (HPS) • Mm3 Ad hoc Networks (TKM) • Mm4 Wireless TCP (HPS) • Mm5 Wireless applications (HPS) www.kom.auc.dk/~tatiana/WDC www.kom.auc.dk/~hps/teaching

  2. Content • Introduction • Application Layer Protocols, basic principles • Hyper-Text Transfer Protocol (HTTP) • Properties and messages • Problems & Improvements in wireless settings • Session Initiation Protocol (SIP) • Architectures & Entities • Methods • Mobility Support • IP Technology in 3G Networks • GSM/GPRS/UMTS architecture • IP packet transport in UMTS • IP based multimedia subsystems (IMS) • Services

  3. Application Layer Protocols • Applications: communicating distributed processes • ’end-user’ applications • network services • Application Layer Protocols • highest layer of communication reference model • Define messages exchanged by applications • Provide an Application Programming Interface (API) • Use Transport Layer to exchange data • Examples: UDP based TCP based DNSVideo StreamingMultimedia Conferencing HTTP, FTP, telnet, SMTP, NNTP

  4. Design principles & approaches • End-to-end principle • communication does not rely on functions in the network • ASCII  binary encoded protocols • ASCII frequently easier to debug and implement • Examples for ASCII encoded: HTTP, SIP, SMTP • Separation of Control Messages and User Data • Separate connections (e.g. SIP)  out-of-band signalling • Special character sequences (e.g. SMTP) • Content length encoding: control messages specify length of subsequent data messages • Client-Server  peer-to-peer  in-band signalling

  5. Client-Server Paradigm • Server (software process, not piece of hardware!) • Offers a service to clients • accepts connections / requests on a (well-known) port • runs continuously • Frequently starts up multiple processes to serve multiple clients • Client • Initiates contact to server (over an IP network) • process runs only as long as needed • can use any port

  6. Content • Introduction • Application Layer Protocols, basic principles • Hyper-Text Transfer Protocol (HTTP) • Properties and messages • Problems & Improvements in wireless settings • Session Initiation Protocol (SIP) • Architectures & Entities • Methods • Mobility Support • IP Technology in 3G Networks • GSM/GPRS/UMTS architecture • IP packet transport in UMTS • IP based multimedia subsystems (IMS) • Services

  7. Hypertext Transfer Protocol (HTTP) • defined in RFCs 1768, 1945, 2616, 2617 • Client-Server Model • All communication (Requests, Response) uses TCP transport • Client: browser that requests, receives, and displays WWW objects • Server • Send objects in response to requests • Well-known port 80 (but others can be specified in URL) • Stateless protocol • self-contained requests • no state kept in server • augmented by the “cookies” concept (store state in clients) • Caching support • HTTP allows to retrieve file properties only (“HEAD” method) • Support for proxies

  8. HTTP Requests • ASCII encoded methods to retrieve (and send) files • GET, HEAD, POST, PUT, OPTIONS, DELETE, TRACE, CONNECT • headers to transport additional informatione.g. Capability selection (client lists e.g. supported character sets, server selects one)

  9. HTTP Request Message: General Format • Uniform resource locator (URL) for addressing • “http://” hostname [ “:”port ] [ abs_path [ “?”query ] ] • relative URL: without the “http:// hostname” [“:”port] part • Byte-range requests • allow completion of interrupted transfers

  10. HTTP Response • Content description • Markup language HTML (Hypertext markup language, RFCs 1866, 1867, 1942) describes structured contents • MIME notation to inform receiver about file types • in addition, receivers judge file types from file name endings

  11. HTTP State Information • HTTP is a “stateless” protocol • server does not maintain any request related information beyond request completion • “Cookies” can be used to store request related information in browser (RFC 2109) • “Set-cookie:” header  set cookie in browser • “Cookie:” header  browser sends cookie along with request • Cookie contains • name, value • optional: comment, domain, max. age, path, security info, version number

  12. e.g. corporate network HTTP Caching and Proxies • Caching • store file locally (e.g. in client) • use local copy when same file is requested again  reduce network traffic • ageing mechanism • retrieve again only if local copy is “old” • conditional requests • retrieve again only if file has changed • e.g. “If-Modified-Since: Sun, 03 Jun 2001 16:12:25 GMT” • server can respond with “304 Not Modified” • browser can force revalidation of page • Proxy Support • Split end-2-end client-server connection • used for performance & security reasons • often combined with caching (performance) • explicitly supported in HTTP/1.1 HTTP Server Internet Proxy

  13. 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:

  14. Traffic models: HTTP specifics • ‘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 timeRead 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

  15. HTTP in wireless settings • Wireless links tend to show special properties, in particular • Large delays • Low throughput • Mobility can make network-internal caches and pre-fetching difficult • Wireless devices pose restrictions • User interfaces: Small screens, limited keyboards • Potential problems of HTTP transmissions -- performance / efficient use of resources -- presentation of content on mobile devices Typical transfer sizes of HTTP: • HTTP request: 100-350 byte • responses avg. <10 kbyte, header 160 byte, GIF 4.1kByte, JPEG 12.8 kbyte, HTML 5.6 kbyte • but also many large files that cannot be ignored

  16. HTTP in wireless settings:Problems (cntd.) • big and redundant protocol headers (readable for humans (ASCII), all state needs to be transferred in headers) • uncompressed content transfer • uses one TCP connection for each request-response pair (HTTP1.0) • huge overhead per request (3-way-handshake) compared with the content, e.g., of a GET request • slow-start problematic • DNS lookup by client causes additional traffic & delay • Caching • quite often disabled by information providers to be able to create user profiles, usage statistics etc. • mobility can decrease network cache hit-ratios (if hand-overs to different caching devices occur) • security problems (how to use SSL/TLS together with proxy-caches?) • frequent use customized pages, dynamically generated on request via CGI, ASP, ...

  17. HTTP Performance Improvements Persistent Connections • Problem: Frequently retrieval of several, small embedded objects  overhead for establishment and termination of many TCP connections • Solution: More than one item transferred in one connection • HTTP/1.0: requested by “Connection: Keep-alive” header • default in HTTP/1.1 • requires specification of content length (“Content-Length” header) • for ‘dynamic’ pages: length is not known before transmission • server notifies the client • sends “Connection: close” header instead of “Content-Length” • closes the connection after transmission (see p. 4-8) Pipelining (HTTP/1.1) • send multiple GET requests (without waiting for response in between) • increase TCP efficiency for transfers of small elements • Potentially problems with servers closing connections

  18. Client Server FIN ACK SYN SYN+ACK Persistent connection SYN TCP Conn.Setup Client Server SYN+ACK ACK ACK Keep-alive + GET GET+ACK GET ACK Data Data Data GET... Data Transfer Data ACK Timeout (e.g. 15sec) FIN TCP Conn.Release FIN+ACK ACK HTTP Requests and Persistent Connections Minimum connection

  19. Improvements in HTTP1.1 • Default use of persistent connections (for several request/response transactions) • Support of pipelining • multiple ‘get’ requests at beginning of session, several responses in same order • enhanced caching of responses (useful if equivalent responses!) • several more tags and options for controlling caching (public/private, max-age, no-cache etc.) • Enhanced proxy support • encoding/compression mechanism, integrity check, security of proxies, authentication, authorization...

  20. HTML and mobile devices • HTML • designed for computers with “high” performance, color high-resolution display, mouse, hard disk • typically, web pages optimized for design, not for communication • Mobile devices • often only small, low-resolution displays, very limited input interfaces (small touch-pads, soft-keyboards) • Additional “features” • animated GIF, Java AWT, Frames, ActiveX Controls, Shockwave, movie clips, audio, ... • many web pages assume true color, multimedia support, high-resolution and many plug-ins • Web pages ignore the heterogeneity of end-systems! • e.g., without additional mechanisms, large high-resolution pictures would be transferred to a mobile phone with a low-resolution display causing high costs

  21. GPRS Backbone BSC Improvements for wireless settings But: additional complexity on devices / special SW needed! • Improved, ‘wireless-aware’ browers (clients) • Local caches & Prefetching • Strategies for content selection (e.g. do not retrieve all embedded objects immediately) • Content adaptation to device capabilities • Improved HTTP servers & content design • HTTP proxies (application gateways) • Caching & pre-fetching • Content compression, filtering, translation • automatic adaptation to network characteristics • TCP optimizations (initial window size,…) • In addition security and charging functions But: servers not aware of wireless access • With modifications of browser SW • http commands and header compression • Pre-computation proxy for content presentation Example: GPRS HTTP Proxy HTTP Server RAN RADIUS SGSN GGSN DHCP

  22. Content • Introduction • Application Layer Protocols, basic principles • Hyper-Text Transfer Protocol (HTTP) • Properties and messages • Problems & Improvements in wireless settings • Session Initiation Protocol (SIP) • Architectures & Entities • Methods • Mobility Support • IP Technology in 3G Networks • GSM/GPRS/UMTS architecture • IP packet transport in UMTS • IP based multimedia subsystems (IMS) • Services

  23. 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

  24. Redirect Server Registrar Server Location Server SIP: Architecture & Entities 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 serverprovides 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 serveraccepts 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.

  25. SIP – Basic messages • 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 • Selected Requests (Methods) • 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

  26. SIP Addressing and header format Addressing: • Addresses specified SIP URL, in the format: user@host. • Examples of SIP URLs: • sip:hostname@vovida.org • sip:hostname@192.168.10.1 • sip:14083831088@vovida.org • Example: SIP Header INVITE sip:5120@192.168.36.180 SIP/2.0 Via: SIP/2.0/UDP 192.168.6.21:5060 From: sip:5121@192.168.6.21 To: <sip:5120@192.168.36.180> Call-ID: c2943000-e0563-2a1ce-2e323931@192.168.6.21 CSeq: 100 INVITE Expires: 180 User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled Accept: application/sdp Contact: sip:5121@192.168.6.21:5060 Content-Type: application/sdp

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

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

  29. 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

  30. 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

  31. Content • Introduction • Application Layer Protocols, basic principles • Hyper-Text Transfer Protocol (HTTP) • Properties and messages • Problems & Improvements in wireless settings • Session Initiation Protocol (SIP) • Architectures & Entities • Methods • Mobility Support • IP Technology in 3G Networks • GSM/GPRS/UMTS architecture • IP packet transport in UMTS • IP based multimedia subsystems (IMS) • Services

  32. GSM: Global System for Mobile Communication History: • 2nd Generation of Mobile Telephony Networks • 1982: Groupe Spèciale Mobile (GSM) founded • 1987: First Standards defined • 1991: Global System for Mobile Communication, Standardisation by ETSI (European Telecommunications Standardisation Institute) - First European Standard • 1995: Fully in Operation

  33. Components: BTS: Base Transceiver Station BSC: Base Station Controller MSC: Mobile Switching Center HLR/VLR: Home/Visitor Location Register AuC: Authentication Center EIR: Equipment Identity Register OMC: Operation and Maintenance Center Transmission: Circuit switched transfer Radio link capacity: 9.6 kb/s (FDMA/TDMA) Duration based charging Network and Operation Radio Subsystem (RSS) Switchung Subsystem Subsystem Base StationSubsystem U A A m bis VLR MS BTS BSC HLR AuC O MS BTS OMC BSC MSC EIR MS Connection to BTS ISDN, PDN PSTN Radio Link GSM – Architecture

  34. GPRS: General Packet Radio Service • Packet Switched Extension of GSM • 1996: new standard developed by ETSI • Components integrated in GSM architecture • Improvements: • Packet-switched transmission • Higher transmission rates on radio link (multiple time-slots) • Volume based charging  ‚Always ON‘ mode possible • Operation started in 2001 (Germany)

  35. Components: CCU: Channel Coding Unit PCU: Packet Control Unit SGSN: Serving GPRS Support Node GGSN: Gateway GPRS Support Node GR: GPRS Register Transmission: Packet Based Transmission Radio link: Radio transmission identical to GSM Different coding schemes (CS1-4) Use of Multiple Time Slots Volume Based Charging GPRS - Architecture

  36. Universal Mobile Telecommunication System (UMTS) • Currently standardized by 3rd Generation Partnership Project (3GPP), see http://www.3GPP.org[North America: 3GPP2] • So far, three releases: R’99, R4, R5 Modifications: • New methods & protocols on radio link  increased access bandwidth • Coexistence of two domains • Packets Switched (PS) • Circuit Switched (CS) • New Services • IP Service Infrastructure: IP Based Multimedia Subsystems (IMS) (R5)

  37. UMTS Domains (Rel 5) IP based MultimediaSubsystem Application and Services IMS AppServ MRF I-CSCF S-CSCF AppServ SCP P-CSCF HSS Gi GGSN GMSC MSC MGW MSC Server SGSN RAN Iu CS Iu PS PS Domain CS Domain

  38. UMTS Radio Access Network (UTRAN): architecture • W-CDMA (Wideband Code Division Multiple Access) on Radio Link • transmission rate theoretically up to 2Mbit/s (realistic up to 300kb/s)

  39. UMTS Standardisation: 3GPP • Collaboration Agreement, Partners: ARIB, CCSA, ETSI, T1, TTA, and TTC • Technical Work Done in WGs • Deliverables • Technical Reports/Technical Specifications • Approval by Consensus or Vote • Change Control When Sufficiently Stable • Inter-WG Coordination • In TSGs • Information Exchange through Liaison Statements

  40. User IP (v4 or v6) Application Server UTRAN SGSN GGSN Terminal Radio Bearer GTP-U GTP-U UMTS: Transport of user IP packets IP tackets are tunnelled through the UMTS network (GTP – GPRS tunneling protocol) Application IP v4 or v6 IP v4 or v6 IP v4 or v6 Relay Relay PDCP PDCP GTP‑U GTP‑U GTP‑U GTP‑U RLC RLC UDP/IP v4 or v6 UDP/IP v4 or v6 UDP/IP v4 or v6 UDP/IP v4 or v6 MAC MAC AAL5 AAL5 L2 L2 L2 [Source: 3GPP] L1 L1 L1 ATM ATM L1 L1 Uu Iu-PS Gn Gi

  41. IP Transport: Concepts • PDP contexts (Packet Data Protocol) activation • done by UE before data transmission • specification of APN and traffic parameters • GGSN delivers IP address to UE • set-up of bearers and mobility contexts in SGSN and GGSN • activation of multiple PDP contexts possible • Access Point Names (APN) • APNs identify external networks (logical Gi interfaces of GGSN) • At PDP context activation, the SGSN performs a DNS query to find out the GGSN(s) serving the APN requested by the terminal. • The DNS response contains a list of GGSN addresses from which the SGSN selects one address in a round-robin fashion (for this APN). • Traffic Flow Templates (TFTs) • set of packet filters (source address, subnet mask, destination port range, source port range, SPI, TOS (IPv4), Traffic Class (v6), Flow Label (v6) • used by GGSN to assign IP packets from external networks to proper PDP context • GPRS tunneling protocol (GTP) • For every UE, one GTP-C tunnel is established for signalling and a number of GTP-U tunnels, one per PDP context (i.e. session), are established for user traffic.

  42. PDP Context X1 (APN X, IP address X, QoS1) PDP Context X2 (APN X, IP address X, QoS2) GGSN GGSN SGSN Terminal IP Transport: PDP Context & APNs ISP X PDP Context Y (APN Y, IP address Y, QoS) PDP Context Z (APN Z, IP address Z, QoS) Same PDP (IP) address and APN ISP Y APN X PDP Context selectionbased on TFT (downstream) ISP Z APN Y APN Z [Source: 3GPP]

  43. UMTS Data Transport: Bearer Hierarchy Air Interface CN TE MT UTRAN/ CN Iu TE/AS GERAN Gateway EDGE NODE End-to-End Service(IP Bearer Service) TE/MT Local External Bearer UMTS Bearer Service UMTS Bearer Bearer Service Service Service CN Bearer Radio Access Bearer Service Service Radio Bearer Iu Bearer Backbone Service Service Bearer Service Physical Physical Radio Bearer Service Service 3G GGSN RAN 3G SGSN User Equipment

  44. UMTS Bearer: Traffic Classes(Source TS23.107, V5.2.0) UMTS Bearer: Selected Traffic/QoS Parameters • Maximum Bitrate (kb/s) • Guaranteed Bitrate (kb/s) • Source statistics descriptor (`speech´, `unknown´) • Transfer delay (ms) • SDU error ratio • Maximum SDU size (bytes)

  45. Example: PDP Context Setup … …

  46. 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)

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

  48. Network Entities 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)

  49. 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

  50. 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

More Related