Report on C MS standardization - Europa · standardization opportunities and contributions, also other OneFIT related contributions are summarized. As a support to future C4MS related

ICT EU OneFIT 31.12.2012

OneFIT Deliverable D3.4 1/33

Report on C4MS standardization – D3.4

Project Number: ICT-2009-257385

Project Title: Opportunistic networks and Cognitive Management Systems for Efficient Application Provision in the Future

Internet - OneFIT Document Type: Deliverable

Contractual Date of Delivery: 31.12.2012

Actual Date of Delivery: 14.01.2013

Editors: M. Mueck

Participants: Markus Mueck, Andreas Schmidt, Jens Gebert, Vera Stavroulaki, Andreas Georgakopoulos, Dimitrios

Karvounas, Kostas Tsagkaris, Panagiotis Demestichas, Marcin Filo

Workpackage: WP3

Estimated Person Months: 20 PMs (including Appendix D3.4-A)

Nature: PU1

Version: 1.0

Total Number of Pages: 33

File: OneFIT_D3.4_20121231_20130111-FINAL.doc

Abstract

This document addresses the standardization landscape, as well as specific contributions by the OneFIT consortium to various standardization bodies. While the focus is mainly on C4MS related standardization opportunities and contributions, also other OneFIT related contributions are summarized. As a support to future C4MS related standardization activities, i.e. beyond the lifetime of the project, an Appendix to this Deliverable has been set-up: “Appendix to Report on C4MS standardization – D3.4-A”. It complements the standardization overview within this document. For this purpose, this document presents a detailed analysis of signalling overhead for non-C4MS signalling.

Keywords List

C4MS, Standardization, ETSI, IEEE, IETF, 3GPP

1 Dissemination level codes: PU = Public

PP = Restricted to other programme participants (including the Commission Services) RE = Restricted to a group specified by the consortium (including the Commission Services) CO = Confidential, only for members of the consortium (including the Commission Services)



Executive Summary

The OneFIT project [1] is a collaborative research project for operator governed opportunistic networks (ON). These ONs are coordinated extensions of the infrastructure which can be used for example for operator governed device-to-device communication, opportunistic coverage extensions and opportunistic capacity extensions. The solution, which can also be used for Proximity Services as currently studied in 3GPP [2], provides enhanced wireless service provision and extended access capabilities for the Future Internet, through higher resource utilization, lower costs, and management decisions with a larger “green” footprint. The project derived from the fifth call for proposals of the 7th framework programme (FP7) of the European Commission for research and technological development.

This document gives an overview on

The current standardization landscape, in particular addressing 3GPP, ETSI, IEEE and IETF activities;

Specific contributions of OneFIT consortium members to standardization bodies, focusing on but not limited to C4MS related contributions;

A list of key interfaces developed by OneFIT which are expected to be of future standardization relevance beyond the lifetime of the project.

Following working directions in the above mentioned standardization bodies are expected to be of specific relevance:

3GPP dominates the cellular communication standardization. Concerning context information provision, a solution entitled ANDSF (Access Network Discovery and Selection Function) is identified to be closely related to C4MS work and a further evolution of corresponding 3GPP standards is expected for the future;

ETSI is actively driving Reconfigurable Radio Systems in the ETSI RRS Technical Committee. Context information provision to Mobile Devices is key in this framework. To this end, OneFIT led and successfully completed the work on ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems” [4] within this committee.

IEEE has a number of C4MS related activities, including “IEEE 802.19.1 TV Whitespace Coexistence Methods” and “IEEE 802.21 Media Independent Handover” which are closely analyzed in the sequel of this document.

IETF currently works on a protocol entitled “PAWS - Protocol to Access White Space Databases”. Due to its expected relationship to C4MS, an overview on those activities is given within this document.

A key success of the OneFIT consortium related to the set-up of a Working Item and the finalization of the corresponding Standards document: ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems” [4]. Indeed, a close cooperation with the ETSI RRS (Reconfigurable Radio Systems) Technical Committee was established; in this framework, ETSI RRS has identified the future need for an overview on possible approaches for providing Mobile Devices with (radio) context and Operator Policy information. The work on ETSI TR 102 684 addressed specifically this need and was mainly driven by OneFIT consortium members.

In order to further prepare follow-up standardization activities beyond the life-time of the OneFIT project, an appendix to this Deliverable has been set-up: “Appendix to Report on C4MS standardization – D3.4-A”. It complements the overview given in the present document by outlining a detailed analysis of signalling overhead for non-C4MS signalling. Together with Deliverable D3.3 (“Protocols, performance assessment and consolidation on interfaces for standardization”), in which



