WO2016015747A1

WO2016015747A1 - Message-based path selection for transport protocols supporting multiple transport paths

Info

Publication number: WO2016015747A1
Application number: PCT/EP2014/066197
Authority: WO
Inventors: Hanns Jurgen Schwarzbauer; Richard Waldhauser; Irina-Mihaela BALAN
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2014-07-28
Filing date: 2014-07-28
Publication date: 2016-02-04
Also published as: JP2017523714A; CN106879262A; EP3175598A1; KR20170027801A

Abstract

There are provided measures enabling/realizing for message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics. Such measures exemplarily comprise obtaining transport characteristics of plural transport paths of a single peer- to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer-to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message.

Description

Title

Message-based path selection for transport protocols supporting multiple transport paths

Field

The present invention relates to message-based path selection for transport protocols supporting multiple transport paths. More specifically, the present invention relates to measures (including methods, apparatuses and computer program products) for enabling/realizing message- based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics .

Background

In current (e.g. 3GPP) mobile communication systems, a transport connection between two communication control entities in a network, such as two base stations, is used for UE handover (HO) procedures. In LTE and LTE-A systems, a logical X2 transport is used for X2 handover procedures for UE handover between eNBs . Apart from the specification that there shall be only one single X2 transport established between an eNB pair, there are no explicit requirements how such X2 transport is carried between the communication control entities . Depending on operator decisions, such X2 transport might be carried either via backhaul transport paths connecting the eNBs via the operator's core network or direct transport paths between neighboring eNBs.

In future (e.g. 3GPP) mobile communication systems, a transport connection between two communication control entities in a network, such as two base stations, should also be used for inter-eNB features relating e.g. to cooperative/coordinated multi-point transmission (CoMP) and carrier aggregation (CA) . In LTE and LTE-A systems, the logical X2 transport used for X2 handover procedures for UE handover between eNBs should thus be extended to additionally support such inter-eNB features. However, support of such inter-eNB features has much more stringent timing/delay requirements than currently specified X2 handover procedures. It is commonly accepted that the stringent timing/delay requirements for inter-eNB features such as CoMP and CA could only be met using direct transport paths between neighboring eNBs providing CoMP and/or CA support for a given UE .

A general requirement for current and future (e.g. 3GPP) mobile communication systems resides in the need for support of redundancy in the access/transport network. Such access/transport network redundancy may be achieved e.g. by using multi-homing for the communicating endpoints of a (peer-to-peer) connection, such as two neighboring eNBs, where every endpoint is assigned with at least two network interfaces (or network interface cards) each with a different IP address in disjunct IP sub-networks.

Figure 1 shows a schematic diagram illustrating the functional principle of multi-homing based on SCTP as an example of a transport protocol supporting multiple transport paths. As evident from Figure 1, a dual-homed transport is implemented in that the two communicating endpoints of a (logical) peer-to-peer connection are physically linked via two transport paths having different transport characteristics such as delays and bandwidths. In the example of Figure 1, SCTP is used as the transport protocol, i.e. a single SCTP association is adopted as the (logical) peer-to-peer connection between the communicating endpoints. However, any transport protocol supporting multiple transport paths can be utilized, including e.g. MP-TCP or any similar transport protocol.

Figure 2 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using backhaul transport paths based on SCTP as an example of a transport protocol supporting multiple transport paths. Such exemplary network architecture can be utilized for the X2 transport for handover procedures and/or inter- eNB features, as discussed above. Yet, in such network architecture, the stringent timing/delay reguirements for inter-eNB features could not be met, since all messages are to be transmitted on one of the backhaul transport paths via the core network, resulting in excessive latency/delay. Figure 3 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using direct transport paths based on SCTP as an example of a transport protocol supporting multiple transport paths. Such exemplary network architecture can be utilized for the X2 transport for handover procedures and/or inter-eNB features, as discussed above. In such network architecture, the stringent timing/delay reguirements for inter-eNB features could be met in a reliable manner, while such approach would be costly and inefficient (and at least two additional network interfaces would be needed for connecting the eNBs with the core network) .

A network architecture capable of further exploiting multi- homing (based on SCTP) in a more efficient way would result from defining an SCTP association with one IP address on the network interface for a direct transport path and one IP address on the network interface for a backhaul transport path. Such network architecture corresponds to a combination of the network architectures of Figures 2 and 3 in that it has at least one direct transport path and at least one backhaul transport path.

As indicated above, SCTP typically defines a primary path for transmission of all traffic (i.e. messages) to be transported on a specific (logical) peer-to-peer connection between communicating endpoints, and all traffic will be transmitted on this primary path irrespective of its purpose and/or transport characteristics. By default, SCTP assumes that there is no essential difference in terms of transport characteristics (e.g. delay, bandwidth, etc.) among various transport paths constituting an SCTP association. Due to this basic assumption, different transport paths are conventionally considered as providing for resilient transport rather than providing different transport characteristics. Therefore, SCTP is not allowing an upper layer protocol to differentiate between the use of one or the other transport path in case of multi-homing except by explicitly setting the primary path.

For example, in a network architecture having at least one direct transport path and at least one backhaul transport path, when the application (e.g. the X2 application) defines the direct transport path as primary path to be used by SCTP, all messages exchanged between the SCTP endpoints will use this primary path as long as this direct transport path is not declared as failed. This results in a mixture of traffic with different timing/delay reguirements via a single (logical) peer-to-peer connection, which is seen as detrimental regarding the expected needs of new inter-eNB features like CoMP and/or CA (and their difference as compared with the needs of current handover procedures ) .

Accordingly, there is a demand for enabling/realizing message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics .

Summary

Various exemplifying embodiments of the present invention aim at addressing at least part of the above issues and/or problems and drawbacks .

