Provisional allocation of documents to agenda items

Does RAN2 have a definition of TA code or TA identity in their specifications? Does RAN2 have a definition of Cell Identity in their specifications?

RAN2 has agreed that both the TA identity and the cell identity are included in System Information Block Type 1. However, the details of these information elements have not been agreed yet. For further information, see TS 36.331, 6.2.8.3.

2. 
   CT1 considers it is the responsibility of RAN2 to decide length of Cell Identity and CT1's will then take responsibility for the TAC. Do RAN2 specifications impose any constraints on the length of Tracking Area Code? Is there a relationship between the size of the TAC and the size Cell_Identity?
   

The split of responsibilities for TAC and Cell Identity as mentioned above is in line with RAN2’s understanding.

RAN2 specifications do not impose any constraints on the length of the TAC but of course a long TAC will increase the size of the SIB.

RAN2 has not discussed yet the size of Cell_id or its relationship with TAC.

In UTRA the TA identity is regarded as NAS information carried in an information container separate from the cell identity. In this approach, there neither are constraints regarding the size of the TAC nor is there a relation with the (size of the) cell identity. It is possible that a similar approach will be adopted in E-UTRA.

3. 
   RAN2 mention that CSG TA identities are independent from the non-CSG TAs. Is the only difference the size of the TA identities or do CSG TAs and non-CSG TAs also have differing structures and/or formats?
   

