TSG-Terminals Working Group 3 (USIM) meeting #6	TSGT3#6(99)171
14-16 June, 1999	Page  1

Source:	Schlumberger  

Title: schlumberger PROPOSAL OF 3rd GENeration phone book feature

Tables of contents

SCOPE	2
Requirement	2
Definition	of Phone Book	2
Support of two name fields per entry	2
Support of multiple phone numbers per entry	2
Support of email address	2
Support of user definable groupings	2
Support of hidden entries	2
Number of entries	2
Mode of alerting	2
Solution	3
Implementation	5
Administration commands	5
Operation commands	6
Compatibility 2G/3G	9
Annex	10
Extended-linear fixed EF	10
READ RECORD	10
UPDATE RECORD	11
SEEK	11

SCOPE
This document is intended to provide a solution that can be deliverable within the existing capabilities of the smart card hardware in term of RAM size and microprocessor speed, etc…
The best way to be able to stay compatible with 2G is to create another type of linear fixed file where the number of record is coded in 16 bits.

Requirement 

Definition	of Phone Book
The Phone Book feature is based on the ADN functionality as defined in GSM 11.11 [7]. Additional features are identified in the following sub-clauses. A Phone Book entry consists of a record in an ADN file and, optionally, additional records which are placed in different EFs. In the latter case, a mechanism shall be defined to link all records in the same Phone Book entry. The ME shall support these features while their support by the USIM is optional.
Support of two name fields per entry
The support of two name fields per entry shall be specified to allow, for example, for two different representations of the same name, for example, in Japanese and English.
Support of multiple phone numbers per entry
The support of multiple phone numbers per entry shall be specified, for example office, home, fax, mobile or pager. In addition to that, information for identifying those attributes is needed.
Support of email address
The support of email addresses linked to Phone Book entries shall be specified. In addition to that, information for identifying these addresses is needed.
Support of user definable groupings
The specification shall support the grouping of Phone Book entries into groups defined by the user, for example, business and private.
Support of hidden entries
The specification shall support means of marking Phone Book entries as "hidden".
Number of entries
The specification shall support storage of at least 500 entries.
Mode of alerting
[FFS]

  Solution

To be compliant with the 21.111 v3.00 we need to include the phonebook functionality as an application in the USIM where the limitation of the structure “definition” of the files as are described in 7816-3(4) does not constraint the functionality.

The solution will be transparent for the external world (ME), special APDUs will be adapted to handle the application, for each entry in the phone book the structure will be linked to one phone number or more. 

Name
Nickname
E-mail
Grp1
Grp2

Hm  Phone

FX  Phone

				

Entry of phonebook { 	
Name :		Char(12) ;	X1
			Nickname	Char(10) ;	X2
			E-mail		Char(25) ;	X3
			Grp1		Char(5) ;	X4
			Grp2		Char(5) ;	X5
			Hidden flag 	Char(1);	X6
			Phone Number{
tag		Char(2);	X7
					Phone		Char(14);	X8
					}
		        }

Note1 		X1 to X6 are variable.
X7, X8 are fixed.

Index	Name	Nickname	e-mail	Grp1	Grp2	H-Flag	
001	John	JJ	JJ@slb.ca	per		X	
002	Peter	PP	Peter@dlow.com	pro			

							
.							
.							
.							
.							
.							

Index	Object-Index	Ref	Phone-number	
001	0001	HM	+1 409 123 4123	
002	0001	FX	+1 309 098 7654	
003	0001	OF	+1 409 097 1234	
004	0002	FX	+1 590 876 2345	
005	0007			
006				
.				
0F1	0001	MB	+1 467 653 4545	
.				
.				
				
FFF				

Index =record number.
FFF will be a maximum 

Implementation

Administration commands

APDU 	Create phonebook
		To define number of entries and the values of the length of the object fields X1….X6
					X1=Alphatag (ADN) – (X7);
		To define number maximum of phone numbers
		
		To define which CHV will be used.

INPUT:
		Maximum Number of object-record,
		X1 value of the length of the name,
		X2 value of the length of the nickname,
		X3 value of the length of the e-mail,
		X4 value of the length of the Grp1,
		X5 value of the length of the Grp2,
		X6 value of the length of the H-Flag,
		Maximum Number of Phone-number >= Number of object-record,

OUTPUT
	OK
	NOK

