3GPP TSG CN WG1										Tdoc N1-99569
Sophia Antipolis, France
June 01-04, 1999										

ETSI STC SMG2	  Tdoc SMG2 736/99 
Meeting no 31 	Agenda item 7.1.5.3 
Tucson, Arizona, United States 
31 May – 4 June, 1999	Revised Tdoc SMG2 733/99

Source:       SMG2 WPA	

To:              SMG3 WPA/ TSG CN1

CC:              SMG12	

Answer to the Liaison Statement on SoLSA exclusive access

SMG2 WPA thanks SMG3 WPA/ TSG CN1 for their comments to the LS on SoLSA exclusive access, Tdoc N1-99371. SMG2 WPA would like to give the following answers to the comments raised in the document.
1)	The answer to the comment presented in section 1 is covered in the Liaison Statement from SMG12 to SMG3 WPA/ TSG CN1 (Tdoc C-99-496).
2)	The answer to the comment presented in section 2 is covered in the Liaison Statement from SMG12 to SMG3 WPA/ TSG CN1 (Tdoc C-99-496).
3)	SMG2 WPA agrees that there is a potential problem with the limited space in the list of forbidden PLMNs. If there are more than 4 forbidden PLMNs (including the “escape PLMN”), the list can not store all of them and the MS may make some unnecessary registration attempts. ITU has however allocated both an MCC and MNC for the “escape PLMN” (MCC=901 and MNC=08), which means that only one more PLMN is required for SoLSA exclusive access.
4)	It should be noted that only MSs that do not understand the exclusive access bit, will add the “escape PLMN” on the list. Increasing the list for future MSs do not solve the problem with existing MSs.
5)	The CR has been elaborated with corresponding changes in the Routing Area Updates message for GPRS, see attached CR 04.08 A528 r1.
6)	The CR has been updated to refer to the ME capability instead of the MS capability, see attached CR 04.08 A528 r1. 
Due to the time schedule for SoLSA, SMG2 WPA hope that the CR can be approved by SMG3/ TSG CN1 in time for the SMG #29.
Enclosed are Tdoc N1-99371, Tdoc C-99-496 and CR 04.08 A528 r1. 

3GPP TSG CN WG1 / STC SMG3 WPA	Tdoc N1-99371
Sophia Antipolis	
26 – 29 April, 1999	

Source:       [SMG3 WPA]	

To: 	            SMG2 WPA
CC:	         SMG12	
Liaison Statement on Response to SoLSA exclusive access 

SMG3 WPA/ TSG CN1 has discussed the liaison statement from SMG2 WPA on “SoLSA exclusive access” and the attached CR A528 to GSM 04.08 in Tdoc SMG2 483/99.
During the discussion of the LS, the following comments were raised:
-	1) The overall stage 2 description of the concept was not clear and not fully understood.  In particular, the actions required in the core network as a result of the proposed change need to be clarified. Also, it is not clear what the impact of the ‘escape MCC’ is on the behaviour of an existing ME not supporting SoLSA.
-	2)	The current status of the code value for “unique MCC (PLMN) escape code” for use by SoLSA exclusive access is not known. It would be useful to know whether a code has already been allocated by ITU or not. In case one is not available have other alternative techniques under GSM’s more direct control been considered to solve the problem e.g. use of cell barred flag or use of single digit Mobile Network Codes?
-	3) A problem resulting from the proposed solution is that there are no requirements for size of the “Forbidden PLMN list” to be greater than 4 in existing MS and it is likely that this will easily be exceeded when the proposed SoSLA solution is introduced as many countries already have several networks.  This will create some adverse problems caused by the “non SoLSA MS ” making unnecessary Location Update requests to previously forbidden PLMNs and may lead to situations where the existing MSs are unable to make any successful call.  This is especially a problem with dual band GSM 900/1800 MS.  The impact of this needs to be considered further. Single digit MNCs would reduce this problem.
-	4) If the “MCC escape code” is kept, then a CR to 03.22 requiring that all new and existing dual band mobiles implement the “extended forbidden list in the ME” seems necessary.
-	5) The MS terminal capability to support SoLSA is signalled in the Location Update message (instead of the MS Classmark) to the MSC/VLR.  As an MS supporting GPRS can perform Routing Area Update and combined Location Area/Routing Area Updates, the corresponding changes for GPRS seem to be missing and need to be elaborated.
-	6) The wording in the proposed CR needs refinement, e.g. to indicate that the new bit refers to the capabilities of the ME and not to the MS.
In view of the above comments SMG3 WPA has not yet agreed the proposed Change Request to GSM 04.08.   One way to progress this matter may to consider alternative simpler solutions (e.g. use of Cell Barred flag etc.), although not ideal, may provide an adequate solution to meet the tight time scales for required for SoSLA.   SMG2 WPA is requested to consider the above issues.

ETSI STC SMG12 	Tdoc SMG12 C-99-496
Sophia Antipolis, France
26 May, 1999	

Source:       SMG12	

To:		SMG3 WPA
CC:		SMG2 WPA	

Answer to the Liaison Statement on SoLSA exclusive access

SMG12 thanks SMG3 WPA for their comments on SoLSA exclusive access. As an answer, SMG12 would like to give some further explanation to the method with an “escape PLMN code”. 
The method with “escape PLMN” was introduced for backward compatibility reasons, in order to prevent old MSs to camp on SoLSA exclusive access cells. The need for this was discussed and agreed on the joint SMG1, SMG2 and SMG12 ad hoc meeting in Edinburgh in March. At this meeting different methods to achieve that goal was discussed. Since many operators (forced by the regulators) require that all MSs shall be able to make emergency calls on these cells, it is not possible to use the Cell Barred flag, as was first proposed. A summary of possible methods, including pros and cons, was presented to SMG12, which recommended the method with “escape PLMN”. That method has been further elaborated by SMG2.
The stage 2 description is updated according to the attached CR 03.73 A006 r1, which has been approved by SMG12. 
A flag in the system information (SI4, SI7, SI8, SI 16, SI17 and PSI3) indicates an exclusive access cell. This will prevent MSs without subscription to that cell to camp on it. The “escape PLMN” is included for old MSs that does not understand the exclusive access flag. Such an MS will consider the cell as belonging to another PLMN. It may try to register to that cell but will be rejected with the cause PLMN not allowed. The “escape PLMN” will be added to the list of forbidden PLMNs and not accessed again. New MSs will however read the correct PLMN in the system information (same as above) and treat the cell as normal.
ITU has allocated the escape PLMN code value, MCC=901 and MNC=08. A CR, defining this specific code, has been issued for 03.03, see attached CR 03.03 A021.

ETSI STC SMG2	Tdoc SMG2 586 /99
Meeting no 31	Agenda item 7. 1.5.3 
Tucson, AZ, USA	
31 May – 4 June, 1999	

CHANGE REQUEST No :	A528_r1	Please see embedded help file at the bottom of this
page for instructions on how to fill in this form correctly.	
	
Technical Specification GSM	04.08	Version:	7.0.0		
	
Submitted to SMG	2	for approval	X	without presentation ("non-strategic")			
list SMG plenary meeting no. here 	for information		with presentation ("strategic")	X		

PT SMG CR cover form is available from. Filename: crf26_3.doc 	

Proposed change affects:	SIM		ME	X	Network	X	
(at least one should be marked with an X)

Work item:	SoLSA – Support of Localised Service Area	

Source:	Nokia	Date: 	990521	

Subject:	Indication of SoLSA compatible mobile station	

Category: 	F	Correction		Release: 	Phase 2		
	A	Corresponds to a correction in an earlier release			Release 96		
(one category 	B	Addition of feature	X		Release 97		
and one release 	C	Functional modification of feature			Release 98	X	
only shall be 	D	Editorial modification			Release 99		
marked with an X)						

Reason for 
change:
	The network needs to know, if the mobile equipment is supporting SoLSA for e.g. exclusive access case. This revised version is updated based on the comments presented in Liaison Statement on SoLSA exclusive access sent by SMG3 WPA to SMG2 WPA.	

Clauses affected:	10.5.3.5, 10.5.5.18	

Other specs	Other releases of same spec		  List of CRs:		
affected:	Other core specifications		  List of CRs:		
	MS test specifications / TBRs		  List of CRs:		
	BSS test specifications		  List of CRs:		
	O&M specifications		  List of CRs:		

Other 
comments:		

10.5.3.5	Location updating type
The purpose of the Location Updating Type information element is to indicate whether a normal updating, a periodic updating or an IMSI attach is wanted. It may also indicate that a follow-on request has been received from the mobile station CM layer. A mobile station shall indicate in this information element, if it is supporting SoLSA.
The Location Updating Type information element is coded as shown in figure 10.5.79/GSM 04.08 and table 10.5.93/GSM 04.08.
The Location Updating Type is a type 1 information element.
   8     7     6     5     4     3     2     1
+-----------------------------------------------+
ª   Location updating   ª FOR ªSoLSAª   LUT    ª octet 1
ª       type IEI        ª     ª ª          ª
+-----------------------------------------------+

Figure 10.5.79/GSM 04.08 Location Updating Type information element

Table 10.5.93/GSM 04.08: Location Updating Type information element
+-----------------------------------------------+
ª LUT (octet 1)                                 ª
ª Bits                                          ª
ª 2 1                                           ª
ª 0 0      Normal location updating             ª
ª 0 1      Periodic updating                    ª
ª 1 0      IMSI attach                          ª
ª 1 1      Reserved                             ª
ª                                               ª
ª FOR (octet 1)                                 ª
ª The Follow-On Request bit (FOR) is coded as   ª
ª follows:                                      ª
ª Bit                                           ª
ª 4                                             ª
ª 0        No follow-on request pending         ª
ª 1        Follow-on request pending            ª
ª 										 ª
ª SoLSA (octet 1)							 ª
ª This bit is used to indicate whether the 	 ª
ª location updating request is sent by a mobile ª
ª station supporting SoLSA or not.			 ª
ª Bit									 ª
ª 3										 ª
ª 0		  non-SoLSA mobile equipment			 ª
ª 1		  SoLSA mobile equipment			 ª
ª										 ª
+-----------------------------------------------+

	***   Next modified section   ***
10.5.5.18	Update type 
The purpose of the update type information element is to specify the area the updating procedure is associated with. 
In addition a mobile station shall indicate in this information element, if it is supporting SoLSA.
The update type is a type 1 information element.
The update type information element is coded as shown in figure 10.5.132/GSM 04.08 and table 10.5.150/GSM 04.08.
	 8	  7	   6	    5	 4	  3	   2	   1		
	Update type
IEI	SoLSA
	Update type value	octet 1	
Figure 10.5.132/GSM 04.08: Update type information element
Table 10.5.150/GSM 04.08: Update type information element

Update type value    (octet 1)

Bits
3 2 1

0 0 0  RA updating
0 0 1  combined RA/LA updating
0 1 0  combined RA/LA updating with 
	IMSI attach
0 1 1  Periodic updating

All other values are reserved.

SoLSA (octet 1)

This bit is used to indicate whether the  routing area updating request is sent by a mobile station supporting SoLSA or not.

Bit
	3
0		  non-SoLSA mobile equipment	
1		  SoLSA mobile equipment