Deliverable D9 - Standardisation Bodies Relationships

Transcription

1 Deliverable D9 - Standardisation Bodies Relationships Author(s): Claire Duranton (Editor) Christian Althaus Magali Crassous Fabio Galliano Thomas Haslestad Frans Panken Partner(s): Telenor ASA Swisscom AG France Telecom SA Lucent Technologies Nederland BV Motorola Electronics SpA Version: l Delivery Month: December 2005 Date: January 06, 2006 Workpackage, Activity: WP6, WP6-A2 Deliverable Type and Number: Report, D9 Distribution Type: Public Document Code: OBAN-WP6-FT-101l-D Internet URL: IST 6FP Contract No Copyright by the OBAN Consortium.

2 Document Revision History Date Version Author/Editor/Contributor Version Description June 01, 2005 a Claire Duranton (FT) Initialization of the document. June 03, 2005 b Magali Crassous (FT) Adding inputs on IETF WG. July 13, 2005 c Magali Crassous (FT) Updates on IETF. September 21, 2005 d Claire Duranton (FT) ToC changes. November 21, 2005 November 23, 2005 e f Frans Panken (LUC) Thomas Haslestad (TNOR) Claire Duranton (FT) Christian Althaus (SCM) IEEE/WiMAX contributions. Update following partners comments. Adding HGI contribution. November 25, 2005 g Claire Duranton (FT) Integrating Chapter 4. Updates on IETF. November 29, 2005 h Fabio Galliano (MOT) Adding UMA aspects. December 01, 2005 i Claire Duranton (FT) Update following WP6 review (11/30). December 07, 2005 j Fabio Galliano (MOT) Correcting some references. December 08, 2005 k Claire Duranton (FT) Adding an Abstract Section. January 04, 2005 l Claire Duranton (FT) Frans Panken (LUC) Thomas Haslestad (TNOR) Update following project review (NPT - ISMB). Table of Contents 1. Introduction Overview of OBAN Related Standardisation Bodies IEEE Activity IEEE IEEE IEEE Rationale Expectations Applicability to OBAN GPP Activity Unlicensed Mobile Access... 8 OBAN-WP6-FT-101l-D OBAN Consortium

3 2.3. IETF Activity Identified OBAN Related Working Groups Objectives description of identified WG Home Gateway Initiative WiMAX Forum Following the Standardisation Bodies Results IEEE Activity IEEE IEEE e IEEE i IEEE n IEEE r IEEE s IEEE u IEEE w IEEE Task Group e (Mobile Wireless MAN) Activities Maintenance Task Group Activities Network Management Task Group Activities Conformance Task Group Activities Licensed-Exempt Task Group GPP Activity Overview of UMA versus UMTS: scope, roadmap and transaction to 3GPP GPP Technical specifications for UMA IETF Activity CAPWAP DNA GEOPRIV MIP MOBOPTS SEAMOBY EMU EAP AAA ECRIT MANET PANA RADEXT AUTOCONF HGI Results related to Standardisation Bodies Activity References Abbreviations Figures Figure 1 - Media Independent Handover (MIH) reference model... 7 Figure 2 - UMA Technology... 8 Figure 3 - UMA Functional Architecture... 9 Figure 4 - UMA for UMTS Figure 5 - UMA - 3GPP transition OBAN-WP6-FT-101l-D OBAN Consortium

4 Figure 6 - GAN Functional Architecture Tables Table 1 IEEE Working Groups and Technical Advisory Group related to OBAN... 3 Table 2 - IEEE Task Groups related to OBAN... 4 Table 3 - IETF Working Groups related to OBAN Table 4 - Initial WiMAX profiles OBAN-WP6-FT-101l-D OBAN Consortium

5 Abstract OBAN partners participate and contribute in a wide range to standardisation activities. The OBAN consortium is therefore well qualified to follow standardisation bodies evolution and to propose inputs to those standardisation bodies. The following document describes the way partners have contributed to standardisation bodies in order to follow the standardisation results and to pave the way to OBAN proposals that could be made by the partners into these standardisation bodies. As a first step, the standardization bodies and working groups most relevant to the OBAN project have been identified. An overview of the standardisation bodies that the partners follow or contribute for the OBAN project is given. The Institute of Electrical and Electronics Engineers (IEEE) standardization bodies is of great interest for OBAN, in particular the following IEEE tasks groups have been followed: e, i, n, r, s, u and w. The OBAN consortium is also willing to follow the standardization activities on alternative radio solutions for offering public broadband access. Therefore, the IEEE group and the Worldwide Interoperability for Microwave Access (WiMAX) Forum have been identified as relevant by the partners. Considering the OBAN will to provide a coupling between WLAN and cellular networks in order to provide a continuous coverage, the IEEE and 3GPP works on this subject are of high interest for the OBAN consortium. In particular, the Unlicensed Mobile Access (UMA) solutions have to be thoroughly followed. Finally, the Internet Engineering Task Force (IETF) groups related to the OBAN activity are presented and the Home Gateway Initiative (HGI) is followed with interest. The OBAN partners that followed the identified standardization bodies activity have reported the standardization evolution since the beginning of OBAN. During the OBAN project, several issues have been identified regarding the mobility, security and Quality of Service (QoS) requirements and some extensions and new features have been proposed. The specific OBAN concept and its related white spots that have been addressed during the project may be submitted to standardization bodies in order to show the evolution need of current standards. With this aim in view, OBAN will present its concept and results for IEEE project during Q The presentation is discussed and agreed upon between the two parties and is going to be presented at IEEE Wireless LAN Next Generation Steering Committee. Several studies made in the architecture and prototyping tasks are related to standardization bodies activity. Many well-known standards have been applied in the OBAN architecture, as well as experimental standards; some extensions to these standards have been proposed. For instance, context transfer results and in particular the CARD protocol has been applied, implemented and evaluated to solve the selection of the best access point and residential gateway. Optimization of a cost function was needed to realize that the information resolved by the CARD protocol is optimally used. Integration with security and QoS solutions requires extensions of the CARD information flow for an overall optimal solution and to realize the fast and secure OBAN handover scenarios. Another example is the work on hierarchical MIPv4 implementation and the interaction between MIP and AAA protocols. The security task proposed two scenarios using new EAP methods that have been worked out in the OBAN architecture activity. Those results are related to the IETF activity. A comparison of the UMA architecture with the stand-alone OBAN architecture has allowed identifying advantages and disadvantages of using UMA to implement OBAN networks. In this context, since some partners are both members of the UMA alliance and of the OBAN consortium, possible contributions to UMA coming from OBAN will be internally evaluated by the partners. These activities will support the dissemination of OBAN results into the UMA context, thus promoting the exploitation of results of research projects towards the standardization bodies. OBAN-WP6-FT-101l-D Page 1 of 1 OBAN Consortium

