1. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 1 TGu Agenda Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-01-18 Authors:

2. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 2 Abstract Agenda for TGu Interworking with External Networks for January 2005, Monterey, California.

3. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 3 Tuesday 18 January 2005, 16:00 – 21:30 Call to Order –On-line Attendance reminder Review IEEE 802 and 802.11 Policies and Procedures –Intellectual Property

4. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 4 6. Patents IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. This assurance shall be provided without coercion and prior to approval of the standard (or reaffirmation when a patent becomes known after initial approval of the standard). This assurance shall be a letter that is in the form of either a) A general disclaimer to the effect that the patentee will not enforce any of its present or future patent(s) whose use would be required to implement the proposed IEEE standard against any person or entity using the patent(s) to comply with the standard or b) A statement that a license will be made available without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination This assurance shall apply, at a minimum, from the date of the standard's approval to the date of the standard's withdrawal and is irrevocable during that period. IEEE-SA Standards Board Bylaws on Patents in Standards Approved by IEEE-SA Standards Board – December 2002

5. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 5 At the December 2004 meeting of the IEEE-SA Standards Board Patent Committee (PatCom), Paul Nikolich (Chair, 802) on behalf of Stuart Kerry (Chair, 802.11)led discussion on an agenda item titled 'Discussion of P802.11n Protest'. You noted that some members of the P802.11n working group requested a clarification of policy from PatCom regarding what would be acceptable to discuss during a working group technical presentation, regarding patent information/statements. PatCom is charged with providing oversight for the use of patents and patent information in IEEE Standards. PatCom is also charged with reviewing patent information submitted to the IEEE Standards Department to determine conformity with patent procedures and guidelines. As empowered by the IEEE-SA Standards Board Bylaws, PatCom has reviewed the information presented and rendered its decision by interpreting the policies and procedures of the IEEE and the IEEE-SA relevant to the issues. In regards to the presentation of information to a standards development group, PatCom has decided the following: 1. After a patent letter of assurance (LoA) has been accepted by PatCom, it is allowable for a presenter to state that an LoA has been filed by a Patent Holder, accepted by PatCom, and listed in the online listing of LoAs at http://standards.ieee.org/db/patents/index.html Anyone seeking a copy of the accepted LoA should contact the PatCom Administrator. 2. Discussion of the content of accepted, submitted, or proposed LoAs is prohibited. 3. Discussion of licensing terms and conditions is prohibited. Patent Committee Ruling – January 6, 2005

6. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 6 Inappropriate Topics for IEEE TG Meetings Don’t discuss licensing terms or conditions Don’t discuss product pricing, territorial restrictions or market share Don’t discuss ongoing litigation or threatened litigation Don’t be silent if inappropriate topics are discussed… do formally object. If you have questions, contact the IEEE Patent Committee Administrator at patcom@ieee.org Approved by IEEE-SA Standards Board – December 2002

7. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 7 Meeting Etiquette "Individuals are to address the comments of others only, not the person"

8. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 8 Tuesday (cont.) 18 January 2005, 16:00 – 21:30 Minutes –Approval of Minutes of November 2004 WIEN SG - 11-04-1523-01- wien-minutes-Nov-2004-session.doc Approve Agenda Secretary Election Temporary Editor nominations –Draft scenarios doc for joint IEEE 802.21 –Draft requirements doc for joint IEEE 802.21 Overview of last WIEN SG meeting –11-04-1514-00-wien-closing-report.ppt Liaison Issues –Incoming –Outgoing

9. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 9 Tuesday (cont.) 18 January 2005, 16:00 – 21:30 Liaison Officer Volunteers TGu Process –11-05-1584-01-wien-process.ppt Recess from 6:00pm until 7:30pm Presentations: –Scenarios and Requirements (E. Hepworth) –Interworking Assumptions (Hong Cheng) –Terminology (E. Hepworth) WIEN SG Open Issues review Teleconferences requirement

10. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 10 Thursday 20 January 2005, 08:00 – 10:00 Requirements and Terminology Drafting –11-05-1583-00-wien-draft-functional-requirements-and- scope.doc –11-05-1619-00-wien-TGu-terms-and-definitions.doc Review old WIEN SG documents, as mentioned in the PAR Scenario generation and preparation for IEEE 802.21 joint session

11. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 11 Thursday 20 January 2005, 10:30 – 12:30 IEEE 802.21 Joint Session –Brief summary of IEEE 802.11u scope –IEEE 802.11u requirements gathering phase –IEEE 802.21 requirements which impact IEEE 802.11u –Required feedback from IEEE 802.11u to IEEE 802.21 –Formal liaison relationships

12. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 12 TGu Secretary Election Tuesday 18 January 2005, 16:00 – 18:00 Nominations

13. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 13 WNG/WIEN Interworking Documents Technical Submissions to WNG SC Justified creation of WIEN SG Requirements from external groups –3GPP/2 –WiFi Alliance –Operators –xDSL –802.21 Reassessment within.11u

14. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 14 WNG/WIEN SG Documents 11-03-0687-02-0wng-wfa-public-access-overview.ppt 11-03-0695-00-0wng-Interworking-Policy.ppt 11-03-0727-02-0wng-Interworking-AdmissionControl.ppt 11-03-0827-00-0wng-co-existence-of-different-authentication-.ppt 11-03-0828-03-0wng-hotspot-evolution.ppt 11-03-0993-00-0wng-interworking-sg-justification.doc 11-04-0222-00-0wng-3gpp-requirements-wlan-selection.ppt 11-04-0407-00-0wng-backend-interworking-security.ppt 11-04-0408-02-0wng-3gpp-wlan-interworking-security.ppt 11-04-0617-00-wien-wlan-interworking-scenarios.ppt 11-04-0626-00-wien-3gpp-wlan-interworking-issues.ppt 11-04-0638-02-wien-network-selection.ppt 11-04-0690-00-wien-3gpp-sa3-interworking-security-issues.ppt 11-04-0691-00-wien-considerations-about-network-selection.ppt 11-04-0708-00-wien-network-side-issues-in-wlan-interworking.ppt 11-04-0711-00-wien-domain-identification-predictive-handover-among-different-domains.ppt 11-04-0733-01-wien-3gpp-wlan-interworking-requirements.ppt 11-04-0751-00-wien-selling-network-access.ppt 11-04-0780-00-wien-anonymous-mac-addresses.ppt 11-04-0835-00-wien-arid-use-case.ppt

15. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 15 3GPP Requirements According to TS22.234 (SA1), TS 23.234 (SA2), TS33.234 (SA3), TS24.234 (CN1): –WLAN needs to support (U)SIM based Access Control –WLAN needs to support Network sharing/Discovery –WLAN needs to support Policy Control/Enforcement –WLAN needs to support QoS for 3G services –WLAN needs to support online/offline Charging

16. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 16 3GPP2 Requirements Summary of 3GPP2 interworking document –Not completed

17. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 17 PAR Open Issues I Network Detection and Selection –This provides additional information to STAs about the characteristics of the network to support network selection decisions. –As part of this, IEEE 802.11u will investigate aspects related to beacon scaleability. Secure Portal Page/IEEE 802.11i co-existence –The majority of current hotspots use portal pages to support authentication and a solution is needed for allowing the full IEEE 802.11i to operate in parallel. –Issues include support for new user sign up in IEEE 802.11i enabled networks –TGr co-existance –ADS SG MAC address anonymity –This provides protection for the terminal identity

18. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 18 PAR Open Issues II Policy enforcement –Issue concern how policy rules from the network are enforced within the IEEE 802.11 access point –Specific requirements placed on IEEE 802.11 by external network operators, where traffic enforcement policies are applied to user traffic. This particularly applies to the scenario where multiple operators share the IEEE 802.11 hotspot infrastructure. External QoS mapping –Issues concerning specific external network requirements mapping to IEEE 802.11 –Issues concerning the co-ordination of admission control between the air interface and external networks

19. doc.: IEEE 802.11-05/1617r1 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 19 PAR Open Issues III Charging –Specifically charging information, generated within the Access Point, is required to be communicate to the external network –IEEE 802.11u will define a mechanism to collect such information Access Router identifier –This is either within the beacon or is an information element within an IEEE 802.11k neighbor information element. –It provides an indication as to whether handover is at layer 2 or layer 3.