3GPP TSG-T2 SWG3 SMS / EMS ad hoc #1
London, UK
3rd to 5th April 2001	T2E010020	

Agenda Item:	

Source:	Motorola

Title:	Mechanism for the limited distribution of EMS objects

Document for:	

___________________________________________________________________________

3GPP TSG-T2 #13 EMS Ad-Hoc
London, UK
3rd - 5th April 2001	T2E-010020 	
CR-Form-v3	
CHANGE REQUEST	
	
	23.040	CR	CR-Num		rev	-		Current version:	4.1.0		
	
For HELP on using this form, see bottom of this page or look at the pop-up text over the  symbols.	
	
Proposed change affects:		(U)SIM		ME/UE	X	Radio Access Network		Core Network		
	
Title:		Mechanism for the limited distribution of EMS objects	
		
Source:		Motorola	
		
Work item code:		SMS/EMS		Date: 	02 April 2001	
					
Category:		C		Release: 	REL-5	
	
Use one of the following categories:
F  (essential correction)
A  (corresponds to a correction in an earlier release)
B  (Addition of feature), 
C  (Functional modification of feature)
D  (Editorial modification)
Detailed explanations of the above categories can
be found in 3GPP TR 21.900.	
Use one of the following releases:
2	(GSM Phase 2)
R96	(Release 1996)
R97	(Release 1997)
R98	(Release 1998)
R99	(Release 1999)
REL-4	(Release 4)
REL-5	(Release 5)	
		
Reason for change:		There is currently no means of limiting the distribution of an object within SMS messages. 	
		
Summary of change:		Add a new information element to provide a means of limiting distribution of objects. 	
		
Consequences if 	
not approved:	There will be no means of limiting the distribution of SMS objects.	
		
Clauses affected:			
		
Other specs			 Other core specifications			
affected:		 Test specifications		
		 O&M Specifications		
		
Other comments:			

How to create CRs using this form:
Comprehensive information and tips about how to create CRs can be found at: http://www.3gpp.org/3G_Specs/CRs.htm.  Below is a brief summary:
1)	Fill out the above form. The symbols above marked  contain pop-up help information about the field that they are closest to.
2)	Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word "revision marks"  feature (also known as "track changes") when making the changes. All 3GPP specifications can be downloaded from the 3GPP server under ftp://www.3gpp.org/specs/ For the latest version, look for the directory name with the latest date e.g. 2000-09 contains the specifications resulting from the September 2000 TSG meetings.
3)	With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of the clause containing the first piece of changed text.  Delete those parts of the specification which are not relevant to the change request.

9.2.3.24	TP‑User Data (TP‑UD)
The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see subclause 9.2.2).
The TP‑User‑Data field may comprise just the short message itself or a Header in addition to the short message depending upon the setting of TP‑UDHI.
Where the TP‑UDHI value is set to 0 the TP‑User‑Data field comprises the short message only, where the user data can be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.
Where the TP‑UDHI value is set to 1 the first octets of the TP‑User‑Data field contains a Header in the following order starting at the first octet of the TP‑User‑Data field.
Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire TPDU exactly as received.
FIELD							LENGTH
Length of User Data Header				1 octet
	Information‑Element‑Identifier "A"			1 octet
	Length of Information‑Element "A"		1 octet
	Information‑Element "A" Data			1 to "n" octets
	Information‑Element‑Identifier "B"			1 octet
	Length of Information‑Element "B"		1 octet
	Information‑Element "B" Data			1 to "n" octets
	Information‑Element‑Identifier "n"			1 octet
	Length of Information‑Element "n"			1 octet
	Information‑Element "n" Data			1 to "n" octets
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.

Figure 9.2.3.24 (a) 
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.

Figure 9.2.3.24 (b)
The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the TP‑User-Data content of the Short Message.

