Communication controller and method for transmitting data

A communication controller is described comprising a determiner configured to determine, for each communication connection of a set of communication connections between a communication device and another communication device, a characteristic of the communication connection, a selector configured to select a plurality of the communication connections based on the characteristics of the communication connections and a controller configured to control a transmission of data between the communication device and the other communication device to use the selected plurality of communication connections.

TECHNICAL FIELD

The present disclosure relates to communication controllers and methods for transmitting data.

BACKGROUND

Future mobile communication terminals such as smartphones can be expected to be able to operate communication links according to different radio access technologies (RATs) at the same time, e.g. a communication link based on WiFi in parallel to a communication link based on LTE. Efficient approaches to make use of such parallel communication links are desirable.

SUMMARY

A communication controller is provided including a determiner configured to determine, for each communication connection of a set of communication connections between a communication device and another communication device, a characteristic of the communication connection, a selector configured to select a plurality of the communication connections based on the characteristics of the communication connections and a controller configured to control a transmission of data between the communication device and the other communication device to use the selected plurality of communication connections.

Further, a method for transmitting data according to the above communication controller is provided.

DESCRIPTION

The following detailed description refers to the accompanying drawings that show, by way of illustration, specific details and aspects of this disclosure in which the invention may be practiced. These aspects of this disclosure are described in sufficient detail to enable those skilled in the art to practice the invention. Other aspects of this disclosure may be utilized and structural, logical, and electrical changes may be made without departing from the scope of the invention. The various aspects of this disclosure are not necessarily mutually exclusive, as some aspects of this disclosure can be combined with one or more other aspects of this disclosure to form new aspects.

It can be expected that future mobile devices (e.g. mobile terminals such as smartphones) will operate a multitude of heterogeneous Radio Access Technologies (RATs) simultaneously, such as WiFi, 3GPP LTE (3rd Generation Partnership Project Long Term Evolution), TV White Space Communication (IEEE 802.11af), Bluetooth, Digital Radio, GPS (Global Positioning System), etc. In order to obtain the best Quality of Service (QoS) possible for the user of a mobile device, it can be expected that a mobile device may jointly and simultaneously use a number of distinct heterogeneous RATs, which leads to an aggregation of all radio resources available to a user.

The simultaneous usage of multiple routes in a network is referred to as multipath routing. The efficient exploitation of multiple routes by applying a coding scheme tailored to the presence of multiple routes is referred to as network coding. These approaches typically apply to fixed, cabled networks.

Simultaneous usage of multiple links in a wireless mobile device may for example be applied in the following contexts:Simultaneous operation of two independent services, e.g. a voice call is operated via 3GPP UMTS (Universal Mobile Telecommunications System) while a Bluetooth connection is active to a Bluetooth headset ensuring a wireless link to the mobile device;Simultaneous operation of two distinct RATs for Vertical Handover, e.g. 2G (second generation) and HS×PA (Highspeed Uplink/Downlink Packet Access) are operated simultaneously during a handover phase from 2G to HS×PA in order to ensure service continuity for the mobile device user.IFOM (IP Flow Mobility): Simultaneous connection via WLAN (Wireless Local Area Network) and 3G (Third Generation) and switching IP (Internet Protocol) flows between these two RATs. This for example involvesSeamless mobility of IP flows between 3G and WLAN by using Mobile IP (DSMIPv6)Network support to find a usable non-3GPP access network (e.g. providing Discovery Information), e.g. based on parameters such as Network-IDs (SSID, TAC, . . . ), Location of AP (Access Point), Coverage-Radius, . . . .Operator controlled RAT preferences (ISRP), e.g. to determine which of currently connected access networks should be used for a certain service/IP flow, e.g. based on IP-Address and port number or based on selected Service (APN)

3GPP technologies such as IFOM provide a technological basis for the specific case of maintaining WiFi and 3GPP simultaneously and for managing corresponding handovers.

Further, it may for example be supported that a number of heterogeneous RATs are jointly used for accessing a single service, such as video streaming, etc. The principle is illustrated inFIG. 1.

In the first communication system101, which may be seen as the conventional or legacy approach, a mobile device access an IP network (such as the Internet or a private IP sub-net)103via a single radio link104and requests and receives data from a server105connected to the IP network103.

In the second communication system102, which may be seen as a multicomm multi-link or multi-RAT approach, a mobile device106has a plurality of radio links107to a plurality of IP networks108and requests and receives data from a server109jointly via the radio links107. The radio links107for example correspond to different communication connections, e.g. different IP connections.