6 1. Introduction OBAN Partners participate and contribute in a wide range to standardisation activities. OBAN consortium is therefore well qualified to follow standardisation bodies evolution and to propose inputs to standardisation bodies. The following document describes the way partners have contributed to standardisation bodies in order to follow the standardisation results and to pave the way to OBAN proposals that could be made into these standardisation bodies. Firstly, the OBAN related standardisation bodies are identified and introduced. Secondly, the document describes the way OBAN partners are following the standardisation bodies results and evolutions. Thirdly, the document will present some OBAN results that could be presented into such standardisation process. 2. Overview of OBAN Related Standardisation Bodies In a first step, we will present the standardisation bodies and the specific working groups that are closely related to the OBAN project. This paragraph should give an overview of the standardisation bodies that the partners follow or contribute for the OBAN project IEEE Activity IEEE Project 802 (also called LMSC) has developed LAN and MAN standards since the early 80 s. The focus for the standardisation is mainly at the lowest 2 layers of the Reference Model for Open Systems Interconnection (OSI). All standardisation is coordinated with other national and international standards groups, with some standards now published by ISO as international standards. The project regards itself as an international standardisation body though the majority of the meetings and the participants are US based. The body is among other responsible for well-known standards with market success such as Ethernet (CDMA/CD 802.3) and Wireless LAN (802.11). The work in P802 is divided into Working Groups which holds a specific area, such as Wireless LAN and Wireless PAN, and task groups within each working group focusing on developing specific functionality within the area of interest for the working group. IEEE Project 802 is organized in Working Groups (WGs) and Technical Advisory Groups (TAGs), as well as a Sponsor Executive Committee (SEC). The relevance of these groups is indicated in Table 1. Note that the number IEEE is not used, probably to prevent bad omen for the standard. OBAN-WP6-FT-101l-D Page 2 of 2 OBAN Consortium

7 Table 1 IEEE Working Groups and Technical Advisory Group related to OBAN WG Name State OBAN interest IEEE Introduction and high level interface Active WG; Low advisory IEEE Logical link control Hibernating WG Low IEEE CSMA/CD ( Ethernet ) Active WG High IEEE Token Bus Disbanded WG Low IEEE Token Ring Hibernating WG Low IEEE Metropolitan Area Network (MAN) Disbanded WG Low IEEE BroadBand Technical Adv. Group Disbanded WG Low (BBTAG) IEEE Fiber Optics Technical Adv. Group Disbanded WG Low (FOTAG) IEEE Integrated Services LAN (ISLAN) Disbanded WG Low IEEE Interoperable LAN Security (SILS) Disbanded WG Low IEEE Wireless LAN (WLAN) Active WG High IEEE Demand Priority Hibernating WG Low IEEE IEEE Cable-TV Based Broadband Disbanded WG Low Communication Network IEEE Wireless Personal Area Network Active WG Medium (WPAN) IEEE Broadband Wireless Access Active WG High IEEE Resilient Packet Ring (RPR) Active WG IEEE Radio Regulatory Technical Advisory Active WG Medium Group IEEE Coexistence Technical Advisory Active WG Low Group IEEE Mobile Wireless Access Active WG Medium IEEE Media Independent Handover Active WG High The IEEE , and groups are detailed in the following paragraphs. Although the standard (Ethernet- CSMA/CD) is relevant for OBAN for the backhaul, it is not described further in this deliverable, as it considered well known IEEE The following IEEE Task Groups are identified as OBAN related and their interest regarding OBAN objectives is evaluated. The state of these groups is also mentioned. OBAN-WP6-FT-101l-D Page 3 of 3 OBAN Consortium

