Defensive Disclosure for US Patent 9,769,776

Title: Apparatus and method for uplink synchronizing in multiple component carrier system
Publication Date: May 14, 2026
Authored by: Senior Patent Strategist and Research Engineer

This document discloses novel variations, applications, and enhancements to the methods described in US patent 9,769,776. The purpose of this disclosure is to establish prior art for subsequent inventions that may be considered obvious incremental improvements upon the original patent's claims. The core inventive concept of the reference patent is a structured message format and sequential process for reconfiguring Secondary Serving Cells (SCells) and their associated Timing Advance Groups (TAGs) in a User Equipment (UE), specifically by performing SCell removal before SCell addition.

---

Derivative Set 1: Component and Material Substitution

1.1. Reconfigurable RRC Processor using FPGA

• Enabling Description: The Radio Resource Control (RRC) processing unit, responsible for parsing SCell configuration information and executing TAG reorganization, is implemented on a Field-Programmable Gate Array (FPGA) instead of a conventional Application-Specific Integrated Circuit (ASIC) or CPU. The RRC Connection Reconfiguration message parser is synthesized as a hardware logic block on the FPGA. Upon a system update, a new bitstream can be loaded onto the FPGA to support new or modified RRC message formats, such as messages with additional fields for 5G-Advanced or 6G features (e.g., integrated sensing or AI model identifiers). This implementation uses a Xilinx Zynq UltraScale+ RFSoC, where the RRC logic resides in the Programmable Logic (PL) section, directly interfacing with the RF data converters for low-latency response. The processing sequence remains: 1) The receiving unit passes the raw RRC PDU to the FPGA. 2) The FPGA's parser logic identifies and separates the sCellToReleaseList and sCellToAddModList. 3) A state machine implemented in hardware logic first processes the release list, de-configuring the specified SCells. 4) Upon completion, the state machine processes the add/modify list, configuring new SCells and updating TAG mappings.
• Mermaid Diagram:

  graph TD
      A[Receiving Unit captures RRC PDU] --> B{FPGA-based RRC Processor};
      B --> C[Hardware Parser];
      C -->|sCellToReleaseList| D[State Machine: De-config SCells];
      C -->|sCellToAddModList| E[State Machine: Add/Mod SCells];
      D --> F[De-config Complete Signal];
      F --> E;
      E --> G[Update TAG Mappings];
      G --> H[Send RRC Reconfig Complete];
  

1.2. Software-Defined Radio (SDR) Front-End for Dynamic Reception

• Enabling Description: The receiving unit is implemented as a Software-Defined Radio (SDR) front-end, utilizing a general-purpose processor (GPP) or GPU for baseband processing. The physical layer (PHY) control software dynamically allocates processing resources for decoding the Physical Downlink Control Channel (PDCCH) and Physical Downlink Shared Channel (PDSCH) carrying the RRC message. If the RRC message indicates a complex reconfiguration (e.g., releasing multiple SCells and adding multiple new SCells across different frequency bands), the SDR scheduler preemptively allocates more computational resources (e.g., additional GPU cores) to ensure the message is decoded within the stringent time limits required by the 3GPP standards, thus preventing a handover failure caused by processing delays. This is achieved by having the MAC layer provide a hint to the PHY control software about the anticipated complexity of the next RRC message based on prior signaling.
• Mermaid Diagram:

  sequenceDiagram
      participant eNB
      participant UE_SDR_PHY as SDR PHY
      participant UE_RRC as RRC Processor
  
      eNB->>UE_SDR_PHY: Transmits RRC Reconfiguration Msg
      activate UE_SDR_PHY
      Note right of UE_SDR_PHY: MAC layer provides complexity hint
      UE_SDR_PHY->>UE_SDR_PHY: Allocate extra GPU cores
      UE_SDR_PHY->>UE_RRC: Pass decoded RRC message
      deactivate UE_SDR_PHY
      activate UE_RRC
      UE_RRC->>UE_RRC: Perform Remove-Then-Add & Reorganize TAG
      UE_RRC-->>eNB: RRC Reconfiguration Complete
      deactivate UE_RRC
  

---

Derivative Set 2: Operational Parameter Expansion

2.1. Nanoscale Application: Intra-Chip Clock Domain Synchronization

• Enabling Description: The patented method is scaled down to manage data path synchronization between clock domains within a multi-core System-on-a-Chip (SoC). The "UE" is a master processing core. The "eNB" is a central power and clock management unit (PCMU). The "SCells" are other functional blocks (e.g., GPU, NPU, memory controller) operating in different, asynchronous clock domains. A "TAG" is a group of blocks that are phase-aligned to a common reference clock for high-speed data transfer. When the PCMU needs to reconfigure the data bus—for instance, to put the GPU into a deep sleep state and reroute its data path to an NPU—it sends a configuration command over an internal control bus. This command contains a releaseList (e.g., GPU data path) and an addList (e.g., NPU data path). The master core's bus interface unit (the "RRC processor") first executes the release command, disabling the clock and data lines to the GPU, before executing the add command to enable the path to the NPU. This prevents bus contention and ensures a glitch-free transition.
• Mermaid Diagram:

  stateDiagram-v2
      [*] --> Active_GPU_Path
      Active_GPU_Path: Data flows to GPU
      Active_GPU_Path --> Reconfiguring: PCMU sends reconfig command
      Reconfiguring: Rcv: {release: GPU, add: NPU}
      Reconfiguring --> GPU_Path_Released: Step 1: Execute release(GPU)
      GPU_Path_Released: GPU data/clock lines tristated
      GPU_Path_Released --> Active_NPU_Path: Step 2: Execute add(NPU)
      Active_NPU_Path: Data flows to NPU
      Active_NPU_Path --> [*]
  

2.2. Extreme Mobility: Predictive Pipelined Reconfiguration

• Enabling Description: For a UE in a high-velocity environment (e.g., a satellite or hypersonic vehicle), the rate of cell handover is extreme. The UE's RRC processor is enhanced with a Kalman filter-based trajectory predictor that uses GPS and inertial measurement unit (IMU) data. The eNB provides a list of future candidate SCells along the predicted path. The UE's RRC processor pipelines the reconfiguration process. As it executes the remove-then-add operation for the current handover (H), it concurrently pre-parses and prepares the reconfiguration instructions for the next handover (H+1). The memory is partitioned to hold the current active SCell state and a shadow "next state" configuration. This reduces the reconfiguration latency from milliseconds to microseconds, as the processing for the next state is largely complete before the trigger is even received.
• Mermaid Diagram:

  graph TD
      subgraph Time T
          A[Receive Reconfig for H_n] --> B[Execute Remove-Then-Add for H_n];
      end
      subgraph Time T+1
          C[Receive Reconfig for H_n+1] --> D[Execute Remove-Then-Add for H_n+1];
      end
      subgraph "Predictive Pipeline"
          P1[Predict Trajectory --> H_n+2]
          P2[Receive Candidate SCells for H_n+2]
          P3[Pre-parse and Prepare Reconfig for H_n+2]
      end
      B --> P1;
      P1 & P2 --> P3;
      C --> P3;
  

---

Derivative Set 3: Cross-Domain Application

3.1. Aerospace: LEO Satellite Constellation Handovers

• Enabling Description: A Low-Earth Orbit (LEO) satellite is treated as a UE, and ground stations are its serving cells. A "TAG" is a group of ground stations within a geographical region that can be served using the same uplink timing advance, compensating for the satellite's movement. As the satellite traverses its orbit, the network's central controller (the "eNB") sends a "Ground Station Reconfiguration" message. This message contains a releaseList for stations it is moving out of range from, and an addList for stations coming into view. The satellite's communication processor executes the release commands first, terminating links to the receding stations, and then establishes links with the new stations. This ordered process is critical to manage the satellite's limited number of simultaneous communication channels and prevent service interruptions.
• Mermaid Diagram:

  sequenceDiagram
      participant Controller as Ground Control (eNB)
      participant LeoSat as LEO Satellite (UE)
      participant GS_A as Ground Station A (SCell)
      participant GS_B as Ground Station B (SCell)
  
      Note over LeoSat, GS_A: Active Communication
      Controller->>LeoSat: Reconfig Msg {release: [GS_A], add: [GS_B]}
      activate LeoSat
      LeoSat->>GS_A: Terminate Link
      LeoSat->>Controller: Ack Release
      LeoSat->>GS_B: Initiate Link
      LeoSat->>Controller: Ack Add
      deactivate LeoSat
      Note over LeoSat, GS_B: Active Communication
  

3.2. AgTech: Drone Swarm Communication Topology Management

• Enabling Description: In a swarm of autonomous agricultural drones, one drone acts as a local cluster head (the "eNB") managing a sub-group of worker drones (the "UEs"). The "SCells" are peer-to-peer communication links to other drones within the cluster. A "TAG" represents a tightly-coupled task group requiring synchronized movements (e.g., a line of drones for crop spraying). When the swarm formation must change, the cluster head sends a "Topology Reconfiguration" command to a worker drone. The command specifies links to release and links to add. The drone's flight controller first severs communication with the designated peer(s), then establishes new links. This ensures that the decentralized control algorithms operating across the swarm do not receive conflicting or unstable topology information during reconfiguration.
• Mermaid Diagram:

  graph LR
      subgraph "Initial Formation (TAG1)"
          D1---D2
          D2---D3
      end
      subgraph "New Formation (TAG2)"
          D2---D4
          D2---D5
      end
      Head[Cluster Head] -- Reconfig {release:[D1,D3], add:[D4,D5]} --> D2
      D2 -- Step 1: Release Link --> D1
      D2 -- Step 1: Release Link --> D3
      D2 -- Step 2: Add Link --> D4
      D2 -- Step 2: Add Link --> D5
  

---

Derivative Set 4: Integration with Emerging Technology

4.1. AI-Driven Predictive SCell Selection

• Enabling Description: The UE's RRC processor is coupled with an onboard AI inference engine (e.g., a Google Edge TPU). The eNB transmits an RRC message that includes the standard sCellToReleaseList and a list of candidate SCells for the sCellToAddModList, each with associated metadata (e.g., predicted load, beam quality). The UE's AI model, trained on its own historical mobility and cell performance data, selects the optimal SCell(s) from the candidate list. It then constructs the final sCellToAddModList and performs the remove-then-add operation. The UE's final choice and the resulting performance are recorded in a transaction on a private blockchain, providing an immutable record for network-wide optimization and auditing.
• Mermaid Diagram:

  flowchart TD
      A[eNB sends {release:[...], candidates:[SCell_X, SCell_Y]}] --> B[UE RRC Receiver];
      B --> C{AI Inference Engine};
      C -- "Select best candidate based on local context" --> D[Decision: Choose SCell_Y];
      B --> E[RRC Processor];
      D --> E;
      E --> F[Step 1: Execute release list];
      F --> G[Step 2: Execute add(SCell_Y)];
      G --> H[Log choice & performance to Blockchain];
  

4.2. Blockchain for Immutable Handover State Verification

• Enabling Description: Every UE and eNB participating in the network is a node in a private, permissioned blockchain. When an eNB sends an RRC Connection Reconfiguration message, it logs a hash of the message as a pending transaction. Upon successful completion of the remove-then-add procedure, the UE sends its RRC Connection Reconfiguration Complete message and simultaneously signs the transaction on the blockchain. This creates an immutable, verifiable, and time-stamped record of every SCell and TAG change for every device on the network. This is used for automated fault detection (e.g., identifying when a UE fails to confirm a reconfiguration) and for enforcing dynamic spectrum sharing agreements between operators.
• Mermaid Diagram:

  sequenceDiagram
      participant eNB
      participant UE
      participant Blockchain
  
      eNB->>UE: RRC Reconfig Msg
      eNB->>Blockchain: Propose Tx (Hash of Msg)
      activate UE
      UE->>UE: Perform Remove-Then-Add
      UE->>eNB: RRC Reconfig Complete
      UE->>Blockchain: Sign & Confirm Tx
      deactivate UE
      Blockchain->>Blockchain: Add Block (Confirmed State Change)
  

---

Derivative Set 5: Inverse and Failure Modes

5.1. Atomic Reconfiguration with Rollback

• Enabling Description: The TAG reorganization process is treated as an atomic transaction. Before executing the sCellToReleaseList, the RRC processor stores the current SCell/TAG configuration in a temporary memory buffer. It then proceeds with the removal. If, during the subsequent sCellToAddModList processing, it encounters a critical failure (e.g., the UE hardware cannot tune to the specified frequency of the new SCell), it aborts the "add" step. It then executes a rollback procedure, restoring the SCell configuration from the temporary buffer (re-adding the just-released cells) to return to the last known stable state. It then sends an RRC Reconfiguration Failure message to the eNB detailing the reason for the rollback, preventing a radio link failure.
• Mermaid Diagram:

  graph TD
      A[Start Reconfiguration] --> B[Store Current State in Buffer];
      B --> C[Process sCellToReleaseList];
      C --> D{Process sCellToAddModList};
      D -- Success --> E[Commit New State];
      D -- Failure --> F[Abort and Rollback];
      F --> G[Restore State from Buffer];
      G --> H[Send Reconfig Failure Msg];
      E --> I[Send Reconfig Complete Msg];
  

5.2. Low-Power Batched Reconfiguration

• Enabling Description: For an energy-constrained device (e.g., an IoT sensor), the RRC processor operates in a "Batched Update" mode. It can receive and buffer several RRC Connection Reconfiguration messages over a period of time without acting on them, remaining in a low-power idle state. The processor aggregates the messages, consolidating all sCellToReleaseList and sCellToAddModList fields into a single, cumulative list. For example, if SCell-A is released in message 1 and added back in message 2, it is netted out of the final operation. The device executes this single, consolidated remove-then-add operation during a scheduled "awake" window, minimizing active processing and radio time.
• Mermaid Diagram:

  flowchart LR
      subgraph "Buffering Period"
          M1[Rcv Msg1 {rel:[A], add:[B]}] --> Buffer
          M2[Rcv Msg2 {rel:[C], add:[A]}] --> Buffer
          M3[Rcv Msg3 {rel:[B], add:[D]}] --> Buffer
      end
      Buffer --> Consolidate{Consolidate Operations};
      Consolidate -- "Net Result" --> Final[Final Op {rel:[C], add:[D]}];
      subgraph "Awake Window"
          Trigger --> Execute[Execute Final Op];
      end
      Final --> Execute
  

---

Combination Prior Art with Open Standards

1. Combination with O-RAN E2 Interface: The logic of crafting the RRC message with sCellToReleaseList and sCellToAddModList is implemented as a "TAG Management xApp" on an O-RAN Near-Real-Time RIC. The xApp subscribes to UE metrics (e.g., RSRP, RSRQ) and location information via the E2 interface from multiple E2 Nodes (gNBs/eNBs). Based on O-RAN Alliance-defined policies from the Non-RT RIC, the xApp makes a handover decision and sends a "TAG Control" message over the E2 interface to the relevant eNB. The eNB's E2 agent then translates this control message into the specific RRC Connection Reconfiguration PDU format to be sent to the UE. This combines the patent's specific method with the open, intelligent, and disaggregated control architecture of O-RAN.

2. Combination with MQTT for IoT Networks: In a massive IoT deployment using cellular technology, the RRC Connection Reconfiguration message is encapsulated as the payload of an MQTT message. The network's core acts as the MQTT Broker. A UE (IoT device) subscribes to a device-specific configuration topic (e.g., devices/1234/cellular/config). When the network needs to reassign the device to a different set of cells, it publishes the encapsulated RRC message to that topic. This allows the management of cellular connectivity parameters using a standard, lightweight, and scalable publish/subscribe protocol common in the IoT industry.

3. Combination with ETSI MEC (Multi-access Edge Computing): A "Connectivity Management" MEC application, running at the network edge, takes over the SCell/TAG management for UEs engaged in ultra-low-latency applications (e.g., AR/VR, robotics). The MEC application uses the ETSI MEC RadioNetworkInformation API to receive real-time radio data for the UE. When it determines a handover is needed, instead of the core network making the decision, the MEC app directly instructs the local eNB to send the required RRC Connection Reconfiguration message (containing the remove/add lists) to the UE. This decentralizes the handover logic to the edge, significantly reducing latency and combining the patent's method with standardized edge computing APIs.