TSG-SA Working Group 1 (Services) meeting #1       TSGS1#1(99)076
Sophia Antipolis 1st - 5th February 1999

Agenda Item:	6.1

Source: 	TTC SWG641 and SWG661

Title:	Work Items in TTC SWG641 and SWG661

Document for:	Information

This contribution shows the work items in TTC SWG641 (RAN (CC/SM/MM)) and SWG661 (NNI) which input to each TSG_N_WGx. 
TTC present this contribution to understand the detail of GSM evolved network requirements v. 0.3.5 (S1-99028).
These work items are made based on the GSM evolved network requirements v. 0.3.5 (S1-99028).

Available work items are as follows;

-	Bearer Capability allocation between UMTS/IMT-2000 and other networks(WG3)
-	Pre-Paging(WG2)
-	Call Associated Signalling(WG2)
-	Out-of-band Transcoder Control (WG2)
-	GLR (WG2)
-	VHE (evolution points for CAMEL) (WG2)
-	Variation of authentication parameter length (WG2)
-	Maximum Call Number of Multiple call(WG2)
-	Requirements for SM Protocol(WG1)
-	Requirements for CC Protocol(WG1)
-	Requirements for MM protocol(WG1)

Joint SMG3 - 3GPP TSG CN WG3	Tdoc SMG3 3P99-150
Sophia Antipolis France						
25th-29th January 1999

Title: 	Bearer Capability allocation between UMTS/IMT-2000 and other networks

Source: 	TTC SWG6-6-1

Purpose:	For discussion

 The purpose of this contribution is to identify the necessity of new Bearer Capability allocation between UMTS/IMT-2000 and other networks since the other working group is currently defining requirements for bearer capability to be supported by the IMT-2000 terminal.
x		Bearer Capability allocation between PLMN and other network 

 The allocation of the Bearer Capability between UMTS/IMT-2000 and other networks is needed if new bearer capability is introduced.

x.1		TSG Project

	Terminal 	
	Radio	
X	Core Network	
	System	

x.2		Linked Work Items

None

x.3		Justification

 As the matter of fact, the other working group is currently defining requirements for bearer capability to be supported by the IMT-2000 terminal. Therefore, the TSG-CN WG3 needs to keep a careful watch on the activity of this matter and once new requirement for bearer capability would be defined, start to investigate about the impact to the interworking between the UMTS/IMT-2000 and ISDN or PSTN as the activity of the TSG-CN WG3.

x.4		Service Aspects

None

x.5		MMI Aspects

None

x.6		Charging Aspects

None

x.7		Security Aspects

None

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes		X	X		
No					
Don't know	X				

x.9		Expected Output and Time scales 

Approval of WI:			TSG-CN-WG3     (January 99)

Start of Report			TSG-CN-WG3     (February 99)

Scope and first draft		TSG-CN-WG3     (March 99)

Approval of deliverable by TSG	TSG-CN-WG3     (March 99)

x.10		 Work Item rapporteurs

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	TSG-CN WG3

Secondary Responsibility 	??

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		 Proposed Work Item : Pre-Paging

Source: 	TTC SWG 6-6-1

Purpose:	For discussion

x	Pre-Paging

In mobile networks , many mobiles stations will sometimes move in and out of radio coverage. As a result there are the cases that mobile terminated calls will fail because the terminated mobile station is "not reachable". 

In current incoming procedure about GSM, the paging will be started after sending setup message to visited MSC. That is to say, the current GSM specifications can result in a call path being setup between the caller and the visited MSC before the terminated mobile station has responded to the paging message. 

This creates the Japanese requirement to reduce the occurrence of unnecesary call paths through the core network to "not reachable" mobile terminated stations. 

This requirement can be solved because the paging will be started after Provide Roaming Number request message arrived at VLR before visited MSC will be received setup. This is one solution to meet this requirement and the option of visited side.

x.1		TSG Project

	Terminal 	
	Radio	
X	Core Network	
	System	

x.2		Linked Work Items

None

x.3		Justification

In order to standardise a network option to support Pre-Paging , it would be necessary to raise CRs on at least the following GSM standards:
GSM 09.02	MAP
GSM 03.18	Basic Call – stage2
GSM 04.08

x.4		Service Aspects

Service Aspects are for further study.

x.5		MMI Aspects

None

x.6		Charging Aspects

None

x.7		Security Aspects

Security aspects are for further study.

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes		X	x		
No					
Don't know	X				
 
x.9		Expected Output and Time scales 

Approval of WI:			TSG #     (January 99)

Start of Report			TSG #     (January 99)

Scope and first draft		TSG #      (February 99)

Approval of deliverable by TSG	TSG #       (March 99)

x.10		 Work Item rapporteurs

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	?? TSG

Secondary Responsibility 	?? TSG

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		Proposed Work Item: Call Associated Signalling

Source: 	TTC SWG6-6-1

Purpose:	For discussion

 
x		Call Associated Signalling 

It is necessary to standardize MSC-MSC and MSC-GMSC Interface for multi vendorship. In case of applying ATM to transport network, B-ISDN User Part will be used as call control signaling. It is considered that Application of B-ISDN User Part for the PLMN should be specified as well as N-ISDN User Part.

Subjects for investigation 
-	basic call signaling procedure
-	considerations on ISDN supplementary service
-	considerations on GSM specific supplementary service

x.1		TSG Project

	Terminal 	
	Radio	
x	 Core Network	
	System	

x.2		Linked Work Items

None

