WiFi OffLoad CheckList

If you had previous experience with following up how IMS implementation has evolved, you would have learned how important to prepare a detailed check list before you try anything for any new technology. As far as I remember, it took around two years for everybody (IMS stack developer, test engineer, equipment vendor) to stabilize their part of implementation and aquire a certain level of troubleshooting technology. As far as I am concerned, I think I saw the first ePDG demo around two years ago (as of Jun 2015) and have seen so many issues.. now it seems that ePDG implmentation seems to be pretty stable/reliable at least with a certain UEs, but still there seems to be long way to go for most of other UEs as of now (as of Jun 2015). I hope this check list would relieve some of frustration you would experience.

The items follow the order in which the UE uses them. The UE first needs a local IP address on the WLAN, then the ePDG address, then an IPsec tunnel with an inner IP address, and finally a P-CSCF for IMS. If one item is wrong, every later step fails, so check them from the top. Each item below also points to the 3GPP clause that defines the expected behaviour.

1. What is the IP type for the overal data path ?

The first thing you have to check or determine before you do any testing, you have to know which IP version will be used at each component on data path. Theoreticall, there may be following possible combinations. As far as I experienced, most of UE used < Case 3 >, but definitely you may see other requirements. The reason you have to determine this at the first step is that you may not see any log you can capture for troubleshooting.

The diagram below draws four combinations side by side. Each column shows the UE, the AP, the ePDG and the P-GW from bottom to top. The yellow bar is the IPsec tunnel between the UE and the ePDG, and the red line is the user packet that travels inside it and continues from the ePDG to the P-GW.

Four combinations of IPv4 and IPv6 for UE, AP, ePDG tunnel and P-GW packet

Case 1 : IPv4 everywhere. The UE and the AP use IPv4, the tunnel is IPv4, and the packet to the P-GW is IPv4.
Case 2 : IPv6 everywhere, the IPv6 version of Case 1.
Case 3 : the AP and the tunnel use IPv4, while the packet inside the tunnel is IPv6. So an IPv6 IMS packet travels in an IPv4 tunnel over an IPv4 WLAN.
Case 4 : the reverse of Case 3. The AP and the tunnel use IPv6, and the packet inside is IPv4.

The key point is that there are two independent IP layers. The outer layer is the local IP address that the UE gets from the WLAN. The UE uses it for the IPsec tunnel on SWu, and TS 24.302 says the UE selects an ePDG address with the same IP version as this local address. The inner layer is the address that the P-GW allocates for the PDN connection. The UE asks for it with an INTERNAL_IP4_ADDRESS attribute, an INTERNAL_IP6_ADDRESS attribute or both in the IKEv2 CFG_REQUEST, and the ePDG returns it in CFG_REPLY.

This also explains the missing logs. A sniffer on the WLAN side sees only the outer layer, and there the user data is encrypted ESP between the UE and the ePDG. The inner IPv6 or IPv4 packets are visible only after decryption, on the UE or at the ePDG and P-GW side. So you need to know which layer uses which version before you set any capture filter.

Outer and inner IP versions are chosen separately : the WLAN decides the outer one, and the APN and the CFG_REQUEST decide the inner one.
The ePDG address must match the outer version : an IPv4-only WLAN needs an IPv4 ePDG address from DNS.
Capture at the right layer : on the WLAN you see ESP, and the IMS traffic appears only inside the tunnel.

2. Is there any specific USIM requirement ?

Same as in IMS case, many UE (Network Operator) requires a specific USIM requirement (Specific Parameters should be set). In most case, UE would not even initiate IKE process (ePDG attach process) if you miss any of the USIM requirement.

Two groups of USIM content matter here. The first group is the credential itself. The UE authenticates to the 3GPP AAA Server with EAP-AKA inside IKEv2, and EAP-AKA runs on the USIM application, so a test SIM must carry keys that match the test equipment or the HSS. The UE also builds its identity from the IMSI. For EAP-AKA, TS 23.003 defines the root NAI as 0<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org, and the UE sends it in the IDi payload.

