Data protocols in mobile networks

Christophe PLANTIN, Regional Service delivery EMEA / NDIO

V1.02
agenda

Architecture

Protocols
Layer 3: IP
Layer 4: UDP, TCP
Application: FTP, HTTP, WAP2.0

Annex

2
Architecture
Layered architecture
The key point is to keep the layered architecture in mind: knowing what
protocol applies to what layer and what are the network nodes impacted.
Regarding internet from end-to-end point of view, 3 layers are essential:
Application: HTTP, FTP, RTSP. Only impacts the 2 endpoints.
Transport: UDP, TCP. Only impacts the 2 endpoints.
Routing: IP. Used by intermediate nodes (routers) which decide what is the
best route to send the packets to destination. The first IP node is the
GGSN.

payload payload
HTTP HTTP
TCP TCP
Gi +
IP Acces + Core IP Internet IP
L1 + L2 L1 + L2 L1 + L2

MOBILE GGSN
4
SERVER
Layered model specifics for (E)GPRS
(1/2)
Regarding internet, the whole wireless network (Radio Access + Core Network)
may be seen as layer 2 which aims at forwarding IP packets (layer 3) from
(to) the mobile to (from) the first IP router in the network chain, i.e. the GGSN.
The radio protocols are fairly complex but are designed to be transparent for IP
layer.

TCP
IP IP
BSS Protocols

Core Protocols
MOBILE GGSN
5
Layered model specifics for (E)GPRS
(2/2)
Some use case are more complex; lets consider WAP service:
HTTP header is modified before reaching the server by the WAP gateway:
from HTTP wireless (w), sligntly modified for WAP2.0, to legacy
HTTP.
IP header is modified before reaching the server: private IP address are
used most of the time, so address translation is needed (NAT)
The following figure illustrates the case where a mobile attempts to reach an
external WAP site (e.g. wap.google.com).

payload payload payload payload payload payload

HTTP w HTTP w HTTP HTTP HTTP HTTP
TCP w TCP w TCP TCP TCP TCP
IP Access + IP Gi IP IP IP (local) IP (public) Internet IP
Core
L1 + L2 L1 + L2 L1 + L2 L1 + L2 L1 + L2 L1 + L2 L1 + L2

6
MOBILE GGSN Wap Gateway Internet Gateway Server
Protocols
Layer 3, Layer 4, Application
 Layer 3 : IP (v4)
Primary function: ROUTING
Secondary function: QoS (diffserv)
Reference documents:
RFC 791 http://www.faqs.org/rfcs/rfc0791.html
RFC 2474 http://www.faqs.org/rfcs/rfc2474.html
Header: 20 bytes
Important fields :
Identifier
Total length
Protocol
To be noted:
Fragments: If payload+header
is above the MTU (max transport
unit), the IP node fragments
the packet and add flag
and offset in the header.

8
 Layer 4 : UDP
Function: simple end-to-end TRANSPORT
Builds packets before sending data in the network
Delivers the packet to the right application, with the port
Does not provide:
Sequencing and in-order delivery
Delivery guarantee (no acknowledgement)
Header: 8 bytes
Reference
RFC 768 http://www.faqs.org/rfcs/rfc768.html
Checksum performed on whole packet.

Note: any application that needs network connectivity has to request a

socket opening to the Operating System [ 3 elements: protocol (UDP or
TCP), IP@, port number]. The packets sent with this socket will then be
associated to the right application, no matter how many applications may use
the network with the same IP address. As a result, the transport layer is at
least required to mention a port number.
9
 Layer 4 : TCP
Function: End-to-end TRANSPORT
Provide the UDP functions (packets building and port number)
In-order and guaranteed delivery.
Congestion control to adapt the transmission speed to network capacity
Sequencing and acknowledgments
The unit for sequence numbers in the Byte
Each Byte is acknowledged
Symmetrical protocol: each segment may
simultaneously carries acknowledgments
and new data payload.

Header: 20 bytes (28 if option [Timestamps])

Reference
RFC 793 http://www.faqs.org/rfcs/rfc793.html
Congestion control : RFC 2581 http://www.faqs.org/rfcs/rfc2581.html

10
 Layer 4 : TCP
Congestion control
Objective: to fill the pipe at best, without any knowledge of its capacity.

Window concept:
Case without window: send 1, ack 1, send 2, ack 2, (TFTP)

Congestion window CWIN): for the sending node, shows the number of
segments that have been sent but not yet acknowledged.
dynamic parameter; updated in real time by congestion control
algorithms.

Receive window (RWIN): maximum value for congestion window

static parameter, advertised by the receiving entity in the
acknowledgements
The Receive window corresponds to the maximum size of the buffer allocated
to the given socket by the receiver: the sender must know it to avoid buffer
overflow at receiver side.

11
Layer 4 : TCP
Congestion control
Typical congestion control during transfer beginning:

slow-start & congestion avoidance

Goal: increase CWIN up to RWIN.

Slow start: for each Acknowledgement (ACK) received, cwin = cwin + 1