Various aspects of exemplifying embodiments of the present invention are set out in the appended claims .

According to an example aspect of the present invention, there is provided a method comprising obtaining transport characteristics of plural transport paths of a single peer- to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer-to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message. According to an example aspect of the present invention, there is provided an apparatus comprising a processor, and a memory configured to store computer program code, wherein the processor is configured to cause the apparatus to perform: obtaining transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer- to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message .

According to an example aspect of the present invention, there is provided a computer program product comprising computer-executable computer program code which, when the program code is executed (or run) on a computer or the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related example aspects of the present invention) , is configured to cause the computer to carry out the method according to any one of the aforementioned method-related example aspects of the present invention. The computer program product may comprise or may be embodied as a (tangible/non-transitory) computer-readable (storage) medium or the like, on which the computer- executable computer program code is stored, and/or the program is directly loadable into an internal memory of the computer or a processor thereof.

Further developments and/or modifications of the aforementioned exemplary aspects of the present invention are set out in the following.

By way of exemplifying embodiments of the present invention, message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics, can be enabled/realized. For example, exemplifying embodiments of the present invention thus teach how messages or message types having different purposes and/or transport reguirements, e.g. with respect to delay, bandwidth, or the like, such as e.g. X2 handover- related messages and CA/CoMP-related messages, could be effectively separated and exchanged via different transport paths on a single (logical) peer-to-peer connection, such as e.g. one logical X2 transport.

Brief description of the drawings In the following, the present invention will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which

Figure 1 shows a schematic diagram illustrating the functional principle of multi-homing based on SCTP,

Figure 2 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using backhaul transport paths based on SCTP,

Figure 3 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using direct transport paths based on SCTP,

Figure 4 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using direct and backhaul transport paths based on SCTP, for which exemplifying embodiments of the present invention are applicable,

Figure 5 shows a flowchart illustrating a method according to exemplifying embodiments of the present invention, Figure 6 shows a diagram illustrating a first example of a procedure according to exemplifying embodiments of the present invention,

Figure 7 shows a diagram illustrating a second example of a procedure according to exemplifying embodiments of the present invention,

Figure 8 shows a diagram illustrating a third example of a procedure according to exemplifying embodiments of the present invention,

Figure 9 shows a schematic diagram illustrating an example of a structure of apparatuses according to exemplifying embodiments of the present invention, and

Figure 10 shows a schematic diagram illustrating another example of a structure of apparatuses according to exemplifying embodiments of the present invention.

Detailed description

The present invention is described herein with reference to particular non-limiting examples and to what are presently considered to be conceivable embodiments of the present invention. A person skilled in the art will appreciate that - li

the present invention is by no means limited to these examples and embodiments, and may be more broadly applied.

It is to be noted that the following description of the present invention and its embodiments mainly refers to specifications being used as non-limiting examples for certain exemplifying network configurations and system deployments. Namely, the present invention and its embodiments are mainly described in relation to 3GPP specifications being used as non-limiting examples for certain exemplifying network configurations and system deployments. In this regard, an X2 interface on which SCTP is used as a transport protocol, i.e. a SCTP association between two eNBs, is adopted as a non-limiting example of a (logical) peer-to-peer connection (between two communication control entities) via a transport protocol supporting multiple transport paths .

As such, the description of exemplifying embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does naturally not limit the invention in any way. Rather, any other network configuration or system deployment, etc. (including any other interface between two communicating entities, any other via transport protocol supporting multiple transport paths, etc.) may also be utilized as long as complying with what is described herein and/or exemplifying embodiments described herein are applicable to it. For example, the multi-path transmission control protocol (MP-TCP) or any other comparable transport protocol can be adopted as a transport protocol supporting multiple transport paths instead of the stream control transmission protocol (SCTP), or any other connection/transport between any two communication endpoints, such as communication control entities, can be adopted instead of a X2 interface .

Hereinafter, various exemplifying embodiments and implementations of the present invention and its aspects are described using several variants and/or alternatives. It is generally to be noted that, according to certain needs and constraints, all of the described variants and/or alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various variants and/or alternatives). In this description, the words "comprising" and "including" should be understood as not limiting the described exemplifying embodiments and implementations to consist of only those features that have been mentioned, and such exemplifying embodiments and implementations may also contain features, structures, units, modules etc. that have not been specifically mentioned.

In the drawings, it is to be noted that lines/arrows interconnecting individual blocks or entities are generally meant to illustrate an operational coupling there-between, which may be a physical and/or logical coupling, which on the one hand is implementation-independent (e.g. wired or wireless) and on the other hand may also comprise an arbitrary number of intermediary functional blocks or entities not shown. For sake of clarity and lucidity, all of the exemplary network architectures are illustrated in a simplified manner. For example, the IP sub-networks are assumed to have no routing functionality between them, which results in that two IPsec tunnels per peer-to-peer- connection (e.g. SCTP association) are shown. So, each IPSec tunnel is terminated in a separate Security Gateway (SeGW) on the boundary of the core network, while only one SeGW per sub-network would be needed in practice.

According to exemplifying embodiments of the present invention, in general terms, there are provided measures and mechanisms for enabling/realizing message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics.

Figure 4 shows a schematic diagram illustrating an exemplary network architecture for dual-homed X2 transport using direct and backhaul transport paths based on SCTP, for which exemplifying embodiments of the present invention are applicable.

As illustrated in Figure 4, eNBl and eNB2 exemplifying two communicating endpoints of an SCTP association exemplifying a single (logical) peer-to-peer connection are linked by a direct transport path network and a backhaul transport path via the core network. That is, the direct transport path and the backhaul transport path constitute the single (logical) peer-to-peer connection, i.e. the SCTP association. The direct transport path and the backhaul transport path have different transport characteristics (or, stated in other words, different transport classifications), e.g. different delay and bandwidth characteristics. Specifically, the direct transport path has better transport characteristics as compared with the backhaul transport path, e.g. its delay is lower and its bandwidth is higher than those of the backhaul transport path .

