802.19.1 Interfaces Date: 2010-09-15 Authors: September 2010 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. 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.19. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 TAG 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 <shellhammer@ieee.org> 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.19 TAG. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Hyunduk Kang, et al, ETRI

Contents Introduction Interface between CM and CE September 2010 Contents Introduction Interface between CM and CE Interface between CM and CDIS Interface between CM and remote CM Centralized topology Distributed topology Hyunduk Kang, et al, ETRI

September 2010 Introduction (1/3) 802.19.1 system architecture consists of three logical entities and six logical interfaces 802.19.1 system architecture Hyunduk Kang, et al, ETRI

September 2010 Introduction (2/3) There are 3 interfaces between 802.19.1 entities as follows: Interface B1: Interface between CE and CM Interface B2: Interface between CM and CDIS Interface B3: Interface between CM and remote CM Each interface is defined by state machine of each entity, message exchange sequences, and message formats. Hyunduk Kang, et al, ETRI

September 2010 Introduction (3/3) Each state machine for interface between 802.19.1 entities consists of 4 or more of the following states: Inactive: the state where it is impossible to set up any interfaces with other 802.19.1 entities. The inactive state goes to the active state when initialization process is finished. Active: the state where it is possible to set up interface with other 802.19.1 entities. The Active state goes to the inactive state when shutdown process is finished. Waiting engagement: the state where one entity has requested for interface setup to the other entity, and is waiting for response from it. Engaged: the state where two entities are ready to communicate with each other. Request sent: the state where the request related to “context information (CI)” or “event (EV)” or “reconfiguration (RC)” has been sent from home entity to remote entity, and the home entity is waiting for response from the remote entity. Request received: the state where the request related to “context information (CI)” or “event (EV)” or “reconfiguration (RC)” has been received from remote entity to home entity, and home entity is waiting for the completion of the request. Hyunduk Kang, et al, ETRI

Interface between CM and CE (1/2) September 2010 Interface between CM and CE (1/2) The CM state machine consists of the following 4 states Inactive Active Engaged Request sent The CE state machine consists of the following 5 states Waiting engagement Hyunduk Kang, et al, ETRI

Interface between CM and CE (2/2) September 2010 Interface between CM and CE (2/2) An example of message exchange sequence Message formats are categorized as follows: Context.Info Reconfiguration Event Hyunduk Kang, et al, ETRI

Interface between CM and CDIS (1/2) September 2010 Interface between CM and CDIS (1/2) The CM state machine consists of the following 6 states Inactive Active Waiting engagement Engaged Request sent Request received The CDIS state machine consists of the following 5 states Hyunduk Kang, et al, ETRI

Interface between CM and CDIS (2/2) September 2010 Interface between CM and CDIS (2/2) An example of message exchange sequence Message formats are categorized as follows: Context.Info Event Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Centralized topology (1/3) September 2010 Interface between CM and remote CM: Centralized topology (1/3) In centralized topology, There is one master CM which has a number of slave CMs. The master CM performs coexistence decision making and slave CMs follows it. Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Centralized topology (2/3) September 2010 Interface between CM and remote CM: Centralized topology (2/3) The master CM state machine consists of the following 5 states Inactive Active Engaged Request sent Request received The slave CM state machine consists of the following 6 states Waiting engagement Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Centralized topology (3/3) September 2010 Interface between CM and remote CM: Centralized topology (3/3) An example of message exchange sequence Message formats are categorized as follows: Context.Info CX.Decision Event Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Distributed topology (1/3) September 2010 Interface between CM and remote CM: Distributed topology (1/3) In distributed topology, A CM pair, one CM and its neighbor CM, is connected each other. Any two CMs could be connected each other. Each CM performs coexistence decision making by negotiation with neighbor CMs. Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Distributed topology (2/3) September 2010 Interface between CM and remote CM: Distributed topology (2/3) The CM state machine consists of the following 6 states Inactive Active Waiting engagement Engaged Request sent Request received The neighbor CM state machine is identical to the CM state machine Hyunduk Kang, et al, ETRI

Interface between CM and remote CM: Distributed topology (3/3) September 2010 Interface between CM and remote CM: Distributed topology (3/3) An example of message exchange sequence Message formats are categorized as follows: Context.Info Event Hyunduk Kang, et al, ETRI