the cost of C4MS signalling was evaluated, comparable overhead evaluations are available which are considered to be key factors to future successful discussions in standardization bodies. For instance, D3.4-A comprises analysis of the C4MS signalling due to ON management for the scenario on opportunistic capacity extension through neighbouring terminals (i.e. SCE#2a) for a set of specific test cases. The C4MS overhead was studied with respect to the network context and the devices capabilities. In the worst case scenario, it was proved that the total amount of bytes that were exchanged in order to create the ON was around 120 KB, which is very low for today’s networks. In addition, cases where periodic maintenance messages are transmitted were studied and in the worst case it was estimated that the required bitrate was around 12 KB/s which is also very low for LTE/UMTS and Wi-Fi networks.



Contributors

First Name Last Name Affiliation Email

Markus Mueck IMC [email protected]

Andreas Schmidt IMC [email protected]

Jens Gebert ALUD [email protected]

Panagiotis Demestichas UPRC [email protected]

Andreas Georgakopoulos UPRC [email protected]

Vera Stavroulaki UPRC [email protected]

Kostas Tsagkaris UPRC [email protected]

Yiouli Kritikou UPRC [email protected]

Lia Tzifa UPRC [email protected]

Nikos Koutsouris UPRC [email protected]

Dimitris Karvounas UPRC [email protected]

Marios Logothetis UPRC [email protected]

Asimina Sarli UPRC [email protected]

Aimilia Bantouna UPRC [email protected]

Louisa-Magdalene

Papadopoulou UPRC [email protected]

Aristi Galani UPRC [email protected]

Panagiotis Vlacheas UPRC [email protected]

Petros Morakos UPRC [email protected]

Alexandros Antzoulatos UPRC [email protected]

Marcin Filo EIT+ [email protected]



Table of Acronyms

Acronym Meaning

3GPP 3rd Generation Partnership Project

ANDSF Access Network Discovery and Selection Function

C4MS Control Channels for the Cooperation of the Cognitive Management System

CCR Cognitive Control Radio

CMON Cognitive Management system for the Opportunistic Network

CPC Cognitive Pilot Channel

CSCI Cognitive management System for the Coordination of the Infrastructure

D2D Device-to-Device

ETSI European Telecommunications Standards Institute

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

LTE Long Term Evolution

MAC Medium Access Control

MIH Media-independent handover

ON Opportunistic Network

OneFIT Opportunistic networks and Cognitive Management Systems for Efficient Application Provision in the Future InterneT

PAWS Protocol to Access White Space Databases

ProSe Proximity Services

RAT Radio Access Technology

RRC Radio Resource Control

RRM Radio Resource Management

RRS Reconfigurable Radio Systems

UE User Equipment

UMTS Universal Mobile Telecommunications System

WLAN Wireless Local Area Network



Table of Contents

1. Introduction ................................................................................................................................................. 9 2. C4MS related Standardization Landscape ...................................................................................... 10 2.1 ETSI ............................................................................................................ 10 2.2 3GPP ............................................................................................................ 13

2.2.1 Feasibility Study on Proximity Services .................................................... 13 2.2.2 Radio Resource Control (RRC)-Protocol .................................................... 15 2.2.3 Access Network Selection and Discovery Function (ANDSF) ........................ 18

2.3 IETF ............................................................................................................. 19 2.3.1 Protocol to Access White Space Databases (PAWS) ................................... 19 2.3.2 Diameter ............................................................................................. 20

2.4 IEEE ............................................................................................................. 21 2.4.1 IEEE 802.19.1 TV Whitespace Coexistence Methods .................................. 21 2.4.2 IEEE 802.21 Media Independent Handover ............................................... 21

3. OneFIT C4MS Standardization activities .......................................................................................... 24 3.1 Informative Activities ..................................................................................... 24 3.2 Standards Contributions ................................................................................. 24

3.2.1 Contributions to ETSI TR 102 684 “Feasibility Study on Control Channels for

Cognitive Radio Systems” .............................................................................. 24 3.2.2 Contributions to 3GPP TR 102 907 “Use Cases for operation in TV White Space

Frequency Bands” ......................................................................................... 26 3.2.3 Contributions to 3GPP TR 22.803 “Feasibility Study for Proximity Services

(ProSe)”....................................................................................................... 26 3.2.4 Contributions to 3GPP TR 23.865 “WLAN Network Selection for 3GPP Terminals

” ................................................................................................................. 28 4. Interface description for future standardization activities ..................................................... 29 5. Conclusions ................................................................................................................................................ 32 6. References .................................................................................................................................................. 33



List of Figures Figure 1: Principle of in-band and out-band Cognitive Pilot Channel (CPC) [8]. ................................... 10 Figure 2: Protocol Stack of the LTE Uu Air Interface. ............................................................................ 17 Figure 3: IETF PAWS between White Space Master Device and Geo-location database ..................... 20 Figure 4: Draft IEEE 802.19.1 coexistence System entities [21] ........................................................... 21 Figure 5: Media Independent C4MS Service in IEEE 802.21 based implementation option for C4MS

procedures. ................................................................................................................................... 23 Figure 6: Key actors of the OneFIT system and their main roles .......................................................... 25 Figure 7: Main interactions and key functionalities of each phase ...................................................... 26 Figure 8: OneFIT Functional Architecture for the Management and Control of infrastructure

governed Opportunistic Networks as an evolution of the ETSI/E3 FA. ........................................ 29



List of Tables Table 1: Control Channel implementation options [3][4] ..................................................................... 12 Table 2: Use Cases and Scenarios described in 3GPP TR 22.803[2] ...................................................... 15 Table 3: List of Contributions to 3GPP SA1 (part 1). ............................................................................. 27 Table 4: List of Contributions to 3GPP SA1 (part 2). ............................................................................. 27 Table 5: List of Contributions to 3GPP SA2. .......................................................................................... 28



1. Introduction The objective of this document is threefold:

First, an overview on key standardization bodies is given whose work is expected to be of high relevance to OneFIT activities. In particular, the focus is on

o 3GPP for its relevance in cellular communication standards;

o ETSI for its relevance to Reconfigurable Radio Systems and Cognitive Radio standards, mainly in the ETSI RRS Technical Committee;

o IEEE for its relevance to TVWS, Coexistence and Handover related protocol work;

o IETF for its relevance to standards addressing a Protocol to Access White Space Databases (PAWS).

Second, an overview on OneFIT standardization activities is given. The key focus is related to C4MS, but further OneFIT related standards contributions are also to be highlighted and those will be summarized in this document.

Third, an overview on key interfaces is given which are expected to be of high interest to future standardization activities, beyond the lifetime of the project.

Please also note the availability of the appendix “Appendix to Report on C4MS standardization – D3.4-A”. It complements the overview given in the present document by outlining a detailed analysis of signalling overhead for non-C4MS signalling. Together with Deliverable D3.3 (“Protocols, performance assessment and consolidation on interfaces for standardization”), in which the cost of C4MS signalling was evaluated, comparable overhead evaluations are available which are considered to be key to future successful discussions in standardization bodies.



2. C4MS related Standardization Landscape This section summarizes the current standardization landscape with expected relevance to C4MS. In particular the following groups have been identified:

3GPP for its relevance in cellular communication standards;

ETSI for its relevance to Reconfigurable Radio Systems and Cognitive Radio standards, mainly in the ETSI RRS Technical Committee;

IEEE for its relevance to TVWS, Coexistence and Handover related protocol work;

IETF for its relevance to standards addressing a Protocol to Access White Space Databases (PAWS).

2.1 ETSI OneFIT consortium members contributed substantially in ETSI RRS. During the lifetime of the OneFIT project, ETSI RRS was constantly informed about the progress and the ideas and solutions developed by the project. A corresponding update was given at each physical ETSI RRS meeting, in most cases by providing a corresponding update presentation. The feed-back of ETSI RRS delegates was noted and provided to the consortium for internal realignment discussions. During those discussions it was indeed identified that there is great need seen in ETSI to investigate implementation options for a Cognitive Control Channel.

As a consequence, OneFIT consortium members were key in proposing the new ETSI RRS Working Item on “Feasibility Study on Control Channels for Cognitive Radio Systems” [4]. It is expected that this document will be used as a reference document for selecting suitable Control Channel solutions in the future work of ETSI RRS.

This activity is indeed building on available Cognitive Pilot Channel principles as introduced in [8]:

RAT 1, e.g. UMTS

RAT 2, e.g. GSM

RAT 3, e.g. WiMAX

RAT 4, e.g. WLAN

RAT 5, e.g. LTE

RAT Infos

In-band CPCCPC Configuration

and Information

RAT Infos

RAT Infos

RAT Infos

RAT Infos

Note: In-band CPC can also be deployed in more than one RAT

Management

Entity

(e.g. JRRM,

O&M)

CPC

ManagerCPC ConfigurationOut-band CPC

Figure 1: Principle of in-band and out-band Cognitive Pilot Channel (CPC) [8].



In the framework of this study, a number of implementation choices for Control Channels have been identified – organized within two main categories, namely i) Radio access technology independent implementation and ii) Radio access dependent implementation:

Radio access technology independent implementation

o IEEE 1900.4 based Information model

o 3GPP ANDSF-based/OMA DM-based implementation

o Distributed Agents based approach

o IETF DIAMETER based approach

o IETF PAWS based implementation

o IEEE 802.21 based approach

o Network management based implementations

Radio access dependent implementation

o 3GPP based L1 and L2 implementations

o IEEE 802.11 based

o Vendor Specific Information in MAC frames

o IEEE 802.11u

o Direct Wi-Fi Approach

o Bluetooth® based

o WiMedia UWB based

An overview of the final assessments is given in the table below [4]:



CC-CRS protocol option

Supported Interfaces

Information delivery model

Basic Connectivity

Required

Extension of baseline

standards required

Protocols Addressing

Radio access independent

