Monday, June 14, 2010
Spec Ambiguity
Could somebody kindly tell me if a SGW could be relocated by a TAU request in connected mode? I think not? Interested in a debate?
3GPP TS 23.401 Chapter:- 5.3.3
Cheers, Santosh
Subscribe to:
Post Comments (Atom)
Posts
12 comments:
Well, I think it should be possible. The handover should happen before TAU and it is perfectly Ok (I guess handover is possible in this scenario).
Nevertheless, I am curious about the outcome of this debate.
A handover can relocated the SGW, but TAU in connected mode cannot as there is no message to inform eNB about the S1-U FTEID of SGW.
I hope the handover procedure should be taking care of this. Handover request from target MME to target eNB possibly sends target SGW details for uplink traffic. So it shouldn't be dependent of TAU procedure as such that will follow the handover. Please correct me if I am wrong.
Exactly my friend. A handover may relocate SGW, but standalone TAU procedure in connected mode cannot relocate SGW. This is where I differ from the spec.
Hmmm, as user has already initiated TAU in CONNECTED mode (may be because of periodic TAU timer expiry??), MME should not select a new SGW now....interesting..little misunderstanding, but now I agree with you, MME should not or can I say MME can not select a new SGW during TAU in UE CONNECTED mode.
Hi, Santosh.
I think TAU in connected mode can relocate S-GW.
Please refer to Step 20 of 5.3.3.1:
"... If the "active flag" is set in the TAU Request message the user plane
setup procedure can be activated in conjunction with the TAU Accept
message. The procedure is described in detail in TS 36.300 [5]. The
message sequence should be the same as for the UE triggered Service
Request procedure specified in clause 5.3.4.1 from the step when MME
establishes the bearer(s). ..."
Thus, the target eNodeB can obtain details of the target S-GW from MME
by a part of Service Request procedure.
Gene, service request procedure is used to move UE from Idle to Connected mode. This basically boils down to the fact that TAU in IDLE mode can only relocated the SGW.
I think this is not addressed by the spec and will have to be handled.
Consider that the enodeb through which the UE is connected services mulitple TAIs.Now, if the UE moves to another TAI which is serviced by the current enodeb, it will gneerate a TAU.(ie if this TAI was not in the TAI list assigned to the UE )
If the currently selected S-GW doesn't service this TAI then the S-GW has to be relocated.
In that scenario, a handover will happen before TAU which will relocate the SGW. Thus TAU itself will not relocate the SGW.
If its the same enodeb, just changing TAI wouldn't trigger a handover.(will it? where is that specified?)
Make a note that handovers are t triggered either by eNB or network. This mean change in TAI will not effect the handover, instead if UE realizes that it has entered a TAI that is not in its list (which was sent during attach) a TAU will be triggered.
As TAI change "may" happen after the handover, TAU is always initiated after a handover.
From section 5.3.3.0A in spec 23.401 generally tracking areas belong to a same eNodeB should be put in a same Tracking Area List. e.g. eNB1 has cell1 and cell2, cell1 has TA1 and cell2 has TA2. TA1 and TA2 should generally be put into a same Tracking Area List. When UE connects to TA1 and registers this Tracking Area List is assigned to the UE. According to the spec tracking areas within same Tracking Area List should be served by the same SGW. So when UE moves from TA1 to TA2 generally TAU will NOT happen. UE's new TAI will be passed to MME in any S1-AP UPLINK NAS TRANSPORT message.
5.3.3.0A Provision of UE's TAI to MME in ECM-CONNECTED state
The eNodeB shall include the TAI+ECGI of the current cell in every S1-AP UPLINK NAS TRANSPORT message.
NOTE: An eNodeB can contain cells from more than one Tracking Area and intra-eNodeB cell changes are not normally notified to the MME. However, the MME needs to know the UE's current TAI in order to correctly produce a TAU accept message.
Post a Comment