x.3		Justification

Many carriers expect to use ATM for the core network of IMT-2000, because of making efficient use of network resources. Furthermore, ATM-SVC(Switched Virtual Channel) , setting up a connection per call is achieved for core network resource optimization.

・	The following protocols can be applied as call control signaling in the ATM-SVC environment.B-ISUP
・	AAL type2(AAL2) Signaling

AAL2 was developed for low speed and delay sensitive service(e.g. voice service) and optimised core network resources. Thus, AAL2 is applied as one good alternative, in such a case of mobile-to-mobile calls with codec bypass. 
But for example, in case of mobile-to-fixed calls, network should transcode low bit rate coding(e.g. 8kbps) to 64kbps PCM for interconnection of PLMN and PSTN. Mostly it is considered that the tanscorder equipment is located in ServingMSC by reason of technical difficulty of codec control. And B-ISUP should be applied as call control signaling. 

Therefore, It is necessary to specify application of B-ISUP as call control signaling as well as N-ISUP.

x.4		Service Aspects

None

x.5		MMI Aspects

None

x.6		Charging Aspects

None

x.7		Security Aspects

None

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes			x		
No	X	X			
Don't know					

x.9		Expected Output and Time scales 

Approval of WI:			TSG #     (January 99)

Start of Report			TSG #     (January 99)

Scope and first draft		TSG #      (February 99)

Approval of deliverable by TSG	TSG #       (March 99)

x.10		 Work Item rapporteurs

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	?? TSG

Secondary Responsibility 	?? TSG

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		 Out-of-band Transcoder Control

Source: 	TTC SWG6-6-1

Purpose:	For discussion

 
X		Out-of-band Transcoder Control
In order to improve voice quality for mobile-to-mobile calls (MS-MS calls) in GSM Phase 2+ networks, Tandem Free Operation (TFO) using in-band signaling has been specified. The equivalent function in Japan's PDC (Personal Digital Cellular) network is known as Transcoder Bypass, which has been specified to make use of out-of-band signaling control (i.e. by the PDC-MAP protocol).
The UMTS Phase 1 network operator should have the option to implement Transcoder Control by making use of either TFO, Transcoder Bypass or both.

x.x.1		 Purpose of Transcoder Control 
Low bit rate coding (e.g. 8kbps or 16kbps) has been adopted for voice coding in the GSM (and PDC) BSS to make efficient use of radio resources. However, the GSM (and PDC) core networks transcodes this traffic to 64kbps PCM in preparation for switching and interconnection with external networks. This transcoding function can lead to a degradation of speech quality. The purpose of Transcoder Control is to improve the speech quality for mobile-to-mobile calls by removing unnecessary transcoding.   
 
x.x.2 		Requirements for Transcoder Control
The requirements for Transcoder Control are as follows:
•	The negotiation procedure should be applied both for speech codecs and multimedia codecs. The procedure  should have flexibility for future enhancements of codec types.
•	The negotiation and control procedures for Transcoder Control should be independent of the transcoder location in the network, i.e. Core Network (e.g. MSC) or Radio Access Network (e.g. RNC).
•	The negotiation and control procedures for Transcoder Control should be independent of the transport layer (e.g. STM or ATM) of both Core Networks and Radio Access Networks.
•	The negotiation and control procedures for Transcoder Control should not cause a significant delay in establishing a through connection in mobile-to-mobile calls. Nor should they cause a significant delay when modifying the communication mode between bypass mode and normal mode (e.g. in support of services such as Multiparty Call).
•	Transcoder Control communication should be maintained even if the mobile terminal (MT) executes handover.
•	Transcoder control communication should be realized in the case of inter-network connections that have different PCM coding standards(i.e. A/-law ) in the through connection if possible.
•	The mobile terminal (MT) may support multiple codec types. Negotiation procedures between the originating MT (or TRAU) and the terminating MT (or TRAU) are required to select a common codec type for Transcoder Control communication in mobile-to-mobile calls. 
•	The originating MT (or TRAU) may transmit a list of preferred codec types to the terminating MT (or TRAU) during the negotiation process.
•	The terminating MT (or TRAU) should select one codec type from this preferred codec list during Transcoder Control negotiation. 

x.1		TSG Project

	Terminal 	
	Radio	
X	 Core Network	
	System	

x.2		Linked Work Items
None

x.3		Justification
In order to improve voice quality for mobile-to-mobile calls (MS-MS calls) in GSM Phase 2+ networks, Tandem Free Operation (TFO) using in-band signaling has been specified. The equivalent function in Japan's PDC (Personal Digital Cellular) network is known as Transcoder Bypass, which has been specified to make use of out-of-band signaling control (i.e. by the PDC-MAP protocol).
The UMTS Phase 1 network operator should have the option to implement Transcoder Control by making use of either TFO, Transcoder Bypass or both.

x.4		Service Aspects
None

x.5		MMI Aspects
None

x.6		Charging Aspects
None

x.7		Security Aspects
None

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes			x		
No	X	X			
Don't know					

x.9		Expected Output and Time scales 

Approval of WI:			TSG #     (January 99)

Start of Report			TSG #     (January 99)

Scope and first draft		TSG #      (February 99)

Approval of deliverable by TSG	TSG #       (March 99)

x.10		 Work Item rapporteurs

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	?? TSG

Secondary Responsibility 	?? TSG

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		Proposed Work Item: GLR 

Source: 	TTC SWG661

Purpose:	For Discussion 

