In this note, I will describe about the protocols used for N8 interface/reference point. As shown below, N8 is the interface between AMF and UDM. It is mainly used when AMF needs some user(subscriber) data from UDM and plays important role especially during the registration process.

It is worth being a little more precise about what the AMF is asking for. N8 carries two quite different conversations, and the page is organised around that split.

One of them answers where the UE is. When an AMF takes a UE on, it tells the UDM that it is now the serving AMF for that subscriber. That is what UEContextManagement is for. Without it the network would have no way of finding the UE later, for a page, an incoming call or an SMS.

The other answers what the UE is allowed to do. The AMF fetches the subscription data, which is where the slice list, the allowed DNNs, the bit rate limits and the QoS defaults come from. That is what SubscriberDataManagement is for.

Keeping those two apart makes the rest of the page much easier to read. One is about location and state. The other is about entitlement. They happen to travel over the same interface, and they are otherwise unrelated. Both sit alongside the rest of the family in the Nudm service list.

N8 is the red line in the figure below, running between AMF and UDM. Notice that it is the only path the AMF has to the subscriber data. Everything the AMF knows about a subscriber arrives over this one interface.

Followings are the name of each network component.

AMF     Access and Mobility Management Function ==> Equivalent to MME in 4G

AUSF    Authentication Server Function

DN       Data Network

NEF      Network Exposure Function

NRF      Network Repository Function

NSSF    Network Slice Selection Function

PCF      Policy Control Function ==> Equivalent to PCRF in 5G

(R)AN   (Radio) Access Network

SMF     Session Management Function

UDM     Unified Data Management ==> Equivalent to HSS in 4G

UPF      User Plane Function ==> Equivalent to PGW in 4G

SMSF   SMS Function

SEAF    SEcurity Anchor Function ==> part of AMF function

ARPF    Authentication credential Repository and Processing Function

SIDF    Subscription Identifier De-concealing Function

Followings are the topics to be covered in this note

• Nudm_UEContextManagement Service
• Registration
• GET
• Update
• Nudm_SubscriberDataManagement Service
• GET
• Info/PUT/POST
• Examples
• Example 1 : n8 during registration

Nudm_UEContextManagement Service

This service exists to answer one question, and the network asks it constantly. Which AMF is currently serving this subscriber ?

The UDM is the only place that knows. I kept expecting this service to do more than that when I first read it, and it really does not. A UE moves between AMFs, and something has to keep track, otherwise a terminating call would have nowhere to go. So when an AMF starts serving a UE it registers itself here, and when it stops it deregisters. The three operations below are that, plus a way to read the current answer back.

Registration

This is the AMF telling the UDM that it is now the serving AMF. It is a write, not a request. Notice while reading the table that the resource being written identifies both the subscriber and the access type. A 3GPP registration and a non-3GPP registration are two separate things at the UDM.

Following table is based on 29.503 - 5.3.2.2

GET

The read side of the same information. Another network function that needs to reach a UE can ask the UDM which AMF is currently serving it, and this is the operation that answers.

Following table is based on 29.503 - 5.3.2.5

Update

A partial change to a registration that already exists, rather than a fresh one. This is what gets used when something about the serving arrangement changes but the serving AMF itself does not.

Following table is based on 29.503 - 5.3.2.6

Nudm_SubscriberDataManagement Service

The other half of N8, and a completely different question. Not where the UE is, but what it is entitled to.

This is the service that hands over the subscription data itself. Slices, allowed DNNs, aggregate bit rates, default QoS, whether MICO is permitted, and so on. Everything a network decides about a UE that is not a consequence of where it happens to be standing comes from here.

One design point is worth noticing before the tables. The AMF does not only fetch this data. It can also subscribe to it, so that a change made in the UDR later reaches a UE that has been registered for hours. Subscription data in 5G is something a serving node follows, not something it copies once.

GET

The fetch itself. What I would look for in the table is that the data comes in named datasets. A consumer asks only for the ones it wants. The example at the end of this page shows an AMF asking for three of them in a single call.

Following table is based on 29.503 - 5.2.2.2

Info/PUT/POST

These are the operations that go the other way, where the consumer tells the UDM something rather than asking. They are much less common in a trace than the GET above, which is why they are easy to overlook.

Following table is based on 29.503 - 5.2.2.6

Examples

Everything above is the specification view, and I always find it easier to trust once I have seen it happen. What follows is the same thing on the wire, taken from a running network. That is where the abstractions turn into HTTP requests with real values in them.

Example 1 : n8 during registration

Following is an example log captured with Amarisoft Callbox.

The screenshot below is the interesting part of a registration, with the N8 exchanges numbered. Read it top to bottom and the shape of the procedure is visible at a glance. Security is completed first. Then two N8 calls happen. Only after both of them come back does the NAS Registration Accept go out.

That ordering is the point. The AMF cannot accept a registration until it knows what the subscriber is entitled to, so the Registration Accept is gated on the N8 exchange finishing.

The numbered steps decode as follows.