APDU Delete phonebook

	To delete all the files relative to the phonebook

APDU Retrieve structure “read binary”
	Objective: retrieve the values of   X1,X2,X3..X6

Those values will be stored in a binary file accessible for read only without any condition. 

Operation commands

Add Object

	Objective: add an object (entry phonebook)

	Since the file is an elementary file Extended-linear fixed Update APDU will be used.

Delete Object

	Objective: Delete object (entry phonebook + all the linked phone-numbers)

This function consist of  updating the record of object file and the records of phone-number file 

Retrieve Object

	Objective: Retrieve data under specific conditions.
	Phase 1: Retrieve all data in one APDU NO CONDITIONS
	Phase 2: TBD

Scenario

SELECT PHONEBOOK

INPUT: 
	Case of
		-Verification key for hidden records presented:

		-No verification key presented:

OUTPUT:

SW1=XX
SW2=”YY” length of data to retrieve

GET DATAPHONEBOOK 
INPUT:
	SW2 from SELECT
	Or
	NDBR

OUTPUT:

LOCR, RNUM-O, X1, X2, X3, X4, X5, RNUM-P, X7, X8, RNUM-P, X7, X8…., LOCR ….NDBR

LOCR: 		Length of coming Record.
RNUM-O: 	Record Number of the Object
RNUM-P: 	Record Number of the Phone
NDBR: 		Number of data-bytes to be retrieved. 

UPDATE PHONEBOOK

INPUT
	Case 
           	Data field:
RNUM-O, X1, X2, X3, X4, X5, X6
           	Update phone number:
	RNUM-O, RNUM-P, X7, X8
              Add phone number:
	RNUM-O, X7, X8
Delete phone number:
	Same as Update phone number 

OUTPUT

	OK
	NOK

To perform those functions we need to adapt two special APDUs 
SEEK 
UPDATE RECORD 

 UPDATE RECORD

Command Message

	APDU HEADER
CLA = ‘8X’. X as defined in 7816-4
	INS= ‘DC’
	P1-P2 See Below

	APDU BODY
		Interpretation of the Body APDU depends on b3,b2,b1 of P2
	Lc :
		Case 1 (Simple) : Lenght of the Data to be overwritten
		Case 2  (Extended): 1+ Lenght of the Data to be overwritten
	Data Field :
		Case 1 (Simple) : Data to be overwritten
		Case 2 (Extended): First byte is the lowest Byte of the Record Number
			  Subsequent bytes 

P1-P2 
Interpretation of P1-P2 depends on b3,b2,b1 of P2:

-Case 1 (Simple):
If b3,b2,b1 of P2 =100 then P1 codes the Record Number to be updated (Up to 256 entries). Coding of P2 is the same as 7816-4.
-Case 2 (Extended):
If b3,b2,b1 of P2 =111, then the Record Number is coded over 2 bytes as [P1 || First Data Field byte].
		
Response Message

	As defined in ISO 7816-4

COMMENT  For Case 1 (Record Number <255) , this command (Structure&Coding) is the same as defined in 7816-4

SEEK (SEARCH RECORD) Command

After a succesful SEEK the record pointer is set to the Record in which the pattern was found.The response Data Field contains the Record Number over 2 bytes.

Command Message

CLA = ‘8X’. X as defined in 7816-4
	INS= ‘A2’
	P1-P2 See Texte below
	LC : Lenght of the subsequent data field coded over one byte
	Data Field : String Data Pattern to be found
	LE = Empty or ‘02’

	P1=’00’
	P2 specifies type and mode
		‘x0’ = Search from the Beginning of the Phonebook Forward
		‘x1’ = Search from the End of the Phonebook Backwards
		‘x2’ = Search from the Next Current Pointer Position 
Forward
		‘x3’ = Search from the Previous Current Pointer Position Backwards
		Where x=’0’ specifies type 1 SEEK and x=’1’ type 2 SEEK.
		
Response Message

	Data Field : Empty or Record Number where the match is found coded over 2 bytes
	SW1-SW2 Status Bytes
		The following specific warning condition may occur
		SW1=’62’ with SW2= ‘82’
		SW2= ‘82’ Means end of file reached before finding matching string.The Response Data Field shall be empty.

READ RECORD is not mandatory for time being.

Compatibility 2G/3G

