UDM stands for Unified Data Management. As the name implies it is a function/service that manges Data. What kind of data it manages ?  It is user data (i.e, data of subscribers). In 4G, HSS played this role.. but in 5G, the HSS role split into two different services : UDM and AUSF. AUSF is mainly for  Authentication Process and UDM is managing the user data for all other process. As shown in the illustration below, UDM is interfaced with many other services : AUSF, AMF, SMF, SMSF. It means when AUSF, AMF, SMF, SMSF needs subscriber data, it request it to UDM and UDM provide the data to the services that requested.

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

This note covers the following.

• What UDM actually is, and what it is not
• Where the HSS actually went
• Inter play between UDM and Other Components
  • N8 : UDM and AMF
  • N10 : UDM and SMF
  • N13 : UDM and AUSF
  • N21 : UDM and SMSF
  • N52 : UDM and NEF
  • N35 : UDM and UDR
  • Other Nudm consumers in the reference model
• The Nudm services : what each consumer is actually asking for
• UDM Functionality
• What a registration actually looks like
• Reference :

What UDM actually is, and what it is not

The name is slightly misleading, and it is worth clearing up before anything else. UDM manages subscriber data, but in the standard deployment model it does not hold any.

UDM is a front end. When the AMF asks it for subscription data, the UDM does not look in its own database. It fetches the data from another function called the UDR, applies whatever logic is needed, and hands back the answer. The data belongs to the UDR. The UDM only knows how to answer questions about it.

Two things inside the UDM box are worth naming, because the abbreviation list above mentions them without saying where they live.

• ARPF : the Authentication credential Repository and Processing Function. It holds the long term subscriber key and runs the key derivation. It is not a separate network function. It sits inside the UDM, and the reason it has its own name is that it is the part that must never be exposed.
• SIDF : the Subscription Identifier De-concealing Function. When a UE sends a concealed identity, a SUCI, this is what turns it back into the real SUPI. It also sits inside the UDM, and it is the only place in the network allowed to do that.

Now the reason this split matters in practice. If a UDM instance stores nothing, then any instance can serve any subscriber. You can put a load balancer in front of a pool of them and scale out. That is the whole point of separating the front end from the repository. It is also why the 5G core can be deployed the way cloud software is deployed.

NOTE : A UDM can also be deployed stateful, keeping data locally rather than in a UDR. That is allowed. But the architecture is designed around the split, and the interesting properties come from it.

Where the HSS actually went

The introduction says the HSS role split into UDM and AUSF. That is the right idea, and it is the half you meet first. The full answer has one more piece in it.

The 4G HSS did three jobs at once. It stored subscriber data, it held the authentication credentials, and it ran the authentication itself. In 5G those three jobs are separated.

• UDM takes the subscriber data management role, and it carries the credential handling with it as ARPF and SIDF.
• AUSF takes the authentication procedure, which is why the AMF talks to AUSF and not to UDM when a UE registers.
• UDR takes the storage. This is the piece that is easy to miss, because it is not in the picture at the top of this page at all.

The HSS itself has not disappeared. An operator running 4G and 5G together will usually still have one, and it interworks with the UDM. That is the NU1 reference point shown in the second diagram, and TS 23.632 covers how the two stay consistent.

The three boxes in the diagram also have different interfaces. AUSF obtains authentication data from UDM, while UDM reads persistent records from UDR when deployed separately. Keeping those paths apart explains why an authentication exchange does not make AUSF the subscriber database.

Inter play between UDM and Other Components

Even though the illustrations shown above indicates the interplay beween UDM and other components, I think following diagram shows better with focus on UDM. The main question is which consumer asks for which subscriber information, not merely which functions share a line.

It is worth being clear about what the difference between the two pictures actually is. It is not a difference of architecture. It is a difference of notation, and the two figures are drawing the same network.

The first picture is the reference point view. Every line carries a number, and that number names the pair of functions at its two ends. N8 is the line between AMF and UDM. N10 is the line between SMF and UDM. This is the older way of drawing a core network, inherited from 4G, and it is still how most architecture diagrams are drawn.

The second picture is the service based view. On the UDM side there is only one interface, called Nudm, and everything that wants something from the UDM connects to it. The lines fanning in are not separate interfaces at all. They are separate consumers of the same one.

That also explains why the first picture has four lines touching UDM and the second has eleven. The first is the overall architecture figure, which only draws the main core functions. The second is the UDM's own reference model, drawn from the UDM's doorstep. So it shows everything that ever calls Nudm, including the parts that never appear on an architecture poster.

Then there is the naming, which is the part that makes people think the two figures disagree. 3GPP names the same interaction twice. A reference point name identifies the pair. A service based name identifies the provider. So 'N8' and 'the AMF consuming Nudm' are two ways of saying one thing. Once that lands, the second figure stops looking like a contradiction of the first.

The labels in the second figure are not a tidy sequence either, and there is a reason for that. They were minted in different specifications, at different times.

• N8, N10, N13, N21 and N52 : the core architecture in TS 23.501. These are AMF, SMF, AUSF, SMSF and NEF.
• NL6 : location services, from TS 23.273. It carries privacy subscription and routing queries from the home GMLC.
• NU1 : HSS interworking, from TS 23.632. This is the one that keeps a 4G HSS and a 5G UDM consistent with each other.
• N68 : the bootstrapping server function of the Generic Bootstrapping Architecture.
• Nyy : the 5G Direct Discovery Name Management Function, from the ProSe work in TS 23.304.

One detail in that figure is easy to walk straight past. DCCF and NWDAF have no reference point label at all. They arrived after 3GPP had settled on service based naming, so no reference point name was ever minted for them. Reading down the labels is close to reading the order in which things were bolted onto the UDM over successive releases.

< 29.503-Figure 4.1-1: Reference model UDM >

Here goes a short descriptions for each of the interactions between UDM and other network components depicted on the diagram.

• DCCF (Data Collection Configuration Function): Interacts with UDM to configure how user data is collected for various services.

• NWDAF (Network Data Analytics Function): Exchanges analytics data with UDM to optimize network performance and user experience.

• AMF (Access and Mobility Management Function): Coordinates with UDM for authentication and to maintain user profiles for mobility management.

• SMF (Session Management Function): Works with UDM to manage sessions and user data related to connectivity and service access.

• SMSF (Short Message Service Function): Relies on UDM for storing and retrieving SMS-related user data.

• AUSF (Authentication Server Function): Verifies user credentials with UDM during the authentication process.

• NEF (Network Exposure Function): Utilizes UDM to control user data exposure to external network functions.

• GMLC (Gateway Mobile Location Centre): Accesses location-related user data from UDM for services requiring location information.

• HSS (Home Subscriber Server): Legacy function from 4G that interacts with UDM for subscriber data management in the transition to 5G.

• GBA's BSF (Generic Bootstrapping Architecture's Bootstrapping Server Function): Uses UDM for secure user data exchange in bootstrapping procedures.

• 5G DDNMF (5G Direct Discovery Name Management Function): Not a proprietary function. It is the ProSe function defined in TS 23.304 that allocates and resolves the names used in direct discovery, and it asks UDM whether a subscriber is authorised for that service.

The diagram identifies the consumers, but it does not show the requests that pass between them. The sequences below use representative successful exchanges. Each example shows selected fields with synthetic values, not a complete HTTP capture or a claim that every call occurs during one registration.

N8 : UDM and AMF

The AMF registers itself as the serving node and reads access-and-mobility subscription data through Nudm services. A registration record and a subscription read answer different questions: who currently serves the UE, and what that UE may use.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N8 : UDM and AMF. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

PUT /nudm-uecm/v1/imsi-001010123456789/registrations/amf-3gpp-access
{"amfInstanceId":"3f19d3ba-a7d4-4b17-96a7-05b43d914817",
 "deregCallbackUri":"https://amf.example.net/dereg",
 "guami":{"plmnId":{"mcc":"001","mnc":"01"},"amfId":"000001"},
 "ratType":"NR"}

201 Created
Location: /nudm-uecm/v1/imsi-001010123456789/registrations/amf-3gpp-access

GET /nudm-sdm/v2/imsi-001010123456789/am-data

200 OK
{"nssai":{"defaultSingleNssais":[{"sst":1,"sd":"000001"}]}}

N10 : UDM and SMF

The SMF reads session-management subscription data through Nudm_SDM before it accepts a requested PDU session. It can then subscribe to changes, so a later DNN or slice update reaches the serving SMF without repeated polling.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N10 : UDM and SMF. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

GET /nudm-sdm/v2/imsi-001010123456789/sm-data
  single-nssai = {"sst":1,"sd":"000001"}
  dnn = internet

200 OK
[{"singleNssai":{"sst":1,"sd":"000001"},
  "dnnConfigurations":{"internet":{
    "pduSessionTypes":{"defaultSessionType":"IPV4"},
    "sscModes":{"defaultSscMode":"SSC_MODE_1"}}}}]

POST /nudm-sdm/v2/imsi-001010123456789/sdm-subscriptions
{"nfInstanceId":"4a4d174e-d204-48fb-b775-b53b1ddf8dbd",
 "callbackReference":"https://smf.example.net/sdm-notify",
 "monitoredResourceUris":["https://udm.example.net/nudm-sdm/v2/imsi-001010123456789/sm-data"]}

201 Created
Location: /nudm-sdm/v2/imsi-001010123456789/sdm-subscriptions/42

N13 : UDM and AUSF

The AUSF requests authentication data from UDM and later reports the authentication outcome. UDM handles the subscriber identity and authentication-vector generation, while AUSF runs the network-side authentication exchange with AMF.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N13 : UDM and AUSF. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

POST /nudm-ueau/v1/suci-0-001-01-0000-0-0-0000001234/security-information/generate-auth-data
{"servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org",
 "ausfInstanceId":"58d2a1b0-3c42-4be2-8c9a-b30cdb004499"}

200 OK (selected fields)
{"authType":"5G_AKA","supi":"imsi-001010123456789",
 "authenticationVector":{"avType":"5G_HE_AKA",
 "rand":"0123456789abcdef0123456789abcdef",
 "xresStar":"0123456789abcdef0123456789abcdef",
 "autn":"112233445566778899aabbccddeeff00",
 "kausf":"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"}}

POST /nudm-ueau/v1/imsi-001010123456789/auth-events
{"nfInstanceId":"58d2a1b0-3c42-4be2-8c9a-b30cdb004499",
 "success":true,"timeStamp":"2026-10-11T14:00:00Z",
 "authType":"5G_AKA",
 "servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org"}

201 Created
Location: /nudm-ueau/v1/imsi-001010123456789/auth-events/77
{"nfInstanceId":"58d2a1b0-3c42-4be2-8c9a-b30cdb004499",
 "success":true,"timeStamp":"2026-10-11T14:00:00Z",
 "authType":"5G_AKA",
 "servingNetworkName":"5G:mnc001.mcc001.3gppnetwork.org"}

N21 : UDM and SMSF

The SMSF registers itself for a UE and retrieves the subscriber's SMS management settings from UDM. The registration identifies the serving SMSF; the separate data request determines whether mobile-originated and mobile-terminated SMS service is subscribed.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N21 : UDM and SMSF. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

PUT /nudm-uecm/v1/imsi-001010123456789/registrations/smsf-3gpp-access
{"smsfInstanceId":"fa487b5e-7991-4504-945f-531003eb61ae",
 "plmnId":{"mcc":"001","mnc":"01"}}

201 Created
Location: /nudm-uecm/v1/imsi-001010123456789/registrations/smsf-3gpp-access

GET /nudm-sdm/v2/imsi-001010123456789/sms-mng-data

200 OK
{"moSmsSubscribed":true,"mtSmsSubscribed":true,
 "moSmsBarringAll":false,"mtSmsBarringAll":false}

N52 : UDM and NEF

The NEF can provision permitted subscriber parameters through Nudm_PP on behalf of an authorized external application. The UDM validates and applies the provisioning request; this is not a direct API from the application to UDM.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N52 : UDM and NEF. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

GET /nudm-pp/v1/imsi-001010123456789/pp-data

200 OK
{"expectedUeBehaviourParameters":{"afInstanceId":"af-plant-01",
 "referenceId":1,"periodicTime":3600}}

PATCH /nudm-pp/v1/imsi-001010123456789/pp-data
Content-Type: application/merge-patch+json
{"expectedUeBehaviourParameters":{"afInstanceId":"af-plant-01",
 "referenceId":1,"periodicTime":1800}}

204 No Content
Response body: none

N35 : UDM and UDR

UDM may fetch persistent subscriber data from UDR through Nudr_DataRepository. This is the storage-side exchange behind a Nudm response, not another service request from AMF or SMF. The two reads below show mobility and session data separately.

The sequence below pairs each request with its response. It separates operations that serve different parts of the same subscriber context.

N35 : UDM and UDR. Representative successful exchanges; conditional branches are omitted.

Each numbered row matches one arrow above. The examples show selected message contents; omitted fields and payloads are not implied to be absent on the wire.

GET /nudr-dr/v2/subscription-data/imsi-001010123456789/00101/provisioned-data/am-data

200 OK
{"nssai":{"defaultSingleNssais":[{"sst":1,"sd":"000001"}]}}

