3GPP TSG-SA5 (Telecom Management)	S5-023002
Meeting #30 Tampere August 19-23

3GPP TSG-T2C UEM JM
Tampere, Finland
20-21 August 2002	T2C-0200032 	
3GPP TSG-T2 #18
Velen, Germany
12 -16 August 2002	1	T2-020780 	

Agenda Item:	SWG2, GUP
Source:	Ericsson ( mailto:Bo.Johansson@emp.ericsson.se )
Title:	GUP, Method to find Common Objects in the Initial Starting phase
Document for:	Discussion
___________________________________________________________________________
1	Introduction
This document is proposing a method to find and describe a first initial set of  “Common Object” which will be a part of TS 24.241.
The introduction describes the main purpose and the background.
Chapter 2 “Finding the initial set of common objects” proposes a method to find the initial set of “Common Objects”. At the beginning of the data description work mainly already defined and described parameters will be described using the DDF. This is called “Reverse engineering”.
Chapter 3 “The normal data description work” briefly describes the general case after the initial phase. 
1.1 Main purpose
The main purpose of the initial work is to
•	Find a first set of common objects.
•	During the work identify the possibly needed improvement on the Data Description Framework.
1.2	Work done so far to find a first set of common objects
Embedded in TS 24.241 there are:
•	Annex B1 GPRS Parameters:
o	Draft to Informal Data Description: UP-010091 (GPRS Parameters)
o	Draft to DDF Data Description: GprsDatatype_dt.xml
•	Annex B3 MMS Parameters
o	Draft to Informal Data Description: T2GUP-020007 (MMS Parameters)
•	T2-020698 MMS-DataCom parameters List

During the SWG2_01 Malmö Meeting there was a discussion about how to continue the work finding the first set of “Common objects”. The document T2C-020007 “identificationCommonDatatypesA.rtf” contains information about finding commonly used Datatypes and the document T2C-020006 “dataComConfigA.rtf” contains a discussion on the principles how to structure the data used to configure the data communication in UE.
Concluded in Malmö were:
•	To start with do not just focus on common objects. The common objects can later be selected from the defined objects.
•	For cases where the data already is defined no data modelling is needed. Reverse engineering can be used because the data are defined in existing specification. 
•	Focus on data needed for User Equipment management related to basic functions like GPRS, WAP, and MMS.

2	Finding the initial set of common objects
2.1	Reverse engineering
The figure 3 illustrates the reverse engineering principle, which can be used when the data to describe using the DDF is already defined in some specification. The figure shows the principle to analyse different specification to identify the defined abstract data. (In the work with GPRS (UP-010091) the main source of information has been the AT-commands.) 

Figure 3

2.2	Proposed working method

Figure 4
The figure 4 illustrates the method. The activities and the related documents are shown. The attributes (or parameters) needed to configure some selected functions and the corresponding datatypes are identified and described.
Two lists are maintained:
•	List of attributes
•	List of datatypes

The lists are described in the following sections.
NOTES! The reverse engineering is only done for data needed in standardised “Common Objects”. The intention is NOT to do this with all the attributes described in all the 3GPP specifications.
2.2.1	List with Attributes
For each attribute in the list the following is given:
•	Id for referencing
Each attribute is given an unique identity which can be used to reference to the attribute.
•	Label
The label is a short text or title used to “label” the attribute in user interfaces.
•	Description
This is a description of the attribute.
•	Default Field name
The default field name used when the attribute is used in a composite datatype.
•	Name of Datatype
Reference to the Datatype for the value of the attribute.
•	References to definitions and descriptions
List of reference where the attribute is described.
2.2.2	List with Datatypes
For each Datatype the following is given:
•	Datatype name
The datatype is given an unique identity.
•	Label
The label is a short text or title used to “label” the datatype in user interfaces.
•	Description
A description of the datatype.
•	References to definitions and descriptions
List of reference where the datatype is described.
•	References to usages
Example of attributes where the datatype is used.
•	DDF definition
The definition of the datatype according to the Data Description Framework.
2.3	Future steps
Future steps are to:
•	Select which of the Datatypes are Common Objects.
•	Define rules how to select Profile Components.
The document T2C-020006 “dataComConfigA.rtf” contains a discussion on the principles how to structure the data used to configure the data communication in User Equipment.
•	Group the attributes in Composite Datatypes.

Figure 5 is illustrating those activities and their relations.

Figure 5
3	The normal data description work
This chapter briefly describes the more normal (after the initial phase) work process and the “non-reverse engineering” case.
3.1	The after initial phase work process
The figure 2 shows the normal (after the initial work is done) data description work.

Figure 2
3.2	The  “non-reverse engineering” case
This section is indicating the “non-reverse engineering” case.
By the definition of new data items the DDF is used. The communication protocols and APIs used to access the data are then defined using a preferable generic mapping. If this is not possible a manual mapping has to be done.