According to exemplifying embodiments of the present invention, a message-based path selection mechanism is applied in such exemplary network architecture having multiple transport paths with different transport characteristics (or, stated in other words, different transport classifications) . As detailed below, traffic with higher transport reguirements (e.g. more stringent timing/delay reguirements), such as HO-related messages, CA-related messages, CoMP-related messages, or the like, is transported via the direct transport path having better transport characteristics, while traffic with lower transport reguirements (e.g. less stringent timing/delay reguirements) is transported via the backhaul transport path having worse transport characteristics. That is to say, the message-based path selection mechanism according to exemplifying embodiments of the present invention enables distribution of messages to different transport paths based on transport characteristics (i.e. message type and/or purpose) . According to exemplifying embodiments of the present invention, more than two transport paths can be provided on the single (logical) peer-to-peer connection between the communicating endpoints. That is, the present invention is not limited to dual-homing but is generally applicable to multi-homing with two or more network interfaces per communicating endpoint .

According to exemplifying embodiments of the present invention, any kind of information indicative of transport capacity and/or property of a transport path can be adopted as transport characteristics (i.e. transport classification) . While path delay and path bandwidth are exemplarily illustrated in Figure 4 and referenced in the present description, the present invention is not limited to these specific examples of transport characteristics (i.e. transport classifications).

Figure 5 shows a flowchart illustrating a method according to exemplifying embodiments of the present invention.

As illustrated in Figure 5, a method according to exemplifying embodiments of the present invention comprises an operation of obtaining (current/actual) transport characteristics of plural transport paths of a single peer- to-peer connection via a transport protocol supporting multiple transport paths, an operation of determining preferred transport characteristics for an application message to be transmitted on the single peer-to-peer connection depending on a type of the application message, and an operation of selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has (current/actual) transport characteristics meeting the determined preferred transport characteristics for the application message.

In the following, various exemplary procedures are described for the exemplary use case of an X2 interface connection based on SCTP as an example of a transport protocol supporting multiple transport paths . The exemplary procedures of any one of Figures 6 to 8 are applicable/operable at any endpoint entity of any (logical) peer-to-peer connection via a transport protocol supporting multiple transport paths, such as e.g. a SCTP association between eNBs like eNBl/eNB2 illustrated in Figure 4.

In Figures 6 to 8, a transport layer is exemplified as a SCTP layer denoted by "SCTP", an application protocol interface of the transport layer is exemplified as a SCTP application protocol interface (API) denoted by "SCTP API", and an application layer is exemplified by a X2 application protocol (AP) denoted by "X2 AP". The application relating to the X2 AP can for example refer to HO, CA and/or CoMP procedures via the X2 interface. Figure 6 shows a diagram illustrating a first example of a procedure according to exemplifying embodiments of the present invention.

As illustrated in Figure 6, the transport characteristics of the plural transport paths are obtained at the SCTP API, the preferred transport characteristics for the application message are determined at the X2 AP, and the transport path for transmitting the application message is selected at the SCTP API .

The SCTP can acguire information about the transport characteristics (i.e. the transport classification) of the plural transport paths. Such information can be acguired in any arbitrary way such as by detection by/at the SCTP itself (implicitly) and/or by detection by/at another entity, application or layer on top of the SCTP and corresponding notification of the SCTP (explicitly) . For example, in this regard, timestamps in HEARTBEAT/HEARTBEAT ACK can be exploited, a separate application measuring delay and/or bandwidth can be used, a management interface can be used, and so on. Further, the SCTP knows about the available transport paths. Accordingly, the SCTP can pass corresponding information (indicating the available transport paths and their transport characteristics) to the SCTP API . The SCTP API can thus obtain the transport characteristics of the plural transport paths from the SCTP. Further, the SCTP API can store the thus received information, and pass corresponding information indicating the transport characteristics of the available transport paths to the X2 AP .

Generally, it is to be noted that in case of path failure the SCTP and/or the SCTP API can inform the application about the transport characteristics of the failed transport path, and in case of path re-establishment, the SCTP and/or the SCTP API can inform the application about the transport characteristics of the re-established transport path.

The aforementioned functionality of the SCTP and the SCTP API is not associated with an actual message transmission or message transmission demand, and can for example be carried out in a periodical manner, upon change of transport paths, upon establishment of the connection, upon change of transport characteristics, or the like.

The X2 AP can determine the preferred transport characteristics for any application message to be transmitted on a per-message basis. Such determination can be based on message type and/or purpose, and can depend on some given policy, operating conditions, or the like. For example, the X2 AP can determine that a CA-related message or a CoMP-related message has stringent timing/delay reguirements , while a HO-related message has relaxed timing/delay requirements . As a result of such determination, the X2 AP can pass corresponding information indicating the determined preferred transport characteristics together with the application message to be transmitted to the SCTP API.

The aforementioned functionality of the X2 AP is associated with an actual message transmission or message transmission demand. That is, this functionality is carried out on a per-message basis when a message is to be transmitted by the related application.

The SCTP API can map the preferred transport characteristics for the application message to be transmitted, as received from the X2 AP, with the previously obtained and stored transport characteristics of the plural transport paths for selecting the transport path for transmitting the application message. In this regard, the SCTP API can select that transport path out of the available transport paths (for which transport characteristics are previously obtained and stored) , which most appropriately meets the preferred transport characteristics for the application message (e.g. the transport path with satisfying transport characteristics closest to the preferred transport characteristics, the transport path with the best/highest transport characteristics satisfying the preferred transport characteristics, etc.) . As a result of such mapping/ selection, the SCTP API can pass corresponding information indicating the selected/preferred transport path together with the application message to be transmitted to the SCTP .

