ETSI EN 303 681-4 V1.1.2 (2020-06)

Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information models and protocols for generalized software reconfiguration architecture; Part 4: generalized Radio Programming Interface (gRPI)

REN/RRS-0231

Radijski sistemi z možnostjo preoblikovanja (RRS) - Informacijski modeli in protokoli za radijsko opremo (RE) za splošno arhitekturo preoblikovanja programske opreme - 4. del: Splošni radijski programski vmesnik (gRPI)

General Information

• Status: Not Published
• Technical Committee: RRS 2 - REA - Reconfigurable Radio Equipment Architecture
• Current Stage: 12 - Completion
• Due Date: 06-Jul-2020
• Completion Date: 29-Jun-2020
• Ref Project: SIST EN 303 681-4 V1.1.2:2020 - Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) information models and protocols for generalized software reconfiguration architecture - Part 4: generalized Radio Programming Interface (gRPI)

Standards Content (Sample)

Draft ETSI EN 303 681-4 V1.1.2 (2020-03)

EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) information models and protocols
for generalized software reconfiguration architecture;
Part 4: generalized Radio Programming Interface (gRPI)

2 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)

Reference
REN/RRS-0231
Keywords
architecture, interface, radio, SDR, software,
system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

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

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

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 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) . 12
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.1 Introduction . 19
7.2 Configcodes generation . 19
7.3 Binary format for Configcodes . 20
7.4 XML schema for Configcodes . 24
8 Radio Library . 29
8.1 Introduction . 29
8.2 Reference Radio Library . 30
8.3 Native Radio Library . 30
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
Annex E (informative): Synchronous Approach . 38
History . 42

