



Distributed Mobility Management                                   Z. Lai
Internet-Draft                                                    Y. Hou
Intended status: Informational                                     Q. Wu
Expires: 31 August 2026                                            H. Li
                                                     Tsinghua University
                                                        27 February 2026


  Mobility Management for Inter-SNO Sharing in LEO Satellite Networks
                   draft-lai-dmm-sno-collaboration-00

Abstract

   Deploying a low-Earth orbit (LEO) satellite network typically
   requires substantial financial investment and long development
   cycles.  To shorten deployment timelines and alleviate economic
   burdens, collaborative constellation deployment has gained attention.
   In such a model, multiple satellite network operators (SNOs)
   contribute their respective constellations to jointly deliver LEO
   connectivity services.  Despite these potential benefits, the high
   mobility of LEO satellites introduces operational complexity.  As
   satellites move rapidly across coverage regions, terrestrial users
   are frequently reassigned to different access satellites, which may
   be connected to distinct SNO core networks.  These cross-operator
   handovers, referred to as inter-SNO handovers, can negatively affect
   service continuity and overall network robustness.  To address these
   challenges, this document outlines a mobility management framework
   aimed at supporting cooperative LEO constellation operation.  The
   framework separates the satellite access layer from individual SNO
   core infrastructures, thereby permitting flexible mapping between
   shared access satellites and multiple operator cores.  Through this
   decoupled architecture, user sessions can remain associated with
   their original SNO core networks whenever operational conditions
   permit.  The framework incorporates a dynamic SNO association
   strategy that seeks to limit the frequency of inter-SNO handovers.
   Furthermore, in scenarios where such handovers cannot be avoided, a
   proactive optimization procedure is employed to shorten interruption
   duration and enhance the efficiency of the handover process.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.



Lai, et al.              Expires 31 August 2026                 [Page 1]

Internet-Draft              sno_collaboration              February 2026


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 31 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Characteristics of LEO Satellite Networks . . . . . . . . . .   4
     2.1.  LEO satellite networks  . . . . . . . . . . . . . . . . .   5
     2.2.  Constructing an LEO network is costly and
           time-consuming  . . . . . . . . . . . . . . . . . . . . .   5
   3.  Impacts of LEO Mobility on Infrastructure Sharing . . . . . .   5
     3.1.  Telecom infrastructure sharing  . . . . . . . . . . . . .   6
     3.2.  Collaboration in LEO networks . . . . . . . . . . . . . .   6
     3.3.  New Challenges of Inter-Constellation Sharing . . . . . .   6
     3.4.  Limitations of existing handover optimizations  . . . . .   8
   4.  The Proposed Mobility Management Framework  . . . . . . . . .   8
     4.1.  Shared LEO access network . . . . . . . . . . . . . . . .   9
     4.2.  Independent SNO cores . . . . . . . . . . . . . . . . . .  10
     4.3.  Adaptive space-ground associations  . . . . . . . . . . .  10
     4.4.  Key techniques behind the proposed framework  . . . . . .  11
   5.  Reducing Disruption Time During Handovers . . . . . . . . . .  11
     5.1.  Baseline inter-SNO handover optimizer . . . . . . . . . .  11
     5.2.  Optimizing handovers by proactive authentication and
           tunneling . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15



Lai, et al.              Expires 31 August 2026                 [Page 2]

Internet-Draft              sno_collaboration              February 2026


   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Over the past few years, a number of emerging commercial space
   enterprises have initiated the deployment of Low-Earth orbit (LEO)
   satellite constellations.  Representative examples include SpaceX's
   Starlink, Eutelsat OneWeb, and Amazon's planned LEO constellation.
   These constellations rely on satellites operating at high orbital
   speeds relative to the Earth's surface, typically around 8 km/s.  As
   a result, a single satellite remains within the visibility range of a
   specific terrestrial location only for a limited duration, often on
   the order of several minutes.  To provide continuous and global
   Internet connectivity under such mobility constraints, operators must
   deploy constellations with a large number of satellites distributed
   across multiple orbital planes.  Achieving this scale of deployment
   is operationally demanding.  It requires completion of multiple
   regulatory and engineering processes
   [satellite_constellation_launch], including orbital slot
   coordination, spectrum authorization, manufacturing, and repeated
   launch campaigns.  Even for established operators such as Starlink
   and OneWeb, several years, typically between three and six, are
   required before global service availability can be realized.

   In order to shorten deployment timelines and control operational
   expenditures, constellation-level cooperation among satellite network
   operators (SNOs) has recently attracted increasing attention
   [decentralized_satellite_networks].  Under this model, multiple SNOs
   share selected infrastructure resources and jointly provide LEO
   connectivity services to terrestrial users.  The underlying concept
   is similar to infrastructure sharing practices in terrestrial mobile
   networks, where operators co-utilize physical facilities or network
   components to improve resource efficiency and reduce capital
   investment.  Although such collaboration can lower entry barriers and
   accelerate rollout, its application to LEO constellations introduces
   additional complexity.  Unlike terrestrial networks, LEO
   constellations exhibit strong infrastructure-level dynamics due to
   rapid satellite movement.  Consequently, users may be frequently
   reassigned across access satellites that are connected to different
   SNO core networks.  These repeated inter-SNO handovers pose
   substantial challenges to maintaining service continuity and overall
   network stability in a shared LEO environment.

   To address the service disruptions introduced by inter-SNO handovers
   and to support stable constellation cooperation, this document
   specifies an inter-networking architecture for collaborative SNO



Lai, et al.              Expires 31 August 2026                 [Page 3]

Internet-Draft              sno_collaboration              February 2026


   operation.  At the architectural level, the framework separates the
   satellite access layer from individual SNO core infrastructures.
   This separation permits shared access satellites to be dynamically
   mapped to different operator core networks, rather than being
   permanently bound to a single SNO.  As a result, user sessions can
   continue to be served by their original SNO core networks whenever
   network conditions allow.  The framework is realized through two
   complementary mechanisms.  The first mechanism governs dynamic SNO
   association, enabling access satellites to be selectively connected
   to appropriate core networks in order to limit unnecessary inter-SNO
   handovers.  The second mechanism focuses on optimizing the handover
   procedure itself.  In scenarios where inter-SNO handovers cannot be
   avoided, a prediction-assisted proactive process is applied.  By
   utilizing pre-established SNO association information, the network-
   level handover operations can be prepared in advance, thereby
   shortening service interruption duration and improving handover
   efficiency.

   The aim of this document is to describe the challenges posed by
   inter-constellation sharing in emerging LEO satellite networks,
   particularly the frequent inter-SNO handovers caused by
   infrastructure-level dynamics, and to describe a mobility management
   framework to mitigate their negative impacts.  Based on our analysis
   of collaborative SNO deployments and handover behaviors, we provide
   design insights and architectural considerations for enabling
   seamless inter-constellation sharing.  We hope this document will
   serve as a useful reference for future standardization efforts on
   inter-SNO inter-networking mechanisms in shared LEO satellite
   networks.

2.  Characteristics of LEO Satellite Networks

     +-----------+  +-----------+  +-----------+    LEO access network
   --| Satellite |--| Satellite |--| Satellite |--(altitude <= 2000 km)
     +-----+-----+  +------+----+  +-----+-----+
               /           /\
              /           /  \
             /           /    \
            /           /      \
    +--+---+ +--+--+--+--+ +---+---+   +----+---+   +--------+--------+
    |Remote| |Residential| |Ground |-->|SNO Core|-->|Point-of Presence|
    |Users | |Users      | |Station|<--|Network |<--|   and Internet  |
    +--+---+ +--+--+--+--+ +---+---+   +----+---+   +--------+--------+

       Figure 1: Networking architecture of operational LEO networks.






Lai, et al.              Expires 31 August 2026                 [Page 4]

Internet-Draft              sno_collaboration              February 2026