8 Table 2 - IEEE Task Groups related to OBAN Task Group TG Name TG State or OBAN Interest Planning e QoS enhanced MAC Closed, Published High i MAC Security Closed, Published High Enhancements n Enhancements for Higher WG Drafting High Effective Throughput r Fast BSS transition WG Drafting High s MESH Networking WG Drafting High u Interworking with external Criteria/Proposals High networks w Protected Management frames Criteria/Proposals High Task Group e (802.11e) The scope of this group is to enhance the current Medium Access Control (MAC) to expand support for LAN applications with Quality of Service requirements; and to provide improvements in capabilities and efficiency of the protocol. These enhancements, in combination with recent improvements in physical layer (PHY) capabilities from a and b, will increase overall system performance, and expand the application space for Example applications include transport of voice, audio and video over wireless networks, video conferencing, media stream distribution, enhanced security applications, and mobile and nomadic access application. Chair: John Fakatselis, Intersil Task Group i (802.11i) The scope of this group is to enhance the MAC to enhance security and authentication mechanisms. The enhancements will lead to mechanisms that will secure integrity and improve the confidentiality over the radio interface in addition to providing a layer 2 support of upper layer authentication mechanism. Upper layer Authentication mechanism will provide the support necessary for allowing for example EAP based authentication messages to be transported through the protocol stack. Chair: David Halasz, Cisco Task Group n (802.11n) The scope of this project is to define an amendment that shall define standardized modifications to both the physical layers (PHY) and the Medium Access Control Layer (MAC) so that modes of operation can be enabled that are capable of much higher throughputs, with a maximum throughput of at least 100Mbps, as measured on the top of the MAC layer (MAC SAP). Chair: Bruce Kraemer, Globespan Virata. Task Group r (802.11r) The scope of this project is to define MAC layer enhancements in order to minimize or eliminate the connectivity loss between the Station and the Distribution System during a change of Access Point. Security must not be decreased as a result of the enhancement. The purpose of this project is to improve mobility within ESSs and to support real time constraints imposed by applications such as Voice over Internet Protocol (VoIP). Chair: Clint Chaplin, Symbol Technologies Task Group s (802.11s) The scope of this project is to develop a Mesh network capability for IEEE The IEEE (2003 edition) standard provides a four-address frame format for exchanging data packets between APs for the purpose of creating a Wireless Distribution System (WDS), but does not define how to configure or use a WDS. The purpose of the project is to provide a protocol for auto-configuring paths between APs over selfconfiguring multi-hop topologies in a WDS to support both broadcast/multicast and unicast traffic in a Mesh using the four-address frame format or an extension. Chair: Donald EastLake, Motorola OBAN-WP6-FT-101l-D Page 4 of 4 OBAN Consortium

9 Task group u (802.11u) This project amends the IEEE MAC and PHY to support interworking with external networks. The purpose of this group is to provide amendments to the IEEE PHY/MAC layers which enable interworking with other networks. This includes both enhanced protocol exchanges across the air interface and provision of primitives to support required interactions with higher layers for interworking. Different technologies are considered in the interworking scheme, but the highest priority are on 3GPP/3GPP2 systems as well as and other IEEE technologies. Chair: Stephen McCann, Siemens Roke Manor Research Task group w (802.11w) Enhancements to the IEEE Medium Access Control layer to provide protection of the management frames. The enhancements shall provide, as appropriate, mechanisms that enable data integrity, data origin authenticity, replay protection, and data confidentiality for selected IEEE management frames including but not limited to: action management frames, deauthentication and disassociation frames. Chair: Jesse Walker, Intel IEEE In the standardisation of the IEEE family of standards, the focus in the early stages was on fixed pointto-multipoint high capacity wireless access in the higher frequency bands (10-66 GHz) where huge amounts of spectrum is available, for providing internet connection and integrated data, voice and video services, or as a backbone network. Due to the high frequencies used, these systems require line-of-sight operation. The standard has evolved to also include lower frequency bands, opening for non-line-of-sight (NLOS) communications, and mobility handling has also been an important issue in the standards. The standard consists of a main air interface standard document and a set of addendums to this standard document. The addendums address issues like new functionalities for the air interface, coexistence issues or conformance issues. Sometimes a revision of the standard carried out, and then a new version of the standard is published which replaces the previous air interface standard document and some or all of its amendments. As a result at any time there are several IEEE documents around, some are obsolete, some are active and some are drafts for new addendums or for a revision. Task Group e (Mobile Wireless MAN) IEEE 's Task Group e is developing, under IEEE PAR e, an amendment to IEEE Standard The e amendment covers "Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands". Maintenance Task Group IEEE 's Maintenance Task Group is chartered to maintain IEEE Standard through appropriate maintenance projects. The group is currently developing a single standards project: - PAR /Cor 1 [approved by IEEE-SA Standards Board, 04/09/23] - Corrigendum to IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems Network Management Task Group IEEE 's Network Management Task Group (NetMan) is developing a series of standards as amendments to IEEE Standard The projects include: - PAR f (approved by IEEE-SA Standards Board, 04/08/12): Draft Amendment to IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed Broadband Wireless Access Systems - Management Information Base - PAR g (approved by IEEE-SA Standards Board, 04/08/12): Draft Amendment to IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Management Plane Procedures and Services Conformance Task Group IEEE 's Task Group C (TGC) is developing a series of conformance standards, per ISO/IEC Standard (1995) and ITU-T X.296, in support of the air interface specified in IEEE Standard The standards/projects include: - Part 1 (IEEE Std /Conformance01): Protocol Implementation Conformance Statements (PICS) proforma, GHz OBAN-WP6-FT-101l-D Page 5 of 5 OBAN Consortium

10 - Part 2 (IEEE Std /Conformance02):Test Suite Structure and Test Purposes (TSS&TP), GHz - Part 3 (IEEE Std /Conformance03): Radio Conformance Tests, GHz - Part 4 (PAR /Conformance04): Protocol Implementation Conformance Statements (PICS) proforma, <11 GHz IEEE Rationale Cellular networks and IEEE networks employ handover mechanisms for handover within the same network and mobile IP employs handover mechanisms for handover across different networks of the same type. However, current 802 standards do not support handover between different types of networks. Moreover, existing 802 standards provide mechanisms for detecting and selecting network access points, but do not allow for detection and selection of network access points in a way that is independent of the of the network type. These shortcomings are addressed in the IEEE standard, called Media Independent Handover Interoperability. A first draft was expected in October 2005 and in July a draft version of the standard was presented Expectations The standard will be applicable to 802 media types, both wired and wireless. For example handover between and within a single mobile station (i.e. unplugging your network cable and switching to WLAN) is a plausible application. Unlicensed Mobile Access (UMA) effort, that was initiated by a number of leading operators and vendors in January 2004, is said to provide roaming and handover between cellular, GSM, GPRS, Bluetooth and networks. However providers of the technology and standards do not guarantee interoperability, see Section 2.2 for more details. The standard shall facilitate optimization of Mobile IP handover; however this does not preclude the standard from being used to optimize handovers of other layer 3 protocols. The IEEE standard will provide services both across an 802 link and to upper layers to: - Facilitate the optimization of detection and selection of networks - Provide a source of extensible and semantically defined information to facilitate optimized handover decision making - Provide a mechanism to access this information over an 802 link. - Provide triggers to upper layers The IEEE specification will neither define security algorithms nor security protocols. This does, however, not preclude the propagation of authentication or authorization information to support network detection and selection. The IEEE has five criteria for the development of a new standard. These criteria and how the IEEE standard justifies them are as follows: 1. Broad market potential A key requirement for generalized seamless handover is that handover can occur between administrative domains either within the same technology, or between different technologies. Thus the standard will be applicable to vendors of network services as well as vendors of multiple equipment types. The likely mechanisms through which 802 handover can be achieved are message passing protocols that are implemented within 802 compatible devices. Handover mechanisms common in existing mobile systems, such as and cellular systems indicate that software will be the most common implementation medium for these protocols. 2. Compatibility IEEE 802 defines a family of standards. All standards shall be in conformance with the IEEE Architecture, Management and Interworking documents as follows: 802. Overview and Architecture, 802.1D, 802.1Q and parts of 802.1f and likely IEEE 802.1X. 3. Technical feasibility The technical feasibility can easily be explained by realizing that handover is a common mechanism, OBAN-WP6-FT-101l-D Page 6 of 6 OBAN Consortium

11 present in many systems such as cellular systems or ESSs. Mobile IP, in both v4 and v6 forms, has shown that roaming across heterogeneous systems is possible. 4. Distinct identity Existing 802 standards provide handover within 802 networks. There are no 802 standards to support handover between heterogeneous network types. The need for layer 2 triggers is arising out of fast mobile IP work and cellular networks. 802 has no standards to meet these requirements at layer 2. Finally, existing 802 standards provide diverse mechanisms for detection and selection of network attachment points. There are no standards to enable detection and selection of network attachment point in a media access independent way within Economic feasibility The economic feasibility can be derived by noticing that today cellular systems and systems provide real world examples of handover mechanisms within homogeneous networks at layers 1 and 2 (PHY and MAC), whereas mobile IP provides an example of a successful implementation of a layer 3 handover mechanism across heterogeneous networks. Figure 1 - Media Independent Handover (MIH) reference model Applicability to OBAN When using OBAN as an umbrella for various network technologies, handovers need to take place from WLAN to cellular technologies and therefore the IEEE activity is applicable for OBAN. Existing 802 standards provide diverse mechanisms for detection and selection of network attachment points. There are no standards to enable detection and selection of network attachment point in a media access independent way within 802. In OBAN, the CARD mechanism was selected for this purpose and makes this aspect of the IEEE standard obsolete for OBAN. Since a draft standard is not available yet, it is more likely that OBAN contributes to this particular standard than vice versa. IEEE networks do employ handover mechanisms for handover within the same network, but there are criteria on layer 2 to realize these handovers fast. The standard does not address handover if the handover passes different subnets and the handover needs to be realized fast in order to meet real-time application requirements. Regarding this last aspect, the IEEE standard does not seem to have any time limit that dictates when the handover needs to be realized. OBAN-WP6-FT-101l-D Page 7 of 7 OBAN Consortium

12 2.2. 3GPP Activity The Unlicensed Mobile Access (UMA) effort was initiated by a number of leading operators and vendors in January The goal of this work was to develop and publish an open set of technical specifications for extending mobile voice and data GSM/GPRS services over unlicensed spectrum technologies (including both Bluetooth and Wi-Fi), and subsequently encourage the specifications to be adopted by a formal global standards organization. The UMA consortium then contributed the specifications to the 3GPP organization as part of 3GPP work item "Generic Access to A/Gb interfaces"; on 8 th April 2005, the 3GPP approved such specifications for 3GPP Release 6 0 [7]. Having achieved their two goals, the UMA participating companies agreed to discontinue operating as an independent group and continue their efforts to further develop the technology within the 3GPP organization. The following of this activity is of interest for the OBAN project, since coupling WLAN with cellular networks will allow the OBAN user to move seamlessly with continuous coverage. A presentation of UMA is therefore made in the next paragraph Unlicensed Mobile Access UMA technology provides access to GSM and GPRS mobile services over unlicensed spectrum technologies, including Bluetooth and By deploying UMA technology, service providers can enable subscribers to roam and handover among cellular networks, public and private unlicensed wireless networks using dual-mode mobile handsets. In order to promote the widespread adoption of UMA technology, a number of leading companies within the wireless industry have jointly developed a set of open specifications. The picture in Figure 2 provides an easy description of how the UMA technology works. Figure 2 - UMA Technology 1. A mobile subscriber with a UMA-enabled, dual-mode handset moves within range of an unlicensed wireless network to which the handset is allowed to connect; OBAN-WP6-FT-101l-D Page 8 of 8 OBAN Consortium

