IP Convergence Layer for HIPERLAN/2IP Convergence Layer for HIPERLAN/2Workshop IP in

Telekommunikationsnetzen

25./26. Januar 2001, Bremen

Servane Bonjour, France TelecomPhilippe Bertin, France Telecom

Sven Hischke, Deutsche TelekomArndt Kadelka, Aachen University of Technology

Andreas Krämling, Aachen University of Technology

Matthias Lott, Siemens AGMark West, Roke Manor Research

Presentation OutlinePresentation Outline

• Transfer of IPv4 and IPv6 Packets

• Address Management

• Header Compression

• Quality of Service with HIPERLAN/2 IP CL

• Network Handover

• Stand-by Mode Support

• Conclusion

IP Convergence Layer for HIPERLAN/2IP Convergence Layer for HIPERLAN/2

• Goal : to efficiently transfer IP packets on an H/2 radio link with QoS and handover management

• Common part convergence layer is defined in the H/2 standard

• Ethernet and 1394 service specific convergence sub-layers are defined in H/2 standard

• Need of an IP service specific convergence sub-layer for H/2

IP network layer

Packet based Convergence LayerPacket based Convergence Layer

Part 1: Common Part Part 1: Common Part

Common Part ConvergenceCommon Part Convergence SublayerSublayer

DLC SAP

Segmentation and Re-assemblySegmentation and Re-assembly

CL SAP

Convergence

Sublayer for IP

Part 1: Common Part

Part 2: SSCS Part

EthernetService Specific

ConvergenceSublayer

IPService Specific

ConvergenceSublayer

1394Service Specific

ConvergenceSublayer

Transfer of IPv4 and IPv6 PacketsTransfer of IPv4 and IPv6 Packets

• Variable IP packet size versus fixed sized DLC PDUs– SAR function (already defined in the H/2 standard)

• Mapping of both connection-less and /-oriented services (IP) to connection-oriented service (H/2)

• Need of additional information attached to each IP packet– Interface Control Information (ICI) with

• hardware destination address• QoS identifier or QoS parameters• packet size …

Header CompressionHeader Compression

• Goal: Efficient use of the scarce radio resources by reducing the header overhead of IP packets

• For VoIP applications the overhead is in the order of several hundred percent

• Existing header compression schemes (e.g. RFC 1144, RFC 2508) do not perform well on HIPERLAN/2

• A new scheme has to be developed which deals with high error rates or long roundtrip times on the wireless link

• An IETF draft from the ROHC (RObust Header Compression) working group describing an IP/UDP/RTP header compression scheme exists

Address ManagementAddress Management

• Goal : to maintain a mapping between the H/2 DLC addresses (MAC-ID) and the addresses sent by the IP-to-wireless interface.– Use of static hardware addresses either IEEE 802 or EUI-

64.– Definition of a table to map hardware addresses and H/2

MAC identifiers (MAC-ID). This avoids to transfer the hardware address with each IP packet and consequently reduces the frame overhead.

– Mapping of IP unicast, multicast, anycast and broadcast addresses to DLC unicast, multicast and broadcast addresses.

Quality of Service on HIPERLAN/2 IP CL Quality of Service on HIPERLAN/2 IP CL

Motivation• Provide transparent QoS for end-to-end connections• Needed for multimedia applications with real-time requirements

Requirements• Resource reservation and control (connection admission control)• QoS type negotiation during association• Re-negotiation owing to changed available resources (e.g.

handover, increased interference, fading, ...)• Mapping of priority scheme of IP layer to priority scheme of DLC

layer• Flow-control and information on QoS violations to IP layer

QoS Management on HIPERLAN/2 IP CL

QoS Management on HIPERLAN/2 IP CL

Functions of the H/2 IP CL

• Agreement of QoS parameters defined on the IP layer and supported by the CL during configuration process

• ICI (interface control information) contains information on QoS parameter of IP packet

• Mapping table is managed in the control plane• By means of the mapping table the packets can be assigned to

the respective queues (user plane) • Queues on the data link control layer (DLC) are accessed by

respective SAP (service access point)• On DLC layer each QoS context is identified by a DLCC-ID

QoS Management on HIPERLAN/2 IP CL

QoS Management on HIPERLAN/2 IP CL

High Priority

Low Priority

1 N-2 N-1 N

Flow control

Classification

ICI generation