2.1.  LEO satellite networks

   Figure 1 illustrates a representative networking structure adopted by
   contemporary LEO satellite network operators (SNOs)
   [democratizing_leo_satellite_network_measurement].  A typical LEO
   constellation can be divided into two primary components.  The first
   component is a satellite-based access segment, formed by a large
   constellation of LEO satellites that deliver last-mile connectivity
   to terrestrial users.  The second component is a terrestrial core
   network, which performs operator-specific control and management
   functions, including user authentication, billing, IP address
   management, and traffic exchange with the public Internet.  When a
   user connects to the Internet via a satellite terminal, the data path
   generally proceeds as follows.  User traffic is transmitted through
   one or more LEO satellites to a ground station, forwarded to the
   corresponding SNO core network for processing, and then routed to the
   broader Internet.  The reverse path follows a similar sequence.  In
   geographically remote regions where direct satellite-to-ground
   visibility may be limited, inter-satellite links (ISLs) enable
   traffic to be relayed across multiple satellites before reaching an
   appropriate ground gateway.

2.2.  Constructing an LEO network is costly and time-consuming

   Since LEO satellites travel at high speeds relative to the Earth,
   sustained service availability in any given region requires
   continuous satellite replacement within the coverage footprint.  To
   achieve this level of persistence, an SNO must deploy a sufficiently
   large constellation before commercial operation can begin.  In
   practice, this implies the construction of a globally distributed
   satellite network.  Reaching such deployment scale is neither
   straightforward nor rapid.  Establishing a mega-constellation
   involves multiple regulatory, technical, and logistical steps
   [satellite_constellation_launch].  Operators are required to obtain
   approval for orbital configurations from national regulators, such as
   the Federal Communications Commission, and to secure spectrum usage
   rights across different jurisdictions.  In parallel, satellite
   production, integration, and launch scheduling must be coordinated,
   each of which introduces additional lead time.  Consequently, SNOs
   often experience an extended pre-operational phase, which may span
   several years before full commercial services become available.

3.  Impacts of LEO Mobility on Infrastructure Sharing








Lai, et al.              Expires 31 August 2026                 [Page 5]

Internet-Draft              sno_collaboration              February 2026


3.1.  Telecom infrastructure sharing

   Infrastructure sharing among operators has long been adopted in
   terrestrial mobile systems as a means of improving deployment
   efficiency.  Through infrastructure sharing arrangements, multiple
   operators can jointly utilize assets such as spectrum licenses and
   access facilities to expand coverage, lower capital expenditures, and
   accelerate network rollout.  Such cooperation has been implemented in
   various markets.  For example, T-Mobile Poland and PTK Centertel
   entered into a long-term agreement, lasting approximately fifteen
   years, to jointly operate portions of their mobile access network
   [comarch-orange-T-Mobile].  In another case, major South Korean
   operators including LG Uplus, KT, and SK Telecom reached an agreement
   to share 5G network infrastructure in sparsely populated coastal and
   agricultural regions [analysysmason-network-sharing].

3.2.  Collaboration in LEO networks

   Drawing on the experience of infrastructure sharing in terrestrial
   mobile systems, similar concepts are now being considered in the
   context of satellite Internet.  Given the substantial financial
   investment and lengthy timelines required to deploy LEO
   constellations, both satellite network operators (SNOs) and the
   research community have begun to investigate inter-constellation
   cooperation [satellitetoday-iridium-oneweb],
   [decentralized_satellite_networks].  Under such arrangements,
   participating SNOs coordinate the use of spectrum and other network
   resources to jointly construct and operate LEO infrastructures.  This
   cooperative model offers several practical benefits.  By pooling
   resources, individual SNOs are no longer required to independently
   deploy a fully standalone global constellation, which can
   significantly reduce the time needed to reach service readiness.  In
   addition, coordinated spectrum planning and joint infrastructure
   utilization may help streamline regulatory processes, thereby
   accelerating overall deployment schedules.

3.3.  New Challenges of Inter-Constellation Sharing














