ETSI TS 103 652-2 V1.1.1 (2020-01)

Reconfigurable Radio Systems (RRS); evolved Licensed Shared Access (eLSA); Part 2: System architecture and high-level procedures

DTS/RRS-0151

General Information

• Status: Published
• Publication Date: 23-Jan-2020
• Technical Committee: RRS 1 - RRS System Aspects & Cognitive functionalities
• Current Stage: 12 - Completion
• Due Date: 08-Jan-2020
• Completion Date: 24-Jan-2020

Standards Content (Sample)

TECHNICAL SPECIFICATION
Reconfigurable Radio Systems (RRS);
evolved Licensed Shared Access (eLSA);
Part 2: System architecture and high-level procedures

2 ETSI TS 103 652-2 V1.1.1 (2020-01)

Reference
DTS/RRS-0151
Keywords
architecture, LSA spectrum resource, network,
radio
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 652-2 V1.1.1 (2020-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 eLSA supported spectrum access schemes. 7
4.1 Introduction . 7
4.2 eLSA Architecture Reference Model . 8
4.2.0 introduction . 8
4.2.1 Logical Elements . 9
4.2.2 Reference Points . 9
4.3 High-Level Functions . 9
4.3.0 introduction . 9
4.3.1 Information Entry Function . 10
4.3.2 Information Processing Function . 10
4.3.3 Information Mapping Function . 10
4.3.4 Reporting Function . 10
4.3.5 eLSA Information Exchange Function . 10
4.3.6 System Support Functions Group . 10
4.3.7 System Management Functions Group . 11
4.4 Mapping of High-Level Functions to Logical Elements . 11
5 eLSA Functional Description and Information Flows . 11
5.1 Introduction . 11
5.2 Protocol Stacks . 12
5.3 eLSA Interface Management Functions . 12
5.4 eLSA Protocol Elements . 12
5.4.1 Identities . 12
5.4.2 eLSA Spectrum Resource Availability Information . 12
5.5 High Level Procedures . 13
5.5.1 Introduction. 13
5.5.2 Registration Procedure . 13
5.5.3 Deregistration Procedure . 14
5.5.4 eLSR Grant Procedure . 15
5.5.5 eLSR Grant Relinquishment Procedure . 15
5.5.6 eLSRAI Request Procedure . 16
5.5.7 eLSRAI Notification Procedure . 17
5.5.8 eLSRAI Confirmation Procedure . 17
5.5.9 Connectivity Check Notification Procedure . 18
5.5.10 Connectivity Check Request Procedure . 18
5.6 Procedure Flows . 19
5.6.1 Introduction. 19
5.6.2 eLC Operation Start-up for granted eLSR . 19
5.6.3 eLC Operation Start-up for non-granted eLSR . 20
5.6.4 eLR Notification of new eLSRAI . 21
5.6.5 eLSRAI Synchronization . 22
5.6.6 eLC Request for new eLSRAI with optional eLR Notification . 23
ETSI
4 ETSI TS 103 652-2 V1.1.1 (2020-01)
6 eLSA Failure Management . 23
7 eLSA Deployment Scenario Rules . 24
Annex A (informative): eLSA Operational Use Cases . 25
A.0 Introduction . 25
A.1 Pre-checking of Spectrum Availability . 25
A.2 Activate eLSA Repository for eLSA operation . 25
A.3 Input of the Sharing Framework, Sharing Arrangement and eLSA License/Lease information to
the eLSA Repository . 26
A.4 VSP activates eLSA support operation . 26
A.5 VSP starts to operate in the available eLSA spectrum resources . 27
A.6 VSP receives information on eLSR Spectrum Resource Availability Information updates when
license/lease expires . 27
A.7 VSP operates in Detached Operation Mode (DOM) . . 28
A.8 Deployment of VSPs. With nomadic and temporary operation . 29
Annex B (informative): Guidance for LSA , LSA , eLSA and eLSA . 31
2 3 4 5
B.1 Introduction . 31
B.2 NRA-Related Guidance (LSA ) . 31
B.3 Incumbent-related Guidance (LSA ) . 31
B.4 VSP-related Guidance (LSA ) . 32
Annex C (informative): Deployment Architecture Examples . 33
C.1 Introduction . 33
C.2 Examples . 33
C.2.1 eLSA Controller in the VSP domain . 33
C.2.2 eLSA Controller outside the VSP domain . 33
C.2.3 eLSA Controller connecting to multiple eLSA Repositories . 33
C.2.4 eLSA Controller for multiple MFCNs in VSP domain . 34
C.2.5 Proxy eLSA Controller . 34
History . 36

ETSI
5 ETSI TS 103 652-2 V1.1.1 (2020-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Reconfigurable Radio Systems
(RRS).
The present document is part 2 of a multi-part deliverable. Full details of the entire series can be found in part 1 ETSI
TS 103 652-1 [1].
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI
6 ETSI TS 103 652-2 V1.1.1 (2020-01)
1 Scope
The present document specifies the system architecture for the operation of an Evolved Licensed Shared Access (eLSA)
System, enabling the provision of spectrum access to many local high-quality wireless networks in dedicated licensed
and leasing scenarios.
The eLSA system architecture specification will include the identification and definition of the logical functional
elements, interfaces, reference points, the mapping of functions to logical entities as well as the definition of the high-
level procedures and information flows enabling assignment and handling of spectrum for the different scenarios
considered.
The present document has been developed following, and in accordance with, the system requirements for eLSA
captured in ETSI TS 103 652-1 [1] and the feasibility study on temporary spectrum access for local high-quality
wireless networks as documented in ETSI TR 103 588 [i.1].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 103 652-1: "Reconfigurable Radio Systems (RRS); evolved Licensed Shared Access
(eLSA); Part 1: System requirements".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document, but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 588: "Reconfigurable Radio Systems (RRS); Feasibility study on temporary
spectrum access for local high-quality wireless networks".
[i.2] ETSI TS 103 235: "Reconfigurable Radio Systems (RRS); System architecture and high level
procedures for operation of Licensed Shared Access (LSA) in the 2 300 MHz - 2 400 MHz band".
[i.3] ECC Recommendation (15)04: "Guidance for the implementation of a sharing framework between
MFCN and PMSE within 2300-2400 MHz".
[i.4] CEPT Report 58: "Technical sharing solutions for the shared use of the 2300-2400 MHz band for
WBB and PMSE".
ETSI
7 ETSI TS 103 652-2 V1.1.1 (2020-01)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
allowance zone: geographical area within which an eLSA Licensee is allowed to operate radio transmitters on its
assigned spectrum resource
NOTE 1: An allowance zone is defined using specific measurement quantities and thresholds, e.g. a maximum field
strength level expressed in dBµ V/m/MHz, along the border of its geographical area.
NOTE 2: An allowance zone is normally applicable for a defined frequency range and time period.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP Third Generation Public Private Partnership
AV Audio-Visual
AV-VSP Audio-Visual Vertical Sector Player
DOM Detached Operation Mode
eLC evolved eLSA Controller
eLR evolved LSA Repository
eLSA evolved Licensed Shared Access
eLSR evolved LSA Spectrum Resource
eLSRAI evolved LSA Spectrum Resource Availability Information
IEM In Ear Monitoring
LC LSA Controller
LR LSA Repository
LSA Licensed Shared Access
LSRAI LSA Spectrum Resource Availability Information
MFCN Mobile/Fixed Communication Network
NOTE: MFCN is used in the present document to refer to a local high-quality wireless network [i.1].
MNO Mobile Network Operator
NRA National Regulatory Authority
PMSE Programme Making and Special Events
VSP Vertical Sector Player
4 eLSA supported spectrum access schemes
4.1 Introduction
ETSI TR 103 588 [i.1] concept identified three spectrum access schemes for MFCN operated by vertical sector
operators (aka local high-quality wireless networks):
• Local area licensing: NRA provides a license to a vertical sector player to operate in a given frequency
allocation in a defined area and for a defined period of time. The vertical sector player (licensee) shall apply
the required operational conditions and restrictions established by the NRA.
ETSI
8 ETSI TS 103 652-2 V1.1.1 (2020-01)
• Local area Leasing: Incumbents (including MNOs) can lease out part of their licensed spectrum to vertical
sector players (lessees) to operate MFCNs in a defined area and for a defined period of time. An Incumbent
(lessor) and a vertical sector player (lessee) agrees through a leasing arrangement, where the existing rules and
operational conditions given in the incumbent's license is included (the incumbent is still responsible for the
fulfilment of those rules/conditions to the NRA). The leasing arrangement can include additional operational
conditions and restrictions for the use of the leased spectrum. An additional license for vertical sector players
is not needed.
• Network as a Service: MFCNs of a vertical sector player are instantiated as local network service areas
(e.g. network slices of a 3GPP network) within the incumbent (e.g. MNO) domain. The incumbent as license
holder offers infrastructure, spectrum and coexistence management service to the MFCNs. An additional
license for vertical sector players is not needed.
Figure 1 illustrates the relationships between the National Regulatory Administration (NRA), the vertical sector player,
and the incumbent (e.g. MNO) for the different spectrum allocation and service provisioning schemes.

Figure 1: Relationship models for eLSA spectrum access schemes.
eLSA aims to evolve the LSA architecture [i.2] to satisfy the local area spectrum demands covering both short-term and
long-term allocations of vertical sector players. In doing so, eLSA targets a system architecture as close as possible to
LSA maximizing synergies at both implementation and regulatory levels.
Annex C provides for two of the spectrum access schemes identified in [i.1], local area licensing and local area leasing,
an architectural instantiation of eLSA, the associated functionality and a list of the technical evolvements compared to
the LSA reference architecture model [i.2]. The Network as a Service option will not be further specified in the present
document as it is handled within the license holder domain.
4.2 eLSA Architecture Reference Model
4.2.0 introduction
The eLSA Architecture Reference model is shown in Figure 2. It is based on the architecture reference model for LSA
defined in [i.2] and supports additionally the spectrum access schemes for local area licensing and the local area leasing.
Reference points shown in dashed format indicate that the respective interfaces and corresponding interface functions
will not be defined in the present document, although some guidance is provided.
ETSI
9 ETSI TS 103 652-2 V1.1.1 (2020-01)

Figure 2: eLSA Architecture Reference Model
4.2.1 Logical Elements
eLSA Repository (eLR): The eLR supports the entry and storage of information describing the shared spectrum
resources as well as Incumbent's and VSP's usage and protection requirements. It is able to convey spectrum resource
information including related availability information to eLSA Controllers. The eLR also provides means for the NRA
to monitor the operation of the eLSA System [see ETSI TS 103 652-1 [1]] and to provide the eLSA System with
information on local area licensing and local area leasing. The eLR ensures that the eLSA system operates in
conformance with the Sharing Framework and the licensing regime and may in addition realize any non-regulatory
details of the Sharing Arrangement [1].
eLSA Controller (eLC): The eLC is associated with the VSP's domain. The eLC enables the VSP to obtain eLSA
spectrum resource and availability information from the eLR. The eLC interacts with the VSP's MFCN in order to
support the mapping of spectrum resource and availability information into appropriate radio transmitter configurations
and receive the respective confirmation from the MFCN.
4.2.2 Reference Points
eLSA : Reference point between eLR and eLC.
eLSA : Reference point for Administration/NRA interaction with the eLR. Some of the functionality
associated with this reference point is described in clause B.2.
eLSA : Reference point for Incumbent interaction with the eLR. Some of the functionality associated with
this reference point is described in clause B.3.
eLSA : Reference point between eLC and MFCN.
eLSA : Reference point for VSP interaction with the eLR. Some of the functionality associated with this
reference point is described in clause B.4.
4.3 High-Level Functions
4.3.0 introduction
This clause lists and describes the high-level functions performed by the eLSA System. The high-level functions cover
the aspects of eLSA System operation in line with requirements of ETSI TS 103 652-1 [1].
ETSI
10 ETSI TS 103 652-2 V1.1.1 (2020-01)
4.3.1 Information Entry Function
The information entry function allows the entry and storage of information that is needed for the operation of the eLSA
System, including the following:
• Sharing Framework information (set of sharing rules or sharing conditions for the band, information on
spectrum that can be made available for shared use and the corresponding technical and operational conditions
for its use, identification of incumbents).
• eLSA License and Leasing information (VSP identity and related information).
• Sharing Arrangement information for each Incumbent and VSP (set of practical details for sharing an eLSA
spectrum resource, whereby eLSA spectrum resource may be used by Incumbent or VSP).
• Incumbent's eLSA spectrum resource usage and protection requirements.
• The function also supports the verification of inputs (consistency with Sharing Framework/Arrangement).
4.3.2 Information Processing Function
This function supports the derivation of eLSRAI for each VSP domain, to be provided to the Information Exchange
function and the Reporting Function. The eLSRAI is derived based on the data collected by the Information Entry
Function. The function further supports the processing of VSP domain acknowledgment information.
The above functionality also includes support for multiple Incumbents and multiple VSP domains, scheduled and
on-demand modes of operation, and logging of processing information.
4.3.3 Information Mapping Function
The information mapping function receives eLSRAI, confirms reception and initiates respective operations in the
MFCN. It also sends acknowledgements to the information exchange function (for forwarding to the information
processing function) when changes in the MFCN are processed.
NOTE: The respective interaction with the MFCN is out of scope of the present document.
4.3.4 Reporting Function
The reporting function is responsible to create and provide reports regarding the eLSA System operation to
Administration/NRA, Incumbent(s), and/or VSP(s) on an on-demand or scheduled basis, e.g. pre-checking of spectrum
resource availability for a local area.
4.3.5 eLSA Information Exchange Function
The information exchange function supports communication mechanisms, internal to the eLSA System, to exchange
spectrum resource and availability information, and related acknowledgement information.
4.3.6 System Support Functions Group
The system support functions comprise:
Security Support Function: support of authentication and authorization as well as services to support integrity and
confidentiality of data.
Robustness and Reliability Function: support of mechanisms to maintain robustness and reliability against failures
and malicious attacks.
Fault Management Function: support of:
• Failure detection in the eLSA System.
• Subsequent generation and delivery of respective failure notification(s) to VSP(s) and Incumbent(s).
ETSI
11 ETSI TS 103 652-2 V1.1.1 (2020-01)
• Initiation of respective operations in the eLSA System.
4.3.7 System Management Functions Group
This includes:
• Operation, administration and maintenance tasks in the eLSA System.
• Identity management (comprising user identity and authentication management, and user authorization
profiles).
System management is separate for eLR and eLC since these logical entities belong to different operation domains. The
supported functionality may also be different in the two entities. Identity management applies to the eLR only.
4.4 Mapping of High-Level Functions to Logical Elements
Figure 3 shows how the high-level functions and function groups are mapped to the logical entities eLR and eLC.

Figure 3: Mapping of high-level functions and function groups to logical elements
The System Support functions group may be considered to map across all elements and reference points of the eLSA
System.
The corresponding functionality at the eLSA reference point is covered by the eLSA Information Exchange function
and the System Support functions group.
5 eLSA Functional Description and Information Flows
5.1 Introduction
This clause describes procedures, procedural flows and additional functional aspects related to the interface between
eLR and eLC (eLSA interface).
The eLSA interface provides support for the exchange of eLSA Spectrum Resource Availability Information (eLSRAI,
clause 5.4.2) and respective acknowledgement information between eLR and eLC, and for maintaining and recovering
synchronization of such information between eLR and eLC.
ETSI
12 ETSI TS 103 652-2 V1.1.1 (2020-01)
As described in [1], VSPs may want to operate and control their local MFCNs in a detached mode, i.e. without a
permanent network connection to the eLSA System. The procedures and procedural flows listed below supports when a
VSP is operating in detached mode.
NOTE 1: It is expected that either the individual right of use, the sharing framework and/or the spectrum sharing
arrangement contain details on the procedure and periodicity for network reconnection between the eLR
and a VSP operating in detached mode.
NOTE 2: The start and end of the Detached Operation Mode will be signalled from the eLC to the eLR. The details
which procedures to be used will be specified in stage 3.
5.2 Protocol Stacks
The eLSA application layer protocol shall ensure the application part, in eLR and eLC, conforms to the regulatory
requirements, thereby the requirements on underlying transport protocols are kept to minimum. Supported network
layer protocol is IP. No eLSA specific requirement is set on the transport layer protocol.
NOTE: Supported Transport layer mechanisms include TCP and UDP. Depending on the security requirements,
use of IPsec, TLS or DTLS may be applicable.
5.3 eLSA Interface Management Functions
The eLSA Interface shall provide Management functions and corresponding procedures to ensure means for a defined
start of interface operation and means to identify application or protocol failure.
The node that initiates a particular procedure is responsible for supervising the overall procedure status and detecting
corresponding failures. In case of failure (e.g. the respective response message is not received, or the response message
is not valid), the action taken is unspecified and left for implementation. A typical behaviour would be to re-initiate the
procedure a number of times, before further recovery action is invoked.
If failures occur during procedures concerned with exchange of eLSRAI, the supervising node may consider that
synchronization has been lost between eLC and eLR and should initiate actions to restore eLSRAI synchronization. The
protocol should ensure that eLSRAI is consistent in both nodes.
5.4 eLSA Protocol Elements
5.4.1 Identities
The following defines identities that shall be employed by the eLSA System in general, and particularly over the eLSA
interface:
• VSP Identity: identifies a specific VSP.
• eLR Identity: identifies a specific eLR.
• eLC Identity: identifies a specific eLC.
VSP Identity, eLR Identity and eLC Identity shall be unique and unambiguous within a particular set of interconnected
eLSA network elements (for example, multiple eLCs of the same or different VSP(s) connected to an eLR).
Transaction Identity: identifies a specific instance of a procedure, and all messages within the same procedure
instance shall include the same Transaction Identity. The node initiating the procedure shall assign a Transaction
Identity which is not currently used by any other procedure initiated by the same node.
5.4.2 eLSA Spectrum Resource Availability Information
The eLSA Spectrum Resource Availability Information (eLSRAI) is conveyed to the eLC in messages originated in the
eLR (e.g. eLSRAI Notification message, see clause 5.5.5).
ETSI
13 ETSI TS 103 652-2 V1.1.1 (2020-01)
Under normal operating conditions, the eLR is aware of the eLSRAI that is known to the eLC, and stores relevant
associated information such as status of eLC acknowledgements. After successful registration of the eLC at the eLR,
eLSA operation starts in order to synchronise eLSRAI of eLR with the eLC.
In scenarios where the evolved LSA spectrum resource eLSR needs to be granted according to a license or a lease, the
frequency resources, radio conditions, local area definition and validity time information are included in the relevant
eLSRAI.
eLR and eLC should take steps to ensure that valid and relevant eLSRAI will always be synchronized, especially with
respect to eLSRAI handling for detached operation.
eLSRAI may be associated with a validity time when received by the eLC. When the validity time expires, the eLC
shall consider that the associated eLSRAI is no longer applicable and may initiate actions to obtain updated eLSRAI.
eLSRAI includes support for the definition of exclusion, restriction, protection and allowance zones (as per
requirements R-FUNC-INC-05 and R-FUNC-INC-06, R-FUNC-GEN-17 in ETSI TS 103 652-1 [1]).
NOTE 1: Examples of exclusion and protection zone parameters are contained in ECC Recommendation
(15)04 [i.3] and in CEPT Report 58 [i.4]
NOTE 2: The eLSRAI format may include further definitions and support future extensions in order to enable the
evolution of sharing rules, or the needs of particular deployments.
5.5 High Level Procedures
5.5.1 Introduction
This clause specifies high level procedures which describe the interaction between eLR and eLC in normal operation.
Some procedures imply the reconfiguration of the VSP's network through the interaction between the eLSA System and
the MFCN. These procedures, how they apply, and the related lead, latency and response times are expected to be in
accordance with the Sharing Framework and the Sharing Arrangement(s), and constrained by the VSP network
reconfiguration performance.
In case of encountered failure during execution of a high-level procedure, such as a missing response or
acknowledgement message, the initiating node in general is in charge of supervising the execution of the procedure and
initiating the respective failure measure. The content of the failure handling is specific for each high-level procedure.
General aspects of the failure management for eLSA are treated in clause 6.
5.5.2 Registration Procedure
The purpose of the registration procedure is to register an eLC with an eLR. This is the first procedure executed on the
eLSA interface. After successful completion of this procedure, the eLC is able to initiate requests or receive
notifications on eLSRAI.
ETSI
14 ETSI TS 103 652-2 V1.1.1 (2020-01)

Figure 4: Registration Procedure
1) The eLC sends a registration request message to the eLR, including its node identity and VSP identity,
requesting establishment of application protocol communication.
2) The eLR checks the validity of the identities and stores the eLC node identity in the list of registered eLCs.
3) The eLR sends a registration response message to the eLC including its node identity to confirm the registration
of eLC in eLR, and the indication whether the next information exchange is started by eLR or triggered by
request from eLC.
Upon reception of the registration response, the eLC stores the eLR node identity and considers itself registered to the
eLR. For obtaining the initial eLSRAI, the eLC proceeds according to the indication sent by the eLR, e.g. awaiting
eLSRAI notification from the eLR or sending a respective request message, e.g. eLSRAI Request or eLSR Grant
Request to the eLR.
5.5.3 Deregistration Procedure
The purpose of the eLC-initiated Deregistration procedure is to allow an eLC to deregister with an eLR. After
successful completion of this procedure, the eLC can close its connectivity with eLR. To re-establish the dialogue with
eLR, eLC shall proceed with a Registration Procedure (see clause 5.5.2).

Figure 5: Deregistration Procedure
ETSI
15 ETSI TS 103 652-2 V1.1.1 (2020-01)
1) The eLC sends a Deregistration Request message to the eLR, including its node identity and the VSP identity
the eLC belongs to.
2) The eLR checks the validity of both identities, terminates any ongoing procedures and removes the eLC node
identity from the list of registered eLCs.
3) The eLR sends a Deregistration Response message to the eLC, including its node identity, to confirm the
deregistration of eLC in eLR. From this point in time the eLC can close its connectivity with eLR.
5.5.4 eLSR Grant Procedure
The purpose of the eLSR Grant procedure is to enable the eLC to request a grant for an eLSR. The grant is provided as
eLSRAI containing Allowance Zone information. The procedure is used to synchronize eLSRAI between eLR and eLC
for the eLSA supported spectrum access schemes.

Figure 6: eLSR Grant Procedure
1) The eLC sends an eLSR Grant Request message to the eLR.
2) The eLR checks the consistency of the eLC request, marks respective eLSR as granted, and builds the relevant
eLSRAI including the allowance zone information.
3) The eLR sends an eLSR Grant Response message including information on the current eLSRAI, such as
spectrum, geographical area and timing and respective restrictions. The eLSRAI may include e.g. associated
information resulting in immediate, delayed or periodic actions.
5.5.5 eLSR Grant Relinquishment Procedure
The purpose of the eLSR Grant Relinquishment procedure is to enable the eLC to relinquish grants for eLSR. The
procedure is used to release a granted eLSR before the grant time expires.
ETSI
16 ETSI TS 103 652-2 V1.1.1 (2020-01)