A challenge for a multicomm multi-link multi-RAT approach may be seen in how to efficiently split data transmission of a single service (e.g. video streaming) over a multitude of RATs being operated simultaneously. This may for example involve techniques for:Efficiently selecting the RAT combination at the time upon demand, e.g., at the connection set-up and splitting the decision making process over network/target and mobile device entities.Efficiently triggering/performing a multi-RAT handover in case that the context of the mobile device106changes (e.g. the mobile device moves and loses coverage of WiFi or similar) and splitting the decision making process over network/server and mobile device entities.

A communication controller200that may be used to provide a multicomm multi-link/multi-RAT communication is described in the following with reference toFIG. 2.

The communication controller200includes a determiner201configured to determine, for each communication connection of a set of communication connections between a communication device and another communication device, a characteristic of the communication connection.

The communication controller200further includes a selector202configured to select a plurality of the communication connections (i.e. two or more communication connections) based on the characteristics of the communication connections.

Further, the communication controller200includes a controller (e.g. a signaling circuit or a processing circuit)203configured to control a transmission of data between the communication device and the other communication device to use the selected plurality of communication connections.

In other words, a communication controller (which may be located on the terminal side or to the network side) selects a plurality of communication connections to be used (e.g. for a multicomm multi-link/multi RAT approach) based on characteristics of the communication connections. Using the selected plurality of communication connections may be understood as using all of the communciation connection of the plurality of communication connections for data transportation, e.g. over each of the communication connections, a part of the data to be transmitted in the data communication is transmitted. For example, this may mean that the communication connections are not merely active but are used for actual data transmission.

For example, in contrast to a multi-link solution such as IP Flow Mobility (IFOM) in 3GPP or a fixed split of a single video transmission over two different RATs the communication controller considers how to efficiently split a single service over a multitude of simultaneously operated wireless links, e.g. combined with a dynamic adaptation of the selected technologies. The approach in context withFIG. 2can thus for example be used on top of IFOM.

The determination and selection may for example be done based on information by the user of the communication terminal. A user of a communication terminal may for example provideA set of IP addresses to be used simultaneously for the provision of at least one service. For example, a user can provide a number of IP addresses among which the network (SRV) side selects the most appropriate ones for the multi-RAT provision of a concerned service.A list of ports which may be used in order to differentiate between the various streams that need to be finally aggregated to a single service in the target device (i.e. the communication terminal).Policies indicating preferred usage of specific RATs and the preferred combination of RATs being operated simultaneously.Mobility context information which may be exploited for efficient RAT selection, e.g. in case of a high mobility scenario no short range RAT (such as Bluetooth, WLAN, etc.) is used but rather a wide area RAT (such as 3G, etc.).

For each communication connection of the set of communication connections, the characteristic is for example a priority of the communication connection.

For each communication connection of the set of communication connections, the characteristic is for example based on at least one of a transmission quality via the communication connection, a bandwidth of the communication connection, a reliability of the communication connection and a cost of data transmission via the communication connection.

The communication controller may further include a transmitter configured to transmit an indication of the selected communication connections to the communication device, the other communication device or both. The transmitter may for example be the transmitter of a communication device of which the communication controller is part.

The communication controller may be part of the communication device, of the other communication device or of a separate device (e.g. network component).

The communication device is for example a communication terminal and the other communication device is for example a component of the network side of a communication system (e.g. a server).

For example, the communication device is a subscriber terminal of a cellular radio communication network.

For example, the other communication device is a network component of a cellular radio communication network.

For example, a network component provides a connection selection policy (i.e. rules to be considered for the decision making, i.e. the selection) and the mobile terminal (i.e. the communication terminal), including the communication controller in this example, selects the connections to be used subject to the policy, e.g. with the objective to maximize its own objectives. In this case, for example, the server side delivers the stream on the RATs imposed by the mobile device.

As another example, the communication terminal may communicate preferences (priorities) for the communication connections and the network side (or server side), comprising the communication controller in this example, for example decides based on these preferences.

In a communication arrangement comprising a mobile device, a network (infrastructure) component and a service server (which can be part of the network infrastructure but can also be an independent server such as a Youtube server, etc.), the communication controller selecting the communication connections may for example be located in the mobile device and select the communication connections subject to a network (and possibly server) policy, in the network component (and possibly select the communication connections subject to mobile device priorities and/or server priorities and/or a server policy) or on the server side and select the communication connections subject to mobile device priorities and/or a network policy.

