KR20170027801A - Message-based path selection for transport protocols supporting multiple transport paths - Google Patents

Abstract

Means are provided for message-based path selection for a transport protocol supporting multiple transport paths, i.e. enabling / realizing the distribution of messages to different transport paths based on transport properties. Such means may include, by way of example, obtaining the transport characteristics of a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths, Determining a desired transport property for an application message to be transmitted over a peer-to-peer connection, and determining a desired one of the plurality of transport paths of a single peer-to- As a transport path for transmitting an application message via the selected transport path, wherein the selected transport path has a transport property that matches the determined desired transport property for the application message.

Description

MESSAGE BASED PATH SELECTION FOR TRANSPORT PROTOCOLS SUPPORTING MULTIPLE TRANSPORT PATHS FOR TRANSPORT PROTOCOLS SUPPORTING MULTIPLE TRANSPORT PATH

The present invention relates to message-based path selection for a transport protocol supporting multiple transport paths. More particularly, the present invention relates to a message-based path selection for a transport protocol supporting multiple transport paths, i.e. means for enabling / realizing the distribution of messages to different transport paths based on transport properties Methods, devices, and computer program products).

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 the UE handover (HO) procedure. In the LTE and LTE-A systems, a logical X2 transport is used for the X2 handover procedure for UE handover between eNBs. Apart from the requirement that there should be only one single X2 transport established between the eNB pairs, there is no explicit requirement as to how such X2 transports are communicated between the communication control entities. Depending on the operator's decision, such an X2 transport may be conveyed via the carrier's core network to the backhaul transport path connecting to the eNB or the direct transport path 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, may also be a cooperative / coordinated multi- point transmission (CoMP) and carrier aggregation (CA). In LTE and LTE-A systems, the logical X2 transport used for the X2 handover procedure for UE handover between eNBs must therefore be extended to additionally support such inter-eNB features. However, the support of this inter-eNB feature has a much more stringent timing / delay requirement than the currently designated X2 handover procedure. It is generally the case that strict timing / delay requirements for inter-eNB features, such as CoMP and CA, can only be met using direct transport paths between neighboring eNBs that provide CoMP and / or CA for a given UE It is being tolerated.

A common requirement for current and future (e.g., 3GPP) mobile communication systems lies in the need for support for redundancy within the access / transport network. This access / transport network redundancy can be achieved, for example, by using multi-homing for communication end points of a (peer-to-peer) connection such as two neighboring eNBs, where all The endpoints are assigned at least two network interfaces (or network interface cards) each having a different IP address within the separate IP sub-network.

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 is apparent from Figure 1, two communication endpoints of a (logical) peer-to-peer connection are physically linked via two transport paths with different transport properties such as delay and bandwidth, a dual-homed transport is implemented. In the example of Figure 1, SCTP is used as a transport protocol, i.e. a single SCTP association is adopted as a (logical) peer-to-peer connection between the communication endpoints. However, any transport protocol that supports transport transport paths including, for example, MP-TCP or any similar transport protocol may be used.

Figure 2 shows a schematic diagram illustrating an exemplary network architecture for a dual-homed X2 transport using a SCTP-based backhaul transport path as an example of a transport protocol supporting multiple transport paths. This exemplary network architecture can be used for X2 transport and / or inter-eNB features for handover procedures, as described above. Also, in such a network architecture, a strict timing / delay requirement for the inter-eNB feature can not be met, since all messages must be sent over one of the backhaul transport paths through the core network, causing excessive delay / .

3 shows a schematic diagram illustrating an exemplary network architecture for a dual-homed X2 transport using a direct transport path based on SCTP as an example of a transport protocol supporting multiple transport paths. This exemplary network architecture can be used for X2 transport and / or inter-eNB features for handover procedures, as described above. In such a network architecture, strict timing / delay requirements for the inter-eNB feature may be met in a reliable manner, but this approach would be costly and inefficient (and at least two additional network interfaces are required to connect the core network and the eNB ).

A network architecture capable of also utilizing multi-homing in a more efficient manner is to define an SCTP association with an IP address on the network interface for the direct transport path and an IP address on the network interface for the backhaul transport path . This network architecture corresponds to the 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 described above, SCTP typically defines a primary path for the transmission of all traffic (i.e., messages) to be transported over a particular (logical) peer-to-peer connection between communication endpoints, And / or on the primary path regardless of the transport nature. By default, SCTP assumes that there are no intrinsic differences in terms of transport characteristics (e.g., delay, bandwidth, etc.) among the various transport paths that make up the SCTP association. Due to this basic assumption, different transport paths are typically considered to provide flexible transport rather than providing different transport properties. Thus, SCTP does not allow the upper layer protocol to distinguish the use of one or other transports in the case of multi-homing other than explicitly setting the primary path.

For example, in a network architecture with at least one direct transport path and at least one backhaul transport path, an application (e.g., an X2 application) may define a direct transport path as the primary path to be used by SCTP , All messages exchanged between SCTP endpoints will use this primary path unless this direct transport path is declared as failed. This results in a mix of different timing / delay requests and traffic via a single (logical) peer-to-peer connection, which is a predicted requirement of new inter-eNB features such as CoMP and / Their differences when compared to the demands of the market).

Accordingly, there is a need for message-based path selection for a transport protocol that supports multiple transport paths, i.e. enabling / realizing distribution of messages to different transport paths based on transport characteristics.

Various exemplary embodiments of the present invention are directed to addressing at least some of the above problems and / or problems and deficiencies.

Various aspects of exemplary embodiments of the invention are set forth in the appended claims.

According to an exemplary aspect of the present invention, there is provided a method comprising: obtaining a transport characteristic of a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths; Determining a desired transport property for an application message to be transmitted over a single peer-to-peer connection, and determining a path of one of the plurality of transport paths of a single peer-to- Selecting as a transport path for transmitting an application message over a peer connection, wherein the selected transport path has a transport property consistent with a determined desired transport characteristic for an application message.