The ICC will make the difference between the two environments 2G and 3G because of the way the application “environment” is selected. The ICC will have a filter in 2G environment to catch all the commands related to ADN and it will map them to have the information from phonebook file.

The Aplhatag(ADN)= X1,X7
The Length of BCD number/SSC contents + TON and NPI + Dialling Number/SSC String + Capability/Configuration Identifier + Extension1 Record Identifier = X8

Annex 
Extended-linear fixed EF
An EF with linear fixed structure consists of a sequence of records all having the same (fixed) length. The first record is record number 1. The length of a record as well as this value multiplied by the number of records are indicated in the header of the EF.
Header			
Body		Record 1	
		Record 2	
		      :	
		      :	
		Record n	

Figure 5: Structure of a linear fixed file
There are several methods to access records within an EF of this type:
‑	absolutely using the record number;
‑	when the record pointer is not set it shall be possible to perform an action on the first or the last record by using the NEXT or PREVIOUS mode;
‑	when the record pointer is set it shall be possible to perform an action on this record, the next record (unless the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first record);
‑	by identifying a record using pattern seek starting:
‑	forwards from the beginning of the file;
‑	forwards from the record following the one at which the record pointer is set (unless the record pointer is set to the last record);
‑	backwards from the end of the file;
‑	backwards from the record preceding the one at which the record pointer is set (unless the record pointer is set to the first record).
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action.
NOTE 1:	It is possible to have more than 255 records in a file of this type because the number of record will be coded in 16 bits, and each record cannot be greater than 255 bytes.

READ RECORD
This function reads one complete record in the current Extended-linear fixed EF. The record to be read is described by the modes below. This function shall only be performed if the READ access condition for this EF is satisfied. The record pointer shall not be changed by an unsuccessful READ RECORD function.
Four modes are defined:
	CURRENT: The current record is read. The record pointer is not affected.
	ABSOLUTE: The record given by the record number is read. The record pointer is not affected.
	NEXT: The record pointer is incremented before the READ RECORD function is performed and the pointed record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD (next) shall read the first record and set the record pointer to this record.
	If the record pointer addresses the last record in a Extended-linear fixed EF, READ RECORD (next) shall not cause the record pointer to be changed, and no data shall be read.
		PREVIOUS: The record pointer is decremented before the READ RECORD function is performed and the pointed record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD (previous) shall read the last record and set the record pointer to this record.
	If the record pointer addresses the first record in a Extended-linear fixed EF, READ RECORD (previous) shall not cause the record pointer to be changed, and no data shall be read.
Input:
‑	mode, record number (absolute mode only) and the length of the record.
Output:
‑	the record.
UPDATE RECORD
This function updates one complete record in the current Extended-linear fixed  EF. This function shall only be performed if the UPDATE access condition for this EF is satisfied. The UPDATE can be considered as a replacement of the relevant record data of the EF by the record data given in the command. The record pointer shall not be changed by an unsuccessful UPDATE RECORD function. 
The record to be updated is described by the modes below. two modes are defined.

	CURRENT: The current record is updated. The record pointer is not affected.
	ABSOLUTE: The record given by the record number is updated. The record pointer is not affected.
	
Input:
‑	mode, record number (absolute mode only) and the length of the record;
‑	the data used for updating the record.
Output:
‑	none.
SEEK
This function searches through the current linear fixed EF to find a record starting with the given pattern. This function shall only be performed if the READ access condition for this EF is satisfied. Two types of SEEK are defined:
Type 1	The record pointer is set to the record containing the pattern, no output is available.
Type 2	The record pointer is set to the record containing the pattern, the output is the record number.
The SIM shall be able to accept any pattern length from 1 to 16 bytes inclusive. The length of the pattern shall not exceed the record length.
Four modes are defined:

‑	from the beginning forwards;
‑	from the end backwards;
‑	from the next location forwards;
‑	from the previous location backwards.
If the record pointer has not been previously set (its status is undefined) within the selected Extended-linear fixed EF, then the search begins:
‑	with the first record in the case of SEEK from the next location forwards; or
‑	with the last record in the case of SEEK from the previous location backwards.
After a successful SEEK, the record pointer is set to the record in which the pattern was found. The record pointer shall not be changed by an unsuccessful SEEK function.
Input:
‑	type and mode;
‑	pattern;
‑	length of the pattern.
Output:
‑	type 1: none;
‑	type 2: status/record number