GET /nudr-dr/v2/subscription-data/imsi-001010123456789/00101/provisioned-data/sm-data
  single-nssai = {"sst":1,"sd":"000001"}
  dnn = internet

200 OK
[{"singleNssai":{"sst":1,"sd":"000001"},
  "dnnConfigurations":{"internet":{
    "pduSessionTypes":{"defaultSessionType":"IPV4"},
    "sscModes":{"defaultSscMode":"SSC_MODE_1"}}}}]

Other Nudm consumers in the reference model

The UDM reference model also shows specialist consumers. Their requests depend on analytics, location, interworking, or ProSe procedures rather than the common registration flow. The table keeps these links visible without implying that they all use one generic Nudm operation.

• A reference point identifies the NF pair : N8, N10, N13, N21, and N52 name the consumers beside UDM in the architecture view.
• A Nudm service identifies the operation : UECM, SDM, UEAU, and PP carry different requests over the service-based interface.
• N35 is the storage side : UDM can read UDR data before it answers a consumer, but UDR is not the endpoint of that consumer's Nudm call.

The Nudm services : what each consumer is actually asking for

The diagram above answers the question of who talks to the UDM. It does not answer what they ask for. All of those arrows carry the same service based interface, Nudm, and that interface is made of a handful of named services.

This is the more useful way to hold the UDM in your head. The consumers differ, but the set of things any of them can ask for is short.

Read the last column and the second diagram on this page becomes much easier to interpret. AUSF has one arrow because it only ever wants one thing. AMF has one arrow but uses three services, because registration needs all of them. NEF has one arrow and uses four, because it is the door through which outside parties reach subscriber data.

NOTE : Later releases add further services beyond the eight above. The set here is the one you will meet in almost every trace.

UDM Functionality

Based on 23.501-6.2.7, the functionality of UDM is descrbed as follows. The list combines identity handling, subscriber authorization, and serving-function registration. These are control-plane jobs; UDM does not carry a UE's user packets.

• Generation of 3GPP AKA Authentication Credentials.
• User Identification Handling (e.g. storage and management of SUPI for each subscriber in the 5G system).
• Support of de-concealment of privacy-protected subscription identifier (SUCI).
• Access authorization based on subscription data (e.g. roaming restrictions).
• UE's Serving NF Registration Management (e.g. storing serving AMF for UE, storing serving SMF for UE's PDU Session).
• Support to service/session continuity e.g. by keeping SMF/DNN assignment of ongoing sessions.
• MT-SMS delivery support.
• Lawful Intercept Functionality (especially in outbound roaming case where UDM is the only point of contact for LI).
• Subscription management.
• SMS management.
• 5G-VN group management handling.
• Support of external parameter provisioning (Expected UE Behaviour parameters or Network Configuration parameters).

NOTE 1: The interaction between UDM and HSS, when they are deployed as separate network functions, is defined in TS 23.632  and TS 29.563 or it is implementation specific.

NOTE 2: The UDM is located in the HPLMN of the subscribers it serves, and access the information of the UDR located in the same PLMN

What a registration actually looks like

Services and reference points stay abstract until you see them in order. The sequence below is a plain UE registration, reduced to the parts that touch the UDM.

Four things in that sequence are worth pointing at.

• The AMF never talks to the UDR : it does not know the UDR exists. Every read passes through a UDM service. That is what makes the front end useful, because the storage can be replaced without any consumer noticing.
• Authentication does not go AMF to UDM : it goes AMF to AUSF to UDM. This is the HSS split showing up in a live procedure. The AUSF runs the procedure and the UDM supplies the material.
• Registration and data retrieval are different services : Nudm_UECM_Registration tells the UDM which AMF now serves this subscriber. Nudm_SDM_Get asks for the subscription data. They are separate calls because they answer separate questions.
• The last call is the interesting one : Nudm_SDM_Subscribe means the AMF does not have to poll. If an operator changes a subscription in the UDR later that evening, the UDM notifies the AMF. The change then reaches a UE that has been registered for hours.

That last point is the practical difference from the 4G way of working. Subscription data in 5G is not something the serving node fetches once and forgets. It is something it subscribes to.

Reference :

• 3GPP TS 29.503 - Nudm UEAU, UECM, SDM, and PP service operations.
• 3GPP TS 29.504 - Nudr DataRepository service on N35.
• 3GPP TS 29.505 - UDR subscription-data resource definitions.
• What Is Unified Data Management (UDM)?
• Unified Data Management