According to an exemplary aspect of the present invention, there is provided a computer program product comprising a processor, and a memory configured to store computer program code, wherein the processor is operable to cause a device to perform a plurality of single- Determining the desired transport properties for the application message to be transmitted over a single peer-to-peer connection, depending on the type of application message, and determining the transport characteristics of the single peer-to- Selecting a path of one of the plurality of transport paths of the peer connection as a transport path for transmitting an application message over a single peer-to-peer connection, the selected transport path being a determined preferred transport for an application message, Have transport characteristics that match port characteristics - An apparatus is provided that is configured to perform the method.

According to an exemplary aspect of the present invention, when the program code is executed (or run) on a computer, or when the program is executed on a computer (e.g., a computer of a device according to any one of the above- There is provided a computer program product comprising computer executable computer program code configured to cause a computer to perform a method according to any one of the above-described method aspects of the present invention.

The computer program product may be a computer-readable (storage) medium on which computer executable computer program code is stored (tangible / non-temporary), or the like, and / Or directly into the processor.

Further improvements and / or modifications of the above-described exemplary aspects of the invention are described below.

According to an exemplary embodiment of the present invention, message-based path selection for a transport protocol supporting multiple transport paths, i.e. enabling / distributing the distribution of messages to different transport paths based on transport properties . For example, an exemplary embodiment of the present invention may thus provide a message or message with different purposes and / or transport requirements, such as, for example, delay, bandwidth, etc., such as X2 handover related messages and CA / CoMP- Teaches how a type can be effectively separated and exchanged over different transport paths on a single (logical) peer-to-peer connection, such as, for example, a single logical X2 transport.

In the following, the present invention will be described in more detail as a non-limiting example with reference to the accompanying drawings.
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 a dual-homed X2 transport using a backhaul transport path based on SCTP,
Figure 3 shows a schematic diagram illustrating an exemplary network architecture for a dual-homed X2 transport using a direct transport path based on SCTP,
4 shows a schematic diagram illustrating an exemplary network architecture for a dual-homed X2 transport using direct and backhaul transport paths based on SCTP, to which an exemplary embodiment of the present invention is applicable,
Figure 5 shows a flow diagram illustrating a method according to an exemplary embodiment of the present invention,
Figure 6 shows a diagram illustrating a first example of another procedure for an exemplary embodiment of the present invention,
Figure 7 illustrates a diagram illustrating a second example of a procedure according to an exemplary embodiment of the present invention,
Figure 8 illustrates a diagram illustrating a third example of a procedure according to an exemplary embodiment of the present invention,
Figure 9 shows a schematic diagram illustrating an example of a structure of an apparatus according to an exemplary embodiment of the present invention,
10 shows a schematic diagram illustrating another example of a structure of an apparatus according to an exemplary embodiment of the present invention.

The present invention is described herein with reference to what is presently considered to be a specific non-limiting example and a contemplated embodiment of the present invention. It will be understood by those skilled in the art that the present invention is not limited to these examples and examples in any way and can be applied more broadly.

It should be noted that the present invention and the following description of its embodiments refer primarily to specific exemplary network configurations and specifications used as non-limiting examples for system deployment. That is, the invention and its embodiments are described primarily with reference to 3GPP specifications used as a non-limiting example for a particular exemplary network configuration and system deployment. In this regard, an X2 interface where SCTP is used as a transport protocol, that is, the SCTP association between two eNBs is a (logical) peer-to-peer connection through a transport protocol that supports multiple transport paths Lt; / RTI > between entities).

As such, the description of the exemplary embodiments provided herein specifically refers to terms directly related thereto. These terms are used only in the context of the presented non-limiting examples and embodiments, and are in no way intended to limit the invention in any way. Rather, any other network configuration or system deployment (any other interface between the two communication entities, any other via the transport protocol supporting multiple transport paths, etc.) is consistent with what is described herein And / or the exemplary embodiments described herein are applicable thereto. For example, a multi-path transmission control protocol (MP-TCP) or any other corresponding transport protocol may be used in place of the stream control transmission protocol (SCTP) , Or any other connection / transport between any two communication end points, such as a communications control entity, may be employed in place of the X2 interface.

Various illustrative embodiments and implementations of the present invention and aspects thereof are described below using numerous variations and / or alternatives. According to particular needs and constraints, all described variations and / or alternatives may be provided alone or in any conceivable combination (including combinations of individual features of various variations and / or alternatives) Generally, it should be noted. In the present description, the words " comprising "and" comprising "should not be construed as limiting the described exemplary embodiments and implementations to only those features that are only mentioned, But may also include features, structures, units, modules, etc. that are not mentioned.

In the drawings, the lines / arrows interconnecting individual blocks or entities are generally referred to herein as any number of intermediate functional blocks or entities (not shown) that are, on the one hand, implementation independent (e.g., wired or wireless) For example, a physical and / or logical coupling that may also include physical, logical, and / or logical operations. For clarity and clarity, all exemplary network architectures are illustrated in a simplified manner. For example, an IP sub-network is assumed to have no routing functionality between them, which allows two IPsec tunnels to be shown per peer-to-peer connection (e.g., SCTP association). Thus, each IPSec tunnel will terminate at a separate Security Gateway (SeGW) on the border of the core network, whereas only one SeGW per sub-network will actually be required.

In accordance with an exemplary embodiment of the present invention, message-based path selection for a transport protocol that supports multiple transport paths is generally enabled, i. E. Enabling distribution of messages to different transport paths based on transport properties Means and mechanisms for realizing / realizing the functions of the present invention are provided.

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

