magma / grants

Connecting the Next Billion People

Magma is an open-source software platform that gives network operators an open, flexible and extendable mobile core network solution. Magma enables better connectivity by:

• Allowing operators to offer cellular service without vendor lock-in with a modern, open source core network
• Enabling operators to manage their networks more efficiently with more automation, less downtime, better predictability, and more agility to add new services and applications
• Enabling federation between existing MNOs and new infrastructure providers for expanding rural infrastructure
• Allowing operators who are constrained with licensed spectrum to add capacity and reach by using Wi-Fi and CBRS

Magma Architecture

The figure below shows the high-level Magma architecture. Magma is 3GPP generation (2G, 3G, 4G or upcoming 5G networks) and access network agnostic (cellular or WiFi). It can flexibly support a radio access network with minimal development and deployment effort.

Magma has three major components

• Access Gateway. The Access Gateway (AGW) provides network services and policy enforcement. In an LTE network, the AGW implements an evolved packet core (EPC), and a combination of an AAA and a PGW. It works with existing, unmodified commercial radio hardware.

• Orchestrator. Orchestrator is a cloud service that provides a simple and consistent way to configure and monitor the wireless network securely. The Orchestrator can be hosted on a public/private cloud. The metrics acquired through the platform allows you to see the analytics and traffic flows of the wireless users through the Magma web UI.

• Federation Gateway. The Federation Gateway integrates the MNO core network with Magma by using standard 3GPP interfaces to existing MNO components. It acts as a proxy between the Magma AGW and the operator's network and facilitates core functions, such as authentication, data plans, policy enforcement, and charging to stay uniform between an existing MNO network and the expanded network with Magma.

Documentation

• Magma Website: Project landing page
• Docs: Deployment, configuration and usage information
• Code: Source code
• Contributing: Contributor Guide
• Wiki: Meeting notes and project team resources
• Rewards Program: How to participate in the Magma rewards program

Join the Magma community

See the Community page for entry points.

Start by joining the community on Slack: magmacore workspace.

Direct specific questions to the GitHub Discussions page. Your question might already have an answer!

License

Magma is BSD License licensed, as found in the LICENSE file.

The EPC originates from OAI (OpenAirInterface Software Alliance) and is offered under the same BSD-3-Clause License.

Risks

The Magma materials are provided in accordance with the licenses made available in the LICENSE file. Prior to using the materials, it is highly recommended that you test and verify that the materials meet your specific requirements, including, without limitation, any and all security and performance requirements.

Security

Responsible disclosures from independent researchers are gratefully accepted. See the Security Policy for submission details and Security Overview for Contributors to learn about other ways of contributing.

We wish to acknowledge valuable disclosures by the following security researchers:

• Guarang Maheta
• Phi Trần

grants's Issues

Proposal: Settlement Service for Magma

Proposal: Settlement Service for Magma

Author(s): [@Arsenii-Oganov]

1.0 Objectives

The objective of this work is to extend Magma and the Helium blockchain to add support for settlement interfaces to bridge the gap between traditional roaming settlement and HIP 27s proposal of packet purchasing OUI managed by the helium network operator.
Software built to accomplish this (aka settlement domain service) will be open source under BSD-3-Clause and will reside in the github repository of the Magma software under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.

As a result of this effort, any MNO, MVNO or 3rd party Gateway Manufacturer will be able to use the software to operate their own roaming interconnect with a network roaming into Helium.
Out of Scope: The commercial aspects of how an MNO/MVNO purchases data credits on the Helium network through a session purchaser operator is outside the scope of this document and is a commercial arrangement between the clearing house, session purchaser operator and the MNO.

2.0 Background

The accounting and settlement of a Helium cellular network is unlike traditional cellular settlement. Unlike traditional cellular networks, a Helium cellular network contains radio and accounting entities (e.g. Miners) owned by private parties not affiliated with the core network operator and/or the subscriber home network provider. Additionally, the subscriber home network operator in a Helium network needs a reward path to pay individual radio/miner owners for the data consumed during subscriber sessions that traverse their deployment. A trust-limited accounting system must be implemented to ensure accounting data integrity and secure the reward path.
When creating this accounting system, the goal has been to avoid significant (or any) deviations from traditional 3GPP interfaces to allow maximum portability and lower the barriers to entry for vendors.
The systems centers around the new usage of a standard component, the Online Charging System (OCS). The OCS traditional role is quota management and realtime session management and accounting. In this system, the signaling of standard OCS is repurposed to provide control and accounting functions to a new Helium entity called the Session Purchaser.
The Session Purchasers job is to account and enforce sessions against a subscribers home network operator account on the helium network. The implementation below describes the role and signaling associated with a Session Purchaser.

3.0 Implementation scope

3.1 High - level solution architecture

3.2 End to end scenarios

Below will be described e2e scenarios needs to be implemented in scope of this project (Note: scenarios may be decomposed into different use-cases depends on actors involved and/or business case):

1. State channel management procedure

The procedure describes Opening, Update and Closure of State channel management call flow.
The detailed call flow for the procedure is specified in section 3.2.1 “State channel management procedure”.

2. UE attach procedure

The procedure in which the UE registers to the network, and receives the usage quota to create the EPS Bearer between the UE and the PGW, in order to be able to send and receive data.
The detailed call flow for the procedure is specified in section 3.2.2 “UE attach procedure”.

3. UE quota update procedure

The procedure describes a next quota request by Threshold from the previously received quota from SGW to OCS.
The detailed call flow for the procedure is specified in section 3.2.3 “UE quota update procedure”.

4. UE initiated session termination procedure

The procedure in which the UE initiates session termination. The procedure includes the last quota usage report from SGW to OCS.
The detailed call flow for the procedure is specified in section 3.2.4 “UE initiated session termination procedure”.

5. Network initiated termination procedure

The procedure in which the Network (S/PGW) initiates session termination. The procedure includes the last quota usage report from SGW to OCS.
The detailed call flow for the procedure is specified in section 3.2.5 “Network initiated termination procedure”.

6. TAP-Out generation and exporting procedure

The procedure to generate TAP3 files and transfer the files to the DCH (HPLMN) partner.

7. RAP processing procedure

The procedure to return rejected TAP files and records to the visited network operator for corrections.

3.2.1 State channel management procedure

Following diagram shows e2e State Channel life cycle management that will be in real life. It consists of existing functionality (marked with black), new functionality to be implemented in magma (marked with blue).

This scenario consists of the steps below:

1. Step [1-2] The State channel opening procedure. The Helium Handler sends Open State Channel Request to open the State Channel. State Channel is opened once the positive Response is received from State Channel.
2. Step [3] On this Step the Handler sends the Used Data Credits for each Used Data Quota per Miner pub key.
3. Step [4-5] The State channel closure procedure. The closure procedure contains two type of triggers - all the Data credits have been used from the State channel and end of an Epoch.

3.2.2 UE attach procedure

Following diagram shows e2e UE attach scenario that will be in real life. It consists of existing functionality (marked with black), new functionality to be implemented in magma (marked with blue).
The attach procedure implies that State Channel is already in open state.

This scenario consists of the steps below:

1. Step [1 - 2] Initial attach procedure in a mobile network. The UE establishes radio link synchronization with an eNB, the UE creates a connection for data delivery via an Attach Request message sent to the eNB, the eNB then forwards the attach request to an MME/SGW.
2. Step [3] The SGW sends CCR-I to the Session Purchaser requesting volume quota.
3. Step [4] Session Purchaser checks if the IMSI-prefix (i.e. the HPLMN operator) has balance to answer with granted data units on CCR-I Request which has been received on Step [3].
4. Step [5] In response to a CCR-I (Step [3]), the Session Purchaser returns a CCA-I message that indicates success (DIAMETER_SUCCESS) or failure (DIAMETER AUTHORIZATION REJECTED) depending on whether the HPLMN operator has sufficient credit for the requested services. In case of HPLMN operator has sufficient credit the CCA contains the Granted Service Unit in Bytes.
5. Step [6] The SGW sends signed Session Init Event to Miner. The message is signed with SGW PubKey.
6. Step [7] The Miner sends signed Session Init Event to Helium Handler. The message is signed with Miner PubKey.
7. Step [8 - 9] The Create Session Request and Response messages to establish UE requested PDN connectivity through the SGW and Home PGW.
8. Step [10-15] Establishing radio link between UE and eNodeB for packet data transfer.
9. Step [16-17] Packet data between UE and Internet.

3.2.3 UE quota update procedure

Following diagram shows e2e UE update scenario that will be in real life. It consists of existing functionality (marked with black), new functionality to be implemented in magma and helium (marked with blue).

This scenario consists of the steps below:

1. Step [1-2] Packet data transfer is ongoing between UE and Internet.
2. Step [3] The threshold of the quota is configured on SGW (e.g. 95% of granted service unit).
3. Step [4] In this Step SGW sends Session Update Request with used service unit.
4. Step [5] Session Purchaser checks if the HPLMN operator has balance to answer with granted data units on CCR-U which has been received on Step [4].
5. Step [6] In response to a CCR-U (Step [5]), the Session Purchaser returns a CCA-U message that indicates success (DIAMETER_SUCCESS) or failure (DIAMETER AUTHORIZATION REJECTED) depending on whether the HPLMN operator has sufficient credit for the requested services.
6. Step [7] The SGW sends signed data usage to Miner. The message is signed with SGW PubKey.
7. Step [8] The Miner sends signed data usage to Helium Handler. The message is signed with Miner PubKey.
8. Step [9] The Helium Handler updates State Channel with signed data usage received on Step [8]
9. Step [10-11] Packet data continuation between UE and Internet.

3.2.4 UE initiated session termination procedure

Following diagram shows e2e UE initiated session termination scenario that will be in real life. It consists of existing functionality (marked with black), new functionality to be implemented in magma and helium (marked with blue).

This scenario consists of the steps below:

1. Step [1-2] UE detach procedure in a mobile network. The UE closes radio link with an eNB and MME/SGW.
2. Step [3] In this Step SGW sends Session Termination Request with last used service unit.
3. Step [4] The Session Purchaser update the HPLMN operator balance with last used data units.
4. Step [5] The Session Purchaser sends Response on CCR-T (Step [3]) to close the session.
5. Step [6] The SGW sends data usage to Miner. The message is signed with SGW PubKey.
6. Step [7] The Miner sends data usage to Helium Handler. The message is signed with Miner PubKey.
7. Step [8] The Helium Handler updates State Channel with signed data usage received on Step [7]
8. Step [9] (Optional) The Helium Handler sends FreedomFi balance update to Session Purchaser.
9. This steps checks for discrepancy between FF and OCS, helpful early, hopefully long term becomes less needed.
10. Step [10-11] The Message between SGW to Home PGW once UE Requested PDN Disconnection to close the PDN connection.
11. Step [12-13] MME/eNodeB closes radio link for the UE.

3.2.5 Network initiated termination procedure

Following diagram shows e2e Network initiated termination that will be in real life. It consists of existing functionality (marked with black), new functionality to be implemented in magma and helium (marked with blue).

This scenario consists of the steps below:

1. Step [1] Delete session request comes from home PGW to close the PDN connection.
2. Step [2] In this Step SGW sends Session Termination Request with last used service unit.
3. Step [3] The Session Purchaser update the HPLMN operator balance with last used data units.
4. Step [4] The Session Purchaser sends Response on CCR-T (Step [2]) to close the session.
5. Step [5] The SGW sends data usage to Miner. The message is signed with SGW PubKey.
6. Step [6] The Miner sends data usage to Helium Handler. The message is signed with Miner PubKey.
7. Step [7] The Helium Handler updates State Channel with signed data usage received on Step [6]
8. Step [8] (Optional) The Helium Handler sends FreedomFi balance update to Session Purchaser.
9. Step [9] Delete session response from SGW to Home PGW to indicate the PDN connection is closed.
10. Step [10-11] MME/eNodeB closes radio link for the UE.

3.2.6 TAP-Out procedure

A roaming agreement between the home network operator and the visited network operator defines the terms that enable each other's customers access to the wireless networks. The visited network operator records the activities performed by the roaming subscriber and then sends the call event details to the home network operator in the format agreed upon in the roaming agreement, usually Transferred Account Procedure (TAP) format. TAP is the process that allows a visited network operator to send call event detail records of roaming subscribers to their respective home network operators to be able to bill for the subscriber's roaming usage.

3.2.8 RAP-In procedure

The home network operator validates the data in the TAP files to ensure that it conforms to the TAP standard and to the terms of the roaming agreement. If the received TAP file contains any errors, the home network operator can reject the entire file or only the incorrect call event detail records. The incorrect file or records are returned to the visited network operator in a Returned Account Procedure (RAP) file.
RAP process is used to return rejected TAP files and records to the visited network operator for corrections. A RAP file contains the rejected TAP file or records and additional data about the error, such as the error code or the error cause. The visited network operator corrects the errors and sends the corrected TAP file back to the home network operator.

3.3 Integration interfaces

The following figure shows the integration interfaces between Magma domain and OCS /DCH.

3.3.1 DIAMETER Gy interface specification

Interface transport protocol: TCP/Diameter/DCCA.
The 3GPP based Gy interface between Session Proxy and Session Purchaser to implement real-time quota management for the packet data service for the roaming subscribers. While this interface resembles Gy in almost every way, this is a non-standard use of the Gy protocol defined to allow accounting at the operator level and allow the session purchaser a control point to approve or deny sessions at initiation or at update points throughout a session.
The Session Purchaser is the Diameter Credit Control server, which provides the online charging data to the Session Proxy based on volume quota.
The connection between the Session Proxy (client) and Session Purchaser (server) is TCP based. There are a series of message exchanges to manage quota in real-time.

3.3.2 MME/SGW ↔︎ Helium Miner

Session lifecycle events and usage reports should be delivered from each deployed AGW to the Network-Server (helium-handler), which uses that information to update a state channel. The Helium Miner container does such communication between hotspot(AGW) and Network Server. So, a trusted channel should be formed between MME/SGW and Miner to let a Miner container communicate with the Helium network on behalf of AGW. For having a trusted channel between AGW and Miner new component is introduced - a session-forwarder. Session-forwarder is a mediator between Magma-specific components deployed on AGW and a Helium Miner.
To let Miner trust Session-forwarder, session-forwarder is deployed on the same AGW where software is signed and Linux Secure Boot is used to verify all software components being loaded. So, Miner can trust to all received session-related messages. Miner just does forward all message to helium-handler.

1. Sessiond(Magma component) requires new sessions statistics gRPC stream API.
2. When new session is created or SessionState is updated on sessiond side, sessiond streams those updates via session statistics API to session-forwarder.
3. Session-forwarder talks to helium miner via gRPC.

Sessiond API update:
service SessionStaticsStreamer { rpc SessionStatistics(orc8r.Void) returns (stream SessionStatisticsUpdate) {} }

Miner API update (session-forwarder <-> Miner) :
service api { rpc session_usage(session_usage_update) returns (orc8r.Void) {} }

3.3.3 Helium Miner ↔︎ Network Server (router/helium-handler)

For each 3gpp session Miner should forward session usage stats from Session-forwarder to Network Server.
service api { rpc session_usage(session_usage_update) returns (orc8r.Void) {} }

3.3.4 helium-handler ↔︎ State channel

Helium-handler can straightly verify session_usage_update messages from Miner and trust them because they are signed by Session-forwarder using Miner key. So classic offer/purchase/reject semantics can be eliminated.

1. Initial session negotiation is done between miner and network server (helium-handler).
2. When session is in progress, miner forwards session_update messages which helium-handler adds as cbrs_session_usage_commit messages the state channel.
3. When session is terminated the last cbrs_session_usage_commit is added to the state channel for the session.