It should be noted that the terminal may decide (i.e. the communication controller may be part of the communication terminal) also in case that the communication connections are provided (at least partially) by multiple operators. If the decision is performed on the network side, it may be desirable that all communication connections are offered by the same operator, which may be restrictive. For performing the decision on the (content) server side the server needs to know, e.g., IPs, ports, the network status, policies and various other things which might be wished to be kept confidential between the operator and the client device (i.e. the mobile terminal).

The communication controller may for example include a receiver configured to receive, for each communication connection, an indication of the characteristic of the communication connection.

The communication connections are for example network layer connections.

For example, the communication connections are IP connections.

The transmission of data is for example transmission of a file.

For example, the controller is configured to initiate splitting of the file in a part for each communication connection of the selected communication connections and control the transmission to transmit the part over the communication connection.

The controller is for example configured to initiate the splitting of the file at the network layer.

The communication connections of the set of communication connections are for example based on different radio access technologies.

In other words, the communication controller may select from various radio technologies like WiFi, WiFi for TVWS (IEEE 802.11af), etc. The communication controller may further include a receiver configured to receive an indication of the set of communication connections.

The components of the communication controller (e.g. the determiner, the selector and the controller and the controller) as well as the various entities described below may for example be implemented by one or more circuits. A “circuit” may be understood as any kind of a logic implementing entity, which may be special purpose circuitry or a processor executing software stored in a memory, firmware, or any combination thereof. Thus a “circuit” may be a hard-wired logic circuit or a programmable logic circuit such as a programmable processor, e.g. a microprocessor (e.g. a Complex Instruction Set Computer (CISC) processor or a Reduced Instruction Set Computer (RISC) processor). A “circuit” may also be a processor executing software, e.g. any kind of computer program, e.g. a computer program using a virtual machine code such as e.g. Java. Any other kind of implementation of the respective functions which will be described in more detail below may also be understood as a “circuit”.

The communication controller200for example carries out a method as illustrated inFIG. 3.

The flow diagram300illustrates a method for transmitting data, for example carried out by a communication controller.

In301, the communication controller determines, for each communication connection of a set of communication connections between a communication device and another communication device, a characteristic of the communication connection.

In302, the communication controller selects a plurality of the communication connections based on the characteristics of the communication connections.

In303the communication controller controls a data transmission between the communication device and the other communication device to use the selected plurality of communication connections.

It should be noted that examples given in context of the communication controller200are analogously valid for the method illustrated inFIG. 3and vice versa.

The examples described in the following may provide the following in context of the multicomm multi-link or multi-RAT approach as illustrated by the second communication system102.A guided mobile device centric decision making entity for multi-RAT connection set-up and multi-RAT Handover.A server centric decision making entity for multi-RAT connection set-up and multi-RAT Handover.Approaches to let the client (i.e. the mobile device) learn about the available pieces that are transmitted by a multitude of RATs, which ports to use etc.An approach to handle private IP sub-nets as they are often used by cellular operators, i.e. mobile devices usually do not have a public IP address but only IP addresses of a private IP sub-net.

In the following, examples for a multicomm multi-link or multi-RAT as illustrated by the second communication system102are described.

The decision making mechanisms for the efficient selection of the multi-RAT radio links107to be operated simultaneously can for example be either done within the concerned mobile device106or in the server109or another network component providing the concerned service (e.g. video streaming) These approaches are described in the following.

Mobile Device Centric Decision Making for Selected a Multitude of Heterogeneous RATs to be Operated Simultaneously for Accessing a Single Service

In the case of mobile device centric decision making, a multi-link management entity is for example introduced on the network/server side which serves for interactions with the concerned mobile device106. This is illustrated inFIG. 4.

The communication arrangement400includes IP networks401for example corresponding to the IP networks108, a server402for example corresponding to the server109and a multi-link management entity403.

The multi-link management entity403provides a first sub-entity404for information provision on available multi-link configurations, a second sub-entity402for information provision on supported IP sub-nets and a third sub-entity403for buffering predefined mobile device configurations, e.g. to be changed via triggers.

The exclusion of a configuration can also be enforced for cost reasons. The notion of cost is dynamic, for example if the user pays a monthly subscription for sending and receiving a fixed amount of data and while there are only two days remaining he has not used the service at all, the cost will be considered almost zero.

The interactions of the mobile device106with the multi-RAT management entity103and the functionalities of the sub-entities404,405,406are described in the following.

Sub-entity404for Information provision on available multi-link configurations: For example, for using a service via multiple radio links107(or more generally multiple communication links) the mobile device106initially contacts the first sub-entity404for Information provision on available multi-link configurations. The first sub-entity404for example gives (e.g. technology-independent) information on the available multi-link configurations possible. The first sub-entity404for example feeds back information to the mobile device106indicating how many independent links can be operated for the concerned service. Also, information on the related user experience is for example given in case that the QoS (Quality of Service) of one of the links107is degraded.