RAN2 has not yet discussed the relative sizes, structures or formats of CSG TA and non-CSG TAs. ,But In line with the previous response, RAN2 assumes that CT1 can proceed with the (size of the) CSG TAC identity independently from the work on the cell identity in RAN2.

		C1-080031	Reply to LS on NAS handling during intra-LTE handover	TSG RAN WG2	To	Reply LS in C1-080399 RAN2 would like to thank 3GPP TSG RAN WG3 for the LS on NAS handling during intra-LTE Handover. RAN2 has reviewed the LS and can provide the following response. RAN2 view is that the eNB should not send a failure indication over S1 if the message was attempted for delivery to the UE even if the eNB is not sure about the receipt of the message by the UE. Based on the above, in response to the question: whether it is foreseen that the eNB attempts to successfully deliver NAS PDUs, once the delivery has started, even if a (time) critical HO is pending ? RAN2 considers this then to be an implementation issue in the eNB. This behaviour will eliminate the possibility of duplication of NAS messages and hence avoids the need for any mechanism to handle duplicates. RAN2 understand that there is a very small risk that a NAS message might not be delivered during a HO but is of the opinion that this should provide acceptable performance. But RAN2 also observed that the NAS messages will probably carry a sequence number for NAS integrity protection and it may be possible for NAS to easily implement duplicate handling should it happen without much additional effort. CT1 to take note of RAN2’s response and inform RAN2 of any comments.
		C1-080032	LS on ”Principles on Idle Mode Signalling Reduction”	TSG RAN WG2	CC	Noted RAN2 would like to thank SA2 for their LS on ”Principles on Idle Mode Signalling Reduction”. RAN2 has discussed the proposed solution in the attachment of the above mentioned LS. RAN2 understood that the main principle of the solution is that the location registrations are separately handled in different RATs. During the discussion, the following questions with regard to the maintenance of location registration (i.e. periodic location update) were raised. Q1) Is the periodic location update handled completely independently by each RAT, or does a location update in one RAT result in a location update in the other RAT? Q2) If the periodic location update is handled independently, will there be any impact on the UE cell reselection behaviour (i.e. UE in RAT-a has to reselect to RAT-b in order to perform a periodic location update in RAT-b)? Q3) In more general, how are the location registrations of different RATs or different domains maintained in the network and how are they “mirrored” in the UE NAS? Please note that it is a strong preference of RAN2 that the solution should not require access to another RAT than the RAT the UE is camping. RAN2 kindly ask SA2 to provide answers to the questions above.
		C1-080033	LS on Access Class barring	TSG RAN WG2	CC	Reply LS in C1-080393 During RAN2#60, RAN WG2 agreed to apply the following principle for access control (Access Class barring) in LTE: Instead of indicating a 1 bit barring status per AC for ACs 0-9 as in UMTS, a single barring rate (a percentage value) that commonly applies to ACs 0-9 is broadcast in system information. The UE draws a random number when initiating connection establishment and compares with the current barring rate to determine whether it is barred or not. If the result is barred, a random backoff is applied. For ACs 10-15, the same principle as in UMTS is applied. (This is based on Alt.2 in R2-074000.) The decision was made primarily in order to avoid frequent changes of system information. For example, if the operator wants to suppress the traffic by a certain percent due to congestion, the traditional UMTS approach would incur the barring status to be updated (rotated) periodically, so that barring is fair among all the UEs. As an update in system information invokes paging signalling to indicate the change and triggers re-reading of the system information by the UE, some companies were concerned about this inefficiency. Hence to resolve this problem, the above mechanism was agreed. Furthermore, RAN WG2 agreed to apply the following principle: LTE will include 1 bit in system information to indicate whether the AC barring status applies to mobile originating calls only or to both mobile originating and terminating calls. This 1 bit indicator applies commonly to all ACs 0-15. This is to support the PPAC concept as have been indicated in the LS RAN WG2 has received from SA WG2 [1]. RAN WG2 kindly requests SA WG1 to take into consideration the above RAN WG2 agreements. Moreover, SA WG1 is requested to update the relevant specifications (e.g., TS 22.011) as appropriate to reflect these agreements. If there are other requirements related to DSAC or PPAC, RAN WG2 would appreciate to be informed about them. RAN WG2 kindly requests CT WG1 to take into consideration the above agreements in RAN WG2.
		C1-080034	LS on CSG related mobility (stage2 text)	TSG RAN WG2	CC	Noted It was agreed by RAN2 that the inbound mobility towards CSG cells is based on a UE autonomous search function in IDLE as well as CONNECTED mode. Therefore the UE is responsible to start the search for suitable CSG cells by itself and in case measurement gaps are required it might indicate the need towards the network (which might grant gaps or not). This search procedure may be independent of the RAT the UE is currently camping on. It was also agreed that the UE autonomous search could be assisted by the network (e.g. in deployment scenarios which are planned by operators – e.g. enterprise or campus deployments). It is FFS if the procedure to minimize the search activity to the geographical area where a suitable CSG cell is located should be standardized or if this is completely left for UE implementation. Furthermore it is up to other groups to decide if performance requirements shall be defined. For outbound mobility from CSG cells it has been decided that this is based on normal mobility procedures as for macro cells. The mobility between CSG cell of the same or different CSG groups is for further study. The agreed text proposal for the stage2 (TS 36.300) is attached to this LS. ACTIONS: RAN2 kindly requests SA1 discuss service related requirements for mobility from macro cells into CSG cells. E.g. is there a max. time until a UE shall be camping on or connected to a suitable CSG cell if present. This could be different for IDLE and CONNECTED mode as the complexity is also very different. It may also be different for the cases of CSG cells on the same RAT as the serving one or CSG cells on a different RAT. RAN2 kindly asks RAN4 to discuss if any radio related performance requirements shall be defined for the inbound mobility into CSG cell or if this can be left for UE implementation. It could also be appropriate to distinguish between IDLE and CONNECTED mode. RAN2 kindly asks GERAN to take this RAN2 decision into account and provide feedback if such an approach is also feasible in a CSG cell is deployed over GERAN coverage or if there are other preferences by GERAN how inbound mobility to CSG cells should be supported ? Specifically RAN2 kindly asks GERAN to summarize impacts if GERAN shall support the mechanisms above. E.g. detection and measurements of “unplanned” E-UTRAN neighbour cells, allocation of (potentially larger) gaps for reading of complete (unique) cell ID and handover to “unplanned” E-UTRAN cells."
		C1-080035	Reply on LS on Area and Access Restrictions	TSG RAN WG3	To	Reply LS in C1-080394
		C1-080036	[Draft] Reply LS on SIB enhancement feasibility for PPAC	TSG GERAN	To	Noted TSG GERAN noted the contribution, which was attached to the incoming liaison, describing one feasible solution approach and understands that the proposed enhancement is to provide two additional independent information elements allowing paging response and allowing location registration. TSG GERAN briefly discussed the proposal and as part of the discussion the following points were noted: There is limited space available in the System Information messages sent on the BCCH and as such any proposed solution should take this into account and minimise the data sent on the broadcast channel. It was unclear to TSG GERAN why there was a need to separate control of paging response and location registration. It was understood that the main aspect of the feature is to allow a mobile to respond to a page, when access control restrictions are in force, and it was suggested that including an indication in the paging message itself, that the mobile was allowed to access the network to respond to the page, might be a better solution for GERAN Finally, TSG GERAN has not had any inputs to propose changes to the specifications under TSG GERAN responsibility but will be happy to consider such inputs when provided.
		C1-080037	Reply LS on Registration in Densely-populated area – clarification on some technical issues	TSG GERAN WG2	CC	Noted TSG GERAN WG2 has reviewed Solution Alternative 1 “Multiple registration area with new registration area (XA)” in TR 23.8xx. TSG GERAN WG2 would like to make the following comments: As of today, no such problem as for UMTS has been identified for GSM that would require additional specification work in TSG GERAN If some problem exists in UMTS networks, then a common solution for GSM/UMTS should be looked into for the case of shared Location Areas between GSM and UMTS Any solution must work and be compatible with legacy terminals (GSM, UMTS, GSM/UMTS) in the field Any solution requiring new terminals (such as alternative 1 requiring the introduction of new eXtra Area – XA) will not resolve existing problems with legacy terminals (GSM, UMTS, GSM/UMTS) in the field Further investigations into the issue may be done by TSG-GERAN.
		C1-080038	LS on Downlink Dual Carrier capability signalling for DTM	TSG GERAN	To	Noted The CR is split off to C1-080395 CR#1166 The Release 7 Downlink Dual Carrier capability information has been formerly included in the Mobile Station Classmark 3 information element with the aim to inform the access network of this capability at uplink access for DTM operation. However the knowledge by the access network of this capability is only needed when establishing a downlink transfer, in which case the information is provided through the MS Radio Access Capability information element. 3GPP GERAN therefore agreed to remove this capability from the Mobile Station Classmark 3 information as proposed in the attached Draft CR to TS 24.008 for the reasons described herein. TSG GERAN kindly asks TSG CT WG1 to review and approve the proposed changes in the attached draft CR to TS 24.008.
		C1-080039	LS regarding service invocation for Application Initiated Sessions	MSF Protocol and Control WG	To	Reply LS in C1-080396
		C1-080040	LS on ICSI and IARI allocation for GSMA defined IMS Services	GSMA	CC	Noted Questions from GSMA on ICSI & IARI values.
		C1-080041	LS from TISPAN to 3GPP – reply on empty SIP INVITE	TISPAN WG3	To	Reply LS in C1-080397 Further questions on SIP INVITE with “empty SDP”. Related T-docs in C1-080301 and 302
		C1-080330	Reply LS on UE specific paging DRX	TSG SA WG2	CC	Noted SA2 would like to thank RAN2 for their LS on UE specific paging DRX in R2-074594 (S2-074952). SA2 would like to point out that since there may be different types of terminals accessing E-UTRAN. Some of the UEs may be sensitive to the power consumption while others not. Some of the UEs may want to receive paging quickly while others don’t. It seems beneficial to support UE specific paging DRX in E-UTRAN.
		C1-080336	LS on algorithm input and output	TSG RAN WG2	CC	Noted RAN2 provides answers and asks some further questions on “algorithm input & output”.
		C1-080337	Reply LS on Paging Permission with Access Control	TSG RAN WG2	To	Noted RAN2 has calculated the possible size of system information if enhancement concept 1 or concept 2 of PPAC is applied. (See attachment: R2-080581) As seen in the attachment, either solution is technically feasible. However, RAN2 has not completely understood why paging and mobility management has to be controlled separately. As for any other solutions, following alternatives are considered, but neither of the alternatives is studied in detail in RAN2. : Discard the paging in the network in order to reduce the load due to paging response, while having only one indicator in the system information that indicates to the UE is allowed to perform MM signalling and paging response when access control is in effect Inclusion of necessary parameters in paging (as suggested by GERAN)
		C1-080338	LS on Assumptions about UE security capability	TSG RAN WG2	CC	Noted During RRC Ad-hoc meeting in December 2007 discussion on UE capability transfer took place and the following was proposed: UE AS security capabilities are derived by EPC from the UE NAS security capabilities received in the initial NAS message at attach. Information that may include the list of supported ciphering and integrity algorithms (based on derived AS security capabilities) is then provided to the eNB by MME. Based on the received information, eNB can select a suitable algorithms and activate security accordingly. The above proposal was taken as a working assumption provided that following is confirmed by SA WG3: AS/NAS UE Security capabilities are the same Security capabilities received from MME can be trusted Even in case AS/NAS capabilities differ, as long as AS capabilities are handled on NAS level (UE sends up both NAS and AS capabilities that are verified by the CN when NAS security is started), RAN2 would like to confirm the basic principle where MME sends down the “AS security capabilities” to eNB. Due to the above RAN2 has some questions ot SA3.
		C1-080339	LS on removal of transparent NAS container on BCCH	TSG RAN WG2	To	Reply LS in C1-080398 Following the discussion of the attached document during the RAN2 LTE RRC adhoc of December 2007, RAN2 sees some benefits to handle the TAC as an AS IE in the SIB. RAN2 only discussed how the information should be transferred over the radio and it is clear to RAN2 that still the definition of the TAC and the specification of the handling in the UE is the responsibility of CT1. As described in section 2.2.2 of the contribution, RAN2 doesn’t see any other potential IEs that need to be included in the NAS container identified at this time. Therefore RAN2 sees some benefits with removing the flexible NAS container and would like to ask CT1 opinion on the matter. RAN2 kindly requests CT1 to check RAN2 assumptions and to consider if they could agree on the removal of the variable length RRC NAS container for LTE.
		C1-080340	Reply LS on UE specific paging DRX	TSG RAN WG2	To	Noted RAN2 would like to thank SA2 for the reply LS on UE specific paging DRX in R2-080492 (S2-075832), in which SA2 asked the following question. SA2 would like to ask RAN2 to take the above into consideration and whether there is significant additional complexity in the RAN. RAN2 has discussed the LS and understood that the Tracking Area Update procedure is used to provide a paging DRX cycle to the UE. Provided that this understanding is correct, RAN2 does not see significant additional complexity from RAN perspective. Then it was questioned during the discussion whether the UE specific paging DRX is always provided by a Tracking Area Update procedure or not. If not, RAN2 thinks that a common default paging DRX cycle will have to be signalled in the system information broadcast. Thus, RAN2 would like to ask the following questions. Q1) Is the UE specific paging DRX always provided in a Tracking Area Update procedure? Q2) If the answer to the Q1 is no, does SA2 see the need for the default paging DRX to be cell specific? Please note that RAN2 does not see strong need for a cell specific paging DRX.
		C1-080341	Reply LS on outstanding NAS messages	TSG RAN WG2	CC	Noted RAN2 discussed the LS and could not at this time identify from RAN2 point of view any case where there would be an uncertainty on which NAS message triggered the AS SMC. RAN2 can hence provide the following response to the questions: Question 1: Is it correct that the UE can be sure which NAS Service Request message triggered AS SMC (i.e., will the UE and the MME always be able to derive the AS keys from the same uplink NAS sequence number). RAN2 response: Yes, from RAN2 point of view. Question 2: Is it correct that the UE can be sure which Attach Request message triggered the attach (i.e., will the UE and the MME always be able to derive the AS keys from the same uplink NAS sequence number). RAN2 response: Yes, from RAN2 point of view. However, RAN2 also noted that RRC SMC does not have the severe size limitation of the uplink Initial direct transfer NAS message and hence it would appear to be possible to echo the NAS sequence number. But from a RAN2 perspective, it is desirable to keep the messages smaller. Further, it was not clear to RAN2 how the proposed solution works for inter-system handover to LTE where the security in LTE is expected to be activated as part of the HO procedure before any NAS message transfer over LTE.
		C1-080342	Reply on LS on Area and Access Restrictions	TSG RAN WG2	CC	Noted RAN2&3 discuss issues with Area and Access Restrictions
		C1-080343	LS on Paging Repetition	TSG RAN WG2	To	Noted RAN2 has discussed the paging repetition scheme and has liaised with RAN3 on this issue. RAN3 responded (R3-072414): The MME sends a PAGING message to each eNB belonging to the tracking area(s) in which the UE is registered. At the reception of the PAGING message, the eNB shall perform paging of the UE in cells which belong to the tracking areas indicated in the PAGING message. RAN3 has discussed whether paging repetition should be performed in the E-UTRAN as well but concluded that the RAN3 preference is that no paging repetition is done by the eNB itself. For information, SA2 has concluded that the MME has the function of paging retransmission. With paging repetition from the MME, it is assumed that the MME can optimize its repetition timer if it knows that no repetition will be done by the radio. In addition, paging repetition in EUTRAN will lead to a waste of radio resources on the paging channel, as pages will be repeated in the cells in the TA where the UE did not respond to the page. RAN2 agrees with the RAN3 response. TSG RAN2 kindly ask TSG SA2 and TSG CT1 to take note of the RAN3 and RAN2 views and provide feedback if necessary.
		C1-080344	Reply LS on piggy-backed Service Request	TSG RAN WG2	CC	Noted RAN2 would like to thank SA2 for the reply LS on the piggy-backed Service Request and would like to provide following additional clarifications: 1) With respect to the Service Request Size, RAN2 would like to inform that the smaller the size the better the HARQ performance will be. Thus there is no “step size” and it is difficult to assess the impact of additional bits on the delay. 2) RAN2 did not understand what is meant with “Radio Access Priority used by the UE”, but would like to point out that the contents of the S1 message are more related to RAN3 than to RAN2. 3) Regarding the handling the Service Request as other NAS messages, the RAN2 would like to clarify that even though there are differences between different procedures (e.g. the transmission of the S-TMSI for Service Request), the current RAN2 solution means that Service Request will be a true NAS message and AS will not modify or look into it.
		C1-080345	LS on handling of an uplink NAS message at intra-LTE handover	TSG RAN WG2	To	Reply LS in C1-080399 At RAN2#60bis, the issue of the handling of an uplink NAS message at intra-LTE handover has been discussed. RAN2 assumes that probability of an uplink NAS message loss due to mobility is less than 1%. And RAN2 concluded that for an uplink NAS message for which the reception is not confirmed by the eNB at intra-LTE handover, the UE AS will not retransmit it but only informs the UE NAS that the reception of the uplink NAS message has not been confirmed by the eNB. RAN2 would kindly like to ask CT1 if there would be any problem or concern on the decision above.
		C1-080346	Reply LS on completion of TR 24.880 and recommended architecture changes for AS/MRFC media control	TSG SA WG2	To	Noted SA2 thanks CT1 for informing them on the work they have done on AS-MRFC media server control protocol and for sending the related WID and TR. SA2 has discussed the question raised by CT1 and has concluded that AS-MRFC media server stage 2 specification work should be done in CT1 according to the recommendation, i.e. the creation of a new 'Cr' reference point between the AS and the MRFC. SA2 asks CT1 group to perform the stage 2 work for the AS-MRFC media server, and to keep SA2 informed of the progress of the specification work in order for SA2 to update the specifications under their control accordingly.
		C1-080347	LS on addressing suppression of services during Call Back from PSAP	TSG SA WG2	To	Noted SA2 is, in relation to IMS emergency, addressing a new requirement from SA1 related to the use of the user's Directory number/MSISDN for emergency calls, i.e., It shall be possible to supply the user’s Directory Number/MSISDN as the CLI to the PSAP to facilitate call-back. The SA1 requirements applicable for IMS core network also requires that if the incoming call can be identified by the core network as a call-back to an emergency call then terminating supplementary services shall not be executed. SA2 has discussed how to address this for Rel-8. A solution for suppression of supplementary services during call back using the Directory number must work both for emergency registrations as well as normal registrations. SA2 concluded that the preferred way to solve this is to ensure that the IMS system will receive an indicator in SIP that the call back is related to emergency and originates from a CS or IP based PSAP. For the case of call-back from CS based PSAP, SA2 proposed that the MGCF will receive an indicator in the ISUP/BICC signalling and will do the appropriate mapping to the SIP signalling or insert the indicator based on other means (e.g., path of entry information). The insertion of the indicator in ISUP/BICC as such is seen as a matter of the regional ISUP/BICC system used. SA2 recognizes that the resolution of the issue may require support from other SDOs, e.g., ITU and IETF. Impacts on PNM as a result of suppression of supplementary services need to be considered. CT1 is asked to take the above information into account and start working on a protocol solution for an emergency call-back indicator that can be used to indicate emergency call back from a PSAP. CT3 is asked to take the above information into account and is asked to provide mean for mapping in the MGCF of emergency call-back indicator for call back.
		C1-080348	Reply to LS on Network Initiated PDP Context	TSG SA WG2	To	Reply LS in C1-080400 Related with C1-080042, 054 -056 + 199 SA2 kindly thanks CT1 for the LS on Network Initiated PDP Context. In the LS the following session establishment scenario was considered: UE A wants to set up a multimedia session with UE B and therefore sends an INVITE request towards UE B As UE A has all required resources already available, UE A indicates the SDP preconditions as "met" The GPRS access network of UE B indicated to UE B, that media PDP contexts will be initiated by the network Upon receipt of the INVITE at the B side, the B-side network is not yet able to establish the related PDP context, as it does not know which of the media parameters (m-lines / codecs) will be selected by UE B. SA2 has discussed about the problem pointed out by CT1 and found out the problem with the short session setup exists even in the case the UE initiated PDP context is used. This applies to Rel-7 and Rel-6 UEs which implement the short IMS session setup flow and networks that implement PCC. In case of network initiated PDP context activation, the problem occurs regardless the usage of PCC. SA2 agrees that a mechanism in which the SDP answer is made available earlier to the network could solve the problem. SA2 would like to confirm with CT1 if a protocol based solution is possible for both scenarios i.e. UE and NW initiated PDP context. Based on CT1 result, SA2 will evaluate whether interim fixes are required and can be based on the CT1 output or on different mechanisms e.g. PCC. SA2 kindly asks CT1 to work on the issue and to provide SA2 with an early indication on the feasibility of a protocol based solution.
		C1-080349	LS on inter-MME load balancing, Attach/TAU/Service Request procedures and corresponding RRC/S1 connection establishment procedures	TSG SA WG2	To	Reply LS in C1-080401
		C1-080350	Reply on Reply LS on Area and Access Restrictions	TSG SA WG2	CC	Noted SA2 reply on issues with Area and Access Restrictions
		C1-080351	LS on outstanding NAS messages	TSG SA WG3	To	Reply LS in C1-080402
		C1-080367	LS on Network Discovery & Selection	TSG SA WG1	CC	Withdrawn Same as C1-080028 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-080368	Support of Turkish alphabet characters for the Short Message Service	GSMA	To	Reply LS in C1-080404 The CR is split off to C1-080403 CR#0016 New coding will extend the 160 characters. The topic has been discussed before and the service requirements have been discussed before. Concerns that more characters will be put in due to other countries being in a similar situation. GSMA kindly asks CT1 to consider the proposed CR for the Turkish alphabet characters for approval at this meeting and hence to be included in specifications after CT Plenary #39. GSMA feels that a solution to the requirement is needed in this meeting cycle to allow manufacturers to be able to meet the regulatory time constraints in place in Turkey.
		C1-080541	LS on SAE Interworking with Pre-REL8 system	CT4	To	Presentation of the LS would be useful