Three details in the request bodies are worth pointing at, because they are easy to scroll past.

• The registration URL carries the access type : the path ends in registrations/amf-3gpp-access. There is a parallel resource for non-3GPP access. This is the per access registration state, made visible as a URL, and it is the same idea described on the N1 page.
• The AMF supplies a callback URL : look for deregCallbackUri in the PUT body. The AMF is telling the UDM where to reach it if this registration is ever superseded. When the subscriber turns up on another AMF, that is the address the UDM uses to tell this one to let go.
• The datasets come back named : the 200 response is split into amData, smData and smfSelData, matching the three names in the query. Inside amData you can read the actual policy for this subscriber, including the aggregate bit rates, the default slice and the list of allowed DNNs.

The AMF checks the handset against the equipment register. The PEI in the query string is the IMEI.

Message: 127.0.1.100:5557 GET http://127.0.1.100:5557/n5g-eir-eic/v1/equipment-status?pei=8690570563562913

Data:
Stream id: 1
HEADERS:
  :method: GET
  :path:   /n5g-eir-eic/v1/equipment-status?pei=8690570563562913
  :scheme: http
  :authority: 127.0.1.100:5557
  accept: application/json
  accept: application/problem+json

The register has never heard of this handset. Nothing is blocked and registration carries straight on.

Message: 127.0.1.100:5557 Status: 404

Data:
Stream id: 1
HEADERS:
  :status: 404
  content-type: application/problem+json
DATA:
  {"cause": "ERROR_EQUIPMENT_UNKNOWN"}

The AMF records itself as the serving AMF for this subscriber. This is the UEContextManagement half of N8.

Message: 127.0.1.100:5556 PUT http://127.0.1.100:5556/nudm-uecm/v1/imsi-001010123456789/registrations/amf-3gpp-access

Data:
Stream id: 3
HEADERS:
  :method: PUT
  :path:   /nudm-uecm/v1/imsi-001010123456789/registrations/amf-3gpp-access
  :scheme: http
  :authority: 127.0.1.100:5556
  accept: application/json
  accept: application/problem+json
  content-type: application/json
DATA:
{
  "amfInstanceId": "96fc86dc-9bf4-489e-acb0-53a672cac636",
  "imsVoPs": "HOMOGENEOUS_SUPPORT",
  "deregCallbackUri": "http://127.0.1.100:6666/nudm-uecm/v1/imsi-001010123456789/pei-8690570563562913/dereg-notify",
  "initialRegistrationInd": true,
  "guami": {"plmnId": {"mcc": "001", "mnc": "01"}, "amfId": "800101"},
  "ratType": "NR"
}

No Content, and rightly so. The AMF was recording a fact rather than asking a question.

Message: 127.0.1.100:5556 Status: 204

Data:
Stream id: 3
HEADERS:
  :status: 204

Now the SubscriberDataManagement half. Three datasets are asked for in a single call, named in the query string.

Message: 127.0.1.100:5556 GET http://127.0.1.100:5556/nudm-sdm/v2/imsi-001010123456789?dataset-names=AM,SM,SMF_SEL

Data:
Stream id: 5
HEADERS:
  :method: GET
  :path:   /nudm-sdm/v2/imsi-001010123456789?dataset-names=AM,SM,SMF_SEL
  :scheme: http
  :authority: 127.0.1.100:5556
  accept: application/json
  accept: application/problem+json

The subscriber profile itself. The three dataset names asked for in [5] come back as the three top level keys, shown in blue below. Highlighted lines are the ones decoded in the table that follows. Where four DNN blocks repeat the same setting the highlight appears once, so the places they actually differ are the places that light up again.

Message: 127.0.1.100:5556 Status: 200

Data:
Stream id: 5
HEADERS:
  :status: 200
  content-type: application/json
