Tag Archives: 5GC

Will 5GC be used in Wireline Access? No. Here’s why.

5G SA, EPC, Mobile Networks, RFCs & Standards, , , , ,

One of the hyped benefits of a 5G Core Networks is that 5GC can be used for wired networks (think DSL or GPON) – In marketing terms this is called “Wireless Wireline Convergence” (5G WWC) meaning DSL operators, cable operators and fibre network operators can all get in on this sweet 5GC action and use this sexy 5G Core Network tech.

This is something that’s in the standards, and that the big kit vendors are pushing heavily in their marketing materials. But will it take off? And should operators of wireline networks (fixed networks) be looking to embrace 5GC?

Comparing 5GC with current wireline network technologies isn’t comparing apples to apples, it’s apples to oranges, and they’re different fruits.

At its heart, the 3GPP Core Networks (including 5G Core) address one particular use cases of the cellular industry: Subscriber mobility – Allowing a customer to move around the network, being served by different kit (gNodeBs) while keeping the same IP Address.

The most important function of 5GC is subscriber mobility.

This is achieved through the use of encapsulating all the subscriber’s IP data into a GTP (A protocol that’s been around since 2G first added data).

Do I need a 5GC for my Fixed Network?

Wireline networks are fixed. Subscribers don’t constantly move around the network. A GPON customer doesn’t need to move their OLT every 30 minutes to a new location.

Encapsulating a fixed subscriber’s traffic in GTP adds significant processing overhead, for almost no gain – The needs of a wireline network operator, are vastly different to the needs of a cellular core.

Today, you can take a /24 IPv4 block, route it to a DSLAM, OLT or CMTS, and give an IP to 254 customers – No cellular core needed, just a router and your access device and you’re done, and this has been possible for decades.
Because there’s no mobility the GTP encapsulation that is the bedrock for cellular, is not needed.

Rather than routing directly to Access Network kit, most fixed operators deploy BRAS systems used for fixed access. Like the cellular packet core, BRAS has been around for a very long time, with a massive install base and a sea of engineering experience in house, it meets the needs of the wireline industry who define its functions and roles along with kit vendors of wireline kit; the fixed industry working groups defined the BRAS in the same way the 3GPP and cellular industry working groups defined 5G Core.

I don’t forsee that we’ll see large scale replacement of BRAS by 5GC, for the same reason a wireless operator won’t replace their mobile core with a BRAS and PPPoE – They’re designed to meet different needs.

All the other features that have been added to the 3GPP Core Network functionality, like limiting speed, guaranteed throughput bearers, 5QI / QCI values, etc, are addons – nice-to-haves. All of these capabilities could be implemented in wireline networks today – if the business case and customer demand was there.

But what about slicing?

With dropping ARPUs across the board, additional services relating to QoS (“Network Slicing”) are being held up as the saving grace of revenues for cellular operators and 5G as a whole, however this has yet to be realized and early indications suggest this is not going to be anywhere near as lucrative as previously hoped.

What about cost savings?

In terms of cost-per-bit of throughput, the existing install base wireline operators have of heavy-metal kit capable of terabit switching and routing has been around for some time in fixed world, and is what most 5G Cores will connect to as their upstream anyway, so there won’t be any significant savings on equipment, power consumption or footprint to be gained.

Fixed networks transport the majority of the world’s data today – Wireline access still accounts for the majority of traffic volumes, so wireline kit handles a higher magnitude of throughput than it’s Packet Core / 5GC cousins already.

Cutting down the number of parts in the network is good though right?

If you’re operating both a Packet Core for Cellular, and a fixed network today, then you might think if you moved from the traditional BRAS architecture fore the wired network to 5GC, you could drop all those pesky routers and switches clogging up your CO, Exchanges and Data Centers.

The problem is that you still need all of those after the 5GC to be able to get the traffic anywhere users want to go. So the 5GC will still need all of that kit, all your border routers and peering routers will remain unchanged, as well as domestic transmission, MPLS and transport.

The parts required for operating fixed networks is actually pretty darn small in comparison to that of 5GC.

TL;DR?

While cellular vendors would love to sell their 5GC platform into fixed operators, the premise that they are willing to replace existing BRAS architectures with 5GC, is as unlikely in my view as 5GC being replaced by BRAS.

If you like Pina Coladas, and service the control plane – Intro to NRF in 5GC

5G SA, Mobile Networks, RFCs & Standards, SDM, , , ,

