03/24/2015DCN 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 Document Title:Basic Use Cases and Interfaces Document Date: Document No:DCN CNTS Author’s NameCompanyAddressPhone Bernd BochowFraunhofer FOKUS Berlin, Germany Fraunhofer FOKUS Kaiserin-Augusta-Allee Berlin, Germany

03/24/2015DCN 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 reference model and then concludes on the interfaces that should be defined for implementing the use cases. 2

03/24/2015DCN CNTS System and Reference Model Options to interface external entities System Model and Reference Model according to IEEE Std Options to interface a new compliant entity. – As a client to the C-SAP (entity implements a 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 compliant gateway function acting as a proxy towards the sensing system (see IEEE Std a-2014 for attaching legacy sensing subsystems). 3

03/24/2015DCN CNTS System and Reference Model Service Access Points A-SAP – Provided as a co-located instance by the entities 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 service to access sensing functions. C-SAP – Provided by a communication system to perform the exchange of sensing related information (including control information) between 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

03/24/2015DCN CNTS Attaching Spectrum Sensors to a Spectrum Database Proxy or Gateway approach Proposal earlier submitted to a using a gateway function between spectrum sensor and spectrum database. An (enhanced) Data Archive (DA) provides access to 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 entity but does not ensure full functionality of a the assumed role. 5

03/24/2015DCN CNTS Attaching Spectrum Sensors to a Spectrum Database entity approach A Spectrum Database acts as a client to the A-SAP. The A-SAP is co- local to the 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 service is implemented by the remote entity not part of the database. Option 2: The database implements the service, the A-SAP and utilizes the communication sub-system through the C-SAP. – The database becomes a 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 and non entities such as remote spectrum databases. 6

03/24/2015DCN CNTS Attaching Spectrum Sensors to a Spectrum Database Proxy/Gateway example from a Attaching non-compliant sensors to a distributed sensing system. Similar approach possible for interfacing a spectrum database Which 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

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

03/24/2015DCN CNTS Attaching Spectrum Sensors to a Spectrum Database entity approach reference model Attaching to the C-SAP as a compliant entity. All implementations (i.e. applications, SAPs, functions and 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

03/24/2015DCN 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 ( 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

03/24/2015DCN 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 ( entity based approach) or through a proprietary protocol (proxy/gateway approach). – When utilizing the 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

03/24/2015DCN 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 ). 12

03/24/2015DCN 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 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 entity based approach, the spectrum database may itself take the role of a controlling DA or CE eliminating the need for any entity other than the Sensors. 13

03/24/2015DCN 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 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

03/24/2015DCN CNTS Basic use cases (6 of 6) The spectrum database acquires sensing information from a sensing system and acts as another 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 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 entity based approach since the 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

03/24/2015DCN CNTS Conclusions From the use cases presented we can conclude the need for specifying additional interfaces not yet considered by 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 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 a. – The introduction of a Spectrum Database as a entity. The main enhancements to the reference model include – An A-SAP proxy/Gateway providing a non 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 entity. 16