3GPP TSG CN Plenary Tdoc NP-010264

Meeting #12, Stockholm, Sweden

13th - 15th June 2001

Source: TSG CN WG 1
Title: All LSs sent from CN1 since TSG#11 meeting,- pack1
Agenda item: 6.1.1
Document for: Information

Introduction:

This document contains 10 agreed LSs sent from TSG CN WG1, and are forwarded to TSG CN Plenary
meeting #12 for information only.

Meeting TDoc # Source Tdoc Title Comments

CN1_SA2_ N1-010582 Keith Proposed LS related with N1-010532 To: S2, N1/2/3/4 JM
04_SIP
CN1_SA2_ N1-010588 Andrew LS to SA3 proposing joint meeting To: S3, N1
04_SIP Allen CC: S2
Meeting TDoc # Source Tdoc Title Comments
CN1_17 N1-010685 Chairman Proposed LS on introduction of new Mobile To: TSGN Plenary
Country Codes (MCC)
CN1_17 N1-010718 Arne Reply to GERAN WG4 on GPRS attach type To: GERAN WG4 GPRS
in NMO I
CN1_17 N1-010799 Fransesc Liaison Statement on "Duplication avoidance Reply to N1-010689.
o protocol moved from 04.18 to 24.007" To:GERAN WG2
Cc: R2, R3
CN1_17 N1-010800 Rouzbeh/I Introduction of AMR-WB Reply to N1-010693
nma To: GERAN
Cc: N4, S4
CN1_17 N1-010801 Andrew Indication of Extended uplink TBF capability Reply to N1-010696
To: GERAN
Cc: S2, CN, SA
CN1_17 N1-010813 Francesc Liaison Statement on "RRC establish cause Reply to N1-010767
o mapping" To: R2
CN1_17 N1-010814 Apostolis Response to LS -UTRAN Initiated RAB Reply to N1-010771
Renegotiation/Reconfiguration (N1-010771 To: R3
or TSGR3#18(01)0305) Cc: S2
CN1_17 N1-010815 Apostolis Response to LS on NAS messages Reply to N1-010774
maximum length To: R3
(N1-010774 or TSGR3#19(01)0953) Cc: R2
3GPP TSG_CN WG1-SA WG2 Joint and CN1 Ad-Hoc Tdoc N1-010582
Sophia Antipolis, France
3 - 5 April, 2001

Title: LS “on GPRS work covering break in radio transmission”

Source: TSG CN WG1-SA2 SIP joint meeting
To: SA2, CN1/CN2/CN3/CN4 joint meeting
Cc:

Contact Person:
Name: Keith Drage
E-mail Address: drage@lucent.com
Tel. Number: +44 1793 776249

1. Overall Description:
The joint meeting of SA2 and CN1 identified the following item within 23.228 (see extract under 3 in this liaison) which
requires enhancement of a number of GPRS specifications under the control of various working groups.

It is desirable that the various work items are updated to reflect the required work, which appears to impact 23.060, GTP
and possibly other document.

It is also desirable that appropriate changes are progressed, and we would appreciate that the appropriate changes are
progressed by SA2 in 23.060 in order to lead this work.

2. Actions:

To TSG SA 2
ACTIONS: SA2 are asked to
Update their work item IM-CCR to identify changes to 23.060, and also to progress the required changes to
23.060.
Consider what is the mechanism to transfer the indication of the loss of radio coverage from GPRS
protocols to the CSCF.

To TSG CN 4
ACTION: CN4 are asked to capture new work on GTP in a work item and to progress those changes.

3. Attachments:
In full below (extract from 23.228)

"5.10.3 Network initiated session release

In case of a break in the radio connection or accidental/malicious removal of a PDP Context that is related to an IMS
session, the corresponding session should be terminated in order to avoid billing for session inactivity time. In the event
of a break in the radio connection, the RNC initiates the RAB release procedure, which in turn shall result in session
termination and a corresponding PDP context deactivation.
The following figure presents GPRS subsystem events that occur following a break in the radio connection. Only the
parameters that are required for the communication between the GGSN and the P-CSCF/PCF are shown in the
description below.
 UE UTRAN SGSN GGSN Proxy CSCF / PCF

1. RAB Release Request/Iu Release

2. Radio Access Bearer Release

3. Delete PDP Context Request

4. Release indication

5. SESSION
TERMINATION

6. Delete PDP Context Response

Figure 5.24: Network initiated session release - loss of radio

1. The RNC sends the RAB Release Request or Iu Release Request message to the SGSN to release the RAB.
2. The radio access bearer release procedure is performed. The radio bearers are released if they still exist.
3. The SGSN deactivates the PDP context by sending the Delete PDP Context Request message to the GGSN.
4. If a request state was created in the PCF at PDP context activation, the GGSN sends the Release indication message
to the PCF. The message indicates that the corresponding PDP context has been deactivated.
5. The Proxy-CSCF performs session termination.
6. The GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP context deletion.
After coverage is regained, the UE shall delete the PDP context in conversational or streaming class.
In the event that the UMTS bearer used for the transport of SIP signalling is released prior normal termination of the
session using SIP signalling then the IM Subsystem shall be informed.
The following figure presents GPRS subsystem events that occur as a result of accidental removal of a PDP Context
used for the transport of SIP signalling. Only the parameters which are required for the communication between the
GGSN and the P-CSCF/PCF are shown in the description below.
UE UTRAN SGSN GGSN Proxy CSCF / PCF

1. Deactivate PDP Context Req

2. Delete PDP Context

3. Release Indication

4. SESSION
5. Delete PDP Context TERMINATION
Response
6. Deactivate PDP Context Accept

7. Radio Access Bearer Release

Figure 5.25: Network initiated session release - loss of SIP signalling context

1. The UE deactivates a PDP context by sending a Deactivate PDP Context Request message to the
network.
2. The SGSN deactivates the PDP context by sending the Delete PDP Context Request message to the
GGSN.
3. If a request state was created in the PCF at PDP context activation, the GGSN sends the Release
indication message to the PCF. The message indicates that the corresponding PDP context has been
deactivated.
4. The proxy CSCF performs session termination, which is FFS.
5. The GGSN sends the Delete PDP Context Response message to the SGSN to acknowledge the PDP
context deactivation.
6. The SGSN responds to the UE with a Deactivate PDP Context Accept message
7. The UE performs the radio access bearer release procedure."
3GPP CN1-SA2 SIP adhoc
3 – 4 April, 2001
Tdoc N1-010588
Sophia Antipolis, France

Title: LS on "Security for IM SIP session Signaling"

Source: TSG SA2-CN1 Joint SIP Adhoc
To: TSG SA WG3, TSG CN WG1
CC; TSG SA WG2
Contact Person:
Name: Andrew Allen

Email: caa019@email.mot.com

Tel : +1-847-435-0016

Attachments: None
___________________________________________________________________________

CN1 is currently developing the signaling flows for the IM subsystem in TS 24.228. In this
specification CN1 has already started the process of specifying the use of SIP header
fields within the SIP signalling messages, including which nodes add headers or modify
their contents, based on the architecture specified in TS 23.228
CN1 is aware that SA3 held a joint meeting with SA2 in February where security issues
with the IM subsystem were discussed including the security associations between nodes.
CN1 also understands that at this meeting some concern was raised that there are issues
arising between the security associations currently proposed by SA3 and the SIP protocol
header useage currently being defined by CN1.
In order to achieve a full mutual understanding by both working groups of the issues of
mutual interest regarding SIP signalling security and to prevent any incompatible work
progressing in this area between the two groups, CN1 believes that a presentation by SA3
on the issue of SIP signalling security would be very beneficial and therefore invites SA3
to send representatives to make such a presentation to CN1 in the near future. CN1 would
also be happy to provide experts to make a presentation to SA3 on the current details of
SIP signalling.

The following security related issues have already been identified by CN1:

• SIP Header Parameter modification by I-CSCF

• Via and Record Route Header Hiding by I-CSCF

• Contact header modification by P-CSCF

• Useage of the User Private Identity

• Authentication of Invite and other SIP session signaling messages

• Integrity protection of SIP signalling messages (especially the first message that is sent)

• Requirement for SIP signaling to support Key exchange for encryption of bearer
th
CN1 has their next meeting on the week of 14 May.

3GPP
1
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010685
Puerto Rico, 14th - 18th May 2001

Title: LS on Introduction of new Mobile Country Codes (MCC)

Reference LS
(If available)

Source: CN1 Chairman

TO (1: TSGN Plenary

Cc:

WI: TEI

Contact Person:
Name: Hannu Hietalahti
E-mail Address: Hannu.Hietalahti@nokia.com
Tel. Number: +358-40-5021724

Attachments:
(Please list documents numbers to be attached)

Date: 10.5.2001
___________________________________________________________________________

CN1 was asked to study how the addition of new Mobile Country Code (MCC) would impact the operation of the
system. The matter was discussed in CN1 #17 and the following scenarios were identified:

1. Using a new MCC in a country where none was used before

This can happen when a new political country is formed but it applies to all cases where a new MCC is allocated
to a country which for one or another reason did not use an MCC code before. For a mobile which is registered in
a PLMN under any other MCC the new PLMNs under the new MCC will be considered to be abroad. In this
scenario this will be true. So allocating an MCC to the new country causes no problems in UMTS system.

2. Using a new MCC in a country where at least one MCC is already in use
The use of additional MCC code(s) to a country which already has got at least one MCC will effect the operation
of mobiles which have been manufactured before the addition. The following points were identified:
• National roaming: Periodic HPLMN search is mandatory when roaming in home country. As the old
mobiles will not know that the new MCC is in the same country as the old MCC(s) of that country, they will
not perform HPLMN search when it would be needed as the new MCC will be assumed to be abroad, which
in this case will not be true. Periodic HPLMN search is defined already in GSM Phase 2+ Release 96 (GSM
03.22 v. 4.b.0 / 4.4.3.3)
The consequence of this is that these old mobiles will not return to the HPLMN until they lose coverage
from the network with the new MCC code.
• Background scan of higher priority PLMNs: When mobiles are roaming they perform the mandatory
background scan of higher priority PLMNs in the same country. Any Mobile Network Code (MNC) will be
ignored by the old mobiles if it is associated with the new MCC as it will be assumed to be in a different
country. Background scan is defined for the first time in R99 specification (TS 03.22 v.3.6.0 / 4.4.3.3)
The consequence of this is the old mobiles will not move to the higher priority PLMN until they lose
coverage from the network with the new MCC code.

CN1 is aware that there are several countries to which multiple MCC codes have been allocated. But the only
specified case on support of multiple MCC in one specific area corresponds to North America. This case has
been explicitly covered by specific exception handling for Country Codes in range of 310 to 316 which has been
defined in GSM 03.22 from R’98 onwards.
1
Please write any action required from the groups in a clear way.
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010685
Puerto Rico, 14th - 18th May 2001

Deletion of an existing MCC was also discussed briefly and that has got no side effect on the system behaviour.

To keep an homogeneous behaviour of all terminals (legacy ones and new ones supporting a potential evolution
of MCC meaning) before and after a PLMN starts using new MCC in area where one MCC was already in use, it
will be necessary to update all legacy terminals.
3GPP TSG_CN WG1 Tdoc N1-010718
Porto Rico, USA
14 - 18 May, 2001

Title: LS “Reply to GERAN WG4 on GPRS attach type in NMO I”

Source: TSG CN WG1
To: TSG GERAN WG4 GPRS
Cc:

Contact Person:
Name: Arne Lyzenga
E-mail Address: arne.lyzenga@mci.co.uk
Tel. Number: +44 (0)1635 871466

1. Overall Description:
nd th
TSG CN WG1 thanks TSG GERAN WG4 GPRS for their LS G4-010330 dated 22 – 26 April 2001 related
to the GPRS attach type in NMO I.

2. Actions:

To GERAN WG4

In answer to your question related to the attach type in NMO I, CN1 provides the following explanation:
An MS in NMO I, which wishes to IMSI attach for GPRS and non-GPRS services shall always use the
combined GPRS attach, using the attach type “Combined attach”. This is independent of the value
of the ATT flag.
An MS in NMO I, which is already IMSI attached for non-GPRS services, wishing to IMSI attach for GPRS
services (i.e. which does not automatically attach for GPRS services at power up), shall use the
combined GPRS attach, with attach type “Combined GPRS attach” or with attach type “GPRS
attach while IMSI attached”. This is independent of the value of the ATT flag.
CN1 is aware that the use of the attach type “GPRS attach while IMSI attached” is not clearly specified, but
the use of it is optional in NMO I.

Network Mobile State

conditions (having just powered on) Attach type
ATT=0 MS class A or B
MS that does not auto attach Combined GPRS attach /
MS in same LAI GPRS attach while IMSI attached
(No IMSI attach performed and no
Normal location update as ATT = 0)
GPRS attach requested by user
ATT=0 MS class A or B
MS that does not auto attach Combined GPRS attach /
MS in new LAI GPRS attach while IMSI attached
(Normal location update already
performed due to new LAI)
GPRS attach requested by user
ATT=1 MS class A or B
MS that does not auto attach Combined GPRS attach /
(LAI not relevant due to ATT flag) GPRS attach while IMSI attached
(Normal location update already
performed as ATT=1)
GPRS attach requested by user
ATT=0 MS class A or B
MS auto attaches to GPRS Combined GPRS / IMSI attach
MS in same LAI
(Normal location update not necessary)
ATT=0 MS class A or B
MS auto attaches to GPRS Combined GPRS / IMSI attach
MS in new LAI
(Normal location update not possible
due to combined GPRS procedures)
ATT=1 MS class A or B
MS auto attaches to GPRS Combined GPRS / IMSI attach
MS in same or new LAI
(No IMSI attach performed and no
Normal location update due to
combined GPRS procedures)
ATT=0 and 1 MS class C in GPRS mode
(IMSI attach not required) GPRS attach
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010799
Puerto Rico, 14th - 18th May 2001

Title: Liaison Statement on "Duplication avoidance protocol moved from 04.18 to

24.007"
Source: TSG_CN WG1
To: TSG_GERAN WG2
cc: TSG_RAN WG2, TSG_RAN WG3
Contact Person:
Name: Francesco Pica
E-mail Address: francesco.pica@eml.ericsson.se
Tel. Number: +447771774995

1. Overall Description:
TSG CN WG1 thank TSG GERAN WG2 for their LS TSGG#03(01)0413 (N1-010689) dated 15th – 19th
January 2001 on Information about current status in RAN2 on the interactions between RRC and upper
layers.
CN1 would like to inform GERAN2 that in CN1#16 a CR to 24.007 introducing the description of the
duplication avoidance protocol, was agreed (and then approved at CN plenary level). The CR is attached.

2. Actions:
To GERAN WG2 group.
TSG CN WG1 ask GERAN WG2 to remove section 3.1.4.3 from 04.18, as it is covered by 24.007 now.

3. Date of Next CN1 Meetings:

CN1_18 10th – 12th July 2001 Dresden, Germany.
CN1_19 27th – 31th August 2001

4. Attachments:
N1-010486 included below:

3GPP TSG-CN1 Meeting #16 Tdoc N1-010486

26 Feb. to 01 March 2001, Sophia France.
Revision of N1-010327
CR-Form-v3

CHANGE REQUEST
a 24.007 CR xxx a rev a Current version: a
- 3.6.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the a symbols.

Proposed change affects: a (U)SIM ME/UE X Radio Access Network X Core Network X

Title: a Transfer of the N(SD) duplication avoidance protocol from GSM 04.18

Source: a Ericsson

CR page 1
Work item code: a GSM/UMTS interworking Date: a 12/02/01

Category: a F Release: a R99

Use one of the following categories: Use one of the following releases:
F (essential correction) 2 (GSM Phase 2)
A (corresponds to a correction in an earlier release) R96 (Release 1996)
B (Addition of feature), R97 (Release 1997)
C (Functional modification of feature) R98 (Release 1998)
D (Editorial modification) R99 (Release 1999)
Detailed explanations of the above categories can REL-4 (Release 4)
be found in 3GPP TR 21.900. REL-5 (Release 5)

Reason for change: a The N(SD) duplication avoidance protocol applies to both UTRAN and GSM
access. However today this protocol is specified in GSM 04.18 which is a GSM
specification. This protocol should be described in a specification common for
UTRAN and GSM access.

Also this protocol is between the MS and the MSC and is therefore a core
network protocol and should be described in the core network specifications.

N1 sent a liaison (N1-001312) to GERAN WG2 to ask if the description could be

moved from the GSM 04.18. GERAN WG2 replied in LS GP-010413 and the
following text is quoted from this reply:

“On the issue, duplication avoidance protocol, TSG GERAN agrees that it is a core
network function and it should be moved to the CN1 specifications. TSG GERAN has
identified section 3.1.4.3 in 04.18 as the section to be moved to the CN1 specifications and
will remove the section from 04.18 when the addition in CN1 specifications has been
confirmed.”

Summary of change: a This CR copy/pastes the section 3.1.4.3 from GSM 04.18 v8.7.0 to a new section
11.2.3.2.3. This CR also contains some editorial clarifications in the pasted text
and in sections 11.2.3.2.1 and 11.2.3.2.2 . (different Word revision colors have
been used to differentiate the original text pasted from GSM 04.18 and the
subsequent changes that have been made)

Consequences if a The N(SD) duplication avoidance protocol is not decribed in the specification set
not approved: for the case of a single mode UTRAN mobile.

Clauses affected: a 11.2.3.2.1, 11.2.3.2.2, 11.2.3.2.3 (new section)

Other specs a Other core specifications a

affected: Test specifications
O&M Specifications

Other comments: a

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 a 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.

CR page 2
 11.2.3.2 Message type octet
11.2.3.2.1 Message type octet (when accessing Release 98 and older networks
only)
The message type octet is the second in a standard L3 message.
When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be
ignored.
When the radio connection started with a core network node of a Release 98 or older network, the message type IE is
coded as shown in figure 11.10a.
Bit 8 is encoded as "0"; value "1" is reserved for possible future use as an extension bit. A protocol entity expecting a
standard L3 message, and receiving a message containing bit 8 of octet 2 encoded as "1" shall diagnose a " message not
defined for the PD" error and treat the message accordingly.
In messages of MM, CC, SS, GCC, BCC , TC (Test Control, see GSM 04.14 and TS 34.109) and LCS protocol sent using
the transmission functionality provided by the RR layer to upper layers, and sent from the mobile station to the network ,
bit 7 of octet 2 is used for send sequence number, see section 11.2.3.2.3.
In all other standard layer 3 messages bit 7 is set to a default value. A protocol entity expecting a standard L3 message, and
not using the transmission functionality provided by the RR layer, and receiving a message containing bit 7 of octet 2
encoded different to the default value shall diagnose a "message not defined for the PD" error and treat the message
accordingly.
The default value for bit 7 is 0 except for the SM protocol where the default value is 1.
8 7 6 5 4 3 2 1

0 N (SD) octet 1
Message type
or 0

Figure 11.10a: Message type IE

Bit 1 to 6 of octet 2 of standard L3 messages contain the message type.

The message type determines the function of a message within a protocol in a given direction and for a given lower layer
SAP. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings
in different protocols), the direction (the same value may have different meanings in the same protocol, when sent from the
Mobile Station to the network and when sent from the network to the Mobile Station) and the lower layer SAP (the same
value may have different meanings, e.g., whether the message was sent on the SACCH or on the main DCCH).
Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard L3
message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the PD".
Some message types may correspond to a function not implemented by the receiver. They are then said to be non
implemented by the receiver.
The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not defined
for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol specification.
As a general rule, a protocol specification should not force the receiver to analyse the message further.
11.2.3.2.2 Message type octet (when accessing Release 99 and newer networks)
The message type octet is the second in a standard L3 message.
When a standard L3 message is expected, and a message is received that is less than 16 bit long, that message shall be
ignored.
When the radio connection started with a core network node of a Release 99 network, the message type IE is coded as
shown in figure 11.10b and 11.10c.
In messages of MM, CC, SS, GCC, BCC, TC (Test Control, see GSM 04.14 and TS 34.109) and LCS protocol sent using
the transmission functionality provided by the RR and/or access stratum layer to upper layers, and sent from the mobile
station to the network , bits 7 and 8 of octet 2 are used for send sequence number, see section 11.2.3.2.3.
In all other standard layer 3 messages bits 7 and 8 are set to a default value. A protocol entity expecting a standard L3
message, and not using the transmission functionality provided by the RR and/or access stratum layer, and receiving a
message containing bit 7 or bit 8 of octet 2 encoded different to the default value shall diagnose a "message not defined for
the PD" error and treat the message accordingly.
The default value for bit 8 is 0. The default value for bit 7 is 0 except for the SM protocol which has a default value of 1.
8 7 6 5 4 3 2 1
N (SD) or 0 Message type octet 1

Figure 11.10b: Message type IE (MM, CC, SS, GCC, BCC, TC and LCS)
 8 7 6 5 4 3 2 1

Message type octet 1

Figure 11.10c: Message type IE (protocol other than MM, CC, SS, GCC, BCC, TC and LCS)

Bit 1 to 6 of octet 2 of standard L3 messages contain the message type.

The message type determines the function of a message within a protocol in a given direction and for a given lower layer
SAP. The meaning of the message type is therefore dependent on the protocol (the same value may have different meanings
in different protocols), the direction (the same value may have different meanings in the same protocol, when sent from the
Mobile Station to the network and when sent from the network to the Mobile Station) and the lower layer SAP (the same
value may have different meanings, e.g., whether the message was sent on the SACCH or on the main DCCH).
Each protocol defines a list of allowed message types for each relevant SAP. A message received analysed as a standard L3
message, and with a message type not in the corresponding list leads to the diagnosis "message not defined for the PD".
Some message types may correspond to a function not implemented by the receiver. They are then said to be non
implemented by the receiver.
The reaction of a protocol entity expecting a standard L3 message and receiving a message with message type not defined
for the PD or not implemented by the receiver and the reception conditions is defined in the relevant protocol specification.
As a general rule, a protocol specification should not force the receiver to analyse the message further.
11.2.3.2.3 Sequenced message transfer operation
Upper layer messages sent using the RR sub-layer transport service from the mobile station to the network can be
duplicated by the data link layer in at least the following cases:
- in A/Gb mode, when a channel change of dedicated channels is required (assignment or handover
procedure) and the last layer 2 frame has not been acknowledged by the peer data link layer before the
mobile station leaves the old channel.
- in Iu mode, when an RLC re-establishment occurs (e.g. due to relocation) and the RLC layer has not acknowledged
the last one or more RLC PDUs before RLC re-establishment
- an inter-system change from Iu mode to A/Gb mode is performed and the RLC layer has not
acknowledged the last one or more RLC PDUs.
- an inter-system change from A/Gb mode to Iu mode is performed and the the last layer 2 frame in A/Gb
mode has not been acknowledged by the peer data link layer before the mobile station leaves the old
channel.
In these cases, the mobile station does not know whether the network has received the messages correctly. Therefore, the
mobile station has to send the messages againwhen the channel change is completed.
The network must be able to detect the duplicated received messages. Therefore, each concerned upper layer messages
must be marked with a send sequence number.
To allow for different termination points in the infrastructure of the messages of different PDs, the sequence numbering is
specific to each PD. For historical reasons, an exception is that messages sent with the CC, SS and MM PDs share the same
sequence numbering. In the following, the phrase upper layer message flow refers to a flow of messages sharing the same
sequence numbering. The different upper layer flows are MM+CC+SS, GCC, BCC, TC (Test Control, see GSM 04.14 and
TS 34.109) ,LCS. The GMM, SM and SMS protocols do not use layer 3 sequence numbering.
11.2.3.2.3.1 Variables and sequence numbers
11.2.3.2.3.1.1 Send state variable V(SD)
The mobile station shall have one associated send state variable V(SD) ("Send Duplicated") for each upper layer message
flow. The send state variable denotes the sequence number of the next in sequence numbered message in the flow to be
transmitted. The value of the corresponding send state variable shall be incremented by one with each numbered message
transmission. When the RR connection starts with a core network of release ’98 or earlier arithmetic operations on V(SD)
are performed modulo 2. When the RR connection starts with a core network of Release ’99 or later, arithmetic operations
on V(SD) are performed modulo 4. The mobile station shall keep using the same modulo (2 or 4) for the duration of the
RR connection.
11.2.3.2.3.1.2 Send sequence number N(SD)
At the time when such a message to be numbered is designated for transmission, the value of N(SD) for the message to be
transferred is set equal to the value of the send state variable V(SD).

CR page 4
 11.2.3.2.3.2 Procedures for the initiation, transfer execution and termination of the
sequenced message transfer operation
11.2.3.2.3.2.1 Initiation
The sequenced message transfer operation is initiated by establishing a RR connection. The send state variables V(SD) are
set to 0.
11.2.3.2.3.2.2 Transfer Execution
A release ’98 or earlier core network must compare the send sequence numbers of pairs of subsequent messages in the same
upper layer messages flow. In case the send sequence numbers of two subsequent messages in a flow are not identical, no
duplication has occurred. In case the send sequence numbers are identical, the network must ignore the second one of the
received messages.
A release ’99 or later core network shall discard any message whose N(SD) is not greater by one (modulo 4) than the
N(SD) of the last accepted message.
11.2.3.2.3.2.3 Termination
The sequenced message transfer operation is terminated by the RR connection release procedure.
Inter system change from A/Gb mode to Iu mode or from Iu mode to A/Gb mode shall not terminate the sequenced
message transfer. UMTS SRNC relocation shall not terminate the sequenced message transfer.

CR page 5
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010800
Puerto Rico, 14th - 18th May 2001

Title: Introduction of AMR-WB

Reference LS TSGG#4(01)0944 (N1-010493)

Source: TSG CN WG1
To: TSG GERAN
cc: TSG CN WG4, TSG SA WG4

Contact Person:
Name: Rouzbeh Farhoumand
E-mail Address: rouzbeh.farhoumand@ericsson.com
Tel. Number: +1 972 583 8061

1. Overall Description:
CN1 would like to thank TSG GERAN on their response Liaison Statement answering questions from CN1.
CN1 would like to inform TSG GERAN that the issue was discussed in CN1#17 with agreement to create a new
CN R5 WI to investigate the protocol impacts due to the introduction of Wideband AMR service.

CN1 discussed the two possible alternatives of indicating new codec types, either populating the BC IE octet
3a, or using the Supported Codecs List IE. The use of Supported Codecs List IE was agreed as preferable,
although further investigation to result into CR’s to indicate this will be required. This will be part of the new WI
for Release 5 and therefore no new codepoints in BC IE Octet 3a are allocated at this time.

Separate system identifiers for GSM 8-PSK / GSM GMSK were also discussed and agreed to be considered in
the WI.

2. Actions:
-

3. Date of Next CNx Meetings:

CN1_18 10th – 12th July 2001 Dresden, Germany.
CN1_19 27th – 31th August 2001

4. Attachment:
-
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010801
Puerto Rico, 14th - 18th May 2001
Agenda item: 9

Liaison Statement

From: 3GPP TSG CN WG1

To: 3GPP TSG GERAN
Cc: 3GPP TSG SA2, 3GPP TSG CN, 3GPP TSG SA

Subject: Indication of Extended uplink TBF capability

Contact: Andrew Howell, Motorola
andrew.howell@motorola.com

3GPP TSG CN WG1 thanks 3GPP TSG GERAN for the LS and corresponding CRs (TDoc GP-010978) on
the introduction of the new feature called “Extended uplink TBF” in the GPRS RLC/MAC protocol.

3GPP TSG CN WG1 has reviewed the change request on 3GPP TS 24.008 (REL-4), proposing to introduce
the MS_EXT_UTBF parameter as a one-bit field, and agrees that the CR is technically correct except for the
fact that the current version of TS 24.008 is v4.2.0.

In addition, 3GPP TSG CN WG1 has considered whether it would be acceptable, to introduce an option for
new mobile stations to utilise the feature on a R97 (or R99) basis by including the MS_EXT_UTBF parameter
in the R97 version of 3GPP TS 04.08, and has the following general comments:

• The proposal would add a new feature to R97, which is already frozen. Although the new feature would
be optional it was felt that the general principle should be discussed at the relevant plenary meetings, that
is 3GPP TSG GERAN, CN and SA, rather than at the working group level.

• Cherry picking features from later versions without any specification support in the reference versions
was not seen as a feasible approach.

• Finally, 3GPP TSG CN WG1 believe that there is a potential technical problem in introducing the feature
into R97. An implementation based on a previous version, e.g. of R97 in this case, might only interpret
part of the MS Radio Access Capability IE contents, meaning that some valid information could be lost
leading to undefined behaviour in the network. The current R97 definition of the MS Radio Access
Capability IE specifies a maximum length of 14 octets and the addition of the MS_EXT_UTBF parameter,
along with the extra bits needed to place it in the correct position, could potentially take the IE beyond the
currently defined limit.

Attached Tdocs:

Tdoc GP-010978 (N1-010696), incoming LS from GERAN

1B/6
,1]LS
3GPP TSG CN WG1 Meeting #17 Tdoc N1-010813
Puerto Rico, 14th - 18th May 2001

Title: Liaison Statement on "RRC establish cause mapping"

Source: TSG_CN WG1
To: TSG_RAN WG2,
cc:
Contact Person:
Name: Francesco Pica
E-mail Address: francesco.pica@eml.ericsson.se
Tel. Number: +447771774995

1. Overall Description:
TSG CN WG1 thank TSG RAN WG2 for their LS R2-010984 (N1-010767) dated 9th – 13th April 2001 on RRC
establish cause mapping, and would like to inform RAN2 about the outcome of the discussion on this issue in
CN1#17.
It is CN1’s understanding that the mapping from PS NAS procedures and RRC establishment cause should be
such that the MS shall:

1. at request to re-establish RABs, use either of RRC establishment causes: ‘Originating Conversational
Call’/’Originating Streaming Call’/’Originating Interactive Call’/’Originating Background Call’ depending on the
Traffic class in QoS of the most demanding PDP context for which the MS requests an re-establishment of the
RAB.
2. at new PDP context activation, use either of RRC establishment causes:
‘Originating Conversational Call’/’Originating Streaming Call’/’Originating
Interactive Call’/’Originating Background Call’; depending on the Traffic class in QoS of the most demanding
active PDP context.If QoS is not available, e.g. if there is not any PDP context active, then the MS shall use
RRC establishment cause ‘Originating High Priority Signalling’.
3. at modification of an existing PDP context, use either of RRC establishment causes:
‘Originating Conversational Call’/’Originating Streaming Call’/’Originating
Interactive Call’/’Originating Background Call’; depending on the Traffic class in QoS of the most demanding
active PDP context.
4. at deactivation of a PDP context, use RRC establishment cause ‘Originating High Priority Signalling’.
5. when performing a Routing Area Update in order to re-establish the signalling connection at RRC connection
release with cause “Directed signalling connection re-establishment”, use RRC establishment cause ‘Call re-
establsihment’,

NOTE: in 2. and 3. the term “active context” refer to already activated PDP contexts, meaning that either the
QoS of the new context being activated, or the requested QoS for the context being modified shall not be taken
into consideration.

CN1 kindly ask RAN2 to indicate whether RAN2 agree with CN1 and share the same understanding. In such a
case, a CR to 24.008 updating annex L could be agreed in CN1.

3. Date of Next CNx Meetings:

CN1_18 10th – 12th July 2001 Dresden, Germany.
CN1_19 27th – 31th August 2001

4. Attachments:
3GPP TSG-CN-WG1, Meeting #17 Tdoc N1-010814
14 – 18 May, 2001, Puerto Rico, USA

From: TSG CN WG1

To: TSG RAN WG3

CC: TSG SA WG2

Title: Response to LS - UTRAN Initiated RAB Renegotiation/Reconfiguration

(N1-010771 or TSGR3#18(01)0305)

Date: 15 May 2001

Contact: Apostolis Salkintzis, Motorola [mailto:salki@motorola.com]

___________________________________________________________________________

CN1 thanks RAN3 for their LS on “UTRAN Initiated RAB Renegotiation/Reconfiguration”.

CN1 understands that RAN3 has updated RANAP protocol for Rel-4 so as to allow (re-)negotiation of the RAB
parameters Maximum Bit Rate and Guaranteed Bit Rate. On the contrary, Traffic Class, RAB Asymmetry
Indicator, Delivery of Erroneous SDUs, and Source Statistic Descriptor parameters cannot be negotiated in Rel-
4.

CN1 wishes to inform RAN3 that TS 24.008/Rel-4 does not allow the definition of negotiable QoS parameters
and, therefore, a Rel-4 mobile is not able to indicate any negotiable QoS parameters at call/session setup. It is
expected that the definition of negotiable QoS parameters will be included in the Release 5 of TS 24.008.

Whether CN1 will make certain QoS parameters negotiable at call setup only, but not renegotiable later on, is for
further study and it is expected to be discussed at the CN1#19 meeting, 27 – 31 August. 2001.
3GPP TSG-CN-WG1, Meeting #17 Tdoc N1-010815
14 – 18 May, 2001, Puerto Rico, USA

From: TSG CN WG1

To: TSG RAN WG3

CC: TSG RAN WG2

Title: Response to LS on NAS messages maximum length

(N1-010774 or TSGR3#19(01)0953)

Date: 15 May 2001

Contact: Apostolis Salkintzis, Motorola [mailto:salki@motorola.com]

___________________________________________________________________________

CN1 thanks RAN3 for their LS on NAS messages maximum length.

CN1 confirms that the length of a NAS message does not exceed 4095 octets, so it can fit in the RRC
NAS message IE without segmentation.