Contents

1   Introduction

1.1   Document Purpose and Scope

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

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   Revision Information

1.3   Typographic Conventions

This document uses the following typographic conventions:

1.4   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 for 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:

  1. 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>

  2. Or COM CLI, refer to Ericsson Command-Line Interface.
• 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.

  And 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:

• Configure the event trigger for IP-CAN change.
• 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.

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.

Glossary

Reference List