What is RN Reconfiguration Complete-r10 in LTE?
It is the relay-node acknowledgement sent after RNReconfiguration-r10.
| Protocol | lte-rrc | Network | lte |
|---|---|---|---|
| Spec | 3GPP TS 36.331 | Spec Section | 5.9.1, 6.2.2 |
| Direction | RN -> Donor eNodeB | Message Type | Relay Configuration Completion |
| Full message name | LTE RRC RN Reconfiguration Complete-r10 |
|---|---|
| Protocol | LTE-RRC |
| Technology | LTE |
| Direction | RN -> Donor eNodeB |
| Interface | Uu / Relay Backhaul |
| Signaling bearer / channel | SRB1 / UL-DCCH |
| Typical trigger | The RN has received RNReconfiguration-r10 and returns the procedure completion. |
| Main purpose | Confirms that the donor-to-RN relay configuration update was applied or accepted on the RN side. |
| Main specification | 3GPP TS 36.331, 5.9.1, 6.2.2 |
| Release added | Release 10 |
| Procedures where used | Relay Node Operation, RN Reconfiguration |
Uplink LTE RRC message used by the relay node to acknowledge RNReconfiguration-r10.
Confirms that the donor-to-RN relay configuration update was applied or accepted on the RN side.
RN Reconfiguration Complete-r10 is the relay-node acknowledgement for the donor-side RN reconfiguration.
Call flow position: Uplink acknowledgement step after donor-to-RN reconfiguration.
Typical state: RN backhaul control remains active.
Preconditions:
Next likely message: Later RN control continuation
Previous message(s): RNReconfiguration-r10
Next message(s): Later RN backhaul control continuation
Security context: Sent as protected connected-mode signaling on the RN backhaul path.
RNReconfigurationComplete-r10 ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE {
rnReconfigurationComplete-r10 RNReconfigurationComplete-r10-IEs,
spare3 NULL,
spare2 NULL,
spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
RNReconfigurationComplete-r10-IEs ::= SEQUENCE {
nonCriticalExtension SEQUENCE {} OPTIONAL
}
The transaction identifier is the main practical check because the payload is otherwise small.
UL-DCCH-Message
message c1 : rnReconfigurationComplete-r10 : {
rrc-TransactionIdentifier 2,
criticalExtensions c1 : rnReconfigurationComplete-r10 : {}
}
| IE | Required | Description |
|---|---|---|
rrc-TransactionIdentifier | Yes | Transaction identifier used to match the completion with the preceding RN reconfiguration. |
nonCriticalExtension | Optional | Release-extension branch. |
rrc-TransactionIdentifierTransaction identifier used to match the completion with the preceding RN reconfiguration.
Presence: Required
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.
nonCriticalExtensionRelease-extension branch.
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: The RN may not have accepted or returned the acknowledgement.
What to inspect: Check the earlier RNReconfiguration-r10 and whether the backhaul-control trace breaks afterward.
Next step: Treat the issue as an incomplete RN control procedure.
It is the relay-node acknowledgement sent after RNReconfiguration-r10.
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.