5
|
-----
|
------
|
Release 5 and earlier
|
----------
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
|
|
6
|
-----
|
------
|
Release 6
|
----------
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
|
|
6
|
S2-060004
|
LS In
|
Reply LS (from SA WG5) on Detecting new RAT type GAN
|
SA WG5 (S5-054579, T-Mobile)
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
SA WG5 thanks CT WG4 for the LS on detecting the RAT type GAN, and confirms that there are indeed requirements for indicating this RAT type in SGSN and GGSN charging. After studying the LS responses from GERAN (GP-051776) and SA WG2 (S2-051889) on this same issue, SA WG5 SWG-B comes to the following conclusions: - It may not be possible for the SGSN to detect the difference between a BSC and a GANC through signalling, however this can be achieved through O&M means. - In SA WG5's understanding, the same situation already arises in earlier 3GPP releases in that the SGSN may not be able to distinguish (through other means than O&M) between GERAN and UTRAN when GERAN Iu mode is used. - Once the SGSN is aware of RAT type GAN through O&M means, it is expected that this RAT type can be forwarded via GTP to the GGSN in the same way as the RAT types that already existed in earlier 3GPP releases. - SA WG5's charging specifications for SGSN and GGSN offline and online charging reference the RAT type specified in 3GPP TS 29.060. Consequently, if the RAT type is amended in TS 29.060 to also include GAN, then the charging functionality will automatically be given without any need for further specification changes in SA WG5. While it is believedthat the above solution requires a change to TS 29.060, SA WG5 has not analysed if and whether such change or any other changes to non-charging TSs are needed to implement its conclusions.
|
Noted
|
6
|
S2-060120
|
[CR]
|
Proposed CR0143 to 23.234: Correction of some references (Rel-6)
|
LG Electronics
|
23.234
|
0143
|
-
|
F
|
6.7.0
|
Rel-6
|
WLAN
|
References to 3GPP TS 29.002 are replaced by references to 3GPP TS 23.060 and 23.093 in section 6.3.3.
|
Revised in S2-060446
|
6
|
S2-060160
|
DISCUSSION
|
Discussion on Relocation of Preserved PDP contexts
|
Lucent Technologies
|
23.060
|
-
|
-
|
-
|
-
|
-
|
TEI6
|
Discussion on Relocation of Preserved PDP contexts, related to incoming RAN WG3 LS
|
Used for discussions on CR in S2-060161
|
6
|
S2-060161
|
[CR]
|
Proposed CR0543 to 23.060: Clarification of Re-establishment of preserved RABs (Rel-6)
|
Lucent Technologies
|
23.060
|
0543
|
-
|
F
|
6.11.0
|
Rel-6
|
TEI6
|
Summary of change: It is specified that the target RNC shall only establish the existing RABs in the source RNC during SRNC relocation. For relocations in combination with Hard Handover or Cell/URA update, the target RNC may establish the same RABs that existed in the source RNC. The UE shall preserve any PDP contexts for which the RB is not established.
|
Revised in S2-060448
|
6
|
S2-060234
|
[CR]
|
Proposed CR0545 to 23.060: Clarification of dynamic PDP address for wild card APN (Rel-6)
|
Huawei
|
23.060
|
0545
|
-
|
F
|
6.11.0
|
Rel-6
|
TEI6
|
Summary of change: It is clarified that when APN (S) = wild card，activation will be accepted only if PDP address(S) is dynamic.
|
Noted
|
6
|
S2-060281
|
DISCUSSION
|
GAN charging: needs and proposed solution
|
Alcatel
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
This contribution discusses the needs for GAN charging in PS domain as well as in CS domain. It proposes an agreement on a generic and future-safe solution, and to send supplementary questions to SA WG1.
|
Noted
|
6
|
S2-060287
|
DISCUSSION
|
GAN & Home zone cell charging, handling of changed cell characteristics
|
Ericsson
|
-
|
-
|
-
|
-
|
-
|
-
|
TEI6
|
The intent with this document is to present an alternative for how changing cell characteristics can be indicated to GGSN and beyond. The issue of implementing home zone cells and specific GAN/UMA charging is also discussed and one alternative is recommended.
|
Noted
|
6
|
S2-060288
|
[CR]
|
Proposed CR0014 to 23.251: Clarification of netshare re-routing (Rel-6)
|
Ericsson
|
23.251
|
0014
|
-
|
F
|
6.5.0
|
Rel-6
|
TEI6
|
Summary of change: Clarification that the RNC shall receive an indication when the re-routing procedure is used for coordination purposes.
|
Revised in S2-060449
|
6
|
S2-060294
|
[LS OUT]
|
Response LS on Relocation of Preserved RABs
|
Lucent Technologies
|
-
|
-
|
-
|
-
|
-
|
-
|
SAE
|
Response LS on Relocation of Preserved RABs
|
Noted
|
6
|
S2-060446
|
[CR]
|
Proposed CR0143R1 to 23.234: Correction of some references (Rel-6)
|
LG Electronics
|
23.234
|
0143
|
1
|
F
|
6.7.0
|
Rel-6
|
WLAN
|
Summary of change: TS 23.002 is inserted in section 2. References to 3GPP TS 29.002 are replaced by references to 3GPP TS 23.002 in section 6.3.3.
|
Revised in S2-060454
|
6
|
S2-060447
|
[CR]
|
Proposed CR0144R1 to 23.234: Correction of some references (Rel-7)
|
LG Electronics
|
23.234
|
0144
|
1
|
A
|
7.0.0
|
Rel-7
|
WLAN
|
Summary of change: TS 23.002 is inserted in section 2. References to 3GPP TS 29.002 are replaced by references to 3GPP TS 23.002 in section 6.3.3.
|
Revised in S2-060455
|
6
|
S2-060448
|
[CR]
|
Proposed CR0543R1 to 23.060: Clarification of Re-establishment of preserved RABs (Rel-6)
|
Lucent Technologies
|
23.060
|
0543
|
1
|
F
|
6.11.0
|
Rel-6
|
TEI6
|
During an inter-SGSN SRNS relocation, it is not possible for the target SGSN to know which non-RT (Interactive/Background) RABs are preserved and will attempt to set up all the RABs that are not set to 0kb/s for uplink and downlink including the preserved non-RT RABs. Target RNC behaviour is clarified.
|
Postponed to meeting #51
|
6
|
S2-060449
|
CR
|
Proposed CR0014R1 to 23.251: Clarification of netshare re-routing (Rel-6)
|
Ericsson
|
23.251
|
0014
|
1
|
F
|
6.5.0
|
Rel-6
|
TEI6
|
Summary of change: Clarification that the RNC shall receive an indication when the re-routing procedure is used for coordination purposes.
|
Approved
|
6
|
S2-060450
|
[LS OUT]
|
[Draft] Reply LS on PS and CS coordination in shared RAN for MOCN
|
SA WG2
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
|
Revised in S2-060514
|
6
|
S2-060454
|
CR
|
Proposed CR0143R2 to 23.234: Correction of some references (Rel-6)
|
LG Electronics
|
23.234
|
0143
|
2
|
F
|
6.7.0
|
Rel-6
|
WLAN
|
Summary of change: TS 23.002 is inserted in section 2. References to 3GPP TS 29.002 are replaced by references to 3GPP TS 23.002 in section 6.3.3.
|
Approved
|
6
|
S2-060455
|
CR
|
Proposed CR0144R2 to 23.234: Correction of some references (Rel-7)
|
LG Electronics
|
23.234
|
0144
|
2
|
A
|
7.0.0
|
Rel-7
|
WLAN
|
Summary of change: TS 23.002 is inserted in section 2. References to 3GPP TS 29.002 are replaced by references to 3GPP TS 23.002 in section 6.3.3.
|
Approved
|
6
|
S2-060514
|
[LS OUT]
|
[Draft] Reply LS on PS and CS coordination in shared RAN for MOCN
|
SA WG2
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
SA WG2 thanks RAN WG3 for their LS regarding PS and CS coordination in shared RAN for MOCN. SA WG2 has decided to update TS23.251 so that the CN node indicates to the RNC when the re-routing procedure is used for coordination purposes. The approved CR is attached (S2-060449). SA WG2 believes that the stage 2 description of PS and CS coordination is now finalized on this point.
|
Revised in S2-060517
|
6
|
S2-060517
|
LS OUT
|
Reply LS on PS and CS coordination in shared RAN for MOCN
|
SA WG2
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
SA WG2 thanks RAN WG3 for their LS regarding PS and CS coordination in shared RAN for MOCN. SA WG2 has decided to update TS23.251 so that the CN node indicates to the RNC when the re-routing procedure is used for coordination purposes. The approved CR is attached (S2-060449). SA WG2 believes that the stage 2 description of PS and CS coordination is now finalized on this point.
|
Approved
|
6, 7
|
S2-060180
|
DISCUSSION
|
Cell ID/Type information transfer to HPLMN
|
Vodafone
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
This document is a continuation of the saga previously recorded in S2-052667 (attached). Since the SA WG2 meeting in Yokosuka, the requirements for this feature have been discussed on the SA WG1 email list. After a few rounds of email, the debate hassubsided. Presumably, the current email version of the CR to 21.101 (see second attachment) is likely to be the outcome of the next SA WG1 meeting. Therefore, SA WG2 can use it as the basis for the production of the stage 2 CRs for these Rel-6 features. Rapid conclusion on the stage 2 aspects will avoid further delay in the conclusion of the stage 3 work by CT and RAN groups (and, if necessary, SA WG5). It is proposed to agree to develop this "user plane" mechanism in preference to the previously raised control plane solutions. A CR to 23.060 has been drafted in S2-060181. Appropriate LSs may need to be sent to SA WG1, CT WG4, RAN WG3, etc.
|
Noted
|
6, 7
|
S2-060181
|
[CR]
|
Proposed CR0544 to 23.060: Cell ID/Type information transfer to HPLMN (Rel-6)
|
Vodafone
|
23.060
|
0544
|
-
|
F
|
6.11.0
|
Rel-6
|
TEI6
|
Summary of change: Following a cell change the RNC/2G-SGSN adds information on the Cell Identity and the Type of Cell to the next few GTP-U uplink packets. To facilitate this, the DRNC provides this information to the SRNC. To provide additional network control (eg of processing load), the HLR can signal whether or not to use this feature on a per-subscriber basis. This signalling can be copied onto the Iu interface to influence the RNC's behaviour. As implementation options, both SGSN and/or RNC can ignore this signalling.
|
Noted
|
6, 7
|
S2-060182
|
WITHDRAWN
|
|
Vodafone
|
-
|
-
|
-
|
-
|
-
|
-
|
-
|
Thoughts on load balancing with Iu/A/Gb flex
|
|
|
