SCA Devices and Services

A primary objective of the Software Communications Architecture (SCA) is to enhance waveform application portability across different hardware platforms executing different Operating Environments (OEs). The aim is to write business logic that can be easily ported from one platform to another.

JTNC APIs
Wireless Innovation Forum (WInnF) APIs

A primary objective of the Software Communications Architecture (SCA) is to enhance waveform application portability across different hardware platforms executing different Operating Environments (OEs). The aim is to write business logic that can be easily ported from one platform to another.

A key element for SCA Waveform portability relies on Hardware Abstraction.


Hardware Abstraction

The SCA achieves Hardware Abstraction by utilizing publicly available open APIs for different hardware elements.

JTNC APIs

  • AudioPort Device
  • Ethernet Device
  • Frequency Reference Device
  • GPS Device
  • Serial Port Device
  • Timing Service
  • Vocoder Service
  • Modem Hardware Abstraction Layer (MHAL)

Wireless Innovation Forum (WInnF) APIs

  • Transceiver
  • International Radio Security Services (IRSS)
  • Light weight (Lw) & Ultra light weight (ULw) AEPs

Got Questions?

If you have any questions about our products and services please contact us at +1-819-307-0333 or email us at info@nordiasoft.com

Audio Port Device

The JTNC Audio Port API enables the creation of a software abstraction of physical Audio devices. The Audio Port API defines methods and attributes that enable waveform application developers to send, receive and control alert and alarm tones as well as to notify the device user of a Push-To-Talk (PTT) signal.

The JTNC Audio Port Device API standard also includes behavioral definition via a state machine to ensure that operations are only executed when the SCA Device is in the proper state.


Ethernet Device

The JTNC Ethernet Device API enables the creation of a software abstraction of physical Ethernet devices. The Ethernet Device API defines methods and attributes that enable waveform application developers to send, receive and control the flow of Ethernet packets.

The JTNC Ethernet Device API standard also includes behavioral definition via a state machine to ensure that operations are only executed when the SCA Device is in the proper state.


Frequency Reference Device

The JTNC Frequency Reference Device API enables the creation of a software abstraction of physical frequency reference hardware devices. The Frequency Reference Device API defines methods and attributes that enable waveform application developers to read frequency reference data and to set the Global Positioning System (GPS) Time Figure of Merit (TFOM) value.


GPS Device

The JTNC GPS Device API enables the creation of a software abstraction of physical Global Positioning System (GPS) receiver hardware devices. The GPS Device API and its extensions define methods and attributes that enable waveform application developers to obtain position, velocity, and time (PVT) data from the physical hardware.

The JTNC GPS Device API standard also includes behavioral definition via a state machine to ensure that operations are only executed when the SCA Device is in the proper state.


Serial Port Device

A Serial Port Device component realizes the Serial Port Device API and supports methods and attributes specific to the Serial Port hardware (HW) device it represents. The Serial Port Device API provides the ability to send flow controlled octet packets to/from the device or service user and supports Request To Send (RTS) / Clear To Send (CTS) handshaking. Serial Port communications are not symmetrical. RTS/CTS operations are dependent on whether the device is a Data Terminal Equipment (DTE) or Data Communications Equipment (DCE).


Timing Service

The JTNC Timing Service API enables the creation of a software abstraction of physical time hardware devices. The Timing Service API defines methods and attributes that enable waveform application developers to maintain, manage, and distributes time within the platform.  This includes Terminal Time and System Time management and distribution. The Timing Service provides an interface for retrieving System Time and Time Figure of Merit (TFOM) for Terminal and System Time.

Terminal Time is the time returned from the Portable Operating System Interface (POSIX) for time and is monotonic increasing. Terminal Time is used for communicating time among the different terminal components (including distributed processor software and hardware components). The Timing Service synchronizes the Terminal Time between distributed components within the terminal. The Timing Service controls the local processor’s POSIX clock.

System Time is the terminal’s estimate of Coordinated Universal Time (UTC) time. UTC time can be derived from various combinations of inputs (e.g. the Global Positioning System (GPS) device, the chronometer device, or operator input) while utilizing the local timing pulse.


Vocoder Service

The JTNC Vocoder Service API enables the creation of a software abstraction that encapsulates vocoding capabilities that are common across waveforms and applications. The Vocoder Service API defines methods and attributes that support waveform application developers with loopback operations, the transfer of encoded/decoded bit streams to and from the service user, and operations to select algorithms supplied by the vocoder.

The Vocoder Service API  and codec extensions allows for the usage of implicit or explicit connection with the Audio Port Device API. Implicit connections are defined by the platform implementation. Explicit connections are defined using the Vocoder Audio Stream API Extension.


Modem Hardware Abstraction Layer (MHAL) Device

The JTNC MHAL API specification aims to enable communications between processors with no CORBA support. The objective is to provide a consistent set of APIs for waveform applications across all JTRS platforms. MHAL is considered part of the Operating Environment (OE) and as such it expected to be bundled with every platform. It is the responsibility of the platform manufacturer to integrate the required MHAL APIs. The use of MHAL does not require any specific feature from a Core Framework. Any version of the Core Framework can be used in conjunction with MHAL.

MHAL relies on usage of the following concepts:

  • Computational Element (CE): a more generic term for processor (since an FPGA is not really a processor).
  • GPP: a CORBA capable processor. This also includes CORBA capable DSP and FPGA.
  • DSP: a C capable processor with no CORBA support.
  • FPGA: a HDL capable processor with no CORBA support.

Figure 1 illustrates that all components running on CORBA capable GPPs can communicate using CORBA. CORBA abstracts the physical transport required to reach other components. In Figure 1 Component B can communicate with Component C because of the physical Ethernet connection between the two GPPs and because CORBA has a software transport that knows how to use that physical Ethernet connection

When CORBA is not available on a constrained CE like DSPs and FPGAs then MHAL can be used to provide that connectivity. As Shown in Figure 2, Component A is able to communicate with Functions on the DSP with the help of a MHAL Device running on the GPP and software transport running on both the GPP and the DSP.


International Radio Security Services

The WInnF International Radio Security Services (IRSS) API standardizes a software security interface for use by the international radio community. In particular, this API is targeted for deployment in radio systems based on the Software Communication Architecture (SCA), though that is not necessarily a prerequisite for its use. In its current increment, the intent of this API is to promote waveform (WF) portability between various radio platforms that provide the API. As such, the focus of this API is on the security interfaces required to meet waveform needs. Although working systems require additional platform security interfaces to fulfill a number of needs, such as keyfill, security policies, etc., standardizing such interfaces does not add to waveform portability. Additionally, it is at the platform level where the variation is expected to be the highest across the international community, making such standardization difficult. As such, platform security interfaces will only be detailed where there is overlap with waveform security interfaces.


Transceiver Next Project Technical Exchange Meetings (TEMs)

The WInnF Transceiver Next Project TEMs are a series of technical exchange meetings announced by the Transceiver Next WInnF work group as a part of the Transceiver v2.0 project.

The meetings aim to support the progress of the Transceiver Next project to develop the next version of the WInnF Transceiver Facility Standard.

The WInnF Transceiver Facility provides implementation-independent standard APIs that enable a high degree of portability for SDR Applications (such as Waveforms), while enabling SDR Transceivers to host a large variety of SDR Applications.

Since its publication in 2009, the V1 specification has been used in many contexts, and a number of suggestions of improvement have already been reported. Besides, interest is growing for a number of additional features to be included in the standard. The WinnF Transceiver Facility is now managed as a WInnF SDR Standard, in accordance with CC SCA Policy 006. Unlike previous version of the Transceiver Facility that was driven by requirements of Waveform Applications, the Transceiver Next Project will broaden applicability of the specification to other categories of SDR Applications such as Test and Measurement, Dynamic Spectrum Allocation, Electronic Warfare and Sensing.


Light weight (Lw) & Ultra light weight (ULw) AEPs

TBA


Unified Timing Service

TBA