message blockchain_state_channel_message_v1 { oneof msg { blockchain_state_channel_response_v1 response = 2; blockchain_state_channel_packet_v1 packet = 4; blockchain_state_channel_offer_v1 offer = 5; blockchain_state_channel_purchase_v1 purchase = 6; blockchain_state_channel_banner_v1 banner = 7; // DEPRECATED blockchain_state_channel_rejection_v1 reject = 8; blockchain_state_channel_cbrs_session_usage_commit_v1 cbrs_session_usage_commit = 9; } }

3.3.5 Session Forwarder ↔︎ CDR/TAP/RAP Engine

Session-Forwarder should send all session details to the CDR/TAP/RAP Engine to generate TAP files.

3.3.6 CDR/TAP/RAP Engine ↔︎ DCH TAP handling system

Interface transport protocol: SFTP.

Roaming outcollect processing is using to track and rate activities of subscribers from other wireless networks that roam on FreedomFi network. Outcollect processing allows to rate the visiting subscribers' roaming usage using InterCarrier Tariff rates and generate TAP files consisting of the visiting subscriber's call event detail records, which should be send to roaming partners along with an invoice to bill them for their subscribers' roaming usage.
Roaming outcollect processing involves:

• Rating the visiting subscribers' roaming CDRs using InterCarrier Tariff rates specified in the roaming agreements and generating TAP files for each roaming partner.
• Handling errors in TAP files returned back in RAP files to FreedomFi from a roaming partner for corrections.

To validate the TAP file, the following types of validations are performed on DCH or/and HPLMN side.

TAP3 fatal error validation:
TAP3 fatal error validation is performed first to ensure all required data is present and valid. For example, if the TAP file is missing a required block, the entire file is rejected and written to a RAP file.

TAP3 severe error validation:
TAP3 severe error validation is performed if fatal error validation is successful. TAP records are validated to check for incorrect or missing reference data or content. For example, if a TAP record is missing a required field, the record is rejected and written to a RAP file, but all other TAP records in the file are processed.

The expected frequency of sending TAP3 files is two tap files in 24 hours.
The expected maximum limit for TAP3 files is 200,000 records, or 50 KB.

TAP3 File Logical Structure:

Mandatory - blue
Conditional - orange
Optional - green

Only the GPRS Call will be used in the the Call Event Details section.

Note: A Notification file is sent where the transfer mechanism is electronic file transfer and there is no data available for transfer.
RAP File Logical Structure:

Mandatory - blue
Conditional - orange
Optional - green

Note: Only one of the elements grouped at Return Detail level is applicable.

4.0 Testing approach

• Main critical parts of the solution will be covered with unit tests
• Lab with inbound roaming will be established for e2e tests
• E2E tests will be done manually in the lab, test scenarios will be upstreamed to Magma repos

5.0 Security

There two main aspects regarding Settlement service security architecture:

• External connectivity through the internet: deployment architecture will require secured IPX connection between Settlement service and external OCS and Blockchain.
• Settlement service internal security will follow in a two-tiered approach:
  • mutual TLS termination at the Orc8r proxy
  • application-level access enforcement

6.0 Team

https://github.com/119Vik
https://github.com/Arsenii-Oganov
https://github.com/Aitend
https://github.com/amarpad
https://github.com/malcolmmadsheep
https://github.com/taaraora
https://github.com/jpad-freedomfi
https://github.com/serhiislobodian

7.0 Roadmap and Schedule

SWE hours approximately: 4500

ONAP/Magma Integration: Helm packaging

During ONAP Integration with Magma, an issue has been identified: Magma K8s resources need to be installed in different namespaces, and therefore be split into separate Helm packages. Is there a delivery date from Magma to deliver it?

ONAP/Magma Integration: Service Assurance feedback

The ONAP team want to move forward with our Network slicing use case, therefore the ONAP team would like to know if there is any feedback on the presentation (ONAP/Magma Service Assurance Integration – KPIs) made by Jorge Hernandez-Herrero last year

Proposal: Fix security gaps in Magma NMS & Orchestrator

Author : Sabitha Atla ([email protected])

Purpose

Intent of this proposal is to address security gaps in Magma NMS and Orc8r leveraging best practices in securing SaaS applications. Proposed solution will be backward compatibile with current version of NMS & orc8r. Proposed soluiton will use open source software framework similar to OPA (Open Policy Agent) for policy and database access layer. Existing RBAC shall be merged into the new UIRP Management service in Magma NMS, While Token middleware, ACL and Policy shall be integrated into the Magma Orc8r through new UIRP proxy service.

Security Gap Analysis on magma Orc8r and NMS

This section summarizes the security gaps in Magma Orc8r and NMS UI.

security gap in Magma NMS

Magma NMS has 3 user roles and does not enforce policy/attributes/advanced role-based access control.
Existing NMS implements a very minimal form of RBAC (RoleBased Access Control) limited to the following hard coded user roles:

• Super Admin -- READ/WRITE Access + Manage other users

• User -- READ/WRITE Access

• Read Only User -- READ access

                    *Figure 1 : Magma NMS to Orc8r API calls limited by 3 User Roles and admin_cert over TLS*

                    *Figure 2 : RBAC security work flow from Magma NMS to Magma Orc8r*

Above roles are enforced only at the MagmaLte level which is a part of NMS. These user roles do not get forwarded to Magma Orc8ras seen in the figure 2.

Security gap in Magma Orchestrator

Magma Orc8r does application-level authentication for 3 identities namely Operator, Gateway and Network using Mutual TLS validation and Access control with accessd service based on the request type and validating the request type with the permissions defined in the stored ACLs (Access Control List) (READ/WRITE/UPDATE).The operator is identified based on the Common Name and SANs in TLS

                 *Figure 3: Magma NMS user request (Add/Get/Update/Config) to Magma Orc8r resources (unsecured)*

Currently Orc8r is not exposed to the end user operating behind the application. However there have been some development in this regard with a recently merged PR [Citation Reference: Orc8r Token PR] that introduces a new Token middleware enabling Orc8r to identify the user behind the application using Authorization header.
In Magma Orc8r, this limits tenant (organisation) user to have granular control over all the REST API endpoints and attributes of the Orc8r. Hence exposing resources (Magma Orc8r REST API Endpoints, network entity and attributes) to anyone with Superuser access in Magma NMS is a security concern for provisioning, configuration updates and deletion operation.
As of now TLS/Certificates between Magma NMS and Orc8r is not helpful for Magma Orc8r to control Add/Update/Delete operation. Any rogue application can use TLS/certificate to add/update/delete Orc8r resources. It is a security threat.

Listed below are some of the unsecured Magma Orc8r resources.

REST Api Endpoint list for Orc8r Subscriber as an example	Unsecured Action allowed
/lte/{network_id}/msisdns	ADD
/lte/{network_id}/msisdns/{msisdn}	UPDATE
/lte/{network_id}/subscribers	ADD
/lte/{network_id}/subscribers/{subscriber_id}	DELETE, UPDATE
/lte/{network_id}/subscribers/{subscriber_id}/activate	ADD
/lte/{network_id}/subscribers/{subscriber_id}/deactivate	ADD
/lte/{network_id}/subscribers/{subscriber_id}/lte/sub_profile	UPDATE

Table 1: examples of Orc8r API Endpoints that do not have access control

However, NMS and Orc8r implement some level of RBAC and Application-level ACLs (Access Control List) respectively but the implementation is not established to support granular authorization of NMS users to Orc8r resources (REST APIs for now) Attribute level authorization is not present in Magma Orc8r or NMS. The risk is any user with Magma NMS superuser access but without knowledge of network entity in Magma Orc8r can provision, delete, modify network entities attributes within Magma Orc8r which is not desirable, and it can disrupt the network of the organization and enterprise tenants.
It becomes major security threat by assigning superuser access to an enterprise tenant user to change/delete other network entities of some other fixed wireless network that is not allowed.
Lack of policy-based access control on Magma Orc8r resources as well as attribute based access control on network entities like subscriber, access, tenants etc is a security gap, solved in this project.
How these security gaps in Magma Orc8r and NMS is resolved is discussed in the next section.

Proposed Solution

Intent of the proposal is to add Policy Based Access Control (PBAC) to control access to the Magma Orc8r resources. All Magma Orc8r resources, routes, services used/accessed through REST API shall be stored in UIRP Database in NMS.

Changes on Magma NMS

The proposal on NMS intends to add extensive user roles, user groups, policy-based access control for Orc8r resources. Add attributes-based access control for the configuration attributes of network Functions of AGW. This proposal intends to add a **new **service, User Identity Roles Policy (UIRP). This would be an extended service to the existing RBAC (Role-Based Access Control) with full backward compatibility to previous versions of Magma NMS. Figure 4 shows the proposed Authorization flow (from 1 to 10) on how an NMS user gets authorized and has a secure connection for all requests from NMS to Magma Orchestrator. Authentication happens at the new UIRP service upon the user sending a request with valid credentials (Username and Password). If the credentials are valid, a JSON Web Token (JWT) of an open standard RFC 7519 [Citation Reference: RFC 7519] token along with the identity (containing user id, user role, token timestamp) of the user encrypted with private key at JWT Issuer, is sent as a response. Subsequently, all resource access requests made it is mandatory to carry a JWT token and an identity encrypted. Those access requests that have a JWT token will be decrypted and by using a public key and be validated. if successfully validated subsequently policy and permission set for the resources are looked upon based on the identity role provided. Resource access requests that do not carry a valid JWT token or don't qualify the authorization criteria are rejected. All transactions will be logged in to an audit log. An audit log is used to provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, event, or device accesed.

                                         *Figure 4: UIRP service proposed for Magma NMS*

Functional Component

• Identities: this module allows Magma NMS superuser to perform CRUD operation on User, Roles, Groups, Organization (tenant). There will be more roles like ProvisionRole (for ADD operation), ConfigRole(Config other than network entities), NetworkConfig(only network entities config), RestrictViewRole(for restricted GET operation). New organizations (tenants) and their users, user groups shall be created, authenticated and then authorized to perform various actions based on his roles and policies assigned.

• User & Credentials: An entity that you create represents the person or service who uses the UIRP user to interact with Magma NMS. Typically, its Username and Password.

• Group: A user group is a collection of UIRP users managed as a unit. An UIRP groups is authorized to perform same actions/operations.

• Roles: in that it is an identity with permission policies that determine what the identity can and cannot do in magma NMS and Orchestrator. However, a role does not have any credentials (password or access keys) associated with it. Instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.

• OPA Policy Service: OPA [citation reference Open Policy Agent] provides a high-level declarative language that lets you specify policy as code and simple APIs to offload policy decision-making, in our case OPA supplies the policy upon request to access any Magma NMS resource or Magma Orc8r resource from the UIRP service.

• JWT Issuer: It is part of UIRP service that deals with generating JWT token which is digitally signed using JSON Web Signature (JWS) and encrypted along with identity of user using provided private key stored within JWT Issuer

• UIRP DB Service: Middleware for UIRP services, which takes care of interactions with the DB and handles all request coming from OPA Policy Services and UIRP DB

• UIRP DB: A MySQL Database holds the actual data for user, roles, policy, groups, resources, organizations, permissions etc.

• Orchestrator & Permissions and Policies: Carries out checks for each request provided by user against policies and permissions from UIRP through a middleware gateway to perform any action

Security features proposed in Magma NMS is explained below:

Authentication Authorization Administration

A new user security model for AAA is being implemented for the digital identity and access management in Magma NMS to manage access to assets and maintain system security.

• Authentication

Authentication is based on the idea that each individual user will have unique information When UIRP is implemented, When a user successfully logs in using their credentials, an JWT Token along with Encrypted Identity is returned, this proposal plans to fortify authentication using UIRP capability.

• Authorization

  Once a user is successfully logged in, a request to access routes, services, or resources (e.g., APIs) on behalf of that user. To do so, in every request, JWT token is validated and user identity is checked so the amount of information and the amount of services the user access depend on the user's authorization level (Roles, Policies, Attributes)

• Administration

A part of Administration is controlling all CRUD operations access on resources, through policies, user roles, attributes. policies and access can be configured, or created new to any users, roles, user group for these resources

Role based access control

A service-based network management system like Magma NMS must have multiple roles for different job functions like Restricted View Role (Read-Only role), View All Role(user role), Config Role for Add/Provision anything except network entities in Magma Orc8r, Network Config Role for network entities in Magma Orc8r, Admin Role for delete resources/entities and administration. A Superuser role in Magma NMS will continue to be there to implement these advance RBAC to identity (users, groups of users, or roles). This can be achieved through UIRP UI. Since this is a extension of existing RBAC it is fully backward compablity.

Policy based access control

It supports environmental and contextual controls, so policies can be set to grant access to resources at certain times and from certain locations and even evaluate relationships between identities and resources. OPA (Open Policy Agent) module handles the decision making of granting a permission upon a user identity request to access a resource

Attribute based access control

This security mechanism defines permissions based on attributes of the different resources available for access and actions that can be performed on it by an identity. A controlled flow is maintained at Magma NMS and Orchestrator to have a lookback at the UIRP for the decision on accessing it each time before an action is going to be performed at a resource.

Database component

OPA DB: (open policy agent) can needs to hold multiple tables hold different data such as user-policy, policy schema, roles, user-roles adaptation, events, logs, stored procedures triggers for policy decision making

• OPA will also need for audit and logs on the same database

• Needs store procedure for advanced / complex queries

UIRP DB: Stores the UIRP Settings and configurations, private keys for JWT Issuer.

changes on Magma Orc8r

There are two new Magma Orc8r components that are a part of this proposal, namely

• UIRP Proxy
• PBAC & ABAC services

A service called accessd inside Orc8r will be extended to support these new components meanwhile keeping the current ACLs (Access Control List) intact. On top of ACLs for northbound REST APIs, this extension will bring policy based access control (PBAC) as well as attribute based access control (ABAC) for authorizing Orc8r Resources (REST endpoints, GRPC calls). UIRP proxy services will bring the policies defined in UIRP (which is a proposed NMS component. Refer section 3.1) inside Magma Orc8r to authorize Magma Orc8r resources.

                                           *Figure 5: New Security features in Magma Orc8r*

Functional Components

A brief breakdown of new functional components of Magma Orc8r is provided below:

UIRP Proxy is a proposed Go service that acts as an interface between existing Accessd service and the policies defined for Orc8r resources using UIRP inside NMS. It will enforce ABAC and PBAC policies defined in NMS UIRP to authorize Orc8r resources. UIRP proxy can be configured using northbound REST API calls from NMS. New swagger handlers will be needed inside Obsidian to facilitate the configuration of UIRP proxy.

PBAC and ABAC Services will enforce ABAC and PBAC at resource level with help of middlewares inside Magma Orc8r.

AUTHENTICATION AUTHORIZATION ADMINISTRATION (AAA)

User identity details inside Magma Orc8r will be managed by new AAA Service. This service will also fetch Roles, Policy, groups, permission defined in Magma NMS OPA or UIRP DB through UIRP proxy in Magma Orc8r UIRP proxy will enforce the policies in place with help of extensions to accessd service in Magma orc8r.

AAA User Interface

Magma Orc8r Security Administration will be done through new AAA UI to manage User Roles, Policy rules for API endpoints, attributes. It will also be used to manage ACLs (Access Control List) inside Magma Orc8r.

ROLE BASED ACCESS CONTROL (RBAC)

RBAC policies will be defined through Magma Orc8rUI and enforced by accessd service with policies stored in replicated database local to orc8r. These policies can be configured using Orc8r AAA UI.

POLICY BASED ACCESS CONTROL (PBAC)

PBAC policies will be defined through Magma Orc8r UI and enforced by accessd service with policies stored in replicated database local to orc8r. These policies can be configured using Orc8r AAA UI.

ATTRIBUTE BASED ACCESS CONTROL (ABAC)

ABAC will be implemented for servicers to protect attributes from unauthorized access. Same can be administered from Orc8r AAA UI.

Delivery Approch

Features will be delivered in 8 milestones. Each milestone will have the following 5 process gates;

1. Design

2. Development & Unit Testing

3. code review

4. Integration testing

5. Resolve integration issues and regression issues

Roadmap

MS/Roadmap : Development effort (Design, Code, UT) against each milestone in person days is captured below:

| Milestone + Date | Module                               | Project__Deliverable__Summary                                                                           | Cost_(USD)
| ---------------- | ------------------------------------ | ------------------------------------------------------------------------------------------------------- | ------------------------ | ---------- |
| MS1, Date        | NMS_UIRP_GUI                         | NMS UIRP GUI Wireframe & Code                                                                           | $73542                   |            |
| MS2, Date        | NMS_UIRP_BACKEND, NMS_OPA            | NMS backend for UIRP services, Integration of OPA in NMS_UIRP                                           | $64628                   |            |
| MS3, Date        | NMS_JWT, ORC8R_ACCESSD ,             | JWT Token Issuer in NMS UIRP,  Orc8r Accessd changes                                                    | $60914                   |            |
| MS4, Date        | ORC8R_UIRP_PROXY, ORC8R_POLICIES     | Orc8r UIRP Proxy service Policies implementations in Orc8r                                              | $73171                   |            |
| MS5, Date        | Orc8r_UI_BACKEND                     | Orc8r UI Backend                                                                                        | $68714                   |            |
| MS6, Date        | NMS_UI_INTG, NMS_MAGMALTE_INTG       | Extending the NMS UI to integrate with UIRP UI and Services, Extending Magma LTE for Auth based routing | $63142                   |            |
| MS7, Date        | ORC8R UI, NMS_DB_INTG, ORC8R_SWAGGER | Orc8r UI wireframe and code, Database integration from NMS, Orc8r Swagger                               | $72428                   |            |
| MS8, Date        | INTEGRATION & TESTING                | NMS and Orc8r is integrated with New security hardening                                                 | $39000                   |            |

References

Reference	Resource/link
Magma_Orc8r_architecture	https://docs.magmacore.org/docs/orc8r/architecture_overview
Orc8r Token PR	magma/magma#10250
Open Policy Agent	https://www.magalix.com/blog/introducing-policy-as-code-the-open-policy-agent-opa
TS 133 501 - V15.2.0 - 5G; Security architecture and procedures for 5G System (3GPP TS 33.501 version 15.2.0 Release 15)	https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/15.02.00_60/ts_133501v150200p.pdf
RFC7519	https://datatracker.ietf.org/doc/html/rfc7519

Suggested improvements to Magma Grant process and application template

I recommend the following changes to https://github.com/magma/grants

1. "We typically fund up to a maximum of $100k USD" -> "$1M USD"
2. "Imnplemented" -> "Implemented"
3. (optional) consider removing all items from this list and replacing with a list of solicitations or detailed user stories (initially empty). Explain that user stories can be sent to [email protected] for consideration to be included

I also recommend the following changes to https://github.com/magma/grants/blob/main/template.md

1. "[email protected]" -> "[email protected]"

Dual stack support for user data connections in 5G

Proposal: Dual stack Support for user data connections in 5G

Authors: [email protected]
Last Updated: 2022-01-12

Elevator Pitch

Magma needs to support dual stack to enable operators manage both IPv4 & IPv6 network domains for FWA (Fixed Wireless Access) use cases. For use case details refer to Section 8.2.2 of 3GPP specification TS 129.561. TIP OCN has indicated IPv6 support for FWA as a highly desirable requirement. Refer to REQ-OCN-04 of TIP OCN FWA requirements document.
It gives network operators an open, flexible and extendable mobile core network solution. Deployment of Large Scale NAT (LSN) also known as Carrier Grade Nat (CGN) in IPv6 network domain is easier.
Magma 5G SA FWA deployments will likely have the following scenarios
• Dual-stack connectivity with Limited Public IPv4 Address Pools
• UEs with IPv6-only connection and Enterprise Application end pionts using IPv6 addresses
• IPv4 applications running on a Dual-stack Enterprise node with an assigned IPv6 prefix and a shared IPv4 address and having to access IPv4 services.
• Enterprise Data Centers are accessed by 5G devices that are IPv6 compliant.
• Design of IPv4 subnets for massive IOT use cases is becoming increasingly difficult

Magma 5G SA today has support for IPv6 address allocation to UEs, but does not have complete IPv6 support in user plane for 5G SA deployments.
Wavelabs as a VAR (Value Added Reseller) for magma 5G SA core received RFPs from FWA service providers. Ipv4v6 suppport is a feature asked by all the service providers.

This proposal intends to add dual stack support in user plane to enable IPv6, IPv4v6 based 5G SA FWA deployments and massive IOT deployments.

Total ask

Support of Dual stack feature on to Magma Architecture will be delivered in two milestones.

Contact Information

Prabina Pattnaik ([email protected])

Project Details

To support dual stack 5G SA deployments the following issues need to be addressed on magma;
• Required to support basic PDU Sessions for IPv6 & IPv4v6.
• Need to support N3 and N6 traffic flows with both IPv4 and IPv6 network addresses.
• Need to support Usage report functionality for IPv4v6 and IPv6 PDU Sessions.
• Need to support dual mode gnodeb interface.
• Need to support IPv6 Neighbor Solicitation requests based on local cache information.
• Need to support IP Packet Filter Set:
Source/destination IP address or IPv6 prefix
Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
• Need to support IPV6 Flow Label in the data path

Example GTP Packet with IPv6 support

The below figure shows an example GTP-U packet over IPv6 that carries an extension header for QFI and an IPv6 PDU.
Outer IPv6 Header's DSCP value(EF) is marked at sender tunnel endpoint node based on QFI value which is contained in GTP-U Extension Header (PDU Session Container).

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|     DSCP=EF   |               Flow Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Payload Length       | NxtHdr=17(UDP)|    Hop Limit  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                             +
|                                                               |
+                   Source IPv6 Address         +
|                        2001:db8:1:1::1               |
+                                                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                            +
|                                                               |
+              Destination IPv6 Address       +
|                        2001:db8:1:2::1               |
+                                                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Outer UDP Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Source Port = xxxx        |         Dest Port = 2152      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         UDP Length            |    UDP Checksum (Non-zero)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTP-U header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x1 |1|0|1|0|0|     0xff      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           TEID = 1654                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Sequence Number = 0        |N-PDU Number=0 |NextExtHdr=0x85|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTP-U Extension Header (PDU Session Container)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ExtHdrLen=2  |Type=0 |0|0|   |0|0|   QFI     | PPI |  Spare  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Padding                    |NextExtHdr=0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Inner IPv6 Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|     DSCP=0    |               Flow Label              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Payload Length       |    NexttHdr   |    Hop Limit  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                             +
|                                                               |
+                   Source IPv6 Address         +
|                        2001:db8:2:1::1               |
+                                                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                             +
|                                                               |
+              Destination IPv6 Address       +
|                        2001:db8:3:1::1               |
+                                                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
.                        TCP/UDP/etc., Data                     .
.                                                               .
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Delivery Approach

Feature will be delivered in 2 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
   Before finishing the 2nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

Milestone1 - Support for IPv6 and IPv4IPv6 sessions

Tasks to be handled on Subscriberdb

1. Need to store the IPv6 address as a UE IP address format.

Tasks to be handled on AMF

1. Based on PDU session Type, AMF will support mobilityd interface, Subscriberdb interface.
2. Dual-mode support for PDU session.
3. Sessiond interface support for UE IPv6 address.

Tasks to be handled on UPF

1. GTP tunnel creation for UE Ipv6 address.
2. QoS flow creation for UE IPv6 address.

Unit tests will be added for all new functions introduced.

Milestone2

Support gnb endpoint, enodeb_iface and NAT with IPv6

1. Dual mode IP configuration support on enodeb_iface and NAT interface in config file.
2. Validate Uplink & Downlink traffic flows based on PDU Type
3. Support multi tunnel with IPv6.

Paging Support

1. Sessiond needs to invoke mobilityd servicer to retrieve IPv6 address for the given IMSI.
2. UPF needs to add paging flows in OVS for the UE IPv6.

Support Usage report, charging and credit for IPv6 traffic

1. UPF needs to send the usage report for IPv6 PDU Sessions.
2. Sessiond needs to have IPv6 support for charging, monitoring of PDU Sessions.

Add Unit tests for all modules that are changed.
Make sure the regression tests are passing for all impacted modules.

Test Plan

Following is the set of tests or scenarios to verify dual stack Support.

Integration Testing using UERANSIM or equivalent simulator

1. Execute the PDU Session establishment, Release, Idle mode, Paging sceanrios with IPv4 type.
2. Execute the PDU Session establishment, Release, Idle mode, Paging sceanrios with IPv6 type.
3. Execute the PDU Session establishment, Release, Idle mode, Paging sceanrios with IPv4IPv6 type.
4. Traffic Testing for IPv4 and IPv6

Feature Roadmap

Feature will be delivered in 2 Milestones. Each milestone duration is 45 calendar days.

MS   	        FUNCTIONAL AREA                DELIVERABLES        	            
M1.0        Subscriberdb	              Store IPv6 address as a UE IP 			
			                       address format
		-----------------------------------------------------------------
                AMF, SMF, UPF	  IPv4v6, IPv6 support as UE IP                      
                                              address for PDU session establishment, 
                                              Release, Paging, Idle mode.
                                              UT for all respective modules.
		------------------------------------------------------------------
                Integration Testing	     Integration Test cases are passed on the designated
			                     simulation environment.
----------------------------------------------------------------------------------------------------------
								
M2.0		Dual stack Interface      Dual mode IP configuration support 
                                           in enodeb_iface and nat interface
 					   in config file.
			------------------------------------------------------------------------
	       SMF, UPF	              Usage Report, monitoring              
			                      and charging for IPv6 PDU session.
			------------------------------------------------------------------------
		UPF, OVS	              Traffic flows for N3 and N6 interface
					       with dual mode configuartion.
            -------------------------------------------------------------------------
                  SIT & UAT               Feature is passing all the tests in Real
			                       equipment environment. 
						Feature user / customer runs the confirmance 
						tests and accepts the feature. 
----------------------------------------------------------------------------------------------

References

magma/magma#2999
https://docs.magmacore.org/docs/faq/faq_magma
https://www.ietf.org/archive/id/draft-tang-iiot-architecture-00.html
https://5ghub.us/ipv6-for-5g-transport/
https://www.osti.gov/servlets/purl/1642737
https://www.etsi.org/deliver/etsi_ts/129500_129599/129561/16.04.00_60/ts_129561v160400p.pdf

[Proposal]: To support Mobile Initiated Connection Only(MICO) Mode

Overview & Purpose

Some of the IOT devices require uplink only mode. It means device only will initiate radio connection when it has some data to deliver. 3GPP TS 123.501 defines a new connection mode known as Mobile Initiated Connection Only (MICO) mode. When a MICO activated device is in an Idle state, the magma core network needs to consider the device is unreachable. Transition to Connected state will always be triggered by device. The device will not be paged whilst in MICO mode. MICO mode does not apply to non-3GPP access.

Scope of Work

• MICO is a mode of operation for 5G only devices, connected to 5G Core (5GC), does not apply to non-3GPP access. A device can request the AMF to enable MICO mode. When a MICO activated device is in an Idle state, the 5G network will consider the device to be unreachable.

• The device will only receive MT (Mobile Terminated) data when it transitions to a Connected state.

• The AMF shall include the MICO indication IE in the REGISTRATION ACCEPT message only if the MICO
indication IE was included in the REGISTRATION REQUEST message to indicate that the AMF supports and accepts the use of
MICO mode.

• When AMF indicates MICO mode to a UE, the AMF considers the UE always unreachable while the UE CM state in the AMF is CM-IDLE. AMF rejects any request for downlink data delivery for UE in MICO mode and whose UE CM state is CM-IDLE with an appropriate cause.

• While performing registration with the MICO mode, AMF assigns "all PLMN registration area allocated" in the MICO indication IE in the REGISTRATION ACCEPT message to the UE because network can't perform any signalling towards such kind of UE and there is no optimization required in that context compare to the LTE core network which performs many optimization schemes for tracking area management

• If the UE is not registered for emergency services and Timer is set in the REGISTRATION REQUEST message to activate MICO mode for the UE, AMF includes timer T3324 in the REGISTRATION ACCEPT message in response to UE.

• AMF does not know for how long the UE remains not reachable, thus the AMF shall not immediately de-register the UE. Instead, after the expiry of the Mobile Reachable timer, the AMF will clear the PPF and shall start an Implicit De-registration timer, with a relatively large value. The AMF shall stop the Implicit De-registration timer and set the PPF if the AMF moves the UE CM state in the AMF to CM-CONNECTED state.

Delivery Approach

Feature will be delivered in 2 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues

Before finishing the 2nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

Milestone1

Tasks to be handled on AMF

1. Support for additional IEs in REGISTRATION REQUEST and REGISTRATION ACCEPT messages.
2. Support for active timer and Implicit De-registration timer.

Unit tests will be added for all new functions introduced.

Milestone2

Tasks to be handled on magma SMF and UPF

1. Notification from AMF to SMF to mark the PDU sessions with MICO mode.
2. Notification from SMF to UPF to mark the PDU sessions with MICO mode.
3. Disabling NAS signaling and data traffic during idle mode for MICO mode devices.
4. Disabling paging notifications during MICO mode.

Unit tests will be added for all new functions introduced.

Test Plan

Following is the set of test scenarios to verify MICO mode Support.

1. Testing of new timers implementation.
   a) Active timer
   - Cause of start, when entering 5GMM-IDLE mode after indicating MICO mode activation to the UE with an active timer value
   - On expiry, activate MICO mode for the UE.
   b) Implicit De-registration timer
   - Cause of start, entering 5GMM-IDLE mode over 3GPP access if the MICO mode is activated and strictly periodic monitoring timer is not running.
   - On expiry, implicitly de-register the UE on 1st expiry.
2. End to end traffic testing with activation of MICO mode covering all the scenarios.

Feature Roadmap

Feature will be delivered in 2 Milestones.

---

Milestone	Deliverable Summary
MS1	Magma AMF support
MS2	Magma SMF, UPF support and integration test

References

1. https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/15.03.00_60/ts_123501v150300p.pdf
2. https://blog.3g4g.co.uk/2020/07/mobile-initiated-connection-only-mico.html
3. https://itectec.com/spec/5-4-3gpp-access-specific-aspects/

Update AGW modules to be Network Slice aware

Proposal: Update AGW modules to be Network Slice aware

Elevator Pitch

The future 5G network will support a vast range of innovative services for customers, enterprises, various industrial verticals, federal level demands, and virtual mobile network operators (MVNOs).
According to their different quality of service (QoS) requirements, these services can be categorized as

