ETSI STC SMG2					   Tdoc 21/00
Copenhagen, Denmark, 6- 8 March 2000		Revised Tdoc RPA000026

Agenda item: 7.1

Source:	Ericsson, Siemens, 
Title:	Adding UE Capabilities to Handover Request message

Background

This CR proposes to change the HANDOVER REQUEST message for the handling of the UE Capabilities. 
In case of Inter BSC handover the target BSC requires the UE capability of the mobile in case of an subsequent Inter System Handover to UTRAN. By transporting the UE capability in the Handover Request signalling provision is also made that the UE capability of the mobile is transported in the core network to the target RNC in case of an Inter system handover. 
The change is needed to A-interface HANDOVER REQUEST message to enable the UE Classmark to be transported from the old BSS to the new BSS in case of an inter BSC handover. 
The old BSS to new BSS Information container shall be used.By reception of Old BSS to Source BSS Information the new BSS shall store it to be used in any subsequent handover within GSM or in case of Hnadover to UMTS.
By temporary storing the UE Classmark in BSS unneccesary signalling over the radio is avoided.
An optional method to store the UE capability in the MSC instead was discussed at a CN1 meeting last millenium. 

ETSI STC SMG2 Handover ad-Hoc	Tdoc 21/00
Copenhagen, Denmark	Revised Tdoc RPA000026
6- 8 March, 2000
	
CHANGE REQUEST No :	Axx rx	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	 	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 Internal GSM handover	

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 Classmark to Handover Request signalling to enable  the transportation of UE capabilities between BSSs. In case of an subsequent handover to UMTS the UE Classmark is needed in the current serving BSS.

Clauses affected:	1.1, 3.2.2.58, 3.2.3

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.2.2.58	Old BSS to New BSS information
This information element is defined as a general container for passing Field Elements transparently between BSSs via  the MSC.
These Field Elements are passed in the “Old BSS to New BSS information elements” octets field. The error handling performed by the receiving entity for the “Old BSS to New BSS information elements” field is that specified in section 3.1.19.7.
+------------------------------------------------------------+
¦  8     7     6     5     4     3     2     1  ¦            ¦
+-----------------------------------------------+------------¦
¦               Element identifier              ¦ octet 1    ¦
+-----------------------------------------------+------------¦
¦               Length                          ¦ octet 2    ¦
+-----------------------------------------------+------------¦
¦ Old BSS to New BSS information elements       ¦ octet 3-n  ¦
+------------------------------------------------------------+

The length indicator (octet 2) is a binary number indicating the absolute length of the contents after the length indicator octet and may be set to zero.
The Old BSS to New BSS information elements field is made up of 0 or more Field Elements listed in the table shown below.

Field elements may occur in any order in the Old BSS to New BSS information elements field.
The construction of the Field Elements allows the receiver to ignore unknown Field Elements.
Due to backward compatibility issues Field Elements in the “Old BSS to New BSS information” may duplicate Information Elements in the HANDOVER REQUEST, when this occurs and the new BSS detects an inconsistency between this information then the information contained in the “Old BSS to New BSS information” shall take precedence as long as the coding is understood by the new BSS.
Reception of an erroneous “Old BSS to New BSS information” shall not cause a rejection of the HANDOVER REQUEST message; the “Old BSS to New BSS information” information element shall be discarded and the handover resource allocation procedure shall continue.

FIELD ELEMENT	REFERENCE	LEN	
Extra information	3.2.3.1	3	
Current Channel Type 2	3.2.3.2	4	
Target cell radio information	3.2.3.3	3	
GPRS Suspend information	3.2.3.4	19	
MultiRate configuration information	3.2.3.5	3-8	
UE Capability Information	3.2.3.6	n	

3.2.3	SIGNALING FIELD ELEMENT CODING
The coding rules for signalling field elements are the same as the signalling element coding rules which are defined in section 3.2.2.
Signalling field elements shall always include a Field Length indicator.  A Field Length indicator with a value of zero shall not be considered as an error.

Field
Element 
Identifier 
Coding	
Field Element name	
Reference	
0000 0001	Extra information	3.2.3.1	
0000 0010	Current Channel Type 2	3.2.2.2	
0000 0011	Target cell radio information	3.2.3.3	
0000 0100	GPRS Suspend information	3.2.3.4	
0000 0110	UE Capability information	3.2.3.6	
0000 0101	MultiRate configuration information	3.2.3.5	

All other valus are for future use.
The UE Capability Information Element structure is specified in the TS 04.18. 

3.2.3	UE Capability Information
The UE Capability Information element is structured and encoded according to TS 25.331