The SCTP can then transmit the application message on the selected/preferred transport path out of the available transport paths of the peer-to-peer connection.

Accordingly, traffic with higher transport reguirements (e.g. more stringent timing/delay reguirements), such as HO-related messages, CA-related messages, CoMP-related messages, or the like, can be transported via a direct transport path having better transport characteristics, while traffic with lower transport reguirements (e.g. less stringent timing/delay reguirements) can be transported via a backhaul transport path having worse transport characteristics. That is to say, the message-based path selection mechanism according to exemplifying embodiments of the present invention enables distribution of messages to different transport paths based on transport characteristics (i.e. message type and/or purpose).

As described above, according to exemplifying embodiments of the present invention, the application protocol interface of the transport layer, e.g. the SCTP API, thus allows the application on top thereof applying a message- based path selection mechanism. This is realized in that the application protocol interface of the transport layer, e.g. the SCTP API, allows the upper layer application to specify the preferred transport characteristics, e.g. by way of a transport class identifier, per application message, and utilizes specification for selecting an appropriate transport path. From the perspective of the application, there is still only one logical transport connection, but the application is enabled to indicate a lower transport layer the reguired transport characteristics for any application message to be transmitted. The functionality of the application protocol interface of the transport layer, e.g. the SCTP API, is enhanced by the additional information received there on a per-message basis, which allows the transport layer, e.g. the SCTP, to schedule the message for transmission on the specific transport path of the logical transport connection, e.g. SCTP association, having the reguested transport characteristics (classification). Accordingly, such enhanced functionality of the application protocol interface of the transport layer, e.g. the SCTP API, is achieved without modification/enhancement of transport layer, e.g. SCTP, message definitions, since the additional information is handled purely inside the local transport layer, e.g. SCTP, by internal, e.g. SCTP, procedures and not communicated via the transport layer, e.g. the SCTP association to the peer node.

Figure 7 shows a diagram illustrating a second example of a procedure according to exemplifying embodiments of the present invention.

The exemplary procedure of Figure 7 is similar to that of Figure 6, and thus a detailed description thereof is omitted. The exemplary procedure of Figure 7 basically differs from that of Figure 6 in that the message-based path selection mechanism is applied only upon reguest and/or when reguired.

As illustrated in Figure 7, the X2 AP can reguest message- based path selection on the SCTP API in case of need and/or support for different transport classifications (classes) of the plural transport paths. That is, it can be reguested that explicit per-message path selection should be enabled in case the transport characteristics of multiple available paths differ. Such reguest can be passed from the X2 AP to the SCTP API and further from the SCTP API to the SCTP. Such reguest can for example be issued prior to, after, or - as exemplarily illustrated - together with reguesting establishment of the peer-to-peer connection, i.e. the SCTP association .

When message-based path selection is reguested by the X2 AP or set as a default, as illustrated in Figure 7, the SCTP can identify need and/or support for different transport classifications of the plural transport paths based on transport characteristics of the plural transport paths, and can notify the X2 AP of the identified need and/or support for different transport classifications of the plural transport paths via the SCTP API. If it is identified, after having established the SCTP association, that there is no need (e.g. because the transport characteristics of all transport paths are similar/comparable e.g. due to the fact that there are only direct or backhaul transport paths available) or no support (e.g. because there is only one transport path available) for different transport classifications, the application on top of SCTP is informed accordingly via the SCTP API . This information can also be provided, if e.g. due to transport path failure, the support of different traffic classifications is no longer provided.

It is to be noted that the aforementioned identification and notification functionality can be carried out by the SCTP API instead of or together with the SCTP. Further, it is to be noted that the illustrated seguence of operations is for illustrative purposes only, while the present invention is not limited thereto. For example, the SCTP can obtain the transport characteristics of the plural transport paths and identify need and/or support for different transport classifications of the plural transport path (at least partly) simultaneously or in parallel, and pass/notify corresponding information or results in a single message to the SCTP API, or the SCTP can pass/notify corresponding information or results in distinct messages of a different order to the SCTP API.

As a result of such identification of need and/or support for different transport classifications of the plural transport paths by the SCTP and/or the SCTP API, determination of the preferred transport characteristics for the application message by the X2 AP and selection of the transport path for transmitting the application message by the SCTP API can be carried out only when reguired, i.e. only when need and/or support for different transport classifications of the plural transport paths is identified .

Figure 8 shows a diagram illustrating a third example of a procedure according to exemplifying embodiments of the present invention.

The exemplary procedure of Figure 8 is similar to that of Figure 6, and thus a detailed description thereof is omitted. The exemplary procedure of Figure 8 basically differs from that of Figure 6 in that the X2 AP does not only determine the preferred transport characteristics for the application message but also includes information indicating the determined preferred transport characteristics for the application message into the application message itself. As explained below, inclusion of such information in the application message itself is effective for achieving a fully transparent behavior of both communicating nodes of the peer-to-peer connection.

As illustrated in Figure 8, the X2 AP can determine the preferred transport characteristics for any application message to be transmitted on a per-message basis, and include corresponding information indicating the determined preferred transport characteristics for the application message into the application message. Then, the X2 AP can pass corresponding information indicating the determined preferred transport characteristics together with the application message to be transmitted (including the information indicating the preferred transport characteristics thereof) to the SCTP API.

After mapping/selection, the SCTP API can pass corresponding information indicating the selected/preferred transport path together with the application message to be transmitted (including the information indicating the preferred transport characteristics thereof) to the SCTP. And the SCTP can then transmit the application message (including the information indicating the preferred transport characteristics thereof) on the selected/preferred transport path out of the available transport paths of the peer-to-peer connection.

According to exemplifying embodiments of the present invention, the information indicating its preferred transport characteristics can be included in a respective application message using a specific/dedicated information element.

An exemplary implementation in X2 AP is to add additional optional Information Elements (IES) to the message definitions in the 3GPP specification TS 36.423 to indicate the preferred transport characterisation.

The specifications of X2 messages suitable for the message- based path selection mechanism according to exemplifying embodiments of the present invention can include additional IEs like "TL path delay" and/or "TL path bandwidth" (assuming that delay and bandwidth are exemplarily used as relevant transport characteristics), as shown below.

The IE "TL path delay" is used to indicate the preferred transport path delay, and can be specified, e.g. in a section 9.2.x, as follows.

The TL path delay can for example be defined as a relative quantification of path delay, as shown below.

As evident from the above example IE, in case of a dual- homing SCTP association, the two transport paths could be classified as e.g. "fast" and "normal" when using the relative delay metric as differentiator. Instead of using a relative quantification of path delay, the TL path delay can for example be defined as a fractional quantification of path delay, as shown below. In this regard, the path delay can preferably be expressed as a fractional value compared with the path delay of the slowest transport path out of the available transport paths .

The IE "TL path bandwidth" is used to indicate the preferred transport path bandwidth, and can be specified, e.g. in a section 9.2.y, as follows.

The TL path bandwidth can for example be defined as a relative quantification of path bandwidth, as shown below.

IE/Group Name PreRange IE Type and Semantics Description sence Reference

TL Path bandwidth EN UM ERATED (1 , Relative quantification of

2, 4, 8, 1 6, 32, bandwidth compared to 64,...) the other path As evident from the above example IE, in case of a multi- homing SCTP association, the various transport paths could be classified by e.g. multiples or fractions of bandwidths when using the relative bandwidth metric as differentiator.

As indicated above, other transport characteristics apart from path delay and path bandwidth could egually be used. In such case, corresponding additional IE/IEs can be introduced accordingly in line with the above examples. Further, while the above examples refer to relative/fractional guantifications of path delay and path bandwidth, absolute values could egually be used for path delay and/or path bandwidth, or any other relevant transport characteristics .

An implementation based on introducing any one of the above additional IEs provides the peer node with the information regarding the transport path characteristics selected by the source node. Thereby, identical use of the transport paths by both peers of a (logical transport) connection can be ensured. Namely, the transport characteristics of the selected transport path, on which an application message is received, can be obtained using information indicating the determined preferred transport characteristics included in the received application message (e.g. the corresponding IE/IEs) . Hence, the receiving node knows about the preferred transport characteristics and the thus selected transport path by the transmitting node, and can act accordingly . Accordingly, a fully transparent behavior of both communicating nodes of the peer-to-peer connection can be achieved in that an application generating a message provides information of the selected transport characteristics, the application message carries the information of the selected transport characteristic, and the selected transport characteristics are specified in the application protocol interface of the transport layer, e.g. the SCTP API, when passing the application message to the transport layer . Thereby, the functionality of the application protocol interface of the transport layer, e.g. the SCTP API, is enhanced. According to exemplifying embodiments of the present invention, the above-described implementation based on introducing an additional IE provides the peer node with the information regarding the transport path characteristics selected by the source node. However, as SCTP needs to have application-independent information about the desired transport path, the SCTP API is adapted to receive such information from the X2 AP accordingly (irrespective of the actual contents of the application message as such). The application would set this SCTP API value according to the specification of the message to be transmitted. As specified in section 7 of the 3GPP specification TS 36.422, within the SCTP association established between one eNB pair:

- a single pair of stream identifiers shall be reserved for the sole use of X2 AP elementary procedures that utilize non UE-associated signaling, - at least one pair of stream identifiers shall be reserved for the sole use of X2 AP elementary procedures that utilize UE-associated signaling; however, a few pairs (i.e. more than one) should be reserved, and

- a single UE-associated signaling shall use one SCTP stream and the stream should not be changed during the communication of the UE-associated signaling.

Based on this description (which is assumed to be equally applicable for an extended X2 AP functionality for CA and CoMP features), in a dual-homing SCTP association, the application decides that e.g. UE-associated signaling is to be transmitted via the "fast" path, whereas non-UE associated signaling is to be transmitted via the "normal" path. Based on the information about the transport characteristics of the different transport paths, the application requests the "fast" path as the primary path in SCTP. This is in line with current SCTP specification.

Based on the described usage of SCTP streams, a possible implementation without any impact on X2 ASN. l definitions is to specify that messages transmitted on UE-associated streams always use the "fast" path, if available. Messages transmitted on non-UE associated streams have to use the "normal" (or slower) path. According default SCTP behavior, this could be implemented in SCTP by transmitting messages on streams flagged or known as "fast" via the primary path in line with standard SCTP behavior. Messages on streams flagged or known as "normal" will get exceptional treatment with respect to default SCTP behavior, as they will not be transmitted via the primary path. In case there are only few of these messages destined for the "normal" path, this could be implemented in standard-compliant SCTP by changing the primary path for a short time interval until this message has been sent, for example.

By virtue of exemplifying embodiments of the present invention, as evident from the above, message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics, can be realized/enabled.