This contribution introduces the concept of the Gateway Location Register (GLR), as defined Q.FNA. The benefits of including the GLR as a functional entity within UMTS Phase 1 are outlined

 
x		Gateway Location Register (GLR)

The GLR is an optional node between the VLR and the HLR, which may be used to optimize the handling of subscriber location data across network boundaries.
In Figure 1, a subscriber to HLRa in Network A is roaming to Network B outside the home PLMN, the GLR in Network B plays the role of an HLR towards the VLRb and the role of a VLR towards HLRa. The GLR handles any location change between different VLR service areas in the visited network without involving the HLRa. Terefore the nember ofmessages between Network A and Network B. The GLR is not involved with the subscriber to HLRb.

HLRa

HLRb

GLR

VLRb

Network A                               

Network B                              

                                  Figure 1

The sequence of events when the subscriber roams to network B is as follows:
-	VLRb sends the registration message to HLRa via the GLR  HLRa stores the GLR number and the GLR stores VLRb number. (These numbers used as SCCP address.)
-	HLRa returns the subscriber profile data
-	The subscriber profile is stored in the GLR and VLRb

As the roaming subscriber moves between VLRs in network B, then the GLR is updated, but no message is sent to HLR, therefore the number of message between network A and network B is reduced. The reduction in signaling traffic is a significant benefit when the two networks are far apart, e.g. between Europe and Japan.

x.1		TSG Project

	Terminal 	
	Radio	
X	 Core Network	
	System	

x.2		Linked Work Items
Linked Work Items are for further study. 

x.3		Justification

It is one of the basic capabilities to support “Global Roaming” for IMT-2000. It is expected that the number of international and inter network roaming user will increase, then the control of inter network traffic will be important.
If GLR is installed in the network, it decrease the number of signal between networks.

GLR will decrease the number of signal about location update between networks to reduce load of signaling network without change of network-network interface protocol and without restriction of installation about VLR.

The GLR is included as an optional functional entity for all UMTS Phase 1 scenarios described in UMTS 23.20 (Evolution of the GSM Platform towards UMTS).

x.4		Service Aspects
Not relevant

x.5		MMI Aspects
Not relevant

x.6		Charging Aspects
Not relevant

x.7		Security Aspects
Not relevant

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes			x		
No	X	X		X	
Don't know					

x.9		Expected Output and Time scales 

Approval of WI:			TSG #     (January 99)

Start of Report			TSG #     (January 99)

Scope and first draft		TSG #      (February 99)

Approval of deliverable by TSG	TSG #       (March 99)

x.10		 Work Item rapporteurs

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	CN TSG

Secondary Responsibility 	?? TSG

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		Draft Proposed Work Item: VHE (evolution points for CAMEL)

Source: 	TTC SWG 6-6-1 VHE protocol ad-hoc

Purpose:	For Discussion

This contribution discusses evolutional points for CAP, which will support the VHE (virtual home environment) in IMT-2000.  The evolution points are identified based on the GSM CAMEL v6.2.0 (1998-11), since it will be discussed as an initial input document for the "IMT-2000 documents, Work Area: Network-Network Interface, Title: NW interface (Circuit) Non-call Associated Signalling" for 3GPP.  
 
x	VHE evolving from CAP etc.   

For the VHE in IMT-2000, some evolution points to the currently defined CAP are needed.  Because some family members need additional capability from their market needs, strategy of the network evolution etc.  As these points will be commonly applied to each family member within VHE context, they should be discussed in 3GPP and have a consensus view and specification for the interoperability.  

x.1		TSG Project

	Terminal 	
	Radio	
x	Core Network	
	System	

x.2		Linked Work Items

 [To be provided according to the corresponding requirements working items.]   

x.3		Justification

Control relationship between CNs (similar to CAP) can support VHE, and following explains about this mechanism's justification (this is called "Direct Home Command" in ITU-T final draft Q.1711).  

Each family member would like to support the value-added and customisable services.   In addition, the services may contain a member specific service/feature like the used language selection, the supplementary service activation procedure etc.  Considering the recent development of the IN technology, they can be build on the common re-usable network capability abstracted by INAP (Intelligent Network Application Protocol) derived interfaces rather than the service specific signalling specification.  GSM has already specified CAMEL and it supports variety of services/features for this purpose, however, additional capabilities will be identified and required for the family members to enhance the value of this approach.  In addition, lower layer related issues (SCCP, TC) should be also considered to ensure the communication between CNs and some of them are reflected in the list below (so they are not only related to INAP derived interfaces but also to lower layer).  

Following is the tentative list of the evolution points identified in the TTC SWG 6-6-1 from the protocol specification point of view based on the requirements provided by TTC SWG 6-2-1 (note: the requirements may be proposed to the SMG1 meeting also, before 3GPP start).  TTC SWG 6-6-1 believes they are commonly useful for every member of the IMT-2000 family.  

Items	Note	
1	Addition of DPs (Analyzed_Information, T_Mid_Call), and removal of Not_Reachable DP		
3	Dynamic trigger embedding with criteria		
6	Limited Network Load		
7	Activation of mobile related Call events 		
8	Out-channel information transfer between MT/UIM and NW (possibly from SCF)	The need of this capability should be confirmed within TTC since the requirements are currently checked.	
10	IN/CN supported service control via in-band interaction 		
11	Service interaction between switch based supplementary service and IN supported service		
12	Support of Multimedia (QoS, ATM end point address, IP address)  		
15	Accounting and traffic measurements		
Note:  Shaded items have lower prioriy than non-shaded items.  	

