ETSI STC SMG2 Handover ad-Hoc				  Tdoc 22/00
Copenhagen, Denmark, 6 - 8 March 2000		Revised Tdoc RPA000027

Agenda item: 5

Source:	Ericsson, Siemens, 

Title:	Adding UE Capabilities to Handover Required BSSMAP message

Background

This CR proposes to change the HANDOVER REQUIRED BSSMAP message for the handling of the UE Capabilities. These new capabilities for UMTS shall be received similar to MS Classmark 2 and 3 during the establishment of connection in GSM access mode. 
This proposal changes the currently specified handling in the TR 23.814. The TR specifies that UMTS RAN Classmark (i.e. UE Capabilities) must be provided in «Old BSS to New BSS information» transparent field  of Handover Required message, and entirely copied by MSC, in «Source RNC to target RNC» transparent field of Relocation Required message
Discussion

The change is needed to A-interface HANDOVER REQUIRED message to enable the BSS to transfer the UE capabilities to the core network at invocation of the Handover from GSM to UMTS. The core network transfers the information received for the target system UMTS in the Handover Required message transparently to the RRC container IE included in the “Source RNC to Target RNC Transparent Container” IE in the Iu interface RELOCATION REQUEST message.
The BSS receives the UE Capabilities from MS in the Um interface message CLASSMARK CHANGE as proposed in another CR. 
Reasons to change

The BSS shall include UE Capabilities in the HANDOVER REQUIRED BSSMAP message at invocation of the Handover from GSM to UMTS.
The attached CR towards GSM 08.08 describes in details the changes needed to HANDOVER REQUIRED message.

ETSI STC SMG2 Handover ad-Hoc	Tdoc xx/00
Copenhagen, Denmark	   Revised RPA000027
6 - 8 March, 2000
	
CHANGE REQUEST No :	A183 r3	Please see embedded help file at the bottom of this
page for instructions on how to fill in this form correctly.	
	
Technical Specification GSM / UMTS:	08.08	Version	8.2.0		
	
Submitted to SMG	#31bis	for approval	x	without presentation ("non-strategic")			
list plenary meeting or STC here 	for information		with presentation ("strategic")			

PT SMG CR cover form. Filename: crf26_3.doc	

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

Work item:	7.1.5.9	

Source:	Ericsson,  Siemens, 	Date: 	000304	

Subject:	UE capabilities in case of Handover from GSM to UMTS	

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		
only shall be 	D	Editorial modification			Release 99	X	
marked with an X)				UMTS		

Reason for 
change:
	The proposed change will add the UE capabilities for UTRAN to the Handover Required BSSMAP message. The change will enable to transfer these capabilities from BSS to core network at invocation of the Handover from GSM to UMTS.

Clauses affected:	1.1, 3.1.5.1.1, 3.1.19.1, 3.2.1.9, 3.2.2, new 3.2.2.61	

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:		

1.1	Normative references
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
-	References are either specific (identified by date of publication, edition number, version number, etc.) or non‑specific.
-	For a specific reference, subsequent revisions do not apply.
-	For a non-specific reference, the latest version applies.
-	A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same number.
[1]	GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms".
[2]	GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification".
…
[29]	GSM 12.21: "Digital cellular telecommunications system (Phase 2); Network Management (NM) procedures and message on the A-bis interface".
[30]	GSM 12.22: "Digital cellular telecommunications system (Phase 2); Interworking of GSM Network Management (NM) procedures and messages at the Base Station Controller (BSC)".
[31]	GSM 04.18: " Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification, Radio Resource Control Protocol ".
3.1.5.1.1	Generation of the HANDOVER REQUIRED message
Generation of the HANDOVER REQUIRED message can be for the following reasons:
-	The BSS has detected that a radio reason exists for a handover to occur.
-	The MSC has initiated a handover candidate enquiry procedure, and this MS is currently a candidate.
-	A cell change is required at call setup due to congestion, e.g. directed retry.
The HANDOVER REQUIRED message contains the following information elements:
-	Message Type;
-	Cause;
-	Cell Identifier List (preferred).
It should also contain the information elements: “Current channel type 1”, “old BSS to new BSS information” and, in case the current channel mode is speech, "Speech version (used)". 

The “Old BSS to New BSS information” is used to pass Field Elements from the old BSS to the new BSS. The information in the “Old BSS to New BSS information” is transparent for the MSC. When the “Old BSS to New BSS information” is present in the HANDOVER REQUIRED message the MSC shall pass it unchanged to any BSS associated to “Cell Identifier List (preferred)” when initiating the Handover resource allocation procedure. The old BSS must ensure that the information contained in the “Old BSS to New BSS information” information element is valid for all cells in the “Cell Identifier List (preferred)”.

The “Source RNC to target RNC information” is used to pass UE Capability Information Elements from the source BSS to the target RNC. The information in the “Source RNC to target RNC information” is transparent for the MSC. When the “Source RNC to target RNC information” is present in the HANDOVER REQUIRED message the MSC shall pass it unchanged to any RNC associated to “Cell Identifier List (preferred)” when initiating the Relocation resource allocation procedure. The source BSS must ensure that the information contained in the “Source RNC to target RNC information” information element is valid for all cells in the “Cell Identifier List (preferred)”.

3.1.19.1	Definitions of Types of Information Elements
The following definitions shall be used in subclause 3.1.19 and only in this subclause.
Essential Elements
	These are the conditional elements when the condition for their reception is fulfilled, plus the Mandatory elements excluding the Cause value information element (3.2.2.5).
Mandatory Elements
	These are the Information Elements marked as 'M' in subclause 3.2.1.
Non-Essential Elements
	Non-essential elements are all the information elements that are not defined as essential.
Conditional Elements
	In the indicated messages the following elements are conditional:
	Circuit identity code in 3.2.1.1 and 3.2.1.8.
Circuit pool list in 3.2.1.3, 3.2.1.9, 3.2.1.16, and 3.2.1.55.
NOTE:	A conditional IE is an IE whose presence or absence in a message can be determined by information contained in the rest of the message.
Transparent Elements
	The following elements are defined as transparent:
for the BSS:  
TMSI;
	RR cause;
	Layer 3 information in the BSSMAP HANDOVER COMMAND message; and
	Layer 3 message contents; and for the MSC: Resource situation.
	Layer 3 information in the BSSMAP HANDOVER REQUEST ACKNOWLEDGE message; and
“Old BSS to new BSS information” ;
“Source RNC to target RNC information”  in the BSSMAP HANDOVER REQUIRED message

Non-Transparent Elements
	Non-transparent elements are all the information elements that are not defined as transparent.
3.2.1.9	HANDOVER REQUIRED
This message is sent from the BSS to the MSC to indicate that for a given MS which already has dedicated radio resource(s) assigned, a handover is required for the reason given by the cause element.
The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s).
INFORMATION ELEMENT	REFERENCE	DIRECTION	TYPE	LEN	
					
 Message Type	 3.2.2.1 	 BSS-MSC 	 M	1	
 	 	 		 	
 Cause 	 3.2.2.5 	 BSS-MSC 	 M	 3-4 	
 	 	 		 	
 Response Request	 3.2.2.28	 BSS-MSC 	 O	1	
 	 	 		 	
 Cell Identifier List	3.2.2.27 	 BSS-MSC 	 M	2n+3 	
 (Preferred) 	 	 		 to	
 	 	 		7n+3 	
 	 	 		 	
 Circuit Pool List 	 3.2.2.46	 BSS-MSC 	 O (1) 	V	
 	 	 		 	
 Current Channel Type 1 	 3.2.2.49	 BSS-MSC 	 O (2)	2	
					
 Speech Version (Used) 	 3.2.2.51	 BSS-MSC 	 O (3)	2
	
 Queueing Indicator	 3.2.2.50	 BSS-MSC 	 O	2
	
 Old BSS to New BSS Information	 3.2.2.59	BSS-MSC	O	2-n	
 	 	 		 	
 Source RNC to Target RNC   
 Information	3.2.2.62 	BSS-MSC	O	n-m	
 	 	 		 	
1	Shall be included when cause "switch circuit pool" and the MSC allocates the A interface circuit.
2	This information element should always be included.
3	This information element should always be included when the channel mode is speech, and only in this case.
Typical Cause values are:
	uplink quality,
	uplink strength,
	downlink quality,
	downlink strength,
	distance,
	better cell,
	response to MSC invocation,
	O&M intervention,
	directed retry,
	switch circuit pool,
	traffic,
	preemption.
3.2.2	Signalling element coding
This paragraph contains the CODING of the signalling elements used.
The following conventions are assumed for the sequence of transmission of bits and bytes:
-	Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first.
-	In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc.
When a field extends over more than one octet, the order of bit values progressively decreases as the octet number increases.  The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet of the field.
-	For variable length elements a length indicator is included, this indicates the number of octets following in the element.
-	All fields within Information Elements are mandatory unless otherwise specified. The Information Element Identifier shall always be included.
All spare bits are set to 0.
The elements used and their CODING are:
Element 
Identifier 
Coding	
Element name	
Reference	
0000 0001	Circuit Identity Code	3.2.2.2	
0000 0010	Reserved	*	
0000 0011	Resource Available	3.2.2.4	
0000 0100	Cause	3.2.2.5	
0000 0101	Cell Identifier	3.2.2.17	
0000 0110	Priority	3.2.2.18	
0000 0111	Layer 3 Header Information	3.2.2.9	
0000 1000	IMSI	3.2.2.6	
0000 1001	TMSI	3.2.2.7	
0000 1010	Encryption Information	3.2.2.10	
0000 1011	Channel Type	3.2.2.11	
0000 1100	Periodicity	3.2.2.12	
0000 1101	Extended Resource Indicator	3.2.2.13	
0000 1110	Number Of MSs	3.2.2.8	
0000 1111	Reserved	*	
0001 0000	Reserved	*	
0001 0001	Reserved	*	
0001 0010	Classmark Information Type 2	3.2.2.19	
0001 0011	Classmark Information Type 3	3.2.2.20	
0001 0100	Interference Band To Be Used	3.2.2.21	
0001 0101	RR Cause	3.2.2.22	
0001 0110	Reserved	*	
0001 0111	Layer 3 Information	3.2.2.24	
0001 1000	DLCI	3.2.2.25	
0001 1001	Downlink DTX Flag	3.2.2.26	
0001 1010	Cell Identifier List	3.2.2.27	
0001 1011	Response Request	3.2.2.28	
0001 1100	Resource Indication Method	3.2.2.29	
0001 1101	Classmark Information Type 1	3.2.2.30	
0001 1110	Circuit Identity Code List	3.2.2.31	
			
(continued)	

The elements used and their CODING are (concluded):
Element 
Identifier 
Coding	
Element name	
Reference	
0001 1111	Diagnostic	3.2.2.32	
0010 0000	Layer 3 Message Contents	3.2.2.35	
0010 0001	Chosen Channel	3.2.2.33	
0010 0010	Total Resource Accessible	3.2.2.14	
0010 0011	Cipher Response Mode	3.2.2.34	
0010 0100	Channel Needed	3.2.2.36	
0010 0101	Trace Type	3.2.2.37	
0010 0110	Triggerid	3.2.2.38	
0010 0111	Trace Reference	3.2.2.39	
0010 1000	Transactionid	3.2.2.40	
0010 1001	Mobile Identity	3.2.2.41	
0010 1010	OMCId	3.2.2.42	
0010 1011	Forward Indicator	3.2.2.43	
0010 1100	Chosen Encryption Algorithm	3.2.2.44	
0010 1101	Circuit Pool	3.2.2.45	
0010 1110	Circuit Pool List	3.2.2.46	
0010 1111	Time Indication	3.2.2.47	
0011 0000	Resource Situation	3.2.2.48	
0011 0001	Current Channel type 1	3.2.2.49	
0011 0010	Queueing Indicator	3.2.2.50	
0100 0000	Speech Version	3.2.2.51	
0011 0011	Assignment Requirement	3.2.2.52	
0011 0101	Talker Flag	3.2.2.54	
0011 0110	Connection Release Requested	3.2.2.3	
0011 0111	Group Call Reference	3.2.2.55	
0011 1000	eMLPP Priority	3.2.2.56	
0011 1001	Configuration Evolution Indication	3.2.2.57	
0011 1010	Old BSS to New BSS Information	3.2.2.58	
0011 1011	LSA Identifier	3.2.2.15	
0011 1100	LSA Identifier List	3.2.2.16	
0011 1101	LSA Information	3.2.2.23	
0011 1110	Location information	3.2.2.60	
Note.	Source RNC to Target RNC Information	3.2.2.62	
Note. RANAP specified tagging.The coding is defined in relevant RANAP specification TS 25.413.
*	Information Element codes marked as "reserved" are reserved for use by previous versions of this interface specification

3.2.2.62	Source RNC to Target RNC Information

This information element is defined as a general container for passing (e.g. UE Capability Information) RNC specific information transparently through the core network from BSS to RNC via the MSC.

+------------------------------------------------------------+
¦  8     7     6     5     4     3     2     1  ¦            ¦
+-----------------------------------------------+------------¦
¦ Source RNC to Target RNC Information Container¦ octet 1    ¦
+-----------------------------------------------+------------¦
¦ structure and encoding is defined in relevant ¦ octet 2    ¦
+-----------------------------------------------+------------¦
¦    RANAP specification TS 25.413              ¦ octet 3-n  ¦
+------------------------------------------------------------+