13 2. Upon connecting, the handset contacts the UMA Network Controller (UNC) over the broadband IP access network to be authenticated and authorized to access GSM voice and GPRS data services via the unlicensed wireless network. 3. If approved, the subscriber s current location information stored in the core network is updated, and, from that point on, all mobile voice and data traffic is routed to the handset via the Unlicensed Mobile Access Network (UMAN) rather than the cellular radio access network (RAN). 4. ROAMING: When a UMA-enabled subscriber moves outside the range of an unlicensed wireless network to which they are connected, the UNC and handset facilitate roaming back to the licensed outdoor network. This roaming process is completely transparent to the subscriber. 5. HANDOVER: If a subscriber is on an active GSM voice call or GPRS data session when they come within range (or out of range) of an unlicensed wireless network, that voice call or data session can automatically handover between access networks with no discernable service interruption. Handovers are completely transparent to the subscriber. The UMA specifications are available at the UMA Technology web site [5]. Based in these specifications, UMA technology (functional architecture shown in Figure 3) operates to: - Seamlessly deliver mobile voice and data services over unlicensed wireless networks; - Provide the same mobile identity on Cellular RAN and unlicensed wireless networks; - Seamlessly transition (roaming and handover) between Cellular RAN and unlicensed wireless networks; - Preserve investment in existing/future mobile core network infrastructure. Further, it is: - Independent of underlying unlicensed spectrum technology (e.g. Wi-Fi, Bluetooth ) - Transparent to existing, standard CPE devices (e.g. access points, routers and modems) - Using standard always on" broadband IP access networks (e.g. DSL, Cable, T1/E1, Broadband Wireless, FTTH ) - Security equivalent to current GSM mobile networks - With no impact to operations of Cellular RAN (e.g. spectrum engineering, cell planning, ) Figure 3 - UMA Functional Architecture The UMA technology provides alternative access to GSM/GPRS core network services via IP-based broadband connections. In order to deliver a seamless user experience, the specifications define a new network element OBAN-WP6-FT-101l-D Page 9 of 9 OBAN Consortium

14 (the UMA Network Controller, UNC) and associated protocols that provide for the secure transport of GSM/GPRS signalling and user plane traffic over IP. The UNC interfaces into the core network via existing 3GPP specified A/Gb interfaces 0[7] IETF Activity Identified OBAN Related Working Groups The following IETF Working Groups (WG) are identified as OBAN related and their interest regarding OBAN objectives is evaluated. The state of these groups is also mentioned. Table 3 - IETF Working Groups related to OBAN WG Name State OBAN interest CAPWAP Control And Provisioning of Wireless Active WG High Access Points DNA Detecting Network Attachment BoF High GEOPRIV Geographic Location/Privacy Active WG High MIP4 Mobility for IPv4 Active WG High MOBOPTS IP Mobility Optimizations Active RG High SEAMOBY Context Transfer, Handoff Candidate Concluded WG High Discovery, and Dormant Mode Host Alerting EMU EAP Methods Update BoF Medium EAP Extensible Authentication Protocol Active WG Medium ECRIT Emergency Context Resolution with Active WG Medium Internet Technologies AAA Authentication, Authorization and Inactive WG Low Accounting PANA Protocol for carrying Authentication Active WG Low for Network Access RADEXT RADIUS Extensions Active WG Low AUTOCONF Ad hoc Network Autoconfiguration Active WG Low MANET Mobile Ad-hoc Networks Active WG Low MIP6 WG has not been evaluated as interesting for OBAN, since the IPv4 studies have been reprioritised towards IPv6 studies. OBAN-WP6-FT-101l-D Page 10 of 10 OBAN Consortium

