Provisional allocation of documents to agenda items

Actions:

To SA1 and CT6.

ACTION: SA3 kindly asks SA1 and CT6 to take the above information into account about moving related work from Release 10 to Release 11.

SA3 kindly asks CT6 to give feedback on the two questions.

		C1-111662	LS reply to CT1 on Support of incremental cost information in AoC-D (S5-111442)	SA5	To	Noted. Tdoc in C1-111615 is related. Reply from SA5 to LS from CT1 in C1-110652. SA5 thanks CT1 for their LS on Support of incremental cost information in AoC-D. SA5 would like to confirm that the solution proposed by CT1 is acceptable, and that the AoC incremental cost can be calculated as the difference between the subtotal costs of the currently received AoC-D information and the subtotal costs of the last received AoC-D information. SA5 confirms that the AoC information elements listed in 3GPP TS 24.647 v10.1.0 Annex C is aligned with TS 32.280.
		C1-111663	Liaison statement from IEEE P802.11	IEEE P802.11	To	Noted Action to be taken as necessary. =========== extract from LS =========== IEEE 802.11 would like to inform 3GPP CT and SA, that IEEE 802.11u (Interworking with External Networks) was completed and published on 25^th February 2011. You are kindly invited to update your references to this standard, within 3GPP documents, as follows: “IEEE Std 802.11u™-2011 Standard for Information technology - Telecommunications and information exchange between systems -Local and metropolitan networks - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 9: Interworking with External Networks.”
		C1-111664	LS on the decision of maximum codec mode from b=AS (S4-110534)	SA4	CC	Noted LS to CT3 and RAN2 Author: Samsung / Kyunghun Jung 1. Overall Description: During SA4#64, SA4 discussed how to set the b=AS bandwidth parameter and possibly the b=TIAS bandwidth parameter for speech and video. SA4 specifications contain recommendations for how to set the b=AS parameter, defined as application-specific maximum bandwidth, by the terminal for particular codecs, but operators can influence the terminal behaviour by supplying other values as management objects to the terminal. SA4 specifications do not yet contain recommendations for b=TIAS bandwidth values, which is defined as transport independent application-specific maximum bandwidth. Annex B of TS 26.236 introduces examples to compute b=AS for voice and video codecs. In the case of video, b=AS is computed assuming a fixed media bit-rate and a fixed amount of encoded video data in bytes per packet, regardless of the frame type, i.e., independent or predicted. Since video encoder controls the quantizer or frame rate, to reduce the fluctuation of bit-rate, b=AS in this definition can be considered as the average media bit-rate plus RTP/UDP/IP headers. In the case of voice, the output bit-rate of AMR or AMR-WB encoder fluctuates depending on voice activity, i.e., ranging from speech frame, SID, and no transmission. The method in TS 26.236 to compute b=AS for AMR assumes one speech frame encapsulated into an RTP packet in bandwidth-efficient mode. In this definition, b=AS can be considered as the maximum media bit-rate (not taking into account the reduction due to speech pauses) plus RTP/UDP/IP headers. In Annex A of TS 26.114, b=AS values computed assuming this method, but in octet-aligned mode, are included. Detailed procedures to compute b=AS for AMR and AMR-WB can be found in the attachment. 2. Discussion: Concerns were raised by some companies that the answerer could interpret b=AS differently than intended by the offerer and thus send undesired media:  For video, as long as the offered b=AS is allowed by service policy, the highest quality codec supported by both the offerer and the answerer is likely to be selected. In other words, b=AS is unlikely to impact the selection of video codec, with enough capability at the offerer and the answerer.  However, voice codecs have different bit-rate ranges and in case the offerer and the answerer apply different methods to compute b=AS, session negotiation may result in configurations not preferred by the offerer or the answerer. For example, the offerer may compute b=AS based on the maximum bit-rate assumptions as in TS 26.236 while the answerer calculates b=AS assuming average bit-rate (taking into account reduction due to speech pauses) plus some margin to avoid overflow. In this case, a b=AS value may be understood by the offerer and the answerer as different codec modes. SA4 discussed if the b=AS value could be set taking into account the statistical saving effects of speech pauses (b=AS recommendations in SA4 specifications currently do not take into account these effects). It was pointed out that since b=AS is mapped to MBR, computation of b=AS for voice as in TS 26.236 might over-reserve the resource and have an impact on VoIP capacity, especially when MBR=GBR. However, several companies expressed the opinion that PCC would expect b=AS values not taking those effects into account. It would rather be up to the radio network resource management to take corresponding savings into account. SA4 also discussed if b=TIAS could be used to indicate a different bandwidth (apart from IP/UDP/RTP header overhead, which is not included in b=TIAS, but is included in b=AS), i.e., to restrict the maximum codec modes in this manner, or to correct the statistical effects described above possibly included in the b=AS value. However, concerns were raised that PCC would expect that all these parameters are set to corresponding values, as it depends on the operator and the implementation options which parameter is used to derive the reserved bandwidth, but the resulting bearer and reserved bandwidth should be appropriate for the services irrespective of these different options. Also, if the optional interpretation of codec specific information is performed by PCC, PCC would assign information derived in that manner a higher priority than information derived from b=AS and b=TIAS bandwidth information. Further, SA4 discussed a scenario where an MTSI terminal sends an offer for AMR-WB without a mode-set parameter, thus allowing all modes up to the highest mode with 23.85 kbit/s bandwidth, and the answer contains a mode-set parameter, e.g., restricting modes to some modes up to 12.65 kbit/s. b=AS settings would then differ between offer and answer, but only the bandwidth contained in the answer is required in both directions, as the mode-set in the answer is applicable in both directions. Concerns were raised that PCC might then reserve different bandwidths for uplink and downlink based on the different b=AS values (While this behaviour is appropriate for codecs that can use different bandwidths in opposite directions, it is not always appropriate for AMR and AMR-WB). Actions to CT3: 1. SA4 would like to ask CT3 to clarify if PCC expects that the statistical effects of video (due to motion activities) and speech (due to pauses) are included in b=AS bandwidth values. 2. SA4 would like to ask CT3 to clarify if PCC expects that b=TIAS, b=AS and codec parameters are all set to corresponding values, and how PCC interprets those parameters. 3. SA4 would like to ask CT3 to clarify the PCC behaviour for the case where the bandwidth in the SDP answer is reduced compared to the offer due to a corresponding reduction of the AMR or AMR-WB mode set (Will the same or different bandwidth be reserved for uplink and downlink?). Actions to TSG RAN2: 1. SA4 would like to ask RAN2 to clarify whether statistical effects of video (due to motion activities) and speech (due to pauses) are assumed to be included or excluded in MBR and GBR values, as received from the core network.
		C1-111665	Reply LS on MTC Planning and Prioritization (SP-110218)	SA	CC	Noted Action to be taken as necessary. SA suggest to commence work on SIMTC. =========== extract from LS =========== TSG SA #51 has considered prioritization of work on the SIMTC work item. SA concluded that work will be organized in building blocks as proposed by SA2 (in SP-110054/S2-111219). Hence, corresponding 3GPP Working Groups are kindly requested to focus their efforts within SIMTC on the following Building Blocks: