ETSI TS 103 379 V1.1.1 (2017-01)
Reconfigurable Radio Systems (RRS); Information elements and protocols for the interface between LSA Controller (LC) and LSA Repository (LR) for operation of Licensed Shared Access (LSA) in the 2 300 MHz - 2 400 MHz band
Reconfigurable Radio Systems (RRS); Information elements and protocols for the interface between LSA Controller (LC) and LSA Repository (LR) for operation of Licensed Shared Access (LSA) in the 2 300 MHz - 2 400 MHz band
DTS/RRS-0146
General Information
Standards Content (Sample)
TECHNICAL SPECIFICATION
Reconfigurable Radio Systems (RRS);
Information elements and protocols for the interface
between LSA Controller (LC) and LSA Repository (LR)
for operation of Licensed Shared Access (LSA)
in the 2 300 MHz - 2 400 MHz band
2 ETSI TS 103 379 V1.1.1 (2017-01)
Reference
DTS/RRS-0146
Keywords
interface, protocol
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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.
© European Telecommunications Standards Institute 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 379 V1.1.1 (2017-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 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 LSA Spectrum Resource Availability Information: Description and Supported Functionality on
LSA . 8
4.1 Introduction . 8
4.2 LSRAI Scope . 8
4.3 LSRAI Definition . 8
4.4 LSRAI Handling Functionality . 9
4.4.1 Introduction. 9
4.4.2 LR Support. 9
4.5 LSRAI Context . 9
4.6 LSRAI Synchronization . 10
4.7 LSRAI Confirmation . 10
4.8 LC Handling of non-impacting Zones . 11
5 LSA Protocol Principles . 11
5.1 Specification Notation . 11
5.2 LSA Protocol Procedures . 11
5.3 Identification of procedures and messages . 12
5.4 Procedure Outcome . 12
5.5 Principles for Protocol Development and Version Interworking . 12
5.6 Message Encoding and IE attributes . 13
5.7 Overview of the protocol specification . 13
6 LSA Protocol: Procedures and Messages . 13
6.1 Registration procedure . 13
6.1.1 General . 13
6.1.2 REGISTRATION REQUEST . 14
6.1.3 REGISTRATION RESPONSE . 14
6.2 Deregistration procedure . 15
6.2.1 General . 15
6.2.2 DEREGISTRATION REQUEST . 16
6.2.3 DEREGISTRATION RESPONSE . 16
6.3 Connectivity Check Notification procedure . 16
6.3.1 General . 16
6.3.2 CONNECTIVITY CHECK NOTIFICATION . 17
6.3.3 CONNECTIVITY CHECK NOTIFICATION ACK . 17
6.4 Connectivity Check Request procedure . 17
6.4.1 General . 17
6.4.2 CONNECTIVITY CHECK REQUEST . 18
6.4.3 CONNECTIVITY CHECK RESPONSE . 18
6.5 LSRAI Notification procedure . 19
6.5.1 General . 19
6.5.2 LSRAI NOTIFICATION . 20
6.5.3 LSRAI NOTIFICATION ACK . 20
6.6 LSRAI Request procedure . 20
6.6.1 General . 20
ETSI
4 ETSI TS 103 379 V1.1.1 (2017-01)
6.6.2 LSRAI REQUEST . 21
6.6.3 LSRAI RESPONSE . 22
6.7 LSRAI Confirmation procedure . 22
6.7.1 General . 22
6.7.2 LSRAI CONFIRMATION REQUEST . 23
6.7.3 LSRAI CONFIRMATION RESPONSE . 23
7 LSA Protocol: Information Elements . 23
7.1 LSRAI . 23
7.2 Zone Description . 24
7.3 Zone Type . 24
7.4 Zone Action . 25
7.5 Frequency . 25
7.6 Radio Constraints . 25
7.6.1 Introduction. 25
7.6.2 Radio Constraints parameters . 25
7.6.3 Radio Constraints profiles . 26
7.7 Space . 26
7.8 Time . 27
7.9 Synchronization Information . 27
7.10 Synchronization Ack Information . 27
7.11 Circle . 27
7.12 Polygon . 28
7.13 Area Descriptor . 28
7.14 Geographical coordinates . 28
7.15 Frequency value . 29
7.16 Periodic . 29
7.17 Aperiodic . 29
7.18 Time . 30
7.19 Day Schedule . 30
7.20 Week Schedule . 30
7.21 Month Schedule . 31
7.22 Year Schedule . 31
7.23 Time of Day . 31
7.24 Time of Week . 32
7.25 Time of Month . 32
7.26 Time of Year . 32
7.27 Confirmed Zone List . 32
7.28 Zone Confirmation . 33
7.29 Zone Configuration Index . 33
7.30 Message Type . 33
7.31 Transaction ID . 34
7.32 LR ID . 34
7.33 LC ID . 34
7.34 Licensee ID . 34
7.35 Result . 34
7.36 Sync ID . 35
7.37 Sync Zone List . 35
7.38 Synched Zone . 35
7.39 Cause . 36
7.40 Zone ID . 37
7.41 Protocol Version List. 38
7.42 Protocol Version . 38
Annex A (informative): Change History . 39
History . 40
ETSI
5 ETSI TS 103 379 V1.1.1 (2017-01)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Reconfigurable Radio Systems
(RRS).
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 379 V1.1.1 (2017-01)
1 Scope
The present document defines the application protocol on the LSA interface, between LSA Controller (LC) and LSA
Repository (LR) [i.2] (LSA protocol), and the content of the LSA Spectrum Resource Availability Information
(LSRAI) conveyed by this protocol. It is based on the System Requirements defined in ETSI TS 103 154 [i.1] and the
System Architecture and High Level Procedures defined in ETSI TS 103 235 [i.2].
The present document supports the operation of mobile broadband service in the 2 300 MHz - 2 400 MHz band under
Licensed Shared Access (LSA), aimed at enabling access for mobile/fixed communication networks (MFCNs) in those
CEPT countries where access to the band is foreseen but cannot be provided without restrictions due to Incumbent
usage, as documented in ETSI TR 103 113 [i.3]. Application to other bands is not precluded and depends on future
regulatory decisions.
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.
Not applicable.
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 TS 103 154: "Reconfigurable Radio Systems (RRS); System requirements for operation of
Mobile Broadband Systems in the 2 300 MHz - 2 400 MHz band under Licensed Shared Access
(LSA)".
[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] ETSI TR 103 113 (V1.1.1): "Electromagnetic compatibility and Radio spectrum Matters (ERM);
System Reference document (SRdoc); Mobile broadband services in the 2 300 MHz - 2 400 MHz
frequency band under Licensed Shared Access regime".
[i.4] ECC Report 205 (February 2014): "Licensed Shared Access (LSA)".
[i.5] CEPT Report 58 (July 2015): "Technical sharing solutions for the shared use of the 2300-
2400 MHz band for WBB and PMSE".
ETSI
7 ETSI TS 103 379 V1.1.1 (2017-01)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
idle zone: zone which has been defined but which is not currently operational
LSA Licensee: entity operating a MFCN, which holds individual rights of use to an LSA spectrum resource
LSA spectrum resource: spectrum resource which is to be shared between an Incumbent and a LSA Licensee on a
static or dynamic basis according to the Sharing Framework defined by the Administration/NRA
LSA spectrum resource availability information: information provided to a Licensee, which conveys the LSA
spectrum resource that may be used by the Licensee, and the respective operational conditions or restrictions
LSRAI context: set of zones and their parameters that are to be maintained by the nodes (LC and LR) in an instance of
the LSA interface
LSRAI synchronization process: process to synchronize the LSRAI context between LC and LR
operational zone: zone to be taken into account by the Licensee, when making use of the LSA spectrum resource
sharing arrangement: set of practical details for sharing an LSA spectrum resource
sharing framework: set of sharing rules or sharing conditions that will materialize the change, if any, in the spectrum
rights of the Incumbent(s) and define the spectrum, with corresponding technical and operational conditions, that can be
made available for alternative usage under LSA
spectrum resource: resource or set of resources defined in time, space and frequency domains
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ACLR Adjacent Channel Leakage power Ratio
ACS Adjacent Channel Selectivity
ECC Electronic Communications Committee of the CEPT
EIRP Equivalent Isotopic Radiated Power
IE Information Element
LC LSA Controller
LR LSA Repository
LSA Licensed Shared Access
LSRAI LSA Spectrum Resource Availability Information
MFCN Mobile/Fixed Communications Network
NRA National Regulatory Authority
PMSE Program Making and Special Events
RF Radio Frequency
UTC Co-ordinated Universal Time
ETSI
8 ETSI TS 103 379 V1.1.1 (2017-01)
4 LSA Spectrum Resource Availability Information:
Description and Supported Functionality on LSA
4.1 Introduction
Clause 4 contains a high level description of the LSA Spectrum Resource Availability Information (LSRAI), and
LSRAI-related functionality supported by the nodes (LC and LR), and the interface (LSA ). This clause expands the
related material in the stage 2 specification of ETSI TS 103 235 [i.2], and describes detailed requirements for the LSA
protocol and its operation.
4.2 LSRAI Scope
LSA Spectrum Resource Availability Information (LSRAI) is information provided to a LSA Licensee, which conveys
information on the LSA spectrum resource that may be used by the LSA Licensee. As described in ETSI
TS 103 235 [i.2], LSRAI is generated in the LR, and sent to the LC over the LSA1 interface, using LSA protocol
messages.
Under LSA operation ECC Report 205 [i.4], it is assumed that the terms of a license will contain a description of the
spectrum resource which is allocated to the respective LSA Licensee, and therefore such information is not required to
be conveyed over LSA as part of LSRAI. LSRAI therefore includes any additional operational conditions or
restrictions that the Licensee shall apply, and which may be subject to change.
NOTE: It is a deployment choice whether permanent restrictions contained in the sharing framework or sharing
arrangement, ETSI TS 103 154 [i.1], are conveyed to the LC as part of LSRAI.
The conditions or restrictions within LSRAI may apply to the licensed spectrum resource, or to a subset (described in
frequency, space, time or a combination of these).
4.3 LSRAI Definition
LSRAI has the following characteristics:
• It contains one or more Zones. A Zone is an information object which describes a set of operational conditions
or restrictions to be applied by the LSA Licensee.
• A Zone has a Zone Type associated to it (e.g. restriction, protection, exclusion).
• A Zone contains space, frequency, radio and time parameters:
- Space parameters describing the geographical area to which the restriction applies.
- Frequency parameters describing the frequency range to which the restriction applies.
- Time parameters describing when the restriction applies.
- Radio parameters describing the RF restrictions to be applied within the space/frequency/time
combination defined by the above parameters.
• A Zone has a Zone ID and a Zone Configuration Index associated to it.
NOTE: When LSRAI is conveyed over the LSA interface, each Zone is associated to a Zone Action.
ETSI
9 ETSI TS 103 379 V1.1.1 (2017-01)
4.4 LSRAI Handling Functionality
4.4.1 Introduction
As described in ETSI TS 103 235 [i.2], the LSA Information Exchange Function supports communication mechanisms
to exchange LSRAI and related acknowledgement information between LR and LC. Clauses 4.4.2 and 4.4.3 further
specify the related functional split between LR and LC in support of this high level function.
4.4.2 LR Support
The LR supports the LSA Information Exchange Function by:
• Constructing zone information including type and parameters for each Zone.
• Assigning a Zone ID, which uniquely identifies a Zone over all instances of the LSA interface for a given LR.
• Assigning a Zone Configuration Index, which uniquely identifies the particular configuration (set of zone
parameters).
• Conveying the zone information towards concerned LCs.
• Monitoring the status of LSRAI conveyed to the LC (e.g. per-zone acknowledgment and confirmation).
• Conveying a modification of Zone parameters towards the LC (with corresponding Zone Configuration Index).
• Conveying deletion of a Zone towards the LC.
• Synchronizing LSRAI with the LC.
4.4.3 LC Support
The LC supports the LSA Information Exchange Function by:
• Receiving and acknowledging LSRAI (including checking of parameters).
• Confirming LSRAI.
• Synchronizing LSRAI with the LR.
4.5 LSRAI Context
The LSRAI Context is the complete set of zones and their parameters that are to be maintained by the nodes (LC and
LR) in an instance of the LSA interface. The LR determines the LSRAI Context and informs the LC of any changes in
the Context due to creation, modification or deletion of zones.
When receiving zone information, the LC shall consider that:
• a zone with a Zone Action set to "Create" is to be added to the LSRAI Context (including its parameters);
• a zone with a Zone Action set to "Modify" is to be kept in the LSRAI Context (including modified parameter
set);
• a zone with a Zone Action set to "Delete" is to be removed from the LSRAI Context.
There is no relationship between the current status of a zone (idle/operational), and whether the zone is part of the
LSRAI Context. The LSRAI Context may therefore include both idle and operational zones at any moment in time.
NOTE: The LR may define a zone in such a way that it is idle (at the time that it is conveyed to the LC), and has
no future idle-operational transition. During operation of the LSA interface, the LR may modify the time
parameters of the zone such that it will trigger an idle-operational transition at any desired point in time.
ETSI
10 ETSI TS 103 379 V1.1.1 (2017-01)
4.6 LSRAI Synchronization
As described in ETSI TS 103 235 [i.2], see e.g. clause 5.6.4, the LSA Information Exchange Function supports means
for maintaining and restoring LSRAI Synchronization between LR and LC.
In the present document, LSRAI Synchronization is the process by which it is ensured that the LR provides the LSRAI
context to the LC. An LSRAI Synchronization process may be triggered by either LC or LR. The provision of the
LSRAI Context towards the LC uses the LR-initiated LSRAI Notification procedure (clause 6.5). The LSRAI Context
may optionally be segmented over two or more instances of this procedure.
All procedures that are part of an LSRAI Synchronization process shall be identified by a specific synchronization
process identity.
An LSRAI Synchronization process may be used to reset the LSRAI Context at the LC. In the case of LSRAI
Synchronization with context reset, the LC shall immediately replace the LSRAI Context with the newly received
context, and shall consider that all zones in the LSRAI Context require confirmation [i.2]. If no context reset is
requested by the LR, the LC:
• shall use the information received to update the local LSRAI Context at the LC;
• shall consider that any existing zones not included in the received LSRAI Context are implicitly deleted;
• shall consider that confirmations are required for new or modified zones.
Once an LSRAI Synchronization process is initiated, any existing LSRAI-handling procedures shall be considered
terminated. A node receiving an initiating message for a LSRAI-handling procedure while an LSRAI Synchronization
process is ongoing shall fail such procedure with an appropriate cause e.g. "Synchronization ongoing", except if the new
procedure indicates the initiation of a new LSRAI Synchronization process. In this case, the old LSRAI
Synchronization process shall be considered to have been unsuccessfully terminated.
4.7 LSRAI Confirmation
As described in ETSI TS 103 235 [i.2], the LSA Information Exchange Function supports means for the LC to notify
the LR once the necessary configuration changes in the MFCN have been applied according to the received LSRAI.
This process is known as LSRAI Confirmation.
The LC shall explicitly provide confirmation for each zone within the LSRAI Context. Each zone shall be confirmed at
least once. If the configuration of an existing zone is modified, the LC shall consider that a further confirmation is
required for the zone (regardless of whether it had been previously confirmed, and regardless of the modification
details). In order to identify the configuration that is confirmed, the LC shall include both the Zone ID and the Zone
Configuration Index within the confirmation signalling.
If the LC receives a new or modified zone whose time configuration is such that the zone is operational at the time of
reception, the LC shall consider that configurations changes shall be applied, if needed, and the corresponding
confirmation shall be sent to the LR.
In the case of a zone whose time configuration includes multiple operational periods (i.e. scheduled or periodic zones),
the LC shall provide confirmation at least once (in connection with its first operational period), and shall also provide
confirmation after any modification (in connection with the first subsequent operational period after the modification is
received by the LC). The LC is not required to provide confirmation for each idle-operational transition.
Confirmation may also be used by the LC to inform the LR that the configuration changes cannot be implemented
("negative confirmation").
NOTE: Confirmation messages may be sent by the LC more than once for a given combination of Zone ID and
Zone Configuration Index (e.g. in the case of scheduled or periodic zones, an initial positive confirmation
is sent by the LC; later the MFCN is not able to comply with a subsequent operational period, and a
negative confirmation is sent). In all cases, the confirmation status of the last received message overwrites
any previously received information.
For a particular zone, the time when the respective confirmation is sent depends on the timing of the required idle-
operational transition for the zone, the timing of the change of configuration, and any associated requirements specific
to the Sharing Framework or Sharing Arrangement.
ETSI
11 ETSI TS 103 379 V1.1.1 (2017-01)
Protocol confirmation messages support simultaneous confirmation of multiple zones. The multiplexing of zone
confirmations is independent of the multiplexing of zones (and respective information) as previously sent by the LR
towards the LC.
4.8 LC Handling of non-impacting Zones
The LC may receive a zone configuration such that the LC has identified that no MFCN resource is impacted by the
zone. The LC shall however consider that the zone (and its information) forms part of the LSRAI Context.
The LC shall also act as if the necessary configuration changes have been applied, by sending an associated
confirmation for any such zone towards the LR.
5 LSA Protocol Principles
5.1 Specification Notation
For the purposes of the present document, the following notations apply:
Procedure When referring to an elementary procedure in the specification the Procedure Name is written with
the first letters in each word in upper case characters followed by the word "procedure",
e.g. LSRAI Notification procedure.
Message When referring to a message in the specification the MESSAGE NAME is written with all letters
in upper case characters followed by the word "message", e.g. LSRAI NOTIFICATION ACK
message.
IE When referring to an information element (IE) in the specification the Information Element Name
is written with the first letters in each word in upper case characters and all letters in Italic font
followed by the abbreviation "IE", e.g. Space IE.
Value of an IE When referring to the value of an information element (IE) in the specification, the value is written
enclosed by quotation marks, e.g. "Value".
5.2 LSA Protocol Procedures
The LSA protocol procedures are classified in the following categories:
1) LSRAI handling Procedures
2) Interface management procedures
The LSRAI handling procedures are those procedures whose primary function is to convey LSRAI, or to exchange
information directly related to the provision of LSRAI (e.g. confirmations).
The interface management procedures are those procedures whose primary function is to set up, maintain or discontinue
an LSA interface instance.
Tables 5.2-1 and 5.2-2 show the procedures and messages for each category:
Table 5.2-1: LSRAI Handling Procedures
LSA Protocol Procedure Initiating Message Response Message
LSRAI Notification LSRAI NOTIFICATION LSRAI NOTIFICATION ACK
LSRAI Request LSRAI REQUEST LSRAI RESPONSE
LSRAI Confirmation LSRAI CONFIRMATION REQUEST LSRAI CONFIRMATION RESPONSE
ETSI
12 ETSI TS 103 379 V1.1.1 (2017-01)
Table 5.2-2: Interface Management Procedures
LSA Protocol Procedure Initiating Message Response Message
Registration REGISTRATION REQUEST REGISTRATION RESPONSE
Deregistration DEREGISTRATION REQUEST DEREGISTRATION RESPONSE
Connectivity Check Notification CONNECTIVITY CHECK CONNECTIVITY CHECK
NOTIFICATION NOTIFICATION ACK
Connectivity Check Request CONNECTIVITY CHECK REQUEST CONNECTIVITY CHECK RESPONSE
5.3 Identification of procedures and messages
Each message defined in the LSA protocol (as listed in the tables of clause 5.2) includes a specific Message Type IE,
allowing the receiver to identify the general procedure and message.
Each procedure instance is identified by a Transaction ID IE, which is mandatory in all messages of the LSA protocol.
The value of this IE is set by the node that initiates the procedure, and the same value shall be used by the responding
node in the response message. The initiating node shall not assign this value to a new procedure during the period of
execution of the original procedure.
5.4 Procedure Outcome
The node that receives the initiating message shall process the message and its IEs according to the requirements in
clauses 6 and 7, and shall include in the response message an indication of whether it considers the procedure to be
successful or unsuccessful.
The node that initiates the procedure shall also consider the procedure to be unsuccessful if it receives an unsuccessful
indication from the receiver node, and in addition it may consider the procedure to be unsuccessful according to criteria
such as:
• lack of response message after an implementation-dependent timer;
• response message indicates success, but IEs in the response message contain errors or are inconsistent with
successful processing.
Subsequent to a procedure failure, the action from the initiating node is generally implementation dependent, except
where specified in the present document or in ETSI TS 103 235 [i.2].
5.5 Principles for Protocol Development and Version
Interworking
The LSA protocol may be further developed in future specifications. Each new version will be distinguished by a
version number. Protocol versions shall be sequentially numbered starting with V1 defined in the present document.
Table 5.5-1 provides the relationship between versions and specifications.
Table 5.5-1: Relationship between LSA protocol versions and respective ETSI specifications
Version Number ETSI Specification
Version 1 ETSI TS 103 379 (V1.1.1)
Backward compatibility between protocol versions shall not be guaranteed. A protocol peer supporting Version N of the
protocol may (but is not mandated to) support lower numbered versions of the protocol (N-1, N-2, etc.). Interworking
between protocol peers is based on explicitly negotiating the protocol version to be used in the specific LSA instance.
This negotiation takes place during the Registration procedure. During this procedure:
• The LC provides a list of supported versions in the initial REGISTRATION REQUEST message.
ETSI
13 ETSI TS 103 379 V1.1.1 (2017-01)
• The LR responds with the version to be used thereafter, selected from the list provided by the LC.
In order to enable that implementations provide support to multiple protocol versions, the following principles shall be
applied concerning the development of the LSA protocol:
• All messages in a particular protocol version shall be present in a higher numbered protocol version.
• All IEs in a particular message of a particular protocol version shall be present in the same message in a higher
numbered protocol version.
5.6 Message Encoding and IE attributes
The message encoding is not specified in the present document.
Definitions of the messages and respective information elements are provided including presence, type and range for
each IE, in order to enable translation into any particular encoding format.
For example:
1) The presence of the IE in a message is defined as either mandatory (M), optional (O) or conditional (C). In the
latter case, a condition is provided (e.g., "if the procedure is successful").
2) The type of IEs include standard types used in abstract notation such as INTEGER and ENUMERATED.
5.7 Overview of the protocol specification
Clauses 6 and 7 provide the detailed specification of the LSA protocol, as follows.
Clause 6 documents for each procedure:
1) The format of each message in the procedure, including:
a) List of IEs in each message.
b) Presence of the IE in the message.
c) Type of the IE and range (if applicable).
d) Description of the IE.
2) The behaviour of the nodes with respect to transmission and reception of the respective messages, and in
relation to the values or presence of specific IEs (including conditions under which procedures are to be
considered successful or unsuccessful).
Clause 7 provides a detailed tabular representation of IEs.
6 LSA Protocol: Procedures and Messages
6.1 Registration procedure
6.1.1 General
The purpose of the Registration procedure is to register an LC with an LR. This is the first procedure executed on the
LSA interface. After successful completion of this procedure, the LC is able to initiate requests or receive notifications
concerning LSRAI.
ETSI
14 ETSI TS 103 37
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...