3GPP ANDSF T2N Unicast No Minor OMA-DM IP or E.164

Distributed Agents T2T, T2N,

N2N Unicast,

Multicast Yes None CORBA/IIOP IP

IETF DIAMETER T2N, N2N Unicast Yes Minor DIAMETER IP

IETF PAWS T2N Unicast Towards database

None To be defined To be

defined

IEEE 802.21] T2N, N2N Unicast,

Multicast No Minor MIH

IP, L2 and MIH

identifier

TR069 N2N Unicast Yes Minor HTTP-SOAP IP

Radio access dependent

3GPP RRC based T2N Unicast,

Broadcast No Minor RRC

3GPP user equipment identifier

IEEE 802.11] T2T, T2N Unicast,

Broadcast No Minor 802.11 L2

IEEE 802.11u] T2N Unicast,

Broadcast No None 802.11u L2

Direct WiFi T2T (mainly) Unicast,

Broadcast No Minor 802.11 L2

Bluetooth® T2T (mainly) Unicast,

Broadcast No None Bluetooth® 2.1 ,

4.0 L2

WiMedia UWB T2T (mainly) Unicast,

Broadcast No None ECMA-368 L2

New Common Multi-RAT Control Layer Approaches

IEEE 802.19.1 T2N, N2N Unicast Yes None To be defined To be

defined

Table 1: Control Channel implementation options [6][4]



2.2 3GPP 3GPP is considered to be the key body for cellular communication standards. The working scope of this body is huge covering legacy, current and future technologies and their respective interaction across all relevant layers. In the framework of this document, the authors focus on a selection of working directions which seem to be most promising to OneFIT related technology:

Feasibility Study on Proximity Services;

RRC-Protocol;

Access Network Selection and Discovery Function (ANDSF).

2.2.1 Feasibility Study on Proximity Services

In September 2011 work on a new feasibility study on Proximity Services (“ProSe”) was kicked off in 3GPP [10]. This initiative was motivated by the fact that proximity-based applications and services represent a recent and growing socio-technological trend. The principle of these (often downloadable third party) applications is to discover instances of partner applications running in devices that are within proximity of each other, and ultimately also to exchange application-related data between these devices. In parallel, there is interest in both proximity-based discovery and proximity-based communications. The former arises from new business cases that were identified recently by some mobile network operators who are interested in offering proximity-detection as a new stand-alone service, while the latter is motivated by new or upcoming government bills, or regulatory decisions to enable establishment of wireless networks for police, firefighters, paramedics, emergency technicians, and other so-called “first responders” in cases where parts of the infrastructure are no longer operational. These wireless emergency networks may be seen as dynamic network extensions of the normal wireless infrastructure that are established in order to keep communicate alive during emergencies.

The current suite of 3GPP’s specifications is only partially suited for such needs, since all traffic and signalling would have to be routed in the network, thus impacting their performance and adding un-necessary load in the network. These current limitations are also an obstacle to the creation of even more advanced proximity-based applications. In this context, 3GPP’s LTE technology (the feasibility study on “ProSe” does not apply to GERAN or UTRAN) has the opportunity to become the platform of choice to enable both proximity-based discovery and communication between devices in vicinity, and to promote a vast array of future and more advanced proximity-based applications.

First ideas that were presented in 3GPP had a very restricted scope and were proposing to enhance the capabilities of the LTE physical layer for a direct device to device communication without any control by the mobile network operator. In these concepts neither policy enforcement by the mobile network operator nor charging aspects were considered.

The OneFIT project partners have been contributing to the “ProSe” feasibility study for which 3GPP SA1 is the leading working group from the start. Thanks to this active role in 3GPP the scope of “ProSe” could be enhanced following closely the spirit of the solutions developed within the OneFIT project. The latest version of the Technical Report (TR) for this Study Item now mentiones device to device communication with mobile network operator control. Also, for the direct communication path non-cellular short range technologies, such as WiFi, are no longer excluded from ongoing investigations. Furthermore, initial security aspects were discussed.

Although the “ProSe” Technical Report has only informative character, it will serve as a basis for future work on a normative requirements document (Stage-1) in 3GPP SA1. The focus areas for “operator controlled discovery of devices that are in proximity” and “communication under continuous network control between devices that are in proximity” are:

commercial and social use;



network offloading;

public safety in general;

public safety in case of absence of E-UTRAN coverage (subject to regional regulation and operator policy, and limited to specific public-safety designated frequency bands and terminals); and

integration of current infrastructure services, to assure the consistency of user experience including reachability and mobility aspects.

As the work load in the various 3GPP working groups is extremely high in Q4/2012 the start of detailed technical work on “ProSe” is delayed. As long as there is no mature Stage-1 document in 3GPP no corresponding Stage-2/-3 work packages can be kicked-off.

An overview of the use cases and scenarios that are described in [10] can be found in Table 2 below. 3GPP decided to include authentication, authorization, accounting, and regulatory aspects in the studies.

Use Cases and Scenarios as described in 3GPP TR 22.803 [10]

1 General Use Cases

1.1 Restricted ProSe Discovery Use Case This use case describes a basic scenario for ProSe Discovery that can be used for any application. A social networking application is used as an example to illustrate this use case

1.2 Open ProSe Discovery Use Case This use case describes a case in which UEs discover other UEs without permission by the discoverable UEs.

1.3 Discovery Use Case with Subscribers from Different PLMNs This use case describes discovery of UEs that are camping on different PLMNs.

1.4 Discovery Use Case with Roaming Subscribers This use case describes discovery between UEs in different PLMNs under roaming conditions.

1.5 EPS ProSe Discovery for ProSe Use Case In this use case, the 3GPP EPS provides ProSe discovery assistance to ProSe-enabled UEs.

1.6 Service Continuity between Infrastructure and E-UTRA ProSe Comm. paths 1.7 Operator A uses ProSe to Enhance Location and Presence Services

ProSe is providing relatively limited enhancements to the presence and location information already present in 3GPP networks and by itself is able to detect a strict subset of the information available in the operator network.

1.8 ProSe for Large Numbers of UEs This use case describes a scenario involving a large number of UEs, and proposes ProSe requirements for such dense environments.

1.9 WLAN ProSe Communication Use Case This use case describes how WLAN direct communication can be used between ProSe-enabled UEs.

1.10 Service Management and Continuity for ProSe Communication via WLAN This use case demonstrates service management and continuity for ProSe Communication via WLAN.

1.11 Use Case for ProSe Application Provided by the Third-Party Application Developer The operator may provide ProSe capability features in a series of APIs to third-party application developers for application development. Benefiting from the cooperation between the operator and third-party application developers, the user can download and use a rich variety of new ProSe applications created by third-party application developers

2 Public Safety Use Cases

2.1 General Comment The following use cases and requirements are specific needs that are applicable for public safety in addition to those general use cases and requirements in the preceding section.

2.2 ProSe Discovery Within Network Coverage This use case describes the scenario where a given UE discovers one or more other UEs while in



network coverage, with ProSe Discovery always enabled.

2.3 ProSe Discovery Out of Network Coverage This use case describes the scenario where a given UE discovers one or more other UEs while out of network coverage, with ProSe Discovery always enabled.

