Provisional allocation of documents to agenda items

3GPP TSG CT WG1 Meeting #51 Was C1-080001

Puerto Vallarta, Mexico, 28^th of January – 1^st of February 2008 CT1#51_Chairmans-Report

Meeting documents by agenda item Meeting: CT1 #51 in Puerto Vallarta, Mexico 28^th of January – 1^st of February 2008
Cyan background means allocated but not available tdoc number		Yellow background means available but not yet treated document					White background means that the document has been handled in the meeting and decision has been made
Agenda item	Agenda item title	Tdoc	Title	Source	Spec.		Result
1	Opening Monday at 09.00		Opening & welcome
							Reminder to Individual Members and the persons making the technical proposals about their obligations under their respective Organizational Partners IPR Policy: I draw your attention to your obligations under the 3GPP Partner Organizations' IPR policies.  Every Individual Member organization is obliged to declare to the Partner Organization or Organizations of which it is a member any IPR owned by the Individual Member or any other organization which is or is likely to become essential to the work of 3GPP
2	Agenda & Reports Monday
		C1-080001	Agenda	CT1 chairman			Noted
		NB! The agenda items for Tuesdays and Thursdays WIs are in general split in “legacy / SAE” WIs versus “pure IMS” WIs. The agenda is tentative, and some WIs may be moved based on amount of contributions on Rel-7 versus Rel-8. Rel-7 is now functionally frozen, which hopefully will limit the number of rel-7 corrections. If Mondays or Wednesdays agenda can be completed in due time, documents for Thursday morning may be shifted to let Thursdays split-sessions start at 09.00. Alternatively, leftover-documents from Monday, Tuesday or Wednesday may be shifted to Thursday. Due to issues on common IMS (specifications coming from TISPAN and the WS with 3GPP2) there are a bit more papers than normally. Agenda may be shifted to handle all contributions. Agenda overview Monday 09.00 Agenda item 3; Incoming LSs - 24 Tdocs Agenda item 8.1; PCC - 4 Tdocs Agenda item 8.2; EMC1 (IMS & access) - 4 Tdocs Agenda item 8.3; ServID - 7 Tdocs Agenda item 8.4; MTSI - 3 Tdocs 14.00 Agenda item 9.18; 3GPP2 alignment - 16 Tdocs Agenda item 8.8; EVGCS / IVGCS / VGCSflex - 2 Tdocs Agenda item 8.9; VCC - 0 Tdocs Agenda item 8.10; CSItermS / CSICS - 0 Tdocs Agenda item 8.11; SMSIP - 0 Tdocs 18:00 Agenda item 9.13; TISPAN Maint (& redoc) - 38 Tdocs Tuesday Tuesday - Main 09.00 Agenda item 9.2; SAES – issues - 76 Tdocs 16.00 Agenda item 5.1, 6.2, 7.2, 8.14.2; Non-IMS WIs (upto and including Rel-7) - 4 Tdocs Agenda item 8.7; SDoUE - 2 Tdocs Agenda item 8.13; NSP-CR - 2 Tdocs Tuesday – IMS-breakout 09.00 Agenda item 6.1, 7.1; IMS Rel-5 & Rel-6 (IMS-CCR, IMS2, PRESNC) - 18 Tdocs Agenda item 8.5; IMSprotoc - 20 Tdocs Agenda item 8.6; GRUU - 0 Tdocs Agenda item 8.12; FBI / FBIpcbl - 0 Tdocs Agenda item 8.14.1; Other IMS rel-7 WIs - 0 Tdocs Agenda item 9.3; PRIOR-MM - 0 Tdocs Agenda item 9.4; MRFC - 3 Tdocs Agenda item 9.12; Overlap - 0 Tdocs Agenda item 9.14; NBA - 1 Tdocs Wednesday Agenda item 9.1; Rel-8 documents for information - 8 Tdocs Agenda item 9.10; PNM - 25 Tdocs Agenda item 9.5; UUSIW - 0 Tdocs Agenda item 9.6; PktCbl-Intw - 1 Tdocs 14.00 Agenda item 9.13; TISPAN Maint (& redoc) recap - tbd Tdocs Agenda item 9.16; IMS SS (CCBS&CW) - 23 Tdocs Agenda item 9.7; PktCbl-Deploy - 0 Tdocs Agenda item 9.8; PktCbl-Sec - 2 Tdocs Thursday Thursday – Main 09.00 Agenda item 9.19.1; IMS rel-8 WIs - 8 Tdocs Agenda item 9.19.2; Non-IMS rel-8 WIs - 8 Tdocs 11.00 Agenda item 9.9; EVA - 1 Tdocs Agenda item 9.15; PPACR - 1 Tdocs Agenda item 9.2; SAES – issues (cont.) - tbd Tdocs Revisions of Tuesdays WIs. Thursday – IMS-breakout 11.00 Agenda item 9.11; IMSProtoc2 - 19 Tdocs Agenda item 9.17; OAM7-Trace - 4 Tdocs IMS-issues from Mon- Tues- & Wednes- day (cont.) - tbd Tdocs Revisions of Tuesdays WIs Friday 09.00 Agenda item 10; Outgoing LSs Agenda item 4.1, 4.2; WP and other adm. issues Rest of revisions 16.00 Latest closing time The indicated times are approximate and given to somehow distribute time evenly between WIs. If WIs are not finished by the given time, we will get back to these WIs at a later time. The agenda may also be altered for other practical reasons.
