170 likes | 344 Views
IP Convergence Layer for HIPERLAN/2. Servane Bonjour, France Telecom Philippe Bertin, France Telecom Sven Hischke, Deutsche Telekom Arndt Kadelka, Aachen University of Technology Andreas Krämling , Aachen University of Technology Matthias Lott, Siemens AG Mark West, Roke Manor Research.
E N D
IP Convergence Layer for HIPERLAN/2 Servane Bonjour, France Telecom Philippe Bertin, France Telecom Sven Hischke, Deutsche Telekom Arndt Kadelka, Aachen University of Technology Andreas Krämling, Aachen University of Technology Matthias Lott, Siemens AG Mark West, Roke Manor Research Workshop IP in Telekommunikationsnetzen 25./26. Januar 2001, Bremen
Presentation 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/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
Transfer 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 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 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 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 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
1 N-2 N-1 N QoS Management on HIPERLAN/2 IP CL Classification IP • Packet length • QoS parameter • ... Scheduling (IP) Low Priority High Priority ICI generation SAR + Buffering CL Flow control Mapping (N -> L) H/2 DLC 1 L-1 L Scheduling (Link Layer) Low Priority High Priority
Handover 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
Mobile IP SSP Cellular IP SSP Common Part Control Plane User Plane Network Handover Concept • IP CL supports various IP mobility concepts (e.g., Mobile IP, Cellular IP) • Functional split in CL control plane • 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 - Example • CL in AP serves as MT-representative • Re-routing of packets from old to new AP
Stand-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
Conclusion • 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 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 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