Accordingly, it is enabled that a single (logical) peer-to- peer connection such as a X2 transport is preserved and the communicating nodes can determine which transport path a given message is to be favorably transmitted on. This is specifically beneficial when the conventional default assumption for SCTP that the available transport paths are providing comparable transport characteristics is no longer intact, such as in network architectures combining a direct transport path with a backhaul transport path via the core network to form one single (logical) peer-to-peer connection such as a SCTP association. If such situation is recognized, the SCTP can be informed about the transport characteristics of the different transport paths . Then, the SCTP is enabled to transport data messages (DATA chunks) according to transport characteristics (i.e. a transport classification) determined by the related application via the thus classified transport path. Applications generating messages with different transport reguirements continue to have only one logical transport connection. Yet, the application is made aware of the presence of different transport characteristics for the different transport paths forming a given SCTP association and is able to indicate the requested transport characteristics (i.e. transport classification) when passing a message to the transport layer. New information elements can additionally be added to the application messages to also inform the peer node about the selected transport characteristics (i.e. transport classification) . Thereby, identical use of the transport paths by both peers of a (logical transport) connection can be ensured.

By way of the message-based path selection for transport protocols supporting multiple transport paths according to exemplifying embodiments of the present invention, the X2 application protocol can be extended to support inter-eNB features such as CA and/or CoMP in addition to handover procedures, for example. Namely, based on their message type and/or purpose, CA- and/or CoMP-related messages can be separated from other traffic and transported over a specific transport path in accordance with their (more stringent) transport requirements.

The above-described methods, procedures and functions may be implemented by respective functional elements, entities, modules, units, processors, or the like, as described below. While in the foregoing exemplifying embodiments of the present invention are described mainly with reference to methods, procedures and functions, corresponding exemplifying embodiments of the present invention also cover respective apparatuses, entities, modules, units, network nodes and/or systems, including both software and/or hardware thereof. Respective exem pl ifying embodi ments of the present invention are described below referring to Figures 9 and 10, while for the sake of brevity reference is made to the detailed description of respective correspondi ng configurations/setups, schemes, methods and functionality, principles and operations according to Figures 4 to 8.

In Figures 9 and 10, the blocks are basically configured to perform respective methods, procedures and/or functions as described above. The entirety of blocks are basically configured to perform the methods, procedures and/or functions as described above, respectively. With respect to Figures 9 and 10, it is to be noted that the individual blocks are meant to illustrate respective functional blocks implementing a respective function, process or procedure, respectively. Such functional blocks are implementation- independent, i.e. may be implemented by means of any kind of hardware or software or combination thereof, respectively .

Further, in Figures 9 and 10, only those functional blocks are illustrated, which relate to any one of the above- described methods, procedures and/or functions. A skilled person will acknowledge the presence of any other conventional functional blocks reguired for an operation of respective structural arrangements, such as e.g. a power supply, a central processing unit, respective memories or the like. Among others, one or more memories are provided for storing programs or program instructions for controlling or enabling the individual functional entities or any combination thereof to operate as described herein in relation to exemplifying embodiments. Figure 9 shows a schematic diagram illustrating an example of a structure of apparatuses according to exemplifying embodiments of the present invention.

As indicated in Figure 9, according to exemplifying embodiments of the present invention, an apparatus 10 may comprise at least one processor 11 and at least one memory 12 (and possibly also at least one interface 13), which may be operationally connected or coupled, for example by a bus 14 or the like, respectively.

The processor 11 and/or the interface 13 of the apparatus 10 may also include a modem or the like to facilitate communication over a (hardwire or wireless) link, respectively. The interface 13 of the apparatus 10 may include a suitable transmitter, receiver or transceiver connected or coupled to one or more antennas, antenna units, such as antenna arrays or communication facilities or means for (hardwire or wireless) communications with the linked, coupled or connected device (s), respectively. The interface 13 of the apparatus 10 is generally configured to communicate with at least one other apparatus, device, node or entity (in particular, the connector thereof) .

The memory 12 of the apparatus 10 may represent a (non- transitory/tangible ) storage medium and store respective programs, program products, macros or applets, etc. or parts of them, which may be assumed to comprise program instructions or computer program code that, when executed by the respective processor, enables the respective electronic device or apparatus to operate in accordance with the exemplifying embodiments of the present invention.

In general terms, respective apparatuses (and/or parts thereof) may represent means for performing respective operations and/or exhibiting respective functionalities, and/or the respective devices (and/or parts thereof) may have functions for performing respective operations and/or exhibiting respective functionalities.

In view of the above, the thus illustrated apparatus 10 is suitable for use in practicing one or more of the exemplifying embodiments of the present invention, as described herein.

When in the subseguent description it is stated that the processor (or some other means) is configured to perform some function, this is to be construed to be eguivalent to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with a computer program code stored in the memory of the respective apparatus or otherwise available (it should be appreciated that the memory may also be an external memory or provided/realized by a cloud service or the like), is configured to cause the apparatus to perform at least the thus mentioned function. The thus illustrated apparatus 10 may represent or realize/embody a (part of a) communication (control) entity or node according to exemplifying embodiments of the present invention, such as eNBl or eNB2 of Figure 4, and it may be configured to perform a procedure and/or exhibit a functionality as described in Figures 5 to 8.

Accordingly, the apparatus 10 may be caused or the apparatus 10 or its processor 11 (possibly together with computer program code stored in the memory 12), in its most basic form, is configured to perform or cause obtaining (current/actual) transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer- to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has (current/actual) transport characteristics meeting the determined preferred transport characteristics for the application message.

For further details regarding the operability/functionality of the individual apparatuses or layers thereof according to exemplifying embodiments of the present invention, reference is made to the above description in connection with any one of Figures 4 to 8, respectively. As mentioned above, any apparatus according to exemplifying embodiments of the present invention may be structured by comprising respective means for performing corresponding operations, procedures and/or functions. For example, such means may be implemented/realized on the basis of an apparatus structure, as exemplified in Figure 9, i.e. by one or more processors 11, one or more memories 12, one or more interfaces 13, or any combination thereof.

As shown in Figure 10, an apparatus 1000 according to exemplifying embodiments of the present invention may be operable as a communication (control) entity or node. In the apparatus 1000, a part/unit 100 may represent or be operable as an application layer such as a X2 AP, a part/unit 200 may represent or be operable as an application protocol interface of a transport layer such as a SCTP API, and a part/unit 300 may represent or be operable as a transport layer such as a SCTP.