3	Input Liaison statements Monday			Source	To / CC
		C1-080017	Reply to LS on Stage 2 Documentation Principles for SAE Specifications	TSG CT WG4	To	Noted CT4 views on the “Stage 2 Documentation Principles for SAE Specifications”. CT4 is also if the opinion that it will be useful to keep the message and parameter names aligned across stage 2 and stage 3.
		C1-080018	Reply LS on LS on ICSI and IARI allocation for GSMA defined IMS Services	TSG CT	CC	Noted Reply to C1-080040 As MMTEL is a specific service that is documented in 3GPP specifications, 3GPP TSG CT would appreciate more background information on how GSMA considers that “the new services (Image Share and Video Share) would fall within the MMtel service classification”. Enhancements to the MMTEL service must be performed by 3GPP by enhancing the relevant 3GPP specifications. On the registration of the URN format of the IARI for Image Share and Video Share, these new services seem to be aligned with the URN formats for the Service Identification framework (urn:urn-xxx:3gpp-service.ims.icsi.___ and urn:urn-xxx:3gpp-application.ims.iari.___). Consequently the URN-format urn:urn-xxx:3gpp-application.ims.iari.gsma-is seems appropriate, but this is left to the registration process for final decision. 3GPP TSG CT would suggest that GSMA follow the registration process as outlined in www.3gpp.org/tb/Other/URN/URN.htm and provides the 3GPP TSG CT WG1 secretary with the appropriate information for the registration. The progress for the “-xxx ” part of the URN is dependent on the status and the progress of draft-drage-sipping-service-identification. The draft is currently in state: Waiting for Writeup :: Revised ID Needed according to the statuses IETF has for their internet drafts. On the last question on format of ICSI and IARI for services and applications that GSMA might define, 3GPP TSG CT was of the opinion that establishing itself as a central point of control for this would be useful, at least at present. Consequently the 1^st option for this, as documented in CP-070859, is preferred. 3GPP TSG CT would however note that an LS is not necessary for registration of URNs, it is sufficient to sent the 3GPP TSG CT WG1 secretary an e-mail with the necessary information as outlined above.
		C1-080019	Response LS on future co-operation with IEEE 802	TSG SA WG2	CC	Noted SA2 discuss closer cooperation (possibly a face-2-face meeting with IEEE 802.11
		C1-080020	Response to LS on signalling for paging	TSG SA WG2	CC	Noted SA replies to RAN2 and RAN3 on issues on signalling for paging.
		C1-080021	Reply LS on IP Fragmentation	TSG SA WG2	CC	Noted Reply to CT4 on issues for IP Fragmentation.
		C1-080022	Reply LS on UE specific paging DRX	TSG SA WG2	CC	Replaced by C1-080330
		C1-080023	TAU in Connected Mode	TSG SA WG2	To	Reply LS in C1-080392 During SA2#61 the need for the TAU procedure in connected (i.e., LTE_ACTIVE) mode was discussed. On the one hand, it was mentioned that the eNodeB change during handover can be regarded as similar to an RNC change in UTRAN after which a RAU is performed even in active mode. On the other hand the TAU procedure is not necessary for the purpose of updating the location information of the UE in the MME since the eNodeB where the UE is located at is also known in connected mode. It was agreed in SA2 that there is the need for a TAU procedure in connected mode in the specific and rare case of Inter eNodeB handover with MME relocation procedure, i.e., when the UE moves to a new MME pool area. It was discussed whether the trigger for this TAU should be that the UE by itself discovers that it has moved to a new TA that has not been registered with the network, or alternatively the network could send an explicit trigger for initiating the TAU procedure in this case. The question was not concluded due to the uncertainties around whether or not TAU is in general performed in connected mode. SA2 is not certain if the TAU procedure shall be used for the purpose of roaming and area restriction handling. If UEs perform the TAU procedure in connected mode, a mechanism is needed in EUTRAN to let the UE know its current TA id, and SA2 was uncertain whether such a mechanism is feasible or not. SA2 note that for IMS signalling purposes, the UE needs to know the current “cell global ID” (or equivalent) to a reasonable time accuracy when establishing IMS sessions while in connected mode, although this time accuracy is currently not specified. SA2 is currently considering two possible approaches for triggering TAU in connected mode: Approach 1 is that the UE is always informed about the current TA id in connected mode, and the UE performs a TAU whenever the current TA id is not included in the list of TAs that are registered with the network, similarly as in idle more. Approach 2 is that the UE in connected mode is triggered to perform TAU only when required, such as in the case of MME relocation. SA2 kindly requests RAN2, RAN3 and CT1 to provide feedback on the two approaches discussed above.
		C1-080024	Reply LS on piggy-backed Service Request	TSG SA WG2	CC	Noted SA2 assume that the S-TMSI will have 40 bits. SA2 is sending a related LS on Identities which gives more information on Globally Unique Temporary IDs and MME IDs and its relation with the S-TMSI. SA2 notes RAN2’s desire to include the Service Request’s NAS information (excluding S-TMSI) within 32 bits, and that the consequence of not achieving this is to increase delay. However, SA2 would appreciate clarification as to whether, if the 32 bit limit cannot be achieved, is it worth trying to keep the size below 40 bits, or, is the next ‘step size’ at 56 bits, etc? And how much will the delay be influenced? In addition, SA2 like to know what additional information elements are provided via S1 from eNodeB to MME, e. g. Radio Access Priority used by the UE. SA2 notes RAN2’s comment that the Service Request will now “be handled as other NAS messages”. SA2 is a bit confused by this statement. SA2 feels that RAN2’s description of the Service Request message handling indicates that it will be handled in a significantly different manner to other NAS messages. SA2 would appreciate clarifications in this area and more details of the exact proposed solution. CT1 asked whether there is a requirement to transfer the NAS messages Attach Accept and Attach Complete piggybacked with the RRC messages Radio Bearer Establishment Request and Radio Bearer Establishment Response, even if the combined RRC+NAS messages could not fit in a single RRC frame. SA2 describes piggybacking for the S1 interface radio bearer messages and the transfer of the related NAS messages. This combining of the radio bearer establishment with the transfer of the related NAS messages on S1 intends to avoid that two related activities (NAS and radio bearer handling) arrives as independent events in the eNodeB. This allows for more efficient RRC and S1 interface operation. The handling on RRC, e.g. combining into a single RRC message or using separate messages is in the scope on RAN2. SA2 kindly asks RAN2 to take the above into consideration and provide feedback to SA2, SA3, and CT1.
		C1-080025	LS on EPS Identities	TSG SA WG2	To	Noted SA2 wish to inform other 3GPP working groups that they have updated the TS 23.401 description of the UE’s temporary identity and included the description of identifiers for the MME. The “core” of the change is in the attached S2-075726. SA2 believe that these changes help the separation of the “paging area description” (e.g. the list of Tracking Areas), which is used by the UE to determine whether to do a Tracking Area Update, from the “globally unique temporary UE identity” (c.f. TMSI plus LAI), which is used within and between Core Network entities. SA2 also see some other benefits of this structure of identities. In the appendix to this LS, SA2 indicate some possibilities for the mapping of these new identities into legacy signalling. SA2 assume that the S-TMSI will have 40 bits. SA2 kindly requests RAN WG2, RAN WG3, CT WG1, CT WG4 and SA WG3 to take the above into account and provide feedback if necessary.
		C1-080026	LS on Earthquake and Tsunami Warning System	TSG SA WG2	To	Noted Earthquake and Tsunami Warning System (ETWS) is the system for notifying the emergency alert to users via 3GPP RAN (i.e. UTRAN/GERAN and LTE), when earthquake and tsunami symptom is detected. ETWS requirements have been developed in SA1 and TS22.168 has been sent to SA #38 for Information. ETWS contains two types of notification. One is a high optimised Primary notification, which needs to be transmitted to a UE within four seconds. Primary notification is particularly useful for Japanese civilians who are anyhow trained regularly for natural disasters. The second is the Secondary notification, which contains more information than the primary. SA2 have started its work on ETWS Stage 2, and decided to propose updating WID (the attached S2-07xxxx) so that SA2 can start investigating feasible solutions and complete specification work within the Release 8 timeframe. UTRAN/GERAN aspects of ETWS SA2 have briefly discussed the working assumption of UTRAN/GERAN aspects of ETWS, and identified that there are several possible solutions. These may be based on existing CBS procedures or MBMS or something more improved for example enhancing paging method to quickly deliver ETWS indication and remotely activate CBS/MBMS. EPS aspects of ETWS E-UTRAN is also within the scope of ETWS. SA2 have realised that possible solutions will be based on eMBMS and/or define a new mechanism. Security aspects of ETWS SA2 noted that mechanisms to prevent spoofing and replay attacks are highly important. SA2 appreciate if CT1 and SA1 take this into account in their further Release 8 work.
		C1-080027	Response LS on EPS Mobility Management (EMM) sublayer state machine in UE	TSG SA WG2	To	Noted SA2 has discussed the CT 1 LS in S2-074943 (= C1-072537) and has agreed to update TS 23.401 with the attached S2-075457. In order to help the adoption of CT1’s two dimensional model, SA2 has retained the EMM terminology for the 24.008 “EPS Mobility Management” states but has adopted the terminology “EPS Connection Management” (ECM) for the “connection modes”. SA2 has noted that the informative annex A to 3GPP TS 36.300 might need updating to align with agreements reached in SA2 and CT1. SA2 kindly asks CT1, RAN2 and RAN3 to take note of the above information and provide feedback if necessary.
		C1-080028	LS on Network Discovery & Selection	TSG SA WG1	CC	Noted SA1 would like to inform SA2 that SA1 has substantially progressed the requirements on Network Discovery & Selection since LS S1-071227 (= S2-073112) from SA2 had been received. The enhancements are covered in the CR to TS 22.278 on "Enhancements to Access network discovery and steering of access", attached to this LS. Also, SA1 would like to inform IEEE 802.11u group on this activity since we understand that related work on "Generic Advertisement Services" is ongoing in your group and you may want to keep in touch with 3GPP on that subject.
		C1-080029	Reply LS on Registration in Densely-populated area – clarification on some technical issues	TSG RAN WG2	CC	Noted RAN2 would like to thank SA2 for their LS in S2-074810 on “Registration in Densely-populated area – clarification on some technical issues”. RAN2 has studied the impact of alternative solution 1 in TR23.880 as requested. From RAN2 perspective, the changes required are notification of XAI(PLMN ID＋LAC＋RAC＋XAC) in relevant places. As RAN2 specs stands today, LAC and RAC is already provided to UE via transparent container, whose length can go up to 8 octets. 3 of these containers are defined: one for each CN domain (and the container for PS domain contains RAC), and one common to both CN domains (which contains LAC). It is foreseen that XAC will be provided in a similar manner, inside one of these containers. These containers are included in System Information (for idle mode UEs), as well as in reconfiguration messages (for connected mode UEs). The exact message format inside these containers is defined in TS24.008, which is under CT1 responsibility, and they should decide which container to include XAC, and whether remaining part of 8 octets is big enough for inclusion of XAC. (For information, it seems only 2 octets are used for any of the containers at the moment). However, it should be noted that even if 8 octets is not big enough, extension to these containers could be defined in Rel-8 if necessary. RAN2 also believes that RAN3 spec, namely TS25.413, is impacted by the introduction of XA concept. Therefore, the alternative solution1 seems feasible with limited impact to RAN2 specs. RAN2 does not have any questions or concerns on alternative solution 1 at this stage.
		C1-080030	Reply LS on CSG Cells Handling	TSG RAN WG2	To	Noted RAN2 would like to thank 3GPP TSG CT WG1 for the LS on CSG Cells handling. RAN2 can provide the following responses to the questions from CT1: