1. 06/21/2015DCN 6-15-0018-01-CNTS Notice: This document has been prepared to assist IEEE DYSPAN-SC and its Working Groups. 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 DYSPAN-SC. Patent Policy and Procedures: The contributor is familiar with the IEEE 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 IEEE DYSPAN-SC and its Working Groups 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 DYSPAN-SC. If you have questions, contact the IEEE Patent Committee Administrator at.patcom@ieee.org Document Title:1900.6b Interface Requirements Document Date:06-23-2015 Document No:DCN 6-15-0018-01-CNTS Author’s NameCompanyAddressPhoneemail Bernd BochowFraunhofer FOKUS Berlin, Germany Fraunhofer FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin, Germany +49 30 3463 7238bernd.bochow@ieee.org 1

2. 06/21/2015DCN 6-15-0018-01-CNTS Purpose This document is building upon DCN 6-15-11-00 ‘Basic Use Cases and Interfaces’. It aims to elaborate on the interface requirements of the 6 basic use cases outlined by DCN 6-15-11 and in particular on the capacities in terms of functionality, parameters and primitives required to implement the use cases. Revision 01 of this document further details on SAP requirements and suggests concrete worging items for consideration by the WG. 2

3. 06/21/2015DCN 6-15-0018-01-CNTS Reference Model (I/II) Interfacing option. – Database attaches to A-SAP though some gateway function as a client application. – Applies to use cases (see DCN 6-15-11): 1 to 5 Integration option – Database attaches to C-SAP though some gateway function as a 1900.6 entity. – Applies to use cases (see DCN 6-15-11): 1 to 6 Main distinction through level of control and trust achievable. – Tight coupling (i.e. integration option) enables higher degree of transparency (e.g. regarding topology) and functionality. 3