As shown in Figure 4, eNB1 and eNB2, which illustrate two communication end points of an SCTP association illustrating a single (logical) peer-to-peer connection, are directly connected to the transport path network and the backhaul transport path . That is, the direct transport path and the backhaul transport path constitute a single (logical) peer-to-peer connection, i.e. SCTP association. The direct transport path and the backhaul transport path have different transport properties (or, in other words, different transport classifications), for example, different delay and bandwidth characteristics. Specifically, the direct transport path has better transport properties as compared to the backhaul transport path, for example, the delay is lower and the bandwidth is higher than those of the backhaul transport path.

According to an exemplary embodiment of the present invention, a message-based route selection mechanism is applied to this exemplary network with multiple transport paths having different transport properties (or, in other words, different transport classification). As will be described in greater detail below, traffic with higher transport requirements (e.g., tighter timing / delay requirements) such as HO-related messages, CA-related messages, CoMP- , While traffic with lower transport requirements (e.g., less stringent timing / delay requirements) is transported through a backhaul transport path with poor transport characteristics. That is, the message-based route selection mechanism according to an exemplary embodiment of the present invention enables the distribution of messages to different transport paths based on the transport characteristics (i.e., message type and / or purpose).

According to an exemplary embodiment of the invention, more than two transport paths may be provided through a single (logical) peer-to-peer connection between the communication endpoints. That is, the present invention is not limited to dual-homing, but is generally applicable to multi-homing having two or more network interfaces per communication end point.

According to an exemplary embodiment of the present invention, any kind of information indicating the nature of the transport path and / or the transport capacity can be adopted as the transport characteristic (i.e., transport classification). Although path delay and path bandwidth are illustrated and illustrated in FIG. 4 by way of example and in the present invention, the present invention is not limited to these specific examples of transport characteristics (i.e., transport classification).

Figure 5 shows a flow diagram illustrating another method in accordance with an exemplary embodiment of the present invention.

As shown in Figure 5, a method according to an exemplary embodiment of the present invention is a method of managing a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths Determining a desired transport property for an application message to be transmitted over a single peer-to-peer connection according to the type of application message; and determining a single peer-to- Selecting one of the plurality of transport paths as a transport path for transmitting an application message over a single peer-to-peer connection, wherein the selected transport path is associated with a determined desired transport property for the application message And have matching (current / actual) transport properties.

Various exemplary procedures are now described for an exemplary use case of an X2 interface connection based on SCTP as an example of a transport protocol supporting multiple transport paths. Any one of the exemplary procedures of Figs. 6 through 8 may be implemented in any (logical) manner over a transport protocol that supports multiple transport paths, such as SCTP between eNBs, eNB1 / eNB2, ) Applicable / operable at any endpoint entity in a peer-to-peer connection.

6 to 8, the transport layer is illustrated as an SCTP layer indicated by "SCTP " and the application protocol interface of the transport layer is represented by an SCTP application protocol interface (API) indicated by" SCTP API & And an application layer is illustrated by the X2 application protocol (AP) indicated by "X2 AP ". The application for the X2 AP may reference the HO, CA and / or CoMP procedures, for example, via the X2 interface.

Figure 6 illustrates a diagram illustrating a first example of a procedure according to an exemplary embodiment of the present invention.

6, the transport characteristics of a plurality of transport paths are obtained in the SCTP API, the preferred transport properties for application messages are determined in the X2 AP, and the transport path for transmitting application messages is SCTP It is selected in the API.

SCTP can acquire information on the transport characteristics (i.e., transport classification) of a plurality of transport paths. This information may be (explicitly) detected by detection (by implicitly) in / by the SCTP itself and / or by detection in / by other entity, application or layer and corresponding notification of the SCTP Or in any other manner. For example, in this regard, timestamps in the HEARTBEAT / HEARTBEAT ACK may be utilized, individual application measurement delays and / or bandwidth may be used, management interfaces may be used, and so on. In addition, SCTP is aware of available transport paths. Accordingly, the SCTP can pass the corresponding information (indicating the available transport paths and their transport properties) to the SCTP API.

The SCTP API can thus obtain the transport properties of multiple transport paths from the SCTP. In addition, the SCTP API may store such received information and may pass corresponding information to the X2 AP indicating the transport characteristics of the available transport path.

In general, in case of a path failure, the SCTP and / or SCTP API can report to the application about the transport properties of the failed transport path, and in case of a path reset, the SCTP and / It should be noted that the transport properties of the port path can be reported to the application.

The above-described functionality of the SCTP and SCTP APIs is not associated with the actual message transmission or message transmission request, for example, in a periodic manner, at the change of the transport path, at the time of connection establishment, .

The X2 AP may determine the desired transport properties for any application messages to be transmitted on a per message basis. Such a determination may be based on the message type and / or purpose, and may depend on any given policy, operating condition, and the like. For example, an X2 AP may determine that a CA-related message or a CoMP-related message has a strict timing / delay requirement while a HO-related message has a generic timing / delay requirement. As a result of this determination, the X2 AP may pass to the SCTP API corresponding information indicative of the desired transport characteristics determined with the application message to be transmitted.

The aforementioned functionality of the X2 AP is associated with the actual message transmission or message transmission request. That is, this functionality is performed on a per-message basis when a message is sent by an associated application.

The SCTP API has previously acquired and stored transport properties of a plurality of transport paths for selecting a transport path for transmitting an application message and has the transport properties for the application message to be transmitted, You can map the properties. In this regard, the SCTP API is a transport path that best suits the desired transport properties for an application message, among the available transport paths (transport properties pre-acquired and stored) (e.g., A transport path having a transport characteristic satisfying the closest to the characteristic, a transport path having the best / best transport characteristic satisfying the preferable transport characteristic, and the like) can be selected. As a result of this mapping / selection, the SCTP API may pass to the SCTP corresponding information indicating the selected / preferred transport path along with the application message to be transmitted.

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

