RAN5 kindly asks CT1 to confirm if the RAN5 assumption is correct.
|
|
C1-111637
|
LS on Automatic re-attach following TAU reject or Service Request reject (R5-110835)
|
RAN5
|
To
|
Reply LS in C1-111964
Related Tdoc in C1-111700.
During the review of CR R5-110395 RAN5 couldn’t reach a consensus on whether the UE should use the existing NAS signalling connection or establish a new signalling connection to perform the re-attach
following reception of Service Reject with cause #9. Similar situation exists for the cases Service Reject with cause#10 and TAU reject (both normal and combined) with causes #9, #10 and 40 for Rel8 UEs. RAN5 has decided to allow both options in the test cases covering these scenarios as a temporary solution and to seek guidance from CT1 on expected UE behaviour. The solution to allow both behaviour has been implemented as per of CR R5-110775.
The following positions were expressed during RAN5 discussion:
- It has been pointed out that some commercial NWs and UE manufacturers have already implemented the possibility to re-use the NAS signalling for these use cases and the fact to remove this possibility would lead to user experiencing longer out of service experience, more signalling (release and establishment of radio bearer) and processing in the UE (e.g. cell selection). Therefore RAN5 should consider both implementation since Rel-8 commercial NWs were already launched and UE were already supplied..
- It was highlighted that the possibility to use the existing NAS Signalling connection could lead to a race condition in which the UE attempts to use the existing NAS signalling connection to perform the re-attach procedure while the network initiates RRC Connection Release.
RAN5 would like to confirm with CT1 if the possibility to re-use ongoing NAS signalling connection to re-attach is compliant with the core specification or if it shall be removed from the test cases defined to cover the use cases described above.
|