4. 06/21/2015DCN 6-15-0018-01-CNTS Reference Model (II/II) Interfacing in a hierarchical scenario (here: use case ‘industrial wireless’). – Architecture option, interfacing option and use case. – Responding to the need for integration of functions from regulatory database, dynamic spectrum management, radio resource management, and coexistence management. Hierarchy level – Regulator – Intermediary (e.g. spectrum manager, spectrum broker, or wireless operator. – Facility operator (i.e. spectrum manager as a database client). Trust level – Trusted (in-domain interfaces) – Dependable ( in-domain third-party) – Untrusted (marshalled through inter- database interfaces). 4

5. 06/21/2015DCN 6-15-0018-01-CNTS Potential Configurations Direct sensor connection Interfaces – Database – Gateway function – Gateway function – 1900.6 Sensor Database – Gateway function Interface – Option 1: Proprietary and out of scope for 1900.6. – Option 2: Proprietary but 1900.6 provides functional requirements in a technology- agnostic way that cover the functionality of the underlying 1900.6 interface. – Option 3: Widely used interface model as a reference implementation (e.g. JSON/REST based web service interface). Gateway function – 1900.6 Sensor Interface – The Gateway function acts as a 1900.6 control application attached to the A-SAP. – The 1900.6 A-SAP interface is revised and extended. – Option 1: Revision of interface SAP and data structure. – Option 2: ‘Transparent’ application as a proxy utilizing a (less-changed) A-SAP 5

6. 06/21/2015DCN 6-15-0018-01-CNTS Potential Configurations Sensing with decision-making capacity Interfaces – Database – Gateway function – Gateway function – 1900.6 Sensor Database – Gateway function Interface – Option 1 … 3 see previous slide. Gateway function – 1900.6 CE Interface – The Gateway function acts as a 1900.6 control application attached to the A-SAP. – 1900.6 A-SAP interface with extensions and adoptions from the C-SAP. – Option 1 … 2 see previous slide. – Option 3: ‘Transparent’ application as a proxy utilizing a (less-changed) A-SAP and potentially connecting directly to the C-SAP (i.e. as a new entity ‘sensing sub-system control function’ that can access remote 1900.6 entities). 6

7. 06/21/2015DCN 6-15-0018-01-CNTS Potential Configurations Full-fledged distributed sensing system Interfaces – Database – Gateway function – Gateway function – 1900.6 CE – Gateway function – 1900.6 DA Database – Gateway function Interface – Option 1 … 3 see previous slide. Gateway function – 1900.6 CE Interface – The Gateway function acts as a 1900.6 control application attached to the A-SAP. – 1900.6 A-SAP interface with extensions and adoptions from the C-SAP. – Option 1 … 2 see previous slide. – Option 3: Not applicable since replaced by the Gateway function – 1900.6 CE interface. Gateway function – 1900.6 DA Interface – Complementing the Gateway function – 1900.6 CE interface through A-SAP extensions that are DA specific. Resembling an inter-database interface on the functional level then. 7

8. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives A-SAP primitives (sub-clause 5.3.3) (I of III) The 1900.6 A-SAP specifies generic primitives enabling to exchange sensing related information (i.e. sensing, control and regulatory data) with the local 1900.6 entity. It also specifies primitives for managing and utilizing remote 1900.6 entities in case the local entity provides access to a communication sub- system. The 1900.6 services implements the SAP. The application (i.e. the database) is client to the 1900.6 services (see clause 4 for the reference model). Two primitives are provided to set and get arbitrary sensing related information: – Read_Sensing_Related_Info.[request | response] – Write_Sensing_Related_Info.[request | response] These directly map to the C-SAP send and receive primitives. 8

9. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives A-SAP primitives (sub-clause 5.3.3) (II of III) Three primitives are provided that control the exclusive use of spectrum sensors in a distributed sensing system with multiple clients to the Sensors under consideration: – Lock.[request | response] – Unlock.[request | response] – BreakLock.[request | response] One primitive allows to obtain a list of currently accessible Sensors in a distributed sensing system: – Get_ Sensor_Logical_ID.[request | response] This primitive is complemented by another one returning the same information for 1900.6 entities of all kinds: – Get_Client_Profile.[request | response] The 1900.6a complemented query options with respect to those entities currently acting as a source of sensing information for a DA: – Get_Data_Source_List.[request | response] (1900.6a) 9

10. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives A-SAP primitives (sub-clause 5.3.3) (III of III) One primitive provides a method to request a certain action to be triggered in the scope of the 1900.6 services at a given point in time: – Trigger.[request | response] One primitive provides a method to indicate an exception or internal status change of the application to the 1900.6 services: – Notify A number of primitives is provided to manage the distributed sensing topology. This is partly achieved by managing the communication subsystem and partly by utilizing the communication subsystem to involve remote 1900.6 entities: – Get_CommSubsys_ID.[request | response] – Advertisement.[request | response] (1900.6a) – LinkSetup.[request | response] (1900.6a) – LinkTermination.[request | response] (1900.6a) – Comm_Management.[request | response] Since the specification of the communication subsystem is not in scope of 1900.6, management mechanisms required are left to the implementation. 10

11. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives Potential A-SAP working items in 1900.6b (I/III) It is suggested to review all A-SAP primitives according to their soundness with regards to their interaction with the 1900.6 services. In particular: – The direction of the Notify primitive, which may be a Notify.indication instead. – The meaning of the LockStatus, which is ambiguously denoted as that of the client. It is suggested to add a new A-SAP primitives to obtain 1900.6 entity status. – This new primitive could replace (i.e. deprecate) the Get_ Sensor_Logical_ID, Get_Client_Profile and Get_Data_Source_List primitives by a single new one. It is suggested to revise the 1900.6 lock handling: – A new primitive could replace (i.e. deprecate) the Lock, UnLock and BreakLock primitives by a single new one that allows also to query the LockStatus and the Lock owner as well as to change multiple Locks in a single atomic operation. – We could extend the Lock handling to accommodate the spectrum database trust requirements, for example, to enhance this primitive with credential exchange capabilities, which in anyway would be needed to make the Locking failsafe. 11

12. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives Potential A-SAP working items in 1900.6b (II/III) It is suggested to complement the A-SAP primitives dedicated to the topology and communication subsystem management to enhance functionality required from the 1900.6b and its spectrum database application. In particular: – To add primitives (or enhance existing ones) to set and get sensing related parameters from a list of Sensors (or other entities) with a single call. – To add primitives (or enhance existing ones) to set a target topology through configuring communication subsystem and links between it instances for a list of entities with a single call. – To add a primitive to exchange credentials and authenticate between two 1900.6 entities. – To enhance the Notify and Trigger primitives to automate the sensing information acquisition process for multiple sensors in a single event. This includes setting and getting sensing related information from groups of Sensors and the implementation of “list filters” to conveniently select subsets of Sensors from a larger list (potentially based on Sensor capabilities or Sensor attributes). 12

13. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives Potential A-SAP working items in 1900.6b (III/III) It is suggested to revise the read and write sensing related information primitive’s parameters to utilize also 1900.6 CE and DA entities as a service to a spectrum database: – Current data structures focus on the interaction with Sensors mainly. – To involve CE and DA entities in the distributed sensing topologies of relevance for spectrum databases will require different data structure. – This has been so far not in scope of 1900.6 since it was assumed that the 1900.6 services of a Sensor are the sole clients to the 1900.6 services of CE or DA entities and vice-versa. It is suggested to add primitives to the A-SAP capable to convey application specific data structures to remote 1900.6 entities. – These primitives should complement the read and write sensing related information primitives to avoid burdening the standard primitives with parameter datasets that are of relevance only for a few applications. – This should be coordinated with the enhancement of the get profile / get capabilities primitives in order to obtain a 1900.6 entities capability or the communication subsystem capability to support such application specific communication. 13

14. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives C-SAP primitives (sub-clause 5.3.2) The 1900.6 C-SAP specifies generic primitives enabling to exchange sensing related information (i.e. sensing, control and regulatory data) with remote 1900.6 entities through a communication sub-system. The communication sub-system implements the SAP. The 1900.6 services are client to the communication sub-system services (see clause 4 for the reference model). Two primitives are provided to set and get arbitrary sensing related information: – Sensing_Related_Information_Send.[request | response] – Sensing_Related_Information_Receive.[request | response] One primitive provides a method to identify the communication sub-system and its capacities – Get_CommSubsys_Profile.[request | response] One primitive provides a method to indicate an exception or internal status change of the communication sub-system to the 1900.6 services: – Notify 14

15. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives Potential C-SAP issues in 1900.6b The 1900.6b aims to provide access to a distributed sensing system to clients of the A-SAP. – This requires to configure the communication sub-system to detect and reach remote 1900.6 entities (e.g. Sensors). – There exists a number of A-SAP primitives intended to manage a distributed system (e.g. Advertisement, LinkSetup, LinkTermination, Comm_Management …). – Without a suitable control SAP or control primitives these can not affect remote entities. Current SAP specifications lack communication sub-system control functions. – The C-SAP has been defined as a user SAP. A corresponding control SAP has not yet been considered due to the technology-agnostic approach. – The send and receive sensing related information primitives do not yet provide the capacity to convey local control information to remote 1900.6 services. – Since the 1900.6 services (as the function to implement a control and management procedure) need to distinguish between local and remote C-SAP instances, both a control SAP and control messages to the communication sub-system may be needed. 15

16. 06/21/2015DCN 6-15-0018-01-CNTS 1900.6-2011 and 1900.6a-2014 SAP Primitives Potential C-SAP working items in 1900.6b It is suggested to review all parameters to the C-SAP primitives. – It must be ensured that all sensing related information required by a spectrum database application can be conveyed through the send and receive primitives towards a remote 1900.6 entity. – It should be verified which control parameters could be added to the send and receive primitives that would allow to control and manage a remote 1900.6 entity. – It is suggested to start from the assumption that all relevant A-SAP primitives could be conveyed to a remote 1900.6 entity through the send and receive primitives and then to reduce these requirements to the minimum actually demanded by the practical database application. It is suggested to add a local communication sub-system control SAP. – A control SAP should provide an interface to deploy control and management data to the local C-SAP instance. – The implementation of the communication sub-system services is not part of this. It thus is not required to relax the technology-agnostic approach of the 1900.6. It is suggested to add a new clause on interface procedures to the 1900.6b as an initial step to support standards conformance evaluation. 16

17. 06/21/2015DCN 6-15-0018-01-CNTS Conclusions This document builds upon the use cases outlined in DCN 6-15-11-0 ‘Basic Use Cases and Interfaces’ and elaborated the interfacing options in more detail. This document also proposes an initial reference model as a proposal for further discussion. In the next steps we need to refine the interface requirements and to detail the IEEE 1900.6-2010 API extensions needed to realize the most relevant of these options. In order to set priorities for upcoming working items we will need to elaborate the database requirements in more detail. Revision 01 of this documents adds a number of proposals for working items to the group regarding the requirements for enhanced 1900.6 A-SAP and C-SAP to accommodate spectrum database clients. 17