September 30, 2014
ANDSF, which stands for access network discovery and selection function, is an entity within the EPC (evolved packet core) with the purpose of assisting UEs in the discovery/selection of access networks, such as WiFi, WiMax, and LTE, in their vicinity; providing them with rules policing the connection to these networks (1).
ANDSF client, which runs on UE, interacts with the ANDSF server using OMA-DM (Open Mobile Alliance Device Management) protocol over the S14 interface. It’s an IP-based interface which supports ‘pull’ as well as ‘push’ mechanisms for communication. The illustration below shows high level interaction between UE and ANDSF Server.
ANDSF can be used to provide the following category of information to UE, based on operator configuration (4):
Access Network Discovery Information
It consists of a list of access networks, such as WiFi, that may be available in the vicinity of a UE. This information is received in response to the UE’s request which contains its location and capability, such as types of supported interfaces, among others. The received information assists the UE to expedite the connection to these networks. ANDSF response may contain the following information:
The suggested list of access networks may also include networks which are not owned by the same operator, but that have a roaming agreement with that operator.
Inter-System Mobility Policy (ISMP)
ISRP is valid for the UEs which can have more than one active access network connection simultaneously, and can also route IP traffic concurrently over multiple radio access interfaces. The UE can use this information to select the most preferable (or restricted) access technology/access network or APNs to direct a given traffic (per flow). Thus, it defines IFOM (per flow mobility) policies and can be used by UEs implementing seamless mobility protocols such as DSMIPv6.
All of this received information comes along with some validity conditions which indicate when it shall be valid, such as a location area condition, time-of-day condition, etc. For example, based on a UE’s location (home network or roaming), it can either latch on to H-ANDSF (home) or V-ANDSF (visitors).
The ANDSF client and server communicate using the OMA-DM protocol, a standard protocol which is designed for the management of mobile devices such as mobile phones, PDAs and tablets. It’s a simple client-server/request-response protocol which is IP-based and agnostic to the transport protocol being used. It is based on SyncML (a lighter version of XML) and uses a messaging sequence that consists of three parts (6):
Alert Phase-used only for server initiated management sessions
The alert phase is optional and data flows only from server to client. If the server wishes to push settings to the device, it has to send a notification package to that device requesting it to start a new management session. This alert phase is done with a WAP push message over SMS bearer.
Setup Phase-authentication and device information exchange
This is a mandatory phase in which data flows from the UE to the server. In this case, the client issues a setup request, with data flowing from client to server, followed by a server response. The initial client request contains three primary pieces of information:
Data (Management) Phase
In the data management phase, the device-initiated messages (inside HTTP POST Request) consist of status information and results that are provided in response to commands from the server. The first message is the response to commands included in the final setup phase message by the server (inside the HTTP ACK response). From there on, the server can issue new commands in next HTTP ACK message to a previous HTTP POST Request message, or it can simply indicate there are no more operations. In that case, the client will stop sending responses in the HTTP POST Request messages and close the session.
The setup and data phases are carried over a TLS session with the UE and server. The session is always started by the UE, but the server may request it with the alert notification SMS. The TLS session is secured according to the used security mode. In GAA (Generic Authentication Architecture), the TLS session is established using a negotiated PSK key while in the generic OMA DM mode, it is a normal HTTPS session.
If GAA is not used, the server responds with its credentials in order to identify itself to the client for authentication and identification purposes. The server also includes the first data command. In OMA-DM it is always the server which issues commands and the client can only follow those.
OMA-DM Management Objects
Device configuration data is organized in a hierarchical structure, called the device management tree. In this tree, sub-trees are called device management nodes and a leaf, usually a single configuration parameter, is referred to as a manageable object (MO). ANDSF MO is the sub-tree under ‘./ANDSF’ node (4). OMA-DM allows for the manipulation of management objects (MOs) via SyncML messages using the following server commands (7):
ANDSF MO management typically uses only the Add/Get/Replace/Delete commands. Each MO is an interface for functionality. As per OMA-DM, the following three MOs are mandatory (8):
As both of them define ways to assist the UE in discovering an access network, how does the UE choose between ANDSF and Hotspot2.0 for access network discovery? Currently no specification answers this question. At HSC, we believe these two techniques can work in tandem in order to expedite the discovery process; where ANDSF can provide a prioritized list of ANs (WiFi SSIDs), and then Hotspot2.0 can work on this list to make the selection, thereby skipping the ‘scan’ procedure.
Please visit our wireless engineering page for more information on our skills in this, and other, areas of wireless technology.
3GPP. TS 24.312: Access Network Discovery and Selection Function (ANDSF) Management Object (MO).
3GPP. TS 23.402: “Architecture Enhancements for non-3GPP Access”.
OMA. SyncML Sync Protocol: V1.1. syncml_sync_protocol_v11_20020215.
OMA. SyncML Representation protocol: V1.2.1. OMA-SyncML-RepPro-V1_2_1-20070813-A.
Navarro, David. libdmclient: An Open Source implementation of OMA-DM. [Online]https://01.org/sites/default/files/downloads/libdmclient/libdmclientfosdem2013.pdf.
libdmclient. Source code: libdmclient. [Online] https://01.org/libdmclient/downloads/2012/source-code-repository.