x.4		Service Aspects

Benchmark services/features are separately identified within TTC (SWG 6-2-1).  Please refer the relevant parts.  

x.5		MMI Aspects

MMI aspect will be covered by VHE capability if the above mentioned condition will be adopted.  

x.6		Charging Aspects

Item 9 in the tentative list refers charging, however, the necessity of this item being checked within TTC SGW 6-6-1 to identify the evolution points existing or not.  

x.7		Security Aspects

Please see item 4, 5, and 6 in the tentative list.  

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes			X	x (lower layer)	
No		x			
Don't know	X				

x.9		Expected Output and Time scales 

Approval of WI:			TSG #     (TBD 99)

Start of Report			TSG #     (TBD 99)

Scope and first draft		TSG #      (TBD 99)

Approval of deliverable by TSG	TSG #      (TBD 99)

x.10		 Work Item rapporteurs

To be determined, but it is proposed that the assignment of two persons (each rapporteur will also act as an liaison person between the European regional standard bodies or TTC and CN TSG).  

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached), 

x.12		Responsible STC(s)

Primary Responsibility	CN TSG

Secondary Responsibility 	?? TSG

x.13		Others

3GPP TSG CN WG2
						
26th-29th February 1999

Title: 		Variation of authentication parameter length 

Source: 	TTC SWG6-6-1

Purpose:	For discussion

 This contribution proposes to study the variation of authentication parameter (RAND and SRES) length. .

X		Variation of authentication parameter length

X.1		TSG Project

	Terminal 	
	Radio	
X	Core Network	
	System	

x.2		Linked Work Items

None

x.3		Justification

Authentication scheme*1 of GSM, unique challenge scheme, is an efficient procedure. RAND and SRES are sent to VLR from HLR, and VLR send RAND to MS, MS calculates and send back SRES, then VLR compares SRES from MS with SRES from HLR. However, the lengths of RAND and SRES are fixed. It will restrict possibility of enhancement of authentication algorithm that requires longer RAND and SRES. Moreover, if these parameters are defined as variable length, operators can select the authentication algorithms and distinguish from other operator by using higher security level. This requirement has already come to an agreement in TTC.

If we will not make the variation in first phase, many UMTS/IMT-2000 MT and MSC that can handle only authentication parameters as fixed length are came onto the market, and it’s too difficult to extend authentication scheme. Therefore, introduction of variable length of authentication parameters in first phase is necessary.

It is expected that we should define these parameters in MAP operation and MM message as variable length parameter. Moreover, we should discuss this issue with the consideration of backward compatibility. 

*1: Authentication scheme means a procedure which is performed using an authentication algorithm and authentication parameters.

x.4		Service Aspects

If RAND and SRES are defined as variable length, operators can select the authentication algorithms and distinguish from other operator by using higher security level. 
Of course, we can use GSM A3 algorithm as usual, an operator who wants to introduce new algorithm without no limitation of authentication parameter length can use the algorithm.

x.5		MMI Aspects

None

x.6		Charging Aspects

None

x.7		Security Aspects

GSM is a system with high security level, but we suppose that in future other authentication algorithms with higher security level than GSM will be developed. It is expected that UMTS/IMT-2000 will be used for a long time, so it’s very effective that authentication scheme is applicable to any authentication algorithms.

Each operator requires different levels of security. In order to allow different levels of security, The present GSM authentication scheme can allow some range of security levels, but authentication scheme which uses authentication parameters with variable length will be applicable to more levels of authentication algorithms. 
The following gives an example that GSM and PDC authentication schemes need different authentication parameter length.

	GSM	PDC	
RAND	16	8	
SRES	4	8	

As stated above, it’s expected that variable length is needed according to authentication algorithms. It is better for us if operators can use the most suitable authentication algorithm for each requirement. 

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes	X		X		
No		X			
Don't know					

x.9		Expected Output and Time scales 

Approval of WI:			TSG CN WG1 #1    (January 99)

Start of Report			TSG CN WG1 #1     (January 99)

Scope and first draft		TSG CN WG1 #1    (January 99)

Approval of deliverable by TSG	TSG CN #2      (March 99)

x.10		 Work Item rapporteurs

TBD

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	TSG-CN WG3

Secondary Responsibility 	??

x.13		Others

3GPP TSG CN WG2
						
16th-18th February 1999

Title: 		Maximum Call Number of Multiple call

Source: 	TTC SWG6-6-1

Purpose:	For discussion

This contribution proposes to study the MAP protocol and procedure for insert subscriber data.

x	Maximum Call Number of Multiple Call

x.1		TSG Project

	Terminal 	
	Radio	
X	Core Network	
	System	

x.2		Linked Work Items
non

x.3		Justification
Circuit switched call and packet session can be held in a MT simultaneously and independently. In addition, multiple CS calls and multiple packet sessions can also be held in a MT.
The number of simultaneous active call that is offered to the user shall be limited. However, operators should be able to freely set the number of simultaneous active calls. In other words, the number of maximum bearer can be set by the operators’ choice. When an operator wish to offer a single call service, they just set the limit of the maximum number of bearer (call) is one.

x.4		Service Aspects

None

x.5		MMI Aspects

None

x.6		Charging Aspects

None

x.7		Security Aspects

None

x.8		Impacts

Affects:	Terminal	Radio	CN	Others	
Yes			X		
No	X	X		X	
Don't know					

x.9		Expected Output and Time scales 

Approval of WI:			TSG CN WG1 #1    (January 99)

Start of Report			TSG CN WG #2     (January 99)

Scope and first draft		TSG CN WG #2     (?)

Approval of deliverable by TSG	TSG CN #2 or 3     (March 99)

x.10		 Work Item rapporteurs
TBD

x.11		Supporting Companies

Members of TTC SWG 6-6-1 (list will be attached),

x.12		Responsible STC(s)

Primary Responsibility	TSG-CN WG3

Secondary Responsibility 	??

x.13		Others

 TSGN#1(99)174
3GPP TSG CN WG1
Sophia Antipolis 26th-28th January 1998

Title: 		TTC/ARIB Requirements for SM Protocol

Source: 		TTC/ARIB

Purpose:		Discussion

1.	Introduction
 TTC/ARIB has been studied on SM protocol of IMT-2000 based on GSM 04.08. Through the discussion, some requirements were identified.

2. Requirements
Identified requirements have been captured in TTC/ARIB baseline document of SM protocol, which is attached in ANNEX.

Source: Editor of SM
Title: Baseline Document for Evolution Points of SM Protocol
Version: 1.0

Table of Contents
1	Scope	2
2	Principle	2
3	Work Items	2
4	Evolution Points	2
4.1	Asymmetric Bearer	2

Scope
This baseline document contains TTC/ARIB’s requirements of the evolution points from GSM toward IMT-2000.
Principle
•	SM should be independent from any specific radio technology. 
•	SM protocol will be developed evolutionary from GSM. 

Work Items
TTC regards items below as WI of SM protocol for the first phase of IMT-2000.
•	Asymmetric Bearer

Evolution Points 
・	Asymmetric Bearer
1)	The requirement
   Need to support different QoS bearer properties for each direction.
 
2)	The expected service and/or the effect
  Multimedelia contents might request different kinds of QoS bearer. Those consist of transmission speed, bit error rate, delay aspects and so on. 
  When up direction of a bearer requests some sort of QoS like a speed and down direction of the bearer requests another speed, if both directions of the bearer was defined as same speed just like as paired, the bearer might not be utilized efficiently. Because the transmission capacity of lower transmission speed part may be regarded as much as higher transmission speed part, lower transmission part occupies more speed than its requests. Therefore, if different users have established multiple session, total bearer efficiency couldn’t be achieved.

TSGN#1(99)170
3GPP TSG CN WG1
Sophia Antipolis 26th-28th January 1999

Title: 		TTC/ARIB Requirements for CC Protocol

Source: 	TTC/ARIB

Purpose:		Discussion

1. Introduction
 TTC/ARIB has been studied on CC protocol of IMT-2000 based on GSM 04.08. Through the discussion, some requirements were identified.

2. Requirements
Identified requirements have been captured in TTC/ARIB baseline document of CC protocol, which is attached in ANNEX.

Source: Editor of CC
Title: Baseline Document for Evolution Points of CC Protocol
Version: 1.0

Table of Contents
1	Scope	2
2	Principle	2
3	Work Items	2
4	Evolution Points	2
4.1	Bearer services and Teleservices negotiation	2
4.2	Multi call	5
4.3	DTMF signaling	5
4.4	Bearer services and Teleservices modification during a call	6
4.5	Parameters for Bearer services and Teleservices	8

Scope
This baseline document contains TTC/ARIB’s requirements of the evolution points from GSM toward IMT-2000.
Principle
•	CC should be independent from any specific radio technology. 
•	CC protocol will be developed evolutionary from GSM. 

Work Items
TTC regards items below as WI of CC protocol for the first phase of IMT-2000.
•	Bearer services and Teleservices negotiation
•	Multi Call
•	DTMF signaling
•	Bearer services and Teleservices modification during call
•	Parameters for Bearer services and Teleservices

Evolution Points 

・	Bearer services and Teleservices negotiation
1)	The requirement(s)
Need to support bearer service procedures in out-band signaling between MT-MT and NT-NW.
2)	The expected service(s) and/or the effect(s)
a)	The service negotiation
In the IMT-2000, by the multimedia service functions, it enables to offer Visual MT that supports both audio/visual communication and speech communication, and Speech MT that supports only speech communication. For the users that request audio/visual communication, they are not always know the types of MT (if they support Visual MT or not).    

Now supposing a NW system (and the MTs) that is not supporting a bearer negotiation procedure, and a caller side is using Visual MT and the receiver side is using a Speech MT. If the NW does not support the bearer negotiation procedure, a new speech calling-request is need after the calling-request is rejected. In this case, the connection has to be re-established, which means the call has to start from a paging. This sequence takes much longer set-up time (delay) compared to the sequence that supports a bearer negotiation procedure. 

	On the other hand, in the case that the NW supports bearer (service) negotiation, users will be able to start a communication by selecting the second priority (service) when the first priority (service) is not acceptable by the receiver side. Additionally, there is a case that a MT wants to start a speech communication even if the receiver is using Visual MT. In this case, receivers will be able to select the types of the services (Fig 2.1).  

b)	 CODEC bypass
	When MTs support multiple CODEC, selecting same CODEC type which is used between MT to MT, a CODEC bypass can be realized. By the CODEC bypass, it enables to improve the audio quality and the NW transcoder can be used in an efficient manner. (Fig2.3, 2.4)

