C2N (CAMARA-to-NEF) is an open-source modular gateway that implements the CAMARA Transformation Function, translating CAMARA Traffic Influence API requests into 3GPP TS 29.522 NEF (Network Exposure Function) API calls. It bridges the abstraction gap between developer-friendly CAMARA Service APIs and the telecommunications-specific 3GPP Network APIs required by the 5G Core.
This artifact accompanies the paper "C2N: Bridging CAMARA Service APIs and 3GPP Core Network Exposure Function" accepted at SBRC 2026.
Paper abstract: The exposure of 5G network capabilities to third-party applications is fundamental for realizing the Network-as-a-Service (NaaS) paradigm. However, the complexity of native 3GPP interfaces, particularly the Network Exposure Function, creates a significant barrier for application developers. The CAMARA project addresses this challenge by standardizing developer-friendly service APIs, yet the Transformation Function that is responsible for translating these APIs into network-native interfaces remains underspecified and typically implemented as a proprietary black box. This paper presents C2N, an open-source Transformation Function for the CAMARA Traffic Influence API. We propose a modular architecture comprising seven components that implement a three-phase semantic mapping strategy: direct mapping; logical transformation with topology enrichment; and structural mapping.
- Considered Stamps
- Basic Information
- Dependencies
- Security Concerns
- Installation
- Minimal Test
- Experiments
- LICENSE
The stamps considered are: Available (SeloD), Functional (SeloF), and Sustainable (SeloS).
- SeloD: Source code is publicly available on GitHub at https://github.com/LABORA-INF-UFG/C2N with this README satisfying the minimum requirements.
- SeloF: The gateway can be built and executed via Docker or Go. Functional tests cover all CRUD operations using a mock NEF — no real 5G infrastructure required.
- SeloS: The codebase is organized into seven well-defined modules across four processing layers. Only two modules are API-specific; the remaining five are reusable across different CAMARA APIs. Module-level documentation is provided in ARCHITECTURE.md.
| Component | Specification |
|---|---|
| OS | Linux (Ubuntu 22.04 LTS recommended) |
| Architecture | x86_64 |
| CPU | 2+ cores |
| RAM | 2 GB minimum |
| Disk | 2 GB (source + Docker image) |
C2N/
├── cmd/server/main.go # Application entry point
├── internal/
│ ├── camara/ # CAMARA API data models
│ ├── nef/ # 3GPP NEF data models and HTTP client
│ ├── config/ # Configuration loader
│ └── modules/
│ ├── orchestrator.go # Central coordinator (request pipeline)
│ ├── security/ # Authentication, rate limiting, CORS [API-agnostic]
│ ├── ingress/ # Request parsing and OpenAPI validation [API-agnostic]
│ ├── topology/ # Zone-to-network identifier resolution [API-specific]
│ ├── mapper/ # CAMARA-to-NEF field translation [API-specific]
│ ├── builder/ # NEF HTTP request construction [API-agnostic]
│ ├── state/ # Subscription lifecycle and ID correlation [API-agnostic]
│ └── response/ # Response transformation to CAMARA format [API-agnostic]
├── config/topology.json # Zone-to-network topology mappings
├── openapi/ # CAMARA and 3GPP OpenAPI specifications
├── tests/functional/ # Functional tests with mock NEF
├── Dockerfile # Production multi-stage container build
├── Dockerfile.test # Test runner container
├── docker-compose.yml # Deployment with free5GC network
├── docker-compose.test.yml # Isolated test runner
├── .env.example # Environment variable template
├── Makefile # Build and run shortcuts
├── ARCHITECTURE.md # Detailed module documentation
└── DOCKER.md # Docker deployment guide
| Package | Version | Purpose |
|---|---|---|
| Go | 1.21+ | Build and run from source |
| Docker | 24.0+ | Containerized execution |
| Docker Compose | v2.x | Container orchestration |
| Module | Version | Purpose |
|---|---|---|
github.com/gin-gonic/gin |
v1.10.0 | HTTP routing framework |
github.com/golang-jwt/jwt/v5 |
v5.2.3 | JWT token verification |
github.com/google/uuid |
v1.6.0 | Correlation ID generation |
All Go dependencies are declared in go.mod and downloaded automatically via go mod download.
C2N implements HTTP Basic Auth and Bearer Token authentication. The test credentials
used in the functional test suite (admin / adminpassword123) are hardcoded for
testing only and must not be used in any production or real network deployment.
Risk to reviewers: None. The artifact runs in an isolated environment.
- Functional tests use an in-process mock NEF server; no external connections are made.
- Docker deployment creates an isolated network and makes no outbound connections unless
NEF_BASE_URLis configured to point to a real NEF endpoint. - No privileged containers or host network access is required for the functional tests.
# 1. Clone the repository
git clone https://github.com/LABORA-INF-UFG/C2N.git
cd C2N
# 2. Run functional tests in a container
docker compose -f docker-compose.test.yml up --buildExpected: all tests pass and the container exits with code 0.
# 1. Clone the repository
git clone https://github.com/LABORA-INF-UFG/C2N.git
cd C2N
# 2. Install Go 1.21+ if needed
# https://go.dev/doc/install
# 3. Download dependencies
go mod download
# 4. Run tests
go test ./tests/functional/... -v# 1. Clone and enter the repository
git clone https://github.com/LABORA-INF-UFG/C2N.git
cd C2N
# 2. Configure environment
cp .env.example .env
# Edit .env: set NEF_BASE_URL and NEF_TOKEN for your NEF instance
# 3. Build and start
docker compose up --build -d
# 4. Verify
curl http://localhost:8080/healthThis test verifies that the gateway is functional using the embedded mock NEF. It does not require a real 5G Core or NEF instance.
go test ./tests/functional/... -v -run TestTrafficInfluence_FullCRUDLifecycleExpected output (internal server logs omitted for brevity):
=== RUN TestTrafficInfluence_FullCRUDLifecycle
traffic_influence_test.go: Created subscription: <uuid>
traffic_influence_test.go: Read subscription successfully
traffic_influence_test.go: Updated subscription successfully
traffic_influence_test.go: Listed subscriptions successfully
traffic_influence_test.go: Deleted subscription successfully
traffic_influence_test.go: Verified subscription deletion
traffic_influence_test.go: Full CRUD lifecycle test completed successfully
--- PASS: TestTrafficInfluence_FullCRUDLifecycle (0.00s)
PASS
ok github.com/LABORA-INF-UFG/camara2nef/tests/functional
This test exercises the complete CAMARA→NEF translation pipeline (all 7 modules) using a mock NEF that validates the translated 3GPP TS 29.522 request format.
Paper reference: Section 4, Table 1 (CAMARA to NEF Field Mappings).
Claim: C2N translates CAMARA Traffic Influence requests into 3GPP NEF format through three transformation phases — direct mapping, logical transformation with topology enrichment, and structural mapping — bridging the 205-byte CAMARA request to the 402-byte 3GPP NEF format.
Requirements: Go 1.21+ or Docker. No real 5G infrastructure needed.
Steps:
# Run the full test suite to validate all three mapping phases
go test ./tests/functional/... -vIdentifying each phase in the code:
| Phase | Description | Location |
|---|---|---|
| Direct | appId → afServiceId, notificationUri → notifDestination |
internal/modules/mapper/parameter_mapper.go |
| Logical | edgeCloudZoneId → dnai + dnn + snssai (via topology lookup) |
internal/modules/topology/engine.go + config/topology.json |
| Structural | device + trafficFilters → FlowInfo[] with IP 5-tuple format |
internal/modules/mapper/parameter_mapper.go |
Expected result: All tests pass. Each TestCreate* test verifies that C2N produces
a well-formed NEF subscription from a CAMARA request.
Estimated time: < 30 seconds.
Paper reference: Section 4, Figure 1, and the architectural discussion (~70% reusability).
Claim: Five of seven modules (Security, Ingress, Request Builder, State Manager, Response Module) are API-agnostic and reusable when implementing additional CAMARA APIs. Only the Topology Engine and Parameter Mapper are API-specific.
Requirements: Go 1.21+ or Docker. No real 5G infrastructure needed.
Steps:
# Run all functional tests to exercise the full 7-module pipeline
go test ./tests/functional/... -v
# Inspect the module structure
ls internal/modules/Module classification:
internal/modules/
├── security/ [API-agnostic] Authentication, RBAC, rate limiting, audit logging
├── ingress/ [API-agnostic] HTTP parsing, OpenAPI schema validation
├── topology/ [API-specific] Maps edgeCloudZoneId → DNAI/DNN/S-NSSAI
├── mapper/ [API-specific] Translates CAMARA fields to NEF fields (Table 1)
├── builder/ [API-agnostic] Constructs NEF HTTP requests, connection pooling
├── state/ [API-agnostic] Bidirectional CAMARA↔NEF ID mapping, lifecycle
└── response/ [API-agnostic] Transforms NEF responses to CAMARA format
The orchestrator.go wires the seven modules into the four-layer pipeline described
in Figure 2 of the paper (Security → Ingress → Topology/Mapper → Builder/State → Response).
Expected result: All tests pass, confirming the complete pipeline is functional. The 5 API-agnostic modules handle all cross-cutting concerns transparently behind a mock backend, validating the reusability claim.
Estimated time: < 30 seconds.
This project is licensed under the MIT License — see the LICENSE file for details.