Policy Control for Wi-Fi Calling
Ericsson Service-Aware Policy Controller
Contents
This document describes the policy control provided by the SAPC for
the Ericsson SIM-based Untrusted Wi-Fi Calling Solution.
Ericsson SIM-based Untrusted Wi-Fi Calling Solution allows subscribers
to make Wi-Fi calls using their SIM-based devices, when the subscribers
attach to either a public or residential Wi-Fi access network.
This solution supports the following two functions:
Wi-Fi calling for SIM-based devices
This function enables SIM-based devices entering the packet core
network through an untrusted Wi-Fi network to use IMS voice services.
The Wi-Fi calling feature is natively integrated in the device, which
avoids the drawbacks of existing over-the-top applications and provides
the subscribers with a carrier-grade performing service. The subscribers
only need to turn on the Wi-Fi calling feature rather than any other
specific settings.
Seamless handover between VoLTE and Wi-Fi
This function enables voice session continuity without interruption
for a UE attached to LTE moving to Wi-Fi and the other way around.
The PCEF acts as anchor point for the session providing key support
for seamless mobility. When the UE decides to handover, authentication
and authorization are triggered for IMS APN on the destination access.
Once connectivity is established over the destination access, session
and bearers over the source access are released. Finally, the SIP
Registration procedure for the new access is triggered.
The solution has the following advantages:
Wi-Fi calling at public or residential areas achieves
better data coverage.
Wi-Fi calling uses the same phone number that the phone
uses for cellular calls.
Wi-Fi calling can be seamlessly handed off to the cellular
network when the UE leaves Wi-Fi range, and the other way around.
Wi-Fi calling can be made to any cell phone or landline
phone, regardless of which network the other end is using.
Wi-Fi calling capability works overseas to avoid cellular
roaming charges.
Voice quality of Wi-Fi calling is the same as on standard
cellular calls.
Figure 1 shows the Ericsson Network Integrated
Wi-Fi (ENIW) architecture that enables the seamless integration of
untrusted Wi-Fi access networks in 3GPP networks. This architecture
allows subscribers to securely access the packet core network through
an untrusted Wi-Fi network.
Figure 1 ENIW Architecture
The Wi-Fi calling can be made or received only when the untrusted
Wi-Fi access network, the IMS network, and S2b capable EPG are deployed.
Figure 2 shows a high-level flow for
the establishment of the Wi-Fi calling.
Figure 2 Overview of Wi-Fi Calling
1. When the UE wants to establish the Wi-Fi calling,
the UE attaches to the Wi-Fi access and requests the IPsec tunnel
by sending the IKE messages.
2. The IPWorks AAA server then authenticates the UE
using the EAP-AKA method.
3. The ePDG triggers the establishment of the S2b GTP
tunnel to the PCEF.
4. The PCEF allocates an UE IP address and initiates
the Gx session establishment. Upon reception of the IMS APN, IP-CAN
type “Non-3GPP-EPS” and RAT type “WLAN”, the SAPC identifies
that the IP-CAN session is for the Wi-Fi calling service. The SAPC then
installs PCC rules to the PCEF with the authorized QoS that applies
to the default EPS bearer for the Wi-Fi calling service.
5. Once the IPsec tunnel and the S2b GTP tunnel are
established, the UE initiates the SIP Registration procedure to the
IMS network.
6. Once the SIP Registration procedure is completed,
the UE initiates the Wi-Fi calling by sending the INVITE request to
the IMS network and subsequent application layer signaling.
7. The P-CSCF establishes an Rx session to the SAPC indicating
in an AAR message that the new AF session relates to Wi-Fi service
and requesting authorization and reservation of resources for the
Wi-Fi service.
8. The SAPC performs session binding and ensures
that the AF session relates to the Wi-Fi calling service. The SAPC then
performs dynamic service classification, authorization, and qualification,
and provides the PCC rules with the authorized QoS and charging for
the Wi-Fi calling service.
The SAPC allows the operator to use the application identifier
and media information received from the P-CSCF in the dynamic service
classification. Example of typical service classification patterns
for Wi-Fi calling is as follows:
Table 1 Example of Dynamic Service Classification Patterns for Wi-Fi
Calling
|
AF Application Identifier
|
Media Type
|
Service-Id
|
|
urn:urn-7:3gpp-service.ims.icsi.mmtel
|
audio
|
Wi-Fi calling
|
At IP-CAN session reauthorization and events received from AF,
the SAPC performs dynamic service authorization, service
QoS control, service charging control, and service qualification for
the Wi-Fi calling service. After that the SAPC downloads
PCC rules with the authorized QoS data and charging data.
In addition, the SAPC supports the following uses cases
for Wi-Fi calling:
Bill shock is the negative experience that subscribers have if
they are faced with unexpected high charges. Bill shock can happen
when the subscribers use a mobile device while roaming without understanding
the voice or data roaming charges involved.
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. The SAPC,
for this purpose, must subscribe to the IP-CAN change event trigger.
The SAPC can provide policy control for the Wi-Fi calling
in the following network deployments:
In the bearer plane (PCEFs) side:
Ericsson EPG, through Ericsson Gx+ Rel9 onwards.
Non-Ericsson PCEF, through standard Gx Rel9 onwards.
In the application plane (AF) side:
Ericsson SBG, through Rx Rel9 onwards.
Non-Ericsson P-CSCF, through Rx Rel9 onwards.
The following traffic case occurs when the UE is setting up the
Wi-Fi calling. Before this traffic case, the UE has registered in
the IMS network.
Figure 3 Wi-Fi Calling Setup
Wi-Fi Calling Setup
2. The P-CSCF receives a SIP INVITE message indicating
the SIP call setup.
3. The SAPC receives an AAR message from the
P-CSCF including the AF-Application-Identifier AVP to indicate that the new AF session relates to the Wi-Fi calling
service.
4. The SAPC performs the session binding to
associate the IP flows in the AF session information with the existing
IP-CAN session for the Wi-Fi calling service. For more information
about session binding, refer to
Dynamic Policy Control (Rx).
5. The SAPC performs dynamic service classification
and authorization for the Wi-Fi calling service.
7. The SAPC performs dynamic service qualification
for the Wi-Fi calling service.
8. The SAPC performs a reauthorization of the IP-CAN session.
9. The SAPC generates the dynamic PCC rules
and sends a Gx RAR message to the PCEF to enforce the PCC rules including
the QoS information.
10. The SAPC receives a Gx RAA message from
the PCEF as a response.
11. The PCEF accepts the installation of PCC rules and
binds all PCC rules on the S2b default bearer.
12. The P-CSCF receives a gating or update message.
13. The SAPC receives an AAR message from the
P-CSCF indicating the AF session modification.
14. The SAPC performs dynamic service classification
and authorization for the Wi-Fi calling service.
16. The SAPC performs dynamic service qualification
for the Wi-Fi calling service.
17. The SAPC performs a reauthorization of
the IP-CAN session.
18. The SAPC updates dynamic PCC rules including
the QoS information and sends a Gx RAR message to the PCEF to update
PCC rules including the QoS information.
19. The SAPC receives a Gx RAA message from
the PCEF as a response.
Wi-Fi Calling Termination
21. The P-CSCF receives a SIP BYE message indicating
the SIP call termination.
22. The SAPC receives an STR message from the
P-CSCF to remove the AF session for the Wi-Fi calling service.
23. The SAPC identifies the session to be removed.
25. The SAPC identifies the affected dynamic
PCC rules to be removed.
26. The SAPC performs a reauthorization of
the IP-CAN session.
27. The SAPC sends a Gx RAR message to the
PCEF to remove the dynamic PCC rules for the Wi-Fi calling service.
28. The SAPC receives a Gx RAA message as a
response.
The following flows show examples of handover between VoLTE and
Wi-Fi. IP-CAN type change notification functionality is also included
in these flows. For more information about IP-CAN type change notification,
refer to
Dynamic Policy Control (Rx).
The following traffic case occurs when the UE loses the Wi-Fi signal
and determines to handover current sessions from Wi-Fi to LTE.
In this example, the AF has also successfully subscribed to indication
of bearer release.
Figure 4 Handover from Wi-Fi to VoLTE
The UE moves from Wi-Fi access to LTE:
1. The PCEF allocates the same UE IP address for the
LTE access as used for Wi-Fi access.
2. The SAPC receives a Gx CCR-U from the PCEF
indicating the IP-CAN session modification. The main information that
the PCEF includes:
Event-Trigger AVP: This indicates
the event IP-CAN_CHANGE (7).
IP-CAN-Type AVP: This indicates
the IP-CAN type "3GPP-EPS" (5).
RAT-Type AVP: This indicates
the RAT type "EUTRAN" (1004).
| Note: |
When the SAPC subscribes the IP-CAN_CHANGE (7) event
trigger and the IP-CAN type is changed, the SAPC receives
the IP-CAN-Type AVP and the RAT-Type AVP regardless of whether the SAPC subscribes
the RAT_CHANGE (2) event trigger.
|
4-15. When the SAPC detects the handover from
Wi-Fi to VoLTE and the subscriber is roaming, the SAPC can
reject the service authorization for the Wi-Fi calling according to
policies:
5. The SAPC performs service authorization
and, as the result of policies evaluation, it rejects the authorization
of dynamic service.
6. The SAPC sends a Gx CCA-U message to the PCEF including
dynamic rules for the Wi-Fi calling service to be removed.
If not all the service data flows within the AF session
are affected:
8. The SAPC sends an RAR message to the AF with
the following main AVPs:
The Specific-Action AVP with
IP-CAN_CHANGE and INDICATION_OF_RELEASE_OF_BEARER values.
The IP-CAN-Type AVP indicating
the type "3GPP-EPS".
The RAT-Type AVP indicating
the type "EUTRAN".
9. The AF returns an RAA successfully.
If all the service data flows within the AF session are
affected:
11. The SAPC sends an ASR command to AF,
including the Abort-Cause AVP set to BEARER_RELEASED.
12. The AF answers with an ASA message.
13. The AF sends an STR command to request the termination
of the AF session.
15. The SAPC removes the AF session.
16-19. If the subscriber is not roaming, the following
steps are executed:
17. The SAPC sends a Gx CCA-U message to the PCEF to
enforce the dynamic PCC rules including the QoS for the Wi-Fi calling
service.
18. The SAPC sends an RAR message to
the AF to notify the IP-CAN type change. The message includes the
following main AVPs:
The Specific-Action AVP with
IP-CAN_CHANGE.
The IP-CAN-Type AVP indicating
the type "3GPP-EPS".
The RAT-Type AVP indicating
the type "EUTRAN".
19. The AF answers back with an RAA including the Result-Code AVP with value SUCCESS.
20. The PCEF installs the dynamic PCC rules on default
EPS bearer before the dedicated EPS bearer is established. In the PCEF,
the payload is switched to the default EPS bearer.
21. The PCEF performs the bearer binding.
22. The PCEF evaluates whether it is possible to use
one of existing bearers to fulfill the QoS requirements of the dynamic
PCC rules. If it is not possible, the PCEF initiates the establishment
of a dedicated EPS bearer and installs dynamic PCC rules on dedicated
EPS bearers. In the PCEF, the payload is switched to the dedicated
EPS bearer.
23. Once the IPsec and GTP tunnels are established,
the UE initiates the SIP Registration procedure to the IMS network
to inform of the new access type for the ongoing session.
The following traffic case occurs when the UE detects the presence
of an untrusted Wi-Fi network and determines to hand over current
sessions from LTE to Wi-Fi.
Figure 5 Handover from VoLTE to Wi-Fi
The UE moves from LTE to Wi-Fi access:
1. The PCEF allocates the same UE IP address for the
Wi-Fi access as used for LTE access.
2. The SAPC receives a Gx CCR-U message from
the PCEF indicating the IP-CAN session modification. The main information
that the PCEF includes:
Event-Trigger AVP: This indicates
the event IP-CAN_CHANGE (7).
IP-CAN-Type AVP: This indicates
the IP-CAN type "Non-3GPP-EPS" (6).
RAT-Type AVP: This indicates
the RAT type "WLAN" (0).
AN-Trusted AVP: This indicates
the access network "UNTRUSTED" (1).
| Note: |
When the SAPC subscribes the IP-CAN_CHANGE (7) event
trigger and the IP-CAN type is changed, the SAPC receives
the IP-CAN-Type AVP, the RAT-Type AVP and the AN-Trusted AVP (if applicable)
regardless of whether the SAPC subscribes the RAT_CHANGE
(2) event trigger.
|
3. The SAPC reauthorizes the IP-CAN session
evaluating controls configured for the PCEF, such as service access
control, bearer QoS control, service QoS control, and service charging
control.
4. The SAPC sends a Gx CCA-U message to the PCEF to
enforce the dynamic PCC rules including the information previously
computed.
5. The SAPC sends an RAR message to
the AF including the following main AVPs:
Specific-Action AVP with
value IP-CAN_CHANGE.
IP-CAN-Type AVP: This indicates
the IP-CAN type "Non-3GPP-EPS".
RAT-Type AVP: This indicates
the RAT type "WLAN".
AN-Trusted AVP: This indicates
the access network "UNTRUSTED".
6. The AF answers back with RAA including the Result-Code AVP with value SUCCESS.
7. The PCEF installs the dynamic PCC rules on the S2b
default bearer.
8. Once the IPsec and GTP tunnels are established, the
UE initiates the SIP Registration procedure to the IMS network to
inform of the new access type for the ongoing session.
9. In the PCEF, the payload is switched to the S2b
default bearer.