Provisional allocation of documents to agenda items

Question 2: How is the operator able to enforce the restriction in CT6 solutions, or is the enforcement done only on the device?

Answer: How the operator is able to enforce the restriction depends on solution in the following way:

1. 
   In solution 1 by pre-configuring PIN on both USIM and ME/MTC device.
   
2. 
   In solution 2 by pre-configuring IMEISV range on the dedicated file on the USIM
   
3. 
   In solution 3 by storing pre-shared keys on ME/MTC device and USIM.
   

For all the solutions above, the USIM enforces the restriction.

		C1-111969	Reply LS on eCall testing deliverables	CT6	CC	Noted In their LS' GERAN3 and RAN5 mention that CT6 is required to clarify ways how to change the eCall modes dynamically, e.g. how an eCall capable UE which is set to eCall only mode can be reconfigured to permit access to additional subscribed to services. According to TS 31.102, clause 5.3.40.1 (eCall Only Support) an eCall capable UE is set to eCall only mode if the following conditions are met: Services n°2 (FDN) and n°89 (eCall Data) are available in the EFUST (TS 31.102, clause 4.2.8) and Services n°1 (FDN) is enabled in EFEST (TS 31.102, clause 4.2.47) and EFFDN contains only two numbers, the eCall test and the eCall reconfiguration numbers According to TS 31.102, clauses 5.3.40.1 and 5.3.40.2 (eCall and Normal call support) an eCall capable UE is set to eCall and normal call mode if the following conditions are met: Services n°4 (SDN) and n°89 (eCall Data) are available in EFUST and Service n°2 (FDN) is not available in EFUST and/or service n°1 (FDN) is not enabled in EFEST and The last two entries of EFSDN contain the eCall test and the eCall reconfiguration numbers One way the eCall mode can be controlled is by enabling or disabling FDN in EFEST if the services SDN, FDN and eCall data are all indicated as available in EFUST. As an update of EFEST is possible via PIN2 the enabling or disabling of FDN can be done via different means provided by the UE, e.g. an MMI (if available) or AT commands. Another alternative would be to update the eCall related EFs via Over The Air (OTA) updating (see TS 31.115 and TS 31.116) and a consecutive REFRESH command (see TS 31.111) which informs the UE about this update. CT6 hopes to have met GERAN3's and RAN5's request for clarification and is looking forward to further fruitful cooperation.
		C1-111970	LS on usage of EF_ACL for EPS Network	CT6	To	Reply LS in C1-111980 TS 31.102, section 5.3.14, indicates that the ME must check the value of the APN against a list stored in the EF_ACL on the USIM before requesting a PDP context activation from the network, when the corresponding service is available on the USIM. The same mechanism does not apply in the case of an EPS Network due to the different sequence used for the PDN Connectivity Request with a given APN value. As a result, the current specification is unclear and might cause different interpretations and behaviours. On an EPS network, the ME performs the ATTACH procedure without passing an APN value and can set the flag "ESM Information transfer" on. Later on, the ME indicates the APN value as part of the ESM Information Response. In the case where the ACL service is available on the USIM, TS 31.102 currently does not indicate if the ME needs to check if the "network provided APN" is contained within EF_ACL before the ATTACH or if the APN value that is passed later in the ESM Information Response is contained within EF_ACL or if both need to be contained within the EF_ACL. CT6 discussed to modify TS 31.102 as per the attached file (C6-110252), requiring the ME to check if the APN value that is passed later in the ESM Information Response is contained within EF_ACL and to not proceed if this condition is not true. CT6 asks CT1 to provide guidance on the issue mentioned above and confirm which value the ME must check to perform a PDN connection.
		C1-112155	Reply LS on Clarifications for MM Back-off Timer	CT4	To	Noted Reply from CT4 on C1-111823 (intended CT1-reply in C1-112100 The MCC will check if the attachments are missing or if they should not be referred to. CT4 has agreed stage 2 CR to TS 23.012 to add a CS Mobility Management back-off timer. This requires updates to TS 24.008 and CT4 understands that such a CR is being addressed by CT1. This solution then resolves the concern that the requirements for congestion control are not limited to PS domain: " The work in 3GPP TR 23.888 on Core Network overload control has not been restricted to the PS domain only. Many MTC devices use the CS domain. Therefore, some companies in SA2 think that the congestion control features can also be used by the MSC as well as by the SGSN. " This does not specifically address point a) in the LS and CT4 leaves this issue for CT1 to discuss. If a combined registration is denied due to PS congestion and this were to result in a subsequent NMO II (CS only) Location Update/Attach request the CS domain has a mechanism to stem an overload. The interactions between the SGSN and MSC and any interpretation by the UE of the PS back-off timer for NMO I are not described. It is assumed that this needs further description in TS 23.060 since this is where the NMO I stage 2 procedures for the SGSN are described but again CT4 believes this is something for CT1 to address with SA2. In addition CT4 has agreed stage 2 updates to extend the periodic LAU timer as described in TR 23.888.
		C1-112224	LS on New ATIS ESIF Issue 72, Comparison of SIP Profile for IP Network Interface (INI) for Emergency Services with SIP Profiles in related NNI specifications for CT4 review and input	ATIS ESIF	(forwarded from CT4)	Noted It was commented that any response to this LS should be coordinated with CT4.