Lai, et al.              Expires 31 August 2026                 [Page 6]

Internet-Draft              sno_collaboration              February 2026


                  satellite access
              +-------+           +----+-----+
              | Sat-A |-----------|SNO Core A|------------
              +-------+       |   +----+-----+           |
                 /            |                          |
                /             |                          |
               /              |                          |
              /\              |                 +--------+--------+
             /  \             |                 |Point-of Presence|
        +------+ \  inter-SNO |                 |   and Internet  |
        | User |  \ handover  | LEO satellite   +--------+--------+
        +------+   \          | movement                 |
             \     /          |                          |
              \   /           |                          |
               \ /            |                          |
                \             |                          |
                 \            |                          |
              +-------+       |   +----+-----+           |
              | Sat-B |-----------|SNO Core B|------------
              +-------+           +----+-----+

                  Figure 2: Current constellation sharing.

   Figure 2 illustrates a representative constellation-sharing
   architecture as described in [decentralized_satellite_networks].  In
   this model, collaborating operators such as SNO A and SNO B retain
   primary control over their respective user bases.  Users of SNO A
   preferentially access satellites owned by SNO A, and only associate
   with satellites of SNO B when local coverage from SNO A is
   temporarily unavailable.  In such deployments, the satellite access
   layer remains tightly bound to the corresponding operator's core
   network.  Due to the rapid orbital movement of LEO satellites,
   satellite visibility for each operator fluctuates over time across a
   given geographic region.  Consequently, users may repeatedly handover
   between satellites affiliated with different SNOs.  These handovers
   give rise to inter-SNO handovers at the network level.  Compared with
   handovers occurring within a single operator domain, inter-SNO
   handovers involve additional signaling and control operations.
   Procedures such as user re-registration, authentication re-
   establishment, and reassignment of IP addresses must be executed
   before service can resume.  These extra steps introduce short-term
   service interruptions, which can degrade session continuity and
   reduce the perceived stability of the shared LEO network.








Lai, et al.              Expires 31 August 2026                 [Page 7]

Internet-Draft              sno_collaboration              February 2026


3.4.  Limitations of existing handover optimizations

   From a network perspective, repeated inter-SNO handovers can be
   interpreted as users continuously alternating between their home LEO
   network and a partner operator's infrastructure.  Such behavior
   resembles roaming across administrative domains, but occurs at a much
   higher frequency due to the orbital dynamics of LEO constellations.
   Mobility management has been extensively studied in the broader
   mobile networking community.  Prior efforts include the design of
   mobility management protocols, proxy-assisted handover acceleration
   techniques, and adaptations of mobility mechanisms for LEO
   environments.  For instance, protocols such as [RFC6275] and
   [RFC5944] are primarily concerned with minimizing service
   interruption during individual handover events.  However, these
   mechanisms generally address the latency of a single handover and do
   not attempt to reduce how often such handovers occur.  Proxy-based
   optimization approaches, including those described in
   [practical_traffic_management_lte_wifi], typically depend on stateful
   proxy entities deployed at relatively stable access points in
   terrestrial networks.  In contrast, access satellites in LEO
   constellations are inherently mobile.  As user attachment points
   continuously change, maintaining persistent proxy state becomes
   impractical, which limits the applicability of such designs in
   satellite scenarios.  More recently, mobility schemes tailored for
   LEO networks have been proposed, such as [skycastle_leo_mobility].
   These solutions focus on addressing mobility within a single
   operator's constellation.  When extended to inter-constellation
   collaboration environments, however, they remain vulnerable to
   frequent cross-operator handovers and the associated disruptions.
   Taken together, the high frequency of inter-SNO handovers and the
   constraints of existing mobility optimization mechanisms highlight
   the need for approaches specifically designed to support seamless
   operation in shared LEO constellations.

4.  The Proposed Mobility Management Framework
















Lai, et al.              Expires 31 August 2026                 [Page 8]