For example, the mobile device106requests a video streaming service. The video service is able to provide i) the full video stream over a single communication link, ii) a base video stream including audio over one communication link and an incremental redundancy stream over a second communication link and iii) the base video stream over one communication link, an incremental redundancy stream over a second communication link and audio over a third communication link. In such a case, the first sub-entity404for example provides the information as shown in table 1a about the possible communication links.

TABLE 1aInformation provided by the sub-entity for informationprovision on available multi-link configurationsConfiguration 1:All video and audio data is transportedOne singleover a single link. If the link fails, thecommunicationvideo/audio stream stops.linkConfiguration 2:Video (base stream) and audio data isTwotransported over one link, incrementalcommunicationredundancy video data is transported over alinks operatedsecond link. If the second link breaks, thesimultaneouslyuser suffers a reduction in QoS, but theVideo is not interrupted. If the first linkfails, the video/audio stream stops.Configuration 3:Video (base stream) is transported over oneThreelink, incremental redundancy Video data iscommunicationtransported over a second link and audiolinks operateddata is transported over a third link.simultaneously

This information may be used by the mobile device106in order to efficiently split the video stream over available radio access technologies. In the example of “configuration 2” in table 2, the mobile device106for example uses a robust link for the video (base stream) and the audio data, such as a 3GPP LTE radio link or similar. The incremental redundancy stream may be transported via a high-throughput but less reliable communication link, e.g. a WLAN radio link. In case that the WLAN link breaks, the user will still be able to enjoy the video/audio stream, however at a lower QoS.

Another example is the following: The mobile device106starts a Web Browsing service. Usually there is a setting in the device's browser that disables the automatic download of images and other bandwidth consuming objects (“heavy” objects) in the web page, not only for speeding up the browsing process, but for cost reasons as well. Instead of this, the web browsing service is able to provide i) The full web page data through a single link, with or without the “heavy” objects ii) The pure text of the web page is transported on one link and any contained “heavy” objects are transported over a second link and iii) The pure text of the web page is transported on one link, any contained “heavy” objects with size up to a predefined threshold are transported over a second link and any contained “heavy” objects with size above the predefined threshold are transported over a third link. In such a case, the information provided by the first sub-entity404is for example as indicated in table 1b.

TABLE 1bInformation provided by the sub-entity for informationprovision on available multi-link configurationsConfiguration 1:All web page data is transported over aOne single linksingle link. If the link fails, the webbrowsing stops.Configuration 2:The pure text of the web page isTwo linkstransported over one link, any containedoperated“heavy” objects are transported over asimultaneouslysecond link. If the second link breaks, theUser suffers a reduction in his experience,but the browsing service is not interrupted.If the first link fails, the web browsingstops.Configuration 3:The pure text of the web page isThree linkstransported over one link, any containedoperated“heavy” objects with size up to asimultaneouslypredefined threshold are transported over asecond link, any contained “heavy” objectswith size above the predefined thresholdare transported over a third link.

Again, this information may be used by the concerned mobile device106in order to efficiently receive the various files over available Radio Access Technologies. In the example of “Configuration 2”, the mobile device uses a very robust link for the core web page data, such as 3GPP LTE or similar. The images, flash animations or any other bandwidth consuming objects that are also part of the web page may be transported via a high-throughput but less reliable link, e.g. WLAN. In case that the WLAN link breaks, the User will still be able to continue browsing, however at a lower level of experience, due to the missing data or the need to explicitly request it over the first link.

A third example is the following: The mobile device106is running in the background a service like an e-mail client, a service that does not require real time communication or immediate user interaction. The service is able to provide i) The full data through a single link ii) The headers and the pure text body of the e-mails are transported on one link and any attached files are transported over a second link and iii) The headers and the pure text body of the e-mails are transported on one link, any attached files with size up to a predefined threshold are transported over a second link and any attached files with size above the predefined threshold are transported over a third link. In such a case, the information provided by the first sub-entity404is for example as indicated in table 1c.

