A decentralized communication relationship autonomous migration method and system in a distributed autonomous intelligent agent cluster

Abstract

This invention discloses a method and system for autonomous migration of decentralized communication relationships in a distributed autonomous intelligent agent cluster. This invention distinguishes between two types of communication relationships: basic communication relationships are based on individual DSFs (two independent keys, each used in one direction), operating on the main logical timeline; service-specific communication relationships are independent DSF instances and their driven service-specific logical timelines, with the Rule_ID of the DSF instance configured with service-specific QoS parameters. This invention breaks down the concept of a cell—the communication relationship is a deterministic association between two node IDs, rather than the terminal's attachment to a physical cell. The migration is essentially an atomic switch of the PSSM instance pointer rather than connection reconstruction, requiring no random access procedure initiated at the target node, and the identity of the communication relationship remains unchanged after migration. The sources of the dedicated K_sec are diverse: deterministic derivation, active allocation, core network distribution, negotiation generation, service identifier derivation, and multicast derivation. In public network scenarios, after the UE completes identity authentication, it derives an individual DSF and can choose to skip the basic communication relationship and directly establish a service-specific communication relationship. Any node autonomously decides to migrate, discovers the target through matching filtering, declares its intention using a migration-specific cryptographic tag, and triggers an atomic switch at the logical moment. The window switching time is determined by the physical layer execution time, and the interruption latency is in the sub-millisecond range.

Description

Technical Field

[0001] This invention belongs to the field of distributed autonomous systems and wireless communication technology, specifically relating to a method, system, and apparatus for enabling any intelligent agent node (including but not limited to satellites, user equipment (UE), drones, ground stations, and robots) to autonomously migrate communication relationships between any two peer nodes through local perception and decision-making in a distributed autonomous intelligent agent cluster based on Dynamic Security Foundation (DSF) and logical time axis, without relying on any centralized control entity.

[0002] This invention is applicable to two deployment scenarios: The first is a pure intelligent agent cluster scenario—all nodes in the cluster are completely equal, with no core network, no base station, and no central control node; communication relationships between nodes are autonomously established and maintained by the DSF foundation. The second is an intelligent agent cluster scenario compatible with the core network—the DSF intelligent agent cluster is deployed as a subnet or extended domain of the 5G / 6G core network, with the core network retaining the control plane and the data plane portion being autonomously managed by the DSF cluster. The migration process is essentially the same in both scenarios (node ​​autonomous decision-making, atomic switching at logical moments). The difference lies in the fact that the pure intelligent agent cluster does not require the core network to perceive path changes, while the core network-compatible scenario requires support for seamless path switching on the core network side.

[0003] This invention is particularly suitable for distributed scenarios without a central control node, such as low-orbit satellite constellations, drone swarms, and robot swarms.

[0004] Cross-reference with prior applications This application relates to the following previously filed patent applications of the applicant, the entire contents of which are incorporated herein by reference and serve as the basis for the technical solutions of this application: - Application No. 2026100015014 (DSF Fundamental Patent): Defines the DSF triplet and PSSM state machine. - Application No. 2026105584990 (Dual-level synchronization patent): Defines a dual-level synchronization model for logic counter synchronization and bounded alignment of physical anchor points. - Application No. 2026106207395 (Distributed Autonomous Intelligent Agent Cluster Patent): Discloses a distributed intelligent agent cluster collaborative system based on individual DSF. - Application No. 202610313177X (LPC+PAN architecture patent): discloses a method for switching centralized LPC decisions. - Application No. 2026102049886 (PSSM Mirroring Handover Patent): Discloses a handover method between base stations based on PSSM mirroring. - Application No. 202611070342X (UWB positioning patent): discloses a pilot signature mechanism. - Application No. 2026110481706 (Zero Signaling Access Patent): Discloses a method for first-time access to a DSF network without a DSF node. - Application No. 2026102173652 (Control Signaling Patent): Discloses the physical layer structure of secure pilot frames and a pilot-data symbol-level fusion method. - Application No. 2026102174585 (QoS Resource Mapping Patent): Discloses a method for RULE_ID multidimensional configuration and fine-grained resource mapping. Background Technology

[0005] I. Basic Communication Relationships and Limitations in the Existing DSF System The applicant's earlier patent application for a distributed autonomous intelligent agent cluster (application number 2026106207395) was the first to realize decentralized intelligent agent cluster collaboration. In this scheme, all nodes share the group DSF root key, and each node derives its individual DSF from the root key based on its own ID. `K_sec_node = PRF(K_sec_root, ID || "NODE")` Where PRF is a cryptographic pseudo-random function (such as HMAC-SHA256), `ID` is the unique identifier of the node, and `"NODE"` is a derived special label.

[0006] Within this framework, any two nodes that know each other's IDs can communicate directly. Taking nodes A and B as an example: node A derives its own individual DSF `K_sec_A` based on the group DSF root key and its own ID, used for transmission in the A→B direction; node B derives `K_sec_A` based on A's ID, used for receiving signals in the A→B direction. The reverse is also true—B uses `K_sec_B` to send, and A uses `K_sec_B` to receive. Therefore, the two nodes maintain two independent sets of individual DSFs, each used for transmission in one direction. Nodes A and B only need to know each other's IDs to independently calculate the individual DSF used for transmission, without any signaling interaction throughout the process.

[0007] This scheme has established a complete technical framework in areas such as logical timeline synchronization, relative spatial coordinate system construction, distributed perception fusion, distributed collaborative decision-making, dynamic joining and dynamic DSF updates, and decentralized election and seamless takeover. Its core advantages are: all nodes share the same logical timeline, and the logical counter `n` is strictly synchronized across the entire network; each node independently runs PSSM based on the shared group DSF root key, maintaining logical state consistency without any continuous signaling interaction.

[0008] However, the core assumption of this scheme is that nodes in the cluster are collaborating on the same task or business, and sharing a common RULE_ID can meet all communication needs. This assumption holds true in single-task scenarios (such as a swarm of drones performing a single reconnaissance mission), because all nodes only need a unified communication configuration.

[0009] However, when nodes need to simultaneously carry multiple services (such as URLLC control, eMBB video backhaul, and mMTC status reporting), need to integrate with the traditional 5G core network, and need to support service-level migration and switching, a single public RULE_ID cannot meet differentiated QoS requirements. Specifically: Different services have different requirements for the logic cycle time `T_step` (URLLC requires 0.125ms, eMBB can be 1ms, and mMTC can be 10ms or even longer). Different services have different requirements for the number of resource units `N_PRB` and the number of symbols `N_symbol`. Different business functions have different priority requirements. The scheme does not provide any "migration" mechanism—nodes cannot smoothly transfer communication relationships from one peer node to another. Meanwhile, while the existing PSSM mirroring handover scheme (application number 2026102049886) and LPC+PAN mapping handover scheme (application number 202610313177X) provide handover mechanisms, they both rely on centralized control entities (base stations or LPCs) for decision-making, with nodes acting as passive executors. Specifically: In the PSSM mirror handover scheme, the source base station determines the handover trigger, the target base station determines the admission conditions, and the UE is merely a passive executor. The handover interruption latency is strongly correlated with RTT, and can reach several seconds in GEO scenarios. In the LPC+PAN mapping handover scheme, the LPC centrally maintains a dynamic mapping table, and the UE is seamlessly migrated by updating the mapping table. However, the LPC is a centralized entity, which poses a single point of failure risk and cannot work when the power supply link is interrupted. Neither of the above two solutions can work in a fully decentralized peer-to-peer cluster.

[0010] The handover process in existing 5G and its evolved systems is always based on the physical concept of a "cell". The UE is attached to a specific cell, and the handover target is a "neighboring cell". The handover execution requires random access (RACH) and RRC reconfiguration to be completed in the target cell. This paradigm implicitly assumes that the anchor point of the communication relationship is the physical cell. Even in the applicant's previous PSSM mirror handover scheme and LPC+PAN mapping scheme, the handover still revolves around the "base station / cell", and the UE is still "moving from one cell to another", rather than "the communication relationship migrating from one peer node to another".

[0011] II. The core technical problem to be solved by this invention In summary, the existing DSF system has the following gaps: Basic communication relationships (based on individual DSF) solve the problem of "how two nodes that know each other's IDs can communicate with zero signaling," but it cannot meet the requirements of differentiated QoS for multiple services, nor does it provide any communication relationship migration mechanism. Centralized handover schemes provide handover mechanisms, but they rely on a centralized control entity and cannot work in a fully decentralized peer-to-peer cluster.

[0012] The core technical problem to be solved by this invention is: in a distributed autonomous intelligent agent cluster, how to establish a business-specific communication relationship (i.e., an independent business-specific DSF instance and its driven business-specific logical time axis) based on the basic communication relationship (identity verification based on individual DSF) and realize the autonomous migration of the business-specific communication relationship between any two peer nodes. The essence of the migration is the atomic switching of the PSSM instance pointer rather than the reconstruction of the connection. The whole process does not depend on any centralized control entity. Summary of the Invention

[0013] I. Definition of Core Concepts Intelligent agent nodes: Communication entities with autonomous decision-making capabilities, including but not limited to satellites, user equipment (UE), drones, ground stations, and robots. All intelligent agent nodes in the cluster have completely equal status—any node can initiate communication relationship migration, and any node can be the target of migration. A node's role is dynamically determined by its autonomous decisions and the current state of its communication relationship, regardless of the node's physical type.

[0014] Basic Communication Relationship: A deterministic communication association established between two intelligent agent nodes based on individual DSFs. Its working principle is as follows: Node A derives its own individual DSF `K_sec_A = PRF(K_sec_root, ID_A || "NODE")` based on the group DSF root key and its own ID, used for sending signals in the A→B direction; Node B derives `K_sec_A` based on A's ID, used for receiving signals in the A→B direction. The reverse is also true—B uses `K_sec_B` to send, and A uses `K_sec_B` to receive. Therefore, two independent individual DSFs are maintained between the two nodes, each used for sending signals in one direction. The basic communication relationship uses a common RULE_ID, operates on the main logic timeline, and serves as the trust foundation for node discovery, state declaration, identity verification, and the establishment of business-specific communication relationships. The establishment of the basic communication relationship requires no signaling interaction—any two nodes that know each other's IDs can independently derive each other's individual DSFs and immediately begin communication.

[0015] Individual DSF: A node's key material is independently derived from the group DSF root key and its own ID, specifically the security key field K_sec_node = PRF(K_sec_root, ID || "NODE") in the DSF triple. A complete individual DSF triple must also include the Init_Anchor and Rule_ID corresponding to that node (typically using the Init_Anchor and Rule_ID of the public DSF). The K_sec of the individual DSF is independently calculated and generated by the node itself, and is not distributed by any other node, ensuring the autonomy of node identity in a decentralized architecture. In public network scenarios, the derivation of the individual DSF occurs after the UE completes identity authentication—before authentication is successful, the UE does not derive the K_sec of the individual DSF and does not participate in any communication. Individual DSF is a core concept fully disclosed in a prior distributed cluster patent (application number 2026106207395), and this invention inherits it as the key basis for basic communication relationships.

[0016] Main Logical Timeline: A unified logical time base driven by a common PSSM across the entire network. All nodes independently run the common PSSM based on a shared common DSF, and the logical counter `n` is strictly equal across the entire network (guaranteed by a deterministic state machine). The main logical timeline is used for node announcements, discovery, maintenance of basic communication relationships, and initial anchoring of service-specific logical timelines. The logical tick period of the main logical timeline is defined by the `T_step_common` parameter in the common RULE_ID.

[0017] Service-specific communication relationships: Enhanced deterministic communication associations established to carry specific services. A service-specific communication relationship corresponds to an independent DSF instance, whose `Rule_ID` field is configured with service-specific QoS parameters (distinct from the public `RULE_ID`). Therefore, a service-specific communication relationship is defined by its complete DSF instance and an independent service-specific logical timeline, where: 1. Identity Element – ​​Exclusive K_sec: A shared key derived for a specific business communication relationship. The exclusive K_sec in a business-specific communication relationship is fundamentally different from the individual DSF in a basic communication relationship – the former is a set of keys shared by both parties, used for bidirectional transmission and reception (naturally supporting full-duplex communication), while the latter is a key held by each node, used only for its own sending direction (A uses `K_sec_A` to send, B uses `K_sec_B` to send, each managing its own direction). The sources of exclusive K_sec include, but are not limited to, the following six methods: - Method 1 (Deterministic Derivation): Derivation is performed using cryptographic functions based on the group DSF root key and the IDs of participating nodes. For example, the dedicated K_sec between node A and node B can be derived as `K_sec_AB = PRF(K_sec_root, ID_A || ID_B || "DEDICATED")`. This method is suitable for purely decentralized scenarios, requiring no external intervention; both parties can independently compute the same shared key. This method can be used independently of the basic communication relationship—that is, node A and node B can skip establishing the basic communication relationship and directly establish a business-specific communication relationship based on deterministic derivation for business communication. This method guarantees zero signaling establishment of business-specific communication relationships in a peer-to-peer architecture.

[0018] - Method 2 (Active Distribution): A random key is generated by the migration initiating node or any node in the network and securely distributed to other participating nodes through basic communication relationships. This method is suitable for scenarios where it is desired that the key is not bound to a node ID, providing greater flexibility.

[0019] - Method 3 (Core Network Distribution): In deployment scenarios compatible with the core network, the key is securely generated by the core network (such as 5G AUSF) and distributed via NAS signaling. This method is suitable for public network deployment scenarios, where the core network can centrally manage service keys. This method embodies master-slave key management, complementing the decentralized derivation of Method 1.

