6 Received Liaison Statements
C3-110012
Reply LS to 3GPP TSG CT4 on support of ECN Source: Q3/16Abstract:
Q3/16 thanks 3GPP TSG CT4 for its liaison on ECN (explicit congestion notification) (our TD 330/Gen, yours C4-103381). Q3/16 has noted that 3GPP TS26.114 is based on the IETF work in this area. We do note however that the features described in 3GPP TS26.114 are based on an early private IETF draft (draft westerlund avt-ecn-for-rtp-02) whereas the latest IETF working group supported draft is draft-ietf-avt-ecn-for-rtp-03. We recommend for compatibility that 3GPP TS26.114 be modified to take into account the latest work. For example: 3GPP TS26.114 specifies the use of
"nonce" however this is removed in the current IETF draft. Specification 3GPP TS26.114 also does not appear to consider the relationship with RTCP reporting introduced in later drafts.
Q3/16 has analysed (draft-ietf-avt-ecn-for-rtp-03) and sees the general use of ECN functionality in various IP based networks, not only in 3GPP specified networks.
As such Q3/16 has started a work item: H.248.ECN "Explicit Congestion Notification Support". This item will consider the support of ECN in MGs and the interaction with the various RTP/RTCP configurations. The scope of H.248.ECN covers RTP/UDP but would not be limited to that particular bearer type. Likewise it will also focus on supporting any media format which may benefit from ECN indication not just the "AMR" family of codecs. Also in addition to describing the use of ECN related SDP in H.248, Q3/16 sees the need for the definition of statistics for logging purposes and procedures for handling ECN failure and re-negotiation. These functions appear not to be considered by 3GPP TS 26.114.
As per previous work: e.g. H.248.77 "SRTP package and procedures", H.248.72 "H.248 support for MONA", we look forward to receiving your input so that we can provide a solution that may be used by your various H.248 profiles.
Discussion:
Use the latest version of the IETF draft. It is necessary that we have any input requirements to their H.248 ECN work.
Related discussion paper: tdoc 123.
Decision: The document was noted .
C3-110013
Reply LS to R2-105299 on Handling of UTRAN Mobility Information Source: RAN WG2Abstract:
RAN2 thanks SA2 for the LS on Handling of UTRAN Mobility Information (S2-104449/R2-105299) in the context of CSFB and PS handover, and would like to provide the following responses to the questions raised by SA2.
Question 1: Will the RNC during PS handover always (regardless whether the LAI is changed or not) deliver the LAI as part of the UTRAN Mobility Information to the UE?
Answer: Detailed RNC behaviour is not specified, but RAN2 assumes the indicated behaviour can be expected.
Question 2: Will the RNCs always provide the UTRAN Mobility Information to the UE as soon as possible?
Answer: As indicated above, detailed RNC behaviour is not specified, but RAN2 assumes the indicated behaviour can be expected. From a RAN2 point of view, “as soon as possible” should be as soon as the security operations on the Uu interface are completed, i.e. UTRAN receives the Security Mode Complete from the UE.
Question 3: SA2 would also like to ask whether the RNC would be able to handle and forward to CN a NAS message sent by the UE before the UE receiving the UTRAN Mobility Information.
Answer: After a (PS) handover to UTRAN, and integrity protection has been activated, RAN2 assumes an RNC should be able to handle and forward a NAS message to the appropriate CN domain, but (again) this is up to RNC
implementation.
Question 4: In such a case, would sending the NAS message immediately without waiting for the UTRAN Mobility Information be faster than if the UE would wait for the UTRAN Mobility Information?
Answer:
On the network side, sending UMI message after sending the RLC ACK for the Security Mode Complete can take as little as 100 ms, depending on RNC implementation.
Given the above, whether it will be faster to send a NAS message in uplink or to wait for the UMI message can depend on other factors, e.g. the LAI match or mismatch, that are hard to predict and outside the scope of RAN2 expertise.
Discussion:
No impact on CT3 identified.
Decision: The document was noted .
C3-110014
LS response on Passing Restart Counter to External Network Source: 3GPP TSG SA2Abstract:
SA2 thanks CT4 for the LS (C4-101562) on Passing Restart Counter to External Network.
With respect to CT4 request to consider the proposed optimization for removing Gx diameter sessions when the SGSN or A-GW restarts as part of the Study on Policy Solutions and Enhancements. SA2 understands that stage 2
requirements for restoration is under CT4 responsibility, so SA2 would assume that CT4 takes care of the stage 2 work for the functionality described.
SA2 does not foresee any need for undertaking any SA2 activity under the study on Policy Solutions and Enhancements.
Discussion:
Cc: CT3
Decision: The document was noted .
C3-110015
LS on NIMTC impacts on PMIP Source: SA2Abstract:
As defined in TS23.401, the indicator(s) defined within the NIMTC Work Item is sent to P-GW to apply P-GW control of overload function upon PDN connectivity establishment.
When P-GW control of overload function is applied, P-GW may reject the PDN connectivity request message with an indication of congestion with a back-off timer.
For PMIP based EPC, SA2 agreed that the indicator, congestion indication and back-off timer are exchanged over on-path signalling i.e. PMIP is used rather than Gxc/Gx interfaces.
Discussion:
Mr.Weihua represented this LS. No impact on CT3?
Decision: The document was noted .
C3-110016
LS on User CSG Information reporting Source: SA2Abstract:
SA2 thanks CT3 for the LS on User CSG Information reporting.
How to subscribe to User CSG Information changes
The current description in 23.203 defines 3 credit reauthorization triggers over Gy in clause A.1.3.1.3 for GPRS access and in the corresponding clauses for both EPC based and PMIP access and 3 CSG Information reporting triggers over Gx in clause A.1.3.4 for GPRS access and in the corresponding clauses for EPC both GTP and PMIP access that directly correspond to the events of the UE entering/leaving/accessing a CSG cell, the UE entering/leaving/accessing a hybrid cell in which the subscriber is a CSG member or the UE entering/leaving/accessing a hybrid call in which the subscribed is not a CSG member. Separate triggers are defined in order to enable control over what User CSG information are needed so that unnecessary signalling in the network can be avoided and only the needed User CSG information are reported to the OCS and to the OFCS.
How to request the access network to report to the User CSG Information changes
The current description in 23.203 defines that for GPRS and EPC based GTP accesses in clauses A.1.3.4 and A.4.3.4 the GGSN/PDN GW sets the MS Info Change Reporting Action IE based on the information provided by the OCS and the PCRF For EPC based PMIP access the S-GW sets the MS Info Change Reporting Action IE based on the event triggers received from the PCRF as stated in Annex A.5.3.1.3.
Answer #1, item 1: For PMIP, the PCEF subscribes to the event triggers to the BBERF via PCRF based on the information received from both PCEF and OCS and the BBERF will use the event triggers to indicate the access network the required User CSG Reporting,
Answer #1, item 2: For GTP, the PCEF requests the access network to report on User CSG Information Change based on both the information received by the PCRF and the OCS. If different values are provided, the PCEF aggregates the information provided by the PCRF and the OCS.
Answer #2: SA2 confirms that both the OCS and the PCRF can request different User CSG information change reporting levels separately:
• For online charging the OCS subscribes to the credit reauthorization triggers for User CSG reporting changes to the PCEF.
• For offline charging the PCRF provisions the User CSG reporting triggers to the PCEF.
Discussion:
Miss. Susanna represented this LS. Mr.Weihua has a question regarding the relations of PCRF,OCS, and PCEF and Miss.Susanna answered for this. Mr.Zhou joined the discussion and all agreeds. (Related CRs in tdocs 20 & 21) Decision: The document was noted .