The Network Repository Function plays matchmaker to all the elements in our 5G Core.

For our 5G Service-Based-Architecture (SBA) we use Service Based Interfaces (SBIs) to communicate between Network Functions. Sometimes a Network Function acts as a server for these interfaces (aka “Service Producer”) and sometimes it acts as a client on these interfaces (aka “Service Consumer”).

For service consumers to be able to find service producers (Clients to be able to find servers), we need a directory mechanism for clients to be able to find the servers to serve their needs, this is the role of the NRF.

With every Service Producer registering to the NRF, the NRF has knowledge of all the available Service Producers in the network, so when a Service Consumer NF comes along (Like an AMF looking for UDM), it just queries the NRF to get the details of who can serve it.

Basic Process – NRF Registration

In order to be found, a service producer NF has to register with the NRF, so the NRF has enough info on the service-producer to be able to recommend it to service-consumers.

This is all the basic info, the Service Based Interfaces (SBIs) that this NF serves, the PLMN, and the type of NF.

The NRF then stores this information in a database, ready to be found by SBI Service Consumers.

This is achieved by the Service Producing NF sending a HTTP2 PUT to the NRF, with the message body containing all the particulars about the services it offers.

Simplified example of an SMSc registering with the NRF in a 5G Core

Basic Process – NRF Discovery

With an NRF that has a few SBI Service Producers registered in it, we can now start querying it from SBI Service Consumers, to find SBI Service Producers.

The SBI Service Consumer looking for a SBI Service Producer, queries the NRF with a little information about itself, and the SBI Service Producer it’s looking for.

For example a SMF looking for a UDM, sends a request like:

http://[::1]:7777/nnrf-disc/v1/nf-instances?requester-nf-type=SMF&target-nf-type=UDM

To the NRF, and the NRF responds with SBI Service Producing NFs that match in JSON body of the response.

SMSF being found by the AMF using the NRF

More Info

I’ve written in a more technical detail on the NRF in this post, you can learn about setting up Open5Gs NRF in this post, and keep tuned for a lot more content on 5GC!

Framed Routing in 5G

5G SA, Mobile Networks, , ,

Previous generations of core mobile network, would only allocate a single IP address per UE (Well, two if dual-stack IPv4/IPv6 if you want to be technical). But one of the cool features in 5GC is the support for Framed Routing natively.

You could do this on several EPC platforms on LTE, but it’s support was always a bit shoe-horned in, and the UE was not informed of the framed addresses.

If you’ve worked in a wireline ISP you’re probably familiar with the concept of framed routing already, in short it’s one or more static routes, typically returned from a AAA server (Normally RADIUS) that are then routed to the subscriber.

Each subscriber gets allocated an IP by the network, but other IPs can also be routed to the subscriber, based on the network and CIDR mask.

So let’s say we allocate a public IP of 1.2.3.4/32 to our subscriber, but our subscriber is a fixed-wireless user running a business and they want a extra public IP Addresses.

How do we do this? With Framed Routing.

Now in our UDM we can add a “Framed IP”, and when the SMF sets up a session for our subscriber, the extra networks specified in the framed routes will get routed to that UE.

If we add 203.176.196.0/30 in our UDM for a subscriber, when the subscriber attaches the UPF will be setup to forward traffic to 1.2.3.4/32 and also traffic to 203.176.196.0/30 to the UE.

Update: I previously claimed:
Best of all this is signaled to the UE during the attach, so the UE is say a router, it becomes aware of the Framed IPs allocated to it.
This is incorrect! Thanks to Anonymous Telco Engineer from an Anonymous Nordic Country for pointing this out, it is not signaled to the UE.

More info in 3GPP TS 23.501 section 5.6.14 Support of Framed Routing.

Reflective QoS in 5G

5G SA, Mobile Networks, ,

Reflective QoS is a clever new concept introduced in 5G SA networks.

The concept is rather simple, apply QoS in the downlink, and let the UE reply using the QoS in the uplink.

So what is Reflective QoS?
If I send an ICMP ping request to a UE with a particular QoS Flow setup on the downlink, if Reflective QoS is enabled, the ICMP reply will have the same QoS applied on the uplink. Simple as that.

The UE looks at the QoS applied on the downlink traffic, and applies the same to the uplink traffic.

