| Protocol | f1ap | Network | 5g |
|---|---|---|---|
| Spec | 3GPP TS 38.473 | Spec Section | Sections 8.5.4 and 9.2.4.6 (Release 18) |
| Direction | gNB-DU -> gNB-CU initiatingMessage | Message Type | Ongoing public warning operation failure notification |
| Full message name | PWS Failure Indication |
|---|---|
| Protocol | F1AP |
| Technology | 5G |
| Direction | gNB-DU -> gNB-CU initiatingMessage |
| Interface | F1-C |
| Signaling bearer / channel | Non-UE-associated F1AP signaling / SCTP-carried F1AP initiatingMessage |
| Typical trigger | The DU detects failure of ongoing PWS operation in one or more cells. |
| Main purpose | Notifies the CU of a failure during ongoing public warning operation so it can investigate the affected warning coverage and coordinate recovery. |
| Main specification | 3GPP TS 38.473, Sections 8.5.4 and 9.2.4.6 (Release 18) |
| Release added | Release 15 |
| Procedures where used | Warning broadcast fault monitoring, DU cell troubleshooting, Warning coverage and recovery assessment |
PWS Failure Indication informs the gNB-CU that ongoing Public Warning System operation has failed for one or more gNB-DU cells.
Notifies the CU of a failure during ongoing public warning operation so it can investigate the affected warning coverage and coordinate recovery.
This is a failure notification from the DU, not a reply rejecting a warning request. Use reported cells and DU logs to investigate.
Call flow position: The DU independently notifies the CU after detecting a failure.
Typical state: Warning operation needs investigation; the indication does not identify a root cause.
Preconditions:
Next likely message: CU fault assessment; no dedicated response is defined
Call flow position: When supplied, failed NR CGI entries scope the CU's investigation.
Preconditions:
Next likely message: Recovery coordination based on DU logs and current warning requirements
Previous message(s): Earlier Write Replace Warning Request and Response, when warning distribution was configured, DU-side PWS fault detection
Next message(s): CU investigation and warning-state reconciliation, Separate recovery procedures, if required
Security context: This node-level notification does not establish or modify a UE security context.
-- Teaching outline, not compilable ASN.1
PWSFailureIndication
protocolIEs
TransactionID mandatory
PWS-Failed-NR-CGI-List optional
item (1..512)
NRCGI mandatory
NumberofBroadcasts mandatory, ignored
The procedure envelope uses ignore criticality. Transaction ID and the failed-cell list IE use reject criticality; these are separate levels.
F1AP-PDU
initiatingMessage
procedureCode: id-PWSFailureIndication
criticality: ignore
value: PWSFailureIndication
protocolIEs:
- id: id-TransactionID
criticality: reject
value: 45
- id: id-PWS-Failed-NR-CGI-List
criticality: reject
value:
- nr-cgi: "00101-000000321"
numberOfBroadcasts: 0
| IE | Presence | Description |
|---|---|---|
Message Type | Mandatory | Identifies PWS FAILURE INDICATION through the F1AP PDU envelope. |
Transaction ID | Mandatory | Identifies the procedure instance; it does not imply a request-response exchange. |
PWS failed NR CGI List | Optional | Optional list containing 1 to 512 cell items when present. Each item requires NR CGI and Number of Broadcasts. |
Message TypeIdentifies PWS FAILURE INDICATION 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 IDIdentifies the procedure instance; it does not imply a request-response exchange.
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.
PWS failed NR CGI ListOptional list containing 1 to 512 cell items when present. Each item requires NR CGI and Number of Broadcasts.
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: This is normal for the Class 2 procedure.
What to inspect: CU receipt and fault-handling logs.
Next step: Verify notification handling without expecting a PWS Failure Response message.
Likely cause: The optional list was not included; the packet alone does not identify affected cells.
What to inspect: DU fault logs, cell alarms, and active warning inventory.
Next step: Establish the affected scope from operational evidence.
Likely cause: The field is ignored for this message in the Release 18 baseline.
What to inspect: The procedure identity and the DU's actual broadcast records.
Next step: Use operational counters rather than this unused field.
Likely cause: An earlier response does not rule out a later failure during ongoing PWS operation.
What to inspect: Timing, cell state changes, and the warning's broadcast history.
Next step: Locate the later fault and verify recovery independently.
Failure reports a problem with ongoing PWS operation. Restart reports cells available for possible warning-information reloading.
The warning response answers a CU request. Failure Indication is an independent DU notification.
PWS Failure Indication concerns ongoing warning operation; Error Indication reports F1AP protocol-level errors.
The gNB-DU sends it to the gNB-CU over F1-C.
No. The list is optional, although NR CGI and Number of Broadcasts are mandatory inside each supplied item.
No. Number of Broadcasts is unused and ignored in this Release 18 message.
No. It is a Class 2 notification with no dedicated response message.
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.