TABLE 1cInformation provided by the sub-entity for informationprovision on available multi-link configurationsConfiguration 1:All e-mail data is transported over a singleOne single linklink. If the link fails, the e-mail downloadstops.Configuration 2:The headers and the pure text body of theTwo linkse-mails are transported over one link, anyoperatedattached files are transported over a secondsimultaneouslylink. If the second link breaks, the Usersuffers a reduction in his experience, butthe e-mail service is not interrupted. If thefirst link fails, the e-mail download stops.Configuration 3:The headers and the pure text body of theThree linkse-mails are transported over one link, anyoperatedattached files with size up to a predefinedsimultaneouslythreshold are transported over a secondlink, any attached files with size above thepredefined threshold are transported over athird link.

Again, this information may be used by the concerned mobile device106in order to efficiently receive the various files over available Radio Access Technologies. In the example of “Configuration 2”, the mobile device106uses a very robust link for the body of the e-mail data, such as 3GPP LTE or similar. The attachments may be transported via a high-throughput but less reliable link, e.g. WLAN. In case that the WLAN link breaks, the User will still be able to be informed about his e-mails, however at a lower level of experience, since he will not be able to access any attachments.

For an efficient communication of the information of table 1 from the multi-management link entity403to the mobile device106(i.e. with low-signaling overhead) the multi-management link entity403may for example only send link priorities to the mobile device106. For example, the priorities as given in table 2 are provided.

TABLE 2Efficient encoding of information providedby the first sub-entity 404Configuration 1:Link Priority: 1One singleComment: All video and audio data iscommunicationtransported over a single link. If the linklinkfails, the video/audio stream stops.Configuration 2:Link Priority, Link 1: 1TwoLink Priority, Link 2: 2communicationComment: Video (base stream) and audiolinks operateddata is transported over one link,simultaneouslyincremental redundancy video data istransported over a second link. If thesecond link breaks, the user suffers areduction in QoS, but the video is notinterrupted. If the first link fails, thevideo/audio stream stops.Configuration 3:Link Priority, Link 1: 2ThreeLink Priority, Link 2: 3communicationLink Priority, Link 3: 1links operatedComment: video (base stream) issimultaneouslytransported over one link, incrementalredundancy video data is transported over asecond link and audio data is transportedover a third link.

In the example of configuration 3, the audio stream is for example considered to be the stream requiring the highest protection level since even in case that the video stream fails, the user will be able to enjoy Audio only. Therefore, the fact that the third radio link has the highest priority in this example indicates that audio would be transmitted over link 3 according to configuration 3. Similarly, the information about the link priorities indicates that the incremental redundancy video data (being the least important) would be transmitted over link 2 and that the video base layer would be transmitted over link 1 according to configuration 3.

Sub-entity405for information provision on supported IP sub-nets: Many cellular operators do not provide public IP addresses to mobile devices. A mobile device may be part of a private IP sub-net within the operator network. Such a configuration typically allows for a “pull” type of information flow (i.e. the mobile device requests information from a distant server), but not for a “push” type of information flow (i.e. a device external to the IP sub-net cannot directly address the concerned mobile device since the sub-net IP address of the mobile device is not available to external entities).

The second sub-entity405may for example provide a service to allow streaming services into such a private IP sub-net as it is illustrated inFIG. 5.

The communication arrangement includes the Internet501and a private IP sub-net (e.g. a sub-net of an operator of a radio communication network providing one of the radio links107)502. The Internet501and the private IP sub-net502for example correspond to the IP networks108, wherein in this example the mobile device106accesses the Internet501via the private IP sub-net502. The communication arrangement500further includes a server503connected to the Internet for example corresponding to the server109and the server402. The private IP sub-net502is connected to the Internet501via a gateway504which may be accessed by a public IP address from the Internet side.

The communication arrangement includes a service for accessing the private sub-net502.

This service eliminates the need for using protocols like STUN (Session Traversal Utilities for NAT), since the operator is fully aware of the applied network settings. Instead of communicating with a public STUN server in order to determine its external IP and port, the mobile device106may inform this “Operator Service” (i.e. a corresponding entity providing this service such as the gateway504) that it needs to receive an incoming data stream from an external device, providing specific details on the IP and the port of that device, as well as its own port where it expects the communication. If the entity providing the “Operator Service” accepts the mobile device's request, it sends back information on the public IP and port that have to be reported to the external device to establish the communication and makes the necessary arrangements to the network routing and protection service. Then the mobile device requests the data stream from the external device (i.e. the server503in this example) and when the incoming stream arrives it is recognized and it is routed (e.g. by the gateway504) to the correct internal IP and port, namely the one of the mobile device.

It should be noted that radio network operators typically do not use a single private IP sub-net but multiple ones. This means that two mobile devices connecting via 3GPP UMTS/LTE/etc. are not necessarily in the same private IP sub-net, but most likely in independent ones. In such a case, the mobile devices can not directly route traffic from one to another.

