| Protocol | f1ap | Network | 5g |
|---|---|---|---|
| Spec | 3GPP TS 38.473 | Spec Section | Sections 8.5.2 and 9.2.4.4 (Release 18) |
| Direction | gNB-DU -> gNB-CU successfulOutcome | Message Type | Public warning broadcast cancellation response |
| Full message name | PWS Cancel Response |
|---|---|
| Protocol | F1AP |
| Technology | 5G |
| Direction | gNB-DU -> gNB-CU successfulOutcome |
| Interface | F1-C |
| Signaling bearer / channel | Non-UE-associated F1AP signaling / SCTP-carried F1AP successfulOutcome |
| Typical trigger | The DU has processed a PWS Cancel Request from the CU. |
| Main purpose | Acknowledges the cancellation transaction and provides cell-level reporting so the CU can reconcile the result with the requested warning scope. |
| Main specification | 3GPP TS 38.473, Sections 8.5.2 and 9.2.4.4 (Release 18) |
| Release added | Release 15 |
| Procedures where used | Emergency alert withdrawal confirmation, Public warning inventory reconciliation, Cell-level cancellation troubleshooting |
PWS Cancel Response is the F1AP reply from the gNB-DU to the gNB-CU reporting the result of a warning broadcast cancellation request.
Acknowledges the cancellation transaction and provides cell-level reporting so the CU can reconcile the result with the requested warning scope.
Match the transaction first, then read cell reporting and counters in the context of the request.
Call flow position: The DU replies after processing the request for a specific warning.
Typical state: The CU correlates the response with the cancellation transaction.
Preconditions:
Next likely message: CU warning-state reconciliation
Call flow position: The DU reports the result of a request selecting all warnings in an area.
Preconditions:
Next likely message: CU review of cancelled-cell reporting
Previous message(s): PWS Cancel Request
Next message(s): CU reconciliation of warning state, Subsequent warning activation or cancellation, if required
Security context: This response belongs to a node-level warning procedure and does not establish UE security.
-- Teaching outline, not compilable ASN.1
PWSCancelResponse
protocolIEs
TransactionID mandatory
Cells-Broadcast-Cancelled-List optional
item
NRCGI mandatory
NumberofBroadcasts mandatory
CriticalityDiagnostics optional
The nested item fields are mandatory when an item is supplied; the list itself is optional. Message Type is represented by the F1AP envelope.
F1AP-PDU
successfulOutcome
procedureCode: id-PWSCancel
criticality: reject
value: PWSCancelResponse
protocolIEs:
- id: id-TransactionID
value: 43
- id: id-Cells-Broadcast-Cancelled-List
value:
- nr-cgi: "00101-000000321"
numberOfBroadcasts: 12
| IE | Presence | Description |
|---|---|---|
Message Type | Mandatory | Identifies PWS CANCEL RESPONSE through the F1AP PDU envelope. |
Transaction ID | Mandatory | Correlates the response with the PWS Cancel Request. |
Cell Broadcast Cancelled List | Optional | Optional cell reporting. Each item contains mandatory NR CGI and Number of Broadcasts fields. |
Criticality Diagnostics | Optional | Optional details about protocol or IE handling. |
Message TypeIdentifies PWS CANCEL RESPONSE through the F1AP PDU envelope.
Presence: Mandatory
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Transaction IDCorrelates the response with the PWS Cancel Request.
Presence: Mandatory
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Cell Broadcast Cancelled ListOptional cell reporting. Each item contains mandatory NR CGI and Number of Broadcasts fields.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Criticality DiagnosticsOptional details about protocol or IE handling.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Likely cause: A capture gap, transport interruption, or request-processing problem is possible.
What to inspect: Both F1-C capture points, Transaction ID, DU logs, and request validity.
Next step: Establish whether the DU received the request before retrying.
Likely cause: The procedure treats this as no matching ongoing broadcast to stop in that area.
What to inspect: The original activation, warning identity, cell ownership, and broadcast history.
Next step: Reconcile the expected warning state with the DU inventory.
Likely cause: The request may be cancel-all, or a valid count may be unavailable.
What to inspect: The request's selector and counter availability in DU logs.
Next step: Interpret the value in procedure context before drawing delivery conclusions.
Use the request's Notification Information to identify the warning associated with this result.
Interpret the report against the area selected by the request rather than assuming a single warning identity.
F1AP reports from DU to CU over F1-C; NGAP reports from NG-RAN to AMF over N2.
The gNB-DU sends it to the gNB-CU over F1-C.
Transaction ID matches this response to PWS Cancel Request.
No. If supplied, each item must contain NR CGI and Number of Broadcasts.
No. This is cancellation procedure reporting, not per-UE reception acknowledgement.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.