Liz Izhikevich

Manda Tran

Katherine Izhikevich

U C San

Diego Gautam Akiwate

Democratizing LEO Satellite Network Measurement

Low Earth Orbit (LEO) satellite networks are quickly gaining traction with promises of impressively low latency, high bandwidth, and global reach. However, the research community knows relatively little about their operation and performance in practice. The obscurity is largely due to the high barrier of entry for measuring LEO networks, which requires deploying specialized hardware or recruiting large numbers of satellite Internet customers. In this paper, we introduce HitchHiking, a methodology that democratizes global visibility into LEO satellite networks. HitchHiking builds on the observation that Internet-exposed services that use LEO Internet can reveal satellite network architecture and performance, bypassing the need for specialized hardware. We evaluate HitchHiking against ground truth measurements and prior methods, showing that it provides more coverage and accuracy. With HitchHiking, we complete the largest study to date of Starlink network latency, measuring over 2,400 users across 13 countries. We uncover unexpected patterns in latency that surface how LEO routing is more complex than previously understood. Finally, we conclude with recommendations for future research on LEO networks.

INTRODUCTION

Low Earth Orbit (LEO) satellite networks promise to decrease latency and increase Internet coverage beyond the means of terrestrial Internet. Used by at least 2 million people as of September 2023 [72], LEO networks have proven immensely useful in natural disaster areas [START_REF]Musk's Starlink connects remote Tonga villages still cut off after tsunami[END_REF], underprivileged schools [START_REF]SpaceX to provide internet for 19K rural schools in Brazil, monitoring Amazon[END_REF], war zones [START_REF]Starlink and the Russia-Ukraine War: A Case of Commercial Technology and Public Purpose?[END_REF], and remote research labs [START_REF]Starlink Is Now Connecting Remote Antarctic Research Camps to the Internet[END_REF]. To improve Internet access for those that rely on LEO networks, researchers have begun to propose improvements to their latency [START_REF] Bhattacharjee | Laser Inter-Satellite Link Setup Delay: Quantification, Impact, and Tolerable Value[END_REF], routing [START_REF] Bhosale | A Characterization of Route Variability in LEO Satellite Networks[END_REF][START_REF] Wang | Reliability Analysis of Multi-hop Routing in Multi-tier LEO Satellite Networks[END_REF], and security [START_REF] Giuliari | ICARUS: Attacking low Earth orbit satellite networks[END_REF].

Unfortunately, researchers today face a barrier when understanding how LEO networks operate in practice: to collect real data, one must acquire expensive specialized satellite hardware or recruit volunteers that use the satellite network. Consequently, the community's study of LEO networks has been limited to a small number of vantage points [START_REF]RIPE Atlas probes[END_REF][START_REF] Kassem | A browser-side view of starlink connectivity[END_REF][START_REF] Ma | Network Characteristics of LEO Satellite Constellations: A Starlink-Based Measurement from End Users[END_REF][START_REF] Michel | A First Look at Starlink Performance[END_REF]] and unvalidated theoretical models [START_REF] Bhattacharjee | Laser Inter-Satellite Link Setup Delay: Quantification, Impact, and Tolerable Value[END_REF][START_REF] Bhosale | A Characterization of Route Variability in LEO Satellite Networks[END_REF][START_REF] Giuliari | ICARUS: Attacking low Earth orbit satellite networks[END_REF][START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF][START_REF] Wang | Reliability Analysis of Multi-hop Routing in Multi-tier LEO Satellite Networks[END_REF]. If researchers plan to help design and protect LEO networks, it behooves us to lower the barrier to acquiring data, such that we have an accurate understanding of how the worldwide LEO network ecosystem works in practice.

In this paper, we introduce HitchHiking, a methodology to actively measure LEO satellite network characteristics at scale. HitchHiking builds on the key insight that probing publicly exposed devices on LEO satellite networks can reveal characteristics of the underlying satellite network. Crucially, the HitchHiking methodology requires no specialized hardware or painstaking recruitment, lowering the barrier to collect real data from LEO networks worldwide. HitchHiking works in three steps [START_REF]Anik F2 Launched on Ariane 5[END_REF] find measurable endpoints that use LEO satellites for Internet connectivity, [START_REF]Ship Alduhail[END_REF] identify where in the network path LEO satellites are used, and (3) measure (i.e., "hitchhike") the satellite link.

We use HitchHiking to conduct the largest LEO network measurement to date-measuring the latency of 2.4K LEO satellite customers across 13 countries-of Starlink [START_REF]Starlink[END_REF], the largest LEO network. We show that HitchHiking collects nearly identical latency data compared to the ground truth observed by a physical Starlink dish. We then use HitchHiking's measurement-and validation by Starlink-to surface the three primary ways in which Starlink's network does not operate as prior work assumed. First, sustained peaks of latency are not due to changes in satellite location. Second, customer latency is bounded by the availability of a nearby Point of Presence (POP). Third, the use of inter-satellite links significantly increases routing path lengths and latency.

Our work illustrates that a diverse set of perspectives are needed to understand the unique routing and latency properties of LEO networks. For researchers interested in studying LEO networks, the HitchHiking methodology we introduce provides accessibility to those desiring experiment flexibility and coverage when collecting real data. To lower the barrier for future LEO research, we are releasing the HitchHiking pipeline for measuring Starlink latency and the data HitchHiking collects under the Apache 2.0 license.

BACKGROUND

Satellite Internet has existed for over 20 years [START_REF]Anik F2 Launched on Ariane 5[END_REF]. However, early Internet-providing satellites were large, expensive, and geostationary (i.e., fixed with respect to a position on the Earth). Geosynchronous equatorial orbit (GEO) satellites orbit over 22,000 miles from earth. While this long distance brings wide coverage, it comes at the expense of latency. Even today, the minimum round trip time (RTT) for a packet to route through a GEO satellite is 480 ms, physically bounded by the speed of light. In response to lower latency requirements-and cheaper satellite technology-a new class of satellite networks emerged: Low Earth Orbit (LEO) satellite networks.

GEO L E O

• .

8?• ⑧ * Fig. 1. LEO vs GEO Satellites-LEO satellites closer distance provides lower latency at the cost of less coverage and no longer being in geostationary orbit.

LEO satellite networks are comprised of hundreds to thousands of satellites that orbit 180 to 1,300 miles from Earth. LEO satellites' closer distance provides significantly lower theoretical latency (≈10 ms RTT), at the cost of reduced coverage and a non-geostationary orbit (Figure 1). The non-geostationary orbit and closer distance causes LEO satellites to travel at tens of thousands of miles per hour, orbiting the earth every 90 minutes. LEO satellite mobility is unique relative to other mobile networks (e.g., cellular, drones), because distances are longer and velocities are higher. Further, the core infrastructure of the network is constantly in motion, but theoretically predictable.

The most basic, and widely deployed [START_REF]Oneweb[END_REF][START_REF] Wang | Tiansuan constellation: An open research platform[END_REF], LEO architecture follow a "bent pipe" routing scheme (Figure 2). Packet routing works as follows:

(1) A client sends a packet to its router [START_REF]Ship Alduhail[END_REF] The router forwards the packet to a physical dish [START_REF]RIPE Atlas probes[END_REF] The dish sends the packet via radio to a passing satellite [START_REF]Oneweb[END_REF] The satellite relays the packet to a ground station [START_REF]Starlink internet plans and pricing[END_REF] The ground station forwards the packet to the provider's Point of Presence (POP), which is often located at an Internet Exchange Point and plays the equivalent role of a home gateway in mobile networks [START_REF] Maria Mandalari | Experience: Implications of roaming in europe[END_REF] (6) The packet is routed from the POP onto the Internet Some newer satellite architectures [START_REF]Starlink[END_REF] are equipped with Inter-Satellite Links (ISLs), which allow satellites to relay packets to each other in space until a ground station is in view. ISL deployment provides coverage to clients in extreme remote locations (e.g., in oceans) that are in view of a satellite (e.g., within 600 miles), but not a ground station. ISLs send packets at the speed of light by using lasers in space, thereby surpassing the performance of optical fiber [START_REF] Aizaz | Optical Wireless Satellite Networks versus Optical Fiber Terrestrial Networks: The Latency Perspective: Invited Chapter[END_REF].

PoP Ground Station

Internet Dish Router Client

S S

Fig. 2. Simplified LEO Satellite Network Routing (Egress)-When a LEO client sends a packet to the public Internet, the packet is sent to a satellite using a dish, and is received by a ground station before forwarding to a POP.

As of 2023, Starlink [START_REF] Satariano | Elon Musk's Unmatched Power in the Stars[END_REF] remains the only consumer-targeted LEO satellite network. Starlink operates satellites with and without ISL capabilities [START_REF] Musk | [END_REF]. Other operational LEO satellites that target businesses include Oneweb [START_REF]Oneweb[END_REF], a network that caters towards enterprises that are located near the earth's poles (e.g., fishing companies in Alaska). Amazon's Project Kuiper [START_REF]Project Kuiper[END_REF] and Telesat [START_REF]Telesat[END_REF] are expected to deploy LEO satellites for consumer-targeted Internet in the future.

RELATED WORK

Three primary methods have been introduced for studying LEO satellite networks: (1) buying and deploying one's own specialized hardware (i.e., a dish) to connect to satellite Internet, capturing real data but providing little coverage;

(2) recruiting others with existing hardware, providing greater coverage at the cost of increased labor; or (3) using theoretical models, providing the most coverage but no real data. Unfortunately, these methods face an inherent trade-off between collecting real data, coverage of vantage points, labor, and monetary cost. We detail each method below:

Deploying Physical Hardware. To measure LEO satellite networks, researchers often buy and travel with specialized hardware (i.e., a satellite dish). Michel et al. [START_REF] Michel | A First Look at Starlink Performance[END_REF] deploy a satellite dish in Belgium to collect data about a single user's perceived Starlink latency. Ma et al. [START_REF] Ma | Network Characteristics of LEO Satellite Constellations: A Starlink-Based Measurement from End Users[END_REF] travel with four dishes around Canada to study Starlink latency across remote locations under different loads. Wang et al. [START_REF] Wang | Tiansuan constellation: An open research platform[END_REF] deploy a constellation of satellites-Tiansuan Constellation-to act as an open research platform in space.

