5G – Apis Training

New Course | 2G to 5G – Evolution, Architecture and Features

linda — Fri, 07 Nov 2025 11:06:02 +0000

This new course presents an introduction to 3GPP networks, the system architecture and evolution, as well as selected network procedures and features.

The course presents similarities and differences between different 3GPP system generations. Basic architecture, terms, concepts, procedures, radio technologies, and the core network functions are introduced. With the 2G and 3G being phased out, the focus is on the newer 4G and 5G systems.

Course Topics

Course Highlights

5G Standalone Architecture and Features

linda — Tue, 07 Oct 2025 11:09:39 +0000

5G Standalone Architecture and Features

Virtual Classroom

€ 1 020*

Classroom Training

€ 1 020*

eLearning

€ 195*

*Prices exclude VAT

Course Contents

This course provides an overview of the 5G Standalone (SA) network architecture and features as specified in the 3GPP standards.

It examines the architecture and key components of both the Access and Core Networks, addressing deployment scenarios for Non-Standalone (NSA) and Standalone (SA) modes.

The course concentrates on the advanced 5G SA capabilities – including features that support the transmission of voice, video, and data from a diverse set of applications with varying traffic characteristics, and those features that enable operators to deploy and manage the network in a cost-efficient and scalable manner.

Course outline

Introduction to 5G

• Expectations and requirements
• 5G Use Cases
• Evolution of the 3GPP standards for 5G since R15

5G Network Architecture

• 5G network architecture: access networks and core network
• UE and external data networks
• Deployment options: Non-Standalone (NSA) and Standalone (SA)
• Network Functions Virtualisation (NFV) as a tool to implement the 5G System (5GS)
• 5G UE Identifiers

5G Access Network

• NG-RAN: 5G New Radio, NR
o NR Frequency bands for 5G: FR1 and FR2 (mmWave)
o Comparison of the NR and E-UTRAN characteristics
• NG-RAN: gNB
o gNB functionalities
o Centralized Radio Access Network (C-RAN) deployment option
o Open-RAN (O-RAN) deployment option
• LTE/E-UTRAN access in 5G
o Dual connectivity: single-RAT and multi-RAT
• Satellite Access in 5G
• Non-3GPP Access Networks
o Untrusted WiFi
o Trusted Wifi
o Multi-access PDU sessions for WiFi Offload
o Wireline/Fixed

5G Core Network

• 5G Core Network (5G CN) Architecture
o Service Based Architecture (SBA) principles
o 5G CN Network Functions (NFs)
o 5G CN roaming architecture
• Network Functions Virtualisation in 5G CN
• Basic signalling procedures
o UE Network Access: 5G Registration
o UE Service Access: PDU Session Establishment

The 5G User Plane

• UP resources in 5G
o Basic definitions: QoS Flow, Service Data Flow (SDF)
o 5G QoS parameters: 5QI
o 5G Routing rules: traffic steering and influencing
• PDU Session
o Attributes
o Session types and the corresponding use cases

Advanced 5G network capabilities for enhanced service handling

• Traffic Steering and Service Influencing via NEF: 5G APIs
• Network Slicing
• Edge computing
• Private Networks
• Local Area Data Networks
• Time Sensitive Communication

Application-specific support in 5G

• Telephony Service support
o IP Multimedia Subsystem (IMS) control
o EPS/RAT fallback procedures
• Advanced Data Services support
o Sessions with multiple PSAs
o Localised Services
• Internet of Things (IoT) support

Prerequisites

Technical knowledge of mobile telecom is strongly recommended. A solid understanding of 4G LTE/EPS will be highly beneficial.

Webinar | Public Safety Services in 5G

linda — Wed, 24 Sep 2025 22:00:00 +0000

This webinar presents the 5G 3GPP solution for the public safety services.

It introduces the major radio and core network features in the 5G Standalone deployments designed to fulfill the stringent Quality of Service requirements of critical communication services. Both access and the core network features that enable low-latency, high-priority communication for fast-response verticals are covered.

Webinar Topics

Introduction to Critical Communication and Public Safety Services

The 5G 3GPP Solution for Public Safety Services