Figure 7: eLSR Grant Relinquishment Request Procedure
1) The eLC sends an eLSR Grant Relinquishment Request message to the eLR.
2) The eLR checks the consistency of the eLC request, releases the eLSR, and builds the resulting eLSRAI
including the new allowance zone information.
3) The eLR sends an eLSR Grant Relinquishment Response message including information on the current
eLSRAI, such as spectrum, geographical area and timing and respective restrictions. The eLSRAI may include
e.g. associated information resulting in immediate, delayed or periodic actions.
5.5.6 eLSRAI Request Procedure
The purpose of the eLSRAI Request procedure is to enable the eLC to request an eLSRAI. The procedure is used to
synchronize eLSRAI between eLR and eLC.

Figure 8: eLSRAI Request Procedure
1) The eLC sends an eLSRAI Request message to the eLR.
2) The eLR checks the consistency of the eLC request and builds the relevant eLSRAI.
3) The eLR sends an eLSRAI Response message including information on the current eLSRAI. The eLSRAI may
include e.g. associated information resulting in immediate, delayed or periodic actions.
ETSI
17 ETSI TS 103 652-2 V1.1.1 (2020-01)
5.5.7 eLSRAI Notification Procedure
The purpose of the eLSRAI Notification procedure is to enable the eLR to send eLSRAI to the eLC. It can be used to
send either specific immediate notifications or periodic updates to the eLC.

