DESCRIPTION

TITLE

TRANSMISSION OF AN ANDSF MANAGED OBJECT TAILORED TO UE

CAPABILITIES This disclosure relates to a method and apparatus and in particular but not exclusively to method and apparatus for use for example for network selection.

A communication system can be seen as a facility that enables communication sessions between two or more entities such as fixed or mobile communication devices, base stations, servers, machine type communication devices and/or other communication nodes. A communication system and compatible communicating entities typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. For example, the standards, specifications and related protocols can define the manner how various aspects of communication such as access to the communication system and feedback messaging shall be implemented between communicating devices. The various development stages of the standard specifications are referred to as releases.

A communication can be carried on wired or wireless carriers. In a wireless

communication system at least a part of communications between stations occurs over a wireless link. Examples of wireless systems include public land mobile networks (PLMN) such as cellular networks, satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). A wireless system can be divided into cells or other radio coverage or service areas provided by a station. Radio service areas can overlap, and thus a communication device in an area can send and receive signals within more than one station. Each radio service area is controlled by an appropriate controller apparatus. Higher level control may be provided by another control apparatus controlling a plurality of radio service area.

A wireless communication system can be accessed by means of an appropriate communication device. A communication device of a user is often referred to as user equipment (UE) or terminal. A communication device is provided with an appropriate signal receiving and transmitting arrangement for enabling communications with other parties. Typically a communication device is used for enabling receiving and transmission of communications such as speech and data. In wireless systems a communication device provides a transceiver station that can communicate with another communication device such as e.g. a base station and/or another user equipment. Wi-Fi networks are becoming an integrated part of mobile broadband. Wi-Fi is a standard feature for example on devices which consume a relatively large amount of data such as smart phones, tablets and laptops.

According to an aspect there is provided a method comprising: generating a message comprising at least one indicator representing at least one defined capability of an apparatus; transmitting the message to a further apparatus; and receiving from the further apparatus a network access management message tailored based on the message comprising the at least one indicator.

Generating the message may comprise generating a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

Generating the message may comprise generating a management object to be exchanged between the apparatus and the further apparatus.

Generating a management object may comprise generating a management object comprising at least one capability indicator node, such that the capability comprises the at least one indicator representing at least one defined capability.

Generating the management object comprising at least one capability node may comprise locating the capability node within at least one of: a ./ANDSF/UE_Profile node; a

GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

Generating the management object comprising at least one capability node may comprise generating a Device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

Generating the management object comprising at least one capability node may comprise generating a Device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus. Generating a message comprising at least one indicator representing at least one defined capability of an apparatus may be performed in response to an apparatus capability request message.

The apparatus may be a user equipment and the further apparatus may be a ANDSF server.

Receiving from the further apparatus a network access management message tailored based on the message comprising the at least one indicator may comprise receiving a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

According to a second aspect there is provided a method comprising: receiving at an apparatus a message comprising at least one indicator representing a at least one defined capability of a further apparatus; generating a tailored network access management message based on the at least one indicator; and transmitting the tailored network access management message to the further apparatus.

Receiving the message may comprise receiving a GEN ERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

Receiving the message may comprise receiving a management object to be exchanged between the further apparatus and the apparatus.

Receiving the management object may comprise receiving at least one capability indicator node, and at least one value of the at least one indicator node represents at least one defined capability.

The capability node may be located within at least one of: a ./ANDSF/UE_Profile node; a GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

The management object may comprise a device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus. The management object may comprise a device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The method may comprise generating a capability request message.

The method may comprise transmitting the capability request message to the further apparatus.

The further apparatus may be a user equipment and the apparatus may be a ANDSF server.

The method may further comprise grouping UEs, which indicate the same capabilities into a group of UEs.

Generating a tailored network access management message based on the at least one indicator may comprise generating a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

Generating a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus may comprise generating identical ANDSF MO information to all UEs of that group.

The at least one defined capability may comprise at least one of: IARP Inter-APN Routing Policy; I FOM IP Flow Mobility; I FOM capable UE; ISMP Inter-System Mobility Policy; ISRP Inter-System Routing Policy; MAPCON Multi Access PDN Connectivity; NSWO Non-Seamless WLAN Offload; HS2.0 Hotspot 2.0; DIDA (Data Identification in ANDSF); UE radio capabilities; and U E radio access capabilities.

A computer program may comprise computer executable instructions which when run cause the method as described herein to be performed.

According to a third aspect there is provided an apparatus comprising at least one processor and at least one memory including computer code for one or more programs, the at least one memory and the computer code configured, with the at least one processor, to cause the apparatus at least to: generate a message comprising at least one indicator representing at least one defined capability of the apparatus; transmit the message to a further apparatus; and receive from the further apparatus a network access management message tailored based on the message comprising the at least one indicator.

Generating the message may cause the apparatus to generate a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

Generating the message may cause the apparatus to generate a management object to be exchanged between the apparatus and the further apparatus.

Generating a management object may cause the apparatus to generate a management object comprising at least one capability indicator node, such that the capability comprises the at least one indicator representing at least one defined capability.