Timeline of the 3GPP specifications for Public Safety Services
Overall 5G architecture for Public Safety Services
Communication components for Public Safety Services
Public Safety Services support: radio features
Public Safety Services support: core network featuress

Get free access to the webinar on Apis Academy!

Five Thoughts from the Big 5G Event

linda — Tue, 28 Jun 2022 08:55:20 +0000

The first post-pandemic Big 5G Event was held in Austin, Texas in late May 2022. Apis Training was there, talking to customers and listening to speakers from the industry. With up to five parallel tracks, it was impossible to cover more than a fraction of the interesting sessions. Still – these are some of our thoughts after the week had passed at the Big 5G event.

Edge is hot!

Lots of attention was given to Edge (or Edge Computing) in various shapes and forms. We all seem to agree that edge computing is the way to handle e.g. latency-sensitive applications and/or “data-heavy” workloads. But the edge can mean different things in terms of both physical location (on-premise, RAN site or in the same part of town) and who owns the (cloud) hardware on which application servers are deployed; the mobile operator, the customer itself or someone else? As is often the case, there is no one-size-fits-all model here. In fact, a variety of deployment models and partnerships can be expected including the use of services from hyperscalers like AWS, MS Azure, and Google Cloud.

Open RAN is hot!

Although the status is somewhat unclear for an outsider. On one hand, there are already existing Open RAN deployments. On the other hand, it seems like this super-open Open RAN ecosystem with an abundance of providers of hardware and software (near-RT and non-RT RAN Intelligent Controllers, xApps, rApps) may still need some time to mature. It is also a matter of discipline from the Open RAN community to make the open interfaces (like A1 and E2) stay truly open, and resist adding proprietary features and tricks! Speakers at the event mentioned that integration of hardware and software from multiple vendors is often a challenge. This brings us to the third remark…

There is Private 5G and then there is Private 5G!

If you have heard different people saying different things about private 5G, it may be because they talked about different things. A private 5G network can be very big or very small, used for a variety of services or be tailor-made for a single application and can be implemented (built, operated, owned) in many different ways, including as a network slice in a public network. Although 3GPP specs are equally relevant for public and private networks, the business logic and drivers are typically quite different. So, any company working with private 5G need to reflect upon what private 5G niche(s) it wants to be in, and make sure it understands the technical and commercial conditions for that particular niche.

Watch our Private 4G/5G Webinar

System integration will be tricky!

Which is no surprise to anyone who has been around a while. Even a small, perhaps private, 5G network is a complicated system built from processors, memory, cables, fibers, radios, software for generic IT purposes (like cloud management), and 5G specific applications (like all the Network Functions). And with openness and “IT-fication” of telecom infrastructure – system integration on different levels will be a true challenge. Which brings us to the last of our remarks…

Skilled people are hot!

This may require some clarification… Several companies emphasized that attracting and retaining talent – a.k.a. skilled, competent human beings – is a strategic matter of the highest importance. Despite automation, AI/ML, and self-optimizing networks, humans are very much needed! And let’s face it: we are no longer just telecom people but rather IT people working with the mobile telecom vertical. And competition for talented IT people is fierce! To finish off with an obvious sales pitch, we at Apis Training believe that training staff to understand the bigger picture around their areas of expertise is an investment in people that pays for itself very quickly.

To conclude, lots of added value to share with you! We have more value to share, soon in September, there will be a great webinar again with guest speaker Daniel Person. This webinar is about Private 5G: The next level of Connectivity.

We hope to see you in this webinar!

About 4G and 5G Interworking

linda — Thu, 02 Jun 2022 07:33:49 +0000

As the evolution of 3GPP system continues, there are more and more 5G network deployments all over the world. The latest generation of the mobile system offers technological possibilities for a range of new services and applications: higher connection speeds, more Internet of Things devices and applications, Augmented/Virtual Reality, smart factories, vehicle communication with other vehicles and infrastructure elements, and so on. And, well, good old voice and SMS.