The second group is the ePDG configuration. TS 24.302 lets the home operator store the ePDG configuration information on the USIM, in the EFePDGId and EFePDGSelection files of TS 31.102. If these files point to an ePDG that your test network does not have, the UE tries the wrong address and never reaches your ePDG. Operator-specific files and settings can come on top of these, and they differ from one operator to another.

EAP-AKA needs a matching USIM : the keys on the SIM and in the AAA or HSS must match, or the IKE_AUTH exchange fails.
The NAI comes from the IMSI : check the MCC and MNC in the realm, because the AAA Server routes on it.
EFePDGId can override your setup : a configured ePDG identifier on the USIM takes precedence over the DNS default of the UE.

3. How UE get the IP address for its WiFi connectivity ?

When your UE gets connected to WiFi access point for the ePDG, UE will get its IPs allocated as shown in the following example. The question is how UE get this IPs allocated ?

UE IP address screen with IPv6 link-local, IPv6 global and IPv4 addresses

fe80::c2bd:d1ff:fea8:dedb : the IPv6 link-local address. Every IPv6 interface has one, and it is not routable.
2001::c2bd:d1ff:fea8:dedb : a global IPv6 address with the same interface ID. The ff:fe in the middle shows that the interface ID was built from the MAC address.
2001::740c:8cc8:1a49:b021 : a second global address in the same prefix with a different interface ID, most likely a temporary privacy address.
192.168.0.1 : the IPv4 address. It is the same address that the DHCP server offers in the capture on the Data Path Setup page.

Basically this is similar to how your PC gets IP address to get access to the public internet. It would be done by Static IP allocation in which you set these IPs manually somewhere in UE or UE get these IPs by dynamic allocation mechanism (i,e, DHCP for IPv4 address and Router Solicitation/Router Advertisement for IPv6).

I am pretty sure that most of the device support both capability, but the thing you have to check is how the specific DUT you are using is configured for these IPs. If it is set by the static IP, you have to doublecheck the IP you set statically matches the requirement by network operator or test equipment setting. If it is set by Dynamic method, you have to make it sure that the DUT's MAC address is properly registered to DHCP server so that the DHCP server does not reject the IP allocation request from the DUT.

All of these are local addresses in the sense of TS 24.302. None of them is the address that IMS uses. So when the UE shows both IPv4 and IPv6 addresses like this, look at which version the UE picks for the ePDG address. That choice fixes the outer IP version of item 1.

4. How UE figure out ePDG IP address - ePDG Discovery ?

As in CSCF Discovery in IMS case, there can be several different ways for a UE to figure out the IP address of ePDG. In many devices at relatively early state of ePDG implementation, I saw these IP was just hardcoded internally (the worst case is that the IP is hardcoded and that hardcoded information is not provided to testing people) or a special GUI is provided in which user can hardcode the IP manually.

In smarter way (probably in live network), UE may ask for the IP via DNS everytime it try ePDG access. (Now I see some test device is using this mechanism even at testing phase).

The standard way is in TS 23.402 clause 4.5.4 and TS 24.302 clause 7.2.1. The home operator can configure an ePDG identifier, an FQDN or an IP address, through H-ANDSF, the USIM or implementation specific means. If nothing is configured, the UE builds the Operator Identifier FQDN epdg.epc.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org from the HPLMN ID and resolves it with DNS. The UE then picks an ePDG address with the same IP version as its local IP address. If an ePDG does not answer IKE_SA_INIT, the UE repeats the selection without that ePDG.

Configuration beats construction : a configured ePDG identifier is used before the UE builds its own FQDN.
Your DNS must answer the right name : the test DNS server has to resolve the exact FQDN that the UE sends, with a record of the right IP version.

5. How UE can figure out CSCF address ?

If the UE performed the attach process to LTE network first, it can figure out CSCF address as described in LTE CSCF Discovery mechanism. But if the UE access to ePDG with purpose of IMS service, how UE can figure out the CSCF address. In most of the device at early phase of ePDG implementation, they hardcode it in ePDG stack itself or they allow user to manually set it with GUI on UE setting. But in UE with more mature ePDG implementation, they tend to get CSCF address via IP allocation during ePDG attach process. (Refer to IP Allocation by ePDG page for the details).