Let’s take another example, if a user starts playing an online game, and the traffic to the user (Downlink) has certain QoS parameters set, if Reflective QoS is enabled, the UE builds rules based on the incoming traffic based on the source IP / port / protocol of the traffic received, and the QoS used on the downlink, and applies the same on the uplink.

But actually getting Reflective QoS enabled requires a few more steps…

Reflective QoS is enabled on a per-packet basis, and is indicated by the UPF setting the Reflective QoS Indication (RQI) bit in the encapsulation header next to the QFI (This is set in the GTP header, as an extension header, used on the N3 and N9 reference points).

But before this is honored, a few other parameters have to be setup.

  • A Reflective QoS Timer (RQ Timer) has to be set, this can be done during the PDU Session Establishment, PDU Session Modification procedure, or set to a default value.
  • SMF has to set Reflective QoS Attribute (RQA) on the QoS profile for this traffic on the N2 reference point towards gNodeB
  • SMF must instruct UPF to use uplink reflective QoS by generating a new UL PDR for this SDF via the N4 reference point

When these requirements have been met, the traffic from the UPF to the gNodeB (N3 reference point) has the Reflective QoS Indication (RQI) bit in the encapsulation header, which is encapsulated and signaled down to the UE, which builds a rule based on the received IP source / port / protocol, and sends responses using the same QoS attributes.

N20 5G SBI for Nsmsf for SMS over 5GC

SMS in 5GC

5G SA, Mobile Networks, ,

Like in EPS / LTE, there are two ways to send SMS in Standalone 5G Core networks.

SMS over IMS or SMS over NAS – Both can be used on the same network, or just one, depending on operator preferences.

SMS over IMS in 5G

SMS over IMS uses the IMS network to send SMS. SIP MESSAGE methods are used to deliver SMS between users. While most operators have deployed IMS for 4G/LTE subscribers to use VoLTE some time ago, there are some changes required to the IMS architecture to support VoNR (Voice over New Radio) on the carrier side, and support for VoNR in commercial devices is currently in its early stages. Because of this many 5G devices and networks do not yet support SMS over IMS.

I’ve read in some places that RCS – The GSMA’s Rich Communications Service will replace SMS in 5GC. If this is the case, it reflected in any of the 3GPP standards.

SMS over NAS

To make a voice call on a device or network that does not support VoNR, EPS (VoLTE) fallback is used.
This means when making or receiving a call, the UE drops from the 5G RAN to using a 4G (LTE) basd RAN, and then uses VoLTE to make the call the same as it would when connected to 4G (LTE) networks, because it is connected to a 4G network.
This works technically, but is not the prefered option as it adds extra signaling and complexity to the network, and delays in the call setup, and it’s expected operators will eventually move to VoNR,but works as a stop-gap measure.

But mobile networks see a lot of SMS traffic. If every time an SMS was sent the UE had to rely on EPS fallback to access IMS, this would see users ping-ponging between 4G and 5G every time they sent or received an SMS.

This isn’t a new problem, in fact SMS-over-NAS was initially added to 4G (LTE) to allow devices to stay connected to the EPC (4G Core network) but still send and receive SMS, even if the network or device relied on “Circuit-Switched fallback” (A mechanism to drop from 4G to 2G / 3G for voice calls).

5GC reintroduces the SMS-over-NAS feature, allowing the SMS messages to be carried over NAS messaging on the N1 interface. Voice calls may still require fallback to EPS (4G) to make calls over VoLTE, but SMS can be carried over NAS messaging, minimizing the amount of Inter-RAT handovers required.

The Nsmsf_SMService

For this a new Service Based Interface is introduced between the AMF and the SMSF (SMS Function, typically built into an SMSc), via the N20 / Nsmsf SBI to offer the Nsmsf_SMService service.

There are 3 operations supported for the Nsmsf_SMService:

  • Active – Initiated by the AMF – Used to active the SMS service for a given subscriber,
  • Deactivate – Initiated by the AMF – Used to deactivate the SMS over NAS service for a given subscriber.
  • UplinkSMS – Initiated by the AMF to transfer the SMS payload towards the SMSF.

The UplinkSMS is a HTTP post from the AMF with the SUPI in the Request URI and the request body containing a JSON encoded SmsRecordData.

Astute readers may notice that’s all well and good, but that only covers Mobile Originated (MO) SMS, what about Mobile Terminated (MT) SMS?

Well that’s actually handled by a totally different SBI, the Namf_Communication action “N1N2MessageTransfer” is resused for sending MT SMS, as that interface already exists for use by SMF, LMF and PCF, and 5GC attempts to reuse interfaces as much as possible.