The 5G system may be deployed in a number of ways, providing various network evolution paths, usually starting with a Non-Standalone option (with a 4G core network still handling the connections) and then moving towards the Standalone solution with the 5G core network separated, interconnected or combined with an existing 4G network. Phones and devices of various kinds also support and require different features. This creates a large number of scenarios, connectivity options, mobility procedures, connection transfer and so on. The possible Wi-Fi and wireline access to 5G core increases the number of potential scenarios.

The 4G and 5G interworking course by Apis addresses most of the issues and possible scenarios within one day and is based on the latest R16 standards from 3GPP. The course presents 4G and 5G network architecture for different interoperability scenarios, UE aspects and capabilities on radio and core network levels, idle and connected mode mobility procedures, connection transfer options for data and voice connections, radio network dual connectivity options and possible traffic splitting in the mixed 4G/5G environment. Some time is also spent on interworking with earlier 2G/3G networks, as well as some procedures for non-3GPP access (Wi-Fi or wireline).

Please note that this course focuses on system-level interworking procedures. For those additionally interested in IMS-based multimedia handling in mixed 4G/5G networks, we recommend our 2-day Voice in 5G course instead.

Open RAN – What is it and Why?

linda — Fri, 06 May 2022 07:35:00 +0000

A few telecom generations ago, Radio Access Network (RAN) equipment was typically provided by a quite small number of telecom equipment manufacturers. There was Ericsson, Nokia, Huawei, Siemens, Alcatel, Lucent, Nortel, Motorola and a few more. Although there were standardized interfaces – by ETSI/3GPP – from BTS to BSC (in 2G) and Node B to RNC (in 3G), conventional wisdom among operators was that mixing equipment from different vendors could result in trouble, or at least some lost functionality.

During the last decade or so, trends like virtualization, cloudification and softwarization has changed the RAN landscape. The 4G/LTE base station, the eNB, is technically one entity in 3GPP specifications. But real-world implementations often split the eNB into multiple physical and logical parts, often referred to as e.g. Base Band Units (BBUs) and Remote Radio Units (RRUs). It’s important to note that the terminology here is un-standardized, which means that there is no all-encompassing view of what a BBU, RRU, RRH or RU exactly is or does. And obviously, splitting base stations into smaller parts leads to the introduction of new (more or less standardized) interfaces and protocols.

In 5G, 3GPP introduces a split of the 5G base station, the gNB, into a central unit (gNB-CU) and a distributed unit (gNB-DU), separated by the F1 interface. The gNB-CU can in turn be split into a control plane part (gNB-CU-CP) and a user plane part (gNB-CU-UP) since handling the control plane signalling to/from UEs is quite a different task from handling the user plane traffic. Hence, the E1 interface has been introduced resulting in a gNB design shown in the picture below.

Figure 1: gNB split according to 3GPP

So where does Open RAN fit into all this? First of all, Open RAN is not one single thing! In fact, there are various Open RAN initiatives and projects that, in different ways, aim to make the RAN ecosystem more “open”. For example, the Telecom Infra Project (TIP) has a high-level goal of making affordable telecom infrastructure available to a larger share of the world’s population. There is also the Open RAN Policy Coalition which, as the name suggests, tries to influence policy makers to act for more openness in the RAN world.

And then there is the O-RAN Alliance, who in their own words are “Transforming the Radio Access Networks Industry Towards Open, Intelligent, Virtualized and Fully Interoperable RAN”. So, it is about openness and interoperability, which means allowing new players to enter the RAN market with new software, hardware or services. It is about intelligence, which means using Artificial Intelligence (AI) and Machine Learning (ML) to make RANs faster, better and more flexible. And obviously, the assumption is that most things in a RAN will be deployed as virtualized network functions (VNFs) rather than physical entities.

O-RAN Alliance has 26 operator members including some of the biggest operator groups on this planet. They cannot be ignored! There are also some 200 contributors – a variety of companies of different sizes and businesses that are in some way involved in the O-RAN activities.

The O-RAN Alliance writes technical specifications. Their purpose is to complement 3GPP specs, not to replace or compete with them. In fact, the O-RAN Alliance also aims to give input to 3GPP specification work so that more openness can be achieved.

O-RAN Alliance has presented an O-RAN logical architecture as shown in figure 2 below.