Mapping (N -> L)

Scheduling (IP)

IP

CL

High Priority

Low Priority

1 L-1 L

Scheduling(Link Layer)

H/2 DLC

SAR + Buffering

•Packet length•QoS parameter...

Handover Requirements on IP CLHandover Requirements on IP CL• BRAIN considers several handover

types– radio handover

(staying at one access point)• served completely at radio access

(in DLC layer)• IP CL not involved

– horizontal and vertical network handover(moving to a different access point)

• interworking with network (adaptation by IP CL)

• requires means to minimize packet loss during HO execution (queuing, re-routing, re-sequencing, etc.)

– handover type performed should not show significant difference in QoS

A P C

A P T

A P T

.

.

.

C o r eN e t w o r k

A P CA P T

A P T

C o r eN e t w o r k

A P C

R a d i o H a n d o v e r

N e t w o r k H a n d o v e r

A P T : A c c e s s P o i n t T r a n s c e i v e r

A P C : A c c e s s P o i n t C o n t r o l l e r

Network Handover ConceptNetwork Handover Concept• IP CL supports various IP mobility concepts (e.g.,

Mobile IP, Cellular IP)• Functional split in CL control plane

Control Plane User Plane

Common Part

Mobile IPSSP

Cellular IPSSP

– IP CL Common Part (IP CL CP)

• forwarding of MT (CL + DLC) specific data to new AP

• tunneling of packets from old to new AP

– IP CL Service Specific Part (IP CL SSP)

• adaptation to Cellular IP, Mobile IP, or new IP mobility protocols

• AP may serve as MT-representative towards IP network

• and AP as proxy towards MT

Netw. Handover Integration - ExampleNetw. Handover Integration - Example• CL in AP serves as MT-representative• Re-routing of packets from old to new AP

Ba c kb o ne Sig na lling

AP_ ne w_ Ro ute _ Up d a te up d a te d b y C LC e llu la r IP Ro uting

HO _ C o m p le te

M T_ Asso c ia te d _ with_ o ld _ AP

c o nve ying o ld AP-IDre c e iving ne w M AC -ID

IP c o m m unic a tio n re sum e s

AP_ o ld _ Ro ute _ Up d a te

HO _ A sso c ia tio n

M T_ Ab se nc e

HO _ Link_ C a p a b ility

AP_ AP_ NW_ HO

Ha nd o ve r_ C o m p le tio n

M T ------------------ AP ---------------------------------------- Ne two rk

Stand-by mode supportStand-by mode support• 2 terminal states handled at the link layer:

– active: full link layer connectivity, support data connections

– stand-by: monitoring of paging information only

• IP Convergence Layer implementation: – need for introducing a stand-by mode in H2, e.g. relying on

multicast and broadcast user data channel used by the CL– Procedure in the AP:

• periodically broadcast paging area identifier

• when needed, multicast paging request to stand-by MTs

– Procedure in the MT:• switch between active and stand-by modes through association and

disassociation procedures

• monitors paging area id and paging request when in the stand-by mode

ConclusionConclusion

• Basis for IP convergence layer for HIPERLAN/2 defined

• BRAIN IP CL for H/2 aligned with the concepts defined in IP2W

• Further work: to evaluate solutions for– QoS management

– Network handover control

QoS Mapping QoS Mapping

Connection-less QoS• No QoS guarantee (no bandwidth reservation possible)• Defined within IP by Differentiated Services (DiffServ)• DiffServ code points (DSCP) define per hop behavior (PHB)• DSCP is mapped to respective QoS parameter on HIPERLAN/2

– e.g. Ethernet priorities (8 priorities; aligned with Ethernet SSCS)

Connection-oriented QoS• QoS can be guaranteed (as far as possible in wireless systems) • Defined within IP by means of IntServ/RSVP• Bandwidth reservation (including connection admission control)

based on RSVP (FLOWSPEC parameters in Resv message)• Connection end-point identifier (CEP-ID) is established for that

flow between CL and IP layer

QoS Mapping QoS Mapping

Connection-oriented QoS• QoS can be guaranteed (as far as possible in wireless systems) • Defined within IP by means of IntServ/RSVP• Bandwidth reservation (including connection admission control)

based on RSVP (FLOWSPEC parameters in Resv message)• Connection end-point identifier (CEP-ID) is established for that

flow between CL and IP layer