Relying on physical hardware presents a financial and coverage barrier to researchers: hardware costs between $500 [START_REF]Starlink internet plans and pricing[END_REF]-$23K [START_REF]Intellian Oneweb Satellite Internet Systems[END_REF], while monthly subscriptions cost upwards of $100. To achieve world-wide coverage of LEO-accessible locations, one must travel with their hardware. Furthermore, the majority of the world's population does not reside in a geographic location that qualifies for LEO satellite Internet subscriptions [START_REF]Starlink Coverage Map[END_REF].

Recruiting Existing Hardware. To collect data on LEO networks with a wider coverage of users and geographic locations, researchers often recruit existing LEO customers. Kassem et al. [START_REF] Kassem | A browser-side view of starlink connectivity[END_REF] build browser extensions and recruit 18 Starlink users world-wide to study browser performance under Starlink connectivity. RIPE Atlas [START_REF]RIPE Atlas probes[END_REF] has sent hardware (i.e., probes) to over 58 Starlink users across 13 countries, which can be used to run a variety of prescribed measurements.

Recruiting participants and maintaining data collection mechanisms (e.g., building extensions, sending hardware) creates a labor-consuming bottleneck for researchers and produces only limited geographic coverage. Further, relying solely on existing data collecting mechanisms often does not provide the data researchers need. For example, RIPE Atlas measurements can only be conducted at minimum intervals of 60 seconds, which is too coarse to detect significant network fluctuations (Section 6.1.2).

Theoretical Models. Given the difficulties in collecting empirical data, one of the most popular methodologies for studying LEO satellite networks is to use theoretical physics-based models, which simulate LEO Internet performance across location, satellite orbiting pattern, and congestion level. The most popular LEO simulators include Hypatia [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF], Starlink.sx [START_REF] Puchol | [END_REF], and SatelliteMap.space [START_REF]Live Starlink Satellite and Coverage[END_REF]. The flexibility of these tools-and theoretical physics in general-has allowed researchers to simulate how LEO networks are affected by different congestion control algorithms [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF], DDoS attacks [START_REF] Giuliari | ICARUS: Attacking low Earth orbit satellite networks[END_REF], route variability [START_REF] Bhosale | A Characterization of Route Variability in LEO Satellite Networks[END_REF][START_REF] Wang | Reliability Analysis of Multi-hop Routing in Multi-tier LEO Satellite Networks[END_REF], ISL deployment [START_REF] Bhattacharjee | Laser Inter-Satellite Link Setup Delay: Quantification, Impact, and Tolerable Value[END_REF], etc.

However, the accuracy of most popular simulations [START_REF]Live Starlink Satellite and Coverage[END_REF][START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF][START_REF] Puchol | [END_REF] has never been verified. The most recent LEO simulator published in NSDI 2023, StarryNet [START_REF] Lai | {StarryNet}: Empowering Researchers to Evaluate Futuristic Integrated Space and Terrestrial Networks[END_REF], does not evaluate latency predictions beyond the 90th percentile latency and is 20 times less accurate at predicting 90th percentile latency compared to 70th percentile latency. Notably, our work shows that simulations are non-trivial to configure and do not always accurately model the architecture and the satellite-ground station selection process of the deployed LEO satellite networks (Section 6.1.2).

Measuring Links. We apply a decades-old observation-network characteristics can be remotely measured-to a new domain: LEO satellites. For example, in 1993 and 2006, Traceroute [START_REF] Malkin | Traceroute using an IP option[END_REF] and Paris-Traceroute [START_REF] Augustin | Avoiding traceroute anomalies with Paris traceroute[END_REF] showed how routers could illuminate an arbitrary network path. In 1999, Downey et al. introduced PathChar, a methodology for estimating latency and bandwidth between two arbitrary router hops [START_REF] Allen | Using pathchar to estimate Internet link characteristics[END_REF]. The same year Savage introduced Sting [70], a system for calculating packet loss rates across asymmetric routes. Notably, LEO satellite routing introduces a new source of non-deterministic delay (i.e., moving satellites) that existing tools primarily attribute to (stationary) router queuing-delay. Throughout our work, we illustrate the new challenges and implications that LEO satellites surface when measuring network characteristics.

Inter-Satellite Links. Prior work has perceived ISL's minimal latency as an opportunity to decrease latency and provide more direct routing paths [START_REF] Bhattacherjee | Gearing up for the 21st century space race[END_REF][START_REF] Bhattacherjee | In-orbit computing: An outlandish thought experiment?[END_REF][START_REF] Bhattacherjee | Network topology design at 27,000 km/hour[END_REF], and has assumed Starlink does the same [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF][START_REF] Michel | A first look at starlink performance[END_REF]. Proposed LEO attacks [START_REF] Giuliari | ICARUS: Attacking low Earth orbit satellite networks[END_REF] and routing recommendations [START_REF] Bhosale | A Characterization of Route Variability in LEO Satellite Networks[END_REF][START_REF] Wang | Reliability Analysis of Multi-hop Routing in Multi-tier LEO Satellite Networks[END_REF] also assumed ISLs correlate with low latency and direct routing. However, we will show that prior work has overlooked a stark reality: while ISLs likely do minimize user to ground station routing, they significantly increase the length of the routing path. Thus, customers who rely on ISLs may experience some of the highest latency and most indirect routing paths.

LEO HITCHHIKING OVERVIEW

In this section, we present an overview of LEO HitchHiking, a general methodology to measure LEO satellite network characteristics at scale. HitchHiking builds on the key insight that probing publicly exposed satellite-routed devices can reveal the underlying satellite network architecture and performance characteristics. In contrast to previously used "inside-out" methodologies (i.e., connecting a measurement instrument to a satellite dish), which require physical access to privileged vantage points, the "outside-in" HitchHiking methodology requires no specialized hardware or painstaking recruitment. HitchHiking can measure wherever satellite clients are already located across the globe.

Broadly, HitchHiking consists of three steps: (1) identify publicly accessible endpoints (e.g., servers, routers) that transit LEO satellites for connectivity; (2) isolate where in the network path LEO satellites are used; and finally (3) craft an experiment to measure a desired characteristic (e.g., latency or availability) of the satellite link. In this section, we describe the general methodology. Then, in Section 5, we describe an implementation of HitchHiking specific to the Starlink LEO network and how it can be used to measure LEO latency.

Finding Satellite-Routed Endpoints

In the first step, HitchHiking needs to identify publicly reachable endpoints that transit a LEO satellite link and are, ideally, geographically distributed. To that end, HitchHiking must first identify networks (e.g., autonomous systems or IP blocks) that house LEO-routed services. Today, there exists only one commercial LEO network that sells to individual consumers: SpaceX-Starlink. However, within coming years, AWS Kuiper, Telesat and OneWeb, are also expected to deploy consumer-oriented satellite services.

Once a network is identified, HitchHiking must find all Internet-exposed services that are hosted on the network. Example services may include those that a customer wants to maintain remote access to, including customer-exposed router administration portals or web servers. Notably, a service hosted within the address space of a LEO network does not immediately mean it transits a satellite link. For instance, LEO-network backbone equipment that routes traffic between a ground station and a POP, while within the LEO network's IP address space, does not necessarily traverse a satellite link. Additionally, performance enhancement proxies (PEPs) are common in satellite routing as they decrease latency and increase reliability of networks by relying on proxies [START_REF] Jc Pavur | QPEP: An actionable approach to secure and performant broadband from geostationary orbit[END_REF], caches [START_REF] Thibaud | QoE enhancements on satellite networks through the use of caches[END_REF], or back-up non-LEO networks [START_REF]Peplink[END_REF]. While helpful to customers, PEPs add confounding factors to measuring LEO links. Thus, HitchHiking must filter for services that are likely using just a LEO-satellite for routing.

Isolating Satellite Links

In the second step, after filtering for end-points that rely on LEO satellites, HitchHiking must identify satellite-based network hops. HitchHiking requires that enough of the routing path be visible to an external scanner, such that enough terrestrial routing artifact can be removed to make meaningful inferences. At a minimum, HitchHiking must (1) identify the hop before a satellite path is taken (i.e., hop 16 from Figure 3), and (2) identify the hop after the satellite path is taken (i.e., hop 18 from Figure 3).

Conducting An Experiment

In the third step, having identified the satellite links in LEO satellite networks, HitchHiking can then be used to run measurement experiments. Many existing strategies for measuring characteristics of networking links (e.g., [START_REF] Allen | Using pathchar to estimate Internet link characteristics[END_REF][START_REF] Savage | Sting: A TCP-based Network Measurement Tool[END_REF]) can be applied.

For example, to measure LEO satellite outages due to a customer's location or obstruction (e.g., a seagull lands on a dish), a researcher might do the following for all exposed LEO services in the same geographic area: (1) send a ping to the router before the satellite link ("terrestrial-hop" router); (2) send a ping to the customer IP after the satellite link ("exposed-service" router); (3) label potential outages as when exposed-service router pings are dropped, but terrestrial-hop router pings are not dropped, for an extended amount of time; and (4) compare outages with neighboring exposed services, to determine if the outages are network-wide or customer-specific.

As another example, to measure LEO satellite bandwidth, a researcher might use the pathchar [START_REF] Allen | Using pathchar to estimate Internet link characteristics[END_REF] approach, where packets of increasing size sent to both the hop before and after the satellite link can be used to estimate the satellite link's bandwidth without flooding the link.

In this paper, we focus on measuring latency in the Starlink network.

Ethical Considerations

HitchHiking relies on Internet-exposed services to measure LEO satellite links. For the measurements in this paper, we follow the best practices outlined by Durumeric et al. [START_REF] Durumeric | ZMap: Fast Internet-wide scanning and its security applications[END_REF], including configuring the scanner's IP to re-direct to an informative page that easily allows end-users to opt out of scans. We received no requests to opt out. We present HitchHiking to Starlink's engineering team and do not receive any reproach.

HitchHiking is not the first to use the presence of exposed devices to measure Internet behavior. For example, researchers have tracked software patching behavior [START_REF] Durumeric | The matter of heartbleed[END_REF] and measured the impact of natural disasters [START_REF] Durumeric | ZMap: Fast Internet-wide scanning and its security applications[END_REF] using exposed services. HitchHiking can also use application layer data, such as TLS certificates, to identify owners of a service. HitchHiking's use of application layer data remains consistent with the ethical standards followed by the community [START_REF] Gautam Akiwate | Retroactive identification of targeted DNS infrastructure hijacking[END_REF][START_REF] Gigis | Seven years in the life of Hypergiants' off-nets[END_REF][START_REF] Izhikevich | LZR: Identifying Unexpected Internet Services[END_REF].

However, much like at the onset of Internet-wide scanning, we need to establish guardrails for the use of exposed satellite-based services for performing experiments. For example, LEO satellite links often operate at lower capacity than terrestrial links [START_REF] Michel | A first look at starlink performance[END_REF]. It is imperative that HitchHiking experiments do not degrade the quality of service for users by, for example, flooding LEO satellite links. We recommend researchers send the minimum number of packets needed to collect statistics about a LEO link, and avoid using tools that overload bandwidth (e.g., iperf [START_REF] David | iPerf -The ultimate speed test tool for TCP, UDP and SCTP[END_REF]).

HITCHHIKING STARLINK TO MEASURE LATENCY

In this section, we present an implemention of HitchHiking to measure the latency of the only commercially available consumer-targeted LEO network: Starlink. Tracking network latency is particularly interesting in the LEO satellite setting, as LEO satellite mobility is expected to induce uniquely predictable and dynamic changes in routing paths [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF]. We measure latency by continually sending TTL limited pings on hitchhiked LEO links and collecting their round trip time.

We run a daily automated HitchHiking pipeline to measure latency with the following steps:

1. Collect Exposed Services To find measurable LEO-hosted Starlink services, we collect IPv4 and IPv6 exposed services in the Starlink network (AS 14593) using Censys [START_REF] Durumeric | A Search Engine Backed by Internet-Wide Scanning[END_REF], a public Internet device search engine. We note that researchers could also perform their own scans using tools like ZMap [START_REF] Durumeric | ZMap: Fast Internet-wide scanning and its security applications[END_REF], Masscan [START_REF] David | MASSCAN: Mass IP port scanner[END_REF], LZR [START_REF] Izhikevich | LZR: Identifying Unexpected Internet Services[END_REF], and GPS [START_REF] Izhikevich | Predicting IPv4 Services Across All Ports[END_REF].

Filter for Customer Endpoints.

To measure only services that likely use a LEO-satellite for routing, we filter for services that belong to customer endpoints. To measure Starlink customer services, we include only IP addresses whose DNS PTR record follow the Starlink customer format: customer.[location].pop.starlinkisp.net. There exist thousands of customer-exposed services in Starlink. For example, on May 10, 2023, 1 we identify a total 4,521 exposed services across 2,051 unique IPs (hosts), 857 unique ports, and 47 application layer protocols in the Starlink network. After filtering for customer endpoints, 1,790 unique IPs remain.

3. Exclude PEPs. We filter for performance enhancement proxies by automatically filtering IPs hosting a TLS certificate that belong to the most popular PEP within the Starlink network: Peplink, a PEP that combines 5G connectivity with Starlink. Filtering for Peplink removes 9% of all services (1,629 IPs remain). We manually analyze other TLS certificates and exposed services and do not find other identifiable PEPs.

4. Geolocate Services. To obtain an approximate geographic location of a Starlink service, we use Starlink's IP Geolocation feed [START_REF]Starlink GEO IP Mapping[END_REF]. Additionally, to identify the location of the customer's assigned POP, we (1) query the PTR record (e.g., customer.atlagax1.pop.starlinkisp.net) associated with each host IP, (2) use the geographic location specified in the domain name (e.g., atlagax) to map the POP to a geographic location (e.g., Atlanta, Georgia) [START_REF]Starlink Internet Infrastructure[END_REF]. Often, the geolocation of a customer is not the same as the geolocation of a customer's POP, since most cities do not have a Starlink POP. 1 All experiments in this section use data collected on May 10, 2023. 5. Identify Last Visible Pre-Satellite Hop. We measure the satellite link using an "outside-in" perspective. In Figure 3, we show the output of running a traceroute2 from Stanford to an exposed Starlink service located in San Diego that we control. 3 . The outside-in traceroute identifies the second-to-last hop (Hop 16) as the occurring right before the satellite link. Note, the hop immediately before the exposed service (Hop 17) is not visible. In Appendix B.1, we use an internal network perspective to show that there is negligible RTT difference between the routers responsible for Hop 16 and 17.

6. Identify First Visible Post-Satellite Hop. The last responsive hop in the traceroute is typically the first, and only, visible post-satellite hop. Notably, while the link between the last visible pre-satellite hop and the first visible post-satellite hop includes the satellite link, it also includes the terrestrial pathway between the POP and the ground station. In Section 6, we show how our measurement technique filters much of the terrestrial routing outside of Starlink's network.

7. Measure Path Latency. We measure path latency for 5 minutes sending two ICMP pings every second with the following additional configuration: (1) with a TTL equal to the terrestrialhop-router-hop number and (2) with a TTL equal to the exposed-service hop number. Notably, only one probe traverses the satellite link during each measurement, thereby minimizing ethical concerns. In Appendix B and Appendix C, we show how sending TTL-specific pings increases coverage by an order of magnitude compared to TCP, UDP, and non-TTL specific pings.

8. Isolate Satellite Link Latency. We subtract the terrestrial-hop router RTT from the exposedservice router RTT, to measure the satellite link and minimize terrestrial artifacts.

9. Filter for Non-LEO Satellite Artifacts. We apply a smoothing filter with a window size of 15 seconds (the time-step with which Starlink dishes stay connected to a satellite, before determining whether to switch connections [START_REF]Petition of Starlink Services, LLC For[END_REF]) to our timeseries of collected measurements, to eliminate short-lived artifacts (Section 6.1). Fortuitously, routers (one of the most popular hosts of exposed services) must be physically connected to a satellite dish using Ethernet [START_REF]Starlink Specifications[END_REF], thereby additionally minimizing potential Wi-Fi artifact. At least one-third of customer-exposed Starlink services belong to a vendor that produces routers and firewall appliances, with the two most poular being Fortinet and Sonicwall. the client, does not know how many satellites, which satellites, and which ground stations packets are routed through. To understand if the incomplete visibility is still sufficient, in the next section, we validate HitchHiking with physical equipment. Critically, we find that HitchHiking's lack of visibility is not a limitation of HitchHiking; even Starlink customers with physical equipment have near identical visibility into Starlink's routing. In spite of this incomplete visibility, in Section 7, we demonstrate how HitchHiking's global perspective helps build informed inferences that illuminate previously undisclosed routing patterns.

Overall, the HitchHiking pipeline is designed to be quickly adaptable to new users and geographic locations. Since LEO network architecture changes nearly everyday due to new satellite launches [START_REF]Launches[END_REF], satellite falls [START_REF]SpaceX Satellites Tumble Out of Orbit After Geomagnetic Storm[END_REF], the integration of inter-satelllite lasers [START_REF] Foust | SpaceX adds laser crosslinks to polar Starlink satellites[END_REF], and new ground stations [START_REF] Swinhoe | Starlink building or expanding more than 20 US ground station sites to operate in Eband[END_REF], adaptability is crucial. The HitchHiking pipeline, which is open sourced under the Apache 2.0 licence, along with the data it collects, can be found at https://github.com/stanfordesrg/LEO_HitchHiking.

EVALUATION

In this section, we evaluate the accuracy and coverage of HitchHiking on the Starlink network. First, we show that HitchHiking accurately measures satellite link latency relative to ground truth, capturing 100% of all sustained latency spikes. Second, we compare HitchHiking's accuracy with the most popular LEO-network simulator and show that HitchHiking is up to 80% more accurate. Third, we demonstrate HitchHiking's expansive coverage of LEO satellite links, which spans 13 countries and contains 28 times more measurable links than other methods.

Comparison with Ground Truth

To obtain ground truth about a client's LEO network latency, we deploy our own residential generation 2.0 Starlink4 dish in San Diego. To make our LEO link "hitchhikeable, " we (1) turn on router ping by bypassing the Starlink router with our own Asus RT-N66U router (Starlink generation 2.0 routers do not allow for port forwarding or respond to ICMP probes), and (2) configure our router to advertise the Starlink-provided public IPv6 address.

We also collect Starlink provided metrics from our dish every second, including the reported "POP ping latency," packet drop, and estimated bandwidth usage. The POP ping latency is the ground truth RTT of a ping from our dish to the assigned POP. The POP ping latency is the most granular provided metric of LEO latency; it includes terrestrial latency to and from the ground station. Starlink metrics do not reveal which ground station or satellite the dish is connected to [START_REF]Starlink Dishy: getting some deeper status[END_REF]. However, we use a novel side-channel in our Starlink dish, the obstruction map, which in real time records the location of a successful satellite connection. We describe in Appendix D our side-channel methodology.

6.1.1 HitchHiking. We compare HitchHiking measured latency to ground truth. To evaluate HitchHiking under different distances from San Diego, we run HitchHiking from four geographic locations: Australia, Brazil, California (US), and Virgina (US). Each location is 500-8,000 miles away from our dish. All HitchHiking pipelines run at the same time on May 12, 2023. We note the presence of clear skies and no physical obstructions, and thus minimal interference during our experiment.