The apparatus 1000 may comprises (at least) means for obtaining (current/actual) transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths (denoted as transport characteristics obtaining means 210 in its part/unit 200), means for determining preferred transport characteristics for an application message to be transmitted on the single peer-to-peer connection depending on a type of the application message (denoted as transport characteristics determining means 110 in its part/unit 100), and means for selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has (current/actual) transport characteristics meeting the determined preferred transport characteristics for the application message (denoted as transport path selecting means 220 in its part/unit 200) .

According to exemplifying embodiments, as described above, it is to be noted that the apparatus 1000 may further comprise means for obtaining transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths (denoted as transport characteristics obtaining means 310 in its part/unit 300) and means for passing information indicating the obtained transport characteristics of the plural transport paths to the application protocol interface of the transport layer (denoted as transport characteristics information passing means 350 in its part/unit 300 ) .

According to exemplifying embodiments, as described above, it is to be noted that the apparatus 1000 may further comprise means for passing information indicating the obtained transport characteristics of the plural transport paths to the application layer (denoted as information/message passing means 230 in its part/unit 200), means for passing the application message together with information indicating the determined preferred transport characteristics from the application layer to the application protocol interface of the transport layer (denoted as application message and information passing means 120 in its part/unit 100), and means for mapping the determined preferred transport characteristics with the obtained transport characteristics of the plural transport paths for selecting the transport path for the application message on the application protocol interface of the transport layer (denoted as transport characteristics mapping means 240 in its part/unit 200) .

According to exemplifying embodiments, as described above, it is to be noted that the apparatus 1000 may further comprise means for passing the application message together with information indicating the selected transport path to the transport layer (denoted as information/message passing means 230 in its part/unit 200), and means for transmitting the application message on the selected transport path of the peer-to-peer connection (denoted as application message transceiving 350 in its part/unit 300) .

According to exemplifying embodiments, as described above, it is to be noted that the apparatus 1000 may further comprise means for reguesting message-based path selection on the application protocol interface of the transport layer in case of need and/or support for different transport classifications of the plural transport paths by the application layer (denoted as path selection requesting means 130 in its part/unit 100), means for identifying need and/or support for different transport classifications of the plural transport paths based on the obtained transport characteristics of the plural transport paths (denoted as classification need/support identifying means 250 in its part/unit 200 and/or classification need/support identifying means 330 in its part/unit 300), means for notifying the application layer of the identified need and/or support for different transport classifications of the plural transport paths (denoted as classification need/support notifying means 260 in its part/unit 200 and/or classification need/support notifying means 340 in its part/unit 300).

According to exemplifying embodiments, as described above, it is to be noted that the apparatus 1000 may further comprise means for including information indicating the determined preferred transport characteristics for the application message into the application message on the application layer (denoted as transport characteristics including means 140 in its part/unit 100), and means for transmitting the application message including the information indicating the determined preferred transport characteristics on the selected transport path of the peer- to-peer connection (denoted as application message transceiving 350 in its part/unit 300) . According to exemplifying embodiments of the present invention, any one of the processor, the memory and the connector, as well as any one of the means, may be implemented as individual modules, chips, chipsets, circuitries or the like, or one or more of them can be implemented as a common module, chip, chipset, circuitry or the like, respectively.

According to exemplifying embodiments of the present invention, a system may comprise any conceivable combination of the thus depicted devices/apparatuses and other network elements, which are configured to cooperate as described above.

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Such software may be software code independent and can be specified using any known or future developed programming language, such as e.g. Java, C++, C, and Assembler, as long as the functionality defined by the method steps is preserved. Such hardware may be hardware type independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor- Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components. A device/apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of a device/apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor. A device may be regarded as a device/apparatus or as an assembly of more than one device/apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

Apparatuses and/or means or parts thereof can be implemented as individual devices, but this does not exclude that they may be implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means/portions or embodied in a signal or in a chip, potentially during processing thereof.

The present invention also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above- described concepts of methodology and structural arrangement are applicable.

In view of the above, there are provided measures for enabling/realizing message-based path selection for transport protocols supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport characteristics. Such measures exemplarily comprise obtaining transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer-to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to-peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is to be understood that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed herein.

List of acronyms and abbreviations

3GPP 3^r Generation Partnership Project

AP Application Protocol

API Application Protocol Interface

AS .1 Abstract Syntax Notation 1

CA Carrier Aggregation

CoMP Cooperative/coordinated Multi-Point eNB enhanced Node B

HO Handover

IE Information Element

IETF Internet Engineering Task Force

IP Internet Protocol

LTE Long Term Evolution

LTE-A Long Term Evolution Advanced

MP-TCP Multi-Path Transmission Control Protocol

RFC Reguest for Comment (i.e. an IETF specification) SCTP Stream Control Transmission Protocol

SeGW Security Gateway

TCP Transmission Control Protocol

TL Transport Layer

UE User Eguipment

Claims

1. A method comprising obtaining transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer- to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to- peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message.

2. The method according to claim 1, wherein the transport characteristics of the plural transport paths are obtained on an application protocol interface of a transport layer, the preferred transport characteristics for the application message are determined on an application layer, and the transport path for transmitting the application message is selected on the application protocol interface of the transport layer.

3. The method according to claim 2, further comprising passing information indicating the obtained transport characteristics of the plural transport paths to the application layer, passing the application message together with information indicating the determined preferred transport characteristics from the application layer to the application protocol interface of the transport layer, and mapping the determined preferred transport characteristics with the obtained transport characteristics of the plural transport paths for selecting the transport path for the application message on the application protocol interface of the transport layer.