Figure 9: eLSRAI Notification Procedure
1) The eLR sends an eLSRAI Notification message to the eLC containing eLSRAI. The eLSRAI may include
e.g. associated information resulting in immediate, delayed or periodic actions.
2) The eLC checks the consistency of the eLSRAI notification, and initiates respective actions related to the
received eLSRAI.
3) The eLC responds with an eLSRAI Notification Acknowledgement message to confirm the reception of
eLSRAI.
5.5.8 eLSRAI Confirmation Procedure
The purpose of the eLSRAI Confirmation Procedure is for the eLC to notify the eLR once the necessary configuration
changes in the MFCN have been applied according to the eLSRAI provided by the eLR.

Figure 10: eLSRAI Confirmation Request Procedure
ETSI
18 ETSI TS 103 652-2 V1.1.1 (2020-01)
1) The eLC sends an eLSRAI Confirmation Request message to the eLR to confirm successful execution of
configurations of eLSA spectrum resources in the MFCN according to received eLSRAI.
2) The eLR processes the eLSRAI Confirmation Request and stores the confirmation.
3) The eLR acknowledges the reception of the eLSRAI confirmation by sending an eLSRAI Confirmation
Response message to the eLC.
NOTE: under detached operation scheduled confirmation is possible.
5.5.9 Connectivity Check Notification Procedure
The eLR-initiated Connectivity Check procedure allows the eLR to test the connectivity with any registered eLC. The
procedure can be invoked at any time after Registration Procedure and throughout the lifetime of the eLC registration,
and on specific events and/or on periodic basis. However, the eLR may take into account previous successful
Connectivity Check procedures initiated by eLC when deciding whether to perform a Connectivity Check procedure at
a certain time.
Figure 11: Connectivity Check Notification Procedure
1) The eLR sends a Connectivity Check Notification message to the eLC.
2) Upon reception of the Connectivity Check Notification, the eLC checks the consistency of the information
provided.
3) If consistency check is successful, the eLC will respond with a Connectivity Check Notification
Acknowledgement message to confirm the reception of Connectivity Check Notification.
The Connectivity Check procedure works at application layer and does not preclude other connectivity checks from
lower protocol layers.
5.5.10 Con
...