Generating the management object comprising at least one capability node may cause the apparatus to locate the capability node within at least one of: a ./ANDSF/UE_Profile node; a ./DevDetail/Ext/<vendor> node; and a GENERIC ALERT message.

Generating the management object comprising at least one capability node may cause the apparatus to generate a Device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

Generating the management object comprising at least one capability node may cause the apparatus to generate a Device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

Generating a message comprising at least one indicator representing at least one defined capability of an apparatus may be performed by the apparatus in response to an apparatus capability request message. The apparatus may be a user equipment and the further apparatus may be a ANDSF server.

Receiving from the further apparatus a network access management message tailored based on the message comprising the at least one indicator may cause the apparatus to receive a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

According to a fourth aspect there is provided an apparatus comprising at least one processor and at least one memory including computer code for one or more programs, the at least one memory and the computer code configured, with the at least one processor, to cause the apparatus at least to: receive at the apparatus a message comprising at least one indicator representing a at least one defined capability of a further apparatus; generate a tailored network access management message based on the at least one indicator; and transmit the tailored network access management message to the further apparatus.

Receiving the message may cause the apparatus to receive a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

Receiving the message may cause the apparatus to receive a management object to be exchanged between the further apparatus and the apparatus.

Receiving the management object may cause the apparatus to receive at least one capability indicator node, and at least one value of the at least one indicator node represents at least one defined capability.

The capability node may be located within at least one of: a ./ANDSF/UE_Profile node; a GENERIC ALERT Message; and a ./DevDetail/Ext/<vendor> node.

The management object may comprise a device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus. The management object may comprise a device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The apparatus may be caused to generate a capability request message.

The apparatus may be caused to transmit the capability request message to the further apparatus.

The further apparatus may be a user equipment and the apparatus may be a ANDSF server.

The apparatus may be further caused to group UEs, which indicate the same capabilities into a group of UEs.

Generating a tailored network access management message based on the at least one indicator may cause the apparatus to generate a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

Generating a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus may cause the apparatus to generate identical ANDSF MO information to all UEs of that group.

The at least one defined capability may comprise at least one of: IARP Inter-APN Routing Policy; IFOM I P Flow Mobility; I FOM capable UE; ISMP Inter-System Mobility Policy; ISRP Inter-System Routing Policy; MAPCON Multi Access PDN Connectivity; NSWO

Non-Seamless WLAN Offload; HS2.0 Hotspot 2.0; DIDA (Data Identification in ANDSF); UE radio capabilities; and U E radio access capabilities.

According to a fifth aspect there is provided an apparatus comprising: means for generating a message comprising at least one indicator representing at least one defined capability of the apparatus; means for transmitting the message to a further apparatus; and means for receiving from the further apparatus a network access management message tailored based on the message comprising the at least one indicator. The means for generating the message may comprise means for generating a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

The means for generating the message may comprise means for generating a

management object to be exchanged between the apparatus and the further apparatus.

The means for generating a management object may comprise means for generating a management object comprising at least one capability indicator node, such that the capability comprises the at least one indicator representing at least one defined capability.

The means for generating the management object comprising at least one capability node may comprise means for locating the capability node within at least one of: a

./AN DS F/U E_Prof ile node; a GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

The means for generating the management object comprising at least one capability node may comprise means for generating a Device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

The means for generating the management object comprising at least one capability node may comprise means for generating a Device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The means for generating a message comprising at least one indicator representing at least one defined capability of an apparatus may be configured to operate in response to an apparatus capability request message.

The means for receiving from the further apparatus a network access management message tailored based on the message comprising the at least one indicator may comprise means for receiving a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus. According to a sixth aspect there is provided an apparatus comprising: means for receiving at an apparatus a message comprising at least one indicator representing a at least one defined capability of a further apparatus; means for generating a tailored network access management message based on the at least one indicator; and means for transmitting the tailored network access management message to the further apparatus.

The means for receiving the message may comprise means for receiving a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

The means for receiving the message may comprise means for receiving a management object to be exchanged between the further apparatus and the apparatus.

The means for receiving the management object may comprise means for receiving at least one capability indicator node, and at least one value of the at least one indicator node represents at least one defined capability.

The capability node may be located within at least one of: a ./ANDSF/UE_Profile node; a GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

The management object may comprise a device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

The management object may comprise a device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The apparatus may comprise means for generating a capability request message.

The apparatus may comprise means for transmitting a capability request message to the further apparatus. The further apparatus may be a user equipment and the apparatus may be a ANDSF server.

The apparatus may further comprise means for grouping UEs, which indicate the same capabilities into a group of UEs.

The means for generating a tailored network access management message based on the at least one indicator may comprise means for generating a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

The means for generating a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus may comprise means for generating identical ANDSF MO information to all UEs of that group.

According to a seventh aspect there is provided an apparatus comprising: a message generator configured to generate a message comprising at least one indicator

representing at least one defined capability of the apparatus; a transmitter configured to transmit the message to a further apparatus; and a receiver configured to receive from the further apparatus a network access management message tailored based on the message comprising the at least one indicator.

