What is RN Reconfiguration-r10 in LTE?
It is the LTE RRC message a donor eNodeB uses to change relay-node specific configuration.
| Protocol | lte-rrc | Network | lte |
|---|---|---|---|
| Spec | 3GPP TS 36.331 | Spec Section | 5.9.1, 6.2.2 |
| Direction | Donor eNodeB -> RN | Message Type | Relay Configuration |
| Full message name | LTE RRC RN Reconfiguration-r10 |
|---|---|
| Protocol | LTE-RRC |
| Technology | LTE |
| Direction | Donor eNodeB -> RN |
| Interface | Uu / Relay Backhaul |
| Signaling bearer / channel | SRB1 / DL-DCCH |
| Typical trigger | The donor eNodeB needs to change RN-specific configuration such as relay system information or subframe-related behavior. |
| Main purpose | Updates RN-specific system-information and relay-operation settings on the backhaul control path between the donor eNodeB and the relay node. |
| Main specification | 3GPP TS 36.331, 5.9.1, 6.2.2 |
| Release added | Release 10 |
| Procedures where used | Relay Node Operation, RN Reconfiguration |
Downlink LTE RRC message used by a donor eNodeB to change relay-node specific configuration.
Updates RN-specific system-information and relay-operation settings on the backhaul control path between the donor eNodeB and the relay node.
RN Reconfiguration-r10 is the donor-controlled LTE RRC message used to change relay-node behavior.
Call flow position: Main donor-to-RN update message used to change relay behavior.
Typical state: RN backhaul control is already active.
Preconditions:
Next likely message: RNReconfigurationComplete-r10
Call flow position: Configuration update branch used when the RN broadcast-related information changes.
Typical state: RN remains under donor control.
Preconditions:
Next likely message: RNReconfigurationComplete-r10
Previous message(s): RN connected backhaul control context
Next message(s): RNReconfigurationComplete-r10
Security context: Sent as protected connected-mode signaling on the donor-to-RN path.
RNReconfiguration-r10 ::= SEQUENCE {
rrc-TransactionIdentifier RRC-TransactionIdentifier,
criticalExtensions CHOICE {
c1 CHOICE {
rnReconfiguration-r10 RNReconfiguration-r10-IEs,
spare3 NULL,
spare2 NULL,
spare1 NULL
},
criticalExtensionsFuture SEQUENCE {}
}
}
RNReconfiguration-r10-IEs ::= SEQUENCE {
rn-SystemInfo-r10 OCTET STRING OPTIONAL,
rn-SubframeConfigReq-r10 BOOLEAN OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}
The key reading point is which RN-specific configuration blocks are populated.
DL-DCCH-Message
message c1 : rnReconfiguration-r10 : {
rrc-TransactionIdentifier 2,
criticalExtensions c1 : rnReconfiguration-r10 : {
rn-SubframeConfigReq-r10 TRUE
}
}
| IE | Required | Description |
|---|---|---|
rrc-TransactionIdentifier | Yes | Transaction identifier used to correlate the RN reconfiguration procedure. |
rn-SystemInfo-r10 | Optional | RN-specific system-information content controlled by the donor. |
rn-SubframeConfigReq-r10 | Optional | RN-related subframe configuration request block. |
nonCriticalExtension | Optional | Release-extension branch. |
rrc-TransactionIdentifierTransaction identifier used to correlate the RN reconfiguration procedure.
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.
rn-SystemInfo-r10RN-specific system-information content controlled by the donor.
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.
rn-SubframeConfigReq-r10RN-related subframe configuration request block.
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.
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 donor-to-RN reconfiguration may be incomplete, unsupported, or not acknowledged.
What to inspect: Check the populated RN-specific blocks and the presence of RNReconfigurationComplete-r10.
Next step: Compare against a known-good donor-to-RN reconfiguration case.
It is the LTE RRC message a donor eNodeB uses to change relay-node specific configuration.
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.