N15 — AMF ⇔ PCF (Npcf_AMPolicyControl reference point)¶

Learning objectives¶

After reading this page, you will be able to:

• Explain that N15 is an SBI (Service Based Interface), fundamentally different in protocol/transport from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• Explain that the substance of N15 is the service Npcf_AMPolicyControl (TS 29.507) provided by the PCF.
• Explain the flow in which the AMF establishes an AM Policy Association to obtain access & mobility related policies (RFSP, service area restriction, mobility restriction, etc.).
• Explain the division of roles: if N7 is the SM (Session Management) side policy, N15 is the MM (Mobility Management) side policy.
• Explain that "reference point N15" and "service Npcf_AMPolicyControl" are two views of the same thing.

Prerequisites¶

The following are helpful to understand first:

• The positioning of SBA / SBI and HTTP/2 · TLS → Protocol dictionary
• The NFs at both ends of N15 → AMF / PCF
• Contrast with SM-side policy (PCC rule) → N7
• The context in which access & mobility control (mobility restriction, RFSP, etc.) comes into play → Registration
• The concept of interfaces and reference points → Interface dictionary

Why — why it is needed¶

When the AMF manages a UE's registration and mobility, it must decide "in which area this subscriber is allowed to communicate (service area restriction)," "which RAT/frequency to prioritize (RFSP)," and "how much movement to permit (mobility restriction)." However, if the AMF were to decide these on its own, it would have to be modified every time the operator's access & mobility rules change (this plan only in this region, this device prioritizes this frequency, etc.).

Therefore, a route to query PCF, the authority on operator policy, "how should this subscriber's mobility and access be handled?" is needed. This is N15. The AMF queries the PCF over N15, and the PCF returns the access & mobility policy it determined from subscriber data (originating from UDR) and operator rules. Without N15 (or without PCF integration), the AMF can only handle mobility with static defaults and cannot perform fine-grained, dynamic per-subscriber access & mobility control.

Analogy: N15 is a dedicated line by which the mobility-management reception desk (AMF) seeks judgment from the rules department (PCF). The reception desk does not decide the rules on its own; over this line it asks "what are this customer's mobility restrictions and preferred frequency?" and proceeds with registration according to the rules department's answer. If N7 is the line for the session desk (SMF), then N15 is the line for the mobility desk (AMF).

Overview¶

N15 is a reference point connecting AMF ⇔ PCF. However, N15 is an SBI (Service Based Interface), which is decisively different from N2 (NGAP/SCTP) and N4 (PFCP/UDP). An SBI is a mechanism by which NFs call each other's services via Web APIs (HTTP), using HTTP/2 + JSON (RESTful) over TLS as the common transport.

The substance of N15 is the service Npcf_AMPolicyControl (TS 29.507) provided by the PCF. The AMF calls this service to establish an AM Policy Association (a binding of the access & mobility policy) and obtains the authorized access & mobility related policies (RFSP, service area restriction, mobility restriction, UE-AMBR related, etc.).

Basic Concept — explanation for beginners¶

Let us compare N15 to an inquiry between the mobility-management reception and the rules department.

When your smartphone tries to register with the network, the mobility-managing AMF acts. Rather than deciding "in which area is this customer allowed to communicate? which frequency to prioritize? how much movement to permit?" on its own, the AMF queries the rules-department PCF (establishing the AM Policy Association). The PCF cross-references the member roster (subscriber data) with the company rules and returns the access & mobility policy (instructions such as RFSP, service area restriction, mobility restriction, etc.). Following these instructions, the AMF proceeds with the UE's registration and mobility control.

This query to the PCF is not a dedicated telephone line (a dedicated protocol like N2 or N4); it is more like throwing a request and getting a reply over an internal web system (HTTP). This is SBI (Service Based Interface) = the mechanism by which NFs converse via Web APIs (HTTP/2). Both request and response are exchanged in JSON, a format that is easy for humans to read.

In this Web API, the operation target (a resource such as the AM Policy Association) is given an "address (URI)," to which HTTP operations such as POST are thrown to create/update/delete. This manner is called RESTful.

Protocol / Transport¶

Architecture¶

This shows the context in which N15 connects AMF and PCF, pairs with the SM-side N7 (SMF⇔PCF), and the PCF retrieves subscriber policy from the UDR via Nudr.

flowchart LR
  AMF["AMF (MM)"]
  PCF["PCF"]
  SMF["SMF (SM)"]
  UDR[("UDR (policy data)")]

  AMF == "N15 (Npcf_AMPolicyControl)" ==> PCF
  SMF -. "N7 (Npcf_SMPolicyControl)" .-> PCF
  PCF -. "Nudr (policy retrieval)" .-> UDR

  classDef ctrl fill:#efe,stroke:#3a3,stroke-width:2px;
  class AMF,PCF ctrl;

How to read the diagram: The thick line (==>) N15 is the AMF⇔PCF policy query (SBI/HTTP2), handling MM (Mobility Management) side access & mobility policy. The dashed N7 is SMF⇔PCF, handling SM (Session Management) side PCC rules. The PCF retrieves subscriber policy from the UDR via Nudr and answers both queries. Note the division of roles: N15 = MM policy, N7 = SM policy.

Procedures used¶

N15 is used within the lifecycle of Registration when the AMF queries the PCF for access & mobility policy.

