Provisional allocation of documents to agenda items


Actions To RAN 2, RAN 3



Yüklə 2,97 Mb.
səhifə14/36
tarix07.01.2022
ölçüsü2,97 Mb.
#91507
1   ...   10   11   12   13   14   15   16   17   ...   36
Actions

To RAN 2, RAN 3:

SA 2 kindly asks RAN 2 and RAN 3 to consider the above issues and to:

- inform SA 2 and CT 1 as to how the RNC can handle PS domain CN node congestion in the above 3 situations; and

- indicate any preference on how any inter-TSG specification dependencies are documented.



To CT 1:

SA 2 kindly asks CT 1 to note the above questions and to be ready to assist RAN 2 and RAN 3.










C1-111648

Reply LS on CN node selection (S2-111207)

SA2

CC

Noted
RAN2 in previous LS ask SA2 "if it is already possible in UMTS to differentiate between the native and mapped without an explicit indication; and whether the reasons to introduce explicit UE AS indication for LTE were also relevant for UMTS". In this SA2 answer SA2 does not think a new indication is needed in UMTS.

============= extract from LS ===========

The IE "Intra Domain NAS Node Selector" (IDNNS) is used by the RNC to route UE signalling to the Core Network node (SGSN). In TS 25.331 clauses 8.1.8 and 10.3.1.6 it is specified that the routing parameter in IE IDNNS consist of bit 14 to 23 of the P-TMSI. Bit 14 to 23 in the P-TMSI is also defined as the Network Resource Identifier (NRI). The NRI uniquely identifies an individual CN node (e.g. SGSN) within a pool.
TS 23.003 specifies the mapping from E-UTRAN to UTRAN/GERAN i.e. the MMEC is mapped into the NRI value . The same or different values of NRI and MME code may be used for a combined node and RAN configuration will allow the NAS messages to be routed to the combined node.
The RNC is configured with NRI values and on AS level from UE to RNC there is only sent an IDNNS (NRI) parameter. Under the SA2 understanding, the IDNNS (NRI) IE is considered sufficient for the RNC NAS node selection function. With that if NRIs are reused among neighbour pools, no detection of pool area changes is possible. But this limitation is present today and not seen as a problem. For load balancing purposes, MSs changing a pool-area could be detected by configuration of different NRI values for adjacent pool-areas.

=====================================










C1-111649

Reply LS on Bearer Control Mode and multiple PDN connectivity (S2-111237)

SA2

CC

Noted
========= extract from LS ============

SA2 discussed scenarios where multiple PDN connections to the same APN over the same IP-CAN Type exist and agreed that for 3GPP2 accesses the BCM should be the same for all the PDN connections to the same APN.


However SA2 thinks that the flexibility of having different BCM values for different PDN connections to the same APN over the same IP-CAN Type should be kept for 3GPP accesses.
Therefore SA2 decided that the same BCM shall be used for all PDN connections to the same APN when the UE supports 3GPP and 3GPP2 accesses. If the UE supports both 3GPP and 3GPP2 accesses, it shall indicate the same BCM capability within all PDN connection requests targeted to the same APN. In this case it is expected that PCRF will select the same BCM for all PDN connections to the same APN.








C1-111650

LS on SGs paging with IMSI for CSFB (S2-111245)

SA2

To

Reply LS in C1-111965

Related papers in C1-111750


SA2 has discussed the case of SGs paging with IMSI for CSFB (CS MT Call). Although not specified in 23.272 it is implied that the UE would used IMSI as the UE identity in Page Response or LAU on the CSFB target RAT as specified in TS 24.008 clause 10.5.1.4. When UE uses IMSI as UE identity it is not possible for the target GERAN or UTRAN to select the correct MSC in a pooled deployment. This is an Access Stratum issue, but unlike a UTRAN RNS which uses an AS layer identity, a GERAN BSS uses NAS layer identity for the CN node selection.
SA2 has discussed a proposal where the UE use the TMSI in page response and LAU on the target RAT at CSFB even if it was paged for CS services with IMSI on E-UTRAN (see ftp://ftp.3gpp.org/tsg_sa/WG2_Arch/TSGS2_83_Salt_Lake_City/Docs/S2-110576). The use of TMSI as the UE identity on the target RAT will make it possible for both GERAN and UTRAN to identify the correct MSC in a pool and hence avoid missed MT calls or MTRR/MTRF inside an MSC pool. It was however commented that this could be a significant change in the UE behaviour and also was commented that the case is an error case.
SA2 would like CT1 feedback on the solution to use TMSI as UE identity in the target RAT for CSFB even if the UE has been paged with IMSI.


Yüklə 2,97 Mb.

Dostları ilə paylaş:
1   ...   10   11   12   13   14   15   16   17   ...   36




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin