Install older version ARC-OTA, e.g. 1.5

Accelerated Computing Aerial Forum
1

Hello,

I am trying to install ARC-OTA, and I only have x86-based platform so far.

However, the latest ARC-OTA version is 1.6, using SDK manager 2.3.0 for installation. But this version only works on arm-based platform.

Therefore, I am thinking using older SDK manager 2.2.0 to install ARC-OTA 1.5, hoping that it can be installed on x86-based platform.
I can install SDK manager 2.2.0, but it only shows “ARC-OTA 1.6 [SDK manager version 2.3.0 or higher version is required]“.

I wonder what I can do to install ARC-OTA 1.5, such as download ARC-OTA .gz file and offline install? or manually install aerial cuda-accelerated RAN container cuBB 24-1 and all required tools, like openairinterface5g?

Any suggestions, links to download or tutorial/user guide will be appreciated.

Thanks,

Hsin-Li

4

Pease use the latest Aerial docuementation

5

Hello,

I’m following ARC-OTA 1.5.1 to build the OAI gNB Aerial Docker image (oai-gnb-aerial). The build progresses into compilation, but fails with some C errors that look like ASN.1 generated type mismatches (pointer vs struct), mainly in NGAP (and previously some in NR RRC).

After inspecting the ASN.1 generated headers produced by the same asn1c inside the base image, it appears that NGAP message types contain:

  • struct NGAP_ProtocolIE_Container *protocolIEs; (opaque pointer)
    while the actual .list member exists only inside concrete containers:
  • NGAP_ProtocolIE_Container_6810Pxx_t { A_SEQUENCE_OF(…) list; … }
    But OAI NGAP sources assume protocolIEs is a concrete struct with a .list field, so code like asn1cSeqAdd(&out->protocolIEs.list, ie); fails.

I’d like to ask if there is a recommended asn1c version/branch, asn1c flags, or known-good OAI commit/patchset for ARC-OTA 1.5.1 that avoids this mismatch.

Environment / Context
Goal: build OAI L2/L3 for end-to-end testing with NVIDIA Aerial/cuBB (ARC-OTA 1.5.1 workflow).
Host: x86 Linux (non-reference server model).
Docker build uses a base image similar to ran-base:latest (Ubuntu 20.04 based build flow).
asn1c inside the base image reports a version string like: asn1c-1.3.0-… (example: asn1c-1.3.0-20-g15fe1bd7-2026-01-06)

Build command

docker build . \
  -f docker/Dockerfile.gNB.aerial.ubuntu20 \
  --build-arg RAN_BASE_IMAGE=ran-base:latest \
  -t oai-gnb-aerial:latest \
  --progress=plain

Key build error excerpt (NGAP)

openair3/NGAP/ngap_gNB.c:420:55: error: 'ie->value.choice.GlobalRANNodeID' is a pointer; did you mean to use '->'?
  420 | &(ie->value.choice.GlobalRANNodeID.choice.globalGNB_ID->pLMNIdentity));

openair3/NGAP/ngap_gNB.c:476:50: error: 'ie->value.choice.SupportedTAList' is a pointer; did you mean to use '->'?
  476 | asn1cSeqAdd(&ie->value.choice.SupportedTAList.list, ta);

openair3/NGAP/ngap_gNB.c:486:32: error: 'out->protocolIEs' is a pointer; did you mean to use '->'?
  486 | asn1cSeqAdd(&out->protocolIEs.list, ie);

openair3/NGAP/ngap_gNB.c:485:32: error: incompatible types when assigning to type 'NGAP_PagingDRX_t *' from type 'ngap_paging_drx_t' (enum)
  485 | ie->value.choice.PagingDRX = instance_p->default_drx;

What I found in ASN.1 generated headers (from the same asn1c in the build image)

  1. protocolIEs is an opaque pointer in generated message headers
    Example excerpt from generated NGAP_InitialUEMessage.h:
/* Forward declarations */
struct NGAP_ProtocolIE_Container_6810P34;
struct NGAP_ProtocolIE_Container;

/* NGAP_InitialUEMessage */
typedef struct NGAP_InitialUEMessage {
  struct NGAP_ProtocolIE_Container *protocolIEs;
  ...
} NGAP_InitialUEMessage_t;

So protocolIEs is not a concrete container type (…_6810Pxx_t) and does not directly expose .list.

  1. The .list member exists only in concrete Pxx containers
    Excerpt from generated NGAP_ProtocolIE-Container.h:
/* NGAP_ProtocolIE-Container */
typedef struct NGAP_ProtocolIE_Container_6810P0 {
  A_SEQUENCE_OF(struct NGAP_PDUSessionResourceSetupRequestIEs) list;
  asn_struct_ctx_t _asn_ctx;
} NGAP_ProtocolIE_Container_6810P0_t;

typedef struct NGAP_ProtocolIE_Container_6810P1 {
  A_SEQUENCE_OF(struct NGAP_PDUSessionResourceSetupResponseIEs) list;
  asn_struct_ctx_t _asn_ctx;
} NGAP_ProtocolIE_Container_6810P1_t;
...

This matches the compile errors: OAI code is written as if out->protocolIEs has a .list member, but under this generation it is a pointer to an opaque base type.

How I reproduced/inspected the generated NGAP headers
Inside the same base image:

ASN1C_PREFIX=NGAP_ /opt/asn1c/bin/asn1c \
  -pdu=all -fcompound-names -gen-APER \
  -no-gen-BER -no-gen-JER -no-gen-OER -gen-UPER \
  -no-gen-example -fno-include-deps -findirect-choice \
  -D /tmp/ngap-gen /path/to/ngap-15.8.0.asn1

sed -n '1,120p' /tmp/ngap-gen/NGAP_InitialUEMessage.h
sed -n '1580,1630p' /tmp/ngap-gen/NGAP_ProtocolIE-Container.h

Questions

  1. For ARC-OTA 1.5.1, does NVIDIA recommend a specific OAI branch/commit (or patchset) that is known to build with the asn1c output style above?
  2. Does NVIDIA recommend a specific asn1c version/branch (e.g., OAI’s asn1c fork/branch) that generates NGAP types compatible with OAI’s NGAP source assumptions?
  3. Are the asn1c flags expected to be different for ARC-OTA?
    For example, should we avoid flags like -findirect-choice or -fno-include-deps if they cause protocolIEs to become an opaque pointer that requires per-message Pxx casting/allocation?
  4. Is there a known upstream fix pattern for NGAP in this environment (e.g., always allocating NGAP_ProtocolIE_Container_6810Pxx_t and assigning it to protocolIEs) that NVIDIA expects users to apply?

Thanks in advance for any guidance or known-good reference for ARC-OTA 1.5.1 builds.

Hsin-Li