[0020] - Method 4 (Negotiation Generation): Participating nodes jointly determine the key after exchanging information through basic communication relationships. In a preferred embodiment, a Diffie-Hellman-like key exchange protocol can be used to complete key negotiation over a secure channel of basic communication relationships. The generated shared key is then bound to the business identifier through a cryptographic hash function to form the final exclusive K_sec.

[0021] - Method 5 (Service Identifier Derivation): Derived based on the service type identifier, independent of the node ID. For example, `K_sec_service = PRF(K_sec_root, Service_ID || "DEDICATED")`. All nodes participating in the same service share the same set of keys, suitable for multicast or broadcast scenarios.

[0022] - Method Six (Multicast Derivation): Derivation based on the joint IDs of all participating nodes. For example, `K_sec_group =PRF(K_sec_root, ID_1 || ID_2 || ... || ID_n || "MULTICAST")`. Only nodes included in the derivation input can compute the correct group key, suitable for multi-node shared key scenarios where restrictions on participating parties are required.

[0023] 2. Behavioral Element – ​​Dedicated RULE_ID: A prior QoS resource mapping patent (application number 2026102174585) has disclosed that RULE_ID can contain QoS parameters such as `T_step`, `N_PRB`, `N_symbol`, `Priority`, `Frame_Mode`, and `Pilot_Ratio`. In this invention, the `Rule_ID` field in the DSF instance corresponding to the service-specific communication relationship is the service-specific RULE_ID, and its parameters are independent of the public RULE_ID and the dedicated RULE_ID of other services. The dedicated RULE_ID determines "what QoS, what beat, and what waveform communication."

[0024] 3. Timing Elements – Business-Specific Logical Time Axis State: Business-specific communication relationships establish an independent business-specific logical time axis above the main logical time axis. This time axis is driven by a dedicated PSSM instance driven by the DSF instance, and its initial anchor point (starting logical time) is anchored to a specific logical time (e.g., `n_start`) of the main logical time axis, after which it evolves independently. The logical tick period of the business-specific logical time axis is defined by the `T_step` parameter in the `Rule_ID` of the DSF instance, and can be different from the tick of the main logical time axis (`T_step_common` in the common RULE_ID). Both parties determine the transmit and receive timing based on the counter of this business-specific logical time axis, decoupling it from the physical clock.

[0025] The essence of communication relationship migration: Migration is not "disconnection and reconnection," but rather the process of atomically transferring a business-specific communication relationship (i.e., a complete business-specific DSF instance and its driven business-specific logical timeline state) from the source node to the target node. The PSSM instance of the new communication relationship has already been created and is in an inactive state during the migration preparation phase. During migration execution, only the atomic switching of the PSSM instance pointer occurs. The old and new PSSM instances are atomically exchanged within the switching window, and there is no "semi-migration" intermediate state.

[0026] Migration initiating node: An agent node that autonomously decides to migrate a communication relationship from its currently associated source node to its target node. Any agent node can become a migration initiating node at any time, regardless of its physical type.

[0027] Source node: The peer node with which the migration initiating node currently maintains a communication relationship. During the migration process, the source node is informed by the migration initiating node (by detecting the migration intention pilot) that the communication relationship is about to be released. It should be noted that the migration initiating node and the source node can be the same node. In this case, the migration is a reconstruction of the communication relationship itself (such as a QoS upgrade), rather than a cross-node transfer of the communication relationship.

[0028] Target node: The node to which the migration initiating node wishes to establish a new communication relationship. During the migration process, the target node is informed by the migration initiating node (by detecting the migration intention pilot signal) that a communication relationship is about to be established.

[0029] Migration decision: A decision made autonomously by an agent node based on local measurement information (signal quality, location prediction, node state, etc.), without relying on network-side instructions. Migration decision is one of the core features that distinguishes this invention from traditional centralized switching schemes—nodes do not passively wait for network commands, but actively make decisions based on local perception information.

[0030] Migration Execution Logic Time (`n_establish`): This is the logical time agreed upon by both parties on the business-specific logical timeline to trigger the atomic switch. This time is based on the counter of the business-specific logical timeline. Both parties have already agreed on this time during the migration preparation phase (carried by the migration intention pilot signal), requiring no signaling negotiation.

[0031] Atomic Switching: An atomic switching instruction is triggered at logical moment `n_establish`. The state transition between the old and new communication relationships is completed within a continuous time window—there is no communication interruption window between the release of the old relationship and the establishment of the new relationship, nor is there an overlap period where the old and new relationships are used simultaneously. The length of the switching window is determined by the physical layer execution time (including but not limited to RF tuning time, register switching time, etc.) and is independent of the service-specific logic tick cycle `T_step`.

[0032] Switching window end flag: The switching window ends when the physical layer synchronization of the target link (including but not limited to automatic gain control convergence and frequency locking) is completed and ready. This flag separates the pure hardware execution time from the logical protocol steps.

[0033] The `n_announce` logical moment is a set of logical moments predefined by the `Rule_ID` of the public DSF, specifically used for pilot signature announcements on the main logical timeline. All nodes broadcast their own pilot announcement signatures during the `n_announce` logical moment and listen for the pilot announcement signatures of other nodes during the same time. The `n_announce` logical moment is time-multiplexed with the normal communication logical moment (signal types are distinguished by different purpose tags).

[0034] Main announcement pilot: A pilot signature generated by a node based on common DSF parameters and the current main logic timeline state, used for the announcement of the main logic timeline and blind search synchronization with unknown nodes. P_announce(n) = PRF(K_sec_public, S(n) || "ANNOUNCE_SIG" || n) Where K_sec_public is the public DSF parameter, S(n) is the current main logic timeline logic state, n is the current main logic timeline logic counter value, and "ANNOUNCE_SIG" is a cryptographically specific tag for announcement purposes. All nodes synchronized to the main logic timeline broadcast the same main announcement pilot at the announcement logic moment. Slave nodes perform matched filtering detection using the method described in the blind search capture patent (application number 2026109913982) to complete the initial synchronization of the main logic timeline. After synchronization is complete, slave nodes obtain the ID of the announcing node by parsing the data part of the announcement message, and then derive the individual DSF of that node based on the group DSF root key for subsequent mutual identification between nodes.

[0035] Migration Intent Pilot: When a node needs to migrate its communication relationship, it generates a pilot signature using a migration-specific tag, the target node ID, and the migration execution logic time as derived parameters. `P_migrate(n) = PRF(K_sec_node, S(n) || "ANNOUNCE_SIG_MIGRATE" || ID_target || n_establish || n)` The "ANNOUNCE_SIG_MIGRATE" tag is a cryptographically specific tag for migration, which differs from the regular declaration tag "ANNOUNCE_SIG". The migration intention pilot signal is used to announce the migration intention, target node, and execution time to all nodes in the cluster. The source and target nodes distinguish between regular declarations and migration intentions by detecting the different cryptographically specific tags.

[0036] II. The essential distinction between basic communication relationships and business-specific communication relationships This invention clearly distinguishes two communication relationships, which are fundamentally different in terms of key mechanism, timeline, RULE_ID, PSSM instance, and purpose: Basic communication relationships (covered by prior distributed cluster patents): - Key mechanism: Two independent individual DSFs (A sends using `K_sec_A`, B receives using `K_sec_A`; B sends using `K_sec_B`, A receives using `K_sec_B`), each managing its own direction. - Timeline: Main logic timeline (driven by common PSSM, with common RULE_ID defining the tick time) - RULE_ID: Public RULE_ID (unified QoS configuration) - PSSM Instance: Public PSSM (shared by all nodes) - Purpose: Node discovery, state declaration, identity verification, basic signaling - Features: Zero negotiation, deterministic ID-based derivation, no need to establish additional processes Business-specific communication relationships (incremental in this invention): - Key mechanism: A shared, dedicated K_sec key (both parties use the same key for bidirectional transmission and reception, naturally supporting full-duplex communication), with diverse sources (deterministic derivation / active allocation / core network distribution / negotiation generation / service identifier derivation / multicast derivation). - Timeline: A business-specific logical timeline (driven by a PSSM instance driven by a business-specific DSF instance), with its initial anchor point fixed to the main logical timeline. - RULE_ID: Included in a dedicated DSF instance, independent of the public RULE_ID, for customized QoS. - PSSM Instance: Independent PSSM instance (one for each business, so they do not interfere with each other) - Purpose: To carry specific business data (URLLC / eMBB / mMTC, etc.) - Features: Built upon basic communication relationships, created on demand, and migrated entirely during migration. The relationship between the two: The basic communication relationship provides ID confirmation and a basic communication channel for the service-specific communication relationship. The service-specific communication relationship can be established directly based on deterministic derivation, or it can be issued by the core network or obtained through other means. The basic communication relationship and the service-specific communication relationship can exist independently—a node can directly establish a service-specific communication relationship for service communication without establishing a basic communication relationship first. In public network scenarios, after the UE completes authentication, it can directly establish a service-specific DSF without first establishing a basic communication relationship.

[0037] III. Core Inventive Concept of this Invention The core inventive concept of this invention lies in: In a distributed autonomous intelligent agent cluster, based on basic communication relationships (individual DSFs), business-specific communication relationships (i.e., independent business-specific DSF instances and their driven business-specific logical timelines) are established. The autonomous migration of business-specific communication relationships between any two peer nodes is achieved through atomic switching of PSSM instance pointers. The migration does not involve changes to individual DSFs, but only the overall transfer of business-specific communication relationships. The entire process involves zero signaling, zero RTT dependency, and zero centralized control.

[0038] This concept includes the following key elements: (I) Layered Design of Two-Layer Communication Relationships and Two-Level Logical Time Axis: Basic communication relationships operate on the main logical time axis (common PSSM, common RULE_ID), solving the identity verification problem of "who are you"; business-specific communication relationships operate on an independent business-specific logical time axis (driven by a business-specific DSF instance), whose cycle period is independently defined by the `Rule_ID` of the DSF instance and may differ from the main logical time axis, solving the problem of "what QoS is used to transmit business data". The two layers are decoupled, each performing its own function, enabling the same node to maintain multiple business-specific connections with different QoS levels simultaneously.

[0039] (ii) Peer-to-peer target discovery and migration decision-making: Any node can discover a target by detecting the declared pilot signatures of other nodes through matched filtering, and autonomously decide to migrate based on local measurement information, without relying on any centralized control entity. This mechanism gives different types of nodes, such as satellites, UEs, and drones, completely equal status, and any node can initiate migration.

[0040] (III) The Essence of Migration – Atomic Switching of PSSM Instance Pointers: Migration is not a “disconnection and reconnection”, but rather the activation of a prepared PSSM instance through an atomic pointer switch at a defined logical moment, while simultaneously deactivating the old PSSM instance. The new and old PSSM instances complete the atomic exchange within the switching window, and there is no “half-migration” intermediate state. Since the new PSSM instance has already been created during the preparation phase, only pointer switching occurs during migration execution, and the interruption latency depends only on the physical layer switching window.

[0041] (iv) Decentralized Collaboration for All Nodes to Autonomously Adjust Behavior: For any migration event, all involved nodes (migration initiator, source node, and target node) obtain migration event information (target node ID, execution time, etc.) by detecting the migration intention guide, and autonomously adjust their respective behaviors accordingly—the migration initiator performs a pointer switch, the target node activates the PSSM instance, and the source node deactivates the old instance or acts as a proxy anchor point to forward data in a compatible core network scenario. No node needs to send "confirmation" or "command" signaling to other nodes.

[0042] (v) Diversification of Service-Specific K_sec Sources: Service-specific K_sec is not limited to deterministic derivation, but can flexibly choose any of the six sources depending on the deployment scenario. Deterministic derivation is used in purely decentralized scenarios, core network distribution is used in core network compatible scenarios, and service identifier derivation or multicast derivation is used in multicast scenarios. This diversity allows the invention to be deployed in various scenarios such as public networks, private networks, and multicast.

[0043] IV. The essential difference between this invention and existing solutions This invention differs fundamentally from existing solutions in several dimensions. The table below compares the systems from the perspectives of inter-node relationships, migration initiator, decision-making body, key type, timeline, migration target, migration nature, whether it supports multiple QoS, and whether it supports parallel migration of multiple services: Comparison Dimensions Distributed cluster solution PSSM Mirror Switching LPC+PAN mapping switch This invention Relationship between nodes reciprocity Master-slave (base station - UE) Master-Slave (LPC-UE) reciprocity Migration Initiator No migration mechanism base station LPC any node Decision-making body No migration mechanism base station LPC Arbitrary node self Key type Individual DSF (two sets) Pre-configured key | Pre-configured key Individual DSF + Dedicated DSF Instance Timeline hierarchy Main logic timeline only Physical frame structure Physical frame structure Main logic timeline + business-specific logic timeline Migration objects No migration mechanism PSSM context Mapping table entries Overall Business-Specific Communication Relationship The nature of migration not applicable Context passing (signaling driven) Mapping update (centralized) PSSM instance pointer atomic switching Does it support multiple QoS? no limited limited Yes (dedicated DSF instance, independent configuration) Does it depend on centralized control? no It is (a base station) Yes (LPC) no Is it based on the concept of a community? No (peer-to-peer communication) yes yes no Is random access required? not applicable Yes (Target Cell RACH) Yes (Target Cell RACH) No (pointer atomic toggle) While distributed cluster solutions achieve zero-signaling communication between peer nodes, they do not provide any migration mechanism. PSSM mirroring and LPC+PAN mapping switching, although providing switching mechanisms, both rely on a centralized control entity. This invention, building upon the above solutions, establishes for the first time a complete communication relationship migration process in a distributed autonomous agent cluster—from autonomous decision-making, target discovery, intention declaration to relationship establishment and release, all completed autonomously by the nodes, and supporting parallel migration across multiple QoS and service requirements.

