3GPP TSG-CT WG4 Meeting #72	C4-161004

Jeju, South Korea; 15th to 19th February 2016.

Source:	Chairman, TSG-CT WG4

Title:	Proposed Allocation of Documents to Agenda Items for CT4 #72: Status on Eve of Meeting

Agenda item:	2

Document for:	INFORMATION

Saved 08/02/2016 10:15 CET

Document available, not yet treated

Document available late, not yet treated

Document not available

Document treated

Document available later

NOTE 1: Hyperlinks assume that this document is extracted and stored in a directory and all documents are in a subdirectory "docs" of this directory.

NOTE 2: Late arrived Contributions will be handled only, if time allows and any company has the right to ask for postponing the document to the next meeting. The detailed agenda and time plan on eve of meeting, and the proposed allocation of documents to agenda items, are treated as being received on time even though they are available only at the start of the meeting (the chairman does have some privileges)

NOTE 3: If a document which was received late (after the deadline) is a revision of a document which was received before the deadline, it is treated as being received on time.

Agenda	Agenda Title	Tdoc C4-15#	Tdoc Title	Source	Result	Notes
1	Opening of the Meeting and Approval of the Agenda
2	Allocation of Documents to Agenda Items
1000	agenda Agenda	CT4 Chairman
1001	agenda Detailed agenda & time plan for CT4#72: status at document deadline	CT4 Chairman
1002	agenda Detailed agenda & time plan for CT4#71: status on eve of meeting	CT4 Chairman
1003	agenda Proposed allocation of documents to agenda items for CT4#71: status at document deadline	CT4 Chairman	This document
1004	agenda Proposed allocation of documents to agenda items for CT4#68bis: status on eve of meeting	CT4 Chairman
3	Meeting Reports
1005	report CT4 previous meeting report for approval	MCC
1006	report CT/SA #70 Status report	FSCOM
4	Input Liaison Statements
1017	LS in Rel-13 LS on NBIFOM procedure in SCM and RAN rules handling parameter	C1	Postponed to 7.2.6	WI NBIFOM-CT To: SA2 CC: CT3, CT4 Contact: ZTE According to the description in subclause 6.2.3.1 of TS 23.161, default access can be transported between the UE and the network via EAP procedures when adding addition of trusted WLAN using SCM. This implies that 3GPP AAA server should be able to convey the default access between UE and TWAG. However, if the 3GPP AAA server does not support NBIFOM, the 3GPP AAA server may drop the default access receiving from the UE and the TWAN. Q1: Based above, if the 3GPP AAA server does not support NBIFOM, how do the UE and the network achieve to determine the default access? In addition, TS 23.161 specifies that network may provide RAN rules handling parameter to the UE when network-initiated mode is selected. However, it is not clear what procedures are used to provide this RAN rules handling parameter to the UE. Q2: In what procedures will the network provide the RAN rules handling parameter to the UE? Proposed Treatment: CT4 can Note.
1018	LS in Reply LS on Disconnection of NBIFOM PDN Connection with the Cause "Reactivation Requested"	C1	Postponed to 7.2.6	WI PCSCF_RES_WLAN To: CT4 Contact: ALU CT1 reviewed the possible behaviours of a UE supporting NBIFOM if it receives a request to release a PDN connection with the cause "reactivation requested" over the 3GPP or the WLAN access, or a Detach request with the cause "reattach required" over the 3GPP access. CT1 confirms the CT4 analysis that if a UE supporting NBIFOM receives such a request over one access the UE shall initiate the release of the related PDN connection(s) over the other access. Further study is still needed for the Detach request case. CT1 agreed the attached pCR “Handling of the Reactivation Requested cause when NBIFOM” to TS 24.cde (C1-154843). Proposed Treatment: CT4 to necessary resultant action.
1019	LS in Rel-13 Reply LS on Mapping table between GTPv2 S2a and WLCPDiameter	C1	Postponed to 8.3.1	To: CT4 Contact: Huawei CT1 thanks the LS from CT4 about the definition of mapping table between GTP and WLCP/Diameter. CT1 has reviewed the CT4 CRs, and decided to introduce the reject causes "user authentication failed" and "PDN connection does not exist" to CT1's TS 24.244 WLCP (MCM, from TWAN to the UE) and TS 24.302 for EAP message (SCM, from 3GPP AAA Server to the UE). CT1 would like CT4 to note that these agreed CRs are only from Rel13. (see attached). Proposed Treatment: CT4 to necessary resultant action. GTP/WLCP CRs produced by Huawei in 8.3.1
1020	LS in Rel-13 LS on issues related to MT SMS over SGs delivery in eDRX	C1	Postponed to 7.2.10	WI eDRX-CT To: SA2 CC: CT4 Contact: Huawei CT1 has observed some issues for the mobile terminated SMS in eDRX procedure described in TS 23.272 subclause 8.2.4a (the procedure shown in Figure 8.2.4a-1). The more critical issues are described below: a. Every MT SMS delivery for UEs in eDRX will cause systematically 5 pairs of messages at the HSS (i.e. the step 3, 8, 12, 13 and another step 3 during step 14 in the Figure 8.2.4a-1). Prior to the introduction of eDRX, steps 3, 8, 12, 13 and 14 are only triggered when the UE is not reachable, which should remain normally a rather rare case (for UEs with an always-on connectivity). With eDRX, MT SMS may cause substantial additional signalling to the HSS. b. There is no synchronisation between the SC and the MME about the time period during which the MME maintains the signalling connection with the UE. So there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained (e.g. SMS-GMSC overload) CT1 would like SA2 to provide the feedback on above issues for MT SMS over SGs in eDRX. Proposed Treatment: CT4 can Note.
1021	LS in Rel-13 LS on MCPTT Group data and affiliation	C1	Postponed to 7.2.11	WI MCPTT-CT To: SA6 CC: CT4 Contact: Ericsson From 3GPP TS 23.179 v13.0.0, it indicates that affiliation status is a part of the MCPTT group information stored in the group management server and that the affiliation status is set solely by the MCPTT server handling the (de)affiliation requests. Some companies believe that affiliation status of an MCPTT group is changed more often than other parameters of the MCPTT group. Other companies believe that this is subjective in the cases where the XCAP document data is persistent for 30-minutes or more. CT1 asks SA6 to clarify why the MCPTT server handling the (de)affiliation requests stores the affiliation status in the group management server. Proposed Treatment: CT4 can Note.
1022	LS in Rel-13 LS on questions on CIoT	C1	Postponed to 7.2.14	WI CIoT-CT To: SA2, RAN2, RAN1 CC: CT4 Contact: Huawei CT1 have started work on CIoT and would like to ask the following questions: (1) To SA2: Have CT1 to provide support for UEs which can have the UE-SCEF connection running in parallel with PDN connection such as Internet, IMS etc. Further information: A use case has been brought to the CT1 attention which describes that the UE can have multiple PDN connections simultaneously in addition to CIoT functionality running (e.g., control plane IoT towards the SCEF via the MME and simultaneous PDN connections towards the P-GW such as Internet and IMS). (2) To SA2: Will the UE-SCEF connection be only utilized for non-IP transmission? Further information: CT1 find not clear whether the UE-SCEF connection can be used for non-IP or also IP data. (3) To SA2: With regards to the Solution 18; can data be sent over the user plane when the UE have multiple PDN connections? (4) To SA2: Is inter-RAT mobility to/from NB-IoT supported? If so, will the data be sent by the UE over control plane in an NB-IOT cell needs to be mapped to the EPS bearers established in E-UTRA? Further information: CT1 would need to know this for the case the UE has established bearers in E-UTRA and moves to NB-IOT. (5) To SA2: Has the CIoT IP data transport to be mapped to an existing EPS bearer context? Further information: Some companies in CT1 indicate that for the case of IP data transport, mapping to an existing EPS bearer context could allow the sending of the IP data between the CN nodes over a bearer. However, this requires that the EPS bearer identity is included in the NAS message together with the encapsulated IP data to be sent. Is this aligned with SA2 understanding? (6) To SA2: Is the indication on immediate acknowledgement/response data to the corresponding CIoT data really needed for all cases of CIoT data or not? Further information: CT1 notice that the technically endorsed SA2 CR in S2-154451 states, quote: The UE can also indicate a Release Assistance Information in the NAS message about whether Downlink data transmission (e.g. Acknowledgements or responses to UL data) subsequent to the Uplink Data transmission is expected or not. Considering the case of SMS, currently the acknowledgement of received SMS is always required, and hence CT1 would like to know whether this is applied to the CIoT SMS too. For the case of CIoT non-IP and IP data, CT1 asks why the immediate acknowledgement/response data is actually required. Furthermore, CT1 notice that SA2 does only describe such indication for the UL direction, and therefore would like to know whether the same requirement applies to the DL direction too. (7) To SA2: Can you clarify the way the S1 connection release indication works? Further information: CT1 notice that SA2 has described in the technically endorsed CR in S2-154451, quote: The UE may also indicate whether the S1 connection has to be released when DL data is received From stage 3 perspective (TS 24.301), the release of the S1 connection is controlled by the network and not based on indication from the UE. Furthermore, the network can refer the acknowledgement/response indication provided by the UE in order to decide the release of the S1 connection (if the UE expects ack data, the network will not release the S1 connection immediately after the receipt of uplink CIoT data). (8) To SA2: If the S1 connection release indication is used with uplink data, then the MME can anyhow perform S1 release procedure after the end of downlink data transmission. If this occurs; should the UE proceed with it even if the UE wants to keep the S1 connection in order to send uplink data later? Further information: The following scenario has been brought up: 1. The UE provides the S1 connection release indication with uplink data. 2. The MME forwards the received data and downlink data is transmitted towards the UE. Note that the downlink data is not acked. 3. The MME performs S1 release procedure after the end of the downlink data transmission. Note that the MME cannot know whether downlink data is acked or not. 4. The UE has received all downlink data which is not acked but the UE shall proceed with the S1 release procedure. (9) To SA2: Is the CIoT data type (non-IP or IP) required to be included in the NAS message together with the encapsulated CIoT data? Further information: CT1 notice that this is not explicitly described by the technically endorsed SA2 CR in S2-154451. However, CT1 do notice that this is part of the TR 23.720 for UL data to enable the transportation of the CIoT data to the P-GW or SCEF. Hence, CT1 would like to confirm with SA2 this aspect, and if the answer is YES, then CT1 will need to know whether this applies to the DL data too. (10) To SA2: Can it always be ensured that the ATTACH REQUEST message for CIoT optimizations reaches an MME which supports CIoT optimizations? (11) To SA2: If a legacy MME can receive the ATTACH REQUEST message for CIoT optimizations, what’s the expected UE and network behaviour upon receipt of the message considering the following two scenarios? a) The ATTACH REQUEST message arrives without one or more mandatory IE(s). b) The ATTACH REQUEST message arrives with all expected mandatory IEs. (12) To SA2: Is header compression required for IP data, or is some form of header compression also required for non-IP data? (13) To SA2: Are CIoT optimizations applicable to combined attached UE for both EPS and non-EPS services? (14) To SA2: Is SDU segmentation/reassembly required for CIoT? If so, is there a distinction between data over control plane and data over user plane? Further information: A company has suggested that SDU segmentation/reassembly is introduced and that the RAN/UE should prioritise transmission of signalling packets ahead of queued data PDUs. These proposals would have major impacts to NAS from what it’s defined today. (15) To RAN1: If SDU segmentation/reassembly is required for CIoT, what’s the minimum data rate on the uplink and on the downlink at the extreme "+20dB" coverage scenario? Further information: A company has suggested that SDU segmentation/reassembly is introduced and that the RAN/UE should prioritise transmission of signalling packets ahead of queued data PDUs. Hence, in order to determine NAS signalling timer values and the SDU size used by the "data via MME", CT1 might need to know the minimum data rate. (16) To: RAN2: Is (or will be) NB-IoT designed to guarantee in-sequence-delivery of packets? Further information: The CT1 NAS security protocol discards out-of-sequence packets as in E-UTRA the RLC ensures in-order delivery of SDUs. Does NB-IOT also provide in-order delivery of SDUs? If this not provided major impacts to NAS security protocol are envisioned. (17) To SA2: Is there is any requirement to handle the “data via MME” and the NAS signalling message PDUs with different priorities? Further information: For instance, providing a higher priority to handle the NAS signalling message PDU, at the eNodeB and the lower layer in the UE. Proposed Treatment: CT4 can Note.
1023	LS in Reply LS on OCS address for Gy and Gyn inter-PLMN	C3	WI TEI13, iPLMN-PS-OCH To: SA5 CC: CT4, SA2 Contact: ALU CT3 thanks SA5 for their reply liaison (S5-154304/C3-154156) and the LS on OCS address for Gyn inter-PLMN (S5-155252/C3-155076) on the OCS address for Gy/Gyn inter-PLMN. CT3 would like to inform SA5 that the functionality is agreed for the Gx and the Sd procedures by TS 29.212 CR 1397 attached to this LS. Proposed Treatment: CT4 can Note.
1024	LS in Rel-13 LS on the decision of NBIFOM mode	C3	Postponed to 7.2.6	WI NBIFOM-CT To: SA2 CC: CT1, CT4 Contact: Huawei CT3 is working on the definition of NBIFOM mode on Gx interface and has some questions about the following definition in TS 23.161: 5.4.4 Mode Selection When an NBIFOM-capable UE supports ANDSF and has an ISRP rule valid in the registered PLMN then: - If the ISRP rule includes at least one "ISRP for IFOM" rule (irrespectively of its validity), the UE requests UE-initiated mode and the network selects UE-initiated mode. - Otherwise, the UE requests Network-initiated mode and the network selects Network-initiated mode. When an NBIFOM-capable UE does not support ANDSF or supports ANDSF but does not have an ISRP rule valid in the registered PLMN then: - The UE requests Network-initiated mode and the network selects Network-initiated mode. Q1: Based on the above SA2 definition, is it the intention to prevent the network from changing the NBIFOM mode requested by the UE side? Q2: If the answer to “Q1” is “YES”, then could you explain the reasons for such limitation? In CT3’s point of view, the PCRF shall decide which NBIFOM mode applies to the IP-CAN session. One reason is to fix the incorrect NBIFOM mode requested by the UE, because the UE is untrusted and the request may be wrong because of accidental or intentional mistake implemented in the UE side. Another reason is, in roaming case, when the UE receives the valid V-ISRP rule including at least one “"ISRP for IFOM" from the V-ANDSF Server, then based on the SA2 definition, the UE requests UE-initated mode. However, if the HPLMN has not deployed the ANDSF Server and wants all the UE to perform the NBIFOM according to the routing rule received from H-PCRF, then it’s better for the H-PCRF to decide the NBIFOM mode, e.g. changing the NBIFOM mode from UE-initated mode to Network-initiated mode. Proposed Treatment: CT4 can Note.
1025	LS in Rel-13 LS on Request for Diameter Command Code and Application ID for new St Interface	C3	WI FMSS-CT To: CT4 Contact: Nokia CT3 has agreed CRs against TS 29.212 that add the Diameter protocol for the St interface. The St application is defined as a vendor specific Diameter application, where the vendor is 3GPP. A new Application ID shall be used. The Application-ID for the St Application needs to be requested from IANA by the CT4 MCC. CT3 asks CT4 and their MCC to kindly request a new Diameter Application ID for the Diameter St application from IANA. Proposed Treatment: CT4 to comply with CT3's request. Kimmo has requested an Application-ID and drafted a CR.
1026	LS in Rel-13 Reply LS on the Setting of Delay Tolerant Connection Indication	C3	WI eDRX-CT To: CT4 CC: SA2 Contact: Ericsson CT3 thanks CT4 for their LS on the setting of Delay Tolerant Connection Indication (DTCI) during a PDN connection creation procedure. CT4 has informed CT3 that CT4 had agreed to the following: The DTCI is set by the PGW/GGSN according to the local policies in the PGW/GGSN e.g. on per APN basis. CT3 has discussed this and has come to the conclusion that there is no impact to PCC interfaces. CT3 asks CT4 to take the above information into account and update the corresponding WID accordingly. Proposed Treatment: CT4 to update the WID. Postponed to 7.2.10 or leave as updated WID may be in 5?
1027	LS in Rel-13 Reply LS on Multi-stream Multiparty Conferencing Media Handling	C3	WI MMCMH To: SA4 CC: CT1, CT4, CT Contact: Nokia CT3 thanks SA4 for their LS providing the draft CR (S4-151542 CR 26.114-0355 rev 2) on "Introduction of Multistream Multiparty Conference Media Handling (Release 13)" for review. SA4 asked CT3 to review that CR and assess the related impacts on CT3´s specifications. CT3 expects sufficient impacts to CT groups to require a dedicated work item. In CT3, the following impacts are anticipated: • The PCC subsystem would likely need to be aware of multiparty conferencing and reserve reduced resources • There are also impacts to H.248 profiles: For instance, new RTCP feedback types for pause and resume needs to be passed by TrGW and AGW. In addition, CT3 would like to provide the following comment to the CR: In Clause S.5.1 the following is stated: "An exception to the previous rule is when the SDP answer containing such rejected "m="-lines would exceed an SDP send size limit, in which case the remaining "m="-lines in the received SDP may be omitted from the SDP answer." CT3 believes that such a deviation from the RFC 3264 SDP offer-answer rules would likely not be tolerated by network entities in the core network (e.g. an IBCF or an P-CSCF) and may thus lead to failed call establishments. The SDP to PCC service information mapping in TS 29.213 as currently specified would also fail. CT3 thus recommends removing this procedure. Proposed Treatment: CT4 can Note.
1028	LS in NG PACKET LS to Standardization groups on PMIP removal	GSMA PA	Postponed from last meeting To: SA2, CT4 Contact: Orange GSMA Networks Group would like to inform all standardization groups working on LTE and EPS Roaming that decision has been taken to not support any more PMIP protocol over S8 interface for current and future International Roaming services, as only the GTP protocol is used for this interface. GMSA NG will then remove all references of PMIP in all its PRDs starting with IR.88 and invite all groups to take this information into consideration for further standardization works. Proposed Treatment: CT4 to take Note and implement. Postponed from our last meeting. CT4 will need to further investigate which CT4 specs are affected to bring CRs. Also to see how SA2 will handle this and from which Release this is removed.
1029	LS in Rel-13 LS on extension to field length of PDCP Sequence Number	R2	Postponed to 7.3.11	WI LTE_CA_enh_b5C-Core To: RAN3, CT4 CC: SA3 Contact: Nokia RAN2 would like to inform RAN3, CT4 and SA3 that RAN2 has taken as a baseline to extend the field length of PDCP SN [TS 36.323] for AM DRB for both UL and DL to 23 bits in Rel-13, in addition to the previous maximum value of 15 bits (which is per DRB configurable). The FMS field in PDCP STATUS PDU is also extended to 23 bits and the size of BITMAP is increased accordingly. In the related discussion this was recognized to have impact also to RAN3 and CT4 specifications. RAN2 respectfully asks RAN3 and CT4 groups to update their Rel-13 specifications to accommodate the longer PDCP SN length. Proposed Treatment: See C4-161030 postponed from our last meeting. CT4 to take action on this increased length.
1030	LS in Rel-13 LS on extension to field length of PDCP Sequence Number	R2	Postponed to 7.3.11	WI LTE_CA_enh_b5C-Core Postponed from Last Meeting. WI LTE_CA_enh_b5C-Core To: RAN3, CT4 Cc: SA3 Contact: Nokia RAN2 would like to inform RAN3, CT4 and SA3 that RAN2 has taken as a baseline to extend the field length of PDCP SN [TS 36.323] for AM DRB for both UL and DL to 23 bits in Rel-13, in addition to the previous maximum value of 15 bits (which is per DRB configurable). The FMS field in PDCP STATUS PDU is also extended to 23 bits and the size of BITMAP is increased accordingly. In the related discussion this was recognized to have impact also to RAN3 and CT4 specifications. 2. Actions: To RAN3 and CT4 groups. ACTION: RAN2 respectfully asks RAN3 and CT4 groups to update their Rel-13 specifications to accommodate the longer PDCP SN length. Proposed Action: Postponed from our last meeting where we agreed to wait for the agreed CR in RAN2 before we update CT4 specifications accordingly from Rel-13. Concerns were raised about the backwards compatibility and the extensibility of these changes. Requested to update CT4 specifications accordingly from Rel-13. Postponed until we get more info from RAN2. See RAN2's LS in C4-161029.
1031	LS in Rel-10 Reply LS on 3GPP Work on Explicit Congestion Notification for Lower Layer Protocols	R2	WI ECSRA_LAA To: SA CC: CT, RAN, SA2, SA4, CT1, CT3, CT4 Contact: Samsung RAN2 thanks SA for the LS on 3GPP Work on Explicit Congestion Notification for Lower Layer Protocols (R2-154021/SP-150574). RAN2 could be affected by the work on ECN for lower layer protocols. Among RAN2 specifications, ECN is used in section 11. 6 of TS 36.300 for codec rate control. At this moment, RAN2 has no particular comments on draft-ietf-tsvwg-ecn-encap-guidelines-04. If RAN2 comes up with any comments in the future meeting, RAN2 will send them to SA. Proposed Treatment: CT4 can Note.
1032	LS in Rel-13 Response LS on Conclusions from TR 23.712 on Warning Status Reporting	R3	Postponed to 7.2.4	WI WSR_EPS To: CT1, CT4 Contact: ALU RAN3 has agreed at RAN3#90 the attached CRs to TS 36.300 and TS 36.413 which introduce the new PWS Failure Indication procedure for ongoing PWS operation. Proposed Treatment: CT4 to take the necessary resultant action.
1033	LS in Rel-13 LS on S1 signalling solutions for non-NB-IoT UEs	RP	Postponed to 7.2.14	WI NB_IOT-Core To: SA2, SA3, SA, CT1, CT3, CT4, RAN2, RAN3 CC: RAN1 Contact: Ericsson RAN discussed applicability of S1 signalling enhancements for non-NB-IoT UEs, i.e., Solution 2 and Solution 18 as discussed in SA2. RAN made following agreements how to proceed with this: • Signalling design for solution 2 and solution 18 for NB-IoT UEs is done in NB-IoT session. Additional changes due to support for other UEs will be done in TEI13 session. However, additional optimizations for non-NB-IoT UEs will not be discussed. • We will have – CRs for NB-IoT UEs (including e.g. L1 parameters, signalling enhancements and other enhancements) – and a separate CR of additional impact due to non-NB-IoT UEs (e.g. capabilities). • RAN2 and RAN3 have to allocate TEI13 time for the support of non-NB-IoT UEs. • Will inform CT1/SA2 by LS and they can apply same approach. • This approach is applied both for Sol2 and Sol18 unless there are significant impacts on specifications identified. RAN would like to inform SA2 that is has not discussed or understood the impacts of the issues raised in Sections 3.3 - 3.6 in RP-151991. Proposed Treatment: CT4 can Note.
1034	LS in Rel-13 Reply LS on clarification on requirements for AESE	S2	Postponed to 7.2.8	WI AESE-CT To: CT4 Contact: ALU In your LS you indicate: I) Overwriting of CP parameter set(s) In TS 23.682 sub-clause 5.10.2 the NOTE2 talks about overwriting of CP sets. The NOTE2 mentions the same SCS/AS or another SCS/AS, but not what happens if it is the same or different SCEFs. CT4's understanding is: A) Overwriting is allowed when the request is from the same SCEF and the CP parameter provisioning procedure shall be treated as a configuration update procedure. If there is a clash in one part of the CP set in a request with stored CP parameter, the overwriting is for the whole CP parameter set assigned to the SCEF reference ID. This means the CP parameter sets belonging to the old SCEF reference ID are cancelled and the new SCEF reference ID are stored. This has to be done in the HSS and in the MME. However currently stage 2 doesn’t define an update (or) delete procedure for the CP parameter sets. Question 1: Does SA2 agree with this understanding and intend to introduce a CP parameter update procedure? SA2 Response: At SA2#111, CR0142rev3 for TS 23.682 was approved (see S2-153692 attached). In that CR, changes were made that: a) Require that in Rel-13 only a single SCEF shall be permitted by the HSS to configure CP parameter sets for a given UE; b) Place the responsibility on the SCEF to assure that there are no overlapping CP parameter sets, while allowing the configuration of multiple CP parameter sets for the same UE. Two examples are given in the CR to help with understanding. c) Clause 5.10.2 of TS 23.682 now supports configuration, modification, and deletion of CP parameter sets. d) Validity time is defined as indicating the expiration time of a CP parameter set. B) If the request comes from a different SCEF than the SCEF which has send the CP parameter sets earlier, this is an error case which SA2 assumes will be handled by stage 3. Question 2: Does SA2 agree with this? SA2 Response: As noted in the answer to Question 1, it is mandatory in Rel-13 that only a single SCEF shall be permitted by the HSS to configure CP parameter sets for a given UE. SA2 expects that stage 3 will handle error cases, including the case of a request to configure CP parameter sets by a second SCEF for a given subscription. II) 3GPP TS 23.682 sub-clause 5.10 mentions the parameter "validity time" in the procedure description and a "Scheduled communication time" in the Table 5.10.1-1. CT4's understanding is that the description of "validity time" by SA2 implies the Scheduled Communication Time. CT4 also felt that a separate time called "period of validity" will be required to indicate how long the CP parameter set is valid (define an expiration time for the CP parameter set). Question 3: CT4 kindly asks SA2 to clarify if CT4's understanding of the "validity time" description in TS 23.682 is correct and if yes, whether adding an additional "period of validity" is applicable. SA2 Response: As noted in the answer to Question 1 item d), “validity time" is defined as indicating the expiration time of a CP parameter set. III) For MONTE we have the possibility to delete events. CT4 felt it would be beneficial to add a delete mechanism for the CP parameter set as well using the SCEF Reference ID as the key similar as for MONTE (SCEF Reference ID for deletion). Question 4: CT4 kindly asks SA2 to consider the above. SA2 Response: As noted in the answer to Question 1 item c), clause 5.10.2 of TS 23.682 now supports configuration, modification, and deletion of CP parameter sets. Proposed Action: CT4 to take note of SA2's answers and take action accordingly.
1035	LS in Rel-13 Reply LS on clarification on requirements for MONTE	S2	Postponed to 7.1.9	WI MONTE-CT To: CT4 Contact: ALU In your LS there are two questions: Question 1: If reporting is stopped due to roaming into an MME/SGSN which does not support the active monitoring event, should the HSS Inform the SCEF about the stop of Monitoring and continuation when the UE roams back into an MME/SGSN which supports the active events. SA2 have agreed the CR in S2-154378 (attached) that will cause the SCEF to be notified when the monitoring event cannot be supported. The monitoring event can be deleted or suspended. Please see the details in the approved CR. Question 2: Should there be a subscription parameter per monitoring event for each subscriber at the HSS, especially considering for events like location information, subscriber’s consent is required to expose towards 3rd party application in order to protect privacy? The text in step 4 of clause 5.6.1.1 of TS 23.682 is: 4. The HSS examines the Monitoring Request message, e.g. with regard to the existence of External Identifier or MSIDSN, whether any included parameters are in the range acceptable for the operator or whether the monitoring event that shall be deleted is valid. The HSS optionally authorizes the chargeable party identified by Chargeable Party Identifier. If this check fails the HSS follows step 8 and provides a Cause value indicating the reason for the failure condition to the SCEF. Since the HSS is required to examine the Monitoring Request message, it is reasonable to assume that the HSS may want (e.g., based on operator policy) to allow a particular monitoring event for one subscription and not allow it for another subscription. This would require information per monitoring event per subscription in the HSS for monitoring events the operator supports. In the particular case of location information, the SCEF must provide a level of filtering, per subscriber’s consent and operator policy, in the case of multiple reports that come to it directly from the MME/SGSN. Therefore, having the SCEF also provide at least that same level of filtering for a report that comes via the HSS is reasonable. It is not intended that the HSS maintain per subscription information on what types of location reporting are allowed, only whether location reporting is allowed or not. In regard to point A in your LS, SA2 agrees with CT4. In regard to points B and C in your LS, SA2 thanks CT4 in advance for keeping us informed. In regard to point D in your LS, SA2 notes that TS 23.682 CR 0134 has been agreed (S2-153063) which deletes “Presence Area reporting level” from clause 4.5.6.1, Note 1. SA2 anticipates further work on PRA reporting via the AULC work ongoing in SA2 for Rel-14. The Update Location procedure in TS 23.401 needs to be updated to allow the old MME/SGSN to send the latest continuous Monitoring Event reporting status to the HSS. The exact mechanism of the indication of non-support for requested Monitoring Event(s) between MME/SGSN and HSS is left to Stage 3. Proposed Treament: CT4 to take note of SA2's answers and take appropriate action.
1036	LS in Rel-13 LS on Network asserted WLAN Location Information for PDN connection establishment over S2b	S2	Postponed to 7.2.9	WI SEW1-CT To: CT4 CC: CT3 Contact: ALU SA2 thanks CT4 for their LS on Network asserted WLAN Location Information for PDN connection establishment over S2b. SA2 have discussed the issue and, as proposed by CT4, concluded that it is valuable that, when available, User Location Information is transferred by the ePDG to the PGW for emergency and non-emergency PDN connections. This indeed allows a generic behaviour, as providing location information over S2b is useful also for non-emergency PDN connections. The User Location Information shall include UE local IP address and optionally UDP source port number (if NAT is detected). It may also include WLAN Location Information (and its Age) the ePDG may have received from the 3GPP AAA server about the UE. The WLAN Location information is provided to the ePDG when the 3GPP AAA server considers that location information coming from the WLAN AN used by the UE is trustable. Proposed Treatment: CT4 to take SA2's answers into account as per their attached CRs.
1037	LS in Rel-13 LS on Mobile Equipment Identity Signalling over WLAN	S2	WI MEI_WLAN To: CT4 CC: CT1, SA3, SA3-LI, SA5 Contact: ALU SA2 thanks CT4 for their LS on “Mobile Equipment Identity Signalling over WLAN”. Based on this LS, SA2 has agreed to the attached CR(s). IMEI checking (e.g. disallow WLAN access for stolen equipment) will be specified as part of the EWE WID that is also attached. SA2 kindly asks CT4, SA3, SA3-LI and SA5 groups to take note of these evolutions and to update their respective specifications, if necessary. Proposed Treatment: CT4 to take the necessary action. See SA2's WID. CT WID update required for Rel-13? Postponed to 7.1.10 or leave as updated WID may be in 5?
1038	LS in Rel-13 LS on Retrieval of UE Usage Type from HSS	S2	Postponed to 7.1.18	WI DECOR-CT To: CT4 Contact: ALU SA2 thanks CT4 for their LS on retrieval of UE Usage Type from HSS. SA2 has evaluated and agreed to the proposal from CT4. Therefore, SA2 has agreed to the attached CR to TS 23.401. SA2 informs CT4 that there is no need for a CR to TS 23.060 because DCN feature related clause for UTRAN/GERAN only contains a pointer to clause 4.3.25.1 of TS 23.401 where DCN feature is specified. Proposed Treatment: CT4 to take the necessary action.
1039	LS in Rel-13 Reply LS on proposed extension to GUSS to include AS address	S2	To: CT1 CC: CT4, SA3 Contact: Ericsson SA2 has further discussed the first topic in the LS and would like to provide the following feedback: [Question#1 from CT1] When an AP receives an HTTP request from a user, and there are several AS instances providing the service requested in the received HTTP request, does stage-2 include any requirements on per-user configuration for AP's routing of the received HTTP request to one of those AS instances? [Feedback from SA2] There are no specific requirements in stage-2 that address any AP configuration related to per-user routing of received HTTP requests to a specific AS instance. Proposed Treatment: CT4 can Note LS. GUSS decision in CT1 has an impact on CT4 pending CRs.
1040	LS in Rel-13 LS on Packet switched conversational multimedia applications TS 26.235 and TS 26.236	S4	WI IMS-CODEC Postponed from last meeting WI IMS-CODEC To: CT3, CT4, RAN5, RAN2 CC: SA Contact: Ericsson 3GPP TS 26.235 Packet switched conversational multimedia applications; Default codecs and 3GPP TS 26.236 Packet switched conversational multimedia applications; Transport protocols are both under SA4 responsibility. Those 2 TSs haven’t been updated since Rel-7 and SA4 considers them as being superseded by 3GPP TS 26.114 IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction, when it comes to specifying default codecs and media transport for multimedia conversational applications. SA4 therefore agreed to no longer maintain 3GPP TS 26.235 and 3GPP TS 26.236. The intention is that Rel-13 and subsequent releases of these specifications will not be created. The attached Tdoc lists the identified 3GPP TSs making use of these 2 TSs as references. The tool used for this quick search is “DocFetcher” (http://sourceforge.net/projects/docfetcher/) and no guarantee is provided that this search is exhaustive. SA4 kindly requests WG responsible to now take action in order to remove any references from their TSs in Rel-13 and potentially replace them to reference TS 26.114. SA4 intends to agree CRs on its own affected TSs at SA4#87. Action has also been taken by SA4 delegates to check OMA and GSMA specifications. 2. Actions: To 3GPP TSG CT WG3, 3GPP TSG CT WG4, 3GPP TSG RAN WG5, 3GPP TSG RAN WG2 ACTION: Remove any references to TS 26.235 and TS 26.236 from the Rel-13 specifications under your responsibility. If needed, consider replacing those references by TS 26.114. Proposed Treatment: CT4 to remove references and replace if necessary. CT4 CRs are required to 23.333, 29.232, 29.332, 29.333 are affected. Postponed from last meeting to remind us that CRs are required.
1041	LS in Rel-10 Reply LS on 3GPP Work on Explicit Congestion Notification for Lower Layer Protocols	SP	WI ECSRA_LAA To: IETF tsvwg Cc: CT, RAN, SA2, SA4, RAN2, RAN3, CT1, CT3, CT4 Contact: Samsung IETF tsvwg requested information from 3GPP. 1) to tell the IETF tsvwg which 3GPP working groups could be affected by this work. The working groups that could be affected by ongoing work on ECN include SA2, SA4, RAN2, CT1, CT3, and CT4. 2) To inform the IETF tsvwg of any specific 3GPP specifications affected by this work. The following Technical Specifications either include a normative citation or normative text relying up RFC 3168. Working Group Technical Specification 3GPP TSG SA WG2 23.060, 23.228, 23.401 3GPP TSG SA WG4 26.114, 26.223, 26.247 3GPP TSG CT WG1 24.229 3GPP TSG CT WG3 29.162, 29.163, 29.213, 29.292 3GPP TSG CT WG4 23.333, 29.333 (Iq stage 2 and stage 3), 23.334, 29.334 (Mp stage 2 and stage 3), 29.238 (Ix stage 3), 29.332 (Mn stage 3), 29.232 (Mc stage 3) 3GPP TSG RAN WG2 36.300 3GPP TSG RAN WG3 25.401 26.114, 29.162, 29.232, 29.238, 29.332, 29.333, 29.334 contain normative text concerning the use of ECN in the 3GPP system. All of the listed specifications contain references to other specifications concerning ECN support. 3) to forward this liaison statement to these affected working groups, and to invite them to review the latest draft of the guidelines, available here: < http://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines> The usage of adding ECN to 3GPP protocols encapsulating or based on IP has not been studied by 3GPP Working Groups. Therefore, no specific review comments on the IETF tsvwg documents are provided at this time. References to IETF RFC 3168, RFC 6679 (and related ECN specifications) were added to 3GPP specifications from Release 10 onwards. Furthermore, numerous 3GPP specifications refer and employ TCP, UDP and other IP-based protocols. Therefore, TSG SA requests IETF to kindly keep TSG SA informed of any changes to ECN functionality (e.g. per IETF RFC 3168, RFC 6679 etc), along with changes to various IP-based protocols such as TCP as a result of the ECN work of IETF tsvwg. SA requests that if RAN2, RAN3, SA2, SA4, CT1, CT3 and CT4 have further comments to IETF tsvwg documents that these comments be sent also to SA, along with the WGs listed in CC, for the purposes of coordinating the discussion. Proposed Treatment: Any further comments from CT4? ECSRA_LAA-CN is 10.7 in Rel-10.
1042	LS in Rel-13 Reply LS on questions on CIoT	R2	Postponed to 7.2.14	WI CIoT-CT To: CT1 CC SA2, RAN1, CT4 Contact: Huawei RAN2 thanks CT1 for the LS and would like to provide feedback on Q16: (16) To: RAN2: Is (or will be) NB-IoT designed to guarantee in-sequence-delivery of packets? RAN2: Yes, NB-IoT design guarantees in-sequence-delivery of packets as for LTE. In addition RAN2 has discussed the per-UE configuration to allow exception reporting and would like to ask CT1 if it is possible to support this by NAS. Proposed Treatment: CT4 can Note.
1219	LS in TAC Allocation as detailed in 3GPP TS 23.003	TS	To: CT4, ETSI Contact: Paul Gosden Within 3GPP TS 23.003 section 6.1, it states “The Type Allocation Code (TAC) is issued by a central body” however it does not say who the central body is or how it can be contacted. TSG respectfully asks that the following be added to 3GPP TS 23.003 section 6.1 to provide greater clarity “The Type Allocation Code (TAC) is issued by the GSM Association in its capacity as the Global Decimal Administrator. Further information can be found in the GSMA TS.06 IMEI Allocation and Approval Process” Should it be considered appropriate, the GSMA is agreeable to the following information also be included in 3GPP TS 23.003 section 6.1 “The IMEI database can be contacted via the following email address imeihelpdesk@gsma.com Access to the IMEI Databased can be requested at https://imeidb.gsma.com/imei/login.jsp. TS.06 IMEI Allocation and Approval Process is available on the GSMA Website: http://www.gsma.com/newsroom/gsmadocuments/” This will help manufacturers with obtaining TAC/IMEI for their own devices and help other stakeholders by clearing up any confusion about where TAC/IMEI are obtained from. A reply to this LS is requested by the 29th February 2016 which will be in time for discussion at the TSG#23 meeting on 16th and 17th March 2016 in Bangkok. Proposed Treatment: CT4 to consider adding this information to 23.003 and create a CR. A reply LS is needed.
1220	LS in Rel-14 Reply LS to CT4 LS on progress of the work on Diameter Base Protocol Update	S5	Postponed to 7.1.19	WI FS_DBPU To: CT4 CC: CT3, SA3 Contact: ALU SA5 thanks CT4 for their LS on progress of the work on Diameter Base Protocol Update (S5-161193/C4-152375) provided with the version of TR 29.819 feasibility Study on the Diameter Base Protocol Update, as basis for their CT4#72 next February meeting. During SA5#105, SA5 has reviewed the TR, and identified some updates were needed, based on their analysis on a set of differences between IETF RFC 3588 and IETF RFC 6733. As result SA5 endorsed the two pCRs attached, to be incorporated in the TR 29.819. SA5 kindly asks CT4 to incorporate in the TR 29.819, the two attached pCRs endorsed by SA5. Proposed Treatment: CT4 to consider SA5's request with their two pCRs.
1221	LS in Rel-13 LS on Charging Id assignment for NBIFOM	S5	Postponed to 7.2.6	WI NBIFOM-CH To: SA2 CC: CT3, CT4 Contact: Ericsson SA5 has determined that the current requirement to assign a unique charging identifier to each bearer as originally specified in TS 23.060, TS 23.401, and TS 23.402 shall be maintained. However, the original convention that the charging identifier for the default bearer be used as a "PDN connection charging id" is no longer sufficient. With the introduction of NBIFOM comes the possibility of a multi-access PDN connection with two default bearers. For correlation purposes, a single PDN connection charging id is still required. SA5 has determined when NBIFOM is supported for a PDN connection, an explicit charging identifier shall be assigned independent of the default bearer charging id to be the single PDN connection charging id for correlation purposes. As a result, the serving node can no longer rely on the convention that uses the charging id of the default bearer for this purpose and a new mechanism is required to convey the assigned PDN connection charging id to the serving node. 1. SA5 asks SA2 to define a mechanism to convey the assigned PDN connection charging id for a PDN connection to the serving node (S-GW, ePDG, and TWAG). SA5 has also determined that the bearer level charging identifiers and the PDN connection charging id described above shall be maintained when a serving node is changed, e.g. when UE moves PDN connection between LTE and WLAN or when serving gateway relocation is performed. As described above, with NBIFOM a situation can occur in which the PDN connection charging id has a value that differs from the default bearer charging id. 2. SA5 asks SA2 to define a mechanism to convey the assigned PDN connection charging id for a PDN connection to a serving node when the serving node is changed. For this purpose, serving node can be an S-GW, ePDG, or TWAG. SA5 has also studied the Access Charging Correlation procedures, as originally defined in TS 23.203, and determined that when NBIFOM is supported for a PDN connection that the PGW shall use the single PDN connection charging identifier for all flows as introduced in Release 12 when charging per IP-CAN session is active in the PGW. 3. SA5 asks SA2 to ensure that the current mechanism for access charging correlation in which the PDN connection charging id is used for all flows applies also when NBIFOM is supported for a PDN connection. Proposed Treatment: CT4 can Note.
1222	LS in Rel-13 LS on Addition of AVP code definitions	S5	Postponed to 7.3.2.	WI CH13, CHeISC, ANIMO, eSaMOG-CH, MONTE-CH To: CT4 Contact: ALU SA5 would like to inform CT4 about the following AVPs defined for Rel-13 charging features in TS 32.299, for incorporation into TS 29.230: <List> SA5 has implemented these AVPs using the range allocated to TS 32.299 by CT4, per CR 0459r1 (C4-151047) to TS 29.230 agreed during CT4#69, as requested in LS S5-153240/C4-151007. SA5 also asks CT4 for a new range of AVP codes allocated to TS 32.299 for Rel-14. Proposed Treatment: CT4 to comply with SA5's request and provide 29.230 CRs.
1223	LS in Rel-13 LS on EVS over CS	S4	Postponed to 7.1.7	WI EVSoCS To: RAN1, RAN2, CT1, CT3, CT4 CC: RAN3, SA Contact: Qualcomm SA4 would like to inform RAN1, RAN2, CT1, CT3 and CT4 that SA4 has agreed on the following new specifications and CR for Release 13: • S4-160298 CR TS 26.103, Introduction of EVS in the speech codec list for UMTS (Release 13) • S4-160200 TS 26.453 v.1.0.0, Codec for Enhanced Voice Services (EVS); Speech codec frame structure (Release 13) • S4-160232 TS 26.454 v.1.0.0, Codec for Enhanced Voice Services (EVS); Interface to Iu, Uu, Nb and Mb (Release 13) SA4 came to the conclusion that the interworking on user plane for all the interfaces (Iu, Nb, Mb) are very similar and should be preferably described in detail in one document, TS 26.454. SA4 recognized that the Mb user plane is described at certain level in TS 29.163. Therefore, SA4 asks for guidance from CT3 whether it would be appropriate that CT3 makes an additional reference in TS 29.163 to TS 26.454 and SA4 includes the details on Mb interface in TS 26.454. SA4 discussed the possible content of Section 10 to TS 26.454 (Mb User Plane) in S4-160199 (attached) and left it for further study in TS 26.454. Please take note that SA4 has decided to optimize the transport of the Silence Descriptor (SID) for EVS AMR-WB IO (40 bits instead of 56 bits), see S4-160298. SA4 kindly asks RAN1 to consider designing a new TFC for this transport on Uu. Proposed Treatment: CT4 can Note.
1224	LS in Rel-13 Reply LS on Multi-stream Multiparty Conferencing Media Handling	S4	WI MMCMH To: CT3, CT1 CC: CT4, CT Contact: Ericsson SA4 acknowledge that the procedure defined in the CR to 26.114 for the handling of too large SDPs is unsuitable. SA4 have studied this further and concluded that this issue is already handled by other 3GPP specifications, e.g. TS 24.229. SA4 have therefore decided to remove the procedure from TS 26.114 without replacement, see attached CR. SA4 would like to know if any minimum requirements have been defined for the SIP/SDP messages size that the clients need to support. Proposed Treatment: CT4 can Note.
1225	LS in Rel-13 LS on Completion of QOSE2EMTSI work item	S4	Postponed to 7.2.3	WI QOSE2EMTSI-CT To: CT3 CC: CT1, CT4 Contact: Ericsson SA4 would like to inform CT1, CT3 and CT4 that the QOSE2EMTSI work item for Release 13 has now been completed. During the discussions in SA4 it was identified that the updates to the SDP definition may impact the PCC rules defined by CT3, see attached CR. SA4 would therefore like CT3 to take these updates into account in their work. Proposed Treatment: CT4 can Note.
1226	LS in Reply LS to CT4 on RTCP Handling for FECC	S4	To: CT4 Contact: Intel SA4 has reviewed CT4’s questions with regards to RTCP handling for the Far End Camera Control (FECC) protocol and would like to provide the following clarification. SA4 believes that for FECC RTCP for the H.224/H.281 IP flow is not necessary; this is neither described in the ITU-T specifications for H.224/H.281 nor in TS 26.114. Thus, SA4 believes that there would be no need to reserve any RTCP resources in media gateways for the FECC 224/H.281 IP flow. (This is unlike RTP video IP flow, for which RTCP is used and resources need to be reserved.) Proposed Treatment: CT4 can Note.
1227	LS in Rel-13 LS on guidance by SA2 on CIOT	S2	Postponed to 7.2.14	WI CIoT-CT To: CT4 Contact: ALU In relationship to a document received during SA2#113 (S2-160484) describing a list of questions by CT4 originated during the 1st CT4 Telco on CIoT that was held on Monday 18th January, SA2 would like to provide the following guidance 1. Is there a need/requirement to support separate control for WLAN Offloadability for WB-E-UTRAN vs. NB-IoT? S2-154394 cover page requests separate control for WLAN mobility, but this is not further documented in the CR body. SA2 response: It is not expected in rel-13 that the NB-IoT cell sends any RAN assistance data. Hence this parameter is not relevant to the UE when using NB-IoT. Separate HSS/MME parameters for WB-E-UTRA and NB-IoT are not needed for WLAN Offloadability. The update of that CR no longer mentions the topic. . 2. Selection of PGW supporting Non-IP data: assuming a user subscription is configured for a given APN with the Non-IP PDN type, can it be assumed that all PGWs returned by DNS for that APN will support Non-IP data (i.e. that there is no need for new DNS mechanisms to determine whether a particular PGW supports Non-IP or not)? SA2 response: It is SA2 understanding that there shall be support of Non-IP data in SGW/PGWs that are associated to an APN the UE or MME select to use Non-IP data. 3. Selection of an SGW/PGW supporting the NB-IoT RAT: is it permitted to select an SGW/PGW not supporting the NB-IoT RAT, for a UE accessing NB-IOT, if there is no candidate SGW/PGWs supporting NB-IoT? Does SA2 assume that some SGWs and PGWs are dedicated to certain RAT, e.g. NB-IoT only? SA2 response: yes it is permitted to select a SGW/PGW that does not understand “RAT type = NB-IoT”, however, there may well be cases where the SGW/PGW implementation is optimised (e.g. with low cost but high latency PDN context retrieval mechanisms) to support NB-IoT (or Low Complexity eMTC) devices. It is expected that the APN and/or UE Usage Type can be configured to cause the selection of such optimised GateWays 4. PGW pause of charging: with buffering of DL data in MME, SGW cannot trigger PGW pause of charging upon drop of DL packets or radio link loss (since the SGW is not aware of DL packets being dropped at the MME and since the MME does not send Release Access Bearers if it maintains the S11-U tunnel even when the UE is in idle mode). Should the MME trigger start/stop PGW charging over S11, and if so, how? a. e.g. by extending the PGW charging on/off flags on S11 or b. e.g. by the MME sending Release Access Bearer Request with the indication “Abnormal Release of Radio Link” to pause the charging (i.e. tearing down the S11-U tunnel); a subsequent MBR would implicit tell the SGW to unpause PGW charging (i.e. w/o S11-C protocol changes) SA2 response: SA2 will discuss these questions in February. 5. Can SA2 confirm that a given APN subscription will either be configured with Non-IP PDN type or an IP PDN type, never both. SA2 response: yes. The same APN shall not be provisioned in the HSS for both IP and non-IP PDN types. 6. Handover to a different MME (WB-E-UTRAN UEs with a PDN cnx) : what does happen if the target MME does not support SMS w/o combined EPS Attach ? Does the source MME need to know whether a candidate target MME supports SMS w/o combined EPS Attach ? SA2 response: SA2 wish to avoid this complexity and have modified their CRs so that the “SMS w/o combined EPS Attach” feature is only available to devices that only support NB-IoT and do not support WB-E-UTRA. Proposed Treatment: CT4 to take into account SA2's answers.
1228	LS in Rel-13 Response to LS on questions on CIoT	S2	Postponed to 7.2.14	WI CIoT-CT To: CT1, RAN2, RAN3 CC: CT4, RAN1, SA3 Contact: Vodafone SA2 answers 16 questions from CT1. Proposed Treatment: CT4 to take Note of SA2's answers.
1229	LS in Rel-13 Reply LS on NBIFOM procedure in SCM and RAN rules handling parameter	S2	Postponed to 7.2.6	WI NBIFOM-CT To: CT1 CC: CT3, CT4 Contact: Huawei Regarding the following questions asked by CT1: Q1: Based above, if the 3GPP AAA server does not support NBIFOM, how do the UE and the network achieve to determine the default access? Answer 1: SA2 agreed to transfer the default access indication via 3GPP access in case of SCM. Q2: In what procedures will the network provide the RAN rules handling parameter to the UE? Answer 2: SA2 agreed that the network provides the RAN rules handling parameter to the UE during the PDN connection establishment via 3GPP. For more details please see the attached CR S2-160575. Proposed Treatment: CT4 can Note.
1230	LS in Rel-13 LS on the Revocation of Discovery Filters	S2	Postponed to 7.2.7	WI ProSe-CT To: CT4 CC: CT1 Contact: TelecomItalia First of all SA2 wants to clarify that the Revocation of Discovery Filters procedure in section 5.3.6A.2.2 has been defined to revoke the authorization to use certain discovery filters as soon as possible after the user has changed the discovery permissions. SA2 answers to CT4 comments to the Revocation of Discovery Filters procedure are as follows: CT4 comment: However, the consequence of the notification of a partial/complete failure in the revocation process is not described: nothing is said on the possible actions that would be performed by the ProSe functions or the ProSe Application Server. As currently described, it seems that the notification phase in the steps 10 and 11 is mainly for information. CT4 has therefore questioned whether the notification phase in the revocation procedure was really required. SA2 Answer: If the ProSe Application Server is notified in step 12 about the failure of the revocation process then it may issue a new revocation request to the HPLMN ProSe Function and/or it may warn the user across the PC1 reference point. Those steps are not explicitly described in the Revocation of Discovery Filters procedure because they depend on the implementation of the ProSe Application Server, that is out of the scope of 3GPP: nevertheless a reliable information shall be conveyed to the ProSe Application Server to enable those steps. CT4 comment: After the step 7, the ProSe Function in the HPLMN has the confirmation that the update request has been successfully processed by the ProSe Function in the other PLMN. At this stage, the ProSe Function in the other PLMN can initiate the revocation of the discovery filters towards the impacted UEs. If the first attempt fails, the ProSe function may re-attempt the revocation. SA2 Answer: After step 7 the ProSe Function in the HPLMN only knows that the update request has been successfully received by the ProSe Function in the other PLMN but doesn’t know anything about the result of the revocation process. CT4 comment: If the revocation is unsuccessful, it seems that it is not so critical from a service point of view as the changes in the discovery permissions will be anyway effective after the expiration of the validity timer associated to the corresponding ProSe Restricted Code. SA2 Answer: Waiting for the expiry of the validity timer is not acceptable because it could be set by the operator to a very long value (e.g., one day) in order to minimize the signalling load over the PC3 reference point. Moreover, if the user cannot be sure that the revocation of the discovery permissions will be effective when he requests it, and not some hours or days after then we do not see the gain to have a revocation procedure at all. CT4 comment: If any discovery must be prohibited after the revocation request, the sets of Banned RPAUID - Banned PDUID could be also stored by the ProSe Function in the HPLMN until the expiration of the validity timer associated to the corresponding ProSe Restricted Code. In such a case, the HPLMN ProSe Function would be able to reject the unauthorized restricted discovery requests. SA2 Answer: The point is not just to prohibit any discovery after the revocation request but also, and more important, to inhibit the use of the already allocated discovery filters without the need to wait for the expiry of the associated validity timers, therefore the proposed alternative solves only part of the problem. For the above reasons SA2 believes that the notification phase described in the steps 10/11 cannot be removed from the Revocation of Discovery Filters. Proposed Treatment: CT4 to take Note of SA2's answers.
1231	LS in Rel-13 LS on issues related to MT SMS over SGs delivery in eDRX	S2	Postponed to 7.2.10	WI eDRX-CT To: CT1 CC: CT4 Contact: Qualcomm SA2 have discussed these issues and finds the issues in the LS and would like to provide the following feedback: a. Every MT SMS delivery for UEs in eDRX will cause systematically 5 pairs of messages at the HSS (i.e. the step 3, 8, 12, 13 and another step 3 during step 14 in the Figure 8.2.4a-1). Prior to the introduction of eDRX, steps 3, 8, 12, 13 and 14 are only triggered when the UE is not reachable, which should remain normally a rather rare case (for UEs with an always-on connectivity). With eDRX, MT SMS may cause substantial additional signalling to the HSS. SA2 feedback: 1. It should be possible for eDRX feature to be deployed without requiring changes to legacy SMS infrastructure. Therefore, the handling of MT SMS as currently defined in TS 23.272 should be allowed. 2. On the other hand, SA2 recognizes that the procedure for MT SMS as currently defined in TS 23.272 does require signalling. A large frequency of MT SMS would create substantial additional signalling to the HSS. 3. SA2 has not discussed any solution for MT SMS optimizations to reduce signalling towards the HSS, and welcomes CT1 to further study this issue, if necessary, taking the above into account. b. There is no synchronisation between the SC and the MME about the time period during which the MME maintains the signalling connection with the UE. So there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained (e.g. SMS-GMSC overload) SA2 feedback: • SA2 agrees there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained. Proposed Treatment: CT4 to take Note of SA2's answers to CT1.
1267	LS in Rel-13 Reply LS on CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points	C1	Postponed to 7.2.11	WI MCPTT-CT To: CT4 CC: SA3, SA6 Contact: Samsung The LS lists a number of assumptions and some open questions. With regard to the questions, CT1 believes that these questions should be answered by SA6 as they do not pertain to protocol-related aspects. With regards to the assumptions in the LS that CT4 discussed in the joint meeting in Nashville, CT1 would like to re-confirm these assumptions. Proposed Treatment: CT4 can note.
1268	LS in Rel-13 LS Response on User Databases interfaces for MCPTT	3GPP TSG SA WG6	Postponed to 7.2.11	WI MCPTT-CT To: CT4 Contact: Nokia SA6 thanks CT4 for sending the LS on User Databases interfaces for MCPTT, focusing on interfaces AAA-1 and MCPTT-2. SA6 discussed the questions contained in the LS and reached conclusion that some answers were already provided during conference calls or will be addressed within the reply LS on “CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points” (C4-160019 / S6-160008). Proposed Treatment: CT4 can Note.
1269	LS in Rel-13 LS Response on CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points	3GPP TSG SA WG6	Postponed to 7.2.11	WI MCPTT-CT To: CT4 CC: CT1, SA3 Contact: Samsung Regarding a set of working assumptions identified by CT4, SA6 would like to inform CT1 as follows: A/ Regarding the IMS Registration procedure Assumption 1: It is assumed that IMS identities (IMS private identity and IMS public identity) are used during SIP registration in the same way as it is done in a normal IMS registration. SA6 Answer : Yes, SA6 confirms this assumption Assumption 2: How the UE retrieves the identities to use in the registration and how the relation between IMS identities and MCPTT identities is done will be clarified by SA3. SA6 Answer : SA6 confirms that SA3 will clarify how the UE retrieves the identities to use in the registration. The relation between IMS identities and MCPTT identities are defined in TS 23.179 (see clause 8). Assumption 3: It is assumed that the IMS private identity and/or the IMS public identity will contain the name of the domain in which is located the HSS/SIP database serving the called MCPTT user. This information is required by the I-CSCF/Registrar finder and the S-CSCF/Registrar to address the HSS/SIP user database located in an external network. SA6 Answer : Yes, SA6 confirms this assumption Assumption 4: It is assumed that the registration authorization given by the HSS/SIP database to the I-CSCF/ Registrar finder does not depend on the fact that the registration authorization is requested for MCPTT or not. It is a normal IMS registration authorization request procedure i.e. there is no specific information to add in the authorization request sent to the HSS/SIP database and in the response received by the I-CSCF/Registrar finder. SA6 Answer : Yes, SA6 confirms this assumption Assumption 5: It is assumed that the service profile retrieved from the HSS/SIP user database during the registration of an IMS public identity contains filter criteria which may trigger multiple application servers e.g. the MCPTT server and one SIP AS for MMTEL. SA6 Answer : Yes, SA6 confirms this assumption B/ Regarding SIP call establishment Assumption 6: It is assumed that call requests between MCPTT servers in case of private/group calls across multiple MCPTT systems are routed using either: - a Public Service Identity (PSI) mapping the called MCPTT ID/MCPTT group ID in the MCPTT Server. This PSI identifies the MCPTT server serving the called MCPTT user/MCPTT group; or - an IMPU mapping the called MCPTT ID in the MCPTT server. This IMPU identifies the called user. The IMPU/PSI is used by the I-CSCF/Registrar finder to retrieve from the HSS/SIP database the required information to forward the call request to the MCPTT server serving the called MCPTT user/MCPTT group. SA6 Answer : Yes, SA6 confirms this assumption C/ MCPTT user database and related reference points Assumption 7: It is assumed that the MCPTT user profile contains only MCPTT user configuration data defined in the Annex B.3 in the TS 23.179. SA6 Answer : Yes, SA6 confirms this assumption. Please take note that the title of Annex B.3 is renamed as MCPTT user profile data. Assumption 8: It is assumed that the data access by CSC-13 is only the MCPTT user profile. SA6 Answer : Yes, SA6 confirms this assumption Assumption 9: It is assumed that the data access by MCPTT-2 is only the MCPTT user profile and this profile is the same than the one managed by the configuration management server over the CSC-13 reference point. SA6 Answer : Yes, SA6 confirms this assumption Assumption 10: It is assumed that the MCPTT server does not update the MCPTT user profile in the MCPTT user database. SA6 Answer : SA6 believes that it should be possible for MCPTT server to update the MCPTT user profile. However, no procedures currently exist in TS 23.179, and SA6 does not intend to define any procedures in Rel-13. Assumption 11: It is assumed that the MCPTT user database is provisioned with the MCPTT user profiles (i.e. the MCPTT ID and the associated MCPTT user profile(s). SA6 Answer : Yes, SA6 confirms this assumption Assumption 12: It is assumed that the MCPTT ID is the primary key to access any data in the MCPTT user profile. SA6 Answer : Yes, SA6 confirms this assumption Assumption 13: It is assumed that IMS identities are not used as keys to access data. SA6 Answer : Yes, SA6 confirms this assumption Assumption 14: It is assumed that the MCPTT user database does neither apply any logic based on data stored nor manipulate the MCPTT user profile in any way, i.e. it does not have any knowledge about stored data. SA6 Answer : Yes, SA6 confirms this assumption Assumption 15: It is assumed that MCPTT user profile(s) data format is XML. SA6 Answer : It is responsibility of CT1 to define MCPTT user profile(s) data format. Assumption 16: It is assumed that one single MCPTT server is in charge of the MCPTT ID at a given time. SA6 Answer : Yes, SA6 confirms this assumption Assumption 17: It is assumed that CSC-13 and MCPTT-2 are intra-domain interfaces. SA6 Answer : Yes, SA6 confirms this assumption Regarding open questions asked by CT4, SA6 would like to inform CT1 as follows: D/ Open questions Question 1: Is it required to define a specific format for the MCPTT ID beyond TS 23.179 requirements (i.e. MCPTT ID is defined as a URI)? SA6 Answer : No from SA6 perspective. Question 2: Is it required to define a specific format for the PSI? SA6 Answer : No from SA6 perspective. Question 3: Is there any other data than the MCPTT user profile to convey over the MCPTT-2 reference point? SA6 Answer : No. Question 4: If multiple MCPTT user profiles are defined per MCPTT ID, is there any need for MCPTT user profile id as a secondary access key? SA6 Answer : SA6 could not reach a conclusion on whether or not a secondary access key is needed over CSC-13 and MCPTT-2. Question 5: Is it required to allow configuration management servers to create/upload in the MCPTT user database additional profiles to an existing MCPTT ID? SA6 Answer : Yes. Proposed Treatment: CT4 to take SA6's answers into account.
5	WIDs
1043	discussion Rel-14 Multi-stream Multiparty Conferencing Media Handling	Ericsson
1044	WID new Rel-14 CT aspects of MTSI Extension on Multi-stream Multiparty Conferencing Media Handling	Ericsson
1055	WID new SCC AS Restoration	China Mobile
1205	SID new Rel-14 New study item on PCRF failure and restoration enhancement	China Mobile Com. Corporation
1250	WID revised Rel-13 Revised WID on Controlling IMS Media Plane with SDP Capability Negotiation	Huawei	Revision of CP-150238
6	Release 14
1178	CR 0515 29.230 Rel-14 AVP code range reservation for 32.299	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI14 CAT F
1201	CR 1681 29.274 Rel-14 Adding eNB change reporting in Location Change Reporting	China Mobile Com. Corporation, ZTE, Allot Communications, China Unicom	Revision of C4-152135 WI TEI14 CAT B
7	Release 13
7.1	CT4 Led WIs
7.1.1	Support of RTP Transport Multiplexing (signalling) in IMS	RTCP-MUX
7.1.2	CT aspects of voice over E-UTRAN Paging Policy Differentiation	voE-UTRAN_PPD-CT
7.1.3	P-CSCF restoration enhancements with WLAN	PCSCF_RES_WLAN
1133	CR 1687 29.274 Rel-13 P-CSCF_RESELECTION_SUPPORT Private Status Type	ZTE/Joy	WI PCSCF_RES_WLAN CAT F
1179	CR 0083 23.380 Rel-13 P-CSCF restoration not prioritized for WLAN	Nokia Networks	WI PCSCF_RES_WLAN CAT F
1180	CR 0084 23.380 Rel-13 Result-Codes for P-CSCF Restoration	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Bell	WI PCSCF_RES_WLAN CAT F
1190	CR 0085 23.380 Rel-13 Indication of P-CSCF restoration extension support over IKEv2	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI PCSCF_RES_WLAN CAT F
1204	CR 0452 29.273 Rel-13 Result-Codes for P-CSCF Restoration	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI ePCSCF_WLAN CAT F
7.1.4	Diameter Load Control Mechanisms	FS_DLoCME
7.1.5	Study on EPC Signalling Improvement for Race Scenarios	FS_EPC_SIG_RACE
7.1.6	Shared Data Update for Multiple Subscribers	SHARED_SubData_UPD
7.1.7	CT aspects of EVS in 3G Circuit-Switched Networks	EVSoCS-CT
1223	LS in Rel-13 LS on EVS over CS	S4	WI EVSoCS To: RAN1, RAN2, CT1, CT3, CT4 CC: RAN3, SA Contact: Qualcomm SA4 would like to inform RAN1, RAN2, CT1, CT3 and CT4 that SA4 has agreed on the following new specifications and CR for Release 13: • S4-160298 CR TS 26.103, Introduction of EVS in the speech codec list for UMTS (Release 13) • S4-160200 TS 26.453 v.1.0.0, Codec for Enhanced Voice Services (EVS); Speech codec frame structure (Release 13) • S4-160232 TS 26.454 v.1.0.0, Codec for Enhanced Voice Services (EVS); Interface to Iu, Uu, Nb and Mb (Release 13) SA4 came to the conclusion that the interworking on user plane for all the interfaces (Iu, Nb, Mb) are very similar and should be preferably described in detail in one document, TS 26.454. SA4 recognized that the Mb user plane is described at certain level in TS 29.163. Therefore, SA4 asks for guidance from CT3 whether it would be appropriate that CT3 makes an additional reference in TS 29.163 to TS 26.454 and SA4 includes the details on Mb interface in TS 26.454. SA4 discussed the possible content of Section 10 to TS 26.454 (Mb User Plane) in S4-160199 (attached) and left it for further study in TS 26.454. Please take note that SA4 has decided to optimize the transport of the Silence Descriptor (SID) for EVS AMR-WB IO (40 bits instead of 56 bits), see S4-160298. SA4 kindly asks RAN1 to consider designing a new TFC for this transport on Uu. Proposed Treatment: CT4 can Note. Postponed to 7.1.7
1058	CR 0131 23.153 Rel-13 Resolution of Editor’s notes on EVS over UMTS CS	Qualcomm Incorporated	WI EVSoCS-CT CAT B
1059	CR 0659 29.232 Rel-13 Resolution of Editor’s note on EVS over UMTS CS	Qualcomm Incorporated	WI EVSoCS-CT CAT B
7.1.8	H.248 Aspects of WebRTC Data Channel on IMS Access Gateway	WebRTCH248DC
1007	CR 0104 23.334 Rel-13 Release of WebRTC Data Channels	Alcatel-Lucent	Revised to C4-161274
1274	CR 0104 23.334 Rel-13 Release of WebRTC Data Channels	Alcatel-Lucent	WI WebRTCH248DC CAT B
1008	CR 0105 29.334 Rel-13 WebRTC Data Channels	Alcatel-Lucent	Revised to C4-161273
1273	CR 0105 29.334 Rel-13 WebRTC Data Channels	Alcatel-Lucent	WI WebRTCH248DC CAT B
7.1.9	Monitoring Enhancements CT aspects	MONTE-CT
1035	LS in Rel-13 Reply LS on clarification on requirements for MONTE	S2	WI MONTE-CT To: CT4 Contact: ALU In your LS there are two questions: Question 1: If reporting is stopped due to roaming into an MME/SGSN which does not support the active monitoring event, should the HSS Inform the SCEF about the stop of Monitoring and continuation when the UE roams back into an MME/SGSN which supports the active events. SA2 have agreed the CR in S2-154378 (attached) that will cause the SCEF to be notified when the monitoring event cannot be supported. The monitoring event can be deleted or suspended. Please see the details in the approved CR. Question 2: Should there be a subscription parameter per monitoring event for each subscriber at the HSS, especially considering for events like location information, subscriber’s consent is required to expose towards 3rd party application in order to protect privacy? The text in step 4 of clause 5.6.1.1 of TS 23.682 is: 4. The HSS examines the Monitoring Request message, e.g. with regard to the existence of External Identifier or MSIDSN, whether any included parameters are in the range acceptable for the operator or whether the monitoring event that shall be deleted is valid. The HSS optionally authorizes the chargeable party identified by Chargeable Party Identifier. If this check fails the HSS follows step 8 and provides a Cause value indicating the reason for the failure condition to the SCEF. Since the HSS is required to examine the Monitoring Request message, it is reasonable to assume that the HSS may want (e.g., based on operator policy) to allow a particular monitoring event for one subscription and not allow it for another subscription. This would require information per monitoring event per subscription in the HSS for monitoring events the operator supports. In the particular case of location information, the SCEF must provide a level of filtering, per subscriber’s consent and operator policy, in the case of multiple reports that come to it directly from the MME/SGSN. Therefore, having the SCEF also provide at least that same level of filtering for a report that comes via the HSS is reasonable. It is not intended that the HSS maintain per subscription information on what types of location reporting are allowed, only whether location reporting is allowed or not. In regard to point A in your LS, SA2 agrees with CT4. In regard to points B and C in your LS, SA2 thanks CT4 in advance for keeping us informed. In regard to point D in your LS, SA2 notes that TS 23.682 CR 0134 has been agreed (S2-153063) which deletes “Presence Area reporting level” from clause 4.5.6.1, Note 1. SA2 anticipates further work on PRA reporting via the AULC work ongoing in SA2 for Rel-14. The Update Location procedure in TS 23.401 needs to be updated to allow the old MME/SGSN to send the latest continuous Monitoring Event reporting status to the HSS. The exact mechanism of the indication of non-support for requested Monitoring Event(s) between MME/SGSN and HSS is left to Stage 3. Proposed Treament: CT4 to take note of SA2's answers and take appropriate action. Postponed to 7.1.9
1060	pCR Rel-13 Pseudo-CR on Removing Editor's Note on IWK-SCEF Authorization and Configuration Failure at IWK-SCEF	Cisco Systems Inc
1061	CR 0618 29.272 Rel-13 Notifying the status of MONTE event configuration at the IWK-SCEF to the HSS	Cisco Systems Inc	CAT B
1075	discussion Rel-13 Discussion on status of MONTE work	Huawei	Revised to 1203	WI MONTE-CT
1203	discussion Rel-13 Discussion on status of MONTE work	Huawei	Revision of C4-161075 WI MONTE-CT
1076	pCR 29.128 Rel-13 Pseudo-CR on cleanup of 29.128	Huawei	WI MONTE-CT
1077	CR 0037 29.336 Rel-13 AVAILABILITY_AFTER_DDN_FAILURE reporting	Huawei	WI MONTE-CT CAT B
1078	CR 0038 29.336 Rel-13 Reporting of overload by the SCEF	Huawei	WI MONTE-CT CAT B
1079	CR 0477 23.008 Rel-13 Clarification on usage of P and T needs	Huawei	WI MONTE-CT CAT B
1080	pCR 29.128 Rel-13 Pseudo-CR on overload	Huawei	WI MONTE-CT
1081	CR 0329 23.007 Rel-13 HSS restart MONTE impacts	Huawei	WI MONTE-CT CAT B
1082	CR 0330 23.007 Rel-13 Restart of SCEF	Huawei	WI MONTE-CT CAT B
1083	CR 0039 29.336 Rel-13 SCEF and HSS Restart	Huawei	WI MONTE-CT CAT B
1084	CR 0040 29.336 Rel-13 Reporting of the start and stop of the reporting of monitoring events	Huawei, Cisco Systems Inc	WI MONTE-CT CAT B
1085	CR 0505 29.230 Rel-13 Correction of AVP code and new AVP assignment	Huawei	WI MONTE-CT CAT B
1128	CR 0621 29.272 Rel-13 Configure Monitoring Event to Multiple Serving Nodes	ZTE	WI MONTE-CT CAT B
1129	CR 0622 29.272 Rel-13 Inform the HSS of remaining number of reports	ZTE	WI MONTE-CT CAT B
1130	CR 0044 29.336 Rel-13 Count and Stop Monitoring Event Reports at SCEF	ZTE	WI MONTE-CT CAT B
1140	CR 0045 29.336 Rel-13 Change of type of Monitoring-Duration AVP to represent an absolute time	Ericsson	WI MONTE-CT CAT F
1141	CR 0509 29.230 Rel-13 Change of type of Monitoring-Duration AVP to represent an absolute time	Ericsson	CAT F
TS 29.128 v010 T6a/b	Peter (Rapporteur)	Agreed as the basis for future work	Draft available next Wednesday COB Europe. Final version available next Friday COB Europe.
7.1.10	Mobile Equipment signalling over the WLAN access	MEI_WLAN
7.1.11	Study on SCC AS Restoration	SCCAS_RES
TR 29.812 v0.3.0 SCC AS Restoration	Rapporteur (Zhang Hou)	Agreed as the Basis for Future Work	SCCAS_RES Draft available next Wednesday COB China. Final version available next Friday COB China.
7.1.12	SDP Capability Negotiation for IMS Media Plane	SDPCN_IMS
1251	CR 0108 29.334 Rel-13 Iq stage 3 to support SDP Capability Negotiation	Huawei	CAT B
1252	CR 0064 29.238 Rel-13 Ix stage 3 to support SDP Capability Negotiation	Huawei	WI SDPCN_IMS CAT B
1253	CR 0085 29.333 Rel-13 Mp stage 3 to support SDP Capability Negotiation	Huawei	WI SDPCN_IMS CAT B
1254	CR 0199 29.332 Rel-13 Mn stage 3 to support SDP Capability Negotiation	Huawei	WI SDPCN_IMS CAT B
1255	CR 0660 29.232 Rel-13 Mc stage 3 to support SDP Capability Negotiation	Huawei	WI SDPCN_IMS CAT B
7.1.13	Optimizations to Support High Latency Communications	HLcom-CT
7.1.14	Group based Enhancements	GROUPE-CT
7.1.15	Video Enhancements by Region-of-Interest Information Signalling	ROI-CT
7.1.16	S6a/S6d Shared Data Update	FS_eSDU
7.1.17	EPC Signalling Improvement for Race Scenarios	EPC_SIG_RACE
7.1.18	Dedicated Core Networks	DECOR-CT
1038	LS in Rel-13 LS on Retrieval of UE Usage Type from HSS	S2	WI DECOR-CT To: CT4 Contact: ALU SA2 thanks CT4 for their LS on retrieval of UE Usage Type from HSS. SA2 has evaluated and agreed to the proposal from CT4. Therefore, SA2 has agreed to the attached CR to TS 23.401. SA2 informs CT4 that there is no need for a CR to TS 23.060 because DCN feature related clause for UTRAN/GERAN only contains a pointer to clause 4.3.25.1 of TS 23.401 where DCN feature is specified. Proposed Treatment: CT4 to take the necessary action. Postponed to 7.1.18
1169	CR 0085 29.303 Rel-13 Clarification on the use of UE Usage Type	Ericsson, NTT DOCOMO	WI DECOR-CT CAT B
1176	CR 0086 29.303 Rel-13 DNS procedures for Decor	DOCOMO Communications Lab.	WI DECOR-CT CAT B
1183	CR 0435 23.003 Rel-13 Introduction of SGSN Group ID for Decor	DOCOMO Communications Lab.	WI DECOR-CT CAT B
7.1.19	Feasibility Study on the Diameter Base Protocol Update	FS_DBPU
1220	LS in Rel-14 Reply LS to CT4 LS on progress of the work on Diameter Base Protocol Update	S5	WI FS_DBPU To: CT4 CC: CT3, SA3 Contact: ALU SA5 thanks CT4 for their LS on progress of the work on Diameter Base Protocol Update (S5-161193/C4-152375) provided with the version of TR 29.819 feasibility Study on the Diameter Base Protocol Update, as basis for their CT4#72 next February meeting. During SA5#105, SA5 has reviewed the TR, and identified some updates were needed, based on their analysis on a set of differences between IETF RFC 3588 and IETF RFC 6733. As result SA5 endorsed the two pCRs attached, to be incorporated in the TR 29.819. SA5 kindly asks CT4 to incorporate in the TR 29.819, the two attached pCRs endorsed by SA5. Proposed Treatment: CT4 to consider SA5's request with their two pCRs. Postponed to 7.1.19
TR 29.819 v020 Diameter Base Protocol Update	Lionel Morand (Rapporteur)	Agreed as the basis for future work	Draft available next Wednesday COB Europe. Final version available next Friday COB Europe.
7.1.20	Diameter Message Priority	DiaPri
1191	CR 0047 29.336 Rel-13 Diameter message priority over S6m, S6n, S6t	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri CAT B
1192	CR 0020 29.338 Rel-13 Diameter message priority over S6c, SGd, GddDiameter message priority over S6c, SGd, Gdd	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri CAT B
1194	CR 0026 29.337 Rel-13 Diameter message priority over T4	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri CAT B
1195	CR 0629 29.272 Rel-13 Diameter message priority over S7a/d, S13, S13’	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri CAT B
1196	CR 0018 29.344 Rel-13 Diameter message priority over PC4a	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri CAT B
1197	CR 0041 29.345 Rel-13 Diameter message priority over PC6/PC7	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	CAT B
1199	pCR 29.128 Rel-13 Diameter message priority over T6a, T6ai, T6b, T6bi, T7	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, ACS, OEC	WI DiaPri
7.1.21	Indoor Positioning Enhancements for UTRA and E-UTRA	UTRA_LTE_iPos_enh-CT
1139	CR 0034 29.171 Rel-13 Implementation Error in CR#29	Ericsson, Nextnav, MCC	WI UTRA_LTE_iPos_enh-CT CAT F
7.2	CT4 Supported WIs
7.2.1	CT aspects of User Plane Congestion Management for BB I (CT3)	UPCON-DOTCON-CT
7.2.2	Enhanced P-CSCF discovery using signalling for access to EPC via WLAN (CT1)	ePCSCF_WLAN
7.2.3	CT aspects of QoS End to End MTSI extensions (CT3)	QOSE2EMTSI-CT
1225	LS in Rel-13 LS on Completion of QOSE2EMTSI work item	S4	WI QOSE2EMTSI-CT To: CT3 CC: CT1, CT4 Contact: Ericsson SA4 would like to inform CT1, CT3 and CT4 that the QOSE2EMTSI work item for Release 13 has now been completed. During the discussions in SA4 it was identified that the updates to the SDP definition may impact the PCC rules defined by CT3, see attached CR. SA4 would therefore like CT3 to take these updates into account in their work. Proposed Treatment: CT4 can Note. Postponed to 7.2.3
1013	discussion Rel-14 QoS end-to-end MTSI extensions: possible impact on H.248 packet gateways	Alcatel-Lucent	WI QOSE2EMTSI-CT
1049	CR 0106 23.334 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
1050	CR 0107 29.334 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
1051	CR 0091 23.333 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
1052	CR 0084 29.333 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
1053	CR 0063 29.238 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
1054	CR 0198 29.332 Rel-13 Support of enhanced bandwidth negotiation mechanism for MTSI sessions	Ericsson	WI QOSE2EMTSI-CT CAT B
7.2.4	Warning Status Report in EPS (CT1)	EPS WSR_EPS
1032	LS in Rel-13 Response LS on Conclusions from TR 23.712 on Warning Status Reporting	R3	WI WSR_EPS To: CT1, CT4 Contact: ALU RAN3 has agreed at RAN3#90 the attached CRs to TS 36.300 and TS 36.413 which introduce the new PWS Failure Indication procedure for ongoing PWS operation. Proposed Treatment: CT4 to take the necessary resultant action. Postponed to 7.2.4
7.2.5	IMS Signalling Activated Trace(CT1)	ISAT
7.2.6	IP Flow Mobility support for S2a and S2b Interfaces on stage 3 (CT1)	NBIFOM
1017	LS in Rel-13 LS on NBIFOM procedure in SCM and RAN rules handling parameter	C1	WI NBIFOM-CT To: SA2 CC: CT3, CT4 Contact: ZTE According to the description in subclause 6.2.3.1 of TS 23.161, default access can be transported between the UE and the network via EAP procedures when adding addition of trusted WLAN using SCM. This implies that 3GPP AAA server should be able to convey the default access between UE and TWAG. However, if the 3GPP AAA server does not support NBIFOM, the 3GPP AAA server may drop the default access receiving from the UE and the TWAN. Q1: Based above, if the 3GPP AAA server does not support NBIFOM, how do the UE and the network achieve to determine the default access? In addition, TS 23.161 specifies that network may provide RAN rules handling parameter to the UE when network-initiated mode is selected. However, it is not clear what procedures are used to provide this RAN rules handling parameter to the UE. Q2: In what procedures will the network provide the RAN rules handling parameter to the UE? Proposed Treatment: CT4 can Note. Postponed to 7.2.6
1018	LS in Reply LS on Disconnection of NBIFOM PDN Connection with the Cause "Reactivation Requested"	C1	WI PCSCF_RES_WLAN To: CT4 Contact: ALU CT1 reviewed the possible behaviours of a UE supporting NBIFOM if it receives a request to release a PDN connection with the cause "reactivation requested" over the 3GPP or the WLAN access, or a Detach request with the cause "reattach required" over the 3GPP access. CT1 confirms the CT4 analysis that if a UE supporting NBIFOM receives such a request over one access the UE shall initiate the release of the related PDN connection(s) over the other access. Further study is still needed for the Detach request case. CT1 agreed the attached pCR “Handling of the Reactivation Requested cause when NBIFOM” to TS 24.cde (C1-154843). Proposed Treatment: CT4 to necessary resultant action. Postponed to 7.2.6
1024	LS in Rel-13 LS on the decision of NBIFOM mode	C3	WI NBIFOM-CT To: SA2 CC: CT1, CT4 Contact: Huawei CT3 is working on the definition of NBIFOM mode on Gx interface and has some questions about the following definition in TS 23.161: 5.4.4 Mode Selection When an NBIFOM-capable UE supports ANDSF and has an ISRP rule valid in the registered PLMN then: - If the ISRP rule includes at least one "ISRP for IFOM" rule (irrespectively of its validity), the UE requests UE-initiated mode and the network selects UE-initiated mode. - Otherwise, the UE requests Network-initiated mode and the network selects Network-initiated mode. When an NBIFOM-capable UE does not support ANDSF or supports ANDSF but does not have an ISRP rule valid in the registered PLMN then: - The UE requests Network-initiated mode and the network selects Network-initiated mode. Q1: Based on the above SA2 definition, is it the intention to prevent the network from changing the NBIFOM mode requested by the UE side? Q2: If the answer to “Q1” is “YES”, then could you explain the reasons for such limitation? In CT3’s point of view, the PCRF shall decide which NBIFOM mode applies to the IP-CAN session. One reason is to fix the incorrect NBIFOM mode requested by the UE, because the UE is untrusted and the request may be wrong because of accidental or intentional mistake implemented in the UE side. Another reason is, in roaming case, when the UE receives the valid V-ISRP rule including at least one “"ISRP for IFOM" from the V-ANDSF Server, then based on the SA2 definition, the UE requests UE-initated mode. However, if the HPLMN has not deployed the ANDSF Server and wants all the UE to perform the NBIFOM according to the routing rule received from H-PCRF, then it’s better for the H-PCRF to decide the NBIFOM mode, e.g. changing the NBIFOM mode from UE-initated mode to Network-initiated mode. Proposed Treatment: CT4 can Note. Postponed to 7.2.6
1221	LS in Rel-13 LS on Charging Id assignment for NBIFOM	S5	WI NBIFOM-CH To: SA2 CC: CT3, CT4 Contact: Ericsson SA5 has determined that the current requirement to assign a unique charging identifier to each bearer as originally specified in TS 23.060, TS 23.401, and TS 23.402 shall be maintained. However, the original convention that the charging identifier for the default bearer be used as a "PDN connection charging id" is no longer sufficient. With the introduction of NBIFOM comes the possibility of a multi-access PDN connection with two default bearers. For correlation purposes, a single PDN connection charging id is still required. SA5 has determined when NBIFOM is supported for a PDN connection, an explicit charging identifier shall be assigned independent of the default bearer charging id to be the single PDN connection charging id for correlation purposes. As a result, the serving node can no longer rely on the convention that uses the charging id of the default bearer for this purpose and a new mechanism is required to convey the assigned PDN connection charging id to the serving node. 1. SA5 asks SA2 to define a mechanism to convey the assigned PDN connection charging id for a PDN connection to the serving node (S-GW, ePDG, and TWAG). SA5 has also determined that the bearer level charging identifiers and the PDN connection charging id described above shall be maintained when a serving node is changed, e.g. when UE moves PDN connection between LTE and WLAN or when serving gateway relocation is performed. As described above, with NBIFOM a situation can occur in which the PDN connection charging id has a value that differs from the default bearer charging id. 2. SA5 asks SA2 to define a mechanism to convey the assigned PDN connection charging id for a PDN connection to a serving node when the serving node is changed. For this purpose, serving node can be an S-GW, ePDG, or TWAG. SA5 has also studied the Access Charging Correlation procedures, as originally defined in TS 23.203, and determined that when NBIFOM is supported for a PDN connection that the PGW shall use the single PDN connection charging identifier for all flows as introduced in Release 12 when charging per IP-CAN session is active in the PGW. 3. SA5 asks SA2 to ensure that the current mechanism for access charging correlation in which the PDN connection charging id is used for all flows applies also when NBIFOM is supported for a PDN connection. Proposed Treatment: CT4 can Note. Postponed to 7.2.6
1229	LS in Rel-13 Reply LS on NBIFOM procedure in SCM and RAN rules handling parameter	S2	WI NBIFOM-CT To: CT1 CC: CT3, CT4 Contact: Huawei Regarding the following questions asked by CT1: Q1: Based above, if the 3GPP AAA server does not support NBIFOM, how do the UE and the network achieve to determine the default access? Answer 1: SA2 agreed to transfer the default access indication via 3GPP access in case of SCM. Q2: In what procedures will the network provide the RAN rules handling parameter to the UE? Answer 2: SA2 agreed that the network provides the RAN rules handling parameter to the UE during the PDN connection establishment via 3GPP. For more details please see the attached CR S2-160575. Proposed Treatment: CT4 can Note. Postponed to 7.2.6
1092	CR 0446 29.273 Rel-13 Remove the default access AVP	Huawei	WI NBIFOM-CT CAT F
1093	CR 0507 29.230 Rel-13 Remove the default access AVP	Huawei	WI NBIFOM-CT CAT F
1094	CR 1682 29.274 Rel-13 Update the reference for NBIFOM container	Huawei	WI NBIFOM-CT CAT F
1095	CR 0508 29.230 Rel-13 Specific AVP codes for NBIFOM	Huawei	WI NBIFOM-CT CAT F
1167	CR 1692 29.274 Rel-13 PDN Connection Charging ID	Ericsson, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI NBIFOM-CT CAT F
7.2.7	Enhancements to Proximity-based Services extensions (CT1)	eProSe-Ext-CT
1230	LS in Rel-13 LS on the Revocation of Discovery Filters	S2	WI ProSe-CT To: CT4 CC: CT1 Contact: TelecomItalia First of all SA2 wants to clarify that the Revocation of Discovery Filters procedure in section 5.3.6A.2.2 has been defined to revoke the authorization to use certain discovery filters as soon as possible after the user has changed the discovery permissions. SA2 answers to CT4 comments to the Revocation of Discovery Filters procedure are as follows: CT4 comment: However, the consequence of the notification of a partial/complete failure in the revocation process is not described: nothing is said on the possible actions that would be performed by the ProSe functions or the ProSe Application Server. As currently described, it seems that the notification phase in the steps 10 and 11 is mainly for information. CT4 has therefore questioned whether the notification phase in the revocation procedure was really required. SA2 Answer: If the ProSe Application Server is notified in step 12 about the failure of the revocation process then it may issue a new revocation request to the HPLMN ProSe Function and/or it may warn the user across the PC1 reference point. Those steps are not explicitly described in the Revocation of Discovery Filters procedure because they depend on the implementation of the ProSe Application Server, that is out of the scope of 3GPP: nevertheless a reliable information shall be conveyed to the ProSe Application Server to enable those steps. CT4 comment: After the step 7, the ProSe Function in the HPLMN has the confirmation that the update request has been successfully processed by the ProSe Function in the other PLMN. At this stage, the ProSe Function in the other PLMN can initiate the revocation of the discovery filters towards the impacted UEs. If the first attempt fails, the ProSe function may re-attempt the revocation. SA2 Answer: After step 7 the ProSe Function in the HPLMN only knows that the update request has been successfully received by the ProSe Function in the other PLMN but doesn’t know anything about the result of the revocation process. CT4 comment: If the revocation is unsuccessful, it seems that it is not so critical from a service point of view as the changes in the discovery permissions will be anyway effective after the expiration of the validity timer associated to the corresponding ProSe Restricted Code. SA2 Answer: Waiting for the expiry of the validity timer is not acceptable because it could be set by the operator to a very long value (e.g., one day) in order to minimize the signalling load over the PC3 reference point. Moreover, if the user cannot be sure that the revocation of the discovery permissions will be effective when he requests it, and not some hours or days after then we do not see the gain to have a revocation procedure at all. CT4 comment: If any discovery must be prohibited after the revocation request, the sets of Banned RPAUID - Banned PDUID could be also stored by the ProSe Function in the HPLMN until the expiration of the validity timer associated to the corresponding ProSe Restricted Code. In such a case, the HPLMN ProSe Function would be able to reject the unauthorized restricted discovery requests. SA2 Answer: The point is not just to prohibit any discovery after the revocation request but also, and more important, to inhibit the use of the already allocated discovery filters without the need to wait for the expiry of the associated validity timers, therefore the proposed alternative solves only part of the problem. For the above reasons SA2 believes that the notification phase described in the steps 10/11 cannot be removed from the Revocation of Discovery Filters. Proposed Treatment: CT4 to take Note of SA2's answers. Postponed to 8.2.4
1056	discussion Rel-13 eProSe-Ext-CT impacts	Qualcomm Incorporated	WI eProSe-Ext-CT
1057	CR 0434 23.003 Rel-13 Addition of ProSe Application Code Prefix and ProSe Application Code Suffix formats	Qualcomm Incorporated	WI eProSe-Ext-CT CAT B
1086	CR 0036 29.345 Rel-13 Reporting of Monitoring update result	Huawei	WI eProSe-Ext-CT CAT B
1117	CR 0037 29.345 Rel-13 Inter-PLMN discovery transmission support	Qualcomm Incorporated	WI eProSe-Ext-CT CAT F
1118	CR 0038 29.345 Rel-13 Adding security related parameters for restricted ProSe direct discovery authorization	Qualcomm Incorporated	WI eProSe-Ext-CT CAT F
1119	CR 0039 29.345 Rel-13 Support open discovery with application-controlled extension	Qualcomm Incorporated	WI eProSe-Ext-CT CAT F
1120	CR 0040 29.345 Rel-13 Discovery update for open and restricted ProSe direct discovery	Qualcomm Incorporated	WI eProSe-Ext-CT CAT F
1170	CR 1694 29.274 Rel-13 Cleanup of the editor's notes for reporting remote UE	Ericsson	WI eProSe-Ext-CT CAT B
1243	CR 0036 29.345 Rel-13 Monitoring update and Reporting of update result	Huawei, Orange, Telecom Italia	Revision of C4-161086 WI eProSe-Ext-CT CAT B
1246	CR 0517 29.230 Rel-13 Monitoring update and Reporting of update result	Huawei	WI eProSe-Ext-CT CAT B
1248	CR 0519 29.230 Rel-13 Allocation of new Diameter Application ID and commands code for PC2 protocol	Huawei	WI eProSe-Ext-CT CAT B
7.2.8	Architecture Enhancements for Service Capability (CT3)	AESE-CT
1034	LS in Rel-13 Reply LS on clarification on requirements for AESE	S2	WI AESE-CT To: CT4 Contact: ALU In your LS you indicate: I) Overwriting of CP parameter set(s) In TS 23.682 sub-clause 5.10.2 the NOTE2 talks about overwriting of CP sets. The NOTE2 mentions the same SCS/AS or another SCS/AS, but not what happens if it is the same or different SCEFs. CT4's understanding is: A) Overwriting is allowed when the request is from the same SCEF and the CP parameter provisioning procedure shall be treated as a configuration update procedure. If there is a clash in one part of the CP set in a request with stored CP parameter, the overwriting is for the whole CP parameter set assigned to the SCEF reference ID. This means the CP parameter sets belonging to the old SCEF reference ID are cancelled and the new SCEF reference ID are stored. This has to be done in the HSS and in the MME. However currently stage 2 doesn’t define an update (or) delete procedure for the CP parameter sets. Question 1: Does SA2 agree with this understanding and intend to introduce a CP parameter update procedure? SA2 Response: At SA2#111, CR0142rev3 for TS 23.682 was approved (see S2-153692 attached). In that CR, changes were made that: a) Require that in Rel-13 only a single SCEF shall be permitted by the HSS to configure CP parameter sets for a given UE; b) Place the responsibility on the SCEF to assure that there are no overlapping CP parameter sets, while allowing the configuration of multiple CP parameter sets for the same UE. Two examples are given in the CR to help with understanding. c) Clause 5.10.2 of TS 23.682 now supports configuration, modification, and deletion of CP parameter sets. d) Validity time is defined as indicating the expiration time of a CP parameter set. B) If the request comes from a different SCEF than the SCEF which has send the CP parameter sets earlier, this is an error case which SA2 assumes will be handled by stage 3. Question 2: Does SA2 agree with this? SA2 Response: As noted in the answer to Question 1, it is mandatory in Rel-13 that only a single SCEF shall be permitted by the HSS to configure CP parameter sets for a given UE. SA2 expects that stage 3 will handle error cases, including the case of a request to configure CP parameter sets by a second SCEF for a given subscription. II) 3GPP TS 23.682 sub-clause 5.10 mentions the parameter "validity time" in the procedure description and a "Scheduled communication time" in the Table 5.10.1-1. CT4's understanding is that the description of "validity time" by SA2 implies the Scheduled Communication Time. CT4 also felt that a separate time called "period of validity" will be required to indicate how long the CP parameter set is valid (define an expiration time for the CP parameter set). Question 3: CT4 kindly asks SA2 to clarify if CT4's understanding of the "validity time" description in TS 23.682 is correct and if yes, whether adding an additional "period of validity" is applicable. SA2 Response: As noted in the answer to Question 1 item d), “validity time" is defined as indicating the expiration time of a CP parameter set. III) For MONTE we have the possibility to delete events. CT4 felt it would be beneficial to add a delete mechanism for the CP parameter set as well using the SCEF Reference ID as the key similar as for MONTE (SCEF Reference ID for deletion). Question 4: CT4 kindly asks SA2 to consider the above. SA2 Response: As noted in the answer to Question 1 item c), clause 5.10.2 of TS 23.682 now supports configuration, modification, and deletion of CP parameter sets. Proposed Action: CT4 to take note of SA2's answers and take action accordingly. Postponed to 7.2.8
7.2.9	Support of Emergency services over WLAN – phase 1 (CT1)	SEW1-CT
1036	LS in Rel-13 LS on Network asserted WLAN Location Information for PDN connection establishment over S2b	S2	WI SEW1-CT To: CT4 CC: CT3 Contact: ALU SA2 thanks CT4 for their LS on Network asserted WLAN Location Information for PDN connection establishment over S2b. SA2 have discussed the issue and, as proposed by CT4, concluded that it is valuable that, when available, User Location Information is transferred by the ePDG to the PGW for emergency and non-emergency PDN connections. This indeed allows a generic behaviour, as providing location information over S2b is useful also for non-emergency PDN connections. The User Location Information shall include UE local IP address and optionally UDP source port number (if NAT is detected). It may also include WLAN Location Information (and its Age) the ePDG may have received from the 3GPP AAA server about the UE. The WLAN Location information is provided to the ePDG when the 3GPP AAA server considers that location information coming from the WLAN AN used by the UE is trustable. Proposed Treatment: CT4 to take SA2's answers into account as per their attached CRs. Postponed to 7.2.9
1156	CR 0449 29.273 Rel-13 Correction of CR Implementation on Emergency PDN connection over untrusted WLAN	MCC, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI SEW1-CT, TEI13 CAT F
1157	CR 0450 29.273 Rel-13 ePDG retrieval of WLAN Location Information	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI SEW1-CT, TEI13 CAT F
1158	CR 0512 29.230 Rel-13 ePDG retrieval of WLAN Location Information	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI SEW1-CT, TEI13 CAT F
7.2.10	Extended DRX cycle for power consumption optimization (CT1)	eDRX-CT
1020	LS in Rel-13 LS on issues related to MT SMS over SGs delivery in eDRX	C1	WI eDRX-CT To: SA2 CC: CT4 Contact: Huawei CT1 has observed some issues for the mobile terminated SMS in eDRX procedure described in TS 23.272 subclause 8.2.4a (the procedure shown in Figure 8.2.4a-1). The more critical issues are described below: a. Every MT SMS delivery for UEs in eDRX will cause systematically 5 pairs of messages at the HSS (i.e. the step 3, 8, 12, 13 and another step 3 during step 14 in the Figure 8.2.4a-1). Prior to the introduction of eDRX, steps 3, 8, 12, 13 and 14 are only triggered when the UE is not reachable, which should remain normally a rather rare case (for UEs with an always-on connectivity). With eDRX, MT SMS may cause substantial additional signalling to the HSS. b. There is no synchronisation between the SC and the MME about the time period during which the MME maintains the signalling connection with the UE. So there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained (e.g. SMS-GMSC overload) CT1 would like SA2 to provide the feedback on above issues for MT SMS over SGs in eDRX. Proposed Treament: CT4 can Note. Postponed to 7.2.10
1026	LS in Rel-13 Reply LS on the Setting of Delay Tolerant Connection Indication	C3	WI eDRX-CT To: CT4 CC: SA2 Contact: Ericsson CT3 thanks CT4 for their LS on the setting of Delay Tolerant Connection Indication (DTCI) during a PDN connection creation procedure. CT4 has informed CT3 that CT4 had agreed to the following: The DTCI is set by the PGW/GGSN according to the local policies in the PGW/GGSN e.g. on per APN basis. CT3 has discussed this and has come to the conclusion that there is no impact to PCC interfaces. CT3 asks CT4 to take the above information into account and update the corresponding WID accordingly. Proposed Treatment: CT4 to update the WID. Postponed to 7.2.10 or leave as updated WID may be in 5?
1231	LS in Rel-13 LS on issues related to MT SMS over SGs delivery in eDRX	S2	WI eDRX-CT To: CT1 CC: CT4 Contact: Qualcomm SA2 have discussed these issues and finds the issues in the LS and would like to provide the following feedback: a. Every MT SMS delivery for UEs in eDRX will cause systematically 5 pairs of messages at the HSS (i.e. the step 3, 8, 12, 13 and another step 3 during step 14 in the Figure 8.2.4a-1). Prior to the introduction of eDRX, steps 3, 8, 12, 13 and 14 are only triggered when the UE is not reachable, which should remain normally a rather rare case (for UEs with an always-on connectivity). With eDRX, MT SMS may cause substantial additional signalling to the HSS. SA2 feedback: 1. It should be possible for eDRX feature to be deployed without requiring changes to legacy SMS infrastructure. Therefore, the handling of MT SMS as currently defined in TS 23.272 should be allowed. 2. On the other hand, SA2 recognizes that the procedure for MT SMS as currently defined in TS 23.272 does require signalling. A large frequency of MT SMS would create substantial additional signalling to the HSS. 3. SA2 has not discussed any solution for MT SMS optimizations to reduce signalling towards the HSS, and welcomes CT1 to further study this issue, if necessary, taking the above into account. b. There is no synchronisation between the SC and the MME about the time period during which the MME maintains the signalling connection with the UE. So there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained (e.g. SMS-GMSC overload) SA2 feedback: • SA2 agrees there is no guarantee that the SMS-GMSC retransmits the SM during the time window where the signalling connection is maintained. Proposed Treatment: CT4 to take Note of SA2's answers to CT1. Postponed to 7.2.10
1062	CR 1200 29.002 Rel-13 Requested Retransmission Time in MT-Forward-SM response	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI eDRX-CT CAT F
1151	discussion New Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, Ericsson, Verizon, AT&T, Vodafone
1152	CR 0019 29.338 Rel-13 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, Ericsson, Verizon, AT&T, Vodafone	WI eDRX-CT CAT B
1153	CR 0511 29.230 Rel-13 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, Ericsson, Verizon, AT&T, Vodafone	WI eDRX-CT CAT B
1154	CR 1202 29.002 Rel-13 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, Ericsson, Verizon, AT&T, Vodafone	Revised to C4-161271
1271	CR 1202 29.002 Rel-13 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks, Ericsson, Verizon, AT&T, Vodafone	WI eDRX-CT CAT B
1155	CR 0062 29.305 Rel-13 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI eDRX-CT CAT B
1172	CR 1033 29.060 Rel-13 Delay Tolerant Connection Indication	Ericsson, MCC	WI eDRX-CT CAT B
1173	CR 1034 29.060 Rel-13 Triggering MT SM retransmission by the SMS GMSC to a UE in eDRX during inter MME/SGSN mobility procedure for GTPv1	Ericsson, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Vodafone	WI eDRX-CT CAT B
1174	CR 1695 29.274 Rel-13 Triggering MT SM retransmission by the SMS GMSC to a UE in eDRX during inter MME/SGSN mobility procedure	Ericsson, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Vodafone	WI eDRX-CT CAT B
7.2.11	Mission Critical Push To Talk over LTE protocol aspects (CT1)	MCPTT-CT
1021	LS in Rel-13 LS on MCPTT Group data and affiliation	C1	WI MCPTT-CT To: SA6 CC: CT4 Contact: Ericsson From 3GPP TS 23.179 v13.0.0, it indicates that affiliation status is a part of the MCPTT group information stored in the group management server and that the affiliation status is set solely by the MCPTT server handling the (de)affiliation requests. Some companies believe that affiliation status of an MCPTT group is changed more often than other parameters of the MCPTT group. Other companies believe that this is subjective in the cases where the XCAP document data is persistent for 30-minutes or more. CT1 asks SA6 to clarify why the MCPTT server handling the (de)affiliation requests stores the affiliation status in the group management server. Proposed Treatment: CT4 can Note. Postponed to 7.2.11
1267	LS in Rel-13 Reply LS on CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points	C1	WI MCPTT-CT To: CT4 CC: SA3, SA6 Contact: Samsung The LS lists a number of assumptions and some open questions. With regard to the questions, CT1 believes that these questions should be answered by SA6 as they do not pertain to protocol-related aspects. With regards to the assumptions in the LS that CT4 discussed in the joint meeting in Nashville, CT1 would like to re-confirm these assumptions. Proposed Treatment: CT4 can note. Postponed to 7.2.11
1268	LS in Rel-13 LS Response on User Databases interfaces for MCPTT	3GPP TSG SA WG6	WI MCPTT-CT To: CT4 Contact: Nokia SA6 thanks CT4 for sending the LS on User Databases interfaces for MCPTT, focusing on interfaces AAA-1 and MCPTT-2. SA6 discussed the questions contained in the LS and reached conclusion that some answers were already provided during conference calls or will be addressed within the reply LS on “CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points” (C4-160019 / S6-160008). Proposed Treatment: CT4 can Note. Postponed to 7.2.11
1269	LS in Rel-13 LS Response on CT4 assumptions on AAA-1, MCPTT-2 and CSC-13 reference points	3GPP TSG SA WG6	WI MCPTT-CT To: CT4 CC: CT1, SA3 Contact: Samsung Regarding a set of working assumptions identified by CT4, SA6 would like to inform CT1 as follows: A/ Regarding the IMS Registration procedure Assumption 1: It is assumed that IMS identities (IMS private identity and IMS public identity) are used during SIP registration in the same way as it is done in a normal IMS registration. SA6 Answer : Yes, SA6 confirms this assumption Assumption 2: How the UE retrieves the identities to use in the registration and how the relation between IMS identities and MCPTT identities is done will be clarified by SA3. SA6 Answer : SA6 confirms that SA3 will clarify how the UE retrieves the identities to use in the registration. The relation between IMS identities and MCPTT identities are defined in TS 23.179 (see clause 8). Assumption 3: It is assumed that the IMS private identity and/or the IMS public identity will contain the name of the domain in which is located the HSS/SIP database serving the called MCPTT user. This information is required by the I-CSCF/Registrar finder and the S-CSCF/Registrar to address the HSS/SIP user database located in an external network. SA6 Answer : Yes, SA6 confirms this assumption Assumption 4: It is assumed that the registration authorization given by the HSS/SIP database to the I-CSCF/ Registrar finder does not depend on the fact that the registration authorization is requested for MCPTT or not. It is a normal IMS registration authorization request procedure i.e. there is no specific information to add in the authorization request sent to the HSS/SIP database and in the response received by the I-CSCF/Registrar finder. SA6 Answer : Yes, SA6 confirms this assumption Assumption 5: It is assumed that the service profile retrieved from the HSS/SIP user database during the registration of an IMS public identity contains filter criteria which may trigger multiple application servers e.g. the MCPTT server and one SIP AS for MMTEL. SA6 Answer : Yes, SA6 confirms this assumption B/ Regarding SIP call establishment Assumption 6: It is assumed that call requests between MCPTT servers in case of private/group calls across multiple MCPTT systems are routed using either: - a Public Service Identity (PSI) mapping the called MCPTT ID/MCPTT group ID in the MCPTT Server. This PSI identifies the MCPTT server serving the called MCPTT user/MCPTT group; or - an IMPU mapping the called MCPTT ID in the MCPTT server. This IMPU identifies the called user. The IMPU/PSI is used by the I-CSCF/Registrar finder to retrieve from the HSS/SIP database the required information to forward the call request to the MCPTT server serving the called MCPTT user/MCPTT group. SA6 Answer : Yes, SA6 confirms this assumption C/ MCPTT user database and related reference points Assumption 7: It is assumed that the MCPTT user profile contains only MCPTT user configuration data defined in the Annex B.3 in the TS 23.179. SA6 Answer : Yes, SA6 confirms this assumption. Please take note that the title of Annex B.3 is renamed as MCPTT user profile data. Assumption 8: It is assumed that the data access by CSC-13 is only the MCPTT user profile. SA6 Answer : Yes, SA6 confirms this assumption Assumption 9: It is assumed that the data access by MCPTT-2 is only the MCPTT user profile and this profile is the same than the one managed by the configuration management server over the CSC-13 reference point. SA6 Answer : Yes, SA6 confirms this assumption Assumption 10: It is assumed that the MCPTT server does not update the MCPTT user profile in the MCPTT user database. SA6 Answer : SA6 believes that it should be possible for MCPTT server to update the MCPTT user profile. However, no procedures currently exist in TS 23.179, and SA6 does not intend to define any procedures in Rel-13. Assumption 11: It is assumed that the MCPTT user database is provisioned with the MCPTT user profiles (i.e. the MCPTT ID and the associated MCPTT user profile(s). SA6 Answer : Yes, SA6 confirms this assumption Assumption 12: It is assumed that the MCPTT ID is the primary key to access any data in the MCPTT user profile. SA6 Answer : Yes, SA6 confirms this assumption Assumption 13: It is assumed that IMS identities are not used as keys to access data. SA6 Answer : Yes, SA6 confirms this assumption Assumption 14: It is assumed that the MCPTT user database does neither apply any logic based on data stored nor manipulate the MCPTT user profile in any way, i.e. it does not have any knowledge about stored data. SA6 Answer : Yes, SA6 confirms this assumption Assumption 15: It is assumed that MCPTT user profile(s) data format is XML. SA6 Answer : It is responsibility of CT1 to define MCPTT user profile(s) data format. Assumption 16: It is assumed that one single MCPTT server is in charge of the MCPTT ID at a given time. SA6 Answer : Yes, SA6 confirms this assumption Assumption 17: It is assumed that CSC-13 and MCPTT-2 are intra-domain interfaces. SA6 Answer : Yes, SA6 confirms this assumption Regarding open questions asked by CT4, SA6 would like to inform CT1 as follows: D/ Open questions Question 1: Is it required to define a specific format for the MCPTT ID beyond TS 23.179 requirements (i.e. MCPTT ID is defined as a URI)? SA6 Answer : No from SA6 perspective. Question 2: Is it required to define a specific format for the PSI? SA6 Answer : No from SA6 perspective. Question 3: Is there any other data than the MCPTT user profile to convey over the MCPTT-2 reference point? SA6 Answer : No. Question 4: If multiple MCPTT user profiles are defined per MCPTT ID, is there any need for MCPTT user profile id as a secondary access key? SA6 Answer : SA6 could not reach a conclusion on whether or not a secondary access key is needed over CSC-13 and MCPTT-2. Question 5: Is it required to allow configuration management servers to create/upload in the MCPTT user database additional profiles to an existing MCPTT ID? SA6 Answer : Yes. Proposed Treatment: CT4 to take SA6's answers into account. Postponed to 7.2.11
1088	CR 0661 29.228 Rel-13 Introduction of AAA-1 interface	Huawei	Revision of C4-160021 WI MCPTT-CT CAT B
1202	CR 0018 29.335 Rel-13 MCPTT data model	Ericsson	CAT B
1237	discussion Rel-13 Sh* application for MCPTT-2 and CSC-13 interfaces	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI MCPTT-CT
1238	discussion Rel-13 Skeleton for Sh* application for MCPTT-2 and CSC-13 interfaces	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI MCPTT-CT
1240	CR 0015 23.335 Rel-13 Data model for new Application FEs’ data clarification	Ericsson	WI MCPTT-CT CAT B
1244	CR 0661 29.228 Rel-13 Introduction of AAA-1 interface	Huawei	Revision of C4-161088 WI MCPTT-CT CAT B
1270	DISC Skeleton and content pCR for the new Diameter application for MCPTT-2 and CSC-13 reference points	Orange	WI MCPTT-CT
7.2.12	Enhancements to WEBRTC interoperability stage 3 (CT1)	eWebRTCi_CT
1009	CR 0105 23.334 Rel-13 WebRTC gateway configuration for end-to-end WebRTC calls (stage 2)	Alcatel-Lucent	WI eWebRTCi-CT CAT B
1010	CR 0106 29.334 Rel-13 WebRTC gateway configuration for end-to-end WebRTC calls (stage 3)	Alcatel-Lucent	WI eWebRTCi-CT CAT B
1011	CR 0062 29.238 Rel-13 TrGW configuration for end-to-end WebRTC calls (stage 3)	Alcatel-Lucent	WI eWebRTCi-CT CAT B
1012	discussion 29.334 Rel-13 H.248 WebRTC gateway bearer plane interworking for end-to-end WebRTC traffic	Alcatel-Lucent	WI eWebRTCi-CT
1185	CR 0107 23.334 Rel-13 WebRTC media plane optimization procedure	Nokia Networks	Revised to C4-161272
1272	CR 0107 23.334 Rel-13 WebRTC media plane optimization procedure	Nokia Networks, Alcatel-Lucent	WI eWebRTCi-CT CAT B
7.2.13	MBMS Enhancements (CT3)	MBMS_enh-CT
7.2.14	Cellular Internet of Things (CT1)	CIoT
1022	LS in Rel-13 LS on questions on CIoT	C1	WI CIoT-CT To: SA2, RAN2, RAN1 CC: CT4 Contact: Huawei CT1 have started work on CIoT and would like to ask the following questions: (1) To SA2: Have CT1 to provide support for UEs which can have the UE-SCEF connection running in parallel with PDN connection such as Internet, IMS etc. Further information: A use case has been brought to the CT1 attention which describes that the UE can have multiple PDN connections simultaneously in addition to CIoT functionality running (e.g., control plane IoT towards the SCEF via the MME and simultaneous PDN connections towards the P-GW such as Internet and IMS). (2) To SA2: Will the UE-SCEF connection be only utilized for non-IP transmission? Further information: CT1 find not clear whether the UE-SCEF connection can be used for non-IP or also IP data. (3) To SA2: With regards to the Solution 18; can data be sent over the user plane when the UE have multiple PDN connections? (4) To SA2: Is inter-RAT mobility to/from NB-IoT supported? If so, will the data be sent by the UE over control plane in an NB-IOT cell needs to be mapped to the EPS bearers established in E-UTRA? Further information: CT1 would need to know this for the case the UE has established bearers in E-UTRA and moves to NB-IOT. (5) To SA2: Has the CIoT IP data transport to be mapped to an existing EPS bearer context? Further information: Some companies in CT1 indicate that for the case of IP data transport, mapping to an existing EPS bearer context could allow the sending of the IP data between the CN nodes over a bearer. However, this requires that the EPS bearer identity is included in the NAS message together with the encapsulated IP data to be sent. Is this aligned with SA2 understanding? (6) To SA2: Is the indication on immediate acknowledgement/response data to the corresponding CIoT data really needed for all cases of CIoT data or not? Further information: CT1 notice that the technically endorsed SA2 CR in S2-154451 states, quote: The UE can also indicate a Release Assistance Information in the NAS message about whether Downlink data transmission (e.g. Acknowledgements or responses to UL data) subsequent to the Uplink Data transmission is expected or not. Considering the case of SMS, currently the acknowledgement of received SMS is always required, and hence CT1 would like to know whether this is applied to the CIoT SMS too. For the case of CIoT non-IP and IP data, CT1 asks why the immediate acknowledgement/response data is actually required. Furthermore, CT1 notice that SA2 does only describe such indication for the UL direction, and therefore would like to know whether the same requirement applies to the DL direction too. (7) To SA2: Can you clarify the way the S1 connection release indication works? Further information: CT1 notice that SA2 has described in the technically endorsed CR in S2-154451, quote: The UE may also indicate whether the S1 connection has to be released when DL data is received From stage 3 perspective (TS 24.301), the release of the S1 connection is controlled by the network and not based on indication from the UE. Furthermore, the network can refer the acknowledgement/response indication provided by the UE in order to decide the release of the S1 connection (if the UE expects ack data, the network will not release the S1 connection immediately after the receipt of uplink CIoT data). (8) To SA2: If the S1 connection release indication is used with uplink data, then the MME can anyhow perform S1 release procedure after the end of downlink data transmission. If this occurs; should the UE proceed with it even if the UE wants to keep the S1 connection in order to send uplink data later? Further information: The following scenario has been brought up: 1. The UE provides the S1 connection release indication with uplink data. 2. The MME forwards the received data and downlink data is transmitted towards the UE. Note that the downlink data is not acked. 3. The MME performs S1 release procedure after the end of the downlink data transmission. Note that the MME cannot know whether downlink data is acked or not. 4. The UE has received all downlink data which is not acked but the UE shall proceed with the S1 release procedure. (9) To SA2: Is the CIoT data type (non-IP or IP) required to be included in the NAS message together with the encapsulated CIoT data? Further information: CT1 notice that this is not explicitly described by the technically endorsed SA2 CR in S2-154451. However, CT1 do notice that this is part of the TR 23.720 for UL data to enable the transportation of the CIoT data to the P-GW or SCEF. Hence, CT1 would like to confirm with SA2 this aspect, and if the answer is YES, then CT1 will need to know whether this applies to the DL data too. (10) To SA2: Can it always be ensured that the ATTACH REQUEST message for CIoT optimizations reaches an MME which supports CIoT optimizations? (11) To SA2: If a legacy MME can receive the ATTACH REQUEST message for CIoT optimizations, what’s the expected UE and network behaviour upon receipt of the message considering the following two scenarios? a) The ATTACH REQUEST message arrives without one or more mandatory IE(s). b) The ATTACH REQUEST message arrives with all expected mandatory IEs. (12) To SA2: Is header compression required for IP data, or is some form of header compression also required for non-IP data? (13) To SA2: Are CIoT optimizations applicable to combined attached UE for both EPS and non-EPS services? (14) To SA2: Is SDU segmentation/reassembly required for CIoT? If so, is there a distinction between data over control plane and data over user plane? Further information: A company has suggested that SDU segmentation/reassembly is introduced and that the RAN/UE should prioritise transmission of signalling packets ahead of queued data PDUs. These proposals would have major impacts to NAS from what it’s defined today. (15) To RAN1: If SDU segmentation/reassembly is required for CIoT, what’s the minimum data rate on the uplink and on the downlink at the extreme "+20dB" coverage scenario? Further information: A company has suggested that SDU segmentation/reassembly is introduced and that the RAN/UE should prioritise transmission of signalling packets ahead of queued data PDUs. Hence, in order to determine NAS signalling timer values and the SDU size used by the "data via MME", CT1 might need to know the minimum data rate. (16) To: RAN2: Is (or will be) NB-IoT designed to guarantee in-sequence-delivery of packets? Further information: The CT1 NAS security protocol discards out-of-sequence packets as in E-UTRA the RLC ensures in-order delivery of SDUs. Does NB-IOT also provide in-order delivery of SDUs? If this not provided major impacts to NAS security protocol are envisioned. (17) To SA2: Is there is any requirement to handle the “data via MME” and the NAS signalling message PDUs with different priorities? Further information: For instance, providing a higher priority to handle the NAS signalling message PDU, at the eNodeB and the lower layer in the UE. Proposed Treatment: CT4 can Note. Postponed to 7.2.14
1033	LS in Rel-13 LS on S1 signalling solutions for non-NB-IoT UEs	RP	WI NB_IOT-Core To: SA2, SA3, SA, CT1, CT3, CT4, RAN2, RAN3 CC: RAN1 Contact: Ericsson RAN discussed applicability of S1 signalling enhancements for non-NB-IoT UEs, i.e., Solution 2 and Solution 18 as discussed in SA2. RAN made following agreements how to proceed with this: • Signalling design for solution 2 and solution 18 for NB-IoT UEs is done in NB-IoT session. Additional changes due to support for other UEs will be done in TEI13 session. However, additional optimizations for non-NB-IoT UEs will not be discussed. • We will have – CRs for NB-IoT UEs (including e.g. L1 parameters, signalling enhancements and other enhancements) – and a separate CR of additional impact due to non-NB-IoT UEs (e.g. capabilities). • RAN2 and RAN3 have to allocate TEI13 time for the support of non-NB-IoT UEs. • Will inform CT1/SA2 by LS and they can apply same approach. • This approach is applied both for Sol2 and Sol18 unless there are significant impacts on specifications identified. RAN would like to inform SA2 that is has not discussed or understood the impacts of the issues raised in Sections 3.3 - 3.6 in RP-151991. Proposed Treatment: CT4 can Note. Postponed to 7.2.14
1042	LS in Rel-13 Reply LS on questions on CIoT	R2	WI CIoT-CT To: CT1 CC SA2, RAN1, CT4 Contact: Huawei RAN2 thanks CT1 for the LS and would like to provide feedback on Q16: (16) To: RAN2: Is (or will be) NB-IoT designed to guarantee in-sequence-delivery of packets? RAN2: Yes, NB-IoT design guarantees in-sequence-delivery of packets as for LTE. In addition RAN2 has discussed the per-UE configuration to allow exception reporting and would like to ask CT1 if it is possible to support this by NAS. Proposed Treatment: CT4 can Note. Postponed to 7.2.14
1227	LS in Rel-13 LS on guidance by SA2 on CIOT	S2	WI CIoT-CT To: CT4 Contact: ALU In relationship to a document received during SA2#113 (S2-160484) describing a list of questions by CT4 originated during the 1st CT4 Telco on CIoT that was held on Monday 18th January, SA2 would like to provide the following guidance 1. Is there a need/requirement to support separate control for WLAN Offloadability for WB-E-UTRAN vs. NB-IoT? S2-154394 cover page requests separate control for WLAN mobility, but this is not further documented in the CR body. SA2 response: It is not expected in rel-13 that the NB-IoT cell sends any RAN assistance data. Hence this parameter is not relevant to the UE when using NB-IoT. Separate HSS/MME parameters for WB-E-UTRA and NB-IoT are not needed for WLAN Offloadability. The update of that CR no longer mentions the topic. . 2. Selection of PGW supporting Non-IP data: assuming a user subscription is configured for a given APN with the Non-IP PDN type, can it be assumed that all PGWs returned by DNS for that APN will support Non-IP data (i.e. that there is no need for new DNS mechanisms to determine whether a particular PGW supports Non-IP or not)? SA2 response: It is SA2 understanding that there shall be support of Non-IP data in SGW/PGWs that are associated to an APN the UE or MME select to use Non-IP data. 3. Selection of an SGW/PGW supporting the NB-IoT RAT: is it permitted to select an SGW/PGW not supporting the NB-IoT RAT, for a UE accessing NB-IOT, if there is no candidate SGW/PGWs supporting NB-IoT? Does SA2 assume that some SGWs and PGWs are dedicated to certain RAT, e.g. NB-IoT only? SA2 response: yes it is permitted to select a SGW/PGW that does not understand “RAT type = NB-IoT”, however, there may well be cases where the SGW/PGW implementation is optimised (e.g. with low cost but high latency PDN context retrieval mechanisms) to support NB-IoT (or Low Complexity eMTC) devices. It is expected that the APN and/or UE Usage Type can be configured to cause the selection of such optimised GateWays 4. PGW pause of charging: with buffering of DL data in MME, SGW cannot trigger PGW pause of charging upon drop of DL packets or radio link loss (since the SGW is not aware of DL packets being dropped at the MME and since the MME does not send Release Access Bearers if it maintains the S11-U tunnel even when the UE is in idle mode). Should the MME trigger start/stop PGW charging over S11, and if so, how? a. e.g. by extending the PGW charging on/off flags on S11 or b. e.g. by the MME sending Release Access Bearer Request with the indication “Abnormal Release of Radio Link” to pause the charging (i.e. tearing down the S11-U tunnel); a subsequent MBR would implicit tell the SGW to unpause PGW charging (i.e. w/o S11-C protocol changes) SA2 response: SA2 will discuss these questions in February. 5. Can SA2 confirm that a given APN subscription will either be configured with Non-IP PDN type or an IP PDN type, never both. SA2 response: yes. The same APN shall not be provisioned in the HSS for both IP and non-IP PDN types. 6. Handover to a different MME (WB-E-UTRAN UEs with a PDN cnx) : what does happen if the target MME does not support SMS w/o combined EPS Attach ? Does the source MME need to know whether a candidate target MME supports SMS w/o combined EPS Attach ? SA2 response: SA2 wish to avoid this complexity and have modified their CRs so that the “SMS w/o combined EPS Attach” feature is only available to devices that only support NB-IoT and do not support WB-E-UTRA. Proposed Treatment: CT4 to take into account SA2's answers. Postponed to 7.2.14
1228	LS in Rel-13 Response to LS on questions on CIoT	S2	WI CIoT-CT To: CT1, RAN2, RAN3 CC: CT4, RAN1, SA3 Contact: Vodafone SA2 answers 16 questions from CT1. Proposed Treatment: CT4 to take Note of SA2's answers. Postponed to 7.2.14
1131	CR 0623 29.272 Rel-13 Allow SMS for NB-IoT UE without Combined Attach	ZTE	WI CIoT-CT CAT B
1132	CR 0624 29.272 Rel-13 Clarification on Reporting Cell ID for NB-IoT	ZTE	WI CIoT-CT CAT B
1143	discussion CT4 impacts for CIoT	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks
1144	discussion GTP-U tunneling over S11	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks
1145	CR 1689 29.274 Rel-13 S11-U tunneling for MO/MT data transport in control plane (SGi based) - with new S11-U F-TEIDs	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1146	CR 1690 29.274 Rel-13 RAT-Type extension for NB-IoT	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1147	CR 0074 29.281 Rel-13 S11-U tunneling for MO/MT data transport in control plane (SGi based)	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1148	CR 0075 29.281 Rel-13 End Marker handling by MME	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1149	CR 0332 23.007 Rel-13 S11-U Error Indication handling	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1150	CR 0333 23.007 Rel-13 S11-U Path Failure handling	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1162	CR 0046 29.336 Rel-13 Configuration for NIDD procedure over S6t	Huawei	Revised to 1193	WI CIoT-CT CAT B
1193	CR 0046 29.336 Rel-13 Authorisation for NIDD procedure over S6t	Huawei	Revision of C4-161162 WI CIoT-CT CAT B
1163	CR 0627 29.272 Rel-13 Configuration for NIDD procedureover S6a	Huawei	Withdrawn	WI CIoT-CT CAT B
1164	pCR 29.128 Rel-13 Pseudo-CR on NIDD configuration over T6a	Huawei	Withdrawn	WI CIoT-CT
1165	CR 0513 29.230 Rel-13 Definition of AVP configuration of NIDD	Huawei	WI CIoT-CT CAT B
1166	CR 0485 23.008 Rel-13 Storage of data for configuration of NIDD	Huawei	Withdrawn	WI CIoT-CT CAT B
1206	CR 1697 29.274 Rel-13 Transfer of non IP PDN to peer MME during mobility	Cisco Systems Inc	CAT B
1207	discussion Rel-13 Discussion on non IP data transfer over T6a	Cisco Systems Inc
1208	CR 0486 23.008 Rel-13 Addition of NB-IoT radio access type to the Access-Restriction-Data feature	Vodafone GmbH, Vodafone, Deutsche Telekom, Huawei	WI CIoT-CT CAT B
1209	CR 0167 23.221 Rel-13 Addition of NB-IoT radio access type to the Access-Restriction-Data feature	Vodafone GmbH, Deutsche Telekom, Huawei	WI CIoT-CT CAT B
1210	CR 1204 29.002 Rel-13 Addition of NB-IoT radio access type to the Access-Restriction-Data feature	Vodafone GmbH, Deutsche Telekom, Huawei	WI CIoT-CT CAT B
1211	CR 0630 29.272 Rel-13 Addition of NB-IoT radio access type to the Access-Restriction-Data feature	Vodafone GmbH, Deutsche Telekom, Huawei	WI CIoT-CT CAT B
1212	CR 1698 29.274 Rel-13 Addition of NB-IoT radio access type to the Access-Restriction-Data feature	Vodafone GmbH, Deutsche Telekom, Huawei	WI CIoT-CT CAT B
1213	CR 1699 29.274 Rel-13 No Delete Session Request for non-existing PDN connection	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI CIoT-CT CAT B
1214	CR 1700 29.274 Rel-13 No Create Session Request for Attach without PDN connection	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI CIoT-CT CAT B
1215	CR 1701 29.274 Rel-13 No PCI in DDN for non-IP PDN connections	Huawei	WI CIoT-CT CAT B
1216	CR 0334 23.007 Rel-13 Behaviours upon receipt of unknown NIDD	Huawei	WI CIoT-CT CAT B
1217	CR 1702 29.274 Rel-13 Dedicated Bearer NOT allowed for Non-IP PDN connections	Huawei	WI CIoT-CT CAT B
1218	CR 0335 23.007 Rel-13 Enhance restoration procedure to be compatible with PDN connection to the SCEF	Huawei	WI CIoT-CT CAT B
1232	CR 0631 29.272 Rel-13 New PDN-Type for Celular IoT	Ericsson	WI CIoT-CT CAT B
1233	pCR 29.128 Rel-13 MO Non-IP Data procedures over T6a	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT
1234	pCR 29.128 Rel-13 MT Non-IP Data procedures over T6a	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT
1235	pCR 29.128 Rel-13 Connection management procedures over T6a	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT
1236	pCR 29.128 Rel-13 Protocol for Non IP-Data over T6a	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT
1239	CR 0487 23.008 Rel-13 Storage for CIoT control plane optimization related information at MME	Cisco Systems Inc	CAT B
1242	CR 0046 29.336 Rel-13 Authorisation for NIDD procedure over S6t	Huawei, Vodafone	Revision of C4-161193 WI CIoT-CT CAT B
1249	CR 1703 29.274 Rel-13 S11-U tunneling for MO/MT data transport in control plane (SGi based) – reusing S1-U F-TEIDs	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI CIoT-CT CAT B
1256	discussion Discussion on the possible solution for GW selection	Ericsson
1257	CR 0087 29.303 Rel-13 Impacts on the DNS procedures for CIoT with introduction of NB-IoT and Non-IP	Ericsson	WI CIoT-CT CAT B
1258	CR 0436 23.003 Rel-13 DNS service for NB-IoT and Non-IP	Ericsson	WI CIoT-CT CAT B
1259	CR 1704 29.274 Rel-13 Protocol change for Connection Suspend and Resume Procedure	Ericsson	WI CIoT-CT CAT B
1260	CR 0336 23.007 Rel-13 Connection Resume procedure used during restoration	Ericsson	WI CIoT-CT CAT B
1261	CR 1705 29.274 Rel-13 Protocol change for introducing new non-IP PDN type	Ericsson	WI CIoT-CT CAT B
1264	CR 1205 29.002 Rel-13 New PDN-Type for Celular IoT	Ericsson	WI CIoT-CT CAT B
1265	CR 0520 29.230 Rel-13 New PDN-Type for Celular IoT	Ericsson	WI CIoT-CT CAT B
1266	CR 0488 23.008 Rel-13 New PDN-Type for Celular IoT	Ericsson	WI CIoT-CT CAT B
7.3	AoB	TEI13
7.3.1	GTP and PMIP	TEI13
1121	CR 1685 29.274 Rel-13 Octet number in MM context IE	Huawei	WI TEI13 CAT F
1122	CR 1686 29.274 Rel-13 Protocol Type in Create Session Request	Huawei	WI TEI13 CAT F
1134	CR 1688 29.274 Rel-13 Incorrect use of the term "full hexadecimal representation" to mean binary encoding	Oracle Corporation	WI TEI13 CAT F
1135	CR 1032 29.060 Rel-13 Incorrect use of the term "full hexadecimal representation" to mean binary encoding	Oracle Corporation	WI TEI13 CAT F
1159	CR 1691 29.274 Rel-13 Use case for inclusion of the RAN/NAS Cause in Delete Bearer Response	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI TEI13, SAES CAT F
1160	CR 0084 29.303 Rel-13 GTP-C Load Control - Mix of NAPTR records with "s" and "a" flags	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI TEI13, GOCMe CAT F
1168	CR 1693 29.274 Rel-13 Transferring AAA identifier from the ePDG to the PGW	Ericsson	Revised to C4-161276
1276	CR 1693 29.274 Rel-13 Transferring AAA identifier from the ePDG to the PGW	Ericsson, ORANGE	WI TEI13 CAT F
1171	CR 0076 29.281 Rel-13 Comprehension requirement for PDCP PDU Number	Ericsson	WI TEI13 CAT F
1186	CR 1696 29.274 Rel-13 Provide AAA information to the PGW	ORANGE	Merged into 1276	WI TEI13 CAT F
7.3.2	Diameter 29.230 CRs	TEI13
1222	LS in Rel-13 LS on Addition of AVP code definitions	S5	WI CH13, CHeISC, ANIMO, eSaMOG-CH, MONTE-CH To: CT4 Contact: ALU SA5 would like to inform CT4 about the following AVPs defined for Rel-13 charging features in TS 32.299, for incorporation into TS 29.230: <List> SA5 has implemented these AVPs using the range allocated to TS 32.299 by CT4, per CR 0459r1 (C4-151047) to TS 29.230 agreed during CT4#69, as requested in LS S5-153240/C4-151007. SA5 also asks CT4 for a new range of AVP codes allocated to TS 32.299 for Rel-14. Proposed Treatment: CT4 to comply with SA5's request and provide 29.230 CRs. Postponed to 7.3.2.
1063	CR 0503 29.230 Rel-13 Application ID for St	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI FMSS-CT CAT F
1064	CR 0504 29.230 Rel-13 AVP code range reservation for 32.299	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13 CAT F
1087	CR 0506 29.230 Rel-13 Corrections on TS numbers	Huawei	WI TEI13 CAT F
1142	CR 0510 29.230 Rel-13 AVPs for the Rx Diameter application	Ericsson	WI TEI13 CAT B
1177	CR 0514 29.230 Rel-13 AVP codes for 32.299	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13 CAT F
1241	CR 0504 29.230 Rel-13 AVP code range reservation for 32.299	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	Revision of C4-161064 WI TEI13 CAT F
1247	CR 0518 29.230 Rel-13 Codes for 29.212	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13 CAT F
7.3.3	EPS AAA interfaces (29.273)	TEI13
1098	CR 0447 29.273 Rel-13 Extension on TWAN-S2a-Failure-Cause	Huawei	WI TEI13 CAT F
1099	CR 0448 29.273 Rel-13 Authorize the UE requested APN	Huawei	WI TEI13 CAT F
1184	CR 0451 29.273 Rel-13 Transfer AAA information to avoid SWx redirection	ORANGE	WI TEI13 CAT F
1187	discussion Rel-13 Transfer AAA information to avoid HSS overload	ORANGE
7.3.4	Restoration Procedures (23.007)	TEI13
1068	discussion Rel-13 An Issue on HSS failure recover procedure	NEC EUROPE LTD	WI TEI13
1069	CR 1654 29.274 Rel-13 Fix the issue on HSS restart procedure	NEC EUROPE LTD	Revision of C4-151951 WI TEI13 CAT F
1070	CR 0619 29.272 Rel-13 Fix the issue on HSS restart procedure	NEC EUROPE LTD	WI TEI13 CAT F
1123	CR 0331 23.007 Rel-13 Correct the partial failure handling on SGW	Huawei	WI TEI13 CAT F
7.3.5	Addressing and Subscriber Data Handling (23.003 and 23.008)	TEI13
1138	CR 0484 23.008 Rel-13 Handover to Non-3GPP Access Not Allowed	Ericsson	WI TEI13 CAT F
1262	CR 0437 23.003 Rel-13 ePDG selection with DNS-based Discovery of Regularory Requirements	Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, Nokia Networks	WI TEI13 CAT B
7.3.6	Diameter based Interfaces (29.272, 29.173)	TEI13
1136	CR 0625 29.272 Rel-13 Adjacent PLMNs	Ericsson	WI TEI13 CAT F
1137	CR 0626 29.272 Rel-13 Invocation of Alert procedure by HSS after ULR	Ericsson	WI TEI13 CAT F
1175	CR 0628 29.272 Rel-13 Subscription data for combined MME/SGSN	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13 CAT F
7.3.7	IMS	TEI13
1074	CR 0542 29.328 Rel-13 Implicit Identities for PSI	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13 CAT F
1089	CR 0543 29.328 Rel-13 Data returned in IMSPublicIdentity correction, new EnhancedPublicIdentifiers class	Ericsson	Revised to 1263	CAT F
1263	CR 0543 29.328 Rel-13 Data returned in IMSPublicIdentity correction, new EnhancedPublicIdentifiers class	Ericsson	Revision of C4-161089 CAT F
1090	CR 0662 29.228 Rel-13 De-registration of emergency registration correction	Ericsson	CAT F
1091	CR 0544 29.328 Rel-13 Local Time Zone for CS retrieval	Ericsson	CAT F
7.3.8	MAP	TEI13
1161	CR 1203 29.002 Rel-13 Time Zone in MAP-Any-Time-Interrogation	Ericsson	WI TEI13 CAT B
7.3.9	H.248 Interfaces	TEI13
1045	CR 0090 23.333 Rel-13 Removal of references to TS 26.235	Ericsson	WI TEI13 CAT F
1046	CR 0083 29.333 Rel-13 Removal of references to TS 26.235	Ericsson	WI TEI13 CAT F
1047	CR 0658 29.232 Rel-13 Removal of references to TS 26.236	Ericsson	WI TEI13 CAT F
1048	CR 0197 29.332 Rel-13 Removal of references to TS 26.236	Ericsson	WI TEI13 CAT F
7.3.10	EGPRS Access Security Enhancements in relation to Cellular IoT	EASE_EC_GSM
1071	CR 0476 23.008 Rel-13 User Plane Integrity Protection Indicator	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI EASE_EC_GSM CAT F
1072	CR 1201 29.002 Rel-13 User Plane Integrity Protection Indicator	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI EASE_EC_GSM CAT F
1073	CR 0620 29.272 Rel-13 User Plane Integrity Protection Indicator	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI EASE_EC_GSM CAT F
7.3.11	18 bits PDCP PDU Number	TEI13, LTE_CA_enh_b5C-Core
1029	LS in Rel-13 LS on extension to field length of PDCP Sequence Number	R2	WI LTE_CA_enh_b5C-Core To: RAN3, CT4 CC: SA3 Contact: Nokia RAN2 would like to inform RAN3, CT4 and SA3 that RAN2 has taken as a baseline to extend the field length of PDCP SN [TS 36.323] for AM DRB for both UL and DL to 23 bits in Rel-13, in addition to the previous maximum value of 15 bits (which is per DRB configurable). The FMS field in PDCP STATUS PDU is also extended to 23 bits and the size of BITMAP is increased accordingly. In the related discussion this was recognized to have impact also to RAN3 and CT4 specifications. RAN2 respectfully asks RAN3 and CT4 groups to update their Rel-13 specifications to accommodate the longer PDCP SN length. Proposed Treatment: See C4-161030 postponed from our last meeting. CT4 to take action on this increased length. Postponed to 7.3.11
1030	LS in Rel-13 LS on extension to field length of PDCP Sequence Number	R2	WI LTE_CA_enh_b5C-Core Postponed from Last Meeting. WI LTE_CA_enh_b5C-Core To: RAN3, CT4 Cc: SA3 Contact: Nokia RAN2 would like to inform RAN3, CT4 and SA3 that RAN2 has taken as a baseline to extend the field length of PDCP SN [TS 36.323] for AM DRB for both UL and DL to 23 bits in Rel-13, in addition to the previous maximum value of 15 bits (which is per DRB configurable). The FMS field in PDCP STATUS PDU is also extended to 23 bits and the size of BITMAP is increased accordingly. In the related discussion this was recognized to have impact also to RAN3 and CT4 specifications. 2. Actions: To RAN3 and CT4 groups. ACTION: RAN2 respectfully asks RAN3 and CT4 groups to update their Rel-13 specifications to accommodate the longer PDCP SN length. Proposed Action: Postponed from our last meeting where we agreed to wait for the agreed CR in RAN2 before we update CT4 specifications accordingly from Rel-13. Concerns were raised about the backwards compatibility and the extensibility of these changes. Requested to update CT4 specifications accordingly from Rel-13. Postponed until we get more info from RAN2. See RAN2's LS in C4-161029. Postponed to 7.3.11
1181	discussion Prolonging PDCP PDU numbers to 18 bits	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell
1182	CR 0077 29.281 Rel-13 18 bits PDCP PDU Number	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI13, LTE_CA_enh_b5C-Core CAT F
8	Release 12
8.1	CT4 Led WIs
8.1.1	IM-SSF Application Server Service Data Descriptions	IMS_SSFDD
8.1.2	Diameter based interface between SGSN-GMLC	Dia_SGSN_GMLC
8.1.3	Diameter based interface between SGSN and SMS central functions	Dia_SGSN_SMS
8.1.4	CT aspects of Extended IMS media plane security	eMEDIASEC-CT
8.1.5	Study on Diameter Overload Control Mechanisms	FS_DOCME
8.1.6	eMBMS Restoration Procedures	eMBMS_Rest
8.1.7	LCore Network Aspects of SIPTO at the Local Network	LIMONET-SIPTO
8.1.8	CT Aspects of Coordination of Video Orientation	CVO-CT
8.1.9	CT Aspects of Coordination of Signalling of Image Size	SIS-CT
8.1.10	GTP-C Overload Control Mechanisms	GOCMe
8.1.11	CT Aspects of LTE HRPD Inter-RAT SON (S104 Interface)	LTE_HRPD_SON-CT
8.1.12	P-CSCF Restoration Enhancements	P-CSCF_RES
8.1.13	Study on Shared Data Update for Multiple Subscribers	FS_SHARED_SubData_UPD
8.1.14	BB1: Small Data and Device Triggering Enhancements (SDDTE) CT	MTCe-SDDTE-CT
8.1.15	ICE Impacts on IMS H.248 Profiles	ICEH248
8.1.16	Support of ALTC Attribute (IPv4/IPv6 interworking)	ALTC
1015	discussion 29.238 Rel-14 Alternate IP Connectivity: upgrade options for ALTC support by H.248 gateways	Alcatel-Lucent	WI ALTC
8.1.17	Diameter Overload Control	DOCME
8.1.18	Dual Connectivity	LTE_SC_enh_dualC-CT
8.1.19	CT impacts of Codec for Enhanced Voices Services	EVS_codec-CT
1016	discussion 23.334 Rel-13 Clarification of EVS codec support by 3GPP H.248 Media Gateways	Alcatel-Lucent	WI EVS_codec-CT
1188	CR 0108 23.334 Rel-12 Corrections to EVS AMR-WB IO mode-change-capability MIME parameter handling	Nokia Networks	WI EVS_codec-CT CAT F
1189	CR 0109 23.334 Rel-13 Corrections to EVS AMR-WB IO mode-change-capability MIME parameter handling	Nokia Networks	WI EVS_codec-CT CAT A
1198	CR 0092 23.333 Rel-12 Corrections to EVS AMR-WB IO mode-change-capability MIME parameter handling	Nokia Networks	WI EVS_codec-CT CAT F
1200	CR 0093 23.333 Rel-13 Corrections to EVS AMR-WB IO mode-change-capability MIME parameter handling	Nokia Networks	WI EVS_codec-CT CAT A
8.2	CT4 Supported WIs
8.2.1	Enhanced S2a Mobility Over trusted WLAN access to EPC	eSaMOG_St3
8.2.2	Network-Provided Location information for IMS TWAN Case	NETLOC_TWAN_CT
8.2.3	Core Network Overload ULI Reporting Improvements	CNO_ULI-CT
8.2.4	Proximity Services	ProSe-CT
8.2.5	IMS Web RTC	IMS_WebRTC
1014	discussion 29.334 Rel-14 IMS-WebRTC Rel-14: potential enhancements for IMS-WebRTC gateways	Alcatel-Lucent	WI IMS_WebRTC-CT4
8.2.6	IMS Signalling Activated Trace	ISAT
8.2.7	IMS-based Telepresence (Stage 3)	IMS_TELEP
8.2.8	BB1: Policy and Charging Control	P4C-F-CT3
8.2.9	Machine-Type Communications UEs	MTCe-UEPCOP-CT
8.2.10	SMS submit and delivery without MSISDN in IMS	SMSMI-CT
8.2.11	Reporting Enhancements in Warning Message Delivery	REP_WMD
8.2.12	Group Communication System Enablers for LTE	GCSE_LTE-CT
8.2.13	CT aspects of WLAN/3GPP Radio Interworking	UTRA_LTE_WLAN_interw-CT
8.3	AoB	TEI12
8.3.1	GTP and PMIP	TEI12
1019	LS in Rel-13 Reply LS on Mapping table between GTPv2 S2a and WLCPDiameter	C1	To: CT4 Contact: Huawei CT1 thanks the LS from CT4 about the definition of mapping table between GTP and WLCP/Diameter. CT1 has reviewed the CT4 CRs, and decided to introduce the reject causes "user authentication failed" and "PDN connection does not exist" to CT1's TS 24.244 WLCP (MCM, from TWAN to the UE) and TS 24.302 for EAP message (SCM, from 3GPP AAA Server to the UE). CT1 would like CT4 to note that these agreed CRs are only from Rel13. (see attached). Proposed Treatment: CT4 to necessary resultant action. GTP/WLCP CRs produced by Huawei in 8.3.1 Postponed to 8.3.1
1096	CR 1683 29.274 Rel-12 Add cause values to TWAN mapping table	Huawei	WI TEI12 CAT F
1097	CR 1684 29.274 Rel-13 Add cause values to TWAN mapping table	Huawei	WI TEI12 CAT F CAT A?
8.3.2	Addressing and Subscriber Data Handling (23.003, 23.008)	TEI12
8.3.3	IMS	TEI12
8.3.4	Diameter based Interfaces (29.272, 29.173)	TEI12
8.3.5	EPS AAA interfaces (29.273)	TEI12
8.3.6	MAP and MAP IWF	TEI12
8.3.7	Diameter 29.230 CRs	TEI12
1245	CR 0516 29.230 Rel-12 AVP Codes for 29.12	Nokia Networks, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell	WI TEI12 CAT F
8.3.8	Restoration Procedures (23.007)	TEI12
8.3.9	H.248 Interfaces (Mn, Mp, …)	TEI12
9	Release 11
9.1	UDC Data Reference Model	UDC_DM
9.2	EPC Nodes Failure	FS_ EPC_NR
9.3	Enhanced Nodes Restoration for EPC	eEPC_NR
9.4	Reference Location Information	RLI
9.5	Anonymous Call Rejection in the CS Domain	ACR_CS-CN
9.6	CT aspects of VPLMN Autonomous CSG Roaming	VCSG-St3
9.7	GCSMSC and GCR Redundancy for VGCS/VBS	RT_VGCS-Red
9.8	BBF Interworking Building Block I	BBAI_BBI-CT
1065	CR 0002 29.139 Rel-11 Complete the EXTERNAL_SOURCE_IP4_NAT_INFO attribute information according to IANA registration	ZTE/Joy	WI BBAI_BBI-CT CAT F
1066	CR 0003 29.139 Rel-12 Complete the EXTERNAL_SOURCE_IP4_NAT_INFO attribute information according to IANA registration	ZTE/Joy	WI BBAI_BBI-CT CAT A
1067	CR 0004 29.139 Rel-13 Complete the EXTERNAL_SOURCE_IP4_NAT_INFO attribute information according to IANA registration	ZTE/Joy	WI BBAI_BBI-CT CAT A
9.9	BBF Interworking Building Block II	BBAI_BBII-CT
9.10	BBF Interworking Building Block III	BBAI_BBIII-CT
9.11	Single Radio Video Call Continuity	vSRVCC-CT
9.12	Single Radio Voice Call Continuity from UTRAN/GERAN to E-UTRAN/HSPA	rSRVCC-CT
9.13	System Improvements to Machine-Type Communication	SIMTC
9.13.1	SIMTC CS Aspects	SIMTC-CS
9.13.2	Reachability Aspects of SIMTC	SIMTC-Reach
1100	discussion Rel-11 SCS Identity Format	Hewlett-Packard Enterprise
1101	CR 0041 29.336 Rel-11 SCS identity format	Hewlett-Packard Enterprise	CAT F
1102	CR 0042 29.336 Rel-12 SCS identity format	Hewlett-Packard Enterprise	CAT A
1103	CR 0043 29.336 Rel-13 SCS identity format	Hewlett-Packard Enterprise	CAT A
9.13.3	SMS Aspects of SIMTC	SIMTC-PS_Only
9.14	LOcation-Based Selection of gaTEways foR WLAN	LOBSTER-CT
9.15	CN aspects of Mobility based On GTP & PMIPv6 for WLAN access to EPC	SaMOG_WLAN- CN
9.16	GBA extension Stage 3	GBA- ext-St3
9.17	Enhancement of the Protocols for SMS over SGs	PROTOC_ SMS_SGs
9.18	Enhancements for Multimedia Priority Service (MPS) Gateway Control Priority	eMPS_ Gateway
9.19	Service Identification for RRC Improvements in GERAN	SIRIG
9.20	Network Provided Location Information	NWK-PL2IMS-CT
9.21	IMS	TEI11
9.22	GTP	TEI11
9.23	P-CSCF Recovery	TEI11
9.24	PS Additional Number	PSAN
9.25	Generic IMS User Group Over Sh	GenUG_Sh
9.26	Full Support of Multi-Operator Core Network by GERAN => Network Sharing	Full_MOCN-GERAN
9.27	IMS Operator Determined Call Barring (Stage 3)	IODB
9.28	Enhanced T.38 FAX Support (Stage 3)	MMTel_T.38_FAX
9.29	AoB	TEI11
9.29.1	Diameter based Interfaces (29.272, 29.173)	TEI11
9.29.2	EPS AAA interfaces (29.273)	TEI11
9.29.3	Diameter 29.230 CRs	TEI11
9.29.4	MAP and MAP IWF	TEI11
9.29.5	Addressing and Subscriber Data Handling (23.003, 23.008)	TEI11
10	Release 10 and Earlier
10.1	Local Call Local Switch	LCLS-CN
10.2	Enhanced User Data Convergence	eUDC
10.3	Selected IP Traffic Offload	SIPTO
10.4	Local IP Access	LIPA
10.5	Network Improvements for Machine Type Communications	NIMTC
10.6	EPC Nodes Failure
10.6.1	EPC Nodes Failure ISR not active	EPC_NR
10.6.2	EPC Nodes Failure ISR active	EPC_NR_wISR
10.7	Enabling Coder Selection and Rate Adaptation for UTRAN and E-UTRAN for Load Adaptive Applications	ECSRA_LAA-CN
10.8	S2b Mobility based On GTP	SMOG-ST3
10.9	Multi Access PDN Connectivity	MAPCON-st3
10.10	Enhanced Multimedia Priority Service	eMPS-CN
10.11	PCRF Restoration	PCRF-FR
10.12	eSRVCC	eSRVCC
10.13	Minimisation of Drive Test (MDT)	OAM-PM-UE
10.14	Relay Node	LTE_Relay
10.15	MTRF	MTRF
10.16	GTP	TEI8, TEI9, TEI10
10.17	PMIP	TEI8
10.18	IMS	TEI8, TEI9
1104	CR 0545 29.328 Rel-8 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT F
1105	CR 0546 29.328 Rel-9 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT A
1106	CR 0547 29.328 Rel-9 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	Withdrawn	CAT A
1107	CR 0548 29.328 Rel-10 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT A
1108	CR 0549 29.328 Rel-11 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT A
1109	CR 0550 29.328 Rel-12 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT A
1110	CR 0551 29.328 Rel-13 Encoding of IP-SM-GW Number	Hewlett-Packard Enterprise	CAT A
1111	CR 0478 23.008 Rel-8 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT F
1112	CR 0479 23.008 Rel-9 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT A
1113	CR 0480 23.008 Rel-10 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT A
1114	CR 0481 23.008 Rel-11 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT A
1115	CR 0482 23.008 Rel-12 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT A
1116	CR 0483 23.008 Rel-13 IP-SW-GW number format	Hewlett-Packard Enterprise	CAT A
1124	CR 0552 29.328 Rel-10 Encoding of SC Address	Hewlett-Packard Enterprise	CAT F
1125	CR 0553 29.328 Rel-11 Encoding of SC Address	Hewlett-Packard Enterprise	CAT A
1126	CR 0554 29.328 Rel-12 Encoding of SC Address	Hewlett-Packard Enterprise	CAT A
1127	CR 0555 29.328 Rel-13 Encoding of SC Address	Hewlett-Packard Enterprise	CAT A
10.19	Any other Business	TEI8, TEI9, TEI10
10.19.1	Diameter 29.230 CRs	TEI8
10.19.2	EPS AAA interfaces (29.273)	TEI8
11	Update of the Work Plan
1275	CT4 Aspects of the Workplan	CT4 Chairman
12	AoB
13	Future meetings
14	Check of Approved Output Documents
CT4#72 List of Output Documents	CT4 Chairman
15	Closing of the Meeting (17:00 Friday)