The message generator may be configured to generate a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

The message generator may comprise a management object generator configured to generate a management object to be exchanged between the apparatus and the further apparatus.

The management object generator may be configured to generate a management object comprising at least one capability indicator node, such that the capability comprises the at least one indicator representing at least one defined capability. The management object generator may be configured to locate the capability node within at least one of: a ./ANDSF/UE_Profile node; a GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

The management object generator may be configured to generate a Device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

The management object generator may be configured to generate a Device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The message generator may be configured to operate in response to an apparatus capability request message.

The receiver may be configured to receive a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

According to an eighth aspect there is provided an apparatus comprising: a receiver configured to receive at the apparatus a message comprising at least one indicator representing a at least one defined capability of a further apparatus; a network access management message generator configured to generate a tailored network access management message based on the at least one indicator; and a transmitter configured to transmit the tailored network access management message to the further apparatus.

The receiver may be configured to receive a GENERIC ALERT message comprising the at least one indicator representing the at least one defined capability of the apparatus.

The receiver may be configured to receive a management object to be exchanged between the further apparatus and the apparatus.

The receiver may be configured to receive at least one capability indicator node, and at least one value of the at least one indicator node represents at least one defined capability. The capability node may be located within at least one of: a ./ANDSF/UE_Profile node; a GENERIC ALERT message; and a ./DevDetail/Ext/<vendor> node.

The management object may comprise a device capability indicator leaf (DevCapab) comprising a bitmask for each capability, such that the bitmask for each capability is the indicator representing the at least one defined capability of the apparatus.

The management object may comprise a device capability indicator leaf (DevCapab) linked to at least one child capability node, such that an at least one child capability node value is the indicator representing the at least one defined capability of the apparatus.

The apparatus may comprise a capability request generator configured to generate a capability request message.

The transmitter may be configured to transmit the capability request message to the further apparatus.

The further apparatus may be a user equipment and the apparatus may be a ANDSF server.

The apparatus may further comprise a UE grouper configured to group UEs, which indicate the same capabilities into a group of UEs.

The network access management message generator may be configured to generate a ANDSF Management Object tailored based on the at least one indicator representing at least one defined capability of an apparatus.

The network access management message generator may be configured to generate identical ANDSF MO information to all UEs of that group.

Various other aspects and further embodiments are also described in the following detailed description and in the attached claims. Embodiments will now be described in further detail, by way of example only, with reference to the following examples and accompanying drawings, in which:

Figure 1 shows a schematic diagram of a cellular communication system within which some embodiments can be;

Figure 2 shows a schematic diagram of an ANDSF deployment within which some embodiments can be implemented to deliver Access Network discovery and network selection information to a mobile terminal (User Equipment, UE) in a mobile

communications network (e.g. 3GPP access network) or in wireless area network (WLAN, WiFi);

Figure 3 schematically shows a user equipment (UE) according to some embodiments;

Figure 4 schematically shows control apparatus according to some embodiments;

Figure 5 shows a flow diagram of the operation of some embodiments;

Figure 6 shows an example management object part according to some embodiments; Figure 7 shows an example node data structure used the management object

embodiments shown in Figure 6;

Figure 8 shows a further example management object part according to some

embodiments; and

Figure 9 shows an example node data structures used the management object embodiments shown in Figure 8.

In the following certain exemplifying embodiments are explained with reference to a cellular mobile communication system and a wireless area network serving mobile communication devices and the interaction there between.

Before explaining in detail the exemplifying embodiments, certain general principles of a cellular wireless communication system are briefly explained with reference to Figures 1 to 4 to assist in understanding the technology underlying the described examples.

In a cellular communication system mobile communication devices or user equipment (UE) 102, 103, 105 are provided wireless access via at least one base station or similar wireless transmitting and/or receiving node or point. In the Figure 1 example two overlapping access systems or radio service areas of a cellular system 100 and 1 10 and three smaller radio service areas 1 15, 1 17 and 1 19 provided by base stations 106, 107, 1 16, 1 18 and 120 are shown. Each mobile communication device and station may have one or more radio channels open at the same time and may send signals to and/or receive signals from more than one source. It is noted that the radio service area borders or edges are schematically shown for illustration purposes only in Figure 1 . It shall also be understood that the sizes and shapes of radio service areas may vary considerably from the shapes of Figure 1 . A base station site can provide one or more cells. A base station can also provide a plurality of sectors, for example three radio sectors, each sector providing a cell or a subarea of a cell. All sectors within a cell can be served by the same base station.

Base stations are typically controlled by at least one appropriate controller apparatus so as to enable operation thereof and management of mobile communication devices in communication with the base stations. It would be understood that in some network architectures such as for example LTE this controller apparatus would be in base station itself, in other words there would be no separate controller. Furthermore it would be understood that cellular networks allow cellular devices to communicate with other cellular devices and other networks over a wide geographical area via cellular base stations and typically maintain communication even when cellular devices are moving.

In Figure 1 control apparatus 108 and 109 is shown to control the respective macro level base stations 106 and 107. The control apparatus of a base station can be interconnected with other control entities. The control apparatus is typically provided with memory capacity and at least one data processor. The control apparatus and functions may be distributed between a plurality of control units.

In Figure 1 stations 106 and 107 are shown as connected to a wider communications network 1 13 via gateway 1 12. A further gateway function may be provided to connect to another network. The smaller stations 1 16, 1 18 and 120 can also be connected to the network 1 13, for example by a separate gateway function and/or via the controllers of the macro level stations. In the example, stations 1 16 and 1 18 are connected via a gateway 1 1 1 whilst station 120 connects via the controller apparatus 108.

Wi-Fi networks are in some places becoming an integral part of mobile broadband. Wi-Fi is a standard feature on some smart phones, tablets and laptops. Some operators are using or planning to use Wi-Fi alongside mobile radio access networks. As Wi-Fi becomes just another cell alongside mobile radio access networks, some operators need to control how the user device or user equipment moves between the mobile and Wi-Fi networks. In some embodiments, dynamic mechanisms may be required in order to control the movement of the user equipment between the mobile and Wi-Fi networks.

For example, a network operator may wish to offload selected users to a Wi-Fi network only when certain conditions are satisfied. For example, if there is congestion in the mobile network, the network operator may wish to offload some of the users to a Wi-Fi network. In some cases the operator may wish to control when the users are using the mobile network. This control may be provided for one or more reasons. For example, the control may be required for policy reasons, user experience reasons, network

management reasons, network performance reasons, charging reasons and/or traffic management reasons.

Currently, the network selection tool which guide how the user moves between mobile and Wi-Fi networks may be static. For example, the Access Network Discovery and Selection Function (ANDSF) is an entity which is provided in some 3GPP networks. See for example 3GPP TS 23.402. The ANDSF server assists a user equipment to discover non- mobile networks such as Wi-Fi or the like which can be used for data communication instead of or in addition to the mobile network.

The Access Network Discovery and Selection Function (ANDSF) in other words provides the UE with information (called ANDSF information) to support inter-system mobility, inter- system routing and access network discovery. ANDSF Inter-system routing policies can be based on the Application Identity, which is unique per operating system in the UE.

The ANDSF information allows the UE to select between access technology types or specific access networks like WLAN hotspots that are available to the UE. The user preferences may also take precedence over ANDSF rules, if for example the user decides to access his home WLAN network.

The ANDSF information is defined in three main groups, that is, the inter-system mobility policies (ISMP), access network discovery information (ANDI) and inter-system routing policies (ISRP). An inter-system mobility policy can contain a preference list of the access networks the UE should use at a given location during a given time.

For access network discovery, the ANDSF can provide information on access networks that are available in the UE's neighbourhood including the access technology types like WLAN or WiMAX and access network identifiers like the WLAN Service Set Identifier (SSID) and Homogeneous Extended Service Set Identifier (HESSID).

Inter-system routing policies are applicable to UEs that are able to route IP traffic simultaneously over multiple radio interfaces (e.g. an IP Flow Mobility <IFOM> capable UE). Using ISRP, the operator can instruct the mobile terminals to route certain types of traffic through a given radio interface. The ISRP rules can also be used to inform the UE about access technology types or access networks that are not allowed for a specific traffic flow.

ANDSF is based on a client/server architecture such as shown in Figure 2. The interface between the ANDSF client running on the UE 200 and the ANDSF server 251 is called S14 231 . The interface S14 231 is shown in Figure 2 as operation via a WLAN network 241 , a 3G network 243 and a LTE network 245, however any suitable network providing access to the ANDSF server can be used to set up the communication link between the user equipment 200 and the ANDSF server 251 .

OMA Device Management is used over the S14 interface 231 to provide data to the UE via push (server initiated) or pull (UE initiated) mode. For example the push mode can be defined to work with short message service (SMS). The S14 interface 231 requires an IP connection to be established between the UE 200 and ANDSF server 251 via 3GPP 243, 245 or non-3GPP 241 access networks.

The ANDSF server can be located in the home network (H-ANDSF) or in the visited network (V-ANDSF) and the rules from V-ANDSF can in some situations be specified to have priority over the rules from the H-ANDSF. In roaming scenarios, the UE can discover the V-ANDSF server in the Visiting Public Land Mobile Network (VPLMN) using a Domain Name System (DNS) and in non-roaming scenarios the UE can, in addition to DNS, also use Dynamic Host Configuration Protocol (DHCP) to discover the IP address of the H- ANDSF (the ANDSF address or name can be provided in DHCP messages to the UE during IP address allocation). The H-ANDSF address or name may also be pre-configured in the UE.

More details on the ANDSF framework can be found in TS 23.402 and TS 24.302.

The ANDSF Management Object (ANDSF-MO) specifying the structure of ANDSF rules and corresponding XML representation is described in TS 24.312.

The ANDSF-MO specified in 3GPP TS 24.312 however is rather big in size and complex and is still continuously growing in size due to new features to be supported by ANDSF are added in each new 3GPP release. The corresponding significant amount of data to be stored in the ANDSF server, sent to the UE and stored in the UE is therefore generating traffic load and reliability difficulties.

In embodiment described herein where the ANDSF server is made aware of all the relevant UE capabilities, the ANDSF server can be configured to streamline and optimize the ANDSF-MO information it delivers to the UE. For example this can be performed in some embodiments by using a node UE_Profile in ANDSF-MO.

One example case is where a UE which supports inter-system routing policies based on Application Identifiers should indicate this capability to the ANDSF server, so that the ANDSF server can deliver appropriate ANDSF information to the UE.

This application and the embodiments described herein show how the UE can indicate that the UE supports inter-system routing policies based on Application Identifiers. The mechanism described herein can also be used to provide indications of other UE capabilities as discussed herein also.

A possible mobile communication device suitable for implementing some embodiments will now be described in more detail in reference to Figure 3 showing a schematic, partially sectioned view of a communication device 102. Such a communication device is often referred to as user equipment (UE) or terminal. An appropriate mobile communication device may be provided by any device capable of sending and receiving radio signals. Non-limiting examples include a mobile station (MS) such as a mobile phone or what is known as a 'smart phone', a computer provided with a wireless interface card or other wireless interface facility, personal data assistant (PDA) provided with wireless

communication capabilities, or any combinations of these or the like. A mobile

communication device may provide, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and so on. Users may thus be offered and provided numerous services via their communication devices. Non-limiting examples of these services include two-way or multi-way calls, data communication or multimedia services or simply an access to a data communications network system, such as the Internet. Users may also be provided broadcast or multicast data. Non-limiting examples of the content include downloads, television and radio programs, videos, advertisements, various alerts and other information.

The mobile device 102 may receive signals over an air interface 207 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In Figure 3 transceiver apparatus is designated schematically by block 206. The transceiver apparatus 206 may be provided for example by means of a radio part and associated antenna arrangement.

A mobile device is also typically provided with at least one data processing entity 201 , at least one memory 202 and other possible components 203 for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 204. The user may control the operation of the mobile device by means of a suitable user interface such as key pad 205, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 208, a speaker and a microphone can be also provided.

Furthermore, a mobile communication device may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto.

The communication devices can access the communication system based on various access techniques, such as 3GPP standardized long term evolution (LTE), code division multiple access (CDMA), or wideband CDMA (WCDMA). Other examples include time division multiple access (TDMA), frequency division multiple access (FDMA) and various schemes thereof such as the interleaved frequency division multiple access (IFDMA), single carrier frequency division multiple access (SC-FDMA) and orthogonal frequency division multiple access (OFDMA), space division multiple access (SDMA) and so on. Some communication devices can in addition also access local area or wide area communications systems based on various non-3GPP standardized access techniques such as wireless local area network (WLAN, WiFi) and/or WiMax (Worldwide

Interoperability for Microwave Access) and/or HRPD (High Rate Packet Data, commonly known as 1 xEV-DO).

A non-limiting example of the recent developments in communication system architectures is the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) that is being standardized by the 3rd Generation Partnership Project (3GPP). As explained above, further development of the LTE is referred to as LTE-Advanced. Non- limiting examples of appropriate LTE access nodes are a base station of a cellular system, for example what is known as NodeB (NB) in the vocabulary of the 3GPP specifications. The LTE employs a mobile architecture known as the Evolved Universal Terrestrial Radio Access Network (E-UTRAN). Base stations of such systems are known as evolved or enhanced Node-Bs (eNBs) and may provide E-UTRAN features such as user plane Radio Link Control/Medium Access Control/Physical layer protocol (RLC/MAC/PHY) and control plane Radio Resource Control (RRC) protocol terminations towards the user devices.

One or more entities of the following may be provided with a control apparatus. Figure 4 shows an example of a control apparatus. The control apparatus 400 can be configured to provide control functions. For this purpose the control apparatus 400 comprises at least one memory 301 , at least one data processing unit 302, 303 and an input/output interface 304. Via the interface the control apparatus can be coupled to receive information and/or commands and/or provide as an output information and/or commands. The control apparatus 400 can be configured to execute an appropriate software code to provide the control functions. The aim according to the embodiments described herein is for the UE itself to set an indication in the UE-Profile about the UE's capabilities which is read by the ANDSF server. In OMA DM framework, the basis for ANDSF framework the server is always in charge of the session. Thus, UE only responds to the queries/commands sent from the server. The query/command components and their results are packaged into specific OMA DM

Packages and these packages are exchanged between UE and ANDSF server during communication. For example, UE cannot autonomously send U E_Profile node information to the server, but can only send the UE_Profile information after the ANDSF server has issued GET command on UE_Profile node. (Devlnfo standardized MO is the only exception: it is mandatory for the UE to send Devlnfo MO to the server during the establishment of the OMA DM session). The ANDSF Server can in some embodiments can get and read this information in the ANDSF-MO during the ANDSF session and adapts the ANDSF MO information delivered to the UE according to the UE capabilities.

In some embodiments as are discussed herein the indication of the UE's capabilities can be included into the DevDetail or Devlnfo nodes. These UE's capabilities can in some embodiments be sent or can be queried from the UE during the ANDSF session establishment. In some embodiments the UE's capabilities can be inserted or included into any other suitable position in the open mobile alliance (OMA) device management (DM) management object (MO) utilized for AN DSF services.

In some embodiments the indication of the UE's capabilities could be included into a GENERIC ALERT message. In such embodiments the UE can include any number of GENERIC ALERT messages into the OMA DM Packages sent to the ANDSF server during the communication. The ANDSF server does not request or query for any

GENERIC ALERT messages as they are just included autonomously by the UE where and if the UE needs to alert server. It could for example contain reason for the

communication. The OMA DM specification does not define what information is included in the GENERIC ALERT messages. UE can indicate the type of the information and actual information format and information if any. AN DSF specification as it currently stands defines 4 different message types for GENERIC ALERT indicating whether devices wishes to receive complete ANDSF MO or specific partial updates. In some embodiments the GENERIC ALERT message format and data content is defined such that the ANDSF server is able to associate the type into specific message structure and understand the format such that the ANDSF server determines or decodes the information in the

GENERIC ALERT concerning the UE capability. This information could contain in some embodiments the same data as described herein with respect to the UE_Profile node. Individual capabilities could be also included capability specific GENERIC ALERT messages. For example in some embodiments the UE capabilities are included into one or more GENERIC ALERT messages included into the OMA DM pkg#1 (as shown with respect to the U E_Profile message example) in Figure 5 by step 405.

The UE capabilities that can be indicated using this mechanism can be for example:

Data Identification in ANDSF (DI DA), or individual features of DI DA: such as traffic identification by implying local application which generates the traffic and traffic identification based on target FQDN, Inter System Mobility Policy (ISMP), Inter System Routing Policy (ISRP), WLAN, WiFi and other non-3GPP access variants, WiMAX, CDMA-2000, 3GPP access variants and any other suitable UE capability (current and future capability).

With respect to Figure 5 an example flow diagram of the signaling flow for an ANDSF session according to some embodiments where a UE_Profile as discussed herein can be used to tailor ANDSF MO contents for the specific UE 200.

In some embodiments the UE 200 can be configured to connect to the EPC (Evolved Packet Core) either using a 3GPP radio access or non-3GPP access (for example WLAN).

The operation of connecting to the EPC by the UE is shown in Figure 5 by step 401 .

In some embodiments the UE 200 discovers the ANDSF server 251 (the ANDSF server 251 operation being defined for example in 3GPP TS 24.302) and establishes a secure connection to the server using GAA (Generic Access Authentication) mechanisms.

The operations of discovering the ANDSF server and establishing a secure connection is shown in Figure 5 by step 403.