Figure 2: O-RAN overall logical architecture (source: O-RAN Alliance white paper)

Some things are familiar, like the F1 and E1 interfaces and terms like O-CU-CP, O-CU-UP and O-DU, which can roughly be mapped to the 3GPP terminology. But in the O-RAN architecture, there is also an O-RU (O-RAN Radio Unit) which contains the lower part of the physical layer. This calls for the introduction of yet another interface – the Open Fronthaul interface.

The Open Fronthaul interface is based on eCPRI (enhanced Common Public Radio Interface). Despite eCPRI being an industry standard, there is still room for implementation-dependent features and tweaks. And actually, the same has been said for F1. Although F1 is standardized by 3GPP, vendors are often tempted to squeeze in some special vendor x-specific feature. Understandable as this may be, it still counteracts the idea of open interfaces and interoperability. And this is of course why O-RAN Alliance aims for truly open and standardized interfaces.

The O-RAN logical architecture also shows an “O-Cloud” which is where virtualized O-RAN network functions are implemented as virtual machines (VMs) and/or containers using COTS (or white-box) hardware. Decoupling of software and hardware is one of the pillars in the O-RAN approach.

One area which historically often has been unclear or incomplete in 3GPP specifications is Management and Operation. We frequently use acronyms like OSS/BSS, O&M, FCAPS etc. but these systems and features are typically based on proprietary solutions from vendors or the operator itself. So, in order to have a common approach to how the RAN entities are configured, supervised and dynamically managed, there is the Non-Real Time RIC (RAN Intelligent Controller) and Near-Real Time RIC.

In 5G NR, radio resources are assigned and re-assigned on millisecond level. In fact, Radio Resource Management (RRM) can even be done in fractions of milliseconds subject to so-called NR numerologies. These super-fast RRM cycles happen between O-DU and O-RU, i.e. “far out” in the RAN. But if we want the RRM to be dynamic, adaptive and flexible, then the base stations – or parts of them – need to be informed that another priority scheme shall be used. Or that the interference level in some cell(s) calls for a different algorithm to be used, or that a certain group of Public Safety UEs now needs 25% more capacity. This is where the Near-Real Time RIC comes in, working in decision cycles of 10 ms – 1s, giving RRM instructions to the O-CU and O-RU. The Near-Real Time RIC hosts so-called xApps which can be viewed as applications that perform some type of radio-related service. The xApps can come from the vendor of the Near-Real Time RIC or from a third-party company. Again, openness refers also to the possibility for a small company with a nice idea for some RAN-related service to be part of the huge global RAN market. The figure below shows applications inside the Near-Real Time RIC.

Figure 3: O-RAN Alliance reference architecture (source: O-RAN Alliance white paper)

And then we have the Service Management and Orchestration (SMO) layer containing, among other things, the Non-Real Time RIC. In short, SMO is about managing equipment and functions. Starting and configuring things, scaling them when conditions change, making sure they work as they should and stopping/deleting things when they are no longer needed.

The Non-Real Time RIC operates in “cycles” of more than 1s. It makes decisions based on input from the RAN itself, but also other external sources, for example a Business Support System or an Application Server. In a sense, this allows “the outside world” to interact with the RAN and influence the Radio Resource Management in almost real-time.

If you were in the telecom business about 20 years ago, you may remember that some operators feared that their networks would be reduced to “stupid bit pipes” for OTT (Over-The-Top) services provided by someone else. In hindsight, it is true that most services/applications today are not from the traditional operator. But the networks have become far from “stupid bit pipes”! And perhaps we should view the various Open RAN initiatives as yet another way to make RANs even more intelligent, allowing everyone involved to get more value from them.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

About Voice in 5G

linda — Fri, 22 Apr 2022 07:38:00 +0000

Mobile operators have been expanding their customer base for a few years now, providing connectivity for an ever-growing variety of services and applications. Internet of Things, Augmented/Virtual Reality, smart factories, communication between vehicles – all of these create new business opportunities. However, in this new connected world, the transportation of voice calls remains the basic service, and supporting it is still the main use case for most mobile operators.

The strong, worldwide drive to deploy 5G networks in order to efficiently support all the new applications and verticals is coupled with a big interest on how to support the telephony service in the 5G ecosystem. Recognising that interest, we have developed a 2-day course, Voice in 5G. This course summarises the standardisation R15 and R16 work done by 3GPP for the telephony service and its interoperability with earlier generations of 3GPP systems.

The Voice in 5G course also presents telephony-specific definitions for the UE and the 5G network for the Standalone (SA) 5G deployment for the device behaviour, transport rules in the 5G System, and the IMS control of the service access. The 5G deployments are a mix of E-UTRA (LTE), WiFi and New Radio (NR) accesses, with different choices for the Core Network design (combinations of the 4G Evolved Packet Core and the 5G Core) resulting in a need for tight interworking between 4G and 5G. This course will therefore also present the rules for UE idle mode mobility, service establishment, service continuity and session transfers in a mixed environment as defined by 3GPP and GSMA.

Please note that significant parts of this course cover IMS-related topics. For those who are interested in only system-level interworking procedures, we recommend our 1-day, 4G and 5G Interworking course.

Multi-access Edge Computing (MEC) and 5G

linda — Thu, 22 Oct 2020 07:41:00 +0000

Edge computing is a concept that:

enables low latencies for time-critical services, known in 5G as Ultra-Reliable Low-Latency Communication (URLLC) services
handles bandwidth-heavy applications closer to the end user in order to offload the transport network

European Telecommunications Standards Institute (ETSI) is leading standardization activities around Multi-access Edge Computing (MEC).

MEC provides compute and storage resources for applications geographically close to the end users. This enables high-bandwidth, low-latency access to services. Real-time radio network information can be used to optimize and adapt the services to the current radio situation.

Several 5G use cases are expected to rely on MEC to deliver added value for services to the end users e.g. inside factory buildings, hospitals, ports as well as in supporting technologies such as virtual and augmented reality.

It is estimated that by 2023, 5G will make up around one-fifth of all mobile data traffic, where 25% of the use cases will depend on edge computing capabilities. The majority of new 5G revenue potential is expected to come from enterprise and IoT services, of which many will rely on edge computing.

In addition to providing an execution environment for running applications at the edge, MEC also enables services that supply information on end user and base station context (Radio Network Information Services), such as the radio channel quality of users and their location in the network, which allows design of context-aware applications. A context-aware system is one that can determine and react to the current physical and computing context of mobile users and devices.

The ETSI MEC Industry Specification Group (ISG) has been working on the development of standardization activities around MEC since 2013. Its first released document covers the reference architecture.

The MEC host provides the virtualization environment to run MEC applications, while interacting with mobile network entities via the MEC platform (MEP) to provide MEC services and data offload to MEC applications. Two MEC hosts can communicate via the Mp3 interface aiming at managing user mobility via the migration of MEC applications among MEC hosts.

The MEC platform (MEP) acts as an interface between the mobile network and the MEC applications. It has an interface (Mp1) for MEC applications to expose and consume MEC services, and another (Mp2) to interact with the mobile network. The latter is used to obtain statistics from the Radio Access Network (RAN) on User Equipments (UEs) and Next Generation NodeBs (gNBs), e.g. to provide the Radio Network Information Service (RNIS) and the Location Service, and to appropriately steer user plane traffic to MEC applications.

MEC applications run on top of a virtualized platform. MEC services provided by third-party MEC applications should be registered with the MEP and made available over the Mp1 reference point. Once registered, a service may be discovered and consumed by other MEC applications.

For the management plane, ETSI MEC introduced the Mobile Edge Orchestrator (MEO), which is in charge of the life-cycle of MEC applications (instantiation, orchestration and management), and acts as the interface between the MEC host and the Operations/Business Support System (OSS/BSS).

In the 5G architecture, the MEP will be integrated as a 5G Application Function (AF), trusted or untrusted, depending on the use case. It may request traffic redirection for a MEC application to a location “closer to the edge”. If the MEP is a trusted 5G AF, it can directly use the Policy Control Function (PCF) to generate a policy to offload traffic towards the MEC application. If it is not considered as a trusted 5G AF, it uses the Network Exposure Function (NEF) to access the Session Management Function (SMF), via its traffic filter policy API, and requests the traffic redirection.