ETSI
4 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This 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 covering the Radio Equipment (RE) information models and
protocols, as identified below:
Part 1: "generalized Multiradio Interface (gMURI)";
Part 2: "generalized Reconfigurable Radio Frequency Interface (gRRFI)";
Part 3: "generalized Unified Radio Application Interface (gURAI)";
Part 4: "generalized Radio Programming Interface (gRPI)".

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 681-4 V1.1.2 (2020-03)
1 Scope
The scope of the present document is to define the generalized Radio Programming Interface (gRPI) for radio
equipment reconfiguration except for reconfigurable mobile devices which are covered in [i.4] to [i.9]. The work is
based on the Use Cases defined in ETSI TR 103 585 [i.1], on the system requirements defined in ETSI EN 303 641 [1]
and on the radio reconfiguration related architecture for radio equipment defined in ETSI EN 303 648 [i.2].
The present document will be based on ETSI EN 303 146-4 [i.9] and provide a generalized interface definition for the
generalized Radio Programming Interface (gRPI).
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.
[1] ETSI EN 303 641: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
requirements".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.2] ETSI EN 303 648: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
architecture".
[i.3] Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the
harmonisation of the laws of the Member States relating to the making available on the market of
Radio Equipment and repealing Directive 1999/5/EC.
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
ETSI
6 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
[i.10] ETSI EN 303 681-1: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 1: generalized
Multiradio Interface (gMURI)".
[i.11] ETSI EN 303 681-2: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 2: generalized
Reconfigurable Radio Frequency Interface (gRRFI)".
[i.12] ETSI EN 303 681-3: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 3: generalized
Unified Radio Application Interface (gURAI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms 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 RERC-7 defined in ETSI EN 303 641 [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
ETSI
7 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
Radio Equipment (RE): "an electrical or electronic product, which intentionally emits and/or receives radio waves for
the purpose of radio communication and/or radiodetermination, or an electrical or electronic product which must be
completed with an accessory, such as antenna, so as to intentionally emit and/or receive radio waves for the purpose of
radio communication and/or radiodetermination".
NOTE: The definition above is as defined in the Radio Equipment Directive, Article 2(1)(1) [i.3].
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
reconfigurable mobile device: mobile device with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable mobile devices include but are not limited to: smartphones, feature phones, tablets, and
laptops.
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.
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 Symbols
Void.
3.3 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
ETSI
8 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
FFT Fast Fourier Transform
gMURI generalized Multiradio Interface
gRPI generalized Radio Programming Interface
gRRFI generalized Reconfigurable Radio Frequency Interface
gURAI generalized Unified Radio Applications Interface
HD Hardware Dimension
HW Hardware
ID IDentification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
NAF Next Address Flag
NAPE Number of Abstract Processing Elements
NCAO Next Configcode Address Offset
NDO Number of Data Objects
NOP No OPeration
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Radio Equipment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming 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 Modelling Language
URA Unified Radio Applications
VDO Virtual Data Object
VHDL Very high speed integrated circuit Hardware Description Language
XML eXtensible Markup Language
XOR eXclusive OR
4 Introduction
A reconfigurable RE is capable of running multiple radios simultaneously, changing the set of radios by loading new
Radio Application Packages (RAP) and setting their parameters. All Radio Applications (RAs) are called Unified Radio
Applications (URAs) when they exhibit a common behaviour from the reconfigurable RE's point of view in ETSI
EN 303 648 [i.2]. In order to run multiple URAs, the reconfigurable RE will include Communication Services Layer
(CSL), Radio Control Frameworks (RCFs), Radio Platforms and 4 sets of interfaces for their interconnection.
ETSI
9 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)

Figure 4.1: Four sets of interfaces for Reconfigurable RE
Figure 4.1 illustrates the Reconfigurable RE architecture with the 4 sets of interfaces, i.e.:
• gMURI for interfacing CSL and RCF (in ETSI EN 303 681-1 [i.10]).
• gRRFI for interfacing URA and RF Transceiver (in ETSI EN 303 681-2 [i.11]).
• gURAI for interfacing URA and RCF (in ETSI EN 303 681-3 [i.12]).
• gRPI for allowing an independent and uniform production of RAs which is the scope of the present document.
The present document defines gRPI.
<< in t erf a ce>>
IgM U R I
<< in t erf a ce>>
IgR R F I
Ra di oC ompute r
<< in t erf a ce>>
IgU R AI
<< in t erf a ce>>
IgR PI
Figure 4.2: UMLclass diagram for Radio Computer interfaces
ETSI
10 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable RE may be seen as a set of
multiple Radio Computers where individual URAs are engineered as software entities in ETSI EN 303 648 [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 loading, 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 gRPI, 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 303 641 [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 303 641 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming R-FUNC-RER-04 The requirement shall be as described in clause 6.4.4 of [1].
Interface
Radio Virtual Machine R-FUNC-RER-13 The requirement shall be as described in clause 6.4.13 of [1].
R-FUNC-RER-14 The requirement shall be as described in clause 6.4.14 of [1].
R-FUNC-RER-15 The requirement shall be as described in clause 6.4.15 of [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 [1].

6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 648 [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 648 [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.
ETSI
11 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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.5] 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.
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
ETSI
12 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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.
• 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 4: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 5: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 6: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
ETSI
13 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)

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 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
DO st at u s
config
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.
ETSI
14 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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.
init
set
con fig
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 7: 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 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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 . port
1 2 L N
...
Switch fabric
config; init, set
c onnec tor
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 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)

Figure 6.6: RVM hierarchy
Figure 6.7: Horizontal scaling of eRVM
ETSI
17 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
• 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 including gMURI, gRRFI, gURAI.
In particular, installation and uninstallation of RAs are supported by gMURI. Access to platform hardware resources is
provided by gURAI. Access to radio spectrum is provided by gRRFI.
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 648 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 648 [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 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
7 Configcodes for RVM
7.1 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.2 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 Draft ETSI EN 303 681-4 V1.1.2 (2020-03)
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
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.3 and
7.4, respectively.
Figure 7.1: Processing step of generating RVM Input file
7.3 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;
- gRPI version, 8 bits, is version number of supported gRPI;
- Reference_ID, 8 bits, is SFB identifier of the reference Radio Library;
- Im
...

EUROPEAN STANDARD
Reconfigurable Radio Systems (RRS);
Radio Equipment (RE) information models and protocols
for generalized software reconfiguration architecture;
Part 4: generalized Radio Programming Interface (gRPI)

2 ETSI EN 303 681-4 V1.1.2 (2020-06)

Reference
REN/RRS-0231
Keywords
architecture, interface, radio, SDR, software,
system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

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

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

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI EN 303 681-4 V1.1.2 (2020-06)
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 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 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) . 12
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.1 Introduction . 19
7.2 Configcodes generation . 19
7.3 Binary format for Configcodes . 20
7.4 XML schema for Configcodes . 24
8 Radio Library . 29
8.1 Introduction . 29
8.2 Reference Radio Library . 30
8.3 Native Radio Library . 30
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
Annex E (informative): Synchronous Approach . 38
History . 42

ETSI
4 ETSI EN 303 681-4 V1.1.2 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This 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 covering the Radio Equipment (RE) information models and
protocols, as identified below:
Part 1: "generalized Multiradio Interface (gMURI)";
Part 2: "generalized Reconfigurable Radio Frequency Interface (gRRFI)";
Part 3: "generalized Unified Radio Application Interface (gURAI)";
Part 4: "generalized Radio Programming Interface (gRPI)".

National transposition dates
Date of adoption of this EN: 22 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021

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 681-4 V1.1.2 (2020-06)
1 Scope
The scope of the present document is to define the generalized Radio Programming Interface (gRPI) for radio
equipment reconfiguration except for reconfigurable mobile devices which are covered in [i.4] to [i.9]. The work is
based on the Use Cases defined in ETSI TR 103 585 [i.1], on the system requirements defined in ETSI EN 303 641 [1]
and on the radio reconfiguration related architecture for radio equipment defined in ETSI EN 303 648 [i.2].
The present document will be based on ETSI EN 303 146-4 [i.9] and provide a generalized interface definition for the
generalized Radio Programming Interface (gRPI).
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 303 641: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
requirements".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.2] ETSI EN 303 648: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
architecture".
[i.3] Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the
harmonisation of the laws of the Member States relating to the making available on the market of
Radio Equipment and repealing Directive 1999/5/EC.
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
ETSI
6 ETSI EN 303 681-4 V1.1.2 (2020-06)
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
[i.10] ETSI EN 303 681-1: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 1: generalized
Multiradio Interface (gMURI)".
[i.11] ETSI EN 303 681-2: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 2: generalized
Reconfigurable Radio Frequency Interface (gRRFI)".
[i.12] ETSI EN 303 681-3: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 3: generalized
Unified Radio Application Interface (gURAI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms 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 RERC-7 defined in ETSI EN 303 641 [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
ETSI
7 ETSI EN 303 681-4 V1.1.2 (2020-06)
port configuration: specification of the number of APEs inputs and outputs
Radio Equipment (RE): "an electrical or electronic product, which intentionally emits and/or receives radio waves for
the purpose of radio communication and/or radiodetermination, or an electrical or electronic product which must be
completed with an accessory, such as antenna, so as to intentionally emit and/or receive radio waves for the purpose of
radio communication and/or radiodetermination".
NOTE: The definition above is as defined in the Radio Equipment Directive, Article 2(1)(1) [i.3].
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
reconfigurable mobile device: mobile device with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable mobile devices include but are not limited to: smartphones, feature phones, tablets, and
laptops.
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.
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 Symbols
Void.
3.3 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
ETSI
8 ETSI EN 303 681-4 V1.1.2 (2020-06)
FB Functional Block
FBRI FB Reusability Index
FFT Fast Fourier Transform
gMURI generalized Multiradio Interface
gRPI generalized Radio Programming Interface
gRRFI generalized Reconfigurable Radio Frequency Interface
gURAI generalized Unified Radio Applications Interface
HD Hardware Dimension
HW Hardware
ID IDentification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
NAF Next Address Flag
NAPE Number of Abstract Processing Elements
NCAO Next Configcode Address Offset
NDO Number of Data Objects
NOP No OPeration
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Radio Equipment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming 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 Modelling Language
URA Unified Radio Applications
VDO Virtual Data Object
VHDL Very high speed integrated circuit Hardware Description Language
XML eXtensible Markup Language
XOR eXclusive OR
4 Introduction
A reconfigurable RE is capable of running multiple radios simultaneously, changing the set of radios by loading new
Radio Application Packages (RAP) and setting their parameters. All Radio Applications (RAs) are called Unified Radio
Applications (URAs) when they exhibit a common behaviour from the reconfigurable RE's point of view in ETSI
EN 303 648 [i.2]. In order to run multiple URAs, the reconfigurable RE will include Communication Services Layer
(CSL), Radio Control Frameworks (RCFs), Radio Platforms and 4 sets of interfaces for their interconnection.
ETSI
9 ETSI EN 303 681-4 V1.1.2 (2020-06)

Figure 4.1: Four sets of interfaces for Reconfigurable RE
Figure 4.1 illustrates the Reconfigurable RE architecture with the 4 sets of interfaces, i.e.:
• gMURI for interfacing CSL and RCF (in ETSI EN 303 681-1 [i.10]).
• gRRFI for interfacing URA and RF Transceiver (in ETSI EN 303 681-2 [i.11]).
• gURAI for interfacing URA and RCF (in ETSI EN 303 681-3 [i.12]).
• gRPI for allowing an independent and uniform production of RAs which is the scope of the present document.
The present document defines gRPI.
<< in t erf ace>>
IgM U R I
<< in t erf ace>>
IgRRFI
Ra di oC ompu te r
<< in t erf ace>>
IgU R AI
<< in t erf ace>>
IgR PI
Figure 4.2: UMLclass diagram for Radio Computer interfaces
ETSI
10 ETSI EN 303 681-4 V1.1.2 (2020-06)
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable RE may be seen as a set of
multiple Radio Computers where individual URAs are engineered as software entities in ETSI EN 303 648 [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 loading, 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 gRPI, 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 303 641 [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 303 641 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming R-FUNC-RER-04 The requirement shall be as described in clause 6.4.4 of [1].
Interface
Radio Virtual Machine R-FUNC-RER-13 The requirement shall be as described in clause 6.4.13 of [1].
R-FUNC-RER-14 The requirement shall be as described in clause 6.4.14 of [1].
R-FUNC-RER-15 The requirement shall be as described in clause 6.4.15 of [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 [1].

6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 648 [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 648 [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.
ETSI
11 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.5] 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.
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
ETSI
12 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.
• 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 4: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 5: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 6: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
ETSI
13 ETSI EN 303 681-4 V1.1.2 (2020-06)

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 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
DO st at u s
config
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.
ETSI
14 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.
init
set
con fig
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 7: 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 681-4 V1.1.2 (2020-06)
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 . port
1 2 L N
...
Switch fabric
config; init, set
c onnec tor
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 681-4 V1.1.2 (2020-06)

Figure 6.6: RVM hierarchy
Figure 6.7: Horizontal scaling of eRVM
ETSI
17 ETSI EN 303 681-4 V1.1.2 (2020-06)
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 681-4 V1.1.2 (2020-06)
• 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 including gMURI, gRRFI, gURAI.
In particular, installation and uninstallation of RAs are supported by gMURI. Access to platform hardware resources is
provided by gURAI. Access to radio spectrum is provided by gRRFI.
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 648 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 648 [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 681-4 V1.1.2 (2020-06)
7 Configcodes for RVM
7.1 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.2 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 681-4 V1.1.2 (2020-06)
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
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.3 and
7.4, respectively.
Figure 7.1: Processing step of generating RVM Input file
7.3 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;
- gRPI version, 8 bits, is version number of supported gRPI;
- 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 t
...

SLOVENSKI STANDARD
01-september-2020
Radijski sistemi z možnostjo preoblikovanja (RRS) - Informacijski modeli in
protokoli za radijsko opremo (RE) za splošno arhitekturo preoblikovanja
programske opreme - 4. del: Splošni radijski programski vmesnik (gRPI)
Reconfigurable Radio Systems (RRS) - Radio Equipment (RE) information models and
protocols for generalized software reconfiguration architecture - Part 4: generalized
Radio Programming Interface (gRPI)
Ta slovenski standard je istoveten z: ETSI EN 303 681-4 V1.1.2 (2020-06)
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);
Radio Equipment (RE) information models and protocols
for generalized software reconfiguration architecture;
Part 4: generalized Radio Programming Interface (gRPI)

2 ETSI EN 303 681-4 V1.1.2 (2020-06)

Reference
REN/RRS-0231
Keywords
architecture, interface, radio, SDR, software,
system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

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

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

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

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI EN 303 681-4 V1.1.2 (2020-06)
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 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 7
3.3 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) . 12
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.1 Introduction . 19
7.2 Configcodes generation . 19
7.3 Binary format for Configcodes . 20
7.4 XML schema for Configcodes . 24
8 Radio Library . 29
8.1 Introduction . 29
8.2 Reference Radio Library . 30
8.3 Native Radio Library . 30
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
Annex E (informative): Synchronous Approach . 38
History . 42

ETSI
4 ETSI EN 303 681-4 V1.1.2 (2020-06)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This 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 covering the Radio Equipment (RE) information models and
protocols, as identified below:
Part 1: "generalized Multiradio Interface (gMURI)";
Part 2: "generalized Reconfigurable Radio Frequency Interface (gRRFI)";
Part 3: "generalized Unified Radio Application Interface (gURAI)";
Part 4: "generalized Radio Programming Interface (gRPI)".

National transposition dates
Date of adoption of this EN: 22 June 2020
Date of latest announcement of this EN (doa): 30 September 2020
Date of latest publication of new National Standard
or endorsement of this EN (dop/e): 31 March 2021
Date of withdrawal of any conflicting National Standard (dow): 31 March 2021

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 681-4 V1.1.2 (2020-06)
1 Scope
The scope of the present document is to define the generalized Radio Programming Interface (gRPI) for radio
equipment reconfiguration except for reconfigurable mobile devices which are covered in [i.4] to [i.9]. The work is
based on the Use Cases defined in ETSI TR 103 585 [i.1], on the system requirements defined in ETSI EN 303 641 [1]
and on the radio reconfiguration related architecture for radio equipment defined in ETSI EN 303 648 [i.2].
The present document will be based on ETSI EN 303 146-4 [i.9] and provide a generalized interface definition for the
generalized Radio Programming Interface (gRPI).
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 303 641: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
requirements".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 103 585: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
use cases".
[i.2] ETSI EN 303 648: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) reconfiguration
architecture".
[i.3] Directive 2014/53/EU of the European Parliament and of the Council of 16 April 2014 on the
harmonisation of the laws of the Member States relating to the making available on the market of
Radio Equipment and repealing Directive 1999/5/EC.
[i.4] ETSI EN 302 969: "Reconfigurable Radio Systems (RRS); Radio Reconfiguration related
requirements for Mobile Devices".
[i.5] ETSI EN 303 095: "Reconfigurable Radio Systems (RRS); Radio reconfiguration related
architecture for Mobile Devices (MD)".
[i.6] ETSI EN 303 146-1: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 1: Multiradio Interface (MURI)".
ETSI
6 ETSI EN 303 681-4 V1.1.2 (2020-06)
[i.7] ETSI EN 303 146-2: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 2: Reconfigurable Radio Frequency Interface (RRFI)".
[i.8] ETSI EN 303 146-3: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 3: Unified Radio Application Interface (URAI)".
[i.9] ETSI EN 303 146-4: "Reconfigurable Radio Systems (RRS); Mobile Device (MD) information
models and protocols; Part 4: Radio Programming Interface (RPI)".
[i.10] ETSI EN 303 681-1: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 1: generalized
Multiradio Interface (gMURI)".
[i.11] ETSI EN 303 681-2: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 2: generalized
Reconfigurable Radio Frequency Interface (gRRFI)".
[i.12] ETSI EN 303 681-3: "Reconfigurable Radio Systems (RRS); Radio Equipment (RE) information
models and protocols for generalized software reconfiguration architecture; Part 3: generalized
Unified Radio Application Interface (gURAI)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms 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 RERC-7 defined in ETSI EN 303 641 [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
ETSI
7 ETSI EN 303 681-4 V1.1.2 (2020-06)
port configuration: specification of the number of APEs inputs and outputs
Radio Equipment (RE): "an electrical or electronic product, which intentionally emits and/or receives radio waves for
the purpose of radio communication and/or radiodetermination, or an electrical or electronic product which must be
completed with an accessory, such as antenna, so as to intentionally emit and/or receive radio waves for the purpose of
radio communication and/or radiodetermination".
NOTE: The definition above is as defined in the Radio Equipment Directive, Article 2(1)(1) [i.3].
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
reconfigurable mobile device: mobile device with radio communication capabilities providing support for radio
reconfiguration
NOTE: Reconfigurable mobile devices include but are not limited to: smartphones, feature phones, tablets, and
laptops.
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.
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 Symbols
Void.
3.3 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
ETSI
8 ETSI EN 303 681-4 V1.1.2 (2020-06)
FB Functional Block
FBRI FB Reusability Index
FFT Fast Fourier Transform
gMURI generalized Multiradio Interface
gRPI generalized Radio Programming Interface
gRRFI generalized Reconfigurable Radio Frequency Interface
gURAI generalized Unified Radio Applications Interface
HD Hardware Dimension
HW Hardware
ID IDentification
IFFT Inverse Fast Fourier Transform
IR Intermediate Representation
JIT Just-In-Time
LCF Last Configuration Flag
NAF Next Address Flag
NAPE Number of Abstract Processing Elements
NCAO Next Configcode Address Offset
NDO Number of Data Objects
NOP No OPeration
RA Radio Application
RAP Radio Application Package
RAT Radio Access Technology
RCF Radio Control Framework
RE Radio Equipment
RF Radio Frequency
RLA Radio Library Authority
ROS Radio Operating System
RPI Radio Programming 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 Modelling Language
URA Unified Radio Applications
VDO Virtual Data Object
VHDL Very high speed integrated circuit Hardware Description Language
XML eXtensible Markup Language
XOR eXclusive OR
4 Introduction
A reconfigurable RE is capable of running multiple radios simultaneously, changing the set of radios by loading new
Radio Application Packages (RAP) and setting their parameters. All Radio Applications (RAs) are called Unified Radio
Applications (URAs) when they exhibit a common behaviour from the reconfigurable RE's point of view in ETSI
EN 303 648 [i.2]. In order to run multiple URAs, the reconfigurable RE will include Communication Services Layer
(CSL), Radio Control Frameworks (RCFs), Radio Platforms and 4 sets of interfaces for their interconnection.
ETSI
9 ETSI EN 303 681-4 V1.1.2 (2020-06)

Figure 4.1: Four sets of interfaces for Reconfigurable RE
Figure 4.1 illustrates the Reconfigurable RE architecture with the 4 sets of interfaces, i.e.:
• gMURI for interfacing CSL and RCF (in ETSI EN 303 681-1 [i.10]).
• gRRFI for interfacing URA and RF Transceiver (in ETSI EN 303 681-2 [i.11]).
• gURAI for interfacing URA and RCF (in ETSI EN 303 681-3 [i.12]).
• gRPI for allowing an independent and uniform production of RAs which is the scope of the present document.
The present document defines gRPI.
<< in t erf ace>>
IgM U R I
<< in t erf ace>>
IgRRFI
Ra di oC ompu te r
<< in t erf ace>>
IgU R AI
<< in t erf ace>>
IgR PI
Figure 4.2: UMLclass diagram for Radio Computer interfaces
ETSI
10 ETSI EN 303 681-4 V1.1.2 (2020-06)
Figure 4.2 illustrates UML class diagram for Radio Computer interfaces. The reconfigurable RE may be seen as a set of
multiple Radio Computers where individual URAs are engineered as software entities in ETSI EN 303 648 [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 loading, 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 gRPI, 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 303 641 [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 303 641 [1]
Entity/Component/Unit System Requirements [1] Comments
Radio Programming R-FUNC-RER-04 The requirement shall be as described in clause 6.4.4 of [1].
Interface
Radio Virtual Machine R-FUNC-RER-13 The requirement shall be as described in clause 6.4.13 of [1].
R-FUNC-RER-14 The requirement shall be as described in clause 6.4.14 of [1].
R-FUNC-RER-15 The requirement shall be as described in clause 6.4.15 of [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 [1].

6 Radio Virtual Machine specification
6.1 Concept of RVM
As introduced in ETSI EN 303 648 [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 648 [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.
ETSI
11 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.5] 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.
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
ETSI
12 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.
• 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 4: A target platform may or may not provide accelerators for some/all SFBs and/or UDFBs.
NOTE 5: Three cases can be considered:
i) RAP includes only SFBs;
ii) RAP includes only UDFBs;
iii) RAP includes SFBs and UDFBs.
NOTE 6: Furthermore, and independent of the upper note, Basic Operations may include:
i) SFBs only;
ii) UDFBs only; or
iii) SFBs and UDFBs.
ETSI
13 ETSI EN 303 681-4 V1.1.2 (2020-06)

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 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
DO st at u s
config
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.
ETSI
14 ETSI EN 303 681-4 V1.1.2 (2020-06)
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.
init
set
con fig
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 7: 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 681-4 V1.1.2 (2020-06)
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 . port
1 2 L N
...
Switch fabric
config; init, set
c onnec tor
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 681-4 V1.1.2 (2020-06)

Figure 6.6: RVM hierarchy
Figure 6.7: Horizontal scaling of eRVM
ETSI
17 ETSI EN 303 681-4 V1.1.2 (2020-06)
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 681-4 V1.1.2 (2020-06)
• 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 including gMURI, gRRFI, gURAI.
In particular, installation and uninstallation of RAs are supported by gMURI. Access to platform hardware resources is
provided by gURAI. Access to radio spectrum is provided by gRRFI.
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 648 [i.2].
NOTE 1: In the case of executable code, the ROS defined in ETSI EN 303 648 [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 681-4 V1.1.2 (2020-06)
7 Configcodes for RVM
7.1 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.2 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 objec
...