Provisional allocation of documents to agenda items

1.2 Discussion
SA2 has discussed different ways to achieve unidirectional bearers, including the possibility to remove the stage 2 description of unidirectional bearers or change the UEs uplink traffic mapping logic. However, such proposals have not been agreed in SA2.
SA2#84 discussed an example of an uplink packet filter the GGSN/PGW could provide to the UE to avoid having the UE sending any useful uplink packets towards bearer meant to be unidirectional (i.e. as the network might drop those packets).

SA2 understanding is that the packet filter would still need to be “valid” as UE otherwise (in case a filter blocking all IP flows is used) may reject the network request with a semantic error (extract from 24.008):

c) Semantic errors in packet filters:

1) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the network determines a semantic error in a packet filter is outside the scope of the present document.

The network shall reject the activation request with cause "semantic errors in packet filter(s)".

The MS shall reject the activation request with cause "semantic errors in packet filter(s)".

SA2 understanding is that CT1 has not covered unidirectional bearers in stage 3 and would therefore like to ask the following.
Question: SA2 would like to ask CT1 and CT3 for guidance on how to effectively achieve unidirectional bearers without impacting the UE, considering the above description.

SA2 would kindly like CT1 to answer the above questions.

		C1-111823	LS on Clarifications for MM Back-off Timer (S2-112219)	SA2	To	Noted Reply LS in C1-112100 ===== extract from LS ============== For the general NAS congestion control scenario the SGSN/MME may reject Mobility Management Request Signaling by sending Attach Reject/RAU/TAU Reject messages with MM Back-off Timer. For the Network Mode of Operation 1 (combined registration) case some questions were raised in SA2 on the applicability of the MM Back-off Timer to the PS domain only or to both the PS domain and the CS domain. There were questions on the expected behaviour of the MS/UE also when MM Back-off timer is running. The following is the summary of the discussions: For the combined registration case, if the UE experiences general NAS congestion control, that should not trigger a change of its Network Mode of Operation. That is, it should not try to attach to the CS domain if it experiences PS domain congestion. It is SA2’s understanding that the current status is that if the PS domain is overloaded the MM Back-off timer is returned in the ‘reject’ message, without taking into account the overload status of the CS domain. Many companies in SA2 consider it important that the receipt of the MM Back-off Timer from the SGSN/MME should not cause the MS to initiate MM signalling with the CS domain. Stated another way, overload in the PS domain should not cause an increase in CS domain signalling and consequent overload of the CS domain as well. For the non-combined registration cases, the MM Back-off Timer received from the SGSN/MME should only apply to the 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. The applicability of the congestion control features to the CS domain was informally communicated from SA2 to CT1 and CT4 in August 2010 by an email between the Chairmen. It was also more formally recorded in the LS from SA2 to GERAN in S2-104220 (attached). As noted in those communications, SA2 is not responsible for the stage 2 specifications for the CS domain. SA 2 kindly requests CT1 and, if necessary CT4, to take the above into account in the development of their specifications. Delegates from many companies in SA2 have indicated their willingness to discuss this jointly with CT1 and CT4, potentially in a conference call taking into account the strict timescales for the completion of NIMTC work in rel.10, the requirements for congestion control features in the CS domain.
		C1-111953	LS on applicability of the extended wait time per CN domain	RAN2	To	Noted Reply in C1-111966 Upon CN congestion and for delay tolerant accesses, the network may reject or release the UE using the RRC Connection Reject and/or Release message which may contain an Extended Wait Timer. RAN2 would like to receive some guidance and clarifications with regards the relationship between the extended wait timer and the CS/PS domain concept. For this purpose, we would appreciate if SA2 and CT1 could answer the following questions: Does the Extended Wait Timer in NAS run per CN domain? If the answer for question a) is yes: Is it expected that in case a signalling connection is already established with one CN domain, and (during the established RRC connection) a NAS-requested signalling connection establishment to the other CN domain is rejected (due to high CN load), the signalling connection to the first CN domain remains, while the signalling connection with the second CN domain is rejected with Extended Wait Timer? In case that a RRC Connection Release is sent to the UE including the Extended Wait Timer, does NAS expect an indication from the AS of the concerned CN domain, or is NAS able to decide this based on NAS-internal CN domain status information? RAN2 kindly asks to SA2 and CT1 to answer the questions presented in the discussion above.
		C1-111968	Reply LS on MTC USIM requirements for Release 10	CT6	CC	Noted CT6 has noted that SA3 would like to move the requirement “The network operator shall be able to restrict the use of a USIM to specific MEs/MTC Devices”, and work on possible solutions to meet this requirement to Rel-11. CT6 will therefore work on the solutions in Rel-11. CT6 would like to inform that it has discussed three mechanisms for ME/MTC Device-USIM binding, which can be used separately or as a combination in order to provide a scalable solution from a security point of view: PIN verification pairing, USAT application pairing (IMEISV based solution), Secure Channel pairing (pre-shared keys based solution). In their LS S3-110556, SA3 asked questions that CT6 would like to answer: Question 1: Will the solutions discussed in CT6 allow restricting the use of a USIM to one ME/MTC Device or more than one MEs/MTC Devices, especially to a large number of MEs/MTC devices? Answer: All solutions allow for binding a USIM to one or a large number of ME/MTC devices. The number of restricted MEs/MTC Devices is dependent on preconfigured/OTA-provisioned USIM and ME/MTC parameters.