1. Enhanced Mobile Broadband (eMBB) devours huge chunks of bandwidth (FWA)
2. Ultra-reliable Low-Latency Communications (urLLC require a lightning-fast response time for mission-critical applications
3. Massive Machine-Type Communications (mMTC) stress the number of simultaneous mobile connections

5G network will fulfill these service requirements through a core technology called Network slicing. It is a central pillar of the 5G network, managed with end-to-end (e2e) service orchestration.

Magma being an open-source software platform that gives network operators an open, flexible and extendable mobile core network solution and implementing network slicing feature will enable it to support various use cases such as Fixed Wireless Access (FWA), Private 5G etc.

This proposal intends to make the AGW network functions aware of network slice type support and provide different QoS requirements based on network slice type.

Total ask

Support of Network Slice aware AGW modules on Magma Architecture will be delivered in three milestones.

Contact Information

Moinuddin Khan ([email protected])

Project Details

To introduce the network slice specific services the UE PDU sessions and multiple modules in AGW need to be aware of S-NSSAI. Currently the following AGW modules are considered as a minimum to support network slice aware UE services.

SubscriberDB extensions to support slice configuration

• Subscriber configurations shall be enhanced to accept SliceType-APN/DNN mappings for 5G UE.
• CLI commands shall be provided for configuring subscriber config with associated Slice and APN configurations.
  subscriberdb_cli.py update --lte-auth-key 465B5CE8B199B49FAA5F0A2EE238A6BC --lte-auth-opc E8ED289DEBA952E4283B54E88E6183CA --slice-apn-map {sst:1, sd:"sd1", apn-config: { apn_1: {5,15,1,1,1000,2000,1,,,,}}} --slice-apn-map {sst:1, sd:"sd2", apnconfig: { apn_2: {5,15,1,1,1000,2000,1,,,,}}} IMSI001010000000002
• Subscriber Slice-APN mappings are maintained and extracted by the SubscriberDB process in AGW and provide the APN info to the NFs via RPC responses.
• SubscriberDB shall support processing requests for Slice Selection Subscription data (like Nudm_SDM_Get) from AMF. And In response sends back Slice Selection Subscription data including Subscribed S-NSSAIs.

AMF extensions to support slice configs

• As part of handling NG setup request, shall populate the supported slice info list in NG setup response.
• As part of handling registration request, shall populate the supported slice info in registration accept.
• As part of handling PDU session establishment request, shall populate the slice info in PDU session establishment accept.
• As part of handling Service request, shall populate the allowed slice info in Service Accept.
• In order to support network slicing for UE registration procedure, the UE context shall be modified to maintain info about the allowed NSSAI list by fetching the subscribed NSSAI info from the subscriberDB.
• Shall modify the existing RPCs invocation to include S-NSSAI towards mobilityd.
• Shall modify the existing RPCs invocation to include S-NSSAI info towards sessiond while requesting addition/deletion a particular PDU session.
• Need to extend the support of slice in the stateless feature.

Mobilityd extensions to support slice configs

• UE IP address allocation logic with mobilityd shall consider slice identifier (S-NSSAI) as one constituent of search key.
• Hence, the existing RPCs exposed by mobility to other NFs need to be modified to accommodate the slice info.
• The IP address assignment shall happen from the default IP pool for both 4G and 5G UE sessions.
  1. As there is no network slicing for 4G sessions, while fetching the IP address from the pool, slice identifier will be set to zero or null
  2. For 5G sessions the slice identifier shall be properly set and shall be used as a constituent of the key for fetching IP address from pool

Sessiond extensions

• Modify the related gRPC interface to introduce the S-NSSAI for PDU session management
• Modify handling of AMF PDU session establishment request and response w.r.t S-NSSAI
• Modify PDU session creation/modification/fetching/deletion in RedisDB and in local memory (session map, session store & session state data structures) with S-NSSAI as constituent of key along with PDU session id and IMSI
• sessiond shall support S-NSSAI specific statistics

Delivery Approach

Features will be delivered in 3 milestones. Each milestone will have the following 4 process gates

1. Design
2. Development & Unit Testing
3. code review

Before finishing the last milestone, the feature shall pass the following process gates 4. Integration testing 5. System test 6. User Acceptance test

Milestone1 – UE registration related subscriberDB and AMF network slicing changes

Tasks to make SubscriberDB and AMF network slice aware.

1. SubscriberDB extensions to store subscriber S-NSSAI details
2. Changes in gRPC interface between subscriberDB and AMF to accommodate S-NSSAI
3. Existing CLI command modification to accept slice-apn mappings
4. New UTs will be added and existing ones will be modified as required.

Milestone2 – IP address reservation taking network slicing into account

Tasks to make mobilityd network slice aware and allocate ip addresses taking S-NSSAI into consideration.

1. Mobilityd extensions to reserve UE IP per slice.
2. Modify the CLI commands to include S-NSSAI as key for reserving IP address
3. Enhancement to existing RPCs in between mobilityd and AMF to include S-NSSAI info
4. New UTs will be added and existing ones will be modified as required.

Milestone3 – PDU session management taking network slicing into account

Tasks to make AMF, sessiond network slice aware.

1. Enhancement to

   • UE context modification in AMF to handle S-NSSAI info
   • NG setup procedure to handle S-NSSAI info in AMF
   • processing Service request w.r.t network slice info and populate the allowed slice info in Service Accept.
   • existing RPCs between sessiond and AMF to include the S-NSSAI for PDU session management
   • processing of PDU session request and sending response w.r.t network slice info in sessiond
   • processing of gRPC PDU session response at AMF - slice specific statistics in sessiond

2. New UTs will be added and existing ones will be modified as required.

Test Plan

Primarily targeted to test the network slicing is achieved during the 5G call flow which is mapped to PDU session creation/deletion. Following is the set of tests or scenarios to test the feature.

Integration Testing will be performed using simulators

1. 5G call flow is working with Network Slicing
2. Existing 4G call flow should work with no slicing
3. Scale and other related tests to be performed
4. Negative scenarios related testing to be done

Feature Roadmap

Feature will be delivered in 3 Milestones.

---

Milestone	Deliverable Summary
MS1	UE registration related subscriberDB and AMF network slicing changes
MS2	IP address reservation taking network slicing into account
MS3	PDU session management taking network slicing into account

Reference

---

3GPP Specification	URL
TS29.531	https://www.etsi.org/deliver/etsi_ts/129500_129599/129531/15.00.00_60/ts_129531v150000p.pdf
TS23.501	https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/16.06.00_60/ts_123501v160600p.pdf
TS23.502	https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/15.03.00_60/ts_123502v150300p.pdf

Single Network Slice Support per AGW Node

Proposal: Single Network Slice Support per AGW Node

Elevator Pitch

Intent of the proposal is to extend the current magma architecture to support single network slice per AGW and introduce
the base framework needed to support multiple slices per AGW.
Introducing NSSF as a new service, to select the optimal network slice available for the service requested by UE.
According to 3GPP TS29.531, section 5.2, Nnssf_NSSelection Service offerings by NSSF is to retrieve the information related to network slice.

Current proposal deals with interfaces towards Network Slice Selection service and the AMF interactions with NSSF during registration, pdu establishment procedures.

Out of scope:

• According to 3GPP TS29.531, section 5.3, Nnssf_NSSAIAvailability Service offerings are not mentioned in this proposal.
• Network slice selection in roaming scenarios is not considered.
• Network Repository Function (NRF) service offerings and interactions with other AGW services are not considered.

Total ask

Support of Single Slice per AGW on to Magma Architecture will be delivered at a total cost of: $261000

Project Details

To support single slice per AGW, enhancements to AGW services, subscriberdb, policydb, sessiond are detailed below.
NSSF is the new service that will be introduced in AGW to retrieve the network slice information.
The below explained features of NSSF shall provide base framework to support dynamic slice in AGW.

NSSF

• According to 3GPP TS29.531 v15.1.0, section 5.2.2.2, Nnssf_NSSelection service offers GET operation to retrieve the network slice info.
• To process the NSSF_NSSelection GET request, NSSF shall hold the info of Slice Instances, Configured Nssai in TA (PLMN+TAC).
• NSSF shall accept the configurations (through CLI and Orc8r)

• Below diagram represents SliceSelection(NSSF_NSSelection_Get as per 3GPP standard) interface, NSSF shall support to interact with AMF to select/retrieve slice info during registration procedure.

From the above figure

• UE initiates Registration request, with NSSAI – Requested NSSAI.
• MME(AMF) connects to SubscriberDB for authentication. SubscriberDB returns the security tokens to MME(AMF) to authenticate UE. MME(AMF) completes authentication of UE.
• MME(AMF) initiates GetSubscribedNssai(Nudm_SDM_Get as per 3GPP standard) to retrieve the Slice Subscription data of UE from SubscriberDB.
• SubscriberDB returns the Subscribed Nssai of UE, which was added by operator.
• MME(AMF) validates If requestedNssai not in SubscribedNssai, initiates rpc SliceSelection() to retrieve the network slice info.
• NSSF compares the UE requestedNssai and TAI info with the SupportedNssai per TA list. And with the below conditions returns AuthorizedNetworkSliceInfo
  • If no match, NSSF fills the rejectedNssai per TAI
  • Else if, requested Nssai matches SupportedNssai in TA, NSSF returns the AllowedNssai, NSIId (Network Slice Instance Identifier), AGWNodes list where slice is supported.
  • Else, NSSF fills the rejectedNssai per TAI
  • MME(AMF) verifies if itself is part of targetAmfSet from the NSSF response (AuthorizedNetworkSliceInfo), else send Registration reject.

Note: AMF Re-allocation is not considered in this proposal.

• MME(AMF) stores the NSIId in the UE context, and uses it during PDU establishment procedure.
• As this proposal deals with single slice per AGW, by default NSIProfile shall be created by operator to map the default Network Slice Instance to the supportedNssai in the list of TrackingAreas.
• As represented below, NSSF shall be responsible to provide the details of default NSIId when requested by AMF for the allowedSnssai.

NSSF Configuration

Below Orc8r APIs shall be supported, to configure NSSF. These APIs will be extended to support dynamic network slices in AGW.

NSSF CLI stub will be implemented in a similar line to operate AGW in headless mode.

---------------------------------------------------------------------------------------------
|      NSSF Orc8r API                          |        Description and Payload             |
|----------------------------------------------|---------------------------------------------
| /lte/{network_id}/nssf/configurednssai       | Configure Supported NSSAI per TAI.         |
|                                              | Attributes:                                | 
|                                              |           ConfiguredNssaiList              |
|                                              |           PLMN                             |
|                                              |           TAC                              |
|----------------------------------------------|--------------------------------------------|                                              |                                                       |
|  /lte/{network_id}/nssf/nsiprofiles          | Configure NSIProfiles.                     |
|                                              | Attributes:		                    |
|                                              |           ProfileName                      |
|                                              |           NSIId                            |
|                                              |           Nssai                            |
|                                              |           targetAmfSet                     |
|----------------------------------------------|--------------------------------------------|

NMS

• NMS UI shall provide options to configure Slice-APN mappings for subscribers.
• NMS UI shall be enhanced to configure policy based on IMSI + Slice + APN.

AMF

• During registration procedure, UE context shall be modified to maintain info about the allowed NSSAI list by fetching the subscribed NSSAI info from the subscriberDB and authorized slice info from NSSF.
• Shall modify the existing RPCs invocation to include slice towards mobilityd.
• Shall modify the existing RPCs invocation to include slice info towards sessiond while requesting addition/deletion a particular PDU session.

Delivery Approach

Features will be delivered in 3 milestones. Each milestone will have the following 4 process gates

• Design
• Development & Unit Testing
• Code review

Before finishing the last milestone, the feature shall pass the following process gates

• Integration testing
• System test
• User Acceptance test

Milestone1 – Design doc, AGW- NSSF Framework initialization + CLI stubs

• Deliver the design doc for NSSF support in AGW
• NSSF as new service in AGW. Init framework, db initialization, data structures.
• NSSF Proto and library generation
• Implement NSSF CLI stub to accept configurations
• AGW NSSF UT
• AGW system level scripts to bring up new service – NSSF

Milestone2 - AGW-NSSF-SliceSelection - Registration

• Implementation of gRPC interface SliceSelection(SliceInfoForRegistration) in NSSF service
• AMF extensions to interact with NSSF during registration and PDU establishment procedures, UTs
• Addition of positive and negative UT testcases in NSSF
• Addition of positive and negative UT testcases in AMF

Milestone3 - AGW-NSSF-SliceSelection – PDU Establishment

• Implementation of gRPC interface SliceSelection(SliceInfoForPDUSession)in NSSF service
• AMF extensions to interact with NSSF during registration and PDU establishment procedures, UTs
• Addition of positive and negative UT testcases in NSSF
• Addition of positive and negative UT testcases in AMF

Milestone4 - Orc8r support to configure NSSF

• Implement new service - SliceManager, initialization of new Orc8r service, gRPC ports, DB initialization,
• Implementation of swagger, obsidian handlers, validate functions, invoke configurator to store data in DB
• Slice Manager UT - for obsidian handlers
• Implement SliceManagerCloud RPC servicer which shall populate the data to AGW, Define protos (messages, interfaces)
• Implement UT for SliceManagerCloud RPC Servicer

Milestone5 - Orc8r and NMS Support to configure Subscriber Slice+APN mappings

• Define swagger models and APIs to accept subscribed nssai and default nssai.
• Define obsidian handlers, validation functions
• Updates to subscribedDB Unittest cases
• Add/Update UI pages to configure Subscriber - Slice + APN mappings
• Updates to NMS module unittestcases

Test plan

With the introduction of NSSF, below is the plan to verify single slice per AGW

• Regular 5G call flow verification with the inclusion of NSSF feature.
• Verification of negative cases for slice selection during control procedures.
• Verification of regression and scale tests.

Feature Roadmap

Feature will be delivered in 3 Milestones.

---

Milestone	Deliverable Summary
MS1	Design doc of NSSF. Launch NSSF as new service, NSSF CLI stub to configure SupportedNssai in TA, SliceProfiles in AGW headless mode
MS2	Implementation of SliceSelection gRPC interface of NSSF for SliceInfoForRegistration. Slice selection procedure by AMF during registration
MS3	Implementation of SliceSelection gRPC interface of NSSF for SliceInfoForPDUSession. Slice selection procedure by AMF during registration
MS4	Orc8r supports configuring NSSF. Implement New service in Orc8r.
MS6	Orc8r and NMS support to configure Subscriber Slice-APN mappings. Policy configs for IMSI + Slice + APN.

References

• https://www.etsi.org/deliver/etsi_ts/129500_129599/129531/15.00.00_60/ts_129531v150000p.pdf
• https://www.etsi.org/deliver/etsi_ts/123500_123599/123501/16.06.00_60/ts_123501v160600p.pdf
• https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/15.03.00_60/ts_123502v150300p.pdf

CG-NAT support on magma to scale up concurrent sessions

Proposal: CG-NAT support on magma to scale up concurrent sessions

Authors: [email protected]
Last Updated: 2022-01-12

Elevator Pitch

Proliferation of wireless and Internet-enabled devices drove the creation of IPv6 as IPv4 addresses were rapidly depleted. All of the RIRs (regional Internet registries) have exhausted off their IPv4 allocations. IPv6 adoption has finally taken off due to wide support from technology vendors and service providers. Given that IPv4-addressed infrastructure will be around for a long time, it is up to service providers to make IP address translation transparent to users. FWA Service providers need a solution that will help them seamlessly optimize network operations that have both IPv4 and IPv6 addressed traffic.

3GPP TR 123.975, CG-NAT recommends service providers deploy native network address translation solutions such as NAT44 and NAT64. It provides carrier-grade scalability by offering a very high number of IP address translations, very fast NAT translation setup rates, high throughput, and high-speed logging. TIP FWA requirement REQ-OCN-14 asks for CG-NAT support on OCN.

Wavelabs as a VAR (Value Added Reseller) for magma 5G SA core received RFPs from FWA service providers. CG-NAT is a feature asked by all the service providers.

CGNAT must be deployed to enable key capabilities such as:

1. Enablement of IP address expansion by relying on the CGNAT to overcome the IPv4 address exhaustion, with the support of NAT64/DNS64 and NAT46 seamless IPv4/v6 connectivity
2. Enhanced threat prevention by hiding subscribers’ and infrastructures’ IP addresses from the Internet.
3. High scalability to support the rapid growth in the number of subscribers and devices to substantially increase revenue.

Total ask

Support of CGNAT feature on to Magma Architecture will be delivered in two milestones.

Contact Information

Prabina Pattnaik ([email protected])

Project Details

This Proposal intends to implement python based CGNAT and integrate with pipelined. It generates CGNAT rules using netmap and handled by pipelined on UPF.

The Implementation is a "py-cgnat" Python library and CLI program for generating firewall rules to deploy Carrier-Grade NAT, besides translating a given IP and port to its private address and vice versa. The methodology consists in building netmap rules at 1:32 public-private ratio, mapping a range of 2000 ports for each client. Works for any netmask, since that follow the 1:32 ratio:

The following tasks are need to implement for achieve this functionality:

1. Create a new optional controller based on configuration in pipelined.yml.

2. Define the services in PipelineD for enable or disable.

3. For generating the rules using pycgnat CLI For translating a private IP to its public one, use the direct option:
   pycgnat 100.64.0.0/20 203.0.113.0/25 trans --direct 100.64.2.15
   pycgnat 100.64.0.0/20 203.0.113.0/25 trans -d 100.64.2.15

4. For translatig a public IP and port to its private IP correspondent, use the reverse option:
   pycgnat 100.64.0.0/20 203.0.113.0/25 trans --reverse 203.0.113.20:13578
   pycgnat 100.64.0.0/20 203.0.113.0/25 trans -r 203.0.113.20:13578

5. To use these functionalities directly in new controller using import.

6. Multiple sessions can configure in a iptables single term.

7. Below features are available in controller:
   Generate CGNAT rules for AWS based on Private address pool and Public adddress pool target from netmap.
   Calculate the public IP and port range from private IP given.
   Maintain Dict containing the public_ip and port_range for the query.
   Calculate the private IP and port range from public IP given.
   Maintain Dict containing the private_ip and port_range for the query.

Configure CGNAT

Based on network configuration, Can configure static, dynamic, or dynamic PAT Carrier Grade NAT using Magma Orchestration and CLI.

1. Configuring Static Carrier Grade NAT
   Static address translation (static NAT) allows one-to-one mapping between local and global addresses.

2. Configuring Dynamic Carrier Grade NAT
   Dynamic address translation (dynamic NAT) maps unregistered IP addresses to registered IP addresses from a pool of registered IP addresses.

3. Configuring Dynamic Port Address Carrier Grade NAT
   Port Address Translation (PAT) or overloading is a form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address (many-to-one mapping) by using different ports. PAT enables thousands of users to connect to the Internet by using only one real global IP address.
   

Delivery Approach

Feature will be delivered in two milestone with the following 6 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
6. System test

Milestone1 - Support for CG-NAT and Integrate with PipelineD

Tasks to be handled on new PipelineD controller (CG-NAT App)

1. Generate CGNAT rules for Magma VM on Private address pool and Public adddress pool target from netmap.
2. Calculate the public IP and port range from private IP given.
3. Maintain Dict containing the public_ip and port_range for the query.
4. Calculate the private IP and port range from public IP given.
5. Maintain Dict containing the private_ip and port_range for the query.
6. Make parser as IP:port format into tuple.
7. Split an IPv4 network into a list of subnets according to given netmask.
8. CLI Stub for functionality verification.

Tasks to be handled on PipelineD

1. Add PipelineD config file for enable/disable APP.
2. Add Service manager of pipelined for start the APP.
3. Provide the GRPC method for configure the IP address range.

Milestone2 - Support configuration for CG-NAT using Magma Orchestration and Deploy model.

1. Implement the swagger api for support configuration of CGNAT.
2. Implement the GUI for configuration of CGNAT in NMS dashboard.
3. Implement the interface to configure rules in device.

Unit tests will be added for all new functions introduced.

Test Plan

Following is the set of tests or scenarios to verify dual stack Support.

Integration Testing using CLI Stub.

1. Execute the PDU Session establishment, Release with IPv4 type.
2. Execute the PDU Session establishment, Release with IPv6 type.
3. Traffic Testing for IPv4 and IPv6

Feature Roadmap

Feature will be delivered in two Milestones. Each milestone duration is 45 calendar days.

MS   		FUNCTIONAL AREA       DELIVERABLES        	                  
M1.0		New Controller		  Configure, generating rules,
                                              Parsing.
			----------------------------------------------------					
		PipelineD		      Configure, Start Service,			
			                      GRPC message support                              
			----------------------------------------------------
		CLI STUB		      Add CLI stub for functionality verification
						UT for all respective modules.
			
-------------------------------------------------------------------------------------------

M2.0		Orchestration		  Configuration, generating rules,
                                                       Parsing.
			----------------------------------------------------					
		Swagger API		      Configuration, APIs,			
			                      GRPC message support                              
			----------------------------------------------------
		Interface		      Implement the interface to configure device
						UT for all respective modules.
			------------------------------------------------------------
		Integration Testing	    integration Test cases are passed on the designated
			                        simulation environment.
---------------------------------------------------------------------------------------------------------

Reference

https://www.etsi.org/deliver/etsi_tr/123900_123999/123975/13.00.00_60/tr_123975v130000p.pdf
https://github.com/williamabreu/py-cgnat/blob/master/pycgnat
https://www.fortinet.com/solutions/mobile-carrier/4g-5g/carrier-grade-nat
https://www.f5.com/pdf/products/big-ip-cgnat-datasheet.pdf
https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs-r6-6/cgnat/configuration/guide/b-cgnat-cg-crs-66x/m-implementing-cgn-crs.html#concept_FC12D656CA794B1899D86C2E6E1EF883

Extension of Magma to support EAP-TLS for WiFi Authentication

Overview

Currently Magma supports Carrier WiFi solutions based on EAP-SIM/AKA authentication. Although Magma simplifies the Service Provider and Mobile Operator integration, the solution still requires integration to MNOs core networks which typically requires several months if not years of work. We propose a Magma extension to support EAP-TLS which simplifies and decouples authentication by avoiding complex 3GPP based integration to a mobile core but still provides the same level of seamless and secure authentication. We will present real use cases from MNO’s and Innovators that can greatly benefit from Magma supporting EAP-TLS which can accelerate building out “augmented networks” that can expand network coverage and capacity quickly, simply, and affordably. We will also provide high level end-to-end requirements needed for this project to be successful.

Current Magma WiFi support

Magma’s current WiFi authentication support is based on EAP-SIM/AKA and reusing credentials stored on a device's SIM card. Magma integrates to an MNO’s network using the Federation Gateway. The Federation Gateway talks to existing core elements such as HLR/HSS/OCS/PCRF and etc, over standard 3GPP interfaces. On the Service Provider or ISP side, Magma deploys a CWAG to facilitate secure EAP-AKA/SIM authentications and local breakout. This approach has two challenges that we will address with our EAP-TLS approach:

• Complex MNO Integration (core to SIM or eSIM based authentication) over a 3GPP interface: This integration is simplified using Magma's FeG; however, integration of a new element in an MNO’s network usually takes a long time due to technical and non technical requirements. This is particularly important in one to many or many to many deployments where there is no incentive for ISPs to integrate into the augmented network until an MNO is part of it.
• No support for devices without a SIM card (or eSIM): Since the credentials used for EAP-AKA/SIM are issued by an MNO and stored inside SIM card, devices without a SIM card (PCs, Tablets, etc) are not supported. As we can see in some of the use cases this is very important.

Project Context

Current network augmentation approaches require extensive design, planning, and negotiation with Mobile Operators, Service Providers, Venues, and other Third Parties which are complex, take months to negotiate contracts and end up costing a lot of money. This approach results in internal Mobile Network Operator (MNO) debates on “Build vs Rent” and without a viable “Rent” option, “Build” usually wins out. Further even with “Build” approaches, today’s network capacity is fixed from a user’s perspective and there is no way to request additional capacity in near real-time by an end user, application, or device. For example, for a high-bandwidth, low-latency application that ends up running over a low-performance user link.

Owing to these severe limitations, today Mobile Operators are unable to offer end-2-end QoE on-demand to their subscribers. They offer "all-you-can-eat" data plans but heavily rely on a subscriber's home and work Wi-Fi offload to balance their peak capacity budgets and may risk falling short for performance SLAs. In addition, there are limited options for Operators to switch to a public Wi-Fi hotspot or service, and solutions may require captive portal login, have reliability and performance issues, and may be insecure and untrusted.

These limitations, especially as unlimited plan market adoption accelerates, force MNOs to spend $Billions on augmenting their network infrastructure with cellular technology vs. leveraging Wi-Fi since there are no viable cost-effective and low-complexity alternatives to utilize existing Wi-Fi capacity. This puts tremendous pressure on Operator business models and infrastructure as the Cellular / Wi-Fi usage almost always sways towards Cellular, despite being an expensive proposition. All this is occurring in an ever-increasing competitive market environment with even more challenges on monetizing network investments.

A new approach is to enable Capacity-as-a-Service (CAPaaS) as an end-2-end trusted and comprehensive model that can be rolled out super-fast by MNOs and allow them to leverage existing unlicensed (or loosely licensed) network capacity through a single point of integration on each network thus eliminating complex core integration.

This approach makes network augmentation between heterogeneous networks totally viable, cost-effective, and end users can potentially access capacity whenever they want and wherever they need, with assured QoE.

In 1H/2021, an initial PoC was implemented, tested and demonstrated in a 1:N model (1 MNO : N ISPS) between TIP Menlo Park lab and DT Germany lab with QoS and Pricing policy enforcement. Shown in this video, a mobile subscriber provisioned UE and connected to an LTE network walks into a location with an ISP’s Wi-Fi access points (APs). Scenario: The UE recognizes the trusted AP and the intelligent traffic agent on the UE monitors QoS to assure users' QoE objectives from the MNO’s subscriber SLA are met. As long as the contract terms are met, the UE seamlessly transitions to the augmented Wi-Fi network and the blockchain stores usage metrics for accounting and automated reconciliation and clearing later.

For this Proposal, the goal is to implement EAP-TLS Authentication within Magma to simplify connecting to WiFi Capacity Providers which is critical to establishing the Capacity as a Service (CAPaaS) Ecosystem. In the first phase, SIM authentication was utilized but was deemed not practical for a production system (requires physical SIM distribution and dual SIM devices). An EAP-TLS auth approach was decided as the best to help accelerate the CAPaaS adoption, simplify deployment, and provide operations flexibility for commercialization. From past experience with MNOs/MVNOs in connection management EAP-TLS was the preferred method.

Proposed Final deliverable for the project:
The final deliverable for this project will be to conduct a field trial of the EAP-TLS Auth capabilities in Magma and to evaluate the solution end-2-end ease of integration and system performance in real-world environments. Helium/Freedom Fi and DT also said they will need EAP-TLS auth capabilities for their WiFi initiatives.

Any legacy or other codebases
For initial validation and prototype we will utilize FreeRadius: https://github.com/FreeRADIUS
For AP we will use OpenWRT: https://openwrt.org/docs/guide-user/network/wifi/wireless.security.8021x

For the Mobile client(Android/iOS) we might utilize some OpenSchema legacy gRPC and mTLS implementation: https://github.com/magma/openschema

List if any specific IP licenses utilized: None contemplated at this time.

System Design

There are two main flows/processes to be implemented:

1. EAP-TLS process flow
2. Identity Verification and PKI infrastructure for certificate issuance and delivery.

EAP-TLS

EAP-TLS is a 802.11x based authentication method, specified by RFC 5216 and uses secure TLS handshake to authenticate users to the WiFi network. EAP-TLS is one of the most secure authentication methods and is recommended, endorsed or used by WFA(HS2.0), GSMA for WiFi roaming and 3GPP for integration of non-3GPP elements to WLAN. Eduroam is an example of a global WiFi network based on EAP-TLS with 1,000s of locations and millions of daily users.

Figure below is the typical EAP-TLS process(from [5])

There are two main processes for an EAP-TLS Implementation:

• Out of band certificate management: In this process, Identity of the Client (UEs, Supplicant or Peer) is verified via their Identity Provider and then a client certificate is signed and issued and delivered to the client.
• EAP-TLS: Is the main EAP process in which a Supplicant uses the certificate to mutually authenticate itself to the Authentication Server.

In the proposed design, the following components can be used to extend Magma and implement the EAP-TLS process:

1. A user space application on the Client’s device will be used to verify the user's identity, receive/store/update client certificates, receive profiles and policies, and find and suggest WiFi connections.
2. Magma Orc8r/Cloud element can function as the Authentication Server.
3. Magma CWAG or AP with Embedded CWAG can provide functionality for secure Radius Communication and facilitation of EAP-Process.
4. Magma FeG can provide a proxy for Identity verification as well as an integration point to an external certificate management system.

Identity Verification and PKI infrastructure for certificate issuance and delivery

On the client OpenSchema SDK will be extended to add the Authentication and Onboarding Layer, from the UE CAPaaS feature stack, for EAP-TLS:

Tech Stack

• EAP-TLS will be implemented as specified in RFC5216 https://datatracker.ietf.org/doc/html/rfc5216
• Initial EAP-TLS flow validation will be based on FreeRadius as a reference model and help build unit tests to make development more productive.
• Everything else will be implemented inside Magma and will follow the same process and tech stack as Magma.

Use Cases (User Stories)

Currently there are multiple planned and active projects that will benefit from EAP-TLS support by Magma:

San Diego Promise Zone(SDPZ):

San Diego Promise Zone is one of 22 US Federally assigned HUD Promise Zones in the nation with 30% of population under or unconnected. Currently, Shoelace Wireless is working with UCSD and the Qualcomm Institute, CENIC, Dish, Intel, Montage Connect, and FBC to conduct a Fixed Wireless Access pilot project in the zone. CENIC, which in addition to having a vast network of Fiber Connectivity in the CA (8000 miles of fiber with Internet backhaul connected to 12,000 sites as part of the CALREN Network) is responsible for the recently approved $3 billion CA State budget for middle mile broadband expansion and plans to use this project as an “early win” for the State per their CALREN’s CEO. The Fixed Wireless Access network will be powered by Magma. In order to augment the coverage and serve more people, we are planning to Augment the network by distributing FWA over WiFi. Since delivering SIM cards is not feasible, the only secure way for clients (Mobiles, Tablets, PCs etc) to authenticate on the network will be EAP-TLS.

Helium/FFi/Dish:

Helium and FreedomFi are building a Magma powered 5G network over unlicensed CBRS spectrum. They are creating a vast distributed wireless network that is community built and rewards them with Helium cryptocurrency. Soon the network will be expanded to WiFi per Helium and Freedom Fi discussions. EAP-TLS supported by Magma makes it possible for end users to get on the “People’s WiFi Network” simply by just downloading an App. Getting more users on this network faster (e.g., not waiting for a sim card to be delivered or provisioned) means more rewards and incentives for community network providers and faster expansion of the network.

0Chain:

0Chain has a similar approach to Helium/FFi but they are only focused only on a WiFi network powered by Magma and 0Chain’s blockchain technology. They have been working with Shoelace Wireless, TIP Lab, DT, and Facebook Connectivity(Shah and Evgeniy) on a block chain based augmented network and need TLS for field trials.

DT:

DT has been a big proponent of Magma as an open source converged core solution. As part of their 5G strategy, DT has a #1 initiative to roll out a home converged gateway solution (a CGW with fixed line and fixed wireless backhaul) for home office worker connectivity continuity. CGW provides better and more reliable connectivity for consumers while at the same time enables new revenue streams and monetization opportunities for DT. Each CGW box can also provide a roaming SSID as an augmented and offload network for DT’s mobile consumer. DT states that EAP-TLS is the preferred authentication method for their WiFi onboarding. At Shoelace Wireless, we are currently working with DT on testing our CGW solution and moving to production deployment. Our CGW solution, with Magma EAP-TLS added and bundled with our Smart Connectivity Agent on Mobile Phone, will provide Improved QoE, Seamless offload and Always Best Connected Solutions to DT consumers.

UCSD and Other UCs:

UCSD provides free WiFi to students and faculty and staff. This is technically a zero-cost roaming network for MNOs and MVNOs. Implementing a Magma powered CAPaaS for UC system Campuses can potentially provide a meaningful revenue stream for universities per UCSD’s CIO. By avoiding complications of integration to MNOs for SIM based authentication and by enabling non-SIM devices to connect, Magma with EAP-TLS can turn campus WiFi networks to a secure roaming augmented network for over 400k daily UC users (which is almost 2x LAX daily visitors).

Key Product Requirements

Magma EAP-TLS will be implemented on two main components:

• Client SDK/App: to be deployed on UEs.
• Magma: Access Gateway, Orc8r/Cloud, FeG

Following are the list of Key Requirements for each component:

Req	Component	User Story/Use Case
Client must be able to securely download TLS certificates	Client	All
Client must provide a way for the end user to verify their identity with identity provider	Client	All
Client must be able to find and connect/suggest connection to supported WiFi networks	Client	All
Client must be able to update and manage TLS certificates	Client	All
Magma must provide a method to verify users identities	Magma	All
Magma must implement a secure method to issue/deliver and update TLS certificates	Magma	All
Magma must implement Authentication Server for EAP-TLS process	Magma	All
Magma must add EAP-TLS support to existing Radius server	Magma	All

Project Plan/Roadmap

(A) Client Tasks (Initial focus will be on Android client to perform e2e system validation)

• (A0) Review Client EAP-TLS Flow
• (A1) Design EAP-TLS UE Flow Model and Requirements(UE Cert/Profile Download and Management
  Find and Connect/Suggest WiFi)
• (A2) Design and Build EAP-TLS (CAPaaS) AuthSDK
• (A3) Design and Build UI/UX EAP-TLS Auth PoC App
• (A4) Test and Modify SDK and App

(B) Server Tasks

• (B0) Review FreeRadius EAP-TLS Flow for Magma Design/Implementation
• (B1) Design and Build and Test Magma EAP-TLS Baseline PoC
• (B2) Start Engineering Testing of PoC
• (B3) Design Magma Architecture for EAP-TLS based on PoC(Cert Infrastructure, Identity Management, & Secure Radius and Accounting)
• (B4) Dev and Test Magma EAP-TLS (Engineering Field Test PoC Candidate), Cert Infrastructure, Identity Management, & Secure Radius and Accounting

(C) E2E Test and Engineering Field Trial of Magma based EAP-TLS PoC

• (C0) Integrate and Test with Client
• (C1) Embedded AP CWAG (Non Embedded CWAG Test by TIP Lab)

(D) General Tasks

• (D0) Conduct project kick off and Finalize use cases, solution rqmts, and project schedule
• (D1) Document and Update Magma Repo
• (D2) Project Management

Milestones

Project will have the following deliverables:

• MS1: Complete project kick-off and use cases, solution rqmts, and project schedule doc consistent with Magma's contribution process, reviewed and accepted by Magma TSC. (Tasks: A0, B0, D0). 420 SWE hours.
• MS2: Complete UE EAP-TLS Flow Design and Design/Build/Test Server EAP-TLS Flow for Magma Baseline PoC with Unit tests, submitted as pull request and reviewed by Magma Codeowner. (Tasks: A1, B1). 1050 SWE hours.
• MS3: Complete Design/Build/Test of EAP-TLS AuthSDK and PoC App, and
  Complete Engineering Test of Baseline EAP-TLS Client/Server PoC with Unit tests, submitted as pull request and reviewed by Magma Codeowner. Complete Design of Magma EAP-TLS Architecture based on PoC. (Tasks: A2-4, B2,B3). 1512 SWE hours.
• MS4: Complete Dev/Integration Test of Magma EAP-TLS (Engineering Field Test PoC Candidate) with Unit tests, submitted as pull request and reviewed by Magma Codeowner.
  Complete e2e Engineering Field Trial of Magma EAP-TLS Client/Server PoC Candidate.
  Complete Project Documentation and Magma Repo Updates.
  (Tasks: B4, C0-1, D1-2). 1218 SWE hours.

Test Plan

Following test will be performed:

• Unit Testing Magma, Client and AP components
• Compliance with Magma Regression and CI requirements
• Full end to end verification of EAP TLS flow in Lab
• Filed Trial of the feature with FWA and Augmented Networking

Team Bio

Lead Architect/Dev and Magma Code owner
https://github.com/emakeev

Dev/Test Team:
https://github.com/behrady
https://github.com/emakeev
https://github.com/echiang07
https://github.com/BioZrod
https://github.com/SebastianJM

Bios:
https://www.linkedin.com/in/behrady/
https://www.linkedin.com/in/eduardo-chiang/
https://www.linkedin.com/in/sebasjmdlc/
https://www.linkedin.com/in/jimains/ (Biz Contact)

Project Management:
https://www.linkedin.com/in/jovanyfunes/

Repos:
https://github.com/magma/openschema
https://github.com/shoelacewireless

Shoelace Past Magma Contributions

Shoelace has been working on Magma since early 2019 on projects relating to WiFi offload and Augmented Networks with Deutsche Telekom and other Eco-System Parties. We created and open sourced our data collection agent into Magma (called OpenSchema) which provides critical network metrics for planning and QoE assessment for traffic steering decisioning.

Grant Proposal Criteria Checklist:
✔ Implements or extends features or functionalities of Magma or Magma related Open Source software.
Yes. EAP-TLS Auth is critical for enabling and simplifying Augmented Networking and increasing Magma functionality and adoption.
✔ Fits Magma Interests Areas 1 & 3
1: Support for outbound roaming of Magma subscribers
3: Support for handoff between Magma AGWs and non-Magma 3gpp compliant networks
✔ Timeframe: up to 12 months to Proof of Concept. Yes (~ 7 months)
✔ Licensed openly under the BSD 3 Clause license. Yes
✔ Implemented to the quality standards of the Magma Project as confirmed by one or more then current Magma Codeowners:
Yes, Evgeniy Makeev (Meta Connect , Magma Code Owner)

References

1- Magma Augmented Network Report: https://docs.google.com/document/d/1lS50SR0Vkzi3r8e4zsGaKLbtJqgWrwrje2wgjgPlazU/edit

2- Mobile Data Offload WP: https://cdn.brandfolder.io/D8DI15S7/at/bzhb4s5rmxxs7gfj5mhtsv8/TIP_Test___Integration_Plug-n-Play_Core_Integration_for_Mobile_Data_Offload_MDO_White_Paper_FINAL_June_2021_Green.pdf

3- RFC: https://datatracker.ietf.org/doc/html/rfc5216

4- Helium/FF: https://github.com/helium/HIP/blob/master/0027-cbrs-5g-support.md

5- Moerschel, Grant, Richard Dreger, and Tom Carpenter. CWSP Certified Wireless Security Professional: Official Study Guide (exam PWO-200). McGraw Hill Professional, 2006.

6- TIP WiFi QoE White paper: https://cdn.brandfolder.io/D8DI15S7/at/3qr9r82qxt7gscvxswc7tfk8/TIP_Wi-Fi_HetNet_OpenSchema_QoS_QoE_Score_White_Paper_v10_Final_GREEN_-_Public_Access.pdf

MAGMA Testing Proposal

Proposal Owner : OpenAirInterface Software Alliance (OSA)

Summary

Testing and integration is a continuous effort that is to be managed by an organization that has experience in community software management and experience in telecom R&D. The community members should all share a cozy feeling that such an organization is working for no other purpose than “the common good”. This team also needs to have a certain degree of depth and stability in its governance structure, as well as neutrality, to be able to manage a community-driven initiative. We believe OpenAirInterface Software Alliance (OSA) meets these criteria.

We propose to take the charge of Magma Continuous Integration (CI) pipelines/workflows and release cycle. We will take the charge of maintaining the existing build and testing infrastructure and extending it when new features are added or if testing of some features is missing. Our goal would be to deliver a robust, user-friendly (documented) and fully tested MAGMA core. On top of that, we also propose to extend/improve MAGMA’s deployment compatibility on different platforms like Docker, Vanilla Kubernetes, Enterprise Grade Kubernetes and Public clouds (AWS, Azure and GCP). Once implemented we will maintain these types of deployments and their proper documentation.

All produced code, binaries and documentation will use the Magma-compatible license "BSD 3-Clause License"

Use the google document link for detailed information related to task list and milestones.

Magma GTP Gateway

Proposal: Magma GTP Gateway

Author(s): [@Arsenii-Oganov]

1. Objectives

The objective of this work is to add a GTP aggregation gateway to the Magma system. This Gateway will aid in scale deployments where S8 inbound roaming is supported by reducing the number of integration points for roaming partners.

Software built to accomplish this will be open source under BSD-3-Clause license and will be committed to the Magma software repository under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.

2. Background

In traditional telecom deployments using a centralized (or non-distributed) core, roaming interfaces are limited in number. These interfaces often connect to an IPX/GRX network provider to aggregate roaming traffic into a small set of interfaces, regardless of the number of roaming partners an operator may have.

In the case of S8 roaming interconnections, the connection supports GTP-C and GTP-U traffic between the SGW in the visited network and the PGW in the home network. The SGW IP for the GTP-U endpoint must be routable from the home network. When using an IPX/GRX provider, this means having a globally routable IP address dedicated to the IPX/GRX network interface of an SGW.

Magma has a distributed core architecture. Each cell site, where the Access Gateway (AGW) element usually resides, has an SGW. The requirement that each site have a globally routable IP dedicated to the IPX/GRX connection (i.e. not a general traffic WAN port ISP provided address) is a challenge for operators using Magma core for roaming. Furthermore, IPX/GRX vendors are reluctant to support large numbers of VPN terminations coming from each AGW.

3. Implementation

3.1 Block Diagram

3.2 GTP Gateway Scope of Change

Below are system requirements for the GTP Gateway. These requirements assume the presence of Magma support for:

3.2.1 Wireguard/IPsec support in AGW for S8 GTP traffic

Random TEID assignment for S8 tunnels across AGWs
Wireguard / IPsec Connection Termination
Pipelined supports configuration of Wireguard tunnels which connect automatically when the service is started. These tunnels will be used for connecting AGWs to the GTP Gateway.

The GTP Gateway will need to support termination of 10k wireguard connections per instance. Instances will be horizontally scalable. This will produce a reduction in IP address usage of 1/10,000.

3.2.2 GTP Traffic Flow Learning

GTP traffic needs to be routed to the correct tunnel in the downlink direction. The GTP Gateway will use OVS rules (or potentially another mapping / CGNAT solution) to keep track of GTP tunnel to Wireguard tunnel mapping.

The initial implementation will use OVS to learn flows based on UE APN IP Address. Learning will occur by seeing uplink traffic originating from a tunnel, learning the UE source IP address, and creating a flow mapping for return traffic.

Alternate solutions may use @mark attribute of the sk_buff struct or other native linux networking stack functions/attributes for flow mapping. Such solutions will be explored for scale performance and evaluated against the OVS solution.

3.2.3 Orc8r Integration

The GTP Gateway will be integrated in the Magma ecosystem. Integration will have the following components:

• GTP Gateway will be deployable via a script prepared for bare metal host deployment similar to AGW.

• GTP Gateway will have a connection to orc8r for configuration, health and performance metrics similar to FeG.

• GTP Gateway will include control proxy to allow for gRPC between GTP Gateway and other services in the Magma deployment.

• GTP Gateway specific API endpoints will be created to support configuration and health monitoring:

  • List all GTP Gateways
  • Register a new GTP Gateway
  • Delete a GTP Gateway
  • Get a specific GTP Gateway

3.2.4 Gateway_Health Service

Gateway health service for GTP Gateway will report on the following metrics:

• GTP Gateway specific health which includes:

  • Number of active VPN connections
  • Number of active GTP connections
  • Status of PGW VPN (if present)
  • Total Ingress throughput per NIC
  • Total Egress throughput per NIC

• Generic Health status which includes:

  • Gateway - Controller connectivity
  • Status for all the running services
  • Number of restarts per each service
  • Number of errors per each service
  • Internet and DNS status
  • Kernel version
  • Magma version

3.2.5 HA Active Active

GTP Gateway will be deployed in HA Active Active configuration. GTP Gateway instances do not need to be colocated. Session loading will be balanced between the available instances.

3.2.6 Infrastructure

GTP Gateway will be deployed on Equinix Metal hosts, or other bare metal hosts. Equinix metal C3.Small will be used to start. These hosts support:

• PROC1 x Xeon E 2278G 8-Core Processor @ 3.4Ghz
• RAM 32GB
• 2 x 480GB SSD
• NIC2 x 10Gbps Bonded Ports

This specification will be considered the base supported specification until further performance data is collected.

NOTE: Equinix Metal chosen for it’s access to IPX/GRX network connections.

3.2.7 NMS GTP Gateway

NMS Elements will be created for display of key configuration and health elements including:

• View configuration
• SW Version
• Gateway - Controller connectivity
• Interface IP addresses
• View health metrics
• Number of active VPN connections
• Number of active GTP connections
• Status of PGW VPN (if present)
• Total Ingress throughput per NIC
• Total Egress throughput per NIC

4. Testing approach

• Main critical parts of the solution will be covered with unit tests
• Lab with real inbound roaming scenario will be created
• E2E tests will be done manually in the lab, test scenarios will be upstreamed to Magma repos

5. Security

There two main aspects regarding Roaming Gateway security architecture:

• External connectivity through the internet: deployment architecture will require secured IPX connection between GTP Gateway and HPLMN.
• GTP Gateway internal security will follow in a two-tiered approach:
  • mutual TLS termination at the Orc8r proxy
  • application-level access enforcement

6. Team

https://github.com/119Vik
https://github.com/isergieienkov
https://github.com/Arsenii-Oganov
https://github.com/sudoki2015
https://github.com/berezovskyi-oleksandr
https://github.com/jpad-freedomfi

7. Roadmap & Schedule

SWE hours approximately - 3000

[Proposal]: Refactoring AMF data structures for Stateless feature improvements

Proposal: Refactoring AMF data structures for Stateless feature improvements

Elevator Pitch

In the current design, serializing and storing the in-memory data of AMF into the persistent database (redisdb), requires an additional conversion which can be avoided with some re-structuring in the current AMF code. This additional conversion or mapping from serialized persistent data to in-memory data is done both during storage and re-trivial time.

This proposal shares the approach of using a protobuf-based data structure to optimize the performance and restructuring some fields at ue context level for simplifying the existing design making it more robust.

Total Ask

Stateless feature optimization feature on to Magma Architecture will be delivered in roughly 4 Milestones.

Contact Information

Ganesh Gedela ([email protected])

Project Details

As part of the activity following items are being planned :

• Moving from native C++ maps to protobuf::maps
• Defining 5G proto buffers as required (in case of smf_context) for structure and getting setter/getter APIs.
• Keys that are of type struct need to be converted to strings in order to support protobuf::maps (like GUTI to context maps)
• Replacing existing ue_context, amf_context, and smf_context structures to use structure generated by proto buffer files.
• To remove the inheritance of task-specific StateManager with common StateManager.
• Hashtables in ngap code to be converted to protobuf::maps
• Moving the NGAP code to C++ so that the newly defined structure can be in the required namespace.
• Amf UeContext Storage Management to faster lookup with different key types.

Task

• Using protos (new or re-used) and then replacing the existing structures like "struct ue_m5gmm_context_s", "struct amf_context_s" etc to use new strucutres.
• Adding the changes in all procedures and state machines.
• Replacing all the ngap hashtables
• Unit test cases to be updated (stateless and normal)
• Ngap code to be transitioned to new proto-based definitions and getting them integrated with ASN-generated files.

Statless feature optimization

As part of the optimization, all conversion functions ( to proto format) will be removed as natively the structures are in protobuf format.
All the keys used in lookup need to be stored in string format.

Delivery Approach

The feature will be delivered in 4 milestones. Each milestone will have the following process gates

1. Design
2. Development & Unit Testing
3. code review
4. System testing
5. Scale test

Milestone1 - Restructuring of AMF data structures with Proto generated Ue Context Structure

• Defining the proto buffer definitions.
• Changing GUTI to string format in Amf.
• Optimizing the AmfStateManager.
• Changing the UE, AMF, and SMF Context to proto buffer format. Defining a new class and access functions.
• Update the GUTI string and other struct-based keys.
• Unit test case updates and adding of new cases.

Milestone2 - Refactor UE Context Storage Information in AMF

• Ue context infrastructure to be moved to smart pointers based approach
• Fields specific to smf_context needs to be re-aligned for faster lookup
• Lookups for ue_context to be tuned for faster lookup

Milestone3 - Restructuring of NGAP for C++ tranistion

• NGAP hashtables to Proto Maps conversion
• Moving the code to C++ infratructure
• Optimizing NgapStateManager
• Integrating the ASN files.

Milestone4 - Stateless feature specific changes and verification

• Clean up all the State Manager conversion code.
• Changes in stateless infrastructure for storage and retrieval specific code.
• Integration and scale testing of the feature

Feature Roadmap

The feature will be delivered in 4 Milestones.

Milestone	Deliverable Summary
MS1	Restructuring of AMF code with Proto generated UE Context Structure
MS2	Refactor UE Context Storage Information in AMF
MS3	Restructuring of NGAP for C++ transition
MS4	Statless feature specific changes and verification

Refrences

[Proposal]: Improvements to 5G SA Access Function for Reliability, Maintainability and extensibility

Elevator Pitch

Access side of the magma 5G SA system is expected to meet the reliability demands of operators and enterprises. With every 3GPP release supported on magma, cost of software development is to be optimal. This is possible when system is designed for extensibility and has very minimal modifications. Also, 5G SA core is also expected to address the non functional requirements compiled by TIP. Current proposal addresses some of these requirements by re-designing portions of AMF for better efficiency and optimization.

Total ask

Improving the 5G SA access procedures and data structures will be delivered in roughly 6 Milestones.

Contact Information

Yogesh Pandey ([email protected])

Project Details

Following are the summary of changes :

• Enhancing the NAS5G library to be make use of object oriented approach and new features available in latest C++ libraries with well defined objects and clearly established relations. Bring uniformity across all encoding/decoding classes along with buffer management.

• Optimizing procedure handling logic and state machine making it more robust for expected transitions, failures, timeout handlings etc. Improve the performance numbers.

• Introduce additional counters for debugging purpose to track of all state transitions targeting for production system.

• Introducing CLI framework for AMF to fetch counters and ue context snapshot as required. Required for load & performance of the Appliance is benchmarked.

• Enhance the unit testing infrastructure making it flexible to take any frame sequence and also making use of advanced gmock features for the verification.

Delivery Approach

Scope of this proposal will be delivered in 6 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. regression testing
5. resolve all regression issues Before finishing the last milestone.

Milestone1 - NAS5G library Enhancements

• Re-align the packet message structure identifying the objects and relationships along with mandatory and optional fields
• Shape up a consistent buffer mechanism both for encoding and decoding with validation infrastructure
• Process all the optional fields as per 3GPP spec 24.501 V15.8

Milestone2 - Optimization of existing procedures and state machine

• Amf procedure structure to be flattened with only 2 level hierarchy and simplified fields
• Flatten the hierarchy in various procedures (target is to have only 2 levels of hierarchy like Procedures : Registration -> Security Mode)
• State Machine to be imbibed into the ue_context infrastructure.
• State Machine to have a clear transition map defined (success, failure, timeout)
• Improving the scalability and performance number target for 1200 UEs

Milestone3 - Enhancing the unit testing infrastructure

• To make the unit test infrastructure more flexible in terms of frame or sequence of packet selection.
• To use extended functionality of Gmock framework for validation.
• Possible extensions to decode the packet sent towards NGAP and do more field level validation.
• Extend the coverage for the few more negative scenarios
• Improving the overall Unit testing coverage targeting

Milestone4 - Additional Debug counters and CLI infrastructure for AMF

Task specific to counters

• Adding the critical counters to trace the current state (like amf_context, session context etc)
• Displaying the counters at regular intervals including connected ues, gnb etc.

Task specific to CLI infrastructure

• Python based CLI layer for AMF
• Interfacing with grpc handler and eventually landing on to itti_message infrastructure of AMF
• Targeting to have counter level information for debugging purpose.
• Any critical data structure related information to be fetched as required.

Milestone5 - Code profiling

• Creating a code profiling infrastructure to see the time spend on the critical functions.
• Creating the call flow graph and time spent overall.
• Tuning based on the output from the tool.

Test Plan

Following are the test tools to be used for the overall project

Integration Testing using UERANSIM or equivalent simulator

• For dev testing UERANSIM or equivalent simulator will be used.
• Covering all Mobility Management, Session Management procedures
• Traffic Testing scenarios
• All regression and scale testing to be covered.
• Additional automation testcases to be added.

Roadmap

Feature will be delivered in 5 Milestones. Each milestone duration is 45 calendar days.

---

Milestone	Deliverable Summary
M1.0	MME(AMF/NGAP) NAS5G library Enahncements
M2.0	MME(AMF/NGAP) Optimisations to procedures and state machine
M4.0	MME(AMF/NGAP) Enhancing the unit testing infrastructure
M5.0	MME(AMF/NGAP) Additional Debug counters and CLI infrastructure
M6.0	MME(AMF/NGAP) create profiling and fix issues to optimize call flow graph

References

• https://app.zenhub.com/workspaces/magma-5fac75d3e2cd890011f1677a/issues/magma/magma/9721
• magma/magma#10810
• https://github.com/google/benchmark
• https://www.etsi.org/deliver/etsi_ts/124500_124599/124501/15.03.00_60/ts_124501v150300p.pdf
• https://www.etsi.org/deliver/etsi_ts/123500_123599/123502/15.04.01_60/ts_123502v150401p.pdf

Adding support for Ciphering algorithm 5G SA for NAS data

Proposal: Adding support for Ciphering algorithm 5G SA for NAS data

Elevator Pitch:

Current Magma 5G supports all the mandatory integrity algorithms like IA1 and IA2 but on the Encryption front it supports only the mandatory EA0 which is Null-Encryption. TS 33.501 covers mandatory and highly desirable ciphering algorithms {EA0, EA1, EA2} to be supported. This proposal intends to add support for ciphering algorithms {EEA1 and EEA2}.

As part of this proposal the plan is to enhance security aspects of Magma 5G core and design an implementation to support 128-EEA1, 128-EEA2 as recommended by section 5.5.1 ("Signaling data confidentiality") in TS 33.501.

Total ask

Support of enhanced security algorithm for 5G NAS Layer project is will be delivered in the time frame of 4 Milestones.

Contact Information

Yogesh Pandey ([email protected])

Project Details

The way it will be realized is to extend the current capabilities of magma which will be exchanged and agreed upon during the Security Mode Procedures. Based on the configuration flow the uplink Nas data will be decrypted and downlink Nas data will be encrypted. Decryption might also be followed by integrity protection procedure based on the configuration. Any packet after Security Mode Completion will be accepted based on agreed capabilities.

The sequence for key generation & call flow is covered is shown as below :

128-EEA1 Algorithm

128-EEA1 :Its based on the Snow 3G stream cipher. Snow 3G is a 32-bit word-oriented stream cipher supporting 128-bit keys, which was also part of the 3G standard. The 3GPP standard supports the encryption (128-EEA1) or authentication (128-NIA1) of blocks of data from 1 to 20’000 bits

Encryption

EEA1(key=16b'\xc1', count=0x9955ab, bearer=0x16, dir=1, data_in=50b'MonPantalonS'EstDecousu', bitlen=1149)
b'\xc4\xce\xf2\x98\xf0\x92G\x14T\xdc\x9e\xa6LN\x89\xc3\xb9\xff\xce\xb7\x02\xeei=\xe1ZQ\xe7\xf5\xff\x13\xb6\x94\x8f\x1a<w\xc0'W\xe8\xd0\xcc-\x8c\t\x10\xa4\x0eT!&\x11\\xd1v\x96\xb99l\x0eX\xffaR\xb2\x1d\xe0\x8a\x11\x06\xb9;b\xda\xeb@\xe0#o\xba\x17\x14\xa2j\x8d\xcf\x9a\x84ahTi["u'2\xb5t\x90\x16}\x80\xeb\x9f\xe52\xb3\xdb7\xa1H9\xc0W\x8cA\xd3\xcf0\x04\r\xecv\xea5\xe8\xaar\xf3$\xf9}\x12\xab,W\L\x0f\x9e\x0f8'

Decryption

EEA1(key=16*b'\xc1', count=0x9955ab, bearer=0x16, dir=1, data_in=_, bitlen=1149)
b"MonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPah"

128-EEA2 Algorithm

128-EEA2 :Its based on the AES block cipher. AES is probably the block cipher that has been the most analyzed in the history of cryptography.

Encryption

EEA2(key=16b'\xc1', count=0x9955ab, bearer=0x16, dir=1, data_in=50b'MonPantalonS'EstDecousu', bitlen=1149)
b'-y\xf1\xee\xb7\xe4\x0c\xf2\xdfz`\xb04"\x8c\xda\xc8B!n\x863V"\xaei\x91\x1b\xc5\xfc\x1dx\xb9l\xe8\x99q\q\x88\x91\xc8f\r\x05\xdf\x94S\x97\xc0\x96\xb75\x00@\xfea\x840\xdb\xa3\x88\x15\x03\x9e\xa4\x98\xa5\x82\xb649\xcez5\xd3\x01\x93\x97\x1dpx\xacW\xe9\xb9.mE3\xb9\xc1\xb8\xbd\x06\x8bI\x7f\xf6\x90A\xd3P\xc9\xbe\xbaE\xa8\xbe\xc2GDQ\x17l\xf7\xac\x0f\x96E\xd0}\x8dw\x80k\x8f\n\xeeW\x94\xfa\xa9/\xc2\x02so\xf4yV\xcad\xf0'

Decryption

EEA2(key=16*b'\xc1', count=0x9955ab, bearer=0x16, dir=1, data_in=_, bitlen=1149)
b"MonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPantalonS'EstDecousuMonPah"

Ciphering Inputs and outputs

The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, a 32-bit COUNT, a 5-bit bearer identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.

Summarizing the approach

• Enabling the selection of Encrpytion algorithms in configuration files during start up along (EA0, EA1, EA2 etc.)
• Ensuring the capabilities are exchanged and agreed upon in security mode procedures.
• Add support for deriving the Knas_encryption key from Kamf
• Add decryption support for decrypting uplink messages
• Add encryption support for encrypting downlink messages

Delivery Approach

Feature will be delivered in 4 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. Code review
4. Integration testing
5. Resolve Integration & existing regression issues

System test will be covered as part of Milestone 4.

Milestone1 - Enabling and Selection of Encryption Algorithms

Tasks to be handled:

• Enabling the selection of encryption algorithms based on priority.
• Checking the security capabilities compatibility during the registration procedure
• Derive Knas_encryption key from KAMF

Milestone2 - Packet processing of Encrypted Nas messages for EA1

Tasks to be handled:

• Decrypting of all the encrypted NAS packets post registration based on EA1.
• Sending encrypted packets for any downling message.
• Adding pipeline for packet decryption followed by integrity protection combination
• Unit Testing on all packets including PduSession related, Failure packets, Paging Service Request Packets etc.
• Basic sanity test cases on simulator

Milestone3 - Packet processing of Encrypted Nas messages for EA2

Tasks to be handled:

• Decrypting of all the encrypted NAS packets post registration based on EA2.
• Sending encrypted packets for any downlin kmessage.
• Adding pipeline for packet decryption followed by integrity protection combination
• Unit Testing on all packets including PduSession related, Failure packets, Paging Service Request Packets etc.
• Basic sanity test cases on simulator

Milestone4 - Automation, Regression and Scale test for the feature

Tasks to be handled:

• Automating the testcases for EA1 encryption for all the packet types falling under the category with and without integrity protection
• Automating the testcases for EA2 encryption for all the packet types falling under the category with
  and without integrity protection
• Regression test covering all the feature set
• Scaling tests

Test Plan

Following is the set of tests or scenarios to verify support of ciphering algorithms EA1 & EA2.

• Execute registration procedure in integration test, regression test environments.
• Ensuring all the packets post SMC are decrypted properly and the response if required is send accordingly.
• Coverage of paging scenarios, service request and IPv6 cases will also be done.

Feature Roadmap

Feature will be delivered in 4 Milestones. Each milestone duration is 30 calendar days.

---

Milestone	Deliverable Summary
MS1	Encryption configuration. Exchange & Selection logic. Key derivation. Unit & integraton test
MS2	Supporting EEA1 encryption. Unit testing for all packets. Integration and automation tests
MS3	Supporting EEA2 encryption. Unit testing for all packets. Integration and automation tests
MS4	Systems testing with IPv6, Suci Extension, negetive scenarios and bug fixing

5G Trace Analyzer

Overview

Trace analyzer allows an operator to trace subscriber activity at various points in the network and at various levels of detail in 5G network.
This provides a 3GPP standards-based subscriber session-level trace function for call debugging and testing new functions and access terminals in 5G environment.

Elevator Pitch

The idea is to automatically convert 5G traces (Wireshark, tcpdump) into something readable (SVG sequence diagrams) given that we needed to account for:
• troubleshoot 5G issues in real network
• trace the control plane messaging for a subscriber, for a specific protocol or interface
• trace captures to started and stopped from the NMS, trace captures to be filtered by subscriber/protocol/interface control plane messaging
• Mix of HTTP/2, 5G-NAS and PFCP protocols for 5G trace visualizer
• Sequence details are quite tiring to check in the Wireshark GUI
• Specific versions of Wireshark may be needed to decode specific versions of (e.g.) 5G-NAS
• Mapping of IPs to container names in the deployment
• Mapping of IPs to VM names in the deployment
• Different coloring of the different 5G protocols (NAS, HTTP/2, PFCP, ...), as well as differentiating between requests and responses where possible

Project Details

The or8cr service ctraced can be leveraged to support for display of control flow messages in the form of SVG sequence diagrams in or8cr dashboard.
ctraced supports tracing at subscriber and gateway levels with multiple filters such as interface and protocol levels, can be extended to support all NAS messages and internal messages between Magma core NFs.

Below is the design approach can be adopted to implement the same.
• Imports a Packet Description Markup Language (PDML) file
• Parse http_proto_protocol
• Calculate the length of a packet
• Call wireshark
• Convert a packet to a string
• Generates scatter plots for the given packets
• Output a PackL file
• Order participants
• Convert xml root to JSON
• Parse an HTTP response element

Delivery Approach

Feature will be delivered in 2 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
   Before finishing the 2nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

Milestone-1

Decoding of specific version of 5G-NAS.

Milestone-2

Implementing and integrating plotting Scripts to plot different metrics and data mainly using python packages.

Test Plan

Following is the set of tests or scenarios to verify dual stack Support.

Integration Testing using UERANSIM or equivalent simulator

1. Testing of all 5G-NAS messages and its details using the trace analyzer
2. Verifying all the 5G-NAS sequence flows between different magma NEs

Feature Roadmap

Feature will be delivered in 2 Milestones.

MS	FUNCTIONAL AREA	DELIVERABLES
M1.0	5G-NAS messages	Decoding of specific version of 5G-NAS
M2.0	Plotting Scripts. SIT & UAT	Different metrics. Feature is passing all the tests in Real equipment environment. Feature user / customer runs the conformance tests and accepts the feature.

References

1. https://dl.cdn-anritsu.com/en-us/test-measurement/files/Brochures-Datasheets-Catalogs/datasheet/MX848086A.pdf
2. https://github.com/telekom/5g-trace-visualizer#summary
3. https://github.com/SadeghKrmi/5G-Trace-Analyzer

eNodeBd Enhancements for Cell PnP Support

1 Objectives

The objective of this work is to add services to address the logistics of scale radio deployments using Magma. Specifically, plug-n-play onboarding and firmware update via TR-069.

Plug-n-play onboarding enables auto-discovery and configuration of a new radio connected to a Magma network. This will enable less sophisticated users to add radios to a Magma managed network, as well making it quicker and easier for private cellular deployment users to setup and/or scale their networks.

Firmware update via TR-069 will allow the enodebd ACS to update the firmware on radios connected to the Magma network. Automated and Remote firmware updates are an important requirement for any scale deployment.

Software built to accomplish this will be open source under BSD-3-Clause license and will be committed to the Magma software repository under the governance of the Linux foundation, such that it can be effectively maintained in the future releases. The project will also enable endpoints for more advanced onboarding logic to allow for vendor extensions.

To demonstrate the developed framework, full support for onboarding, configuration, and firmware update will be demonstrated for specific radio models including:

• Baicells Nova 436Q
• Baicells Nova 430
• Baicells Neutrino 430
• Sercomm Englewood

2 Background

2.1: Terminology

1. TR-069 refers to an application layer technical specification of the CPE WAN Management Protocol (CWMP) both specified by the Broadband Forum. This application is used for the remote management of configuration, firmware, and metrics in network equipment

2. ACS refers to the Automatic Configuration Server which is the TR-069 server in a server client model.

2.2 Plug-n-Play
The radio onboarding process for Magma currently follows a pre-provisioning workflow. A user with login credentials for the NMS must complete the following steps:

1. Add a new radio element to the NMS with the following fields:

• Name
• Serial number
• Description
• Externally managed
• Device Class
• Bandwidth
• Cell ID
• RAN Config (FDD/TDD)
• EARFCNDL
• Special Subframe Pattern
• Subframe Assignment
• PCI
• TAC
• Transmit Enable

2. Assign the radio to an AGW

After this process has been completed the enodebd process in the AGW will now respond to the initial TR-069 Inform message and attempt to configure the radio. Enodebd uses the serial number as the key for matching informs to known radio elements.

If an inform message arrives at enodebd with a serial number that is not known, the TR-069 session is terminated and no further action is taken.

2.3 Firmware Update
Magma TR-069 ACS functionality in enodebd currently does not support firmware update procedures.

3 Implementation

3.1 Plug-n-Play

3.1.1 Block Diagram

3.1.2 Call Flow

3.1.3 PnP Scope of Change

3.1.3.1 eNodeBD Service (Modified)
The enodebd service will be updated to support 2 modes of operation, auto-discovery enabled/disabled.
Auto-Discovery Disabled
When Auto-Discovery is disabled enodebd will operate as it does today. When a TR-069 inform message is received with a serial number unknown to enodebd, it will terminate the session without further action.
Auto-Discovery Enabled
When Auto-discovery is enabled, enodebd will receive a new inform, check it’s local configuration to see if the serial number is known, if it is not, it will forward the serial number and device ID field contents to Control Proxy with the endpoint specified as Onboarding Service.

3.1.3.2 Control Proxy Service (Modified)
The Control Proxy service will be modified to add Onboarding Service onboardd to the service registry. This new endpoint will be used for transporting messages between enodebd and onboardd.

3.1.3.3 Onboardd Service (New)
The Onboarding Service onboardd will be a new service added to support automated radio onboarding. The primary function will be to respond to enodebd new radio messages and using the API, create a new radio element and assign it to the source AGW.

In addition, when the new eNB is a CBRS CBSD, onboardd will also create a new radio element in the Domain Proxy (DP). When the radio is a Cat A indoor with a GPS derived location, the onboardd configuration will be sufficient for the DP to register and obtain a grant for the new eNB.

Onboarding Logic
Onboardd will have 2 modes for onboarding, default and vendor.

Default logic will apply a default configuration parameter set when adding the radio via API. The default configuration will be defined in a configuration file. Default configurations will be matched based on Product Class parameter within the Device ID data. If no matching Product Class configuration file is found, a default configuration can be defined. If the default configuration file is empty, auto-discovery is rejected, otherwise settings within are used.

During the configuration, the Cell ID will need to be randomly generated and assigned to both the radio and the orchestrator radio element.

Vendor logic will be configurable to query an external service for radio configuration parameters. Onboardd will have a configuration for the endpoint to be used for vendor logic. If the endpoint configuration is populated, all new radio messages will be forwarded to the vendor logic service endpoint. Vendor logic will return radio configuration parameters for radio onboarding. Examples of vendor logic may include allow/block lists of serial numbers or assignment of serial number specific radio configuration parameters.
Vendor Logic API
To ensure ease of adoption and integration, a API will be defined for the calls to external vendor logic endpoints. The API will include at least radio_parameters_request and radio_parameters_response endpoints.
Domain Proxy Integration
The new onboardd service will support a set of CBRS configuration elements sufficient for adding a radio to the Domain Proxy. In certain cases, the information will be sufficient to also register a new eNB with the CBRS SAS and allow operation without Certified Professional Installer interaction. In other cases, the eNB will be populated with the majority of the data, making it faster and easier for a CPI to quickly review new radios. CBRS Configuration elements will include:

• SAS URL (TBD, may be global)
• SAS User ID (TBD, may be global)
• CBSD Category
• Location (indoor/outdoor)
• Height Type
• Channel Type (GAA/PAL) (TBD, may be global)
• FCC ID
• Radio Technology (LTE/NR)

This dataset will be supported via static files in default configuration mode and via the vendor logic API.

### 3.2 Firmware Update
3.2.1 Block Diagram

3.2.2 Call Flows
User Configuration

FW Update Applied to Radio

3.2.3 Firmware Update Scope of Changes
3.1.3.1 NMS Service (Modified)
The NMS will be updated to allow creation of eNB upgrade tiers including the selection of applicable Device Classes. NMS will also be extended to allow configuration of upgrade tier parameters including :

• FW image URL
• FW metadata
• Username (default = null)
• Password (default = null)
• FileSize
• TargetFileName
• DelaySeconds (default = 0)
• Md5 (Baicells only)
• RawMode (Baicells only, default = false)

In the case of vendor specific configurations, the NMS will allow user selection to include / exclude these elements in the metadata associated with an upgrade tier.
The NMS will also be updated to display FW version for each managed eNB elements.

3.1.3.2 Configurator/lte Service (Modified)
The orchestrator configurator (and/or lte) service will add support for FW image URL and metadata to be added to the mconfig for LTE AGWs. Metadata will include:

• Username
• Password
• FileSize
• TargetFileName
• DelaySeconds
• Md5
• RawMode

3.1.3.3 enodebd Service (Modified)
The enodebd service will be extended to support the new mconfig format with the FW image URL and metadata elements. Enodebd will also add support for the TR-069 FW update call flow shown above using the Download() method and metadata as shown. This method is used by all target radios. Moreover, this method is the basic FW update method defined in TR-069 protocol and is likely to be supported broadly across more TR-069 capable radios.

eNodebd will be extended to capture and report eNB firmware version reported via TR-069 to the orchestrator database. This will be used as the source for version displayed in the NMS.

Update logic will be implemented as part of Device Classes in enodebd so that any radio specific variations can be scope limited to that Device Class, similar to the FSM and data model today.

4. Security

This functionality does not provide any big changes to Magma AGW or Magma Orc8r. Changes will follow common Magma approaches:

• mutual TLS termination at the Orc8r proxy
• application-level access enforcement

5. Testing

• Main critical parts of the solution will be covered with unit tests
• Lab with baicells small cells will be established for e2e tests
• Test scenarios will be upstreamed to Magma repos

6. Team

• https://github.com/119Vik
• https://github.com/Arsenii-Oganov
• https://github.com/berezovskyi-oleksandr
• https://github.com/IgoninVV
• https://github.com/jpad-freedomfi

7. Roadmap & Schedule

Scope items:
MS1: Demonstrate manually triggered firmware update via enodebd TR-069 ACS (Sercomm and 1 Baicells Radio) - Dec 2021
MS2: Demonstrate configurator/lte service creation of updated AGW mconfig triggering firmware update of both radios - Feb 2022
MS3: Complete NMS updates - Mar 2022
MS4: Demonstrate PoC implementation with enodebd talking directly to vendor onboarding server, performing auto-discovery of radio - Dec 2021
MS5: Demonstrate onboardd addition and deployment inside Magma orchestration, including addition to Control Proxy Service Registry - Feb 2022
MS6: Demonstrate message flow through Control Proxy performing Default Logic radio addition using all magma integrated services - Mar 2022
MS7: Demonstrate radio auto-discovery for the 4 radio models shown - Mar 2022
MS8: Launch Magma integrated PnP in the FreedomFi/Helium network using Vendor Logic extension - Mar 2022
MS9: Solution upstream to master - May 2022

SWE hours approximately for proposal: 2500

Proposal: 5G SA community support

Proposal: 5G community support

Elevator Pitch :

Release 1.7 will lay the foundation stone for 5G services, on top of which lot of other use cases will be realized.
Vibrant community members will be experimenting on various 5G services as part of their solutions. During the exercise there will be quite some questions around the offerings, deployment, installation, throughput etc. which needs to be responded promptly.

Through this proposal intent is to provide dedicated community members which can support the queries and also do regular maintenance, throughput benchmarking and validations with new Simulators and real equipment.

Contact Information

Yogesh Pandey ([email protected])

Project Details

Post the foundational releases for 5G SA as part of 1.7, their is a need to have a dedicated team to support various queries from different community members, evaluate any approaches, doing some bug fixing, throughput benchmarking, integrating the software with any updated automated test suites from open source/commercial vendors. Also team will be responsible to support CI/CD activities for 5G sa as required for smoother releases.

Delivery Approach

The team will be divided into 3 groups :

• Testing Group : Will be responsible for analyzing new failures reported, checking on the daily regression report, generating the throughput benchmarks and adding of any new automated testcase as applicable.
• Community Support Group : Will be responsible for responding on the queries from slack or any individual and either solving the query or helping the development/test group to reproduce the specific issues.
• Development Group: Module wise owner will be there to solve specific queries or to check on for a specific request/issue. This will include members for MME, SessionD, Policy DB, Pipelined, orc8r, FeG etc.

Feature Roadmap

There will be a team of 8 engineers working for the support activities.

Deep packet Inspection service to enforce policy rules on 5G SA Deployments

Proposal: Deep packet inspection service to enforce policy rules on 5G SA Deployments

Authors: [email protected]
Last Updated: 2022-01-12

Overview

DPI (Deep Packet Inspection) is a traffic recognition method that classifies IP traffic in real time. DPI identifies protocols, applications and application attributes. In addition to IP traffic classification, DPI engines extract protocol and application-based metadata,
providing insight into user behavior and application usage. Examples of metadata that can be
extracted from IP traffic include the following:

Metadata category Example metadata
Traffic volume Per user, per protocol, per application, per flow, per direction.

Service detection Differentiation between for example Skype audio and video calls

Quality of service Jitter, throughput, latency, roundtrip time, ramp-up time, packet loss,retransmissions

Purpose

TIP OCN Functional requirement REQ-OCN-18 for FWA deployment asks for application detection as a minimum DPI requirement.
Adding DPI support on Magma will help enterprises that subscribe to FWA services get the following benefits

1. DPI is required to deliver real-time intelligence about traffic to create the most effective solution.
2. With DPI-enabled FWA Deployments, operators have the ability to tailor policies and adjust the traffic shaper based on time, package, or applications.
3. DPI will be applied to improve network efficiency, but ultimately it will allow carriers to deliver tailored Edge / Application services that increase customer satisfaction, create differentiation, and provide revenue growth.
4. Policy and charging control: Provides policy control and charging software vendors with the capability to define bandwidth guarantees,
   priorities and limits, offer fine-grained QoS for an additional fee and deliver real-time charging and billing support. It can offers a high detection rate (> 95 %) and accurate application identification for policy and billing purposes.
5. Enterprises can leverage DPI to block or throttle access to risky or unauthorized applications, block policy-violating usage patterns or prevent unauthorized data access within corporate-approved applications, stop data exfiltration attempts by external attackers or potential data leaks caused by both malicious and negligent insiders.

Wavelabs as a VAR (Value Added Reseller) for magma 5G SA core received RFPs from FWA service providers. DPI is a feature asked by all the service providers.

Gap (Design) Analysis

To provide DPI support on magma OVS and Pipelined will need the following changes;

1. Provide the new Opaque DPI Interface that integrates with the open source DPI plugin. (dynamically any 3rd party / external / customer DPI engine can be hooked with OVS seamlessly)

2. Implement the sample plugin will demonstrate the DPI public API that was given for DPI-enabled-OVS. This sample plugin will simply write out the ethernet packet from OVS to a file.

3. Implement the test-dpi plugin, to demonstrate the interfacing capablity of DPI with OVS. This can be extended to full-fledged DPI engine as we now have raw ethernet packet from OVS

4. Implement the DPI engine
   Init the DPI engine
   Destroy the DPI engine
   Traffic processing
   Logging support (which enables plugin developers to log their contents directly into OVS logging framework. A handy tool for debugging & maintenance)

5. Kernel datapath modified to clone all the incoming packets to send it to userspace with special label for DPI.

6. Create DPI controller for marking a flow with an App ID derived from DPI in Pipelined.
   Assigns the App ID to each new IP tuple.

    -------------------------------
    |          Table X            |
    |            DPI              |
    |- Assigns App ID to each new |
    |  IP tuple encountered       |
    |- Requires separate          |
    |  DPI engine                 |
    -------------------------------

Delivery Approach

Feature will be delivered in a single milestone with the following 7 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
6. System test
7. User Acceptance test

The DPI will support for service based and application based traffic.

1. Implement the test-dpi plugin to verify the DPI functionality.
2. Add support for 5G rule policy for DPI services and applications.
   • DPI service interface add with SMF
   • DPId support for L4-L7 polices.
3. Implement the Interface for 3rd party DPI engine can plugin.
4. Integration with network Qos policy.
5. Implement the DPI engine.
6. Implement DPI controller for marking a flow with an App ID derived from DPI in Pipelined.
7. Implement the CLI for support dynamically load any DPI plugin.

Test Plan

• Verify the packet processing in DPI engine using logs
• Traffic Testing UDP/TCP/ICMP with Video/Audio/Chat
• Verify the Logging API to provided to log onto the OVS logfile, directly from dpi-plugin using below Loglevels:
DPIERR DPIINFO DPIWARN DPIDEBUG
• Verify the DPI controller functionality in pipelined using test-DPI controller.
• Introduce a command-line switch to dynamically load any DPI plugin. Here is the syntax
sudo ovs-vswitchd --dpi-engine=

Roadmaps

This section should break out the development roadmap into a number of milestones.

MS1   		FUNCTIONAL AREA       DELIVERABLES        	                    
M1.0		Pipelined	      DPI controller 
                                        Classify the app/service_type
					 to a numeric identifier to export.
			--------------------------------------------------------					
		Sessiond		Support QoS with DPI 			
			                      
			------------------------------------------------------------     
		DPI engine	     DPI enginee with OVS compatibility
			
			------------------------------------------------------------
		DPI-plugin            Provide the DPI public API for 
			               any 3rd party / external / customer DPI engine
 			               can be hooked with OVS seamlessly
			-------------------------------------------------------------
		Integration Test	Functionality verification

Reference

https://www.fiercewireless.com/sponsored/deep-packet-inspection-getting-most-out-5g
https://www.thefastmode.com/expert-opinion/21162-dpi-supporting-sase-for-5g-security
https://www.thefastmode.com/expert-opinion/15934-how-dpi-drives-monetization-in-the-5g-era
https://github.com/kspviswa/dpi-enabled-ovs
https://kspviswa.github.io/dpi-enabled-ovs/

Proposal: Support Application Function to provide private services to customers

Author(s): [email protected]
Last updated: 01/02/2022

Overview & Purpose

Educational institutes and enterprises are looking for Application (Video) services. These application services need support on magma core. TIP OCN requirement REQ-OCN-19 asks to support Application services. For non-MNO network operators, magma opens the market to deploy on campus applications such as OTT, industrial automation, medical imaging etc. To support these services magma needs to implement Application function (AF). This network function acts as an application server to provide support for targeted services. Trusted applications connect via N5 and untrusted 3rd party applications are connected via NEF.
Operators that expressed interest to host application services are looking to host trusted AF. This proposal intends to support trusted AF on magma.
Intent of the proposal is to support the following functionality;
• Applications Traffic Routing
• Expose hosted services to End users
• Interaction with policydb to transfer dynamic QoS-related service information

AF in Magma ecosystem

AF interacts with FeG for Policy Control, Application Traffic Routing, exposing services to End users. AF exposes the Application layer to interact with 5G Network resources (Internet of Things (IoT), device-to-device (D2D) communications, vehicular networking, mobile edge computing (MEC), and cloud computing).
Application-level session information is exchanged between AF and Magma AGW which includes information like Bandwidth requirements for QoS, Identifying Application service providers & Applications, Traffic routing based on Applications access, Identifying Application traffic for Charging & Policy control.
AF supports the Traffic influencing subscription and Packet Flow Description Management functionality to help steer the Edge-specific traffic in UPF towards the applications deployed on the edge node.

Figure 01: AF interaction ecosystem

Deployment View

AF will be hosted in service provider / Enterprise data centre. Orc8r and FeG will be hosted on premises or in public / private cloud. This proposal will limit to CLI as the user interface.

Figure 02: AF Deployment view

proposal

Features of AF

Configuration interface to assign service description, service parameters, identifiers of UE.

1. AF is to lookup the policy using the tuple (UE IP address, DNN, SUPI, S-NNSAI, NSI ID).
2. AF session establishment through application-level signalling protocol.
3. AF session signalling to control the AF session.
4. The traffic flow rules to identify the application traffic, ie. Packet Flow Descriptor (PFD)
   Implement North bound interface to accept application service request.
   Traffic steering NB APIs
   • API Endpoint: /af/v1/subscriptions
   • Supported methods: POST, PUT, PATCH, GET, DELETE
   • Request/Response body: 5G AF North Bound APIs schema using REST-based APIs

AF Session Establishment:
This procedure is triggered when AF user requests to create an AF application session context for the requested service.

Figure 03: AF Session Establishment
AF Session Modification:
This procedure is triggered when AF user requests to update an AF application session context for the requested service.

Figure 04: AF Session Modification
AF Session Termination:
This procedure is triggered when AF user requests to delete the AF application session context.

Figure 05: AF Session Termination
Implement the AF interface exchange using HTTP
• PolicyAuthorization_Create service: This service operation by sending the HTTP POST request with "{apiRoot}/npcfpolicyauthorization/v1/app-sessions" as the resource URI to the FeG
• Handle the PolicyAuthorization_Create response
• Handle PolicyAuthorization_Subscribe service: This operation by sending the HTTP PUT request with "{apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/events-subscription" as the resource URI to subscribe.
• Handle PolicyAuthorization_Subscribe response
Implement N25 Interface towards FeG and Ocr8r coming from AF:
• Implement the HTTP/2 interface for N25
• Handle the decode and encode messages on FeG and Ocr8r.
Implement the Grpc services and methods for subscriberdb.
UPF selection for traffic via N6 interface based on the APN.
Application detection and control – UPF needs to match traffic to an application ID.
As existing header enrichment support in Magma 4G for service header (UE HTTP traffic), This feature would allow operators to enable header enrichment for UE HTTP traffic. This way AGW could add subscriber information to HTTP requests.

The Operator can set target URLs in policy rules via AF. This would enable header enrichment for HTTP requests towards those URLs.
Re-use the existing functionality of service header and configure via AF.
Support plain text HTTP headers for IMSI and MSISDSN. This would be configurable.
Operator needs to set policy rules in AF with target URLs and destination IP addresses. The destination IP address would allow AGW to create an efficient L3 filter for HTTP proxy traffic.
In short header enrichment can be enabled for specific UE traffic to specific destination IP address and to HTTP URL.

Delivery Approach

Feature will be delivered in 4 milestones. Each milestone will have the following 5 process gates
• Design
• Development & Unit Testing
• code review
• Integration testing
• resolve integration issues and regression issues
4th milestone will cover system test as well.

Milestone1 - Support for AF functionality.

Tasks to be handled on new Network Function, AF.
• Implement configuration framework
• Implement Parsing module to encode and decode the North bound interface messages.
• Implement AF Session Establishment, AF Session Modification and AF Session Termination procedures.
• Implement Parser module to encode and decode the N5 interface messages

Milestone2 - Support for AF functionality and handle message flow in FeG and Ocr8r

Tasks to be handled on new NF (AF):
• Implement the AF session and AF session signalling to control the AF session.
• Write stub to verify
Tasks to be handled on FeG:
• Implement local Data structure to Store the Service Information received from AF.
• Implement the Handler to receive request from AF and send response.
• Implement the logic for selection of dynamic policies and install policies according to service consumer provided information.
• Unit testing framework for AF.
• Integration testing.
Tasks to be handled on Ocr8r and Subscriberdb:
• Implement decode and encode the messages from AF on FegRelay
• Implement the Grpc services and methods for subscriberdb

Milestone3- UPF changes for service header handle and QoS handle

Tasks to be handled on UPF
• Implement logic for UPF selection for traffic via n6 interface based on the APN.
• Implement Application detection and control logic based on application ID.
• Assuming existing header enrichment support in Magma 4G for service header (UE HTTP traffic) will be sufficient, no additional effort will be required to support service headers.
• Write stub to verify the functionality.

Milestone4

• UT for AF and SubscriberDB
• Integration tests the feature
• System test

Test Plan

Following is the set of tests or scenarios to verify the Video streaming usecase

Integration Testing using application Stub.

• Execute the PDU Session establishment
• Select the Policy based on provided Service Information.
• Video Traffic Testing on same Policy.
• Execute the PDU Session Termination.
• Execute the PDU Session Modification with update dynamic Policy.

Feature Roadmap

Feature will be delivered in 4 Milestones. Each milestone duration is 45 calendar days.

<style> </style>

MS	FUNCTIONAL AREA	DELIVERABLES
M1.0	AF	Implement the new Network Function
--	AF	Implement the Interface towards FeG and Northbound Interface
M2.0	AF	Write the stub for functional testing
--	FeG and Orc8r	Decode and encode of messages from AF.
--	Subscriberdb	Implement the GRPC services for get SessionManagementPolicyData and subscription data.
M3.0	UPF	Application detection and traffic management with application id.
--	UPF	Simulating and testing with UPF
M4.0	UT	UT for AF and SubscriberDB
--	Integration testing	Integration of the feature and testing the functionality

Reference

1. TS 126 501 - V16.5.0 - 5G; 5G Media Streaming (5GMS); General description and architecture (3GPP TS 26.501 version 16.5.0 Release 16) (etsi.org)
2. TS 123 501 - V16.6.0 - 5G; System architecture for the 5G System (5GS) (3GPP TS 23.501 version 16.6.0 Release 16) (etsi.org)
3. TS 123 502 - V15.2.0 - 5G; Procedures for the 5G System (3GPP TS 23.502 version 15.2.0 Release 15) (etsi.org)
4. https://www.etsi.org/deliver/etsi_ts/129500_129599/129513/15.09.00_60/ts_129513v150900p.pdf

Magma extensions for inbound roaming proposal

Magma extensions for inbound roaming

1. Background and Objective

The objective of this proposal is to extend Magma components to add support for settlement interfaces to bridge the gap between traditional roaming settlement based on Gy interface on Home PGW and new requirements of packet purchasing managed by the Magma core.

Currently, the Magma Access Gateway (AGW) implements a merged SGW+PGW (SPGW) task with support for inbound roaming. The goal of this proposal is to involve sessiond task to support Gy CCR-I/CCR-U messages for roaming subscribers in AGW and FeG.
Software built to accomplish this will be open source under BSD-3-Clause license and will be committed to the Magma software repository under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.

2. Implementation Scope

2.1 Network Architecture

The planned network architecture to use sessiond for generate an initial CCR. The initial CCR should be generated to check IMSI balance before establish default bearer.

S6a: No changes for S6a are planned in this proposal.
S8 Control Plane: Only one change is planned in this proposal: MME session setup logic should be changed to send Create Session Request after/when Sessiond received quota from OCS. In case of no quota has been received the S1 session should be terminated by the MME.
S8 User Plane: No changes for S8 User Plane are planned in this proposal. We are still going to use MME to install the Table 0 for roaming subscribers.
Sessiond: The main change we are planning to make here is to involve sessiond in the inbound roaming call flow.
The new logic should be added to the MME task:
Before sending Create Session Create request to S8 Proxy the MME should send “Create Session” message to the Sessiond. This message will be trigger to generate CCR-I message towards session-proxy with first volume quota request. When the quota has been received from OCS the sessiond should send "Create Session Response" towards MME to allow S8 crate session procedure. In case of no quota has been received from OCS the sessiond should trigger session termination to the MME.
Once MME received Create Bearer Request and Table0 has been provisioned to the OVS the MME should sent "Final Create Session Request" towards sessiond to start get stats procedure from OVS. After reaching the configurable volume threshold on sessiond the sessiond should generate CCR-U to ask the next quota in OCS. This is an existing procedure for home subscribers but we should add the procedure to the inbound roaming call flow.

2.1 Call Flows

The colour scheme in the diagram is as follows:
Black: The existing messages for inbound roaming
Red: The new expected messages
Blue: The existing messages for local users which have to be added to the inbound roaming procedure

2.1.1 UE Attach call flow (successful case)

2.1.2 UE Attach call flow (unsuccessful case)

The behaviour if quota has not been received from OCS.

Note: In case if quota has not been received from OCS the MME should terminate the established session using standard GTP-С termination procedure.

2.1.3 Quota Update Call Flow

2.1.4 Session Termination due to quota exhausted call flow

The session termination procedure should be the same as is for local subscribers.

3. Testing approach

• Main critical parts of the solution will be covered with unit tests
• Lab with inbound roaming will be established for e2e tests
• E2E tests will be done manually in the lab, test scenarios will be upstreamed to Magma repos

4. Security

This functionality does not provide any big changes to Magma AGW or Magma Orc8r. Changes will follow common Magma approaches:

• mutual TLS termination at the Orc8r proxy
• application-level access enforcement

5. Team

https://github.com/just-now
https://github.com/Arsenii-Oganov
https://github.com/jpad-freedomfi

6. Roadmap and schedule

SWE hours approximately for proposal: 230

ONAP/Magma Integration: KPI for Network slicing

The ONAP team would like to know What would be the Magma KPIs to support Network Slicing?

N4 Proxy plugin for supporting PFCP protocol

Proposal: Adding support for PFCP protocol via N4Proxy Plugin

Elevator Pitch :

Targeting for different scenarios there is a rapid development in fast path technologies and new functionalities being added. Supporting these functionalities, there are various 3GPP compliant UPF solutions which makes optimal use of various fastpath techniques like DPDK, VPP or providing integration with asic or np based chipset.
This is also based on the ask from the OCN community is to make third party NFs compatible with Magma.

Total ask

Support of NRF feature on to Magma Architecture will be delivered across 5 milestones.

Contact Information

Yogesh Pandey ([email protected])

Project Details

As part of current magma architecture almost modules GRPC for communication. The messaging structure itself is simplified version of 3GPP.
There are 3 main reasons for the philosophy :

• gRPC does all the heavy lifting work for inter-module communication and provides lot of inbuilt libraries for health monitoring.
• Moving away from layered architecture as defined in the spec gives more simplification and improves performance.
• Moving away from CURD based operation to set interface for enhanced reliability.

While one end the reliability is achieved, the challenge is when interworking with any other 3rd party 3GPP compliant UPF Network Function which can bring rich features of fastpath.

As part of this proposal, idea is to create Proxy Plugin which can facilitate the interaction between the existing Magma module sessiond with
other User Plane Network Function. All the messages defined as part of PFCP protocol needs to be covered by the proxy plugin.

Existing messages between Sessiond and Pipelined is SetInterface and it needs to be converted to CURD format.

Proposed Approach

To support interworking with 3GPP compliant 3rd party UPF following changes are proposed :
• Create a proxy plugin module connected to sessiond which will be chosen based on the selected UPF.
• The plugin will convert the fields to the PFCP protocol format to be accepted by UPF.
• This plugin will process the packets as expected by third party UPF. For example

• Node Level Procedures : like N4 Association setup, update, release, heart beat etc
• Session level procedures : like N4 Session Establishment, Modification, Release & Session Report
  • Need to perform integrated testing with other modules
  • Basic Sanity traffic testing with a reference UPF platform
  • Paging related testing
  • Testing IPv6 scenarios

N4 Proxy Plugin Module

N4 Proxy plugin module will be part of magma agw services and will be invoked if 3rd Party UPF is involved.
Upon detecting the new UPF it will create an association and will start the heart beat procedure.
This module will also define PFCP context which will be responsible for defining PDR, FAR,QER, URR to be send towards UPF.

It will act as a terminating point for the magmad's sessiond GRPC messages. The GRPC messages will be processed and converted
to the PFCP protocol towards the actual UPF.

Message Conversion

For message conversion 2 main changes are required :

• Processing of GRPC message and creating the PDR, FAR and QER rules
• Converting of the set interface operations into CURD operations

The existing GRPC message between Sessiond and Pipelined Encapsulates fully qualified rule in one flow without need for
extra indexing. This makes the rule simple to parse and stand alone. Where as the same with PFCP format it has a
layer of rule indexes in order to provide a generic framework where multiple rules can use same instance.

GrpcFlow: PDR + FAR <=> PFCPFlow: CreatePDR -> PDR ID + Precedence + PDI <+ OHR> + FARID CreateFAR -> FARID + Apply Action

To support the conversion a data structure needs to be created which will be on a session basis. This data structure will store the incoming
grpc message will create an index based entries 3 main entries : PDR, FAR and QER.

Following is the snapshot of the message

Existing GRPC Message Snapshot

 INFO:root:Got RPC payload:
 SessionSet {
 subscriber_id: "IMSI222456000000001"
 local_f_teid: 2147483650
 session_version: 2
 node_id {node_id: "192.168.200.1"}
 state {state: CREATED}
 
 // Uplink Flow Rules
 set_gr_pdr {pdr_id: 1, pdr_version: 1, precedence: 32
             pdi {local_f_teid: 2147483650, net_instance: "uplink", ue_ipv4: "192.168.128.17"}
             set_gr_far {far_action_to_apply: FORW}
             activate_flow_req {sid {id: "IMSI222456000000001"}
                ip_addr: "192.168.128.17", request_origin {type: N4}
                apn_ambr {max_bandwidth_ul: 1000, max_bandwidth_dl: 2000}
                uplink_tunnel: 2147483650
                policies {rule {id: "allowlist_sid-IMSI222456000000001-internet"
                  priority: 2 flow_list {match {}}
             qos {}
             tracking_type: NO_TRACKING}
             version: 1}}}
 // Downlink Flow Rules            
 set_gr_pdr {
   ...
   ...
 }
}

PFCP Packet Snapshot

Start up and Initialization

As soon as the AGW is starting with 3rd party UPF, N4 proxy will be launched. On Northobound it gets connected to Sessiond and on southbound
it connects to UPF. The mamgad services script should launch and monitor the same. The dependency matrix will be on similar lines as current pipelined

Underlying UPF will start Node level information to the this module which will be then converted and shared with sessiond
Also this module will start a regular heartbeat. Once the resource information and capabilties of underlying UPF is received, this proxy
module will convert to GRPC message and share it sessiond. On getting response from Sessiond, this module will share Control Plan features
with UPF and will establish an association.

Session Level Procedure

Once the initial association is established, the proxy module will be responsible for converting the GRPC message from sessiond to PFCP
messages and send it towards UPF.
For doing this it might need to store the session related information and its mapping information. All the response from UPF will be shared with sessiond.

Session Related Reports

The regular reports generated from UPF will be stored in the Proxy module and will be preiodically synced with the sessiond for report generation.

Delivery Approach

Feature will be delivered in 5 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues

Before finishing the 2nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

Milestone1 - Launching & Initalizing of N4Proxy plugin

Tasks to launch N4 Proxy Plugin

• Creation of N4 Proxy Place holder with GRPC service end point.
• Putting the module as part of Magma Services based on compilation option.
• Launching of the process and attaching it with UPF module (or a stub)

Milestone2 - Node Management infrastructure

• Putting the state machine for Node level message exchange
• Putting encoder/decoder for Node level messages.
• Handling Heartbeat message
• Sharing the information with sessiond over GRPC message

Milestone4 - Session Management infrastructure

• Processing of GRPC message coming from sessiond and creating the PFCP context
• Creating the infrastructure for Session related operations including Session Establishment, release etc.
• Converting the message into add, delete, modification category as specified by the spec.
• Sharing the information with SMF over GRPC message

Milestone5 - Charging, Usage reporting and IPv6 support

• Providing support Usage report handling
• Converting the usage reporting messages
• Handling of error cases like association deletion and getting re-attached etc.
• Testing with UE ipv6 support

Test Plan

Primarily targeted for a stub testing. The testing will be targeted with UPF Module simulators from third party. Following is the set of tests or scenarios to 3rd Party UPF integration.

Integration Testing using simulators will be done

• Testing with simulators the node level scenarios
• Testing with simulators the session handling scenarios
• Testing Usage reporting and charging related features.

Feature Roadmap

Feature will be delivered in 5 Milestones.

---

Milestone	Deliverable Summary
MS1	Launching & Initalizing of N4Proxy plugin
MS3	Node Management infrastrucutre
MS4	Session Management infrastrcture
MS5	Charging, Usage reporting and IPv6 support & SIT

References

1. https://www.etsi.org/deliver/etsi_ts/129200_129299/129244/16.04.00_60/ts_129244v160400p.pdf
2. https://docs.magmacore.org/docs/
3. https://www.globalspec.com/FeaturedProducts/Detail/GLCommunications/5G_N4_Interface_Simulation_and_Analysis/314687/0

Magma outbound roaming proposal

Outbound Roaming

1 Objectives

The objective of this work is to add support in Magma for deployments where outbound roaming is required. Specifically, adding support to expose the server sides of s6a and s8 to roaming partner core networks. This will enable outbound roaming to be supported in a 3GPP compliant and standard way which operators are used to.

Software built to accomplish this will be open source under BSD-3 license and will be committed to the Magma software repository under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.

2 Background

2.1: Terminology

S6a refers to the Authentication, Location, and Service definition interface of an HSS in a mobile core.
S8 refers to the control and user plane interfaces used when user data is home routed during an outbound roaming session.

2.2 Outbound roaming

Outbound roaming is when a subscriber gains access to services from a visited operator (VPLMN) other than their home network operator (HPLMN). In this case the HPLMN is a Magma deployment, and the VPLMN is another network operator with which this HPLMN has a roaming relationship.

When outbound roaming, the standard interfaces are s6a and s8 which allow the VPLMN to authenticate the SIM credentials with the home network and route user traffic back to the home network. See diagram below from 3GPP TS 23.401 V17.3.0 (2021-12).

Currently, Magma supports only inbound roaming where magma is the VPLMN and another operator/core is the HPLMN. Magma supports the client side of both S6a and S8 interfaces.

By implementing the server side of S6a and S8, this project will add support for outbound roaming to Magma.

3 Implementation

3.1 Diagrams

The Roaming Gateway diagram shows the services which will run in the Roaming gateway. These services will support the user plane data transport for both inbound roaming GTP aggregation and outbound roaming when traffic is home routed.

Overall, when combined with the orchestrator and federation gateway, the proposed architecture is depicted below showing all key interfaces for inbound and outbound roaming.

The proposed architecture gives the Magma deploying operator the ability to locate the user plane carrying Roaming Gateway outside of AWS where data transport rates are more competitive and/or in a location favorable for connection to the GRX/IPX network.

3.2 Scope of Change

3.2.1 Roaming Gateway Services

The following existing services will be ported to run in the Roaming Gateway:

• Health
• S8_proxy
• PolicyDB
• SessionD
• PipelineD
• MobilityD
• SubscriberDB
• Control Proxy
• Magmad
• Eventd
• td-agent-bit

Similar to FeG and AGW, Roaming Gateway will be a full Magma gateway with control proxy connection to orchestrator and health service.

3.2.1.1 Health (modified)

In addition to the health metrics added in the GTP Gateway proposal for inbound roaming, the following health metrics will also be added to health.
S8-U Inbound Traffic Rate (Mbps)
S8-U Outbound Traffic Rate (Mbps)
S8-U Inbound Bytes
S8-U Outbound Bytes
Active Inbound Sessions
Active Outbound Sessions

3.2.1.2 PolicyDB + SessionD + PipelineD + MobilityD(modified)

The combination of policyDB, sessiond, and pipelined provide the PCEF functionality to the Roaming gateway for home routed data sessions. This ensures that policy rules, QoS profiles, Rating Groups, and charging can be applied to subscriber sessions while getting services from a VPLMN.

Once the GTP-C session is created on FeG, Roaming Gateway sessiond process will be notified via gRPC and OVS flow will be installed to enable GTP-U tunnel and start sending data to the SGi interface of the Roaming Gateway associated with the session APN. Having sessiond manage the tunnel lifecycle mirrors how it is done in the case of 5G in AGW and should reuse code where possible.

3.2.1.3 MobilityD

UE IP address allocation will be provided by MobilityD. The UE IP request will be moved from MME function to sessiond to provide consistency across Roaming Gateway and AGW. IP allocation via NAT will be supported with a configurable NAT pool for IPs. Other IP address allocation schemes are out of scope.

In this phase, default bearer and general internet access is provided to home routed sessions. Dedicated bearer and other services are out of scope.

3.2.1.4 SubscriberDB (modified)

SubscriberDB will be added to Roaming Gateway to support S6a_proxy originated message handling of AIR, ULR and PUR responses.

3.2.1.5 S8_Proxy (new)

S8_proxy service will implement the GTP-U protocol for establishing sessions between the Visitor SGW and the
Magma GTP Gateway, the S8-U interface.

3.2.1.6 Control Proxy (modified)

Control Proxy will run on the Roaming Gateway to provide a configuration and message passing interface to the orchestrator. Control proxy and service registry will be updated to support the new GTP_proxy service endpoint.

3.2.1.7 Magmad (modified)

Magmad will run on GTP Gateway to support gateway checkin and configuration management processes. Modifications will be limited to anything needed to handle new mconfig format for new services.

3.2.1.8 Eventd / td-agent-bit (modified)

Eventd and td-agent-bit will run on GTP gateway to support log and metric reporting. Modifications will be to handle new event types and new metrics specific to roaming gateways.

3.2.2 Federation Gateway Services

3.2.2.1 S6a_proxy (modified)

S6a_proxy will be extended on FeG to support AIR, ULR, and PUR messages. These messages will be proxied to the Roaming Gateway where subscriberDB will be running and used to generate response. Content for AIA, ULA, and PUA will be proxied back to FeG where S6a_proxy will translate back to diameter. The main work will be adding support for converting new S6a messages to and from Diameter protocol to gRPC and adding routing to get the gRPC messages from FeG to Roaming Gateway.

New messages to be supported by s6a_proxy:
Incoming Authentication Information Request (AIR)
Incoming User Location Update Request (ULR)
Incoming Purge UE Request (PUR)

3.2.2.2 S8_proxy (modified)

S8_proxy service will be extended to support the GTP-C protocol for establishing sessions between the Visitor SGW and the home PGW, the S8-C interface. The northbound interface will add support 3GPP compliant S8-C signaling for the following messages:
Incoming Create Session Request
Incoming Delete Session Request
Incoming GTP Echo Request

S8_proxy will be extended to convert the Diameter messages above to gRPC for communication with Roaming Gateway service sessiond.

3.3 Call flow

In the call flow below, red number messages indicate new functionality supported by a Magma element.

4 Security

There two main aspects regarding Roaming Gateway security architecture:

1. External connectivity through the internet: deployment architecture will require secured IPX connection between Roaming Gateway and VPLMN PGW and SGW.
2. Roaming Gateway internal security will follow in a two-tiered approach:

• mutual TLS termination at the Orc8r proxy
• application-level access enforcement

5 Testing approach

• Main critical parts of the solution will be covered with unit tests (services from new Roaming Gateway):
  • Health
  • S8_proxy
  • PolicyDB
  • SessionD
  • PipelineD
  • MobilityD
  • SubscriberDB
  • Control Proxy
  • Magmad
  • Eventd
  • td-agent-bit
• Lab with inbound roaming will be established for e2e tests
• Test scenarios will be upstreamed to Magma repos
• VPLMN PGW will be mocked to be used in testing
• E2E tests:
  • Attach flow sunny day scenario
  • Update flow sunny day scenario
  • Terminate flow sunny day scenario
  • Network terminate flow scenario
  • OCS terminate flow scenario
  • Attach flow cloudy day scenario
  • Update flow cloudy day scenario

6 Team

https://github.com/119Vik
https://github.com/Aitend
https://github.com/amarpad
https://github.com/just-now
https://github.com/malcolmmadsheep
https://github.com/taaraora
https://github.com/Arsenii-Oganov
https://github.com/berezovskyi-oleksandr
https://github.com/IgoninVV
https://github.com/jpad-freedomfi

7 Schedule & Roadmap

SWE hours approximately for proposal: 11000

Magma support for integrating 3gpp compliant Converged Charging System (CCS)

Overview

Magma core is to support integration of any third party 3GPP compliant Charging Function (CHF) through N40 (Nchf_ConvergedCharging) interface. It leverages the existing charging framework present for LTE to support 5G Converged Charging System (CCS).

Elevator Pitch

As service providers around the world are working on their plans for 5G, one question is absolutely critical: how do they make sure the cash flow is guaranteed? Current networks have a mature and stable Business Support System (BSS) architecture and operators are asking how does this need to change to support the new 5G Charging Function?

The standards for the new 5G Core define a 5G Converged Charging System (CCS), containing a 5G Charging function (CHF), which provides converged charging and spending limit controls in the new service-based architecture that is introduced with 5G Core. This system includes balance management, rating, generation of both rated and unrated call detail records (CDRs), and CDR export to billing and other back-office systems.

Currently Magma AGW supports integration of MNO OCS for LTE. The main goal of this proposal to leverage on the existing framework to support 5G converged charging features.

Magma Sessiond acts as a Charging Transfer Function (CTF). The CTF generates charging events towards the Charging Function (CHF), which is responsible for generating Charging Data Records (CDRs).

The 5G system supports converged charging for offline and online charging scenarios.

The Sessiond performs converged charging for each of the following:

• Charging data that is related to PDU session.

• Charging data that are related to service-data flows within a PDU session.

Figure 01: Architecture to integrate 3rd party CHF with Magma AGW

Project Details

Magma AGW is integrated with the MNO core network by using federation gateway through standard 3GPP interfaces. It acts as a proxy between the Magma AGW and MNO’s network and facilitates core functions, such as authentication, data plans, policy enforcement, and charging.

While offline and online charging were separately implemented in previous wireless technologies, in 5G the Converged Charging System supports simultaneous online and offline charging through the Nchf_ConvergedCharging Service. The Nchf_OfflineOnlyCharging service provides session-based and event charging. In addition, PCFs can now use the Nchf_SpendingLimitControl service to subscribe to notifications of policy counter changes that influence the policy decisions.

Sessiond which acts as the Charging Trigger Function (CTF) report the chargeable activities of subscribers to the CHF, which in turn delivers Charging Data Record (CDR) files to the operator’s Billing Domain. When offline charging is used the charging data is collected during resource consumption by the subscriber and reported when a threshold is crossed or after the resource is released. Offline charging has no effect on subscribers’ real-time activities or resource consumption.

Conversely, online charging occurs for particular services or events when the service is requested or the event is initiated, and it involves authorization, and possibly re-authorization, of service accessibility or prepaid credit remaining. Service delivery may be curtailed if a subscriber is not authorized to access it, does not have sufficient credit quota to pay for it, or chooses not to pay for it in real time. The same chargeable event can be reported by both online and offline charging, although the type of information reported may differ.

Implementation of service Nchf_ConvergedCharging includes the below messages:

• Nchf_ConvergedCharging_Create
• Nchf_ConvergedCharging_Update
• Nchf_ConvergedCharging_Release
• Nchf_ConvergedCharging_Notify

Call Flow:

Delivery Approach

Feature will be delivered in 4 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
   Before finishing the 4nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

Milestone-1

Tasks to be handled on magma AGW NE
Implement 5G Services Based Interface (SBI) for Federation Gateway as defined in 3GPP TS 32.291
OpenAPI definitions for all SBI interfaces are provided as YAML files by 3GPP
Use openapi-codegen to generate GO types and client definitions for N40 interface

Sessiond side implementation to identify and support the required missing charging attributes from existing framework for N40 interface through GRPC calls.
Unit tests will be added for all new functions introduced.

Milestone-2

Feg Relay changes for Converged Charging session create, update, delete through GRPC calls
Unit tests will be added for all new functions introduced.

Milestone-3

Implementation of Feg N40 Session Proxy for Nchf_ConvergedCharging create, update, delete through HTTP protocol
Unit tests will be added for all new functions introduced.

Milestone-4

Client(CHF) initiated Converged Charging notifications and basic stub implementation to support Nchf_ConvergedCharging messages
Unit tests will be added for all new functions introduced.
Integration testing using third party mycloudBSS Charging function.

Test Plan

Following is the set of tests or scenarios to verify dual stack Support.

Integration Testing using UERANSIM or equivalent simulator

1. Testing of event based charging magma AGW end to end
2. Testing of session based charging magma AGW end to end.

Feature Roadmap

Feature will be delivered in 4 Milestones.

MS	FUNCTIONAL AREA	DELIVERABLES
M1.0	Sessiond Implementation	CLI based Converged Charging Output
M2.0	Feg Relay	CLI based Converged Charging Output
M3.0	Feg N40 Session Proxy	CLI based Converged Charging Output
M4.0	CHF Stub SIT & UAT	Final set of CC CDR records. Feature is passing all the tests in Real equipment environment. Feature user / customer runs the conformance tests and accepts the feature.

References

1. https://www.etsi.org/deliver/etsi_ts/132200_132299/132291/15.08.00_60/ts_132291v150800p.pdf
2. https://www.etsi.org/deliver/etsi_ts/132200_132299/132255/16.08.00_60/ts_132255v160800p.pdf
3. https://www.arib.or.jp/english/html/overview/doc/STD-T63v9_30/5_Appendix/Rel4/29/29060-4b0.pdf
4. https://itectec.com/spec/5-1-5g-data-connectivity-charging-principles/
5. https://docs.magmacore.org/docs/faq/faq_magma

Support for 5G metrics

Proposal: Support for 5G metrics

Elevator Pitch

Magma 5G SA is required to support 5G metrics to provide monitoring capabilities. Refer to REQ-SW-08 of TIP OCN FWA requirements specification.

5G Metrics indicate the overall non functional attributes of Magma AGW such as connected devices, mobility, throughput, performance, reliability, etc. These metrics are regularly pushed into prometheus, which along with grafana enables us to store and query these metrics.

Based on the Magma 5G metrics, a number of decisions can be made at orc8r level such as triggering alerts for threshold values to troubleshoot the issues at operator end, and scale-in/scale-out AGW decisions to cater to wider requirements, etc.

Total ask

Support Magma 5G metrics will be delivered at a total cost of: $60000

Contact Information

Kaleemullah Mohammed ([email protected])

Project Details

A metric in Magma deployments may originate at gateways (AGW, FeG, etc.) and travels through the Orc8r and is eventually displayed on the NMS UI. All the metrics are stored in prometheus for a default of 30 days.

Current metrics framework for LTE can be leveraged upon to support for magma 5G.

On the AGW, metrics are collected and exported from Python and C++ services.

Mainly metrics are categorized into:

• prometheus metrics (process, memory, cpu, fd, etc.)
• gateway failures/alerts
• sctp
• UE Registration Request metrics
• Service Request metrics
• Registration failures
• Service failures
• subscriberdb
• gNB metrics
• magmad
• pipelined
• mobilityd

Feature Roadmap

Feature will be delivered in 3 milestones. Each milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
   Before finishing the 2nd milestone, the feature shall pass the following process gates
6. System test
7. User Acceptance test

MileStone 1

Collection and export

• On the AGW, 5G metrics are needed to defined, collect and export from Python and C++ services.

MileStone 2

Orchestrator and Prometheus

• To extend the support service present in the Orc8r and pushes metrics over gRPC to Prometheus Edge Hub.

MileStone 3

NMS and Grafana

• NMS dashboard which connects to the Grafana Data Source API, which proxies the parameterized metric request to Prometheus and displays the retrieved metrics.

Test plan

UT and validation of Magma 5G AGW metrics
Integration testing AGW, orc8r and NMS

Feature Roadmap

Feature will be delivered in 3 Milestones.

MS	DELIVERABLES
M1.0	AGW metrics collection and export
M2.0	Orchestrator and Prometheus
M3.0	NMS and Grafana

References

https://docs.magmacore.org/docs/nms/metrics

Supporting High Availability on AMF

Proposal: Supporting High Availability on AMF

Elevator Pitch

High availability is a very essential element in a core network as it offers seamless services in case of failures.
In the current proposal we are planning to achieve it from a load balancer.

When active node fails, load balancer will detect failure and it will switch the context to standby(Standby will undergo a transition to active) and start handling the requests.

The current HA proposal is considered for AMF node only.

Total ask

Support of HA feature on to Magma Architecture will be delivered in 3 milestones.

Contact Information

Ajay Kashyap ([email protected])

Project Details

Prerequisite: Considering the stateless feature into account, we assume all the data structures, counters and configurations are stored in Redis db.

Current Architecture

 <Does not have HA support> 

Proposed Architecture

  In the Current proposal, Plan is to introduce HA functionality for AMF using Redis sentinal along with a open source load balancer.

Sequence of operations

 * Load balancer to send requests for active node by continuously monitoring heartbeat.
 * All the data in active to be synced continuously  with standby with Redis sentinal.
 * When there is heartbeat failure LB to send signal to Standby to undergo transition from active to standby.

Proposed approach

* An open source load balancer needs to be identified which monitors the heartbeat of magma AMF. 

* If heart beat is not received then load balancer needs to send a signal to standby for a transition from standby to active state. 

* Redis DB is used to store the session and policy details, It also stores the in memory data structures of AMF & this information is confined to a node. 

* Approach would be to use Redis sential for replicating  the data present in active to standby (Master - Slave) 

* When active node goes down, all its resources has to be cleared and the process needs to be gracefully shut down. 

* Load balancer will assign a floating IP to the current active node . 

Feature Roadmap

Feature will be delivered in 3 milestones. Each milestone will have the following 5 process gates.

• Design
• Development & Unit Testing
• code review
• Integration testing with multinode
• Resolve integration issues and regression issues

MileStone 1

1)Identify a HA load balancer for magma product.

2)Load balancer (LB)with have the active and standby node configurations understanding and testing.

3)Existing AMF needs modifications to respond for the heartbeat messages sent from LB.

4)Integration testing of AMF and LB for heartbeat and heartbeat Ack.

MileStone 2

1)Configurations of Redis sentinal to be identified for active to standby replication.

2)Multi node setup creation.

3)Testing to be done at standby for redis db replication.

MileStone 3

1)Active to Standby transition testing.

2)After active to standby transition, resources from standby needs to be gracefully released and tested.

3)After active to standby transition all new calls get diverted here and LB assigns a floating IP and current calls will be intact, this needs to be tested.

4)Transitions from active to standby and vice versa to be rigorously tested.

Test plan

• Testing of HA feature has to be done with multi node set up.
• Initial UT can be planned by testing with load balancer.
• Integration testing with multi-node setups.

---

Milestone	Deliverable Summary
MS1	Identify Load Balancer,LB to send heartbeat for SCTPd & AMF, Modify SCTPd & AMF to respond to heart beat , Integration testing
MS2	Configure Redis Sentinal for master-slave, multi-node setup creation, Redis data replication in standby and its testing
MS3	Active-Standby transition testing,LB assigns floating IP testing,All calls to be intact and new calls directed to current active testing

References

https://redis.io/topics/sentinel

https://www.haproxy.org/

Proposal: Platform for Training and Certification for Magma

1.0 Objectives

The objective of this work is to build and support an ecosystem for magma training and certification. Through which users should not face difficulties whether in the aspect of giving the exam, getting exam scores or certificates.