Figure 9.2.3.24 (c)
The definition of the TP‑User‑Data‑Length field which immediately precedes the "Length of User Data Header" is unchanged and shall therefore be the total length of the TP‑User‑Data field including the Header, if present. (see 9.2.3.16)
The "Length‑of‑Information‑Element" fields shall be the integer representation of the number of octets within its associated "Information‑Element‑Data" field which follows and shall not include itself in its count value.
The "Length‑of‑User‑Data‑Header" field shall be the integer representation of the number of octets within the "User‑Data‑Header" information fields which follow and shall not include itself in its count or any fill bits which may be present (see text below).
Information Elements may appear in any order and need not necessarily follow the order used in the present document.
In the case where there are no multiple instances of any Information Element type: If Information Elements are duplicated (either with the same or different content), within one single SM or within one segment of a concatenated message then the contents of the last occurrence of the Information Element shall be used.
In the case where there are multiple instances of any Information Element type: If certain types of Information Elements are duplicated (either with the same or different content) within one single SM or within one segment of a concatenated message and there is a contradiction in meaning (e.g. more than one Special Message Indication for voice) or there is a contradiction of Information Element types (e.g. an 8bit port address and a 16bit port address), then the contents of the last occurrence of the Information Element shall be used. Other types of Information Elements may occur more than once when there is additional information of the same type to be conveyed. The individual specifications for each Information Element will state if multiple use is permitted and in such a case will also indicate the maximum number of occurrences within one User Data Header.
If the length of the User Data Header overall is such that there appear to be too few or too many octets in the final Information Element then the whole User Data Header shall be ignored.
If any reserved values are received within the content of any Information Element then that part of the Information Element shall be ignored.

The Information Element Identifier octet shall be coded as follows:
VALUE (hex)	MEANING	
00	Concatenated short messages, 8-bit reference number	
01	Special SMS Message Indication	
02	Reserved	
03	Value not used to avoid misinterpretation as <LF> character	
04	Application port addressing scheme, 8 bit address	
05	Application port addressing scheme, 16 bit address	
06	SMSC Control Parameters	
07	UDH Source Indicator 	
08	Concatenated short message, 16-bit reference number	
09	Wireless Control Message Protocol	
0A	Text Formatting	
0B	Predefined Sound	
0C	User Defined Sound (iMelody max 128 bytes)	
0D	Predefined Animation	
0E	Large Animation (16*16 times 4 = 32*4 =128 bytes)	
0F	Small Animation (8*8 times 4 = 8*4 =32 bytes)	
10	Large Picture (32*32 = 128 bytes)	
11	Small Picture (16*16 = 32 bytes)	
12	Variable Picture	
13	User prompt indicator	
14-1F	Reserved for future EMS features (see subclause 3.10)	
20	RFC 822 E-Mail Header	
21	Limited Distribution Indicator	
20-6F	Reserved for future use	
70 – 7F	(U)SIM Toolkit Security Headers 	
80 – 9F	SME to SME specific use	
A0 – BF	Reserved for future use	
C0 – DF	SC specific use	
E0 – FF	Reserved for future use	

A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next information element by looking at the length of the current information element and skipping that number of octets.

The SM itself may be coded as 7, 8 or 16 bit data.

If 7 bit data is used and the TP‑UD‑Header does not finish on a septet boundary then fill bits are inserted after the last Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the entire TP‑UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile shall be capable of displaying the SM itself although the TP‑UD Header in the TP‑UD field may not be understood.
It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7 bit alphabet so that earlier Phase mobiles, which do not understand the TP‑UD‑Header, shall over‑write the displayed TP‑UD‑Header with the SM itself.

If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.

If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself although the TP‑UD header may not be understood.

It is also possible for mobiles not wishing to support the TP‑UD header to check the value of the TP‑UDHI bit in the SMS‑Deliver PDU and the first octet of the TP‑UD field and skip to the start of the SM and ignore the TP‑UD header.

The Limited Distribution Indicator (LDI) IEI puts circulation or delivery restrictions on SMS objects that a terminal device can transfer in an SMS-Delivery message. The support for this IE is mandatory. The LDI has 1 octet of data that specifies the distribution limitations of IE(s) that immediately follow it. If no LDI precedes an IE, then the distribution of the object is not limited. 

Octet 1
Bit 1, bit 0
00	associated object(s) has limited forwarding capabilities
01	associated object(s) has multiple forwarding capabilities
10	associated object(s) has no forwarding capabilities

Bits 7, 6, 5, 4, 3, 2
Define the ‘limited forwarding capabilities’ or the number of occurrences the associated object(s) can be used in an SMS-Submit message. *

Octet 2
Bits 7, 6, 5, 4, 3, 2, 1, 0Define the ‘multiple forwarding capabilities’ or the number of occurrences the associated object(s) can be used in an SMS-Submit message. *

* Note: Each time an LDI’s associated object(s) is used in an SMS-Submit message, the values of the ‘limited forwarding capabilities’ and ‘multiple forwarding capabilities’ fields shall be one half the value received in the SMS-Deliver message.