What is a Network Application

Blog

5GASP definition of a Network Application

Although there does not yet exist a standard definition of what a Network Application is, in 5GASP we identified some key characteristics that shall aid to the definition of a Network Application in the context of the 5G System. Specifically, in 5GASP we consider that:

A Network Application, in the context of the 5G System, is defined as set of services that provide certain functionalities to the verticals and their associated use cases.

The following are some identified characteristics of a Network Application, following the terminology introduced in Section ‘Definitions’ at the beginning of this document. Specifically, a Network Application:

  • Should deliver services to 5G Verticals;
  • May consist of both software and hardware parts;
  • Must embrace the Service Based Architecture paradigm;
  • Should follow the NFV model;
  • May expose APIs to be consumed by other service consumers. The exposed APIs should be delivered in an Open API model and may follow the 3GPP recommended APIs for applications (i.e. 3GPP CAPIF, Service Enabler Architecture Layer for Verticals – SEAL);
  • A Network Application may be part of one or more vertical application services;
  • One or more services of the Network Application may be attached to one or more 5G User Plane Function (UPF) data paths;
  • May be part of one or more 5G slices. The slices may be shared or not;
  • Part of a Network Application may reside at the User Equipment (UE) side. The part of the UE side may interact with a Network Application service that resides within the domain network. The UE part may follow the definition of the Vertical Application Layer (VAL) client of 3GPP;
  • May be part of the 5G Core. In such case, then it must follow the 3GPP standards;
  • May interact with the 5G System by consuming 5G system’s APIs, if the 5G system allows. When interacting with the 5G System, it must support relevant 3GPP standards. Such interactions may include location services, Quality of Services (QoS) management, Assured Forwarding (AF) traffic;
  • May support service continuity by minimizing service interruption when transferring application context;
  • Software parts should be deployed either in a virtualized or containerized manner;
  • May have the resource and network requirements in terms of hardware, memory, Graphics Processing Unit (GPU), Central Processing Unit (CPU), availability, etc.;
  • May have placement requirements (e.g. edge, region, core, etc.). Additionally, a network latency KPI must be specified by the Network Application when requesting a slice by the 5G system;
  • May consume monitoring and telemetry data from the 5G System. Such data from the 5G System should be consumed by functions like the Network Data Analytics Function (NWDAF);
  • May interact with the VIM/Container Infrastructure Service Management (CISM) of the domain, if this is not restricted;
  • May interact with the Service or NFV Orchestrator of the domain if this is not restricted;
  • Should follow relevant 3GPP security definitions and recommendations.

Gathering Network Application requirements

To gather 5GASP Network Application requirements we provided the following templates:

  1. a generic architectural template to be followed by our Network Applications in order to better understand their requirements in terms of data paths, interactions with the 5G system, placement, etc. The developers need to place their services in the template. The architectural template is given in Figure.
  2. We advised them to identify their requirements by expressing them in the form of the Generic Slice Template of GSMA, thus producing a NEtwork Slice Type (NEST).
  3. Provide integration and dependency needs in terms of resources (VNFs, NSDs, VDUs, etc).
Figure 1. Network Application template architecture
Figure 2. Network Application resources

Using GSMA General Slice Template (GST) for defining the Network Application slice

The Global System for Mobile Communications Association (GSMA) is a trade body representing the interests of mobile operators worldwide. GSMA’s work mainly focuses on network slicing and in particular on vertical industry requirements into network slice characteristics. The attempt to introduce a unanimously accepted communication model among operators, providers, and vertical customers has resulted in the publication of two GSMA white papers.

From the analysis conducted in the white paper30, several service requirements on network slicing were extracted considering different expressions between industry sectors, including augmented/virtual reality, automotive, logistics, healthcare, finance, manufacturing (industry 4.0), smart cities, and public safety. The aim of this overview was to analyze the specifications and requirements from the industry use cases in the direction of providing a universal template that would describe the needs of each specific vertical use case. Although requirements for each use case were addressed, quantified where possible, and categorized into performance, functional and operational requirements, there was no agreement on how verticals would express these requirements in this study.

In this context, GSMA pointed at the direction of a generic network slice template to:

  • introduce certain guidelines for verticals on how to address their service requirements towards providers and operators;
  • facilitate the signing of the SLA between the operator and the business customer as a guarantee that the network capabilities derived from the customer’s requirements are always provided. On this notion, GSMA elaborated a new paper31 introducing two novel concepts:
    • General Slice Template (GST): a template used to describe a network slice/service. It contains all the potential attributes to define a network slice regardless of the industry vertical use case.
    • Network Slice Template (NEST): a GST filled with values that serves the purpose of describing the features of vendor-specific products fulfilling a particular vertical use case. Furthermore, a NEST can reference the contractual agreements between slice customers and operators, while facilitating the definition of network slices across multi-operator roaming agreements.

The process of creating a NEST based on the customer’s use case is depicted in the next Figure. As seen, the service requirements derived from a specific vertical industry use case are translated into technical requirements. This leads to NEST formation with industry-accepted characteristics, with specific values or value ranges that have been commonly agreed and can be used by operators if they consider it appropriate. Once NEST is created, and therefore the network requirements are defined, the 3rd Generation Partnership Project (3GPP) network slice preparation phase can be initiated as described later in this document.

Figure 3. GSMA NEST

As already stated, the aim of GSMA-NEST is to define a set of NESTs with industry-accepted slice characteristics shareable between all network operators. The introduction of Standardized NESTs (S-NESTs) enables the replication of network slice behavior across network boundaries. GSMA-defined NESTs provide a mapping to the standardized 3GPP Slice/Service Type (SST) values, introducing the “minimum requirements” to address each Network Slice Type. On the contrary, operator-specific Private NESTs (P-NESTs) are also foreseen. The specification of P-NESTs is assigned to each respective network operator and is based on negotiations between the operator and its customers.

In 5GASP we aim to create P-NESTs given our Network Applications requirements. These P-NESTs will be instantiated by 5GASP’s infrastructure.

Exemplary Network Application

Here is an example of a Network Application called Fire detection and ground assistance using drones (FIDEGAD), with its architecture using the provided template.

Wildfires are one of the costliest and deadliest natural disasters across the world, especially in the Mediterranean region. The immediate impacts include damage to millions of hectares of forest resources, evacuation of thousands of people, burning of homes and devastation of infrastructure, and most importantly, threatening the lives of people.

This Network Application will give to teams the first assessment of buildings and forests on fire. The Network Application is onboarded to an air drone as a cloud-native application together with services on the Edge ensuring low latency. Telemetry, as well as information from infrared sensors, speakers, conventional video, and thermal vision, are transmitted to the 5G System and from there to the teams on the ground. The Network Application not only handles the drone live images streaming and processing, but also allows the teams on ground to adjust the altitude at which flyover takes place according to the height of the flames. Apart from the service creation time, it shall also be critical for the handover between 5G stations.

Network Application high level infrastructure

The Network Application is onboarded to a drone along with services running to the Edge, i.e. image recognition services, ensuring the lowest latency in case of fire detection. Besides that, information from multiple input channels is transmitted to the 5G System and from there to the ground units. Ground units would be able to take over the control of the drone, apart from receiving the aforementioned information.

Figure 4. FIDEGAD Network Application architecture

The Network Application NEST table with needed slice requirements:

A table filled with needed resources: