ANDSF Premier: Access Network Discovery and Selection Function

September 30, 2014

introduction to ANDSF


Introduction To ANDSF

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.

high level interaction between andsf and ue

High Level Interaction Between ANDSF & UE


Information Exchanged By ANDSF 


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:

  • Access the technology type, such as WiFi, WiMAX
  • Radio access network identifier, such as SSID of WLANs
  • Technology-specific information, such as one or more carrier frequencies

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)

ISMP is valid for those UEs which cannot have more than one active access network connection at a time. For example, a UE that supports LTE as well as WiFi interface, but only one of them can be active at a time. ISMP consists of rules which can be used by UEs to select the most preferable access technology type. Such rules decide if a specific access technology is preferable to another (e.g. WiMAX is preferable to WLAN or WLAN SSID-1 is preferable to WLAN SSID-2, etc.) or not.

Inter-System Routing Policy (ISRP)

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

ANDSF architectureANDSF Architecture (5)


OMA-DM Protocol



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:

  • Device information – e.g. device ID, manufacturer, model tag, phone language and DM protocol version
  • Client credentials – used for authentication purposes (unless GAA is used)
  • Session origin – indicate whether the incoming session is client or server initiated

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 session message flowOMA-DM Session Message Flow

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

  • Add: add an object (node) to a tree
  • Get: returns a node name based on the URI passed with the GET request
  • Replace: replaces an object on the tree
  • Delete: deletes an object on the tree
  • Copy: copies an object on the tree
  • Exec: executes a device-defined command on an object on the tree

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

  • DevInfo
  • DevDetail
  • DmAcc


ANDSF & Hotspot 2.0

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.

Have A Radio Or Wireless Project?

Blog CTA Banner

External References

  1. 3GPP. TS 24.302: Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks.
  2. libdmclient. [Online]
  3. Funambol – OMA-DM Server. [Online]
  4. 3GPP. TS 24.312: Access Network Discovery and Selection Function (ANDSF) Management Object (MO). 
  5.  3GPP. TS 23.402: “Architecture Enhancements for non-3GPP Access”.
  6. OMA. SyncML Sync Protocol: V1.1. syncml_sync_protocol_v11_20020215.
  7. OMA. SyncML Representation protocol: V1.2.1. OMA-SyncML-RepPro-V1_2_1-20070813-A.
  8. Navarro, David. libdmclient: An Open Source implementation of OMA-DM. [Online]
  9. libdmclient. Source code: libdmclient. [Online]

No Comments

Add Comment