DATA:
{
  "amData": {
    "subscribedUeAmbr": {"uplink": "1000000 Kbps", "downlink": "3000000 Kbps"},
    "nssai": {"defaultSingleNssais": [{"sst": 1}], "singleNssais": [{"sst": 1}]},
    "micoAllowed": true,
    "subscribedDnnList": ["default", "internet", "ims", "sos"],
    "ptwParametersList": [{"operationMode": "WB_N1", "ptwValue": "0011"}, {"operationMode": "NB_N1", "ptwValue": "0011"}]
  },
  "smData": [
    {
      "singleNssai": {"sst": 1},
      "dnnConfigurations": {
        "default": {
          "pduSessionTypes": {"defaultSessionType": "IPV4", "allowedSessionTypes": ["IPV4"]},
          "sscModes": {"defaultSscMode": "SSC_MODE_1", "allowedSscModes": ["SSC_MODE_1"]},
          "iwkEpsInd": true,
          "5gQosProfile": {"5qi": 9, "arp": {"priorityLevel": 15, "preemptCap": "NOT_PREEMPT", "preemptVuln": "NOT_PREEMPTABLE"}},
          "sessionAmbr": {"uplink": "1000000 Kbps", "downlink": "3000000 Kbps"}
        },
        "internet": {
          "pduSessionTypes": {"defaultSessionType": "IPV4", "allowedSessionTypes": ["IPV4"]},
          "sscModes": {"defaultSscMode": "SSC_MODE_1", "allowedSscModes": ["SSC_MODE_1"]},
          "iwkEpsInd": true,
          "5gQosProfile": {"5qi": 9, "arp": {"priorityLevel": 15, "preemptCap": "NOT_PREEMPT", "preemptVuln": "NOT_PREEMPTABLE"}},
          "sessionAmbr": {"uplink": "1000000 Kbps", "downlink": "3000000 Kbps"}
        },
        "ims": {
          "pduSessionTypes": {"defaultSessionType": "IPV4V6", "allowedSessionTypes": ["IPV4", "IPV6", "IPV4V6"]},
          "sscModes": {"defaultSscMode": "SSC_MODE_1", "allowedSscModes": ["SSC_MODE_1"]},
          "iwkEpsInd": true,
          "5gQosProfile": {"5qi": 5, "arp": {"priorityLevel": 15, "preemptCap": "NOT_PREEMPT", "preemptVuln": "NOT_PREEMPTABLE"}},
          "sessionAmbr": {"uplink": "1000000 Kbps", "downlink": "3000000 Kbps"}
        },
        "sos": {
          "pduSessionTypes": {"defaultSessionType": "IPV4V6", "allowedSessionTypes": ["IPV4", "IPV6", "IPV4V6"]},
          "sscModes": {"defaultSscMode": "SSC_MODE_1", "allowedSscModes": ["SSC_MODE_1"]},
          "iwkEpsInd": true,
          "5gQosProfile": {"5qi": 5, "arp": {"priorityLevel": 15, "preemptCap": "NOT_PREEMPT", "preemptVuln": "NOT_PREEMPTABLE"}},
          "sessionAmbr": {"uplink": "1000000 Kbps", "downlink": "3000000 Kbps"}
        }
      }
    }
  ],
  "smfSelData": {
    "subscribedSnssaiInfos": {
      "1": {
        "dnnInfos": [
          {
            "dnn": "default",
            "defaultDnnIndicator": true,
            "lboRoamingAllowed": false,
            "iwkEpsInd": false,
            "dnnBarred": false
          },
          {
            "dnn": "internet",
            "defaultDnnIndicator": false,
            "lboRoamingAllowed": false,
            "iwkEpsInd": false,
            "dnnBarred": false
          },
          {
            "dnn": "ims",
            "defaultDnnIndicator": false,
            "lboRoamingAllowed": false,
            "iwkEpsInd": false,
            "dnnBarred": false
          },
          {
            "dnn": "sos",
            "defaultDnnIndicator": false,
            "lboRoamingAllowed": false,
            "iwkEpsInd": false,
            "dnnBarred": false
          }
        ]
      }
    }
  }
}

That last block is the whole subscriber profile, and it repays reading slowly. Here is what the fields actually decide.

One oddity in this particular capture is worth a note, in case you go looking for it. The field iwkEpsInd appears in both smData and smfSelData, and here the two disagree. They are read by different consumers. The SM copy tells the SMF whether a session on that DNN supports EPS interworking. The SMF_SEL copy tells the AMF whether it must pick a combined SMF and PGW-C. In a real deployment you would expect them to agree, and in this lab configuration they simply do not.

And only now. Follow the highlighted lines back into [6] and you can see the subscription turning into something the UE is actually told.

Message: Registration accept

Data:                          ........
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header        = 0x2 (Integrity protected and ciphered)
Auth code              = 0xc93c7d52
Sequence number        = 0x02
Protocol discriminator = 0x7e (5GS Mobility Management)
Security header        = 0x0 (Plain 5GS NAS message, not security protected)
Message type           = 0x42 (Registration accept)
5GS registration result = 0x09 (Emergency registered=0, NSSAA to be performed=0, SMS allowed=1, 3GPP access)
5G-GUTI:
  5G-GUTI
    MCC = 001
    MNC = 01
    AMF Region ID = 128
    AMF Set ID    = 4
    AMF Pointer   = 1
    5G-TMSI       = 0x32c5098b
TAI list:
  Length = 7
  Data   = 00 00 f1 10 00 00 64
Allowed NSSAI:
  S-NSSAI
    Length of S-NSSAI contents = 1 (SST)
    SST = 0x01
5GS network feature support:
  0x03 (MPSI=0, IWK N26=0, EMF=not supported, EMC=not supported, IMS-VoPS-N3GPP=1, IMS-VoPS-3GPP=1)
  0x00 (5G-UP CIoT=0, 5G-IPHC-CP CIoT=0, N3 data=0, 5G-CP CIoT=0,
        RestrictEC=both CE mode A and CE mode B are not restricted, MCSI=0, EMCN3=0)
T3512 value:
  Value = 30
  Unit  = 5 (1 minute)
Emergency number list:
  Length = 8
  Data   = 03 1f 19 f1 03 1f 11 f2