1. 03/24/2015DCN 6-15-0011-00-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:Basic Use Cases and Interfaces Document Date:03-24-2014 Document No:DCN 6-15-0011-00-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. 03/24/2015DCN 6-15-0011-00-CNTS Purpose For developing the initial use cases and to identify the main interfaces to be considered for further study, this document is proposing a number of basic use cases, their mapping to the current 1900.6 reference model and then concludes on the interfaces that should be defined for implementing the use cases. 2

3. 03/24/2015DCN 6-15-0011-00-CNTS 1900.6 System and Reference Model Options to interface external entities System Model and Reference Model according to IEEE Std 1900.6-2011. Options to interface a new 1900.6 compliant entity. – As a client to the C-SAP (entity implements a 1900.6 service). – As a client to the A-SAP (entity implements a compliant A-SAP client). Options to interface a legacy / proprietary (i.e. non-compliant) entity. – As a client to a 1900.6 compliant gateway function acting as a proxy towards the 1900.6 sensing system (see IEEE Std 1900.6a-2014 for attaching legacy sensing subsystems). 3

4. 03/24/2015DCN 6-15-0011-00-CNTS 1900.6 System and Reference Model Service Access Points A-SAP – Provided as a co-located instance by the entities 1900.6 service. – Utilized by the client application – client applications are entity specific. – In general measurement application for a Sensor, control application for Sensor Clients - Note that Sensors can be clients to other Sensors. M-SAP – A particular service access point enabling access to sensing equipment/functions. – Provided directly by the sensing functions or as a dedicated function (adapter, gateway or proxy). – Utilized by the 19000.6 service to access sensing functions. C-SAP – Provided by a communication system to perform the exchange of sensing related information (including control information) between 1900.6 entities. – Carries an application layer protocol across a wide range of possible implementations (e.g. a message bus or a communication network, OSI Layer 1 or above). 4

5. 03/24/2015DCN 6-15-0011-00-CNTS Attaching Spectrum Sensors to a Spectrum Database Proxy or Gateway approach Proposal earlier submitted to 1900.6a using a gateway function between spectrum sensor and spectrum database. An (enhanced) Data Archive (DA) provides access to 1900.6 sensing information but does not allow to issue requests to sensors directly. This role was not foreseen for a DA. A gateway function allows to convey all types of sensing related information – including control information if needed. This allows a spectrum database to act as any kind of 1900.6 entity but does not ensure full functionality of a the assumed role. 5

6. 03/24/2015DCN 6-15-0011-00-CNTS Attaching Spectrum Sensors to a Spectrum Database 1900.6 entity approach A Spectrum Database acts as a client to the 1900.6 A-SAP. The A-SAP is co- local to the 1900.6 service. Option 1: The database implements communication functions to access the A-SAP remotely. – A gateway function on top of the A-SAP is providing a widely used interface (e.g. RESTful) – The 1900.6 service is implemented by the remote entity not part of the database. Option 2: The database implements the 1900.6 service, the A-SAP and utilizes the 1900.6 communication sub-system through the C-SAP. – The database becomes a 1900.6 compliant entity implementing any SAP needed to realize a certain database function such as DA and CE related functions. – The database may optionally implement gateways to enable communication between 1900.6 and non-1900.6 entities such as remote spectrum databases. 6

7. 03/24/2015DCN 6-15-0011-00-CNTS Attaching Spectrum Sensors to a Spectrum Database Proxy/Gateway example from 1900.6a Attaching non-compliant sensors to a 1900.6 distributed sensing system. Similar approach possible for interfacing a spectrum database Which 1900.6 entity best to use as a proxy is determined by the use case, by the role taken by the spectrum database and by the functionality the spectrum database requires from the spectrum sensing. 7

8. 03/24/2015DCN 6-15-0011-00-CNTS Attaching Spectrum Sensors to a Spectrum Database Proxy/Gateway approach reference model Attaching to the A-SAP instantiated by a 1900.6 entity. The Proxy or the spectrum database may provide the Control/Application. The database is represented towards the sensing system as a 1900.6 entity taking a role determined by the chosen proxy. Interface between gateway and database is determined by the database. 8