[0044] V. Two Deployment Scenarios to which this Invention is Applicable This invention is applicable to the following two deployment scenarios. The migration process is essentially the same in both scenarios, the difference being whether the core network needs to be aware of path changes: Scenario 1: Pure intelligent agent cluster (decentralized native mode) All nodes in the cluster (satellites, drones, UEs, robots) are completely peer-to-peer, with no core network, no base stations, and no central control node. Communication relationships between nodes are autonomously established and maintained by the DSF (Digital Service Provider) foundation. Basic communication relationships are established on the main logical timeline based on individual DSFs, while service-specific communication relationships are established on an independent service-specific logical timeline above the main logical timeline. Dedicated K_sec is generated through deterministic derivation (based on participating node IDs) or proactive allocation. The entire migration process involves no core network participation, no centralized decision-making by base stations / LPCs; migration decisions are made autonomously by the nodes, and direct communication occurs between nodes after migration.

[0045] Applicable scenarios: drone swarm formation flight, deep space exploration cluster collaboration, military ad hoc network communication, disaster relief networks, underwater unmanned vehicle collaboration, etc.

[0046] Scenario 2: Intelligent agent cluster compatible with core network (hybrid mode) The DSF intelligent agent cluster is deployed as a subnet or extended domain of the 5G / 6G core network. The core network retains the control plane, while the data plane portion is delegated to the DSF cluster for autonomous management. The dedicated K_sec for service-specific communication relationships can be securely generated and distributed by the core network (Method 3). During the migration, the core network achieves seamless path switching through source node proxy forwarding—the source node continues to act as the core network's service anchor point during the migration, relaying received downlink data to the target node via basic communication relationships. The target node caches the data and sends it to the migration initiating node after the handover window ends. After the migration is complete, the core network updates the data plane path from the source node to the target node.

[0047] Applicable scenarios: 5G / 6G UE migration across base stations, satellite internet user switching, and migration of communication relationships between vehicles and roadside units in vehicle-to-everything (V2X) networks.

[0048] The migration process in both scenarios is essentially the same—node autonomous decision-making and logical atomic switching. The difference lies in the fact that scenario two requires seamless path switching on the core network side (see Implementation Example 7 for details). This dual-scenario design makes the present invention applicable to both fully decentralized private networks and public networks coexisting with traditional core networks, and has broad commercial application prospects.

[0049] VI. Technical Solution (I) System Model and Assumptions This invention is applicable to the following system environments: - There exists a distributed autonomous agent cluster consisting of multiple agent nodes. Each node shares the group DSF root key `K_sec_root` and public DSF parameters (including public RULE_ID, declaration logic timing configuration, etc.). - Each node runs the public PSSM independently, and the main logical time axis logical counter `n` is strictly equal across the entire network (guaranteed by a deterministic state machine - all nodes independently execute the same deterministic hash chain or logical counter evolution algorithm based on the same group DSF root key and initial state, mathematically guaranteeing that the same logical time `n` corresponds to the same logical state `S(n)`). - Each node holds its own individual DSF `K_sec_self = PRF(K_sec_root, ID_self || "NODE")`, which is used for the transmission direction in basic communication relationships. In public network scenarios, the derivation of the individual DSF occurs after the UE completes identity authentication. - Each node broadcasts the main announcement pilot (derived from the common DSF parameters) at the announcement logic time n ∈ N_announce, and listens for the main announcement pilot at the announcement logic time. - Basic communication relationships have been established between nodes or can be established on demand (i.e., nodes know each other's IDs and can derive each other's individual DSFs). - Business-specific communication relationships are established on top of the main logical timeline, with a dedicated business-specific logical timeline driven by a PSSM instance driven by a dedicated DSF instance. A key feature of the system model is that nodes in the cluster can be any type of communication entity—satellites, UEs, drones, ground stations, robots, etc.—and they have completely equal status. A node can maintain multiple service-specific communication relationships simultaneously. Each communication relationship corresponds to a different peer node and a different service type, and each has its own dedicated K_sec, a dedicated service-specific logical timeline, and a dedicated PSSM instance.

[0050] (II) Authentication of Public Network UEs and Individual DSF Derivation Timing For UEs accessing via the public network, the complete process of adding them to the main logical timeline and obtaining their individual DSF is as follows: Step 1: Obtain Public DSF Parameters. The UE first obtains the publicly available public DSF parameters (group DSF root key `K_sec_root` and public DSF parameters), which are publicly available and can be obtained by any UE. The UE detects the announcement message of the main announcement node and completes the main logical timeline synchronization by blindly searching and capturing the method described in the patent (application number 2026109913982).

[0051] Step 2: Initiate Access Procedure. The UE initiates a zero-signaling access procedure (MsgA / MsgB) based on common DSF parameters, announcing its existence to the network and requesting access. MsgA uses a secure pilot frame format, with the pilot sequence carrying the contention identifier `C` and the data portion carrying the temporary identity identifier `Temp_ID`. The base station detects MsgA on dedicated MsgA resources and identifies the contention identifier used by the UE through matched filtering.

[0052] Step 3: Identity Authentication. During or after the access procedure is triggered, the network side performs identity authentication on the UE (such as 5G AKA or its equivalent). This authentication process verifies the legitimacy of the UE's identity and confirms whether it is an authorized user.

[0053] Step 4: Individual DSF Derivation. After successful authentication, the UE independently derives its individual DSF `K_sec_UE = PRF(K_sec_root, ID_UE || "NODE")` based on its own ID and the group DSF root key. The network side independently derives the same individual DSF based on the UE's ID for basic communication with that UE. UEs that fail authentication have their access process terminated, do not derive an individual DSF, and cannot be added to the main logical timeline.

[0054] Step 5: Establishing Subsequent Communication. After obtaining the individual DSF, the UE can choose one of the following methods to establish a service-specific communication relationship according to the deployment strategy: - Path A: Establish basic communication relationships, and then build a dedicated DSF instance for the business based on this. - Path B: Skip the basic communication relationship establishment steps and directly create a dedicated DSF instance for business communication. This authentication sequence ensures the security premise that "only legitimate UEs can obtain individual DSFs and participate in DSF network communication" in public network scenarios.

[0055] (III) Detection principle of node ID and status information in pilot signature In this invention, node ID and status information are carried through different dimensions of the physical layer signal, and the receiving end can extract both types of information simultaneously through matched filtering. 1. Obtaining and detecting node IDs During the announcement phase of the main logical timeline, the node ID is not carried by the pilot sequence itself, but rather by the data portion of the announcement message. The main announcement pilot is derived from common DSF parameters: P_announce(n) = PRF(K_sec_public, S(n) || "ANNOUNCE_SIG" || n) K_sec_public is the common DSF parameter. All synchronized nodes use the same common DSF parameter to generate the same master announcement pilot. During the blind search phase, slave nodes use the common template for matched filtering detection to complete the initial synchronization of the main logical timeline without needing to know the ID of any node in advance.

[0056] After synchronization is complete, the slave node parses the sender node's ID from the data portion of the announcement message, and then derives the individual DSF for that node based on the group DSF root key, which is used for subsequent inter-node identification and matching filtering. At this point, the receiver can generate the corresponding individual DSF based on the candidate node ID for node identification. K_sec_candidate = PRF(K_sec_root, ID_candidate || "NODE") P_candidate(n) = PRF(K_sec_candidate, S(n) || "ANNOUNCE_SIG" || n) Then, the correlation value between the received signal and the candidate pilot signature is calculated: C = |Σ Y[k] · conj(P_candidate[k])| When ID_candidate = ID_node, the correlation value C shows a significant peak; when ID_candidate ≠ ID_node, the correlation value approaches zero.

[0057] After receiving signal Y at logical time n, the receiving end generates a corresponding candidate pilot signature for candidate node ID ID_candidate: `K_sec_candidate = PRF(K_sec_root, ID_candidate || "NODE")` `P_candidate(n) = PRF(K_sec_candidate, S(n) || "ANNOUNCE_SIG" || n)` Then, the correlation value between the received signal and the candidate pilot signature is calculated: `C = |Σ Y[k] · conj(P_candidate[k])|` When `ID_candidate = ID_node`, `P_candidate = P_announce`, and the correlation value `C` shows a significant peak; when `ID_candidate ≠ ID_node`, due to the pseudo-randomness of the PRF output, the correlation value approaches zero. By setting a detection threshold `γ`, a successful match is determined when `C > γ`, and the ID of the unknown node is identified as `ID_candidate`.

[0058] 2. Bearing and Demodulating Status Information Status information (including but not limited to the node’s current load, available resources, coverage area, etc.) is not carried by the pilot sequence itself, but by the data portion of the security pilot frame.

[0059] The physical layer format of the security pilot frame is as follows (based on control signaling patent application number 2026102173652): `S[k] = P_base[k] × (1 - 2 × Data_bit[i])` Where `P_base[k]` is the cross-referencing pilot sequence generated based on DSF, and `Data_bit[i]` is the data bit to be transmitted. This formula realizes the fusion of pilot sequence and data at the physical layer symbol level. Specifically, each resource unit carries both pilot and data simultaneously—the pilot sequence `P_base[k]` provides channel estimation and synchronization reference, while the data bits are modulated onto the pilot sequence using BPSK modulation of `(1 - 2 × Data_bit[i])`.

[0060] The receiving end processing flow is as follows: (1) First, the received signal is matched-filtered using the locally generated pilot sequence `P_base`: `Z[k] = Y[k] × conj(P_base[k]) = H[k] × (1 - 2 × Data_bit[i]) + N'` Where `H[k]` is the channel response and `N'` is the noise term.

[0061] (2) Extract the channel response `|H[k]|` from the amplitude of `Z[k]` to complete the channel estimation.

[0062] (3) Determine the data bits from the real part of `Z[k]`: `Data_bit[i] = (sign(Real(Z[i])) + 1) / 2` (4) Recover status information fields, including current load (percentage), available resources (remaining PRBs), coverage (latitude and longitude / beam pointing), etc.

[0063] 3. Separation design of pilot signature and status information Pilot signatures (derived from PRFs) serve as authentication tools—unforgeable and cryptographically verifiable; the data portion of the secure pilot frame serves as a status announcement tool—readable by all nodes and containing no security-sensitive information. The two are fused at the physical layer symbol level, with a single matched filtering operation simultaneously completing authentication and data demodulation.

[0064] The significance of this separation design is that: identity information is cryptographically guaranteed (attackers cannot forge it because they cannot generate the correct pilot signature without the group DSF root key `K_sec_root` and the node ID), state information can be read by all nodes (facilitating migration decisions), and the two do not interfere with each other.

[0065] (iv) Migration Triggering Conditions The agent node continuously performs the following local measurements as input for the migration decision: 1. Signal Quality Measurement: Nodes continuously measure the received signal quality of the current source node, including but not limited to RSRP (Reference Signal Received Power), SINR (Signal-to-Interference-plus-Noise Ratio), and RSRQ (Reference Signal Received Quality). When a node receives the announcement pilot signatures of other nodes at the announcement logic time, it also simultaneously measures the signal quality of those nodes.

[0066] 2. Position and Motion Prediction: Based on its own positioning information (obtainable via GNSS, inertial navigation, or cluster relative positioning) and a pre-configured coverage map (or ephemeris), a node predicts whether it is about to leave the effective coverage area of ​​the source node. In satellite communication scenarios, nodes can predict satellite overpass times and coverage changes based on ephemeris data.

[0067] 3. Neighbor Node State Awareness: During the announcement logic, nodes continuously listen to the announcement pilot signatures of other nodes to obtain their IDs and the state information carried in the announcements (load, available resources, coverage, etc.). This state information provides a reference for the resource availability of the target node for migration decisions.

[0068] The triggering conditions for migration decisions include, but are not limited to, the following three: - Condition 1 (Signal Quality Trigger): The signal quality of the target node is consistently better than that of the source node by more than a preset threshold (e.g., 3dB), and the duration reaches a preset number of logic ticks (e.g., N logic ticks). This condition is used for signal quality-driven migration.

[0069] - Condition 2 (Location Prediction Triggered): The node's location is predicted to leave the source node's coverage area (e.g., based on ephemeris prediction, it will leave the coverage area after K logical moments). This condition is used for coverage-driven migration.

[0070] - Condition 3 (Load Balancing Triggered): The load status declared by the source node becomes "overloaded," and the load status declared by the target node becomes "normal." This condition is used for load balancing-driven migration, allowing nodes such as satellites to proactively migrate some services to adjacent nodes with lower loads.

[0071] The above triggering conditions can be used individually or in combination (for example, migration is triggered only when both signal quality and load balancing conditions are met simultaneously). Specific thresholds and parameters are pre-configured by network policies or determined autonomously by nodes according to their own policies.

[0072] (v) Autonomous discovery of target nodes and confirmation of basic communication relationships Before migrating the business-specific communication relationship, if the migration initiating node (denoted as Node 1) and the target node (denoted as Node 3) have not yet established a basic communication relationship, then the establishment of the basic communication relationship must be completed first. The establishment of the basic communication relationship is completed entirely at the physical layer and does not involve any signaling interaction. Step B1: Target Node Discovery. Node 1 opens its receive window and receives the signal at the announcement logic time n ∈ N_announce. Node 1 uses the main announcement pilot template generated by the common DSF parameters to perform matched filtering detection and capture the announcement message. After successful capture, it demodulates the announcement information from the data portion of the security pilot frame, extracts the ID of the sending node, and verifies its legitimacy in step B2.