Thus, traffic with higher transport requirements (e.g., a stricter timing / delay request) such as HO-related messages, CA-related messages, CoMP-related messages, etc., While traffic with lower transport requirements (e.g., less stringent timing / delay requirements) can be transported over backhaul transport paths with poor transport characteristics. That is, the message-based route selection mechanism according to an exemplary embodiment of the present invention enables the distribution of messages to different transport paths based on the transport characteristics (i.e., message type and / or purpose).

As described above, according to an exemplary embodiment of the present invention, an application protocol interface of the transport layer, for example the SCTP API, thus allows the application on top of applying a message-based path selection mechanism. This allows the upper layer application to specify the desired transport properties via an application protocol interface of the transport layer, for example the SCTP API, for example via a transport class identifier, a message per application, Is realized in terms of using the specifications for the above. From the application's point of view, there is still only one logical transport connection, but the application is enabled to indicate to the lower transport layer the required transport properties for any application messages to be transmitted. The functionality of the transport layer's application protocol interface, for example, the SCTP API, is enhanced on the per-message basis by additional information received thereon, which allows the transport layer, for example SCTP, To schedule a message for transmission on a specific transport path of an SCTP association, for example. Thus, the application protocol interface of the transport layer, for example the SCTP API, is accomplished without modification / enhancement of the transport layer, e.g. SCTP message definition, because the additional information is internally, Since it is handled only within the transport layer, for example SCTP, and is not communicated to the peer node via the transport layer, for example SCTP association.

Figure 7 illustrates a diagram illustrating a second example of a procedure according to an exemplary embodiment of the present invention.

The exemplary procedure of FIG. 7 is similar to that of FIG. 6, and therefore its detailed description is omitted. The exemplary procedure of FIG. 7 is fundamentally different from that of FIG. 6 in that a message-based path selection mechanism is applied only when requested and / or required.

As shown in FIG. 7, the X2 AP may request message-based path selection on the SCTP API in the case of a request and / or support for different transport classes (classes) of a plurality of transport paths. That is, explicit route selection per message should be enabled when the transport characteristics of multiple available paths are different. These requests can be passed from the X2 AP to the SCTP API and also from the SCTP API to SCTP. Such a request may be issued together, for example, before, after, or - as illustratively shown, a peer-to-peer connection, i.e., a request establishment of an SCTP association.

When the message-based path selection is requested by the X2 AP or is set as a default, the SCTP, as shown in FIG. 7, selects a different transport classification of a plurality of transport paths based on the transport properties of the plurality of transport paths And / or support for the different transport classification of the plurality of transport paths via the SCTP API and notify the X2 AP of the identified request and / or support for the different transport classification of the plurality of transport paths. After establishing the SCTP association, if there is no request and there is a similar / unrelated (for example, due to the fact that the transport properties of all transport paths, for example, only available direct or backhaul transport paths are present) (For example, because there is only one transport path available), the upper application of the SCTP is then sent via the SCTP API Reported. This information may also be provided if, for example, due to a transport path failure, support for different traffic classifications is no longer provided.

It should be noted that the aforementioned identification and notification functionality may be performed by the SCTP API instead of or in conjunction with SCTP. It should also be noted that the sequence of operations illustrated is for illustrative purposes only, while the invention is not so limited. For example, the SCTP obtains the transport characteristics of a plurality of transport paths, identifies (at least in part) simultaneously or in parallel the requirements and / or support for different transport classifications of the plurality of transport paths, Or the SCTP may pass / notify the SCTP API with corresponding information or results in a different message in a different order.

As a result of this identification of the need for and / or support for different transport classification of the plurality of transport paths by the SCTP and / or SCTP APIs, the determination of the desired transport properties for application messages by the X2 AP, The selection of the transport path for transmitting the application message by means of the transport message can only be performed when it is required, i.e. only when a request and / or support for different transport classification of the plurality of transport paths is identified.

Figure 8 illustrates a diagram illustrating a third example of a procedure according to an exemplary embodiment of the present invention.

The exemplary procedure of FIG. 8 is similar to that of FIG. 6, and therefore its detailed description is omitted. The exemplary procedure of Figure 8 is similar to that of Figure 6 in that the X2 AP not only determines the desired transport properties for the application message but also includes information indicating the determined desired transport properties for the application message within the application message itself It is fundamentally different. Including this information in the application message itself, as described below, may allow both communication nodes of the peer-to-peer connection to behave in a fully transparent manner effectively.

As shown in FIG. 8, the X2 AP may determine the desired transport properties for any application messages to be transmitted on a per-message basis, and may provide corresponding information indicative of the determined desired transport properties for the application message . Next, the X2 AP may pass to the SCTP API the corresponding information indicating the desired transport properties determined together with the application message to be transmitted (including information indicating the desired transport properties thereof).

After mapping / selection, the SCTP API may pass to the SCTP corresponding information indicating the selected / preferred transport path along with the application message to be transmitted (including information indicating the desired transport properties thereof). The SCTP can then send an application message (including information indicative of its desired transport properties) on the selected / preferred transport path among the available transport paths of the peer-to-peer connection.

According to an exemplary embodiment of the present invention, information indicative of the desired transport characteristics may be included in each application message using a specific / dedicated information element.

An exemplary implementation within the X2 AP is to add an additional optional information element (IE) to the message definition in the 3GPP specification TS 36.423 to indicate the desired transport properties.

The specification of a suitable X2 message for a message-based path selection mechanism according to an exemplary embodiment of the present invention includes additional IEs such as "TL path delay" and / or "TL path bandwidth" (The delay and bandwidth are assumed to be used as exemplary transport properties).

IE "TL path delay" can be used to indicate the desired transport path delay, and can be specified in section 9.2.x, for example as follows.

The TL path delay may be defined as the relative quantization of the path delay, e.g., as described below.

As is apparent from the IE of the example above, in the case of a dual-homing SCTP association, the two transport paths can be classified as "high" and "normal" when using a relative delay metric, for example as a differentiator.