Exponential increase of congestion window, up to ssth (slow start
threshold)

Congestion avoidance : each RTT (round trip time), cwin = cwin + 1

Linear increase of the congestion window, up to RWIN.

12
 Application layer: FTP
About the protocol:
RFC 959: http://www.faqs.org/rfcs/rfc959.html
2 ports are used by the application: 21 for control, 20 for data
Control Socket (21): commands (RETR), authentication,
Data socket (21): direct transfer over TCP.

As a result, FTP is not a representative application which is used a lot in real

network, but allows to test the TCP behavior that will also impact the following
realistic situations:
HTTP download
Mail attachment download

Note: the destination port for data is provided by the client in the FTP header by the
PORT command(no strict respect of layer independence principle). This may create some
problems, e.g. with NATs (must translate the port number in FTP header)

13
Application layer: FTP
Practical examples.
Ethereal Analysis:
time/sequence graph is
essential

On receiver side: shows the

performance

On sender side: to understand

TCP behaviour

Other graphs:
RTT (real)
Throughput (computed)

14
Application layer: FTP
Practical examples.
TCP flow control:
Beginning with slow start, up to ssthreshold (depends on the OS)
Continue with congestion avoidance while cwin < rwin

Segments losses:
-timeout: transfer restart in Slow Start state up to ssthreshold / 2
- or fast-retransmit: transfer restart in Congestion Avoidance state with
CWIN/2
In that case, the most Duplicate Ack , the less impact on throughput ( fast
recovery mechanism: congestion window increased for each dup Ack
received)

In all cases, durable throughput reduction.

15
Application layer: FTP
Important TCP parameters
RWIN:
Shall be big enough to allow the usage of all radio resource.
However, very high RWIN leads to high level of buffering in the
network (may create buffer overflow problems)
Rwin is linked with the product: throughput * RTD
May be tuned in Windows registry
Default may be 17k (warning, too low for EDGE!!!) or 64k (OK)
depending on OS version.

SACK (Selective Acknowledgement)

Without SACK: all packets following a loss shall be retransmitted
With SACK: The packets are selectively acknowledged.
The performance is significantly improved for isolated packet loss.
May be tuned in Windows registry (activated by default)
16
 Application layer: HTTP
Basic elements
Typical call-flow
1- TBF activation MS < ----- > MFS(PCUSN)
2- PDP activation MS < --------------- > S/GGSN
3- DNS request MS < ----------------------- > DNS
4- TCP handshake MS < ------------------------------ >HTTP server
5- One / several requests for elements < ------------------------------ >HTTP server

The Browser / Mobile is identified in HTTP header to allow content

adaptation:
user-agent (name of the device / browser)
x-wap-profile (details)

17
 Application layer: WAP 2.0
WAP 2.0 is based on HTTP et TCP
RFC 2616: http://www.faqs.org/rfcs/rfc2616.html
Request / Response model
The pages are encoded slightly differently than for WEB: wbxml, xhtml
Some restrictions in WAP 2.0 : http://www.wapforum.org/what/technical.htm

HTTP w HTTP w HTTP HTTP

TCP w TCP w TCP TCP
IP Access + IP Gi IP IP IP
Core
L1 + L2 L1 + L2 L1 + L2 L1 + L2 L1 + L2

MOBILE GGSN Wap Gateway Server

18
 Application layer: WAP 2.0
Advanced elements
Key elements in HTTP / WAP2.0 performance:

-TCP keep-alive
One single TCP port for several elements

-Pipelining
Several HTTP requests in the same message (i.e. same TCP port),
without waiting for the answer to previous request

-Compression
Lossless compression for text, stylesheets (typically gzip, deflate
method)

-Cache
Optimal browser cache usage
19
 WAP 2.0: emulator
We may use any PC like a WAP terminal
WAP stack on PC
Mobile used as a modem
E.g Openwave
http://developer.openwave.com/dvl/community/devnews/articles/phonesuitev7
_1004.htm

Installation and settings:

For server configuration: address and port of the Wap Gateway
For mobile configuration: chose any user agent
What for?
IP trace with Ethereal is possible (without any network probe)
Gives accurate view of the WAP page structure.
WARNING!
Does not correspond to the mobile HTTP / TCP stack, so the performance
may be (and often is) different.
The mobile response time (limited by its processing capabilities) is not realistic
when emulated on PC.
20
Annex: Streaming
 Practical example: Streaming
About the protocols:
Lots of solution with varied protocols
Some protocols selected by 3GPP: see TS 26.234 PSS Protocols and
Codecs

Codecs: video H263 or MPEG

SPv1
Transport: RTP
Control: RTCP
Presentation / session:
HTTP and RTSP

22
 Streaming: presentation and session
Objective:
Mobile request for the content
Server advertising the content type
Connection information exchange: ports

The clip description is downloaded with HTTP (packet video case)

Description: SDP file

Other session transactions are performed with RTSP

HTTP-like protocol with special command: PLAY ,

23
thank you!