3)	The evolution points
In order to support bearer negotiation, the following capability is required.
a) O-MT notifies O-MSC of various services
b) O-MSC notifies D-MSC of services required by O-MT 
c) D-MSC notifies D-MT of services required by O-MT
d) D-MT notifies D-MSC of services selected by D-MT or D-User
e) D-MSC notifies O-MSC of services selected by D-side 
f) O-MSC notifies O-MT of services selected by D-side
 
In the Air-IF a, c, d, and f, the enhancement of CC is required, b and e are out of scope in this case.

・	Multi call 

1)  The requirements
  Support the function that offers multi active call on a MT. 
  This means, this capability offers multi bearers (CH) on a single MT.
2)  The expected service(s) and/or the effect(s)
It makes a possible to offer a transmission of data and audio simultaneously which has been impossible in the 2G system.
  Example: Down load data from the web during a speech communication.
3) The evolution point
 Enhancements are required on CC. 

・	DTMF signaling

1)  The requirements
It is need to support the capability of DTMF transmission from NW to MT in the Out-of-band-Signaling.
2) The expected service(s) and/or the effect(s)
It is possible to offer a service to control a remote MT from originating side by PSTN using DTMF. 

3)  The evolution point
It is need to define an out-of-band-signaling for DTMF transmission from NW to MT.

Bearer services and Teleservices modification during a call  1) The requirements
Bearer service and tele-service modification procedures are required in the MT-MT and MT-NW.
  2) The expected service(s) and/or the effect(s)
a) The maximization in utilizing of the MT radio capability.
Now supposing that MTs are under a data communication that has maximum information rate at 64 k/bps. In this case, when a MT receives a speech incoming call, it has to receive the speech call after releasing the data communication or the MT would have to reject the incoming speech call. 
  But, if the NW (with the MT) support bearer modification procedure, the MT can receive incoming speech call by reducing the bearer size of the data communication without releasing the data communication (see Fig 3.1).

Additionally, the MT can start a call by changing the bearer rate when the MT wish to initiate an additional call. When a speech communication is released from a speech and data communication are held, the capacity of the data communication can be increased by (the amount of) the capacity of the released speech communication (Fig 3.2).
By the supporting the bearer modification procedure, MTs’ radio (capacities) capabilities are highly utilized. Considering the limitation of the capacity and the size of the battery, it is important to maximize the utilization of the radio resources.
 
b)  Switching the speech, Modem, & Facsimile during a call (communication). 
If the NW support the bearer negotiation procedure, once a MT connects a speech call to a Fax mail server, then receiving a Fax mail by switching to a Fax communication. Additionally, the same service will be able to support as PDC when a MT receives a Fax and Modem from PSTN NW (Fig 3.3).

1)	The evolution points
Regarding to the MT-MT, the following capabilities are required.
a) Requesting MT request to modify service to Requesting MSC.
- Modification of service may contain only modification of bearer or modification of bearer and tele-service
b) Requesting MSC notifies Requested MSC of the request to modify service. 
c) Requested MSC requests to modify service to Requested MT.
d) Requested MT notifies Requested MSC of modification result.
e) Requested MSC notifies Requesting MSC of the modification result.
f) Requesting MSC notifies Requesting MT of the modification result.

In the Air-IF a, c, d, and f, the enhancement of CC is required, b and e are out of scope in this case. In the case of MT-NW, it is required the capability on a and f.

・	Parameters for Bearer services and Teleservices
The following services will be support in the first phase of the 3G system
•	Speech(GSM-AMR, CS-CELP, EVRC, etc )
•	MODEM( ～33.6kbit/s )
•	FAX( ～14.4kbit/s )
•	PIAFS(32kbit/s, 64kbit/s)
•	Unrestricted digital (32kbit/s, 64bit/s)
•	Audio/visual(H.324/M, etc)

The first five items are the succession of the conventional services provided by existing mobile systems. PIAFS is the service provided as PHS (Personal Handy-phone System) data transfer service. Transmission speed of each service should be higher. The last item, Audio/visual, is new additional service. Moreover, in order to increase the capacity of radio bandwidth by reducing amount of radio interfere, Speech, MODEM, FAX, PIAFS, and Audio/Visual services require interworking function in network side, such as equipment for codec for speech. Consequently, it is expected the need of the parameters to indicate service type to allocate the interworking function to the call.
In SMG, bearer services are defined by some attributes, such as information transfer rate attributes and maximum transfer delay attributes, and teleservices are also defined in UMTS 22.05. For speech teleservice, UMTS 22.25 section 4.2 Support of Speech Services includes the following description. “A standardised speech codec will be adopted for UMTS. It shall be possible for proprietary speech codecs standardised elsewhere to be deployed as well as the codec standardised for UMTS.” It is expected the need of the parameters to indicate attributes of bearer services, and also expected the need of the parameters to indicate codec types in order to adopt several codecs.
Consequently, it is necessary to study the parameters for bearer services and teleservices. The expected changes of CC specification are additional definitions of new individual parameters for bearer services and teleservices. 

TSG-Core Network meeting #1	TSGN#1(99)158
Sophia Antipolis 26th - 28th January 1999	

Agenda Item:	TSG-N UMTS work (Technical input documents on UMTS)

Source:	TTC/ARIB

Title:	TTC/ARIB Requirements for MM protocol

Document for:	Discussion

___________________________________________________________________________

1.	Introduction
TTC/ARIB has been studied on MM protocol of IMT-2000 based on GSM 04.08. Through the discussion, some requirements were identified. 
All the evolution points are based on the principles below,
-	Clear separation of core network and radio access network
-	More secured system
-	Consideration of further extension
2.	Requirements
Identified requirements have been captured in TTC/ARIB baseline document of MM protocol, which is attached in ANNEX.

Source: Editor of MM
Title: Baseline Document for Evolution Points of MM Protocol
Version: 1.0

Table of Contents
1	Scope	2
2	Principle	2
3	Work Items	2
4	Evolution Points	2
4.1	MS Classmark Restructuring	2
4.1.1	MS Classmark Structure	2
i)	Separation of RAN and CN information	2
ii)	Limitation of length	3
4.1.2	Notification Procedure	4
4.1.3	Condition of Presence	5
i)	Location Updating Request message	5
ii)	CM Service Request message	5
4.1.4	Necessary Information	5
4.2	Paging Response Message Protocol Category	6
4.3	Secured Detach Procedure	6
4.4	Variable Length of Authentication Parameter	7

Scope
This baseline document contains TTC/ARIB’s requirements of the evolution points from GSM toward IMT-2000.
Principle
•	MM should be independent from any specific radio technology. 
•	MM protocol will be developed evolutionary from GSM. 
Work Items
TTC regards items below as WI of MM protocol for the first phase of IMT-2000.
•	MS Classmark 
•	Paging Response Message Protocol Category
•	Secured Detach Procedure
•	Variable Length of Authentication Parameter

Evolution Points
・	MS Classmark Restructuring
・	MS Classmark Structure
・	Separation of RAN and CN information
Various information is packed in Mobile station classmark in GSM, therefore location of RAN and CN information elements depend on each other. For the independent development of RAN and CN, both information need to be placed separately. 
Information regarding Core Network and Radio Access Network should be clearly separated so that interpretation of the information can be done without any presumption of data structure of another sub-system(i.e., UTRAN and GSM RR). 
MS Classmark should be newly defined for IMT-2000. It consists of necessary information only for IMT-2000 not to send unnecessary information to the network. 
Reason to have different MS classmark parameter for IMT-2000 is that radio access network for IMT-2000 is not necessarily one so that it is predicted to emerge more different systems. If we capture all the radio information in a same parameter, unnecessary information will increase endlessly. Considering the case, it would be a good approach to have different parameter by every radio system.
Requirement 1: Mobile station capability of radio access network and core network need to be set in different parameters.
MS classmark 2 and 3 contains GSM RR specific information, which is not necessary for IMT-2000 single mode terminal. 
MS Classmark for CN is to be defined in MM protocol and one for RAN is to be defined in RRC protocol.
Mobile station classmark for each RAN will be independently defined in each system for the protocol independency and efficiency.
Requirement 2: Mobile station classmark parameters for different radio access network are to be different.
Structure of newly defined MS classmark for IMT-2000 illustrated in the figure 1. 
[Editor’s note: Appropriate name for MS classmark for IMT-2000 is requested.]

Fig. 1. Restructured Mobile station classmark
・	Limitation of length
Mobile station classmark 3 has maximum length of IE, which is 14 octets. This is explained as because it is to fit in a single radio frame.
As we after the radio independent MM protocol, this limitation is desired to be put away.
Layer 3 procedure is designed to be independent from Layer 2 procedure, This means that CM Service Request message does not need to be designed to fit in a UUI field of L2 establishment message.
If we need to have limitation of length, this is to be determined as appropriate for MM protocol.
Requirement 3: Maximum length of Mobile station classmark should be extended.
・	Notification Procedure
Paging Response and CM Service Request can carry only MS classmark 2, therefore further information such as MS classmark 3 should be got using Classmark Interrogation procedure. 
If we define another Mobile station classmark, it will not be included in neither of Paging Response nor CM Service Request but these parameters (i.e., MS classmark 3 and others) are retrieved by classmark interrogation procedure, which requires one more round trip. 
It is supposed that this is because of a specific radio procedure applied to GSM. The procedure is to send initial layer 3 information (i.e., CM Service Request, Paging Response and so no) on the UUI filed of SABM, which establishes layer 2 connection.
Some problems are seen in the procedure. First one is that MM procedure is too much dependent on specific radio procedure, and next is classmark interrogation procedure causes more radio traffic and delay of service provisioning to a user. 
Requirement 4: All the information required for CN is set in CM Service Request as a single parameter to be sent in a message.
Figure 2 shows high level description of the proposed procedure. It is assumed that Mobile terminal classmark for RAN is conveyed to RNC during RRC connection setup procedure.

Fig. 2 Classmark Notification Procedure
IMT-2000 is an evolved from GSM, however both system are different so that information for both system should be in different parameters. IMT-2000 single mode terminal does not need GSM information. Considering the efficiency it is better not to include Mobile station classmark for GSM (i.e., MS classmark 2) in initial layer 3 message for IMT-2000.
Requirement 5: CM service requesting message of IMT-2000 does not include Mobile station classmark 2 defined for GSM.
This is based on an assumption that procedure below is applied in case of inter radio system handover (including to/from GSM BSS).
Assumption: Procedure which appears in Iu interface in case of inter radio system HO is same as one of inter BSS HO of GSM. [Note: This assumption needs to be confirmed]
-	MS Classmark for CN is transferred to CN in CM service invocation procedure (e.g. CM Service Request, Paging Response etc.) and it is not influenced by handover. 
-	MT notifies all the supporting radio information to RNC in RRC connection setup procedure.
-	MS Classmark for RANs is transferred to target RAN in inter radio system HO procedure through Iu.
-	The detail condition which classmark to be transferred needs to be studied because it would depend on the direction of handover (i.e., one directional or both directional)