2.4 Can Discover But Not Discoverable This use case describes the scenario where a given UE is able to discover other UEs, but is not discoverable by other UEs.

2.5 Basic ProSe One-to-One Direct User Traffic Initiation in Public Safety Spectrum dedicated to ProSe

This use case describes the case where a given UE initiates one-to-one direct user traffic session with another UE.

2.6 UE with Multiple One-to-One Direct User Traffic Sessions in Public Safety Spectrum dedicated to ProSe

This use case describes the case where a given UE can maintain one-to-one user traffic sessions with several other UEs concurrently.

2.7 ProSe Group This use case describes the scenario where a user wants to communicate the same information concurrently to two or more other users using ProSe Group Communications. The UEs of all users in the scenario belong to a common communications group.

2.8 ProSe Broadcast This use case describes the scenario where a given UE initiates a ProSe Broadcast Communication transmission to all UEs within transmission range.

2.9 ProSe Relay This use case describes the scenario where a given UE acts as a communication relay for one or more UEs.

2.10 ProSe Hybrid and Range Extension This use case describes the scenario where a given UE communicates using the network infrastructure and using ProSe Communications concurrently. This use case also describes the scenario where a given UE acts as a communication relay for one or more UEs so that the latter UE(s) can get communication towards the network.

2.11 ProSe Range This use case describes the scenario where a given UE is within a building and uses ProSe Communications to exchange user traffic to/from UEs outside of a building.

2.12 Public Safety Implicit Discovery This use case describes a scenario for ProSe public safety in which public safety officials need to communicate without an explicit ProSe discovery event.

Table 2: Use Cases and Scenarios described in 3GPP TR 22.803[2]

2.2.2 Radio Resource Control (RRC)-Protocol

The LTE Uu air interface is logically divided into three protocol layers as shown in Figure 2. The main services and functions of the RRC sublayer include:

- Broadcast of System Information related to the non-access stratum (NAS);

- Broadcast of System Information related to the access stratum (AS);

- Paging;

- Establishment, maintenance and release of an RRC connection between the UE and E-UTRAN including:

- Allocation of temporary identifiers between UE and E-UTRAN;

- Configuration of signalling radio bearer(s) for RRC connection:



- Low priority SRB and high priority SRB.

- Security functions including key management;

- Establishment, configuration, maintenance and release of point to point Radio Bearers (RBs);

- Mobility functions including:

- UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility;

- Handover;

- UE cell selection and reselection and control of cell selection and reselection;

- Context transfer at handover.

- Notification and counting for MBMS services;

- Establishment, configuration, maintenance and release of Radio Bearers for MBMS services;

- QoS management functions;

- UE measurement reporting and control of the reporting;

- NAS direct message transfer to/from NAS from/to UE.

Signalling Radio Bearers (SRBs) are defined as Radio Bearers (RB) that are used only for the transmission of RRC and NAS messages. More specifically, the following three SRBs are defined:

1. SRB0 is for RRC messages using the CCCH logical channel;

2. SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using DCCH logical channel;

3. SRB2 is for RRC messages which include logged measurement information as well as for NAS messages, all using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured by E-UTRAN after security activation.

In downlink piggybacking of NAS messages is used only for one dependant (i.e. with joint success/ failure) procedure: bearer establishment/ modification/ release. In uplink NAS message piggybacking is used only for transferring the initial NAS message during connection setup. The NAS messages transferred via SRB2 are also contained in RRC messages, which however do not include any RRC protocol control information.

Once security is activated, all RRC messages on SRB1 and SRB2, including those containing NAS or non-3GPP messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to the NAS messages.



One important RRC function is the broadcast of System Information in the LTE system for example in order to disseminate cell (re-)selection parameters and neighbouring cell information for UEs residing in RRC_IDLE mode of operation, and to disseminate information that is (also) applicable for UEs in RRC_CONNECTED, such as common channel configuration information.

Figure 2: Protocol Stack of the LTE Uu Air Interface.

A straightforward approach to transmit cognitive control data from the infrastructure (E-UTRAN) to mobile devices (User Equipment) would be to enhance the System Information (SI) broadcast messages. For instance, in case of LTE there are three types of RRC Messages for SI-Broadcast and the following mapping applies:

For the Master Information Block (MIB) carrying the most essential information needed to acquire other pieces of system information from the cell and for SIB-Type1 (containing information that is relevant for evaluating whether a UE is allowed to access a cell, and defines the scheduling of other system information) in each case distinct RRC Messages exist, while SIB-Type2 through SIB-Type15 use a third type of RRC Messages. It is noteworthy that during work on the OneFIT solutions 3GPP kept on adding new SIB-Types. So, addition of new SIB-Types is no theoretical excursion. This development is also mentioned here to explain why early milestone documents/deliverables talk about eleven SIB-types. At the time of writing this document 3GPP arrived at a total number of fifteen different SIB-Types. In order to include cognitive control data, a new SIB-Type would have to be introduced (for example SIB Type 16: “Cognitive Control Data”) for corresponding information broadcast.



2.2.3 Access Network Selection and Discovery Function (ANDSF) The scope of the 3GPP Access Network Discovery and Selection Function (ANDSF) is to support multi-access network scenarios with intersystem-mobility between 3GPP-networks (GSM, UMTS, LTE) and non-3GPP networks (e.g. WiMAX, WLAN). The ANDSF is located in the 3GPP Evolved Packet Core (EPC) and provides from the network to the mobile node (MN) policies for access network selection as well as access network specific information used to assist the mobile node (MN) in discovering available access networks and therefore in performing inter-system handovers. In 3GPP Rel-8 the ANDSF is located in the subscriber's home operator network (H-ANDSF) while in 3GPP Rel-9 there is no such restriction, i.e. the ANDSF can also be located in the visited network (V-ANDSF). For the exchange of information between the ANDSF server and the mobile node (MN) certain management objects (MOs) that are compatible with the OMA Device Management (DM) protocol specification were defined for ANDSF [15].The GSMA (GSM Association, http://www.gsma.com/) and WBA (Wireless Broadband Alliance, http://www.wballiance.com/) have been working together to enable networks and terminals to support WLAN Roaming capabilities, which will enable terminals to connect to both macro-cellular and WLAN networks with minimal configuration, and with integration between networks for the purpose of subscription management and charging. For this, a new GSMA Wi-Fi Roaming Task Force was established in the GSMA. The GSMA Wi-Fi Roaming Task Force have sent LS (SP-120003) to 3GPP which identifies areas where work needs to be done by 3GPP and/or WFA (Wi-Fi Alliance) to enable WLAN Roaming. Please also refer to the reply-LS (S2-121211) sent from SA back to the GSMA Wi-Fi Roaming Task Force in this regard. Based on this initiative 3GPP agreed a work item on ”WLAN Network Selection for 3GPP Terminals” in June 2012 that may lead to ANDSF enhancements as well as to enhancements for 3GPP System to WLAN interworking Management Object as described in [24].

