A UE that is connected to a domain in which it is possible for the UE to make calls, should use that domain to make an emergency call.
RAN2 would like clarify the intention of the sentence with SA1.
RAN2 asks SA1 "if support IMS Emergency calls is mandatory for a UE supporting IMS voice calls from Rel-9."
C1-111631
SR-VCC from LTE to UMTS (R2-112624)
RAN2
To
Reply LS in C1-111961
=========== extracts from LS ===========
RAN2 has discussed and confirmed how the inter-RAT/Intra-UMTS SR-VCC procedure should work and would like to share the understating with RAN3 .... (and SA2 and CT1).
For SR-VCC, in RRC (TS 25.331), IE SR-VCC Info (containing NONCE) and IE RAB info to replace are signalled to UE and target RNC receives these parameters from source RNC in the Source RNC to Target RNC Transparent Container defined in TS 25.413
For LTE to UMTS/GSM SR-VCC, to avoid any impacts to the target RNS/BSS, the target RNC/BSS does not provide these parameters to the UE because the necessary parameter is provided in the source side.....PS RAB in the source LTE, which is replaced with CS RAB, is implicitly indicated to UE because the QCI value of this bearer for VoIP will be always “1” and NAS layer indicates QCI for the bearer.
==============end of extract ============
RAN2 ask to RAN3 to consider their part in 25.413. RAN2 ask CT1 (and SA2) if "Using QCI=1 to determine PS bearer to be replaced due to LTE to UMTS/GSM SR-VCC" is workable.
C1-111632
LS on PLMN and CSG whitelist handling in H(e)NB (R2-112637)
RAN2
To
Reply LS in C1-111962
The RAN CRs can be found in C1-111958
Related CT1-CRs in C1-111725-27
At RAN2 #73bis meeting the inconsistencies between RAN2 and CT1/SA2 specifications, and between UMTS and LTE RAN2 specifications has been discussed.
As a result the following agreements have been made in order to align the RAN2 specifications:
1) For membership check during UE based mobility (i.e. IDLE and UMTS PCH), the UE shall consider the CSG-Id part of all broadcast PLMN's.
Note that suitability check will only consider rPLMN/sPLMN/ePLMN as indicated already in 25.304/36.304, i.e. only if (rPLMN/sPLMN/ePLMN, CSG-Id) is in the whitelist, the cell will be considered suitable.
2) In connected mode when the UE is asked to report member/non member, the UE considers itself member only if the rPLMN is broadcast by cell and (rPLMN, CSG-Id) is in the UE's whitelist.
3) Proximity should only be reported if there is a possibility that a UE membership check could indicate "member".
RAN2 is aware that RAN sharing is not supported in the CN. RAN2 would like to confirm with CT1 whether the above agreements are aligned with CT1 understanding and specifications and whether any issues may arise from the agreements for the non-RAN sharing case. It remains to be seen whether the above will also work for the RAN sharing case.
RAN2 would also like the opinion of SA2 whether for (2) the UE should also consider itself as a member if the cell broadcasts ePLMN, CSD-ID which is in the UE whitelist.
Further, RAN2 would like to confirm to GERAN the understanding in [1] that it is sufficient for the UE to report the primary PLMN ID of the target CSG/hybrid cell as part of the handover procedure.
The attached CRs were agreed in principle in order to correct the specifications to address the agreements.