Evaluation. Across all HitchHiking vantage points, HitchHiking captures latency statistics that are close to the ground truth: 96% of reported RTT times are within one standard deviation (10 ms), and 50% of RTT times are within 3 ms of the ground truth (i.e., the dish's pop ping latency). We illustrate the output of HitchHiking relative to the ground truth in Figure 4a and the output of HitchHiking without removing terrestrial artifact-to better depict the captured RTT patterns across HitchHiking locations-in Figure 4b. HitchHiking captures 100% of all sustained RTT spikes, which we define as latencies over two standard deviations away from the median that last at least 15 seconds (i.e., the Starlink minimum amount of time dishes stay connected to the same satellite [START_REF]Petition of Starlink Services, LLC For[END_REF]). We describe the underlying cause for sustained RTT spikes (ISL usage) in Section 7.

HitchHiking observes only one false-positive RTT spikes across our cumulative 10,000 second measurement period. All but one HitchHiking geographic location has a 0% false positive rate for capturing RTT spikes. When HitchHiking is deployed 6,000 miles from our ground-truth dish, it returns one false positive RTT peak near second 1800. We attribute the false positive to a less stable terrestrial-router hop; while other terrestrial-router hops never deviate more than 1 ms from the average, the 6,000 miles terrestrial-router hop jitters up to 10 ms in latency near second 1800. Thus, although terrestrial-router RTT is subtracted from the final hop, jitter can propagate. To decrease the false positive rate of finding sustained latency spikes, in Section 7, we only study endpoints whose second-to-last hop experiences no more than 1 ms deviation of RTT.

Sustained spikes in RTT are not caused by distant satellite location and not always caused by satellite switches. In Figure 5a, we present the obstruction map overlayed with the corresponding ground truth RTT. There exists no clear correlation between sustained latency and the satellite locations relative to the dish: sustained anomalous RTTs, colored in red, occur throughout all satellite locations. In Figure 5b, we vertically mark every satellite change, which we detected when the dish connects to a satellite that is not neighboring the prior connection's location. Within the first 500 seconds of measurement, the first sustained RTT peak occurs while still connected to the same satellite. Across the entire measurement period, 2/5 sustained RTT spikes occur while still connected to the same satellite. For standard RTT spikes (i.e., spikes over one-but not twostandard deviations above the median), 5% occur while still connected to the same satellites. Thus, satellites switches are not the ultimate cause behind latency spikes.

RTT spikes are also not due to congestion. The ground truth metrics report no packet drop or drop in bandwidth during sustained or standard latency spikes. Furthermore, we find that spikes occur in multiples of 15 second-aligning with Starlink's reported satellite reconfiguration period [START_REF]Petition of Starlink Services, LLC For[END_REF]-further making any cause of latency that is independent of Starlink routing (e.g., brief congestion caused by a nearby user) unlikely. In Section 7, we use HitchHiking's global perspective, and validation by Starlink, to show that sustained latency spikes are due to routing path changes exacerbated by ISLs. Notably, Starlink shares that routing path changes can happen even if a user remains connected to the same satellite.

6.1.2 LEO Simulations. LEO simulations model real-world LEO networks to help researchers explore scenarios that are impossible to test on real networks. We consider two LEO simulators: (1) the most widely-used, Hypatia [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF] and (2) the newest, StarryNet [START_REF] Lai | {StarryNet}: Empowering Researchers to Evaluate Futuristic Integrated Space and Terrestrial Networks[END_REF].

Hypatia is a LEO simulator that takes as input the geographic location of ground stations and satellite constellation parameters (e.g., number of satellites, their altitude, inclination, etc.). Hypatia then returns the predicted RTT packet latency between two ground stations (GS) A and B. We show that HitchHiking is more accurate than Hypatia at estimating LEO latency. Unfortunately, we cannot evaluate against StarryNet because it requires over 2 TB of RAM to simulate Starlink and is not able to run in cloud environments 5 . Methodology. To model Starlink latency, we configure Hypatia with the Starlink constellation parameters published by the FCC [START_REF]Satellite Earth Station FCC Filing[END_REF]. To model client latency to a POP, we run multiple simulations where GS A is the location of our dish (Section 6.1) and GS B is a GS within the set of all GS that are reachable using one satellite hop from the dish. To account for additional terrestrial latency between the ground station and POP, we add the latency that a packet would incur traveling at 2/3rds the speed of light (i.e., estimated optical fiber latency [START_REF] Aizaz | Optical Wireless Satellite Networks versus Optical Fiber Terrestrial Networks: The Latency Perspective: Invited Chapter[END_REF]) between the ground station and POP.

We use Hypatia's default satellite selection algorithms: Hypatia connects the client with a satellite that minimizes the RTT between the client and ground station. In Appendix E, we present the results of configuring Hypatia using a theoretical worst case satellite selection algorithm and find that it does not significantly change the quality of Hypatia's predictions. We compare Hypatia results with our ground truth dish and a HitchHiking deployment located 500 miles away from the dish. Evaluation. While HitchHiking accurately estimates LEO satellite latency relative to ground truth, Hypatia is difficult to parameterize such that its output matches ground truth.

DNS

In Figure 6a, we illustrate the output of Hypatia when using the best-case satellite selection algorithm, and a subset of nearby groundstations (the nearest, second nearest, and furthest). No matter the ground station, Hypatia never predicts that a client experiences sustained RTT spikes, unlike HitchHiking (Figure 6b). In Section 7.2, we find that RTT peaks are due to dynamic ISL routing patterns, which Hypatia is unaware of. Notably, configuring Hypatia to use the second nearest ground station produces a latency prediction that on average is only 7.6 ms in error relative to the ground truth.

Nevertheless, HitchHiking RTTs are on average 1.8 times more accurate than Hypatia. Hypatia's inability to model real-world LEO links is not necessarily a deficiency of Hypatia, but rather a limitation of applying theoretical models to predict latencies about a network that reveals little about its operation. Starlink does not reveal its internal fiber paths between ground stations and POPs, terrestrial routing decisions, satellite selection algorithm, ISL routing, or congestion patterns. In order to approximate latency, the only ground truth information Hypatia has access to is satellite and ground station location.

Nevetheless, Hypatia's theoretical minimum calculations can help illustrate which ground stations a dish is connected to. Given that 20% of ground truth RTT fall below the second-nearest ground station best-case RTTs, Starlink must be connected to the nearest ground station at least 20% of the time. However, using Hypatia alone, it is unclear whether other increases in RTT latency are due to connecting to a different ground station, or congestion. 6.1.3 RIPE Atlas. RIPE Atlas-one of the most comprehensive community-driven Internet measurement platforms-provides substantially less coverage and granular statistics than HitchHiking. Unfortunately, the nearest RIPE Atlas dish that is assigned our POP is located over 300 miles away (i.e., uses a different set of ground stations). Furthermore, RIPE Atlas limits measurements to occur no more frequently than every 60 seconds, making it difficult to capture sustained RTT spikes that often change every 15 seconds.

HitchHiking Coverage

HitchHiking provides the most comprehensive coverage of LEO networks today. Fortuitously for HitchHiking, LEO network customers expose services across the world. On May 10, 2023, we use HitchHiking to measure all (publicly exposed) LEO links in the Starlink network. In Table 1, we list the POP locations of Starlink customers that expose services, as well as the POP locations of all RIPE Atlas Starlink Probes. HitchHiking has 28 times more exposed services than RIPE Atlas, whose services use POPs across only five countries. Only seven IPs found by HitchHiking overlap with those of RIPE Atlas. HitchHiking finds exposed Starlink services are assigned to POPs that reside across 20 cities and 13 countries. While a majority (59%) of HitchHiking found services use POPs in the US, there exists a long-tail of other locations including Australia (7%), Germany (6%), and England (3%).

WORLDWIDE LATENCIES IN THE WILD

We perform the most geographically-diverse data-driven analysis of LEO satellite latency to date. Our global perspective illuminates that real world deployment of a global LEO network is more complex than previously understood. While prior work attributed differences in customer latency to localized effects such as satellite location or congestion, we infer, and validate, that customer latency is correlated with a customer's distance to POP and unexpected ground station selection. Additionally, our investigation surfaces an overlooked reality by prior work: while ISLs do increase coverage, they significantly increase the distance of the route between the ground station to POP.

We use the HitchHiking methodology (Section 5) to collect Starlink latency data between May 18-June 23, 2023. Additionally, we use HitchHiking to scan the IP addresses of all Starlink RIPE Atlas probes, which provide ground truth about customer location; we mention when RIPE Atlas probes are used in our analysis. We filter the initial 3.5K exposed customer Starlink IPs for jittery presatellite hops, leaving 2.4K IPs that host exposed services. The set of services follows a geographic distribution similar to Table 1. In this section, we investigate how a customer's distance to POP correlates with their expected latency. We find that even with Starlink's vast network topology, remote customers can experience latency increases by over three fold compared to other customers assigned to the same POP.

In Figure 7, we plot the HitchHikingmeasured latency and distances of the RIPE Atlas probes with their respective POPs. The further a Starlink customer is from their POP, the greater their minimum RTT. In the worst case, a customer from the US Virgin Islands is assigned to their nearest POP, in Atlanta, Georgia, located roughly 1600 miles away. They experience a minimum RTT nearly twice as large compared to customers that are closer to their own POP.

Minimum RTT can be used to approximate customer location when no ground truth is available (i.e., when measuring non-RIPE Atlas exposed services). For example, in Figure 8a, minimum RTT from data collected on May 18, 2023, indicates that customer e must be located much closer to the Nigerian POP than customer c. Indeed, customer c is on a yacht near Seychelles (they host a TLS certificate registered to the name of a unique sportfisher yacht, which MarineTraffic.com shows to be near Seychelles [START_REF]Ship Alduhail[END_REF]) while customer e is in the Nigerian Palm-Oil farm (i.e., the customer hosts a TLS certificate that fingerprints to a Nigerian Palm-Oil farm). Additionally, in Figure 8c, we find that customer p, whose minimum RTT is nearly 3 times larger than average minimum RTT, is thousands of miles away from their assigned nearest Seattle POP (customer p's exposed email server belongs to Vuntut Gwitchin First Nation, a cultural site, which is located thousands of miles away Seattle near the northern border of Canada).

Notably, no matter a customer's distance to their POP, all of our Starlink traceroutes show that packets are always tunneled to/from the customers assigned POP before traversing the public Internet6 , thereby causing unavoidable latency. Tunneling customers through a home gateway across all connections is not unique to Starlink, but rather also common in mobile networks [START_REF] Maria Mandalari | Experience: Implications of roaming in europe[END_REF].

Routing Changes

We next investigate how routing changes between a client, groundstation, and POP correlate with latency. We find that customers physically located within ground station coverage experience surprising spikes in latency due to sub-optimal routing changes that are exacerbated by ISL technology, which Starlink engineers confirm. To deduce routing causes of latency, we take advantage of HitchHiking's ability to measure customer latency nearly anywhere in the world. We study a POP that minimizes the most variables in packet routing: the Nigerian POP. The Nigerian POP has the least number 7 of ground stations (2) a negligible distance (80 miles) apart, within a one-hop satellite distance. We study a customer that we confirm is physically near their assigned Nigerian POP: the Palm-Oil customer (customer e from Section 7.1). Notably, without HitchHiking, one would have to solicit volunteers in Nigeria (of which currently there are none in RIPE Atlas) or travel with a dish to Nigeria.

In the simplest case of routing, the Palm-Oil customer will connect to one of the two Nigerian ground stations nearby, using a one satellite "relay" hop (Figure 9a). After connecting to any ground station, the packet is always terrestrially routed to the POP, as revealed by Starlink [9, 12] 8 . To deduce how often relay routing occurs, we first plot the customer's RTT over time in Figure 10 from data collected on May 18, 2023. Second, we plot Hypatia's calculated minimum RTT when using non-relay routing (i.e., two satellites with ISLs) to the Nigerian ground station ("Min(ISL-NG)"). Over 70% of customer RTTs fall below Min(ISL-NG), indicating that in the of cases the customer falls below the theoretical minimum latency of using two satellites to route to the nearest ground station, and therefore must be using single-hop relay routed to the nearest ground station. 7 We rely on public crowd sourcing to collect country-specific SpaceX requests for ground stations [7,8,[START_REF]Satellite Earth Station FCC Filing[END_REF] to map the ground station topology of Starlink's network. Given Starlink's large fanbase who enjoy tracking ground station locations [START_REF] Owens | Unoffical Starlink Global Gateways & PoPs[END_REF][START_REF] Puchol | [END_REF] we assume that our knowledge is complete. Even if our knowledge was incomplete, sustained latency spikes that increase RTT by nearly an order of magnitude (e.g., second 350 in Figure 10), could not be explained by connecting to nearby ground stations within one hop). 8 In Section 5 we confirm that packets are routed terrestrially for as long as possible before reaching the satellite path. In Appendix B, we confirm that no matter the public Internet destination, packets leave their assigned (nearest) pop and continue the route terrestrially.

However, one-third of the time, the Nigerian customer's RTTs increase between 2-5 fold the median, indicating that Starlink is likely connecting customers with distant ground stations 9 . Indeed, Starlink engineers confirm that these sustained latency spikes are due to customers using ISLs, which route through ground stations located anywhere in the world-not necessarily in close geo-proximity 10 . Thus, the outlier latency (162 ms) near second 350 in Figure 10 could be the sum of the following footnoted equation 11 , which shows that it would take at least 154 ms for a Nigerian POP customer to route through the nearest non-Nigerian ground station, in Lepe, Spain (Figure 9c). The Nigerian customer's terrestrial route from the Spanish ground station would span over 4970 miles, given that all customers traverse from their ground station to their assigned POP terrestrially (Section 7.1). The sustained latency spikes near seconds 175 and 300 in Figure 10 are likely due to ISLs routing back to the Nigerian ground station, as depicted in Figure 9b. While the sustained peaks are above the theoretical minimum latency, when accounting for potential additional latency due to bad satellite selection 12 (12ms) and an indirect ISL routing path 13 (13 ms), the total RTT is within 5 ms of the second highest sustained peak at second 300.

While it may seem that always routing through a customer's assigned POP, even when a closer POP is available, is uniquely inefficient, routing through an assigned gateway is a wide-spread practice in IP Packet Exchange Networks (IPX) during international roaming. Mandalari et al [START_REF] Maria Mandalari | Experience: Implications of roaming in europe[END_REF] show that in IPXs, significant latency increases occur due to the strict requirement of packets routing through the customer's home gateway, no matter the packet destination, so that cellular carriers can easily monitor data usage, perform content filtering, etc. While Starlink customers are often stationary, the satellites (and their routing path) are not, causing routing patterns similar to international roaming. Coincidentally, the majority (70%) of Starlink traceroutes leak MultiProtocol Label Switching, a protocol heavily used by IPXs to route between gateways [START_REF] Maria Mandalari | Experience: Implications of roaming in europe[END_REF].

We find that customers who must fully rely on ISLs experience latency that is substantially worse than the expected latency of direct ISL routing, which Starlink independently confirms [START_REF]r/Starlink -Service in Mozambique is provided only by space lasers[END_REF][START_REF]r/Starlink -Starlink Global Roaming Service[END_REF]. For example, the Seychelles-yacht customer thousands of miles away from Nigeria (Section 7.1) is surrounded by no ground stations, and therefore must solely rely on ISLs to route to its assigned Nigerian-POP. The Seychelles yacht's experiences a minimum RTT ms (6 times worse than Palm-Oil-Farm Customer's minimum RTT) indicating that it is theoretically improbable that ISLs are using a direct path to reach the ground station nearest to the Nigerian POP (i.e., a direct speed of light path from Seychelles to the Nigerian POP would take an RTT of 40 ms, and no more than 80 ms to account for potential "zig-zag" paths between satellites [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF]). Rather, the Seychelles yacht is also likely routed to a further ground station and suffers the additional latency of a terrestrial path back to the customer POP. Making matters worse, the Seychelles yacht is likely frequently 9 We record no packet drop during the RTT increases and know that a sustained latency increase is not ultimately due to a satellite switch (Section 6.1.1). 10 Starlink shares that routing is determined based on link availability, reliability, and capacity. 11 A Nigerian POP customer symmetrically routed through Spain would experience at least the following latency, where 𝑐 is the speed of light: re-routed: during 42% of our measurement period, the yacht's RTT is 150 ms over its minimum RTT. Sustained latency spikes are widespread and constant; at least 70% of customers experience at least one sustained latency every day during our month-long 5 minute data collection. Starlink engineers share that they are still building their ISL "mesh" and hope to improve edge case performance over time. In the next section, we find other instances of customers who experience impactful latency patterns and study how customer latency changes over time.

Geographic and Temporal Patterns

Latencies across POPs significantly vary due to their assigned types of customers (e.g., maritime, stationary) and distances of customers (e.g., extremely remote). We plot the distribution of customer RTTs across all customers and POP locations in Figure 11. Average RTTs vary by over 500%: from 28 ms (Mexico)-149 ms (Nigeria). Standard deviation of RTTs also vary by an order of magnitude: from 4 ms (Mexico)-109 ms (Nigeria). While customers with different RTTs are commonplace across all POPs (Figure 8a-Figure 8c), we describe how certain geographies are more or less likely to attract unique customer patterns: Nigeria. As of October 2023, Nigeria contains the only POP for the entire continent of Africa, which causes African marine traffic (e.g., Seychelles yacht in Figure 8a) to be routed through the Nigeria POP. Since marine traffic must rely on ISLs, which correlate with high average RTTs (Section 7.2), it is no surprise that Nigeria customers experience the worst RTTs. Nevertheless, we see Nigeria customer latency decrease overtime. In Figure 12a, we show that between May-June, 2023 the population of customers that experience outlier behavior shrinks and median latency decreases by 25%, from roughly 400 ms to 300 ms. The downward trend in latency provides encouragement that Starlink is actively changing routing patterns.

Brazil. Brazil-POP customers experience the second largest average RTT (104 ms) and standard deviation of RTT (27 ms). While Brazil has at least 10 ground stations, its coastal location also attracts marine traffic that relies on ISLs, which correlate with substantially increased latency. For example, customer Oceanica Sub VII (identified using an exposed SNMP firewall name) who is off the coast of Fortaleza Brazil [START_REF]OCEANICASUB VII[END_REF] at the time of our experiment is 1491 mi away from its POP-a 14 ms RTT if using a direct ISL path-but experiences an average RTT of 96 ms (Figure 8b), indicating indirect routing is in use. Consistent with other marine traffic, Oceanica Sub VII continually experiences sustained latency spikes, lasting for 16% of our measurement period. Brazil customers do not see overall latency improvement in the same way as Nigerian customers do (Figure 12b). Georgia, USA. Georgia-POP customers experience the highest average (58 ms) and standard deviation (21 ms) of latency across the US. Ground truth location from RIPE atlas probes indicate that on average, a Georgia-POP customer is 1,000 miles away, partly due to customers located in the US Virgin Islands being assigned the Georgia POP. Thus, customers' often long distance to the Georgia-POP increases the lower bound of the latency that the majority of customers experience. Georgia latency patterns remain relatively stable over time (Figure 12c).

Other POPs. Peru, Australia, and New Zealend experience the shortest RTT times, on average under 30 ms. All three locations surrounded by at least six groundstations that are reachable by a single satellite-hop. We do not identify any maritime customers assigned to those POPs.

Summary

HitchHiking's global perspective shows how Starlink's complex network architecture impacts customer latency across many facets. First, we find that depending upon a customer's distance to their POP, minimum latency grows over three-fold. Second, we detect and validate that routing changes to different ground stations cause sustained latency spikes that increase RTT by near an order of magnitude. Third, reliance on ISLs (e.g., customers on boats) correlates with increases in RTT and sustained latency increases. Notably, the diversity of customers and routing infrastructure causes large variances in RTT across POPs worldwide, underlining the value of the global and diverse perspective provided by HitchHiking.

LIMITATIONS AND FUTURE WORK

HitchHiking does not replace existing methodologies, but rather serves as a low-barrier methodology that provides data about LEO links worldwide. We see many possible directions to integrate HitchHiking into future LEO research:

Measuring Other LEO Networks. While Starlink is the only LEO satellite network that sells to individuals, other LEO networks (e.g., AWS Kuiper, Telesat, etc) are expected to provide new services in the coming years. With different networking architectures, including differently-arranged satellite constellations, these networks will likely exhibit both similar and different behaviors to Starlink. HitchHiking can be applied to measure other LEO networks once customers begin to expose services. HitchHiking collected data can illuminate the similarities and differences of LEO network performance across different architectures in practice.

As an example, we use HitchHiking to identify roughly 20 OneWeb measurable-endpoints that belong to business customers located in primarily Northern regions (e.g., Alaska, Canada). We detail our exact OneWeb-specific HitchHiking methodology in Appendix F. Unfortunately, we are not able to validate latency measurements with ground truth (i.e., a OneWeb dish we control) because OneWeb dishes are (1) only available to businesses and (2) prohibitively expensive (e.g., upwards of $23,000 [START_REF]Intellian Oneweb Satellite Internet Systems[END_REF]). We hope future work with access to OneWeb equipment can validate our OneWeb-HitchHiking methodology.

Measuring LEO Networks Over Time. As Starlink continues to add more customers, ground stations, POPs, satellite orbits and routing policies, HitchHiking can be used to compare how the architecture changes network measurements over time. For example, how does adding more users in a single location affect congestion, bandwidth and latency? Do different routing policies fundamentally change customer network quality of experience? We are open sourcing HitchHiking daily-collected data, giving researchers immediate access to answer temporal questions.

Data-Driven Simulations. While simulations allow for a wider flexibility of experiments than measurements, simulation accuracy is constrained by a plethora of unknowns about how real LEO networks operate. Future work should look into (1) training predictive models with HitchHiking collected data to better simulate real-world networking conditions world wide, (2) creating "replay" models with HitchHiking data that can test the performance of new algorithms (e.g., congestion control) using real data from the past. LEO Network Coverage. While HitchHiking provides over 10 times more coverage of a LEO network than the leading alternative [START_REF]RIPE Atlas probes[END_REF], HitchHiking does not provide full coverage. For example, while Starlink has an estimated 2 million users [72], HitchHiking only measures an estimated 0.1% of all customers. Furthermore, HitchHiking is biased towards measuring customers who host exposed services, which may introduce confounding factors. Future work should investigate if other opportunities exist to measure LEO customers that do not expose services, to further increase coverage and reduce bias.

CONCLUSION

In this work we introduced HitchHiking, a methodology for measuring LEO satellite networks at scale. HitchHiking builds on the observation that Internet exposed services that use LEO-based Internet access can reveal both satellite network architecture and performance, without needing physical hardware. HitchHiking is accurate and provides an order of magnitude more coverage than alternative solutions. Using our new global perspective, we study over 2.4K Starlink customers across farms, boats, and remote regions, to understand user latency.

Our investigation surfaces that contrary to prior assumptions, sustained peaks of latency are not caused by distant satellite location. We highlight that ISL routing patterns create the widest variance of latency. While ISLs were advertised as a low latency solution for more direct routing [START_REF] Kassing | Exploring the "Internet from Space" with Hypatia[END_REF][START_REF] Musk | [END_REF], they significantly increase the length of the routing path between the ground station to POP, at the benefit of increasing connectivity (e.g., to ships).

Connectivity at the cost of latency is not unique to Starlink; mobile networks face the same tradeoff when providing international roaming under different regulatory bodies [START_REF] Maria Mandalari | Experience: Implications of roaming in europe[END_REF]. By increasing connectivity through ISL deployment, Starlink customers now occasionally experience RTTs that are inching closer to GEO latency. As LEO networks continue to increase connectivity, we hope the community uses HitchHiking to understand their real-world deployment when continuing to help design and protect the LEO ecosystem. all 360 degrees. In Figure 13, we illustrate the worst case predictions between the client and a subset of ground stations. Unfortunately, even worst case predictions do not capture Starlink's RTT dynamics. OneWeb is a LEO constellation that provides Internet for businesses, rather than individual customers [START_REF]Oneweb[END_REF]. We apply the HitchHiking methodology to measure OneWeb. However, we are not able to validate latency measurements with ground truth (i.e., a OneWeb dish we control) because OneWeb dishes are (1) only available to businesses and (2) prohibitively expensive (e.g., upwards of $23,000 [START_REF]Intellian Oneweb Satellite Internet Systems[END_REF]). We outline the OneWeb-specific HitchHiking steps below.

F USING HITCHHIKING TO MEASURE ONEWEB

1. Collect Exposed Services. We use Censys to collect all exposed services in the OneWeb network (AS 800).

2. Filter for Customer Endpoints. For OneWeb services, customer IP addresses resolve to business names. Thus, HitchHiking uses a blocklist approach in which it filters for PTR or SOA records that do not contain OneWeb's domain, nor the domain of any regional Internet registry (i.e., AFRINIC, ARIN, APNIC, LACNIC, or RIPE).

3. Exclude PEPs. We do not identify any PEPs.

4. Geolocate services. To determine the geographic location of OneWeb services, we leverage an observation: OneWeb enterprise customers are listed as the registrant of One Web IP addresses in the whois database. Thus, we use the location of the registrant to determine the likely location of the service. Unlike Starlink, the majority of OneWeb expoesed services are located in Northern regions, including Alaska.

4.Identify satellite-routed path. OneWeb does not publicly reveal internal network operations. Moreover, since OneWeb only caters to enterprise and government clients, we do not have access equipment that can provide an internal network perspective. We conduct Ingress traceroutes to all the OneWeb endpoints from a server in Stanford, and show an example traceroute in Table 3. To measure OneWeb satellite latency, we subtract the second-to-last visible hop from the last hop.

6Fig. 3 .

 3 Fig. 3. Truncated "Outside-In" Traceroute From Public Server to Starlink Dish-The LEO link is traversed between the last hop and the second-to-last responsive hop, as indicated by a jump in latency.

  Fig. 4. Comparing Hitchhiking With Ground Truth-HitchHiking from different servers world-wide is always able to detect long-lasting spikes in latency.

  Sustained Latency Spikes are Not Correlated With Satellite Location-An image projection of the satellites the dish connects to when facing the sky (Appendix D), overlayed by the user's RTT when connected to each satellite's location, shows no correlation between high RTTs and satellite location.

  Sustained Latency Spikes are Not Always Satellite Changes-Satellite switches are computed using the obstruction map above.

Fig. 5 .Fig. 6 .

 56 Fig. 5. Satellite Location Relative to Latency-Sustained increased latency is not due to satellite location or satellite changes.

Fig. 7 .

 7 Fig. 7. Latency vs POP Distance-Customers located further from their assigned POP experience higher minimum RTT times.

7. 1

 1 Fig. 8. Client Latencies (Log Scale)-Due to a variety of factors (distance from POP, ISL usage), clients assigned to the same POP experience latencies that differ by an order of magnitude.

Fig. 9 .Fig. 10 .

 910 Fig. 9. Routing Options-Paths from a client to its POP can vary in satellite hops and length.

(Fig. 11 .

 11 Fig. 11. Latency Across All Starlink POPs-Customer latency varies dramatically depending upon their geographic location. Nigerian-POP customers experience the highest average RTT.

Fig. 12 .

 12 Fig. 12. Latency Over Time-POP latency changes over time depending upon the geographic location.

Fig. 13 .

 13 Fig. 13. Worst Case Hypatia Predictions-Simulations do not capture the dynamics of real-world Starlink RTTs.

  10. Validating Incomplete Visibility While HitchHiking lowers the barrier for identifying LEO satellite routing in the wild, it does not have complete visibility of all satellite routing. When measuring Starlink, HitchHiking cannot identify exactly what routing occurs between the POP and

	RTT (ms)	50 100		8K		Hitchhiking Server Distance (mi) 6K 500 Ground Truth	2.5K
		0	250	500	750	1000 Time (s)	1250	1500	1750	2000

Table 1 .

 1 Geographic

		POP	# Distinct IPs
	Subdomain Location	Hitch-RIPE
			Hiking Atlas
	sttlwax1	Seattle, Washington	243	7
	atlagax1	Atlanta, Georgia	210	4
	dllstxx1	Dallas, Texas	186	1
	chcoilx1	Chicago, Illinois	182	6
	lsancax1	Los Angeles, California	173	2
	sydyaus1	Sydney, Australia	148	4
	nwyynyx1	New York City, New York 144	6
	frntdeu1	Frankfurt, Germany	124	13
	dnvrcox1	Denver, Colorado	87	7
	lndngbr1	Heathrow, England	56	6
	mdrdesp1	Madrid, Spain	20	0
	sntoch1	Santiago, Chile	19	1
	acklnzl1	Auckland, New Zealand	11	0
	lgosnga1	Lagos, Nigeria	6	0
	bgtacol1	Bogata, Columbia	5	0
	limaper1	Lima, Peru	3	0
	prthaus1	Perth, Australia	3	1
	qrtomex1	Mexico City, Mexico	3	0
	splobra1	San Paulo, Brazil	3	0
	tkyojpn1	Tokyo, Japan	3	0
	Total		1,629	58
		Coverage of Exposed Ser-
	vices-Starlink exposed services are geographically
	wide-spread, providing HitchHiking an ample amount
	of measurable LEO links.

  Brazil POP Latency Over Time-Outliers in latency briefly decrease before increasing again over time.

	Nigeria POP RTT (ms)	250 500 750
		5 -2 1 5 -2 2 5 -2 3 5 -2 4 5 -2 5 5 -2 6 5 -2 7 5 -2 8 5 -2 9 5 -3 0 5 -3 1 6 -1 6 -2 6 -3 6 -4 6 -5 6 -6 6 -7 6 -8 6 -9 6 -1 0 6 -1 1 6 -1 2 6 -1 3 6 -1 4 6 -1 5 6 -1 6 6 -1 7 6 -1 8 6 -1 9 6 -2 0 6 -2 1 6 -2 2 6 -2 3 Date
		(a) Nigeria POP Latency Over Time-Outliers in latency decrease over time.
	Brazil POP RTT (ms)	200 400
		5 -2 1 5 -2 2 5 -2 3 5 -2 4 5 -2 5 5 -2 6 5 -2 7 5 -2 8 5 -2 9 5 -3 0 5 -3 1 6 -1 6 -2 6 -3 6 -4 6 -5 6 -6 6 -7 6 -8 6 -9 6 -1 0 6 -1 1 6 -1 2 6 -1 3 6 -1 4 6 -1 5 6 -1 6 6 -1 7 6 -1 8 6 -1 9 6 -2 0 6 -2 1 6 -2 2 6 -2 3 Date
	5 -2 2 5 -2 3 5 -2 4 5 -2 5 5 -2 6 5 -2 7 5 -2 8 5 -2 9 5 -3 0 5 -3 1 6 -1 6 -2 6 -3 6 -4 6 -5 6 -6 6 -7 6 -8 6 -9 6 -1 0 6 -1 1 6 -1 2 6 -1 3 6 -1 4 6 -1 5 6 -1 6 6 -1 7 6 -1 8 6 -1 9 6 -2 0 6 -2 1 6 -2 2 6 -2 3 Date (b) 5 -2 1 200 400 GA, US POP RTT (ms)
		(c) Georgia, US POP Latency Over Time-Latency remains stable over time.

Table 3 .

 3 Truncated Traceroute From Public Server to OneWeb-The LEO link is traversed between the last and second-to-last hop, as indicated by the single spike in latency.

	Hop Router IP	RTT Network
			(ms)
	3	104.255.10.149 50	Astute Hosting
	4	*
	5	*
	6	Customer IP	118	OneWeb

We experiment with many different traceroute tools in Appendix B.

To connect to our dish from an external server, we (1) configure the Starlink router to run on "bypass" mode, (2) connect our own router, (3) configure our router to respond to pings, (4) identify the public IP address Starlink has assigned to us, and (5) ping our Starlink IP address (i.e., our router) from the external server.

Starlink is the only commercially available LEO-provider that sells to individuals, and therefore the only network that easily provides ground truth.

We inspect the source code and find that StarryNet requires a specific type of local network reconfiguration which Google Cloud cannot successfully execute.

Packets are always first routed through the customer's assigned Starlink POP once they enter the Starlink network. We conduct Section 6.1's experiment in reverse (contact the geographically distributed servers from our dish), and find that when sending packets from a Starlink dish, packets are always routed through the customers assigned POP before leaving the Starlink network.

We compute worst case RTT using the methodology in Appendix

[START_REF]Musk's Starlink connects remote Tonga villages still cut off after tsunami[END_REF] Starlink's first shell contains 22 satellites per orbit, creating a roughly 1243 mi distance between satellites. If using an extra satellite to ISL route through, that would create additional RTT of 2* 1243 mi/speed of light (13 ms).

A ETHICS Our work does not involve human subjects and therefore, according to our institution's IRB policies, does not require IRB approval. Nevertheless, we agree with and support the mission of minimizing harm when measuring LEO links, and thoroughly discuss the measures we take in Section 4.4.

B MAPPING THE STARLINK NETWORK WITH TRACEROUTE

To map Starlink, we first experiment with different tools and protocols, to determine which illicit the most network information. We experiment with running ICMP, UDP, and TCP traceroutes across the following tools, which differ in the manner they construct and send packets: dublintraceroute [6], paris-traceroute [START_REF] Augustin | Avoiding traceroute anomalies with Paris traceroute[END_REF], tcp-traceroute [30], mtr (with the mpls flag) [START_REF]What is My Traceroute (MTR)?[END_REF], and TNT [START_REF] Vanaubel | TNT, watch me explode: A light in the dark for revealing MPLS tunnels[END_REF]. When scanning all Starlink customer endpoints (Section 5) from Stanford, 60.3% are reachable across all tools using ICMP, 17.2% are reachable using UDP, and 24.6% using TCP. The number of routing hops within the Starlink network nearly always (96% of the time) does not change depending upon the tool or protocol used.

After performing all variations of traceroute, we find three noteworthy network characteristics of Starlink: (1) Starlink routes TCP and UDP packets through a changing set of IP addresses before reaching the endpoint, while keeping a consistent routing path for ICMP packets. While 98.3% of tcptraceroutes result in a second-to-last hop set of at least two IP addresses, 100% of ICMP paris-traceroutes result in in a second-to-last hop set of just one IP address. (2) Starlink's consistent routing path traverses the customer's POP across 100% of traceroutes, no matter from/to where the server and client are. (3) Starlink uses MPLS routing before reaching the end-host. Consequently, a subset of routing is not visible to any traceroute tool. TNT, a tool used to uncover routing behind MPLS does not find any new networking paths within Starlink. While mtr reveals the last label assigned to a packet at the end of an MPLS tunnel, we do not identify any useful patterns.

B.1 Mapping Starlink's Routing

To obtain ground truth on Starlink's internal network operation, we purchase a Starlink generation 2 router and dish [START_REF]Order Starlink[END_REF], and deploy it in San Diego. To identify where internal satellite routing occurs, we conduct egress ICMP paris-traceroutes from our dish to a diverse set of end-points, including at least 3 LEO satellite endpoints (Section 6.2) in every available country, all the geographicallydistributed DNS root servers, and geographically distributed AWS servers (described in Section 6). Across all egress traceroutes, once a packet leaves our dish's local area network (LAN), there is a spike in the round trip time (e.g., 39ms in Table 2). All subsequent Starlink (ASN 14593) hops incur negligibly different round-trip-times, suggesting that the first hop encompasses at least the entire satellite link (i.e., dish to satellite to groundstation). We further validate in Section 6 that the satellite link is within the first hop.

While the first visible non-LAN hop includes the satellite link, it likely also includes the terrestrial pathway between the groundstation and POP. Starlink addresses that are one hop away from a different autonomous system (e.g., hop 5 in Table 2) likely belong to equipment located in Internet Exchange Points (i.e., Starlink PoPs), as they are (1) often (68.2% of the resolvable hostnames) preceded by an IP address a hostname suffix that indicates an IXP presence (e.g., any2ix.coresite.com, ch3.unitedix.net) (2) nearly always (87.6%) experience less than 1ms RTT difference between the preceded router. All Starlink IP addresses between the POP hop and the client incur negligible additional latency, indicating that they are likely not a ground station, which, in our experiment, is built at least 100 miles away from the POP. Thus, with physical equipment and today's networking tools, Starlink's satellite link will include terrestrial latencies between the groundstation and POP. We further evaluate the groundstation impact in Section 6.1.2. We define a ttl ping as an ICMP paris-traceroute with the first hop and max-ttl set to the same hop number. To ping the terrestrial router we set both the first hop and the max-ttl to the terrestrial-hop-router-hop number (i.e., the second-to-last visible hop in the paristraceroute). To ping the exposed service router we set both the first hop and the max-ttl to the exposed-service-hop-router-hop number (i.e., the last hop in the paris-traceroute). We opt to use ttl pings over regular pings due to the lack of coverage regular pings provide for terrestrial routers. We find that 99.2% of regular pings to terrestrial-hop-router-hops never respond. In contrast, 0% of ttl pings to terrestrial routers resulted in complete packet loss.

C HITCHHIKING IMPLEMENTATION DETAILS CONTINUED

To use ttl pings, we rely on the assumption that the terrestrial-hop-router-hop number and the exposed-service-hop-router-hop number and the IP addresses they map to are stable. We validate the assumption by running 100 paris-traceroutes, one second apart, to each exposed service. We find that the vast majority of the exposed-service-hop-router-hop numbers (96.1%) and terrestrialhop-router-hop numbers (99.9%) are consistent across the ICMP paris-traceroutes to the same exposed service. Additionally, we find that IP addresses for the same hop numbers do not change across ICMP paris-traceroutes.

D USING A STARLINK DISH OBSTRUCTION MAP TO INFER SATELLITE LOCATION

Starlink's satellite dish does not directly reveal which satellite it is connected to. However, we notice that Starlink's obstruction map-a map that highlights where the dish's visibility is obstructedrecords the location of the satellite that is connected to the dish. To infer which satellites the Starlink dish is connected to during our experiment, we first reboot our dish to clear the dish's cached obstruction map and visually validate that the dish's obstruction map is clear. We then start our experiment and send the "get_obstruction_map" gRPC command every second to receive the obstruction map every second. After reboot, we notice a 30 second delay before "get_obstruction_map" returns data. Once our experiment is finished, we subtract the obstruction map at time 𝑡 -1 from the obstruction map at time 𝑡, to illuminate the location of the dish-connected satellite is at time 𝑡. Visual validation shows that every second the dish connects to a new satellite location that is either near the original one (i.e., the same satellite is connected to the dish) or at a completely different location (i.e., a new satellite is now connected to the dish).

E HYPATIA WORST CASE SATELLITE SELECTION PREDICTIONS

We modify Hypatia's source code such that, when simulating routing patterns, it chooses the worst-case option for satellite routing (i.e., it connects the client with satellite that maximizes its round trip time to the ground station. We additionally configure Hypatia to reflect the azimuth properties of a Starlink dish. Since a Starlink dish cannot connect to satellites behind itself [START_REF]Starlink Specifications[END_REF], and points itself at an azimuth of -22 N, we configure Hypatia to choose satellites for the dish that are between an azimuth lower than 180 -22 = 158 or greater than 360 -22 = 338. The ground station is not configured with an azimuth cut-off, as their antennas can connect to satellites across


Dominique Planson

Pierre Brosselard

Dominique Tournier

Viet Luong

Christian Phung

Brykinski

L V Phung

C Brylinski

Towards Very High Voltage SiC Power Devices

come   L'archive ouverte pluridisciplinaire

Brief Introduction: the Motivations towards Silicon Carbide for Very High Voltage Devices

Railway Applications

Silicon components are widely used in railway traction through IGBT with different voltage ranges (1200, 1700, 3300 and 6500V) depending on the applications (Tramway, regional and high speed trains). Most of the power flows through the power devices, but auxiliary systems become more and more important (heating, air conditioning system, lighting, communication and information…) and require an increasing volume in the coach. Downsizing the volume of the converter is now possible with the use of 1200V SiC available unipolar devices (Schottky, JFETs and MOSFETs) by increasing the switching frequency, and hence decreasing the size of the passive components. These devices could also allow reducing the size of the cooling system due to smaller losses and better conduction of the heat thanks to SiC. High voltage devices (more than 10 kV) are required for power supply chain. A heavy high voltage transformer decreases the supply voltage (25 kV) down to a lower voltage to supply the 1500V DC with the help of a rectifier. This transformer is heavy (more than 10 tons) and bulky (more than 50% of the locomotive). In order to replace it, research projects aim to develop an AC/DC converter with several stages (using between 12 and 18 Si-IGBT 6.5 kV). With the use of high voltage devices, this figure could be reduce by a factor of 2, allowing to split the converter in several parts and thus increasing the number of travelers in the train.

Smart Grid Applications

With the arrival of renewable energy (Photovoltaic's and wind mills), the high-voltage distribution network is changing since the beginning of 2000. The European network is interconnected and long distance exchanges of energy are now a reality. From the beginning up to now, the present solution uses AC high voltage. But the increasing distance (more than 100 km) make the DC high voltage more profitable from the economic point of view due to the line losses. Moreover, the DC transport requires one conductor less. The very good yield of power electronic converters makes them attractive for DC transport of electricity. According to the prediction of major T&D actors (Alstom Grid, GE, ABB…), and as illustrated on figure 2, DC/DC converters are required with the following voltages 600kV/150kV, 150kV/50kV, 50kV/10kV and finally 10kV/500V. This is the reason for high voltage devices able to sustain at least 15 kV. Smart grid applications are one of the major issues in this field to realize LCC (Line Commutated Converter) AC/DC converters. Railway and renewable energy applications also require high voltage devices. Both high voltage (>10kV) and high current (>1kA) are required. GaN devices breakdown voltage limitation below 1kV is related to technological issues: no p-type doping, high quality bulk material nor thick epilayer are available. Concerning diamond, even if high voltage diamond diodes have been demonstrated [1], the substrates size dimensions (4mm × 4mm) and the doping issues are also limiting their performances.

For such very high voltage devices, highly efficient periphery protections are needed. The next section will review the periphery protections technics applied to diodes and transistors. Recent results including MESA-JTE and MESA-JTE field rings combination will be given.

Periphery protections for Very High Voltage Silicon Carbide Devices

High voltage devices are vertical ones where the current flows from one electrode at the top the other one at the backside. It allows to exploit the full thickness of the epilayer as a drift layer, which reduces the device' size compared to a lateral structure. It requires an important drift layer length with an optimal doping to match the trade-off between onresistance and breakdown voltage.

From a device design point of view, the realization of an effective edge termination is one of the biggest challenges. Many techniques like guards rings, floating field rings, JTE… are used to make the electric field uniform at the edge of the device. In the first part of this section, different periphery protections will be reviewed shortly, then a state of the art will be presented and finally the remaining works to reach high voltage devices will be drawn.

Different periphery technics

Junction Termination Extension (JTE). This protection is very often used in SiC. This surrounding ring is realized with aluminum or a boron implantation with a controlled dose and requires an additional mask level. When the device is reverse biased, the depletion layer spreads into the JTE. Once totally depleted, the JTE becomes a highly resistive area and the electric potential is distributed over the full length of the JTE.

The total dose of the JTE must be chosen properly so that it can be totally depleted before field crowding occurs either at the JTE end or at the intersection between P+ and JTE zone. Three parameters define the JTE characteristics: first the JTE length must be optimized and then the breakdown voltage strongly depends on the JTE dose as it could be seen on Figure 4. When the dose is too high, the JTE protection has no effect and the breakdown voltage drops drastically, for a smaller dose, the maximum electric field peaks will have comparable height. The optimal dose is reached once the peaks have exactly the same magnitude. The breakdown voltage is very sensitive to the distance between the rings and these are getting smaller when the number is increased. Numerical simulations are mandatory to optimize the distance based on the electric field equilibrium at the border of each ring.

MESA: An etching process is used to remove the surrounding material at the periphery of the main junction. The breakdown voltage depends strongly on the etch depth, and for the high voltage device, this technique is often combined with a JTE, and is described as MESA-JTE as shown in Figure 7. The parameters to be optimized are the MESA etch depth, the JTE length and also the dose of the JTE. For a dose of 7×10 12 cm -2 , the breakdown voltage is closed to the ideal P + N plane semiinfinite junction (16.5 kV) and is independent of the JTE length. When the etching depth increases the range of optimized dose also increases, and the protection efficiency increases. The combined MESA-JTE allows obtaining better results than MESA or JTE edge terminations.

Combination of different terminations: The advantages of each termination could be combined and adapted to the junction features, as an example, the etched JTE has been applied to the thyristor structure [3].

New protections are needed, using combination of MESA, single and/or multiple JTE, and guard rings [4] in order to increase the breakdown voltage. It allows widening the parameter ranges and being closer to the 100% efficiency, but one should keep in mind that the area used by the protection itself should be reduced as much as possible to reduce the total cost of the device. It is particularly true for high voltage device, due to the thick drift layer. JBS and Single JTE (Junction Termination Extension) has been applied to 10 kV-10A and 20A JBS diode exhibiting a leakage current of 1 µA@10 kV [START_REF] Hull | Electron Devices[END_REF]. 9 kV JBS have been protected with JTE assisted with field rings, and exhibit a relatively low leakage current of 100 µA@10 kV [START_REF] Berthou | Implementation of high voltage Silicon Carbide rectifiers and switches[END_REF] and losses in comparison to 6.5kV Si-IGBT [START_REF] Wang | Solid-State Transformer application[END_REF].

Bipolar Diodes.

Very high breakdown voltage has been demonstrated very recently, the world record being a 22 kV bipolar diode [START_REF] Niwa | Power Semiconductor Devices and ICs[END_REF] using a two-zone JTE combined with JTE-rings. Also a recent result with a shorter JTE length has been presented in [START_REF] Hiyoshi | [END_REF] for a 10 kV PiN diode.

Transistors

All kinds of transistors have been demonstrated with breakdown voltage higher than 9 kV. Unipolar devices exhibit a large on-resistance with fast switching, contrary to the bipolar transistor depending on the minority carrier lifetime. Concerning unipolar switches, a 9 kV JFET, protected by MESA/JTE has been fabricated [10], but a quite high gate bias (-50 V) is necessary to block the transistor. In order to achieve high voltage and high current applications requirements, i.e. to overcome the large resistance of high voltage unipolar devices, twelve 10 kV MOSFETs have been connected in parallel with JBS diodes in the same module [START_REF] Das | Energy Conversion Congress and Exposition (ECCE)[END_REF]. For bipolar devices, MESA/JTE protected BJT (Bipolar Junction Transistor) have shown a 10 kV breakdown voltage, but the current gain is limited to 28 [START_REF] Zhang | Materials Science Forum[END_REF]. Etched JTE has been used to protect nearly 6 kV thyristors to replace the commonly used implanted JTE [START_REF] Pâques | Materials Science Forum[END_REF].

Works to be done for increasing the breakdown voltage

The impact of the bend radius will also be shown by TCAD means. The high voltage devices are usually used for high power applications, it means that increasing the area of the active part of the device is important. Rectangular shape of device is one way to increase the size in comparison with circular one. In such case, rounded corner are designed to avoid electric field crowding. A 3D-simulation has been performed to exhibit the effect of the bend radius on the maximum eùlectric field in the structure in Figure 10. The simulation was stopped for the same critical electric field in both structures. The bigger bend radius allows an increase on the breakdown voltage of 2 kV compared to the smaller one allowing an increase in JTE efficiency from 66 % up to 80 %.

UV-switching devices

In the perspective of high voltage converter, a demonstration of UV-switching devices operation has been developed using a UV-LED light triggered thyristors (LTT) [START_REF] Dheilly | [END_REF]. These were protected with an etched guard ring assisted JTE, with 6 rings as we can see on Figure 11. The advantages of the light triggered thyristor (LTT) are the galvanic isolation of the driver and the reduction of EMI interferences, which are interesting for high voltage systems. In systems requiring very high voltage, such as HVDC transmission that works at several hundred of kV, serial association of semiconductor devices will be needed, even when using SiC ones. The schematic of the circuit is shown on Figure 12. The DC bus voltage was set as an example to 300V and the load was a 235 Ω resistor. The voltages of the thyristors during the switching with balancing capacitors of 22 nF is shown in the Figure 14. The voltage between the two thyristors is then equally shared. However the fall time is longer and around 500 ns against 200 ns without the capacitors, and the switching losses are therefore higher.

Passivation layers

Higher voltage devices will induce a high electric field stress in the passivation layer. Therefore, extended performances of packaging materials are necessary to sustain higher voltage and also temperature. An insulation material with appropriate high dielectric rigidity will prevent the formation of premature arcing. Polyimides appear as potential candidates for this passivation layer [15]. Packaging Specific packages are required for high voltage devices. The material itself must be able to sustain high electric field, but the layout of the electrodes must be properly designed (distance between electrodes).

Figure 1 :

 1 Figure 1: Illustration of benefit of WBG switches: Si and SiC 1.5kW inverter volume comparison (SiC/Si power density ratio is about 20).

Figure 2 :

 2 Figure 2: General layout of electricity networks showing end-user and source interconnection (Solar and Wind farms…) at distribution grid level.

Figure 3 :

 3 Figure 3: Schematic view of the PiN diode with a JTE termination and a channel stop.

Figure 4

 4 Figure 4 Influence of the JTE length (a) and dose (b) for a PiN diode with a JTE termination. The y-axis is a percentage of the breakdown voltage (V br ) obtained from the ratio between the actual voltage and the ideal one.

Figure 5 :

 5 Figure 5: Schematic view of the PiN diode with a guard rings termination

Figure 6 :

 6 Figure 6: Breakdown voltage percentage versus the distance in between the anode and the first ring (red curve) and the optimized breakdown voltage versus the number of rings (black curve).

Figure 7 .

 7 Figure 7. Schematic view of the PiN diode with a MESA-JTE termination.

Figure 8 .

 8 Figure 8. Breakdown voltage percentage of a MESA-JTE diode versus the implanted dose of the JTE for different JTE lengths.

Figure 9 .

 9 Figure 9. Schematic cross section of a 4H-SiC PiN diode protected by two-zone JTE and space-modulated JTE [5].

Figure 10 .

 10 Figure 10. Equipotential line distribution at the rounded corner of a PiN diode for two bend radius (120 µm left and 450 µm right).

Figure 11 .

 11 Figure 11. Schematic of the experiment of the serial association of two thyristors.

Figure 12 .

 12 Figure 12. Schematic of the experiment of the serial association of two thyristors.

Figure 13 .

 13 Figure 13. Experimental setup for the optical thyristors, attached on alumina substrate and wire bonded.

Figure 14 .

 14 Figure 14. Serial association of two thyristors with balancing capacitors: TH1 voltage and sum of the TH1 and TH2 voltages during the commutation.