21-07-xxxx IEEE MEDIA INDEPENDENT HANDOVER DCN: xxxx Title: Subscription ID Scope Date Submitted: June, 14 th, 2007 Presented at IEEE Adhoc session Korea Authors or Source(s): Srinivas Sreemanthula Abstract: This is the abstract text. Replace this text with a short statement of the contents and purpose of the presentation. Communicate well, you only have a few lines or so to convey the essence of the slides.

21-07-xxxx IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as outlined in Section 6.3 of the IEEE-SA Standards Board Operations Manual and in Understanding Patent Issues During IEEE Standards Development Section 6.3 of the IEEE-SA Standards Board Operations Manualhttp://standards.ieee.org/guides/opman/sect6.html#6.3 IEEE presentation release statements This document has been prepared to assist the IEEE Working Group. 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. 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 The contributor is familiar with IEEE patent policy, as stated in Section 6 of the IEEE-SA Standards Board bylaws and in Understanding Patent Issues During IEEE Standards Development Section 6 of the IEEE-SA Standards Board bylawshttp://standards.ieee.org/guides/bylaws/sect6-7.html#6

21-07-xxxx Subscription ID: Definition Subscription ID is defined to be used with event registrations and event notifications Subscription ID is assigned during remote event registration request and response exchange MIH user originates a remote event registration request primitive and MIHF sends a remote message to the peer MIHF with a subscription ID This ID is then included in every event notification corresponding to the specific event registration

21-07-xxxx Analysis - I Although not clearly stated in the draft, the intention is to create an event registration session/subscription from MIH user level on one node to the peer MIHF entity Implies that two MIH users on a node-A will have two subscription IDs to the peer node-B When node-B initiates an event it includes a MIHF id of node-A and also subscription ID identifying the MIH user MIH user level event management on the node (A) was pushed over the network to node B, which results in multiple event registrations over the network multiple event notifications (which are the same) are going to the node A to specific MIH users Basically, local management issues have now become a management issue on the remote node

21-07-xxxx Analysis – I Figure-1 Node-B Node-A MIHF M-user1M-user2 Event.Reg.Req(event-x, node-B) Event.Reg.Resp(status) Event.Reg.Req(event-x, subs-id1) Event.Reg.Resp(status, subs-id1) Event.Reg.Req(event-x, node-B) Event.Reg.Resp(status) Event.Reg.Req(event-x, subs-id2) Event.Reg.Resp(status, subs-id2) Event.x(subs-id1, node-A) Event.x(subs-id2, node-A) Event.x(node-B) Link originates event.x

21-07-xxxx Analysis – I contd An easier approach is to have one event registration to node B from one or more MIH users on node A Implies, when a second MIH user requests for the event registration that is already established, it results in no action over the network or on node-B When an event notification is received at node-A, it will be distributed to all the registered MIH users within the host (which are managed locally within node-A) It can be argued that subscription ID is not on a MIH-user basis, but then it is not clear if it provides any benefit beyond what is already available in the MIH header This can be verified against the figure in next slide

21-07-xxxx Analysis – I Simplified Figure-2 Node-B Node-A MIHF M-user1M-user2 Event.Reg.Req(event-x, node-B) Event.Reg.Resp(status) Event.Reg.Req(event-x) Event.Reg.Resp(status) Event.Reg.Req(event-x, node-B) Event.Reg.Resp(status) Event.x(node-A) Event.x(node-B) Already in place, do local management Locally generate to all mih users Link originates event.x

21-07-xxxx Analysis - II It was argued that subscription ID is useful for mih-link-configure and mih- link-parameter-reports from two mih users setting different threshold values for a certain parameter figure 1 is still valid reference for this scenario Additionally, the mih-link-configure req/resp is exchanged from each mih-user Node-B manages threshold value configurations on a subscription ID basis This solution is based on assumptions on how and if MAC implementations can handle multiple threshold values for the same parameter E.g. how does a WLAN MAC provide threshold settings for two values for radio signal strength? Assuming it does, MIHF in node-B must still correlate the parameters from link layers to a certain subscription ID This is because, link layers have no knowledge of subscription ID This correlation functionality might as well be done in node-A There is no reason why node-B should do it any more than node-A

21-07-xxxx Conclusion Subscription ID does not provide any additional value for event subscriptions and notifications Introduces an additional parameter in every event notification which has no identification benefit compared to MIH IDs in the header Additional complexity in transport and management of another identifier over the network and on hosts respectively Use of subscription ID for link-parameters-report does not eliminate any complexity of requiring to match specific threshold parameters to a configured setting from a mih user. Pushing the complexity to the other node does not reduce the complexity any more Request WG to reconsider true benefits of Subscription ID and remove all references to it from the draft 5.01