Instead of using relative quantization of path delays, the TL path delays may be defined as fractional quantization of path delays, e.g., as described below. In this regard, the path delay may preferably be represented as a fractional value compared to the path delay of the lowest speed transport path from the available transport path.

The IE "TL path bandwidth" is used to indicate the desired transport path bandwidth, and can be specified, for example, in section 9.2.y as follows.

The TL path bandwidth can be defined as the relative quantification of the path bandwidth, e.g., as described below.

As is apparent from the IE of the example above, in the case of a multi-homing SCTP association, the various transport paths can be classified as a multiple of bandwidth or a fraction, for example, when using a relative bandwidth metric as a differentiator.

As indicated above, other transport properties other than path delay and path bandwidth may be equally used. In this case, the corresponding IE / IEs may be introduced in a line in the above example accordingly. Further, while the above example refers to path / latency and relative / fractional quantification of path bandwidth, the absolute value may equally be used for path delay and / or path bandwidth, or any other relevant transport characteristics.

An implementation based on introducing any one of the additional IEs provides information to the peer node about the transport path characteristics selected by the source node. This can ensure the same use of the transport path by both peers of the (logical transport) connection. That is, the transport properties of the selected transport path on which the application message is received may be obtained using information indicating the determined preferred transport properties included in the received application message (e.g., corresponding IE / IEs) . Thus, the receiving node may be aware of and act upon the desired transport characteristics and thus the selected transport path by the transmitting node.

Accordingly, when the application generating the message provides the information of the selected transport property, the application message carries the information of the selected transport property, and the selected transport property when the application message is passed to the transport layer, A completely transparent behavior of both communication nodes of the peer-to-peer connection can be achieved, in that it is specified in the application protocol interface of the SCTP API, for example, in the SCTP API. This improves the functionality of the transport layer application protocol interface, for example, the SCTP API.

According to an exemplary embodiment of the present invention, the above-described implementation based on introducing additional IE provides information to the peer node about the transport path characteristics selected by the source node. However, since SCTP needs to have application-independent information about the desired transport path, the SCTP API is accordingly adapted to receive this information from the X2 AP (thus irrespective of the actual content of the application message). The application will set this SCTP API value according to the specification of the message to be transmitted.

Within the SCTP association established between one eNB pair, as specified in Section 7 of 3GPP specification TS 36.422:

- should be reserved for the sole use of the X2 AP basic procedure using non-UE-associated signaling,

- at least a pair of stream identifiers should be reserved for the sole use of the X2 AP basic procedure using UE-associated signaling, but some pairs (i.e. more than one)

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

In a dual-homing SCTP association (assuming equally applicable for extended X2 AP functionality for CA and CoMP features) based on this description, the application may be able to determine whether the UE- , While non-UE associated signaling is to be sent over the "normal" path. Based on information on the transport characteristics of the different transport paths, the application requests a "high" path as the primary path in the SCTP. This is consistent with the current SCTP specification.

Based on the described use of the SCTP stream, a possible implementation without any effect on the X2 ASN.1 definition is to specify that the "high" path is always used if a message sent on the UE- . Transmitted messages on non-UE associated streams should use the "normal" (or slower) path. According to the default SCTP behavior, it can be implemented within SCTP by sending a message on a stream that is flagged or known as "high" via the primary path consistent with the standard SCTP behavior. Messages on streams that are flagged or known as "normal " will obtain exceptional processing with respect to the default SCTP behavior, since they will not be transmitted over the primary path. If only a few of these messages intended for the "normal" path are present, this may be implemented in standard-compliant SCTP, for example, by changing the primary path for a short time interval until the message is transmitted.

According to an exemplary embodiment of the present invention, as is apparent from the above, message-based path selection for a transport protocol supporting multiple transport paths, i.e. distribution of messages to different transport paths based on transport properties Can be realized / enabled.

Thus, a single (logical) peer-to-peer connection, such as the X2 transport, is secured and the communication node can determine from which transport path a given message is to be properly transmitted. This is true for network architectures that combine backhaul transport paths and direct transport paths across the core network to form a single (logical) peer-to-peer connection, such as an SCTP association, Lt; RTI ID = 0.0 > SCTP < / RTI & If this situation is recognized, the SCTP can be reported on the transport characteristics of the different transport paths. The SCTP is then enabled to transport data messages (DATA chunks) in accordance with the transport characteristics (i.e., transport classification) determined by the associated application via the transport path thus classified. Applications that generate messages with different transport requests continue to have only one logical transport connection. In addition, the application recognizes the presence of different transport properties for different transport paths forming a given SCTP association, and displays the requested transport properties (i. E., Transport classification) when passing the message to the transport layer It is possible. The new information element may be added to the application message to also report to the peer node for the additional selected transport properties (i.e., transport classification). This can ensure the same use of the transport path by both peers of the (logical transport) connection.

Via a message-based path selection for a transport protocol supporting multiple transport paths according to an exemplary embodiment of the present invention, the X2 application protocol may, for example, in addition to a handover procedure, such as CA and / or CoMP Can be extended to support inter-eNB features. That is, based on their message type and / or purpose, CA- and / or CoMP-related messages may be separated from other traffic and transported over a specific transport path in accordance with their (more stringent) transport requirements have.

The above-described methods, procedures, and functions may be implemented by respective functional elements, entities, modules, units, processors, etc., as described below.

Although the foregoing exemplary embodiments of the present invention have been described primarily with reference to methods, procedures, and functions, the corresponding exemplary embodiments of the present invention also encompass each of the devices, entities, modules , Units, network nodes and / or systems.

Each exemplary embodiment of the present invention is described below with reference to Figures 9 and 10, but for the sake of brevity, each corresponding configuration / setup, scheme, method, and functionality, principles, And a detailed description of the operation are referenced.