5G Online Charging with the Nchf_ConvergedCharging SBI

5G SA, Mobile Networks, RFCs & Standards, , , ,

There’s no such thing as a free lunch, and 5G is the same – services running through a 5G Standalone core need to be billed.

In 5G Core Networks, the SMF (Session Management Function) reaches out to the CHF (Charging Function) to perform online charging, via the Nchf_ConvergedCharging Service Based Interface (aka reference point).

Like in other generations of core mobile networks, Credit Control in 5G networks is based on 3 functions:
Requesting a quota for a subscriber from an online charging service, which if granted permits the subscriber to use a certain number of units (in this case data transferred in/out).
Just before those units are exhausted sending an update to request more units from the online charging service to allow the service to continue.
When the session has ended or or subscriber has disconnected, a termination to inform the online charging service to stop billing and refund any unused credit / units (data).

Initial Service Creation (ConvergedCharging_Create)

When the SMF needs to setup a session, (For example when the AMF sends the SMF a Nsmf_PDU_SessionCreate request), the CTF (Charging Trigger Function) built into the SMF sends a Nchf_ ConvergedCharging_Create (Initial, Quota Requested) to the Charging Function (CHF).

Because the Nchf_ConvergedCharging interface is a Service Based Interface this is carried over HTTP, in practice, this means the SMF sends a HTTP post to http://yourchargingfunction/Nchf_ConvergedCharging/v1/chargingdata/

Obviously there’s some additional information to be shared rather than just a HTTP post, so the HTTP post includes the ChargingDataRequest as the Request Body. If you’ve dealt with Diameter Credit Control you may be expecting the ChargingDataRequest information to be a huge jumble of nested AVPs, but it’s actually a fairly short list:

  • The subscriberIdentifier (SUPI) is included to identify the subscriber so the CHF knows which subscriber to charge
  • The nfConsumerIdentification identifies the SMF generating the request (The SBI Consumer)
  • The invocationTimeStamp and invocationSequenceNumber are both pretty self explanatory; the time the request is sent and the sequence number from the SBI consumer
  • The notifyUri identifies which URI should receive subsequent notifications from the CHF (For example if the CHF wants to terminate the session, the SMF to send that to)
  • The multipleUnitUsage defines the service-specific parameters for the quota being requested.
  • The triggers identifies the events that trigger the request

Of those each of the fields should be pretty self explanatory as to their purpose.
The multipleUnitUsage data is used like the Service Information AVP in Diameter based Credit Control, in that it defines the specifics of the service we’re requesting a quota for. Inside it contains a mandatory ratingGroup specifying which rating group the CHF should use, and optionally requestedUnit which can define either the amount of service units being requested (For us this is data in/out), or to tell the CHF units are needed. Typically this is used to define the amount of units to be requested.

On the amount of units requested we have a bit of a chicken-and-egg scenario; we don’t know how many units (In our case the units is transferred data in/out) to request, if we request too much we’ll take up all the customer’s credit, potentially prohibiting them from accessing other services, and not enough requested and we’ll constantly slam the CHF with requests for more credit.
In practice this value is somewhere between the two, and will vary quite a bit.

Based on the service details the SMF has put in the Nchf_ ConvergedCharging_Create request, the Charging Function (CHF) takes into account the subscriber’s current balance, credit control policies, etc, and uses this to determine if the Subscriber has the required balances to be granted a service, and if so, sends back a 201 CREATED response back to the Nchf_ConvergedCharging_Create request sent by the CTF inside the SMF.

This 201 CREATED response is again fairly clean and simple, the key information is in the multipleQuotaInformation which is nested within the ChargingDataResponse, which contains the finalUnitIndication defining the maximum units to be granted for the session, and the triggers to define when to check in with CHF again, for time, volume and quota thresholds.

And with that, the service is granted, the SMF can instruct the UPF to start allowing traffic through.

Update (ConvergedCharging_Update)

Once the granted units / quota has been exhausted, the Update (ConvergedCharging_Update) request is used for requesting subsequent usage / quota units. For example our Subscriber has used up all the data initially allocated but is still consuming data, so the SMF sends a Nchf_ConvergedCharging_Update request to request more units, via another HTTP post, to the CHF, with the requested service unit in the request body in the form of ChargingDataRequest as we saw in the initial ConvergedCharging_Create.