9. 03/24/2015DCN 6-15-0011-00-CNTS Attaching Spectrum Sensors to a Spectrum Database 1900.6 entity approach reference model Attaching to the C-SAP as a 1900.6 compliant entity. All implementations (i.e. applications, SAPs, functions and 1900.6 service under control of the database implementation. The spectrum database is not limited to a single entity’s functionality but can implement multiple roles at the same time (e.g. DA and CE). As a C-SAP client the database has full control of the sensing system’s configuration and functionality. 9

10. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (1 of 6) The spectrum database acquires sensing information from one or more pre-configured sensors aiming to verify or update database internal propagation models – The database wants to control associated sensors and configures the sensors through the A-SAP. – For configuration and control the database may implement an A-SAP compliant application or may utilize the Control/Application part of an existing Sensor. – The database may attach to the A-SAP either directly (1900.6 entity based approach) or through a proprietary protocol (proxy/gateway approach). – The Database receives sensing information and may trigger the sensing process either through communication with the control process or directly with the sensors utilizing standard A-SAP primitives mapped onto the proprietary protocol. 10

11. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (2 of 6) The spectrum database acquires instantaneous sensing information and past sensing information from a pre-configured sensing system aiming to consider sensing information from mobile sensors and historic data for establishing an initial data and parameter set for its internal model and its internal spectrum map enabling estimations and predictions related to a given area of interest. – This use case set-up is similar to that for use case 1. – Additionally, the database may utilize a communication with a DA entity through the A- SAP to query past sensing information or to obtain sensing information from sensors that are not (no longer) reachable from the A-SAP associated with the database. – The database may attach to the A-SAP either directly (1900.6 entity based approach) or through a proprietary protocol (proxy/gateway approach). – When utilizing the 1900.6 entity based approach, the database may also benefit from a direct communication with a DA or CE for optimizing the sensing area or the sensing process. 11

12. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (3 of 6) The Spectrum database provides sensing information (e.g. model-based) to a sensing system (virtually acting as one or more sensors) or as a DA, aiming to emulate certain situations for a system depending on spectrum sensing. – This use case requires a similar set-up as for use cases 1 and 2 except that the database is also acting as a sensing information provider towards the sensing system. – The database can provide an (emulated) radio environment map to verify sensing only systems or to test decision-making capacities of the sensing system or the communication system depending on the sensing data. – The database may also act as a evaluation environment for other spectrum databases. – To provide sensing information the database may act as a Sensor or as a DA towards the sensing system. – As a Sensor it can provide sensing information for a distinct location, as a set of Sensors it can provide sensing information from (virtually) multiple locations. – Acting as a DA a database could also provide (virtually) past sensing data or predicted sensing data as well as regulatory information. The DA virtually acts as a Sensor towards the sensing system in that case (already considered by 1900.6-2011). 12

13. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (4 of 6) The spectrum database configures and controls one or more sensors aiming to improve its function being approved by regulations through reliable spectrum sensing. – This set-up is complementing use case 1 by making the database a sensing system controller removing the need for a dedicated control application and removing potential issues with the approval of external algorithms. – In this use case the database needs to attach directly to the A-SAP of a Sensor it wants to utilize. The required trust level may demand for a peer-to-peer communication with all controlled sensors. – Since a 1900.6 compliant sensing system does not provide a dedicated controller, virtually any entity may take the responsibility for configuring and controlling the system through a particular application logic accessing the A-SAP on any instance of a Sensor, CE or DA in the system. – When utilizing an 1900.6 entity based approach, the spectrum database may itself take the role of a controlling DA or CE eliminating the need for any 1900.6 entity other than the Sensors. 13

14. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (5 of 6) The spectrum database configures and controls a distributed sensing system aiming to improve the database approved by a regulator through complex spectrum sensing and pre-processing of sensing data. – The sensing data acquired may be used to enhance the database or to evaluate the database in terms of efficiency, performance or accuracy through an independent system. – This use case relies on a similar set-up as for use case 4 except that it is complementing use case 2 instead of use case 1. – In this use case the database needs to attach to the A-SAP of a Sensor or a client to a Sensor (Sensor, CE, or DA) to take full control of the sensing system potentially utilizing a 1900.6 entity based approach. – Since the sensing system may have own databases (DA) and decision-making (CE) it can provide complex services to the spectrum database but may act as a widely autonomous system, which might restrict its applicability for certain scenarios requiring, for example, an increased trust level. 14

15. 03/24/2015DCN 6-15-0011-00-CNTS Basic use cases (6 of 6) The spectrum database acquires sensing information from a sensing system and acts as another 1900.6 entity (i.e. CE, DA or Sensor) in parallel aiming to ensure that the way spectrum sensing is correctly customized to the needs of the database. – The database may query sensors and jointly decides in collaboration with a 1900.6 CE how to optimize the overall sensing, or how to focus on particular parameters (e.g. location, area of interest, frequency range, accuracy, resolution, acquisition rate …) based on the relevance or contribution of single sensors to the current context. – This use case requires the 1900.6 entity based approach since the 1900.6 does not foresee to mimic a multi-purpose entity through the A-SAP and thus requires direct connection to the C-SAP. – This use case enables the spectrum database to act in multiples roles enabling the database to control and complement spectrum sensing by adding functionality to the sensing system. – In this use case the spectrum database may also act as a sensing system towards other spectrum databases utilizing inter-database interfaces and communication. 15

16. 03/24/2015DCN 6-15-0011-00-CNTS Conclusions From the use cases presented we can conclude the need for specifying additional interfaces not yet considered by 1900.6 as well as some enhancements of the system and reference model. The main enhancements to the system model include – A clarification on the number of instances of a SAP a 1900.6 entity can provide to address multiple local SAP clients. – A clarification on multi-purpose entities implementing more SAPs than actually required for a “conventional” entity such as a DA (A-SAP, C-SAP) with Sensor capacity (M-SAP, C- SAP). – A proxy/gateway function should be specified for the A-SAP complementing that for the M-SAP introduced by 1900.6a. – The introduction of a Spectrum Database as a 1900.6 entity. The main enhancements to the reference model include – An A-SAP proxy/Gateway providing a non-1900.6 interface (e.g. a RESTful interface). – An enhanced A-SAP that can convey C-SAP primitives transparently between a local Control/Application and a remote 1900.6 entity. 16