In some embodiments the UE initiates the actual Open Mobile Alliance (OMA) Device Management (DM) session by sending a first message to the ANDSF server. It would be understood that in some embodiments the OMA DM specifications define the contents of the message. Thus for the first message can be for example an OMA DM Devlnfo message transferred from the UE 200 to the ANDSF server 251 . The operation of establishing the OMA DM session by sending a first message, for example a HTTP Post (OMA DM pkg#1 : Devlnfo) message, is shown in Figure 5 by step 405.

In some embodiments the ANDSF session establishment is finalized. This can for example be performed by the AN DSF server 407 transmitting a message (for example an OK message) to the U E 200. In some embodiments the ANDSF server 251 can be configured to include OMA DM management commands into this message. For example in some embodiments where the ANDSF server decides to read the contents of

UE_Profile from the UE the ANDSF server 251 can be configured to transmit a GET UE_Profile indicator within the OK message. This for example can be a HTTP OK (OMA DM pk#4 : Get UE_Profile) message.

The operation of transmitting the Get UE_Profile message according to some

embodiments is shown in Figure 5 by step 407.

The UE having received the ANDSF server 251 GET request can then be configured to generate a suitable response containing UE_Profile information according to some embodiments as discussed herein. The UE_Profile information can in some embodiments be sent as a HTTP Post (OMA DM pkg#3 : UE_Profile included) message.

The operation of generating and transmitting the message containing UE_Profile information according to some embodiments is shown in Figure 5 by step 409.

The ANDSF server, having received the UE_Profile as described herein, can be configured to then tailor the ANDSF MO to match the specific capabilities of the UE.

The operation of configuring or tailoring the ANDSF management object contents based on the UE_Profile information is shown in Figure 5 by step 41 1 .

It would be understood that in some embodiments the operator of the ANDSF server 251 can choose to streamline, optimize and/or minimize the ANDSF information transmitted or delivered to the specific UE. In some embodiments the ANDSF server 251 can choose to streamline, optimize and/or minimize the AN DSF information transmitted or delivered to a group of UEs, where all UEs in the group have indicated the same UE capabilities.

Thus for example the ANDSF server 251 can be configured to transmit to the UE 200, or to the group of UEs all having the same UE capabilities, the tailored or modified ANDSF MO. The tailored or modified ANDSF MO can for example be transmitted to the UE in the form of a HTTP OK (OMA DM pkg#4: ADD ANDSF MO) message.

The generation and transmission of the modified or tailored management object to the UE is shown in Figure 5 by step 413.

The UE in some embodiments can be configured to receive and store the modified or tailored MO and furthermore configured to acknowledge the operation to the server. This can for example be implemented in some embodiments by the UE 250 transmitting a HTTP POST (OMA DM pkg#3 : ack) message to the AN DSF server 251 .

The operation of receiving, storing and acknowledging the modified or tailored MO is shown in Figure 5 by step 415.

In this example scenario the ANDSF session is terminated after the successful ANDSF MO provisioning. This termination is shown for example by the ANDSF server 251 transmitting to the UE 250 a HTTP OK (OMA DM pkg#4 : final) message.

The operation of terminating the MO provisioning is shown in Figure 5 by step 417.

After termination of the ANDSF session, U E can start using the tailored ANDSF MO information in all subsequent network decisions and/or handover decisions between 3GPP and non-3GPP access networks.

The UE capability indication in some embodiments is added to an OMA DM MO structure exchanged between UE and ANDSF server. For example in some embodiments the capability indicator node location could be ./ANDSF/UE_Profile node or a

./DevDetail/Ext/<vendor> node. With respect to Figures 6 and 8 example capability indicator structures according to some embodiments are shown. In the example shown in Figures 6 and 8 the location of the capability indicator is illustrated for ./ANDSF/UE_Profile node with the proposed new DevCapab node to store the UE capabilities.

Thus in the example shown in Figure 6 the MO structure is the root UE_Profile 501 , the placeholder interior node <X>+ 503 which means that there are one or more instances of this interior node (containing the child nodes), and furthermore that the server can give the name of the "<X> +" node during run time (i.e. during the creation of the ANDSF MO). For example, the server could create UE_Profile with two instances of "<X> +" node and name them with a digit and '2', respectively (Ext node not defined, '?' stands for optionality):

UE_Profile/1/OSId=iOS

UE_Profile/1/DecCapab= 10000000 /* arbitrary example */

UE Profile/2/OSId=Android

UE_Profile/2/DevCapab=0100000 /* arbitrary example */

The root UE_Profile 501 further comprises the Operating system Identifier (OSId) 505 leaf, the Device capability indicator leaf DevCapb 507, and an interior node Ext 509. The Ext 509 node is in some embodiments a placeholder for vendor/operator specific extensions that do not need to be standardized. For example this is a common way of defining Management Objects (MO) in OMA DM. For example OMA Device Management comprises a framework for remote device management.

With respect to Figure 7 an example content configuration for a DevCapab node is shown. In some embodiments the DevCapab node is an OMA DM MO leaf node that contains a

"bitmask" for each capability. For example as shown in Figure 7 the DevCapab node is a sequence of ' 1 ' or Ό' characters where each position indicates support for a specific feature. For example, the first character could indicate support for Data identification in ANDSF (DI DA), where the character value denotes support and Ό' denotes no support, and further characters indicate support or lack of support for other features. DI DA Data

Identification in ANDSF for example is a mechanism which allows 3GPP operator to control UE traffic routing to different IP interfaces based on target network FQDN and/or used UE application. Thus for example the DIDA may control for example "All traffic to www.netflix.com is sent via WLAN", or "All traffic from Application com. android. netflix is sent via WLAN".

With respect to Figure 8 a further example capability indicator structure is shown. In this example the MO structure is the root UE_Profile 501 , the placeholder interior node <X>+ 503 for an account for a fixed node, the Operating system Identifier (OSId) 505 leaf, and an interior node Ext 509. However in the example shown in Figure 8 the DevCapab leaf node 601 is an OMA DM MO interior node that can comprise separate child nodes for each capability. Thus as shown in Figure 8 example child nodes are show representing Data identification in ANDSF (DIDA) 603, Inter system mobility policy (ISMP) 605 and Inter system routing policy (ISRPJFOM) 607 capability.

Figure 9 shows the example DevCapab lead node 601 which acts as a place holder for the child nodes. Furthermore Figure 9 shows the example DIDA child node 603. In the example format of the DIDA child node 603 the node comprises a Boolean value indicating support for the feature. In some embodiments where the leaf is not present or the leaf value is 'False' then the UE or device does not support a DIDA feature. Figure 9 also shows the example ISMP child node 605. In the example format of the DIDA child node 605 the node comprises a Boolean value indicating support for the feature. Similarly in some embodiments where this leaf is not present or the leaf value is 'False' then device does not support an ISMP feature. Also in Figure 9 is shown an example format of the ISRPJFOM node 607 which comprises a Boolean value indicating support for the feature. Where the ISRP_IFOM node leaf is not present or the leaf value is 'False' then the device does not support an ISRP IFOM feature.

It would be envisaged that by implemented embodiments as described herein that the ANDSF server could be configured to determine the UE's capabilities related to the ANDSF supported features and thus be able to configure or adapt the ANDSF information delivered to the UE according to the UE's capabilities, thereby optimizing or minimizing the size of the ANDSF information delivered to the UE.

Furthermore the operator could by implementing embodiments as described herein determine what ANDSF related UE capabilities are available (in reality) in their network on average or per specific UE and thus could be configured to streamline network capacity accordingly.

The operator of the ANDSF server, which typically also is the operator

of the mobile communications network or the operator of the local area

wireless network, can use the methods described herein to determine

specific amounts of UEs or average numbers of UEs having defined UE

capabilities in the network. Such an operator can use this information

for ANDSF purposes as described previously, but the collected UE

capability information can also be used to determine whether there is a

need to add network capacity, or to redistribute network capacity, to

support the UE capabilities detected in the network in an optimized

way. Although in the example shown the leaves show DIDA, ISMP and ISRP nodes other types of capability as indicated herein may be shown according to some embodiments.

Other capabilities can for example be:

IARP Inter-APN Routing Policy a mechanism which allows 3GPP operator to route traffic via specific APN. APN itself can be bound to specific IP interface using

IFOM, NSWO or MAPCON.

- IFOM IP Flow Mobility a mechanism which allows 3GPP operator to route some traffic via 3GPP and some via non-3GPP networks like WLAN. In such situations the device has to support simultaneously multiple access networks.

IFOM capable UE: A UE that is capable of routing different IP flows to the same

PDN connection through different access networks.

- ISMP Inter-System Mobility Policy a mechanism which allows 3GPP operator to route all traffic either via 3GPP or via non-3GPP network. In such situations the UE operates only a single radio at time.

- ISRP Inter-System Routing Policy which is a container for IFOM, MAPCON and

ISRP policies. Where a device supports multiple access networks simultaneously it is ISRP capable. However IARP may be placed for example under ISRP or next to

ISRP/ISMP definitions in ANDSF MO.

MAPCON Multi Access PDN Connectivity a mechanism for 3GPP operator to control the access network selection for specific APN. The UE uses the intersystem routing policies when it can route IP traffic simultaneously over multiple radio access interfaces (e.g. it is an IFOM capable UE with the IFOM capability enabled or a MAPCON capable UE with the MAPCON capability enabled) in order to meet the operator routing / offload preferences.

NSWO Non-Seamless WLAN Offload a mechanism which allows 3GPP operator to route some traffic directly to WLAN without routing it via EPC (LTE packet core). Device has to support simultaneously multiple access networks.

HS2.0 Hotspot 2.0 a WiFi Alliance initiative to enable seamless Wi-Fi usage including roaming support and online service activation.

DIDA, Data Identification in ANDSF: a mechanism which allows 3GPP operator to control UE traffic routing to different IP interfaces based on target network FQDN and/or used UE application. "All traffic to www.netflix.com is sent via WLAN", "All traffic from Application com. android. netflix is sent via WLAN"

HS2.0 Hotspot 2.0: WiFi Alliance initiative to enable seamless Wi-Fi usage including roaming support and online service activation

- UE radio capabilities like 3GPP standardized access technologies

UE radio access capabilities like non-3GPP standardized access technologies, for example WLAN, HRPD, WiMAX

Other existing and future UE capabilities that are supported by ANDSF information delivered to the UE.

Although the embodiments describe herein the action of a single UE or device it would be understood that in some embodiments the ANDSF server can group UEs, which indicated the same capabilities into a group of UEs. In such embodiments because all UEs in the group have the same UE capabilities, the ANDSF server can deliver identical ANDSF MO information to all UEs of that group. The term describing such a tailoring of information could be for example information for a "Group of UEs with the same capability" or shorter "same capability UE group".

Various entities have been described as being used in embodiments. These entities are by way of example only and alternative or additional entities may be used alternatively or additionally.

The required data processing apparatus and functions of an apparatus in a network element and/or a mobile device and/or core network element may be provided by means of one or more data processor. The described functions may be provided by separate processors or by an integrated processor. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multi core processor architecture, as non limiting examples. The data processing may be distributed across several data processing modules. A data processor may be provided by means of, for example, at least one chip. Appropriate memory capacity can also be provided in the relevant devices. The memory or memories may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. An appropriately adapted computer program code product or products may be used for implementing the embodiments, when loaded or otherwise provided on an appropriate data processing apparatus. The program code product for providing the operation may be stored on, provided and embodied by means of an appropriate carrier medium. An appropriate computer program can be embodied on a computer readable record medium. A possibility is to download the program code product via a data network. In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Embodiments may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large an automated process. Complex and powerful tools are available for converting a logic level design into a semiconductor circuit design ready to be formed on a semiconductor substrate.

It is noted that whilst embodiments have been described in relation to particular standards similar principles can be applied to any other communication system. Therefore, although certain embodiments were described above by way of example with reference to certain exemplifying architectures for wireless networks, technologies and standards,

embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the exemplary embodiments of this invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. For example, a combination of one or more of any of the other embodiments previously discussed can be provided. All such and similar modifications of the teachings of this invention will still fall within the scope of this invention as defined in the appended claims.