IEEE MEDIA INDEPENDENT HANDOVER DCN: Title: Initial feedback by FMCA on IEEE questions Date Submitted: May, 12th, 2006 Presented at IEEE session #14 in Jacksonville, USA Authors or Source(s): Rob Glassford (BT), Rodrigo Donazzolo (FMCA) Abstract: Initial feedback from FMCA on IEEE questions and a liaison update.

Discussion Items FMCA – IEEE Engagement Initial Feedback on IEEE questions for FMCA Initial Feedback on IEEE comments on PRD Matrix Converged Applications & Device Management Requirements

Engagement History to date March IEEE Meeting: FMCA shared a Wi-Fi SIP PRD Release 1.0 Matrix showing key product requirements that the FMCA would welcome IEEE feedback on. End April: IEEE provided feedback on FMCA PRD Matrix IEEE provided a list of MIH questions for the FMCA IEEE indicated their interest in future FMCA PRDs referencing appropriate IEEE capabilities.

Proposed Future Engagement FMCA to provide feedback to IEEE questions in time for IEEE September Meeting. FMCA to review IEEE PRD comments as part of FMCA PRD Release 3.0 development discussions. FMCA to invite IEEE to present at FMCA Technical Review Session – 19 th – 23 rd June, Hong Kong.

Proposed Time Line March 06 FMCA highlights Wi-Fi SIP PRD R1.0 Handover Requirements to IEEE for comment End of April IEEE provide PRD R1.0 feedback and a list of handover questions requiring FMCA comment. 15 th – 19 th May FMCA Initial Feedback at IEEE Plenary 19 th – 23rd June IEEE Presentation at FMCA Technical Review Session 15 th – 22 nd July IEEE Plenary September FMCA Feedback at IEEE Plenary FMCA Members review and respond to IEEE Feedback & Questions

Feedback on IEEE questions FMCA have noted the IEEE questions and review requests, relating to the following capabilities: Event Service Information Elements Definition of Voice Quality Parameters UE Display of Available Wireless Networks Roaming Interference & Co-existence Link Layer Triggers FMCA will provide feedback on these at the September IEEE meeting. However we have some initial comments and points for clarification

Initial comments Information Elements (1) IEEE question: Are there any other Information Elements the FMCA would like to see in the standard? FMCA initial comment: FMCA will provide feedback on this in time for IEEE September meeting. However in the interim, we support in principle the additional IEs mentioned in the joint BT/Intel Handover Use Cases and Additional IEs ( Handover_Use_Cases_More_IEs.ppt) presentation made in Januaryhttp:// Handover_Use_Cases_More_IEs.ppt E.g. Cost of basic services, Pre-Authentication & CAC, Emergency Service Support, Class of User Supported, Latency, Jitter, Encryption Support, Power consumption, Coverage, Mobility speed supported, Hand-over times, etc What parameters will exist for cost IE? Do different cost parameters need to be considered, e.g. messaging, data, voice, etc and not just minute based parameters?

Initial comments Information Elements (2) IEEE question: Are the Information Elements in the right format? FMCA initial comment: What naming convention will be used to ensure consistency? IEEE question: In the view of FMCA operators, how and where in the network should the Information Server be deployed in the following scenarios? –a) Multiple Networks managed by single operator –b) Multiple Networks co-managed by multiple operators, etc. FMCA initial comment: Multiple Networks managed by single operator and multiple networks co-managed by multiple operators should be treated the same, through the use of standard interfaces.

Initial comments Information Elements (3) FMCA Follow-up Question: How does IEEE envisage Information Elements fitting into a 3GPP IMS compliant network architecture? What is the current status of the 3GPP liaison? Has IEEE considered discussions with ETSI TISPAN regarding the use of Information Elements and Network Intelligence for Handover decisions? How does IEEE envisage operators building and maintaining databases of “neighbouring networks” ? There seems to be a requirement for the geographical location of each AP to be known. Will MIH be able to function without this information being available?

