Extension 1: End-to-end slicing support for SDR and SDN:

Extension 2: LBT functionality on FPGA as an IP core

Extension 3: RAT interworking on NS-3 based SDR Prototyping Platform

Extension 4: Digital self-interference cancellation for in-Band Full Duplex


The ORCA project hereby announces its first Open Call for Extensions which focuses on the development of missing functionalities to extend the ORCA software and hardware platforms. In particular, this first call targets four extensions:

  • EXT1 – End-to-end slicing support for SDR and SDN
  • EXT2 – LBT functionality on FPGA as an IP core
  • EXT3 – RAT interworking on NS-3 based SDR Prototyping Platform
  • EXT4 – Digital self-interference cancellation for in-Band Full Duplex

You can find more information about the ORCA testbeds here.


Project full nameORCA – Orchestration and Reconfiguration Control Architecture
Project grant agreement number732174
Call identifierORCA-OC1-EXT
Call titleFirst ORCA Open Call for Extension
Submission deadlineWednesday the 15th November 2017, at 17:00 Brussels local time
Feasibility and Relevance check deadlineWednesday the 8th November 2017, at 17:00 Brussels local time

A technical feasibility and relevance check is required before submission. This feasibility and relevance check will be carried out by the ORCA members responsible for the facilities, radio hardware platforms, and software platforms involved.

It is essential that the proposing party gets in contact with the ORCA partner in charge of the testbed which are intended to be used for the proposed Extension, to discuss its feasibility and relevance within the ORCA federation and the related specific requirements. Each proposing party must therefore identify a possible Patron either by contacting an appropriate ORCA partner (see section 4 of the Open Call document) or through [email protected], in case support is required for selecting an appropriate partner.Please check the FAQ section below before contacting us.
The proposing party must submit its draft proposal to the Patron by Wednesday the 8th of November 2017, at 17:00 Brussels local time using the submission portal.  In this draft proposal at least sections A, B and C needs to be fully completed. The feedback will be provided by the Patron at the latest by Tuesday the 14th of November 2017 at 17:00, and must be copied into section D of the proposal template


  • Total budget for Open Call 1 for Extension: 300 000 €
  • Maximum budget per Extension: 80 000 €
  • Expected number of Extensions to be funded: 4
  • Guaranteed support: 18 000 € (An extra budget of typically € 4500 per Extension will be allocated to the ORCA consortium partner acting as Patron for guaranteed support)

Requirements related to the proposer

A proposer can only be selected for funding for one proposal, even if the proposer submitted multiple proposals that are ranked high enough to be selected for funding. In the latter case, the proposer may be given the opportunity to choose the one to be retained for funding.


  • Language in which the proposal must be submitted: English
  • Proposals must follow the provided template (see Section 5.1 Open Call and Appendix A to the same document)
  • Proposals (draft as well as final proposals) must be submitted through the online submission form at the bottom of this page


Contact: [email protected]


General questions