The Hotspot 2.0 solution developed by WFA builds on the architecture and set of protocols defined by IEEE 802.11u and develops key capabilities for network discovery and selection of WLAN terminals based on the ANQP (Access Network Query Protocol) defined in IEEE 802.11u. The Wi-Fi Alliance is working on a certification program that improves WLAN hotspot discovery, network selection, and security. The program leverages the ANQP protocol that is part of IEEE 802.11u (or IEEE 802.11-2012) as well as WPA2 Enterprise security (includes EAP authentication over IEEE 802.1X). 3GPP already has some support for IEEE 802.11u, GAS (Generic Advertisement Service) and ANQP for I-WLAN as per TS 24.234. As Hotspot 2.0 also deals with network selection, there is a need to analyse how a UE can interact with network selection framework of I-WLAN, Hotspot 2.0 and ANDSF and specify a consistent procedure for WLAN network selection

The objective of the new 3GPP work item is to evaluate and if needed enhance existing 3GPP solutions for network selection for WLAN networks taking into account WFA Hotspot 2.0 solutions. The proposed work is based on existing TS 23.402 architectures. 3GPP operator’s policies for WLAN network selection will be provisioned on 3GPP terminals via pre-configuration or using the ANDSF. Specifically the objectives shall include:

1. Evaluate existing 3GPP WLAN PLMN and access network selection procedures for 3GPP terminals which use Hotspot 2.0 procedures and provisioned network operator policy (e.g. mechanisms based on WLAN and ANDSF) for any needed changes to current specifications. This may require enhancements to the ANDSF framework. The established 3GPP PLMN network selection (per TS 23.122) shall not be impacted. The work must ensure there are no conflicts between existing 3GPP PLMN network selection and the 3GPP WLAN PLMN access network selection procedures defined by this WID.

2. Ensure that the content in the Management Object related to 3GPP operator policy provisioning for WLAN network selection procedures and the operator policy provisioning in WFA MO for WLAN network selection are consistent.



3. Identify solutions to resolve potential conflicts between policies provided by non-3GPP providers via Hotspot 2.0 mechanisms and policies provided by 3GPP operators using ANDSF.

This work applies to non-seamless WLAN offload as well as to trusted and untrusted WLAN access to EPC with/without seamless offload. A new Technical Report [23] will be developed in 3GPP as part of this work item. Based on the technical analysis, stage 1 requirements may need to be addressed (e.g. WLAN PLMN selection criteria). Any needed enhancements/updates to 3GPP functions and interfaces will be identified and specified.

One possible solution would be to extend the ANDSF selection policies to support also selection policies based on the Realms and/or the Organizational Unique Identifiers (OUIs) which are supported by Hotspot 2.0 compliant WLAN networks. The ANDSF may send policies to UE based on Realms and/or OUIs to indicate for example that “WLANs that interwork with Realm=PartnerX.com have the highest access priority”. The UE uses the Realms and/or OUIs as an alternative way (instead of using SSID) to identify and prioritize the discovered WLAN access networks. A Hotspot 2.0 compliant UE is capable to discover the Realms and/or OUIs supported by a specific WLAN access network prior to association by using the applicable discovery procedures (e.g. based on the Access Network Query Protocol ANQP) and/or by receiving the beacon transmissions of APs (some OUIs are included in the AP beacon messages).

The OneFIT project partners have been contributing to the ”WLAN Network Selection for 3GPP Terminals” work item for which SA2 is the leading working group in 3GPP. Contributions were for instance related to improving the efficiency of WLAN discovery, enabling 3GPP UEs to select WLAN access networks based on parameters other than SSIDs, and general clarifications that a user has only one HPLMN.

2.3 IETF

2.3.1 Protocol to Access White Space Databases (PAWS) A "Protocol to Access White Space Databases (PAWS)" is currently developed in IETF [25]. The following functions shall be supported by the protocol:

White Space Master Device (WSD) initialisation, including discovery of a white space database, optional WSD authentication

WSD registration to provide information on owner/operator, location, antenna height, etc.

Database query and response

Channel use notification and response,

WSD validation.

The current proposed protocol stack is PAWS/HTTPS/TCP/IP.

Figure 3 shows an example where base stations and access points use PAWS to retrieve information from a geolocation database in order to select the white space frequency bands which will then be used to communicate with the devices.

Although still under discussion, PAWS will likely be transported over secured http-messages and using XML or JSON to describe the data.



(White Space) Geo-location

Database

Database access

via IETF PAWS

Communication in WhiteSpace Frequency Bands

White SpaceMaster Device

(MSD)

Slave Device PAWS

HTTPS

TCP

IP

Figure 3: IETF PAWS between White Space Master Device and Geo-location database

2.3.2 Diameter The DIAMETER base protocol as defined in IETF RFC 6733 [24] is an extensible protocol originally designed to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also used in 3GPP based networks e.g. to access the Home Subscriber Server (HSS) [19]. To support the applications in 3GPP, IETF has defined Diameter extensions, e.g.

- RFC 3589: Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5. September 2003

- RFC 4004: Diameter Mobile IPv4 Application. August 2005

- RFC 4005: Diameter Network Access Server Application. August 2005

- RFC 4006: Diameter Credit-Control Application. August 2005

- RFC 4072: Diameter Extensible Authentication Protocol (EAP) Application. August 2005

- RFC 4740: Diameter Session Initiation Protocol (SIP) Application. M. November 2006

- RFC 5224: Diameter Policy Processing Application. March 2008

- RFC 5431: Diameter ITU-T Rw Policy Enforcement Interface Application. March 2009

- RFC 5447: Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction. February 2009

- RFC 5516: Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS). April 2009

- RFC 5624: Quality of Service Parameters for Usage with Diameter.

The possible usage of the Diameter Protocol for the C4MS is presented in D3.2[7] and in the Appendix to D3.3[9].



2.4 IEEE Similar to 3GPP, the working scope of this body is extremely broad and cannot be covered in its entirety. The analysis performed in the framework of OneFIT are thus limited to the activities that are expected to be of key relevance to C4MS related technology.

2.4.1 IEEE 802.19.1 TV Whitespace Coexistence Methods

IEEE 802.19 task group 1 [21] works on defining a standard for TV White Space Coexistence Methods. The scope of the work is on radio technology independent methods for coexistence among dissimilar or independently operated TV band networks and devices.

The group has developed a system design document including a draft system architecture and requirements for neighbour TV WS device discovery, coexistence decision making, as well as management commands and information sharing. The logical entities providing those services and their relations are shown in Figure 4. The Coexistence Enabler (CE) interfaces the IEEE 802.19.1 coexistence system with a TV WS device (TVWSD). It obtains information needed for the coexistence from the TVWSD, and provides control and information from the coexistence system to the TVWSD. The Coexistence Manager (CM) makes the coexistence decisions. It discovers and solves the coexistence conflicts of the TVWSDs operating in the same area. The TVWSDs, which potentially cause interference to each other, may be served by different CMs. The Coexistence Discovery and Information Server (CDIS) assists the CMs to discover the neighbour TVWSDs and facilitates opening interfaces between the CMs which serve those TVWSDs. Some of the system entities are implemented in the wireless device and some in the network. The functional split may depend on the deployment. The protocols for different interfaces for accessing and sharing management commands and information are still to be defined. Further information can be found in [22].

Coexistence

Manager

Coexistence Enabler

Interface B1

Another

Coexistence Manager

Interface B3

TVBD network or

device

Interface A

Coexistence

Discovery and

Information Server

TVWS

Database

Interface B2Interface C

Operator

Mgmt

Entity

Interface D

802.19.1 Scope

Interface C

Figure 4: Draft IEEE 802.19.1 coexistence System entities [21]

2.4.2 IEEE 802.21 Media Independent Handover

The IEEE 802.21 “Media-Independent Handover (MIH) Services” standard [23] provides a set of extensible mechanisms mainly targeted to enable the optimization of handovers between heterogeneous IEEE 802 systems as well as facilitate handovers between IEEE 802 systems and cellular systems (e.g., 3GPP and 3GPP2). To that end, the standard defines:



A new functional entity (i.e., MIH Function, MIHF) to be allocated within terminals and networks.

A set of media-independent and media-dependent service access points (SAPs) for information exchange between the MIHF entity and other collocated system functional entities (e.g., link and network layer entities).

A signalling protocol for message exchanging between remote MIHF entities.

The MIHF entity has some control on link layer operation though media-dependent SAP and offers a set of services to entities within upper layers of the protocol stack (denoted as MIH users according to 802.21 standard’s terminology) though a media-independent SAP. Services provided to MIH users are classified as Media Independent Event Service (MIES), Media Independent Command Service (MICS) and Media Independent Information Service (MIIS). MIIS is an information service conceived to provide mobile terminals with details on the (static) characteristics and services of the serving and neighboring networks (e.g., network type, operator identifier, frequency bands, etc.). MIIS is built on the specification of various Information Elements (IEs) that can be transferred between remote MIHF entities. IEs can be represented by means of two distinct methods specified in the standard: Binary representation and Resource Description Framework (RDF). In the former case, each IE is assigned a given binary identifier so that the addition of new IEs for other purposes than handover optimization is possible but requires an extension of the standard. On the contrary, in the case of RDF representation, it is possible to define an extended schema to introduce new IEs without requiring further modifications to the standard.

In addition to service specification, IEEE 802.21 defines a complete protocol for message exchanges between remote MIH entities whose main characteristics are:

Transaction oriented protocol. At any given moment, an MIH node should have no more than one transaction pending for each direction with a certain MIH peer.

Support for reliable delivery service, flow control and fragmentation/reassembly. These functions are mainly intended to be used when transport mechanisms available to transfer MIH signalling messages between remote MIH entities do not support such functionalities.

Each MIHF entity is identified by means of a network access identifier (NAI) that should be unique as per IETF RFC 4282 (e.g., fully qualified domain name). MIHF identifiers are included in all protocol messages. A multicast MIHF identifier is also defined.

The protocol supports solicited and unsolicited MIH function discovery and capability discovery procedures.

Transport-agnostic design: MIH signalling messages can be transferred by means of either layer 2 (L2) or layer 3 (L3) protocols.

MIIS and MIH protocol constitute two relevant pieces of the IEEE 802.21 standard to be further considered in a potential implementation of Control Channels for Cognitive Radio Systems.

In the context of D3.3 [9] potential implementation procedures based on IEEE 802.21 are elaborated. To that respect, Figure 5 which is extracted from D3.3, presents a simple Message Sequence Chart depicting the usage of an example MIC4S messages in pull mode (i.e. Information Request/Response) and pull mode (Status Notification) for the purpose of C4MS message exchange.



Figure 5: Media Independent C4MS Service in IEEE 802.21 based implementation option

for C4MS procedures.



3. OneFIT C4MS Standardization activities This section summarizes standardization activities undertaken by OneFIT consortium members. There are two types of contributions:

Informative activities, providing updates on the progress of the OneFIT project and the relationship and relevance to the concerned standardization bodies;

Technical contributions to targeted standardization bodies.

A summary of both activities is given in the sequel.

3.1 Informative Activities Informative activities were mainly focusing on the ETSI RRS Technical Committee, since the greatest relevance to specific OneFIT interface and protocol work was identified to be inside this committee. The consortium reported about OneFIT progress at all physical ETSI RRS meetings during the life-time of the project – those meeting are organized four times per year.

The feed-back was consistently positive – comments and suggestions were further communicated to the consortium and help to improve the quality of the results.

Due to the good relationship to the ETSI RRS committee, OneFIT was able to initiate and feed the activity related to ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems” [4]. It is indeed a key success of the consortium since it provides an answer and support to a specific request of the RRS Technical Committee.

3.2 Standards Contributions

3.2.1 Contributions to ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems”

The TR [4] was published on April 2012 and it was driven mainly by OneFIT partners, including also some extra-OneFIT contributors. The scope of the TR is to identify and study communication mechanisms:

For the coexistence and coordination of different cognitive radio networks and nodes, operating in unlicensed bands like the ISM band or as secondary users in TV White Spaces;

For the management of ONs, operating in the same bands as mentioned above.

The scope and definition of ONs is elaborated within this TR; in particular, it is expected ONs will include mechanisms for operator-governed ad-hoc coverage extensions or capacity extensions of infrastructure networks. The communication is expected to include procedures from terminal to terminal as well as between a terminal and infrastructure networks. These mechanisms could be radio access technology (RAT) specific or/and be RAT-independent.

In particular, the TR carries out a study on the following topics:

(i) Methods for delivery of context and policy information in heterogeneous environments;

(ii) Discovery and identification of neighbouring devices;

(iii) Enable creation, maintenance and termination of opportunistic networks;

(iv) Consider previous work on in-band-Cognitive Pilot Channel (CPC) and Cognitive Control Radio (CCR);

(v) Implementation options for Control Channels for Cognitive Radio Systems.



Moreover, the OneFIT scenarios are described namely opportunistic coverage extension, opportunistic capacity extension, infrastructure supported opportunistic ad-hoc networking, opportunistic traffic aggregation in the radio access network and opportunistic resource aggregation in the backhaul network. The main actors and stakeholders have also been identified and elaborated and these are the network operator, the service provider, the ON end users/terminals, the ON supporting users/terminals and the content providers. The key actors and their main roles are illustrated in the figure that follows:

Figure 6: Key actors of the OneFIT system and their main roles

Also, explicit descriptions of the management phases of ONs, namely the suitability determination, the creation, the maintenance and the termination. Main interactions and key functionalities of each phase are illustrated in the figure that follows.



SUITABILITY CREATION MAINTENANCE

TERMINATION

•Detection of opportunities •Nodes• Applications• Mobility

• Resources

• Potential radio paths

•Assessment of potential gains

ON creation for:• Coverage

extension• Capacity

extension• Localized service

provision

• Traffic aggregation in the RAN

• Resource aggregation in the backhaul network

• Input to the creation phase is the information and knowledge accumulated from the suitability phase

Monitor• Nodes

• Spectrum• Policies• QoS

Reconfiguration:•Modification of an ON•Merge/Split ONs (governed by the operator)

•Alterations to the nodes, spectrum, operator’s policies, QoS trigger the maintenance phase

• Cessation of application provision• Resource release

• Inadequate gains• Handover to

infrastructure• Resource release

•Forced termination• Handover to

infrastructure for preserving important flows

• Resource release

Composite Wireless NetworkOpportunistic Network

• Suitability triggers the creation phase

SECURITY & TRUST

Figure 7: Main interactions and key functionalities of each phase

Finally, implementation options (both RAT-dependent and RAT-independent) for Control Channels for Cognitive Radio Systems are analyzed. Related information has already been provided through this deliverable, section 2.1.