One interesting question that often pops up is: what – or where – is the actual edge of the network? Depending on who you ask, you’ll be given a variety of very different answers. Obviously, there is no standardized definition of the word edge, so it very much depends on the application as to how close to the user the application needs to be. In some cases, edge computing requires that the hardware (and software) for the application needs to be physically co-located with the gNB inside a production plant, for example. For caching popular media content (e.g. a new episode of some popular TV series), a neighborhood or even a city can be considered to be the edge.

5G-training

The native 5G network monitoring: NWDAF

linda — Thu, 08 Oct 2020 07:42:00 +0000

NWDAF Services

NWDAF is introduced in R15 in the 23.501 specification, with its details outlined in 23.288 and 29.520. In its capacity as a Service Producer it has two services defined in the R16 standards that enable Network Consumers (e.g. the PCF) to receive various analytics from the NWDAF.

In order to perform that task the NWDAF collects data from a number of Network Functions (NFs).

The list of analytics the NWDAF can provide is already impressive in R16, and expected to grow in the future. At the moment it contains:

Slice load information
R16 analytics
Observed service experience
NF load
Network performance
User equipment (UE) mobility
UE communication
Expected UE behaviour
User data congestion
Potential QoS change

The detailed list of events can be found in 29.520.

It will be interesting to see how this development might affect the current approach of the mobile operators to monitoring both their network performance, and the UEs. It seems to be a tool especially useful in the current environment where mobile networks are expected to provide transport for very different applications with a great diversity of communication and mobility patterns.

For more information on the 5G CN see Apis “5G Core Network Architecture” course.

Access Networks for the 5GC in R16 3GPP standards

linda — Mon, 15 Jun 2020 07:44:00 +0000

The 5GS System (5GS), just as the previous mobile telecom systems, consists of the Access Network (AN) and the Core Network (CN). R15 of the 3GPP standards defined the 5G New Radio (NR) and E-UTRA (commonly referred to as LTE) as the 3GPP Access Type, and Untrusted WiFi as the non-3GPP Access Type. In R16 the list of Access Types is was extended, with Trusted WiFi and Wireline accesses added as options within the non-3GPP Access Type.

3gpp 5G

The Trusted WiFi access added in the R16 3GPP standards, termed “Trusted Non-3GPP Access” is using the Trusted Non-3GPP Access Point (TNAP) for connectivity with the UE over the radio, and the Trusted Non-3GPP Gateway Function (TNGF) to terminate the N2 and N3 interfaces to the AMF and UPF, respectively, and the IPsec tunnel towards the UE.

For this scenario a UE needs to first perform a PLMN selection (over 3GPP access) and only afterwards will be allowed to select a TNGF within that PLMN. In most cases a UE utilizing the 3GPP and Trusted Non-3GPP accesses simultaneously will be serviced by one AMF and will have one common 5G-GUTI allocated, with the AMF terminating two different N1 connections and running two separate Registration Management (RM) and Connection Management (CM) state machines for the UE. The only exception is when a roaming UE uses different connection options (Local Breakout vs Home-Routed) for the 3GPP and for the non-3GPP accesses.

Wireline

R16 standards add an option of Wireline access for the 5G UEs. The specifications mention two types of connections: from the Broadband Forum (BBF) and Data Over Cable Service Interface Specification (DOCSIS): In both cases, a Wireline Access Gateway Function (W-AGF) is used to terminate the N2 and N3 interfaces. The standards define a 5G-aware 5G Residential Gateway (5G-RG), or allow for a non-5G aware Fixed Network Residential Gateway (FN-RG) to be used. In the first case the 5G-RG acts as a 5G UE, terminating the N1 interface, while in the latter – the W-AGF has to take over the handling of the N1.

Roaming scenarios with the 5G-RG and the FN-RG are not specified in the current release of the standards.

With these new definitions the 5G is well on its way to offer wireless and wireline convergence, with a uniform handling of the UE access, security, mobility procedures as well as application-specific QoS, traffic steering and charging handling .

For more information on the 5G CN go to our in-depth 5G Core Network Architecture course.