WO2014088408A1

WO2014088408A1 - System and method for data traffic offloading

Info

Publication number: WO2014088408A1
Application number: PCT/MY2013/000249
Authority: WO
Inventors: Chieng Heng TZE; Kwong Kae HSIANG; Ting Kee NGOH
Original assignee: Mimos Bhd
Current assignee: Mimos Bhd
Priority date: 2012-12-05
Filing date: 2013-12-04
Publication date: 2014-06-12
Anticipated expiration: 2015-06-05
Also published as: MY182199A

Abstract

A method for data traffic offloading to an alternative radio access network among a plurality of available alternative radio access networks for use by a client device connected to a network through a radio access network is provided. The client device has a plurality of types of data traffics. The method comprises registering the client device to a traffic manager residing at the network end, storing in the traffic manager the radio access network performance parameters as expected by each data traffic in the client device. It is then determined whether the expected network performance parameters arc violated, and when the expected network performance parameters are violated, the traffic manager instructing the client device to identify available alternative radio networks, and upon identification, the traffic manager deciding on behalf of the client device which specific data traffic type suitable to offload to the identified available alternative radio networks. A system for such data traffic offloading is also provided herein.

Description

System and Method For Data Traffic Offloading

Field of the Invention

The present invention relates to wireless network. In particular, the present invention relates to system and method for traffic offloading in a wireless network.

Background

The number of smart phones and other mobile computing devices, such as laptops and tablets, has grown exponentially iu past decades and causes heavy data traffic in wireless networks. As a result, network problems such as service degradation, inten'upted service or connection loss, are becoming more evident. The network operators are demanded to cope with such surge in capacity demand, or else they might lose revenue as well as customer's confidence.

The explosion of data traffic on a network has created a need for offloading data traffic. Data offloading allows the device connected to the network to move its data traffic to alternative networks. In current praclice, the network typically offloads the data traffic to any alternative network accessible by the devices. For example, a mobile network may offload its traffic to WiFi as the mobile device falls within the WiFi coverage area. However, this may not be an efficient solution to handle the data traffic. One widely known problem related to such traffic offloading is that the target network often is heavily traffic-loaded thai the user indeed experiences worse service after offloading. Summary

In one aspect of the present invention, there is provided a method for data traffic offloading†o an alternative radio access network among a plurality of available alternative radio ccess networks for use by a client device connected to a network through a radio access network, the client device having a plurality of data traffic types. The method comprises registering flic client device to a traffic manager residing at the network end, storing in the traffic manager the radio access network performance parameters as expected by each data traffic in the client device; determining whether the expected network performance parameters are violated; and when the expected network performance parameters are violatedj the traffic manager instructing the client device to identify available alternative radio networks, and upon identification, the traffic manager deciding on behalf of the client device which specific data traffic type suitable to offload to the identified available alternative radio networks.

In one embodiment, the radio access network performance parameters may include client link quality, traffic type and corresponding client quality of experience, traffic type and corresponding quality of service, core network connectivity, and respective radio access networks load condition.

In another embodiment, the determining whether the expected network performance parameters ar violated may further comprise monitoring actual performance of the radio access network and compare the actual performance parameters of the radio access network against the expected network performance parameters stored in the traffic manager; and generating need-to-offioad notification when at least one of the expected network performance parameters is violated, the nccd-to-offload notification corresponds to the violated network performance parameter and is associated with a code. 11 may further comprise performing data traffic offloading according to an offload procedure associated with the code of Llie need-to- offload notification, upon deciding which specific data traffic type suitable to offload to Hie identified available alternative radio networks.

in a further embodiment, the method may also comprise checking quality of the connection of the client device to the network through the radio access network and i f the quality of the connection is low. generating nccd-tn-offload notification and performing offloading if any alternative radio network is identified. Yet, it may further comprise checking total load of the radio access network, and if the total load exceeds a pre-defined value, generating need-to-offload notification and perfonning offloading if any alternative radio network is identified.

In yet a further embodiment, the radio access network may include further active client devices and when the expected network performance parameters of each cl ient devices arc violated, decide whether all the active client devices needs to be instructed to identify available alternative radio networks suitable for offloading, it is possible to also include a step of ranking the active client devices in priority and instructing the active client devices which are in high priority to perform offloading.