[0073] Step B2: Identity Legitimacy Verification. Node 1 uses the group DSF root key `K_sec_root` and the extracted unknown node ID `ID_3` to regenerate the candidate pilot signature `P_verify(n) = PRF(PRF(K_sec_root, ID_3 ||"NODE"), S(n) || "ANNOUNCE_SIG" || n)`, and compares it with the received pilot signature. If they match (the correlation value exceeds the threshold), the verification passes, confirming that the node is a legitimate node.

[0074] Step B3: Basic communication key derivation. Node 1 derives Node 3's individual DSF based on the group DSF root key and Node 3's ID: `K_sec_node3 = PRF(K_sec_root, ID_3 || "NODE")`. Node 3 derives Node 1's individual DSF in the same way: `K_sec_node1 = PRF(K_sec_root, ID_1 || "NODE")`. Both nodes compute independently without any signaling interaction.

[0075] Step B4: Establishing Basic Communication Relationship. Both parties activate their basic communication relationship with each other at the next logical time step, using the common RULE_ID for deterministic communication on the main logical timeline. At this point, Node 1 and Node 3 have established a basic communication relationship and can exchange status information and negotiate business parameters. After the basic communication relationship is established, Node 1 and Node 3 each maintain the other's individual DSF locally, and subsequent communication does not require repeated derivation.

[0076] The establishment of basic communication relationships is a one-time overhead. In typical deployments such as satellite constellations and drone swarms, basic communication relationships between nodes are usually established during cluster initialization or when a node joins, and subsequent migration of business-specific communication relationships does not require repeating the above steps.

[0077] (vi) Declaration of relocation intention Step D1: Determine the migration target and execution time. The migration initiating node (denoted as Node 1) determines the migration target node (denoted as Node 3) and the migration execution logic time `n_establish` based on the local migration decision results. `n_establish` is a future logical time on the business-specific logical timeline, and its selection satisfies the following constraints: - `n_establish` represents the logical moment in the future, allowing preparation time for target node 3 (at least `Δ_prepare` business-specific logical beats). - `n_establish` occurs within the logical time window when both node 1 and node 3 are active. The selection of `n_establish` is independent of the physical layer switching window length—the switching window length is determined by physical layer factors such as RF tuning time, and is not constrained by `n_establish`. Step D2: Generate migration intention pilot. Node 1 generates a migration intention pilot at the announcement logic time `n_announce_migrate` (satisfying `n_announce_migrate < n_establish`). Node 1 uses a migration-specific cryptographic tag, the target node ID, and the migration execution logic time as derived parameters: `P_migrate(n_announce_migrate) = PRF(K_sec_1, S(n_announce_migrate) || "ANNOUNCE_SIG_MIGRATE" || ID_3 || n_establish || n_announce_migrate)` Where `K_sec_1` is the individual DSF of node 1, `S(n)` is the current main logic timeline logic state, `n` is the current main logic timeline logic counter value, `"ANNOUNCE_SIG_MIGRATE"` is a cryptographic label for migration purposes, `ID_3` is the target node ID, and `n_establish` is the migration execution logic time.

[0078] The migration intention pilot and the ordinary declaration pilot coexist on the same time-frequency resource via code division multiplexing. Due to their different usage labels, the pilot signatures derived from the two are cryptographically orthogonal and do not interfere with each other. The receiver uses different matched filter templates (corresponding to "ANNOUNCE_SIG" and "ANNOUNCE_SIG_MIGRATE" respectively) for detection to distinguish between ordinary declarations and migration intentions.

[0079] The migration intention guide uses `ID_3` and `n_establish` as derived parameters to carry the target node ID and migration execution time information. The receiving end (node ​​2 and node 3) can simultaneously obtain the migration target and execution time through PRF verification.

[0080] Step D3: Target Node Preparation. After detecting the migration intention pilot signal at the announcement logic time, Node 3 checks the "ANNOUNCE_SIG_MIGRATE" tag through matched filtering and verifies the match between `ID_3` and `n_establish`, confirming itself as the target node. Node 3 performs the following operations during the preparation phase from `n_announce_migrate` to `n_establish`: - Determine the dedicated K_sec: Based on the deployment scenario, select one of six sources (deterministic derivation, active allocation, core network allocation, negotiated generation, service identifier derivation, or multicast derivation) to determine the dedicated K_sec for this service's dedicated communication relationship. - Create a complete DSF instance based on this dedicated K_sec, configuring its `Rule_ID` field with the corresponding service-specific QoS parameters (inheriting the service-specific QoS configuration currently being used by the source node, including parameters such as `T_step`, `N_PRB`, `N_symbol`, `Priority`, `Frame_Mode`, and `Pilot_Ratio`), ensuring QoS consistency before and after the migration. - Create a PSSM instance, which is in an inactive state and will be activated at `n_establish` to drive an independent business-specific logic timeline. - Reserve communication resources for node 1 in the local resource calendar. - In the subsequent declaration logic, set the acceptance status flag to confirm acceptance of the migration (if it cannot be accepted due to insufficient resources or other reasons, set the rejection status flag). Step D4: Source Node Awareness. After detecting the migration intention pilot signal of node 1 at the announcement logic time (target is node 3, execution time is `n_establish`), the source node (denoted as node 2) confirms that node 1 will trigger its migration to node 3 at the `n_establish` time. During the preparation phase from `n_announce_migrate` to `n_establish`, node 2 performs the following operations: - Prepare to release the communication relationship with node 1 at the start of the switching window corresponding to `n_establish`. - In scenarios compatible with the core network (see Implementation Example 7), prepare to act as a proxy anchor point for forwarding data during migration. Regarding the carrying of priority information in migration intention guides: In an optional implementation, the migration initiating node can use the Priority parameter of the current service-specific communication relationship as an additional derived input when generating the migration intention guide (e.g., participating in PRF calculation, encoding the Priority and concatenating it with `ID_target` and `n_establish` as PRF input). The receiving end can recover this priority information through PRF verification. It should be noted that the core information carrying mechanism of the migration intention guide of this invention is implemented through the two derived parameters `ID_target` and `n_establish`; the Priority parameter is optional auxiliary carrying information and does not affect the basic function of the migration intention guide. For migration intention guides that do not carry the Priority parameter, the target node can resolve conflicts based on deterministic rules such as received signal strength or node ID.

[0081] Step D3a (Target Node Concurrency Processing and Conflict Resolution): When multiple initiating nodes simultaneously initiate migrations to the same target node (i.e., the target node detects multiple migration intention signals at the same announcement logic moment), the target node resolves conflicts in a distributed manner through the following mechanism, without the need for any centralized scheduling entity: Mechanism 1 (Priority Arbitration): The target node sorts the requests according to the priority information implied in the pilot signals of each migration intention. Priority information can be obtained in one of the following ways: (1) by deriving the Priority parameter from the implicit bearer in the pilot signal; (2) by the RULE_ID configuration indication carried in the node's declared status information; (3) by the implicit representation of the strength of the received signal (the stronger the signal, the higher the priority). High-priority requests are accepted first.

[0082] Mechanism 2 (Resource-Aware Adoption): The target node determines the upper limit of the number of concurrent migrations it can accept based on the currently available resources (the number of remaining service-specific communication relationships that can be carried, the number of available PRBs, processing capacity, etc.). If the number of requests exceeds the upper limit, the acceptance set is determined according to priority, and a "delay" indication is sent to the initiating nodes that are not accepted through the declaration status field.

[0083] Mechanism 3 (Deterministic Backoff): The initiating node that receives the "delay" instruction re-initiates its migration intention after a predetermined deterministic backoff period. The backoff period is calculated as: `T_backoff = Hash(ID_node || n_current || "BACKOFF") mod K`, where `K` is the maximum backoff window size (configured by the network policy), `ID_node` is the initiating node ID, and `n_current` is the current main logic timeline counter value. Since all nodes independently calculate based on the same input (`ID_node`, `n_current`) and the same hash function, the backoff period obtained by each node is deterministic and evenly distributed, effectively avoiding secondary collisions.

[0084] This conflict resolution mechanism does not rely on any centralized scheduling entity. It is entirely autonomously completed by the target node based on local information and deterministic rules. Each node calculates independently, and the results are consistent.

[0085] (vii) Atomic switching based on logical time axis – PSSM instance pointer switching 1. Ensuring synchronization accuracy of atomic switching The synchronous execution of atomic switching in this invention relies on the two-level synchronization mechanism of the DSF system: Layer 1: The logic counters on the main logic timeline are strictly equal. Each node independently runs the common PSSM based on the same group DSF root key and public DSF parameters. Since the PSSM is a deterministic state machine (its state evolution is driven by a deterministic hash chain or logic counter algorithm), at the same main logic timeline logical moment `n`, the logic counter values ​​`n` calculated by any two nodes holding the same DSF are strictly equal (`n_1 = n_2 = n_3`). This equality is a mathematical fact of the deterministic algorithm, guaranteed by the unidirectionality and determinism of the hash chain or deterministic function, and is independent of whether the physical clock is synchronized or the physical anchor point deviation.

[0086] Layer 2: Bounded alignment of physical anchors. Each node instantaneously samples its local physical clock at the logic decision time `n` to obtain a physical anchor `T_anchor(n)`. Due to the inherent deviation of the physical clocks of each node, there is a deviation between `T_anchor_1(n)` and `T_anchor_2(n)`. This deviation does not need to be eliminated, but only needs to be constrained within the tolerance range of the physical layer—that is, the deviation does not exceed the OFDM cyclic prefix (CP) length (typically 2.34 μs). This deviation does not propagate to the logic counter, but only affects the timing of the current physical layer operation.

[0087] The synchronization precision of atomic switching comes from the following: atomic switching completes the migration intention declaration at the declaration logic moment `n_announce_migrate` on the main logical timeline and triggers execution at the logic moment `n_establish` on the business-specific logical timeline. Since the main logical timeline's logic counter `n` is strictly equal, all nodes have a completely consistent understanding of the "declaration moment"; and since the initial anchor point of the business-specific logical timeline is anchored to a specific logic moment on the main logical timeline, and its evolution is subsequently driven independently by a dedicated PSSM instance, all nodes also have a completely consistent understanding of the "migration execution moment". Bounded alignment of physical anchor points is only used to ensure that the start times of the switching window overlap in physical time.

[0088] Therefore, the synchronization accuracy of atomic switching is guaranteed by the strict equality of the logic counters (determinism), rather than by the synchronization accuracy of the physical clock (statistics). This is the fundamental feature that distinguishes this invention from traditional GPS / 1588 physical synchronization schemes.

[0089] 2. Timing model for window switching The complete timing sequence for the atomic switching is as follows: Step 1 (Trigger Time): At the business-specific logical timeline logical moment `n_establish`, each node simultaneously recognizes the arrival of the trigger time based on its independently running business-specific PSSM instance. Since the initial anchor point of the business-specific logical timeline of each node is the same (all anchored to the same logical moment of the main logical timeline), and subsequent evolution is driven by the same dedicated RULE_ID (the same `T_step`), the business-specific logical timeline counters of each node remain synchronized.

[0090] Step 2 (Window Switching): Starting from the physical moment corresponding to `n_establish`, the window switching begins. The length of the window `Δ_switch` is determined by the following physical layer factors: - RF tuning time (zero for same-frequency shift, inter-frequency shift depends on frequency range and hardware capabilities, typical value 50-200μs) - Register / pointer switching time (<1μs) - PSSM instance switching time (<1μs) Within the switching window, the migration initiating node (Node 1) releases the old communication relationship and establishes the new one. During the switching window, Node 1 does not send or receive data. In public network scenarios, the network side can bypass this window through scheduling mechanisms; in private network scenarios, the length of this window is much shorter than the traditional migration interruption time, and its impact on services is negligible.

[0091] Step 3 (Switch Window End Flag): The switch window ends when the physical layer synchronization of the target link (including but not limited to automatic gain control convergence and frequency locking) is completed and ready. This flag separates the pure hardware execution time from the logical protocol steps.

[0092] Step 4 (Switchover Complete): After the switchover window ends, the old relationship has been released and the new relationship has been established. Node 1 will begin using the new communication relationship to send and receive data at the next available logical moment in the business-specific logical timeline (the next logical tick boundary after `n_establish`).

[0093] 3. Decoupling the window switching mechanism from the business-specific logic cycle `T_step`. The window switching `Δ_switch` and the business-specific logic tick cycle `T_step` are two independent parameters: - The `Δ_switch` is determined by the physical layer hardware capabilities (RF tuning time, register switching time, etc.) and is independent of the application. - `T_step` is determined by the service QoS requirements (e.g., URLLC services can be configured to 0.125ms, and eMBB services can be configured to 1ms), and is independent of the physical layer. - `Δ_switch` may be less than, equal to, or greater than `T_step` — there is no mandatory size relationship between the two. The only constraint is: `Δ_switch` < the maximum tolerable downtime for the business logic. 4. Migration Execution – Atomic Switching of PSSM Instance Pointers During the migration preparation phase (between `n_announce_migrate` and `n_establish`), the PSSM instance of the target node (node ​​3) has been created and is in an activation state (the dedicated K_sec has been determined, the dedicated DSF instance has been created, and the business-specific logical timeline has been initialized but not yet activated).

[0094] At the physical moment corresponding to the logical moment `n_establish` on the business-specific logic timeline, node 1 triggers an atomic switch instruction and enters the switch window. Within the switch window, node 1 performs the following operations: (1) Release old relationships: Deactivate the dedicated DSF instance `K_sec_1-2` (including its Rule_ID configuration) with the source node (node ​​2), terminate the corresponding PSSM instance and its driven business-specific logical time axis (deactivate the old pointer). The PSSM instance stops running, and node 1 no longer uses `K_sec_1-2` for sending and receiving.

[0095] (2) Establish a new relationship: Activate the dedicated DSF instance `K_sec_1-3` (including its Rule_ID configuration) of the target node (node ​​3), activate the corresponding PSSM instance based on this dedicated DSF instance (enable the new pointer), inherit the dedicated RULE_ID, and start an independent business-specific logical timeline, whose initial anchor point is anchored to the current logical time of the main logical timeline (i.e., the logical time of the main logical timeline corresponding to `n_establish`). The PSSM instance starts running, and node 1 starts using `K_sec_1-3` for sending and receiving.

[0096] The two operations described above are completed within the same switching window. There is no communication interruption window between the deactivation of the old pointer and the activation of the new pointer (i.e., there is no period during which neither the old nor the new relationship is used), nor is there an overlapping period during which the old and new pointers are used simultaneously (i.e., two relationships are not used for data sending and receiving at the same time, avoiding data conflicts and timing disorder). This is essentially an atomic swap of PSSM instance pointers—the old PSSM instance pointer is atomically replaced with the new PSSM instance pointer.

[0097] at the same time: - The target node (node ​​3) triggers readiness at the physical time corresponding to `n_establish`, enters the switchover window, and completes the operations of enabling the dedicated DSF instance `K_sec_3-1` of node 1 and activating the corresponding PSSM instance within the window. - The source node (node ​​2) triggers release preparation at the physical moment corresponding to `n_establish`, and completes the release of communication with node 1 within the switching window. After the window switch ends, Node 1 will begin using the new communication relationship to send and receive data at the next available logical moment in the business-specific logical timeline. Node 1 updates the local communication relationship status: marking Node 2 as "released" and Node 3 as "current service node".

[0098] 5. Migration interruption delay The migration interruption latency is equal to the actual length of the switching window `Δ_switch` (which depends on physical layer factors such as RF tuning time and register switching time), and is independent of the service-specific logic tick period `T_step` and RTT. Under typical configurations (same-frequency migration or narrow-band-span inter-frequency migration), the switching window can be controlled within 50-200μs.

[0099] (viii) Optimization methods for ID space search During the target discovery phase, when a node detects an unknown pilot signature that cannot be matched by known candidate pilot signatures, it needs to search the candidate ID space to verify the legitimacy of the pilot signature. The candidate ID space is the set of candidate IDs that the node can obtain, including but not limited to the set of active nodes in the current communication area, the set of nodes in the historical discovery records, or a subset of IDs limited by network prefixes / regional identifiers.

[0100] 1. Candidate ID Space Pre-filtering Based on Inter-Node Information Distribution Within the cluster, nodes can exchange node information they maintain through inter-satellite links, power supply links, or ground backhaul networks, forming a distributed "node relationship table." The contents of the node relationship table include, but are not limited to: - List of node IDs currently serving / associated with each node - Individual DSF digest (or its hash value) for each node - Node's most recent discovery time and movement trajectory prediction - The coverage area of ​​the node (beam pointing, ephemeris, etc.) Taking a low-Earth orbit satellite constellation as an example: Satellites A, B, and C exchange node context information via inter-satellite links. Satellite A broadcasts a list of all node IDs it currently serves to its neighboring satellites (Satellites B and C). When a node moves from the coverage area of ​​Satellite A to the coverage area of ​​Satellite B, Satellite B has already pre-stored the node's ID and individual DSF summary in its local node relationship table.

[0101] Compression effect of candidate ID space: - No node relationship table: The satellite needs to traverse the entire candidate ID space (e.g., 10,000 active nodes in the region). - With a node relationship table: The satellite only needs to search a subset (e.g., 200) of nodes marked as "may enter this coverage area" in the node relationship table, and further narrow it down to dozens by combining physical layer characteristics (beam direction, time delay range). The update mechanism of the node relationship table: - Periodic switching: Synchronize once every `N_sync` logical ticks. - Event Trigger: When migration intention is detected, an immediate exchange is triggered. - Predictive push notifications: Based on ephemeris and node trajectory predictions, proactively push relevant information to potential target nodes. Security Guarantee: The node relationship table only contains the ID and DSF digest (hash value) of each node, and does not contain `K_sec_root` itself. Even if the relationship table is intercepted, the attacker will still be unable to derive a valid pilot signature.

[0102] 2. Optimization methods for ID space search computation The node relationship table can work in conjunction with the following four optimization methods: the relationship table provides a "whitelist" candidate set, hierarchical search further filters on the narrowed candidate set, and parallel acceleration completes the final verification. The specific optimization methods are as follows: Method 1 (Hierarchical Search): The ID space is hierarchically grouped according to network prefix or region identifier. Nodes first narrow down the candidate range based on the physical layer characteristics of the received signal (including but not limited to angle of arrival, propagation delay, and beam direction), and then only traverse and verify within the narrowed subset.

[0103] Method 2 (Parallel Computing Acceleration): Nodes utilize hardware parallel computing capabilities (including but not limited to GPUs, FPGAs, and SIMD instruction sets) to simultaneously perform pilot signature calculations and matching verifications on multiple candidate IDs. For cryptographic functions such as HMAC-SHA256, modern hardware can support hundreds to thousands of parallel computations. Under a typical configuration (candidate region containing 10^4 IDs, hardware parallelism of 1024 paths), the time taken for a single verification can be reduced from several seconds to milliseconds.

[0104] Method 3 (Multi-level Verification Filtering): When traversing the candidate ID space, the node first calculates a portion of the candidate pilot signature bits (e.g., the first 64 bits) for fast filtering and matching, and only performs full verification on partially matching candidate IDs. This strategy can reduce the computational load by 1-2 orders of magnitude without significantly reducing the verification accuracy.

[0105] Method 4 (Indexed based on historical data): Nodes maintain an index of historical discovery records, prioritizing searches of recently active ID space subsets. For long-term inactive ID subsets, the search priority is reduced.

[0106] The optimization method described above can reduce the computational cost of ID space search by more than an order of magnitude.

[0107] (ix) Rollback mechanism for migration failure If an exception occurs during the migration process, this invention provides the following rollback mechanism: Scenario 1: The target node rejects or does not respond. - If the target node (node ​​3) rejects the migration by declaring a rejection via a status field during the preparation phase before `n_establish` (e.g., insufficient resources), the migration initiating node (node ​​1) cancels the migration and continues to use the communication relationship with the source node (node ​​2). - If the target node (node ​​3) fails to complete preparation within the switching window corresponding to `n_establish` (timeout, typically `Δ_timeout` logical ticks), node 1 automatically rolls back—continuing to use the communication relationship with node 2, and re-evaluating the migration conditions at a subsequent announcement logical tick. The timeout detection mechanism is as follows: node 1 starts a timer at the physical tick corresponding to `n_establish`. If no acknowledgment signal from the target node is detected within `Δ_timeout` (by detecting the target node's announcement pilot or the activity of a new PSSM instance), a timeout is determined.

[0108] Scenario 2: Source node released prematurely during migration execution - If the source node (node ​​2) mistakenly releases the communication relationship before the start of the switching window corresponding to `n_establish`, and node 1 fails to successfully establish a communication relationship with the target node (node ​​3) within the switching window, then an emergency recovery is executed—an emergency declaration pilot is broadcast at the declaration logic moment (using the emergency-specific tag `"ANNOUNCE_SIG_EMERGENCY"`), requesting any available node to take over. The node that detects the emergency declaration responds according to its own resource status.

[0109] Scenario 3: Communication quality fails to meet standards after migration - After the migration is completed, Node 1 continuously measures the communication quality (RSRP, SINR, etc.) with the target node (Node 3). If the quality is consistently lower than the preset threshold (e.g., RSRP < -95dBm) within a preset time window (e.g., 50 logical ticks), a rollback migration is triggered. Node 1 re-evaluates the signal quality of neighboring nodes, selects a new target node (e.g., source node 2 or another node 4), and re-executes the migration process.

[0110] (x) Resource allocation and scalability at the declaration logic moment In this invention, all nodes broadcast the pilot signature at the declared logic time and coexist on the same time-frequency resources through code division multiplexing. Since each node's pilot signature is derived from a different individual DSF (the individual DSF is derived from the group DSF root key and its respective node ID), the pilot signatures are cryptographically orthogonal.

[0111] The orthogonal capacity is determined by the pilot sequence length: assuming a pilot sequence length of `L` bits, the orthogonal space is on the order of `2^L`. Under typical configurations (`L=64~128`), the orthogonal space far exceeds the actual number of deployed nodes, indicating that the orthogonal capacity at the declared logical moment does not constitute a system bottleneck.

[0112] To further optimize resource utilization, the announcement period `T_announce` is a configurable parameter. In scenarios with a small number of nodes, the announcement period can be shortened to improve discovery speed; in scenarios with a large number of nodes, the announcement period can be lengthened to reduce overhead. Nodes can also adopt a discontinuous announcement mode, actively broadcasting announcements only when a migration requirement is detected, further reducing resource consumption.

[0113] (xi) Synergy with distributed cluster solutions The migration method of this invention is based on the basic communication relationship of a distributed cluster scheme (application number 2026106207395). The distributed cluster scheme provides the basic capability of "how any two nodes that know each other's IDs can communicate with zero signaling" (based on individual DSFs, running on the main logical timeline). This invention adds a business-specific communication relationship layer (dedicated DSF instance + business-specific logical timeline) on this basis, and realizes the autonomous migration of business-specific communication relationships.

[0114] The relationship between the two is complementary, consisting of a "base layer + enhancement layer"—the distributed cluster solution addresses "how to achieve basic communication," while this invention addresses "how to carry services with differentiated QoS and achieve migration." Together, they constitute a complete DSF technology system.

[0115] (xii) Coordination with zero signaling access scheme This invention works in conjunction with the zero signaling access scheme (application number 2026110481706) to form a complete technical chain of "initial access → bearer establishment → communication relationship migration".

[0116] The zero-signaling access scheme provides the foundation for this invention: new nodes access the DSF network for the first time through the MsgA / MsgB process, obtain the group DSF root key `K_sec_root` and public DSF parameters, and complete the synchronization of the main logical time axis.

[0117] In public network scenarios, after obtaining public DSF parameters, the UE initiates an access procedure. The network authenticates the UE during this procedure (e.g., 5G AKA or an equivalent procedure). Upon successful authentication, the UE independently derives its individual DSF based on its own ID and the group DSF root key. The network independently derives the same individual DSF based on the UE's ID for basic communication with that UE. For UEs that fail authentication, their access procedure is terminated, they do not derive an individual DSF, and they cannot be added to the main logical timeline.

[0118] Based on this, the UE can choose one of the following methods to establish a service-specific communication relationship according to the deployment strategy: Method 1 (Based on Basic Communication Relationship): At the declaration logic time, the UE broadcasts a declaration pilot signature derived from its individual DSF. Other nodes detect this pilot signature through matched filtering, verify the UE's legitimacy, obtain its ID, derive its individual DSF, and establish a basic communication relationship. Subsequently, a service-specific DSF instance is established based on this (determining the dedicated K_sec, creating the dedicated DSF instance, and configuring its Rule_ID as a service-specific QoS parameter), and an independent service-specific PSSM instance and service-specific logical timeline are started. This method is suitable for scenarios requiring lightweight signaling interaction beforehand, or scenarios where there is no pre-existing trust relationship between nodes.

[0119] Method 2 (Direct Bearer Establishment): During or after the zero-signaling access procedure (MsgA / MsgB), the base station or core network directly obtains the UE's identity identifier (ID). Other nodes can obtain the UE's ID through information distribution from the base station / core network, directly derive its individual DSF, and configure a service-specific DSF instance for the UE (determine the dedicated K_sec, create the dedicated DSF instance and configure its Rule_ID as the service-specific QoS parameter) and a service-specific logical timeline, skipping the basic communication relationship establishment steps. This method is closer to the process in 5G where the core network directly configures the DRB (Data Radio Bearer) for the UE after random access. The process is simpler and more efficient, and it is suitable for public network deployment scenarios where the base station or core network participates in coordination.

[0120] The relationship between the two methods: Method 2 does not preclude establishing a basic communication relationship first, but this relationship is not mandatory. For scenarios involving a core network or base stations, Method 2 can directly establish service-specific communication relationships, avoiding additional announcement monitoring and matched filtering delays. For purely decentralized scenarios (no core network, no base stations), Method 1 can be used, enabling nodes to autonomously discover themselves and establish basic communication relationships through pilot announcements.

[0121] Key difference: The zero-signaling access solution addresses the problem of "how nodes obtain the group DSF root key and public DSF parameters and complete identity authentication"; this invention addresses the problem of "how to establish a migrateable service-specific communication relationship based on the already obtained DSF". When the two are combined, a complete process is formed from "initial access" to "bearer establishment" and then to "communication relationship migration".

[0122] Beneficial effects Compared with existing solutions, the present invention has the following advantages: I. Layered Design of Two-Layer Communication Relationship and Two-Level Logical Time Axis Basic communication relationships (based on individual DSFs, each holding an independent key and managing its own transmission direction) operate on the main logical timeline, resolving the "who are you?" identity verification problem. Service-specific communication relationships (based on independent DSF instances, whose Rule_ID is a service-specific QoS configuration) operate on independent service-specific logical timelines, resolving the "with what QoS" problem for transmitting service data. This two-layer decoupling enables autonomous intelligence and service diversity for nodes. The logical timelines of different service-specific communication relationships are independent of each other, do not interfere with each other, and each has its own independent clock cycle and QoS configuration.

[0123] Second, migration is essentially a pointer switch; service interruption depends only on the physical layer switching window. Traditional solutions involve "disconnecting and reconnecting," with interruption latency strongly correlated with RTT (810-1080ms in LEO scenarios, several seconds in GEO scenarios). The migration mechanism of this invention is essentially an atomic switch of the PSSM instance pointer—the new PSSM instance has already been created and is in an inactive state during the preparation phase; only the pointer is atomically swapped during migration execution. Interruption latency is determined by the physical layer switching window (50-200μs), independent of the business-specific logic cycle and RTT. Under typical configurations, the performance improvement reaches 1600-8600 times (LEO scenarios) to over 10000 times (GEO scenarios).

[0124] III. Zero Signaling – No signaling interaction throughout the entire migration process. This invention's migration process involves no RRC signaling: target discovery (matching filter, physical layer), migration decision (local autonomy), migration intention declaration (cryptographic tagging, physical layer), and atomic handover (triggered at logical moments). Traditionally, each migration involves a large amount of signaling interaction (kilobytes / time), including measurement reports, handover commands, and random access. This invention reduces signaling overhead from kilobytes / time to zero bytes / time, fundamentally eliminating the risk of signaling storms.

[0125] IV. Peer-to-peer architecture, any node can initiate migration. All nodes are completely peer-to-peer, and any node can initiate migration, supporting multi-directional migration (satellite→UE, UE→satellite, satellite→satellite, UE→UE, etc.). Node type does not determine the migration role; the migration direction is dynamically determined by the node's autonomous decision. This completely eliminates the fundamental asymmetry of "network dominance, terminal following" in traditional cellular networks.

[0126] V. Support for diversified sources of business-specific DSF The business-specific K_sec can flexibly choose from six sources depending on the deployment scenario: deterministic derivation for purely decentralized scenarios, core network distribution for core network compatible scenarios, business identifier derivation or multicast derivation for multicast scenarios, and active allocation or negotiation generation for flexible scenarios. This diversity allows the invention to be deployed in various scenarios such as public networks, private networks, and multicast.

[0127] VI. Time-sequence protection for public network authentication and individual DSF derivation In public network scenarios, the derivation of an individual DSF occurs after the UE completes authentication. The UE first obtains the publicly available DSF parameters and initiates the access procedure. The network side authenticates the UE during the access procedure, and only after successful authentication does the UE derive its individual DSF. This mechanism ensures the security premise that "only legitimate UEs can obtain individual DSFs and participate in communication" in public network scenarios.

[0128] VII. Business-specific communication relationships can be established independently of basic communication relationships. Service-specific DSF instances can be established directly based on deterministic derivation (Method 1) or issued by the core network (Method 3), without the need to establish basic communication relationships first. This flexibility allows UEs to establish service bearers immediately after authentication, reducing unnecessary intermediate steps and improving access efficiency.

[0129] 8. No GPS or high-precision clock synchronization required. The strict equality of the main logic timeline logic counters is guaranteed by a deterministic public PSSM, while the business-specific logic timeline is driven independently by a dedicated PSSM instance. Physical anchor points only need to be bounded and aligned (at the CP level, such as 2.34μs), without the need for nanosecond-level forced synchronization or GPS / 1588 timing devices.

[0130] 9. Supports overlay migration, superimposed migration, and batch migration. - Overlay migration: Release the communication relationship with the source node and establish a communication relationship with the target node (standard scenario). - Overlay migration: Maintains communication with the source node while establishing communication with the target node, forming multicast or parallel connections. - Batch migration: Simultaneously migrate multiple service-specific communication relationships during a single migration execution logic moment, while maintaining the QoS parameters of each service unchanged. The three modes cover a variety of scenarios, from simple to complex multicast.

[0131] 10. Breaking the Cell Concept: Upgrading from Terminal Handover to Peer-to-Peer Communication Relationship Migration. Existing communication systems' handover processes are always based on the physical concept of a "cell"—the UE is attached to a specific cell, the handover target is an adjacent cell, and handover execution requires random access (RACH) to be completed in the target cell. This invention fundamentally breaks this premise: the communication relationship is a deterministic association between two node IDs, rather than the terminal's attachment to a physical cell. The migration initiating node identifies the target node's node ID through matched filtering. Based on the established basic communication relationship (or after synchronous establishment), the overall transfer of the communication relationship is completed through atomic switching of the PSSM instance pointer. The entire process does not require initiating any random access procedure at the target node. This invention upgrades "handover" from "physical migration of the terminal between different cells" to "logical migration of the communication relationship between different peer nodes."

[0132] 11. The migration window acts as a natural set-based convergence window. During the migration preparation phase and the switching window, the migration initiating node maintains or establishes communication relationships with both the source and target nodes. The two dedicated DSFs operate independently and are orthogonal in the code domain. Both the source and target nodes can simultaneously send downlink data to the migration initiating node, and the migration initiating node can simultaneously send uplink data to both nodes, achieving bidirectional set-based convergence gain without requiring additional signaling coordination. This gain is a natural byproduct of the migration process, not an additional configured feature. Attached Figure Description

[0133] Figure 1 This is a schematic diagram of the two-layer communication relationship and two-level logical time axis architecture of the present invention, showing the hierarchical structure in which the basic communication relationship (individual DSF) runs on the main logical time axis, and the business-specific communication relationship (independent DSF instance and its Rule_ID configuration) runs on an independent business-specific logical time axis, as well as the relationship in which the initial anchor point of the business-specific logical time axis is anchored to the main logical time axis.

[0134] Figure 2 This is a schematic diagram of the system architecture of the present invention, showing the interaction relationship between the migration initiating node (node ​​1), the source node (node ​​2), and the target node (node ​​3) in the migration process, as well as the key moments on the logical timeline (`n_announce_migrate`, `n_establish`).

[0135] Figure 3 This is a schematic diagram of the migration decision process, showing the complete process from local measurement and trigger condition judgment to target node selection.

[0136] Figure 4The sequence diagram for migration intention declaration and target discovery shows the timing of sending and detecting migration intention pilot signals, as well as the interaction mechanism of target nodes responding to acceptance / rejection through the declaration status field.

[0137] Figure 5 This is an atomic switching timing diagram, showing the timing relationship between the `n_establish` trigger time, the switching window, and the first available logical time after the switching window ends, as well as the essence of the atomic switching of the PSSM instance pointer.

[0138] Figure 6 The flowchart for the migration failure rollback mechanism illustrates the decision paths for three rollback scenarios. Detailed Implementation

[0139] Example 1: Purely Decentralized Scenario – Migration of Service-Specific Communication Relationship between UE and Satellite (Deterministic Derivation) Scenario: A low-Earth orbit satellite constellation consists of multiple satellites, including satellite A (node ​​2) and satellite B (node ​​3). Each satellite shares the group DSF root key `K_sec_root` and common DSF parameters. The UE (node ​​1) has completed authentication and obtained `K_sec_root` and common DSF parameters through a zero-signaling access procedure. A basic communication relationship has been established with satellite A (node ​​2) (based on individual DSFs, running on the main logical timeline), and a dedicated communication relationship for URLLC services has also been established. The dedicated K_sec for this service-specific communication relationship is generated deterministically through `K_sec_1-2 = PRF(K_sec_root, ID_1 || ID_2 || "DEDICATED")`. The corresponding DSF instance's `Rule_ID` is configured with `T_step=0.125ms`, `N_PRB=1`, `N_symbol=14`, `Priority=1`, and `Frame_Mode=Full_Pilot`. This `Rule_ID` defines the clock cycle of the service-specific logical time axis. A basic communication relationship has been established between the UE and satellite B (Node 3) (they know each other's IDs and can derive each other's individual DSFs). The UE is moving towards the satellite B coverage area, with a radio frequency tuning time of approximately 80μs.

[0140] Step 1: Continuous local measurement The UE continuously performs the following measurements during normal communication: - Receive downlink pilot signal from satellite A, measured RSRP = -85dBm, SINR = 12dB - At the announcement logic times `n=1000, 1050, 1100, ...` (`T_announce=50` logic ticks, `T_step_common=0.5ms`, i.e., once every 25ms), the announcement pilot signatures of each satellite are received, and the RSRP of satellite B is measured to be -78dBm, and the SINR to be 16dB. The announcement pilot signatures of each satellite also carry status information: satellite A has a load of 70%, and satellite B has a load of 30%.

[0141] Step 2: Autonomous Migration Decision The UE's local decision-making logic is as follows (without relying on any instructions from the network side): - Triggering condition 1 (signal quality): Satellite B's RSRP (-78dBm) is more than 3dB better than Satellite A's (-85dBm) for 15 logic time intervals (7.5ms) → Satisfied - Triggering condition 2 (location prediction): Based on GNSS positioning and ephemeris prediction, the UE will leave the coverage area of ​​satellite A after 50 logical moments (25ms) → Satisfied - Triggering condition 3 (load status): Satellite B load 30% (lower than Satellite A's 70%) → Met - Decision result: Migration triggered, target node identified as satellite B. - The UE determines the execution time of the migration logic `n_establish=1200` (based on the business-specific logic time axis counter, after 50 logic ticks, i.e., after 6.25ms, `T_step=0.125ms`). - The UE confirmed that the handover window `Δ_switch=80μs` is much smaller than the service's tolerable interruption time (the service requires <1ms), making migration feasible. Step 3: Declaration of Relocation Intent The UE generates a migration intention pilot signal at the announcement logic time `n=1150` on the main logic timeline (satisfying `n_announce_migrate < n_establish`, corresponding to `1150 × 0.5ms = 575ms` on the main logic timeline): `P_migrate(1150) = PRF(K_sec_1, S(1150) || "ANNOUNCE_SIG_MIGRATE" ||ID_3 || 1200 || 1150)` The migration intention guide uses `ID_3` and `n_establish=1200` as derived parameters to carry the target node ID and migration execution time information.

[0142] Step 4: Preparation Phase - At the announcement logic time `n=1150`, Satellite B uses the migration intention matching filter template to detect the UE's migration intention pilot signal, confirms the target is itself (`ID_3` match) through PRF verification, and learns that `n_establish=1200`. During the preparation phase from `n=1150` to `n=1200` (corresponding to approximately 50 ticks, 6.25ms, on the service-specific logic timeline): - Derived specific K_sec: `K_sec_3-1 = PRF(K_sec_root, ID_3 || ID_1 || "DEDICATED")` - Create a complete DSF instance based on this dedicated K_sec, with its `Rule_ID` configured with the corresponding URLLCQoS parameters (`T_step=0.125ms`, `N_PRB=1`, `N_symbol=14`, `Priority=1`, `Frame_Mode=Full_Pilot`). - Create a corresponding PSSM instance (in an pending activation state). This PSSM instance will drive an independent business-specific logical timeline. - Reserve communication resources for the UE in the local resource calendar - Set the acceptance status flag in the announcement at logical time `n=1175` to confirm acceptance of the UE. Satellite A also detected the UE's migration intention pilot signal (target: Satellite B, execution time: 1200) at the declared logic time `n=1150`, and learned that the UE would trigger migration to Satellite B at `n=1200`. Satellite A prepared to release the communication relationship with the UE within the handover window.

[0143] Step 5: Atomic Switching – PSSM Instance Pointer Switching At the physical time corresponding to the business-specific logic timeline logical moment `n=1200` (corresponding to the physical time after the main logic timeline `1200 × 0.125ms = 150ms`), the UE triggers an atomic handover command and enters an 80μs handover window: - The UE disables the dedicated DSF instance `K_sec_1-2` (including its Rule_ID configuration) for satellite A, terminates the corresponding PSSM instance and its driver's service-specific logical timeline (disables the old pointer). - The UE activates the dedicated DSF instance `K_sec_1-3` (including its Rule_ID configuration) for satellite B, and activates the corresponding PSSM instance based on this dedicated DSF instance (enabling a new pointer), inheriting the URLLC dedicated RULE_ID (`T_step=0.125ms`, `N_PRB=1`, `N_symbol=14`, `Priority=1`, `Frame_Mode=Full_Pilot`), and starts an independent service-specific logical timeline, whose initial anchor point is anchored to the current logical moment of the main logical timeline. - Satellite B enables a dedicated DSF instance `K_sec_3-1` (including its Rule_ID configuration) for the UE, activates the corresponding PSSM instance, and starts an independent service-specific logical timeline. - Satellite A releases communication relationship with UE The above operations are completed within 80μs. There is no communication interruption window between the deactivation of the old pointer and the activation of the new pointer, nor is there an overlap period where the old and new pointers are used simultaneously.

[0144] During step 5, within the switching window (80μs), satellites A and B can simultaneously send downlink data to the UE. The UE uses two dedicated DSFs to demodulate and merge the data to achieve diversity gain. The UE can also simultaneously send uplink data to both satellites, which are received by each satellite and merged via inter-satellite links. This diversity effect is a natural byproduct of this migration process and does not increase signaling overhead.

[0145] Step 6: Migration Complete After the handover window ends, the UE will begin using the new communication relationship for data transmission and reception at the next available logical moment in the service-specific logical timeline. The UE updates the local communication relationship status: marking satellite A as "released" and satellite B as "current serving node".

[0146] Results: Migration interruption latency was 80μs. URLLC service QoS remained consistent before and after the migration (Rule_ID inheritance for dedicated DSF instances, and the tick period `T_step=0.125ms` of the service-specific logical time axis remained unchanged). No base station, LPC, or core network participated in decision-making or execution throughout the entire migration process. Service-specific K_sec was derived deterministically, requiring no external intervention.

[0147] Example 2: Purely Decentralized Scenario – Business-Specific DSFs are Actively Allocated by the Initiating Node Scenario: Drone A (Node 1) and Drone B (Node 2) have a dedicated communication relationship for video backhaul services (the dedicated K_sec is generated through deterministic derivation). Drone A needs to migrate this service to Drone C (Node 3), but wants to determine the new dedicated K_sec for the service itself (instead of deterministic derivation based on ID) to enhance the randomness and security of the key.

[0148] process: 1. Drone A and Drone C have established a basic communication relationship. 2. Drone A continuously measures the link quality with Drone B and detects a decline in signal quality (due to increased distance). Drone A, through surveillance, discovers that Drone C has better signal quality and autonomously decides to migrate, determining `n_establish`. 3. Drone A generates a new business-specific K_sec`K_sec_new` (a 256-bit random number generated by a cryptographically secure random number generator), creates a new DSF instance based on this key (configured with a corresponding exclusive Rule_ID), and securely informs Drone C through basic communication relationships (encrypted using individual DSF). 4. Drone A broadcasts a migration intention pilot signal at the declared logical time, carrying the hash value `K_sec_new` for verification. 5. During the preparation phase, drone C uses `K_sec_new` to create the corresponding DSF instance and PSSM instance (in an active state). This PSSM instance will drive an independent business-specific logical timeline, inheriting the original exclusive RULE_ID (parameters such as `T_step` and `N_PRB` remain unchanged). 6. Perform an atomic switch in `n_establish`. Effect: The business-specific K_sec is actively allocated by the initiating node, independent of deterministic ID derivation, providing greater flexibility and key randomness. Suitable for scenarios requiring enhanced security.

[0149] Example 3: Core Network Compatibility Scenario - Core Network Issues Dedicated DSF for Services Scenario: A UE maintains communication with satellite A through the 5G core network. The core network wants to control the generation and management of the service-specific K_sec. The service-specific K_sec between the UE and satellite A is generated by the core network AUSF and securely distributed via NAS signaling. The UE and satellite A each create a DSF instance based on this K_sec (configuring a corresponding dedicated Rule_ID). The UE autonomously decides to migrate to satellite B.