4. The method according to claim 3, further comprising passing the application message together with information indicating the selected transport path to the transport layer, and transmitting the application message on the selected transport path of the peer-to-peer connection.

5. The method according to any one of claims 2 to 4, further comprising reguesting message-based path selection on the application protocol interface of the transport layer in case of need and/or support for different transport classifications of the plural transport paths by the application layer, identifying need and/or support for different transport classifications of the plural transport paths based on the obtained transport characteristics of the plural transport paths, and notifying the application layer of the identified need and/or support for different transport classifications of the plural transport paths .

6. The method according to claim 5, wherein the preferred transport characteristics for the application message are determined on the application layer and the transport path for transmitting the application message is selected on the application protocol interface of the transport layer only when need and/or support for different transport classifications of the plural transport paths is identified.

7. The method according to any one of claims 1 to 6, further comprising including information indicating the determined preferred transport characteristics for the application message into the application message on the application layer, and transmitting the application message including the information indicating the determined preferred transport characteristics on the selected transport path of the peer- to-peer connection.

8. The method according to any one of claims 1 to 7, wherein the transport characteristics of the selected transport path, on which an application message is received, are obtained using information indicating the determined preferred transport characteristics included in the received application message.

9. The method according to any one of claims 1 to 8, wherein the transport characteristics comprise at least one of an absolute, a relative and a fractional guantification of a path delay and an absolute or relative guantification of a path bandwidth, and/or the transport protocol supporting multiple transport paths comprises the stream control transmission protocol (SCTP) or the multi-path transmission control protocol (MP- TCP) .

10. The method according to any one of claims 1 to 9, wherein the peer-to-peer connection forms an interface between two communication control entities of a communication system. - so

11. The method according to claim 10, wherein the plural transport paths comprise at least one direct transport path between the two communication control entities and at least one backhaul transport path, and/or the type of the application message comprises at least one of a message type relating to handover, a message type relating to carrier aggregation, and a message type relating to cooperative/coordinated multi-point communication .

12. An apparatus comprising a processor, and a memory configured to store computer program code, wherein the processor is configured to cause the apparatus to perform: obtaining transport characteristics of plural transport paths of a single peer-to-peer connection via a transport protocol supporting multiple transport paths, determining preferred transport characteristics for an application message to be transmitted on the single peer- to-peer connection depending on a type of the application message, and selecting one of the plural transport paths of the single peer-to-peer connection as the transport path for transmitting the application message on the single peer-to- peer connection, wherein the selected transport path has transport characteristics meeting the determined preferred transport characteristics for the application message.

13. The apparatus according to claim 12, wherein the processor is configured to cause the apparatus to obtain the transport characteristics of the plural transport paths on an application protocol interface of a transport layer, to determine the preferred transport characteristics for the application message on an application layer, and to select the transport path for transmitting the application message on the application protocol interface of the transport layer .

14. The apparatus according to claim 13, wherein the processor is configured to cause the apparatus to perform: passing information indicating the obtained transport characteristics of the plural transport paths to the application layer, passing the application message together with information indicating the determined preferred transport characteristics from the application layer to the application protocol interface of the transport layer, and mapping the determined preferred transport characteristics with the obtained transport characteristics of the plural transport paths for selecting the transport path for the application message on the application protocol interface of the transport layer.

15. The apparatus according to claim 14, wherein the processor is configured to cause the apparatus to perform: passing the application message together with information indicating the selected transport path to the transport layer, and transmitting the application message on the selected transport path of the peer-to-peer connection.

16. The apparatus according to any one of claims 13 to 15, wherein the processor is configured to cause the apparatus to perform: reguesting message-based path selection on the application protocol interface of the transport layer in case of need and/or support for different transport classifications of the plural transport paths by the application layer, identifying need and/or support for different transport classifications of the plural transport paths based on the obtained transport characteristics of the plural transport paths, and notifying the application layer of the identified need and/or support for different transport classifications of the plural transport paths .

17. The apparatus according to claim 16, wherein the processor is configured to cause the apparatus to determine the preferred transport characteristics for the application message on the application layer and to select the transport path for transmitting the application message on the application protocol interface of the transport layer only when need and/or support for different transport classifications of the plural transport paths is identified.

18. The apparatus according to any one of claims 12 to 17, wherein the processor is configured to cause the apparatus to perform: including information indicating the determined preferred transport characteristics for the application message into the application message on the application layer, and transmitting the application message including the information indicating the determined preferred transport characteristics on the selected transport path of the peer- to-peer connection.

19. The apparatus according to any one of claims 12 to 18, wherein the processor is configured to cause the apparatus to obtain the transport characteristics of the selected transport path, on which an application message is received, using information indicating the determined preferred transport characteristics included in the received application message.

20. The apparatus according to any one of claims 12 to 19, wherein the transport characteristics comprise at least one of an absolute, a relative and a fractional quantification of a path delay and an absolute or relative quantification of a path bandwidth, and/or the transport protocol supportinq multiple transport paths comprises the stream control transmission protocol (SCTP) or the multi-path transmission control protocol (MP- TCP) .

21. The apparatus accordinq to any one of claims 12 to 20, wherein the peer-to-peer connection forms an interface between two communication control entities of a communication system.

22. The apparatus accordinq to claim 21, wherein the plural transport paths comprise at least one direct transport path between the two communication control entities and at least one backhaul transport path, and/or the type of the application messaqe comprises at least one of a messaqe type relatinq to handover, a messaqe type relatinq to carrier aqqreqation, and a messaqe type relatinq to cooperative/coordinated multi-point communication .

23. A computer proqram product comprisinq computer- executable computer proqram code which, when the computer program code is executed on a computer, is configured cause the computer to carry out the method according to one of claims 1 to 11.