2.0 Background

Currently, Magma certification is not maintained by anyone and there are a lot of bugs in the platform after completion of the test certificate should be generated automatically. Instead of this, the user has to request the admin to generate the certificate after passing the test. With the new platform, a user has to enroll for the Magma Certification exam. After that, they will get the result instantly after the exam and also the certificate is also generated for that user if they successfully passed the exam.

3.0 Implementation scope

3.1

We have developed an end to end platform based on Openedx. This platform includes Blockchain-based certificates powered by Hyperledger Besu.

POC:

https://edx.magmaindia.org/

We will finalize the changes according to the magma core foundation once our proposal will be approved by the foundation.

We will also build an app for the same

3.2

In future, we will add a Microsite so that anyone from the magma community can make their own MOOCS on magma and can host it on our platform.

POC: https://moocshub.com/

4.0 Team

Vipin Rathi https://github.com/viprat
Nitin Rajput https://github.com/nitinrajput1997
Vishal Bhardwaj https://github.com/SRDeveloperVishal

5.0 Budget

Budget Required: $ 0

Magma CDR Availability proposal

CDR Availability proposal

Author(s): [@Arsenii-Oganov]

1.0 Objectives

The objective of this work is to extend Magma to support Call Data Records (CDR). The charging information is passed through a chain of logical charging functions. At the end of this process, CDR files are generated by the network, which are then transferred to the CDR client/network operator's Billing Domain for the purpose of subscriber billing and/or inter-operator accounting.
Software built to accomplish this (aka settlement domain service) will be open source under BSD-3-Clause and will reside in the github repository of the Magma software under the governance of the Linux foundation, such that it can be effectively maintained in the future releases.

