ETSI EN 303 146-4 V1.1.2 (2017-04)
Reconfigurable Radio Systems (RRS); Mobile Device (MD) information models and protocols; Part 4: Radio Programming Interface (RPI)
Reconfigurable Radio Systems (RRS); Mobile Device (MD) information models and protocols; Part 4: Radio Programming Interface (RPI)
REN/RRS-0214
Reconfigurable Radio Systems (RRS) - Mobile Device Information Models and Protocols - Part 1: Multiradio Interface (MURI)
Radijski sistemi z možnostjo preoblikovanja (RRS) - Informacijski modeli in protokoli za mobilne naprave (MD) - 4. del: Radijski programski vmesnik (RPI)
Področje uporabe tega dokumenta zajema opredelitev radijskega programskega vmesnika (RPI) za mobilne naprave z možnostjo preoblikovanja. Delo temelji na primerih uporabe, opredeljenih v standardu ETSI TR 102 944 [i.1], sistemskih zahtevah,
opredeljenih v standardu ETSI EN 302 969 [1], ter preoblikovanju radia glede na arhitekturo za mobilne naprave, opredeljeno v standardu ETSI EN 303 095 [i.2]. Poleg tega ta dokument dopolnjuje informacijske modele in protokole za mobilne naprave, ki se nanašajo na večradijski vmesnik iz standarda ETSI EN 303 146-1 [i.3], spremenljivi radiofrekvenčni vmesnik iz standarda ETSI EN 303 146-2 [i.4] in enotni radijski aplikacijski vmesnik iz standarda ETSI EN 303 146-3 [i.5].
General Information
Standards Content (Sample)
Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Mobile Device (MD) information models and protocols;
Part 4: Radio Programming Interface (RPI)
2 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Reference
REN/RRS-0214
Keywords
architecture, mobile, radio, SDR, software,
system
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 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Introduction . 8
5 System Requirement Mapping . 9
6 Radio Virtual Machine specification . 10
6.1 Concept of RVM . 10
6.2 Elementary RVM (eRVM) . 11
6.3 RVM Hierarchy . 15
6.4 Data types . 16
6.4.1 Types and Values . 16
6.4.2 Run-Time Data . 16
6.5 Arithmetic. 17
6.6 Exceptions . 17
6.7 Control, Synchronization and Execution . 17
6.8 Operations with Memory . 18
6.9 RVM run-time environment . 18
7 Configcodes for RVM . 18
7.0 Introduction . 18
7.1 Configcodes generation . 18
7.2 Binary format for Configcodes . 20
7.3 XML schema for Configcodes . 23
8 Radio Library . 29
8.0 Introduction . 29
8.1 Reference Radio Library . 30
8.2 Native Radio Library . 31
9 Loading, Linking and Initialization . 31
10 Compiling for RVM (Front-End Compilation) . 32
Annex A (informative): Mapping between XML and Binary . 33
Annex B (informative): SFB Candidate . 34
Annex C (informative): Replacement of selected components of an existing RAT . 36
Annex D (informative): Introducing new SFBs . 37
History . 38
ETSI
4 Draft ETSI EN 303 146-4 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 draft European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio
Systems (RRS), and is now submitted for the combined Public Enquiry and Vote phase of the ETSI standards EN
Approval Procedure.
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.3].
Proposed national transposition dates
Date of latest announcement of this EN (doa): 3 months after ETSI publication
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 6 months after doa
Date of withdrawal of any conflicting National Standard (dow): 6 months after doa
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
5 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
1 Scope
The scope of the present document is to define the Radio Programming Interface (RPI) for mobile device
reconfiguration. The work is based on the Use Cases defined in ETSI TR 102 944 [i.1], on the system requirements
defined in ETSI EN 302 969 [1] and on the radio reconfiguration related architecture for mobile devices defined in
ETSI EN 303 095 [i.2]. Furthermore, the present document complements the mobile device information models and
protocols related to the Multiradio Interface ETSI EN 303 146-1 [i.3], to the Reconfigurable Radio Frequency Interface
ETSI EN 303 146-2 [i.4] and to the Unified Radio Application Interface ETSI EN 303 146-3 [i.5].
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 EN 302 969 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
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 102 944: "Reconfigurable Radio Systems (RRS); Use Cases for Baseband Interfaces for
Unified Radio Applications of Mobile Device".
[i.2] ETSI EN 303 095 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Architecture for Mobile Devices".
[i.3] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device Information Models
and Protocols; Part 1: Multiradio Interface (MURI)".
[i.4] ETSI EN 303 146-2 : "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.5] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
6 Draft ETSI EN 303 146-4 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:
Abstract Processing Element (APE): abstracts computational resource that executes any computations downloaded
from Radio Library
NOTE: APE is connected with input and output DOs. APE is reactive. Any computations are started if all input
DOs are filled with real data.
basic operations: operations either provided by the Radio Library and/or UDFB Set to eRVM or by the Radio Library
and/or RVM/eRVM Configcodes to RVM
NOTE: Each Basic Operation is mapped to a corresponding APE in the case of eRVM or mapped to a
corresponding APE or RVM/eRVM in the case of RVM.
data flow chart: reactive data flow computational model consisting of data and operators where data are connected
with operators
NOTE: Operators abstract computations. They are triggered by full data. Results of operator computations are
written in connected output data if they are empty.
Data Object (DO): typeless token abstracting any type of data
NOTE: DO provides a container for storing data. It can be empty if no data in the container or it can be full if
there is data in the container. DO is allocated in the infinite and flat memory. Any RVM has access to this
memory. One or a few APEs from RVM can be connected with DO. DO acknowledges connected APEs
about its status whether it empty or full.
dynamic operation: operation that is performed by allocating the computational resources during run-time for each
APE required executing the given operation
NOTE 1: The resources are deallocated upon completion of the corresponding operation
NOTE 2: Dynamic operation is available only in the case of MDRC-7 defined in ETSI EN 302 969 [1]. In other
words, dynamic operation is needed when RA requires the dynamic resource sharing.
native radio library: library providing platform-specific description of each SFB that represents the target platform
hardware
port configuration: specification of the number of APEs inputs and outputs
radio library authority: authority empowered to decide which components can be registered as new SFBs
NOTE: Any suitable organization can take the role of a Radio Library Authority. The choice of the organization
is beyond the scope of the present document.
reference radio library: library providing normative definition of each SFB
NOTE: There may be multiple such Reference Radio Libraries. For a given RA, a unique Reference Radio
Library is used.
Radio Virtual Machine (RVM): abstract machine that supports reactive and concurrent executions
NOTE: A RVM may be implemented as a controlled execution environment that allows the selection of a trade-
off between flexibility of base band code development and required (re-)certification efforts.
Radio Virtual Machine Runtime Environment (RVM RE): software that allows running Radio Applications that
might be Configcodes or executable codes
ETSI
7 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
terminal operation: operation that will always be executed without any other interruption
NOTE 1: Furthermore, terminal operation cannot be decomposed into smaller operations.
NOTE 2: "Terminal operations" are equivalent to "atomic operations", but additionally it indicates that a hierarchy
is being used in which the "terminal operations" are on the lowest level of hierarchy and they can be part
of another operation.
Software Intermediate Representation (SWIR): RA representation as data flow chart
NOTE: SWIR file contains information on all terminal objects, their parameters (cost, implement function, size,
etc.) and connections (links, access type, source and destination).
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AOT Ahead-Of-Time
APE Abstract Processing Element
ASF Abstract Switch Fabric
BE Back End
CC Configcodes Counter
CSL Communication Services Layer
CU Control Unit
DO Data Object
eRVM Elementary RVM
eSFB Elementary SFB
FB Functional Block
FBRI FB Reusability Index
FFT Fast Fourier Transform
HD Hardware Dimension
HW Hardware
ID Identification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
MD Mobile Device
MURI MUltiRadio Interface
NAF Next Address Flag
NCAO Next Configcode Address Offset
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Runtime Environment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming Interface
RRFI Reconfigurable Radio Frequency Interface
RVM RE RVM Runtime Environment
RVM Radio Virtual Machine
SD Software Dimension
SFB Standard Functional Block
SWIR SoftWare Intermediate Representation
UDFB User Defined Functional Block
UML Unified Modeling Language
URA Unified Radio Applications
URAI Unified Radio Applications Interface
XML eXtensible Markup Language
ETSI
8 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
4 Introduction
A reconfigurable MD is capable of running multiple radios simultaneously and of changing the set of radios by loading
new Radio Application Package (RAP). All Radio Applications (RAs) are called Unified Radio Applications (URAs)
when they exhibit a common behaviour from the reconfigurable MD's point of view [i.2]. In order to run multiple
URAs, the reconfigurable MD will include Communication Services Layer (CSL), Radio Control Framework (RCF),
Radio Platform and 4 sets of interfaces for their interconnection.
Figure 4.1: Four sets of interfaces for Reconfigurable MD
Figure 4.1 illustrates the Reconfigurable MD architecture with the 4 sets of interfaces, i.e.:
• MURI for interfacing CSL and RCF [i.2];
• RRFI for interfacing URA and RF Transceiver [i.3];
• URAI for interfacing URA and RCF [i.2];
• RPI for allowing an independent and uniform production of RAs.
The present document defines RPI.
ETSI
9 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
<>
IMUR I
<>
IRR F I
R adioComput er
<>
IRPI
<>
IUR AI ®
Figure 4.2: UML class diagram for Radio Computer interfaces ®
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable MD may be seen as a
Radio Computer where individual URAs are engineered as software entities [i.2].
The present document is organized as follows:
• Clause 5 describes the system requirement mapping;
• Clause 6 describes the radio virtual machine specification;
• Clause 7 describes the Configcodes for RVM;
• Clause 8 describes the radio library structure;
• Clause 9 describes the load, linking and initialization;
• Clause 10 describes the compiling for RVM;
• Annex A describes the mapping between Binary and XML;
• Annex B describes SFB Candidates;
• Annex C describes the replacement of selected components of an existing RAT. ®
While UML is used for defining the information model and protocol related to RPI, other modelling languages could
be used as well.
5 System Requirement Mapping
The Radio Programming Interface and its related components described in the present document shall support the
system requirements shown in table 5.1 referring to clause 6 of ETSI EN 302 969 [1]. This is achieved by introducing
st
the entities/components/units given in the 1 column of table 5.1.
ETSI
10 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Table 5.1: Mapping of Radio Programming Interface and its related components to
the system requirements described in ETSI EN 302 969 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming Interface R-FUNC-MDR-04 The requirement shall be as described in clause 6.4.4 of ETSI
EN 302 969 [1].
Radio Virtual Machine R-FUNC-MDR-13 The requirement shall be as described in clause 6.4.13 of
ETSI EN 302 969 [1].
R-FUNC-MDR-14 The requirement shall be as described in clause 6.4.14 of
ETSI EN 302 969 [1].
R-FUNC-MDR-15 The requirement shall be as described in clause 6.4.15 of
ETSI EN 302 969 [1].
Radio Library R-FUNC-FB-06 A library extension shall be supported. The requirement shall
be as described in clause 6.3.6 of ETSI EN 302 969 [1].
6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 095 [i.2], the Radio Virtual Machine (RVM) is an Abstract Machine which is capable of
executing Configcodes and it is independent of the hardware. The implementation of a RVM is target Radio Computer
specific and it shall have access to the Back-end Compiler (on the platform itself or externally as described in ETSI
EN 303 095 [i.2], clause 4.4.1) for Just-in-Time (JIT) or Ahead-of-Time (AOT) compilation of Configcodes.
This clause describes the concept of RVM. As mentioned above, the RVM is an abstract machine, which executes a
particular algorithm presented as a data flow chart. In other words, the RVM is the result of replacing all operators and
tokens in the particular data flow chart with Abstract Processing Elements (APEs) and Data Objects (DOs),
respectively. Each APE executes computations marked by the replaced operator identifier. These computations are
taken from the Radio Library.
Figure 6.1 illustrates a conceptual view of RVM processing. This process requires APE, DO and Radio Library, of
which the definitions are as follows:
• APE abstracts a computational resource corresponding to the operation in a particular data flow chart.
• DO abstracts a memory resource. In other words, DO is an abstracted memory for storing data used during the
procedure of Radio processing.
• Reference/Native Radio Library includes normative definitions/native implementation of all Standard
Functional Blocks (SFBs) [i.2] for front-end/back-end compilation. Note that the computations included in the
Radio Library are represented in terms of normative definitions or native implementations of SFBs depending
upon whether the Radio Library is used for front-end or back-end compilation, respectively.
NOTE 1: User Defined Functional Blocks (UDFBs) will be created through combination of SFBs and represented
as a data flow chart to be executed in the RVM. Alternatively, a UDFB is implemented as a stand-alone
module/function which can be mapped:
i) into one APE (i.e. this UDFB can be considered atomic); or
ii) into an eRVM/RVM (i.e. not atomic). UDFBs are not in general included into the Radio Library,
but they are part of the Radio Application Package.
The RVM begins to work immediately after some DOs initialization. All APEs shall execute computations
asynchronously and concurrently. An individual APE shall execute the allocated operator if all the corresponding input
DOs are full. APEs shall access DOs with operations "read" , "read-erase", or "write". After reading input data from
DOs, the APE shall execute the allocated operator and, if output DOs are empty, then the APE shall write processed
data. Any full output DO shall block the corresponding writing operation. The RVM shall execute computations until
reaching the state when all APEs become inactive. In this state, there are not enough full DOs, which can activate the
inactive operators. The result of computations are full DOs, which cannot activate the inactive operators.
ETSI
11 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
NOTE 2: An Output DO can become an Input DO for a subsequent operator. Then, this input DO can activate the
subsequent operator.
NOTE 3: The state or operation of a given APE is independent on the state of other APEs. I.e. each APE is atomic.
Figure 6.1: Conceptual Diagram of Radio Virtual Machine Processing
6.2 Elementary RVM (eRVM)
This clause describes the eRVM which shall consist of components of Basic Operations, Program memory, Control
Unit (CU), Abstract Switch Fabric (ASF) as well as APEs and DOs, of which the definitions are as follows. eRVM shall
not contain another eRVM or RVM.
• Basic Operations shall include operators either provided:
i) from Radio Library as SFBs and/or;
ii) from UDFB set as UDFBs, each of which is mapped onto one single APE.
NOTE 1: Since UDFBs might be implemented as a stand-alone module/function which can be mapped into one
APE, in this case, Basic Operations include operators provided by UDFB Set as well as by Radio Library
as SFBs. Note that those UDFBs are atomic.
NOTE 2: For a RVM, the SFB or UDFB can be mapped onto an APE or RVM or eRVM. In the eRVM case, the
mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy as it will be introduced
in clause 6.3.
NOTE 3: From an execution perspective, there is no difference between SFBs and UDFBs.
ETSI
12 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
• Program memory shall be provided with Configcodes which determine the eRVM configuration.
• CU shall generate Initialization and Set-up instructions for APEs, DOs and ASF based on decoding
Configcodes stored in the Program memory.
• ASF shall connect APEs and DOs in accordance with CU signals. One DO can be connected with multiple
APEs. One APE can be connected with multiple DOs. DO from other eRVMs can be connected with ASF
through external data ports.
Figure 6.2 illustrates a block diagram of eRVM. Basic Operations in eRVM consist of operations provided by the Radio
Library and/orUDFB Set.
NOTE 1: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 2: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 3: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
Figure 6.2: Elementary RVM
The Data path of an eRVM shall consist of the following blocks:
• DOs;
• APEs;
• ASF.
Each DO shall have a unique number and for this purpose the DOs shall be represented as DO , DO , … , DO , where
1 2 N
N is a sufficiently large number. The structure of DO is shown in figure 6.3.
ETSI
13 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
in it fu ll / e mp t y
st at u s
config DO
se t
exce ption
ds data
F
S
A
Figure 6.3: DO and its interfaces
Each DO shall be configured by a config instruction which consists of:
• init field initializes DO according to the specific initialization procedure (depending on implementation);
• set field is an instruction which sets up the DO attributes such as DO_ID, access time, size, etc. (as shown in
clause 6.2).
DO shall communicate with APEs through ASF interface which consists of:
• data status (ds) signal to indicate whether the DO is full or empty;
• data lines directed to or from DO to read or write data to or from APEs.
Status interface shall provide the status information of DO to CU and consists of:
• full/empty describes whether DO is full of data or empty;
• exception describes the reason of fail when an APE operates with the DO.
Each APE shall have a unique number and shall be represented as APE1, APE2, … , APEM, where M is a sufficiently
large number. The structure of APE is shown in figure 6.4.
init
set
config
APE
exce pt ion st atus
ds data ds data
...
1 N
t
t
r
r
o o
p
p
Figure 6.4: APE and its interfaces
ETSI
14 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
APEs shall be configured by the config instruction which consists of:
• init field brings the op code operation from Basic Operations;
• set field sets up APE attributes such as the number of ports, port types, the execution cost and time.
APE's ports shall connect APE to ASF and shall include data interface which consists of:
• ds signal to indicate whether the DO is full or empty;
• data lines to read or write data through ASF.
Status interface shall provide status information of APE to CU and consists of:
• active/inactive describes state of the APE such as active and inactive;
• exception describes the reason of fail when an APE's operation has an error.
Note that, the APE is active when it has consumed input DOs and processes them. The APE goes to the inactive state
with corresponding indication to CU immediately after processing all the data associated to the APE.
ASF shall connect APEs and DOs as shown in figure 6.5. One DO can be connected to multiple APEs. One APE can
also be connected to multiple DOs.
Data ports
l
l
a a
n
n
r
r
e e
t
t
x
n
i e
data
data data data
port port port
port1 2 L . N
...
Switch fabric
config; init, set
connector
processing processing processing
port port . port
1 2 M
Processing ports
Figure 6.5: Abstract Switch Fabric
ASF shall connect DOs and APEs through ports which consist of:
• data ports (internal) connect the ASF to DOs via interface lines;
• data ports (external) connect the ASF to DOs from other eRVMs or RVMs;
• processing ports connect the ASF to APEs via interface lines.
Each connector of ASF shall connect ports bounded to DO with ports bounded to APE. Each connector shall have the
same interface lines as ports do, i.e. ds, data. Connectors shall convey interface values between ports when they appear
in corresponding ports.
CU shall configure the ASF by the following commands:
• init associates data ports with DOs and processing ports with APEs;
• set creates connections between data ports and processing ports.
ETSI
15 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
6.3 RVM Hierarchy
Figure 6.6 illustrates RVM hierarchy which shall consist of APEs, DOs, Basic Operations, Program memory, CU, ASF
and eRVMs/RVMs. Note that RVM might contain another eRVM(s)/RVM(s). Each eRVM/RVM in this case functions
like an APE. Similarly to the case of figure 6.2, the CU in figure 6.6 connects the DO(s) to the corresponding APE(s)
through the ASF. But in this case the data might be connected to eRVM/RVM as well as to APE.
For a RVM, the SFB or UDFB shall be mapped onto an APE or RVM or eRVM.
NOTE 1: In the eRVM case, the mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy.
NOTE 2: Only Basic Operations can be mapped to an APE, but these Basic Operations can furthermore be mapped
to an eRVM or RVM. If an SFB or UDFB is not included in the Basic Operations, it cannot be mapped to
an APE, it is mapped to an eRVM or RVM.
The RVM shall be scalable vertically and/or horizontally. As for vertical scaling, since each eRVM contains exactly one
particular data flow chart, i.e. specific algorithm, in order to build a RVM hierarchy, an APE can contain another
eRVM/RVM which executes another particular data flow chart. As for horizontal scaling, several RVMs can be
arranged on the same level. These horizontally arranged RVMs shall be independent, meaning that fully independent
processes are executed in parallel.
Figure 6.6: RVM hierarchy
ETSI
16 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Figure 6.7: Horizontal scaling of eRVM
6.4 Data types
6.4.1 Types and Values
The only data types for DOs shall be tokens which have some size in bits. The DOs structure is recognized by
initialized APE.
NOTE: As one example, full DOs can be treated an allocation of bits in memory.
6.4.2 Run-Time Data
There shall be the following Run-Time Data types:
1) CC (Configcodes Counter) register : positive 32-bit integer.
2) Constant DOs: dynamic allocation of bits existing only during task execution and initialized by some external
agent. In short, this DO is related to externally provided data.
3) Intermediate DOs: dynamic allocation of bits existing only during task execution and initialized by
intermediate value created as a result of corresponding APE operation.
ETSI
17 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
6.5 Arithmetic
Arithmetic is not fixed but defined by operations from Basic Operations.
6.6 Exceptions
There shall be 2 types of exceptions:
• Generated by DOs, see table 6.1.
Table 6.1: DO Exceptions
Value Semantic
00 No exception
01 Operation with size > DO size
10 Conflicting writes
11 Conflicting read-erase operations
• Generated by APEs/(e)RVMs, see table 6.2.
Table 6.2 : APE/(e)RVM Exceptions
Exception Semantic
00 No exception
01 Change CC flow
10 Arithmetic overflow/underflow
Incorrect operation (operation is carried out on data
where the operation is not defined)
6.7 Control, Synchronization and Execution
Control shall be data-driven only. Execution shall be done by APE in case that
• All input DOs are configured and full in case of terminal operations;
• All input DOs are configured and some of them are full in case of nonterminal operations;
• APE is configured;
• APE is connected with configured DOs.
After APE has been configured, some output DOs of APE might be non-empty while the APE is executing its
operation. The task of execution is not instantaneous but has some finite duration. All operation on the data path shall
be concurrent and asynchronous.
CU does not manage task execution directly. CU shall:
• configure all data path elements before Configcodes execution;
• receive status signals from all data path element during task execution;
• detect end of each Configcode;
• detect the last Configcode in the task;
• stop execution in case of any exception.
ETSI
18 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
6.8 Operations with Memory
In the applied model, memory is considered be flat and infinite. Its implementation is out the scope of the present
document. Any RVM shall have access to the memory. DOs shall be allocated in the memory during their
configuration. The memory shall allow multiple parallel read write operations. Conflicting operations shall enforce
exceptions. Attempts to write more data than there is allocated DO memory shall also enforce exceptions. During
particular memory operation the entire DOs shall be consumed.
6.9 RVM run-time environment
The RVM Runtime Environment (RVM RE), e.g. software based, allows to run RAs which might be Configcodes or
executable codes:
1) In case of CConfigcode execution, the RVM RE comprises a RVM interpreter.
2) In case of executable codes, binary platform-specific codes are created which are executed on the target
platform.
The RVM RE provides access for RAs to platform hardware resources and radio spectrum. For that purpose RVM RE
and RAs shall implement interfaces defined by documents [i.3], [i.4] and [i.5].
In particular, installation and uninstallation of RAs are supported by MURI. Access to platform hardware resources is
provided by URAI. Access to radio spectrum is provided by RRFI.
In case of Configcodes, JIT compiler might be a part of the RVM RE.
Any type of code representation (i.e. executable code, source code, IR) should comply with the interfaces defined in
ETSI EN 303 095 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 095 [i.2] allows the executable RA code
to access the platform HW in order to generate or receive a radio signal.
NOTE 2: In the case of source code, compilation is performed on the platform as an additional step prior to
execution.
NOTE 3: The RVM is only used for the IR case.
7 Configcodes for RVM
7.0 Introduction
This clause explains how the Configcodes are generated as a result of front-end compilation of the software
Intermediate Representation (SWIR) during the design time of RA code distribution. The Configcodes are typically
generated in either binary or eXtensible Markup Langugage (XML) depending on vendor's choice.
7.1 Configcodes generation
This clause explains how the Configcodes are generated in either binary or XML format, which is referred to as a RVM
Input file in the present document. Figure 7.1 illustrates the processing steps of generating the Configcodes from
corresponding SWIR. Processing of Configcodes generation shown in figure 7.1 starts from SWIR which consists of
functions and processes of a given RA code. The SWIR shall be generated through the procedure of parallelizing a
given RA code created in a high-level language, e.g. C, C++, etc. The operation of SWIR is based on data-driven
mechanism as mentioned in clause 6.1. The conversion of SWIR into corresponding Configcodes shall consist of the
following 3 steps.
1) Parsing SWIR file.
Input: SWIR file.
ETSI
19 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Output: Intermediate Representation (IR) objects which consist of terminal objects and links that connect the
terminal objects.
Actions: Parsing of SWIR file and creating IR objects consisting of sections and links.
2) Mapping of IR objects into Configcodes objects.
Input: List of IR objects.
Output: Configcodes objects each of which represents one configuration determined by terminal operators,
APE, DO and Switch configurations and text file with OpCode which specifies implemented data flow chart.
Actions: Conversion of each object from IR data format to Configcodes format with all configurations of the
Configcodes in the task being determined by parameters for APE, DO and Switch. Creation of OpCode file
with matches between the name of each implemented function and corresponding OpCode.
3) Creation of RVM Input file.
Input: Configcodes objects.
Output: RVM Input file.
Actions: Creation of RVM Input file from Configcodes objects.
SWIR
Step 1
Parsing SWIR
IR objects
Convert to OpCode
Step 2
RVM IR file
Configcode
objects
Create
Step 3
RVM Input
RVM
Input file
Figure 7.1: Processing step of generating RVM Input file
ETSI
20 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
NOTE: While there might be various formats in the RVM Input file, the present document considers XML and
Binary format. Examples of Configcodes defined in Binary and XML format are shown in clauses 7.2 and
7.3, respectively.
7.2 Binary format for Configcodes
In this clause, the format of binary Configcodes is presented.
Each task shall include one or several Configcodes. Each of them shall consist of Control Configcode, DO Configcode,
APE Configcode, ASF Configcode and optionally Next Configcode Address Offset (NCAO). The field NCAO shall be
augmented if NAF = 1. The binary format of Configcodes is shown in figure 7.2 and shall consist of:
• The control section provides general information regarding the task and consists of:
- LCF, 1 bit, LCF = 1 means that this is the last Configcode in the task;
- NAF, 1 bit, NAF = 1 means that the field NCAO is augmented to this Configcode;
- Task_ID, 8 bits, is an automatically generated identifier of this task;
- RPI version, 8 bits, is version number of supported RPI;
- Reference_ID, 8 bits, is SFB identifier of the reference Radio Library;
- Implementation version, 8 bits, is the version number of the implemented task;
- Developer_ID, 16 bits, is the identifier of the developer who creates the current task;
- Creation_Date, 16 bits, is the date of task creation.
• DO section provides general information regarding DO configuration and consists of:
- N_DO, 8 bits is the number of DOs involved in this Configcode;
- N_DO particular DO configuration fields:
DO_config is a particular DO Configcode;
ASF_config is the ASF Configcode without DO field.
• APE section provides general information regarding APE configuration and consists of:
- N_APE, 16 bits is the number of APEs involved in this Configcode;
- N_APE particular APE configuration fields:
APE config field is a particular APE Configcode.
ETSI
21 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
1 bit 1 bit
LCF NAF
8 bits 8 bits 8 bits 8 bits
Control
Implementation
Task_ID RPRPI I Vveerrssiioonn ReRPfeI rVeenrcseio_nID RPI Version
section version
16 bits 16 bits
Developer_ID Creation_Date
8 bits variable length field variable length field
N_DO DO 0 DO_config DO 0 ASF_config
DO 1 DO_config DO 1 ASF_config
DO
section
...
DO (N_DO-1) DO_config DO (N_DO-1)ASF_config
16 bits 9 bytes+2*NN bits
N_APE APE 0 APE_config
APE 1 APE_config
APE
section
...
APE (N_APE-1) APE_config
16 bits
NCAO
Figure 7.2: Binary format for Configcodes
Format of a particular DO_Configcode shall consist of two parts: one part is a fixed length field of DO set code and the
other part is a variable length field of DO init code. It is shown in figure 7.3.
Figure 7.3: Format of a particular DO_Configcode
DO shall be configured by an instruction DO_config (Set, Init) with Set field and Init field.
Figure 7.4 illustrates the format of the DO set code and it shall consist of :
• SIZE is the positive integer number showing the DO size in bytes;
• ACCESS TIME is the positive integer number showing access time in ns.
Figure 7.4: Format of DO set code
The Set field shall set DO attributes using Set(YYYY, ZZZZ) where YYYY is the size in bytes, ZZZZ is the access
time in ns.
ETSI
22 Draft ETSI EN 303 146-4 V1.1.1 (2017-01)
Figure 7.5 illustrates the format of DO init code and it consists of :
• LENGTH, 1 byte, is the length of the variable part of the field in bytes;
• VARIABLE LENGTH FIELD up to 256 bytes brings immediate values.
Figure 7.5: Format of DO init code
The Init field shall initialize the DO according to the specific initialization procedure (depending on implementation)
and make DO full after initialization if LENGTH ≠ 0, i.e. Init( XXXX), where XXXX contains the length and
initialization value in the form of a bit sequence. Init field might be empty if LENGTH = 0, in such case the DO is
empty.
Figure 7.6 illustrates the format of APE_Configcode and it shall consist of :
• APE_ID, 2 bytes, is the number of APE;
• op code, 20 bits is the code of operation from Basic Operations;
• T, 1 bit flag, when T = 1 for dynamic operations, APE is inactive just after completion of the operation, when
T = 0 for static operations, APE is active even after completion of the operation;
NOTE 1: The statement "APE is inactive just after completion of the operation" indicates that another functionality
may be allocated to the APE. The statement "APE is active even
...
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Mobile Device (MD) information models and protocols;
Part 4: Radio Programming Interface (RPI)
2 ETSI EN 303 146-4 V1.1.2 (2017-04)
Reference
REN/RRS-0214
Keywords
architecture, mobile, radio, SDR, software,
system
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.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EN 303 146-4 V1.1.2 (2017-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Introduction . 8
5 System Requirement Mapping . 10
6 Radio Virtual Machine specification . 10
6.1 Concept of RVM . 10
6.2 Elementary RVM (eRVM) . 11
6.3 RVM Hierarchy . 15
6.4 Data types . 17
6.4.1 Types and Values . 17
6.4.2 Run-Time Data . 17
6.5 Arithmetic. 17
6.6 Exceptions . 17
6.7 Control, Synchronization and Execution . 17
6.8 Operations with Memory . 18
6.9 RVM run-time environment . 18
7 Configcodes for RVM . 19
7.0 Introduction . 19
7.1 Configcodes generation . 19
7.2 Binary format for Configcodes . 20
7.3 XML schema for Configcodes . 24
8 Radio Library . 30
8.0 Introduction . 30
8.1 Reference Radio Library . 30
8.2 Native Radio Library . 31
9 Loading, Linking and Initialization . 32
10 Compiling for RVM (Front-End Compilation) . 33
Annex A (informative): Mapping between XML and Binary . 34
Annex B (informative): SFB Candidate . 35
Annex C (informative): Replacement of selected components of an existing RAT . 37
Annex D (informative): Introducing new SFBs . 38
History . 39
ETSI
4 ETSI EN 303 146-4 V1.1.2 (2017-04)
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 European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.3].
National transposition dates
Date of adoption of this EN: 10 April 2017
Date of latest announcement of this EN (doa): 31 July 2017
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 January 2018
Date of withdrawal of any conflicting National Standard (dow): 31 January 2018
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
5 ETSI EN 303 146-4 V1.1.2 (2017-04)
1 Scope
The scope of the present document is to define the Radio Programming Interface (RPI) for mobile device
reconfiguration. The work is based on the Use Cases defined in ETSI TR 102 944 [i.1], on the system requirements
defined in ETSI EN 302 969 [1] and on the radio reconfiguration related architecture for mobile devices defined in
ETSI EN 303 095 [i.2]. Furthermore, the present document complements the mobile device information models and
protocols related to the Multiradio Interface ETSI EN 303 146-1 [i.3], to the Reconfigurable Radio Frequency Interface
ETSI EN 303 146-2 [i.4] and to the Unified Radio Application Interface ETSI EN 303 146-3 [i.5].
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 EN 302 969 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
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 102 944: "Reconfigurable Radio Systems (RRS); Use Cases for Baseband Interfaces for
Unified Radio Applications of Mobile Device".
[i.2] ETSI EN 303 095 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Architecture for Mobile Devices".
[i.3] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device Information Models
and Protocols; Part 1: Multiradio Interface (MURI)".
[i.4] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.5] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
6 ETSI EN 303 146-4 V1.1.2 (2017-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Abstract Processing Element (APE): abstracts computational resource that executes any computations downloaded
from Radio Library
NOTE: APE is connected with input and output DOs. APE is reactive. Any computations are started if all input
DOs are filled with real data.
basic operations: operations either provided by the Radio Library and/or UDFB Set to eRVM or by the Radio Library
and/or RVM/eRVM Configcodes to RVM
NOTE: Each Basic Operation is mapped to a corresponding APE in the case of eRVM or mapped to a
corresponding APE or RVM/eRVM in the case of RVM.
data flow chart: reactive data flow computational model consisting of data and operators where data are connected
with operators
NOTE: Operators abstract computations. They are triggered by full data. Results of operator computations are
written in connected output data if they are empty.
Data Object (DO): typeless token abstracting any type of data
NOTE: DO provides a container for storing data. It can be empty if no data in the container or it can be full if
there is data in the container. DO is allocated in the infinite and flat memory. Any RVM has access to this
memory. One or a few APEs from RVM can be connected with DO. DO acknowledges connected APEs
about its status whether it empty or full.
dynamic operation: operation that is performed by allocating the computational resources during run-time for each
APE required executing the given operation
NOTE 1: The resources are deallocated upon completion of the corresponding operation.
NOTE 2: Dynamic operation is available only in the case of MDRC-7 defined in ETSI EN 302 969 [1]. In other
words, dynamic operation is needed when RA requires the dynamic resource sharing.
native radio library: library providing platform-specific description of each SFB that represents the target platform
hardware
port configuration: specification of the number of APEs inputs and outputs
radio library authority: authority empowered to decide which components can be registered as new SFBs
NOTE: Any suitable organization can take the role of a Radio Library Authority. The choice of the organization
is beyond the scope of the present document.
Radio Virtual Machine (RVM): abstract machine that supports reactive and concurrent executions
NOTE: A RVM may be implemented as a controlled execution environment that allows the selection of a trade-
off between flexibility of base band code development and required (re-)certification efforts.
Radio Virtual Machine Runtime Environment (RVM RE): software that allows running Radio Applications that
might be Configcodes or executable codes
reference radio library: library providing normative definition of each SFB
NOTE: There may be multiple such Reference Radio Libraries. For a given RA, a unique Reference Radio
Library is used.
ETSI
7 ETSI EN 303 146-4 V1.1.2 (2017-04)
Software Intermediate Representation (SWIR): RA representation as data flow chart
NOTE: SWIR file contains information on all terminal objects, their parameters (cost, implement function, size,
etc.) and connections (links, access type, source and destination).
terminal operation: operation that will always be executed without any other interruption
NOTE 1: Furthermore, terminal operation cannot be decomposed into smaller operations.
NOTE 2: "Terminal operations" are equivalent to "atomic operations", but additionally it indicates that a hierarchy
is being used in which the "terminal operations" are on the lowest level of hierarchy and they can be part
of another operation.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AOT Ahead-Of-Time
APE Abstract Processing Element
ASF Abstract Switch Fabric
CC Configcodes Counter
CSL Communication Services Layer
CU Control Unit
DO Data Object
eRVM Elementary RVM
eSFB Elementary SFB
FB Functional Block
FBRI FB Reusability Index
FFT Fast Fourier Transform
HD Hardware Dimension
HW Hardware
ID Identification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
MD Mobile Device
MURI MUltiRadio Interface
NAF Next Address Flag
NAPE Number of Abstract Processing Elements
NCAO Next Configcode Address Offset
NDO Number of Data Objects
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Runtime Environment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming Interface
RRFI Reconfigurable Radio Frequency Interface
RVM Radio Virtual Machine
RVM RE RVM Runtime Environment
SD Software Dimension
SFB Standard Functional Block
SWIR SoftWare Intermediate Representation
UDFB User Defined Functional Block
UML Unified Modeling Language
URA Unified Radio Applications
URAI Unified Radio Applications Interface
XML eXtensible Markup Language
ETSI
8 ETSI EN 303 146-4 V1.1.2 (2017-04)
4 Introduction
A reconfigurable MD is capable of running multiple radios simultaneously and of changing the set of radios by loading
new Radio Application Package (RAP). All Radio Applications (RAs) are called Unified Radio Applications (URAs)
when they exhibit a common behaviour from the reconfigurable MD's point of view [i.2]. In order to run multiple
URAs, the reconfigurable MD will include Communication Services Layer (CSL), Radio Control Framework (RCF),
Radio Platform and 4 sets of interfaces for their interconnection.
Figure 4.1: Four sets of interfaces for Reconfigurable MD
Figure 4.1 illustrates the Reconfigurable MD architecture with the 4 sets of interfaces, i.e.:
• MURI for interfacing CSL and RCF [i.2];
• RRFI for interfacing URA and RF Transceiver [i.3];
• URAI for interfacing URA and RCF [i.2];
• RPI for allowing an independent and uniform production of RAs.
The present document defines RPI.
ETSI
9 ETSI EN 303 146-4 V1.1.2 (2017-04)
<>
IMURI
<>
IRR F I
R adioComput er
<>
IRPI
<>
IURAI ®
Figure 4.2: UML class diagram for Radio Computer interfaces ®
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable MD may be seen as a
Radio Computer where individual URAs are engineered as software entities [i.2].
The present document is organized as follows:
• Clause 5 describes the system requirement mapping.
• Clause 6 describes the radio virtual machine specification.
• Clause 7 describes the Configcodes for RVM.
• Clause 8 describes the radio library structure.
• Clause 9 describes the load, linking and initialization.
• Clause 10 describes the compiling for RVM.
• Annex A describes the mapping between Binary and XML.
• Annex B describes SFB Candidates.
• Annex C describes the replacement of selected components of an existing RAT. ®
While UML is used for defining the information model and protocol related to RPI, other modelling languages could
be used as well.
ETSI
10 ETSI EN 303 146-4 V1.1.2 (2017-04)
5 System Requirement Mapping
The Radio Programming Interface and its related components described in the present document shall support the
system requirements shown in table 5.1 referring to clause 6 of ETSI EN 302 969 [1]. This is achieved by introducing
st
the entities/components/units given in the 1 column of table 5.1.
Table 5.1: Mapping of Radio Programming Interface and its related components to
the system requirements described in ETSI EN 302 969 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming R-FUNC-MDR-04 The requirement shall be as described in clause 6.4.4 of ETSI
Interface EN 302 969 [1].
Radio Virtual Machine R-FUNC-MDR-13 The requirement shall be as described in clause 6.4.13 of
ETSI EN 302 969 [1].
R-FUNC-MDR-14 The requirement shall be as described in clause 6.4.14 of
ETSI EN 302 969 [1].
R-FUNC-MDR-15 The requirement shall be as described in clause 6.4.15 of
ETSI EN 302 969 [1].
Radio Library R-FUNC-FB-06 A library extension shall be supported. The requirement shall
be as described in clause 6.3.6 of ETSI EN 302 969 [1].
6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 095 [i.2], the Radio Virtual Machine (RVM) is an Abstract Machine which is capable of
executing Configcodes and it is independent of the hardware. The implementation of a RVM is target Radio Computer
specific and it shall have access to the Back-end Compiler (on the platform itself or externally as described in ETSI
EN 303 095 [i.2], clause 4.4.1) for Just-in-Time (JIT) or Ahead-of-Time (AOT) compilation of Configcodes.
This clause describes the concept of RVM. As mentioned above, the RVM is an abstract machine, which executes a
particular algorithm presented as a data flow chart. In other words, the RVM is the result of replacing all operators and
tokens in the particular data flow chart with Abstract Processing Elements (APEs) and Data Objects (DOs),
respectively. Each APE executes computations marked by the replaced operator identifier. These computations are
taken from the Radio Library.
Figure 6.1 illustrates a conceptual view of RVM processing. This process requires APE, DO and Radio Library, of
which the definitions are as follows:
• APE abstracts a computational resource corresponding to the operation in a particular data flow chart.
• DO abstracts a memory resource. In other words, DO is an abstracted memory for storing data used during the
procedure of Radio processing.
• Reference/Native Radio Library includes normative definitions/native implementation of all Standard
Functional Blocks (SFBs) [i.2] for front-end/back-end compilation. Note that the computations included in the
Radio Library are represented in terms of normative definitions or native implementations of SFBs depending
upon whether the Radio Library is used for front-end or back-end compilation, respectively.
NOTE 1: User Defined Functional Blocks (UDFBs) will be created through combination of SFBs and represented
as a data flow chart to be executed in the RVM. Alternatively, a UDFB is implemented as a stand-alone
module/function which can be mapped:
i) into one APE (i.e. this UDFB can be considered atomic); or
ii) into an eRVM/RVM (i.e. not atomic). UDFBs are not in general included into the Radio Library,
but they are part of the Radio Application Package.
ETSI
11 ETSI EN 303 146-4 V1.1.2 (2017-04)
The RVM begins to work immediately after some DOs initialization. All APEs shall execute computations
asynchronously and concurrently. An individual APE shall execute the allocated operator if all the corresponding input
DOs are full. APEs shall access DOs with operations "read", "read-erase", or "write". After reading input data from
DOs, the APE shall execute the allocated operator and, if output DOs are empty, then the APE shall write processed
data. Any full output DO shall block the corresponding writing operation. The RVM shall execute computations until
reaching the state when all APEs become inactive. In this state, there are not enough full DOs, which can activate the
inactive operators. The result of computations are full DOs, which cannot activate the inactive operators.
NOTE 2: An Output DO can become an Input DO for a subsequent operator. Then, this input DO can activate the
subsequent operator.
NOTE 3: The state or operation of a given APE is independent on the state of other APEs. I.e. each APE is atomic.
Figure 6.1: Conceptual Diagram of Radio Virtual Machine Processing
6.2 Elementary RVM (eRVM)
This clause describes the eRVM which shall consist of components of Basic Operations, Program memory, Control
Unit (CU), Abstract Switch Fabric (ASF) as well as APEs and DOs, of which the definitions are as follows. eRVM shall
not contain another eRVM or RVM.
• Basic Operations shall include operators either provided:
i) from Radio Library as SFBs and/or;
ii) from UDFB set as UDFBs, each of which is mapped onto one single APE.
ETSI
12 ETSI EN 303 146-4 V1.1.2 (2017-04)
NOTE 1: Since UDFBs might be implemented as a stand-alone module/function which can be mapped into one
APE, in this case, Basic Operations include operators provided by UDFB Set as well as by Radio Library
as SFBs. Note that those UDFBs are atomic.
NOTE 2: For a RVM, the SFB or UDFB can be mapped onto an APE or RVM or eRVM. In the eRVM case, the
mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy as it will be introduced
in clause 6.3.
NOTE 3: From an execution perspective, there is no difference between SFBs and UDFBs.
• Program memory shall be provided with Configcodes which determine the eRVM configuration.
• CU shall generate Initialization and Set-up instructions for APEs, DOs and ASF based on decoding
Configcodes stored in the Program memory.
• ASF shall connect APEs and DOs in accordance with CU signals. One DO can be connected with multiple
APEs. One APE can be connected with multiple DOs. DO from other eRVMs can be connected with ASF
through external data ports.
Figure 6.2 illustrates a block diagram of eRVM. Basic Operations in eRVM consist of operations provided by the Radio
Library and/orUDFB Set.
NOTE 1: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 2: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 3: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
Figure 6.2: Elementary RVM
ETSI
13 ETSI EN 303 146-4 V1.1.2 (2017-04)
The Data path of an eRVM shall consist of the following blocks:
• DOs;
• APEs;
• ASF.
Each DO shall have a unique number and for this purpose the DOs shall be represented as DO , DO , …, DO , where N
1 2 N
is a sufficiently large number. The structure of DO is shown in figure 6.3.
in it fu ll / e mp t y
st at u s
config DO
se t
exce ption
ds data
F
S
A
Figure 6.3: DO and its interfaces
Each DO shall be configured by a config instruction which consists of:
• init field initializes DO according to the specific initialization procedure (depending on implementation);
• set field is an instruction which sets up the DO attributes such as DO_ID, access time, size, etc. (as shown in
clause 6.2).
DO shall communicate with APEs through ASF interface which consists of:
• data status (ds) signal to indicate whether the DO is full or empty;
• data lines directed to or from DO to read or write data to or from APEs.
Status interface shall provide the status information of DO to CU and consists of:
• full/empty describes whether DO is full of data or empty;
• exception describes the reason of fail when an APE operates with the DO.
Each APE shall have a unique number and shall be represented as APE , APE , …, APE , where M is a sufficiently
1 2 M
large number. The structure of APE is shown in figure 6.4.
ETSI
14 ETSI EN 303 146-4 V1.1.2 (2017-04)
init
set
config
APE exce pt ion st atus
ds data ds data
...
1 N
t t
r r
o o
p
p
Figure 6.4: APE and its interfaces
APEs shall be configured by the config instruction which consists of:
• init field brings the op code operation from Basic Operations;
• set field sets up APE attributes such as the number of ports, port types, the execution cost and time.
APE's ports shall connect APE to ASF and shall include data interface which consists of:
• ds signal to indicate whether the DO is full or empty;
• data lines to read or write data through ASF.
Status interface shall provide status information of APE to CU and consists of:
• active/inactive describes state of the APE such as active and inactive;
• exception describes the reason of fail when an APE's operation has an error.
Note that, the APE is active when it has consumed input DOs and processes them. The APE goes to the inactive state
with corresponding indication to CU immediately after processing all the data associated to the APE.
ASF shall connect APEs and DOs as shown in figure 6.5. One DO can be connected to multiple APEs. One APE can
also be connected to multiple DOs.
ETSI
15 ETSI EN 303 146-4 V1.1.2 (2017-04)
Data ports
l
l
a
a
n
n
r
r
e
e
t
t
x
n
i
e
data
data data data
port
port port L . port
1 2 . N
Switch fabric
config; init, set
connector
processing processing
processing
port port . port
1 2 M
Processing ports
Figure 6.5: Abstract Switch Fabric
ASF shall connect DOs and APEs through ports which consist of:
• data ports (internal) connect the ASF to DOs via interface lines;
• data ports (external) connect the ASF to DOs from other eRVMs or RVMs;
• processing ports connect the ASF to APEs via interface lines.
Each connector of ASF shall connect ports bounded to DO with ports bounded to APE. Each connector shall have the
same interface lines as ports do, i.e. ds, data. Connectors shall convey interface values between ports when they appear
in corresponding ports.
CU shall configure the ASF by the following commands:
• init associates data ports with DOs and processing ports with APEs;
• set creates connections between data ports and processing ports.
6.3 RVM Hierarchy
Figure 6.6 illustrates RVM hierarchy which shall consist of APEs, DOs, Basic Operations, Program memory, CU, ASF
and eRVMs/RVMs. Note that RVM might contain another eRVM(s)/RVM(s). Each eRVM/RVM in this case functions
like an APE. Similarly to the case of figure 6.2, the CU in figure 6.6 connects the DO(s) to the corresponding APE(s)
through the ASF. But in this case the data might be connected to eRVM/RVM as well as to APE.
For a RVM, the SFB or UDFB shall be mapped onto an APE or RVM or eRVM.
NOTE 1: In the eRVM case, the mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy.
NOTE 2: Only Basic Operations can be mapped to an APE, but these Basic Operations can furthermore be mapped
to an eRVM or RVM. If an SFB or UDFB is not included in the Basic Operations, it cannot be mapped to
an APE, it is mapped to an eRVM or RVM.
The RVM shall be scalable vertically and/or horizontally. As for vertical scaling, since each eRVM contains exactly one
particular data flow chart, i.e. specific algorithm, in order to build a RVM hierarchy, an APE can contain another
eRVM/RVM which executes another particular data flow chart. As for horizontal scaling, several RVMs can be
arranged on the same level. These horizontally arranged RVMs shall be independent, meaning that fully independent
processes are executed in parallel.
ETSI
16 ETSI EN 303 146-4 V1.1.2 (2017-04)
Figure 6.6: RVM hierarchy
Figure 6.7: Horizontal scaling of eRVM
ETSI
17 ETSI EN 303 146-4 V1.1.2 (2017-04)
6.4 Data types
6.4.1 Types and Values
The only data types for DOs shall be tokens which have some size in bits. The DOs structure is recognized by
initialized APE.
NOTE: As one example, full DOs can be treated an allocation of bits in memory.
6.4.2 Run-Time Data
There shall be the following Run-Time Data types:
1) CC (Configcodes Counter) register: positive 32-bit integer.
2) Constant DOs: dynamic allocation of bits existing only during task execution and initialized by some external
agent. In short, this DO is related to externally provided data.
3) Intermediate DOs: dynamic allocation of bits existing only during task execution and initialized by
intermediate value created as a result of corresponding APE operation.
6.5 Arithmetic
Arithmetic is not fixed but defined by operations from Basic Operations.
6.6 Exceptions
There shall be 2 types of exceptions:
• Generated by DOs, see table 6.1.
Table 6.1: DO Exceptions
Value Semantic
00 No exception
01 Operation with size > DO size
10 Conflicting writes
11 Conflicting read-erase operations
• Generated by APEs/(e)RVMs, see table 6.2.
Table 6.2: APE/(e)RVM Exceptions
Exception Semantic
00 No exception
01 Change CC flow
10 Arithmetic overflow/underflow
Incorrect operation (operation is carried out on data
where the operation is not defined)
6.7 Control, Synchronization and Execution
Control shall be data-driven only. Execution shall be done by APE in case that:
• All input DOs are configured and full in case of terminal operations.
• All input DOs are configured and some of them are full in case of nonterminal operations.
ETSI
18 ETSI EN 303 146-4 V1.1.2 (2017-04)
• APE is configured.
• APE is connected with configured DOs.
After APE has been configured, some output DOs of APE might be non-empty while the APE is executing its
operation. The task of execution is not instantaneous but has some finite duration. All operation on the data path shall
be concurrent and asynchronous.
CU does not manage task execution directly. CU shall:
• configure all data path elements before Configcodes execution;
• receive status signals from all data path element during task execution;
• detect end of each Configcode;
• detect the last Configcode in the task;
• stop execution in case of any exception.
6.8 Operations with Memory
In the applied model, memory is considered be flat and infinite. Its implementation is out the scope of the present
document. Any RVM shall have access to the memory. DOs shall be allocated in the memory during their
configuration. The memory shall allow multiple parallel read write operations. Conflicting operations shall enforce
exceptions. Attempts to write more data than there is allocated DO memory shall also enforce exceptions. During
particular memory operation the entire DOs shall be consumed.
6.9 RVM run-time environment
The RVM Runtime Environment (RVM RE), e.g. software based, allows to run RAs which might be Configcodes or
executable codes:
1) In case of CConfigcode execution, the RVM RE comprises a RVM interpreter.
2) In case of executable codes, binary platform-specific codes are created which are executed on the target
platform.
The RVM RE provides access for RAs to platform hardware resources and radio spectrum. For that purpose RVM RE
and RAs shall implement interfaces defined by documents [i.3], [i.4] and [i.5].
In particular, installation and uninstallation of RAs are supported by MURI. Access to platform hardware resources is
provided by URAI. Access to radio spectrum is provided by RRFI.
In case of Configcodes, JIT compiler might be a part of the RVM RE.
Any type of code representation (i.e. executable code, source code, IR) should comply with the interfaces defined in
ETSI EN 303 095 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 095 [i.2] allows the executable RA code
to access the platform HW in order to generate or receive a radio signal.
NOTE 2: In the case of source code, compilation is performed on the platform as an additional step prior to
execution.
NOTE 3: The RVM is only used for the IR case.
ETSI
19 ETSI EN 303 146-4 V1.1.2 (2017-04)
7 Configcodes for RVM
7.0 Introduction
This clause explains how the Configcodes are generated as a result of front-end compilation of the software
Intermediate Representation (SWIR) during the design time of RA code distribution. The Configcodes are typically
generated in either binary or eXtensible Markup Langugage (XML) depending on vendor's choice.
7.1 Configcodes generation
This clause explains how the Configcodes are generated in either binary or XML format, which is referred to as a RVM
Input file in the present document. Figure 7.1 illustrates the processing steps of generating the Configcodes from
corresponding SWIR. Processing of Configcodes generation shown in figure 7.1 starts from SWIR which consists of
functions and processes of a given RA code. The SWIR shall be generated through the procedure of parallelizing a
given RA code created in a high-level language, e.g. C, C++, etc. The operation of SWIR is based on data-driven
mechanism as mentioned in clause 6.1. The conversion of SWIR into corresponding Configcodes shall consist of the
following 3 steps.
1) Parsing SWIR file.
Input: SWIR file.
Output: Intermediate Representation (IR) objects which consist of terminal objects and links that connect the
terminal objects.
Actions: Parsing of SWIR file and creating IR objects consisting of sections and links.
2) Mapping of IR objects into Configcodes objects.
Input: List of IR objects.
Output: Configcodes objects each of which represents one configuration determined by terminal operators,
APE, DO and Switch configurations and text file with OpCode which specifies implemented data flow chart.
Actions: Conversion of each object from IR data format to Configcodes format with all configurations of the
Configcodes in the task being determined by parameters for APE, DO and Switch. Creation of OpCode file
with matches between the name of each implemented function and corresponding OpCode.
3) Creation of RVM Input file.
Input: Configcodes objects.
Output: RVM Input file.
Actions: Creation of RVM Input file from Configcodes objects.
ETSI
20 ETSI EN 303 146-4 V1.1.2 (2017-04)
SWIR
Step 1
Parsing SWIR
IR objects
Convert to OpCode
Step 2
RVM IR file
Configcode
objects
Create
Step 3
RVM Input
RVM
Input file
Figure 7.1: Processing step of generating RVM Input file
NOTE: While there might be various formats in the RVM Input file, the present document considers XML and
Binary format. Examples of Configcodes defined in Binary and XML format are shown in clauses 7.2 and
7.3, respectively.
7.2 Binary format for Configcodes
In this clause, the format of binary Configcodes is presented.
Each task shall include one or several Configcodes. Each of them shall consist of Control Configcode, DO Configcode,
APE Configcode, ASF Configcode and optionally Next Configcode Address Offset (NCAO). The field NCAO shall be
augmented if NAF = 1. The binary format of Configcodes is shown in figure 7.2 and shall consist of:
• The control section provides general information regarding the task and consists of:
- LCF, 1 bit, LCF = 1 means that this is the last Configcode in the task;
- NAF, 1 bit, NAF = 1 means that the field NCAO is augmented to this Configcode;
- Task_ID, 8 bits, is an automatically generated identifier of this task;
- RPI version, 8 bits, is version number of supported RPI;
- Reference_ID, 8 bits, is SFB identifier of the reference Radio Library;
- Implementation version, 8 bits, is the version number of the implemented task;
ETSI
21 ETSI EN 303 146-4 V1.1.2 (2017-04)
- Developer_ID, 16 bits, is the identifier of the developer who creates the current task;
- Creation_Date, 16 bits, is the date of task creation.
• DO section provides general information regarding DO configuration and consists of:
- N_DO, 8 bits is the number of DOs involved in this Configcode;
- N_DO particular DO configuration fields:
DO_config is a particular DO Configcode;
ASF_config is the ASF Configcode without DO field.
• APE section provides general information regarding APE configuration and consists of:
- N_APE, 16 bits is the number of APEs involved in this Configcode;
- N_APE particular APE configuration fields:
APE config field is a particular APE Configcode.
1 bit 1 bit
LCF NAF
8 bits 8 bits 8 bits 8 bits
Control
Implementation
Task_ID RPRPI I Vveerrssiioonn ReRPfeI rVeenrcseio_nID RPI Version
section version
16 bits 16 bits
Developer_ID Creation_Date
8 bits variable length field variable length field
N_DO DO 0 DO_config DO 0 ASF_config
DO 1 DO_config DO 1 ASF_config
DO
section
...
DO (N_DO-1) DO_config DO (N_DO-1)ASF_config
16 bits 9 bytes+2*NN bits
N_APE APE 0 APE_config
APE 1 APE_config
APE
section
...
APE (N_APE-1) APE_config
16 bits
NCAO
Figure 7.2: Binary format for Configcodes
Format of a particular DO_Configcode shall consist of two parts: one part is a fixed length field of DO set code and the
other part is a variable length field of DO init code. It is shown in figure 7.3.
ETSI
22 ETSI EN 303 146-4 V1.1.2 (2017-04)
Figure 7.3: Format of a particular DO_Configcode
DO shall be configured by an instruction DO_config (Set, Init) with Set field and Init field.
Figure 7.4 illustrates the format of the DO set code and it shall consist of:
• SIZE is the positive integer number showing the DO size in bytes;
• ACCESS TIME is the positive integer number showing access time in ns.
Figure 7.4: Format of DO set code
The Set field shall set DO attributes using Set(YYYY, ZZZZ) where YYYY is the size in bytes, ZZZZ is the access
time in ns.
Figure 7.5 illustrates the format of DO init code and it consists of:
• LENGTH, 1 byte, is the length of the variable part of the field in bytes;
• VARIABLE LENGTH FIELD up to 256 bytes brings immediate values.
Figure 7.5: Format of DO init code
The Init field shall initialize the DO according to the specific initialization procedure (depending on implementation)
and make DO full after initialization if LENGTH ≠ 0, i.e. Init( XXXX), where XXXX contains the length and
initialization value in the form of a bit sequence. Init field might be empty if LENGTH = 0, in such case the DO is
empty.
Figure 7.6 illustrates the format of APE_Configcode and it shall consist of:
• APE_ID, 2 bytes, is the number of APE;
• op code, 20 bits is the code of operation from Basic Operations;
• T, 1 bit flag, when T = 1 for dynamic operations, APE is inactive just after completion of the operation, when
T = 0 for static operations, APE is active even after completion of the operation;
NOTE 1: The statement "APE is inactive just after completion of the operation" indicates that another functionality
may be allocated to the APE. The statement "APE is active even after completion of the operation"
indicates that no change of functionality will occur.
• NN, 3 bits is the number of ports;
• cost, 2 bytes is the execut
...
SLOVENSKI STANDARD
01-junij-2017
Radijski sistemi z možnostjo preoblikovanja (RRS) - Informacijski modeli in
protokoli za mobilne naprave (MD) - 4. del: Radijski programski vmesnik (RPI)
Reconfigurable Radio Systems (RRS) - Mobile Device (MD) information models and
protocols - Part 4: Radio Programming Interface (RPI)
Reconfigurable Radio Systems (RRS) - Mobile Device Information Models and Protocols
- Part 1: Multiradio Interface (MURI)
Ta slovenski standard je istoveten z: ETSI EN 303 146-4 V1.1.2 (2017-04)
ICS:
33.060.01 Radijske komunikacije na Radiocommunications in
splošno general
35.200 Vmesniška in povezovalna Interface and interconnection
oprema equipment
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Mobile Device (MD) information models and protocols;
Part 4: Radio Programming Interface (RPI)
2 ETSI EN 303 146-4 V1.1.2 (2017-04)
Reference
REN/RRS-0214
Keywords
architecture, mobile, radio, SDR, software,
system
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.
oneM2M logo is protected for the benefit of its Members
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI EN 303 146-4 V1.1.2 (2017-04)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Introduction . 8
5 System Requirement Mapping . 10
6 Radio Virtual Machine specification . 10
6.1 Concept of RVM . 10
6.2 Elementary RVM (eRVM) . 11
6.3 RVM Hierarchy . 15
6.4 Data types . 17
6.4.1 Types and Values . 17
6.4.2 Run-Time Data . 17
6.5 Arithmetic. 17
6.6 Exceptions . 17
6.7 Control, Synchronization and Execution . 17
6.8 Operations with Memory . 18
6.9 RVM run-time environment . 18
7 Configcodes for RVM . 19
7.0 Introduction . 19
7.1 Configcodes generation . 19
7.2 Binary format for Configcodes . 20
7.3 XML schema for Configcodes . 24
8 Radio Library . 30
8.0 Introduction . 30
8.1 Reference Radio Library . 30
8.2 Native Radio Library . 31
9 Loading, Linking and Initialization . 32
10 Compiling for RVM (Front-End Compilation) . 33
Annex A (informative): Mapping between XML and Binary . 34
Annex B (informative): SFB Candidate . 35
Annex C (informative): Replacement of selected components of an existing RAT . 37
Annex D (informative): Introducing new SFBs . 38
History . 39
ETSI
4 ETSI EN 303 146-4 V1.1.2 (2017-04)
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 European Standard (EN) has been produced by ETSI Technical Committee Reconfigurable Radio Systems (RRS).
The present document is part 4 of a multi-part deliverable. Full details of the entire series can be found in part 1 [i.3].
National transposition dates
Date of adoption of this EN: 10 April 2017
Date of latest announcement of this EN (doa): 31 July 2017
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 January 2018
Date of withdrawal of any conflicting National Standard (dow): 31 January 2018
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
5 ETSI EN 303 146-4 V1.1.2 (2017-04)
1 Scope
The scope of the present document is to define the Radio Programming Interface (RPI) for mobile device
reconfiguration. The work is based on the Use Cases defined in ETSI TR 102 944 [i.1], on the system requirements
defined in ETSI EN 302 969 [1] and on the radio reconfiguration related architecture for mobile devices defined in
ETSI EN 303 095 [i.2]. Furthermore, the present document complements the mobile device information models and
protocols related to the Multiradio Interface ETSI EN 303 146-1 [i.3], to the Reconfigurable Radio Frequency Interface
ETSI EN 303 146-2 [i.4] and to the Unified Radio Application Interface ETSI EN 303 146-3 [i.5].
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 EN 302 969 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Requirements for Mobile Devices".
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 102 944: "Reconfigurable Radio Systems (RRS); Use Cases for Baseband Interfaces for
Unified Radio Applications of Mobile Device".
[i.2] ETSI EN 303 095 (V1.2.1): "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
Architecture for Mobile Devices".
[i.3] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device Information Models
and Protocols; Part 1: Multiradio Interface (MURI)".
[i.4] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.5] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
ETSI
6 ETSI EN 303 146-4 V1.1.2 (2017-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Abstract Processing Element (APE): abstracts computational resource that executes any computations downloaded
from Radio Library
NOTE: APE is connected with input and output DOs. APE is reactive. Any computations are started if all input
DOs are filled with real data.
basic operations: operations either provided by the Radio Library and/or UDFB Set to eRVM or by the Radio Library
and/or RVM/eRVM Configcodes to RVM
NOTE: Each Basic Operation is mapped to a corresponding APE in the case of eRVM or mapped to a
corresponding APE or RVM/eRVM in the case of RVM.
data flow chart: reactive data flow computational model consisting of data and operators where data are connected
with operators
NOTE: Operators abstract computations. They are triggered by full data. Results of operator computations are
written in connected output data if they are empty.
Data Object (DO): typeless token abstracting any type of data
NOTE: DO provides a container for storing data. It can be empty if no data in the container or it can be full if
there is data in the container. DO is allocated in the infinite and flat memory. Any RVM has access to this
memory. One or a few APEs from RVM can be connected with DO. DO acknowledges connected APEs
about its status whether it empty or full.
dynamic operation: operation that is performed by allocating the computational resources during run-time for each
APE required executing the given operation
NOTE 1: The resources are deallocated upon completion of the corresponding operation.
NOTE 2: Dynamic operation is available only in the case of MDRC-7 defined in ETSI EN 302 969 [1]. In other
words, dynamic operation is needed when RA requires the dynamic resource sharing.
native radio library: library providing platform-specific description of each SFB that represents the target platform
hardware
port configuration: specification of the number of APEs inputs and outputs
radio library authority: authority empowered to decide which components can be registered as new SFBs
NOTE: Any suitable organization can take the role of a Radio Library Authority. The choice of the organization
is beyond the scope of the present document.
Radio Virtual Machine (RVM): abstract machine that supports reactive and concurrent executions
NOTE: A RVM may be implemented as a controlled execution environment that allows the selection of a trade-
off between flexibility of base band code development and required (re-)certification efforts.
Radio Virtual Machine Runtime Environment (RVM RE): software that allows running Radio Applications that
might be Configcodes or executable codes
reference radio library: library providing normative definition of each SFB
NOTE: There may be multiple such Reference Radio Libraries. For a given RA, a unique Reference Radio
Library is used.
ETSI
7 ETSI EN 303 146-4 V1.1.2 (2017-04)
Software Intermediate Representation (SWIR): RA representation as data flow chart
NOTE: SWIR file contains information on all terminal objects, their parameters (cost, implement function, size,
etc.) and connections (links, access type, source and destination).
terminal operation: operation that will always be executed without any other interruption
NOTE 1: Furthermore, terminal operation cannot be decomposed into smaller operations.
NOTE 2: "Terminal operations" are equivalent to "atomic operations", but additionally it indicates that a hierarchy
is being used in which the "terminal operations" are on the lowest level of hierarchy and they can be part
of another operation.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AOT Ahead-Of-Time
APE Abstract Processing Element
ASF Abstract Switch Fabric
CC Configcodes Counter
CSL Communication Services Layer
CU Control Unit
DO Data Object
eRVM Elementary RVM
eSFB Elementary SFB
FB Functional Block
FBRI FB Reusability Index
FFT Fast Fourier Transform
HD Hardware Dimension
HW Hardware
ID Identification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
MD Mobile Device
MURI MUltiRadio Interface
NAF Next Address Flag
NAPE Number of Abstract Processing Elements
NCAO Next Configcode Address Offset
NDO Number of Data Objects
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Runtime Environment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming Interface
RRFI Reconfigurable Radio Frequency Interface
RVM Radio Virtual Machine
RVM RE RVM Runtime Environment
SD Software Dimension
SFB Standard Functional Block
SWIR SoftWare Intermediate Representation
UDFB User Defined Functional Block
UML Unified Modeling Language
URA Unified Radio Applications
URAI Unified Radio Applications Interface
XML eXtensible Markup Language
ETSI
8 ETSI EN 303 146-4 V1.1.2 (2017-04)
4 Introduction
A reconfigurable MD is capable of running multiple radios simultaneously and of changing the set of radios by loading
new Radio Application Package (RAP). All Radio Applications (RAs) are called Unified Radio Applications (URAs)
when they exhibit a common behaviour from the reconfigurable MD's point of view [i.2]. In order to run multiple
URAs, the reconfigurable MD will include Communication Services Layer (CSL), Radio Control Framework (RCF),
Radio Platform and 4 sets of interfaces for their interconnection.
Figure 4.1: Four sets of interfaces for Reconfigurable MD
Figure 4.1 illustrates the Reconfigurable MD architecture with the 4 sets of interfaces, i.e.:
• MURI for interfacing CSL and RCF [i.2];
• RRFI for interfacing URA and RF Transceiver [i.3];
• URAI for interfacing URA and RCF [i.2];
• RPI for allowing an independent and uniform production of RAs.
The present document defines RPI.
ETSI
9 ETSI EN 303 146-4 V1.1.2 (2017-04)
<>
IMURI
<>
IRR F I
R adioComput er
<>
IRPI
<>
IURAI ®
Figure 4.2: UML class diagram for Radio Computer interfaces ®
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable MD may be seen as a
Radio Computer where individual URAs are engineered as software entities [i.2].
The present document is organized as follows:
• Clause 5 describes the system requirement mapping.
• Clause 6 describes the radio virtual machine specification.
• Clause 7 describes the Configcodes for RVM.
• Clause 8 describes the radio library structure.
• Clause 9 describes the load, linking and initialization.
• Clause 10 describes the compiling for RVM.
• Annex A describes the mapping between Binary and XML.
• Annex B describes SFB Candidates.
• Annex C describes the replacement of selected components of an existing RAT. ®
While UML is used for defining the information model and protocol related to RPI, other modelling languages could
be used as well.
ETSI
10 ETSI EN 303 146-4 V1.1.2 (2017-04)
5 System Requirement Mapping
The Radio Programming Interface and its related components described in the present document shall support the
system requirements shown in table 5.1 referring to clause 6 of ETSI EN 302 969 [1]. This is achieved by introducing
st
the entities/components/units given in the 1 column of table 5.1.
Table 5.1: Mapping of Radio Programming Interface and its related components to
the system requirements described in ETSI EN 302 969 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming R-FUNC-MDR-04 The requirement shall be as described in clause 6.4.4 of ETSI
Interface EN 302 969 [1].
Radio Virtual Machine R-FUNC-MDR-13 The requirement shall be as described in clause 6.4.13 of
ETSI EN 302 969 [1].
R-FUNC-MDR-14 The requirement shall be as described in clause 6.4.14 of
ETSI EN 302 969 [1].
R-FUNC-MDR-15 The requirement shall be as described in clause 6.4.15 of
ETSI EN 302 969 [1].
Radio Library R-FUNC-FB-06 A library extension shall be supported. The requirement shall
be as described in clause 6.3.6 of ETSI EN 302 969 [1].
6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 095 [i.2], the Radio Virtual Machine (RVM) is an Abstract Machine which is capable of
executing Configcodes and it is independent of the hardware. The implementation of a RVM is target Radio Computer
specific and it shall have access to the Back-end Compiler (on the platform itself or externally as described in ETSI
EN 303 095 [i.2], clause 4.4.1) for Just-in-Time (JIT) or Ahead-of-Time (AOT) compilation of Configcodes.
This clause describes the concept of RVM. As mentioned above, the RVM is an abstract machine, which executes a
particular algorithm presented as a data flow chart. In other words, the RVM is the result of replacing all operators and
tokens in the particular data flow chart with Abstract Processing Elements (APEs) and Data Objects (DOs),
respectively. Each APE executes computations marked by the replaced operator identifier. These computations are
taken from the Radio Library.
Figure 6.1 illustrates a conceptual view of RVM processing. This process requires APE, DO and Radio Library, of
which the definitions are as follows:
• APE abstracts a computational resource corresponding to the operation in a particular data flow chart.
• DO abstracts a memory resource. In other words, DO is an abstracted memory for storing data used during the
procedure of Radio processing.
• Reference/Native Radio Library includes normative definitions/native implementation of all Standard
Functional Blocks (SFBs) [i.2] for front-end/back-end compilation. Note that the computations included in the
Radio Library are represented in terms of normative definitions or native implementations of SFBs depending
upon whether the Radio Library is used for front-end or back-end compilation, respectively.
NOTE 1: User Defined Functional Blocks (UDFBs) will be created through combination of SFBs and represented
as a data flow chart to be executed in the RVM. Alternatively, a UDFB is implemented as a stand-alone
module/function which can be mapped:
i) into one APE (i.e. this UDFB can be considered atomic); or
ii) into an eRVM/RVM (i.e. not atomic). UDFBs are not in general included into the Radio Library,
but they are part of the Radio Application Package.
ETSI
11 ETSI EN 303 146-4 V1.1.2 (2017-04)
The RVM begins to work immediately after some DOs initialization. All APEs shall execute computations
asynchronously and concurrently. An individual APE shall execute the allocated operator if all the corresponding input
DOs are full. APEs shall access DOs with operations "read", "read-erase", or "write". After reading input data from
DOs, the APE shall execute the allocated operator and, if output DOs are empty, then the APE shall write processed
data. Any full output DO shall block the corresponding writing operation. The RVM shall execute computations until
reaching the state when all APEs become inactive. In this state, there are not enough full DOs, which can activate the
inactive operators. The result of computations are full DOs, which cannot activate the inactive operators.
NOTE 2: An Output DO can become an Input DO for a subsequent operator. Then, this input DO can activate the
subsequent operator.
NOTE 3: The state or operation of a given APE is independent on the state of other APEs. I.e. each APE is atomic.
Figure 6.1: Conceptual Diagram of Radio Virtual Machine Processing
6.2 Elementary RVM (eRVM)
This clause describes the eRVM which shall consist of components of Basic Operations, Program memory, Control
Unit (CU), Abstract Switch Fabric (ASF) as well as APEs and DOs, of which the definitions are as follows. eRVM shall
not contain another eRVM or RVM.
• Basic Operations shall include operators either provided:
i) from Radio Library as SFBs and/or;
ii) from UDFB set as UDFBs, each of which is mapped onto one single APE.
ETSI
12 ETSI EN 303 146-4 V1.1.2 (2017-04)
NOTE 1: Since UDFBs might be implemented as a stand-alone module/function which can be mapped into one
APE, in this case, Basic Operations include operators provided by UDFB Set as well as by Radio Library
as SFBs. Note that those UDFBs are atomic.
NOTE 2: For a RVM, the SFB or UDFB can be mapped onto an APE or RVM or eRVM. In the eRVM case, the
mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy as it will be introduced
in clause 6.3.
NOTE 3: From an execution perspective, there is no difference between SFBs and UDFBs.
• Program memory shall be provided with Configcodes which determine the eRVM configuration.
• CU shall generate Initialization and Set-up instructions for APEs, DOs and ASF based on decoding
Configcodes stored in the Program memory.
• ASF shall connect APEs and DOs in accordance with CU signals. One DO can be connected with multiple
APEs. One APE can be connected with multiple DOs. DO from other eRVMs can be connected with ASF
through external data ports.
Figure 6.2 illustrates a block diagram of eRVM. Basic Operations in eRVM consist of operations provided by the Radio
Library and/orUDFB Set.
NOTE 1: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 2: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 3: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
Figure 6.2: Elementary RVM
ETSI
13 ETSI EN 303 146-4 V1.1.2 (2017-04)
The Data path of an eRVM shall consist of the following blocks:
• DOs;
• APEs;
• ASF.
Each DO shall have a unique number and for this purpose the DOs shall be represented as DO , DO , …, DO , where N
1 2 N
is a sufficiently large number. The structure of DO is shown in figure 6.3.
in it fu ll / e mp t y
st at u s
config DO
se t
exce ption
ds data
F
S
A
Figure 6.3: DO and its interfaces
Each DO shall be configured by a config instruction which consists of:
• init field initializes DO according to the specific initialization procedure (depending on implementation);
• set field is an instruction which sets up the DO attributes such as DO_ID, access time, size, etc. (as shown in
clause 6.2).
DO shall communicate with APEs through ASF interface which consists of:
• data status (ds) signal to indicate whether the DO is full or empty;
• data lines directed to or from DO to read or write data to or from APEs.
Status interface shall provide the status information of DO to CU and consists of:
• full/empty describes whether DO is full of data or empty;
• exception describes the reason of fail when an APE operates with the DO.
Each APE shall have a unique number and shall be represented as APE , APE , …, APE , where M is a sufficiently
1 2 M
large number. The structure of APE is shown in figure 6.4.
ETSI
14 ETSI EN 303 146-4 V1.1.2 (2017-04)
init
set
config
APE exce pt ion st atus
ds data ds data
...
1 N
t t
r r
o o
p
p
Figure 6.4: APE and its interfaces
APEs shall be configured by the config instruction which consists of:
• init field brings the op code operation from Basic Operations;
• set field sets up APE attributes such as the number of ports, port types, the execution cost and time.
APE's ports shall connect APE to ASF and shall include data interface which consists of:
• ds signal to indicate whether the DO is full or empty;
• data lines to read or write data through ASF.
Status interface shall provide status information of APE to CU and consists of:
• active/inactive describes state of the APE such as active and inactive;
• exception describes the reason of fail when an APE's operation has an error.
Note that, the APE is active when it has consumed input DOs and processes them. The APE goes to the inactive state
with corresponding indication to CU immediately after processing all the data associated to the APE.
ASF shall connect APEs and DOs as shown in figure 6.5. One DO can be connected to multiple APEs. One APE can
also be connected to multiple DOs.
ETSI
15 ETSI EN 303 146-4 V1.1.2 (2017-04)
Data ports
l
l
a
a
n
n
r
r
e
e
t
t
x
n
i
e
data
data data data
port
port port L . port
1 2 . N
Switch fabric
config; init, set
connector
processing processing
processing
port port . port
1 2 M
Processing ports
Figure 6.5: Abstract Switch Fabric
ASF shall connect DOs and APEs through ports which consist of:
• data ports (internal) connect the ASF to DOs via interface lines;
• data ports (external) connect the ASF to DOs from other eRVMs or RVMs;
• processing ports connect the ASF to APEs via interface lines.
Each connector of ASF shall connect ports bounded to DO with ports bounded to APE. Each connector shall have the
same interface lines as ports do, i.e. ds, data. Connectors shall convey interface values between ports when they appear
in corresponding ports.
CU shall configure the ASF by the following commands:
• init associates data ports with DOs and processing ports with APEs;
• set creates connections between data ports and processing ports.
6.3 RVM Hierarchy
Figure 6.6 illustrates RVM hierarchy which shall consist of APEs, DOs, Basic Operations, Program memory, CU, ASF
and eRVMs/RVMs. Note that RVM might contain another eRVM(s)/RVM(s). Each eRVM/RVM in this case functions
like an APE. Similarly to the case of figure 6.2, the CU in figure 6.6 connects the DO(s) to the corresponding APE(s)
through the ASF. But in this case the data might be connected to eRVM/RVM as well as to APE.
For a RVM, the SFB or UDFB shall be mapped onto an APE or RVM or eRVM.
NOTE 1: In the eRVM case, the mapping to RVM or eRVM is not possible since it is the lowest level of hierarchy.
NOTE 2: Only Basic Operations can be mapped to an APE, but these Basic Operations can furthermore be mapped
to an eRVM or RVM. If an SFB or UDFB is not included in the Basic Operations, it cannot be mapped to
an APE, it is mapped to an eRVM or RVM.
The RVM shall be scalable vertically and/or horizontally. As for vertical scaling, since each eRVM contains exactly one
particular data flow chart, i.e. specific algorithm, in order to build a RVM hierarchy, an APE can contain another
eRVM/RVM which executes another particular data flow chart. As for horizontal scaling, several RVMs can be
arranged on the same level. These horizontally arranged RVMs shall be independent, meaning that fully independent
processes are executed in parallel.
ETSI
16 ETSI EN 303 146-4 V1.1.2 (2017-04)
Figure 6.6: RVM hierarchy
Figure 6.7: Horizontal scaling of eRVM
ETSI
17 ETSI EN 303 146-4 V1.1.2 (2017-04)
6.4 Data types
6.4.1 Types and Values
The only data types for DOs shall be tokens which have some size in bits. The DOs structure is recognized by
initialized APE.
NOTE: As one example, full DOs can be treated an allocation of bits in memory.
6.4.2 Run-Time Data
There shall be the following Run-Time Data types:
1) CC (Configcodes Counter) register: positive 32-bit integer.
2) Constant DOs: dynamic allocation of bits existing only during task execution and initialized by some external
agent. In short, this DO is related to externally provided data.
3) Intermediate DOs: dynamic allocation of bits existing only during task execution and initialized by
intermediate value created as a result of corresponding APE operation.
6.5 Arithmetic
Arithmetic is not fixed but defined by operations from Basic Operations.
6.6 Exceptions
There shall be 2 types of exceptions:
• Generated by DOs, see table 6.1.
Table 6.1: DO Exceptions
Value Semantic
00 No exception
01 Operation with size > DO size
10 Conflicting writes
11 Conflicting read-erase operations
• Generated by APEs/(e)RVMs, see table 6.2.
Table 6.2: APE/(e)RVM Exceptions
Exception Semantic
00 No exception
01 Change CC flow
10 Arithmetic overflow/underflow
Incorrect operation (operation is carried out on data
where the operation is not defined)
6.7 Control, Synchronization and Execution
Control shall be data-driven only. Execution shall be done by APE in case that:
• All input DOs are configured and full in case of terminal operations.
• All input DOs are configured and some of them are full in case of nonterminal operations.
ETSI
18 ETSI EN 303 146-4 V1.1.2 (2017-04)
• APE is configured.
• APE is connected with configured DOs.
After APE has been configured, some output DOs of APE might be non-empty while the APE is executing its
operation. The task of execution is not instantaneous but has some finite duration. All operation on the data path shall
be concurrent and asynchronous.
CU does not manage task execution directly. CU shall:
• configure all data path elements before Configcodes execution;
• receive status signals from all data path element during task execution;
• detect end of each Configcode;
• detect the last Configcode in the task;
• stop execution in case of any exception.
6.8 Operations with Memory
In the applied model, memory is considered be flat and infinite. Its implementation is out the scope of the present
document. Any RVM shall have access to the memory. DOs shall be allocated in the memory during their
configuration. The memory shall allow multiple parallel read write operations. Conflicting operations shall enforce
exceptions. Attempts to write more data than there is allocated DO memory shall also enforce exceptions. During
particular memory operation the entire DOs shall be consumed.
6.9 RVM run-time environment
The RVM Runtime Environment (RVM RE), e.g. software based, allows to run RAs which might be Configcodes or
executable codes:
1) In case of CConfigcode execution, the RVM RE comprises a RVM interpreter.
2) In case of executable codes, binary platform-specific codes are created which are executed on the target
platform.
The RVM RE provides access for RAs to platform hardware resources and radio spectrum. For that purpose RVM RE
and RAs shall implement interfaces defined by documents [i.3], [i.4] and [i.5].
In particular, installation and uninstallation of RAs are supported by MURI. Access to platform hardware resources is
provided by URAI. Access to radio spectrum is provided by RRFI.
In case of Configcodes, JIT compiler might be a part of the RVM RE.
Any type of code representation (i.e. executable code, source code, IR) should comply with the interfaces defined in
ETSI EN 303 095 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 095 [i.2] allows the executable RA code
to access the platform HW in order to generate or receive a radio signal.
NOTE 2: In the case of source code, compilation is performed on the platform as an additional step prior to
execution.
NOTE 3: The RVM is only used for the IR case.
ETSI
19 ETSI EN 303 146-4 V1.1.2 (2017-04)
7 Configcodes for RVM
7.0 Introduction
This clause explains how the Configcodes are generated as a result of front-end compilation of the software
Intermediate Representation (SWIR) during the design time of RA code distribution. The Configcodes are typically
generated in either binary or eXtensible Markup Langugage (XML) depending on vendor's choice.
7.1 Configcodes generation
This clause explains how the Configcodes are generated in either binary or XML format, which is referred to as a RVM
Input file in the present document. Figure 7.1 illustrates the processing steps of generating the Configcodes from
corresponding SWIR. Processing of Configcodes generation shown in figure 7.1 starts from SWIR which consists of
functions and processes of a given RA code. The SWIR shall be generated through the procedure of parallelizing a
given RA code created in a high-level language, e.g. C, C++, etc. The operation of SWIR is based on data-driven
mechanism as mentioned in clause 6.1. The conversion of SWIR into corresponding Configcodes shall consist of the
following 3 steps.
1) Parsing SWIR file.
Input: SWIR file.
Output: Intermediate Representation (IR) objects which consist of terminal objects and links that connect the
terminal objects.
Actions: Parsing of SWIR file and creating IR objects consisting of sections and links.
2) Mapping of IR objects into Configcodes objects.
Input: List of IR objects.
Output: Configcodes objects each of which represents one configuration determined by terminal operators,
APE, DO and Switch configurations and text file with OpCode which specifies implemented data flow chart.
Actions: Conversion of each object from IR data format to Configcodes format with all configurations of the
Configcodes in the task being determined by parameters for APE, DO and Switch. Creation of OpCode file
with matches between the name of each implemented function and corresponding OpCode.
3) Creation of RVM Input file.
Input: Configcodes objects.
Output: RVM Input file.
Actions: Creation of RVM Input file from Configcodes objects.
ETSI
20 ETSI EN 303 146-4 V1.1.2 (2017-04)
SWIR
Step 1
Parsing SWIR
IR objects
Convert to OpCode
Step 2
RVM IR file
Configcode
objects
Create
Step 3
RVM Input
RVM
Input file
Figure 7.1: Processing step of generating RVM Input file
NOTE: While there might be various formats in the RVM Input file, the present document considers XML and
Binary format. Examples of Configcodes defined in Binary and XML format are shown in clauses 7.2 and
7.3, respectively.
7.2 Binary format for Configcodes
In this clause, the format of binary Configcodes is presented.
Each task shall include one or several Configcodes. Each of them shall consist of Control Configcode, DO Configcode,
APE Configcode, ASF Configcode and optionally Next Configcode Address Offset (NCAO). The field NCAO shall be
augmented if NAF = 1. The binary format of Configcodes is shown in figure 7.2 and shall consist of:
• The control section provides general information regarding the task and consists of:
- LCF, 1 bit, LCF = 1 means that this is the last Configcode in the task;
- NAF, 1 bit, NAF = 1 means that the field NCAO is augmented to this Configcode;
- Task_ID, 8 bits, is an automatically generated identifier of this task;
- RPI version, 8 bits, is version number of supported RPI;
- Reference_ID, 8 bits, is SFB identifier of the reference Radio Library;
- Implementation version, 8 bits, is the version number of the implemented task;
ETSI
21 ETSI EN 303 146-4 V1.1.2 (2017-04)
- Developer_ID, 16 bits, is the identifier of the developer who creates the current task;
- Creation_Date, 16 bits, is the date of task creation.
• DO section provides general information regarding DO configuration and consists of:
- N_DO, 8 bits is the number of DOs involved in this Configcode;
- N_DO particular DO configuration fields:
DO_config is a particular DO Configcode;
ASF_config is the ASF Configcode without DO field.
• APE section provides general information regarding APE configuration and consists of:
- N_APE, 16 bits is the number of APEs involved in this Configcode;
- N_APE particular APE configuration fields:
APE config field is a particular APE Configcode.
1 bit 1 bit
LCF NAF
8 bits 8 bits 8 bits 8 bits
Control
Implementation
Task_ID RPRPI I Vveerrssiioonn ReRPfeI rVeenrcseio_nID RPI Version
section version
16 bits 16 bits
Developer_ID Creation_Date
8 bits variable length field variable length field
N_DO DO 0 DO_config DO 0 ASF_config
DO 1 DO_config DO 1 ASF_config
DO
section
...
DO (N_DO-1) DO_config DO (N_DO-1)ASF_config
16 bits 9 bytes+2*NN bits
N_APE APE 0 APE_config
APE 1 APE_config
APE
section
...
APE (N_APE-1) APE_config
16 bits
NCAO
Figure 7.2: Binary format for Configcodes
Format of a particular DO_Configcode shall consist of two parts: one part is a fixed length field of DO set code and the
other part is a variable length field of DO init code. It is shown in figure 7.3.
ETSI
22 ETSI EN 303 146-4 V1.1.2 (2017-04)
Figure 7.3: Format of a particular DO_Configcode
DO shall be configured by an instruction DO_config (Set, Init)
...
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...