Actions to 3GPP TSG CT WG1.
Provide guidance on how to handle NAS Signalling Connection in case of Service Reject with causes #9, #10 and TAU reject (both normal and combined) with causes #9, #10 and #40.
|
|
C1-111638
|
Reply LS to MSG on eCall testing deliverables (R5-110880)
|
RAN5
|
CC
|
Noted
Answer from RAN5 to LS from ETSI TC MSG (C1-110433 noted at CT1#69).
GERAN3 answer available in C1-111625.
No action for CT1.
|
|
|
C1-111639
|
LS on Response on LS on “Wide area sensor and/or actuator network (WASN) systems” (RT-110024) and on “Quality of Service requirements and objectives for wireless access systems” (RT-110025) (S1-110248)
|
SA1
|
CC
|
Withdrawn
Already handled in CT1#70 as C1-111142
LS is on SA1 feedback to ITU-R Ad Hoc on queries ITU-R Ad Hoc ask of 3GPP on the topic of " Quality of Service requirements and objectives for wireless access systems" and " Wide area sensor and/or actuator network (WASN) systems".
|
|
|
C1-111640
|
Reply LS on the interaction between ISRP and ISMP (S2-111006)
|
SA2
|
To
|
Withdrawn
Treated at CT1#70
|
|
|
C1-111641
|
Reply LS on MSC server assisted mid-call feature (S2-111152)
|
SA2
|
To
|
Noted
Author: Alcatel-Lucent / Richard Ejzak
This issues got resolved at last CT1 meeting already. No need for further actions.
SA2 thanks CT1 for their LS on MSC server assisted mid-call feature.
SA2 concluded that an MSC Server enhanced with MSC server assisted mid-call feature will also need to be enhanced for ICS and successfully register the UE in IMS to enable the UE to remove/add participants from/to an IMS conference call after the access transfer.
SA2 has not done any separation of the different MAM feature into sub features. Hence, stage 3 specifications should include a statement that, to enable the UE to remove/add participants from/to an IMS conference call after an access transfer, the network should be provisioned so that all MSC servers in the potential service area of the UE support ICS I2 procedures and that the ICS flag in the HSS be enabled for the UE.
SA2 has also concluded that neither the SCC AS nor MSC server needs to perform additional checks to attempt to verify network provisioning in support of successful ICS I2 registration for the UE.
Thus specifications needs to include MSC server procedures to handle the case when ICS I2 registration procedures are not attempted or successfully completed after access transfer with the MSC assisted mid-call feature enabled.
Actions to CT1: SA WG2 asks CT WG1 to take the above into consideration when completing the specifications for the MSC server assisted mid-call feature.
|
|
|
C1-111642
|
Reply LS on Simultaneous registration of a single private identity from different Ues (S2-111153)
|
SA2
|
CC
|
Noted
LS to SA3 and SA1
Author: Interdigital / Milan
SA WG2 kindly thanks SA WG3 for their analysis on simultaneous registration of a single private ID from different UEs and the detailed observations on the use of the authentication mechanisms supported by "Common IMS" with the "shared IMPI" feature. SA WG2 would also like to thank SA WG3 for the attachment on "Shared IMPI in IMS, comments on CR in S3-101302" (S3-101389).
For the question of whether there is a typical number or a maximum number of UEs sharing an IMPI, SA WG2 does not have any strong opinion. It was felt that a response from SA WG1 to this question would be more appropriate.
SA WG2 will await for the further studies on NBA and SIP Digest use with "shared IMPI" to be concluded before deciding on if the "shared IMPI" feature requires further architectural requirements to be specified.
Actions to SA WG1: SA WG1 are kindly asked to comment on whether there is a typical number or maximum number of UEs sharing an IMPI (family use case or enterprise use case).
|
|
|
C1-111643
|
Reply LS on identifying sessions targeted for access transfer (S2-111154)
|
SA2
|
To
|
Noted
Author: Samsung / Haris Zisimopoulos
Are there papers related to this? At least C1-111620 seems related)
Related papers in C1-111804 - 09
Question to SA2: Single Radio VCC:
CT1 has been discussing how the SCC AS and the SRVCC capable UE can get the same view as to whether a session is subject to SRVCC, i.e. is anchored in the SCC AS. Two options have been discussed, but no agreement has been made. The proposals are:
1. To indicate this explicitly in signalling (e.g. in the signalling from the SCC AS towards the UE) that a session is subject to SRVCC, i.e. anchored in the SCC AS
2. To let the UE derive the information that a session is subject to SRVCC (i.e. that it has been anchored) from existing signalling, i.e. the SC UE learns that a session is subject for SRVCC from the fact that it is an audio session and the audio is transported over a PS bearer with QCI-1 (or with traffic and source statistics descriptor ="speech")
Do you believe that 2) is possible or do we need a solution based on 1)?
Answer:
SA2 believes that solution 2) is possible and is already supported by existing specifications. When SRVCC is enabled, QCI-1 (or with traffic and source statistics descriptor ="speech") can only be used for IMS speech sessions subject to SRVCC according to TS 23.216. SA2 is reviewing the need to further clarify the above solution in the relevant specifications through rel.10. SA2 wants to clarify also that the text in sections 4.2 and 4.3 of TS 23.216:
For facilitating session transfer (SRVCC) of the voice component to the CS domain, the IMS multimedia telephony sessions needs to be anchored in the IMS.
is not a normative requirement and should not be interpreted that only MMTEL sessions will be anchored in IMS/SCC AS. In fact any sessions that will be subject to SRVCC based on HPLMN operator policy determined by iFCs need to be anchored on IMS/SCC AS.
Question to SA2: Dual Radio VCC:
CT1 have been discussing similar issues with dual radio VCC (DRVCC).
• Does the SC UE need to get an explicit indication that the session has been anchored in the SCC AS; or
• Can the SC UE deduce whether the session has been anchored in the SCC AS from the characteristics of the session?
Answer:
SA2 believes that an explicit indication is not needed even in the case of Dual Radio VCC since the UE initiates the session transfer and the UE can assume that the relevant sessions will be anchored in IMS/SCC AS.
Actions to CT1: SA2 asks CT1 to take the above information into account.
|
|
|
C1-111644
|
LS reply on GBR and MBR definition (S2-111180)
|
SA2
|
CC
|
Noted
Reply LS from SA2 to RAN3 LS (C1-104504 noted at CT1#68).
SA2 thanks RAN3 for their LS on GBR and MBR definition (R3-103110) and discussed the issue during SA2#83.
From the SA2 perspective, it was concluded that TS 23.401 defines the bit rate values of GBR, MBR and UE AMBR (signalled to the eNB over S1) already sufficiently well in Section 4.7.3:
“The GBR and MBR denote bit rates of traffic per bearer while UE-AMBR/APN-AMBR denote bit rates of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component. On S1_MME the values of the GBR, MBR, and AMBR refer to the bit stream excluding the GTP-U/IP header overhead of the tunnel on S1_U.”
SA2 kindly ask RAN3 to check if the clarification provided above is sufficient to resolve this issue in RAN3.
|
|
|
C1-111645
|
LS reply on Applicability of Handover restriction list for CSFB (S2-11181)
|
SA2
|
CC
|
Noted
|
