# Chapter 5 — The Full Flight Lifecycle This chapter walks through the complete technical lifecycle of a drone flight in BR-UTM — from pre-flight planning to post-flight cleanup. Every API call, data structure, and decision point is described in sequence. --- ## 5.1 Lifecycle Overview A BR-UTM flight goes through the following stages: ``` PRE-FLIGHT IN-FLIGHT POST-FLIGHT ───────────────────────── ─────────────────────────── ─────────────── Query DSS (OIRs + Constraints) │ ├─► Fetch details from USSs (peer-to-peer) │ (get OVNs) │ ├─► Calculate conflicts locally (4D intersection) │ ├─► Create OIR in DSS (state: Accepted) │ (include all OVNs in `key`) │ └─► Notify subscribers Delete OIR from DSS │ │ ├─► Notify subscribers ▼ │ Re-check conflicts (pre-activation) └─► Delete ISA from Remote ID DSS │ Activate OIR in DSS (state: Activated) Notify subscribers │ Create ISA in Remote ID DSS │ Serve telemetry (≤10s updates) ──────────────────────────► │ │ ├── Conformance monitoring ────────────────────────── │ │ (detect out-of-volume) │ │ │ ├── Handle incoming notifications │ │ (POST /uss/v1/operational_intents) │ │ │ └── Emergency handling (if needed) │ (Nonconforming → Contingent) │ ``` --- ## 5.2 Pre-Flight: Querying the Airspace Before creating an OIR, your USS must understand the current state of the airspace in the intended operation area. ### 5.2.1 Query for Existing OIRs **Endpoint:** `POST http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/query` **Scope:** `utm.strategic_coordination` ```json { "area_of_interest": { "volume": { "outline_polygon": { "vertices": [ { "lat": -23.205, "lng": -45.878 }, { "lat": -23.205, "lng": -45.872 }, { "lat": -23.211, "lng": -45.872 }, { "lat": -23.211, "lng": -45.878 } ] }, "altitude_lower": { "value": 0, "reference": "W84", "units": "M" }, "altitude_upper": { "value": 200, "reference": "W84", "units": "M" } }, "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" }, "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" } } } ``` The response includes a list of `OperationalIntentReference` objects. Each contains the `uss_base_url` of the managing USS. > **Important:** The DSS uses S2 cell indexing. It may return OIRs that do not precisely intersect your area. Your USS must perform the exact 4D intersection calculation locally after fetching the full volume details. ### 5.2.2 Fetch OIR Details from Peer USSs For each OIR returned by the DSS that is **managed by another USS**, fetch the full details (including the OVN and exact volumes): **Endpoint (on the peer USS):** `GET {uss_base_url}/uss/v1/operational_intents/{entityid}` **Scope:** `utm.strategic_coordination` **Token audience:** Domain of the peer USS (extracted from `uss_base_url`) The response includes the full `OperationalIntentDetails` — volumes, off_nominal_volumes, priority, and the current OVN. **Collect the OVN from each response** — you will need all of them when creating your OIR. > **Note:** Even if local geometry calculation shows a particular OIR does not intersect with your planned volume, you **must still collect its OVN** and include it in the `key` array. The DSS guarantees airspace awareness at the S2 cell level, not the geometric level. ### 5.2.3 Query for Constraints **Endpoint:** `POST http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/constraint_references/query` **Scope:** `utm.constraint_processing` Same request format as the OIR query above. The response returns `ConstraintReference` objects. ### 5.2.4 Fetch Constraint Details from DECEA's USS For each constraint returned, fetch the full details: **Endpoint (on DECEA's USS):** `GET {constraint_uss_base_url}/uss/v1/constraints/{entityid}` **Scope:** `utm.constraint_processing` Collect the OVN from each constraint. If your planned volume intersects a constraint, **you must not proceed** with creating the OIR in that area — deconflict or abandon the operation. ### 5.2.5 Local 4D Conflict Detection After collecting all nearby OIR and Constraint volumes, perform local 4D intersection calculations: - **Horizontal**: polygon or circle intersection in the lat/lng plane. - **Vertical**: overlap between altitude ranges (`altitude_lower` and `altitude_upper`). - **Temporal**: overlap between time windows (`time_start` and `time_end`). A conflict exists only when **all three dimensions overlap simultaneously**. If a conflict with another OIR is detected at the same priority (0), deconfliction strategies include: - Adjusting the route or volume to avoid overlap. - Adjusting the time window to fly when the conflicting OIR is not active. - Suggesting the operator wait and retry. --- ## 5.3 Pre-Flight: Creating the OIR Once you have resolved any conflicts and collected all OVNs, create the OIR in the DSS. **Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/{entityid}` **Scope:** `utm.strategic_coordination` The `{entityid}` is a UUID generated by **your USS** — you own this identifier. ```json { "extents": [ { "volume": { "outline_polygon": { "vertices": [ { "lat": -23.207, "lng": -45.875 }, { "lat": -23.208, "lng": -45.874 }, { "lat": -23.209, "lng": -45.876 } ] }, "altitude_lower": { "value": 0, "reference": "W84", "units": "M" }, "altitude_upper": { "value": 120, "reference": "W84", "units": "M" } }, "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" }, "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" } } ], "key": ["", ""], "state": "Accepted", "uss_base_url": "https://uss.yourcompany.com/utm", "new_subscription": { "uss_base_url": "https://uss.yourcompany.com/utm", "notify_for_constraints": true }, "flight_type": "BVLOS" } ``` **Key fields:** - `extents`: The bounding box of your operation (used for S2 indexing). This should cover all your planned volumes. - `key`: **All OVNs** you collected in steps 5.2.2 and 5.2.4. Can be empty `[]` if the area is clear. - `state`: Always `Accepted` at creation time. - `uss_base_url`: Your publicly accessible base URL. Other USSs will use this to call you. - `new_subscription`: Creates an implicit subscription for the operation's area, so you receive notifications about new OIRs/Constraints appearing in that area. - `flight_type`: One of `VLOS`, `EVLOS`, `BVLOS`. **Response (HTTP 201):** ```json { "operational_intent_reference": { "id": "2f8343be-6482-4d1b-a474-16847e01af1e", "manager": "your-uss-sub", "state": "Accepted", "ovn": "9d158f59-80b7-4c11-9c0c-8a2b4d936b2d", "uss_base_url": "https://uss.yourcompany.com/utm", "subscription_id": "78ea3fe8-...", ... }, "subscribers": [ { "subscriptions": [...], "uss_base_url": "https://other-uss.com/utm" } ] } ``` **Save the `ovn` from the response** — you will need it for all subsequent updates. --- ## 5.4 Pre-Flight: Notifying Subscribers The DSS response includes a `subscribers` list — the USSs that have subscriptions in your operation's area. You **must notify each of them** immediately after a successful DSS write. **Endpoint (on each subscriber USS):** `POST {subscriber_uss_base_url}/uss/v1/operational_intents` **Scope:** `utm.strategic_coordination` **Token audience:** Domain of the subscriber USS ```json { "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e", "operational_intent": { "reference": { ... }, "details": { "volumes": [ ... ], "off_nominal_volumes": [], "priority": 0 } }, "subscriptions": [ { "subscription_id": "78ea3fe8-...", "notification_index": 1 } ] } ``` **Expected response:** `204 No Content` > **Notification timing:** You must send this notification within **5 seconds** in at least 95% of cases. If a subscriber USS is unreachable, proceed — their unavailability does not block your operation. This same notification pattern applies for **every DSS write** — creation, updates, state changes, and deletion all require notifying the subscribers returned in that write's response. --- ## 5.5 Flight Activation Immediately before the flight begins, activate the OIR. This is the moment the drone is cleared to launch. ### 5.5.1 Pre-Activation Conflict Re-Check Before transitioning to `Activated`, perform a fresh conflict check (repeat steps 5.2.1–5.2.5). The airspace may have changed since you created the OIR. If a newly arrived OIR at the same or higher priority conflicts with your volume, **you must not activate** — deconflict first. The rule: **first to activate wins**. If two USSs with overlapping OIRs at the same priority (0) both attempt activation simultaneously, it is the USS's responsibility to detect this and stand down if necessary. ### 5.5.2 Update OIR State to Activated **Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/v1/operational_intent_references/{entityid}/{ovn}` **Scope:** `utm.strategic_coordination` ```json { "extents": [ ... ], "key": [""], "state": "Activated", "uss_base_url": "https://uss.yourcompany.com/utm", "subscription_id": "78ea3fe8-...", "flight_type": "BVLOS" } ``` > **Note:** The `{ovn}` in the URL must be the current OVN of your OIR (from the creation response or last update response). If the DSS returns `409 AirspaceConflictResponse`, it means new entities have appeared in the area whose OVNs you haven't acknowledged. Fetch their details, add their OVNs to `key`, and retry. **Response (HTTP 200):** Returns the updated reference with a new OVN and a fresh `subscribers` list. Notify all subscribers (step 5.4) with the `Activated` state. ### 5.5.3 Create the ISA (Remote ID) Simultaneously with (or immediately after) OIR activation, register an **ISA** in the Remote ID DSS: **Endpoint:** `PUT http://api.sandbox.brutm.dcta.mil.br/dss/dss/identification_service_areas/{isa_id}` **Scope:** `rid.service_provider` ```json { "extents": { "volume": { "outline_polygon": { "vertices": [ { "lat": -23.205, "lng": -45.878 }, { "lat": -23.205, "lng": -45.872 }, { "lat": -23.211, "lng": -45.872 }, { "lat": -23.211, "lng": -45.878 } ] }, "altitude_lo": 0, "altitude_hi": 120 }, "time_start": "2026-07-01T10:00:00Z", "time_end": "2026-07-01T11:00:00Z" }, "flights_url": "https://uss.yourcompany.com/uss/flights" } ``` The `flights_url` tells display providers (like DECEA's monitoring tools) where to query your telemetry. --- ## 5.6 In-Flight: Serving Telemetry Once the flight is activated and the ISA is registered, your USS must serve **live telemetry** for the drone via the Remote ID endpoints. DECEA and other display providers will **poll** your telemetry endpoints. You must keep the data fresh. **Required update frequency:** At least once every **10 seconds**. Your USS must implement and serve: **`GET /uss/flights`** — Basic flight list for a view area. **`GET /uss/flights/{id}/details`** — Detailed information for a specific flight. See [Chapter 6 — APIs to Implement](./06-apis-to-implement.md) for the full request/response specification. --- ## 5.7 In-Flight: Conformance Monitoring Your USS must continuously monitor whether the drone is flying within its declared OIR volumes. This is called **conformance monitoring**. - If the drone's reported position is inside the `volumes` of the Activated OIR → **nominal, no action needed**. - If the drone's position is outside the `volumes` → trigger the Non-Conforming flow (Section 5.8). --- ## 5.8 In-Flight: Handling Incoming Notifications While your flight is active, you may receive notifications from other USSs about changes in the airspace near you (new OIRs, constraint changes). These arrive as `POST` requests on your own USS: - `POST /uss/v1/operational_intents` — A new or updated OIR in your subscription area. - `POST /uss/v1/constraints` — A new or updated Constraint in your subscription area. **When you receive such a notification:** 1. Update your internal airspace state. 2. Check whether the new/updated entity conflicts with your active OIR. 3. If a conflict exists and the new entity has **equal or higher priority**, you must deconflict — either modify your route (update the OIR) or, if the flight is active, trigger the Nonconforming flow. This is how DECEA enforces ATM priority: DECEA's USS may create a high-priority Constraint or OIR in your area, and your USS must react within the 10-second conformance window. --- ## 5.9 Emergency Handling: Non-Conforming State **Trigger:** The drone's telemetry position is outside the OIR's `volumes`. **Required response time:** Transition to `Nonconforming` **within 10 seconds** of detecting the deviation. ### 5.9.1 Calculate off_nominal_volumes Compute a volume that covers the drone's current position and the deviation path. This is your "warning zone" for other operators. The exact calculation is at your USS's discretion — it should be large enough to represent the risk area but not unnecessarily large. ### 5.9.2 Update DSS (within 5 seconds of detection) **Endpoint:** `PUT .../dss/v1/operational_intent_references/{entityid}/{ovn}` ```json { "extents": [ ... ], "state": "Nonconforming", "uss_base_url": "https://uss.yourcompany.com/utm", "subscription_id": "78ea3fe8-...", "flight_type": "BVLOS" } ``` Note: `key` (OVNs) **may be omitted** in `Nonconforming` state — the DSS does not require proof of airspace awareness during emergencies. ### 5.9.3 Expose Telemetry Endpoint In `Nonconforming` state, you must also expose live drone position at: `GET /uss/v1/operational_intents/{entityid}/telemetry` This allows DECEA and other USSs to monitor the drone's actual position in real time. ### 5.9.4 Notify Subscribers After the DSS update, notify all subscribers (as returned in the DSS response) with: - The new `Nonconforming` state. - The updated `off_nominal_volumes` included in the `details`. ### 5.9.5 Recovery If the drone returns to its original volume: 1. Update the OIR back to `state: Activated`. 2. Clear `off_nominal_volumes` from the details. 3. Notify subscribers of the recovery. 4. Continue normal telemetry serving. --- ## 5.10 Emergency Handling: Contingent State **Trigger:** The drone has been continuously in `Nonconforming` state for **more than 60 seconds**. ### Transition to Contingent **Endpoint:** `PUT .../dss/v1/operational_intent_references/{entityid}/{ovn}` ```json { "extents": [ ... ], "state": "Contingent", "uss_base_url": "https://uss.yourcompany.com/utm", "subscription_id": "78ea3fe8-...", "flight_type": "BVLOS" } ``` In `Contingent` state: - The **original `volumes` are no longer active** — only `off_nominal_volumes` define the warning zone. - There is **no recovery path** — the operation must be terminated. - The ISA **remains active** as long as the drone is still sharing telemetry. - The telemetry endpoint `GET /uss/v1/operational_intents/{entityid}/telemetry` must remain available. - Continue notifying subscribers of the Contingent state. The USS must guide the operator to land the drone and then close the operation (Section 5.11). --- ## 5.11 End of Flight: Cleanup When the flight concludes normally (or after a Contingent state is resolved), the USS must clean up all DSS records. ### 5.11.1 Delete the ISA **Endpoint:** `DELETE /dss/identification_service_areas/{isa_id}/{version}` **Scope:** `rid.service_provider` Delete the ISA from the Remote ID DSS. The `{version}` comes from the ISA creation response. Notify the ISA subscribers if the DSS response includes any. ### 5.11.2 Delete the OIR **Endpoint:** `DELETE /dss/v1/operational_intent_references/{entityid}/{ovn}` **Scope:** `utm.strategic_coordination` Delete the OIR from the DSS entirely. There is no "Completed" state — deletion is how a flight is closed. > **Note:** Each OIR represents a single flight. If the same drone flies a second mission (e.g., after a battery change), create a **new OIR with a new UUID** for that second flight. ### 5.11.3 Notify Subscribers of Deletion The DSS delete response includes a `subscribers` list. Notify each subscriber: **Endpoint (on each subscriber):** `POST {subscriber_uss_base_url}/uss/v1/operational_intents` When sending a deletion notification, **omit the `operational_intent` field** from the body — its absence signals that the OIR has been deleted: ```json { "operational_intent_id": "2f8343be-6482-4d1b-a474-16847e01af1e", "subscriptions": [ { "subscription_id": "78ea3fe8-...", "notification_index": 5 } ] } ``` --- ## 5.12 Multi-Volume Operations A single OIR can contain **multiple `Volume4D` objects** in its `volumes` array. This is the correct approach for complex flight paths. Example structure for a takeoff → route → landing mission: ```json "volumes": [ { "volume": { "outline_circle": { "center": {...}, "radius": { "value": 50, "units": "M" }}, "altitude_lower": { "value": 0, "reference": "W84", "units": "M" }, "altitude_upper": { "value": 120, "reference": "W84", "units": "M" } }, "time_start": { "value": "2026-07-01T10:00:00Z", "format": "RFC3339" }, "time_end": { "value": "2026-07-01T10:05:00Z", "format": "RFC3339" } }, { "volume": { "outline_polygon": { "vertices": [...] }, "altitude_lower": { "value": 80, "reference": "W84", "units": "M" }, "altitude_upper": { "value": 120, "reference": "W84", "units": "M" } }, "time_start": { "value": "2026-07-01T10:05:00Z", "format": "RFC3339" }, "time_end": { "value": "2026-07-01T10:55:00Z", "format": "RFC3339" } }, { "volume": { "outline_circle": { "center": {...}, "radius": { "value": 50, "units": "M" }}, "altitude_lower": { "value": 0, "reference": "W84", "units": "M" }, "altitude_upper": { "value": 120, "reference": "W84", "units": "M" } }, "time_start": { "value": "2026-07-01T10:55:00Z", "format": "RFC3339" }, "time_end": { "value": "2026-07-01T11:00:00Z", "format": "RFC3339" } } ] ``` --- ## 5.13 Complete State Transition Summary ``` [Created] ──────────────────────────────────────────────────── [Deleted] │ ▲ ▼ │ Accepted ──activate──► Activated ──out of volume──► Nonconforming │ │ │ │ │ │ back in vol 60s │ │ │ │ │ │ ▼ ▼ │ │ Activated Contingent │ │ └───────────────────────────────────┘ (delete at end of flight) ```