SDR hardware can be remotely accessed in the wireless test facilities supported in ORCA (see The costs for equipment should be a minor contribution of the requested funding.

ORCA targets to offer open and modular software and hardware platforms to the wireless community for experimental validation of networked SDR solutions. The results achieved during the implementation of the Extension by the proposer will be owned by the proposer (further referred to as the Provider). But the Provider is expected to grant to the coordinator (IMEC) non-exclusive, non-transferable, royalty-free and fully paid-up right, with the right to grant sub-licenses to third parties (e.g. ORCA partners or successful proposers in future Open Calls), to use, improve and/or modify the source code. See also article 2.1.1 in Agreement for the integration of an Extension to the ORCA Platform for Experimentation.

A successful proposer will enter the ORCA project as a third party. This implies that a third party does not have to fill in NEF or any other forms from the Commission for financial claims. The only thing that is needed is an invoice, and then depending on the report and the outcome of the review, the Third Party will be paid. However, for a good and better review of your proposal it is best to list the costs related to the proposed experiment or extension as would be done for any European Project:

  • number of PM
  • personnel costs
  • other direct costs (with a very rough split into the different major categories)
  • indirect costs

This information will be used to evaluate the “value for money” of your proposal which is one of the criteria in the proposal review process.
So, there will be no audit, no formal accounting required, but any information, as close as possible to what you would do for a EU project, is advisable to get a proper review of the proposal.

Both draft and final proposals have to be submitted via the submission portal. The latest submission before the submission deadline will be considered for evaluation.
The full process is as follows:

  • A first draft proposal is submitted by the Proposer via the submission portal before the feasibility and relevance check deadline.
  • The Patron provides feedback via email to proposer
  • The Proposer includes the feedback in the proposal, finalises its proposal and submits the final proposal again via the submission portal before the submission deadline

The Patron will NOT review draft proposals or propose any changes to the proposal. The Patron will only give feedback on the feasibility of the proposed experiment based on the completed sections A, B and C. The feedback of the Patron needs to be included in section D of the proposal. The feasibility check does not provide a commitment that the proposal will be selected.

The Patron will be your main contact and support during the time of your extension but in the general based on the platforms considered and your needs, other contact partners can be contacted. The full list of contact people and related platforms can be found in section 6.1 of the Open Call document linked as Detail Call information in the Call documents section in this page.

The maximum duration for an extension is 9 months.

For the integration of the extension with the SDR platform the provider will get support from skilled ORCA consortium partner (the Patron). Details about roles in this OC etc. are listed under the following link:

More details are listed within the call information document:

  • Page 35 -> 6.1. Support of Extension and role of Patron
  • Page 44 -> Section C

For the extension, it is targeted to select one main Patron, but the proposer/provider can also interact with other ORCA contact persons as well, depend which platforms are considered. The degree of platform independence is also a high weighted evaluation criteria for this extension. More information on this topic you will found under

  • Page 32 -> point 6. Degree of platform independence

Unfortunately it is not possible to borrow hardware from ORCA, because it’s integrated fix into the testbeds, but several options are possible to make the integration successful:

  • simulator only tests
  • loop back modes to tests without SDR hardware
  • remote access to SDR hardware through the testbeds
  • physical integration session together with the patron (e.g. meet together for 2-3 days with direct access to the SDR hardware), the travel expenses for this can be foresee in the proposal
  • buy SDR hardware for integration purposes (not funded by ORCA)

Questions about EXT3 – RAT interworking on NS-3 based SDR Prototyping Platform

As an example for the integration of NS-3 LTE with the NI SDR platform detailed information is available under:

Another option for the LTE path could be to use the srsLTE SDR platform together with NS-3 LTE. More information is available under:

Yes, this is a customized version of ns-3 (v3.26). This code will be become available for the provider of the extension in case the proposal is successful. For the LTE part it is already public available under .

The main goal for this extension is to have ns-3 LTE + SDR and ns-3 WIFI + SDR running in parallel . For an intermediate step and for testing it would make sense to run only one RAT on an SDR or use only the ns-3 simulator first. At the end it must be ensured that the validation scenario (Page 25, ) is fulfilled. For implementing and testing this extension, it would make sense to:

  1. start with the implementation of LWA/LWIP using only the ns-3 simulator
  2. if point 1. works, continue testing with UDP loopback modes
    Note: here the SDR will be abstracted using UDP as transport media
  3. If point 2. works, continue integration and testing with an SDR platform. To speed up patron and extension provider could meet physically for an integration session

Yes, the baseline is 3GPP Rel. 13. See also the validation scenario on page 25, or the references section on the same page, point 3.

Questions about EXT2 – LBT functionality on FPGA as an IP core

Yes, see also section 2 (Terms and conditions) of Open Call document, and article 2.1.1 in Agreement for the integration of an Extension to the ORCA Platform for Experimentation.

Figure only gives you a basic example and principle. You can propose new bandwidth and sampling rate values (higher or lower) or even new architecture design, if you believe they are consistent, relevant and good enough for the open call topic.

We expect a generic implementation of the LBT core, meaning that it should work with LTE as defined for LAA. But it could also work with any other technology that want to use LBT. It should be end-to-end, as defined in 3GPP Rel13, 36.789 (see Fig. 5.2.1-1). The validation scenario is more elaborated in Table 5.2.1-1, among which Scenario 1 with ‘best effort’ traffic type for aggressor is mandatory.

This can be done, but you have to make sure that the LBT extension is also validated with the 2 platforms mentioned in the Open Call document. If the LBT core is generic, it should be able to take IQ samples from any other platform (FPGA or host PC).

We leave the design of the Baseband Tx Interface to the proposer. The Open Call document just makes some recommendations. Any design is OK, as long as it can be tested with the 2 platforms mentioned in the Open Call document.

The channel requirements depend on the capabilities of the analog frontend. If the LBT is sufficiently generic, this can be a configurable parameter. Minimum requirement is 20 MHz (see 3GPP document 36.789). The 4 different bands of 23.04 MHz, should be 4 bands of 20 MHz. This is a typing error in the Open Call document.

Related to spectrum sensing, we target a sensing functionality beyond the standard, as described in the Open Call document. We aim to extend the sensing to a more broadband frequency band (covering multiple channels) to assist fast channel selection. When some channel in the monitoring band is free, we can select that free channel for transmission.

We do not expect the LBT controller to change the central frequency of the analog frontend. We assume that, if there are multiple channels in the Baseband TX Buffer, the center frequency of IQ samples is already shifted in the digital domain before entering the buffer in the LBT.

We refer to the 3GPP document 36.789. This set-up uses 2 legacy Wi-Fi nodes (AP + STA) and 2 SDR nodes (1 eNB + UE, downlink only). Only 2 SDR boards are needed. Such a setup can be remotely accessed in one of the testbeds supported by ORCA