3.2.2 Contributions to 3GPP TR 102 907 “Use Cases for operation in TV White Space Frequency Bands”

Because opportunistic networks can also be operated in white space frequency bands, the OneFIT Project has contributed to the ETSI TR 102 907 [11] by providing the following use cases:

- Infrastructure supported ad-hoc networking

- Direct device-to-device links in TVWS managed by access points or femto cells

3.2.3 Contributions to 3GPP TR 22.803 “Feasibility Study for Proximity Services (ProSe)”

The objective of this Feasibility Study in 3GPP is to study use cases and to identify potential requirements for operator controlled discovery and communications between UEs that are in proximity, for:

1. Commercial/Social Use

2. Network Offloading

3. Public Safety



4. Integration of current infrastructure services, to assure the consistency of the user experience including reachability and mobility aspects

Additionally, the study item will study use cases and identify potential requirements for

5. Public Safety, in case of absence of EUTRAN coverage (subject to regional regulation and operator policy, and limited to specific public-safety designated frequency bands and terminals)

At the end of 2012 3GPP is still in the process of studying use cases (preparation of stage 1). As soon as this endeavour is concluded, the next step will be derivation of service requirements from the identified use cases. It is expected that work on a normative requirements document (stage 1) will include topics such as network operator control, authentication, authorization, accounting and regulatory aspects. The “ProSe” feasibility study does not apply to GERAN or UTRAN. OneFIT project partners contributed (amongst others) the following list of documents to this work package (all related to use cases):

Table 3: List of Contributions to 3GPP SA1 (part 1).

Table 4: List of Contributions to 3GPP SA1 (part 2).



3.2.4 Contributions to 3GPP TR 23.865 “WLAN Network Selection for 3GPP Terminals”

The GSMA and WBA have been working together to enable networks and terminals to support WLAN Roaming. This initiative will enable terminals to connect to both macro-cellular and WLAN networks with minimal configuration, and with tighter integration between networks for purposes of subscription management and charging. In summer 2012 3GPP received an official Liaison Statement from the GSMA and WBA which identified areas where work needs to be done by 3GPP and/or WFA (Wi-Fi Alliance) to enable WLAN Roaming (SP-12000).

The Hotspot 2.0 solution developed by WFA builds on the architecture and set of protocols defined by IEEE 802.11u and develops key capabilities for network discovery and selection of WLAN terminals based on the ANQP (Access Network Query Protocol) defined in IEEE 802.11u. The Wi-Fi Alliance is working on a certification program that improves WLAN hotspot discovery, network selection, and security. The program leverages the ANQP protocol that is part of IEEE 802.11u (or IEEE 802.11-2012) as well as WPA2 Enterprise security (includes EAP authentication over IEEE 802.1X). 3GPP’s specifications already have some support for IEEE 802.11u, GAS (Generic Advertisement Service) and ANQP for I-WLAN as per TS 24.234. As Hotspot 2.0 also deals with network selection, there is a need to analyse how a UE can interact with network selection framework of I-WLAN, Hotspot 2.0 and ANDSF and specify a consistent procedure for WLAN network selection.

3GPP Technical Report 23.865 is in a process of being developed as part of this work item. Based on the technical analysis, new stage 1 requirements may need to be addressed in future (e.g. related to WLAN PLMN selection criteria). OneFIT project partners contributed the following list of documents to this work package:

Table 5: List of Contributions to 3GPP SA2.



4. Interface description for future standardization activities The objective of this section is to clearly outline the key interfaces developed by the OneFIT consortium which are expected to be promising candidates for future standardization activities beyond the life-time of the project.

Note that further information of relevance on this topic is available in [5] (Deliverable D3.3 “Protocols, performance assessment and consolidation on interfaces for standardization”) and *6+ (Appendix to D3.3: “Detailed C4MS Protocol Specification”).

Figure 8 presents the OneFIT Functional Architecture which is based on the existing ETSI/E3 FA (defined in the TR 102 682[10]) and new functional entities related to Opportunistic Networks Management (to provide mechanisms for operator-governed ad-hoc extensions of infrastructure networks).

JRRM

RAT 1 RAT 2 RAT n…

DSM

DSONPM

CCMCJ

MJ MC

JR CR

CS

Operator’s

Infrastructure

JRRM

RAT 1 RAT n…

CCMCJ

CR JR

Relay Node (Terminal or AP)

JJ-TN

Country-wide spectrum database

Geo-location database

SS

MS

OJ

CI/OM

-TN

JRRM

RAT 1 RAT n…

CCMCJ

CR JR

Terminal

CI/OM

-TT

OJOCOJOCJJ-TT

CSCI CMON CSCI CMON CSCI CMON

RR-TT RR-TN

Opportunistic network

CD

Figure 8: OneFIT Functional Architecture for the Management and Control of infrastructure governed Opportunistic Networks as an evolution of the ETSI/E3 FA.

In general, the infrastructure governed Opportunistic Networks Management can be divided into two building blocks, namely the “Cognitive management System for the Coordination of the infrastructure” (responsible for the ON opportunity detection and ON suitability determination) and the “Cognitive Management system for the Opportunistic Network” (responsible for controlling the life cycle of the ON).

The following interfaces were developed/driven by OneFIT and are used in the OneFIT Functional Architecture (for the description of the functionality of other interfaces, see E3 D2.3).

CI/OM-Interface for the “Coordination with the Infrastructure” and “Opportunistic Management” and is located between different CSCI/CMON-instances. This interface is used to:

exchange context information, user preferences, node capabilities and policy related information,

negotiate about the creation or modification of an ON (during the negotiation, nodes establishes parameters for creation or modification of an ON),

execute creation and reconfiguration of an ON based on the negotiated parameters,

execute termination of an ON.



Additionally, the interface is used by the infrastructure network to:

inform terminals (or other infrastructure network elements) about the suitability of an ON,

