In collaboration with The OpenAirInterfaceTM Software Alliance (OSA) and its partners, b<>com advanced connectivity lab develops some 5G core network functions.
Current development mainly focus on NRF, AMF and SMF.
b<>com advanced connectivity labs is proud to provide on the web the cloud native APIs of these 5G core network functions.
All the APIs are also available programmatically. Please read next sections for more details.
Our up to date development are based on 3GPP R15.2.0 release. References to 3GPP Technical Specifications are provided in the next sections.
For more details please contact us.
Anyone is welcome to use the provided APIs.
Nevertheless for the convenience of any API user, we recommend to apply the following rules.
Any user must use the NF instances he·she has registered. NF instances with nfInstanceId value 02000000-cc86-44cf-aaa3-000000000200, 02010000-cc86-44cf-aaa3-000000000201, 02020000-cc86-44cf-aaa3-000000000202, 02030000-cc86-44cf-aaa3-000000000203, 03000000-cc86-44cf-aaa3-000000000300 and 03010000-cc86-44cf-aaa3-000000000301 are reserved and must not be updated.
To register your own NF instance you can:
The major java frameworks we use :
Next development steps include:
3GPP R15.2.0 NRF technical specification can be downloaded from this link 5G System; Network function repository services; Stage 3.
powered by quarkus
Any API is available :
Any NF other than NRF manages the heart-beat with the NRF in order to show it is still operative.
The NRF specification allows the use of PUT or PATCH method for heart-beat. In our case, a NF alternatively uses PUT and PATCH requests for heart-beat. The time interval varies between 3mn to 5mn depending on the NF.
Heart-beat can be observed thanks to our online Jaeger UI. Press Find Traces button wait at least 3mn and press again this button in order to see the new heart-beat requests.
Heart-beat at NRF side will be implemented later.
powered by quarkus
API fully available
not available
NRF forward and redirection are not available.
NRF registration to another NRF is not available.
3GPP R15.2.0 AMF technical specification can be downloaded from this link 5G System; Access and Mobility Management Services; Stage 3.
Served response payload contains randomized values based on their type definitions. Business logic is not yet available.
powered by quarkus
The NAMF Communication service automatically registers with the nnrf-nfm service when starting. Its NFType is AMF and its serviceName is namf-comm. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
powered by quarkus
The NAMF Event Exposure service automatically registers with the NNRF-NFM service when starting. Its NFType is AMF and its serviceName is namf-evts. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
powered by quarkus
The NAMF Location service automatically registers with the NNRF-NFM service when starting. Its NFType is AMF and its serviceName is namf-loc. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
powered by quarkus
The NAMF MT service automatically registers with the NNRF-NFM service when starting. Its NFType is AMF and its serviceName is namf-mt. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
3GPP R15.2.0 SMF technical specification can be downloaded from this link 5G System; Session Management Services; Stage 3.
Served response payload contains randomized values based on their type definitions. Business logic is not yet available.
powered by quarkus
The NSMF Event Exposure service automatically registers with the NNRF-NFM service when starting. Its NFType is SMF and its serviceName is nsmf-event-exposure. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
powered by quarkus
The NSMF PDUSession service automatically registers with the NNRF-NFM service when starting. Its NFType is SMF and its serviceName is nsmf-pdusession. It manages the NF heart-beat. Its NF profile can be downloaded from this link.
Many operations have two content types application/json and multipart/related. Depending on the context, the response content type can be application/json or multipart/related. For instance in case of error on receipt of a multipart/related request, the producer must serve the N1 and N2 parts in the error response. The following HTTP captures show some of these use cases.
These captures come from our integration tests of our in-house Nsmf_PDUSession service.
Metrics are exposed for the following NF services:
Current metrics are of types Meter and Timer. There is one metric per type for any API operation. The format of the metrics is Prometheus text-based format. Of course, the exposed metrics can be consumed by a Prometheus server
Any HTTP request between NF is traced. Jaeger is our end-to-end distributed tracing solution (https://www.jaegertracing.io/). Please visit our online Jaeger UI.
We built a native quarkus docker image for the namf-mt service based on quarkus 1.8.3.Final. It started in just 51ms (logs). Quarkus is supersonic.
This dramatic cold start time must be compared to around 4s for the jvm quarkus docker image and to the 20s for the thorntail docker image.
PC hardware is based on Intel(R) Xeon(R) E-2286M CPU@2.40GHz 32GB RAM with 512GB Toshiba(R) SSD.
In addition to the jvm mode, Quarkus provides a native mode. Native mode is about the built of a native executable file like a C/C++ compiler does. Native executable speeds up the cold start time. From the building a native executable guide, we built a MS Windows 10 (R) native executable (quarkus 1.8.3.Final) of the namf-mt service without any source code update and any feature loss (native build logs).
As expected, the cold start time dramatically speeds up to around 500ms compared to 5s for the quarkus jvm mode compared to 20s for the thorntail docker image.
Here are the logs when namf-mt service native executable starts (including registration to NRF).
PC hardware is based on Intel(R) Xeon(R) E-2286M CPU@2.40GHz 32GB RAM with 512GB Toshiba(R) SSD.
Migration of source code base of SMF services from thorntail (2.7.0) to quarkus (1.8.3.Final).
Please visit quarkus home page in order to know this framework and its benefits.
The migration has been motivated by the fact that quarkus has become mature and thorntail had been announced end of life.
The migration of the source code base has been done without any feature loss.
Attributes with null value are not serialized in JSON payload body.
Migration of source code base of SMF services from thorntail (2.7.0) to quarkus (1.8.3.Final).
Comparison table between thorntail and quarkus frameworks for the same service nsmf_event-exposure and nsmf-pdusession with the same source code base.
| nsmf_event-exposure | thorntail (2.7.0) |
quarkus (jvm) (1.8.3) |
| cold start time (s) | 19 | 4.8 |
| graceful shutdown time (ms) | 300 | 100 |
| RSS (MB) | 899 | 253 |
| uber jar size (MB) | 113.64 | 34.96 |
| Docker image size (MB) | 153.34 | 71.37 |
| nsmf-pdusession | thorntail (2.7.0) |
quarkus (jvm) (1.8.3) |
| cold start time (s) | 19 | 4.9 |
| graceful shutdown time (ms) | 130 | 180 |
| RSS (MB) | 810 | 247 |
| uber jar size (MB) | 113.46 | 35.27 |
| Docker image size (MB) | 153.16 | 71.63 |
Note: Any quarkus jvm application comes with some extensions among them the hibernate-validator extension. This extension is in charge of request validation. It triggers the software layer in charge to serve bad request responses (400) when requests are not compliant to 3GPP 5GC OpenAPI 3 specifications. We observed that by disabling this extension we gain around 1 second on the cold start time.
Upgrade any AMF and NRF service from quarkus 1.6.1.Final version to 1.8.1.Final version.
Migration of source code base of NRF services from thorntail (2.7.0) to quarkus (1.6.1.Final).
Please visit quarkus home page in order to know this framework and its benefits.
The migration has been motivated by the fact that quarkus has become mature and thorntail had been announced end of life.
The migration of the source code base has been done without any feature loss.
Attributes with null value are not serialized in JSON payload body.
Current SMF services powered by thorntail no more register to the NRF powered by quarkus. The register request is rejected by the NRF because the recoveryTime attribute is invalid. It is based on epoch format while it shoud be ISO 8601 format. The legacy NRF powered by thorntail did the conversion silently.
As a consequence, only AMF services can be discovered.
Comparison table between thorntail and quarkus frameworks for the same service nnrf-nfm and nnrf-disc with the same source code base.
| nnrf-disc | thorntail (2.7.0) |
quarkus (jvm) (1.6.1) |
| cold start time (s) | 18 | 2.130 |
| graceful shutdown time (ms) | 130 | 34 |
| RSS (MB) | 910 | 150 |
| uber jar size (MB) | 109.10 | 25.2 |
| Docker image size (MB) | 148.8 | 62.17 |
| nnrf-nfm | thorntail (2.7.0) |
quarkus (jvm) (1.6.1) |
| cold start time (s) | 18 | 3.5 |
| graceful shutdown time (ms) | 300 | 163 |
| RSS (MB) | 877 | 245 |
| uber jar size (MB) | 110.52 | 30.48 |
| Docker image size (MB) | 150.24 | 67.09 |
Note: Any quarkus jvm application comes with some extensions among them the hibernate-validator extension. This extension is in charge of request validation. It triggers the software layer in charge to serve bad request responses (400) when requests are not compliant to 3GPP 5GC OpenAPI 3 specifications. We observed that by disabling this extension we gain around 1 second on the cold start time.
Migration of source code base of AMF services from thorntail (2.7.0) to quarkus (1.6.1.Final).
Please visit quarkus home page in order to know this framework and its benefits.
The migration has been motivated by the fact that quarkus has become mature and thorntail had been announced end of life.
The migration of the source code base has been done without any feature loss.
Attributes with null value are not serialized in JSON payload body.
Comparison table between thorntail and quarkus frameworks for the same service namf-comm with the same source code base.
| namf-comm | thorntail (2.7.0) |
quarkus (jvm) (1.6.1) |
| cold start time (ms) | 15000 | 2598 |
| graceful shutdown time (ms) | 198 | 73 |
| RSS (MB) | 866.78 | 160.25 |
| uber jar size (MB) | 113.87 | 30.60 |
| Docker image size (MB) | 150.8 | 64.60 |
Note: Any quarkus jvm application comes with some extensions among them the hibernate-validator extension. This extension is in charge of request validation. It triggers the software layer in charge to serve bad request responses (400) when requests are not compliant to 3GPP 5GC OpenAPI 3 specifications. We observed that by disabling this extension we gain around 1 second on the cold start time.
Adding Nsmf_PDUSession service request examples request examples.
Adding Nnrf_NFManagement GetNFInstances request example.
Adding Health sections for each NF.
Adding PATCH and DELETE subscription request examples related to Nnrf_NFManagement service.
Adding subscription and notification request examples related to Nnrf_NFManagement service.
Adding many request examples related to Nnrf_NFManagement service and Nnrf_Discovery service .
Adding some Nnrf_NFManagement RegisterNFinstance request examples.
The following features are now available:
Special thanks to Dinh Hoang Tran for his significant contribution.
Upgrade to thorntail 2.5.0
Expose metrics for any AMF service
Add metric paragraph and links
Expose metrics for any NRF service
and any SMF service