In Figures 9 and 10, the block is basically configured to perform each method, procedure and / or function as described above. The entire blocks are each basically configured to perform the methods, procedures and / or functions as described above. With reference to Figures 9 and 10, it should be noted that the individual blocks are intended to illustrate each functional block that implements each function, process, or procedure, respectively. These functional blocks are implementation-independent, that is, they may be implemented by each type of hardware or software, or a combination thereof.

9 and 10, only those functional blocks relating to any one of the above-described methods, procedures and / or functions are illustrated. One skilled in the art will recognize the presence of any other conventional functional blocks required for operation of each structural configuration, such as, for example, a power supply, a central processing unit, a respective memory, and the like. Among others, one or more programs for storing or controlling program or program instructions for controlling or enabling individual functional entities or any combination thereof to operate as described herein with respect to the exemplary embodiment. / RTI >

Figure 9 shows a schematic diagram illustrating an example of a structure of an apparatus according to an exemplary embodiment of the present invention.

As shown in FIG. 9, according to an exemplary embodiment of the present invention, the apparatus 10 comprises at least one processor 11 and at least one processor 11, which may be operatively connected or coupled, respectively, One memory 12 (and possibly also at least one interface 13).

The processor 11 and / or interface 13 of the device 10 may also include a modem or the like, respectively, to facilitate communication over a (wired or wireless) link. The interface 13 of the device 10 may be implemented as one or more antennas, such as an antenna unit, such as an antenna array, or a communication device, such as a device for each (wired or wireless) communication with a linked, Or a suitable transmitter, receiver, or transceiver coupled to or coupled to the base station. The interface 13 of the device 10 is generally configured to communicate with at least one other device, device, node or entity (in particular, its connector).

The memory 12 of the device 10 represents a (non-temporary / tangible) storage medium and, when executed by each processor, indicates that each electronic device or device operates in accordance with an exemplary embodiment of the present invention A program product, a macro or an applet, etc., or portions thereof, which may be taken to include program instructions or computer program code that enable the computer to perform the functions described herein.

In general, each device (and / or portion thereof) may represent a means for performing each operation and / or representing each function, and / or each device (and / or portion thereof) And may have functions for performing each operation and / or representing each function.

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

In the following description, when a processor (or some other means) is referred to as being configured to perform some function, it may potentially be stored in the memory of the respective device, or in cooperation with other available computer program code It should be understood that the memory may also be external memory or may be provided / realized by a cloud service, etc.), one (i. E., At least one) processor or corresponding circuit may perform the function The present invention is not limited thereto.

The device 10 thus illustrated may represent or implement / implement a communication (control) entity or a node (part of) in accordance with an exemplary embodiment of the present invention, such as eNB1 or eNB2 of Figure 4, 5 to 8 and / or may be configured to perform the procedure.

The device 10 or the device 10 or its processor 11 (possibly with the computer program code stored in the memory 12) is in its most basic form a trans- To obtain (current / actual) transport characteristics of a plurality of transport paths of a single peer-to-peer connection over a port protocol, through a single peer-to-peer connection depending on the type of application message Determining one or more of the plurality of transport paths of a single peer-to-peer connection as a transport path for transmitting application messages over a single peer-to-peer connection, , And the selected transport path is configured to cause the determined preferred < RTI ID = 0.0 > It has the (current and / or physical) transport properties that meet the transport characteristics.

For further details regarding the operation / functionality of an individual device or its layer according to an exemplary embodiment of the present invention, reference is made to the above description with respect to any one of Figs. 4-8.

As described above, any device in accordance with an exemplary embodiment of the present invention may be structured by including respective means for performing corresponding actions, procedures, and / or functions. For example, such means may be based on a device structure as illustrated in FIG. 9, i.e., by one or more processors 11, one or more memories 12, one or more interfaces 13, Can be implemented / realized.

10 shows a schematic diagram illustrating another example of a structure of an apparatus according to an exemplary embodiment of the present invention.

As shown in FIG. 10, an apparatus 1000 according to an exemplary embodiment of the present invention may be operable as a communication (control) entity or node. Unit 100 may be represented or operable as an application layer such as an X2 AP and the portion / unit 200 may be represented or operable as an application protocol interface of a transport layer, such as an SCTP API And the part / unit 300 may be represented or operable as a transport layer, such as SCTP.

Apparatus 1000 includes means for obtaining (current / actual) transport characteristics of a plurality of transport paths in a single peer-to-peer connection via a transport path that supports multiple transport paths Means for determining a desired transport characteristic for an application message to be transmitted over a single peer-to-peer connection according to the type of application message (referred to as transport characteristic acquisition means 210 in that portion / RTI > as a transport path for transporting application messages over a single peer-to-peer connection) and a plurality of (At least) means for selecting one of the transport paths, wherein the selected transport path is a determined desired path for the application message (Shown as a transport channel selection means 220 in that part / unit 200) (current / physical) transport properties consistent with the spot has a characteristic.

According to an exemplary embodiment, as described above, the apparatus 1000 may obtain transport properties of a plurality of transport paths of a single peer-to-peer connection through a transport protocol that supports multiple transport paths (Referred to as transport characteristic acquisition means 310 in that part / unit 300) and means for passing information indicating the obtained transport characteristics of the plurality of transport paths to the application protocol interface of the transport layer Unit (indicated as the transport characteristic information path means 350 in the part / unit 300).

According to an exemplary embodiment, as described above, the apparatus 1000 includes means for passing information indicative of the acquired transport properties of a plurality of transport paths to an application layer (information in that portion / unit 200) Means for passing an application message from the application layer to the application protocol interface of the transport layer with the information indicating the determined desired transport properties, Message and information path means 120), and the acquired transport properties of a plurality of transport paths for selecting a transport path for an application message on an application protocol interface of the transport layer and the determined desired transport properties Means for mapping That the / unit indicated as transport characteristic mapping unit 240 in 200) it may further comprise a should be noted.

In accordance with an exemplary embodiment, device 1000 includes means for passing an application message to a transport layer with information indicative of a selected transport path (information / message in that portion / unit 200) Path unit 230), and means for sending an application message on the selected transport path of the peer-to-peer connection (indicated as application message transceiver 350 in that portion / unit 300) It should be noted that it can be additionally included.

According to an exemplary embodiment, as described above, the device 1000 may include a message (e.g., a message) on the application protocol interface of the transport layer in the case of a request and / or support of different transport classification of the plurality of transport paths by the application layer - means for requesting a route selection based on the obtained transport properties of the plurality of transport paths (referred to as route selection request means 130 in the part / unit 100) A classification request / support identification means 250 in the part / unit 200 and / or a classification request / support identification means 250 in the part / unit 300 for identifying a request and / (Indicated as 330), to notify the application layer of the identified request and / or support for different transport classification of the plurality of transport paths (Indicated as classification request / support notification means 260 in that part / unit 200 and / or classification request / support notification means 340 in that part / unit 300) It should be noted.

According to an exemplary embodiment, as described above, the apparatus 1000 includes means for including information indicating the determined desired transport properties for an application message in an application message on an application layer Means for transmitting an application message including information indicative of the determined preferred transport characteristics on the selected transport path of the peer-to-peer connection, And an application message transmission / reception unit 350 in the mobile communication system 300).

According to an exemplary embodiment of the invention, any one of the processor, memory and connector, as well as any one of the means, can be implemented as a separate module, chip, chipset, circuit, etc., Module, chip, chipset, circuit, etc., respectively.

According to an exemplary embodiment of the present invention, the system may include any recognizable combination of such depicted devices / devices and other network elements configured to cooperate as described above.

In general, it is noted that each functional block or element in accordance with the above described aspects may be implemented by any known means in hardware and / or software, respectively, only if applied to perform the described function of each part . The mentioned method steps may be realized in a separate functional block or by an individual device, or one or more of the method steps may be realized in a single functional block or by a single device.

In general, any method steps are suitable to be implemented as software or hardware without changing the spirit of the present invention. Such software may be software code independent and may be any known or future developed programming such as, for example, Java, C ++, C, and Assembler, as long as the functionality defined by the method steps is preserved. ≪ / RTI > language. Such hardware may be hardware-type independent and may be, for example, an ASIC (Application Specific Integrated Circuit) component, a Field-programmable Gate Arrays (FPGA) component, a Complex Programmable Logic Device (CPLD) Signal Processor) components, it is possible to use a semiconductor device such as a MOS (Metal Oxide Semiconductor), a CMOS (Complementary MOS), a BiMOS (Bipolar MOS), a BiCMOS (Bipolar CMOS), an Emitter Coupled Logic (ECL), a Transistor-Transistor Logic And may be implemented using any known or future developed hardware technology or any combination thereof. The device / device may be represented by a semiconductor chip, a chipset, or a (hardware) module including such a chip or chipset, but this is not intended to imply that the functionality of the device / But does not preclude the possibility of being implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions to be executed. The devices may be regarded, for example, as a device / device or as an assembly of more than one device / device, whether functionally or functionally independent, but in the same device housing, in cooperation with each other.

The device and / or means or portions thereof may be implemented as discrete devices, but this does not preclude that they may be implemented in a distributed manner throughout the system as long as the functionality of the device is preserved. These and similar principles should be considered as known to those skilled in the art.

In the context of this description, the software may comprise code means or portions for performing the respective functions or software codes such as those comprising a computer program or a computer program product, as well as potentially any data structure or code means / (Or a computer program or computer program product) on a tangible medium, such as a computer readable medium, stored on or in a signal or embodied in a chip.

The present invention also contemplates any recognizable combination of the above-described method steps and operations, any recognizable combination of the nodes, devices, modules or elements described above, as long as the above-described concepts of the methodologies and structural arrangements are applicable do.

In view of the above, there is provided a message-based path selection for a transport protocol supporting multiple transport paths, i.e. means for enabling / realizing the distribution of messages to different transport paths based on the transport properties do. Such means may include, by way of example, obtaining the transport characteristics of a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths, To-peer connection as a transport path for sending application messages over a single peer-to-peer connection, and determining a desired transport property for the application message to be transmitted over a single peer- Selecting one of the plurality of transport paths of the connection, wherein the selected transport path has a transport property that matches the determined desired transport property for the application message.

Although the present invention has been described above with reference to examples according to the accompanying drawings, it should be understood that the present invention is not limited thereto. Rather, it is obvious to those skilled in the art that the present invention may be modified in many ways without departing from the scope of the inventive concept as disclosed herein.

3GPP: 3rd Generation Partnership Project AP: Application Protocol
API: Application Protocol Interface
ASN.1: Abstract Syntax Notation 1 CA: Carrier Aggregation
CoMP: Cooperative / Coordinated Multipoint 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: Request for Comments (ie, IETF specification)
SCTP: Stream control transmission
SeGW: Secure Gateway TCP: Transmission Control Protocol
TL: Transport layer UE: User equipment

Claims (23)

