Multimedia Priority Service for VoLTE Access
The Oracle Communications Session Border Controller (SBC) supports Multimedia-priority services (MPS) to prioritize communications by emergency personnel within VoLTE networks. Specifically, the SBC supports emergency service authorization and resource allocation for an MPS call. You enable support for MPS by enabling mps-volte in the sip-config. You configure this support in conjunction with your net-management-control and rph-profile configurations.
MPS is designed by 3GPP as a component of National Security/Emergency Preparedness (NS/EP) in IMS networks. During an emergency, Multimedia-priority services (MPS) enables authorized emergency personnel to coordinate their efforts by applying priority to their communications.
MPS calls can differ from, for example, a 911 call in that the destination does not necessarily specify that it requires high priority. Instead, the information used to authorize priority call treatment is distributed via reg-event subscriptions to the P-CSCF. The SBC, acting as P-CSCF, authorizes the priority for the call and informs the PCRF about the call over the Rx interface. Having authorized priority and informed the PCRF, the SBC then handles the call via its Network Management Controls (NMC) function. NMC filters traffic to identify priority (and other) flows. For MPS, NMC offers a means directing the filtered traffic through to egress appropriately for its priority, as well as a fallback mechanism for applying priority to emergency calls.
Authorization and Resource Management
An SBC can support MPS priority calls when authorized via the name-space and priority values. These are specified by the resource value (r-value) parameter in a SIP method's Resource Priority Header (RPH). Applicable SIP methods, including INVITEs, are presented in RFC 4412. The SBC supports the following name-spaces:
- Emergency Telecommunications Services (ETS)
- Wireless Priority Service (WPS)
Supported priority values range from 0 to 4.
MPS operation requires that an administrator has assigned applicable user profiles for priority service at the HSS. Those users register their UEs via the P-CSCF. After successful registration, either the P-CSCF, and in some cases the UE, subscribes to registration events with the S-CSCF. The S-CSCF immediately sends a NOTIFY that specifies the priority available to the UE. The P-CSCF stores this information so it can perform priority authorization for these users and support RPH header processing for all applicable methods. The P-CSCF learns of priority changes, if any, via the subscription.
When this UE sends an INVITE that includes RPH, the SBC authorizes the call based on RPH match. This match is based on a single or multiple priority levels allowed by the HSS. Subsequently, the SBC informs the PCRF of the priority call over the Rx interface and the call proceeds.
General rules on RPH insertion include:
- For INVITEs from registered UEs by
public identities for whom the HSS allows priority:
- If there is no RPH, the SBC inserts the RPH it learns from the subscription.
- If there is no match and the call is an emergency, the SBC inserts the RPH it learns from the subscription.
- If there is no match and the call is not an emergency, the SBC inserts the RPH it learns from the subscription.
- For emergency or other unregistered
call, the HSS does not have information needed for authorization. In these
cases, the SBC falls back to its configured NS/EP
configuration and uses its own RPH configuration to proceed with the call:
- If there was an RPH header, the SBC overwrites it with the first RPH in the rph-profile.
- If there was no RPH header, the SBC inserts it with the first RPH in the rph-profile.
- If there was no RPH header or RPH in the reg-event, refer to the conditions described in the section on Matching by NMC and by RPH.
This MPS call flow depicts registration, AAR and INVITE, resulting in an authorized RPH.
Diameter Processes
When the SBC handles an authorized RPH: containing an appropriate namespace and priority value in SIP Invite, it includes the following AVPs in an AAR towards the PCRF:
- MPS-Identifier AVP (AVP code 528, type OctetString, Rx Interface)
- Reservation-Priority AVP (AVP code 458, type Enumerated, Rx Interface)
- DRMP AVP (AVP code 301, type Enumerated, S6A Interface)
Important behaviors with respect to the AAR include:
- Generation of this AAR is based on reserve-incomplete and other configurations within the applicable ext-policy-server configuration and the AAR optimization configuration.
- The DRMP AVP, which indicates relative priority of the diameter message, contains the same value as the Reservation-Priority AVP, as defined by TS 29.214.
- The SBC includes these AVPs in the first AAR message, which initiates the Rx session for that subscriber and does not include them in subsequent AARs for the same session.
RPH Management
Important RPH header insertion conditions include:
- If an EP is authorized to use multiple namespaces, the SBC bases priority treatment on the first matched r-value in the RPH header of the ingress SIP INVITE.
- If there are multiple r-values for the same namespace, but different priorities are sent by the HSS and the RPH of the ingress SIP INVITE, the SBC sends the highest priority for that namespace that matches the first r-value received in the RPH header of the ingress SIP INVITE.
- The SBC provides MPS priority service for PS-CS handoff calls like any other. If subscribed for priority service at the HSS, the call gets priority service.
- If the SBC sends a call to an untrusted realm, it removes the RPH.
- If the SBC receives an INVITE from an untrusted realm, it removes the RPH.
The SBC performs RPH validity checks on SIP INVITEs during MPS processing. These are the same as those used for the existing GETS/NSEP feature. The SBC rejects Invalid SIP INVITE with a 400 - bad response message along with a specific reason header. Reasons include:
- The RPH header contains an r-value that is not supported. (reason header-"Invalid RPH - Invalid r-value")
- A WPS call without an ETS r-value (reason header-"Invalid RPH - No ETS R-value")
- The SBC found two r-values of the same namespace (reason header- "Invalid RPH - Namespace repeated")
The table below presents scenarios and whether they result in authorizing priority.
| Scenario (MPS feature enabled) | Send AAR? | RPH R-Value | Reg-event R-value | MPS-Identifier | Reservation-Priority | DRMP | Authorize Priority? |
|---|---|---|---|---|---|---|---|
| R-value in SIP Invite matches reg-event. | YES | WPS.3 | WPS.3 | WPS | 3 | 3 | Yes |
| R-value in SIP Invite partially matches reg-event. | YES | WPS or
ETS.1 |
WPS.2 | WPS | 2 | 2 | Yes |
| R-value in SIP Invite does not match reg-event. | YES | ETS.0 | WPS.2 | WPS | 2 | 2 | yes |
| R-Value in SIP invite, no r-value via reg-event.
ETS call detected using NSEP. |
YES
(r-value in CFG) |
ETS.2 | none | Use CFG name-space | Use CFG priority value | Use CFG priority value | No |
| No RPH header in SIP invite.
R-value received from HSS. |
YES | none | WPS.2 | WPS | 2 | 2 | Yes |
| No RPH header in SIP invite.
No R-value received from HSS. ETS call detection using NSEP |
YES
(r-value in CFG) |
None | none | Use CFG name-space | Use CFG priority value | Use CFG priority value | No |
| No RPH header in SIP Invite or via reg-event and no ETS call detection using NSEP | NO | None | none | NA | NA | NA | No |
Dependence on NSEP Configuration
Full MPS support utilizes the NSEP configurations listed below:
- National Security/Emergency Preparedness (NS/EP) (rph-feature enabled under sip-config)
- Network Management Control (NMC) configuration on the ingress realm (net-management-control)
- The insert-arp-header under sip-config, when enabled. This ensures the SBC includes the Accept-Resource-Priority header (ARPH) in responses.
You must ensure that the following configuration options are disabled to allow unregistered priority calls:
- sip-interface, options -reject-unreg-priority-calls
- sip-interface, options -disallow-priority-calls
Interaction with NSEP Configuration
Enabling mps-volte extends upon NSEP/NMC behavior by including MPS call authorization procedures and preventing the execution of the default NS/EP behavior. When you enable the MPS for VoLTE and the NSEP feature, they interact as follows:
- The SBC defaults to using the r-values received from HSS to determine priority. It uses the NSEP defined rph-profile only when priority information is not provided by HSS.
- If the SBC receives an unregistered emergency call and is configured to
accept it, priority treatment based on existing NSEP feature using related
configuration.
- If there are no r-values available from any source for a call, the SBC does not authorize priority and uses NSEP procedures to detect an ETS call.
- In case of congestion, SBC NSEP call treatment mechanisms ensure adequate resources for priority calls. Both the nsep-user-sessions-rate and the nsep-load-limit option in the sip-config establish the priority for RPH and other emergency calls, by reserving bandwidth and CPU cycles. The recommendation is to ensure that this traffic has more than 50% of bandwidth and CPU available to it.
- If the SBC receives an unregistered emergency call and the SBC configuration allows it to process further, the SBC decides whether to allow the call based on the NSEP feature's configuration.
- The SBC first attempts to derive values for the MPS-Identifier and Reservation-Priority AVP's from priority information received from the HSS. If an endpoint's subscription information does not reflect priority information and you have enabled the rph-feature, then these AVP's have values derived based on Network Management Controls, if the NSEP feature is enabled.
Note:
As you configure, you must be aware when your MPS configuration is overriding your GETS/NSEP configuration. The system does notify you of such conditions.MPS Reporting
Execute the show mps-stats command to display the priority call statistics. Running the command without argument displays all MPS calls. Specifying an r-value displays statistics on sessions that use that r-value.
ORACLE# show mps-stats
------ Lifetime -----
Current Total PerMax
Incoming Calls 0 0 0
ORACLE# show mps-stats ets.2
-- Period -- -------- Lifetime --------
Active High Total Total PerMax High
Inbound Sessions 0 0 0 0 0 0
Outbound Sessions 0 0 0 0 0 0
InbSessions Rej 0 0 0 0 0 0
OutbSessions Rej 0 0 0 0 0 0
ORACLE# show registration sipd by-user sip:user0@acme.com detailed
Registration Cache (Detailed View) Wed Mar 21 2018 18:35:41
User: sip:user0@acme.com
Registered at: 2018-03-21-18:34:34 Surrogate User: false
Emergency Registration? No
R-value: ETS.2 WPS.1
...
MPSIdentifier AVP (AVP 528)
The MPS-Identifier AVP is of type OctectString and indicates that an Application Function (AF, eg P-CSCF) session relates to an MPS session.
When the SBC receives an authorized Resource-Priority header containing an appropriate namespace and priority value in SIP Invite, and recognizes the need for priority treatment, the SBC will include the MPSIdentifier AVP in the AAR command towards the PCRF.
Reservation-Priority AVP (468)
The Reservation-Type AVP is of type Enumerates and specifies the priority associated with the reservation. The ETSI defines the protocol values in TS 183 026-V3.1.1, with a default of 0 being the lowest and the highest being 15. The SBC maps a subset of these AVP values for use in MPS.
For MPS, IMS defines priority values using the default of 0 as the lowest priority and a range from 0 to 7. RFC 4412 further redefines these values with the level of priorities in reverse order. The SBC operates by mapping ETSI to IMS values with a default of 4 and the highest priority as 0, as shown below.
- The
SBC implementation
defines the diameter priorities as shown below, with the applicable strings
recorded in logs:
- DIAM_PRIORITY_DEFAULT (0)—This is the lowest level, and indicates no priority.
- DIAM_PRIORITY_ONE
- DIAM_PRIORITY_TWO
- DIAM_PRIORITY_THREE
- DIAM_PRIORITY_FOUR
- DIAM_PRIORITY_FIVE
- DIAM_PRIORITY_SIX
- DIAM_PRIORITY_SEVEN—This is the highest priority, indicating an emergency.
- The
SBC maps priorities in
compliance with RFC 4412, for use with the HSS as follows:
- HSS priority of 0 — value of 7 in AVP—Highest priority
- HSS priority of 1 — value of 6 in AVP
- HSS priority of 2 — value of 5 in AVP
- HSS priority of 3 — value of 4 in AVP
- HSS priority of 4 — value of 3 in AVP—Lowest priority
When the SBC recognizes the need for priority treatment by receiving an authorized Resource-Priority header containing an appropriate namespace and priority value in SIP Invite, and , In these cases, the SBC includes the Reservation-Priority AVP in the AAR command towards the PCRF.
DRMP AVP (301)
The Diameter Routing Message Priority (DRMP) AVP in Diameter messages is of type Enumerated and specifies the relative priority of the Diameter message on a scale of 0 to 15 where priority value zero is highest and 15 is the lowest priority.
When the SBC handles an authorized Resource-Priority header containing an appropriate namespace and priority value in SIP Invite, it includes the DRMP AVPs in an AAR towards the PCRF to specify its own priority.