In the 5G Core, the AMF holds first-hand mobility information about a UE, including its current Tracking Area, reachability status, registration changes, CM state, and access type changes. When network functions such as the SMF, NEF, or UDM need this information, repeatedly querying the AMF only provides a snapshot at a particular moment and does not efficiently capture state changes. Namf_EventExposure addresses this problem by turning AMF-managed mobility information into event services that other network functions can subscribe to and receive through ongoing notifications.
Service Name: Namf_EventExposure
Core Model: Event subscription + state-change notification
Typical Consumers: SMF, NEF, UDM
Version Context: Based on relevant 3GPP Release 15.6 definitions
Service Role and Boundaries
Namf_EventExposure is an AMF service that exposes mobility-related events to other network functions. Because the AMF is responsible for access and mobility management, it directly maintains information such as UE location, registration status, and connection management state. Other network functions do not need to recreate the same state-determination logic. Instead, they can use this service to declare which events they are interested in, while the AMF determines when those events occur and sends notifications when the configured conditions are met.
Event subscription is fundamentally different from a conventional status query. A query answers the question, “What is the current state?” An event subscription answers, “When does the state change?” For example, the SMF does not need to continuously query whether a UE is reachable; it may only need to be notified when the UE changes from reachable to unreachable. The NEF may only care whether a UE enters a defined area, while the UDM may be interested in registration or reachability changes. Event exposure therefore provides an asynchronous, condition-driven way to exchange information only when it is needed.
The AMF does not broadcast all of its internal information indiscriminately. Events are exposed according to established subscription relationships. The consumer, target UE, event type, and notification URI together define the scope of a subscription. This approach reduces unnecessary signaling while allowing each network function to subscribe only to the mobility information relevant to its own service logic.
Event Types and Key Parameters
The AMF can expose events covering multiple aspects of UE mobility, registration, connectivity, and reachability. Rather than memorizing each event individually, it is easier to group them into three categories: location and area events, registration and access state events, and reachability or exception events.
Location and Area Events
One of the most direct event types is UE location reporting. A consumer can subscribe to location changes for a single UE or a group of UEs, with notifications carrying information such as the TAI and cell identifier. AOI, or Area of Interest, reporting focuses on the relationship between the UE and a predefined area, such as whether the UE has entered the area, left it, or is in an unknown state.
AOI reporting is particularly useful when an application does not require continuous precise location updates and only needs to know whether a UE is inside a defined region. For example, if the application only needs to determine whether a UE enters an area composed of TA1 and TA2, there is no need to generate continuous location notifications while the UE remains within that area. A report is only required when the UE enters or leaves the configured region.
Registration, Access and Connection States
Registration status reporting distinguishes between REGISTERED and DEREGISTERED states, while connection management reporting indicates whether the UE is in CM-IDLE or CM-CONNECTED. These two states have different meanings for network functions that need to determine whether user-plane or signaling communication can be established immediately.
The AMF can also expose changes in the UE's access network type, such as transitions between 3GPP and non-3GPP access, as well as changes to the UE's current time zone. These parameters generally do not need to be polled at a high frequency, but when they do change, they may affect policy decisions or service processing. That makes them well suited to an event subscription model.
Reachability and Exception Events
Reachability reporting indicates whether the AMF considers the UE reachable by the network. Possible results include reachable, unreachable, and REGULATORY-ONLY. REGULATORY-ONLY indicates that the UE is reachable only for regulatory prioritized services. Reachability should not be confused with connection state: a UE in CM-IDLE may still be reachable, although paging may be required before a connection can be re-established.
Exception events describe communication failures or loss of communication. Communication failure reports may include RAN or NAS connection release cause values. A loss-of-communication report can be generated when the AMF determines, for example through the expiry of a mobile reachability timer, that communication with the UE has been lost, allowing the subscriber to receive the relevant UE identifier.
In addition to events associated with an individual UE or a group of UEs, the AMF can expose statistics on the number of UEs within a specific area. In this case, the consumer is interested in the total number of UEs in the region rather than the state of a particular subscriber. This shows that Event Exposure is not limited to per-UE notifications and can also provide mobility-related statistical information.
Subscription, Update and Notification
Namf_EventExposure organizes state changes around a complete subscription lifecycle. A network function consumer first creates a subscription, and the AMF stores the subscription relationship. If the consumer later needs to change the event conditions, the subscription can be updated. When the event is no longer required, the subscription can be deleted. Actual event results are then delivered by the AMF to the configured notification address.
To create a subscription, the consumer sends a POST request for a new subscription. If the request succeeds, the AMF returns the created subscription information together with an identifier that can be referenced by subsequent operations. If the consumer needs to modify event conditions, it can use PATCH on the relevant subscription rather than deleting and recreating it. When the event is no longer required, the consumer sends DELETE to remove the subscription relationship, after which the AMF no longer sends notifications for that subscription.
Notify is the key step that delivers the actual state change. When the subscribed event condition is satisfied, the AMF sends an event notification by POST to the eventNotificationUri stored with the subscription. After the consumer processes the notification and returns a response, that notification transaction is complete. A typical sequence can be summarized as follows:
The consumer identifies the UE and event it wants to monitor;
The AMF creates and maintains the subscription context;
The AMF continues to track the relevant mobility state;
When the event condition is met, the AMF sends a notification;
The consumer processes the event and performs the required service logic;
The subscription is updated or deleted when the service requirements change.
Reporting can be configured as either one-time or continuous. A one-time report is suitable when the consumer only needs the current result or a single event occurrence. With continuous reporting, the subscription remains active and subsequent state changes that match the configured conditions can trigger additional notifications. From an engineering perspective, “which event is being subscribed to” and “how many reports are required” should therefore be treated as separate configuration considerations.
Engineering Perspective and Conclusion
From the perspective of the 5GC service-based architecture, Namf_EventExposure addresses a responsibility boundary: which network function detects a state and which network function consumes it. Because the AMF already owns mobility management information, it is more efficient for the AMF to expose that information through a standardized event mechanism than for the SMF, NEF, or UDM to repeatedly infer the same UE state through additional signaling.
This is also why a subscription model is well suited to event exposure. UE location, registration, connection state, and reachability are all state-oriented information. Most of the time, these values remain unchanged, but when a change does occur, it may immediately affect the behavior of another network function. Continuous polling would generate a large amount of signaling with little operational value, whereas subscription and notification allow information to flow only when an actual event occurs.
When analyzing Namf_EventExposure signaling in practice, four elements are particularly important: which NF created the subscription, which event was requested, which UE or area is being monitored, and where the notification is sent. By following the subscription ID together with the eventNotificationUri, it is usually possible to reconstruct the complete interaction from subscription creation and modification through to the final Notify message.
The most effective way to understand Namf_EventExposure is to build a simple model: the AMF maintains mobility state, the consumer declares its interest, the subscription establishes the relationship, and Notify delivers the result when the state changes. Once this model is clear, specific events such as location, AOI, registration, connection state, and reachability become much easier to interpret.
FAQ
What is the fundamental difference between Namf_EventExposure and directly querying the AMF?
A direct query retrieves the state at a specific moment. Event Exposure establishes an interest in advance and allows the AMF to notify the consumer when the relevant state changes. The former is suited to point-in-time queries, while the latter is better for ongoing event monitoring.
Can one consumer subscribe to events for multiple UEs?
Yes. The supported target scope depends on the event type. Some events can apply to a single UE or a group of UEs, while statistics such as the number of UEs within a specified area can apply to an arbitrary number of UEs.
Does CM-IDLE mean that the UE is unreachable?
No. CM state describes the UE's connection management state, whereas reachability describes whether the network can reach the UE. A UE in CM-IDLE may still be reachable, although communication normally requires the connection to be restored first.
Why does event notification require a separate callback URI?
Subscription creation and event occurrence do not necessarily happen at the same time. The consumer provides a notification URI when the subscription is created, allowing the AMF to send a Notify message later whenever the configured event condition is met, without keeping the original request connection open.