Figure 3. Assumed Iu procedure for inter radio system handover 
MS classmark for RAN A or B can be Mobile station classmark 2 and 3.
If this approach is applied, radio information does not need to be sent to CN together with core network information in MS Classmark for CN.As a conclusion, MS capability information for radio access network does not need to be included in MM message.
Requirement 6: Radio dependent information is not to be included in MM protocol message.
・	Condition of Presence
a)	Location Updating Request message
In GSM, Location Updating Request message contains MS Classmark 1, which is the subset of MS Classmark 2.
RR connection established in Location Updating procedure may be used for CM services. In such case, the network will start classmark interrogation procedure for the case of terminating call, or the mobile terminal sends MS Classmark 2 in CM Service Request message. This would cause delay of call complete and increases number of signal.
Location Updating Request message is to include MS Classmark for CN instead of having specialized classmark for location updating procedure.
Requirement 7: Same Mobile station classmark IE is to be applied both for Location updating and CM service invocation.
・	CM Service Request message
MS Classmark 2, which is a part of mobile terminal classmark information, is defined as a mandatory parameter in CM Service Request.
As per CM service originated by a mobile terminal, CM Service Request message needs to be sent to a network.
A mobile station classmark may not changed during it keeps the association between the network the mobile terminal (and this is normal the case) therefore re-sending of same information seems redundant.
Requirement 8: Presence of Mobile station classmark IE in CM Service Request is to be Conditional, which is for the first invocation of CM service.
Considering the case, Mobile station classmark in CM Re-establishment may not be necessary.
・	Necessary Information
Newly defined MS classmark which is used in IMT-2000 core network needs to be identified.
The information is picked up from one in Mobile station classmark 2 and 3. 
Information necessary for IMT-2000 CN are listed below.  [Editor’s note: Further check are required]
-	Revision level
-	SM capability
-	VBS notification Reception
-	VGCS notification Reception
-	UCS2
Necessity of parameter listed below are to be studied. 
-	Ciphering algorithm
-	SS Screening Indicator
・	Paging Response Message Protocol Category
Current procedure of GSM:
Paging Response message is categorized in RR protocol and it is carried through A interface included in Complete Layer 3 Information message and then interpreted by MSC.
Issues identified are,
-	If Paging Response is carried though Iu interface to MSC, it needs to be analyzed by MSC.  This means that MSC knows the format of RRC message. According to basic principle of UMTS, RAN and CN are to be independent from each other, therefore this procedure is against the principle.
-	The modification to redefine Paging Response message in MM protocol does not have any impact to actual products of GSM MSCs, but the impact is just on the specification. 
-	Issue of Paging Response categorization is related to both RR and MM. If we are waiting for the simultaneous evolution both of RAN and CN, there is no chance to improve the protocol.
-	We may have more than one radio systems for IMT-2000. These should be independent from each other in terms of protocol structure and so on, however both of which should commonly have same message, that is Paging Response.
According to above points, it was agreed that it is better to have Paging Response message in MM protocol, however some concerns from load standardization work were expressed. Points are shown below.
-	We have very tight schedule to the 1st phase of IMT-2000. It is better to concentrate the standardization works on the technical improvement rather than philosophical one. 
-	MM of 1st phase of IMT-2000 should be evolution from GSM. If we consider the smooth migration from GSM to IMT-2000, it is better to keep Paging Response in RRC protocol. 
Considering the technical aspects, Paging Response should be MM protocol.
Requirement 9: Paging Response is to be defined as a MM message.
Whether we will make the work for the modification will depend on the available resource. Evaluation of the priority should be made, and final decision will be made according to it.
・	Secured Detach Procedure 
Current Detach procedure does not involve the method to check the validity of the requesting user. This allows malicious user to obstruct a third party’s terminating call. This will cause not only the user’s inconvenience but also bat reputation of the operator.
Requirement 10: User verification of IMSI Detach Indication is required not to be interfered with terminating service.
TMSI signature, whose usage is very similar to P-TMSI signature in GPRS, is effective for the user verification in detach procedure.
Comparing to normal authentication procedure, this method can be easily achieved by adding parameter, but modifying any procedure, and more generally applicable, for example, in case of detach procedure triggered by SIM removal.
a)	Network assigns mobile terminal TMSI signature through ciphered radio channel. 
b)	In case of detach, the mobile terminal sets assigned TMSI signature in IMSI Detach Indication message.
c)	The network compares the TMSI received in IMSI Detach Indication and one stored by itself. If the value is same, the requesting mobile terminal can be regarded as valid.

Figure 4 Example of TMSI signature usage

Requirement 11: User verification method, which is similar to P-TMSI signature it to be introduced for MM of circuit switch service.
・	Variable Length of Authentication Parameter
In IMT-2000, it is sure to apply challenge and response scheme as is in GSM for this scheme will be still valid for the third generation system. There is, however, a concern about the flexibility in terms of protocol capability.
RAND and SRES are carried on MM protocol message. In GSM, both are defined as type 3 information element, whose length are fixed. It is concerned that it might restrict the capability to adopt emerging better authentication algorithm.
It has been already in trouble if someone wants to select same authentication algorithm to PDC. (see table 1)
Table 1. Length of Authentication Parameters
	GSM	PDC	
RAND	16 oct	8 oct	
SRES	4 oct	8 oct	

Requirement 12: Authentication parameters are to be variable length to be adopted to various authentication schemes.