2.0 Background

Currently Magma doesn’t support any kind of CDR files for any scenarios. By implementing this proposal Magma will have full support for standard 3GPP CDRs for inbound roaming scenario and core CDR functionality for outbound roaming scenario.

3.0 Implementation scope

3.1 High - level solution architecture

Where:
SessionD runs CTF (Charging Trigger Function) that generates and sends session init/update/terminate events to the data storage.
Session telemetry - database stores information about all sessions for all network elements for all user equipments.
CDR engine runs CDF (Charging Data Function)
Bx - 3GPP integration reference points
CDR Gateway - Persistent CDR storage
Sessiond enhancements and Session telemetry creation functions are covered inside different proposal (Settlement service, (magma/magma#11166)) and here assumed to be fully implemented.

3.2 CDR engine

The CDR engine pulls data from the Session telemetry via GRPC interface and uses the information contained in the charging events to construct CDRs. The result of the CDR engine task is generated Charging Data Records (CDRs) with a well-defined content and format. The content and format of these CDRs are specified per domain/subsystem/service in the related charging specification 3GPP TS 32.251 for PS domain. The CDR engine implements the following main functions:

• CDR pre-processing
• Validation, Consolidation and (Re)Formatting of CDRs
• CDR error handling
• CDR filtering, push CDRs to SFTP and put on separate files based on filtering criteria such as CDR type, CDR parameters, originating of network element etc.
• CDR File Management, e.g. file creation, file opening / closure triggers, file deletion
• CDR file transfer to the CDR clients

3.3. Session based charging scenario

This scenario represent the flow how CDRs will be generated.
In the call flow below, red number messages indicate new functionality supported by a Magma elements.

• Steps 1-8 General steps of Session activation and OVS provisioning in Magma.
  Since the flow table is installed in to OVS, OVS start to collect session statistics
• Steps 9-12 SessionD query and gets user session statistics
• Step 13-14 Session telemetry pulls statistics near real time and stores in it's own database.
• Step 15 CDR engine pulls statistics near real time and uses the information contained in the statistics to construct CDRs.
• Step 16 CDR engine puts Charging Data Records (CDRs) with a well-defined content and format to CDR Gateway for permanent store
• Step 17 Sessions has predefined/configurable time treshold to repeat statistics query by steps 18-21 described above
• Steps 18-21 SessionD intermediate queries and gets user session statistics , the process of intermediate queries continues to collect usages until its flows are no longer included in the report (flow deleted in Pipelined) or a specified timeout
• Steps 22-25 the same procedure as described below in steps 13-16, the process continues until sessiond can collect related flow statistics
• Steps 26-32 General steps of Session deactivation and OVS flow removing in Magma.

4.0 CDR file structure

The CDR files contain a variable length header section followed by a variable sized CDR data section.
The CDR data section contains zero or more concatenated CDRs.
Each CDR in a file includes a header indicating the CDR length, data record format, release, version and encoding scheme. Basic Encoding Rules specified by (ITU-T Recommendation X.690 [301]) must be supported by all 3GPP systems.
CDR abstract syntax specification and Charging Data Record (CDR) parameters described in the (3GPP TS 32.298

5.0 Security

This functionality does not provide any changes to Magma AGW or Magma Orc8r, the only change is implementation of the exporting and transformation engine on the FeG side. There are no new public APIs with pull approach will be created, only push mechanism. In real telco implementations mostly SFTP transport protocol is used.

6.0 Testing approach

• Main critical parts of the solution will be covered with unit tests
• Lab with inbound roaming will be established for e2e tests
• Test scenarios will be upstreamed to Magma repos
• E2E tests:
  • One UE attaches to one AGW sunny day scenario
  • Few UEs attaches to multiple AGWs sunny day scenario
  • One UE attaches to one AGW cloudy day scenario
  • Few UEs attaches to multiple AGWs cloudy day scenario

7.0 Team

https://github.com/abisare
https://github.com/Arsenii-Oganov
https://github.com/taaraora
https://github.com/malcolmmadsheep
https://github.com/jpad-freedomfi

8.0 Roadmap and Schedule

SWE hours approximately for proposal: 1250

Converged GTP Tunnel Setup for 4G

Elevator Pitch

Add support for to make GTP tunnel operations by Sessiond for 4G Call as similar to 5G Call Flows.

Today Magma AGW is making the GTP tunnel operations using below two ways for 4G call:

1. Using openflow controller or libgtpnl from SPGW.
2. Or Making gRPC call from MME to Pipelined.

For option-2 is doing extra gRPC call to configure the GTP tunnel in OVS but
not using the existing gRPC call from MME to Sessiond to Pipelined (Activate_flow and deactivate_flow).

Intent of the proposal is to make common gRPC call to configure GTP flows, Enforcement flows and enforcement stats flows as similar to 5G flows. For this proposal, we reduce the operation cost of Magma AGW.

Total ask

Support of Converged GTP Tunnel Setup feature on to Magma Architecture will be delivered in a single milestone

Contact Information

Prabina Pattnaik ([email protected])

Project Details

To extend the existing gRPC methods of MME-Sessiond and Sessiond-Pipelined to configure GTP tunnel flows.
Following scenarios or process are need to implement using gRPC:

GTP tunnel Creation:

1. MME-Sessiond:
   rpc CreateSession(LocalCreateSessionRequest) returns (LocalCreateSessionResponse) {}
   rpc UpdateTunnelIds(UpdateTunnelIdsRequest) returns (UpdateTunnelIdsResponse) {}
2. Sessiond-Pipelined:
   Activate flows for a subscriber based on predefined flow templates
   rpc ActivateFlows (ActivateFlowsRequest) returns (ActivateFlowsResult) {}

GTP tunnel Deletion:

1. MME-Sessiond:
   rpc EndSession(LocalEndSessionRequest) returns (LocalEndSessionResponse) {}
2. Sessiond-Pipelined:
   Deactivate flows for a subscriber
   rpc DeactivateFlows (DeactivateFlowsRequest) returns (DeactivateFlowsResult) {}

Block diagram

GTP tunnel for IdleSession:

1. MME-Sessiond:
   rpc IdleSession(LocalIdleSessionRequest) returns (LocalIdleSessionResponse) {}

2. Sessiond-Pipelined:
   rpc PagingFlows(PagingFlowsRequest) returns (PagingFlowsResult) {}

GTP tunnel for PagingNotification:

1. Sessiond-MME:
   rpc PagingNotification(LocalPagingInfo) returns (void) {}

2. Pipelined-Sessiond:
   rpc SendPagingRequest(UPFPagingInfo) returns (SmContextVoid) {}

Block Diagram

Configuration

AGW need following configuration:

1. pipelined_managed_tbl0: false in pipelined.yml and spgw.yml

Delivery Approach

Feature will be delivered in one milestone with the following 6 process gates

1. Design
2. Development & Unit Testing
3. code review
4. Integration testing
5. resolve integration issues and regression issues
6. System test

Milestone1

1. Create new gRPC methods for MME-Sessiond in session_manager.proto.
2. Create new gRPC methods for Sessiond-Pipelined in pipelined.proto.
3. Add gRPC handler (service endpoints) for new methods in Sessiond,MME and Pipelined.
4. Add support Paging notifications for 4G call in sessiond.

Test Plan

The following tests scenario are proposed to verify to cover this functionality:

Integration Testing

1. Verify the functionality using S1ap test cases.
2. Write UT test cases for sessiond and pipelined.
3. Write the python stub for verify the functionality.

Regration Testing

Following tests will be verified on magma master branch to make sure there is no breakage introduced through this proposal.
• Verify the 5G and 4G basic call flows and paging using UERANSIM, Teravm etc.
• Need to verify the traffic test.

Feature Roadmap

Feature will be delivered in one Milestones. Each milestone duration is 45 calendar days.

MS   		FUNCTIONAL AREA       DELIVERABLES        	           
M1.0		    MME		              Service endpoints support
                                                 Parsing.
		--------------------------------------------------------------	
                  SessionD	  gRPC Service Support
                                           Paging Support
                 -------------------------------------------------------								  
		PipelineD		  Configure			
			                  GRPC message support                           
		----------------------------------------------------
		CLI STUB		  Add CLI stub for functionality verification
					  UT for all respective modules.
		------------------------------------------------------
		Regration Testing     Regration testing for 4G and 5G.
-------------------------------------------------------------------------------------------

Proposal : Adding support for Network Function Repository functions in Magma

Proposal: Adding support for Network Function Repository Functions in magma

Elevator Pitch :

NRF allows 5G NFs to register and discover other NFs via standard defined techniques. This requirement is in compliance with TIP Requirement <>.
As part of current magma architecture the communication channel details are present in service_registry.yml. This provides a static and simple way of
discovering the end point when all the components are in single node. But when moving to a distributed or containerized environment especially in 5G deployments dynamic discovery of NFs becomes critical. Also with NRF, other modules can be launched without pre-conditions. NRF also addresses the requirement of to discover the amf which supports specific slice types.

Total ask

Support of NRF feature on to Magma Architecture will be delivered across 4 Milestones.

Contact Information

Yogesh Pandey ([email protected])

Project Details

Functionality planning to support as part of NRF

• Maintaining NF profile and supported services.
• Get NF instances to subscribe to and get notified about, the registration in NRF of new NF instances of a given type.
• To provide support service discovery function
• As a map towards 3GPP spec idea is to provide support for nnrf-nfm, nnrf-disc

Sequence of operations

• NRF will enable registration and discovery functionality in order to communicate with other network functions via APIs.
• When a new NF Service Producer (e.g., sessiond) is launched, it registers its own details like type-of-service, IP address, and port number with the NRF.
• When a Network function like AMF wants to establish the PDU session via sesssiond, it sends a service discovery request to the NRF.
• If authorized, the NRF responds with the details of sessiond instance.
• The AMF then will send a grpc request to sessiond. The respective NF will then service the request to install the session in fast path

NF Management Service

This service will allow NF in the serving PLMN to register, update or deregister its profile in the NRF. It will also allow to subscribe and notify the services of other NF Instances, along with their services.
The subscription mechanism will be based on profiles (NF Profiles). NF Profile will consist of general parameters of the instance and different NF Services that will get registered with NRF.

Following are the few examples :

• AMF parameters and services
  plmnList, sNssais, ipv4Addresses, amfInfo (like amfSetId etc.)
  namf-com, namf-mt, namf-loc (location services etc.)
• SMF parameters and services:
  plmnList, sNssais, ipv4Addresses, snssais including with DNN List etc.
  nsmf-pdusession, nsmf-oam etc

The communication channel between any NF and NRF will be based on GRPC interface and all the elements (parameters and services) will be using the protobufs.

Attaching 3GPP reference snapshots of registration request going from AMF to NRF.

NF Discovery Service

As part of NF Discovery service NRF will allow discovering of required NF services matching the services send in query requests from another NF. Before trying to discover the required NF, local NF will check if similar query has been used earlier and the response is within the validity interval. If so the results will be re-used. If not new query will be fired.

Attaching 3gPP reference snapshot of discovery procedure

Work items

• Launching the NRF process on a well defined port will be the first work item. Target for the project is to
  integrate AMF, Subscriberdb and Sessiond with NRF.
• Each of the process needs to define clear profiles and services to be offered. Corresponding proto files needs
  to be put in place for each of the NFs.
• Each NF while getting started will share the profiles which will be stored in the NRFs data base.
• NFs when killed will be removed from NRF
• While looking for the specific NF, discovery request will be send to the NRF which will then send the response.
• All communication towards specific NF will be done after that.

Suggested way of launching the process : NRF > SUBSCRIBERDB > AMF > UPF > SMF

Delivery Approach

Feature will be delivered in 4 milestones. Each milestone will have the following 4 process gates

1. Design
2. Development & Unit Testing
3. code review

Before finishing the last milestone, the feature shall pass the following process gates
4. Integration testing
5. System test
6. User Acceptance test

Milestone1 - Launching & Initializing of NRF process

Tasks to launch NRF process

• Creation of NRF process with GRPC service end point.
• Putting the module as part of Magma Services based on compilation option.
• Launching of the other process and attaching it with NRF.
• Re-looking at the start up sequence of the modules and try to make it independent.

Milestone2 - NF Management Service (Profile and Service Definition for AMF, Subsriberdb and Sessiond)

• Create the Profiles for each of the modules and expose the services.
• Storing the information of the services in some tables in NRF where profiles can be used as matching criterion during discovery.
• Defining the GRPC calls for the modules for the registration and de-registration.

Milestone3 - NF Discovery Service

• Discovering subscriberdb, during the authentication procedure in AMF and get the user authenticated considering the PLMN and NSSAI information.
• Discovering the sessiond module, during the PDU Session creation process based on PLMN and NSSAI and establishing end to end session.
• 5G call flow validation

Milestone4 - Regression, Integration & System Testing

• Verifying the functionality with regression test scripts.
• Benchmarking the scalability and performance numbers.

Test Plan

Primarily targeted to test whether dynamic discovery of services is possible during the session creation.
Following is the set of tests or scenarios to to test the feature.

Integration Testing using simulators will be done

• 5G Call flow is working with NRF feature.
• Scale and other related tests to be performed.
• Negative scenarios related testing to be done.

Feature Roadmap

Feature will be delivered in 4 Milestones.

---

Milestone	Deliverable Summary
MS1	Launching, Initalizing of NRF process, Modifying start up scripts
MS2	Implementing NF Management services in NRF
MS3	Implementing NF Discovery Service in NRF
MS4	Verification, Regression and scale tests

References

https://raiith.iith.ac.in/5670/1/Mtech_Thesis_TD1466_2019.pdf
https://github.com/bubblecounter/Internship-5GCN
https://nickvsnetworking.com/5gc-the-nrf-in-theory/
https://nickvsnetworking.com/open5gs-nrf-setup/
https://www.etsi.org/deliver/etsi_ts/129500_129599/129510/16.05.00_60/ts_129510v160500p.pdf
https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-nrf

Support HQOS for multiple sessions of multiple Subscriber and Fixed bandwidth

Overview

Hierarchical Quality of Service (HQoS) uses a queue scheduling mechanism to guarantee the bandwidth of multiple services of multiple subscribers served by the service provider. HQoS uses multi-level scheduling to distinguish user-specific or service-specific traffic and provide differentiated bandwidth management.
Servcie providers will use HQoS to provide differentiated QoS guarantee for key users and services, improving user experience.

Elevator Pitch

Magma 5G SA is required to support for Multi-Level Scheduling QoS (Two-Level Scheduling) for multiple sessions of different QoS. Refer to REQ-OCN-03 of TIP OCN FWA requirements specification.
UPF supports the following functions for UE’s Uplink (DL) and Downlink (DL) traffic:
• Traffic Classification
• Prioritization
• rate shaping
Magma 5G SA supports traffic classification and queueing in Linux kernel for egress and ingress traffic as a basic configuration (default config) as below:

1. This process allows some packets to egress earlier than others, and is performed by the pfifo_fast qdisc ( First-In and First-Out). The QDisc which implements a simple three band prioritization scheme based on the TOS bits.

Figure 01: Hierarchical Token Bucket Structure

2. Individual QDiscs may implement classes in order to handle subsets of the traffic differently and Not all QDiscs have support for multiple classes. For example, the Hierarchical Token Bucket (HTB) QDisc allows the user to configure 500Kbps and 300Kbps classes and direct traffic to each as desired. The hierarchical token bucket (HTB) algorithm allows to specify per-flow bitrate guarantees and enables excess bandwidth sharing between flows of the same class.
3. Filters are the mechanism used to classify traffic to a particular QDisc or class. There are many different types of filters of varying complexity.
   Following features are needed in Magma 5G SA:
   • To extend support PriorityQueue for htb that different priority levels allow the HTBQueue to interfere in the fair excess bandwidth sharing mechanism, in favor of the higher priority flow.
   • The hierarchical design of HTB allows to assign each traffic flow two bandwidth parameters: an assured rate and a ceiling rate. While the first one is the minimum guaranteed rate, the second one is an upper limit until which the flow can borrow excess bandwidth.

<class id="className">
<parentId> classParent</parentId>
<rate type="int">Rassured, className</rate>
<ceil type="int">Rceiling, className</ceil>
<burst type="int">burst</burst>
<cburst type="int">cburst</cburst>
<level type="int">classLevel</level>
<quantum type="int">quantum</quantum>
<mbuffer type="int">mbuffer</mbuffer>
 <priority>priority</priority>         [only for the leaf classes]
<queueNum type="int">n</queueNum>      [corresponding packet queue index, only for the leaf class]
</class>

class htb 1:1 parent 1:fffe prio 0 quantum 1000 rate 12Kbit ceil 40Kbit linklayer ethernet burst 1599b/1 mpu 0b cburst 1600b/1 mpu 0b level 0 priority 10 queueNum 1
class htb 1:fffe root rate 80Kbit ceil 80Kbit linklayer ethernet burst 1600b/1 mpu 0b cburst 1600b/1 mpu 0b level 7

Use cases

Hierarchical class of service is most frequently used in the following scenarios:

1. Services to Subscribers: Multiservice network operators face a challenge to provide different types of services on the same infrastructure to residential and business subscribers. The network operator needs to make sure each subscriber gets the network resources they paid for and each service gets the network resources it needs to operate properly. Using hierarchical class of service, the network edge device can have up to five levels of scheduling and prioritization. So the traffic can be shaped and prioritized per customer and per service type.
   By allowing network operators to consolidate different services and multiple customers on the same physical infrastructure, hierarchical class of service helps maximize the ability to offer revenue generating services while simultaneously minimizing capital cost.
2. Services to Businesses: Hierarchical class of service is a valuable tool for service providers that support business customers who are running applications with different prioritization and scheduling requirements over the same infrastructure. In this scenario hierarchical class of service allows lower priority traffic to fully utilize the available bandwidth on a port, while simultaneously ensuring low latency and guaranteed bandwidth to higher priority traffic on the same port. This allows a provider to consolidate different services on the same physical device and physical infrastructure thus optimizing network resources while maintaining the required level of service.
   All of this maximizes revenue and minimizes cost.
3. Wireless Backhaul: Wireless backhaul is very sensitive to fluctuations in the packet stream (Jitter) because it relies on synchronization. In this scenario, hierarchical class of service allows each type of traffic to receive the required resources and quality of service while being delivered over the same infrastructure. By consolidate different services on the same physical infrastructure, HCoS helps maximize revenue and minimize cost.

Project Details

Using iproute2 (command line utility), The tc tool performs all of the configuration of the kernel structures required to support traffic control. The utility takes as its first non-option argument one of three Linux traffic control components, qdisc, class or filter.
The following tasks are needed to implement for achieve this functionality:

1. Create HTB class for a UE session with correct value of rate limiting (GBR value).
2. Create HTB class for a UE session with priority value of QoS policy.
3. Create HTB class for a UE session with root and leaf value as parent for multi sessions (IMSI).
4. Create TC Filter for HTB class with parent ID and Priority.
5. Create nested token buckets for controlling the assured and ceiling rate.
6. Add for GBR and QoS policy priority attributes value from SMF to UPF.

Delivery Approach

Feature will be delivered in one milestone. Every milestone will have the following 5 process gates

1. Design
2. Development & Unit Testing
3. Code review
4. Integration testing
5. Resolve integration issues and regression issues
6. System test
7. User Acceptance test

Milestone1

Tasks to be handled on PipelineD
• Implement the namedtuple for QosInfo with GBR and MBR value.
• Implement the value set for qos_handle_root and qos_handle_leaf.
• Implement the grpc messages SMF-UPF for passing the GBR, MBR and priority attributes.
• Implement the functionality of Classifies packets into correct leaf classes using pyroute2.
• CLI Stub for functionality verification.
Tasks to be handled on Sessiond, PolicyDB and Ocr8r (NMS):
• Support for configure the gbr UL/DL attributes in NMS dashboard
• Implement the grpc attributes for Ocr8r to Sessiond to Pipelined.
Unit tests will be added for all new functions introduced.

Test Plan

Following is the set of tests or scenarios to verify the multi qos policy for multi sessions:

PDU Session	UE IP Addr	Prio	Rate	Ceil
1   (UC1)	192.168.128.15	  1	40kbit	40kbit
2   (UC1)	192.168.128.17	  5	20kbit	30kbit
3   (UC2)	192.168.128.16	 10	20kbit	20kbit

Parent/Master
Rate Ceil
UC1 80kbit 80kbit
UC2 90kbit 90kbit

Integration Testing using CLI Stub.

• Multi PDU session Establishment with single QoS
• Multi PDU session Establishment with multi QoS
• Send UDP/TCP traffic with Rate value and Ceil value

Feature Roadmap

Feature will be delivered in Two Milestones. Each milestone duration is 45 calendar days.

<style> </style>

MS | FUNCTIONAL AREA | DELIVERABLES
-- | -- | -- | --
M1.0 | Pipelined | Implement the QosInfo
--|--| Implement the functionality of Classifies packets.
--|--| Implement CLI stub for verification the functionality.
--| SMF, Ocr8r, NMS | Support GBR and Priority set and grpc messages.
M2.0 | Integration Testing | Complete testing with multi qos configure in NMS and pdu establishment with UERANSIM | $39000
--| System Integration Testing | Traffic Throughput Testing with multi qos (Audio, Video etc)

Reference

https://docs.magmacore.org/docs/proposals/p003_qos_enforcement
https://github.com/svinota/pyroute2
https://github.com/fg-inet/omnet_htb
http://ce.sc.edu/cyberinfra/workshops/Material/NTP/Lab%2020.pdf
https://linux.die.net/man/8/tc-htb

[Proposal]: Magma integration test framework

Project: Magma 5G ngap integration test framework

Elevator Pitch:

Magma 5G SA is in continuous development, hence new features addition and refactoring are recurring. There is a need to have an integration framework to ensure that existing features/functionalities are working as expected.

This proposal presents a framework similar to the s1ap test framework in Magma LTE, which will empower developers for smooth integration with 5G SA functionality.

 

Contact information:

Laawanya Kishor

Email: [email protected]

 

Project Details:

Implementation Approach:

magma_test VM will be used to compile and run 5G test simulator.

 

NGAP Test Framework architecture

 

Fig: Representation of architecture

 

NGAP Test Framework Components

 

Fig: Representation of Project Components

 

The framework will have five primary Components.

1. UE Application: It will have functions and placeholders for UE procedures.
2. Gnb Application: It will have functions and placeholders related to N2, N3 interfaces, SCTP association and other gnodeb processes.
3. Test Controller Framework: It will contain placeholders for managing all other components.
4. Traffic Generator: It will contain placeholders to generate traffic packets.
5. Test Controller Stub: It will contain a placeholder for all the test scenarios. These scenarios are grouped into the following categories:
   1. Attach Detach Scenario
   2. Mobility Management Scenario
   3. Session Management Scenario
   4. Session Modification Scenario
   5. Traffic Management Scenarios

 

Milestone Overview

The project will be delivered in 5 Milestones. 4 of these milestones are focused on development, while the fifth will include regressive testing and evaluation. Each milestone is further divided into sub milestones as follows:

 

Milestone 1:
This milestone will have deliverables in the following functional areas:

Basic Framework

1. Framework (Test Controller Framework)
2. Gnb placeholders (Gnodeb Application)
3. Ue placeholders (Ue Application)
4. NGAP encoding/decoding (NGAP Module)
5. NAS encoding/decoding (NAS Module)
6. sctp placeholder (SCTP)
7. gtp placeholder (GTPU)

Basic registration procedures
Each scenario will contain multiple test cases (ranging from 5-15).

1. SCTP Scenarios
2. Plmn verification scenarios
3. Registration Deregistration

 

Milestone 2:
This milestone will have deliverables in the following functional areas:

Mobility Management:
Each scenario will contain multiple test cases (ranging from 5-15).

1. Identification scenarios (SUCI/GUTI etc)
2. Authentication scenarios
3. Security mode scenarios
4. Registration complete and ICS handler

Session Management:
Each scenario will contain multiple test cases (ranging from 5-15).

1. PDU Session Scenarios (Establishment Request, Accept)
2. Timer-based

 

Milestone 3:
This milestone will have deliverables in the following functional areas:

Additional Test Cases for Mobility and Session Management:
Each scenario will contain multiple test cases (ranging from 5-15).

1. Session Modification Scenarios
2. Paging Scenarios
3. Idle mode Scenarios

Traffic Scenarios:
Each scenario will contain multiple test cases (ranging from 5-15).

1. Mobility (Ip allocation related test cases for v4, v6 etc)
2. Traffic scenarios(Traffice Generator)

 

Milestone 4:
This milestone will have deliverables in the following functional areas:

Negative Scenarios

1. Negative Scenarios for all the above covered test cases.
2. Multi Session Scenarios for all the above covered test cases.

 

Milestone 5:
This milestone will have deliverables in the following functional areas:

Evaluation

1. Overall Integration
2. Bug fixes
3. Documentation
4. Minor Enhancements

 

Roadmap

The project will be delivered in 5 Milestones timelines as indicated.

---

Milestone	Deliverable Summary
MS1	Basic Framework, Encoding and Decoding of IEs and basic registration procedures
MS2	Mobility Management and Session Management basic test cases
MS3	Additional Test Cases for Mobility and Session Management including traffic cases
MS4	Negative and timeout scenarios with multi session test cases
MS5	Overall Integration, Bug fixes and minor enhancements

---

References

1. s1ap integration test