provide context and policy information which are needed for the creation and maintenance of an ON (SCE#3),

collect context information from the terminals to enable the ON suitability determination

A distinction can be made between the CI/OM-TT interface connecting the CSCI/CMON-instances of two terminals, the CI/OM-TN interface connecting the CSCI/CMON in a terminal with the CSCI/CMON on Network side and the CI/OM-NN interface connecting the CSCI/CMON-instances of two network entities.

It needs to be underlined here that in the early phase of the OneFIT project the CSCI and CMON were considered as separate entities. However, as the CSCI and CMON need to interact closely and also because they act on the same context information, they were integrated into one combined module and the CI-interface and OM-interface were combined into the CI/OM interface.

OJ: Interface between JRRM and CSCI/CMON. The interface may be used to:

o trigger the JRRM for the establishment and release of radio links during the creation, maintenance and deletion of an ON.

o collect locally available context information e.g. on available access networks or on link performance

A distinction can be made between the OJ-T interface connecting the CMON/CSCI instances with the JRRM in a terminal, and the OJ-N interface connecting the CMON/CSCI instances with the JRRM on network side

OC: Interface between CCM and CSCI/CMON. This interface is similar to the OJ interface and may be used to:

o obtain information about the current device configuration

o obtain information about the reconfiguration capabilities of the device

In contrast to the OJ interface, the OC interface is present only on the terminal side.

CD: Interface between DSONPM and CSCI/CMON. The interface can be used:

o retrieve information on the configuration of the operator’s network

o retrieve information on the reconfiguration capabilities of the operator’s network

The interface is present only on the infrastructure side.

CS: Interface between CSCI/CMON and the DSM. This interface is used to :

o obtain information on spectrum usage and spectrum allocation

o obtain spectrum policies



The spectrum related information obtain over this interface can be used for the suitability determination of ONs as well as for the decision making on which spectrum shall be used in an ON (It is assumed that this interface uses identical procedures and protocols as the MS-interface). The interface is present only on the infrastructure side.

Among the above mentioned interfaces, the CI/OM interface was in the main scope of the OneFIT project and seems to have the most potential for standardization. The implementation options (both RAT-dependent and RAT-independent) for the realization of Cognitive Control Channel over the CI/OM-TT, CI/OM-TN and CI/ON-NN interfaces were even analysed within ETSI RRS TR 102 684 (additionally, as shown in D3.3 [5], the signalling load on the interface is foreseen to be low compared to the actual user traffic).

The CI/OM interface supports the following elementary procedures (see Appendix to D3.3 for more detail D3.3 [5]):

Information provisioning: the procedure is used to exchange different types of information between nodes (e.g. Neighbourhood-Information, Node-status, Node-capabilities, User-profile, Geographical-Location, ON-Policies, Link Measurements). The procedure is based on the usage of Information-Request, Information-Answer and Information-Indication messages

ON suitability: the procedure is used to initiate the ON suitability determination in a node. This procedure is typically used in scenarios where a node which is not necessarily part of the ON and thus cannot decide on the suitability of an ON (e.g. Scenario 3) discovers a situation where an ON consisting of other nodes may be suitable. The procedure is based on the usage of ON-Suitability-Indication message

ON negotiation: the procedure is used to negotiate about the creation or modification of an

ON (e.g. if a node is willing to join an ON, the conditions for joining). The procedure is based on the exchange of ON-Negotiation-Request (ONNR) and ON-Negotiation-Answer (ONNA) messages.

ON creation: the procedure is used to create an ON based on the negotiated ON parameters

(e.g. the nodes involved and the spectrum band to be used), after successful negotiation. The procedure is based on the exchange of ON-Creation-Request (ONCR), ON-Creation-Answer (ONCA) messages.

ON modification: the procedure is used to enable a modification of an ON configuration. The

modification can be conducted for a single node, multiple nodes or the whole ON and may be based on the negotiated ON parameters (optionally ON modification can be preceded by the negotiation procedure). The procedure is based on the exchange of ON-Modification-Request (ONMR) and ON-Modification-Answer (ONMA) messages.

ON release: the procedure is used to release a node from the ON or to release the complete

ON. The procedure is based on the exchange of ON-Release-Request (ONRR) and ON-Release-Answer (ONRA) messages.

ON status notification: the procedure is used by a node to inform other node about the

status or status changes in an ON (e.g. ON_Negotiated, ON_Created, ON_Modified, ON_Released). This procedure is used for example to notify the infrastructure about creation, modification or release of an ON and may be used e.g. for accounting and billing purposes. The procedure is based on the usage of ON-Status-Notification (ONSN) message.



5. Conclusions The present work gives a concise overview on the standardization landscape and corresponding activities which are considered to be key by the OneFIT consortium. Also, a number of relevant standardization contributions is outlined.

The list of key interfaces developed by the OneFIT consortium is expected to support future follow-up standardization activities, beyond the life-time of the consortium.

Note that a key success of the OneFIT consortium is related to the set-up of a Working Item and the finalization of the corresponding Standards document: ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems” [4]. Indeed, a close cooperation with the ETSI RRS (Reconfigurable Radio Systems) Technical Committee was established and the following protocol options had been considered and analyzed:

Radio access independent:

3GPP ANDSF

Distributed Agents

IETF DIAMETER

IETF PAWS

IEEE 802.21

TR069

Radio access dependent:

3GPP RRC based

IEEE 802.11

IEEE 802.11u

Direct WiFi

Bluetooth®

WiMedia UWB

New Common Multi-RAT Control Layer Approaches:

IEEE 802.19.1



6. References [1] ICT-2009-257385 OneFIT Project, http://www.ict-onefit.eu/

[2] 3GPP TR 22.803 “Feasibility Study for Proximity Services (ProSe) (Rel12)”

[3] ETSI TR 102 683 “Cognitive Pilot Channel”, Sept. 2009

[4] ETSI TR 102 684 “Feasibility Study on Control Channels for Cognitive Radio Systems“, April 2012

[5] OneFIT Deliverable D2.2 “OneFIT functional and system architecture”, Febr. 2011

[6] OneFIT Deliverable D3.1 “Proposal of C4MS and inherent technical challenges”, March 2011

[7] OneFIT Deliverable D3.2 ”Information definition and signalling flows”, Sept. 2011

[8] OneFIT Deliverable D3.3 “Protocols, performance assessment and consolidation on interfaces for standardization”, June 2012

[9] Appendix to OneFIT Deliverable D3.3: “Detailed C4MS Protocol Specification”, June 2012

[10] ETSI TR 102 682 “Functional Architecture for the Management and Control of Reconfigurable Radio Systems”, July 2009

[11] ETSI TR 102 907 “Use Cases for Operation in White Space Frequency Bands”, October 2011

[12] 3GPP TS 23.203 “Policy and charging control architecture”.

[13] 3GPP TS 23.401 “GPRS enhancements for E-UTRAN access”

[14] 3GPP TS 23.402 “Architecture enhancements for non-3GPP accesses”

[15] 3GPP TS 24.235: “3GPP System to WLAN interworking Management Object”

[16] 3GPP TS 24.302 “Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks”

[17] 3GPP TS 24.312: "Access Network Discovery and Selection Function (ANDSF) Management Object (MO) “

[18] 3GPP TS 25.331 “Radio Resource Control (RRC); Protocol Specification”

[19] 3GPP TS 29.229 “Cx and Dx Interfaces based on Diameter protocols; protocol details”

[20] 3GPP TS 33.102 “3G Security; Security Architecture”

[21] IEEE 802.19.1 Wireless Coexistence in the TV White Space, http://ieee802.org/19/pub/TG1.html

[22] IEEE 802.19-11/49r0 “Full proposal for IEEE 802.19 Wireless Coexistence WG”, May 2011, https://mentor.ieee.org/802.19/dcn/11/19-11-0049-00-0001-full-proposal.pdf

[23] IEEE 802.21 Standard, “IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services.”, IEEE Computer Society, Sponsored by the LAN/MAN Standards Committee, January 2009

[24] IETF RFC 6733 “Diameter Base Protocol”, October 2012

[25] IETF Protocol to Access White Space database (PAWS), http://datatracker.ietf.org/wg/paws/charter/

http://www.ict-onefit.eu/

http://ieee802.org/19/pub/TG1.html

https://mentor.ieee.org/802.19/dcn/11/19-11-0049-00-0001-full-proposal.pdf

http://datatracker.ietf.org/wg/paws/charter/

Documents

Report on C MS standardization - Europa · standardization opportunities and contributions, also other OneFIT related contributions are summarized. As a support to future C4MS related