Obtaining a transport characteristic of a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths,
Determining a desired transport property for the application message to be transmitted over the single peer-to-peer connection according to the type of application message;
Selecting one of the plurality of transport paths of the single peer-to-peer connection as a transport path for transmitting the application message over the single peer-to-peer connection, Wherein the path has a transport property consistent with the determined preferred transport property for the application message
Way.
The method according to claim 1,
Wherein a transport property of the plurality of transport paths is obtained on an application protocol interface of a transport layer, a desired transport property for the application message is determined on an application layer, Selected on the application protocol interface of the transport layer
Way.
3. The method of claim 2,
Transferring information indicating the obtained transport characteristics of the plurality of transport paths to the application layer;
Transferring the application message from the application layer to the application protocol interface of the transport layer with information indicating the determined desired transport characteristic;
Further comprising mapping the determined desired transport properties with the obtained transport properties of the plurality of transport paths to select a transport path for the application message on the application layer protocol of the transport layer
Way.
The method of claim 3,
Forwarding the application message to the transport layer with information indicating the selected transport path;
Further comprising transmitting the application message to a selected transport path of the peer-to-peer connection
Way.
5. The method according to any one of claims 2 to 4,
Requesting message-based path selection on an application protocol interface of the transport layer when the application layer performs one or more of the request and support of different transport classes of the plurality of transport paths;
Identifying one or more of a request and support for different transport classifications of the plurality of transport paths based on the obtained transport properties of the plurality of transport paths;
And notifying the application layer of one or more of a request and support for different transport classification of the identified plurality of transport paths
Way.
6. The method of claim 5,
A preferred transport property for the application message is determined on the application layer and a transport path for transmitting the application message is identified when one or more of the request and support for different transport classes of the plurality of transport paths are identified Is selected on the application protocol interface of the transport layer only
Way.
7. The method according to any one of claims 1 to 6,
Including in the application message information representative of the determined desired transport characteristic for the application message on the application layer,
And sending the application message including information indicating the determined preferred transport characteristic to a selected transport path of the peer-to-peer connection
Way.
8. The method according to any one of claims 1 to 7,
The transport property of the selected transport path receiving an application message is obtained using information indicating the determined desired transport property included in the received application message
Way.
9. The method according to any one of claims 1 to 8,
Wherein the transport property comprises at least one of absolute, relative and fractional quantification of path delays and absolute or relative quantification of path bandwidths,
Wherein the transport protocol supporting the multiple transport path comprises a Stream Control Transmission Protocol (SCTP) or a Multi-Path Transmission Control Protocol (MP-TCP).
Way.
10. The method according to any one of claims 1 to 9,
The peer-to-peer connection forms an interface between two communication control entities of the communication system
Way.
11. The method of claim 10,
Wherein the plurality of transport paths comprise at least one direct transport path between the two communication control entities and at least one backhaul transport path,
Wherein the type of 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 / harmonized multipoint communication
Way.
A processor,
An apparatus comprising a memory for storing computer program code,
The processor may cause the device to:
Obtaining transport properties of a plurality of transport paths of a single peer-to-peer connection through a transport protocol supporting multiple transport paths,
Determine a desired transport property for an application message to be transmitted over the single peer-to-peer connection according to the type of application message,
Selecting one of the plurality of transport paths of the single peer-to-peer connection as a transport path for transmitting the application message over the single peer-to-peer connection, the selected transport path And having a transport property consistent with the determined preferred transport property for the application message
Device.
13. The method of claim 12,
The processor may cause the device to:
Acquiring a transport property of a plurality of transport paths on an application protocol interface of the transport layer,
Determining a desired transport property for the application message on an application layer,
To select a transport path for transmitting the application message on an application protocol interface of the transport layer
Device.
14. The method of claim 13,
The processor may cause the device to:
Transferring information indicating the obtained transport properties of the plurality of transport paths to the application layer,
Transferring the application message from the application layer to the application protocol interface of the transport layer with the information indicating the determined desired transport property,
To map the determined preferred transport properties to the acquired transport properties of the plurality of transport paths to select a transport path for the application message on the application layer protocol of the transport layer
Device.
15. The method of claim 14,
The processor may cause the device to:
Transfers the application message to the transport layer together with information indicating the selected transport path,
To transmit the application message to the selected transport path of the peer-to-peer connection
Device.
16. The method according to any one of claims 13 to 15,
The processor may cause the device to:
Requesting message-based path selection on an application protocol interface of the transport layer when the application layer performs one or more of the request and support of different transport classes of the plurality of transport paths,
Identify one or more of a request and support for different transport classes of the plurality of transport paths based on the acquired transport properties of the plurality of transport paths,
And notifying the application layer of at least one of a request and support for different transport classification of the identified plurality of transport paths
Device.
17. The method of claim 16,
The processor may cause the device to:
Determining a desired transport property for the application message on the application layer,
To select a transport path for transmitting the application message on an application protocol interface of the transport layer only when one or more of the request and support for different transport classes of the plurality of transport paths is identified
Device.
18. The method according to any one of claims 12 to 17,
The processor may cause the device to:
Comprising: in the application message, information indicating the determined desired transport characteristic for the application message on the application layer,
To transmit the application message including information indicating the determined desired transport characteristic to the selected transport path of the peer-to-peer connection
Device.
19. The method according to any one of claims 12 to 18,
The processor may cause the device to:
Using the information indicating the determined desired transport characteristic included in the received application message to obtain the transport property of the selected transport path to receive the application message
Device.
20. The method according to any one of claims 12 to 19,
Wherein the transport property comprises at least one of absolute, relative and fractional quantification of path delays and absolute or relative quantification of path bandwidths,
Wherein the transport protocol supporting the multiple transport path comprises a Stream Control Transmission Protocol (SCTP) or a Multi-Path Transmission Control Protocol (MP-TCP).
Device.
21. The method according to any one of claims 12 to 20,
The peer-to-peer connection forms an interface between two communication control entities of the communication system
Device.
22. The method of claim 21,
Wherein the plurality of transport paths comprise at least one direct transport path between the two communication control entities and at least one backhaul transport path,
Wherein the type of application message includes at least one of a message type relating to handover, a message type relating to carrier aggregation, and a message type relating to collaborative / harmonized multipoint communication
Device.
15. A computer program product comprising computer executable computer program code, the computer program code being executable on a computer to cause the computer to perform the method according to any one of claims 1 to 11
Computer program products.

Images