The gateway504provides a service for accessing the private sub-net502. The mobile device106for example communicates with the second sub-entity405in the context of the operator service provide by the gateway504as follows.

In601, the mobile device106contacts the second sub-entity405. The mobile device provides an indication on the target geographic area where it wants to use the service provided by the server503(e.g., Germany, US, etc.) and/or a selection of the relevant operator (e.g., T-Mobile Germany, Vodaphone Germany, etc.) providing communication links in the target geographic area.

In602, The second sub-entity404provides a list of supported operators which provide services for routing into their private IP sub-nets or which provide open access (e.g., via public IP addresses granted to each mobile device). If required, the second sub-entity404communicates the information required by the operator service (e.g. required by the gateway504) in order to access the concerned private IP sub-nets (e.g., a mobile device ID, the sub-net IP address of the concerned IP address, etc.).

In603, the mobile device106provides the sub-entity “Information provision on supported IP sub-nets” with the required information for accessing the private IP sub-nets maintained by the concerned operator (e.g. the IP sub-net502). If the mobile device106chooses not to provide the required access parameters for all/some operators, the corresponding sub-net cannot be accessed and the corresponding link(s) (i.e. the communication links using this sub-net) cannot be used.

The third sub-entity406stores a plurality of pre-defined configurations for transmitting data to the mobile device106.

For example, the mobile device106indicates a number of sets of IP addresses (or details on private IP sub-nets if required) to the third sub-entity406which may be used for the service provided by the server109, e.g. to transmit data to the mobile device106. In other words, a pre-defined configuration may correspond to a set of IP addresses of the mobile device106corresponding to IP connections to be used for transmitting data to the mobile device106according to this configuration.

In case that a handover needs to be performed the following may be carried out:The mobile device106triggers to change to another one of the pre-defined configurations orThe network/server (i.e. the server109or another, e.g. intermediate, network component handling data transmission to the mobile device106) is allowed to autonomously select one of the pre-defined configurations.In case that no trigger from the mobile device106arrives at the network component/server within a given time-frame, the network component/server is allowed to autonomously select one of the pre-defined configurations.

As an example corresponding to the example of table 2, the pre-defined sets of IP addresses provided by the mobile device106is for example communicated in a format as by table 3.

TABLE 3Example of pre-defined sets of links provided by the mobile deviceConfiguration 1:Predefined link set 1: IP address “IP-A1”One single link(within a private sub-net of Operator“xyz”, corresponds for example to 3GPPLTE)Predefined link set 2: IP address “IP-A2”(public IP address, corresponds forexample to WLAN)Predefined link set 3: IP address “IP-A3”(public IP address, corresponds forexample to IEEE 802.11af, i.e. WIFI forTVWS)Comment: All video and audio data istransported over a single link. If the linkfails, the video/audio stream stops.Configuration 2:Predefined link set 1: IP address “IP-B1”Two linksfor Link 1 (within a private sub-net ofoperatedOperator “xyz”, corresponds for examplesimultaneouslyto 3GPP LTE), IP address “IP-B2” forLink 2 (corresponds for example toWLAN),Predefined link set 1: IP address “IP-B3”for Link 1 (within a private sub-net ofOperator “xyz”, corresponds for exampleto 3GPP LTE), IP address “IP-B4” forLink 2 (corresponds for example to IEEE802.11af, i.e. WiFi for TVWS)Comment: Video (base stream) and audiodata is transported over one link,incremental redundancy video data istransported over a second link. If thesecond link breaks, the user suffers areduction in QoS, but the video is notinterrupted. If the first link fails, thevideo/audio stream stops.Configuration 3:Predefined link set 1: IP address “IP-C1”Three linksfor Link 3 (within a private sub-net ofoperatedOperator “xyz”, corresponds for examplesimultaneouslyto 3GPP LTE), IP address “IP-C2” forLink 1 (corresponds for example toWLAN), “IP-C3” for Link 2 (correspondsfor example to IEEE 802.11af, i.e. WiFi forTVWS)Comment: Video (base stream) istransported over one link, incrementalredundancy video data is transported over asecond link and audio data is transportedover a third link.

By providing the sets of IP addresses, e.g. as in table 3, the mobile device106can also take hardware constraints into account. For example, the simultaneous operation of some RATs may not be possible in a mobile device106. Those configurations can be excluded by the mobile device106when communicating the sets of IP addresses to the third sub-entity406.

Based on the sub-entities404,405,406the set-up and management of a multi-RAT based service access with mobile device centric decision making is for example performed as illustrated inFIG. 7.

