B Hesmans

H Tran-Viet

R Sadre

O Bonaventure

A first look at real Multipath TCP traffic

Multipath TCP is a new TCP extension that attracts a growing interest from both researchers and industry. It enables hosts to send data over several interfaces or paths and has use cases on smartphones, datacenters or dual-stack hosts. We provide the first analysis of the operation of Multipath TCP on a public Internet server based on a one-week long packet trace. We analyse the main new features of Multipath TCP, namely the utilisation of subflows, the address advertisement mechanism, the data transfers and the reinjections and the connection release mechanisms. Our results confirm that Multipath TCP operates correctly over the real Internet, despite the presence of middleboxes and that it is used over very heterogeneous paths.

Introduction

The Transmission Control Protocol (TCP) [START_REF] Postel | Transmission Control Protocol[END_REF] was designed when hosts were equipped with a single interface. When two hosts exchange data through a TCP connection, all packets generated by the client (resp. server) must be sent from the same IP address. This remains true even if the communicating hosts have several interfaces and thus IP addresses that could be used to improve performance or resilience. In today's networks, this limitation is becoming a major drawback. Cellular and WiFi networks are available in most cities and smartphone users would like to be able to start a TCP connection in a WiFi hotspot and continue it later via their 3G interface. Reality with TCP is different [START_REF] Paasch | Exploring Mobile/WiFi Handover with Multipath TCP[END_REF]. Datacenters provide multiple paths between servers, but all packets from a given connection always follow the same path [START_REF] Raiciu | Improving Datacenter Performance and Robustness with Multipath TCP[END_REF]. Dual stack hosts would like to exploit their IPv6 and IPv4 paths simultaneously but with regular TCP they can only rely on Happy Eyeballs [START_REF] Wing | Happy Eyeballs: Success with Dual-Stack Hosts[END_REF].

Multipath TCP (MPTCP) is a recent TCP extension that has been standardised by the Internet Engineering Task Force [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF] to solve this problem. In a nutshell, thanks to Multipath TCP, a multihomed host can use several interfaces (and thus IP addresses) to support a single TCP connection. Multipath TCP can pool all the resources available to improve the performance and the resilience of the service provided to the applications [START_REF] Wischik | The Resource Pooling Principle[END_REF]. Several use cases for Multipath TCP have already been studied by the research community including datacenters [START_REF] Raiciu | Improving Datacenter Performance and Robustness with Multipath TCP[END_REF] and WiFi/3G offload [START_REF] Paasch | Exploring Mobile/WiFi Handover with Multipath TCP[END_REF][START_REF] Chen | A Measurement-based Study of Multipath TCP Performance over Wireless Networks[END_REF][START_REF] Deng | WiFi, LTE, or Both?: Measuring Multi-Homed Wireless Internet Performance[END_REF]. Implementers and industry are adopting Multipath TCP quickly. As of this writing, Multipath TCP implementations exist on Linux [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF], Apple iOS and MacOS [START_REF]Apple. ios: Multipath tcp support in ios 7[END_REF], FreeBSD [START_REF] Williams | FreeBSD kernel patch for Multipath TCP[END_REF] and Solaris [START_REF] Eardley | Survey of MPTCP Implementations[END_REF]. Apple has enabled Multipath TCP by default for its voice recognition SIRI application running on all recent iPhones and iPads. Today, there are thus hundreds of millions of devices that use Multipath TCP on the Internet.

Despite of this large scale deployment, little is known about how Multipath TCP really behaves in the global Internet. In this paper, we provide a first analysis of the Multipath TCP packets received and sent by the server that hosts the reference implementation in the Linux kernel 1 . Besides Apple's servers that support the SIRI application, this is probably the most widely used public Multipath TCP server. By observing how real users use this new protocol, we complement the existing measurement that relied on simulations, emulations or active measurements.

This paper is organised as follows. In Section 2, we describe our dataset, how the packets have been collected and the software that we used to analyse them. Section 3 describes the main features of the Multipath TCP protocol and analyses their impact based on the collected packets. Section 4 compares our work with related work. We conclude the paper in Section 5.

Dataset

The dataset2 used in this paper is a one-week long packet trace collected in November 2014 at Université catholique de Louvain (UCL). It has been collected using tcpdump and contains the headers of all TCP packets received and sent by the server hosting the Multipath TCP Linux kernel implementation. Apart from a web server, the machine also hosts an FTP server and an iperf server. It has one physical network interface with two IP addresses (IPv4 and IPv6) and runs the stable version 0.89 of the Multipath TCP implementation in the Linux kernel [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF].

To analyse the Multipath TCP connections in the dataset, we have extended the mptcptrace software [START_REF] Hesmans | Tracing Multipath TCP Connections[END_REF] developed by the same authors. mptcptrace handles all the main features of the Multipath TCP protocol and can extract various statistics from a packet trace. Our extensions to mptcptrace have been included in the last release. Furthermore, we have combined it with tcptrace [START_REF] Ostermann | tcptrace[END_REF] and its output has been further processed by custom python scripts.

Table 1 summarizes the general characteristics of the dataset. In total, the server received around 136 million TCP packets carrying 134 GiBytes of data (including the TCP and IP headers) during the measurement period. As shown in table 1 (in the block "Multipath TCP"), a significant fraction of the TCP traffic was related to Multipath TCP. Unsurprisingly, IPv4 remains more popular than IPv6, but it is interesting to note that the fraction of IPv6 traffic from the hosts that are using Multipath TCP (9.8%) is larger than from the hosts using regular TCP (3.7%). On the monitored server, dual-stack hosts are already an important use case for Multipath TCP. It should be noted that the monitored server is mainly used by Multipath TCP users and developers who are likely to be researchers or computer scientists. These users probably have better connectivity that the average Internet user.

We have also studied the application protocols used in the Multipath TCP traffic. Around 22.7% of the packets were sent or received on port 80 (HTTP). A similar percentage of packets (21.2%) was sent to port 5001 (iperf) by users conducting throughput measurements. The FTP server, was responsible for the majority of packets. It hosts the Debian and Ubuntu packages for the Multipath TCP kernel and is thus often used by Multipath TCP developers.

Considering the number of connections, 89.7% of them were targeted on HTTP, 6.4% for iperf, 1.9% for FTP control connections and the remaining 2.0% on higher ports are likely FTP data connections.

Another important figure is the number of distinct Multipath TCP clients connected to our server. While identifying this figure exactly is not trivial, information about client IP addresses may be useful to give some feeling about the variety of clients' location. Among 790 distinct client IP addresses we observed, there are 562 IPv4 addresses coming from 464 distinct class C IPv4 network prefixes and 228 different IPv6 addresses coming from 79 distinct 48-bit IPv6 prefixes.

Analysis

Multipath TCP is a major extension to TCP that modifies many features of the protocol. A detailed overview of Multipath TCP is outside the scope of this paper and may be found in [START_REF] Paasch | Multipath TCP[END_REF][START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. In this section, we first describe the key features of Multipath TCP. Then, each subsection focuses on a particular aspect of the protocol that is explained and analysed in more details based on the collected packet trace.

Like most TCP extensions, Multipath TCP defines a new TCP option that is used during the initial three-way handshake. This MP CAPABLE option contains several important parameters [START_REF] Paasch | Multipath TCP[END_REF][START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. A prominent characteristic of Multipath TCP is that, to be able to use several paths, Multipath TCP combines several TCP connections called subflows inside a single Multipath TCP connection. These subflows are linked together by using a token extracted from the MP CAPABLE option and included in the MP JOIN option that is exchanged during the handshake of the other subflows. To support mobile hosts, Multipath TCP allows each host to advertise its current list of addresses to its peer [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. This is done thanks to the ADD ADDR and REMOVE ADDR options that can be sent at any time over one of the TCP subflows. It is important to note that the subflows that compose a Multipath TCP connection is not fixed. The set of subflows changes during the lifetime of the connection since each host can add or remove a subflow at any time.

Which hosts use Multipath TCP?

The first question that we asked ourselves while analysing the trace was the characteristics of the clients that contacted the monitored server. Since the packet trace was collected on the server that hosts the Multipath TCP implementation in the Linux kernel, we can expect that many Linux enthusiasts use it to download new versions of the code, visit the documentation, perform tests or verify that their configuration is correct. These users might run different versions of Multipath TCP in the Linux kernel or on other operating systems [START_REF] Eardley | Survey of MPTCP Implementations[END_REF]. Unfortunately, as of this writing, there is not enough experience with the Multipath TCP implementations to detect which operating system was used to generate specific Multipath TCP packets. This is an interesting direction for future work. Instead, we focus our analysis on the number of addresses used by the clients.

Thanks to the ADD ADDR option, it is possible to collect interesting data about the characteristics of the clients that contact our server. Over the 5098 observed Multipath TCP connections, 3321 of them announced at least one additional address. Surprisingly, only 21% of the collected IPv4 addresses in the ADD ADDR option were globally routable addresses. The remaining 79% of the IPv4 addresses found in the ADD ADDR option were private addresses and in some cases link-local addresses. The large number of private address confirms that Multipath TCP's ability to pass through NATs is an important feature of the protocol [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF].

The IPv6 addresses collected in the ADD ADDR option had more diversity. We first observed 72% of globally routable IPv6 addresses. The other types of addresses that we observed are shown in Table 2. The IPv4-compatible and the 6to4 IPv6 addresses were expected, but the link local and documentation addresses should have been filtered by the client and never be announced over Multipath TCP connections. The Multipath TCP specification [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF] does not currently specify the types of addresses that can be advertised over a Multipath TCP connection. It should probably be updated to specify which types of IPv4 and IPv6 addresses can be announced with the the ADD ADDR option.

Another interesting point to note is that although the ADD ADDR option defined in [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF] can also be used to advertise transport protocol port numbers together with IP addresses, we didn't detect any utilisation of this feature in our trace. 3.2 How quickly are subflows established?

The previous section has shown that a large number of (multihomed) hosts exchange Multipath TCP packets with our server. Our server has a single interface but two IP addresses (IPv4 and IPv6). Like the other Multipath TCP implementations [START_REF] Eardley | Survey of MPTCP Implementations[END_REF], it never creates subflows [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF] because, as confirmed by the measurements in the previous section, the client is likely to reside behind a NAT or a firewall that would block these subflow establishments.

The current implementation of Multipath TCP in the Linux kernel [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF] uses two strategies to create subflows. The first strategy, supported by the default path manager on multihomed hosts, is to create a full-mesh of subflows as soon as possible. Figure 1 shows the delay between the SYN segment sent on the initial subflow and the SYN segment of the first subflow. For 88.9% of the Multipath TCP connections composed of two or more subflows, the first subflow is established within less than one second. For 46.5% of the connections, this delay is shorter than 100 msec. The longest delay between the establishment of a Multipath TCP connection and the first subflow is 360 seconds. For test purposes and to support local balancing over multiple equal cost paths [START_REF] Raiciu | Improving Datacenter Performance and Robustness with Multipath TCP[END_REF], another path manager can be used on single-homed hosts. This path manager creates n subflows from the single IP address of the client to the server. An analysis of all the observed Multipath TCP connections indicates that this path manager was used by about one third of the connections that we observed.

Multipath TCP can also support backup subflows [START_REF] Paasch | Exploring Mobile/WiFi Handover with Multipath TCP[END_REF]. In this case, the client indicates that a subflow is a backup subflow at subflow establishment time or by sending the MP PRIO option on an existing subflow. In the analysed trace, we did not observe any utilisation of this option.

When Multipath TCP is used over heterogeneous paths, its performance can decrease if the paths have different round-trip-times or bandwidth [START_REF] Paasch | On the Benefits of Applying Experimental Design to Improve Multipath TCP[END_REF]. Figure 2 plots, for all Multipath TCP connections using two or more subflows, the CDF of the difference between the minimum and the maximum average round-triptimes over all the subflows that compose each Multipath TCP connection. These average round-trip-times were computed by using tcptrace [START_REF] Ostermann | tcptrace[END_REF]. Less than 10% of the Multipath TCP connections have subflows having the same average roundtrip-times. Almost 54.3% of the Multipath TCP connections combine subflows with a spread of up to 10 msec. 13.7% of the connections have a spread larger than 50 msec. This is an important indication about the heterogeneity of the paths over which Multipath TCP is used today. In theory, a Multipath TCP connection can gather an unlimited number of subflows. In practice, implementations [START_REF] Eardley | Survey of MPTCP Implementations[END_REF] limit the number of concurrent subflows.

The Linux implementation [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF] used on the monitored server can support up to 32 different subflows. We analyse here the number of subflows that are established for each Multipath TCP connection. Since our server never establishes subflows, this number is an indication of the capabilities of the clients that interact with it.

Figure 3 provides the distribution of the number of subflows per Multipath TCP connection. We show the distribution for the number of successfully established subflows, i.e., subflows that complete the handshake, as well as for all attempted ones. As can be seen, several connection attempts either fail completely or establish less subflows than intended. In total, we observe 5098 successful connections with 8701 subflows. The majority of the observed connections (57%) only establish one subflow. Around 27% of them use two subflows. Only 10 connections use more than 8 subflows, which are omitted from the figure. The fact that many Multipath TCP connections establish more than one subflow affects the connection sizes as perceived on TCP level. In Figure 4 we show the cumulative distribution of the number of payload bytes exchanged on the Multipath TCP connections and compare it with the size distribution of the individual TCP connections. As expected, we see a larger number of small TCP subflow connections.

It should be noted that establishing multiple subflows does not necessarily mean that the payload of a Multipath TCP connection is evenly distributed over them. This will be further discussed in Section 3.6. While the MP PRIO option has been introduced to Multipath TCP providing the capability to change the priority of a subflow, we do not observe any subflow using this option. The interference caused by various types of middleboxes has significantly affected the design of the Multipath TCP protocol [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF][START_REF] Raiciu | How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP[END_REF][START_REF] Honda | Is It Still Possible to Extend TCP?[END_REF]. Multipath TCP can cope with middleboxes that modify the source/destination IP addresses and ports, but also change the TCP sequence numbers or split/reassemble TCP segments [START_REF] Hesmans | Are TCP Extensions Middlebox-proof?[END_REF]. If a middlebox strips TCP options, the Multipath TCP implementation in the Linux kernel performs a fallback to regular TCP [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. The worst middlebox interference for Multipath TCP is when a middlebox such as a NAT using a Application Level Gateway changes "transparently" the payload of TCP segments, e.g. to translate the ASCII representation of an IP address. Multipath TCP can detect this type of interference by using the DSS checksum which is computed over the data and the Multipath TCP option [START_REF] Raiciu | How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP[END_REF][START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. Given that the TCP segments are already protected by the TCP checksum, an error in the DSS checksum is always a sign of middlebox interference. If a host receives a TCP segment with a valid TCP checksum and an invalid DSS checksum, it sends an MP FAIL option to inform the peer of the interference and performs a fallback to regular TCP. Among more than 5000 Multipath TCP connections that we have analysed, we observe three transmissions of the MP FAIL option. In all three cases, MP FAILs are sent on port 21 (FTP). This is a relatively small number knowing that the monitored server provides FTP services that are subject to middlebox interference [START_REF] Hesmans | Are TCP Extensions Middlebox-proof?[END_REF] due to Application Level Gateways included in NAT devices. We did not observe the MP FAIL option on port 80 despite the fact that transparent proxies are often reported [START_REF] Weaver | Here be web proxies[END_REF]. Surprisingly, we also observe this MP FAIL option inside IPv6 packets.

As explained earlier, the utilisation of the DSS Checksum [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF] ensures that middlebox interference is detected and that the data is transported correctly. However, computing the DSS Checksum consumes CPU ressources [START_REF] Raiciu | How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP[END_REF] and the DSS checksum can be disabled on a per connection basis. During the three-way handshake on the initial subflow, the client and the server can opt out the DSS Checksum. The DSS Checksum is only disabled if both propose to disable it. If either the client or the server is configured to use the DSS Checksum, then it is used in both directions. Since the monitored server was configured to always us the DSS Checksum, it was active for all Multipath TCP connections. This is the default configuration which is recommended in the Internet [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. The DSS Checksum should only be disabled in controlled environments such as datacenters that are known to be immune of middlebox interference. We were surprised to measure that about 5% of the Multipath TCP connections established with our server requested to disable the DSS Checksum. This configuration was probably chosen for performance reasons, but it puts the data transfert at risk of undetected middlebox interference.

How do Multipath TCP connections terminate?

TCP uses two different mechanisms to terminate a connection. Most connections should terminate by exchanging FIN segments in both directions [START_REF] Postel | Transmission Control Protocol[END_REF]. Some connections terminate abruptly with the transmission of a RST segment due to problems or because the server does not want to wait in the CLOSE WAIT state [START_REF] Arlitt | An Analysis of TCP Reset Behaviour on the Internet[END_REF]. Each of the TCP subflows that compose a Multipath TCP connection can be terminated using one of these mechanisms. Above the subflows, Multipath TCP also includes similar mechanisms to terminate the Multipath TCP connection [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF]. If all the data has been transferred correctly, a Multipath TCP connection should terminate with the exchange of DATA FIN options in both directions. We observe that 89% of the 5098 monitored Multipath TCP connections are terminated by exchanging DATA FINs. Multipath TCP also includes a fast close mechanism that allows a host to terminate a Multipath TCP connection by sending a FAST CLOSE option inside a RST segment. This feature was included in [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF] to enable a server to quickly terminate a Multipath TCP connection. It is used by roughly 10% of the observed Multipath TCP connections.

How is data distributed?

Since a Multipath TCP connection combines several TCP subflows, data can be transmitted over any of these subflows. The Linux implementation of Multipath TCP uses a packet scheduler [START_REF] Paasch | Experimental Evaluation of Multipath TCP Schedulers[END_REF] to select the subflow over which each data segment is transmitted. The monitored server uses the default scheduler that tries to send data on the subflow having the smallest round-trip-time among the subflows whose congestion window is open. The client could use another scheduler such as the round-robin scheduler or any custom scheduler [START_REF] Paasch | Experimental Evaluation of Multipath TCP Schedulers[END_REF].

The utilisation of the default scheduler implies that the data is not evenly distributed among the different subflows. Figure 5 shows, for connections composed of more than one subflow, how the data is distributed among the initial subflow and the other subflows of the connection. We observe that around 52% of the connections send less than half of their data over the initial subflow. In contrast, around 30% of the connections transfer their data nearly entirely over the initial subflow. There are different possible explanations for this behaviour. One reason could be that those connections are simply too short or too small to use the additional subflows. However, we have studied their length and size distribution and could not find any prevalence of very short or small connections among them in comparison to other connections.

Like regular TCP connections, Multipath TCP connections can be impacted by packet losses. The Multipath TCP implementation in the Linux kernel includes three main strategies to cope with losses. If an isolated packet is lost, Multipath TCP will use the fast retransmit mechanism to retransmit it over the subflow where it was initially sent. This is the normal behaviour of a TCP connection. If a retransmission timer expires, this usually indicates a more severe loss. In this case, Multipath TCP evaluates whether the data should be retransmitted over the same subflow as the original transmission or over another subflow. In the latter case (reinjection), data will be retransmitted over both subflows to ensure that any middlebox over one of the paths observes in-sequence data [START_REF] Ford | TCP Extensions for Multipath Operation with Multiple Addresses[END_REF][START_REF] Hesmans | Are TCP Extensions Middlebox-proof?[END_REF]. In some cases, such retransmissions can also occur when one of the subflows is too slow compared to the other ones [START_REF] Raiciu | How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP[END_REF]. If a subflow dies, e.g. due to the failure of a WiFi interface, then all unacknowledged data sent over this subflow is retransmitted over the remaining subflows. These reinjections are an indication of the inefficiency of Multipath TCP. Since reinjected data is sent over two or more subflows, a large reinjection rate will result in a badly performing Multipath TCP connection.

Figure 6 shows the fractions of reinjected data (bytes) for the Multipath TCP connections composed of at least two subflows. We provide the CDF for transmissions from the client to the server resp. from the server to the client. We observe that more than 90% of the connections do not have any reinjection. More than 98% of the connections have fewer than 2% of reinjections. This shows that reinjections are rare and that the overhead caused by them is very low in comparison to the overall TCP retransmission rate of 0.8-2.4% reported in [START_REF] Jerry | Tuning TCP Parameters[END_REF].

We also observe that the fraction of reinjections is larger in the client-to-server direction than in the opposite one. The reasons for this will be the topic of future work. Finally, it should be noted that the results shown in the figure should be taken with caution for fractions above 30%. Due to the small population size and the presence of very short connections, extreme cases, such as a single-packet connection with reinjection, do have a visible impact on the tail of the empirical CDF.

Related work

Various researchers have studied the performance of Multipath TCP on cellular networks and/or the global Internet. As of this writing, most of these studies have focussed on performing active measurements among a relatively small set of connected devices. We are not aware of published studies where large Multipath TCP packet traces have been analysed in details. In this section, we thus compare our findings with the main results obtained with active measurements. Although several implementations of Multipath TCP exist [START_REF] Eardley | Survey of MPTCP Implementations[END_REF], we are not aware of published results that compare their performance. In fact, most of the published papers use the Linux implementation. Several researchers have analysed the performance of Multipath TCP in cellular networks. Paasch et al. propose, implement and evaluate path management strategies to efficiently support 3G and WiFi interfaces with Multipath TCP [START_REF] Paasch | Exploring Mobile/WiFi Handover with Multipath TCP[END_REF]. The Linux implementation [START_REF] Paasch | Multipath TCP implementation in the Linux kernel[END_REF] is used by the monitored server and likely most of the clients that sent packets. Chen et al. [START_REF] Chen | A Measurement-based Study of Multipath TCP Performance over Wireless Networks[END_REF] [START_REF] Kvalbein | The NorNet Edge Platform for Mobile Broadband Measurements[END_REF] to analyse the performance of Multipath TCP in heterogeneous networks (WiFi and 2G or 3G) [START_REF] Ferlin | Multi-Path Transport over Heterogeneous Wireless Networks: Does it really pay off[END_REF]. Their measurements show that when the difference in bandwidth between the two interfaces is large (e.g. 2G and WiFi), then the performance of Multipath TCP may suffer. They propose an algorithm that monitors the subflow performance and disables the under-performing ones.

Multipath TCP is not the only transport protocol that is capable of supporting multiple paths. The Stream Control Transmission Protocol [START_REF] Stewart | Stream Control Transmission Protocol[END_REF] (SCTP) has been implemented in most operating systems. It was designed with multihoming in mind and support for concurrent multipath was added to SCTP [START_REF] Iyengar | Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths[END_REF] before the deployment of Multipath TCP. However, we have not found in the scientific literature detailed measurements of the performance of SCTP based on passive measurements. As shown in [START_REF] Budzisz | A Taxonomy and Survey of SCTP Research[END_REF] only a small fraction of the published SCTP research is based on real measurements on the Internet.

Conclusion

In this paper, we have presented a first analysis of the behaviour of Multipath TCP based on a one-week long packet trace collected on a popular Multipath TCP server. Since the server hosts the Multipath TCP implementation in the Linux kernel, it is mainly used by developpers and researchers. Furthermore, we expect that most clients use the same Linux implementation as the one running on the server. We have analysed the real utilisation of the new features introduced in this TCP extension, namely the establishment of the subflows, the advertisement of addresses, the reinjection of data, the detection of middlebox interference and the termination of the Multipath TCP connections. Some of our results confirm that the protocol operates correctly over the Internet. Others were less expected and provide an insight on the operation of this protocol over the Internet. Firstly, Multipath TCP hosts can use many interfaces. Some hosts announced up to 14 different IP addresses over a single Multipath TCP connection. Secondly, the subflows that compose a Multipath TCP connection are usually established very quickly. This corresponds to the default strategy of the current Linux implementation and confirms that clients mainly use this implementation. Thirdly, when two or more subflows are used, their average round-trip-times can differ by 10-100 msec for 40% of the Multipath TCP connections. This is a large delay difference that indicates that Multipath TCP is used in heterogeneous environments. This delay difference must be taken into account by Multipath TCP implementors who are tuning their implementations. Fourthly, Multipath TCP spreads the data over the different subflows and rarely needs to reinject some data over another subflow. Finally, there are middleboxes that interfere with Multipath TCP, even in IPv6 networks.

For our future work, we will collect a longer trace to study in more details other aspects of the protocol such as identifying the congestion control scheme used on the subflows, the packet scheduler used by the client, or measuring the short term dynamics of the data transmission on the different subflows or middlebox interference.

Fig. 1 :

 1 Fig. 1: Delay between the SYN of initial flow and the first MP JOIN

Fig. 2 :

 2 Fig. 2: Difference between the maximum RTT and minimum RTT among subflows belonging to one MPTCP connection

Fig. 3 :

 3 Fig. 3: Distribution of subflows per connection

Fig. 4 :

 4 Fig. 4: Distribution of data on Multipath TCP connections and the subflows

Fig. 5 :

 5 Fig.5: Fraction of data on initial subflow over total data for connections with more than one subflow

Fig. 6 :

 6 Fig. 6: Fraction of reinjected data over total data for connections

Table 1 :

 1 Dataset characteristics

	Collection period	Nov. 17 -24, 2014
	All TCP	Total IPv4 IPv6
	# of packets [Mpkt] 136.1 128.5 7.6
	# of bytes [GiByte] 134.0 129.0 5.0
	Multipath TCP	Total IPv4 IPv6
	# of packets [Mpkt] 29.4 25.0 4.4
	# of bytes [GiByte] 20.5 18.5 2.0

Table 2 :

 2 Special addresses advertised by clients

	Address type	Count
	Link-local (IPv4)	51
	Link-local (IPv6)	241
	Documentation only (IPv6) 21
	IPv4-compatible IPv6	13
	6to4	206

  and Deng et al. [6] also perform measurements with the Multipath TCP implementation in the Linux kernel. Chen et al. focus on bulk transfers over WiFi and 3G and conclude that Multipath TCP provides performance benefits compared to regular TCP. Deng et al. analyse different scenarios. Their measurements show that the benefits of using Multipath TCP increase with the volume of data transferred. Lim et al. present other measurements with cellular and WiFi networks in [16] and focus on tuning the Multipath TCP implementation to reduce the energy consumption. Williams et al. use experiments to investigate the use of Multipath TCP (MPTCP) to augment cellular 3G connections with roadside infrastructure [27]. Ferlin et al. use the NorNet infrastructure

http://www.multipath-tcp.org

The anonymised packet trace is available at http://multipath-tcp.org/data/ TMA-2015.tar.gz.

Acknowledgements

This work was partially supported by the ITN METRICS and the FP7 TRIL-OGY 2 projects funded by the European Commission and by the BESTCOM IAP.


Laurent Zamponi

Emmanuel Mermoz

Jean-Marc Linares
email: linares@univmed.fr

´ Etude des méthodes de calcul des pressions de contact dans les roulements à pistes intégrées des boîtes de transmission aéronautiques

Keywords: Roulement, CAO, éléments-finis, théorie de Hertz, boîte de transmission Rolling bearing, CAD, finite-element method, Hertz theory, gearbox

De plus en plus, les concepteurs utilisent des méthodes avancées de calcul, pour optimiser les performances des systèmes mécaniques. Ce constat est d'autant plus vrai dans le milieu aéronautique ou ` le rapport poids puissance doit être le plus faible possible. Certains logiciels de CAO (CATIA, SO-LIDWORKS, PRO ENGINEER, etc.) off rent la possibilité d'eff ectuer des calculs de dimensionnement. Néanmoins, ce type d'outil ne permet pas, a ` ce jour, d'estimer facilement les pressions de contact entre deux pièces. Cet article présente les diff érentes méthodologies utilisables dans un environnement CAO pour le calcul des pressions de contact dans les roulements à pistes intégrées de boîte de transmission aéronautique. Ces méthodologies sont analytiques (théorie de Hertz), numériques (éléments-finis) ou hybrides. Ces diff érentes approches sont analysées et comparées suivant les critères de précision, de temps de calcul et de leurs aptitudes a ` s'intégrer dans un processus de conception industriel. A partir de cette analyse, il sera proposé une méthodologie de calcul des pressions de contact.

Introduction

En conception mécanique, le roulement est l'une des pièces les plus fréquemment utilisées pour réaliser des liaisons entre sous-ensembles en rotation. La connaissance de son fonctionnement est essentielle pour la maîtrise de la conception et de la fiabilité des mécanismes. Les normes ISO ainsi que les catalogues des fabricants de roulements permettent au concepteur d'implanter ce composant dans un mécanisme. Dans l'industrie aéronautique et, plus particulièrement, dans la construction d'hélicoptères, la recherche de la performance, en minimisant la masse embarquée, est essentielle. Une boîte de transmission de puissance, ayant comme caractéristique une masse de 300 kg et pouvant transmettre une puissance de plusieurs mégawatts, est présentée sur la figure 1. Dans ce type de boîte de transmission de puissance d'hélicoptère, le gain de masse est obtenu en minimisant le nombre et l'épaisseur des pièces. Pour le guidage en rotation par éléments roulants, le gain de masse s'obtient en

Nomenclature :

Fr, Fa, M : φ : Qi : charges appliquées sur le roulement, respectivement, eff ort radial, eff ort axial et moment angle de déphasage entre le moment M et l'eff ort radial Fr eff ort normal de contact sur l'élément roulant i raideur globale de contact entre la bille et les pistes repère cartésien, avec O centre géométrique de la piste intérieure, Z colinéaire à l'axe de rotation, X parallèle à la direction de l'eff ort radial, et Y complète le trièdre angle entre la bille i et l'axe X dans le plan XY centre de piste intérieure après chargement repère cartésien liée à la bille i, tel que ψi = (X, Ui) = (Y, Vi) dans le plan XY angle de contact de la bille i dans le plan UiZ déformation globale de contact entre la bille i et les bagues déplacement radial relatif entre la bague intérieure et la bague extérieure déplacement axial relatif entre la bague intérieure et la bague extérieure rotation relative entre la bague intérieure et la bague extérieure jeu diamétral diamètre moyen grand diamètre de la piste intérieure grand diamètre de la piste extérieure rayon de la piste intérieure rayon de la piste extérieure diamètre des billes point intersection entre le grand cercle de la piste extérieure et le plan UiZ point intersection entre le grand cercle de la piste intérieure et le plan UiZ champ de déplacements issus de la déformation des pièces calculé par E.F., respectivement, champ de déplacement radial, champ de déplacement axial déplacements entre la piste intérieure et extérieure au voisinage de l'élément roulant i, respectivement, déplacement radial, déplacement axial déplacements entre les zones d'accrochage de l'élément de substitution i, respectivement, déplacement radial, déplacement axial raideur équivalente de l'élément de substitution i au pas de calcul p complète du mécanisme afin de prendre en compte les raideurs des pièces, les jeux dans les roulements, les contacts, etc. Ce type de modélisation peut être partiellement effectué par les fabricants de roulements. Chaque fabricant de roulement a développé ses outils pour eff ectuer ce genre de modélisation. A l'heure actuelle, le dimensionnement des roulements à pistes intégrées des boîtes de transmission d'hélicoptère s'eff ectue en deux phases. Durant la première, le concepteur dimensionne le roulement à pistes intégrées comme un roulement avec la méthode de calcul de la durée de vie issue de l'ISO 286 [START_REF]Charges dynamiques de base et durée nominale[END_REF] et des règles (( métier )). Ensuite, la liaison pivot étudiée est envoyée chez le fabriquant de roulements pour la vérification du dimensionnement des roulements à pistes intégrées à l'aide de leurs outils de calculs. Dans le but de minimiser les cycles de développement et d'optimiser globalement le mécanisme, il serait intéressant pour le concepteur d'avoir directement accès a ` ce type d'outils dans l'environnement CAO. Dans le secteur des mécaniques pour hélicoptère, les roulements à pistes intégrées des boîtes de transmission sont fortement chargés. De plus, l'expérience acquise par l'hélicoptériste et les roulementiers a permis de montrer que la pression de Hertz est un des critères qui impacte la fiabilité des pistes intégrées et leurs tenues en service. Un des critères de dimensionnement principal est la pression de contact entre les éléments roulants et la piste.

K h : (O, X, Y, Z) :
L'objectif général de nos travaux est de proposer une méthode de calcul des pressions de contact sur les pistes des roulements à pistes intégrées en incluant les déformations des pièces du mécanisme. Cette méthode devra s'intégrer dans un logiciel de CAO industriel. Dans cet article, la majorité des méthodes permettant d'obtenir les pressions de contact dans les roulements d'un mécanisme seront présentées. Nous étudierons si ces méthodes sont capables de prendre en compte les déformations des pièces et si elles sont intégrables dans un environnement CAO. Afin d'illustrer le déploiement de ces méthodes, applicable aux roulements usuels ou a ` pistes intégrées, l'exemple d'un roulement a ` billes sera utilisé.

Bibliographie sur le dimensionnement des roulements

Le professeur Stribeck a été l'un des premiers scientifiques a ` publier un travail sur la répartition des charges dans les roulements. Dans son rapport [START_REF] Stribeck | Ball bearing for various loads[END_REF], il a proposé l'étude du contact bille-piste en corrélant la théorie de contact de Hertz à plusieurs séries d'essais. Il a obtenu une relation entre l'eff ort radial appliqué sur le roulement et l'eff ort sur l'élément roulant le plus chargé. Ces travaux sont a ` l'origine de la norme ISO 76 [START_REF]ISO 76[END_REF] sur le calcul de la charge statique de base. Lundberg et Palmgren [START_REF] Lundberg | Dynamic Capacity of Rolling Bearings[END_REF] ont étudié le comportement en fatigue des roulements, ce qui a permis d'obtenir un critère de dimensionnement en fatigue. Ce travail a contribué à la mise en place de la norme ISO 281 [START_REF]Charges dynamiques de base et durée nominale[END_REF]. Une évolution importante de la connaissance sur le comportement des roulements a été réalisée au milieu du XX e siècle par les travaux de Jones [START_REF] Jones | A general theory for elastically constrained ball and radial roller bearings under arbitrary load and speed conditions[END_REF]. Ils portent sur l'étude de leur comportement statique et dynamique. Ces derniers ont été généralisés par Harris [START_REF] Harris | Rolling Bearing Analysis 4[END_REF]. Ils sont la base de toutes les études théoriques des roulements.

La méthode proposée par Harris fait l'hypothèse que les déformations dans un roulement proviennent seulement des écrasements locaux dans les zones de contact. Cette hypothèse n'est plus valable si les bagues des roulements ont une épaisseur faible et d'autant plus si les pistes sont intégrées dans l'arbre ou le logement. Dans l'article de Harris et Jones [START_REF] Jones | Analysis of a rolling element idler gear bearing having a deformable outer race structure[END_REF], la méthode d'Harris a été modifiée en utilisant des coeffi cients de souplesse qui prennent en compte les déformations de la piste extérieure du roulement de satellite d'un train épicycloïdal. Cette piste a été intégrée sur le satellite juste sous la denture. Zupan et Prebil [START_REF] Zupan | Carrying angle and carrying capacity of large single row ball bearing as a function of geometry parameters of the rolling contact and the supporting structure stiff ness[END_REF] ont généralisé cette approche en utilisant les éléments-finis pour calculer la matrice de souplesse de la structure afin de prendre en compte les déformations globales de la structure. Le calcul de la matrice de souplesse est limité par la taille des structures car l'inversion de la matrice de raideur demande des temps de calcul élevés. Hauswald et Houpert [START_REF] Hauswald | Numerical and experimental simulations of performances of bearing system, shaft and housing, Account for global and local deformations[END_REF] et [START_REF] Hauswald | Simulations des performances d'un système avec roulements[END_REF], pour pallier a ` ce problème, ont utilisé la technique de condensation de matrice (condensation de la matrice de raideur aux noeuds de liaisons). Bourdon et al. [START_REF] Bourdon | Static rolling bering model in a C.A.D. Environment for the study of complex mechanisms: Part I and II, Rolling bearing model[END_REF] ont développé un modèle hybride pour prendre en compte les déformations globales, ou ` le mécanisme est discrétisé en éléments-finis et les éléments roulants de chaque roulement sont remplacés par des éléments-finis non-linéaires accrochés aux deux bagues. Les travaux de Lovell et al. [START_REF] Lovel | A finiteelement analysis of the frictional forces between a cylindrical bearing element and MoS2 coated and uncoated surfaces[END_REF] sur le contact entre une bille et deux plaques parallèles, modélisé par les éléments-finis ont montré que les résultats obtenus sont proches de ceux issus de la théorie de Hertz. Zhao [START_REF] Zhao | Analysis of load distribution within solid and hollow roller bearings[END_REF] a utilisé un code éléments-finis 2D de contact, pour calculer les répartitions de charge dans un roulement soumis à un eff ort radial. Kang et al. [START_REF] Kang | A modification of the Jones-Harris method for deep-groove ball bearings[END_REF] propose une modification de la loi de contact de Hertz par une loi issue d'une modélisation locale du contact par éléments-finis. Houpert [START_REF] Houpert | An Engineering Approach to Hertzian Contact Elasticity, part I and II[END_REF], et Tanaka [START_REF] Tanaka | A new calculation method of Hertz elliptical contact pressure[END_REF] ont proposé une amélioration analytique de la loi de Hertz pour les contacts dans les roulements. Antoine et al. [START_REF] Antoine | Analytical solution for Hertzian contact problems[END_REF] ont suggéré une formulation empirique et explicite de la loi de Hertz afin d'éviter la résolution numérique. D'après la bibliographie, trois types de méthodes sont utilisés pour analyser les contacts dans les roulements. Elles sont analytiques, numériques ou hybrides. Pour les structures mécaniques et les technologies de roulements utilisées dans nos applications, il est nécessaire de prendre en compte la déformation de toutes les pièces. Généralement, sur les mécanismes étudiés, seulement 70 % du déplacement relatif (hors jeux) entre les pistes intérieure et extérieure sont issus des déformations locales aux contacts entre les éléments roulants et les pistes, 20 % du déplacement relatif proviennent des déformations de la piste extérieure et du carter, le reste, soit 10 %, est du ˆ a ` la déformation de l'arbre (piste intérieure intégrée sur l'arbre). Dans les sections suivantes, certaines méthodologies proposées dans la bibliographie seront décrites, analysées et adaptées aux contraintes des ´

Problématique physique

Dans l'étude des mécanismes, le calcul des charges aux liaisons F i en fonction de la charge extérieure F n'est pas aisé sans faire les hypothèses de raideur infinie et de liaisons simplifiées (voir Fig. 3). Chacune des charges F i dépend de la résultante des charges extérieures F , des raideurs du carter et de l'arbre, de la raideur globale de chacune des liaisons, et des défauts géométriques (coaxialité, perpendicularité,...). Cependant, pour des liaisons par éléments roulants, la raideur globale de celles-ci n'est pas constante (présence de contacts). Elle dépend de la charge F i , du nombre d'éléments roulants, du jeu, de la géométrie interne, des matériaux, et des défauts géométriques. La résolution du problème devra être itérative. Toute la difficulté est issue de la non-linéarité de comportement aux contacts. Dans notre cas, nous allons nous intéresser à la modélisation des contacts dans les roulements à pistes intégrées, afin d'en estimer les pressions de contact. Les pressions de contact seront calculées par la théorie de Hertz. Dans le cadre des mécaniques étudiées, nous pouvons négliger les eff orts dynamiques et les forces de frottements qui sont faibles vis-a `-vis des charges appliquées. Si les roulements sont soumis à de grandes vitesses de rotation et faiblement chargés, le rapport entre la force centrifuge et la force de contact appliquée sur l'élément roulant le plus chargé est supérieur à 10 %. Cette configuration, conduit a ` prendre en compte les eff ets dynamiques appliqués aux éléments roulants. Dans la suite du paragraphe, trois méthodes aptes a ` répondre a ` cette problématique sont présentées. L'exemple d'un roulement à billes servira d'illustration a ` l'application de ces méthodes.

Méthode analytique

La méthode analytique est la première méthode qui a été développée pour une modélisation fine des montages de roulements. Elle est utilisée dans la plupart des programmes des fabricants de roulements. L'approche pour l'arbre, les équations de la statique et la loi de comportement (modélisation 1D), pour les roulements, les équations de la statique, la loi de contact de Hertz et la relation entre le déplacement local de contact et le déplacement relatif entre la piste intérieure et la piste extérieure.

X

Les équations de l'arbre sont classiques, par contre les équations des roulements sont issues d'un couplage contact, déplacement. Afin d'illustrer ce couplage, les équations d'un roulement a ` billes sont détaillées cidessous. En eff ectuant l'équilibre de la bague intérieure du roulement (voir Fig. 4), les équations suivantes sont obtenues :

i=Z F r - Q i cos (ψ i ) = 0 (1) i=1 X i=Z F a - Q i sin (α i ) = 0 (2) i=1 1 X i=1 π 2 2 i=Z M -d m Q i sin (α i ) cos ψ i + ϕ - = 0 (3)
i En utilisant successivement la théorie de Hertz, pour les contacts entre la piste intérieure et la bille i, et entre la bille i et la piste extérieure, la relation suivante est déduite :

Q = K h • (δ i ) n (4)
La raideur globale de contact K h dépend de la géométrie interne du roulement décrite sur la figure 5 (rayons de courbure). La relation entre le déplacement local du

La relation ( 5) est obtenue en calculant la distance entre le point A i et le point B s i avant et après déplacement des pistes (voir Fig. 6). Cette relation permet de faire le lien entre les déplacements relatifs globaux (δ r , δ a , et θ entre la piste intérieure et la piste extérieure) et les déplacements locaux de contact (δ i ) de chaque bille i. Le jeu diamétral J est relié à la géométrie des pistes et celles des éléments roulants par l'équation [START_REF] Harris | Rolling Bearing Analysis 4[END_REF]. L'angle de contact α i de la bille i est donné par l'orientation de la droite de contact (A i B i ) par rapport a ` l'axe U i mesuré dans le plan (U i Z). La relation déduite est la suivante :

voir équation [START_REF] Jones | Analysis of a rolling element idler gear bearing having a deformable outer race structure[END_REF]

ci-dessus

La résolution globale du problème est eff ectuée en utilisant la méthode itérative de Newton-Raphson.

Cette méthode analytique est rapide mais ne prend pas en compte toutes les déformations présentes dans le mécanisme (déformation carter, déformation des pistes de roulement). Elle ne peut pas être directement appliquée dans les mécanismes aéronautiques étudiés. Cependant, les méthodes hybrides, présentées dans la suite de l'article, utilisent en partie des équations issues de cette méthode analytique pour modéliser le comportement local au niveau du roulement ou des éléments roulants.

Méthode hybride E.F. et analytique utilisant les codes de contacts

La plupart des logiciels d'éléments-finis sont capables aujourd'hui de gérer le contact entre pièces. Il existe plusieurs méthodes, les plus utilisées dans les codes de calculs industriels sont les méthodes des multiplicateurs de La démarche développée pour calculer un mécanisme complet est décrite par l'organigramme de la figure 8. Elle consiste à eff ectuer le calcul en éléments-finis du mécanisme avec un maillage optimisé des roulements a ` pistes intégrées, de récupérer les eff orts et les déplacements de chaque piste, et de calculer les pressions de contact ainsi que les angles de contact pour les éléments roulants sphériques par une méthode analytique. Le maillage d'une boîte de transmission principale d'hélicoptère est représenté sur la figure 9. La méthode analytique mise en place s'inspire de celle décrite dans la section 3.2 pour le calcul d'un roulement seul. La méthode analytique intègre la déformation des pistes et le partage des charges issues du calcul par éléments-finis. Les valeurs récupérées dans le calcul éléments-finis sont les efforts globaux (F r , F a , et M ), l'angle de déphasage φ (entre M et F r ), et le champ de déplacements des pistes de chaque roulement. Nous nous ramenons à un calcul analytique de chaque roulement individuellement. Le champ de déplacements de chaque piste est traité de fac ¸on a ` soustraire les déplacements de corps rigide afin de n'avoir que des déplacements issus de la déformation. Ce dernier est reporté sur la piste intérieure, puis caractérisé par des paramètres d'une série de Fourier en utilisant une méthode des moindres carrés. Ces paramètres définissent la déformation équivalente des pistes, et permettent de prendre en compte l'eff et de la déformation globale du mécanisme modélisé. Dans le cas d'un roulement à billes, ces paramètres sont introduits dans les relations ( 5) et [START_REF] Jones | Analysis of a rolling element idler gear bearing having a deformable outer race structure[END_REF] de fac ¸on a ` bruiter la géométrie nominale. Par exemple, la relation ( 5) s'écrit comme suit :

voir équation (8) ci-dessus avec r 0 2 2 r r a 1 1 2 2 δ def = a r + (a r cos 2ψ i + b r sin 2ψ i ) + (a 3 cos 3ψ i + b 3 sin 3ψ i ) (9) δ def = (a a cos ψ i + b a sin ψ i ) + (a r cos 2ψ i + b r sin 2ψ i ) ( 10
)
Avec les pulsations choisies, seulement les premiers modes de déformations sont récupérés. Il n'est pas nécessaire d'aller plus loin dans l'identification du champ de déplacements. Les charges sur chaque élément roulant s'obtiennent en résolvant simultanément les équations (1)-(3) (utilisation de la méthode de Newton-Raphson) avec les paramètres et les valeurs récupérés dans le calcul par éléments-finis. Le champ de pressions est calculé à partir de la charge sur l'élément roulant en utilisant la théorie de Hertz avec les rayons de courbure nominaux.

La méthodologie développée permet d'obtenir les pressions de contact dans les roulements à pistes intégrées en tenant compte des déformations de toutes les pièces du mécanisme. Elle s'implante bien dans un environnement CAO. Le mécanisme est conçu sous le logiciel CATIA V5. Toutes les pièces sauf les roulements à pistes intégrées sont maillées puis exportées dans le logiciel élémentsfinis SAMCEF. Pour les roulements a ` pistes intégrées, le maillage ainsi que les conditions de contact sont créés automatiquement sous SAMCEF a ` partir des données géométriques par un programme dédié. De plus, les temps de calcul ne sont pas excessifs (environ 3 h pour une boîte de transmission a ` 4 étages de réduction). Un programme a été développé pour récupérer les résultats obtenus par les éléments-finis et pour calculer les pressions de contact.

`

La modélisation du mécanisme est réalisée par les éléments-finis sans condition de contact. Ces derniers sont remplacés par des éléments de substitution comme illustrés sur la figure 10. Cette méthode est inspirée des travaux menés par Bourdon et al. [START_REF] Bourdon | Static rolling bering model in a C.A.D. Environment for the study of complex mechanisms: Part I and II, Rolling bearing model[END_REF]. Dans cet article, les contacts entre les éléments roulants et les pistes sont modélisés par des poutres non-linéaires accrochées aux pistes. La résolution est eff ectuée en linéaire d'une manière itérative.

Contrairement à Bourdon et al., la méthode proposée remplace les contacts entre les éléments roulants et les pistes par des ressorts linéaires orientés comme décrit sur la figure 10. La méthode est détaillée dans l'organigramme de la figure 11. A chaque pas d'itération, le calcul par les éléments-finis du mécanisme, équipé des éléments de substitution, est eff ectué. Les raideurs ainsi que l'orientation des ressorts sont recalculés à la fin de chaque itération a ` partir des déplacements relatifs des zones d'accrochages de chaque élément de substitution, et des eff orts subis par ces derniers. La position d'équilibre du mécanisme est atteinte quand la diff érence relative entre la somme des raideurs des ressorts du pas p + 1 et du pas p est inférieure a ` 0,1 %. La méthode analytique mise en place pour le calcul des raideurs et des orientations utilise des équations similaires (dans le cas d'un roulement a ` billes) a ` celles de la méthode decrite dans la section 3.2. Les données d'entrée du calcul analytique, a ` chaque pas p et pour chaque élément de substitution i, sont le déplacement relatif U Δi entre les zones d'accrochages et l'eff ort appliqué Q . A partir de ces données, le déplacement réel local de contact et l'orientation réelle de l'eff ort sont calculés.

Méthode hybride E.F. et analytique utilisant

Design CAO

des éléments de substitution Calcul E.F.

Maillage et construction des éléments de substitution

Calcul analytique

Oui Dans le cas d'un roulement à billes, le déplacement local de contact δ p s'obtient directement a ` partir de l'eff ort appliqué Q p et la raideur de contact de Hertz en inversant la relation [START_REF] Jones | A general theory for elastically constrained ball and radial roller bearings under arbitrary load and speed conditions[END_REF]. L'angle de contact α p est plus délicat à obtenir. Il est nécessaire de connaître la décomposition du déplacement en radial U p et en axial U p entre les pistes intérieure et extérieure au voisinage de l'élément roulant i. Pour cela, il faut résoudre l'équation suivante :

i p p q δ p = (r i + r e -D -J + U ri ) 2 + (U ai ) 2 -(r i + r e -D) (11)
sin α = q U ai ( 13
) (r i + r e -D -J + U ri ) 2 + (U ai ) 2
La raideur équivalente de l'élément de substitution i, au pas p, s'obtient par la relation :

p Q i p p i i p K i = [U ai sin α p + U ri cos α p ] (14)
Le champ de pressions est calculé, à la fin des itérations, à partir de l'eff ort sur l'élément de substitution en utilisant la théorie de Hertz avec les rayons de courbure nominaux.

Cette méthodologie permet d'obtenir les pressions de contact dans les roulements à pistes intégrées en tenant compte des déformations de toutes les pièces du mécanisme. Elle a l'avantage d'être implantée directement dans l'environnement CAO (CATIA V5) utilisé pour la conception. La modélisation est eff ectuée sous le module d'éléments-finis (GPS) de CATIA V5. La raideur ainsi que l'orientation (angle de contact) des ressorts sont pilotées par une macro VB de CATIA V5. En général, la solution converge au bout de quelques itérations. Le nombre d'itérations est inférieur à 10. Par contre, le temps de mise a ` jour du modèle éléments-finis par l'interface VB dans CATIA V5 pénalise la durée de calcul.

Comparaison des méthodes

` Dans les sections précédentes, trois méthodes ont été proposées pour calculer les pressions entre les éléments roulants et les pistes. La méthode analytique ne permet pas d'inclure les déformations générales de la structure du mécanisme. Cette remarque rend cette méthode inutilisable pour le problème traité. La deuxième méthode est basée sur un calcul hybride associant les éléments-finis dans un premier temps et l'approche analytique dans un deuxième temps. Elle a été mise en place et testée avec succès sur des problèmes réels. La dernière méthode hybride est basée sur un calcul par éléments-finis et sur la déformation d'éléments de type ressort. Le contact est décrit avec des ressorts dont la raideur et l'orientation sont calculées par une approche analytique. Elle a donné de très bons résultats sur des ensembles mécaniques. En conclusion, les deux dernières méthodes conviennent aux impératifs fixés par l'environnement aéronautique.

Afin de comparer la justesse relative des résultats fournis, une simulation a été menée. Dans un premier temps, une structure simple est considérée rigide (roulement a ` 9 billes soumis à une charge radiale de 7000 N au droit de la bille 1). Dans ce cas, la méthode analytique peut être aussi utilisée. Cette comparaison permet de confronter les deux méthodes développées à la méthode analytique utilisée par les fabricants de roulements. Les résultats obtenus durant cette simulation sont présentés sur la figure 12a. Les valeurs obtenues par les trois méthodes sont similaires. La diff érence entre les pressions maximales calculées est inférieure a ` 1 %.

Dans un deuxieme temps, la déformabilité de la structure est prise en compte. Les résultats obtenus durant cette simulation sont présentés sur la figure 12b. Les deux méthodes proposées, hors analytique, donnent des résultats semblables. La diff érence maximale atteinte entre les deux estimations est de 3 %.

Il est intéressant de noter la diff érence de répartition des pressions maximales sur la piste intérieure entre les deux simulations présentées. La prise en compte de la déformabilité des bagues du roulement fait diminuer de 10 % la valeur de la pression sur l'élément roulant le plus chargé (la bille numéro 1). Ce type de calcul montre l'eff et bénéfique de la déformation de la structure sur la répartition des pressions de contact. Après expérimentation, il pourrait conduire a ` une optimisation du dimensionnement ou a ` une augmentation des spécifications géométriques des pistes intégrées.

Ces deux méthodes sont incorporées dans le processus de conception des boîtes de transmission de puissance. Le modèle de CAO du mécanisme est réalisé avec le logiciel CATIA V5. La méthode hybride utilisant les éléments de substitution est implantée dans le module de calcul par éléments-finis de CATIA V5. Par contre, la méthode hybride utilisant un code de contact est externe au logiciel de CAO. Cette méthode est implantée dans le logiciel SAM-CEF, et il est, donc, nécessaire de transférer le modèle CAO de CATIA V5 à SAMCEF.

Conclusion

Dans cet article, une étude bibliographique a été proposée pour mettre en évidence les méthodes capables de déterminer les pressions de contact entre les éléments roulants et les pistes intégrées dans un mécanisme aéronautique. Deux méthodes ont été étudiées, améliorées et adaptées à l'environnement aéronautique. Une comparaison a été eff ectuée sur les résultats fournis et sur leur mise en oeuvre dans l'environnement CAO. Cette comparaison a permis de conclure sur la similitude des résultats obtenus et sur la propriété de la méthode hybride utilisant les éléments de substitution a ` s'intégrer parfaitement dans le logiciel de conception. De plus, l'eff et bénéfique de la déformation de la structure sur la répartition des pressions de contact a été mis en évidence. Cette étude servira de base à l'introduction des défauts géométriques dans le mécanisme afin d'en déterminer leurs influences sur la tenue en service.

Fig. 1 .Fig. 2 .

 12 Fig. 1. Boîte de transmission principale d'hélicoptère vue en 3D.

Fig. 3 .

 3 Fig. 3. Diagramme de transmission des eff orts dans un mécanisme simple.

Fig. 4 .

 4 Fig. 4. Représentation des eff orts extérieurs appliqués sur la bague intérieure d'un roulement à billes.

2 δiZ

 2 sin α = q δa + 2 dmi θ cos ψi + ϕ -2 (5) (ri + re -D -J + δr cos ψi) 2 + δa + 1 dmi θ cos ψi + ϕ -π 2 s = (ri + re -D -J + δr cos ψi) 2 + δa + 2 dmi θ cos ψi + ϕ -2 -(ri + re -D) contact de la bille i et le déplacement relatif global entre la piste intérieure et la piste extérieure est la suivante : voir équation (5) ci-dessus avec : J = (d me + 2r e ) -(d mi + 2r i ) -2D

Fig. 5 .

 5 Fig. 5. Géométrie interne d'un roulement à billes.

Fig. 6 .

 6 Fig. 6. Déplacements relatifs entre la bague intérieure et la bague extérieure.

2 -Fig. 7 .Fig. 8 .

 278 Fig. 7. (a) Maillage optimisé d'un roulement à billes en vue 3D ; (b) maillage optimisé d'un roulement à billes vue en coupe.

Fig. 9 .RessortFig. 10 .

 910 Fig. 9. Maillage du carter d'une transmission d'hélicoptère ; (b) maillage d'une partie des pièces à l'intérieur du carter.

Fig. 11 .

 11 Fig. 11. Organigramme décrivant la méthode par éléments de substitution.

Fig. 12 .

 12 Fig. 12. (a) Graphique des répartitions des pressions en considérant la structure rigide ; (b) graphique des répartitions des pressions en considérant la structure élastique.

  Elle ne suffi t pas pour déterminer le déplacement radial et axial. Il est nécessaire d'introduire une relation supplémentaire. Cette dernière est obtenue a ` partir du rapport entre les déplacements axial U * p et radial U * p issus du déplacement relatif U p de l'élément de substitution i. U p est issu du calcul par éléments-finis au pas p. La relation s'écrit comme suit :

			ai
	ri	Δi
	Δi
	U U * p * p ai = ai p U U p ri ri		(12)
	ri En résolvant le système constitué des équations (11) et (12) deux couples de solutions (U p , U p ) sont trouvés. ai ri ai i Nous choisissons la solution la plus proche du couple (U * p , U * p ) pour respecter la continuité du déplacement. L'angle de contact α p est donné par l'équation suivante :
	p
	i	p	p