TS 24.302 makes this part of the tunnel setup. In the IKE_AUTH request, the UE can put a P_CSCF_IP6_ADDRESS attribute, a P_CSCF_IP4_ADDRESS attribute or both in the CFG_REQUEST. The ePDG can then return zero or more P-CSCF addresses in the CFG_REPLY, as specified in IETF RFC 7651. The UE can ask for DNS server addresses in the same way, with INTERNAL_IP4_DNS or INTERNAL_IP6_DNS.

Two checks follow from this. First, look for the P-CSCF attribute in the UE's CFG_REQUEST, because the ePDG answers only what the UE asks for. Second, check that the network side has a P-CSCF address for that APN and that the ePDG returns it in CFG_REPLY. Also note that zero addresses is a valid answer, and the UE then needs another way to find the P-CSCF.

No request, no P-CSCF : the P-CSCF attribute in CFG_REQUEST is optional, so a UE without it has to know the P-CSCF in another way.
The address version matters : an IPv6 IMS PDN connection needs P_CSCF_IP6_ADDRESS, even when the tunnel runs over IPv4 as in Case 3.

6. What are other UE settings to trigger access to ePDG ?

Probably this would be the trickiest part since the answer to this question would be completely different depending on the requirement of each service provider. Make it sure that you have all the details UE side condition to trigger ePDG attach before you try any testing. Otherwise, you will waste time on random trial and error or hacking process to figure out those information that are necessary but not given to you. Followings are only a few examples of factors and there would be many other factors as well.

WiFi Access Point Signal Strength
Availability of Cellular Network
Preference Setting between WiFi and Celluar networ
WiFi Service Setting (e.g, WiFi only or Voice/Video call over WiFi)

These factors fall into three groups, and each group has a place in the specifications. Signal strength is a radio condition. The RAN rules of Release 12 and the WLAN Selection Policy of ANDSF both use such thresholds. The preference between WiFi and cellular is operator policy, which ANDSF carries as ISMP or ISRP rules. The service setting is a user preference in the UE, and the standards leave it to the UE implementation. TS 24.302 clause 6.10 also defines whether ANDSF rules or RAN rules control WLAN selection and traffic routing for a given UE.

Ask which rule set is active : TS 24.302 gives control of WLAN selection and traffic routing either to ANDSF rules or to RAN rules, not to both at once.
Test the thresholds, not only the switch : a UE may attach to the ePDG only when the WLAN signal is above a limit and the LTE signal is below one.

7. What to do next ?

In any communication technology, it is almost impossible to fix the problems you would see without knowing the details of the protocol. So my first recommendation is to understand the overall WiFi Oflload concept and the details of IKE process.

After that, use the checklist as a sequence when a test fails. First, check that the UE is associated with the AP and has a local IP address from DHCP or from Router Advertisement. Second, check the DNS query for the ePDG FQDN and the address in the answer. Third, check that IKE_SA_INIT gets a response from that address. Fourth, check that EAP-AKA inside IKE_AUTH ends with EAP-Success. Finally, check the CFG_REPLY for the inner address and the P-CSCF address, and then the SIP REGISTER inside the tunnel.

The Overall Procedure of Untrusted Data Path Setup page shows these same steps as one sequence diagram, with the DHCP and DNS captures.

Stop at the first failed step : a later failure is usually a result of an earlier one, for example a wrong IP version in item 1.
Each step has its own log : DHCP and DNS are visible on the WLAN, while EAP and CFG exchanges need IKE decryption on the UE or the ePDG.

Reference

TS 23.003 v20.0.0 : Numbering, addressing and identification
TS 23.402 v19.0.0 : Architecture enhancements for non-3GPP accesses
TS 24.302 v19.0.0 : Access to the 3GPP Evolved Packet Core via non-3GPP access networks, Stage 3
TS 33.402 v19.0.0 : 3GPP System Architecture Evolution, Security aspects of non-3GPP accesses