UE display of available wireless networks IEEE question: IEEE would like FMCA feedback on what are the key parameters which a UE should display when showing the list of available networks? In addition what are the key parameters the UE should display to help the end-user make optimum network selection decisions? FMCA initial comments: The FMCA will provide feedback on this subject at the September IEEE meetings. Perhaps this question needs to be expanded to consider how different applications could also use these key parameters?

Roaming IEEE questions: How are the roaming agreements specified between different operators? Do the roaming agreements specified as part of IS in section 8.3 of current IEEE draft capture this appropriately? Information Elements (as specified in Section 6.3) can provide details on Roaming Agreements, how does this align with FMCA Roaming requirements? FMCA initial comment: FMCA is intending to cover roaming and inter-operability aspects in subsequent PRDs and white papers. IEEE will have the opportunity to review these requirements.

Interference & Co-existence IEEE questions: When connecting to multiple networks concurrently the UE may have to deal with interference and co-existence type issues across different wireless networks. Since during handovers across heterogeneous technologies, multiple links have to be in operation anyway, should IEEE try to define a preferred sequence of steps to conduct handover and thereby mitigate interference and co-existence type issues to a certain extent? FMCA initial comment: What is meant by concurrent connections, e.g. how long before and after a handover would concurrent connections exist for? Have IEEE considered security (multiple network authentications, denial of service attacks) and battery life/power saving aspects?

Initial Feedback on IEEE comments on PRD Matrix FMCA will review IEEE comments on the PRD Matrix as part of PRD Release 3.0 development discussions. FMCA will look to reference IEEE capabilities, where appropriate, in PRD Release 3.0. See embedded spreadsheet for initial FMCA feedback on IEEE IEEE are encouraged to review FMCA Wi-Fi SIP and Wi-Fi GAN PRD Release 2.0 documents, which are now available off the FMCA website –

Converged Application Requirements for IEEE In a heterogenous network environment applications will need to know about the availability and characteristics of network connections Certain application functions only make sense either from a cost or usability perspective if they use an appropriate network. i.e. match application bandwidth/latency/cost requirements against those provided by current networks. Applications will want to dynamically alter their behaviour and UI based on what the current network can support e.g. a comms client may alter presence info to indicate video messaging is available when in Wi-Fi. Applications may only be launched or become active when certain network conditions are available.

Scenario 1: Network Aware OTA Device Management Scenario: Device Management client performs various functions including low bandwidth aspects like settings updates through to large application downloads and even OTA firmware upgrades. Device Management needs to know about imminent loss of network or change in QoS in order to perform a graceful stop or warn the user. Certain DM functions may take a significant period of time and hence networks may disappear during function. DM client may want to postpone completion of DM functions until appropriate network reappears. Moves into home network, application downloads restart. Connection likely to be available for a prolonged period, offers OTA firmware upgrade to user. User warned if network performance drops so they can take action. User moves into Wi-Fi public hotspot, DM system realises good opportunity to initiate application downloads and starts download. Handover or Wi-Fi network is lost mid download, DM suspends app provisioning User has Cellular coverage only, basic settings are managed, e.g. APN updates Cellular Public Wi-Fi Home Wi-Fi

Scenario 2: Network Aware Data Synchronisation Client Scenario: – Data sync client manages exchange of local device data with a network store. Device data includes essential data such as calendar, contacts that need regular synchronisation and less important data that relies on more intermittent connections e.g. picture gallery, attachments. Client adapts its behaviour according to the available networks to deliver the best cost/performance balance. Default client behaviour may be modified or overridden according to user preferences, e.g. urgent data may be sync’d even if connection is expensive and slow. Moves into home network, no backhaul congestion. Starts full synchronisation including bandwidth hungry picture and multimedia gallery, attachments etc. User moves into Wi-Fi public hotspot, up-link congested. Client initiates attachment download but maintains suspension of outbox and picture gallery upload. User has cellular coverage only, only important, time critical data sync’d e.g. Calendar, contact, inbox. attachments, outbox and picture gallery suspended Cellular Public Wi-Fi Home Wi-Fi

Handover Implications for Device Management FMCA would welcome IEEE feedback on the handover implications for automatically initiated device management and over the air updates. Implications associated with running simultaneous background applications and foreground applications as the UE handsover between different access networks.