Is there a 3GPP mentioning that if there is no TAU update UE cannot initiate a service?

Specs
#1

Hello Experts: I have this crazy scenario:

UE in idle mode, on a fixed location, doing ping-pong between 2 different PCI each PCI having a different TAC. So 2 TACs in total.

UE does a lot of TAU update all successful.

But in between this time it does not initiate VoLTE calls as per scripts.

No RRC Connection requests to go to DCH and send SIP INVITE.

Is there a 3GPP mentioning that if there is no TAU update (TAC registered on SIM is different from TAC on cell) UE cannot initiate a service?

Technology: LTE.

Is there a 3GPP mentioning that if there is no TAU update UE cannot initiate a service
Is there a 3GPP mentioning that if there is no TAU update UE cannot initiate a service1094Ă—695 69.3 KB

#2

What is the carrier?

I am asking this as different carriers have different requirements for IMS when changing that TAC.

#3

I think TAC defined at Core end is different from Cell.

#4

Some carriers (operators) expect Ims rereg to update the Licatokn to core network via PANI header.

Is rereg happening after changing the TAC?

RAN info doesn’t matter here as this seems to be a Core network related issue.

#5

No, just TAU update.
That happens very fast 2-3 seconds.
Then again pingpong and so on.
It is a SIM issue.
But what exactly?
It seems AS doesn’t like something
Actually NAS does not trigger AS action
I know that between TAUs UE cannot receive paging (It will always be paged on old TAC while he will register on new TAC).
So I expect UE not to be able to receive calls, this is fine. But not to make calls?

#6

What happens exactly when you try to make a call?

Which recorded message do you hear?

#7

I don’t see any RRC Connection requests for it.
Just dial on higher layers of phone.
But I noticed something: there is tau request in ul, tau accept in dl but np tau complete sent by UE in UL. Is it mandatory this TAU complete?
So is TAU complete mandatory to be sent by UE in UL?

#8

You should compare SIB contents of those 2 PCIs.
Maybe S1 HO ping pong in fixed location.
Remember that location too because…this scenario is golden…if some crazy client asks u to do that again.
Hysteria value is there then shouldn’t ping pong so much.
Q hyst value.
But still…might getting L1 hacked on FBS attack who knows.

#9

It is not actually static he moves around his house.

So still lot of ping-pongs and not possible to make calls

#10

Normally yes. Can not think of a reason why the UE will not send it?

#11

I am not trying to optimize the situation. I just need to provide a 3gpp answer of this situation.

In most cases I see there is TAU complete as well.

If anyone could provide a hint to what should I check further it would be great.

#12

Every tracking area update accept also has IE about eps feature support.

Therefore parsing and passing this info to application layer will take some time.

However, in your case it seems there is not much time between tau.

UE has to be ready to disable IMS service if not supported in that TAC,and enable csfb.

1 Like
#13

I should see csfb initiated at least in this case.
But i see nothing.

I know that UE has 10-15 seconds between camping on a cell with a new TAC and sending TAU request.

Does anyone knows what is the name of this core timer of 10-15 seconds?

#14

Not sure if you talking about T3410 which is 15s (attach accept).

& Regarding Tau I think:
T3430 for tau request (ue will start)
Between tau accept & tau complete it’s T3450 (6s)

1 Like
#15

Thanks a lot!

#16

There will be no csfb because in TAU update network is not changing anything.

But calls with TAU every 2-3 seconds is an odd scenario.

What about data part, is there any bearer handling traffic?

#17

Check t320 in rrc conn rel.

Also check the TAU Accept whether that has IMS eps bearer active or not, next would be to check if there is any additional mm cause in tau accept like #18

Or #16

#18

Thanks for the tips.

Here are my answers:

  • There is no T320 in RRC Connection release.

  • TAU accept has only one EPS bearer active EBI5.

  • There are no additional causes in TAU accept like 16 or 18.

In first case of failure there is T320 = 180 min in first RRC connection release and UE goes to idle and does not initiate call for VoLTE as per scripts.
And all the other consecutive dial attempts are failing.
But what T320 has to do with failures? This is for Idle mode mobility management.

How is T320 affecting NAS layers that seem not to initiate the call?

#19

If there is reselection priority, that is valid till t320 and UE shall not go to lower priority earfcn till then.

In case there is load balancing tau required in rel, the UE can send TAU to new cell.

Mainly check if the IMS bearer is active in TAU accept and no mm cause 16 or 18 in it.

#20

I do not get how this can impact VoLTE call initiation. Can you elaborate?