15 Objectives description of identified WG CAPWAP objectives (WG) The intent of the CAPWAP (Control And Provisioning of Wireless Access Points) protocol is to facilitate control, management and provisioning of WLAN Termination Points (WTPs) specifying the services, functions and resources relating to WLAN Termination Points in order to allow for interoperable implementations of WTPs and Access Controllers. DNA objectives (WG) [9] For the purposes of DNA (detecting network attachment), a Layer 3 link is defined as the topological range within which IP packets may be sent without resorting to forwarding. In other words, a link is the range where a given IP configuration is valid. The current IPv6 stateless and stateful autoconfiguration procedures may take a fairly long time due to delays associated with Router Discovery and Duplicate Address Detection. Furthermore, in some wireless technologies, the link layer state and events may not give an accurate indication of whether or not the IP addressing configuration and routability have changed. Therefore detecting network attachment requires not only change detection but IP layer connectivity testing. The purpose of the DNA working group is to define standards track and BCP (Binary Communication Protocol) documents that allow hosts to detect their IP layer configuration and connectivity status quickly, proposing some optimization to the current specifications that would allow a host to reconfigure its IPv6 layer faster than today. GEOPRIV objectives (WG) [10] As more and more resources become available on the Internet, some applications need to acquire geographic location information about certain resources or entities. These applications include navigation, emergency services, management of equipment in the field, and other location-based services. The primary task of the GEOPRIV (Geographic Location/Privacy) WG is to assess the authorization, integrity and privacy requirements that must be met in order to transfer such information, or authorize the release or representation of such information through an agent. In addition, the working group will select an already standardized format to recommend for use in representing location. The combination of these elements should provide a service capable of transferring geographic location information in a private and secure fashion MIP4 objectives (WG) IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. MOBOPTS objectives (RG) [11] The dramatic increase in wireless and mobile devices coupled with the desire to connect them to the evergrowing Internet is leading to a Mobile Internet. While basic protocol support and some enhancements are being standardized IETF, there is a need for significant research (both empirical and analytical) to better understand mobility on the Internet. The objective of the MOBOPTS (IP Mobility Optimizations) WG is two-fold. Establish a forum for Wireless and IP Mobility researchers to investigate key and interesting problems in the field. The findings on these problems should benefit the community at large, but especially the standardization bodies like the IETF and the IEEE. And, help establish a uniform platform or testbed that researchers could use for experimentation as common tools, scenarios and methodologies provide more accurate performance benchmarking. A more ambitious, longer-term goal is to become a catalyst for research in Mobile Inter-networking. OBAN-WP6-FT-101l-D Page 11 of 11 OBAN Consortium

16 SEAMOBY objectives (concluded WG) [12] A need for a protocol has been identified to allow state information to be transferred between edge mobility devices. Examples of state information that could be useful to transfer is AAA information, security context, QoS properties assigned to the user, Robust Header Compression information, etc. Furthermore, the protocols developed by the SEAMOBY WG must allow for real-time services to work with minimal disruption across heterogeneous wireless, and wired, technologies. In addition to Context Transfer, the working group has identified two more technologies that are important for use as tools for providing real-time services over IP wireless infrastructure: Handoff Candidate Discovery and Dormant Mode Host Alerting. Another technology, micro-mobility, in which routing occurs without the Mobile IP address change, has been removed from the WG by rechartering and the topic has been addressed to the IRTF Routing Research Group. EMU objectives (BoF) The Extensible Authentication Protocol (EAP), defined in RFC 3748 is a network access authentication framework used in the PPP, , , VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in so called EAP methods. Over 40 different EAP methods exist. This includes many undocumented and proprietary methods. Only a few methods are documented in RFCs, and out of these, methods listed in the original EAP RFC are no longer applicable in today's environments. For instance, none of the EAP methods that are applicable in a wireless environment are in Standards Track RFCs. Some methods have been defined in Internet Drafts, many of which have expired or have not been updated to reflect the true behaviour in the protocols. The lack of documented, open specifications is a deployment and interoperability problem. In addition, new requirements such as those posed by wireless environments are creating needs that are currently not well matched by existing methods. Finally, there are authentication mechanism types that are not supported by existing RFCs. For instance, there is no widely applicable method that would be able to authenticate using shared secrets in a wireless environment. The purpose of this BoF is to continue the work started in the EAP WG and in the SECMECH BoF, in a manner focused on few key EAP method needs. One immediate goal is to bring existing widely deployed EAP methods such as EAP-TLS (RFC 2716) to Proposed Standards with clarifications learned during deployment. Another goal is to standardize additional mechanism to match the current requirements. EAP objectives (WG) [13] The EAP working group will restrict itself to the following work items, in order to fully document and improve the interoperability of the existing EAP protocol: 1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. Documentation of interaction between EAP and other layers. 6. Resolution of interoperability issues. 7. EAP state machine. 8. EAP keying framework. 9. EAP network selection problem definition Items 1-6 were included within RFC Items 7-9 will be handled as separate documents. While the EAP WG is not currently chartered to standardize EAP methods, with the publication of RFC 3748, the EAP WG will assume responsibility for review of EAP methods requesting a Type code allocation, as specified in the IANA considerations section of RFC When the current work items are completed, the WG may be rechartered, or a new WG may be formed to standardize methods. ECRIT objectives (WG) The focus of this working group is to consider emergency services calls which might be made by any user of the Internet. The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response centre. Though the term "call routing" is used in this text, it should be understood that some of the mechanisms which will be described might be used to enable other types of media streams. Video and text messaging, for example, might be used to request emergency services. Explicitly outside the scope of this group is the question of pre-emption or prioritization of emergency services traffic. OBAN-WP6-FT-101l-D Page 12 of 12 OBAN Consortium

