Home / Call Flows / LTE / LTE Relay Node Reconfiguration

LTE Relay Node Reconfiguration Call Flow

call-flow LTE | Relay Node | RN | RRC

LTE Relay Node Reconfiguration is the donor-to-relay control path used when the donor eNB changes relay-node-specific configuration on the RN backhaul control branch.

The practical anchors are RN Reconfiguration r10 and RN Reconfiguration Complete r10, which together define the RN-specific configuration update and acknowledgement path.

Introduction

This page is for relay-node-specific control rather than for normal UE-facing connected-mode updates. The trace has to stay on the donor-to-RN branch to make sense of the change.

Use it when the RN-specific system-information or relay-operation behavior changed and the main question is whether the donor commanded the right update and whether the relay acknowledged it.

What Is LTE Relay Node Reconfiguration in Simple Terms?

What starts the procedure: The donor eNB needs to change relay-node-specific configuration on the RN control branch.
What the UE and network want to achieve: A relay-node state that matches the donor’s new RN-specific configuration.
What success looks like: The donor sends the RN update and the relay acknowledges it cleanly.
What failure means: The relay does not acknowledge the change cleanly or later RN behavior does not reflect it.

Why this procedure matters

Relay-node traces can look deceptively similar to ordinary LTE reconfiguration unless the RN-specific branch is kept in view. This page keeps the analysis on the donor-to-RN control path where the actual change was commanded.

Quick Fact Sheet

Procedure name	LTE Relay Node Reconfiguration
Domain	Relay-node backhaul control
Main trigger	Need to change RN-specific system-information or relay operation settings
Start state	The relay node is operating under donor control
End state	The relay has accepted the new RN-specific configuration or the update remains incomplete
Main nodes	Relay node, donor eNB
Main protocols	RRC
Main success outcome	RN-specific change is acknowledged and reflected later
Main failure outcome	RN-specific control update is not completed or not reflected correctly
Most important messages	RN Reconfiguration r10, RN Reconfiguration Complete r10
Main specs	TS 36.331

LTE Relay Node Reconfiguration Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

A relay node is operating under donor eNB control.
The donor needs to update RN-specific configuration or system-information behavior.
The RN control branch is visible in the trace.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
Relay node	Receives the RN-specific update and acknowledges it if accepted.
Donor eNB	Sends the RN-specific configuration change and expects RN acknowledgement.
RN control context	Represents the donor-to-RN branch that should not be confused with ordinary UE-facing updates.

Interfaces used

Interface	Path	Role
RN backhaul control path	Donor eNB <-> Relay node	Carries the RN-specific reconfiguration exchange.
RRC	Donor eNB <-> Relay node	Carries the main RN-specific configuration and completion messages.

End-to-End Call Flow

Relay node              Donor eNB
|<--RN Reconfiguration---|
|--RN Reconfig Complete->|
|==== RN-specific continuation ===>|

Major Phases

Phase	What happens
1. Decide the RN-specific change	The donor eNB prepares the relay-specific update.
2. Deliver the RN update	The donor sends the RN-specific reconfiguration message.
3. Acknowledge the change	The relay returns the completion message if the update is accepted.
4. Continue with the new RN state	Later relay behavior should now match the updated RN-specific configuration.

Step-by-Step Breakdown

Send the RN-specific update

Sender -> receiver: Donor eNB -> Relay node

Message(s): RN Reconfiguration r10

Purpose: Carry the relay-node-specific configuration change.

State or context change: The RN now has a pending donor-controlled update to apply.

Note: This is the main message that proves the donor actually commanded a relay-specific change.

Acknowledge the RN update

Sender -> receiver: Relay node -> Donor eNB

Message(s): RN Reconfiguration Complete r10

Purpose: Confirm that the RN applied or accepted the requested update.

State or context change: The RN-specific change is now complete from the message-exchange point of view.

Note: If the acknowledgement is missing, later RN behavior should not be assumed to reflect the new state.

Check later RN-specific behavior

Sender -> receiver: Relay node / donor eNB

Message(s): Later RN control continuation

Purpose: Validate whether the RN behavior now matches the intended donor change.

State or context change: The relay branch is now using the new configuration or is clearly inconsistent with it.

Note: This separates message completion from operational correctness.

Correlate with RN system-information impact if relevant

Sender -> receiver: Relay node

Message(s): RN-specific system-information refresh

Purpose: Check whether RN system-information behavior changed in line with the update.

State or context change: The RN control path is now tied to a visible later effect if one exists.

Note: This is especially useful when the update was mainly about RN-specific system-information behavior.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
RN Reconfiguration r10	RRC	Donor eNB -> Relay node	Carries the RN-specific configuration update.	Check which RN-specific behavior the donor tried to change.
RN Reconfiguration Complete r10	RRC	Relay node -> Donor eNB	Acknowledges the RN-specific update.	Check whether the relay really acknowledged the exact update being analyzed.
RRC Connection Reconfiguration	RRC	eNB -> UE	Useful contrast only when mixed traces risk confusing RN control with ordinary UE control.	Check that the trace branch is really relay-node specific and not a normal UE-facing branch.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
RN-specific change scope	The exact relay-specific behavior the donor attempted to change.	RN Reconfiguration r10	Useful for checking whether later RN behavior should have changed at all.	The wrong later behavior is blamed because the actual RN change scope was misunderstood.
Acknowledgement presence	Whether the RN returned the completion message.	RN Reconfiguration Complete r10	This is the clearest proof that the RN accepted the update.	Later RN behavior is assumed to reflect a change that was never acknowledged.
Branch identity	Whether the trace is truly donor-to-RN control and not ordinary UE-facing control.	Whole procedure window	Prevents the RN branch from being mixed with normal LTE control flows.	The wrong control family is being analyzed.
Later RN effect	The visible RN-specific behavior that should match the update.	Post-acknowledgement continuation	Separates configuration completion from operational correctness.	The message exchange completed, but the intended RN effect never appeared.
System-information impact	Whether the RN update changed relay-specific system-information behavior.	Later RN behavior	Useful when the update was tied to RN system-information handling.	The update is judged without checking the most visible later effect.

Successful Completion

Success means the donor sends the RN-specific update, the relay acknowledges it, and later RN behavior matches the intended change.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The donor sends RN Reconfiguration, but later RN behavior does not match it	The RN may have accepted the update message but still not moved into the intended operational state.	RN Reconfiguration r10, RN Reconfiguration Complete r10, and the first later RN-specific behavior together.	RN Reconfiguration r10, RN Reconfiguration Complete r10	RN backhaul control	Separate message acknowledgement from actual RN-side effect.
The trace looks like a reconfiguration issue, but the wrong branch is being analyzed	A normal UE-facing LTE reconfiguration may be mixed into a relay-node trace.	Branch identity around the message family.	RN Reconfiguration r10, RRC Connection Reconfiguration	RRC	Confirm the branch is donor-to-RN before continuing.

What to Check in Logs and Traces

Use RN Reconfiguration r10 as the main donor-side anchor.
Do not assume later RN behavior changed unless RN Reconfiguration Complete r10 is present.
Keep ordinary UE-facing reconfiguration separate from donor-to-RN control.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page is RN-specific. Use ordinary LTE reconfiguration pages only when the trace is clearly UE-facing and not donor-to-relay control.

FAQ

What is LTE Relay Node Reconfiguration?

It is the donor-to-relay RRC update path used to change RN-specific behavior on the relay-node control branch.

Which two messages define this procedure?

RN Reconfiguration r10 and RN Reconfiguration Complete r10 are the main relay-node control anchors.