User Guide 25/1553-AXB 901 33/7 Uen A

Configuration Guide for Wi-Fi Calling
Ericsson Service-Aware Policy Controller

Contents


1 Introduction

1.1 Document Purpose and Scope

Next figure, shows the main parts related to configuration and provisioning in the SAPC.

sapc_conf_prov.eps Figure 1   Configuration and Provisioning Overview

The purpose of this document is to provide guidelines and examples to configure the SAPC node for the Ericsson SIM-based Untrusted Wi-Fi Calling Solution.

This document is not intended as an exhaustive guide to configure the SAPC for every possible scenario.

The complete parameter list and details of all the SAPC configuration options are included in separate documents, refer to Managed Object Model (MOM) and Provisioning REST API for more information.

1.2 Typographic Conventions

The following typographic and document conventions are used:

Table 1   Typographic Conventions

Convention

Description

Example

Representational State Transfer (REST)

SAPC REST provisioning.

Exact REST resources, methods, attibutes, or their corresponding values.

PUT /dataplans/Silver { "dataplanName" : "Silver", "notification" : "sms" }

Managed Object Class (MOC)

or Attributes value

Exact COM model object, classes names, attributes, or their corresponding values.

SmsCenter

enableDelivery=true

NETCONF

SAPC COM configuration

<edit-config> <target> <running /> </target> <config> <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop"> <managedElementId> 1 </managedElementId> <PolicyControlFunction xmlns="urn:com:ericsson:ecim:sapcmom"> <policyControlFunctionId> 1 </policyControlFunctionId> <NotificationConfig xmlns="urn:com:ericsson: ecim:notificationconfigmom"> <notificationConfigId> 1 </notificationConfigId> <enableDelivery> true </enableDelivery> </NotificationConfig> </PolicyControlFunction> </ManagedElement> </config> </edit-config>

1.3 Other Conventions

This document refers to some configuration and provisioning data.

To clarify which detailed data is managed by COM or by the REST API, this document uses the following conventions:

  • Configuration: whenever referring to Managed Object Class (MOC).

    The detailed description of the object and attributes can be found in Managed Object Model (MOM).

    Example: set enableReauthsOnSubsChange attribute in class AppConfig.

    The tools or interfaces to manage these data in the SAPC are:

    • NETCONF interface, refer to Ericsson NETCONF Interface.

      The configuration examples show the NETCONF file contents, using the following syntax:

      <edit-config>
        ...
        <config>
        <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
        <managedElementId>1</managedElementId>
             ...
        </ManagedElement>
        </config>
      </edit-config>
  • Provisioning: mainly subscribers, subscriber groups (dataplans), services (contents), profiles, and policy-related data. The SAPC provides a REST API for them, see Provisioning REST API.

    This document uses the following terminology for them: <resource-name> URI in the provisioning REST API.

    Example: To provision subscriber groups, use the dataplan URI in the provisioning REST API.

    Provisioning examples show HTTP operations on REST resources with the following syntax:

    HTTP-Operation /resource-URI 
        {json content}

    where /resource-URI is the relative URI from the SAPC provisioning base URI detailed in Provisioning REST API.

    Example:

    PUT /dataplans/Gold   
    { "dataplanName" : "Gold",
      "subscribedContents" : [{"contentName" : "HTTP_Streaming",
                               "redirect" : false}]
    }
    Note: To ease provisioning operations, the SAPC provides an HTTPS CLI client named resty, refer to Provisioning Tools.

2 Configuration Prerequisites

Before configuring the SAPC in an operational network, assure that:

  • CBA Components are installed.

  • The SAPC product software is installed.

  • To have a detailed understanding of the function.

3 Configuration

To support Wi-Fi calling, configure the SAPC by performing the following items:

  • In the Wi-Fi calling solution, the SAPC can perform Dynamic Policy Control (refer to Configuration Guide for Dynamic Policy Control (Rx)) depending on the needs:

    • Provision services (if necessary). Typically, no additional dynamic service is provisioned for Wi-Fi calling.

    • Configure the dynamic service classification (if necessary). Typically, no additional dynamic service classification is configured for Wi-Fi calling.

    • Configure the dynamic service qualification (if necessary). Dynamic services can be qualified with QoS profile and charging profile either statically or by configuring dynamic policy conditions. Additional QoS and charging profiles can be configured for Wi-Fi calling, but typically not configured.

    • Configure the dynamic service authorization (if necessary). The SAPC can reject the dynamic service authorization owing to bill shock prevention.

    • Configure other applicable controls (if necessary).

The WLAN access type (AccessData.bearer.accessType), NON-3PP-EPS IP-CAN type (AccessData.bearer.ipCanType), and handover (AccessData.bearer.handover) policy tags can be used as dynamic conditions in the condition attribute of the rules URI in the provisioning REST API for Wi-Fi calling in previous configuration tasks.

3.1 Configure Event Triggers

To receive the RAT type and IP-CAN type from the PCEF when the handover between LTE and Wi-Fi occurs, set event trigger IP_CAN_CHANGE value. For details on how to configure event triggers, refer to Configuration Guide for Access and Charging Control (Gx).

4 Configuration Examples for Use Cases

4.1 Configure Bill Shock Prevention

To prevent bill shock, the SAPC can reject the service authorization for the Wi-Fi calling according to policies when the SAPC detects the handover from Wi-Fi to VoLTE and the subscriber is roaming.

In the following example, it is assumed to use the same dynamic service than in Multimedia Telephony over LTE.

Example 1   Configuration of Bill Shock Prevention

PUT /rules/rWifi

{
	"condition" : "not ((AccessData.subscriber.locationInfo.countryCode != 072) &&(AccessData.bearer.handover == 1))",
	"ruleName" : "rWifi"
}


PUT /policies/pWifi

{
	"policyName" : "pWifi",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "rWifi" ]
}


PUT /locators/resources/service_VoLTE/contexts/access

{
	"policies" : [ "pWifi" ]
}

This example rejects authorization for the dynamic service "service_VoLTE" in the Gx interface, when the handover from Wi-Fi to VoLTE is performed and the subscriber is in international roaming (MNC is not 072).

5 Appendix A. Policy Tags

5.1 Tags Related to Wi-Fi Calling

For ease of use, the SAPC implements the following policy tag to detect the handover between Wi-Fi and LTE accesses.

Table 2   Tags Related to Wi-Fi Calling

Tag

Return Type

Possible Values

Comments

AccessData. bearer. handover

Integer

0-2

Indicates the handover type occurring in the network:

  • 1: Handover from Wi-Fi to LTE

    The SAPC returns this value, if the value of received Event Trigger is IP_CAN_CHANGE, the value of IP-CAN type changes from Non-3GPP-EPS to 3GPP-EPS and the value of RAT type changes from WLAN to EUTRAN.

  • 2: Handover from LTE to Wi-Fi

    The SAPC returns this value, if the value of received Event Trigger is IP_CAN_CHANGE, the value of IP-CAN type changes from 3GPP-EPS to Non-3GPP-EPS and the value of RAT type changes from EUTRAN to WLAN.

  • 0: No handover

    In other cases, the SAPC returns this value.

6 Reference List