Internet-Draft              sno_collaboration              February 2026


          shared LEO access           independent
          (transparent forwarding)    SNO core networks
        +------+   +-----+   +-------+---------+
        |User A|---|Sat-A|---|      Core A     |---------
        +------+   +-----+   +-------+---------+        |
               \  /      \  /    ||      ||             |
                \/        \/     ||      ||             |
                /\        /\     ||      ||             |
               /  \      /  \    ||      ||             |
        +------+   +-----+   +---+----+  ||    +--------+--------+
        |User B|---|Sat-B|---| Core B |--------|Point-of Presence|
        +------+   +-----+   +---+----+  ||    |   and Internet  |
               \  /      \  /    ||      ||    +--------+--------+
                \/        \/     ||      ||             |
                /\        /\     ||      || Tunnels     |
               /  \      /  \    ||      ||             |
        +------+   +-----+   +-------+---------+        |
        |User C|---|Sat-C|---|      Core C     |---------
        +------+   +-----+   +-------+---------+
                    flexible and dynamic SNO association

       Figure 3: The proposed mobility management framework overview.

   This document outlines an architectural approach for constellation
   cooperation that aims to limit the operational impact of recurrent
   inter-SNO handovers and to support stable inter-constellation service
   integration.  At a conceptual level, the architecture is composed of
   two principal elements: a common LEO-based access layer shared among
   participating operators, and a set of autonomous SNO core networks.
   The overall structure of this arrangement is depicted in Figure 3.

4.1.  Shared LEO access network

   Within this architecture, participating SNOs make their satellite
   resources and associated spectrum bands mutually available,
   potentially leveraging techniques such as those described in
   [spectrum_sharing_leo].  Collectively, these satellites form a
   unified LEO access layer that is shared across operators.  Satellites
   in this shared layer operate in a stateless forwarding mode, allowing
   a single satellite to simultaneously provide access services to users
   subscribed to different SNOs.  Because a variety of established
   mechanisms already exist for assigning satellite access points to
   terrestrial users, the framework does not mandate a specific
   selection policy.  Instead, it permits collaborating SNOs to jointly
   determine a common satellite allocation strategy, which may consider
   factors such as signal quality, instantaneous traffic load, or other
   operational metrics.  The resulting allocation decisions are then
   enforced at the satellite terminal level.



Lai, et al.              Expires 31 August 2026                 [Page 9]

Internet-Draft              sno_collaboration              February 2026


4.2.  Independent SNO cores

   Within each operator domain, the SNO core network continues to handle
   functions that are specific to that operator, including user
   authentication, address assignment, and other control-plane
   responsibilities.  Accordingly, the architecture preserves the
   administrative independence of participating SNO core networks.  To
   support inter-operator coordination, secure connectivity is
   established between the core networks of different SNOs over the
   terrestrial Internet.  These protected tunnels provide a
   communication channel for exchanging signaling information and
   aligning operational decisions across domains.  Each SNO maintains a
   set of geographically distributed ground stations that serve as
   gateways between its core infrastructure and the satellite layer.
   Building on this foundation, the framework enables dynamic satellite-
   to-operator mapping.  At any given time, a satellite within the
   shared access layer may attach to the ground station and core network
   of a selected SNO, allowing association relationships to evolve in
   response to operational conditions.

4.3.  Adaptive space-ground associations

   In contrast to conventional collaboration models, such as the one
   shown in Figure 2, where an operator's LEO access segment remains
   tightly bound to its own core infrastructure, the proposed
   architecture separates these two layers.  By removing the fixed
   coupling between access satellites and specific SNO cores, the
   framework allows connection relationships to be adjusted dynamically,
   with the objective of limiting unnecessary inter-SNO handovers
   experienced by end users.  As depicted in Figure 3, users belonging
   to different SNOs attach to a common LEO access layer that is shared
   among participating operators.  Because satellites move rapidly along
   their orbital paths, user terminals inevitably handover between
   different access satellites over time.  To preserve continuity at the
   operator level, the framework continuously adapts the mapping between
   access satellites and SNO core networks.  Through this adaptive
   association, user sessions are maintained with their original SNO
   whenever feasible, thereby reducing cross-operator handovers.  In
   situations where a handover between SNO cores cannot be avoided, the
   architecture relies on inter-core tunneling mechanisms to forward
   user traffic back to the original SNO core network, mitigating the
   impact of the handover on ongoing sessions.









Lai, et al.              Expires 31 August 2026                [Page 10]

Internet-Draft              sno_collaboration              February 2026


4.4.  Key techniques behind the proposed framework

   To mitigate the service degradation caused by inter-SNO handovers,
   the architecture incorporates two complementary mechanisms.  The
   first mechanism regulates SNO association by dynamically assigning
   stateless access satellites to suitable core networks.  Through
   adaptive satellite-to-core mapping, the frequency of cross-operator
   handovers experienced by terrestrial users can be effectively
   constrained.  The second mechanism focuses on accelerating the
   handover procedure itself.  By taking satellite trajectory
   information into account, a fast handover scheme is applied to
   shorten the duration of network-layer interruption during inter-SNO
   handovers.

5.  Reducing Disruption Time During Handovers

   By taking advantage of the deterministic nature of satellite orbital
   motion, the architecture computes in advance the mapping between
   individual satellites and participating SNO core networks.  This
   advance planning reduces the likelihood of unnecessary cross-operator
   handovers.  Building on these pre-established association results,
   the framework further implements an expedited inter-SNO handover
   procedure.  Because the target operator relationship is known ahead
   of time, network-layer preparation can be initiated prior to the
   actual handover, thereby shortening service interruption during
   inter-SNO handovers.

5.1.  Baseline inter-SNO handover optimizer























Lai, et al.              Expires 31 August 2026                [Page 11]

Internet-Draft              sno_collaboration              February 2026


        +------+        +------+      +------+
        |User A|        |Core-B|      |Core-A|
        +------+        +------+      +------+
        | Core disconnect |    handover start|
        |-----------------|----------------->|
        |                 | disconnection ACK|
        |<----------------|------------------|
        |                 |                  |
        | link handover   |                  |
        |                 |                  |
        |                 |                  |
        |                 |                  |
        |                 |                  |
        |                 |new link formation|
        |   Core discovery|------------------|
        |---------------->|authentication(ID)|
        |                 |----------------->|
        |                 |authentication ACK|
        |                 |<-----------------|
        |                 |  CoA, Tunnel Req |
        |                 |----------------->|
        |                 |    Tunnel ACK    |
        |registration done|<-----------------|
        |<----------------|     handover done|
        |Pkt.IP.dst=server|                  |  Traffic exchange after
        |---------------->|Pkt.IP.dst=server |  inter-SNO handover
        |                 |----------------->|
        |                 |Pkt.IP.dst=CoA    |
        |Pkt.IP.dst=user  |<-----------------|
        |<----------------|                  |

                   Figure 4: Baseline inter-SNO handover.

   This section first describes a baseline handover optimization
   procedure that incorporates the Mobile IP mechanism defined in
   [RFC6275] into the LEO environment, as shown in Figure 4.  The
   objective of this baseline design is to preserve the user's IP
   address across an inter-SNO handover.  Consider a user initially
   served by SNO-A.  The user accesses the Internet through the shared
   LEO access layer and is anchored at the core network of SNO-A.  When
   satellite mobility causes the user to attach to a new access
   satellite associated with SNO-B, a cross-operator handover is
   triggered.  Because SNO-A and SNO-B maintain independent IP address
   pools, a direct handover would normally result in address
   reassignment.  To prevent this outcome, the baseline procedure
   proceeds as follows.  Upon detaching from core A, the user initiates
   an unregistration process by sending a disconnect notification to
   core A.  The user then establishes connectivity with the incoming



Lai, et al.              Expires 31 August 2026                [Page 12]

Internet-Draft              sno_collaboration              February 2026


   satellite, while link-layer mechanisms handle the physical
   disconnection and subsequent link setup.  Once the new link becomes
   operational, the user broadcasts a core discovery message containing
   its unique identifier.  After receiving this identifier, core B
   determines that the user is originally associated with SNO-A.  Core B
   forwards the identifier to core A over the terrestrial network,
   allowing core A to authenticate the user.  Following successful
   authentication, core B allocates a care-of address (CoA) for the user
   and sets up a secure tunnel between the two core networks.  Core B
   then informs the user that registration has been completed.  At this
   stage, the user regains Internet connectivity without changing its
   original IP address.  During subsequent data exchange, packets
   transmitted from the user toward an external server are first routed
   through core B, then tunneled to core A, and finally delivered to the
   destination.  In the reverse direction, because the destination IP
   corresponds to SNO-A, incoming packets are directed to core A.  Core
   A encapsulates each packet with a CoA associated with SNO-B and
   forwards them through the inter-core tunnel.  Core B decapsulates the
   packets and delivers them to the user.

5.2.  Optimizing handovers by proactive authentication and tunneling

   +------+        +------+      +------+
   |User A|        |Core-B|      |Core-A|
   +------+        +------+      +------+
   | Core disconnect |    handover start|
   |-----------------|----------------->|
   |                 | disconnection ACK|
   |<----------------|------------------|
   |                 |proactive auth(ID)|
   | link handover   |<-----------------|
   |                 |  CoA, Tunnel Req |
   |                 |----------------->|
   |                 |    Tunnel ACK    |
   |                 |<-----------------|
   |                 |new link formation|
   |   Core discovery|------------------|
   |---------------->|                  |
   |registration done|                  |
   |<----------------|     handover done|  Proactive authentication and
   |Pkt.IP.dst=server|                  |  tunneling-based on
   |---------------->|Pkt.IP.dst=server |  pre-calculated SNO core
   |                 |----------------->|  associations
   |                 |Pkt.IP.dst=CoA    |
   |Pkt.IP.dst=user  |<-----------------|
   |<----------------|                  |

                  Figure 5: Optimized inter-SNO handover.



Lai, et al.              Expires 31 August 2026                [Page 13]

Internet-Draft              sno_collaboration              February 2026


   The baseline network-layer recovery procedure may introduce several
   seconds of service interruption.  To further shorten this
   interruption interval, the architecture refines the baseline process
   by utilizing advance knowledge of satellite-to-SNO associations.
   Because these associations are computed ahead of time, the
   corresponding inter-SNO coordination steps can be partially prepared
   before the actual handover occurs.  An overview of the enhanced
   handover procedure is provided in Figure 5.  With the association
   results already available, core A can determine in advance the target
   core network to which the user will attach after the handover.  Once
   the user detaches from core A, core A immediately transmits the user
   identifier to core B to initiate local authentication procedures.  In
   parallel with the link-layer switching process, core B allocates a
   care-of address (CoA) and establishes the required inter-core tunnel.
   After the physical link to the new satellite becomes operational, the
   user issues a core discovery message.  Core B validates the
   identifier and finalizes the registration with minimal additional
   delay.  Because inter-core signaling and tunnel setup are executed
   concurrently with the underlying link-layer handover, the overall
   service disruption experienced during the inter-SNO handover can be
   significantly reduced.

6.  Conclusion

   This document presents an architectural model for cooperation among
   multiple SNOs with the objective of strengthening service continuity
   and operational stability in LEO environments.  The design addresses
   inter-SNO mobility from two complementary perspectives: limiting the
   occurrence of cross-operator handovers and accelerating the handover
   process when such handovers are unavoidable.  Through this combined
   strategy, the disruptive effects commonly associated with frequent
   inter-SNO handovers can be substantially alleviated.  By outlining
   mechanisms that coordinate shared access infrastructure with
   independent core networks, the architecture establishes a technical
   basis for interoperable inter-SNO operation within collaborative LEO
   constellations.  The concepts and procedures described herein are
   intended to contribute to ongoing and future discussions on
   standardizing inter-SNO inter-networking solutions.

