How to Use Domain Proxy (DP) for Multiple CBSDs

This guide explains how to use a Domain Proxy (DP) to manage multiple CBSDs efficiently with a single SAS connection, as supported in WINNF-TS-0016.

Overview

A Domain Proxy acts as an intermediary:

• Aggregates messages from many CBSDs
• Presents a single, secure interface to the SAS
• Simplifies fleet management, reduces connections, and isolates errors

Key Bridge SAS Support:

We fully support DPs. Use for 10+ CBSDs to reduce overhead and improve reliability.

Key Bridge SAS Note:

While the protocol imposes no limit on array size, the Key Bridge SAS enforces a hard limit of 512 entries per message (a proprietary restriction). We recommend that Domain Proxies restrict batches to approximately 100 devices per message, as our observations indicate that many DPs begin to experience processing delays beyond this threshold, with several becoming unstable above 256 entries.

Benefits

• Fewer TLS connections to SAS
• Batch requests/responses
• Centralized logging/error handling
• Easier certificate management (one DP cert)
• CBSDs can be simple (no direct SAS logic)

Architecture

Multiple CBSDs → Domain Proxy → SAS
               ←             ←

DP handles:

• Registration, inquiry, grant, heartbeat for all CBSDs
• Mapping responses back to individual CBSDs

Step 1: Implement DP as SAS Client

• Single TLS client certificate for DP
• Maintain per-CBSD state (cbsdId, grants, timers)

Step 2: Batch Messages

All protocol messages support arrays:

Example: Batch Registration for 3 CBSDs

{
  "registrationRequest": [
    { /* CBSD 1 params */ },
    { /* CBSD 2 params */ },
    { /* CBSD 3 params */ }
  ]
}

Response: Array in same order

{
  "registrationResponse": [
    { "cbsdId": "DP/CBSD-001", "response": { "responseCode": 0 } },
    { "cbsdId": "DP/CBSD-002", "response": { "responseCode": 0 } },
    { "response": { "responseCode": 103 } }  // Error for CBSD 3
  ]
}

Tip: Mix message types NOT allowed — one type per request.

Step 3: Manage Per-CBSD Heartbeats

• DP runs independent timer per grant
• Batch heartbeats when possible (≤100 recommended)
• Handle individual suspend/terminate

Example: Batch Heartbeat for Multiple Grants

{
  "heartbeatRequest": [
    { "cbsdId": "DP/CBSD-001", "grantId": "GRANT-789", ... },
    { "cbsdId": "DP/CBSD-002", "grantId": "GRANT-790", ... }
  ]
}

Step 4: Error Isolation

• One CBSD error doesn't affect others
• Retry failed items individually

Best Practices & Tips

• Start DP with 10-50 CBSDs; scale to thousands
• Use unique userId per customer/operator
• Include grouping across CBSDs for better aggregate EIRP
• Send measurements from all CBSDs — batch in requests
• Batch Size: Target ≤100 entries per message for stability; never exceed 512
• Log per-CBSD responses for troubleshooting
• Key Bridge SAS: DPs see faster batch processing and lower latency

Common Issues & Troubleshooting

Next Steps

• Build DP as wrapper around single-CBSD logic
• Test batch registration/heartbeat in sandbox with 50-100 entries

[Image placeholder: Domain Proxy architecture diagram]