In another aspect of the present invention, there is also provided a system for data traffic offloading to an alternative radio access network among a plurality of available alternative radio access networks for use by a client device connected to a network through a radio access network, the client device having a plurality of data traffic types. The system may comprise a traffic manager residing at the network end. the traffic manager storing radio access network performance parameters expected by the client device a client .manager, which is operable to communicate with the traffic manager, (he client manager residing at the client device, Ihe clienl manager having a radio scanner controller, which in response to violation of the radio access network performance parameters, is operable for scanning available alternative networks and comnumicating the available alternative networks information to the traffic manager; a traffic switching module, which upon decision by the traffic manager on which specific data traffic type suitable to offload to the identified available alteraative radio networks, is operable for offloading the specific data traffic type to the suitable identified alternative radio networks.

In one embodiment, the radio access network performance parameters stored in the traffic manager include client linli quality, traffic type and corresponding client quality of experience, traffic type and corresponding quality uf service, core network connectivity, and respective radio access networks load condition.

Brief Description uf the Drawings

This invention will be described by way of non-limiting embodiments of the present invention, with reference to the accompanying drawings, in which:

Fig. 1 illustrates a communication system in which various embodiments of the present invention can be implemented;

Fig. 1A illustrates a schematic diagram of client devices according to one exemplary embodiment of the present invention;

Fig. 2 illustrates a system for data traffic offloading in accordance with one embodiment of the present invention;

Fig. 3 illustrates a schematic diagram of a Traffic Offloading Manager (TOM) in accordance with one embodiment of the present invention:

Fig. 3 A illustrates an exemplary table of client devices database; Fig. 3B illustrates an exemplary table of radio access network information stored in radio access networks database;

Fig. 4 illustrates a schematic diagram of a client traffic manager (CM) according to one embodiment of the present invention;

Fig. 5 illusti atcs a diagram of a corrununication sysictn in which the system of

Fig. 2 is deployed;

Fig. (5 illustrates a flow diagram of deployment of the system of Fig. 2 to offload data traffic in the communication system in accordance with one embodiment of the present invention;

Fig. 7 illustrates a flow diagram of generating need-to-ofJtload (NTO) notification performed in Fig. 6;

Fig. 7A illustrates a table depicting possible SLS parameters violation condition;

Fig. 8 illustrates a flow diagram of processing NTO notification performed in Fig, 6;

Fig. 9 illustrates a flow diagram of the identifying target RAN performed in Fig.

6:

Fig. 10 illustrates a flow diagram of the CM performing offload according to the offloading instructions, which is performed in l' ig.6; and

Fig. I I illustrates a communication flow diagram of the TOM and the CM in accordance with one embodiment of the present invention

Detailed Description The following descriptions of a number of specific and alternative embodiments are provided lo unders and Lhe inventive features of the presen invention. It shall be apparent to one slcillcd in the art, however that this invention may be practiced without such specific details. Some of the details may not be described in lengdi so as to not obscure the invention. For ease of reference, common reference numerals will be used throughout the figures when referring to same or similar features common to the figures.

The present invention provides a method and system for data traffic offloading. Fig. 1 illustrates a communication system 100 in which various embodiments of the present invention can be implemented. The communication system 100 comprises plurality of client devices 101 A. 101 B, and 101C, each of which may hold multiple radio interfaces for communicating with a core network 102. The communication is provided by Radio Access Networks (RANs) 103Λ, 103B, 103C, 103D, and 103E.

Each of the RANs 103Λ, 103B, 103G, 1 3D, and 103E includes at least a base station 1031 or a plurality of access points (Ars) 1032, 033, 1034, and 1035. The base station 1031 or the APs 1032, 1033, 1034, and 1035 may employ one or more radio technologies, such as, but not limited to. General Packet Radio Services (GPRS), Universal Mobile Telecommunications System (UMTS), Enhanced Data rates for GSM Evolution (EDGE), ΓΕΕΕ 802.16 such as Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE), IEEE 802.1 1 .such as WiFi®, etc. Different base station or different APs can employ different radio technologies. The radio coverage of one base point or AP often overlaps with one another.

Still referring to Fig. 1, the radio interfaces of the client devices 101A, 101B, and 101O similarly may also be configured to employ any type of radio access technologies of GPRS, UMTS, EDGE, WiMAX, l.TR, WiFi® ur the like. Di fTerent radio interfaces residing in one single client device may have alike or different radio technology, i'or example, a client device 101Λ comprises three radio interfaces, i.e., one Wi^'Fi interface, one WiMAX interface, and one LTE interface, while a client device 101 comprises four radio interfaces, i.e., two iFi interfaces, one WiMAX interface, and one LTE interface. Fig. 1 A illustrates a schematic diagram of the client device 101.Λ and the client device 101 B.

Due to the explosion of data traffic, it is sometimes desirable to offload data traffic to an alternative radio access network, in a typical example, when a smart phone having interfaces of GPRS and WiFi falls within a WiFi coverage area, the smart phone simply offloads its traffic from GPRS to WiFi by default. However, even the offloadi ng process between one radio access network to another radio access network is successfully carried out. such simplistic solution may not often be efficient due to some weaknesses, such as:

• The offloading process does not consider link quality of the radio access network that the target radio access network may actually offer worse link quality than the original network;

• The o floading process is agnostic of types of traffic and Quality of Service (QoS) that the target radio access network may not be able to support the level of QoS required by some specific types of traffic;

• The offloading process is ignorant on load condition of the target radio access network, wherein the target radio access network often is often already heavily traffic-loaded that the user indeed experiences worse service after offioadine: and • The offloading process is agnostic of end user experiences as certain types of traffic do perform well and give belter user experiences under specific types of radio access networks wherein the experiences vary across different networks.

Accordingly, it is desired that data traffic offloading in. deciding which alternative RAN is optimal to offload to should lake into account of network- performance parameters.

According to the present invention, data traffic offloading can be a full or partial offloading. Full offloading occurs when all traffics within a client device is offloaded to another RAN entirely, while pailial offloading occurs when only selected traffics arc offloaded to another RAN, while some others remain at the original RAN. For example, when data traffic of a smart phone is being offloaded from LTE to WiFi, time-critical traffic such as voice data traffic is maintained at the original Τ,ΤΕ, while web or email traffic data can he offloaded to WiFi.

Fig. 2 illustrates a system for data traffic offloading 200 in accordance with one embodiment of the present invention. In this embodiment, the system 200 decides which RAN is the optimum offloading target based on a plurality of Service Level Specification (SLS) parameters. The SLS parameters comprise, hut no limited ro. client link quality, traffic type and corresponding client quality of experience (Qoii).. traffic type and corresponding quality of service (QoS). core network connectivity, and respective RANs load condition.

QoE is generally regarded as a measure of a client's experience with a service, or in other words, a measure of client's satisfaction. In this present invention, the service may refer to any network communication services, such as web browsing, phone and video call. QoE parameter values may be pre-defined by the network operators and/or end clients, and may he customized as desired. I'or example, for QoE of phone call, QoE parameter values for an excellent phone call quality is rated as '4*, while a poor phone call quality is rated as ^; . At present, Mean Opinion Score (MOS) is generally accepted as a means to measure voice QoE.

Still referring to Fig. 2, the system 200 comprises a traffic-offloading manager (TOM) 201 that resides at a core network end 202, and client connection manager (CM) 203 that resides on a client device 204. The TOM 201 operably communicates with the CM 203 to decide on behalf of the client device 204 which alternative RAN is the optimum offloading target.

In a communication system comprising plurality of client devices, the TOM 201 may be configured to communicate with plurality of CMs 203, each of which residing at each of the plurality of client devices.

Fig. 3 illustrates a schematic diagram of the TOM 201 in accordance with one embodiment of the present invention. The TOM 201 comprises an offload-processing sub-module 301 connected to a database 302. The database 302 comprises client devices database 303 and radio access networks database 304. The client devices 303 and radio access networks database 304 store ail information related to the core network at which the TOM 201 resides and client devices connected thereto, such as expected SLS parameters of client devices connected to the core network, link quality, traffic type present in the core network, load condition of the core network backhaul links, collective client QoE, core network connectivity status, etc. The QoE can be perceived based on the expected SLS parameters of the client devices. Each data traffic in the client devices associates with one specific expected SLS parameter. The information is required for making offloading decision. For example, when QoE of voice data traffic across RAN of Fig. 2 is low, it indicates that the RAN might be overloaded and/or not suitable to transmit voice data. Thus this particular data Iraffie needs to be offloaded to another RAN that can offer a belter QoE for (he same type of data traffic.

Fig. 3Λ illustrates an exemplaiy table of client devices database. The client devices database store information of per user per traffic activity. The client devices database stores information of expected SLS parameters of each client devices, such as Qoii of each traffic activity of each client devices. The client devices databa-se also slures active connections of each client devices and current l ink quality values associated with the connections.

Fig. 3B illustrates an exemplary table of RAN information stored in radio access networks database. The information includes type of the RAN, connectivity to core network, current traffic load, and average QoE for all data traffic types.

The database 302 further comprises service policy database 305. The sendee policy database 305 specifically stores certain parameters pre-defined as to trigger data traffic offload. The parameters may be defined and modified by operators of the core network.

The information stored in the database 302 enables the TOM 201 to monitor per client devices per RAN connection accordingly. This thus allows the TOM in yield optimum offloading decision.

Fig. 4 illustrates a. schematic diagram of the CM 203 residing in client device. The CM 203 comm nicates with the TOM 20t through a communication interface 40] . The communication interface 401 is connected to a TOM message broker 402. The TOM message broker 402 coordinates message exchanging between the TOM 201 and the CM 203.

The CM 203 further comprises a group of sub-modules 403 comprising a radio scanner controller 404 communicating with radio interfaces 405 of the client device, a traffic-switching module 406, a QoE monitor 407, and a policy database 408. The group 403 is contr lled by the TOM message broker 402.

The radio scanner controller 404 is configured to coordinate network-scanning process of the radio interfaces 405 actively or passively. The scanning process may vary according to number and types of radio interfaces 405 involved. During the scanning process, information on potential RANs available for offloading and backhaul link quality of the RANs is obtained. The information is communicated to the TOM 201.

The QoE monitor 407 is configured to observe quality of experience (QoE) of specific RANs and accordingly store the observation data. It also observes data traffic and QoE of various applications associated with the RANs. The QoE data is continuously communicated to the TOM 201 via the TOM message broker 402 and the communication interface 41)1. In a further embodiment, the end users may manually evaluate QoE of the RANs and specific traffics and applications associated therewith. With these configurations, TOM 201 is well informed on which R AN is specifically optimum to serve a certain type of data traffic and application,