17 AAA objectives (WG) The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA The AAA WG then solicited submission of protocols meeting the requirements, and evaluated the submissions. This incarnation of the AAA Working Group focus on development of an IETF Standards track protocol, based on the Diameter submission. This WG met for the last time in IETF 60th, July Since, Working Group document are becoming RFC. RFC number 4005 has been allocated for the NASREQ application document, and the RFC number 4004 should be allocated for the Mobile IPv4 application document. PANA objectives (WG) The goal of PANA is to define a protocol that allows clients to authenticate themselves to the access network using IP protocols. Such a protocol would allow a client to interact with a site's back-end AAA infrastructure to gain access without needing to understand the particular AAA infrastructure protocols that are in use at the site. It would also allow such interactions to take place without a link-layer specific mechanism. PANA would be applicable to both multi-access and point-to-point links. It would provide support for various authentication methods, dynamic service provider selection, and roaming clients. The WG works with the assumption that a PANA client (PaC) is already configured with an IP address before using PANA. This IP address will provide limited reachability to the PaC until it is authenticated with the PANA Authentication Agent (PAA). Upon successful authentication, PaC is granted broader network access possibly by either a new IP address assignment, or by enforcement points changing filtering rules for the same IP address. It is believed that PANA will be able to meet its goals if it is able to carry EAP payloads. Note, however, that EAP may need to be extended in order for PANA to meet the need for all of its intended usages. Such extensions are outside the scope of the PANA WG. PANA will develop an IP-based protocol that allows a device to authenticate itself with the network (and to a PAA in particular) in order to be granted network access. For simplicity, it is assumed that the PAA is attached to the same link as the device (i.e., no intermediary IP routers). The PAA itself may interface with other AAA backend infrastructures for authenticating and authorizing the service being requested by the host, but such interactions are transparent to the PaC. The PAA does not necessarily act as an enforcement point (EP) to prevent unauthorized access or usage of the network. When a PaC successfully authenticates itself to the PAA, EP(s) (e.g., access routers) will need to be suitably notified. This WG will identify a (preferably existing) protocol solution that allows the PAA to deliver the authorization information to one or more EPs when the PAA is separated from EPs. A single PAA may serve many access routers. The WG will also propose a solution of how the PaC discovers the IP address of PAA for sending the authentication request. RADEXT objectives The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to enable its use in applications such as IP telephony and Local Area Network authentication, authorization and accounting. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All RADIUS work must be backward compatible with existing RADIUS RFCs, including RFCs , , 3162, 3575, 3576, 3579, and All RADIUS work must be compatible with equivalent facilities in Diameter. When possible, new attributes should be defined so that the same attribute can be used in both RADIUS and Diameter without translation. In other cases a translation considerations section should be included in the specification. - No new RADIUS transports (e.g. TCP, SCTP) will be defined. - No new security mechanisms will be defined for protecting RADIUS. - No new commands will be defined. AUTOCONF objectives The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing OBAN-WP6-FT-101l-D Page 13 of 13 OBAN Consortium

18 protocols as developed by the IETF MANET WG. An AUTOCONF mechanism should not be dependent on any specific MANET routing protocol, however the routing protocol may provide for optimizations. With this in mind, the goals of AUTOCONF WG are to: - Produce a "MANET architecture" document defining the MANET architecture as is related to IP networks and the Internet. - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 address autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. MANET objectives The purpose of the MANET (Mobile Ad-hoc Networks) working group is to standardize IP routing protocol functionality suitable for wireless routing application within both static and dynamic topologies with increased dynamics due to node motion and other factors. Approaches are intended to be relatively lightweight in nature, suitable for multiple hardware and wireless environments, and address scenarios where MANETs are deployed at the edges of an IP infrastructure. Hybrid mesh infrastructures should also be supported by MANET specifications and management features. Using mature components from previous work on experimental reactive and proactive protocols, the WG will develop two Standards track routing protocol specifications: - Reactive MANET Protocol (RMP) - Proactive MANET Protocol (PMP) If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach. Both IPv4 and IPv6 will be supported. Routing security requirements and issues will also be addressed. The MANET WG will also develop a scoped forwarding protocol that can efficiently flood data packets to all participating MANET nodes. The primary purpose of this mechanism is a simplified best effort multicast forwarding function. The use of this protocol is intended to be applied only within MANET routing areas and the WG effort will be limited to routing layer design issues. The MANET WG will pay attention to the OSPF-MANET protocol work within the OSPF WG and IRTF work that is addressing research topics related to MANET environments Home Gateway Initiative The Home Gateway Initiative (HGI) is an open forum launched by Telcos in December 2004 with the aim to release specifications of the home gateway. It is a non profit organization that represents the interests of different Telcos (Belgacom, BT, Deutsche Telecom, France Telecom, KPN, NTT, Telecom Italia, Telefonica, TeliaSonera and Swisscom). Many device manufacturers joined the initiative to represent their interests as well. The main goals of the initiative are the following: - synchronization with other organizations such as ITU H610, DSL Forum, DLNA, OSGi Alliance, etc., to analyze the different activities and to try to fill existing gaps; - identifying and prioritizing use cases that may influence the home gateway functionality and architecture. The use cases shall be validated by the Telcos and also by the vendors. - Producing requirements and guidelines for the implementation of the future home gateway enabling end-to-end delivery of services. These requirements shall be standardized by other organizations as DSL Forum, ETSI or ITU-T, later. The resulting list of requirements align future RFQs from the Telcos and this makes it easier for the home gateway manufacturers to create cheaper HGI certified mass products that are satisfying the needs of a large number of service providers. The Home Gateway Initiative is organized different Working Groups: - The Architectural Task Force is a Telcos only group with the goal of defining an end-to-end reference architecture to create the main high-level requirements for the gateway. OBAN-WP6-FT-101l-D Page 14 of 14 OBAN Consortium