If the subscriber still has credit and the CHF is OK to allow their service to continue, the CHF returns a 200 OK with the ChargingDataResponse, again, detailing the units to be granted.

This procedure repeats over and over as the subscriber uses their allocated units.

Release (ConvergedCharging_Release)

Eventually when our subscriber disconnects, the SMF will generate a Nchf_ConvergedCharging_Release request, detailing the data the subscriber used in the ChargingDataRequest in the body, to the CHF, so it can refund any unused credits.

The CHF sends back a 204 No Content response, and the procedure is completed.

More Info

If you’ve had experience in Diameter credit control, this simple procedure will be a breath of fresh air, it’s clean and easy to comprehend,
If you’d like to learn more the 3GPP specification docs on the topic are clear and comprehensible, I’d suggest:

  • TS 132 290 – Short overview of charging mechanisms
  • TS 132 291 – Specifics of the Nchf_ConvergedCharging interface
  • The common 3GPP charging architecture is specified in TS 32.240
  • TS 132 291 – Overview of components and SBIs inc Operations

EIR in 5G Networks (N5g-eir_EquipmentIdentityCheck)

5G SA, Mobile Networks, SDM, , , ,

Today, we’re going to look at one of the simplest Service Based Interfaces in the 5G Core, the Equipment Identity Register (EIR).

The purpose of the EIR is very simple – When a subscriber connects to the network it’s Permanent Equipment Identifier (PEI) can be queried against an EIR to determine if that device should be allowed onto the network or not.

The PEI is the IMEI of a phone / device, with the idea being that stolen phones IMEIs are added to a forbidden list on the EIR, and prohibited from connecting to the network, making them useless, in turn making stolen phones harder to resell, deterring mobile phone theft.

In reality these forbidden-lists are typically either country specific or carrier specific, meaning if the phone is used in a different country, or in some cases a different carrier, the phone’s IMEI is not in the forbidden-list of the overseas operator and can be freely used.

The dialog goes something like this:

AMF: Hey EIR, can PEI 49-015420-323751-8 connect to the network?
EIR: (checks if 49-015420-323751-8 in forbidden list - It's not) Yes.

or

AMF: Hey EIR, can PEI 58-241992-991142-3 connect to the network?
EIR: (checks if 58-241992-991142-3 is in forbidden list - It is) No.

(Optionally the SUPI can be included in the query as well, to lock an IMSI to an IMEI, which is a requirement in some jurisdictions)

As we saw in the above script, the AMF queries the EIR using the N5g-eir_EquipmentIdentityCheck service.

The N5g-eir_EquipmentIdentityCheck service only offers one operation – CheckEquipmentIdentity.

It’s called by sending an HTTP GET to:

http://{apiRoot}/n5g-eir-eic/v1/equipment-status

Obviously we’ll need to include the PEI (IMEI) in the HTTP GET, which means if you remember back to basic HTTP GET, you may remember means you have to add ?attribute=value&attribute=value… for each attribute / value you want to share.

For the CheckEquipmentIdentity operation, the PEI is a mandatory parameter, and optionally the SUPI can be included, this means to query our PEI (The IMSI of the phone) against our EIR we’d simply send an HTTP GET to:

AMF: HTTP GET http://{apiRoot}/n5g-eir-eic/v1/equipment-status?pei=490154203237518
EIR: 200 (Body EirResponseData: status "WHITELISTED")

And how it would look for a blacklisted IMEI:

AMF: HTTP GET http://{apiRoot}/n5g-eir-eic/v1/equipment-status?pei=490154203237518
EIR: 404 (Body EirResponseData: status "BLACKLISTED")

Because it’s so simple, the N5g-eir_EquipmentIdentityCheck service is a great starting point for learning about 5G’s Service Based Interfaces.

You can find all the specifics in 3GPP TS 29.511 – Equipment Identity Register Services; Stage 3

5G Subscriber Identifiers – SUCI & SUPI

5G SA, Mobile Networks, SDM, Security, SIM Cards, , , , ,

The SUPI (Subscription Permanent Identifier) replaces the IMSI as the unique identifier for each Subscriber in 5G.

One of the issues with using IMSI in LTE/EUTRAN is there were a few occasions where the IMSI was sent over the clear – meaning the IMSIs of subscribers nearby could be revealed to anyone listening.

So what is a SUPI and what does it look like? Well, most likely it’ll look like an IMSI – 15 or 16 digits long, with the MCC/MNC as the prefix.

If you’re using a non-3GPP RAT it could be a RFC 4282 Network Access Identifier, but if it’s on a SIM card or in a Mobile Device, it’s probably exactly the same as the IMSI.

SUCI Subscription Concealed Identifier

Our SUPI is never sent over the air in the clear / plaintext, instead we rely on the SUCI (Subscription Concealed Identifier) for this, which replaces the GUTI/TMSI/IMSI for all plaintext transactions over the air.

Either the UE or the SIM generate the SUCI (if it’s done by the SIM it’s much slower), based on a set of parameters defined on the SIM.

The SUCI has to be generated by the UE or SIM in a way the Network can identify the SUPI behind the SUCI, but no one else can.

In LTE/EUTRAN this was done by the network randomly assigning a value (T-MSI / GUTI) and the network keeping track of which randomly assigned value mapped to which user, but initial attach and certain handovers revealed the real IMSI in the clear, so for 5G this isn’t an option.

So let’s take a look at how SUCI is calculated in a way that only the network can reveal the SUPI belonging to a SUCI.

The Crypto behind SUCI Calculation

As we’ll see further down, SUCI is actually made up of several values concatenated together. The most complicated of these values is the Protection Scheme Output, the cryptographically generated part of the SUCI that can be used to determine the SUPI by the network.

Currently 3GPP defines 3 “Protection Scheme Profiles” for calculating the SUCI.

Protection Scheme Identifier 1 – null-scheme

Does nothing. Doesn’t conceal the SUPI at all. If this scheme is used then the Protection Scheme Output is going to just be the SUPI, for anyone to sniff off the air.

Protection Scheme Identifier 2 & 3 – ECIES scheme profile A & B

The other two Protection Scheme Identifiers both rely on Elliptic Curve Integrated Encryption Scheme (ECIES) for generation.

This is better known as Elliptic Curve Encryption Scheme, it’s primarily used for Cryptography. Crypto is crazy complex, and I’m a mere mathematical mortal, but there’s a great post on the Cloudflare blog on the topic that touches on Elliptic Curve Encryption.

So if both Profile A & Profile B rely on Elliptic Curve Integrated Encryption Scheme, then what’s the difference between the two?

Well dear reader, the answer is semantics! There’s lots of parameters and variables that go into generating a resulting value from a cryptographic function, and Profile A & Profile B are just different parameters being used to generate the results.

For crypto nerds you can find the specifics in C.3.4.1 Profile A and C.3.4.1 Profile B outlined in 3GPP TS 33.501.

For non crypto nerds we just need to know this;

When the SIM is generating the SUCI the UE just asks for an identity by executing the GET IDENTITY command ADF against the SIM and uses the response as the SUCI.

When the UE is generating the SUCI, the UE gets the SUCI_Calc_Info EF contents from the SIM and extracts the Home Network Public Key from it’s reply. It uses this Home Network Public Key and a freshly created ephemeral public/private key pair to generate a SUCI value to use.

Creating the SUCI

After generating a Protection Scheme Output, we’ll need to add some extra info into it to make it useful.

The first digit of the SUCI is the SUPI type, a value of 0 denotes the value contained in the Protection Scheme Output is an IMSI, while 1 is used for Network Access Indicator for Non 3GPP access.

Next up we have the Home Network Identifier, which in a mobile environment is our PLMN (MCC/MCC).

Then a Routing Indicator, 1-4 digits long, is used with the Home Network Identifier to route the Authentication traffic to the UDM that contains that subscriber’s information, ie you may have MVNOs with their own UDM. If the routing indicator of 10 is assigned to the MVNOs SIMs then the AMF can be set to route traffic with a routing indicator of 10 to the UDM of the VMNO.

The Protection Scheme we covered earlier, with the 3 types of protection scheme (Null & two relying on Elliptic Curve Integrated Encryption Scheme).

Home Network Public Key Identifier identifies which Public Key was used to generate the Protection Scheme Output.

Finally we have the Protection Scheme Output which we covered generating in the previous session.

Usage in Signaling

The SUPI is actually rarely used beyond the initial attach to the network.

After authenticating to the network using AKA and the SUCI, in 5GC, like in LTE/EUTRAN, a shorter GUTI is used which further protects the subscriber’s identity and changes frequently.

Open5GS – NRF Setup

5G SA, Mobile Networks,

We covered NRFs last week, but I thought I’d cover actually configuring the NRF on Open5GS,

We’ll first off need to install the NRF,

$ sudo apt update 
$ sudo apt install software-properties-common 
$ sudo add-apt-repository ppa:open5gs/latest 
$ sudo apt update 
$ sudo apt install open5gs

Next up we’ll need to configure the NRF on the domain “nrf.5gc.mnc001.mcc001.3gppnetwork.org”, for this we’ll edit /etc/open5gs/nrf.conf and set the binding IP.

nrf:
  sbi:
    - addr:
       - 10.0.1.252
      port: 7777

Now for each Network Element we’re bringing online we’ll need to point it at our NRF’s address (or IP).

nrf:
  sbi:
    - addr:
       - nrf.5gc.mnc001.mcc001.3gppnetwork.org
      port: 7777

But there’s another very similar section inside the definition file, but this defines which IP the NRF client will listen on,

And that’s it,

From the log in /var/log/open5gs/nrf.log you see connections coming in,

5GC: The Network Function Repository Function

5G SA, Mobile Networks, RFCs & Standards, , , ,

The Problem

Mobile networks are designed to be redundant and resilient, with N+1 for everything.

Every network element connects to multiple other network elements.

The idea being the network is architected so a failure of any one network element will not impact service.

To take an LTE/EPC example, your eNodeBs connect to multiple MMEs, which in turn connect to multiple HSSs, multiple S-GWs, multiple EIRs, etc.
The problem is when each eNodeB connects to 3 MMEs, and you want to add a 4th MME, you have to go and reconfigure all the eNodeBs to point to the new MME, and all the HSSs to accept that MME as a new Diameter Peer, for example.

The more redundant you make the network, the harder it becomes to change.

This led to development of network elements like Diameter Routing Agents (DRAs) and DNS SRV for service discovery, but ultimately adding and removing network elements in previous generations of mobile core, involved changing a lot of config on a lot of different boxes.

The Solution

The NRF – Network Repository Function serves as a central repository for Network Functions (NFs) on the network.

In practice this means when you bring a new Network Function / Network Element online, you only need to point it at the NRF, which will tell it about other Network Functions on the network, register the new Network Function and let every other interested Network Function know about the new guy.

Take for example adding a new AMF to the network, after bringing it online the only bit of information the AMF really needs to start placing itself in the network, is the details of the NRF, so it can find everything it needs to know.

Our new AMF will register itself to the NRF, advertising what Network Functions it can offer (ie AMF service), and it’ll in turn be able to learn about what Network Functions it can consume – for example our AMF would need to know about the UDMs it can query data from.

It is one of the really cool design patterns usually seen in modern software, that 3GPP have adopted as part of the 5GC.

In Practice

Let’s go into a bit more detail and look at how it looks.

The NRF uses HTTP and JSON to communicate (anything not using ASN.1 is a winner), and looks familiar to anyone used to dealing with RESTful APIs.

Let’s take a look at how an AMF looks when registering to a NRF,

NF Register – Providing the NRF a profile for each NF

In order for the NRF to function it has to know about the presence of all the Network Functions on the network, and what they support. So when a new Network Function comes online, it’s got to introduce itself to the NRF.

It does this by providing a “Profile” containing information about the Network Functions it supports, IP Addresses, versions, etc.

Going back to our AMF example, the AMF sends a HTTP PUT request to our NRF, with a JSON payload describing the functions and capabilities of the AMF, so other Network Functions will be able to find it.

Let’s take a look at what’s in the JSON payload used for the NF Profile.

  • Each Network Function is identified by a UUID – nfInstanceId, in this example it’s value is “f2b2a934-1b06-41eb-8b8b-cb1a09f099af”
  • The nfType (Network Function type) is an AMF, and it’s IP Address is 10.0.1.7
  • The heartBeatTimer sets how often the network function (in this case AMF) sends messages to the NRF to indicate it’s still alive. This prevents a device registering to an NRF and then going offline, and the NRF not knowing.

The nfServices key contains an array of services and details of those services, in the below example the key feature is the serviceName which is namf-comm which means the Namf_Communication Service offered by the AMF.

The NRF files this info away for anyone who requests it (more on that later) and in response to this our NRF will indicate (hopefully) that it’s successfully created the entry in its internal database of Network Functions for our AMF, resulting in a HTTP 201 “Created” response back from the NRF to the AMF.

NRF StatusSubscribe – Subscribe & Notify

Simply telling the NRF about the presence of NFs is one thing, but it’s not much use if nothing is done with that data.

A Network Function can subscribe to the NRF to get updates when certain types of NFs enter/leave the network.

Subscribing is done by sending a HTTP POST with a JSON payload indicating which NFs we’re interested in.

Contents of a Subscription message to be notified of all AMFs joining the network

Whenever a Network Function registers on the NRF that related to the type that has been subscribed to, a HTTP POST is sent to each subscriber to let them know.

For example when a UDM registers to the network, our AMF gets a Notification with information about the UDM that’s just joined.

NRF Update – Updating NRF Profiles & Heartbeat

If our AMF wants to update its profile in the NRF – for example a new IP is added to our AMF, a HTTP PATCH request is sent with a JSON payload with the updated details, to the NRF.

The same mechanism is used as the Heartbeat / keepalive mechanism, to indicate the NRF is still there and working.

Summary

The NRF acts as a central repository used for discovery of neighboring network functions.

5GC for EPC Folks – Control Plane Signalling

5G SA, EPC, Mobile Networks, RFCs & Standards, , , , ,

As the standardisation for 5G-SA has been completed and the first roll outs are happening, I thought I’d cover the basic architecture of the 5G Core Network, for people with a background in EPC/SAE networks for 4G/LTE, covering the key differences, what’s the same and what’s new.

The AMF – Authentication & Mobility Function, serves much the same role as the MME in LTE/EPC/SAE networks.

Like the MME, the AMF only handles Control Plane traffic, and serves as the gatekeeper to the services on the network, connecting the RAN to the core, authenticating subscribers and starting data / PDN connections for the UEs.

While the MME connects to eNodeBs for RAN connectivity, the AMF connects to gNodeBs for RAN.

The Authentication Functions

In EPC the HSS had two functions; it was a database of all subscribers’ profile information and also the authentication centre for generating authentication vectors.

5GC splits this back into two network elements (Akin to the AuC and HLR in 2G/3G).

The UDM (Unified Data Management) provides the AMF with the subscriber profile information (allowed / barred services / networks, etc),

The AUSF (Authentication Server Function) provides the AMF with the authentication vectors for authenticating subscribers.

Like in UMTS/LTE USIMs are used to authenticate subscribers when connecting to the network, again using AKA (Authentication and Key Agreement) for mutual subscriber & network authentication.

Other authentication methods may be implemented, R16 defines 3 suporrted methods, 5G-AKA, EAP-AKA’, and EAP-TLS.

This opens the door for the 5GC to be used for non-mobile usage. There has been early talk of using the 5G architecture for fixed line connectivity as well as mobile, hence supporting a variety of authentication methods beyond classic AKA & USIMs. (For more info about Non-3GPP Access interworking look into the N3IWF)

The Mobility Functions

When a user connects to the network the AMF selects a SMF (Session Management Function) akin to a P-GW-C in EPC CUPS architecture and requests the SMF setup a connection for the UE.

This is similar to the S11 interface in EPC, however there is no S-GW used in 5GC, so would be more like if S11 were instead sent to the P-GW-C.

The SMF selects a UPF (Akin to the P-GW-C selecting a P-GW-U in EPC), which will handle this user’s traffic, as the UPF bridges external data networks (DNs) to the gNodeB serving the UE.

More info on how the UPF functions compared to it’s EPC counterparts can be found in this post.

Moving between cells / gNodeBs is handled in much the same way as done previously, with the path the UPF sends traffic to (N3 interface) updated to point to the IP of the new gNodeB.

Mobility between EPC & 5GC is covered in this post.

Connection Overview

When a UE attempts to connect to the network their signalling traffic (Using the N1 reference point between the UE and the AMF), is sent to the AMF.

an authentication challenge is issued as in previous generations.

Upon successful authentication the AMF signals the SMF to setup a session for the UE. The SMF selects a UPF to handle the user plane forwarding to the gNodeB serving the UE.

Key Differences

  • Functions handled by the MME in EPC now handled by AMF in 5GC
  • Functions of HSS now in two Network Functions – The UDM (Unified Data Management) and AUSF (Authentication Server Function)
  • Setting up data connections “flatter” (more info on the User Plane differences can be found here)
  • Non 3GPP access (Potentially used for fixed-line / non mobile networks)

See also: 5GC for EPC Folks – User Plane Traffic