In701, the mobile device106interacts with the first sub-entity404in order to obtain information on available multi-link configurations.

In702, the mobile device106interacts with the second sub-entity405. Information on available operators' networks in a given geographic area is exchanged. Information for accessing the concerned private IP sub-nets of operators is given by the mobile device106if the information is available.

In703, the mobile device106interacts with the third sub-entity406. In particular, the mobile device106communicates sets of pre-defined link configurations. One of those sets is chosen for an initial configuration.

In704, the server109provides the service to the mobile device106.

In705, the mobile device106(or another entity) checks whether the QoS at which the service is provided is sufficient. If yes, the server109continues to provide the service in704. For example,705is carried out periodically.

If the QoS at which the service is provided is not sufficient, the mobile device106, in706, interacts with the third sub-entity406in order to change the current configuration. Alternatively, the network/server has the authority to perform the configuration change autonomously, or after a certain period during which no trigger from the concerned mobile device106arrives. The server109then continues to provide the service with the changed configuration in704

Network/Server Centric Decision Making for Selected a Multitude of Heterogeneous RATs to be Operated Simultaneously for Accessing a Single Service

For network/server centric decision making a multi-link management entity403may also be introduced as described above for mobile device centric decision making. For network/server centric decision making, the functionalities of the sub-entities404,405,406are for example adapted as follows.

Sub-entity404for Information provision on available multi-link configurations: The first sub-entity404on the network side stores a list of feasible configurations, e.g. indicating how many independent links can be supported for providing the concerned service requested by the mobile device106from the server109. The mobile device106can request this information but does not have to since the final decision on the link selection is taken on the network/server side. However, the information may be used by the mobile device in order to only deliver the link information to the network/server that finally lead to feasible configurations. Also, it helps the mobile device106(or its user) to better understand the behavior of the network/server centric decision making processes in case that the current link situation makes the QoS drop and a reconfiguration is required.

Sub-entity405for information provision on supported IP sub-nets: The second sub-entity405is used by the network/server in order to identify the feasible connections through private IP sub-nets. The network/server requests location information from the mobile device106or take the information from the network (for example, information on a base station location may be sufficient if the mobile device106is connected to this base station). Then, the network/server requests corresponding access information from the mobile device106. This information can be expected to be required by the relevant operators in order to grant access to the concerned private IP sub-nets.

Sub-entity406for buffering predefined mobile device configurations: The third sub-entity406is for example used in case that the mobile device106(or its user) prefers to communicate preferred multi-RAT link configurations in case of a link reconfiguration. The triggers for a reconfiguration change are however for example initiated by the network/server and communicated to the mobile device106, forcing a reconfiguration.

Based on the sub-entities404,405,406the set-up and management of a multi-RAT based service access with network/server centric decision making is for example performed as illustrated inFIG. 8.

In801, the mobile device106optionally interacts with the first sub-entity404in order to obtain information on available multi-link configurations.

In802, the mobile device106interacts with the second sub-entity405. This interaction is for example triggered by the network/server. For example, information on available operators' networks in a given geographic area is exchanged. The location of the mobile device106is for example either detected by the network, i.e. by a component of the network side, for example by identifying a specific cell to which the mobile device106is attached, or requested to be provided by the mobile device106. Information for accessing the concerned private IP sub-nets of operators are given by the mobile device106if the information is available.

In803, the mobile device106optionally interacts with the third sub-entity406. For example, the mobile device106may communicate sets of pre-defined link configurations. The network/server chooses an initial configuration, e.g. taken from one of the provided sets.

In804, the server109provides the service to the mobile device106.

In805, the mobile device106(or another entity) checks whether the QoS at which the service is provided is sufficient. If yes, the server109continues to provide the service in804. For example,805is carried out periodically.

If the QoS at which the service is provided is not sufficient, the third sub-entity406sends triggers to the mobile device106in order to change the current configuration and the server109continues to provide the service with the changed configuration in804.

In the following, it is discussed how the mobile device106may learn how to receive the various desired parts of the data provided by the server109, e.g. which parts of the data are sent via which radio link.

It is assumed that the splitting of the data provided by the server109(e.g. a multimedia resource) that the client has requested has already been done on the network/server side. The issue after the splitting is how the client (i.e. the mobile device106) learns about how to receive the desired pieces of the data.