19 - The Business Working Group identifies, describes and prioritizes the most interesting use-cases that are going to be considered by the technical working Groups. - Technical Working Groups - The Home Gateway Architecture and Security Working Group defines the main architecture of the gateway and creates the related requirements for the home gateway - The Remote Operations and Device Management Working Group looks into the requirements needed for a standardized remote management solution for the home gateway and devices in the home network. - The End-to-End Architecture and Quality of Service Working Group is defining the QoS architecture in the home network for future services - The Home Networking Architecture and Technology Working Group analyzes the needed network interfaces, bit rate requirements and technologies for in-house distribution WiMAX Forum Worldwide Interoperability for Microwave Access (WiMAX) Forum is a non-profit organisation created to promote deployment of broadband wireless access networks by using a global standard and certifying interoperability of products and technologies. The group is seeking to accelerate the introduction of wireless broadband equipment into the marketplace, speeding up wireless broadband deployment worldwide. There are claims however unproven that the WiMAX collaboration on mass market products will result in similar economics of scale as those seen for Wi-Fi WLAN products. Then benefits of certification are several: - For a network operator, it means interoperability between equipment manufacturers and conformance to the standard (including minimum performance) - For equipment manufacturers, it means less product options and a larger market - For component manufacturers, it means large volume production of chips - For the end user, it means more affordable and available equipment - WiMAX Forum certified mobile WiMAX products are expected during Q4/06, and portable/mobile commercial networks are expected deployed from Q3/07, according to the WiMAX forum roadmaps. Certification A WiMAX Forum certification implies interoperability of equipment to other vendors base stations and subscriber stations, and conformance to the WiMAX defined PICS (Protocol Implementation Conformance Statement) and TSS&TP (Test Suite Structure & Test Purposes). The PICS and TSS&TP are based on the IEEE and ETSI HiperMAN standards. It should be realized that conformance does not imply interoperability, and interoperability does not imply conformance. Hence both these aspects must be verified in the certification process. A WiMAX certification does not guarantee interoperability, but makes it very probable. Interoperability testing must be completed with a minimum of three different vendor s equipment. Ideally a full mesh of interoperability tests should be performed to validate that all vendors base stations work with all vendors subscriber stations. But this is not possible to do in practice. Instead the certification lab will randomly select units to perform the interoperability testing. This will be done such that no single solution becomes de facto for the test bed by rotating vendor hardware in the test bed. The conformance requirements include both functionality requirements and performance requirements. Also, the conformance requirements include both mandatory PICS and prohibited PICS. Certified equipment will be identified by manufacturer, model number, hardware revision and software version. Re-certification will be required if vendors change the equipment configuration (components) or identification (model, hardware or software versions) and want the updated equipment noted on the WiMAX Forum Certified Equipment list. For modules such as PCMCIA cards, USB adapters, it is expected that also the host operating system version will be included as part of the certified equipment identification (e.g. Windows 2000 build 1394). Later, the PICS might be modified and new PICS (mandatory, optional and prohibited) will be added. As a member of the WiMAX Forum, Telenor can influence this work. OBAN-WP6-FT-101l-D Page 15 of 15 OBAN Consortium

20 Profiles for fixed, nomadic, portable, simple mobile and full mobile use The IEEE standard has many options, and one of the most important tasks for the WiMAX Forum is to decide on which of these should be mandatory to implement in a system to ensure interoperability. Since there are many different applications of WiMAX systems having different requirements, it is necessary to define several sets of requirements. These sets of chosen options and requirements are called profiles. A profile is the lowest common denominator of interoperability for equipment. Five profiles have currently been defined: Table 4 - Initial WiMAX profiles Profile name Profile details Frequency band Duplexing method Channel bandwidth 5.8T 5.8 GHz TDD 10 MHz 3.5T1 3.5 GHz TDD 7 MHz 3.5T2 3.5 GHz TDD 3.5 MHz 3.5F1 3.5 GHz FDD 3.5 MHz 3.5F2 3.5 GHz FDD 7 MHz Note: 3.5 GHz frequency band is for licensed operation and 5.8 GHz frequency band is for licence exempt operation. WiMAX has started the process of deciding profiles for mobile WiMAX. These will be based on the IEEE standard and the IEEE e addendum. The work is going on in several of the WiMAX working groups. The work is in an early stage and no decisions have yet been made. It is expected that the first mobile profiles defined will be based on TDD, and probably be for the 2,3 and 2,5 GHz frequency bands. 3. Following the Standardisation Bodies Results This paragraph presents the evolution of standardization as stated by OBAN partners IEEE Activity IEEE This section integrates executive summary of each TG of the IEEE#93 session or summarizes the results obtained since 2004 in no more active WG IEEE e The work within TGe is finalized and published. The standard may be found available on the IEEE website. Wi-Fi Alliance have earlier taken e draft and made the WMM trademark approval for a limited set of QoS support. There exists no known plan for an extended WMM incorporating the entire e standard into the trademark from Wi-Fi Alliance IEEE i The work within TGi is finalized and published. The standard may be found available on the IEEE website. Wi-Fi Alliance have already taken both i draft 3.0 and the final approved i version and produced trademark approvals named WPA and WPA/2. Wi-Fi Protected Access (WPA) is now a commodity for Wi-Fi Alliance certified equipments IEEE n At the March meeting TGn Synch was the last proposal standing after the down selection procedure (e.g. a voting procedure for eliminating the pool of proposals). Unfortunately the proposal did not come through the confirmation vote, neither the first nor the second round. This opened up for all of the previous five proposals. OBAN-WP6-FT-101l-D Page 16 of 16 OBAN Consortium