7.  IANA Considerations

   This document includes no request to IANA.

8.  Security Considerations

   This document does not represent a change to any aspect of the TCP/IP
   protocol suite and therefore does not directly impact Internet
   security.



Lai, et al.              Expires 31 August 2026                [Page 14]

Internet-Draft              sno_collaboration              February 2026


9.  References

9.1.  Normative References

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC5944]  Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
              RFC 5944, DOI 10.17487/RFC5944, November 2010,
              <https://www.rfc-editor.org/info/rfc5944>.

9.2.  Informative References

   [satellite_constellation_launch]
              Cornara, S., Beech, T., Bello-Mora, M., and A. M. D.
              Aragon, "Satellite constellation launch, deployment,
              replacement and end-of-life strategies", 1999.

   [decentralized_satellite_networks]
              Oh, S. and D. Vasisht, "A call for decentralized satellite
              networks", 2024.

   [democratizing_leo_satellite_network_measurement]
              Izhikevich, L., Tran, M., Izhikevich, K., Akiwate, G., and
              Z. Durumeric, "Democratizing LEO satellite network
              measurement", 2024.

   [comarch-orange-T-Mobile]
              Comarch, "Comarch Fault Management Supports Orange and
              T-Mobile's Infrastructure Sharing Initiative in Poland",
              URL https://www.comarch.com/telecommunications/customers/
              networks/, 2026.

   [analysysmason-network-sharing]
              Analysys Mason, "Operators View Cost Saving and Coverage
              as the Two Main Drivers for Network Sharing", URL 
              https://www.analysysmason.com/research/content/articles/
              cost-network-sharing-rdns0/, 2026.

   [satellitetoday-iridium-oneweb]
              Satellite Today, "Constellations Combined: Iridium and
              OneWeb Join Forces on New LEO Service", URL 
              https://www.satellitetoday.com/mobile-
              connectivity/2019/09/17/constellations-combined-iridium-
              and-oneweb-join-forces-onnew-leo-service/, 2026.





Lai, et al.              Expires 31 August 2026                [Page 15]

Internet-Draft              sno_collaboration              February 2026


   [practical_traffic_management_lte_wifi]
              Mahindra, R., Viswanathan, H., Sundaresan, K., Arslan, M.
              Y, and S. Rangarajan, "A Practical Traffic Management
              System for Integrated LTE-WiFi Networks", 2014.

   [skycastle_leo_mobility]
              Li, J., Li, H., Lai, Z., Wu, Q., Liu, W., Wang, X., Li,
              Y., Liu, J., and Q. Zhang, "Skycastle: Taming LEO Mobility
              to Facilitate Seamless and Low-Latency Satellite Internet
              Services", 2024.

   [spectrum_sharing_leo]
              Yun, J., An, T., Jo, H., Ku, B., Oh, D., and C. Joo,
              "Downlink Spectrum Sharing of Heterogeneous Communication
              Systems in LEO Satellite Networks", 2022.

Acknowledgements

Contributors

   Thanks to all of the contributors.

Authors' Addresses

   Zeqi Lai
   Tsinghua University
   30 ShuangQing Ave
   Beijing
   100089
   China
   Email: zeqilai@tsinghua.edu.cn


   Yunan Hou
   Tsinghua University
   30 ShuangQing Ave
   Beijing
   100089
   China
   Email: houyn24@mails.tsinghua.edu.cn


   Qian Wu
   Tsinghua University
   30 ShuangQing Ave
   Beijing
   100089
   China



Lai, et al.              Expires 31 August 2026                [Page 16]

Internet-Draft              sno_collaboration              February 2026


   Email: wuqian@cernet.edu.cn


   Hewu Li
   Tsinghua University
   30 ShuangQing Ave
   Beijing
   100089
   China
   Email: lihewu@cernet.edu.cn









































Lai, et al.              Expires 31 August 2026                [Page 17]
