5G NPLI Call Flows

As stated, there are no changes to existing call flows when using 5G NPLI. The difference is in the construction of the NPLI because the SBC receives 5G-specific values in Rx AVPs, parsing and storing them appropriately so it can construct the 5G location string (NPLI). This section provides some call flow examples to display operation when 5G specific values are received in the AVPs.

For all of these call flows, the following configuration is common:

• Set hold-invite-calls-for-loc-info to a non-zero value and start-hold-timer-event to AAA. This causes the SBC to start the hold timer after receiving the AAA and wait for RAR from PCF/PCRF.
• Configured the location-optimization-on-aar feature.
• Configured the access-network-info-report in the specific-action-subscription.

5G PANI in MO with Calling Endpoint Trusted

For this call flow, the calling UE is registered, trusted and you have enabled add-ue-location-in-pani.

The procedure depicted in the image below includes:

1. The UAC sends an INVITE with an offer SDP to the SBC with the 5G PANI Header (UPLI).
2. The SBC sends an AAR (INITIAL_REQUEST) to the PCF/PCRF, requesting location Information, and waits for the RAR.
3. The PCF/PCRF sends 5G supported location information in the 3GPP-User-Location-Info AVP of the RAR.
4. The SBC constructs the NPLI from RAR and sends the INVITE out with a 5G PANI header (UPLI + NPLI).
5. When it receives a 200 OK with answer SDP, the SBC sends an AAR (UPDATE_REQUEST) to the PCF/PCRF requesting location information again. However, it does not wait for the RAR.
6. The SBC uses the cached NPLI (generated during initial INVITE) and adds it as the PANI header in the 200 OK.
7. Because the UAC (access) is trusted, the SBC also adds the 5G NPLI towards the UAC.

5G PANI in MT Call

For this call flow, the called UE is registered, trusted, and the caller is on the core side. The procedure depicted in the image below includes:

1. The SBC receives offer an SDP from the core and sends the AAR (INITIAL_REQUEST) to the PCF/PCRF requesting location Information.
2. When the SBC receives the AAA, it starts the hold timer and waits for the RAR.
3. The PCF/PCRF sends 5G specific location information in the 3GPP-User-Location-Info AVP within the RAR.
4. The SBC constructs the NPLI from the RAR and sends the INVITE (towards access) with a 5G PANI header (NPLI).

   Note:

   The access UE is trusted.
5. When the SBC receives the 200 OK with the answer SDP, it sends an AAR (UPDATE_REQUEST) to the PCF/PCRF.
6. The SBC uses the cached NPLI, generated during the initial INVITE, and adds it as the PANI header in the 200 OK towards the Core for that session.

Registered Emergency Calls

SBC behavior (including the configuration parameters) for adding PANI header for Emergency calls shall remain the same as in previous release. Key detail to keep in mind includes:

• You can configure the hold-emergency-calls-for-loc-info to enable and set the timing (in seconds) for the buffering of emergency INVITES, while waiting for location information from the PCRF.
• If the PCRF fails to provide NPLI within that time period, the P-CSCF (SBC) forwards the emergency INVITE to the core network with a PANI header populated from the default location string value (if configured).
• If location information is unavailable, the P-CSCF forwards the INVITE without a PANI header.

For this call flow, the UAC is registered, but not trusted. In addition, you have enabled allow-pani-for-trusted-only. The procedure depicted in the image below includes:

1. The SBC receives Emergency INVITE from UAC (Registered UE) and it sends AAR (INITIAL_REQUEST) to PCF/PCRF requesting location Information.
2. When the The SBC receives the AAA, it starts the hold timer and waits for the RAR.
3. The PCF/PCRF sends 5G specific location information in the 3GPP-User-Location-Info AVP within the RAR.
4. The SBC constructs NPLI from the RAR.
5. The SBC sends the INVITE out with the 5G PANI header (NPLI).
6. When the SBC receives the 200 OK with the answer SDP, it sends an AAR (UPDATE_REQUEST) to the PCF/PCRF.
7. The SBC forwards the 200 OK to UE with no NPLI header because it is untrusted.