The traffic-switching module 406 is configured to perform traffic offloading in the client device as instructed by the TOM 201. When there is a trigger to offload a certain traffic, the traffic switching module 406 is provided with information eeded to trigger the data traffic offload by the TOM 201, and thereafter, the traffic switching module 406 switches the dat traffic from one RAN to another RAN seamlessly. Upon switching, the QoE monitor 407 observes the QoE of the new RAN and communicates the observation to tbe TOM 201.

The policy database 408 comprises policies or rules set by network operator for both clients and RANs alike, static references such as threshold values, user preferences, network operator preferences, logical statements such as condition and action, and others. I^'he policy database allows uses and administrators to predefine preferences, which may varies from one to another. For example not every user have the same QoE preferences, some users might be able to tolerate slightly lower QoE in application A but require higher QoE in the other. Accordingly, such policy database 408 allows the traffic selections and offloading to be personalised and customized to achieve the optimal network selections.

Fig. 5 illustrates a diagram of a communication system 500 in which the system 200 is deployed. The communication system 500 comprises client devices 501A, 50113, and 501C, each of which having the CM resides therein. The client devices 501A, 501B, and 501 communicate with a core network 502 handled by a network operator, in this embodiment the TOM 201 resides in the core network, ^'i^'he client devices are registered with the TOM 201, thus establishing communication between the CM of the client devices and the TOM.

It is understood to a skilled person that the TOM 201 does not necessarily reside at the core network 502. in other embodiments, the TOM 201 may reside at any remote location as long as il is reachable by the CMs.

The communication between the client devices atid the core network is provided by Radio Access Networks (RANs) 503Λ, 503R, 503C. 503D, and 503K. The RAN 503A includes a base station 5031, while the RANs 503B, 503C, 503D, and 503E [3 include an access point (AFs) 5032, 5033, 5034, and 5035, respectively. In this embodiment, client device 501A falls within the coverage of 503J3 and 503 .

Fig. 6 illustrates a flow diagram of deployment of the system 200 to offload data traffic in the communication system 500 in accordance with one embodiment of the present invention. At step 602, the client devices are required k> register lo the TOM. Once registered, each of the client devices shall deploy with a CM. Expected SLS parameters of each client devices arc stored in the database in the TOM and arc retrievable through the respective CMs.

At step 604, the ΤΟΛ4 activates the monitoring function on each of client devices to monitor the cl ient devices and RANs associated therewith. At step 606, when at least one of the expected SLS parameters of the client devices is violated, the TOM generates a need-to-offkrad (NTO) notification.

At step 608, the TOM processes the NTO notification generated according to the violated SLS parameters. Based on the NTO notification, the TOM can identify the registered client devices that the violated SLS parameters belong lo. The TOM then selects client devices associated with the violated SLS to perform neighbourhood net ork scanning. At step 610, the TOM instructs the radio scanner controller in the CM of the selected client devices to perform network scanning to identify alternative RANs.

At step 611, it is determined whether an alternative RAN is identified. If no alternative RAN is identified, no offloading will be performed and the process terminates at step 18.

When an alternative RAN is identified, the CM feedbacks to the TOM. which will evaluate the identified RANs at step 612. The TOM then identifies, at step 613, which RAN is optimum for offloading and which specific data traffic is suitable lo be offloaded to the corresponding optimum RAN.

When the optimum target RAN and data traffic to be offloaded are identified, the TOM sends offload instructions at step 614, and upon receiving the instructions, the CM perforins traffic offloading according to offload instructions at step 616.

When no optimum target RAM target is identified, no offloading will be performed and the process terminates at step 618.

Fig. 7 illustrates a flow diagram of generating need-to-offload (NTO) notification performed at step 606 of Fig. 6 in accordance with an embodiment of the present invention. The NTO notification is generated when the expected SLS parameters are violated. Fig. 7A illustrates depicting non-exhaustive list of possible SLS parameters violation condition in accordance with one embodiment of the present invention. Each violation condition may he referenced with a code. Accordingly, the network operator may understand the condition that triggers the need to offload by referring to the code and subsequently take respective actions.

Referring to Fig. 7 and Fig. 7A, as the TOM is deployed, it checks whether the network connection for all RANs are in optimum condition at step 702. When one network connection is not i optimum condition, the TOM triggers an NTO notification with NTO reason code = 1 at step 703.

If the network connection is in optimum condition, the ΊΌΜ further checks whether total load of the RANs exceeds a prc-defincd threshold at step 704. When the total load exceeds the pre-defined threshold, the TOM triggers an NTO notification with NTO reason code ~ 2 at step 705. if the total load does not exceed the pre-defined threshold, the TOM then retrieves the client device's expected SLS parameters from the database at step 706. At step 707, the TOM compares current SLS parameter values against the expected SLS parameters. At step 708, it is determined whether the expected SLS parameters are violated. If (he SLS parameters are violated, the TOM triggers an NTO notification with NTO reason code - 3 at slep 709.

Further expected SLS parameters violation condition may be defined as to determi ne whether a NTO notification needs to be generated. For example, when an 'ir SLS violation condition is identified at step 710. an NTO notification -with NTO reason code = n is accordingly generated at step 7 1.

Fig. 8 illustrates a flow diagram of processing NTO notification performed a( step 608 of Fig. 6 in accordance with one embodiment of the present invention. At step 802, NTO notification trigger is received. If the NTO notification is accompanied by NTO reason code = 1 , the TOM selects all active clients belonging to the RAN to perform neighbourhood scan on selected radio inter aces at step 804. The TOM then sends the scan instruct ions to the CM at step 814.

If the NTO notification is accompanied by NTO reason code = 2, the TOM identifies a top percentile load, x, generating clients and requests them to perform neighbourhood scan on selected radio interfaces at step 806. Without any limitations, the lop percentile load, x. can be anything between 5-15%. Such value can be determined under the discretions uf the operator, Such optimal value can also be determined through experiments and tests. The TOM then sends the scan instructions to the CM at step 814. If the NTO notification is accompanied by NTO reason code = 3, the TOM ranks each client in priority based on type of traffics violated, number of violation and degree of violation and request a top percentile of Ihe ranked client;;, y, to perform neighbourhood scan on selected radio interfaces al step 80S. The TOM then sends the scan instructions to the CM al step 814. Without any limitations, the lop percentile of the ranked cl icnfe, y, may also be decided by the operator under his discretions.

If flic NTO notification is accompanied by NTO reason code - n, the TOM performs scanning procedure associated with NTO reason code - n, the TOM performs scanning procedure associated with NTO reason code - n at step 810 and sends the scan instructions to the CM at step 814.

If NTO notification is not accompanied by any NTO reason code, the TOM generates false NTO notification at step 816.

Fig. 9 illustrates a flow diagram of the identifying target RAN performed at step 611 of Fig. 6 in accordance with one embodiment of the present invention. At step 901, tlie TOM first filters out the identified RANs that are not under contOi of current network operator. If NTO with reason code - 1 is previously generated, the TOM prepares handover procedure by identifying target RANs based on scan result of each client devices at step .902. Tlie identified target RANs include (hose with lowest data traffic load and with data traffic load not larger than a pre-defined threshold load level. It is then determined at step 910 whether a target RAN is identified. When a target RAN is identified, the TOM accordingly prepares suitable offload instruction at step 912.

If NTO with reason code ^~- 2 is previously generated, i.e., a specific RAN is overloaded, (he TOM prepares inter-RAN load balancing procedure by identifying alternative RANs for each client for preemptive load distribution based on type of client's data traffic and existing load levels of the identified alternative RANs at step 904. It is then dctcmiincd at step 910 whether a target RAN is identified. When a target RAN is identified, the TOM accordingly prepares suitable offload instruction at step 912.

Tf NTO with reason eode= 3 is previously generated, the TOM prepares inter- RAN selective traffic reshuffling procedure at. step 906 by redistributing specific traffic type of each identified ciicnt based on priority level defined by type of traffics violated, number of violation and degree of violation. For each traffic type, it is preferable that the identified alternative RAN is tire one that can provide the highest QoE.

If TO with reason code = n is previously generated, the TOM evaluates the neighborhood RANs and execute procedure n at step 908 to identify alternative RAN and specific traffic type to offload to the alternative RAN. The TOM thereafter accordingly prepares suitable offload instruction at step 912.

Fig. 10 illustrates a flow diagram of the CM performing offload according to the offloading instructions, which is performed at step 616 of Fig.6 in accordance with one embodiment of the present invention. At step 1002, traffic offload instruction is received by (he CM. When the traffic offload instruction received is according to NTO with reason code - i , the offload Lo target RAN is performed using selected radio interfaces at step 1 04.

When the traffic offload instruction received is according to NTO with reason code ^ 2, the offload to target RAN is performed using selected radio interfaces at step 1004. When the traffic offload instruction received is according to NTO with reason code = 3, the selected radio interface is instructed to connect with target RAN, and the CM then offloads the selected traffic type to target RAN accordingly at step 1006.

When the traffic offload instruction received is according to NTO with reason code = n, a speci fic offload procedure associated with NTO reason code = n is executed by the CM at step 1008.

In another embodiment of the present invention, an exception -rule can be defined to interrupt or cease (i.e. remains with the current traffic) the traffic offloading when desire, it can be useful when clients are offloading from one RAN to another, in case when RAN or SLS violation reverts to the slate before NTO was triggered or generated during the traffic offloading, the exception rule can he triggered to cease the offloading of the remaining clients, even through a certain percentile of clients have been identified to be offloaded. For example, the TOM may have already scheduled to offload top ten load generating clients from existing RAN to another. However upon successfully offloaded five clients, the TOM discovers that RAN load falls below a load threshold, further offloading may no longer be not required.

Fig. 11 illustrates a communication flow diagram 1100 of the TOM and the CM in accordance with one embodiment of the present invention. The TOM generates need-to-offload notification when at least one expected SLS parameter of registered client devices is violated. The TOM then sends scan request to the CM of the registered client devices. The CM accordingly feedbacks to the TOM with a scan report, which includes link quality and total load of the RAN connected to the client device of the CM. The TOM then makes offload decision on behalf of client devices, and send the offload instruction to the CM. Upon receipt of offload instruction, the CM performs offloading as instructed. The TOM provides radio scan request u> the registered C s for polling radio Inad status on on-demand basis. In return, the CMs revert with radio scan report to the TOM. Alternatively, CMs may be configured to provide periodic update of the radio scan report automatically to TOM. It can be earned based on a predefined time interval.

In yet a further embodiment, the CMs may provide option to "onload" selected traffic, when desired. The traffic onload referred to traffic/client coming back to the subject RAN. The traffic onload procedure is substantially the same as traffic offload as every RAN treats other RAN as offload target upon offload conditions are fulfilled. in the context of this invention, other RANs thai receive traffic/client offloaded by subject RAN are experiencing onloading.

Existing infrastructure docs not requi re major upgrade or modification so as to adapt and implement the system and method of the present invention. In one embodiment, the system and method of the present invention are simply adapted into a software component accordingly placed at network and client devices end.

The above description illustrates various embodiments of the present invention along with examples of how aspects of the present invention may e implemented. While specific embodiments have been described and illustrated it is understood that many changes, modifications, variations and combinations thereof could be made to the present invention without departing from the scope of the present invention. The above examples, embodiments, instructions semantics, and drawings should not be deemed Lo be the only embodiments, and are presented to illustrate the flexibility and advantages of the present invention as defined by the following claims:

Claims

1 . Λ method for data traffic offloading to an alternative radio access network among a plural ity of available alternative radio access networks for use by a client, device connected to a network through a radio access network, the client device having a plurality of data traffic types, comprising:

registering Ihe client device to a traffic manager residing at the network end, storing in the traffic manager the radio access network performance parameters as expected by each data traffic in the client device;

detemiining whether the expected network performance parameters arc violated; and

when the expected network performance parameters arc violated, the traffic manager instructing the client device to identify available alternative radio networks, and upon identi fication, the traffic manager deciding on behalf of the client device which specific data traffic type suitable to offload to the identified available alternative radio networks.

2. The method according to claim 1 , wherein the radio access network performance parameters include client link quality, traffic type and corresponding client quality of experience, traffic type and corresponding quality of service, core network connectivity, and respective radio access networks load condition.

3. The method according to claim 1 , wherein the determining whether the expected network performance parameters arc violated further comprises:

monitoring- actual performance of the radio access network and compare the actual performance parameters of the radio access network against the expected network performance parameters .stored in the Iraffic manager; and generating need-to-offl ad notification when at least one of trie expected network performance parameters is violated, the need-to-offioad notification corresponds lo the violated network performance parameler and is associated with a code.

4. The method according to claim 3, further comprises performing data traffic offloading according to an offload procedure associated with the code of the need-to- oflload notification, upon deciding which specific data !raffic type suilabJe to offload lo the identified available alternative radio networks,

5. The method according to claim 1 , further comprises checking quality of the connection of the client device to the network througli the radio access network and if the quality of the connection is low, generating necd-to-oftload notification and performing offloading if any alternative radio network is identified.

6. The method according to claim 1 , further comprises checking total load of the radio access network, and if the total load exceeds a pre-defined value, generating need- to-oifload notification and performing offloading if any alternative radio network is identified.

7. The method according to claim 1, wherein the radio access network includes further active client devices and when the expected network performance parameters of each ciient devices are violated, decide whether all the active client devices needs lo be instructed to identify available alternative radio networks suitable for offloading.

8. The method according to claim 7, further comprises ranki g the active client devices in priority and instructing the active client devices which arc in high priority to perform offloading.

9. Λ system for data traffic offloading to an alternative radio access network, among a plurality of available alternative radio access networks for use by a client device connected to a network througli a radio access network, the client device having a plurality of data traffic types, comprising:

a traffic manager residing al the nelwork end, (he traffic manager storing radio access nelwork performance parameters expected by the client device;

a client manager, which is operable to communicate with the traffic manager, the client manager residing at the client device, the client manager having

a radio seamier controller, which in response to violation of the radio access network performance parameters, is operable for scanning available alternative networks and communicating the available alternative networks information to the traffic manager;

a traffic switching module, which upon decision by the traffic manager on which specific data traffic type suitable to offload to the identified available alternative radio networks, is operable for offloading the specific data traffic type to the suitable identified alternative radio networks.

10, The system according to claim 1, wherein the radio access network performance parameters stored in the traffic manager include client link quality, traffic type and corresponding client quality of experience, traffic type and corresponding quality of service, core network connectivity, and respective radio access networks load condition.