[0150] process: 1. The UE continuously measures the signal quality of satellite A and satellite B, autonomously decides to migrate to satellite B, and determines `n_establish`. 2. The UE broadcasts the migration intention pilot signal at the declared logical time, with the target being satellite B. 3. When the core network detects a migration event (reported via satellite A or indicated in the UE's declaration), it generates a new service-specific K_sec and sends it to the UE and satellite B via satellite A / satellite B (through a secure channel between the core network and the satellite). 4. Satellite B uses the K_sec allocated by the core network to create the corresponding DSF instance (configured with the corresponding exclusive Rule_ID) and PSSM instance (in a pending activation state). 5. Perform an atomic switch in `n_establish`. 6. After the migration is complete, the core network will update the data plane path from satellite A to satellite B. Results: Service-specific K_sec is centrally managed by the core network, compatible with existing 5G security architectures, and suitable for public network deployment scenarios. Services on the core network side are uninterrupted, with interruption latency equal to the handover window length (50-200μs).

[0151] Example 4: Multicast Scenario – Service-Specific DSF Derived from All Participating Nodes Scenario: Drone A (Node 1) needs to send the same control command (multicast) to Drone B (Node 2), Drone C (Node 3), and Drone D (Node 4) simultaneously. All participating nodes need to share the same set of dedicated K_sec for the business.

[0152] process: 1. Drone A has established basic communication relationships with drones B, C, and D. 2. Drone A determines the multicast key: `K_sec_group = PRF(K_sec_root, ID_A || ID_B || ID_C || ID_D || "MULTICAST")`, and creates a DSF instance based on this key (configuring the corresponding exclusive Rule_ID). 3. Drone A communicates its multicast key and unique RULE_ID (which defines QoS parameters such as `T_step` and `N_PRB` for multicast services) to B, C, and D via basic communication relationships. 4. B, C, and D each create corresponding DSF and PSSM instances based on their multicast keys (each driving an independent business-specific timeline, but sharing the same exclusive RULE_ID defined tick period), all of which are in an inactive state. 5. At the agreed-upon logical moment, A, B, C, and D simultaneously activate their respective PSSM instances and initiate their respective business-specific logical timelines. 6. Drone A sends data to B, C, and D (all nodes use the same `K_sec_group`). Effect: A single shared key serves multiple nodes, suitable for multicast / broadcast scenarios. The key is derived jointly from the IDs of all participating nodes, ensuring that only the specified node can calculate the correct key. Each node's business-specific logical timeline evolves independently, but they share the same clock cycle.

[0153] Example 5: Batch migration of multi-service dedicated communication relationships Scenario: The UE and satellite A have three service-specific communication relationships, each corresponding to an independent DSF instance and PSSM instance: URLLC control flow (`T_step=0.125ms`), eMBB data flow (`T_step=0.5ms`, `N_PRB=2`, `N_symbol=14`, Hybrid mode), and mMTC state flow (`T_step=10ms`, `N_PRB=1`, `N_symbol=1`). Each instance drives an independent service-specific logical timeline. The UE needs to migrate all three services to satellite C. Basic communication relationships have already been established between the UE and satellite C.

[0154] process: 1. The UE discovers through surveillance that the satellite C signal quality meets the migration conditions, autonomously decides to migrate, and determines `n_establish=3000`. 2. When announcing the logical time, the UE broadcasts the migration intention pilot, carrying a "batch migration" flag and a list of exclusive K_sec hash values ​​(or corresponding RULE_ID lists) for three PSSM instances. 3. During the preparation phase, satellite C assigns a dedicated K_sec to each of the three services (selecting either derived or received based on the scenario), and creates corresponding DSF instances (each configured with its own dedicated Rule_ID) and PSSM instances (both in an inactive state). 4. Within the `n_establish` handover window, the UE simultaneously releases three dedicated DSF instances with satellite A (terminating three service-specific logical timelines) and activates three dedicated DSF instances with satellite C (starting three new service-specific logical timelines). 5. All three services complete the migration within the same window, and the QoS rules for each service (including the tick cycle of each service's dedicated logical time axis) remain unchanged. Results: The latency for concurrent migration of multiple services is the same as that for a single service (within one switching window). The QoS parameters of each service are maintained independently.

[0155] Example 6: Preserving original connections after migration (overlay migration) Scenario: There is a control link between drone A and drone B (business-specific communication relationship 1, `T_step=0.5ms`). Drone A needs to simultaneously send the content of this link to drone C (formation control command issuance), requiring the addition of a new connection with C while retaining the original connection with B.

[0156] process: 1. Drone A discovers Drone C through surveillance, and the signal quality meets the conditions for establishing a connection. Drone A decides not to release its connection with B, but instead to establish a new connection with C, forming a multicast connection. Drone A determines `n_establish`. 2. Drone A broadcasts a migration intention pilot signal at the designated time, carrying an "additional mode" flag, indicating whether to retain the original connection or add a new connection during this migration, with the target being Drone C. 3. During the preparation phase, drone C creates a new DSF instance and PSSM instance (in an active state) based on the same dedicated K_sec (`K_sec_A-B`) as B, or derives a new dedicated K_sec. 4. In `n_establish`, drone A activates a new PSSM instance with C (starting a new business-specific logical timeline); the PSSM instance with B continues to run (the original business-specific logical timeline continues to evolve). 5. After the migration, drone A sends the same data to both B and C on two independent business-specific logical timelines, forming a multicast. Effect: Supports overlay migration—the original connection is not interrupted, and new connections are added, achieving a smooth expansion from unicast to multicast.

[0157] Example 7: Core Network Compatible Agent Cluster – Seamless Core Network Migration Scenario: UE (Node 1) maintains communication with satellite A (Node 2) through the 5G core network. Satellite B (Node 3) is the migration target. The core network communicates with the UE through satellite A, which serves as the core network's service anchor point. A basic communication relationship has been established between the UE and satellite B. The service-specific logic timeline runs between the UE and satellite A (`T_step=0.25ms`).

[0158] Before migration: Core network <──> Satellite A (anchor point) <──> UE (service-specific logical timeline runs between UE and Satellite A) Migration preparation phase: 1. The UE autonomously decides to migrate to satellite B, determining `n_establish`. 2. UE and Satellite B complete the preparation of service-specific communication relationship: Satellite B determines the dedicated K_sec (selecting derived or received according to the scenario), creates the corresponding DSF instance (configuring the corresponding dedicated Rule_ID) and PSSM instance (in a pending activation state), and this PSSM instance will drive an independent service-specific logical timeline. 3. Satellite A was unaware of the impending migration during this period and continued to relay data as the core network anchor point. Migration Execution Phase: During the handover window, the UE deactivates its DSF instance with satellite A (terminating the service-specific logical timeline) and activates its DSF instance with satellite B (starting a new service-specific logical timeline, with the initial anchor point set to the current main logical timeline). Satellite A continues to receive downlink data from the core network, but the DSF instance between satellite A and the UE is now deactivated. To ensure uninterrupted service, satellite A relays the received downlink data to satellite B via basic communication relay. Satellite B stores the data in its local cache and sends it to the UE after the handover window ends.

[0159] After migration is complete: 1. The UE begins communicating with satellite B, and satellite B takes over the UE's services. 2. After detecting that it has successfully taken over the service, Satellite B announces to the cluster that it has taken over the UE's service by announcing the status information. 3. After detecting this status information, satellite A stops forwarding data and releases the UE context. 4. The core network continues to communicate with the UE via satellite B (the core network path becomes: core network → satellite B → UE). 5. Core network-side perception is "the same UE switching between different satellites". Path switching is completed in the data plane, and the control plane does not need to be rebuilt. Results: Core network services remain uninterrupted during the migration process. Satellite A acts as a proxy anchor point to forward data during the migration, ensuring uplink / downlink data continuity. The core network does not need to be aware of the internal details of the migration; it only needs to update the data plane path after the migration is complete. The migration interruption latency remains the same as the switching window length (50-200μs).

[0160] The common feature of all the above embodiments is that the migration initiating node does not initiate any random access procedure on the target node during the migration execution process. The essence of the migration is an atomic switch of the PSSM instance pointer. The communication relationship is a deterministic association between two node IDs, rather than the attachment of the terminal to the physical cell. The identity identifier of the communication relationship (including exclusive K_sec, exclusive RULE_ID, and service-specific logical timeline status) remains unchanged before and after the migration.

[0161] Systems and Devices A network device (including but not limited to satellites, base stations, access points, and ground stations) implementing the method of the present invention includes a processor, a memory, a transceiver, and a network interface. The processor is configured to execute a program to implement the following functional modules: Local measurement module: configured to continuously measure the received signal quality (including RSRP, SINR, etc.) of the current source node on the first agent node side, and receive and measure the quality of the declaration pilot signature signal of other agent nodes at the declaration logic time, and demodulate the status information (load, available resources, etc.) from the declaration pilot signature.

[0162] Migration decision module: It is configured to determine whether the migration trigger conditions (signal quality threshold, location prediction, load status, etc.) are met based on the local measurement results and without relying on network side instructions. When the conditions are met, it will determine the target node and the migration execution logic time (based on the business-specific logic time axis counter).

[0163] Migration Declaration Module: Configured to generate and send a migration intention pilot using a migration-specific cryptographic tag at the declaration logic time. The migration intention pilot is generated using the target node ID and the migration execution logic time as derived parameters. The migration declaration module also supports carrying "bulk migration" and "additional mode" flags.

[0164] The communication relationship management module is configured to manage basic communication relationships (running on the main logical timeline) and business-specific communication relationships (running on independent business-specific logical timelines). An atomic switchover instruction is triggered at the physical time corresponding to the migration execution logic time, entering a switchover window. Within this window, the PSSM instance pointer with the source node is deactivated (terminating its driven business-specific logical timeline), and the PSSM instance pointer with the target node is activated (starting a new business-specific logical timeline, with the initial anchor point anchored to the current logical time of the main logical timeline). Each business-specific communication relationship corresponds to an independent DSF instance (containing a dedicated K_sec and a dedicated Rule_ID) and its driven business-specific logical timeline. The length of the switchover window is determined by the physical layer execution time and is independent of the business-specific logical timeline's tick cycle. Three migration modes are supported: overlay migration, superimposed migration, and batch migration.

[0165] ID space search optimization module (optional): Configured to narrow down the candidate range based on the physical layer characteristics of the received signal using a hierarchical search strategy when an unknown pilot signature is detected, and to complete the ID space search verification by combining at least one of hardware parallel computing acceleration and multi-level verification filtering. The ID space search optimization module is also configured to receive and maintain a node relationship table distributed between nodes, and to pre-filter the candidate ID space based on the node relationship table.

[0166] Rollback Management Module: Configured to perform a rollback operation when migration fails. Three rollback scenarios: Continue using the original communication relationship when the target node refuses or does not respond; Perform emergency recovery when the source node is released prematurely during migration; Trigger rollback migration or reselect the target node when the communication quality is substandard after migration.

[0167] The module division and functions on the user equipment (UE) side are consistent with those on the network equipment side, and it can participate in the migration process as a migration initiator, source node, or target node.

[0168] Industrial applicability This invention has clear industrial applicability and can be widely applied in the following scenarios: 1. Low Earth Orbit (LEO) Satellite Cluster: Autonomous inter-satellite migration for UEs, unaffected by RTT, with migration interruptions in the sub-millisecond range, suitable for user terminal handover in LEO satellite constellations. 2. Drone Swarm: Autonomous migration of swarm nodes (between drones and between drones and ground stations) in the absence of GPS / ground stations, suitable for military reconnaissance, coordinated strike, and other missions. 3. Robot Clusters: Distributed mobility management (between robots and between robots and servers) without centralized scheduling, suitable for smart manufacturing, warehousing and logistics scenarios. 4. Military Data Link: Autonomous migration in highly contested environments without relying on GPS (can be initiated by any node), characterized by low probability of interception. 5. Disaster Relief Network: Self-organized migration in the absence of infrastructure deployment, suitable for emergency communications after disasters such as earthquakes and floods. 6. Public 5G / 6G: As an enhancement or replacement for existing handover solutions, it reduces signaling overhead and eliminates RTT impact, and is suitable for operator network upgrades. The migration process of this invention is fully compatible with prior DSF series solutions (DSF basic, distributed cluster, zero signaling access, etc.) and can together form a complete DSF technology system.

[0169] Scope of Protection Statement The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. The functional modules, parameter values, communication protocols, and network architectures in the embodiments are merely specific examples provided to facilitate understanding of the technical solutions of the present invention.

[0170] Those skilled in the art, after reading this specification, can fully understand the invention without departing from its spirit and scope: - Various modifications, equivalent substitutions, and improvements can be made to the above embodiments; - Combine or separate the technical features in each embodiment; - Adjust specific parameters such as the period and offset of the declaration logic moment; - Employ different ID space search strategies and parallel computing methods; - Use different dedicated K_sec source methods; - Integrate the method described in this invention into different types of communication devices; - Adapt to different switching window lengths under different physical layer hardware capabilities.

[0171] The scope of protection of this invention is defined by the claims. The description and drawings are for interpreting the contents of the claims only and should not be construed as limiting the scope of protection of the claims in any way.

Claims

1. A method for autonomous migration of decentralized communication relationships in a distributed autonomous intelligent agent cluster, characterized in that, Includes the following steps: Local measurement steps: The first agent node continuously measures the quality of the received signal of the current source node, and receives and measures the quality of the announcement pilot signature signal of other agent nodes at the announcement logic time; Migration decision steps: Based on the local measurement results, the first intelligent agent node autonomously determines whether the migration triggering conditions are met without relying on network-side instructions. When the conditions are met, it autonomously determines the target node and the timing of the migration execution logic. Migration intention declaration step: The first agent node generates a migration intention pilot signal using a migration-specific cryptographic tag at the declaration logic time and sends it. The generation of the migration intention pilot signal uses the target node ID and the migration execution logic time as derived parameters. Target node preparation steps: After the target node detects the migration intention pilot, it completes the preparation work for establishing the service-specific communication relationship before the migration execution logic time, including determining the exclusive K_sec, creating a complete DSF instance based on the exclusive K_sec (its Rule_ID field is configured with the corresponding service-specific QoS parameters), and creating the corresponding PSSM instance. The created PSSM instance is in an inactive state, and the PSSM instance will drive an independent service-specific logical timeline. Atomic switching steps: At the physical time corresponding to the migration execution logic time, the first agent node triggers an atomic switching instruction, enters a switching window, deactivates the PSSM instance pointer with the source node, activates the PSSM instance pointer with the target node, and completes the release of the old communication relationship and the establishment of the new communication relationship. The length of the switching window is determined by the physical layer execution time and is independent of the business-specific logic tick cycle. After the switching window ends, the first agent node begins to use the new communication relationship for data transmission and reception at the next available logic time of the business-specific logic timeline.

2. The method according to claim 1, characterized in that, The first intelligent agent node, the source node, and the target node are intelligent agent nodes of any type in a distributed autonomous intelligent agent cluster, including but not limited to satellites, user equipment (UE), drones, ground stations, and robots; the first intelligent agent node and the target node have equal status, and the node type does not determine the migration role of the node.

3. The method according to claim 1, characterized in that, If the first agent node and the target node have not yet established a basic communication relationship, the basic communication relationship is established by detecting the target node's declared pilot signature through matched filtering before proceeding with subsequent steps; if the basic communication relationship has been established, the subsequent steps are executed directly; the basic communication relationship is established based on individual DSFs, and two independent individual DSFs are maintained between the two nodes for transmission in two directions respectively, and the basic communication relationship runs on the main logic timeline.

4. The method according to claim 3, characterized in that, The K_sec of the individual DSF in the basic communication relationship is derived from the group DSF root key and node ID: K_sec_node = PRF(K_sec_root, ID || "NODE").

5. The method according to claim 1, characterized in that, The service-specific communication relationship includes: an identity element—a dedicated K_sec, which is a shared key derived from a specific service communication relationship. The Rule_ID field of the DSF instance where the dedicated K_sec resides is configured with a service-specific QoS parameter; and a timing element—a service-specific logical time axis state. This time axis is driven by the PSSM instance driven by the DSF instance. Its initial anchor point is anchored to a specific logical moment of the main logical time axis, and then it evolves independently. The logical tick period is defined by the `T_step` parameter in the Rule_ID of the DSF instance.

6. The method according to claim 5, characterized in that, The source of the dedicated K_sec includes at least one of the following methods: Method 1 (Deterministic Derivation): Derivation is performed using cryptographic functions based on the group DSF root key and the IDs of participating nodes; Method 2 (Active Allocation): Generated by the migration initiating node or any node in the network and securely distributed to other participating nodes through basic communication relationships; Method 3 (Core Network Distribution): In deployment scenarios compatible with the core network, the core network securely generates and distributes the distribution. Method 4 (Negotiation Generation): Participating nodes jointly determine the method after exchanging information through basic communication relationships; Method 5 (Business Identifier Derivation): Derived based on business type identifier, independent of node ID, suitable for multicast or broadcast scenarios; Method 6 (Multicast Derivation): Based on joint derivation of all participating node IDs, suitable for multi-node shared key scenarios.

7. The method according to claim 5, characterized in that, The Rule_ID of the DSF instance contains at least one of the following parameters: logical tick period `T_step`, number of resource units `N_PRB`, number of symbols `N_symbol`, priority `Priority`, frame mode `Frame_Mode`, and pilot ratio `Pilot_Ratio`.

8. The method according to claim 1, characterized in that, The migration intention pilot is generated in the following way: `P_migrate(n) = PRF(K_sec_node, S(n) || "ANNOUNCE_SIG_MIGRATE" || ID_target || n_establish || n)` Where `PRF` is a cryptographic pseudo-random function, `K_sec_node` is the individual DSF of the first agent node, `S(n)` is the current logical state, `n` is the current logical counter value, `"ANNOUNCE_SIG_MIGRATE"` is a cryptographic label for migration, `ID_target` is the target node ID, `n_establish` is the migration execution logic time, and the ordinary declaration label `"ANNOUNCE_SIG"` is different from the migration-specific label.

9. The method according to claim 1, characterized in that, The determination of the target node includes the following sub-steps: The first agent node detects the main announcement pilot through matched filtering at the announcement logic time. The main announcement pilot is generated in the following way: P_announce(n) = PRF(K_sec_public, S(n) || "ANNOUNCE_SIG" || n) Where PRF is a cryptographic pseudo-random function, K_sec_public is a public DSF parameter, S(n) is the current main logic timeline logic state, n is the current main logic timeline logic counter value, and "ANNOUNCE_SIG" is a tag for declaring cryptographic purposes. After the matched filter detects the main announcement pilot, the first agent node parses the corresponding node ID from the data part of the announcement message and verifies its legitimacy using the group DSF root key; The first intelligent agent node selects the target node from the detected nodes based on the signal quality measurement results.

10. The method according to claim 1, characterized in that, The migration triggering conditions include at least one of the following: The signal quality of the target node is consistently better than the signal quality of the source node by a preset threshold. The first agent node is predicted to be about to leave the coverage area of ​​the source node; The source node declares its load status as overloaded, while the target node declares its load status as normal.

11. The method according to claim 1, characterized in that, In the atomic switching step: Establishing a new communication relationship includes: the first agent node activates the corresponding PSSM instance based on a dedicated K_sec within the switching window. The Rule_ID in the DSF instance corresponding to the PSSM instance is a service-specific configuration. An independent service-specific logical timeline is started, with its initial anchor point anchored to the current logical moment of the main logical timeline. Releasing old communication relationships includes: the first agent node deactivating its dedicated DSF instance with the source node within the switching window, terminating the corresponding PSSM instance and its driven business-specific logic timeline; Within the switching window, there is no communication interruption window between the deactivation of the old PSSM instance pointer and the activation of the new PSSM instance pointer; The synchronous execution of the atomic switching is based on a two-level synchronization mechanism: the main logic time axis logic counters are strictly equal across nodes, guaranteed by a deterministic protocol state machine; the physical anchors are bounded and aligned across nodes, with the deviation not exceeding the OFDM cyclic prefix length.

12. The method according to claim 1, characterized in that, In the target node preparation step, when multiple initiating nodes simultaneously initiate migration to the same target node, the target node performs distributed conflict resolution, including: Requests are sorted according to priority information implied in each migration intention guide or indicated by node declaration status information, with higher priority requests being accepted first. The maximum number of concurrent migrations that can be accepted is determined based on the currently available resources. If the maximum is exceeded, a delay indication is sent to the unaccepted requests. The initiating node that receives the delay indication will re-initiate the migration intention after a deterministic backoff period determined based on the node ID and the current logical counter value.

13. The method according to claim 1, characterized in that, The first intelligent agent node supports maintaining multiple business-specific communication relationships simultaneously. Each business-specific communication relationship corresponds to an independent dedicated K_sec, an independent business-specific logical timeline, and an independent PSSM instance. In the atomic switching step, the first agent node may choose one of the following methods to perform the migration: Method 1 (Overlay Migration): Release the communication relationship with the source node and establish a communication relationship with the target node; Method 2 (Overlay Migration): Maintain the communication relationship with the source node, and establish a communication relationship with the target node at the same time.

14. The method according to claim 13, characterized in that, The first intelligent agent node supports batch migration: during a single migration execution logic moment, multiple business-specific communication relationships are simultaneously migrated from the source node to the target node, and the service quality parameters of each communication relationship and the time axis cycle of their respective business-specific logic remain unchanged before and after the migration.

15. The method according to claim 1, characterized in that, It also includes computational optimization steps for ID space search: When the first agent node detects an unknown pilot signature that cannot be matched by a known candidate pilot signature, it uses the group DSF root key to search the candidate ID space. The candidate ID space is pre-filtered based on the node relationship table distributed between nodes; The search employs at least one of the following optimization methods: hierarchical search, parallel computing acceleration, multi-level verification filtering, and indexing based on historical data.

16. The method according to claim 1, characterized in that, It also includes steps for rolling back from migration failures: If the target node fails to complete preparation or refuses migration within the switching window corresponding to the migration execution logic time, the first agent node continues to use the communication relationship with the source node and re-evaluates the migration conditions at a subsequent announcement logic time. If the first agent node detects that the communication quality with the target node is consistently lower than a preset threshold after the migration is completed, it triggers a rollback migration or a reselection of the target node.

17. The method according to claim 1, characterized in that, The migration execution logic time is a future logic time on the business-specific logic timeline. Each node determines the local physical execution time of this time based on its own independently running business-specific PSSM instance. There is no binding relationship between the length of the switching window and the business-specific logic tick cycle.

18. The method according to claim 1, characterized in that, In a scenario where the intelligent agent cluster is deployed in a way that is compatible with the core network, the first intelligent agent node maintains communication with the source node through the core network, and the source node is the service anchor point of the core network; Within the switching window corresponding to the migration execution logic moment, the source node forwards the received downlink data to the target node through the basic communication relationship relay, which is then cached by the target node and sent to the first agent node after the switching window ends; after the migration is completed, the core network side updates the data plane path from the source node to the target node.

19. A decentralized communication relationship autonomous migration system in a distributed autonomous intelligent agent cluster, characterized in that, include: Multiple intelligent agent nodes, each node shares the group DSF root key and public DSF parameters, independently runs the protocol security state machine, and the main logic time axis logic counter is strictly equal among all nodes; Each agent node includes: The local measurement module is configured to continuously measure the received signal quality of the current source node, and to receive and measure the quality of the announcement pilot signature signals of other nodes at the announcement logic time. The migration decision module is configured to determine the migration triggering conditions, target node, and migration execution logic timing based on the local measurement results, without relying on network-side instructions. The migration announcement module is configured to generate and send a migration intention pilot signal using a migration-specific cryptographic tag at the announcement logic time. The migration intention pilot signal is generated using the target node ID and the migration execution logic time as derived parameters. The communication relationship management module is configured to manage basic communication relationships (running on the main logic timeline) and business-specific communication relationships (running on an independent business-specific logic timeline). It triggers an atomic switch command at the physical time corresponding to the migration execution logic time, enters a switch window, and disables the PSSM instance pointer with the source node and activates the PSSM instance pointer with the target node within the switch window. The business-specific communication relationship is an independent DSF instance and its driven business-specific logic timeline. The length of the switch window is determined by the physical layer execution time and is independent of the business-specific logic tick cycle. It supports three modes: overlay migration, superimposed migration, and batch migration. The rollback management module is configured to perform a rollback operation when migration fails.

20. The system according to claim 19, characterized in that, The intelligent agent nodes can be any of the following types: satellite, user equipment (UE), drone, ground station, or robot; the intelligent agent nodes have equal status, and any node can act as a migration initiator or a migration target.

21. The method according to claim 1, characterized in that, In the atomic handover step, the first agent node activates the PSSM instance with the target node at the migration execution logic time. The activation does not involve any random access procedure or physical cell attachment procedure. After the migration is completed, the identity identifier of the communication relationship remains unchanged.

Images