• AM Policy Association Establishment: During Registration, the AMF queries the PCF with Npcf_AMPolicyControl_Create and obtains the access & mobility policy (RFSP, service area restriction, mobility restriction, etc.). Based on the obtained policy, the AMF proceeds with the UE's mobility control and registration processing.
• AM Policy Association Modification: When the policy changes (an AMF-initiated update, or a notification from the PCF), the policy is updated with Update / UpdateNotify.
• AM Policy Association Termination: On UE deregistration and so on, the AM Policy Association is terminated.

This PCF integration is optional/conditional and is performed under a dynamic access & mobility policy configuration. In configurations without PCF integration, processing continues with the AMF's default policy (configuration-dependent).

The detailed flow of the procedure (message sequence, conditions, IEs, etc.) is consolidated in the description of Registration. Refer there for the details of the procedure (the details are to be confirmed).

Main Messages¶

Because N15 is an SBI, messages take the form of HTTP method + resource operation (RESTful operations, not a procedureCode like NGAP). The representative service operations are as follows.

The HTTP operation mapping is a conceptual arrangement: The "HTTP operation" in the table above is a mapping for understanding; the exact method, resource URI, and invocation direction of each operation follow the OpenAPI definition of TS 29.507. The strict method assignment is to be confirmed. For details of each message, refer to the Message dictionary.

Packet Analysis (Wireshark)¶

Because N15 is an SBI, it is observed on capture as HTTP/2 (an L4-dedicated protocol like NGAP/SCTP does not appear).

Decode highlights:

• N15 is encrypted with TLS. To see the contents (HTTP/2 headers and JSON body), a decryption key (TLS session keys, etc.) is required. Without the key, it is only visible as the encrypted payload of tls.
• If you can decrypt, you can identify the operation from the HTTP/2 headers (:method = POST, etc., the :path includes the AMPolicyControl resource path) (the exact path string is to be confirmed).
• The body is JSON (policy information such as RFSP, service area restriction, mobility restriction), stored in a human-readable structure. The concrete format of policy values is to be confirmed.
• Unlike N2's NGAP (binary, over SCTP), the point of observation for N15 is that it is Web-like (HTTP/JSON). Do not use SCTP-specific filters (sctp.port, etc.) or PFCP.

Comparison with EPC¶

• In 4G: Control related to access & mobility (location management, mobility control, RAT/frequency selection priority, etc.) was mainly realized as internal functions of the MME, and the PCRF was mainly responsible for gateway-side (SM/charging) policy (Gx, etc.). Therefore, the form of clearly externalizing MM-side policy as an independent reference point was thin (details are to be confirmed).
• In 5G: PCF oversees both SM-side (N7) and MM-side (N15) policy, resulting in a configuration that holds access & mobility policy as an independent reference point N15 (Npcf_AMPolicyControl). The ability to dynamically obtain MM-side policy over SBI is a 5G characteristic.

Holding MM-side policy as an independent reference point is a 5G characteristic. In 4G, mobility control was mostly closed within the MME; in 5G this was turned into an SBI and externalized as the N15 of AMF⇔PCF. The strict correspondence on the 4G side is to be confirmed.

3GPP Specification¶

• 3GPP TS 29.507 — Npcf_AMPolicyControl service (Access and Mobility Policy, N15). Individual clause numbers are to be confirmed
• 3GPP TS 29.500 / TS 29.501 — SBI framework (technical conventions / design principles · OpenAPI). Individual clause numbers are to be confirmed
• 3GPP TS 23.503 — Policy and Charging Control framework (including the policy model for access & mobility policy)
• 3GPP TS 23.501 §4 — System architecture and reference points (definition of N15)
• 3GPP TS 33.501 — SBI security (TLS, etc.). Individual clause numbers are to be confirmed

Note (to be confirmed): That the substance of N15 is Npcf_AMPolicyControl (TS 29.507), that the common SBI framework is the TS 29.500/29.501 family, and that reference point N15 and service Npcf are two views of the same collaboration, are general arrangements of the 3GPP architecture. The detailed clause numbers of each service operation, the exact resource URIs, and the format of concrete policy values (RFSP values, etc.) differ by Release, so they are individually to be confirmed.

Summary¶

• N15 is a reference point connecting AMF ⇔ PCF, but being an SBI (Service Based Interface) it is fundamentally different from N2 (NGAP/SCTP) and N4 (PFCP/UDP).
• The protocol is HTTP/2 + JSON (RESTful) over TLS, and its substance is the PCF service Npcf_AMPolicyControl (TS 29.507).
• The AMF establishes an AM Policy Association, obtains access & mobility related policies (RFSP, service area restriction, mobility restriction, etc.), and applies them to the UE's registration and mobility control.
• If N7 is the SM (Session Management) side policy, N15 is the MM (Mobility Management) side policy. The two form a pair, both overseen collectively by the PCF.
• Reference point N15 = service Npcf_AMPolicyControl are two views of the same AMF⇔PCF collaboration. Holding MM-side policy as an independent reference point is a 5G characteristic (the 4G-side correspondence is to be confirmed).

Next Step¶

• PCF — the other side of N15. The hub of access & mobility / SM policy
• AMF — the NF that uses N15 to obtain access & mobility policy and applies it to registration and mobility control
• N7 — the paired reference point that handles SM-side policy (PCC rules)
• Registration — the procedure for AM Policy Association establishment (details)
• Interface dictionary — check reference points such as N7, N5, N8