1 / 12

Design Principles for Entity Responsibilities

Design Principles for Entity Responsibilities. Authors:. Date: 2012-07-03.

oakley
Download Presentation

Design Principles for Entity Responsibilities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Design Principles for Entity Responsibilities Authors: Date:2012-07-03 Notice:This document has been prepared to assist IEEE 802.19. 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. Mika Kasslin, Nokia

  2. Abstract This presentation continues discussion on entity responsibilities and corresponding implications to procedures which were discussed in 19-12/0057r1. Further material has been added into the r1 of the presentation on differences between a request based approach and an indication based approach when applied between a CE and a CM. Mika Kasslin, Nokia

  3. Design Assumptions • The IEEE 802.19.1 system comprises of coexistence enablers (CEs), coexistence managers (CMs) and coexistence discovery and information servers (CDISs) • Each piece of information has a source which is a coexistence system entity (CE, CM or CDIS) • The 802.19.1 system consumes information to provide services (coexistence discovery, coexistence management and information service) • The 802.19.1 system generates information in the services Mika Kasslin, Nokia

  4. Design Principles • The information source entities are responsible for sharing the information with the other entities of the coexistence system to the extent needed • The entities that have information for consumption in the coexistence system are responsible for pushing up to date information to other relevant entities • The entities that provide services push service related information to service subscribers • Request based procedures have reasons and places but they are not the best ones to distribute information that is dynamic in nature • Indication and push based approach should be used to share information since the information source is the entity which knows when there is change in the information Mika Kasslin, Nokia

  5. Example case setup: A CE subscribed to the information service • A CE is registered to a CM • The CE is subscribed to the information service • The WSO which the CE represents in the coexistence system decides on its own operating parameters • The CM provides coexistence reports to the CE • Two procedures specified for this in the DF2.08 as summarized in the next slide • It is entirely up to the WSO implementation when and on what basis it decides on its own operating parameters • Changes in the WSO may trigger the decision making • Information from the CM may trigger the decision making Mika Kasslin, Nokia

  6. Example case setup: Coexistence report procedures • The current draft provides both a pull and push based procedure • The CE is allowed to issue a request at any time (pull approach) • The CM is mandated to issue an announcement on changes in the report (push approach) Mika Kasslin, Nokia

  7. Example case: WSO decisions on operating parameters • Let’s assume that the WSO makes decisions on operating parameters based on all the relevant information it has from internal sources and from the coexistence system • Internal: Resource needs, experienced connection quality, changes in connection quality, changes in experienced interference situation, etc. • Coexistence system: Coexistence report • Information updates may be the reason to change the operating parameters • Most probably the WSO uses every information update to check whether a change is needed • Every internal and external update contains valuable information and should be considered against the current set of operating parameters Mika Kasslin, Nokia

  8. Example case: Two possible approaches Timeline example above illustrates a case in which the WSO checks whether new operating parameters are needed once it receives an internal event. The process box represents WSO function to check whether new operating parameters are needed and to determine new operating parameters. Timeline example above illustrates a case in which the WSO checks whether new operating parameters are needed once it receives either an internal or external event. The process box represents WSO function to check whether new operating parameters are needed and to determine new operating parameters. Mika Kasslin, Nokia

  9. Example case: Discussion • If the WSO uses only the internal events to trigger decision making on operating parameters there will be time periods during which the WSO operates with parameters which were selected based on outdated coexistence report • This kind of implementation should be avoided at least when designing the coexistence system Period of outdated coexistence report Mika Kasslin, Nokia

  10. Example case: Discussion (cont.) • If the WSO uses both internal and external events to trigger decision making on operating parameters the WSO can be expected to run the decision making process more frequently than when using only one of the events as the trigger • We have assumed this kind of implementation when designing the coexistence system • We don’t see a reason for the CE to issue requests on coexistence report to the CM since every coexistaence report update will be analyzed to check whether there is a reason to change the operating parameters Mika Kasslin, Nokia

  11. The design in nutshell • The current draft mandates the CM to issue a CoexistenceReport_Announcement message whenever there is a change in the report • The current draft allows for the CE to issue a CoexistenceReport_Request whenever it needs the latest coexistence report • The WSO should count on having all the time the up to date coexistence report since the CM is responsible for delivering it in an unsolicited manner • The WSO should use all the information and all the informations updates to evaluate validity of the current operating parameters • Role of coexisatence report requests is still very unclear unless the assumption is to ignore some of the coexistence report announcements • If the group believes a request based procedure is needed, we would like to propose the specification to limit use of the procedure by, as an example, setting a minimum time from a CoexistenceReport_Announcement or a CoexistenceReport_Response to a CoexistenceReport_Request which each CE needs to obey. This would prevent a CE issuing really frequent and unnecessary requests. Mika Kasslin, Nokia

  12. Summary • Pull and push based coexistence report delivery mechanisms analyzed from perspective of a WSO which is represented by a CE which is subscribed to the information service • Two possible approaches of WSO decision making discussed with the intention to prove that push based coexistence report delivery is enough for WSO implementations in which all the information updates either internal or external are evaluated • The proposal is still to either delete the request based procedure as obsolete • If the group decides to keep the request based procedure in the specification, the specificaiton needs to ensure that a CE doesn’t issue requests on regular basis and too often Mika Kasslin, Nokia

More Related