The network/server for example communicates to the mobile device106the characteristics of each part of the data, as well as for example, for each part of the data, the IP address/port by means of which the part of the data is communicated. At this point the client may inform the network/server about the existence of its other interfaces (i.e. supported communication links) as well (e.g. indicating their public addresses). In that case the network/server may send back information on alternative IP/ports where the same resource pieces are available, i.e. by means of which the part of the data is communicated. Some of these alternative communication links may for example use the same subnet as the mobile device106. Identifying subnets is of course also an issue, but it can be done based on the public IP.

For the identifying the pieces of interest (i.e. parts of the data) to the client (e.g. just the base quality stream of an Audio Stream, not the incremental redundancy streams, etc.) the protocol as illustrated inFIG. 9is for example used.

The message flow takes place between a client901, e.g. corresponding to the mobile device106and the network or server (e.g. a plurality of network components, e.g. including the server109and the multi-link management entity403or any of its sub-entities404,405,406or any other network component, e.g. an intermediate network component handling the data transfer between the server109and the mobile device106).

FIG. 10andFIG. 11show examples for the messages exchanged according to the message flow diagram900.

In903, the client901transmits a first message904to the network/server, e.g. to a network entity, for example, the first sub-entity404.

The first message904is a resource/service request which for example relates toA service to be provided, e.g. video streaming, VoIP communication, gaming, etc. The first message904can include a service quality level, e.g. a video quality levels, etc.A resource request, e.g. indicating the communication parameter (minimum) requirements such as i) data bandwidth, ii) latency, iii) jitter, iv) packet loss probability, etc.Client context information can be provided to the network/server902in order to support it in the RAT selection process. This context information can also be used in order to request a specific set of RATs.

An example for the first message904is the message1001shown inFIG. 10.

In905, the network/server902informs the client901about the available pieces of data and the characteristics of each piece of data with a second message906.

An example for the second message906is the message1002shown inFIG. 10.

In907, the client901informs the network/server902by means of a third message908about the pieces of interest for the client901and gives, for each piece of interest (e.g. audio, base layer of a video, enhancement layer of a video), a public IP address by means of which the piece of interest can be transmitted to the client901.

An example for the third message908is the message1003shown inFIG. 10.

In909, the network/server902informs the client901about the IP addresses and ports used for transmitting the pieces of interest by means of a fourth message910. The network/server902may have identified that an interface of the client901and a resource point are on the same subnet (e.g. both have public Ws known to belong to the same 3G Operator). In that case the server could send to the client the local IP/port of the resource point as well, resolving connectivity issues because of firewalls and NATs.

An example for the fourth message910is the message1101shown inFIG. 11.

In911, the client requests to start transmission of the pieces of interest using a specific IP address and port per piece by sending a fifth message912to the network/server902. The transmission may thus be controlled by the client, i.e. the server has sent all the necessary information and the client decides which pieces of data should be communicated over which communication link. In response of the request, the network/server902starts providing the requested data to the client901.

An example for the fifth message912is the message1102shown inFIG. 11.

In this example, the client901changes the client context in913by means of a sixth message914.

Such a client context change may trigger the re-negotiation of the service parameters, i.e. a change of the communication links used (including e.g. a change of the IP addresses and ports used). Some or all of903,905,907,911may be carried out perform this adaptation of the service parameters.

An example for the sixth message914is the message1103shown inFIG. 11.

It should be noted that the pieces of data or parts of the data that the mobile device106requests and that are provided according to the service provided by the server109are not necessarily sub-streams of a stream (e.g. an audio stream or a base layer or an enhancement layer of a video stream). In contrast, the server109may for example provide a file and the parts of the data are parts of the file.

Further, the splitting of a file or stream may happen at a lower layers than the application layer (e.g. at a lower layer than the layer of the codec as in case of the parts of data being an audio stream and a base layer and an enhancement layer of a video stream). For example, an entity at the network layer may receive a file or stream and separates it into sub-files or sub-stream, e.g. cyclically distributes consecutive parts (e.g. parts of data corresponding to one or more frames) to the different communication links to be used for the transmission.

FIG. 12shows an example for a web-Interface for adding a number of IP links to be used simultaneously in order to provide a single service which is split over a number of independent communication links.

In this example, the user may enter an IP address in a first IP address field1201corresponding to a first communication link over which audio data is to be transmitted to the client106.

In a second IP address field1202, the user may enter an IP address corresponding to a second communication link over which video data is to be transmitted to the client106.

By means of a web interface as for example shown inFIG. 12, a user of a web-based service, in this example video streaming, may enter a number of IP addresses to be used simultaneously for an efficient split of the service.

While specific aspects have been described, it should be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the aspects of this disclosure as defined by the appended claims. The scope is thus indicated by the appended claims and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced.